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 Tahap selanjutnya adalah identifikasi operasi dan atribut untuk tiap-tiap kelas perancangan (disebut juga dengan identifikasi block interface). Seperti yang saya katakan tadi, membuat diagram interaksi terlebih dahulu seharusnya memudahkan kita mengidentifikasi operasi pada tahap ini. Kita tinggal menambahkan visibilitasnya–yang merupakan ciri OO–apakah public, private, atau protected. Untuk yang satu ini, mau tidak mau Anda memang harus sedikit mengerti tentang prinsip pemrograman OO😛

Lalu bagaimana dengan object dan package? Di mana bagian yang menyorot kedua hal ini dalam OOD? sebelumnya kita harus tahu bahwa objek adalah instance dari sebuah kelas. Kelas merupakan definisi atau spesifikasi dari sebuah object. Atribut dan kelakukan setiap object inilah yang didefinisikan dalam kelasnya. Jadi dapat dikatakan bahwa kelas merupakan kumpulan dari objek-objek yang dihasilkan dalam waktu yang sama atau berlainan. Duh ko jadi membhasa hal yang fundamental begini ya😀 Contohnya mudah saja, manusia adalah kelas dan Ega atau Dioni itu adalah objek. Ega dan Dioni dalam perjalanan waktu yang dijalani manusia dapat saja dilahirkan atau mati dalam waktu yang berbeda. Yah, kurang lebih seperti itulah analoginya. Atribut Ega berupa nama, alamat, atau umur dan kelakuan Ega berupa “membeli baju baru” atau “makan” inilah yang akan dideskripsikan dalam block interface. Kita lihat contohnya:

kelas-detilKeadaan objek-objek tersebut digambarkan dalam state diagram. Penggambaran state diagram ini bersifat optional karena memang tidak semua objek memiliki keadaan yang kompleks. Hanya objek-objek dengan keadaan yang kompleks lah yang akan digambarkan. Sebuah state diagram mungkin menggambarkan keadaan objek-objek dalam satu kelas yang sama atau satu use case yang sama. Suka-suka si desainer saja…atau suka-suka si dosen dan asisten yang memberi tugas saja (-,-‘). Contoh state diagram yang kompleks:
statechart
Package sendiri merupakan mekanisme untuk mengorganisir kelas dalam satu grup. Hal ini jarang digambarkan dalam OOD. Namun gambar berikut mungkin berguna sebagai referensi bagi Anda.
package
Poin terakhir, OOD kita belum lengkap tanpa perancangan antarmuka. Pada tahap analisis, kita masih merancang antarmuka dalam bentuk sketsa tata letak elemen-elemennya saja, nah di tahap perancangan ini, kita membuat rancangan antarmuka yang “sesungguhnya” seperti yang kita bayangkan ketika perangkat lunak sudah diimplementasikan.
antarmuka1
Begitulah, OOD kita sudah selesai. Namun, versi tertentu mengharuskan kita membuat diagram kelas keseluruhan dan menggambarkan keterhubungan antar kelas tersebut. Keterhubungan kelas ini mirip dengan prinsip pemrograman OO, ada asosiasi, inheritance, agregasi, komposisi (pemodelan inner class), dan lain-lain. Prinsip penting yang harus Anda pegang dalam OOD adalah perancangan Anda hasil bisa memvalidasi hasil analisis dan siap diadaptasikan di lingkungan implementasi. Bahasa kasarnya sih, sudah siap diserahkan ke programmer untuk di-coding. Selamat merancang!

Akhir kata, mengutip jargon lab keahlian Rekayasa Perangkat Lunak di prodi saya: Software engineering is fun (^_~’)

Leave a comment

5 Comments

  1. yo, nambah-nambahin dikit, khususnya tentang package….

    umumnya package itu berisi kelas, interface, enum, dan tipe2 lain yang memiliki kemiripan fungsionalitas (modularitas)…. dan kadang2 juga dipakai untuk membedakan fungsionalitas dua kelas yang memiliki nama yang sama (namespace)

    misalnya ada dua buah package graph2D dan graph3D….
    graph2D berisi kelas2 yang digunakan untuk menggambarkan bentuk2 2D seperti Rectangle, Triangle, dll… graph3D berisi kelas2 yang digunakan untuk menggambarkan bentuk2 3D seperti Cube, Sphere, dll….
    nah kadang2 ada sebuah class yg sama seperti Point… sebuah Point pada 2D memiliki 2 buah atribut, sedangkan Point pada 3D memiliki 3 buah atribut…. ada baiknya ketimbang dibiat Point2D dan Point3D, keduanya dipisahkan ke dalam 2 package tersebut….

    menurut pengalaman pribadi, untuk best practice aja… hindarkan kebutuhan timbal balik antara 2 buah package…😛

    Reply
  2. bella

     /  January 12, 2009

    trimakasih tuk bahasan ttg use case dan ooa ini, saya mau minta tolong, maukah bantu saya buatkan use case pada ANALISA DAN PERANCANGAN SISTEM INFORMASI MANAJEMEN PENDIDIKAN, karena saya sedang membahasa tugas saya tentang hala yang diatas, terimakasih.

    Reply
  3. ophiezt gates

     /  June 18, 2010

    infonya gw pke referensi tugas…
    thanx..

    Reply
  1. Belajar Instan Component Based Software Engineering « .:: si /-|ebat ::.

Wait! Don't forget to leave a reply here.. :D

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: