Design Principle

Josua Siregar_11321012_D3TI

 Design Principle

Merancang dengan metodologi apapun, baik berorientasi objek atau tidak, harus dimulai dengan membuat deskripsi sistem yang jelas, yaitu deskripsi pengguna, komponen/modul sistem dan interaksi antar komponen, dan input yang diperlukan, serta output yang dihasilkan oleh sistem. Deskripsi umum sistem sebaiknya ditulis dalam narasi yang jelas, disertai ilustrasi yang sesuai, dan fokusnya adalah pada kepentingan stakeholder (bukan pada software).

Merancang sistem biasanya dilakukan bukan dengan memandang “objek” atau kelas, tapi fokus ke stakeholder, kepentingan, kebutuhan mereka dan interaksi antar komponen sistem maupun sistem tersebut dengan dunia luar. Dengan perkataan lain, fokus ke : “tujuan” (goal) Perancang sistem harus memperhatikan kepentingan berbagai stakeholder: 

a. End user 

b. Manager 

c. Para Eksekutif 

d. Administrator 

e. Teknisi penginstalasi

Perancang software, fokus agar kualitas teknikal dari software yang akan dihasilkan dapat memenuhi requirement yang ditentukan. Untuk ini, orientasi objek dapat menjadi salah satu pilihan dalam menghasilkan aplikasi. Jadi, berorientasi objek (merancang kelas) dilakukan pada waktu sudah memfokuskan diri ke aplikasi. UC merupakan bentuk antara yang dipakai bersama oleh pengembang sistem dan pengembang software, untuk menyamakan “apa” yang akan dihasilkan. 

Tips : bedakan posisi anda sebagai perancang software dengan perancang sistem. 

Panduan dalam mendokumentasikan Use Case : 

1. Daftar Use case disusun dengan mengacu kepada deskripsi umum sistem. Keseluruhan UC dalam Daftar ringkas ini mencerminkan “big picture” dari sistem yang akan dibangun. 
2. Use case (UC) harus melibatkan aktor, karena UC pada hakekatnya ditulis untuk memperjelas bagaimana aktor berinteraksi dengan software. 
3. UC harus mempunyai trigger (aksi pertama dari aktor yang akan menyebabkan rangkaian skenario dijalankan). 
4. UC minimal mengandung satu skenario normal, dan sebaiknya dilengkapi dengan skenario tidak normal. 
5. UC dipakai untuk menjadi dasar dalam mengetes sistem atau software, di mana user menjalankan setiap skenario yang dirancang. 
6. Granularitas (derajat detail) UC : perhatikan poin (4), pada hakekatnya menjadi dasar satu satuan test yang dilakukan oleh user; bedakan dengan unit test SW misalnya mengetes per kelas, yang dilakukan oleh programmer (programmer bukan aktor). 
7. Elemen UC : 
• Aktor : harus jelas. 
• Deskripsi : harus jelas dan bukan hanya judul. 
• Prekondisi : syarat UC dapat dijalankan (jika tidak, akan menghasilkan sesuatu yang tidak sesuai spesifikasi). 
• Skenario : minimal satu skenario normal, tapi aneh jika tidak ada yang tidak normal. 
• Post kondisi : kondisi setelah UC dijalankan, mungkin berbedabeda untuk skenario yang berbeda. 
8. Include, Extend strereo type 
• Harap pakai sesuai dengan artinya, bukan hanya sekedar "choice", cases, “call”, yang merupakan fungsi software .
9. Jika software mengandung User Interface, sebaiknya User Interface digambarkan dan "objek-objek" UI dapat dipakai namanya dalam menjelaskan Use case.
10. Penulisan/dokumentasi : Untuk sistem yang dirancang mempunyai User Interface seragam (misalnya satu jenis form yang sama, dipakai untuk mengimplementasi banyak sekali tabel, bahkan sampai lebih dari 10 tabel, hanya tabelnya berbedabeda), tidak perlu dituliskan satu persatu. Anda disarankan menuliskan satu UC yang mencerminkan perilaku yang umum, dan mendaftar tabel apa saja yang akan memakai skenario tersebut. Gunanya adalah menghindari pengulangan yang menyebabkan kesalahan copy/paste. Dengan prinsip ini, maka dokumentasi menjadi "concise" dan bermakna. Selain itu, layout UI menjadi seragam. 
11. Aturan Validasi : jika ada aturan validasi yang bersifat umum, dapat dituliskan sebagai aturan umum

