Use Case Diagram Adalah: Simbol, Relasi & Contohnya

Sebelum sebuah rumah dibangun, arsitek menggambar denah. Denah tidak menjelaskan cara memasang bata, tetapi semua orang yang melihatnya langsung tahu ada berapa kamar dan pintu mana yang menuju ke mana. Perangkat lunak juga punya "denah", hanya saja jumlahnya lebih dari satu. ERD menggambar susunan data, sedangkan flowchart menggambar urutan langkah sebuah proses.

Ada satu pertanyaan yang belum dijawab keduanya: siapa saja yang memakai sistem, dan apa yang bisa mereka lakukan di dalamnya? Pertanyaan itulah yang dijawab oleh use case diagram, yang di mesin pencari juga sering ditulis usecase diagram. Artikel ini membahas pengertiannya, simbol dan relasinya, contoh sistem perpustakaan lengkap dengan skenarionya, hingga cara membuatnya sendiri.

Apa Itu Use Case Diagram?

Use case diagram adalah diagram dalam UML (Unified Modeling Language, bahasa pemodelan standar untuk merancang perangkat lunak) yang memetakan interaksi antara pengguna dan sistem. Diagram ini menunjukkan tiga hal: siapa yang berinteraksi, fungsi apa yang tersedia, dan di mana batas sistemnya. UML mengelompokkannya ke dalam diagram perilaku (behavior diagram), karena yang digambar adalah apa yang dilakukan sistem.

Agar tidak tertukar, bedakan dulu dua istilahnya. Secara harfiah, use case artinya kasus penggunaan. Dalam UML, use case adalah satu tujuan yang ingin dicapai pengguna lewat sistem, misalnya "Meminjam Buku" atau "Membayar Tagihan". Use case diagram adalah gambar yang mengumpulkan semua use case tersebut beserta pihak yang terlibat dalam satu halaman.

Hal yang perlu dipegang sejak awal: use case diagram menjawab apa, bukan bagaimana. Diagram ini tidak menunjukkan urutan klik, isi tabel database, atau logika program. Ia hanya menyatakan bahwa sistem perpustakaan, misalnya, harus bisa melayani peminjaman, pengembalian, dan pencarian buku.

Konsep use case diperkenalkan Ivar Jacobson dari lingkungan Ericsson pada konferensi OOPSLA tahun 1987. Istilah awalnya usage case, terjemahan kata Swedia användningsfall. Bukunya tahun 1992 mempopulerkan teknik ini, lalu use case masuk ke UML yang dibakukan OMG (Object Management Group) pada 1997.

Untuk Apa Use Case Diagram Dibuat?

Use case diagram paling berguna di awal proyek, saat kebutuhan sistem masih berupa catatan rapat. Ada tiga fungsi praktisnya:

1. Menyepakati batas sistem: Klien, analis, dan programmer menunjuk satu gambar yang sama. Fitur yang berada di luar kotak berarti tidak dikerjakan pada proyek ini.
2. Menjadi daftar fitur yang bisa dicentang: Setiap elips mewakili satu tujuan pengguna. Saat proyek berjalan, daftar ini berfungsi sebagai alat ukur kemajuan yang mudah dipahami pihak non-teknis.
3. Menjadi bahan rencana pengujian: Setiap use case nantinya diuji minimal satu kali, sehingga penguji tahu persis apa yang harus dicoba.

Cara paling mudah memahami posisinya adalah menganggapnya sebagai daftar isi buku kebutuhan. Daftar isi memberi gambaran utuh dalam sekali lihat, tetapi isi babnya ditulis di tempat lain, yaitu skenario.

Simbol Use Case Diagram dan Artinya

Dibanding ERD atau flowchart, simbol use case diagram jauh lebih sedikit. Komponen use case diagram hanya ada empat, yaitu aktor, use case, batas sistem, dan garis relasi:

Aktor selalu digambar di luar kotak, sedangkan use case selalu di dalam kotak. Nama sistem ditulis di bagian atas kotak, misalnya "Sistem Perpustakaan".

Perlu diperhatikan bahwa aktor adalah peran, bukan orang tertentu. Satu orang bisa memainkan dua peran: pustakawan yang meminjam buku untuk dirinya sendiri sedang berperan sebagai Anggota. Aktor juga tidak harus manusia. Layanan pembayaran pihak ketiga, server email, atau penjadwal otomatis yang berjalan setiap tengah malam juga bisa menjadi aktor.

Penamaan ikut menentukan apakah diagram mudah dibaca. Pakai aturan sederhana berikut:

• Aktor dinamai dengan kata benda peran: Anggota, Petugas, Admin, Sistem Pembayaran.
• Use case dinamai dengan kata kerja + objek: Meminjam Buku, Mencetak Laporan, Mengubah Kata Sandi.

