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

Empat belas use case…
Empat puluh block…
Empat orang pria…
Ditambah seorang wanita…

Sudra System menutup kuliah Rekayasa Perangkat Lunak semester dua tahun 2007-2008 di teknik Informatika <itebeh> dengan presentasinya tentang desain perangkat lunak berorientasi objek yang mencengangkan dunia. Hahaha. ini dia fotonya setelah presentasi:

Hari ini cukup menarik bagi saya. Setelah kurang lebih tiga bulan bekerja sama membuat laporan seputar analisis dan desain perangkat lunak, kelompok saya akhirnya tampil presentasi juga. Presentasi dalam kuliah empat SKS saya ini agak beda, pemirsa. Sang dosen adalah orang yang lumayan cerewet doal kostum. Jadilah setiap tiga minggu sekali, setiap kelompok berlomba-lomba untuk tampil sekeren mungkin saat presentasi. Nah, kebetulan saya dan teman-teman setuju buat make batik. Taraaa…persis dah kami kaya orang mau kondangan bareng. Selain itu, karena kelompok pertama yang tampil sebelum kami memiliki topik yang sama dengan kami, akhirnya bu dosen menawarkan kami tampil terlebih dahulu kemudian baru sesi tanya jawab untuk kedua kelompok dijadikan satu. Berhubung forum kelas menerima dan dua kelompok terkait menerima tawaran tersebut, yeah..maka acara presentasi hari ini langsung berubah jadi seminar. Seminar object oriented design in salon-operational software. Wih, keren kan Hehehe.

Baru kali ini saya merasa sangat puas setelah melakukan presentasi. Setelah dipikir-pikir, ternyata penyebabnya selain didukung rasa kepercayaan diri yang tinggi dari kostum, juga karena setiap anggota dalam kelompok saya totalitas dalam bekerja sehingga menghasilkan sebuah karya yang tidak sekedar “tugas”, tapi layak untuk “dijual ke khalayak umum”. Hmm, ini kenarsisan saya saja sih sebenarnya . Yah, ibarat sales lah, ketika dia merasa barang yang dia tawarkan itu bagus, tentu dia akan lebih percaya diri dalam mempromosikan dagangannya kan? That’s the point.

Lalu, apa sih sebenarnya yang kami buat?

Berangkat dari materi kuliah kami pada bab Object Oriented Software Engineering (OOSE) nih pemirsa, kami membuat perancangan suatu perangkat lunak yang dapat diterapkan di sebuah salon untuk membantu sistem operasionalnya. Kami menyebut perangkat lunak rancangan kami “Sally’s Salon”. Dalam OOSE, perancangan diimplementasikan dalam use case dan block. Use case adalah kasus penggunaan perangkat lunak yang mungkin dilakukan oleh sistem luar atau user. Misalnya, dalam Sally’s Salon ada use case -use case sebagai berikut:

Mencatat transaksi penjualan
Mengecek status keanggotaan pengunjung
Meminta spesifikasi produk atau layanan
Melayani pemesanan produk dan layanan
Mengelola membership salon
Membuat laporan history anggota
Mencatat history transaksi anggota
Mengelola jenis barang yang akan dijual
Mengelola jenis layanan yang disediakan salon
Mengelola inventaris keperluan salon
Mencatat pengeluaran dan pemasukan uang dalam salon
Mengelola penggajian karyawan salon
Membuat laporan finansial salon
Mengelola akun pengguna software beserta role-nya

Masing-masing use case di atas dilakukan user tertentu yang dalam OOSE disebut sebagai aktor. Jika use case-use case di atas dituangkan dalam bentuk diagram use case seperti di bawah ini, maka aktor adalah gambar orang di luar kotak. Sisi-sisi kotak menggambarkan batas sistem perangkat lunak dengan sistem di luarnya (system border atau system boundary).

Use case merupakan landasan pokok pembuatan kelas-kelas yang nantinya akan diwujudkan programmer dalam suatu source code. Use case dapat digambarkan dengan diagram kelas analisis atau sequence diagram (disebut pula diagram interaksi). Untuk membuat diagram-diagram dalam OOSE ini, dibutuhkan sebuah perangkat lunak khusus desain OO, misalnya StartUML. Mau tahu contoh diagram kelas analisis dan sequence diagram itu kaya gimana? Silakan lihat gambar di bawah ini:

