Candidate Class dan Interaction Diagram

Candidate Class dan Interaction Diagram

1.1. Candidate Class

Pengertian candidate class

Dari suatu behavior atau fungsionalitas yang dimiliki oleh sistem, kita memiliki skenario dari behavior tersebut, yang menceritakan proses yang terjadi (bussiness logic). Analisis merupakan tahap dimana seorang sistem analis, mengidentifikasi object-object yang terlibat dalam suatu bussiness logic. Dari skenario ini kita bisa mengidentifikasi object-object yang terlibat.

Object adalah gambaran dari entity, baik dunia nyata atau konsep dengan batasan-batasan yang tepat. Object bisa mewakili sesuatu yang nyata dalam domain problem kita seperti komputer, barang, konsumen, atau dapat berupa konsep seperti proses penarikan uang, pembayaran, pengembalian buku dan lain-lain. Setiap object dalam sistem memiliki tiga karakteristik yaitu State(status), Behavior(sifat), Identity(identitas).

Dari object-object ini kita bisa mengabstraksikan candidate class yang mungkin terlibat.

Cara mengidentifikasi object:

1. Pengelompokan berdasarkan kata/frase benda pada skenario.
2. Berdasarkan daftar kategori object, antara lain:

·         object fisik, contoh : pesawat telepon

·         spesifikasi/rancangan/deskripsi, contoh : deskripsi pesawat

·         tempat, contoh : gudang

·         transaksi, contoh : penjualan

·         butir yang terlibat pada transaksi, contoh : barang jualan

·         peran, contoh : pelanggan

·         wadah, contoh : pesawat terbang

·         kata benda abstrak, contoh : kecanduan

·         kejadian, contoh : pendaratan

·         aturan atau kebijakan, contoh : aturan diskon

·         catalog atau rujukan, contoh : daftar pelanggan

Class adalah deskripsi sekelompok object dari property (atribut), sifat (operasi), relasi antar object dan sematik yang umum. Class merupakan template untuk membentuk object. Setiap object merupakan contoh dari beberapa class dan object tidak dapat menjadi contoh lebih dari satu class. Penamaan class menggunakan kata benda tunggal yang merupakan abstraksi yang terbaik. Pada UML, class digambarkan dengan segi empat yang dibagi. Bagian atas merupakan nama dari class. Bagian yang tengah merupakan struktur dari class (atribut) dan bagian bawah merupakan sifat dari class (operasi). 

Gambar 3‑1 Class

Candidate Class

Candidate class dapat kita tentukan dengan melihat skenario use case yang telah kita buat. Candidate class tersebut dapat diambil dari kata benda yang muncul pada skenario use case, atau mengikuti penjelasan yang telah disampaikan di atas.

Sebagai contoh :

Gambar 3‑2 Candidate Class

1.2     Interaction Diagram

Pengertian Interaction diagram

Interaction diagram menunjukkan kolaborasi sekumpulan object dalam suatu fungsionalitas. Termasuk pesan yang dilepaskan di antara mereka. Ketika kita memberikan pesan, aksi yang dihasilkan adalah sebuah pernyataan tereksekusi yang membentuk abstraksi dari prosedur komputasi. Sebuah aksi mungkin menghasilkan perubahan kondisi.

Dalam UML, kita dapat memodelkan beberapa jenis aksi, yaitu:

·         Call : memanggil operasi yang ada pada object, object mungkin mengirim ke dirinya sendiri, menghasilkan pemanggilan lokal dari operasi.

·         Return : mengembalikan nilai dari caller

·         Send : mengirimkan sinyal ke object

·         Create : membuat sebuah object

·         Destroy : mematikan sebuah object, object mungkin saja mematikan dirinya sendiri.

Interaction diagram selain digunakan untuk memodelkan aspek dinamis dari sistem, tetapi juga berguna untuk membangun sistem yang executables melalui forward dan reverse enginerring.

Interaction diagram menggambarkan kelakuan beberapa object dalam suatu use case tunggal sebagai bentuk use case realization. Dalam UML Interaction diagram muncul dalam 2 varian, Sequence Diagram dan Collaboration Diagram.

sequence diagram

Sequence diagram menggambarkan interaksi antara sejumlah object dalam urutan waktu. Umumnya sebuah sequence diagram menangkap behavior dari suatu skenario (best case). Diagram ini menunjukkan sejumlah object dan pesan-pesan yang dilewatkan antara object-object ini dalam skenario tersebut. Dalam UML, object pada diagram sequence digambarkan dengan segi empat yang berisi nama dari object yang digarisbawahi. Pada object terdapat 3 cara untuk menamainya yaitu : nama object, nama object dan class serta nama class.

Contoh :

Gambar 3‑3 Penamaan Object

Dalam diagram sequence, setiap object hanya memiliki garis yang digambarkan garis putus-putus ke bawah. Pesan antar object digambarkan dengan anak panah dari object yang mengirimkan pesan ke object yang menerima pesan.

Berikut contoh Sequence Diagram: Peminjaman untuk studi kasus Aplikasi Perpustakaan

Gambar 3‑4 Sequence Diagram: Peminjaman(1)

Diagram sequence secara explicit menggambarkan interaksi antar object yang terlibat dalam suatu skenario, berdasarkan urutan waktu. Terlihat, instansiasi dari masing-masing kelas yang terlibat saling mengirimkan dan menerima pesan, pesan yang dikirimkan berupa pemanggilan prosedur atau pengembalian suatu nilai balik/status.