Panduan dalam merancang diagram kelas: 

1. Kandidat kelas disusun daftarnya berdasarkan deskripsi umum sistem, dan mempelajari kemampuan Software (SRS) yang didefinisikan setelah mempelajari deskripsi umum sistem, user case dan informasi mengenai platform serta jenis software yang akan dibuat. Misalnya ditentukan bahwa software tersebut mempunyai GUI, maka rancangan kelas akan lain. 
2. Ada baiknya meninjau kemungkinan diterapkannya pattern sebelum melakukan elaborasi dari diagram kelas. 
3. Kelas sebaiknya jelas perannya, dan digolongkan menjadi : 
• Entity class (yang untuk sebagian besar aplikasi, akan merupakan tabel/ER representation). Kelas ini merupakan kelas “statik”. Panduan dalam memberi Nama kelas: “kata benda, noun“ yang menjadi namanya. Contoh : Pegawai, Buku, Peminjam. Untuk aplikasi yang berbasis data, sebaiknya diagram ER didesign dengan dengan baik, atau jika sudah mengenal ORM (Object Relational Modeling), ER dapat digantikan dengan ORM. Lihat bahasan tersendiri mengenai database dalam OOD. 
• Kelas yang merupakan modeler, selain entity class, ada beberapa kelas yang bersifat mempunyai “reponsibility” untuk proses tertentu. Panduan dalam memberi Nama kelas: "kata kerja yang dijadikan kata benda". Contoh : “transporter“, “DBManager“, “Controller“.
• Kelas yang merupakan Viewer, user interface yang akan menjadi antarmuka pengguna untuk melakukan operasi terhadap kelas-kelas entity yang dimanipulasi user melalui controller. Panduan dalam memberi nama kelas : boleh mengandung nama kata benda yang biasa dipakai dalam beberapa tools berbasis GUI seperti Form XX, Buttonzz, .... 
• Kelas yang menyimpan nilai single-instance harus dapat dibedakan namanya dengan kelas yang menyimpan collection.
4. Atribut dari kelas : 
• Mencerminkan "state", nilai yang dikandung dalam objek yang akan merupakan instans dari kelas tersebut. Setiap objek akan menyimpan state masing-masing, sehingga jika dipunyai sekumpulan objek, maka perilaku akan sama namun "nilai" nya berbeda-beda. 
• Atribut yang single value harus dibedakan penamaaanya dengan yang menyimpan multiple value (collection). Pakailah nama yang mencerminkan jenis koleksi yang dipakai. 
• Atribut berupa koleksi : array, map, hash, stack, queue, …. 
• Berikan lingkup akses yang sesuai : public, protected, private.
5. Method dari Kelas: 
• Method mencerminkan perilaku dari kelas; yang dimaksudkan dengan perilaku ada. 
• Method yang ada di kelas harus mencerminkan operasi terhadap/yang dilakukan oleh objek dalam kelas tersebut. Ciri design yang baik : jika method tersebut hanya kata kerja, dan tidak mengandung kata benda, karena secara intrinsik "benda" yang dimanipulasi melalui kata kerja adalah objek itu sendiri (“this“). 
• Test nama method dengan menambahkan kata benda (objek itu sendiri), apakah cocok? Anda bisa mengidentifikasi “design flaws“ dari test ini. 
• Constructor dan destructor yang sesuai harus dirancang, agar penciptaan objek dapat dilakukan dengan benar. 
• Operator overloading : nama “proses“ yang sama yang dipakai banyak kelas; pakailah nama "proses" (prosedur, fungsi) yang sesuai. 
• Overriding : hanya untuk kelas turunan. 
• Berikan lingkup akses yang sesuai : public, protected, private.
6. Hubungan antar kelas: harus dirancang dengan baik, sesuai dengan salah satu pola hubungan sbb
• Client supplier : adalah hubungan “has”. 
1. Hubungan kontrak (perhatikan Precondition, post condition). 
2. Tidak ada mekanisme khusus. 
• Inheritance : adalah hubungan "is-A“ 
1. Kelas turunan/anak tidak perlu mempunyai features (atribut, method) dari kelas dasar/bapak. Karena feature bapak secara otomatis akan dipunyai oleh anak. 
2. Anak dapat meng-override method bapak, mempunyai atrubut dan method tambahan. 
3. Hati-hati dengan polymorhism. 
4. Hati-hati dengan multiple inheritance dan repeated inheritance. 
• Hubungan antara berapa instans object yang dituliskan dalam diagram (*- N, 1-N, N-M) : penting untuk implementasi program kelak (menjadi single value atau multi value).
7. Interface : interface yang dimaksud di sini sama dengan interface di bahasa Java (interface adalah semacam kelas, namun bukan kelas). 
• Interface tidak menyimpan state. 
• Interface hanya mengandung spesifikasi method. Yang “body”, implementasinya dilakukan di kelas yang akan mengimplementasi interface. 
• Interface dapat menyimpan nilai konstanta “sistem” [publik] yang akan dipakai oleh semua kelas lainnya. 
• Interface berbeda dengan abstract class.
8. Generic 
• Generic memungkinkan kita untuk mempunyai beberapa “object” yang merupakan instansiasi dari kelas generik, yang mengikuti “templates” yang sama. 
• Generic lebih banyak dipakai untuk parametrisasi “type“ parametrisasi prosedur/fungsi akan dipakai mekanisme lain seperti interface, function pointers, lambda expression, delegate (dalam .NET). 
• Type generik banyak dipakai dalam library yang mengelola collection (lihat library).
9. Library/Component 
• Library, komponen yang tersedia dalam suatu platform/bahasa dapat dipakai. Tergantung keperluan, dapat dicantumkan atau hanya disebutkan dalam diagram kelas. 
• Hampir semua library menyediakan collection dan manipulasinya. 

