Diagram Use Case: Panduan Praktis

Sebuah diagram use case adalah diagram perilaku UML yang menunjukkan bagaimana pengguna eksternal atau sistem berinteraksi dengan suatu sistem. Diagram ini berfokus pada apa yang dilakukan sistem dari perspektif aktor, bukan pada detail implementasi internal.

Diagram use case sangat berguna selama analisis persyaratan karena memberikan pandangan tingkat tinggi tentang fungsionalitas dan ruang lingkup sistem.

1. Apa yang Ditunjukkan oleh Diagram Use Case

Diagram use case biasanya berisi:

• Batas sistem — mendefinisikan apa yang ada di dalam sistem yang dimodelkan.

• Aktor — pengguna eksternal, organisasi, perangkat, atau sistem yang berinteraksi dengannya.

• Use case — tujuan atau layanan yang disediakan oleh sistem.

• Asosiasi — tautan komunikasi antara aktor dan use case.

• Hubungan antar use case — seperti <<include>> dan <<extend>>.

• Generalisasi — pewarisan antara aktor atau use case.

Diagram use case biasanya tidak menampilkan:

• Langkah-langkah algoritma

• Tabel basis data

• Kelas program

• Alur kerja internal

• Tata letak antarmuka pengguna yang terperinci

• Urutan pesan seiring waktu

Rincian tersebut lebih baik direpresentasikan dengan diagram aktivitas, kelas, urutan, atau keadaan.

2. Konsep Utama

Batas Sistem

Batas sistem adalah persegi panjang yang mengelilingi kasus penggunaan yang termasuk dalam sistem.

Sebagai contoh, dalam sistem belanja online:

+--------------------------------------+
|        Sistem Belanja Online         |
|                                      |
|  (Jelajahi Produk)                   |
|  (Tempatkan Pesanan)                 |
|  (Lakukan Pembayaran)                |
+--------------------------------------+

Aktor tetap berada di luar batas karena mereka eksternal terhadap sistem.

Batas ini membantu memperjelas ruang lingkupdari sistem. Jika suatu kemampuan berada di luar batas, maka kemampuan tersebut tidak diimplementasikan oleh sistem yang dimodelkan.

Aktor

Sebuah aktoradalah apa pun yang eksternal yang berinteraksi dengan sistem untuk mencapai tujuan.

Aktor dapat mencakup:

• Pengguna manusia

• Aplikasi eksternal

• Perangkat keras

• Organisasi lain

• Waktu atau peristiwa terjadwal, ketika dimodelkan sebagai pemicu eksternal

Contoh:

• Pelanggan

• Pustakawan

• Gerbang Pembayaran

• Administrator

• Layanan Email

Sebuah aktor mewakili sebuah peran, tidak harus merupakan orang tertentu. Misalnya, “Pelanggan” biasanya lebih baik daripada “Alex.”

Aktor dapat berupa:

• Aktor utama— memulai interaksi untuk mencapai tujuan.

• Aktor pendukung— menyediakan layanan bagi sistem.

Sebagai contoh, seorang pelanggan dapat memulai “Tempatkan Pesanan,” sementara gerbang pembayaran mendukung “Proses Pembayaran.”

Kasus Penggunaan

Sebuah kasus penggunaanmewakili tujuan atau layanan yang bermakna yang disediakan oleh sistem.

Nama kasus penggunaan yang baik biasanya mengikuti bentuk ini:

Kata kerja + objek

Contoh:

• Daftarkan Akun

• Cari Katalog

• Kirimkan Aplikasi

• Hasilkan Laporan

• Batalkan Reservasi

• Proses Pembayaran

Sebuah kasus penggunaan harus menggambarkan hasil yang dapat diamati, bukan langkah implementasi internal.

Lebih utamakan:

Tempatkan Pesanan

daripada:

Validasi Objek Pesanan

Yang kedua menggambarkan operasi internal, bukan tujuan pengguna.

Asosiasi

Sebuah asosiasi adalah tautan komunikasi antara aktor dan kasus penggunaan.

Ini menunjukkan bahwa aktor berpartisipasi dalam atau memulai kasus penggunaan tersebut.

Pelanggan ---- (Tempatkan Pesanan)

