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

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:

diagram use case + extension

diagram use case dilengkapi extension

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 digunakan 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 terdaftar (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:

skenario use case

skenario use case

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

use case description

alternatif untuk 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.

interface description

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.

problem domain object model

problem domain object model

Objek-objek tersebut dapat diperoleh dari object name, logical attributes, static instances associations, inheritance, dynamic instance associations, atau perations. Wew, sebenarnya saya juga nggak ngerti apa yang barusan saya tulis ini🙄. 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:

  1. identifikasi kelas analisis
  2. membuat diagram kelas analisis
  3. membuat diagram interaksi antar kelas analisis

Kelas analisis kita definisikan dari use case behaviour. Di sini harus jelas kelas mana “bertanggung jawab” terhadap use case behaviour 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:

diagram kelas analisis

diagram kelas analisis per kasus

diagram kelas analisis keseluruhan sistem

diagram kelas analisis keseluruhan

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.

sequence diagram analisis

sequence diagram tahap analisis

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

Leave a comment

33 Comments

  1. kalo pre dan post condition itu biasanya mendefinisikan keadaan usernya dan state-state obyek2nya.. karena fasenya masih analisis, gak terlalu perlu mendefinisikan state dari sistemnya….

    misal untuk sebuah use case “memberi rating lagu”, kita cukup bilang aja di pre condition
    – user sudah melakukan login
    – user sedang membuka sebuah halaman lagu
    post conditionnya
    – rating lagu berubah

    untuk bedanya analisis dan desain, itu sebenernya gak hanya asal copy paste sih. dalam fase desain, kita harus sudah mikirin hal-hal yang sudah dibatasi oleh teknologi dan juga keterbatasan non-fungsional. ada kalanya misalnya sebuah kelas pada tahap analisis harus dipecah ke dalam beberapa kelas dalam desain karena ada sedikit keterbatasan…. di dalam desain kita juga sebaiknya sudah tau aspek implementasinya, misalnya, kelas interface nanti akan diimplementasikan dengan apa, dsb…

    Reply
  2. Tidaaaaaaaakk ErPeEl :((
    saia tidak berpikir..tidak berpikir (Damas Mode: On)

    Reply
  3. tepan

     /  December 30, 2008

    Ega telah terpilih sebgai Miss RPL:D

    Reply
  4. rpl itu susah ya?😀

    Reply
  5. @petra:

    Nggak susah, cuma tidak menyenangkan

    Reply
  6. Virus HAtes

     /  January 15, 2009

    contoh diagram yang laen dunk mbak!!! Pls

    Reply
  7. shiro.tan

     /  March 4, 2009

    yang Problem domain object model, koq jadi kayak class diagram?? iya g?? klo beda na apa???

    trus klo kelas controller na mendingan dikasi tiap tabel/database, ato per peran/role yang ada di sistem??

    Reply
  8. @Virus HATEes->
    diagram apa butuhnya emang?hubungi saya via email saja ya, nanti saya kirim contoh2nya🙂
    @shiro.tan->
    beda donk, kalo kelas diagram kan digambarkan per use case, tapi kalo problem domain object tuh keseluruhan sistem…selain itu, membuatnya kan juga pada tahap yang berbeda, coba baca lagi bagian setelah

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

    PDOM dibuat saat kita membuat model kebutuhan, sedangkan kelas kita buat saat tahap analisis. Jadi sebelum terpikir kelasnya bakal apa aja, ketika membuat PDOM kita harus udah kepikir objek-objek apa aja sih yang bakal terlibat dalam sistem. Objek ini bisa macam-macam, kan disebutkan juga di atas bahwa

    Objek-objek tersebut dapat diperoleh dari object name, logical attributes, static instances associations, inheritance, dynamic instance associations, atau operations

    Tapi kebanyakan sih memang cenderung dibuat yang mengarah ke kelas, ada object name yang nantinya ‘menginspirasi’ pembentukan kelas view, ada logical attributes yang nantinya ‘menginspirasi’ pembentukan kelas model, ada pula operations yang nantinya ‘menginspirasi’ pembentukan kelas controller. Begitu kira-kira…Kalau kurang jelas bisa tanya lagi. Atau mungkin pembaca yang lain bisa membantu saya menjawab? silakan saja🙂

    Untuk jawaban pertanyaan yang kedua,
    menurut saya terserah saja sih, namun sebaiknya dibuat per peran karena kelas tersebut kan nantinya mungkin tidak akan dipakai di satu tabel atau database saja.

    Reply
  9. M0eTzwiD

     /  June 1, 2009

    Kl yg 1 usecaSe tp 2 akt0r cara bwt sequence diagram sama system sequence diagram na gmn?

    Reply
  10. Moch Lutfi

     /  October 23, 2009

    wah..sepertinya kuliah RPLnya menyenangkan…pingin belajar lagi…makasih atas ilmunya, saya jadi semangat lagi karena sempat frustasi gara2 RPL

    Reply
  11. Aqmal

     /  November 18, 2009

    wah mbak gantiin dosen RPLq aja..coz dosenq telo banget …wkwkwkwk thanks for all

    Reply
  12. walah saya nyasar ke sini,,

    nice article mbak. serem juga cewe maenannya use case:mrgreen:

    Reply
  13. kalau mau donlot filenya harus login😦

    Reply
  14. Yackvou

     /  February 14, 2011

    RPL -> P3PL -> KP -> SKRIPSI -> Pendadaran(Asumsi Lulus) -> Wisuda -> Kerja -> Pergi k Disko^^ -> The End!

    Reply
  15. Keren mas, saya baru tau tentang ini

    Reply
  16. eko

     /  July 25, 2011

    Ga bisa didownload materinya mbak…..
    mau baca soale gambar dari site nya kecil

    Reply
  17. vibi

     /  September 22, 2011

    coba di upload lagi materinya mbak.soalnya ga bisa didonlot.
    upload aja di 4shared atau mediafire.

    lagi pengen belajar rpl lagi nih.🙂

    Reply
  18. SiKase

     /  October 12, 2011

    Asslmkm neng ega..yang bagian 2 mana y..

    Reply
  19. nicho

     /  June 15, 2012

    username and password ny apa kk

    Reply
  20. apri

     /  September 29, 2012

    mba,saya msh kurang paham nih hehe. jadi model analysis itu fungsinya untuk apa? trs apakah bisa diterapkan di semua jenis diagram? mis. saya ingin membuat suatu uml aplikasi menggunakan diagram collaboration tp digambar dlm model analysis. kira2 bisa mba?

    Reply
    • Maaf, Apri.. “diagram collaboration” itu seperti apa ya? saya belum pernah membuat. Yang jelas, model analisis itu fungsinya seperti “sketsa” model perancangan. Memang isinya hampir sama, tapi kalo di model perancangan variabel dan fungsionalitasnya udah ditulis sebagaimana yg akan diimplementasikan dalam program. Misal, kalo di diagram sequence model analisis kita masih bisa nulis “menghapus data pelanggan”, maka di model perancangan harus ditulis “deleteUserData()”. Kira-kira kaya gitu..

      Reply
  21. rico

     /  January 13, 2013

    thx ya.. sangat membantu.. ^^

    Reply
  22. saya punya buku OOAD with the Unified process Versi : Satzinger * Jackson * Burd tetapi bhs inggris smua dan banyak kata2 yg sulit dipahami trus sya cari penjelasan singkat tentang OOAD ketemu dg blog ini, menurut saya artikel ini sangat membantu….

    Reply
  23. nikii

     /  March 21, 2013

    widih lengkap, tapi bahasanya masih rumit😀 .. good job (y)

    Reply
  24. wah mbak, makasih banget. udah lama nyari bahasan scenario diagram tapi gak nemu-nemu. ngubek-ngubek mbah gugel dikasih link postingan yang ini. bener-bener ngebantu😀

    Reply
  1. Membahas Use Case dan Kawan-kawannya (lagi) - Bagian 2 « cReAtiVegA’s dayEri…
  2. 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: