Pertemuan 8 9 DOMAIN MODEL Alur Proses Use

Pertemuan 8 -9 DOMAIN MODEL

Alur Proses Use Case Driven Modelling

Pengertian Domain Model adalah tugas membangun daftar istilah proyek, atau kamus yang digunakan dalam proyek. Domain model juga menyediakan kosa kata umum untuk memungkinkan komunikasi yang jelas antara anggota tim proyek. Model domain menunjukkan hubungan agregasi dan generalisasi (hubungan has-a dan is-a) antara kelas domain.

Kenapa dimulai dari domain model Domain Model membentuk dasar dari bagian statis sedangkan use case adalah dasar dari bagian dinamis. Bagian statis menggambarkan struktur ; bagian dinamis menggambarkan perilaku. Domain model mendefinisikan ruang lingkup dan membentuk dasar untuk membangun use case.

Proses. . . Domain model ini akan terus di-update sepanjang proyek, sehingga selalu mencerminkan pemahaman saat ini dari suatu permasalahan. Domain model tidak hanya di-update pada saat memodelkan use case, tetapi juga pada saat menggambarkan robustness diagram dan sequence diagram. Domain model akan berubah menjadi domain model yang di-update, yang pada akhirnya berubah menjadi class model yaitu model statis yang mendefinisikan class-class perangkat lunak.

Contoh Domain Model

10 Pedoman Domain Model 10. Fokus pada dunia nyata (domain masalah) obyek. 9. Gunakan hubungan generalisasi (is-a) dan agregasi (has-a) untuk menunjukkan bagaimana objek berhubungan satu sama lain. 8. Batasi upaya pemodelan domain awal untuk beberapa jam. 7. Mengatur kelas di sekitar abstraksi kunci dalam domain masalah. 6. Jangan salah mengartikan model domain untuk model data. 5. Jangan bingung mengenai obyek (yang mewakili contoh tunggal) dengan tabel database (yang berisi kumpulan beberapa hal). 4. Gunakan model domain sebagai glossary proyek. 3. Lakukan model domain awal sebelum membuat use case untuk menghindari ambiguitas nama. 2. Jangan berharap diagram kelas akhir secara tepat sesuai dengan model domain, tapi harus ada beberapa kemiripan di antara mereka. 1. Jangan menempatkan layar dan kelas-GUI secara spesifik pada model domain

10. Fokus pada objek dunia nyata (domain masalah). Mengatur arsitektur perangkat lunak seperti seputar apa yang terlihat di dunia nyata. Dunia nyata cenderung berubah lebih jarang daripada persyaratan perangkat lunak. Pada kelas diagram akan menggunakan versi di sebelah kiri, dengan atribut dan operasi. Namun, selama upaya domain model awal menggunakan notasi sederhana ditampilkan di sebelah kanan (nama kelas).

9. Gunakan hubungan generalisasi (is-a) dan agregasi (has-a) Gunakan hubungan (atau asosiasi) antara objek Contoh : Review Buku termasuk dalam Buku, dan Pemesanan Pembelian dan Kartu Kredit adalah dua jenis pembayaran. Hubungan pertama (Review Buku termasuk dalam Buku) disebut agregasi (has-a, karena Buku memiliki Review Buku). Hubungan kedua (Pemesanan Pembelian dan Kartu Kredit keduanya Jenis Pembayaran) disebut generalisasi (is-a, karena Kartu Kredit adalah Jenis Pembayaran).

Contoh: aggregasi dan generalisasi has-a is-a

8. Batasi upaya pemodelan domain awal untuk beberapa jam Beberapa jam untuk membuat semua yang diperlukan. Proses usecase driven mengasumsikan bahwa model domain tidak lengkap dan menyediakan mekanisme untuk menemukan apa yang tidak terjawab. Sesi modeling domain awal mungkin adalah dua jam yang paling penting akan menemukan 80% dari kelas domain. Domain model ini akan terus di-update sepanjang proyek, sehingga selalu mencerminkan pemahaman saat ini dari suatu permasalahan. Domain model tidak hanya di-update pada saat memodelkan use case, tetapi juga pada saat menggambarkan robustness diagram dan sequence diagram.

7. Mengatur kelas di sekitar abstraksi kunci dalam domain masalah. Domain model adalah diagram kelas (dipotong) yang menjadi dasar dari arsitektur perangkat lunak. Pengorganisasian arsitektur sekitar abstraksi dunia nyata membuat model yang lebih tangguh dalam menghadapi perubahan kebutuhan.

6. Jangan salah mengartikan model domain untuk model data. Meskipun diagram mungkin terlihat serupa, ingat bahwa apa praktek yang baik pada model data tidak mungkin praktek yang baik pada diagram kelas (dan sebaliknya). Kelas kecil dan tabel yang lebih besar. Sebuah tabel dalam database relasional sering berkaitan beberapa hal. Sebaliknya, kelas lebih baik dirancang jika mereka paket yang relatif kecil data dan perilaku.