Asosiasi biasanya tidak menunjukkan urutan, alur kontrol, atau arah. Jika urutan interaksi penting, gunakan diagram urutan atau diagram aktivitas.

3. Hubungan Antar Kasus Penggunaan

<<include>>

Gunakan <<include>> ketika satu kasus penggunaan selalu menggunakan kasus penggunaan lainnya.

Sebagai contoh, penempatan pesanan mungkin selalu memerlukan autentikasi:

(Tempatkan Pesanan) ..> (Autentikasi Pelanggan) : <<include>>

Kasus penggunaan dasar bergantung pada kasus penggunaan yang disertakan.

Gunakan include ketika:

• Perilaku tersebut wajib.

• Perilaku tersebut digunakan kembali oleh beberapa kasus penggunaan.

• Mengeluarkan perilaku tersebut meningkatkan kejelasan.

Contoh:

(Tarik Tunai) ..> (Autentikasi Kartu) : <<include>>
(Cek Saldo) ..> (Autentikasi Kartu) : <<include>>

Kedua kasus penggunaan selalu memerlukan autentikasi kartu.

<<extend>>

Gunakan <<extend>> ketika perilaku tambahan bersifat opsional atau disisipkan secara bersyarat ke dalam kasus penggunaan dasar.

(Terapkan Diskon) ..> (Tempatkan Pesanan) : <<extend>>

Perilaku diskon terjadi hanya ketika kondisi kelayakan terpenuhi.

Gunakan extend ketika:

• Perilaku tersebut bersifat opsional.

• Hal ini hanya terjadi dalam kondisi tertentu.

• Kasus penggunaan dasar sudah lengkap tanpa hal tersebut.

Contoh:

• “Tambahkan Pembungkus Hadiah” memperluas “Tempatkan Pesanan.”

• “Minta Pengembalian Dana” memperluas “Batalkan Langganan.”

• “Kirim Email Promosi” memperluas “Selesaikan Pendaftaran.”

Panah mengarah dari kasus penggunaan yang memperluas ke kasus penggunaan dasar.

Generalisasi

Generalisasi merepresentasikan hubungan “adalah-sebuah” antara aktor atau kasus penggunaan.

Sebagai contoh:

Pelanggan Premium --|> Pelanggan

Pelanggan premium adalah jenis pelanggan dan mewarisi interaksi pelanggan.

Generalisasi aktor dapat berguna ketika beberapa aktor berbagi perilaku yang sama:

Administrator --|> Karyawan
Pustakawan --|> Karyawan

Gunakan generalisasi secara hemat. Jika hubungannya hanyalah “menggunakan” atau “berpartisipasi dalam,” asosiasi biasanya lebih tepat.

4. Aktor Utama dan Pendukung

Pertimbangkan skenario pembayaran online:

• The Pelanggan adalah aktor utama karena mereka memulai pembelian.

• The Gerbang Pembayaran adalah aktor pendukung karena memproses pembayaran atas permintaan sistem.

Model sederhana mungkin terlihat seperti ini:

Pelanggan ---- (Tempatkan Pesanan)
(Tempatkan Pesanan) ---- Gerbang Pembayaran

Pembedaan ini berguna karena memperjelas siapa yang mendapat manfaat dari kasus penggunaan dan sistem eksternal mana yang terlibat.

5. Cara Mengidentifikasi Kasus Penggunaan

Cara praktis untuk menemukan kasus penggunaan adalah dengan bertanya:

1. Siapa yang menggunakan sistem?

2. Tujuan apa yang ingin dicapai oleh setiap aktor?

3. Layanan apa yang disediakan oleh sistem?

4. Peristiwa apa yang memicu perilaku sistem?

5. Sistem eksternal apa yang harus berinteraksi dengan sistem ini?

6. Perilaku apa yang selalu diperlukan?

7. Perilaku apa yang bersifat opsional atau bersyarat?

Untuk setiap aktor, daftarkan tujuan mereka:

Tujuan harus bermakna bagi aktor. Hindari mengubah setiap operasi kecil sistem menjadi kasus penggunaan.

6. Pedoman Penamaan

Gunakan nama yang jelas dan berorientasi pada tujuan.

Contoh yang baik:

• Buat Akun

• Perbarui Profil

• Klaimkan

• Lacak Pengiriman