Komponen-komponen yang terdapat pada sequence diagram, antara lain :

Object didapat dari class diagram

Found message merupakan suatu pesan yang men-stimulus terjadinya suatu skenario, asal dari found message ini sebenarnya tidak terlalu dipermasalahkan, karena diagram ini tidak menekankan pada apa yang menginisiasi suatu skenario (hal ini ditekankan dalam diagram use case), tetapi pada skenario apa yang terjadi bila sudah di inisiasi. Found message bisa berasal dari main program atau aktifitas user.

Life line merupakan jalur hidup suatu instance kelas tertentu, selain berfungsi untuk mengetahui kapan suatu instance hidup dan dihapus, juga untuk melinierkan urutan pemanggilan pesan untuk instance yang bersangkutan.

Activation bar atau focus of control dalam setiap life line menunjukkan kapan suatu instance aktif dalam interaksi, activation bar ini juga berhubungan dengan fungsi dari instance yang berada dalam stack.

Procedure call merupakan pemanggilan suatu fungsi milik instance kelas lain, dilambangkan dengan garis tegas dan panah solid, pemilik fungsi yang bersangkutan adalah yang ditunjuk oleh panah. Dari diagram diatas bisa kita ketahui bahwa kelas Peminjaman memiliki fungsi setPeminjaman, savePeminjaman, kelas Anggota memiliki fungsi cekAnggota, cekPinjamMax, setStatusPinjam, updateAnggota, dan seterusnya. Suatu kelas tidak hanya dapat berpartisipasi dalam suatu skenario, tetapi juga dapat berpartisipasi dalam skenario lain, sehingga fungsi-fungsi yang dimiliki oleh suatu kelas adalah semua fungsi yang pernah dipanggil dari instance kelas tersebut, dalam semua skenario untuk semua use case yang ada. Untuk mengirim suatu procedure call antar objek, harus ada pula asosiasi antar kelas pada class diagram.

Self call identik dengan procedure call, hanya saja dipanggil dalam fungsi milik instance sendiri yang sedang aktif pada saat itu (ditandai dengan activation bar).

Return value merupakan suatu nilai balik yang dihasilkan dari pemanggilan suatu fungsi, return value tidak selalu harus digambar, gambarkan hanya bila menambah informasi tambahan untuk memahami skenario yang terjadi. Sehingga dari diagram diatas kita bisa lihat bahwa skenario yang terjadi merupakan skenario best case, dimana fungsi cekAnggota, cekBuku, cekPinjamMax mengembalikan nilai yang memungkinkan skenario ini berlanjut sampai proses peminjaman selesai. Jika return value ini tidak ditambahkan pada diagram sequence tersebut, maka akan menyulitkan pembaca untuk memahami skenario apa yang diterangkan dalam diagram tersebut.

Gambar 3‑5 Sequence Diagram: Peminjaman(2)

Diagram diatas (Gambar 3-4) tidak menceritakan skenario yang berbeda dengan diagram sebelumnya (Gambar 3-5). Namun bila diperhatikan dua diagram tersebut secara jelas menggambarkan perbedaan interaksi yang terjadi antara object-object yang terlibat, disinilah kelebihan diagram sequence, diagram sequence tidak dirancang untuk menggambarkan flow of control seperti conditional atau looping (walaupun dalam UML versi 2.0 ditambahkan beberapa notasi untuk mengakomodasi kebutuhan tersebut), tapi lebih untuk menggambarkan proses tertentu dilakukan oleh instance tertentu.

Responsibility merupakan letak perbedaan diantara dua diagram tersebut, pada diagram pertama, terlihat bahwa sebagian besar pemanggilan fungsi dilakukan oleh instance FormPinjam (over responsibility), ini yang disebut dengan centralized control. Pada diagram kedua beberapa pemanggilan disebar ke instance yang lain, sehingga masing-masing instance melakukan proses yang seharusnya mereka lakukan, ini yang disebut dengan distributed control. Responsibility dari suatu kelas ditentukan oleh konteks kelas tersebut dalam suatu skenario, diagram kedua lebih membagi responsibility ke instance-instance yang terlibat, dan control seperti ini lebih disukai dalam pendekatan object oriented, karena pada proses design kita memang seharusnya bisa membagi responsibility dari kelas-kelas yang kita rancang.

collaboration diagram

Seperti halnya sequence diagram collaboration diagram juga menggambarkan interaksi antara sejumlah object. Hanya saja diagram ini hanya menggambarkan hubungan antara object-object yang bekerja, tanpa mendeskripsikan urutan proses tersebut.

Collaboration diagram berisi :

§  Object yang digambarkan dengan segiempat.

§  Hubungan antara object yang digambarkan dengan garis penghubung.

§  Pesan yang digambarkan dengan teks dan panah dari object yang mengirim pesan ke penerima pesan.

Berikut contoh Collaboration diagram: Peminjaman untuk studi kasus Aplikasi Perpustakaan

Gambar 3‑6 Collaboration Diagram: Peminjaman

Dalam collaboration diagram, yang ditekankan adalah organisasi struktural object-object yang berinteraksi. Secara semantik sequence dan collaboration merupakan diagram yang ekivalen, bahkan kita dapat beralih dari sequence diagram ke collaboration diagram tanpa kehilangan informasi.

Dalam tahap implementasi sequence diagram cenderung lebih banyak digunakan untuk menggambarkan use case realization, karena lebih mudah untuk diterjemahkan ke bentuk source code.