Pertemuan 08:

1. Pertemuan 08: Systems Analysis and Design Oleh: Purwanto, S.Si, M.Kom Purwanto, S.Si, M.Kom

2. Langkah 1: Mengidentifikasi Asosiasi dan Multiplicity • Perlu mengidentifikasi asosiasi yang ada di antara objek dan kelompok. Demikian juga multiplicity yang menentukan asosiasi harus didefinisikan. • Satu cara untuk memastikan bahwa hubungan dapat diidentifikasi adalah dengan menggunakan sebuah matriks objek/ kelas. Matriks ini digunakan sebagai checklist untuk memastikan bahwa tiap objek dan kelas yang muncul pada sebuah baris diperiksa berdasarkan setiap objek dan kelas yang muncul pada sebuah kolom untuk kemungkinan asosiasi yang terbentuk, seperti contoh Gambar 21. Lanjutan ...

3. Object Association Matrix • CLUB MEMBER menempatkan nol pada banyak MEMBER ORDERS • CLUB MEMBER membeli nol jumlah pada banyak MEMBER ORDERED PRODUCTS • CLUB MEMBER dan PRODUCT tidak mempunyai asosiasi diantara keduanya. • MEMBER ORDER ditempatkan oleh satu da hanya satu CLUM MEMBER • Dan seterusnya…

4. Langkah 2: Mengidentifikasi Hubungan Generalization/Specialization • Apabila telah diidentifikasi asosiasi dan multiplicity, kemudian harus ditentukan apakah ada hubungan Generalization/ Specialization. • Hubungan Generalization/ Specialization dapat ditemukan dengan melihat diagram kelas. • Apakah ada beberapa asosiasi diantara dua kelas yang memiliki multiplicity satu ke satu?. Jika ya, apakah dapat dikatakan “Objek X adalah sebuah tipe objek Y”?. Jika ya, maka mungkin memiliki sebuah hubungan Generalization/ Specialization. Perhatikan contoh gambar 22.

5. Generalization/Specialization Hierarchies Gambar 22. Hierarki Generalization/Specialization dalam Member Services System • Hierarki PRODUCT memperbolehkan melacak semua produk yang dapat dibeli dan nantinya mampu menambah tipe produk yang berbeda. • Hierarki CUSTOMER memperbolehkan melacak semua MEMBER. Hierarki ini memperbolehkan mengirimkan promosi khusus ke anggota yang tidak aktif untuk mendorong mereka memulai memesan produk. Juga memperbolehkan untuk mengidentifikasi para anggota. Disamping itu juga dapat menambahkan tipe pelanggan yang berbeda. • Hierarki TRANSACTION memperbolehkan melacak berbagai macam transaksi CUSTOMERS.

6. Langkah 3 : Mengidentifikasi Hubungan Aggregation • Menentukan apakah ada hubungan agregasi atau komposisi dasar. • Hubungan ini unik dimana satu objek “adalah bagian dari” objek lain. Hubungan ini sering disebut whole/ part relationship dan dapat dibaca sebagai “Objek A terdiri dari objek B dan objek B adalah bagian dari objek A”. Contoh lihat gambar 8a dan 8b.

7. Langkah 4 : Menyiapkan Diagram Kelas • Gambar 23, adalah contoh sebagian diagram kelas UML untuk Member Services System. Model ini menggambarkan objek/ kelas bisnis dengan domain Soundstage Member Services System. • Persistent Class Kelas yang menggambarkan sebuah objek yang mempertahankan eksekusi program yang membuatnya. • Transient Object Class Menggambarkan sebuah objek yang dibuat secara temporer oleh program dan hidup hanya selama eksekusi program.

8. Class Diagram Gambar 23. Diagram Kelas Member Services System

9. DESAIN DAN PEMODELAN BERORIENTASI OBJEK MENGGUNAKAN UML Oleh: Purwanto, S.Si, M.Kom Purwanto, S.Si, M.Kom

10. Desain dan Pemodelan Berorientasi Objek menggunakan UML • Membedakan antara entity, antarmuka dan objek kontrol • Memahami konsep hubungan dependensi/ ketergantungan dan lingkungan yang membuat hubungan tersebut digunakan. • Menggambarkan asosiasi yang dapat dinavigasi dan menjelaskan mengapa hal itu dipakai. • Mendefinisikan visibilitas dan menjelaskan tiga level visibilitas. • Memahami konsep dasar dari tanggungjawab objek dan bagaimana hubungannya dengan mengirim pesan antartipe objek • Menjelaskan pentingnya menggunakan kembali sebuah objek selama desain sistem • Menjelaskan tiga kegiatan yang terlibat dalam menyelesaikan desain objek. • Membedakan antara desain use case narative dan analisis use case narative • Mengkonstuksikan diagram objek robustness • Mengkonstuksikan statechart diagram dan sequence diagram • Mengkonstuksikan class diagram yang menggambarkan hal-hal khusus desain • Mengkonstuksikan diagram komponen dan diagram deployment

11. Pengantar Desain Berorientasi Objek • Object Oriented Design (OOD) Sebuah pendekatan yang digunakan untuk menentukan solusi perangkat lunak khususnya pada objek yang berkolaborasi atribut mereka dan metode mereka. • Object Oriented Design adalah kelanjutan dari analisis berorientasi objek dimana digunakan banyak model yang dikembangkan dengan menggunakan analisis yang sama, dan memperbaikinya untuk merefleksikan lingkungan produksi yang menjadi target, meliputi software, hardware dan berbagai teknologi arsitektur.

12. Objek Desain • Objek Entiti (Entity Object) Sebuah objek yang berisi informasi yang berhubungan dengan bisnis yang bersifat menetap dan disimpan pada sebuah database. Objek entiti besifat resisten/menetap, yang berarti sebuah objek biasanya aktif setelah mengeksekusi program perangkat lunak yang membuatnya. Objek entiti biasanya berkaitan dengan item-item pada kehidupan nyata (seperti Mahasiswa) dan memuat informasi yang biasa disebut atribut. • Objek Antarmuka (Interface Object) Sebuah objek yang menyediakan peralatan di mana pengguna dapat mengantarmuka dengan sistem tersebut. Tanggung jawab Objek Antarmuka mencakup: • Menerjemahkan input pengguna ke dalam informasi yang dapat dipahami oleh sistem dan untuk memproses peristiwa bisnis. • Mengambil data yang berkaitan dengan peristiwa bisnis dan menerjemahkan data tersebut untuk memberikan presentasi yang tepat kepada pengguna.

13. ENTITY CONTROL INTERFACE OBJECT OBJECT OBJECT Objek Desain (cont.) • Objek Kontrol (Control Object) Objek yang berisi berisi logika aplikasi yang bukan merupakan tanggung jawab entity objek. Contoh logika tersebut adalah aturan dan perhitungan bisnis yang melibatkan banyak objek. Dalam sebuah use case sebuah objek kontrol harus digabungkan dengan sebuah dan hanya sebuah aktor. Gambar 24. Simbol Entity Object, Interface Object dan Control Object

14. The Order Display Window is an interface class. It is dependent on the Order Processor class to respond to events initiated from the interface. Mendesain Hubungan • Dependency Relationship Hubungan Dependensi digunakan untuk memodelkan asosiasi antara dua buah kelas dalam dua buah contoh/ instance: (1) untuk menunjukkan bahwa ketika terjadi perubahan pada sebuah kelas, perubahan tersebut dapat berpengaruh pada kelas lain, dan (2) untuk menunjukkan asosiasi antara sebuah kelas persisten/ tetap dan kelas transien/ sementara. Kelas antarmuka biasanya bersifat transien dan dimodelkan pada hubungan dependensi. Hubungan dependensi digambarkan dengan sebuah panah dengan garis putus-putus. Gambar 25. Contoh Dependency Relationship

15. Given a User, you can find that user’s current password for authentication. But given a password, you cannot find the corresponding user. Mendesain Hubungan (cont.) • Navigability Secara default sebuah asosiasi antara kelas adalah bidireksional, artinya objek dari sebuah tipe dapat menavigasi objek yang tipenya lain. Tetapi ada kemungkinan perlu membatasi pengiriman pesan yang hanya ke satu arah dan diperlukan Navigability. Navigability digambarkan dengan anak panah yang hanya menunjuk ke arah pesan tersebut dikirim Gambar 26. Contoh Navigability

