Pemodelan Sistem Perangkat Lunak Andronicus Riyono, M.T. Universitas Kristen Duta Wacana
1
Building Software, Requirements, Changes Pemodelan Sistem Perangkat Lunak Pertemuan 2
2
Bagian I: Building Software Pemodelan Sistem Perangkat Lunak Pertemuan 2
3
Menurut Anda, apakah ‘Pemrograman’ itu? ________________________________ ________________________________ ________________________________ ________________________________
4
Pemrograman adalah •
menyuruh komputer agar melakukan apa yang kita ingin komputer lakukan
• •
untuk mempermudah kehidupan manusia proses pembuatan (writing), pengujian (testing), perbaikan (debugging/troubleshooting), dan pengelolaan (maintaining) kode program komputer
5
Membuat Software, Menyelesaikan Masalah •
Kita membuat perangkat lunak untuk menyelesaikan masalah. Orang-orang memiliki masalah.
•
Jadi, kita membuat perangkat lunak untuk membantu orang-orang
•
Perangkat lunak yang baik tidak hanya dapat menyelesaikan masalah, namun mudah disesuaikan dengan perubahan.
6
Toko Blackberry milik si Jerry Menyimpan data tentang berbagai macam Blackberry Mencari Blackberry yang sesuai untuk para pelanggan
7
Yang telah dibuat Blackberry family : String model : String price : double getPrice() : double setPrice(newPrice : double) getFamily() : String getModel() : String
Inventory blackberries : List addBlackberry(family : String, model : String, price : double) getBlackberry(model : String) : Blackberry searchBlackberry(searchedFor : Blackberry) : Blackberry
•
Apakah Anda paham maksud diagram ini?
8
family: Curve model: 8300 price: 200
family: Bold model: 9000 price: 650
price: 600
price: 750
Stok di family: Curve family: Storm gudang model: 8330 model: 9530 price: 500 price: 700 milik si family: Curve family: Tour model: 8900 Jerry model: 9630 9
Koq nggak ada? “Saya mau beli. Saya dari tadi sudah cari-cari. Gimana ini?” “yang dicari apa pak?” “bold 9000” *hmm, ada koq di gudang* 10
Koq nggak ada? “Saya mau beli. Saya dari tadi sudah cari-cari. Gimana ini?” “yang dicari apa pak?” “bold 9000” *hmm, ada koq di gudang* bold != BOLD != Bold 11
method search dalam class Inventory public Blackberry search(Blackberry searchedBlackberry) { for (Iterator i = blackberries.iterator(); i.hasNext(); ) { Blackberry blackberry = (Blackberry)i.next(); String family = searchedBlackberry.getFamily(); if ((family != null) && (!family.equals("")) && (!family.equals(blackberry.getFamily()) continue; return blackberry; } return null; }
12
Apa yang bisa dilakukan? ________________________________ ________________________________ ________________________________ ________________________________
13
Apa yang bisa dilakukan? •
Mengubah agar pembandingan family mengabaikan besar kecil huruf
•
Mengubah agar semua pembandingan mengabaikan besar kecil huruf
• •
Menggunakan konstanta untuk family Bicara dengan Jerry untuk mendapat detil permasalahan yang dihadapi
14
15
16
Langkah pertama untuk Great Software 1. Pastikan bahwa perangkat lunak yang Anda buat bekerja sesuai dengan apa yang diperlukan oleh customer
17
Langkah 1: Tanya Jerry Pertanyaan apa saja kah yang akan Anda tanyakan ke Jerry?
18
Pertanyaan-Pertanyaan untuk si Jerry ________________________________ ________________________________ ________________________________ ________________________________
19
Pertanyaan-Pertanyaan untuk si Jerry • • •
Apakah hanya berjualan BlackBerry saja?
•
Apakah perlu laporan gudang dan laporan penjualan?
Bagaimana proses update Inventory? Bagaimana proses pencarian yang seharusnya?
20
Jawaban Jerry •
Pembeli seringkali tidak tahu detil dari apa yang mereka cari
•
Seringkali ada lebih dari satu model yang sebenarnya sesuai dengan apa yang dicari oleh pembeli
• •
Pembeli sering mencari berdasarkan harga Laporan perlu, tapi yang paling penting adalah mencari BlackBerry untuk pembeli
21
Yang harus dilakukan 1. Apabila di gudang ada BlackBerry yang dicari pembeli, maka harus ditemukan 2. Kesalahan pengetikan oleh pembeli harus ditoleransi, atau buat supaya tidak mungkin memasukkan data yang salah dalam pencarian
22
method search dalam class Inventory public Blackberry search(Blackberry searchedBlackberry) { for (Iterator i = blackberries.iterator(); i.hasNext(); ) { Blackberry blackberry = (Blackberry)i.next(); String family = searchedBlackberry.getFamily().toLowerCase(); if ((family != null) && (!family.equals("")) && (!family.equals(blackberry.getFamily().toLowerCase()) continue; } return null; }
23
Perubahan Pertama Menghilangkan String • •
private Family family; public enum Family { CURVE, BOLD, STORM, TOUR; public String toString() { switch(this) { case CURVE: return "Curve"; case BOLD: return "Bold"; case STORM: return "Storm"; case TOUR: return "Tour"; } } } 24
Perubahan Pertama Menghilangkan String (lanjutan) public Blackberry search(Blackberry searchedBlackberry) { for (Iterator i = blackberries.iterator(); i.hasNext(); ) { Blackberry blackberry = (Blackberry)i.next(); if (blackberry.getFamily() != searchedBlackberry.getFamily()) continue; return blackberry; } return null; }
25
Perubahan Pertama Menghilangkan String (lanjutan) Blackberry family : Family model : String price : double getPrice() : double setPrice(newPrice : double) getFamily() : Family getModel() : String
Inventory blackberries : List addBlackberry(family : Family, model : String, price : double) getBlackberry(model : String) : Blackberry searchBlackberry(searchedFor : Blackberry) : Blackberry
26
Dampak Perubahan • •
Ubah form untuk menambah data Ubah database inventory
27
Apakah sudah cukup? • • •
Lebih dari satu hasil pencarian (hal 20)
•
mengembalikan array? atau List?
Hanya menyebut sebagian saja (hal 25)
•
kasus di buku, GuitarSpec (encapsulation)
pelajari .ppt dari Head First OOA&D
28
Increments & Iterations • •
Iterative development
• •
Mengulangi langkah-langkah proses pengembangan Semakin pendek semakin baik
Incremental development
• •
Tambahkan sedikit demi sedikit Tidak ada "Big Bang"
Goal
Start
29
Akhir dari Bagian Pertama
30
Bagian II: Requirements Pemodelan Sistem Perangkat Lunak Pertemuan 2
31
•
Kita membuat perangkat lunak karena suatu alasan...
•
Kita membuat perangkat lunak untuk orang-orang yang memerlukannya...
•
Kita perlu tahu apa yang orang-orang inginkan dari perangkat lunak yang kita buat
•
Inilah yang disebut REQUIREMENTS
32
Siapa yang menentukan requirements? ________________________________ ________________________________ ________________________________ ________________________________
33
Siapa yang menentukan requirements? • • • • •
Pembeli Pengguna akhir Tim pengembang Manajemen Penyedia teknologi
pihak-pihak inilah yang disebut sebagai Stakeholders 34
Aplikasi yang akan dibahas pada bagian ini •
Doug, Dog, Door (Bab 2, buku HF OOA&D)
35
Pekerjaan yang ditawarkan... Todd dan Gina memerlukan pintu dengan remote control agar mereka dapat membuka pintu dari kamar tidur mereka jika Fido, anjing peliharaan mereka, membangunkan mereka di tengah malam.
36
Gambaran awal produk
37
Requirements 1. Tekan tombol pada remote control, pintu akan terbuka "Ini yang harus kita buat, setidaknya, begitu kata Doug."
2. Tekan tombol lagi untuk menutup pintu
"Kamu yakin, cuma itu saja yang perlu kita buat? Ayo kita desain dulu sebelum implementasi"
38
Requirement - dua class •
DogDoor ‣
Buka
‣
Tutup
‣
Tunggu sinyal dari remote control
•
Remote ‣
Beri sinyal ke pintu untuk menutup atau membuka
‣
Mengenali ketika tombol ditekan
Fokus pada class responsibility (sebuah class bertanggung jawab atas apa saja?)
39
public class DogDoor {
public class Remote {
private boolean open;
private DogDoor door;
public DogDoor() { this.open = false; }
public Remote(DogDoor door) { this.door = door; }
public void open() { System.out.println("The dog door opens."); open = true; }
public void pressButton() { System.out.println("Pressing the remote control button..."); if (door.isOpen()) { door.close(); } else { door.open(); } }
public void close() { System.out.println("The dog door closes."); open = false; } public boolean isOpen() { return open; }
}
}
40
Pertanyaan dari departemen QA* "Yakin programnya bekerja dengan baik? Mana pengujiannya?"
*Quality Assurance 41
Program Pengujian (dari buku HF OOA&D) public class DogDoorSimulator { public static void main(String[] args) { DogDoor door = new DogDoor(); Remote remote = new Remote(door); System.out.println("Fido barks to go outside..."); remote.pressButton(); System.out.println("\nFido has gone outside..."); remote.pressButton();
Apakah pengujian ini sudah baik? Mengapa?
System.out.println("\nFido's all done..."); remote.pressButton(); System.out.println("\nFido's back inside..."); remote.pressButton(); } } 42
Pembeli adalah Raja
43
Mari introspeksi •
Sudah membuat tepat seperti yang diperintahkan Doug
• • • •
Sudah melakukan pengujian Pintu bekerja sesuai program yang dibuat Hardware OK Software OK Lantas, apa yang salah? 44
Apakah requirement itu? •
Requirement adalah fitur yang harus dimiliki sistem untuk memuaskan pembeli
•
Requirement adalah sesuatu yang harus dilakukan oleh sistem yang dibuat
Apakah sudah memenuhi requirements? 45
Mendefinisikan masalah • • • • •
Bicara dengan pembeli Bicara dengan stakeholders lain Bertanya Brainstorm Coba lihat permasalahan dari berbagai sudut pandang yang mungkin
46
Kami tidak ingin pergi dari kamar di tengah malam. Kami mau pintu yang bisa dibuka dengan remote control dan menutup otomatis setelah anjing kembali dari luar Saya ingin Fluffy bisa keluar tanpa saya harus pergi membukakan pintu, tapi saya hanya ingin pintu terbuka bila saya mengizinkannya
saya hanya ingin keluar
47
Apa yang kita tahu ‣ Doug ‣ Kita perlu sistem segera jadi ‣ Sistem yang dibuat harus hemat biaya ‣ Hardware engineer ‣ Pintu punya dua macam sinyal ‣ Cek kondisi saat ini (terbuka/tertutup) ‣ Ubah kondisi pintu (buka tutup, tutup buka) ‣ Remote mengirim satu sinyal saja (ketika tombol ditekan) ‣ Pembeli menyatakan bahwa ‣ Pintu harus dapat terbuka dengan menekan tombol remote ‣ Pintu harus dapat menutup setelah anjing kembali ‣ Requirement yang tersirat dari pernyataan pembeli ‣ Pintu tidak boleh tertutup ketika anjing sedang melewatinya ‣ Pintu harus tertutup secara otomatis tanpa menekan remote 48
Requirements (dari buku)
49
Skenario
50
Skenario
51
Skenario
52
Skenario
53
Skenario
54
Apakah kita perlu diagram?
55
Skenario lain •
Fido tidak pergi keluar, tapi malah diam di dalam rumah
• •
Fido tidak kembali ke dalam rumah
•
...
Pintu menutup ketika Fido sedang melalui pintu
56
Salam kenal dari Use Case Use Case mendeskripsikan apa yang dilakukan sistem untuk mencapai tujuan tertentu yang diinginkan oleh pembeli
57
Use Case •
Use Case adalah teknik untuk mendapatkan potential requirements dari sebuah sistem baru atau perubahan software
•
Setiap Use Case memberi satu atau lebih skenario yang menunjukkan bagaimana sistem harus berinteraksi dengan pengguna atau sistem lain untuk mencapai tujuan tertentu
58
Satu Use Case, Tiga Bagian •
Sebuah Use Case harus
•
Memiliki langkah-langkah lengkap yang bernilai bagi seseorang
• •
Memiliki kondisi awal dan akhir Dimulai oleh Actor (seseorang atau sesuatu yang bukan bagian dari sistem yang dibuat)
59
Intinya... •
Use case pasti
• • • •
bernilai (terhadap kegunaan sistem) lengkap (ada kondisi awal dan akhir) dimulai oleh actor menunjukkan sebuah tujuan dari sistem
60
Use Case ≠ Scenario •
Skenario adalah salah satu cara untuk mencapai tujuan dari sebuah kondisi awal
•
Use Case mendeskripsikan semua cara yang mungkin untuk mencapai tujuan dari sebuah kondisi awal
61
Bagian-bagian Use Case • • • • • • •
Nama: biasanya kata kerja + kata benda (misal: mengambil matakuliah) Deskripsi: satu atau dua paragraf yang menjelaskan tujuan dan nilai (hasil) Actors: nama actor(s) yang terlibat Basic Flow: yang paling umum atau yang diharapkan dalam use case Alternate Flows: yang mungkin terjadi Preconditions: kondisi yang harus terpenuhi sebelum use case dapat dinyatakan dimulai Postconditions: kondisi yang harus terpenuhi ketika use case selesai 62
Seberapa formal?
Jika berhasil/berguna, gunakan! 63
import java.util.Timer; import java.util.TimerTask; public class Remote { private DogDoor door;
Dog Door v.2
public Remote(DogDoor door) { this.door = door; } public void pressButton() { System.out.println("Pressing the remote control button..."); if (door.isOpen()) { door.close(); } else { door.open();
sepertinya karma tanggungjawab tidak seimbang
final Timer timer = new Timer(); timer.schedule(new TimerTask() { public void run() { door.close(); timer.cancel(); } }, 5000); } } } 64
Requirement - dua class •
DogDoor ‣
Buka
‣
Tutup
‣
Tunggu sinyal dari remote control
‣
Tutup pintu setelah 5 detik
•
Remote ‣
Beri sinyal ke pintu untuk menutup atau membuka
‣
Mengenali ketika tombol ditekan
Information Expert Pattern (LAR, 283, 294) 65
Looking ahead
66
Looking ahead
67
Looking ahead
68
Apa saja kira-kira fitur untuk versi berikutnya? ________________________________ ________________________________ ________________________________ ________________________________
69
Akhir dari Bagian Kedua
70
Bagian III: Perubahan Pemodelan Sistem Perangkat Lunak Pertemuan 2
71
dan Anda bertanggungjawab untuk mengubah program buatan Anda
72
Great dog door, but... Bisakah ditambahkan hardware untuk mengenali gonggongan Fido ketika Fido ingin pergi keluar dan kembali serta otomatis membuka pintunya? Dengan demikian kami tidak perlu mendengarnya atau mencari remotenya.
73
Kemungkinan perubahan ________________________________ ________________________________ ________________________________ ________________________________
74
Kemungkinan perubahan • • • •
Hardware (baru dan modifikasi) Use Case Kode program (implementasi, pengujian) ...
75
Skenario Lama Gina, open the dog door…Fido won’t quit barking! Woof! Woof! Woof! Woof!
1 Fido barks to be let out.
I feel much better now!
6.1 The door shuts automatically.
2 Todd or Gina hears Fido barking. 4 The dog door opens.
3 Todd or Gina presses the button
on the remote control.
5 Fido goes outside.
6.2 Fido barks to be let back inside.
Again with the barking! Someone let Fido back inside 6 Fido does his business. 6.3 Todd or Gina hears
Fido barking (again).
6.4 8 The door shuts automatically.
7
Fido goes back inside.
Todd or Gina presses the button on the remote control.
6.5 The dog door opens (again).
76
Skenario Baru 2 Todd or Gina hears
Fido barking.
3 Todd or Gina presses
the button on the remote control.
1 Fido barks to be let out. 6.1 The door shuts automatically. 2.1 The bark recognizer
“hears” a bark.
3.1 The bark recognizer
sends a request to the door to open.
4 The dog door opens. 5 Fido goes outside.
6.3.1 The bark recognizer
“hears” a bark (again).
6.2 Fido barks to be let back inside.
6.4.1 The bark recognizer
sends a request to the door to open.
6 Fido does his business. 6.3 Todd or Gina hears
Fido barking (again).
6.4 8 The door shuts automatically.
7 Fido goes back inside.
Todd or Gina presses the button on the remote control.
6.5 The dog door opens (again).
77
Alternate Path
Masuk akal? Ada ide untuk perbaikan?
78
79
Urutan hasil Requirements Documentation
Design documents and classes Tests
Code
80
Desain Lama Multiplicity
Association
81
Desain Baru
82
BarkRecognizer class public class BarkRecognizer { private DogDoor door;
Hmm, mudah sekali membuatnya!
public BarkRecognizer(DogDoor door) { this.door = door; }
+
}
public void recognize(String bark) { System.out.println(" BarkRecognizer: Heard a '"
}
bark + "'"); door.open();
83
Untung kita sudah mengaplikasikan pola Information Expert.
Mengapa untung? Apakah ada prinsip yang penting di sini?
84
Jika tidak... Copy saja kode untuk menutup pintu otomatis dari Remote ke BarkRecognizer
Ini Doug. Dia bukan programmer.
Bagaimana menurut Anda? Apakah ide Doug ini baik?
85
Yang salah dari ide Doug • •
Kemungkinan kesalahan copy-paste
•
Semakin banyak copy, semakin banyak yang harus diubah ketika ada perubahan requirement
•
Tidak rapi dan jelek
Kalau ada peralatan lain, maka perlu copy kodenya lagi, dan lagi, dan lagi.
86
Guk! (artinya: apa kegunaan parameter Bark di BarkRecognizer?
Apa parameter Bark itu? Apakah kita memerlukannya? Apa yang harus kita lakukan?
87
Versi kedua siap diluncurkan •
• •
Kita telah melampaui sebuah iterasi Requirement Design Code Test Kita mengerjakan suatu bagian pekerjaan yang dapat dikelola Kita meluncurkan sistem yang bekerja dengan baik
• • • •
88
Mari berpikir •
•
Apakah Remote dan BarkRecognizer mirip?
• •
Bisakah kemiripannya dienkapsulasi? Bagaimana perubahan ini berpengaruh terhadap sistem?
Class Bark belum diimplementasi, bagaimana mengimplementasinya?
•
Apa yang kita dapatkan?
89
Akhir dari Bagian Ketiga
90
Referensi •
Craig, L. (2004). Applying UML and patterns: An introduction to objectoriented analysis and design and iterative development. Westford, MA: Prentice Hall PTR.
•
McLaughlin, B.D., Pollice, G., & West, D. (2006). Head first object-oriented analysis & design. Sebastopol, CA: O'Reilly.
91