5. Jangan bingung mengenai obyek dengan database tabel Sebuah objek merupakan satu contoh dari sesuatu. Sedangkan Sebuah tabel database merupakan kumpulan hal. Meskipun Kelas domain mirip, Jika memanggil kelas domain Book maka tidak berarti tabel Book berarti satu buku. Kolom dalam tabel umumnya dipetakan ke atribut pada kelas. Namun, tabel database biasanya berisi lebih banyak kolom dari kelas yang berisi atribut (tabel sering memiliki foreign key, sebagai salah satu contoh), sehingga mungkin tidak langsung pemetaan 1: 1 antara baris tabel dan objek.

4. Gunakan model domain sebagai glossary proyek. Model domain harus berfungsi sebagai glossary proyek yang membantu untuk memastikan penggunaan yang istilah konsisten istilah ketika menggambarkan ruang masalah mencegah ambigu Contoh : "shopping cart, " “shopping basket, " atau “shopping troley").

3. Lakukan model domain awal sebelum membuat use case untuk menghindari ambiguitas nama. Domain model digunakan untuk menghndari nama yang ambigu Membuat use case tanpa domain model akan menimbulkan banyak masalah nantinya.

2. Jangan berharap diagram kelas akhir secara tepat sesuai dengan model domain, tapi harus ada beberapa kemiripan di antara mereka. Kelas diagram jauh lebih rinci dibandingkan dengan domain model domain sengaja disimpan cukup sederhana. Saat mendesain (sequence diagram), akan ditambahkan konstruksi desain rinci seperti tampilan GUI, dan infrastruktur kelas.

1. Jangan menempatkan layar dan kelas-GUI secara spesifik pada model domain Optimaslisasi kinerja kelas, kelas pembantu, dan sebagainya juga harus dijauhkan dari model domain. Model domain harus fokus sepenuhnya pada masalah domain.

INTERNET BOOKSTORE 1. 2. 3. 4. 5. 6. 7. Internet Bookstore akan berbasis web pada awalnya , tetapi harus memiliki alternatif arsitektur front-end yang cukup fleksibel untuk dapat dikembangkan ( swing / applet , web service, dll ). Toko buku harus mampu menjual Book , dengan Orders yang diterima melalui Internet. Pengguna harus dapat menambahkan buku ke Shopping cart online , sebelum checkout. a. Demikian pula , pengguna harus dapat menghapus items dari keranjang belanja. Pengguna harus dapat mengatur Wish Lists (daftar keinginan) buku yang dia inginkan untuk dibeli nanti. Pengguna harus dapat membatalkan perintah sebelum dikirim. Pengguna harus dapat membayar dengan credit cards atau purchase orders. Itu harus mungkin bagi pengguna untuk mengembalikan buku.

INTERNET BOOKSTORE 8. Toko buku harus mencakup ke dalam website associate partners’ menggunakan mini-catalogs , yang berasal dari master catalog secara keseluruhan disimpan dalam pusat Database. a. Mini - katalog harus didefinisikan dalam XML , karena mereka akan ditransfer diantara ini dan (kemudian harus didefinisikan ) sistem eksternal. b. shipping fulfillment system (Sistem pemenuhan pengiriman) harus dilakukan melalui layanan web Amazon. 9. Pengguna harus dapat membuat costumer account, sehingga sistem mengingat rincian pengguna ( rincian nama , alamat , kartu kredit ) saat login. a. Sistem harus memelihara list of a account dalam database pusat. b. Ketika user log in , password-nya harus selalu dicocokkan dengan password dalam master account list. 10. Pengguna harus dapat mencari buku-buku oleh berbagai search methods- title, author, keyword, or category— dan kemudian melihat books’ details

INTERNET BOOKSTORE 11. Ini harus memungkinkan pengguna untuk posting review buku favorit ; review comments akan muncul pada tampilan rincian buku. Review tersebut harus mencakup customer rating( 1 -5 ) , yang biasanya ditampilkan bersama dengan judul buku dalam book lists. a. Book reviews harus dikelola --- yaitu, diperiksa dan “OK” oleh anggota Staf sebelum mereka dipublikasikan di website b. Ulasan yang panjang harus disingkat pada tampilan rincian buku ; costumer bisa mengklik untuk melihat review lengkap pada halaman terpisah. 12. Itu harus memungkinkan staf untuk posting editorial reviews buku. Ini juga akan muncul pada tampilan rincian buku. 13. Toko buku akan memungkinkan sellers pihak ketiga (misalnya, toko buku bekas) untuk menambah sendiri book catalogs masing-masing. Ini ditambahkan ke dalam master book catalog keseluruhan sehingga penjual buku 'termasuk dalam hasil pencarian.

14. Toko buku harus terukur, dengan persyaratan khusus sebagai berikut: a. Toko buku harus mampu memelihara user accounts hingga 100. 000 pelanggan dalam enam bulan pertama, dan kemudian lebih lanjut 1. 000 setelah itu. b. Toko buku harus mampu melayani hingga 1. 000 pengguna secara simultan (10. 000 setelah enam bulan). c. Toko buku harus mampu menampung hingga 100 permintaan pencarian per menit (1. 000 / menit setelah enam bulan). d. Toko buku harus mampu menampung hingga 100 pembelian per jam (1. 000 / jam setelah enam bulan).

Daftar Pustaka Rosenberg, D. , Stephens, M. 2007. Use Case Driven Object Modeling with UML “Theory and Practice”. Springer-Verlag New York Inc