16. Visibility Atribut dan Metode • Visibility Level akses yang dimiliki oleh sebuah objek eksternal pada sebuah atribut atau metode. Tiga buah level Visibility dalam UML: . Public  simbol “+” Atribut publik dapat diakses dan metode publik dapat diminta oleh metode lain pada objek atau kelas lain. . Protected  simbol “#” Atribut Protected dapat diakses dan metode Protected dapat diminta oleh semua metode pada kelas yang atribut dan metodenya diketahui atau pada subkelas dari kelas tersebut. . Private  simbol “- ” Atribut Private dapat diakses dan metode Private dapat diminta hanya oleh metode yang terdapat pada kelas dimana atribut dan metodenya diketahui. Gambar 27. Contoh Visibility

17. Tanggung Jawab Objek • Metode (Method ) Logika perangkat lunak yang dieksekusi sebagai respon terhadap sebuah pesan • Object Responsibility Kewajiban bahwa sebuah objek harus memberikan memberikan layanan ketika diminta dan bekerja sama dengan objek lain untuk memenuhi kebutuhan tersebut jika diminta. Tanggung Jawab sangat berhubungan dengan konsep mengenai kemampuan objek untuk mengirim dan atau merespon pesan. Contoh Tanggung Jawab dapat dilihat seperti gambar 28.

18. Tanggung Jawab Objek Gambar 28. Tanggung Jawab Objek

19. The Process of Object-Oriented Design Desain berorientasi objek meliputi kegiatan sebagai berikut: • Menyeleksi model use case untuk menggambarkan lingkungan implementasi • Membuat model interaksi dan behavior objek yang mendukung skenario use case • Memperbarui model objek untuk menggambarjan lingkungan implementasi • Menyeleksi model use case • Meliputi 2 langkah: • a. Mengubah Use Case Analisis menjadi Use Case Desain • Perbaikan use case Analisis menjadi Use Case Design, meliputi: • . Tipe Use Case - untuk menggambarkan detail implementasi seperti batasan antarmuka pengguna. • . Kontrol Window – Pada Use Case Desain Sistem, kontrol window seperti icon, link, check box, dan tombol telah ditetapkan secara explisit.

20. Menyeleksi model use case b. Memperbarui Diagram Model Use Case dan Dokumentasi lain untuk menggambarkan semua Use Case Baru Setelah use case desain sistem dibuat, maka sangat mungkin untuk menemukan use case baru, dependensi use case, atau bahkan aktor. . Nama Window – Nama masing-masing elemen antarmuka pengguna telah ditetapkan. . Instruksi Navigasi – Petunjuk bagaimana pengguna menavigasi antarmuka pengguna haruslah ditentukan Selanjutnya lihat gambar 29 (perhatikan  s.d.)

21. Design Use Case

22. Design Use Case (continued)

23. Design Use Case (continued)

24. Design Use Case (concluded) Gambar 29. Contoh Use Case Desain

25. Breaking… • Snack#1 • Worm • Snack#2 • Axe

26. Model Interaksi dan Behavior Objek yang Mendukung Skenario Use Case Pada kegiatan ini mengidentifikasi dan mengelompokkan objek-objek desain yang diperlukan fungsionalitas yang telah ditetapkan pada masing-masing use case. Perlu juga mengidentifikasi interaksi objek, tanggung jawab objek dan behavior objek. Bagian ini meliputi 5 langkah: 1.Mengidentifikasi dan mengelompokkan Objek Desain Use Case 2. Mengidentifikasi Atribut Objek 3. Memodelkan Interaksi Objek Tingkat Tinggi untuk Sebuah Use Case 4. Mengenali State, Behavior dan Tanggung Jawab Objek 5. Memodelkan Interaksi Objek Detail untuk Sebuah Bisnis

27. Langkah 1. Mengidentifikasi dan Mengelompokkan Objek Desain Use Case • Langkah ini menyelidiki masing-masing use case desain untuk Mengidentifikasi dan Mengelompokkan Objek entity tambahan, objek kontrol dan objek antarmuka yang dibutuhkan oleh logika use case. Hasil Analisisnya adalah:  Kolom interface Object berisi daftar objek yang disebutkan pada use case bahwa pengguna berantarmuka secara langsung dengan screen, window, dan printer.  Kolom Kontrol Objek berisi daftar objek yang mengenkapsulasi logika aplikasi atau aturan perusahaan. Satu use case harus menyatakan satu objek kontrol per pengguna atau aktor unik.  Kolom Entity Objek berisi daftar objek yang berhubungan dengan objek domain bisnis yang atributnya direferensi di dalam use case

