Use Case Diagram dan Contoh Use Case Diagram

Sebuah bisnis pasti berinteraksi dengan lingkungan. Interaksi ini meliputi bagaimana bisnis tersebut melayani customer, cara bisnis tersebut memperoleh barang mereka. Interaksi-interaksi yang terjadi ini disebut proses bisnis. Sebagai seorang analis sistem kita mungkin diminta untuk menggambarkan proses bisnis dan memperbaikinya atau meningkatkannya. Namun karna proses bisnis ini sangat banyak maka kita memerlukan sebuah model, yang mana mudah dimengerti dan bisa menggambarkan bagaimana cara bisnis ini berinteraksi dengan lingkungan. Salah satu model yang direkomendasikan untuk menggambarkan proses bisnis adalah use case.

Use Case

Use Case adalah cara formal untuk merepresentasikan bagaimana sistem bisnis berinteraksi dengan lingkungannya. Use Case adalah sebuah model logical di mana kita bisa mengetahui aktifitas bisnis tanpa memperdulikan urutan aktifitas tersebut dilakukan. Hal ini biasanya dilakukan setelah mengumpulkan kebutuhan dari user atau pengguna yang menggunakan sistem. 

Bagaimana cara mengumpulkan? Tentu saja dengan melakukan fact finding. Namun saat ini kita tidak akan membahas fact finding.

Inti utama dari model use case adalah menggambarkan siapa yang berinteraksi dengan sistem dan berinteraksi dengan fungsi utama yang mana saja. Di sini saat menggambarkan model yang berasal dari fact finding kita harus berhati-hati. Karena bisa jadi ada salah persepsi. Salah satu contoh adalah kasus di supermarket. Sebuah supermarket digambarkan bahwa customernya melakukan pembelanjaan dan pembayaran. Sekilas terlihat masuk akal, namun perhatikan pada hasil observasi di supermarket. Siapakah yang berinteraksi langsung dengan sistem/komputer? atau siapakah yang memberikan input pada sistem/komputer? apakah customer atau kasir? Bila customer melakukan sendiri input pada sistem maka actor yang digambar adalah customer, namun bila customer hanya membawa barang dan memberikan pada kasir, kemudian kasir yang melakukan semua input pada sistem maka kasirlah yang dibuatkan use case dan customer tidak perlu dibuatkan use case atau digambar sebagai actor.

Sebelum dilanjutkan kita coba kenali notasi/simbol yang ada dalam use case.

Ada 4 Notasi utama : 

1. Actors
2. Use Cases
3. Subject Boundaries
4. Set Relationship

Actor adalah orang atau sistem lain yang berinteraksi dengan sistem bisnis yang dimiliki perusahaan. Mereka akan menjadi subjek kita dan digambarkan dengan figur stickman seperti gambar berikut

Contoh gambar actor

Actor ini akan diberi label sebuah pekerjaan dari orang yang berperan dalam sistem, apabila dia merupakan sistem lain bisa digambarkan dengan kotak dan diberi label <<actor>>

Kemudian actor tidak bisa berinteraksi dengan actor lain secara langsung tanpa melalui relationship superclass, generalization atau specialization.

Sebuah actor bisa memiliki 1 atau beberapa use case tergantung peran dari aktor tersebut di dalam sistem. Simbol use case digambarkan dengan elips dan diberi tulisan aksi atau kasus/case yang dilakukan oleh actor di dalamnya.

Use Case digunakan untuk merepresentasikan fungsi utama yang akan dikerjakan di dalam sistem. Bedakan fungsi utama dan sebuah kewajiban umum. Register, login, forgot password adalah kewajiban umum atau fasilitas yang harus ada dalam sistem dan bukan pekerjaan utama dari aktor tersebut. Sehingga fungsi-fungsi tersebut ada baiknya tidak digambar sebagai use case.

untuk set relationship ada 4 simbol yang harus diperhatikan