• Setujui Permintaan

• Buat Faktur

Hindari nama yang samar:

• Pemrosesan Sistem

• Kelola Data

• Fungsi Pengguna

• Jalankan Operasi

Hindari detail teknis yang berlebihan:

• Eksekusi Kueri SQL

• Panggil Endpoint REST

• Inisialisasi PaymentService

Ini mungkin merupakan langkah implementasi yang valid, tetapi biasanya tidak berguna sebagai kasus penggunaan tingkat tinggi.

7. Contoh: Sistem Manajemen Perpustakaan

Misalkan sistem perpustakaan mendukung:

• Anggota mencari buku

• Anggota meminjam buku

• Anggota mengembalikan buku

• Pustakawan mengelola katalog

• Notifikasi keterlambatan

• Pemrosesan pembayaran denda

Aktor yang mungkin:

• Anggota

• Pustakawan

• Layanan Notifikasi

• Layanan Pembayaran

Kasus penggunaan yang mungkin:

• Cari Katalog

• Pinjam Buku

• Kembalikan Buku

• Hitung Denda

• Bayar Denda

• Kelola Katalog

• Kirim Pemberitahuan Terlambat

Hubungan:

• Meminjam Buku mencakup Pengecekan Keanggotaan.

• Meminjam Buku mencakup Pengecekan Ketersediaan Buku.

• Mengembalikan Buku mencakup Perhitungan Denda.

• Bayar Denda berinteraksi dengan Layanan Pembayaran.

• Kirim Pemberitahuan Terlambat berinteraksi dengan Layanan Pemberitahuan.

8. Contoh PlantUML

Kode PlantUML berikut membuat diagram kasus penggunaan untuk sistem perpustakaan:

@startuml
arah kiri ke kanan

judul Sistem Manajemen Perpustakaan - Diagram Kasus Penggunaan

aktor Anggota
aktor Pustakawan
aktor "Layanan Pemberitahuan" sebagai Pemberitahuan
aktor "Layanan Pembayaran" sebagai Pembayaran

persegi panjang "Sistem Manajemen Perpustakaan" {

  usecase "Cari Katalog" sebagai UC_Cari
  usecase "Pinjam Buku" sebagai UC_Pinjam
  usecase "Kembalikan Buku" sebagai UC_Kembalikan
  usecase "Periksa Keanggotaan" sebagai UC_PeriksaAnggota
  usecase "Periksa Ketersediaan Buku" sebagai UC_PeriksaKetersediaan
  usecase "Hitung Denda" sebagai UC_HitungDenda
  usecase "Bayar Denda" sebagai UC_BayarDenda
  usecase "Kelola Katalog" sebagai UC_KelolaKatalog
  usecase "Kirim Pemberitahuan Terlambat" sebagai UC_Pemberitahuan
}

Anggota --> UC_Cari
Anggota --> UC_Pinjam
Anggota --> UC_Kembalikan
Anggota --> UC_BayarDenda

Pustakawan --> UC_KelolaKatalog
Pustakawan --> UC_Pinjam
Pustakawan --> UC_Kembalikan

Pembayaran --> UC_BayarDenda
Pemberitahuan --> UC_Pemberitahuan

UC_Pinjam ..> UC_PeriksaAnggota : <<include>>
UC_Pinjam ..> UC_PeriksaKetersediaan : <<include>>
UC_Kembalikan ..> UC_HitungDenda : <<include>>

UC_Pemberitahuan ..> UC_Kembalikan : <<extend>>

@enduml

9. Penjelasan Contoh

Aktor

aktor Anggota
aktor Pustakawan
aktor "Layanan Pemberitahuan" sebagai Pemberitahuan
aktor "Layanan Pembayaran" sebagai Pembayaran

Diagram ini memodelkan dua aktor manusia dan dua layanan eksternal.

Alias seperti sebagai Pemberitahuanmembuat nama yang lebih panjang lebih mudah untuk dirujuk nanti.

Batas Sistem

kotak "Sistem Manajemen Perpustakaan" {
    ...
}

Kotak tersebut mendefinisikan ruang lingkup sistem. Use case di dalam kotak disediakan oleh sistem perpustakaan.

Asosiasi Aktor

Member --> UC_Pencarian
Member --> UC_Peminjaman