Contoh diagram kelas analisis dalam use case “Mencatat Transaksi Penjualan”

Misalnya, kelas-kelas analisis dari use case di atas adalah IF_Cashier(interface), Pencatat Transaksi(control), Pengenal Status Anggota(control), Database Transaksi (entity) dan Database Aggota(entity). Kelas interface berhubungan dengan antarmuka yang akan diakses pengguna, kelas control berhubungan dengan eksekusi operasi-operasi, dan entity berhubungan dengan penyimpanan data.

Contoh sequence diagram dalam use case “Mencatat Transaksi Penjualan”

Yang menarik dalam perancangan secara OOSE adalah jika use case perangkat lunak kompleks. Semakin banyak use case maka diagram kelas analisis dan sequence diagram yang dibuat akan lebih banyak lagi. Misalnya nih, dari use case-use case di atas, ditambah use case mengelola bonus pegawai, mengelola waiting list, mengelola warning atau reminder kepada pelanggan, dan sebagainya.

Awal dapat tugas ini dulu, saya sempat hopeless lho…karena nggak ngerti apa itu use case, diagram kelas, sequence diagram, dan sebagainya. Tetapi, ternyata benar apa yang dikatakan ayah saya bahwa tugas bagi anak teknik itu penting karena kita belajar paling banyak dari tugas, bukan dari kuliah. Benar juga, setelah mengerjakan tugas, saya tidak sekedar mengerti apa itu use case dan kawan-kawannya tetapi juga dapat membuat diagramnya di StartUML. Keahlian saya semakin bertambah ketika use case-use case itu harus dirubah, dikurangi, atau ditambah. Lama-lama saya jadi tahu mana yang benar mana yang salah. Makin seru lagi kalau ada perbedaan pendapat dengan teman sekelompok saya, kami jadi bisa saling bertukar pikiran dan menganalisis bagaimana membuat use case yang benar. Mengerjakan tugas ini selama dua minggu rasanya saya udah kaya Master of Use Case saja…Hahaha.

Nah, seperti yang sudah saya jelaskan di depan tadi, selain ada perancangan use case, ada juga perancangan block. Block dalam hal ini dapat diartikan sebagai kelas yang akan membangun modul-modul dalam program jika rancangan perangkat lunak diwujudkan menjadi perangkat lunak yang sesungguhnya. Inilah menariknya desain OOSE, yaitu ia sangat dekat sekali dengan implementasi alias proses coding. Nah, kelompok saya sempat membuat heboh tuh tadi pagi gara-garanya jumlah block yang dirancang banyak sekali dan jika digambar, akan menjadi seruwet ini:

Wow sekali bukan…salut buat teman saya yang udah bikin ini

Sebelum presentasi, saya khawatir teman-teman saya yang menyaksikan jadi boring abis saking banyaknya block kami. Tapi rupanya, pujian dari dosen kami mampu membuat seisi kelas fokus lagi (haduh, narsis lagi…). Mengapa bisa sebanyak itu? alasannya simpel, karena memang yang dibutuhkan segitu. Mau berbagi pengalaman aja nih, dalam OOSE kadang kita telah memperkirakan bahwa jumlah block kita ada sekian, namun ketika sudah mengimplementasikannya, ternyata banyak kelas-kelas baru yang perlu kita ciptakan agar semua yang direncanakan dalam use case dapet terpenuhi. Itulah yang terjadi pada kelompok saya.

Kembali ke presentasi hari ini…
Lagi-lagi, saya dapat pelajaran dari dosen RPL saya. Pertama, idenya agar kami menjadi orang yang beda saat presentasi boleh juga. Seru kali ya kalo maju presentasi bajunya selalu ber-dresscode Kedua, beliau berpesan ketika menggarap TA atau laporan apa pun kelak, jangan lupa tentukan asumsi sebanyak-banyanya sehingga tidak ada celah sedikit yang dapat ditembus penonton untuk bertanya (hehe) dan menunjukkan bahwa pemikiran kita sudah maju jauh ke depan. Yeah, kalo meminjam istilah Narenda sih, kita harus “pongah” ketika presentasi! Anggap saja “jurinya” nggak tahu apa-apa. Hehehe.