1. Associate disimbolkan dengan sebuah garis lurus. Digunakan untuk menghubungkan actor dengan use case.

 

 

 2. Include Relationship. Dari sebuah use case utama menuju ke use case lain, dan diberi tanda <<include>>. Relasi dalam include digunakan bila setelah melakukan sebuah use case maka actor harus melakukan use case lain. Contoh gambar dari relationship include seperti berikut. Contoh penggunaan akan diberikan pada contoh use case lengkap.

 

 

3. Extend Relationship. Dari use case lain menuju use case utama dan diberi tanda <<Extend>>. Extend di dalam use case diagram digunakan apabila seorang actor selesai melakukan sebuah use case, dia bisa menjalankan use case lain. Namun bedanya extend dengan include adalah relationship extend ini bersifat optional.  Contoh gambar dari relationship extend seperti gambar berikut.

4. Generalization relationship yang digunakan untuk menggambarkan relasi dari actor menuju actor lain.

Lalu ada hal yang belum dijelaskan yakni subject boundaries. Subject boundaries dalam use case digunakan untuk memberitahu batasan dari sebuah proses sistem. Misalkan dalam rumah sakit, kita memiliki beberapa subsistem maka subject boundaries digunakan untuk memberikan batasan dari subsistem tersebut dan yang tergambar dalam subject boundaries adalah yang berada dalam subsistem tersebut.

Contoh Use Case Manajer

Sebagai contoh ini adalah use case dari seorang manajer setelah kita melakukan fact finding. 

Seorang manajer memiliki 4 use case atau pekerjaan utama di dalam sistem namun saat kita menggunakan sebuah Subject Boundaries, maka hanya actor dan use case yang berhubungan dengan subjectnya saja yang digambarkan. Sehingga gambar tersebut berubah sesuai dengan subjectnya, misalkan di dalam sebuah subject membuat janji temu atau appointment maka hanya akan ada actor dan use case yang berhubungan dengan appointment saja yang akan masuk dalam gambar use case.

Diagram use case dengan subject boundaries

Perhatikan di gambar ini, karena manajer hanya memiliki 1 case yang berada dalam subjek maka use case lain dari actor manajer tidak digambar dan actor-actor lain yang terlibat dalam sistem appointment digambar beserta dengan use case mereka.

Kemudian kita lihat bahwa dari actor menuju use case terdapat garis, garis inilah yang kita sebut associate relationship. Selain itu fokus berikutnya akan saya arahkan menuju ke generalization relationship yang ada pada bagian kanan use case dengan subject boundaries.

Gambar ini menyatakan bahwa bila ada pasien baru maka mereka akan memiliki sebuah case yang sama dengan yang dimiliki oleh actor pasien. Hal ini digunakan untuk membuat gambar use case menjadi lebih sederhana dan tidak membuat gambar dari use case diagram menjadi sesak. 

Perlu saya tekankan, alasan subject boundaries digunakan adalah agar kita melihat model use case secara sederhana dan dengan mudah melihat siapa saja actor yang berinteraksi dengan sistem yang sedang dibahas dan apa yang mereka lakukan dalam sistem.

Kemudian pasien baru bisa jadi punya use case sendiri seperti melakukan pendaftaran atau upload bukti KTP atau apapun itu, biasanya use case ini tidak akan dilakukan lagi oleh orang yang sudah jadi pasien lama dalam sistem sehingga perlu digambarkan sebagai 2 actor yang berbeda dan dilakukan generalisasi.

Lalu 2 relasi yang lain adalah include dan extend

Include Relationship dalam use case aturannya dari sebuah use case utama menuju ke use case lain, dan diberi tanda <<Include>>. Mungkin kalau dari tulisan saja susah menangkapnya jadi saya ambil dari kasus sebelumnya dan tambahkan relasi Include dalam use case yang dimiliki

Penggunaan Include dalam use case

