Behavior Model : Sequence Diagram, Aturan dan Cara Menggambar

 Sequence diagram adalah bagian dari Behavior Model dan Interaction Diagram, yang mana tugasnya untuk membantu dalam menentukan perilaku sebuah objek atau kalau dengan kasarnya kita bisa bilang perilaku atau urutan bekerjanya sebuah coding untuk mencapai tujuannya. Tentu saja ini bukan dalam hal yang sangat luas, tetapi dalam hal detil yang spesifik. Namun sebelum kita asumsikan semua secara liar, silahkan pelajari cara dan konsep yang ada.

User pasti memiliki sebuah tujuan dalam memakai sebuah software, namun code dalam software tersebut bisa dibuat dalam berbagai macam bentuk tergantung dari style developernya. Maka agar kita memiliki pemikiran yang sama maka kita gunakan sequence diagram. Setiap code juga pasti akan berinteraksi dengan objek lain seperti tabel dalam database atau bahkan atribut-atributnya. Sehingga nanti ketika kita menggambarkan code tersebut menyimpan data, maka penyimpanan data ini tidak boleh kita tulis sebagai database. Namun harus detil, seperti code yang dibuat menyimpan data di tabel mana dan atribut apa yang menjadi penentunya(terutama dalam update dan delete).

Kapan sequence ini dipakai? 

Sequence dipakai saat kita memiliki aturan khusus dalam membangun sebuah code/program. Contohnya adalah seorang user pada umumnya kalau mau masuk dalam sistem maka mereka akan mengisikan username dan password. Untuk kasus ini biasanya password akan menggunakan enkripsi MD5. Namun kali ini kita selain menggunakan MD5 kita juga menggunakan kode khusus yang digenerate bedasarkan tanggal hari ini dan id usernya. Kode khusus di sini adalah sesuatu yang abstrak, seorang programmer berpengalaman pun akan susah mengartikan kode khusus dan digenerate bedasarkan tanggal ini. Hal ini wajar karena kita memiliki konsep yang berbeda. Supaya programmer ini nanti saat membuat code memiliki konsep yang sama dan mencegah kesalahan terjadi maka sistem desainer akan menggambarkan sequence diagramnya.

Sequence diagram mengilustrasikan objek yang berpartisipasi dalam use case(Actor) dan message yang sering terjadi seiring berjalannya waktu(Aksi yang dilakukan actor). Maka kita bisa melihat alur kerja secara spesifik, jadi saat sequence diagram ini diberikan ke programmer maka mereka tahu alur kerja yang diharapkan oleh desainer dalam code yang akan mereka bangun nanti

Element dalam Sequence Diagram

Actor, actor adalah seseorang yang berada di luar sistem namun dia berpatisipasi dalam sistem atau menggunakan sistem. Actor yang berupa manusia akan digambarkan menggunakan stickman. Jangan lupa menuliskan nama actor atau divisi yang akan berpartisipasi di atas atau dibawah simbol actor ini. 

Actor kedua adalah sistem lain yang berada di luar sistem yang dibangun. Seperti saat kita menggunakan login menggunakan akun google kita, maka google ini akan dimasukan sebagai actor namun dia adalah actor berupa sistem, bukan manusia. Untuk memberitahu bahwa objek ini sebagia actor tambahkan <<Actor>> lalu beri nama(di gambar saya beri nama AnActor). Kenapa harus ditambahkan <<Actor>> karena sebuah objek akan memiliki simbol yang mirip. Maka <<Actor>> digunakan untuk memberitahu bahwa ini adalah objek di luar sistem kita dan tidak perlu mencari di dalam sistem atau desain yang dibangun.

Ketika code berurusan dengan database, maka database ini harus dituliskan secara spesifik dalam objek oriented sebuah tabel akan digambarkan dengan class diagram dan di dalam sequence diagram kita langsung menyebutnya sebagai class.

Kemudian bila kita ingin mengarah pada object yang sangat spesifik kita bisa masukan nama objeknya di dalam. Untuk menggambarkan  obejek di dalam class ini kita bisa gunakan simbol kotak dengan namaObjek:namaClass di dalamnya. Bila anda tidak memberikan objek secara spesifik maka tulis saja ": namaClass" di dalam kotak.

 

Berikutnya yang perlu digambar adalah sebuah object lifeline, digambarkan di bawah actor atau object dengan garis lurus putus-putus dan akan ada hingga akhir sebuah sequence atau ketika object tersebut dihapus. 

 

 

 Sedangkan saat terjadi sebuah aksi di dalam object tersebut maka akan ditambahkan simbol Execution Occurance, tujuannya memberitahu bahwa objek ini sedang menerima dan mengirimkan messages. Execution occurance digambarkan dengan simbol kotak dan akan berada di atas object lifeline.

 

 

Kemudian, untuk menjalankan perintah atau memberikan sebuah informasi dari 1 objek ke objek lain, kita gunakan simbol message dengan pesan/perintah yang dijalankan di atasnya

 Simbol bisa ke arah manapun selama dia memberikan informasi atau menjalankan perintah yang berhubungan atau menuju class yang dimaksud. 

Untuk return value bisa menggunakan tanda panah dengan garis putus-putus. Return value adalah reaksi dari menjalankan sebuah perintah program atau hanya sekedar pesan bahwa code telah berjalan dengan baik. Tulisan ReturnValue yang ada di bawah garis tidak harus ada atau bisa diganti dengan hal lain.

Kemudian bila ada sebuah perintah yang dijalankan dengan syarat tertentu kita bisa memberikan guard condition pada panah message yang ada.