Pertanyaan: Method dalam kelas atau UC ? Kelas yang mewakili dunia nyata dan kelas yang “diciptakan” karena adanya software. Pada kebanyakan kasus, mahasiswa belum dapat membedakan “benda” dunia nyata dengan objek yang diciptakan dalam aplikasi. Untuk beberapa kasus, objek dunia nyata yang memang ada, dimodelkan menjadi objek dalam aplikasi (sebelum diinstansiasi menjadi objek, tentunya harus dimodelkan menjadi kelas). Untuk kasus lain, kita harus berhati-hati dalam memodelkan objek. Dampaknya, adalah memilih method yang sesuai untuk objek maya atau nyata, dan membedakan method tersebut dengan UC.

Contoh : 

1. Pulsa telepon: pulsa telepon merupakan “benda maya” yang sebetulnya tidak ada, namun diciptakan dan menjadi berharga dalam sistem komunikasi telpon genggam. Mengirim pulsa, akan menjadi method yang tepat dalam salah satu kelas dari software. 
2. Uang : dalam hal sistem perbankan, uang dapat menjadi benda nyata, dan menjadi benda maya (saldo, tabungan). Mengirim uang menjadi method yang aneh dalam kelas, karena mengirim uang pada hakekatnya lebih tepat untuk menjadi UC. Mengurangi saldo, mungkin akan menjadi method yang tepat bagi sebuah kelas rancangan. Yang akan diaktfikan akibat pemakai dari software melakukan/menjalankan UC Mengirim uang. 

Panduan dalam merancang collaboration diagram dan sequence diagram

1. Collaboration diagram merepresentasikan bagaimana antar kelas berkolaborasi untuk menghasilkan perilaku yang ditentukan. 
2. Sequence diagram merepresentasikan aksi-reaksi dan pengiriman pesan antar object dalam aplikasi/software. 
3. Oleh karena itu sequence diagram merupakan gambaran lebih detail dari sebuah atau beberapa buah langkah di dalam “sistem” yang tergambar dalam UC, sehingga ada baiknya dibuat mapping terhadap UC terkait. 
4. Karena bersifat detail, sebaiknya sequence diagram merupakan detail sequence of message passing and reaction yang mengacu ke collaboration diagram

Panduan dalam merancang state diagram

1. State diagram menggambarkan perubahan state dalam sebuah object (bukan dalam aplikasi). 
2. State diagram hanya perlu digambarkan untuk : 
• controller, untuk memperjelas “otomata”, state transition yang harus dilakukan dalam mengontrol. 
• entiti, jika entiti mengalami perubahan status akibat pengaruh luar (business process). Contoh ini jelas untuk filed basis data yang berupa “status” yang perubahannya dikontrol oleh syarat-syarat business. Jika field status hanya merupakan enumerasi dan tidak ada syarat, maka yang diperlukan bukan penggambaran state diagram melainkan status apa saja yang mungkin (misalnya SexCode {P,L} ).

