Sekitar Mei lalu, saya menulis artikel mengenai pengalaman mengerjakan tugas kuliah merancang software secara object oriented di blog ini. Ketika itu, saya masih menginjak semester empat dan mengikuti mata kuliah Rekayasa Perangkat Lunak (RPL). Kendati isinya tidak banyak membahas teknis membuat elemen-elemen Object Oriented Analysis dan Design (OOAD), namun rupanya banyak pengunjung yang nyasar ke artikel tersebut karena mencari materi tentang use case. Hihihi. Untuk semua yang pernah merasa “ketipu”, maafkan saya ya, peace (^,^v) Nah, berhubung banyak yang menghubungi saya secara pribadi dan menceritakan ketertarikannya terhadap OOAD, saya akan mencoba menulis lebih banyak mengenai OOAD di sini. Sebenarnya hanya berbagi materi kuliah dan pengalaman mengerjakan tugas saja sih. Kebetulan, di semester lima yang hampir berakhir ini, saya mendapatkan kuliah RPL Lanjut (RPLL). Pembahasan akan saya bagi menjadi dua, yaitu Object Oriented Analysis (OOA) dan Object Oriented Design (OOD). Kali ini saya akan membahas tahap analisisnya dulu…ok, kencangkan sabuk pengaman Anda, kita akan mulai menjelajah dunia Object Oriented Software Engineering (OOSE) yang menyenangkan! Hehehe.

Tahap pertama yang harus kita buat dalam OOA adalah mendeskripsikan model kebutuhan. Model kebutuhan ini–mungkin dengan berbagai versi lain–terdiri dari hal-hal berikut:

1. Identifikasi aktor
2. Identifikasi use case
3. Membuat diagram use case
4. Membuat skenario use case
5. Membuat deskripsi interface
6. Membuat problem domain object model

Langkah ketiga dapat saja dibalik dengan langkah pertama dan kedua, tergantung bagaimana enaknya sang analis saja. Orang imajiner mungkin lebih suka menggambar diagram dulu ketimbang memuat deskripsi. Sedangkan orang teoretis tentu saja yang akan kebagian tugas “membuat definisi” dari tiap aktor dan use case. Intinya, asal kebutuhan fungsional perangkat lunak dan interaksinya dengan dunia luar dapat tergambar dengan jelas. Dalam kasus tertentu–walaupun hal ini tidak terlalu dianjurkan dalam merancang sistem–use case kita tidak sesederhana menggambarkan aktor, use case, dan keduanya. Namun ada elemen-elemen yang perlu Anda tambahkan, yaitu hubungan antar use case dan antar aktor itu sendiri. Kita lihat contohnya:

use case extension

Hubungan antar use case dihubungkan dengan garis putus-putus dan disebut inheritance atau association. Setiap asosiasi harus diberi stereotype <<extend>> atau <<include>>(<<uses>>). Extends untuk use case yang merupakan alternatif dari use case lain, sedangkan include untuk use case yang harus selalu menyertakan use case lain. Hubungan antar aktor hanya satu jenis, yaitu inheritance. Seperti pada contoh di atas, musisi dan casting director adalah turunan dari pengguna yang sudah teregister (kesalahan penulisan nama aktor pada diagram, harusnya ‘registered user’).

Selanjutnya, setelah diagram use case selesai, setiap use case harus dirinci lagi dalam bentuk skenario use case sehingga jelas bagaimana urutan aksi aktor dan reaksi sistem. Skenario mungkin saja melibatkan lebih dari satu aktor, namun trigger skenario use case selalu berasal dari satu aktor. Jika perlu, dapat ditambahkan pre-condition dan post-condition pada sebuah skenario. Contoh skenario use case:

Alternatif lain, pre-condition dan post-condition dituliskan dalam deskripsi use case:

Langkah kelima dan keenam sebenarnya bersifat optional. FYI, tugas RPLL saya tidak disuruh membuat keduanya. Hehe. Saya hanya punya contoh dari tugas RPL saya berikut yang entah sudah benar atau belum

Deskripsi interface merupakan sketsa antarmuka yang akan kita tampilkan ke pengguna saat use case tertentu dijalankan. Pada tahap ini, kita membuat rancangan tata letak elemen-elemen antarmuka seperti tombol, textfield, gambar, teks, dan sebagainya. Poin penting di sini adalah konsistensi dari tampilan lojik dan kelakuan aktual sistem. Selain itu, keterlibatan pengguna juga berperan penting dalam mendeskripsikan detil antarmuka.

