Membahas Use Case dan Kawan-kawannya (lagi) – Bagian 2

Melanjutkan tulisan ini, tahap perancangan berorientasi objek di sini akan kita sebut OOD (Object Oriented Design). OOD agak berbeda dengan perancangan menggunakan metode terstruktur. Pada metode terstruktur, kita harus mengurus perancangan data dengan membuat daftar tabel aplikasi yang akan diimplementasikan menjadi tabel-tabel database. Namun, pada OOD, kita fokus merancang kelas-kelas dengan struktur layaknya kita membuat program dengan bahasa OO, ada object, class dan package. Ketiga hal ini diuraikan baik secara implisit maupun eksplisit dalam tabel dan diagram.

Hal pertama yang kita lakukan di OOD adalah mengidentifikasi kelas perancangan. Kelas perancangan ini juga diistilahkan dengan “block”. Jika kita menggambar dengan StarUML, kalo kita perhatikan pun, kita tidak akan menemukan simbol untuk kelas tapi simbol untuk “block” akan dengan mudah kita temukan. Kelas-kelas tersebut sebenarnya tinggal menilik saja pada kelas analisis yang telah kita buat sebelumnya. Nama kelas perancangan dan kelas analisis pun bisa saja sama, tetapi kebanyakan desainer membedakannya untuk menandai mana yang dibuat pada tahap analisis dan mana yang dibuat pada tahap perancangan. Begitu kita selesai mendeskripsikan kelas perancangan apa saja yang dibutuhkan, “isi” dari kelas tersebut jika nantinya diimplementasikan dalam program juga harus sudah terbayang, seperti atributnya, operasinya, visibilitas keduanya, dan fungsi tiap-tiap operasinya. Untuk memudahkan tahapan tersebut, kitaย  sebaiknya menggambar sequence diagram (interaction diagram) setiap use case terlebih dahulu. Diagram interaksi menggambarkan bagaimana objek-objek dalam kelas tersebut saling berkomunikasi. Stimulus dari satu kelas ke kelas lainnya merupakan cikal bakal operasi. Oleh karena itu, biasanya stimulus ini tidak lagi dituliskan dengan kata-kata seperti “berpidah layar” atau “menambah pengguna” tetapi sudah mengikuti aturan penamaan method dalam pemrograman seperti “navigateTo()” atau “addUser(username,password)”, tanpa spasi dan pemakaian parameter.
kelas (more…)

Advertisements

Membahas Use Case dan Kawan-kawannya (lagi) – Bagian 1

Sekitar Mei lalu, saya menulis artikel mengenai pengalaman mengerjakan tugas kuliah merancang perangkat lunak 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), tapi 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.

Harap dicatat bahwa contoh-contoh gambar di sini tidak berasal dari dokumen yang sama, tapi saya pilih acak dari beberapa dokumen sistem yang berbeda-beda, tergantung kebutuhan.

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

(more…)