Jadi dari manajer dia memiliki use case membuat jadwal. ini adalah use case utamanya, lalu setelah membuat jadwal keluarlah panah putus-putus menuju mengatur jadwal. Perlu diketahui bahwa simbol include dalam use case diagram ini memaksa actor melakukan use case lain setelah dia melakukan use case pertama, maksudnya adalah setelah manajer membuat jadwal dia diharuskan mengatur jadwal. Hal ini juga berlaku bagi actor dokter yang memiliki use case memberikan jadwal praktek, dia juga harus melakukan use case mengatur jadwal. Atau bisa juga kita bilang bila ingin melakukan use case mengatur jadwal maka actor tersebut harus melakukan use case membuat jadwal dan tanpa membuat jadwal maka actor tersebut tidak mungkin mengatur jadwal. 

Sifatnya seperti sebuah syarat. Bedakan dengan urutan. Untuk contoh nya mungkin akan lebih jelas dalam penggunaan extend.

Terakhir adalah relational extend, cara penggunaan extend tidak jauh berbeda dengan include. Perbedaan yang dimiliki adalah arah panahnya dan tulisan yang harus ada.

Penggunaan Extend dalam use case

Actor di sini melakukan sebuah use case janji temu, namun dia memiliki extend melakukan pembayaran. Artinya setelah membuat janji temu maka actor ini bisa memutuskan untuk melakukan pembayaran dan bisa juga memutuskan untuk tidak melakukan pembayaran. Perhatikan arah panahnya, extend dan include memiliki penggambaran arah panah yang berbeda. Ini juga merupakan sebuah syarat. Di mana untuk melakukan pembayaran, harus ada janji temu yang dibuat oleh actor. Namun saat actor membuat janji temu dia memiliki kebebasan untuk melakukan pembayaran atau tidak. Hal ini seperti yang ada di dalam e-commerce app, di mana kita bisa memasukan sebuah barang ke dalam keranjang belanja namun kita bebas untuk melakukan pembayaran atau tidak. Tentu saja bila pembayaran tidak dilakukan maka tidak akan ada transaksi dan kita tidak akan memperoleh barang tersebut.

Include yang bersifat mandatory/keharusan dari use case utama menuju use case selanjutnya.

Extend yang bersifat optional/pilihan berasal dari use case lain menuju use case utama.

Kemudian relationship extend dan include ini hanya untuk use case utama saja atau hal yang dikerjakan user dalam sistem. seperti login tidak usah dimasukan, hal ini hanya akan mempersusah diri. Contoh untuk melakukan sebuah aktifitas dalam sistem maka diharuskan melakukan login. Maka gambar akan menjadi penuh dengan relasi extend atau include seperti gambar berikut

Ini adalah sebuah gambar use case dengan penggunaan extend yang salah. Perlu diingat bahwa Use Case adalah sebuah model logical di mana kita bisa megetahui aktifitas bisnis tanpa memperdulikan urutan aktifitas tersebut dilakukan. Kemudian bila logikanya dibalik akan menjadi seperti ini. Untuk membuat jadwal, manajer harus login. Untuk memasukan data pegawai maka manajer harus login. Sekilas logikanya terlihat benar. Namun pada kenyataan saat menggunakan sistem nanti. Manajer hanya melakukan login 1 kali saja dan setelah itu dia bisa memasukan data pegawai dan membuat jadwal tanpa harus login kembali.

Maka gambar yang benar bila ingin memasukan use case login adalah seperti berikut.

Login menjadi sebuah use case lain tanpa harus menggunakan extend. 

Penggunaan yang Salah dalam Use Case

Ada beberapa kesalahan dalam penggunaan use case yang sering terjadi. Pertama adalah penggunaan usecase oleh beberapa actor. Seperti yang kita tahu setiap transaksi akan memiliki pembayaran yang dilakukan oleh customer. Maka biasanya akan kita gambarkan seperti ini