Asosiasi ini menunjukkan bahwa anggota dapat mencari katalog dan meminjam buku.

Arah panah biasanya tidak penting secara semantik dalam diagram use case dasar. Arah ini terutama digunakan untuk membuat diagram lebih mudah dibaca.

Relasi Include

UC_Peminjaman ..> UC_PengecekanAnggota : <<include>>
UC_Peminjaman ..> UC_PengecekanKetersediaan : <<include>>

Meminjam buku selalu memerlukan pengecekan keanggotaan dan ketersediaan, sehingga ini dimodelkan sebagai use case yang di-include.

Relasi Extend

UC_Pemberitahuan ..> UC_Pengembalian : <<extend>>

Ini menunjukkan bahwa perilaku pemberitahuan buku terlambat adalah perilaku tambahan yang terkait dengan pengembalian buku.

Namun, dalam model persyaratan yang sebenarnya, desain yang lebih alami mungkin adalah mengasosiasikan “Kirim Pemberitahuan Terlambat” dengan proses terjadwal atau aktor seperti “Penjadwal Perpustakaan.” Hubungan terbaik tergantung pada aturan bisnis yang sebenarnya.

10. Spesifikasi Use Case yang Lebih Detail

Diagram memberikan gambaran umum, tetapi setiap use case penting biasanya harus memiliki spesifikasi tekstual.

Use Case: Pinjam Buku

Diagram kasus penggunaan tidak boleh mencoba memuat semua detail ini. Diagram menyediakan peta; spesifikasi menyediakan perilaku.

11. Referensi Sintaks PlantUML

Mendeklarasikan Aktor

actor Customer
actor "Payment Gateway" as Gateway

Mendeklarasikan Kasus Penggunaan

usecase "Place Order" as PlaceOrder
usecase "Process Payment" as ProcessPayment

Membuat Batas Sistem

rectangle "Toko Online" {
    usecase "Jelajahi Produk" sebagai Browse
    usecase "Tempatkan Pesanan" sebagai Order
}

Menghubungkan Aktor dan Kasus Penggunaan

Pelanggan --> Browse
Pelanggan --> Order

Termasuk

Pesanan ..> ProsesPembayaran : <<termasuk>>

Memperluas

TerapkanKupon ..> Pesanan : <<memperluas>>

Generalisasi Aktor

PelangganPremium --|> Pelanggan

Pengelompokan Paket

Paket dapat mengelompokkan kasus penggunaan yang terkait secara visual:

rectangle "Sistem Perbankan" {
  package "Manajemen Akun" {
    usecase "Buka Akun" sebagai OpenAccount
    usecase "Tutup Akun" sebagai CloseAccount
  }

  package "Pembayaran" {
    usecase "Transfer Dana" sebagai TransferFunds
    usecase "Bayar Tagihan" sebagai PayBill
  }
}

Catatan

note kanan dari PlaceOrder
  Pelanggan harus terautentikasi
  sebelum melakukan pemesanan.
end note

12. Meningkatkan Tata Letak Diagram

PlantUML secara otomatis menyusun diagram, namun beberapa teknik dapat meningkatkan keterbacaan.

Kontrol Arah

arah dari kiri ke kanan

Ini sering berguna ketika aktor harus muncul di sisi dan kasus penggunaan di tengah.

Arah umum lainnya meliputi:

arah dari atas ke bawah

Gunakan Alias

Alih-alih mengulang nama panjang:

usecase "Verifikasi Identitas Pelanggan" sebagai VerifyIdentity

Kemudian referensi:

RegisterAccount ..> VerifyIdentity : <<include>>

Kelompokkan Use Case yang Terkait

Gunakan paket atau persegi panjang bersarang untuk memisahkan area fungsional:

package "Pengelolaan Pesanan" {
    usecase "Buat Pesanan" as CreateOrder
    usecase "Batalkan Pesanan" as CancelOrder
}

Hindari Perpotongan yang Berlebihan

Diagram menjadi sulit dibaca ketika terlalu banyak garis saling berpotongan. Anda dapat meningkatkannya dengan:

• Menempatkan aktor yang terkait di dekat use case mereka

• Mengelompokkan use case ke dalam paket

• Memecah satu diagram besar menjadi beberapa diagram yang lebih kecil

• Menggunakan alias untuk referensi yang jelas

• Menghindari hubungan yang tidak perlu

13. Kesalahan Umum

Memodelkan Fungsi Internal sebagai Use Case

Ini biasanya terlalu teknis:

Validasi Koneksi Database
Serialisasi Permintaan
Panggil API Pembayaran

Lebih utamakan tujuan yang bermakna secara eksternal:

Lakukan Pembayaran
Kirimkan Aplikasi
Hasilkan Laporan

Memperlakukan Setiap Aktor sebagai Orang

Sistem eksternal dan perangkat juga dapat menjadi aktor:

• Gerbang Pembayaran

• Penyedia Identitas

• Sistem Gudang

• Pemindai Barcode

• Layanan Notifikasi

Menggunakan includeuntuk Perilaku Opsional

Jika perilaku bersifat opsional, gunakan perluas daripada sertakan.

Salah:

Tempatkan Pesanan ..> Terapkan Kupon : <<sertakan>>

Jika penerapan kupon bersifat opsional, gunakan:

Terapkan Kupon ..> Tempatkan Pesanan : <<perluas>>

Menggunakan perluas untuk Perilaku Wajib

Jika suatu perilaku selalu terjadi, umumnya harus dimodelkan dengan sertakan.

Tempatkan Pesanan ..> Autentikasi Pelanggan : <<sertakan>>

Menghubungkan Use Case Langsung Tanpa Makna

Garis antara dua use case harus merepresentasikan hubungan UML yang valid. Hindari koneksi sewenang-wenang yang hanya menyiratkan bahwa use case tersebut terkait dalam beberapa cara.

Membuat Satu Diagram Raksasa

Diagram use case harus mengkomunikasikan dengan jelas pada tingkat tinggi. Jika berisi puluhan aktor dan use case, buat beberapa diagram yang diorganisir berdasarkan subsistem atau area bisnis.

Menunjukkan Urutan

Diagram use case tidak menunjukkan bahwa satu use case terjadi sebelum yang lain. Untuk urutan, gunakan diagram urutan atau diagram aktivitas.

14. Kapan Menggunakan Diagram UML Lainnya

Diagram use case paling cocok untuk cakupan sistem dan tujuan pengguna. Gabungkan dengan diagram lain ketika detail lebih diperlukan:

15. Proses Pemodelan yang Direkomendasikan

1. Tentukan batas sistem.

2. Identifikasi semua aktor eksternal.

3. Identifikasi tujuan setiap aktor.

4. Ubah tujuan-tujuan tersebut menjadi kasus penggunaan.

5. Hubungkan aktor dengan kasus penggunaan yang mereka ikuti.

6. Identifikasi perilaku wajib yang dapat digunakan kembali dan modelkan dengan <<include>>.

7. Identifikasi perilaku opsional atau bersyarat dan modelkan dengan <<extend>>.

8. Tambahkan generalisasi hanya di mana terdapat hubungan “adalah-a” yang nyata.

9. Tinjau diagram bersama para pemangku kepentingan.

10. Tambahkan spesifikasi tekstual untuk kasus penggunaan penting.

11. Pisahkan diagram jika menjadi padat.

16. Templat PlantUML Ringkas

Anda dapat menggunakan ini sebagai titik awal:

@startuml
arah kiri ke kanan

judul Diagram Kasus Penggunaan Sistem

aktor User
aktor "Sistem Eksternal" sebagai ExternalSystem

persegi panjang "Nama Sistem" {
  usecase "Tujuan Utama Pengguna" sebagai MainGoal
  usecase "Perilaku Bersama yang Diperlukan" sebagai RequiredBehavior
  usecase "Perilaku Opsional" sebagai OptionalBehavior
}

User --> MainGoal
ExternalSystem --> MainGoal

MainGoal ..> RequiredBehavior : <<include>>
OptionalBehavior ..> MainGoal : <<extend>>

@enduml

Prinsip utamanya adalah memodelkan tujuan yang terlihat dari luar, bukan detail implementasi internal. Diagram kasus penggunaan yang kuat membuat batas sistem, aktor, kemampuan, dan ketergantungan penting langsung mudah dipahami.

Referensi

This post is also available in Deutsch, English, Español, فارسی and Français.