by Rahmadi M. Ali , under Analisis dan Perancangan Berorientasi Objek
Tahap desain dalam pengembangan sistem berorientasi objek menggunakan persyaratan yang
dikumpulkan selama proses analisis untuk membuat cetak biru desain yang sukses untuk membangun masa depan system.Desain yang sukses berdasar atas apa yang telah dipelajari pada tahap sebelumnya dan mengarah pada kelancaran pelaksanaan dengan menciptakan rencana yang akurat dan jelas yang perlu dilakukan.Bab ini menggambarkan transisi awal dari analisis ke desain dan menyajikan tiga cara untuk pendekatan desain untuk sistem yang baru.
INTRODUCTION
Tujuan dari tahap analisis ini adalah untuk mencari tahu apa kebutuhan bisnis.Tujuan dari
tahap desain adalah menentukan bagaimana membangunya .Aktivitas utama yang terjadi selama
fase desain adalah mengembangkan representasi analisis menjadi representasi desain.
Selama fase desain, tim proyek dengan hati-hati mempertimbangkan sistem baru berkenaan dengan lingkungan saat ini dan sistem yang ada dalam organisasi sebagai keseluruhan .Pertimbangan utama dari “bagaimana” dari suatu sistem adalah faktor lingkungan seperti integrasi dengan system yang sudah ada, mengkonversi data dari sistem warisan, dan meningkatkan keterampilan yang ada ditempat .Walaupun fase Perencanaan dan fase Analisis dilakukan untuk mengembangkan sebuah “kemungkinan” sistem, tujuan dari fase Desain adalah untuk menciptakan cetak biru untuk sebuah sistem yang masuk akal untuk dilaksanakan.
Bagian awal yang penting dari tahap desain adalah untuk menguji beberapa strategi desain dan memutuskan mana yang akan digunakan untuk membangun system.Systems dapat dibangun dari awal, dibeli dan disesuaikan, atau outsourcing kepada orang lain, dan tim proyek perlu menyelidiki kelangsungan hidup setiap keputusan alternative.
Keputusan untuk membuat, membeli, atau outsourcing mempengaruhi tugas desain yang dilakukan sepanjang sisa fase. Pada saat yang sama, desain detail dari kelas-kelas individu dan metode yang digunakan untuk memetakan mur dan baut dari sistem dan bagaimana mereka harus disimpan masih harus diselesaikan.
Teknik seperti CRC cards, diagram kelas, spesifikasi kontrak, spesifikasi metode, dan desain database memberikan detail dalam persiapan untuk fase implementasi, dan mereka memastikan bahwa programer memiliki informasi yang cukup untuk membangun sistem yang tepat dengan efisien .
Desain juga mencakup kegiatan-kegiatan seperti merancang antarmuka pengguna, masukan sistem, dan output sistem, yang melibatkan cara-cara pengguna berinteraksi dengan system.Chapter 12 menjelaskan tiga kegiatan secara detail, bersama dengan teknik, seperti story boarding dan prototyping yang membantu tim desain proyek sistem yang memenuhi kebutuhan pengguna dan yang memuaskan untuk digunakan.
Akhirnya, keputusan arsitektur fisik yang dibuat mengenai hardware dan software
yang akan dibeli untuk mendukung sistem baru dan cara yang mengolah sistem akan di organisasi. Sebagai contoh, sistem dapat diatur sehingga pengolahan terpusat di satu lokasi, didistribusikan, atau keduanya terpusat dan terdistribusi, dan masing-masing solusi menawarkan manfaat unik dan tantangan kepada tim.
Isu-isu Global dan keamanan perlu dipertimbangkan bersama dengan arsitektur teknis sistem karena akan mempengaruhi rencana implementasi yang arsitektur keamanan yang sudah dibuat.Arsitektur fisik, dan isu-isu global akan dijelaskan dalam Bab13.
Banyak langkah perancangan dan sangat saling terkait,dan seperti langkah-langkah dalam
tahap analisis, para analis sering bolak-balik.Sebagai contoh, prototyping pada tahap desain antarmuka seringkali mengungkapkan informasi tambahan yang diperlukan dalam system.Sebagai alternatif, sebuah sistem yang sedang dirancang untuk sebuah organisasi yang memiliki sistem terpusat mungkin memerlukan perangkat keras yang besar dan investasi perangkat lunak jika tim proyek memutuskan untuk mengubah ke sistem di mana semua proses didistribusikan.
Dalam bab ini, digambarankan proses yang digunakan untuk mengevolusi model analisis menjadi model desain. Kemudian memperkenalkan penggunaan paket-paket dan diagram. Selanjutnya, kita menguji tiga pendekatan dasar untuk mengembangkan sistem baru: membuat, membeli, atau outsourcing.
EVOLVING THE ANALYSIS MODELS INTO DESIGN MODELS
Tujuan dari model analisis adalah untuk mewakili masalah bisnis yang mendasar sebagai satu set kolaborasi objects. Dengan kata lain, kegiatan analisis mendefinisikan kebutuhan-kebutuhan fungsional. Untuk mencapai hal ini, kegiatan analisis mengabaikan kebutuhan nonfunctional seperti kinerja dan isu-isu lingkungan sistem (misalnya, pemrosesan terdistribusi atau terpusat, masalah antarmuka pengguna, dan masalah database). Sebaliknya, tujuan utama dari model disain adalah untuk meningkatkan kemungkinan berhasil memberikan suatu sistem yang mengimplementasikan persyaratan fungsional dengan cara yang terjangkau dan mudah dipelihara. Oleh karena itu, dalam desain sistem, kami menguunakan baik fungsional requirements dan non fungsional requirement . Dari perspektif berorientasi objek, sistem model desain hanya memperbaiki system analisis model dengan menambahkan detail lingkungan sistem (atau solusi domain) untuk mereka dan pemurnian masalah informasi utama yang sudah terkandung di dalam model analisis.
Ketika mengembangkan model analisis menjadi model desain, Anda harus terlebih dahulu meninjau dengan hati-hati use case dan set kelas saat ini (metode dan atribut, dan hubungan
antara mereka). Apakah semua kelas diperlukan? Apakah ada kelas yang hilang? Apakah kelas
sepenuhnya didefinisikan? Apakah ada atribut atau metode yang hilang? Apakah kelas memiliki atribut dan metode yang tidak perlu? Apakah representasi pengembangan system saat ini optimal? Pada bagian berikut, kami memperkenalkan factoring,partitions and collaborations, dan
layers sebagai cara untuk mengembangkan model analisis berorientasi masalah kedalam model desain berorientasi solusi optimal
Menghindari Kesalahan Desain Klasik
a. Mengurangi waktu desain
Jika waktunya pendek, ada pengaruh untuk mengurangi waktu yang dihabiskan kegiatan “tidak produktif” seperti desain sehingga tim dapat melompat ke dalam program “produktif”. Hal ini mengakibatkan hilangnya detail penting yang harus diselidiki kemudian pada biaya waktu yang jauh lebih tinggi (biasanya pada sedikitnya sepuluh kali lebih lama).
Solusi: Jika tekanan waktu sangat ketat, gunakan timeboxing untuk menghilangkan fungsi atau memindahkannya ke versi masa depan.
b. Fitur creep
Bahkan jika Anda berhasil menghindari lingkup creep, sekitar 25 persen dari kebutuhan sistem
masih akan berubah. Dan, perubahan besar atau kecil dapat secara signifikan meningkatkan waktu dan biaya.
Solusi: Pastikan bahwa semua perubahan itu penting dan bahwa pengguna menyadari dampak pada biaya dan waktu.
c. Sindrom Silver Bullet
Analis kadang-kadang percaya klaim pemasaran untuk beberapa alat desain yang mengklaim
untuk menyelesaikan semua masalah dan secara ajaib mengurangi waktu dan biaya. Tidak ada alat atau teknik yang dapat menghilangkan secara keseluruhan waktu atau biaya dengan lebih dari 25 persen (meskipun beberapa dapat mengurangi banyak langkah individu).
Solusi: Jika alat desain telah mengklaim bahwa tampaknya terlalu bagus untuk jadi kenyataan, hanya mengatakan tidak.
d. Mengganti peralatan saat pertengahan proyek
Kadang-kadang analis beralih ke apa yang tampaknya menjadi alat yang lebih baik selama
desain dengan harapan menghemat waktu atau biaya. Biasanya, setiap manfaat sebanding dengan kebutuhan untuk belajar alat baru. Ini juga berlaku bahkan untuk upgrade “kecil” ke alat mutakhir.
Solusi: Jangan aktifkan atau upgrade kecuali ada keperluan mendesak untuk fitur tertentu pada alat baru, dan kemudian secara eksplisit meningkatkan jadwal untuk memasukkan waktu pembelajaran.
Factoring
Factoring adalah proses memisahkan modul ke modul mandiri dalam dan dari
modul itu sendiri.Modul baru dapat menjadi kelas baru atau metode baru. Sebagai contoh, ketika meninjau satu set kelas, mungkin ditemukan bahwa mereka memiliki satu set atribut dan method yang sama .Seperti, mungkin masuk akal untuk faktor luar kesamaan menjadi kelas terpisah.Tergantung pada apakah kelas baru harus dalam hubungan superclass untuk yang kelas yang sudah ada atau tidak, kelas baru dapat berhubungan dengan kelas-kelas yang ada melalui generalisasi atau mungkin melalui hubungan agregasi (Memiliki-Bagian).Sebagai contoh, dengan menggunakan contoh sistem penunjukan pada bab-bab sebelumnya, jika kelas Karyawan belum teridentifikasi, kita mungkin bisa mengidentifikasi pada tahap ini dengan factoring keluar metode dan atribut yang mirip dari kelas Perawat, Staf Administrasi, dan Dokter.
Dalam hal ini, kita akan menghubungankan kelas baru (Karyawan) ke kelas yang ada dengan menggunakan hubungan generalisasi (A-Kind-Of). Abstraksi dan perbaikan adalah dua proses yang berhubungan erat dengan factoring. Abstraction berkaitan dengan penciptaan ide level “lebih tinggi” dari satu set ideas. Mengidentifikasi kelas Karyawan adalah contoh abstraksi dari kelas bunga ke yang lebih tinggi. Pada beberapa kasus, proses abstraksi akan mengidentifikasi kelas abstrak, sedangkan, dalam situasi lain, itu akan mengidentifikasi kelas tambahan.
Proses perbaikan adalah kebalikan dari process abstraksi. Pada contoh sistem pendaftaran dalam bab-bab sebelumnya ,kita bisa mengidentifikasi subclass tambahan dari kelas Staf Administrasi, seperti Resepsionis, Sekretaris, dan Bookkeeper.Tentu saja kita hanya akan menambahkan kelas baru jika ada perbedaan yang cukup antara mereka.Selain itu, kelas yang lebih umum, Staf Administrasi, akan cukup.
Partitions and Collaborations
Berdasarkan semua factoring,reļ¬ning, dan abstraksi yang dapat mengambil tempat ke pengembangan sistem, besarnya representasi sistem dapat membebani baik pengguna dan developer.Pada titik ini dalam evolusi sistem, mungkin masuk akal untuk membagi representasi menjadi satu set partisi.
Sebuah partisi adalah setara dengan suatu subsistem berorientasi objek,
dimana subsistem adalah dekomposisi dari sistem yang lebih besar ke dalam komponen sistem (misalnya, sistem informasi akuntansi bisa fungsional didekomposisi menjadi hutang sistem, sistem piutang usaha, sistem penggajian, dan sebagainya).
Dari sudut pandang berorientasi objek, partisi didasarkan pada pola aktivitas (pesan dikirim) di antara object di sistem berorientasi objek. Tempat yang baik untuk mencari partisi potensial adalah kolaborasi dimodelkan dalam UML’s komunikasi diagram (lihat Bab 8). Jika Anda ingat, salah satu cara yang berguna untuk mengidentifikasi Collaboration adalah menciptakan diagram komunikasi untuk setiap case.Walaupun demikian, karena kelas individu dapat mendukung penggunaan beberapa use case, kelas individu dapat berpartisipasi dalam beberapa use-case collaborations.
Dalam beberapa kasus di mana kelas yang mendukung menggunakan beberapa
use-case, kolaborasi harus digabung bersama.Juga, CRUD analisis (lihat Bab
dapat digunakan untuk mengidentifikasi kelas potensial yang untuk menggabungkan kolaborasi. Tergantung
pada kompleksitas dari kolaborasi yang digabung, mungkin akan berguna
dalam dekomposisi kolaborasi ke beberapa partitions.Pada kasus ini,
selain memiliki kolaborasi antara obyek, dimungkinkan untuk memiliki
kolaborasi antara partitions. Aturan umum adalah lebih banyak pesan yang dikirim antara objek, semakin besar kemungkinan objek dimiliki dalam partition yang sama.Makin sedikit pesan dikirim, semakin kecil kemungkinan dua objek milik bersama.
Pendekatan lain yang berguna untuk mengidentifikasi partisi potensial adalah untuk model tiap kolaborasi antara objek dalam hal klien, server, dan klien contracts. Client adalah instance dari kelas yang mengirim pesan ke sebuah instance dari kelas lainnya untuk metode yang akan dijalankan; server adalah instance dari kelas yang menerima pesan tersebut, dan kontrak adalah spesifikasi yang meresmikan interaksi antara obyek client dan server (lihat Bab 7 dan 10) ini.
pendekatan yang memungkinkan pengembang untuk membangun partisi potensial dengan melihat kontrak yang telah ditetapkan antara objects.Pada kasus ini, semakin banyak kontrak antara objek, lebih sering daripada bukan sebuah objek milik partition yang sama.Makin sedikit contracs, kemungkinan adalah dua kelas tidak termasuk dalam partisi yang sama.
Layers
Sampai titik ini dalam pengembangan sistem kita, kita telah berfokus hanya pada area masalah, kami telah total mengabaikan lingkungan sistem (fisik arsitektur, antarmuka pengguna, dan data akses dan manajemen). Untuk berhasil mengevolusi model analisis sistem ke model desain sistem, kita harus menambahkan information lingkungan sistem .
Cara yang berguna untuk melakukan hal ini, tanpa membebani pengembang, adalah dengan menggunakan lapisan. Sebuah lapisan merupakan elemen dari arsitektur perangkat lunak dari system.Kita telah berfokus hanya pada satu lapisan dalam arsitektur perangkat lunak:lapisan masalah. Seharusnya ada lapisan untuk setiap elemen yang berbeda dari lingkungan sistem (misalnya, sistem arsitektur, antarmuka pengguna, dan akses data dan manajemen). Gagasan memisahkan unsur-unsur yang berbeda dari arsitektur ke lapisan terpisah dapat ditelusuri kembali ke arsitektur MVC dari Smalltalk.
Ketika pertama kali diciptakan Smalltalk, penulis memutuskan untuk memisahkan logika aplikasi dari logika antarmuka .Pada cara ini, hal itu mungkin untuk dengan mudah mengembangkan antarmuka pengguna yang berbeda yang bekerja dengan application yang sama.Untuk mencapai hal ini, mereka menciptakan Model-View-Controller
(MVC) arsitektur dimana Model mengimplementasikan logika aplikasi (domain masalah),
dan View dan Controller menerapkan logika untuk pengguna interface.
Views menangani output dan Controller menangani input.Karena antarmuka pengguna grafis pertama kali dikembangkan dalam bahasa Smalltalk, arsitektur MVC menjadi dasar untuk hampir semua antarmuka pengguna grafis yang telah dikembangkan hari ini (termasuk Mac interface, keluarga Windows, dan berbagai Unix berbasis GUI).
Berdasarkan arsitektur inovatif MVC Smalltalk, banyak lapisan perangkat lunak yang berbeda telah diusulkan. Berdasarkan proposal tersebut, kami sarankan lapisan berikut yang menjadi dasar arsitektur perangkat lunak: pondasi, arsitektur fisik, interaksi komputer manusia, data akses dan manajemen, dan domain penuh masalah . Setiap lapisan membatasi jenis kelas yang ada di atasnya (misalnya, hanya kelas antarmuka pengguna mungkin yang ada pada lapisan interaksi manusia komputer). Berikut ini menyediakan deskripsi pendek dari tiap lapisan.
Foundation
Lapisan dasar ini, dalam banyak hal, layer yang sangat tidak menarik. Berisi kelas yang diperlukan untuk setiap aplikasi berorientasi objek.Termasuk kelas yang mewakili tipe data dasar (misalnya, bilangan bulat, bilangan real, karakter, dan string), kelas yang mewakili struktur data dasar (kadang-kadang disebut sebagai container kelas, misalnya, daftar, pohon, grafik, set, tumpukan, dan antrian), dan kelas yang mewakili abstraksi yang berguna (kadang-kadang disebut sebagai kelas utilitas, misalnya, tanggal, waktu, dan uang). Saat ini, kelas ditemukan di lapisan ini biasanya disertakan dengan pembangunan lingkungan berorientasi objek
Physical Architecture
Lapisan arsitektur fisik berisi bagaimana perangkat lunak akan dijalankan pada komputer tertentu dan jaringan.Seperti, lapisan ini termasuk kelas yang menangani komunikasi antara perangkat lunak dan sistem operasi komputer dan network.Sebagai contoh, kelas-kelas yang berisi bagaimana berinteraksi dengan berbagai port pada komputer tertentu akan dimasukkan dalam lapisan layer.Termasuk juga kelas yang akan berinteraksi dengan aplikasi middleware , seperti OMG’s CORBA dan Microsoft DCOM arsitektur yang menangani objek terdistribusi.
Berbeda dengan lapisan dasar, ada isu desain banyak yang harus dibenahi sebelum memilih set yang sesuai dari kelas untuk masalah desain layer.Isu desain ini termasuk pilihan komputasi atau arsitektur jaringan (seperti arsitektur berbagai client-server), jaringan desain yang sebenarnya ofa, hardware dan spesifikasi perangkat lunak server, global / isu-isu internasional (seperti persyaratan bahasa), dan isu keamanan.
Deskripsi lengkap tentang semua hal yang berkaitan dengan arsitektur sistem yang berada di luar ruang lingkup buku ini diluar jangkaun materi ini ini.Akan tetapi, kami menyajikan dasar isu-isu dalam Bab 13.
Human Computer Interaction
Lapisan interaksi manusia komputer berisi kelas terkait dengan gagasan View dan Controller dari tujuan utama Smalltalk.Tujuan utama dari lapisan ini adalah untuk menjaga pelaksanaan antarmuka pengguna tertentu terpisah dari masalah classes.Ini meningkatkan portabilitas kelas system.
Typical kelas ditemukan pada lapisan ini termasuk kelas yang dapat digunakan untuk mewakili tombol, jendela, bidang teks, scroll bar, kotak cek, daftar drop-down, dan kelas lain yang merupakan elemen pengguna antar- muka.
Ketika datang untuk merancang antarmuka pengguna untuk aplikasi, ada banyak isu
yang harus menjadi diselesaikan.Sebagai contoh, seberapa penting konsistensi di antarmuka pengguna yang berbeda , bagaimana dengan tingkat pengalaman pengguna yang berbeda, bagaimana pengguna diharapkan mampu untuk menavigasi melalui sistem, bagaimana system pembantu dan manual online, apa jenis elemen input harus dimasukkan (misalnya, kotak teks, tombol radio, kotak cek, slider, drop-down box, dll), dan jenis elemen output harus dimasukkan (misalnya, teks, tabel, grafik, dll) Seperti lapisan arsitektur fisik,. deskripsi lengkap dari semua
isu yang berkaitan dengan interaksi komputer manusia adalah di luar cakupan buku ini.
Namun dari perspektif pengguna, antarmuka pengguna adalah system.Kami menyajikan
dasar isu-isu dalam desain user interface pada Bab 12.
Data Management
Lapisan manajemen data membahas isu-isu yang melibatkan kegigihan objek yang terkandung dalam system.Jenis- jenis kelas yang muncul dalam lapisan ini menangani bagaimana objek dapat disimpan dan diterima. Seperti lapisan antarmuka komputer manusia, kelas yang terkandung dalam lapisan ini memungkinkan kelas masalah yang akan independen dari
penyimpanan digunakan, dan karenanya meningkatkan portabilitas dari system.
Beberapa isu yang berkembang terkait dengan lapisan ini mencakup pilihan format penyimpanan (seperti relasional, objek / relasional, dan objek database) dan optimasi penyimpanan (seperti clustering dan indeks). Penjelasan lengkap dari semua persoalan yang berkaitan dengan lapisan pengelolaan data juga berada di luar ruang lingkup buku ini. Namun, kami menyajikan fundamental dalam Bab 11.
Problem Domain
Lapisan sebelumnya ditangani dengan kelas yang mewakili unsur-unsur dari
lingkungan dan sistem yang akan ditambahkan ke sistem specification.
Masalah lapisan domain adalah apa yang kita telah memfokuskan perhatian kami sampai sekarang.Pada tahap ini dari pengembangan sistem kami, kita perlu untuk lebih mendetailkand kelas sehingga akan mungkin untuk menerapkannya secara efektif dan efisien.
Banyak masalah perlu diatasi ketika merancang kelas, tidak peduli pada lapisan mana.Misalnya, ada isu yang berkaitan dengan factoring,cohesion dan kopling, connascence,encapsulation,proper use of inheritance dan polymorphism,constraints, spesifikasi kontrak, dan isu-isu rinci metode design.Ini dibahas dalam Bab 10.
Paket dan Paket Diagram
Paket adalah sebuah gagasan umum yang dapat diterapkan pada setiap elemen dalam model UML. Pada bagian ini kami akan menjelaskan paket diagram: diagram yang hanya terdiri dari paket. Sebuah diagram paket adalah diagram kelas yang secara efektif hanya menampilkan paket. Tergantung di mana sebuah paket digunakan, paket dapat berpartisipasi dalam berbagai jenis hubungan. Sebagai contoh, dalam diagram kelas, paket merupakan pengelompokan kelas.
Dalam diagram paket, hubungan baru, hubungan ketergantungan, berguna untuk
menggambarkan. Hubungan ketergantungan digambarkan oleh panah putus-putus seperti pada gambar di bawah ini.
Hubungan ketergantungan merupakan fakta bahwa ketergantungan modifikasi ada antara dua paket. Artinya, ada kemungkinan bahwa perubahan dalam satu paket berpotensi menyebabkan perubahan yang diperlukan dalam paket lain. Gambar berikut menggambarkan ketergantungan antara berbagai layer (pondasi, arsitektur fisik, interaksi komputer manusia, data akses dan manajemen, dan domain masalah).
Misalnya, jika perubahan terjadi pada lapisan domain masalah, kemungkinan besar akan menyebabkan terjadinya perubahan pada interaksi komputer manusia, arsitektur fisik, dan lapisan manajemen data.
Pada tingkat kelas, mungkin ada banyak penyebab ketergantungan antar kelas. Sebagai contoh, jika protokol untuk metode berubah, maka ini menyebabkan interface untuk semua objek di kelas ini berubah. Oleh karena itu, semua kelas yang memiliki objek-objek yang mengirim pesan ke instansi dari kelas yang termodifikasi mungkin harus dimodifikasi. Hubungan ketergantungan Capturing antara kelas dan paket membantu organisasi dalam memelihara sistem informasi berorientasi objek.
Mengidentifikasi Paket dan Menciptakan Diagram Paket
Pada bagian ini, kita menggambarkan suatu proses lima langkah sederhana untuk membuat diagram paket.
i. Mengatur konteks.
Menetapkan konteks untuk diagram paket. Ingat, paket dapat digunakan untuk memodelkan partisi dan / atau layer.
ii. Cluster kelas bersama-sama berdasarkan pada hubungan bersama.
Langkah kedua adalah cluster kelas bersama menjadi beberapa partisi berdasarkan hubungan yang dibagi oleh kelas. Hubungan tersebut termasuk generalisasi, agregasi, berbagai asosiasi, dan pengiriman pesan yang terjadi antara objek dalam sistem.
iii. Model cluster kelas sebagai sebuah paket.
Langkah ketiga adalah menempatkan kelas berkumpul bersama dalam sebuah partisi dan menggambarkan partisi sebagai paket. Gambar di bawah ini menggambarkan lima paket: PD Layer, Person Pkg, Patient Pkg, Appt Pkg, and Treatment Pkg.
iv. Mengidentifikasi hubungan ketergantungan antar paket.
Langkah keempat adalah untuk mengidentifikasi hubungan ketergantungan antar paket. Dalam hal ini, kami meninjau hubungan yang melintasi batas paket untuk mengungkap ketergantungan potensial.
v. Menempatkan hubungan ketergantungan antar paket.
Menerapkan Konsep pada Pilihan CD
Dalam bab-bab sebelumnya, sistem penjualan Internet pilihan CD telah digambarkan. Pada bagian ini, ditunjukkan pembuatan diagram paket untuk sistem penjualan Internet pilihan CD. Dalam pengembangan sistem penjualan internet untuk CD Seleksi, penulis menginginkan tim pengembangan hanya untuk berkonsentrasi pada Masalah Domain Layer.
Langkah kedua, kelas cluster bersama, dicapai dengan meninjau hubungan antara kelas-kelas yang berbeda. Langkah ketiga adalah memodelkan masing-masing partisi sebagai paket. Gambar di bawah ini menunjukkan kelas yang terkandung dalam masing-masing paket. Perhatikan bahwa Credit-Card Center saat ini tidak terdapat dalam paket apapun.
Mengidentifikasi hubungan ketergantungan antara paket-paket adalah langkah keempat. Dalam hal ini, mengidentifikasi empat asosiasi di antara paket yang berbeda: Customer Package dan Order Package, Customer Package dan Search Package, Order Package dan CD Package, dan Search Package dan CD Package.
Langkah kelima dan terakhir adalah menempatkan hubungan ketergantungan pada diagram paket.
dikumpulkan selama proses analisis untuk membuat cetak biru desain yang sukses untuk membangun masa depan system.Desain yang sukses berdasar atas apa yang telah dipelajari pada tahap sebelumnya dan mengarah pada kelancaran pelaksanaan dengan menciptakan rencana yang akurat dan jelas yang perlu dilakukan.Bab ini menggambarkan transisi awal dari analisis ke desain dan menyajikan tiga cara untuk pendekatan desain untuk sistem yang baru.
INTRODUCTION
Tujuan dari tahap analisis ini adalah untuk mencari tahu apa kebutuhan bisnis.Tujuan dari
tahap desain adalah menentukan bagaimana membangunya .Aktivitas utama yang terjadi selama
fase desain adalah mengembangkan representasi analisis menjadi representasi desain.
Selama fase desain, tim proyek dengan hati-hati mempertimbangkan sistem baru berkenaan dengan lingkungan saat ini dan sistem yang ada dalam organisasi sebagai keseluruhan .Pertimbangan utama dari “bagaimana” dari suatu sistem adalah faktor lingkungan seperti integrasi dengan system yang sudah ada, mengkonversi data dari sistem warisan, dan meningkatkan keterampilan yang ada ditempat .Walaupun fase Perencanaan dan fase Analisis dilakukan untuk mengembangkan sebuah “kemungkinan” sistem, tujuan dari fase Desain adalah untuk menciptakan cetak biru untuk sebuah sistem yang masuk akal untuk dilaksanakan.
Bagian awal yang penting dari tahap desain adalah untuk menguji beberapa strategi desain dan memutuskan mana yang akan digunakan untuk membangun system.Systems dapat dibangun dari awal, dibeli dan disesuaikan, atau outsourcing kepada orang lain, dan tim proyek perlu menyelidiki kelangsungan hidup setiap keputusan alternative.
Keputusan untuk membuat, membeli, atau outsourcing mempengaruhi tugas desain yang dilakukan sepanjang sisa fase. Pada saat yang sama, desain detail dari kelas-kelas individu dan metode yang digunakan untuk memetakan mur dan baut dari sistem dan bagaimana mereka harus disimpan masih harus diselesaikan.
Teknik seperti CRC cards, diagram kelas, spesifikasi kontrak, spesifikasi metode, dan desain database memberikan detail dalam persiapan untuk fase implementasi, dan mereka memastikan bahwa programer memiliki informasi yang cukup untuk membangun sistem yang tepat dengan efisien .
Desain juga mencakup kegiatan-kegiatan seperti merancang antarmuka pengguna, masukan sistem, dan output sistem, yang melibatkan cara-cara pengguna berinteraksi dengan system.Chapter 12 menjelaskan tiga kegiatan secara detail, bersama dengan teknik, seperti story boarding dan prototyping yang membantu tim desain proyek sistem yang memenuhi kebutuhan pengguna dan yang memuaskan untuk digunakan.
Akhirnya, keputusan arsitektur fisik yang dibuat mengenai hardware dan software
yang akan dibeli untuk mendukung sistem baru dan cara yang mengolah sistem akan di organisasi. Sebagai contoh, sistem dapat diatur sehingga pengolahan terpusat di satu lokasi, didistribusikan, atau keduanya terpusat dan terdistribusi, dan masing-masing solusi menawarkan manfaat unik dan tantangan kepada tim.
Isu-isu Global dan keamanan perlu dipertimbangkan bersama dengan arsitektur teknis sistem karena akan mempengaruhi rencana implementasi yang arsitektur keamanan yang sudah dibuat.Arsitektur fisik, dan isu-isu global akan dijelaskan dalam Bab13.
Banyak langkah perancangan dan sangat saling terkait,dan seperti langkah-langkah dalam
tahap analisis, para analis sering bolak-balik.Sebagai contoh, prototyping pada tahap desain antarmuka seringkali mengungkapkan informasi tambahan yang diperlukan dalam system.Sebagai alternatif, sebuah sistem yang sedang dirancang untuk sebuah organisasi yang memiliki sistem terpusat mungkin memerlukan perangkat keras yang besar dan investasi perangkat lunak jika tim proyek memutuskan untuk mengubah ke sistem di mana semua proses didistribusikan.
Dalam bab ini, digambarankan proses yang digunakan untuk mengevolusi model analisis menjadi model desain. Kemudian memperkenalkan penggunaan paket-paket dan diagram. Selanjutnya, kita menguji tiga pendekatan dasar untuk mengembangkan sistem baru: membuat, membeli, atau outsourcing.
EVOLVING THE ANALYSIS MODELS INTO DESIGN MODELS
Tujuan dari model analisis adalah untuk mewakili masalah bisnis yang mendasar sebagai satu set kolaborasi objects. Dengan kata lain, kegiatan analisis mendefinisikan kebutuhan-kebutuhan fungsional. Untuk mencapai hal ini, kegiatan analisis mengabaikan kebutuhan nonfunctional seperti kinerja dan isu-isu lingkungan sistem (misalnya, pemrosesan terdistribusi atau terpusat, masalah antarmuka pengguna, dan masalah database). Sebaliknya, tujuan utama dari model disain adalah untuk meningkatkan kemungkinan berhasil memberikan suatu sistem yang mengimplementasikan persyaratan fungsional dengan cara yang terjangkau dan mudah dipelihara. Oleh karena itu, dalam desain sistem, kami menguunakan baik fungsional requirements dan non fungsional requirement . Dari perspektif berorientasi objek, sistem model desain hanya memperbaiki system analisis model dengan menambahkan detail lingkungan sistem (atau solusi domain) untuk mereka dan pemurnian masalah informasi utama yang sudah terkandung di dalam model analisis.
Ketika mengembangkan model analisis menjadi model desain, Anda harus terlebih dahulu meninjau dengan hati-hati use case dan set kelas saat ini (metode dan atribut, dan hubungan
antara mereka). Apakah semua kelas diperlukan? Apakah ada kelas yang hilang? Apakah kelas
sepenuhnya didefinisikan? Apakah ada atribut atau metode yang hilang? Apakah kelas memiliki atribut dan metode yang tidak perlu? Apakah representasi pengembangan system saat ini optimal? Pada bagian berikut, kami memperkenalkan factoring,partitions and collaborations, dan
layers sebagai cara untuk mengembangkan model analisis berorientasi masalah kedalam model desain berorientasi solusi optimal
Menghindari Kesalahan Desain Klasik
a. Mengurangi waktu desain
Jika waktunya pendek, ada pengaruh untuk mengurangi waktu yang dihabiskan kegiatan “tidak produktif” seperti desain sehingga tim dapat melompat ke dalam program “produktif”. Hal ini mengakibatkan hilangnya detail penting yang harus diselidiki kemudian pada biaya waktu yang jauh lebih tinggi (biasanya pada sedikitnya sepuluh kali lebih lama).
Solusi: Jika tekanan waktu sangat ketat, gunakan timeboxing untuk menghilangkan fungsi atau memindahkannya ke versi masa depan.
b. Fitur creep
Bahkan jika Anda berhasil menghindari lingkup creep, sekitar 25 persen dari kebutuhan sistem
masih akan berubah. Dan, perubahan besar atau kecil dapat secara signifikan meningkatkan waktu dan biaya.
Solusi: Pastikan bahwa semua perubahan itu penting dan bahwa pengguna menyadari dampak pada biaya dan waktu.
c. Sindrom Silver Bullet
Analis kadang-kadang percaya klaim pemasaran untuk beberapa alat desain yang mengklaim
untuk menyelesaikan semua masalah dan secara ajaib mengurangi waktu dan biaya. Tidak ada alat atau teknik yang dapat menghilangkan secara keseluruhan waktu atau biaya dengan lebih dari 25 persen (meskipun beberapa dapat mengurangi banyak langkah individu).
Solusi: Jika alat desain telah mengklaim bahwa tampaknya terlalu bagus untuk jadi kenyataan, hanya mengatakan tidak.
d. Mengganti peralatan saat pertengahan proyek
Kadang-kadang analis beralih ke apa yang tampaknya menjadi alat yang lebih baik selama
desain dengan harapan menghemat waktu atau biaya. Biasanya, setiap manfaat sebanding dengan kebutuhan untuk belajar alat baru. Ini juga berlaku bahkan untuk upgrade “kecil” ke alat mutakhir.
Solusi: Jangan aktifkan atau upgrade kecuali ada keperluan mendesak untuk fitur tertentu pada alat baru, dan kemudian secara eksplisit meningkatkan jadwal untuk memasukkan waktu pembelajaran.
Factoring
Factoring adalah proses memisahkan modul ke modul mandiri dalam dan dari
modul itu sendiri.Modul baru dapat menjadi kelas baru atau metode baru. Sebagai contoh, ketika meninjau satu set kelas, mungkin ditemukan bahwa mereka memiliki satu set atribut dan method yang sama .Seperti, mungkin masuk akal untuk faktor luar kesamaan menjadi kelas terpisah.Tergantung pada apakah kelas baru harus dalam hubungan superclass untuk yang kelas yang sudah ada atau tidak, kelas baru dapat berhubungan dengan kelas-kelas yang ada melalui generalisasi atau mungkin melalui hubungan agregasi (Memiliki-Bagian).Sebagai contoh, dengan menggunakan contoh sistem penunjukan pada bab-bab sebelumnya, jika kelas Karyawan belum teridentifikasi, kita mungkin bisa mengidentifikasi pada tahap ini dengan factoring keluar metode dan atribut yang mirip dari kelas Perawat, Staf Administrasi, dan Dokter.
Dalam hal ini, kita akan menghubungankan kelas baru (Karyawan) ke kelas yang ada dengan menggunakan hubungan generalisasi (A-Kind-Of). Abstraksi dan perbaikan adalah dua proses yang berhubungan erat dengan factoring. Abstraction berkaitan dengan penciptaan ide level “lebih tinggi” dari satu set ideas. Mengidentifikasi kelas Karyawan adalah contoh abstraksi dari kelas bunga ke yang lebih tinggi. Pada beberapa kasus, proses abstraksi akan mengidentifikasi kelas abstrak, sedangkan, dalam situasi lain, itu akan mengidentifikasi kelas tambahan.
Proses perbaikan adalah kebalikan dari process abstraksi. Pada contoh sistem pendaftaran dalam bab-bab sebelumnya ,kita bisa mengidentifikasi subclass tambahan dari kelas Staf Administrasi, seperti Resepsionis, Sekretaris, dan Bookkeeper.Tentu saja kita hanya akan menambahkan kelas baru jika ada perbedaan yang cukup antara mereka.Selain itu, kelas yang lebih umum, Staf Administrasi, akan cukup.
Partitions and Collaborations
Berdasarkan semua factoring,reļ¬ning, dan abstraksi yang dapat mengambil tempat ke pengembangan sistem, besarnya representasi sistem dapat membebani baik pengguna dan developer.Pada titik ini dalam evolusi sistem, mungkin masuk akal untuk membagi representasi menjadi satu set partisi.
Sebuah partisi adalah setara dengan suatu subsistem berorientasi objek,
dimana subsistem adalah dekomposisi dari sistem yang lebih besar ke dalam komponen sistem (misalnya, sistem informasi akuntansi bisa fungsional didekomposisi menjadi hutang sistem, sistem piutang usaha, sistem penggajian, dan sebagainya).
Dari sudut pandang berorientasi objek, partisi didasarkan pada pola aktivitas (pesan dikirim) di antara object di sistem berorientasi objek. Tempat yang baik untuk mencari partisi potensial adalah kolaborasi dimodelkan dalam UML’s komunikasi diagram (lihat Bab 8). Jika Anda ingat, salah satu cara yang berguna untuk mengidentifikasi Collaboration adalah menciptakan diagram komunikasi untuk setiap case.Walaupun demikian, karena kelas individu dapat mendukung penggunaan beberapa use case, kelas individu dapat berpartisipasi dalam beberapa use-case collaborations.
Dalam beberapa kasus di mana kelas yang mendukung menggunakan beberapa
use-case, kolaborasi harus digabung bersama.Juga, CRUD analisis (lihat Bab
dapat digunakan untuk mengidentifikasi kelas potensial yang untuk menggabungkan kolaborasi. Tergantung
pada kompleksitas dari kolaborasi yang digabung, mungkin akan berguna
dalam dekomposisi kolaborasi ke beberapa partitions.Pada kasus ini,
selain memiliki kolaborasi antara obyek, dimungkinkan untuk memiliki
kolaborasi antara partitions. Aturan umum adalah lebih banyak pesan yang dikirim antara objek, semakin besar kemungkinan objek dimiliki dalam partition yang sama.Makin sedikit pesan dikirim, semakin kecil kemungkinan dua objek milik bersama.Pendekatan lain yang berguna untuk mengidentifikasi partisi potensial adalah untuk model tiap kolaborasi antara objek dalam hal klien, server, dan klien contracts. Client adalah instance dari kelas yang mengirim pesan ke sebuah instance dari kelas lainnya untuk metode yang akan dijalankan; server adalah instance dari kelas yang menerima pesan tersebut, dan kontrak adalah spesifikasi yang meresmikan interaksi antara obyek client dan server (lihat Bab 7 dan 10) ini.
pendekatan yang memungkinkan pengembang untuk membangun partisi potensial dengan melihat kontrak yang telah ditetapkan antara objects.Pada kasus ini, semakin banyak kontrak antara objek, lebih sering daripada bukan sebuah objek milik partition yang sama.Makin sedikit contracs, kemungkinan adalah dua kelas tidak termasuk dalam partisi yang sama.
Layers
Sampai titik ini dalam pengembangan sistem kita, kita telah berfokus hanya pada area masalah, kami telah total mengabaikan lingkungan sistem (fisik arsitektur, antarmuka pengguna, dan data akses dan manajemen). Untuk berhasil mengevolusi model analisis sistem ke model desain sistem, kita harus menambahkan information lingkungan sistem .
Cara yang berguna untuk melakukan hal ini, tanpa membebani pengembang, adalah dengan menggunakan lapisan. Sebuah lapisan merupakan elemen dari arsitektur perangkat lunak dari system.Kita telah berfokus hanya pada satu lapisan dalam arsitektur perangkat lunak:lapisan masalah. Seharusnya ada lapisan untuk setiap elemen yang berbeda dari lingkungan sistem (misalnya, sistem arsitektur, antarmuka pengguna, dan akses data dan manajemen). Gagasan memisahkan unsur-unsur yang berbeda dari arsitektur ke lapisan terpisah dapat ditelusuri kembali ke arsitektur MVC dari Smalltalk.
Ketika pertama kali diciptakan Smalltalk, penulis memutuskan untuk memisahkan logika aplikasi dari logika antarmuka .Pada cara ini, hal itu mungkin untuk dengan mudah mengembangkan antarmuka pengguna yang berbeda yang bekerja dengan application yang sama.Untuk mencapai hal ini, mereka menciptakan Model-View-Controller
(MVC) arsitektur dimana Model mengimplementasikan logika aplikasi (domain masalah),
dan View dan Controller menerapkan logika untuk pengguna interface.
Views menangani output dan Controller menangani input.Karena antarmuka pengguna grafis pertama kali dikembangkan dalam bahasa Smalltalk, arsitektur MVC menjadi dasar untuk hampir semua antarmuka pengguna grafis yang telah dikembangkan hari ini (termasuk Mac interface, keluarga Windows, dan berbagai Unix berbasis GUI).
Berdasarkan arsitektur inovatif MVC Smalltalk, banyak lapisan perangkat lunak yang berbeda telah diusulkan. Berdasarkan proposal tersebut, kami sarankan lapisan berikut yang menjadi dasar arsitektur perangkat lunak: pondasi, arsitektur fisik, interaksi komputer manusia, data akses dan manajemen, dan domain penuh masalah . Setiap lapisan membatasi jenis kelas yang ada di atasnya (misalnya, hanya kelas antarmuka pengguna mungkin yang ada pada lapisan interaksi manusia komputer). Berikut ini menyediakan deskripsi pendek dari tiap lapisan.
Foundation
Lapisan dasar ini, dalam banyak hal, layer yang sangat tidak menarik. Berisi kelas yang diperlukan untuk setiap aplikasi berorientasi objek.Termasuk kelas yang mewakili tipe data dasar (misalnya, bilangan bulat, bilangan real, karakter, dan string), kelas yang mewakili struktur data dasar (kadang-kadang disebut sebagai container kelas, misalnya, daftar, pohon, grafik, set, tumpukan, dan antrian), dan kelas yang mewakili abstraksi yang berguna (kadang-kadang disebut sebagai kelas utilitas, misalnya, tanggal, waktu, dan uang). Saat ini, kelas ditemukan di lapisan ini biasanya disertakan dengan pembangunan lingkungan berorientasi objek
Physical Architecture
Lapisan arsitektur fisik berisi bagaimana perangkat lunak akan dijalankan pada komputer tertentu dan jaringan.Seperti, lapisan ini termasuk kelas yang menangani komunikasi antara perangkat lunak dan sistem operasi komputer dan network.Sebagai contoh, kelas-kelas yang berisi bagaimana berinteraksi dengan berbagai port pada komputer tertentu akan dimasukkan dalam lapisan layer.Termasuk juga kelas yang akan berinteraksi dengan aplikasi middleware , seperti OMG’s CORBA dan Microsoft DCOM arsitektur yang menangani objek terdistribusi.
Berbeda dengan lapisan dasar, ada isu desain banyak yang harus dibenahi sebelum memilih set yang sesuai dari kelas untuk masalah desain layer.Isu desain ini termasuk pilihan komputasi atau arsitektur jaringan (seperti arsitektur berbagai client-server), jaringan desain yang sebenarnya ofa, hardware dan spesifikasi perangkat lunak server, global / isu-isu internasional (seperti persyaratan bahasa), dan isu keamanan.
Deskripsi lengkap tentang semua hal yang berkaitan dengan arsitektur sistem yang berada di luar ruang lingkup buku ini diluar jangkaun materi ini ini.Akan tetapi, kami menyajikan dasar isu-isu dalam Bab 13.
Human Computer Interaction
Lapisan interaksi manusia komputer berisi kelas terkait dengan gagasan View dan Controller dari tujuan utama Smalltalk.Tujuan utama dari lapisan ini adalah untuk menjaga pelaksanaan antarmuka pengguna tertentu terpisah dari masalah classes.Ini meningkatkan portabilitas kelas system.
Typical kelas ditemukan pada lapisan ini termasuk kelas yang dapat digunakan untuk mewakili tombol, jendela, bidang teks, scroll bar, kotak cek, daftar drop-down, dan kelas lain yang merupakan elemen pengguna antar- muka.
Ketika datang untuk merancang antarmuka pengguna untuk aplikasi, ada banyak isu
yang harus menjadi diselesaikan.Sebagai contoh, seberapa penting konsistensi di antarmuka pengguna yang berbeda , bagaimana dengan tingkat pengalaman pengguna yang berbeda, bagaimana pengguna diharapkan mampu untuk menavigasi melalui sistem, bagaimana system pembantu dan manual online, apa jenis elemen input harus dimasukkan (misalnya, kotak teks, tombol radio, kotak cek, slider, drop-down box, dll), dan jenis elemen output harus dimasukkan (misalnya, teks, tabel, grafik, dll) Seperti lapisan arsitektur fisik,. deskripsi lengkap dari semua
isu yang berkaitan dengan interaksi komputer manusia adalah di luar cakupan buku ini.
Namun dari perspektif pengguna, antarmuka pengguna adalah system.Kami menyajikan
dasar isu-isu dalam desain user interface pada Bab 12.
Data Management
Lapisan manajemen data membahas isu-isu yang melibatkan kegigihan objek yang terkandung dalam system.Jenis- jenis kelas yang muncul dalam lapisan ini menangani bagaimana objek dapat disimpan dan diterima. Seperti lapisan antarmuka komputer manusia, kelas yang terkandung dalam lapisan ini memungkinkan kelas masalah yang akan independen dari
penyimpanan digunakan, dan karenanya meningkatkan portabilitas dari system.
Beberapa isu yang berkembang terkait dengan lapisan ini mencakup pilihan format penyimpanan (seperti relasional, objek / relasional, dan objek database) dan optimasi penyimpanan (seperti clustering dan indeks). Penjelasan lengkap dari semua persoalan yang berkaitan dengan lapisan pengelolaan data juga berada di luar ruang lingkup buku ini. Namun, kami menyajikan fundamental dalam Bab 11.
Problem Domain
Lapisan sebelumnya ditangani dengan kelas yang mewakili unsur-unsur dari
lingkungan dan sistem yang akan ditambahkan ke sistem specification.
Masalah lapisan domain adalah apa yang kita telah memfokuskan perhatian kami sampai sekarang.Pada tahap ini dari pengembangan sistem kami, kita perlu untuk lebih mendetailkand kelas sehingga akan mungkin untuk menerapkannya secara efektif dan efisien.
Banyak masalah perlu diatasi ketika merancang kelas, tidak peduli pada lapisan mana.Misalnya, ada isu yang berkaitan dengan factoring,cohesion dan kopling, connascence,encapsulation,proper use of inheritance dan polymorphism,constraints, spesifikasi kontrak, dan isu-isu rinci metode design.Ini dibahas dalam Bab 10.
Paket dan Paket Diagram
Paket adalah sebuah gagasan umum yang dapat diterapkan pada setiap elemen dalam model UML. Pada bagian ini kami akan menjelaskan paket diagram: diagram yang hanya terdiri dari paket. Sebuah diagram paket adalah diagram kelas yang secara efektif hanya menampilkan paket. Tergantung di mana sebuah paket digunakan, paket dapat berpartisipasi dalam berbagai jenis hubungan. Sebagai contoh, dalam diagram kelas, paket merupakan pengelompokan kelas.
Dalam diagram paket, hubungan baru, hubungan ketergantungan, berguna untuk
menggambarkan. Hubungan ketergantungan digambarkan oleh panah putus-putus seperti pada gambar di bawah ini.
Hubungan ketergantungan merupakan fakta bahwa ketergantungan modifikasi ada antara dua paket. Artinya, ada kemungkinan bahwa perubahan dalam satu paket berpotensi menyebabkan perubahan yang diperlukan dalam paket lain. Gambar berikut menggambarkan ketergantungan antara berbagai layer (pondasi, arsitektur fisik, interaksi komputer manusia, data akses dan manajemen, dan domain masalah).
Misalnya, jika perubahan terjadi pada lapisan domain masalah, kemungkinan besar akan menyebabkan terjadinya perubahan pada interaksi komputer manusia, arsitektur fisik, dan lapisan manajemen data.
Pada tingkat kelas, mungkin ada banyak penyebab ketergantungan antar kelas. Sebagai contoh, jika protokol untuk metode berubah, maka ini menyebabkan interface untuk semua objek di kelas ini berubah. Oleh karena itu, semua kelas yang memiliki objek-objek yang mengirim pesan ke instansi dari kelas yang termodifikasi mungkin harus dimodifikasi. Hubungan ketergantungan Capturing antara kelas dan paket membantu organisasi dalam memelihara sistem informasi berorientasi objek.
Mengidentifikasi Paket dan Menciptakan Diagram Paket
Pada bagian ini, kita menggambarkan suatu proses lima langkah sederhana untuk membuat diagram paket.
i. Mengatur konteks.
Menetapkan konteks untuk diagram paket. Ingat, paket dapat digunakan untuk memodelkan partisi dan / atau layer.
ii. Cluster kelas bersama-sama berdasarkan pada hubungan bersama.
Langkah kedua adalah cluster kelas bersama menjadi beberapa partisi berdasarkan hubungan yang dibagi oleh kelas. Hubungan tersebut termasuk generalisasi, agregasi, berbagai asosiasi, dan pengiriman pesan yang terjadi antara objek dalam sistem.
iii. Model cluster kelas sebagai sebuah paket.
Langkah ketiga adalah menempatkan kelas berkumpul bersama dalam sebuah partisi dan menggambarkan partisi sebagai paket. Gambar di bawah ini menggambarkan lima paket: PD Layer, Person Pkg, Patient Pkg, Appt Pkg, and Treatment Pkg.
iv. Mengidentifikasi hubungan ketergantungan antar paket.
Langkah keempat adalah untuk mengidentifikasi hubungan ketergantungan antar paket. Dalam hal ini, kami meninjau hubungan yang melintasi batas paket untuk mengungkap ketergantungan potensial.
v. Menempatkan hubungan ketergantungan antar paket.
Menerapkan Konsep pada Pilihan CD
Dalam bab-bab sebelumnya, sistem penjualan Internet pilihan CD telah digambarkan. Pada bagian ini, ditunjukkan pembuatan diagram paket untuk sistem penjualan Internet pilihan CD. Dalam pengembangan sistem penjualan internet untuk CD Seleksi, penulis menginginkan tim pengembangan hanya untuk berkonsentrasi pada Masalah Domain Layer.
Langkah kedua, kelas cluster bersama, dicapai dengan meninjau hubungan antara kelas-kelas yang berbeda. Langkah ketiga adalah memodelkan masing-masing partisi sebagai paket. Gambar di bawah ini menunjukkan kelas yang terkandung dalam masing-masing paket. Perhatikan bahwa Credit-Card Center saat ini tidak terdapat dalam paket apapun.
Mengidentifikasi hubungan ketergantungan antara paket-paket adalah langkah keempat. Dalam hal ini, mengidentifikasi empat asosiasi di antara paket yang berbeda: Customer Package dan Order Package, Customer Package dan Search Package, Order Package dan CD Package, dan Search Package dan CD Package.
Langkah kelima dan terakhir adalah menempatkan hubungan ketergantungan pada diagram paket.
0 comments:
Post a Comment