Nama seperti "Data Buku" atau "Laporan" adalah tanda bahaya. Keduanya kata benda, sehingga pembaca tidak tahu apa yang sebenarnya dilakukan terhadap data atau laporan tersebut.

Include dan Extend Use Case: Membaca Arah Panah

Garis penghubung di use case diagram ada empat jenis. Bagian inilah yang paling sering membuat mahasiswa kehilangan nilai, terutama karena arah panah include dan extend kelihatan mirip.

1. Asosiasi (association): Garis lurus polos tanpa kepala panah antara aktor dan use case. Artinya aktor tersebut terlibat dalam use case itu.
2. Include: Garis putus-putus berlabel «include». Use case dasar selalu menjalankan use case lain sebagai bagian dari dirinya, mirip pemanggilan fungsi dalam program. Panah berangkat dari use case dasar menuju use case yang di-include.
3. Extend: Garis putus-putus berlabel «extend». Use case perluasan kadang-kadang menyisipkan perilaku tambahan ke use case dasar, hanya jika kondisi tertentu terpenuhi. Panah berangkat dari use case perluasan menuju use case dasar.
4. Generalisasi (generalization): Garis lurus dengan kepala panah segitiga kosong. Artinya pewarisan: aktor Mahasiswa dan Dosen sama-sama "jenis" Anggota, sehingga keduanya mewarisi semua use case milik Anggota.

Arah panah include dan extend memang berlawanan, dan menghafalnya secara terpisah mudah tertukar. Ada satu aturan yang lebih mudah diingat:

💡 Panah selalu berangkat dari use case yang menyebut use case lain di dalam skenarionya.

• Pada include, skenario "Meminjam Buku" menulis "sistem memeriksa status anggota". Use case dasar yang menyebut, jadi panah berangkat dari use case dasar.
• Pada extend, skenario "Meminjam Buku" tidak tahu apa-apa soal denda. Justru use case "Membayar Denda" yang menyatakan, "saya menempel pada Mengembalikan Buku jika ada keterlambatan". Use case perluasan yang menyebut, jadi panah berangkat dari use case perluasan.

Titik tempat perluasan boleh menempel disebut extension point. Spesifikasi UML mengizinkan titik ini ditulis di dalam elips use case dasar, di bawah judul "extension points". Syarat berlakunya, misalnya "terlambat > 0 hari", boleh ditulis dalam catatan yang ditempel pada garis extend.

Ringkasnya, perbedaan include dan extend bisa dilihat dari tabel berikut:

Contoh Use Case Diagram Sistem Perpustakaan

Teori di atas akan lebih mudah dipahami lewat contoh. Kita pakai contoh use case diagram sederhana untuk perpustakaan kampus, dengan 3 aktor dan 7 use case.

Aktor:

1. Anggota: Mahasiswa atau dosen yang mencari, memesan, dan meminjam buku.
2. Petugas: Pustakawan yang melayani peminjaman, pengembalian, dan mengelola koleksi.
3. Bank: Layanan pihak ketiga yang memproses pembayaran denda secara nontunai.

Use case: Mencari Buku, Memesan Buku, Meminjam Buku, Mengembalikan Buku, Memeriksa Status Anggota, Membayar Denda, dan Mengelola Data Buku.

Cara membacanya: Anggota terhubung ke Mencari Buku dan Memesan Buku, karena kedua hal itu bisa ia lakukan sendiri dari aplikasi. Meminjam Buku dan Mengembalikan Buku terhubung ke dua aktor sekaligus, karena transaksi di meja layanan melibatkan Anggota dan Petugas. Satu use case memang boleh punya lebih dari satu aktor.

Meminjam Buku meng-include Memeriksa Status Anggota, karena setiap peminjaman wajib melewati pengecekan apakah anggota sedang diblokir. Sebaliknya, Membayar Denda memperluas (extend) Mengembalikan Buku, karena denda hanya muncul jika buku terlambat dikembalikan. Membayar Denda juga terhubung ke Bank, aktor nonmanusia yang memproses transaksinya.

Perhatikan juga apa yang tidak ada di diagram. Tidak ada urutan "cari dulu, baru pesan", tidak ada tabel buku, dan tidak ada tombol. Semua itu memang bukan tugas use case diagram.

Skenario Use Case: Isi yang Tidak Terlihat di Diagram

Elips bertuliskan "Meminjam Buku" belum cukup untuk membangun fitur. Programmer masih perlu tahu apa yang terjadi jika anggota sedang diblokir, atau berapa lama masa pinjamnya. Jawaban itu ditulis dalam use case scenario atau skenario use case, yang di beberapa buku disebut juga use case description atau spesifikasi use case.

Berikut contoh skenario untuk use case Meminjam Buku:

Ada dua hal yang terlihat jelas dari tabel ini. Pertama, relasi include muncul secara alami di langkah 3, sehingga Anda bisa memeriksa kebenaran arah panah dari skenarionya. Kedua, alur alternatif berisi informasi yang paling dibutuhkan programmer dan penguji, padahal tidak satu pun terlihat di diagram.

Inilah alasan Martin Fowler, penulis UML Distilled, pernah menyebut use case diagram sebagai "daftar isi visual, tidak lebih". Nilai sebenarnya dari use case ada pada teks skenarionya. Jika waktu Anda terbatas, prioritaskan skenario untuk use case yang paling penting, bukan merapikan bentuk elips.

Cara Membuat Use Case Diagram dalam Lima Langkah

Langkah berikut berlaku untuk sistem apa pun, dari aplikasi kasir hingga sistem informasi akademik. Kerjakan berurutan, karena setiap langkah memakai hasil langkah sebelumnya.

Langkah #1: Tentukan Batas Sistem

Tulis satu kalimat tentang apa yang dikerjakan sistem dan apa yang tidak. Misalnya, "Sistem ini mencatat sirkulasi buku, tetapi tidak mengurus pengadaan buku baru." Kalimat ini mencegah diagram melebar ke fitur yang tidak pernah diminta.

Langkah #2: Daftar Semua Aktor

Ajukan empat pertanyaan pemandu. Siapa yang memakai sistem setiap hari? Siapa yang merawat atau mengonfigurasinya? Sistem lain apa yang bertukar data dengannya? Adakah proses yang berjalan otomatis pada jam tertentu? Setiap jawaban adalah kandidat aktor. Gabungkan kandidat yang sebenarnya memainkan peran yang sama.

Langkah #3: Cari Tujuan Tiap Aktor

Untuk setiap aktor, tanyakan apa yang ingin ia selesaikan lewat sistem ini. Pancingan yang berguna adalah empat operasi CRUD: data apa yang dibuat, dibaca, diubah, atau dihapus oleh aktor tersebut.

Saring hasilnya dengan uji satu kali duduk dari Alistair Cockburn, penulis Writing Effective Use Cases. Use case yang baik adalah tujuan yang bisa diselesaikan aktor dalam satu sesi, lalu ia pergi dengan hasil yang berarti. "Meminjam Buku" lolos. "Mengklik Tombol Simpan" terlalu kecil, sedangkan "Mengelola Perpustakaan" terlalu besar.

Langkah #4: Hubungkan dan Faktorkan Secukupnya

Tarik garis asosiasi dari setiap aktor ke use case miliknya. Setelah itu, cari langkah yang muncul di dua use case atau lebih, lalu jadikan include. Gunakan extend hanya untuk perilaku yang benar-benar bersyarat.

Satu tingkat include biasanya sudah cukup. Diagram yang dipenuhi panah putus-putus justru lebih sulit dibaca daripada diagram tanpa include sama sekali.

Langkah #5: Tulis Skenario dan Periksa Ulang

Tulis skenario minimal untuk use case yang paling penting, lalu cocokkan dengan diagramnya. Jika skenario menyebut use case lain, pastikan ada panah include. Jika ada use case tanpa aktor, tanyakan siapa yang memicunya.

Sebagai patokan ukuran, satu diagram yang nyaman dibaca berisi sekitar 5 sampai 15 use case. Panduan Visual Paradigm menyebut diagram dengan lebih dari 20 use case kemungkinan besar sudah salah pakai. Jika sistem Anda sebesar itu, pecah menjadi beberapa diagram per modul, misalnya modul sirkulasi dan modul keanggotaan.

Kesalahan Umum dan Soal Login di Use Case Diagram

Selain arah include dan extend yang terbalik, empat kesalahan berikut paling sering ditemukan:

1. Memperlakukan diagram seperti flowchart: Use case disusun berurutan dari atas ke bawah lalu dihubungkan panah, seolah-olah ada urutan langkah. Use case diagram tidak mengenal urutan. Urutan langkah tempatnya di skenario atau di activity diagram.
2. Use case dinamai kata benda: "Data Anggota" atau "Menu Laporan" bukan tujuan pengguna. Ganti menjadi "Mendaftarkan Anggota" atau "Mencetak Laporan Bulanan".
3. Memberi kepala panah pada asosiasi: Asosiasi aktor ke use case cukup garis polos. Kepala panah segitiga di sana justru terbaca sebagai generalisasi.
4. Terlalu banyak elips kecil: "Mengisi Nama", "Mengisi Alamat", dan "Menekan Simpan" seharusnya digabung menjadi satu use case "Mendaftarkan Anggota".

Lalu bagaimana dengan Login? Hampir semua contoh use case diagram di Indonesia menggambar Login sebagai use case, sering kali disertai panah include dari setiap use case lain. Jika diuji dengan uji satu kali duduk, Login tidak lolos. Tidak ada orang yang membuka aplikasi perpustakaan dengan tujuan login, lalu pergi dengan puas.

