2.4.4.2 Aktivitas Desain
2.4.4.2.1 Component Design
Component Design fokus pada menentukan implementasi dari kebutuhan di dalam framework arsitektural. Titik awal Component design adalah spesifikasi aplikasi dan kebutuhan sistem. Hasil dari aktivitas ini adalah spesifikasi dari komponen yang tersambung.
Aktivitas connecting component adalah untuk mendesain koneksi antara komponen-komponen agar mendapatkan desain yang fleksibel dan komprehensif. Hasil dari aktivitas ini adalah class diagram dari komponen-komponen yang terlibat.
Dalam object oriented software engineering dinyatakan bahwa suatu software terdiri atas komponen-komponen yang masing-masing memiliki responsibility dan saling berinteraksi satu dengan yang lainnya. Menurut Irwanto (2006, P42-45), sebuah software minimal harus memiliki tiga buah komponen dasar, yaitu:
a. Component Interface.
b. Component Function.
c. Problem Domain Model.
Komponen interface adalah komponen yang memiliki responsibility untuk menjembatani interaksi antara actor (user) dengan software system. Komponen function adalah komponen yang merepresentasikan fungsi-fungsi dalam piranti lunak untuk mengontrol dan mengadministrasi problem domain. Komponen problem domain adalah komponen yang memodelkan domain masalah didalam suatu konteks atau bisnis proses.
Oleh karena itu didalam aktivitas desain komponen untuk piranti lunak, aktivitas utamanya adalah mendesain tiga komponen diatas tadi seperti yang ditunjukkan pada gambar dibawah ini:
Problem Domain Model Component Design Dokumen Pemodelan Domain Functional System Component Design Interface Component Design PDM Component Functional Component Interface Component & Sequence Diagram
Gambar 2.9 Aktivitas mendesain komponen (Irwanto, 2006)
Untuk pembahasan langkah-langkah masing-masing desain dibahas pada subbab dibawah ini.
2.4.4.2.1.1 Design Component Problem Domain Model (PDM)
Untuk merancang komponen problem domain model (PDM), kita tidak bisa membuatnya sembarangan. Oleh karena itu kita harus meng-comply seperangkat aturan atau kaidah desain. Menurut Irwanto (2006, P46-61) aturan atau kaidah untuk mendesain komponen PDM terdiri atas delapan langkah yang dilakukan secara iterative, yaitu:
1. Langkah pertama yang dilakukan ketika merevisi class diagram adalah memerhatikan design pattern untuk mengoptimalkan solusi desain.
Peninjauan design pattern kita lakukan secara iterasi pada setiap langkah desain dan baru berhenti ketika komponen problem domain model sudah valid. Implementasi suatu pattern ketika merevisi class diagram memungkin-kan terjadinya penambahan class dan perubahan struktur pada class diagram secara fundamental. Penambahan class-class baru di dalam class diagram dan perubahan struktur yang terjadi di sana memungkinkan pola behavior objek dari class diagram tersebut otomatis ikut berubah dan bertambah.
2. Langkah yang kedua adalah memeriksa konsistensi multiple inheritance. Pada langkah tersebut, kita memeriksa apakah pada class diagram terdapat multiple inheritance. Jika benar, maka kita harus meninjau dan memastikan ulang apakah technical platform yang digunakan C++? Jika tidak, maka multiple inheritance yang terdapat pada class diagram harus direvisi menjadi single inheritance.
3. Langkah ketiga adalah mempresentasikan private event dan common event dari class-class yang memiliki hubungan struktur asosiasi dan agregasi. Representasi event dapat dibuat ke dalam sebuah tabel sehingga dapat menyederhanakan pola behavior objek yang kompleks tanpa kehilangan gambaran perspektifnya. Untuk concrete class yang memiliki hubungan structural dengan abstract class, pola behavior abstract class tersebut akan didelegasikan oleh subclass-nya.
4. Langkah keempat, setelah dibuat tabel representasi event untuk class-class yang memiliki hubungan struktural agregasi dan asosiasi, periksalah satu per satu apakah pada tabel-tabel tersebut sekurang-kurangnya terdapat satu buah common event? Jika ada yang tidak, maka mungkin pada class diagram kita terdapat hubungan struktural yang keliru atau ada kekurangan pada pola behavior objek kita. Karena pada prinsipnya jika dua buah class memiliki hubungan struktur asosiasi atau agregasi, maka dipertimbangkan sekurang-kurangnya terdapat satu buah common event yang memengaruhi objek-objek dari dua class tersebut, dan sebaliknya jika pada pola behavior terdapat dua atau lebih objek yang memiliki common event, maka dipertimbangkan bahwa classifier objek-objek tersebut memiliki hubungan structural agregasi atau asosiasi. Jika pada pola behavior atau class diagram kita terdapat kekurangan, maka perbaiki dahulu keduanya sebelum melangkah ke tahap selanjutnya.
5. Langkah kelima, presentasikan event yang terdapat pada pola behavior objek ke dalam komponen problem domain model. Pada saat kita mendesain sebuah sistem, mungkin saja kita mendesain sebuah sistem yang kompleks. Dalam situasi itu, bisa saja kita memiliki pola behavior yang kompleks dan banyak. Agar tidak mudah kehilangan gambaran perspektif, disarankan agar tabel representasi event tabel di update berdasarkan keperluan desain ketika kita merepresentasikan event ke dalam komponen problem domain model. Berikut ini adalah cara dan aturan yang digunakan
untuk mempresentasikan event ke dalam komponen problem domain model dan meng-update tabel representasi event:
a. Pertama, seperti yang telah disinggung di atas bahwa atribut merupakan descriptive property dari event. Oleh karena itu asosiasikanlah semua atribut yang berhubungan dengan event pada pola behavior objek.
b. Kedua, representasikanlah event-event yang terdapat pada pola behavior ke dalam komponen problem domain model dengan aturan sebagai berikut:
Tabel 2.3 Tabel Aturan Merepresentasikan Event (Irwanto, 2006) Untuk event yang berjenis
sequence dan selection
Representasikanlah event yang bertipe sequence dan selection sebagai state attribute dari class yang bersangkutan. Setiap kali event tersebut terjadi, sistem akan menetepakan nilai yang baru kepada state attribute tersebut.
Untuk event yang berjenis inserting iteration
Representasikan event yang bertipe iterasi sebagai class baru. Selanjutnya, lekatkan class baru tersebut kepada class yang memiliki iteration event menggunakan struktur agregasi. Setiap kali iteration event terjadi, sistem akan menghasilkan objek baru pada class tersebut.
updating & Retrieving iteration
berkolerasi dengan class yang bersangkutan. Setiap kali event tersebut terjadi, sistem akan mengubah dan menetapkan nilai yang baru kepada atribut-atribut tersebut atau meretrieve objek-objek tertentu sesuai dengan kriteria yang diinginkan.
c. Ketiga, tentukanlah jenis iteration event, di mana didapat pola behavior objek, ke dalam tabel representasi event sesuai dengan proses bisnis dan definisi sistem yang berlaku.
6. Langkah keenam, setelah selesai merepresentasikan semua event yang terdapat pada pola behavior, langkah selanjutnya adalah mendesain association class. Jika pada class diagram kita terdapat association class, maka lekatkanlah association class tersebut dengan pasangan class yang menimbulkannya dengan menggunakan hubungan struktur agregasi.
Ketika kita mendesain association class, ada dua hal yang harus kita perhatikan yaitu:
a. Pertama, jika pada class diagram terdapat association class yang ditimbulkan akibat multiplicity many to many pada hubungan struktur binary association, maka semua sesuai dengan aturan desain, lekatkan association class dengan dua class menggunakan hubungan struktur agregasi.
b. Kedua, association class tidak selalu muncul pada binary association, tetapi juga bisa muncul pada ternary association atau bahkan pada level yang lebih tinggi lagi N-ary association.
Walaupun penentuan multiplitcity sepertinya merupakan hal yang sepele, akan tetapi apabila kita berhadapan dengan ternary dan N-ary association, maka penentuan multiplicity bukanlah hal yang remeh. Salah menentukan multiplicity dapat memberikan dampak yang kurang baik pada skala yang panjang di kemudian hari.
7. Langkah ketujuh, revisi class diagram yang akan dilakukan pada proses desain komponen problem domain model memberikan dampak perubahan class dan struktur pada class diagram. Pada langkah ketujuh ini kita akan memeriksa apakah di dalam komponen problem domain model kita terdapat hubungan struktur antar-class yang sudah tidak lagi berguna? Jika ada, maka struktur relationship itu harus dibuang.
Langkah kedelapan, periksalah atribut-atribut yang memiliki hubungan struktur, apakah sudah lengkap? Jika sudah, periksalah kembali apakah hubungan struktur yang digunakan sudah tepat. Navigation association adalah assosiasi satu arah, atau istilah lainnya unidirectional association. Penggunaan association structure yang tepat di dalam desain efektif menjaga agar coupling antarobjek tetap rendah. Sebaliknya, penggunaan association structure yang tidak tepat secara efektif meninggikan coupling antarobjek dalam desain kita.
2.4.4.2.1.2 Design Component Function
Merancang komponen sistem fungsional software adalah suatu kegiatan yang amat penting untuk dilakukan mengingat tidak ada software yang tidak memiliki functional system. Apabila sebuah software tidak memiliki functional system, praktis software menjadi tidak berguna dan problem domain model yang telah kita buat menjadi sia-sia (Irwanto, 2006). Apabila kia bicara mengenai functional system, makan pada prinsipnya kita tengah membicarakan apa yang dapat dilakukan oleh sistem. Oleh karena itu, hal tersebut tentunya sangat terkait erat dengan responsibility sistem. Didalam studi literature yang dilakukan oleh Irwanto (2006, P63-64) menyatakan pendapat Larman (1998, P170-187) bahwa Inti dari aktivitas desain pada fase ini pada prinsipnya adalah menetapkan responsibility sistem pada software kita dengan memerhatikan objek-objek yang berkolaborasi di dalam software sistem tersebut. Oleh karena itu, pada fase ini keahlian menetapkan system responsibility melalui interaction diagram menjadi pokok masalah yang penting.
Menurut Mathiassen et al (2000: 260), ada tiga buah pola yang harus kita perhatikan pada saat menetapkan responsibility, yaitu:
a. Model class placement
Pola ini menetapkan method di dalam komponen problem domain model. Method yang ditetapkan dengan menggunakan pola ini biasanya mengakses hanya single objek atau objek yang memiliki struktur agregasi yang sederhana.
b. Function class placement
Pola ini menetapkan method di dalam komponen sistem fungsional. Method yang ditetapkan dengan menggunakan pola ini biasanya mengakses banyak objek yang berbeda yang terdapat di dalam komponen problem domain model.
c. Active function
Pola active function biasanya digunakan apabila di dalam sistem kia terdapat signaling functionality. Biasanya active function ada di dalam sistem realtime.
Menurut Irwanto (2006, P66-72) ada tiga langkah-langkah desain yang harus dilakukan untuk membuat function komponen adalah sebagai berikut:
a. Langkah pertama membuat atau merevisi CRC card
b. Langkah kedua menetapkan responsibility software system dengan menggunakan model class placement terlebih dahulu yang di deskripsikan dengan menggunakan interaction digram UML.
Langkah ketiga, setelah penetapan system responsibility dengan pola model class placement dilakukan melalui collaboration diagram, selanjutnya kita memeriksa apakah ada system responsibility yang tidak bisa ditetapkan dengan menggunakan model class placement? Jika ada, maka tetapkanlah responsibility software sistem tersebut dengan menggunakan pola function class placement.