Database dan persistent object 

1. Database merupakan salah satu representasi dari persisten objek, objek yang secara permanen akan ada dan dapat diretrieve kembali. Cara lain untuk mempunyai persisten object : menyimpan ke dalam file, format XML. Untuk ini diperlukan spesifikasi struktur dan formatnya, seperti halnya untuk database didefinisikan struktur tabelnya. 
2. Dalam merancang sebuah aplikasi berbasis data, harus dibuat pemodelan dan rancangan lojik (E-R, ORM) sebelum membuat rancangan fisik. Ini perlu, agar rancangan yang dibuat dapat dipertanggung jawabkan. 
3. Setiap tabel basis data akan menjadi sebuah kelas, dan biasanya akan dibuat getter dan setter secara otomatis. Operasi lain dapat dirancang sesuai keperluan dan biasanya dilakukan oleh kelas lain yang sengaja diciptakan; hal ini agak bertentangan dengan konsep kelas dimana atribut dan operasi akan dienkapsulasi [untuk ini akan dijelaskan secara khusus].

Aplikasi dan Software Requirement 

1. Karena ada perbedaan fundamental antara aplikasi berjenis : console/textual, desk top application dan web based application, maka perlu diberikan gambaran mengenai aplikasi dalam deskripsi sistem. 
2. Khusus untuk : 
• aplikasi Web sudah diciptakan sekumpulan stereo type yang menggambarkan web page, submit (dan aksi lain). 
• aplikasi real time : disediakan stereotype khusus 
3. UC dapat mengacu ke perilaku standard setiap aplikasi yang dibuat, jika sistem terdiri dari banyak aplikasi.
4. SRS (SW requirement specification) : didefinisikan dengan mengacu ke UC. Jika dalam UC tercermin user mampu melakukan apa untuk melakukan tugasnya, maka dalam SRS, didefinisikan kemampuan software (the software must be able to….). 
• Functional requirement : kemampuan fungsional yang harus diwujudkan (entry, update, delete, validate, compute, sort, send, receive, ….). Biasanya dalam kata kerja yang terbatas, dibandingkan dengan kemampuan user yang kata kerjanya lebih banyak (mengontrol, mengawasi, mengambil keputusan, menyunting, mengirim, menentukan,…). Ada beberapa kata kerja yang bisa sama seperti : send, receive … merupakan kata kerja yang berimpitan untuk digunakan baik oleh aktor maupun oleh software, misalnya dalam sebuah mobile application untuk send/receive SMS. 
• Non functional requirement : security, maintainability, kemudahan deployment, usability, availability, reliability, extendability,…. Yang juga harus dijamin dapat dipenuhi Semua requirement harus testable (dapat ditest, dibuktikan). Jika tidak dapat ditest, maka tidak boleh disebut sebagai requirement.

Platform, Deskripsi Arsitektural Software Deskripsi arsitektural terkadang perlu digambarkan, jika software dibangun di atas sutu platform spesifik, menggunakan komponen-komponen yang dikembangkan di atas suatu platform yang dipilih. Dalam hal platform standard yang dipakai (misalnya J2EE, ADF, .NET,…), maka gambaran arsitektural tidak perlu untuk disertakan, namun pengembang harus memahami platform dan deskripsi arsitektural dari platform tersebut, supaya dapat melakukan perancangan secara optimal dengan memanfaatkan komponen yang sudah ada, serta tidak “reinventing the wheel”.

Biasanya, suatu platform sudah mendukung aplikasi dengan perilaku yang terstandardisasi, yang sebaiknya dipelajari sebelum melakukan perancangan rinci. Tidak disarankan untuk mengubah perilaku dasar yang sudah disediakan suatu platform, karena akan mengakibatkan pengembangan software yang “bongkar pasang” yang memakan energi, dan mungkin dapat menghasilkan software yang “rapuh”. Deskripsi arsitektural ini penting untuk dipahami reviewer, sebelum memahami detail design mengenai kelas, package, component

Referensi

Ditulis ulang dari tulisan IL, Tutorial OOAD, IE31129- Rangkuman Kuliah OOAD Semester 1-0809