Penulisannya nanti bisa berupa seperti ini [Grand total melebih budget]:Alert(budget). Tulisan [Grand total melebihi budget] adalah syarat untuk menjalankan perintah Alert(budget). 

Terakhir bila sebuah object dihancurkan kita juga memberikan simbol Object Destruction, tujuannya memberi tahu bahwa objek ini sudah tidak terpakai dan dihapus agar tidak membebani penyimpanan/server/pc dan apapun yang bisa kalian sebutkan.

Adapun beberapa aturan yang harus dipahami bersama adalah pemulai scenario akan selalu berada di posisi kiri atas. Bila ada 2 objek dengan tipe sama berinteraksi maka mereka harus diberi nama objek pada class agar bisa dibedakan.

 

Kemudian sekali lagi return value tidak harus ada, hanya dibuat untuk memberikan informasi tambahan pada pembaca diagram. 

Message pada dasarnya adalah sebuah informasi sehinga pada sequence diagram masih memungkinkan ada gambar dari actor menuju actor lain, tetapi hal ini sebisa mungkin dihindari agar tidak membuat orang kebingungan. 

Terakhir sequence diagram hampir  mirip dengan Data Flow Diagram, dia mencari tahu siapa pemberi data(input) lalu data diolah bagaimana(proses) dan hasil akhirnya menjadi seperti apa(output). Tapi sequence diagram tidak melihat secara keseluruhan melainkan per objek atau perkasus dengan proses yang spesifik.

Misal ketika kita membuat sistem untuk perpusatakaan di mana penjaga perpus yang kita sebut librarian akan mencari buku terlebih dahulu dalam sistem, kemudian mengubah status buku pada detil buku dan dari sana dia akan mendapat output informasi tanggal buku harus kembali. Maka gambar sequence diagram akan menjadi seperti berikut. 

tBuku dan tDetilBuku adalah nama class, karena kita tidak ada objek spesifik maka hanya dituliskan nama class. Dari mana asal tBuku dan tDetilBuku, tentu saja dari sistem desainer bersama sistem analis yang mengubah hasil fact finding yang didapatkan menjadi struktur database atau class diagram.

Sekarang kita membaca sequence diagram seperti ini, seoarang penjaga perpus akan menjalankan program dan program ini akan mencari buku pada tabel tBuku bedasarkan NoBuku menggunakan perintah CariIDBuku. Kemudian dari tBuku librarian bisa melihat detil dan mengubah status buku di detil tersebut. Saat status diubah maka program akan memberikan informasi pada librarian mengenai tanggal buku kembali.

Saya harap dengan gambar sederhana ini bisa mengerti cara membaca ataupun membuat sequence diagram. Kemudian hal yang harus diperhatikan adalah setiap class sudah ada terlebih dahulu, oleh karena itu semua class akan ditaruh di paling atas. Namun harus disadari juga ada class yang terbentuk atau dibuat pada kondisi khusus seperti Shopping Cart. Maka cara menggambar akan berubah menjadi seperti ini.

Sequence diagram shopping cart

Perhatikan di sini, class shopping cart hanya dibuat saat dibutuhkan saja dan tidak ada dalam database. Setelah shopping cart ada, maka user bisa langsung berinteraksi shopping cart yang ada. Lalu saat barang sudah selesai dan shopping cart tidak dibutuhkan lagi, kita bisa menggunakan object destroy untuk mengatakan bahwa class ini sudah tidak diperlukan dan harus dihapus.

 

Shopping cart adalah sebuah contoh sederhana kalau anda bertanya dalam hal apa destroy objek ini sering digunakan maka jawabannya adalah captcha, dibuat sementara dan bila di refresh maka yang lama dihapus dan dibuatkan yang baru. Tujuannya adalah captcha tidak menghabiskan resource komputer. Kemudian banyak hal lain seperti kode otentikasi yang sering kita gunakan dalam transaksi perbankan. Tujuannya adalah demi keamanan. 

Berikutnya, mungkin akan ada yang memerlukan sebuah class yang menjalankan fungsi di dalam class itu sendiri dan bingung dari mana atau ke mana arah panahnya. Jawabannya cukup mudah buat panah message keluar dan mengarah pada dirinya sendiri.

Terakhir ada juga sebuah fungsi yang dijalankan pada saat melakukan input tapi user belum melakukan aksi seperti simpan. Kejadian ini terjadi di mana? paling banyak di halaman register dan pada bagian username. Saat user memasukan username, maka sistem otomatis melakukan pengecekan pada database untuk melihat apakah username tersebut sudah terpakai atau tidak dan di sini user belum menekan tombol apapun. Bagaimana cara menggambarnya? Kasus ini kasus khusus di mana kita bisa menggunakan garis message(Lurus) tanpa tanda panah. Artinya adalah untuk input saja.

Perhatikan beda garis yang dari actor dan dari class register.php menuju class user. Dari actor hanya garis lurus dan ini menandakan user hanya melakukan input. Sedangkan register.php menjalankan fungsi pengecekan yang dituju ke class tUser. Cara menjalankan pengecekan tidak ditentukan, karena semua diserahkan pada programmer dan sangat bergantung pada bahasa pemprograman yang dipakai. Kemudian perlu diingat ini adalah sebuah desain khusus. Sehingga tidak semua perlu dimasukan dan digambarkan seperti pengecekan username di atas(Maksudnya setiap input digambar garis). 

Penggunaan objek dan simbol yang ada sesuai kebutuhan, jadi jangan dipaksakan semua harus ada, gunakan yang bisa menggambarkan alur code yang anda inginkan dan pastikan sesuai permintaan client atau fact finding anda. Pastikan setiap model yang anda bangun sederhana dan mudah dimengerti oleh orang lain.