28.    Gambar 30. Objek Antarmuka, Kontrol dan Entity dari Use Case Place New Order

29. Langkah 2. Mengidentifikasi Atribut Objek • Pada langkah ini menyelidiki setiap use case untuk atribut-atribut tambahan yang belum teridentifikasi dan memperbarui diagram kelas untuk memasukkan atribut-atribut tersebut.

30. Langkah 3. Memodelkan Interaksi Objek Tingkat Tinggi untuk Sebuah Use Case • Pada langkah ini dimodelkan objek-objek dan interaksi dari objek-objek yang telah teridentifikasi dan dikelompokkan. Model ini disebut object robustness diagram dan merupakan perluasan dari sebuah model use case pada UML. Gambar 31 menggambarkan sebagian (use case langkah 1 s.d 3) dari diagram object robustness untuk use case Place New Order.  Aktor dapat berinteraksi dengan sistem hanya melalui objek antarmuka. Pada contoh, aktor berinteraksi dengan W00,W11 dan W15.  Kontrol Objek Place New Order Handler mengkoordinasi pesan yang dikirim kepada objek entity untuk mendaptkan informasi dan mengirimkannya kembali ke objek antarmuka untuk ditampilkan  Dengan mengikuti logika use case, kita dapat mengkonstruksi view level tinggal bagaimana objek harus berinteraksi satu sama lain untuk mendukung fungsionalitas use case.

31. Control object coordinates messages sent to the entity objects Actors may interact with the system via interface objects Gambar 31. Diagram Objek robustnessParsial dari Use Case Place New Order

32. Langkah 4. Mengenali State, Behavior dan Tanggung Jawab Objek Langkah ini meliputi tugas-tugas sebagai berikut: a. Menganalisis use case untuk mengidentifikasi behavior sistem yang dibutuhkan Deskripsi use case diteliti untuk dapat mengenali seluruh frasa kata kerja. Frasa kata kerja ini berhubungan dengan behavior sistem yang dibutuhkan untuk merespon peristiwa bisnis . Masing-masing use case harus diteliti secara terpisah untuk mengidentifikasi behavior yang terkait dengan use case. b. Menghubungkan behavior dan tanggung jawab dengan objek Setelah behavior teridentifikasi, selanjutnya menentukan apakah behavior tersebut manual atau akan diotomatisasi. Jika otomatis, maka behavior tersebut harus ditempatkan pada objek yang sesuai yang akan bertanggung jawab melaksanakan behavior tersebut. Contoh dari kegiatan ini, seperti gambar 32.

33. Gambar 32. Sebagian Ringkasan Behavior Use CAse

34. Kemudian dari gambar 32, dirangkum daftar behavior untuk menunjukkan hanya behavior yang harus diotomatisasi. Gambar 33 adalah daftar behavior yang diotomatisasi. Gambar 33. Rangkuman Behavior yang terotomatisasi

35. Selanjutnya mengidentifikasi seluruh behavior yang dapat digabungkan dengan sebuah tipe objek dan mengidentifikasi kolaborasi diantara objek-objek tersebut. Peralatan yang populer untuk mendokumentasikan behavior dan kolaborasi dari sebuah objek adalah Class Responsibility Collaboration (CRC) card. Gambar 34. CRC Card objek Member Order

36. Memodelkan objek yang memiliki behavior kompleks • Mengidentifikasi dan Memodelkan objek yang memiliki behavior kompleks berdasarkan perubahan state-nya. Sebuah objek mengubah state ketika nilai dari salah satu atributnya berubah. Perubahan state digerakkan oleh sebuah state transition event. • Object State adalah Kondisi objek pada masa hidupnya. • State transition event adalah sebuah kejadian yang memicu sebuah perubahan pada sebuah state objek dengan cara memperbarui satu atau lebih nilai atributnya. • Statechart Diagram adalah sebuah diagram UML yang menggambarkan kombinasi state yang dapat diasumsikan oleh objek selama masa hidupnya, kejadian-kejadian yang memicu transisi antar state dan aturan yang mengatur dari dan ke state yang mana sebuah objek dapat melakukan transisi. Contoh Statechart Diagram seperti gambar 35. • Diagram statechart tidak dibutuhkan seluruh objek. Biasanya dibuat hanya untuk objek-objek yang dengan jelas memiliki state yang dapat diidentifikasi dan behavior yang kompleks.