Secara konsep, Login lebih tepat ditulis sebagai prasyarat di skenario, seperti pada tabel Meminjam Buku di atas. Namun, jika dosen atau template dokumen proyek Anda mewajibkan Login muncul, gambarkan sekali saja sebagai use case yang terhubung ke aktor. Hindari menarik include dari belasan use case ke Login, karena panahnya akan menutupi informasi yang lebih penting.

Keterbatasan Use Case Diagram

Use case diagram bekerja baik untuk satu pertanyaan, yaitu siapa melakukan apa. Di luar itu, ada beberapa sisi lain yang perlu Anda pertimbangkan sebelum mengandalkannya:

1. Tidak menunjukkan urutan dan logika: Percabangan, perulangan, dan waktu tunggu tidak bisa digambar di sini. Untuk itu, gunakan activity diagram atau sequence diagram.
2. Tidak memuat kebutuhan nonfungsional: Syarat seperti "halaman tampil di bawah 2 detik" atau "data terenkripsi" tidak punya tempat di diagram. Tulis kebutuhan semacam ini di dokumen terpisah.
3. Mudah menjadi formalitas: Diagram yang digambar hanya untuk memenuhi bab laporan sering berhenti diperbarui setelah coding dimulai. Diagram yang usang lebih menyesatkan daripada tidak ada diagram.
4. Terlalu kasar untuk tim kecil yang bergerak cepat: Tim dengan siklus kerja satu atau dua minggu biasanya lebih nyaman memakai user story. Bentuknya kalimat kebutuhan pendek, misalnya "Sebagai anggota, saya ingin memesan buku."

Untuk aplikasi kecil yang dikerjakan satu orang, skenario tertulis sering kali sudah cukup.

Alat untuk Menggambar Use Case Diagram

Menggambar use case diagram tidak memerlukan aplikasi mahal. Beberapa pilihan yang umum dipakai:

1. draw.io (diagrams.net): Gratis dan sudah punya pustaka simbol UML. Pilihan paling praktis untuk membuat use case diagram secara online, dan tersedia juga versi desktop.
2. PlantUML: Diagram ditulis sebagai teks lalu dirender otomatis. Cocok jika dokumen Anda disimpan bersama kode di Git.
3. StarUML dan Visual Paradigm: Aplikasi khusus UML yang memeriksa aturan notasi, misalnya mencegah asosiasi antar-use case.
4. Lucidchart: Berbasis web dengan fitur kolaborasi, cocok untuk kerja kelompok.

Sebagai gambaran, potongan diagram perpustakaan di atas dapat ditulis dalam PlantUML seperti berikut:

@startuml
left to right direction
actor Anggota
actor Petugas
rectangle "Sistem Perpustakaan" {
  usecase "Meminjam Buku" as UC1
  usecase "Memeriksa Status Anggota" as UC2
  usecase "Mengembalikan Buku" as UC3
  usecase "Membayar Denda" as UC4
}
Anggota -- UC1
Petugas -- UC1
Anggota -- UC3
Petugas -- UC3
UC1 ..> UC2 : <<include>>
UC4 ..> UC3 : <<extend>>
@enduml

Perhatikan dua baris terakhir: arah ..> mengikuti aturan yang sama dengan diagram gambar. Hal yang sama berlaku untuk alat pembuat diagram berbasis AI: periksa selalu arah include dan extend-nya.

Pertanyaan Seputar Use Case Diagram

Apa beda use case diagram dan activity diagram?

Use case diagram menjawab siapa melakukan apa, tanpa urutan. Activity diagram menjawab bagaimana sebuah proses berjalan langkah demi langkah, lengkap dengan percabangan. Keduanya sering dipasangkan: satu use case di diagram dijabarkan menjadi satu activity diagram.

Apakah UML masih dipakai?

Masih, tetapi tidak selengkap dulu. UML 2.5 mengenal 14 jenis diagram, dan dalam praktik sehari-hari hanya sebagian kecil yang rutin digambar. Use case diagram, class diagram, dan sequence diagram adalah yang paling bertahan, terutama di dunia pendidikan dan proyek yang menuntut dokumentasi formal.

Kesimpulan

Use case diagram adalah denah tingkat tinggi sebuah sistem: siapa aktornya, apa tujuannya, dan di mana batasnya. Kekuatannya ada pada kesederhanaan, tetapi isi sebenarnya tetap berada di skenario tertulis. Gunakan diagram ini saat banyak pihak perlu menyepakati cakupan, dan jangan memaksakan urutan langkah ke dalamnya. Untuk relasi, ingat satu aturan: panah berangkat dari use case yang menyebut use case lain.

Semoga artikel ini membantu.