desain antarmuka pada tahap analisis berupa sketsa tata letak elemen-elemen

Problem domain object model dibuat untuk menggambarkan hubungan antar objek-objek yang memiliki keterlibatan secara langsung dalam sistem.

Objek-objek tersebut dapat diperoleh dari object name, logical attributes, static instances associations, inheritance, dynamic instance associations, atau perations. Gampangannya, PDOM digunakan untuk meng-capture struktur statik, sedangkan untuk meng-capture struktur dinamik kita menggunakan sequence diagram, state diagram atau activity diagram..

Oke, model kebutuhan sudah selesai kita kembangkan. Tahap berikutnya adalah mendeskripsikan model analisis. Tujuan dari tahap ini adalah merealisasikan use case agar siap dirancang. Hal-hal yang harus kita lakukan dalam tahap ini antara lain:
identifikasi kelas analisis
membuat diagram kelas analisis
membuat diagram interaksi antar kelas analisis

Kelas analisis kita definisikan dari behaviour use case. Di sini harus jelas kelas mana “bertanggung jawab” terhadap behaviour use case yang mana. Kelas-kelas analisis ini sebenarnya seperti penjelmaan dari objek-objek yang kita definisikan di PDOM tadi. Ada tiga jenis kelas analisis yang berbeda, yaitu kelas boundary (disebut juga kelas interface), kelas entity, dan kelas control. Dalam versi Smalltalk, ketiganya lebih terkenal dengan sebutan MVC, Model-View-Controller. Kelas boundary yang akan berhubungan langsung dengan lingkungan atau “dunia luar” seperti pengguna atau sistem lain. Kelas ini biasanya yang akan menjadi modul untuk antarmuka pada perancangan, misalnya file .html atau .php pada aplikasi berbasis web. Kelas entity berhubungan dengan penyimpanan dan pengaksesan informasi entitas dalam sistem. Segala macam bentuk keluar masuknya data dari dan ke database ditangani di kelas ini. Sedangkan kelas control mengilustrasikan semua fungsionalitas yang belum tertangani di kedua kelas. Biasanya kelas inilah justru yang berperan sebagai “jembatan” kedua jenis kelas sebelumnya. Setelah selesai mengidentifikasi kelas-kelas tersebut, selanjutnya kita buat diagramnya. Membuat diagram ini mudah saja, hanya tinggal menghubung-hubungkan kelas-kelas analisis yang memiliki keterkaitan. Sama seperti diagram use case, keterhubungan antar kelas tersebut juga dapat dikembangkan menjadi agregasi, asosiasi, atau inheritance. Jika perlu, diagram kelas analisis keseluruhan dapat pula digambar, seperti ini:

Untuk menggambar diagram interaksi (sequence diagram atau collaboration diagram), kita buat seperti menggambar sequence diagram kelas perancangan. Saya mengatakan demikian karena mungkin saja sebagian dari Anda terbiasa membuat sequence diagram pada tahap perancangan, bukan saat analisis. Memang poin ini bersifat optional, artinya Anda tidak harus membuat diagram interaksi pada tahap analisis karena sebenarnya hasilnya akan mirip dengan diagram interaksi yang Anda buat saat perancangan. Dengan kata lain, jika Anda sudah membuat diagram interaksi pada saat analisis, Anda hanya tinggal copy paste saja di tahap perancangannya. Hanya saja, mereka yang suka membuat di kedua tahap tersebut biasanya membedakan nama kelas dan prosedur atau fungsi pada analisis dan perancangan.

Dapat kita lihat di atas bahwa dalam notasi UML, tiap jenis kelas analisis dilambangkan dengan bulatan-bulatan serupa tapi tak sama. Hehe. Sebagai informasi, jika Anda menggambar menggunakan StarUML, lambang tersebut mungkin tidak akan Anda temukan saat membuat diagram interaksi. Cara yang biasa saya dan teman-teman gunakan adalah kami menggambar diagram interaksi seperti biasa dengan simbol kotak-kotak dulu untuk kelas, baru kemudian klik kanan dan pilih ‘iconic’ pada stereotype diplay. Voilaa…jadilah diagram interaksi kelas analisis! (bersambung)

*Materi seputar OOA dapat Anda unduh di sini