37. Gambar 35. Diagram Statchart dari Member Order

38. Memeriksa model objek untuk behavior tambahan Memeriksa apakah ada behavior tambahan atau tidak. e. Memverifikasi klasifikasi Pendekatan verifikasi yang sering digunakan adalah role playing, yaitu tindakan mensimulasikan behavior dan kolaborasi objek dengan cara melakukan sebuah behavior dan tanggung jawab objek. Dalam role playing, skenario use case dilaksanakan oleh para partisipan.

39. Langkah 5.Memodelkan Interaksi Objek Detail untuk Sebuah Bisnis UML memberikan dua tipe diagram secara grafis menggambarkan interaksi-interaksi objek, yaitu Squence Diagram dan Collaboration Diagram. Squence Diagram Diagram UML yang memodelkan logika sebuah use case dengan cara menggambarkan interaksi pesan di antara objek-objek dalam rangkaian waktu. Collaboration Diagram Diagram UML yang memodelkan logika sebuah use case dengan cara menggambarkan aliran pesan di antara objek-objek dalam rangkaian pesan.

40. Masing-masing objek digambarkan dengan simbul objek UML. • Referensi pada use case digambarkan dengan lifeline-sebuah garis vertikal • Behavior atau operasi yang perlu dilakukan oleh masing-masing objek digambarkan dengan kotak persegi empat pada lifeline. • Anak panah antara garis menggambarkan interaksi yang telah dikirim ke sebuah objek tertentu Gambar 36. Diagram Squence Sebagian dari Use Case Place New Order

41. Gambar 37. Contoh Collaboration Diagram

42. Memperbarui model objek untuk menggambarkan lingkungan implementasi Setelah mendesain objek dan interaksi, kita dapat meningkatkan diagram kelas unntuk menggambarkan kelas-kelas perangkat lunak dan aplikasi. Desain diagram kelas umumnya meliputi: kelas, asosiasi dan hubungan generalisai/ spesifikasi dan agregasi, Metode dengan parameter, Navigability dan Dependensi. Langkah-langkah yang digunakan untuk mengubah diagram kelas yang disiapkan dalam OOA ke dalam sebuah diagram kelas desain. 1. Menambahkan objek desain pada diagram 2. Menambahkan atribut dan informasi tipe atribut pada objek desain. 3. Menambahkan visibilitas atribut 4. Menambahkan Metode untuk objek desain. 5. Menambahkan visibilitas metode. 6. Menambahkan navigability asosiasi antar kelas. 7. Menambahkan hubungan dependensi.

43. Gambar 38. Contoh Diagram Kelas Desain (sebagian)

44. Keterangan:  Visibilitas telah ditetapkan untuk masing-masing atribut. Simbol “-” menunjukkan atributnya adalah private.  Metode dan visibilitas telah ditetapkan  Navigability telah dicatat pada beberapa asosiasi untuk menyatakan lewatnya pesan yang akan menuju ke satu arah.  Antarmuka kelas telah ditambahkan untuk menunjukkan objek utama dari antarmuka pengguna..  Sebuah kelas kontrol telah ditambahkan untuk mengkoordinasikan interaksi antara objek antarmuka dan objek entity.  Objek antarmuka tergantung pada objek kontrol.

45. Diagram Tambahan Implementasi dan Desain UML • UML menawarkan diagram tambahan untuk memodelkan aspek-aspek desain dan implementasi, yaitu diagram kegiatan (lihat pertemuan 7), diagram komponen dan diagram deployment (definisi lihat pertemuan 7). Berikut contoh diagram komponen dan diagram deployment. Gambar 39. Contoh Diagram Komponen Sebuah komponen ditunjukkan dalm UML sebagai sebuah segi empat denga dua buah segi empat yang lebih kecil di sebelah kiri. Panah menggambarkan mereka berkomunikasi.

46. Masing-masing kotak adalah simbol untuk sebuah node yang pada kebanyakan kasus merupakan bagian dari sebuah perangkat keras. Perangkat lunak terletak pada node diwakiili oleh komponen. Garis menunjukkan sebuah jalur komonikasi di antara peralatan. Gambar 40. Contoh Diagram deployment

47. m T e r i a a k s i h