Contoh penggunaan use case yang salah

Sekilas terlihat benar, karena dalam transaksi perlu peran dari customer dan kasir di saat bersamaan. Namun dalam prakteknya hal ini tidak mungkin terjadi. Karena harus diingat bahwa use case memerlukan spesifik pekerjaan yang dilakukan. Meski benar ini case transaksi namun keduanya memiliki use case yang berbeda. Silahkan perhatikan di supermarket saat terjadi transaksi. 

Kasir akan memasukan barang yang dibeli ke dalam sistem dan sistem akan otomatis menghitungkan biaya yang harus dibayarkan oleh customer. Kemudian customer bisa melakukan pembayaran secara digital maupun secara cash. Untuk pembayaran digital maka kasir akan memasukan jumlah yang harus dibayar lalu memberikan QR code kepada customer, baru setelah itu customer bisa melakukan pembayaran digital.

Saya rasa sebagian besar kasus yang terjadi di supermarket seperti itu bukan? maka kita tidak bisa menggunakan use case di atas. Karena meski sama-sama transaksi peran yang dimiliki kedua actor berbeda, maka gambar biasanya akan berubah seperti gambar berikut

Note : Ini MASIH CONTOH YANG SALAH

Use Case Transksi Supermarket

 

Sesuai seperti cerita di atas maka kasir bertugas memasukan barang dan bila user menggunakan pembayaran digital maka akan masuk ke dalam pembayaran digital dengan menggunakan extend. Sekarang kita lihat secara spesifik dalam "Pembayaran Digital" di mana ada 2 relasi. Ini artinya harus dikerjakan oleh kedua actor yg berhubungan. Yakni actor kasir yang melakukan "scan barang" dan memilih untuk melanjutkan ke pembayaran digital dan actor customer yang melakukan pembayaran digital. Apabila salah satu tidak melakukan pembayaran digital maka case pembayaran digital tidak bisa dilakukan. Misal kasir masuk ke pembayaran digital namun customer tidak melakukan pembayaran digital maka use case "Pembayaran digital" harusnya tidak mungkin terjadi. Sekilas terlihat sudah lebih masuk akal namun, hal ini masih salah. 

Perlu dipahami bahwa sebuah case adalah sebuah pekerjaan bagi actor. Saat kita berada di kasus supermarket ini harus diperhatikan bahwa dalam pembayaran digital "Kasir akan memasukan jumlah yang harus dibayar lalu memberikan QR code kepada customer baru setelah itu customer bisa melakukan pembayaran digital" Maka use case di kasir adalah extend memasukan jumlah dan include generate QR code.

Use Case Kasir dalam Pembayaran Digital

Kemudian bagaimana dengan customer? Seperti yang kita tahu customer akan sanagt terganung pada aksi yang dilakukan. Maksudnya seperti ini, bila sistem yang kamu bangun memiliki fitur scan QR code maka use case customer akan digambar, namun bila dia menggunakan e-Wallet lain, yang tidak berhubungan dengan sistem yang dibangun maka tidak pelu menggambarkan use case dari customer melakukan pembayaran. Ingat use case adalah cara formal untuk menggambarkan sistem bisnis berinteraksi dengan lingkungannya. Karena kamu tidak menyediakan sistem e-Wallet dan customer mnggunakan e-Wallet dari sistem lain yang tidak berada dalam lingkunganmu maka tidak perlu menggambar use case customer. Bila kamu menyediakan pembayaran dengan e-Wallet yang ada di dalam sistem, gambar antar use case tidak akan terhubung. Karena mereka mempunyai pekerjaan yang berbeda. 

Use Case yang terhubung dengan use case lain hanya terjadi apabila objek yang dikerjakan sama dan GUI yang digunakan untuk melakukan case tersebut sama. Seperti contoh yang ada di dalam include.

Semoga artikel untuk membuat use case diagram ini membantu.