Menguasai Pendekatan Berbasis Use Case: Panduan Komprehensif untuk Persyaratan dan Desain

Pendahuluan

Dalam rekayasa perangkat lunak, menjembatani kesenjangan antara kebutuhan pemangku kepentingan dan implementasi teknis sering kali merupakan fase pengembangan yang paling menantang. Pendekatan Pendekatan Berbasis Use Case menawarkan metodologi terstruktur dan iteratif untuk menyelesaikan masalah ini. Dengan berfokus pada bagaimana pengguna berinteraksi dengan sistemuntuk mencapai tujuan tertentu, pendekatan ini memastikan bahwa persyaratan jelas, dapat diuji, dan secara langsung dapat ditelusuri ke artefak desain.

Panduan ini memberikan panduan lengkap mengenai Pendekatan Berbasis Use Case, bergerak dari persyaratan tingkat tinggi hingga desain terperinci. Kami akan menggunakan satu contoh berjalan—sebuah Sistem Manajemen Pesanan Online—untuk mengilustrasikan setiap tahap, memastikan konsistensi dan kejelasan sepanjang proses.

---

Gambaran Umum Metodologi

Pendekatan Berbasis Use Case mengikuti perkembangan alami dari atas ke bawah. Setiap tahap menyempurnakan tahap sebelumnya, menambahkan presisi dan mengurangi ambiguitas.

Mengapa Urutan Ini Penting?

1. Diagram Use Case: Menyediakan inventaris lengkap kemampuan dan ruang lingkup. Diagram ini cepat untuk dipindai dan ideal untuk kesepakatan pemangku kepentingan mengenai apa yang dilakukan oleh sistem.
2. Deskripsi Use Case: Menghilangkan ambiguitas dengan menetapkan kondisi awal, kondisi akhir, aktor, dan prioritas. Deskripsi ini “membekukan” kontrak perilaku.
3. Alur Kejadian: Mengubah kontrak menjadi langkah-langkah konkret yang dapat diuji. Ini berfungsi sebagai bahan baku untuk kasus uji dan desain teknis.
4. Aktivitas/Diagram Urutan:Bertindak sebagai jembatan menuju kode. Ia mengidentifikasi objek yang berpartisipasi, tanggung jawab mereka, pertukaran pesan, dan aturan percabangan yang tepat.

---

Tahap 1: Diagram Use Case (Persyaratan)

Diagram Use Case menangkapsiapa yang berinteraksi dengan sistem (aktor) danapa yang dapat mereka lakukan (use case), beserta hubungan di antara mereka.

Konsep Utama

• Aktor Utama: Memulai use case (diletakkan di sebelah kiri).
• Aktor Sekunder: Mendukung sistem atau menerima notifikasi (diletakkan di sebelah kanan).
• Batas Sistem: Persegi panjang yang mendefinisikan ruang lingkup sistem.
• <<include>>: Mewakili perilaku bersama yang wajib. Jika Use Case A menyertakan Use Case B, B harus terjadi agar A dapat selesai.
• <<extend>>: Mewakili perilaku opsional. Use Case B memperluas Use Case A hanya dalam kondisi tertentu.

Contoh: Sistem Manajemen Pesanan Online

@startuml
skinparam linetype ortho
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam vpDiagramType UseCaseDiagram
skinparam actor {
  BackgroundColor #E8F5E9
}
skinparam usecase {
  BackgroundColor #BBDEFB
  BorderColor #1976D2
  ArrowColor #1976D2
}

left to right direction
actor "Customern(Primary)" as cust
actor "Warehousen(Secondary)" as wh

rectangle "Order Management System" {
  usecase "Place Order" as UC1
  usecase "Cancel Order" as UC2
  usecase "Track Order" as UC3
  usecase "Login" as UC4
  usecase "Print Invoice" as UC5
}

cust -[#black]- UC1
cust -[#black]- UC2
cust -[#black]- UC3
UC1 -[#crimson]- wh
UC2 -[#crimson]- wh
UC1 ...> UC4 : <<include>>
UC2 ...> UC4 : <<include>>
UC3 ...> UC4 : <<include>>
UC1 <... UC5 : <<extend>>
@enduml

Analisis Diagram:

• DiagramPelanggan memulai pemesanan, pembatalan, dan pelacakan pesanan.
• GudangGudang terlibat dalam pemesanan dan pembatalan pesanan (kemungkinan untuk pembaruan inventaris).
• Masuk termasuk dalam Pemesanan, Pembatalan, dan Pelacakan Pesanan, yang berarti autentikasi wajib untuk tindakan-tindakan ini.
• Cetak Faktur merupakan perluasan dari Pemesanan Pesanan, yang berarti ini adalah langkah opsional yang dapat terjadi setelah pesanan dibuat.

---

Tahap 2: Deskripsi Kasus Penggunaan (Spesifikasi)

Diagram menamai kasus penggunaan tetapi kurang detail. Tabel Deskripsi Kasus Penggunaanmenentukan kontrak yang tepat untuk setiap kasus penggunaan.

Contoh: UC-01 Pemesanan Pesanan

Kolom	Nilai
ID Kasus Penggunaan	UC-01
Nama	Pemesanan Pesanan
Aktor Utama	Pelanggan
Aktor Pendukung	Gudang
Prasyarat	Pelanggan telah masuk; keranjang berisi setidaknya satu item; item tersedia dalam stok
Pasca-kondisi (Berhasil)	Pesanan disimpan dengan status dikonfirmasi; pembayaran berhasil diambil; nomor pelacakan diterbitkan
Pasca-kondisi (Kegagalan)	Pesanan tidak dibuat; keranjang tidak berubah; pengguna diberi tahu alasannya
Alur Utama	→ Lihat Tahap 3
Alur Alternatif / Pengecualian	Stok tidak mencukupi; pembayaran ditolak
Prioritas	Tinggi

Tujuan:Tahap ini mendefinisikan apa yang harus benarsebelumkasus penggunaan berjalan (pra-kondisi) dan apa yang harus berlakusetelah(pasca-kondisi), menetapkan kriteria keberhasilan/kegagalan yang jelas.

---

Tahap 3: Alur Peristiwa (Skenario)

Ini adalah jantung perilaku dari pendekatan tersebut. Kasus penggunaan “Tempatkan Pesanan” berkembang menjadi sebuahnaskah skenario—sebuah urutan langkah bernomor yang ditulis sebelum diagram desain terperinci apa pun ada.

Skenario Keberhasilan Utama (Alur Dasar)

1. Pelanggan masuk ke sistem.
2. Pelanggan menyerahkan keranjang dengan item yang dipilih.
3. Sistem memvalidasi isi keranjang dan ketersediaan stok.
4. Sistem membebankan total melalui gerbang pembayaran.
5. Sistem menyimpan pesanan dengan statusdikonfirmasi.
6. Sistem mengembalikan konfirmasi pesanan dengan ID pesanan.
7. Sistem memberi tahu Gudang untuk mengambil, mengemas, dan mengirim.

Skenario Alternatif

• 3a. Stok Tidak Memadai: Sistem melaporkan barang yang tidak tersedia dan kembali ke keranjang.
• 4a. Pembayaran Ditolak: Sistem memberi tahu pelanggan dan tidak membuat pesanan.

Konvensi Utama: Setiap skenario dipetakan langsung ke satu langkah dalam deskripsi. Alur-alur ini menjadi dasar untuk diagram Aktivitas dan Urutan pada tahap berikutnya.

---

Tahap 4: Desain Rinci (Diagram Urutan & Aktivitas)

Pada tahap ini, Anda memilih notasi berdasarkan aspek sistem yang ingin Anda tekankan.

• Diagram Urutan:Menekankangaris kehidupan, urutan pesan, dan tanggung jawab antar objek. Ideal untuk menemukan kelas dan metode.
• Diagram Aktivitas:Menekankanalur kontrol dan keputusan melalui jalur/pihak. Ideal untuk mendokumentasikan proses dan tanggung jawab peran.

4A. Diagram Urutan (Perspektif Interaksi)

@startuml
title Diagram Urutan Pemesanan
skinparam linetype ortho
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam sequenceParticipant underline
skinparam vpDiagramType InteractionDiagram
skinparam {
  FontSize 14
  ArrowColor #4A4A4A
  ArrowFontColor #4A4A4A
  BackgroundColor #FFFFFF
  BorderColor #DEDEDE
  FontColor #333333
  Participant {
    BorderColor #0077B6
    BackgroundColor #F0F8FF
    FontColor #005691
  }
  Actor {
    BorderColor #6A057F
    BackgroundColor #F5EEF8
    FontColor #510363
  }
  Sequence {
    ArrowThickness 2
    LifeLineBorderColor #444444
    LifeLineBackgroundColor #F7F7F7
    BoxBorderColor #AAAAAA
    BoxBackgroundColor #FFFFFF
    BoxFontColor #333333
  }
}

actor "Pelanggan" as USR
participant "Layanan Pesanan" as OS
participant "Gerbang Pembayaran" as PG
database "DB Pesanan" as DB

activate USR
USR -> OS : submitOrder(items)
activate OS
alt Validasi & Pembayaran
  OS -> OS : validateCart(items)
  OS -> PG : charge(total)
  activate PG
  PG --> OS : paymentOk
  deactivate PG
  OS -> DB : saveOrder(status=confirmed)
  activate DB
  DB --> OS : orderId
  deactivate DB
  OS --> USR : orderConfirmation(orderId)
else Stok Tidak Memadai
  OS -> DB : checkStock(items)
  activate DB
  DB --> OS : stockUnavailable
  deactivate DB
  OS --> USR : error("Stok habis")
else Pembayaran Gagal
  PG --> OS : paymentFailed
  OS --> USR : error("Pembayaran ditolak")
end
deactivate OS
@enduml

Konsep Utama:

• Panggilan Sinkron: Panah padat (->).
• Balasan: Panah putus-putus (-->).
• Bilah Aktivasi: Menampilkan masa hidup pemrosesan suatu objek.
• alt Fragmen Gabungan: Membungkus tiga skenario (Berhasil, Stok Tidak Cukup, Kegagalan Pembayaran), secara langsung mencerminkan Alur Kejadian dari Tahap 3.

4B. Diagram Aktivitas (Perspektif Proses)

@startuml
<style>
  element { MaximumWidth 150 }
  start   { Backgroundcolor #00695C }
  stop    { Backgroundcolor #C2185B }
  activity{ Backgroundcolor #81D4FA; MaximumWidth 150 }
  diamond { Backgroundcolor #FFB74D; MaximumWidth 80 }
  arrow   { LineColor #424242; Fontcolor #000000 }
  swimlane{ Fontcolor #000000; FontSize 14 }
</style>
title Diagram Aktivitas Pemesanan

|#F0F8FF|Pelanggan|
start
:Login;
:Jelajahi Katalog;
:Tambahkan Item ke Keranjang;

if (Siap Checkout?) then (ya)
  :Lanjutkan ke Checkout;
else (tidak)
  :Kembali ke Penjelajahan;
  stop
endif

|#E8F5E9|Sistem|
:Validasi Keranjang;
:Proses Pembayaran;

if (Pembayaran Disetujui?) then (ya)
  :Buat Pesanan (status=terkonfirmasi);
else (tidak)
  :Beritahu Kegagalan Pembayaran;
endif

|#F5EEF8|Gudang|
if (Pembayaran Disetujui?) then (ya)
  :Ambil & Kemas Item;
  :Kirim Pesanan;
  :Kirim Nomor Pelacakan;
  stop
else (tidak)
  stop
endif
@enduml

Konsep Kunci:

• Jalur Renang (Swimlanes): Tugaskan setiap tindakan kepada pihak yang bertanggung jawab (Pelanggan, Sistem, Gudang).
• Node Keputusan: if/then/else/endif struktur mengkodekan skenario percabangan.
• Penanda Mulai/Selesai: Menandai awal dan akhir proses.

---

Poin Penting PlantUML

Untuk memodelkan pendekatan ini secara efektif menggunakan PlantUML, ingatlah esensi sintaks berikut:

1. Diagram Kasus Penggunaan:
   • Gunakan usecase untuk fungsi.
   • Gunakan ...> untuk <<include>> hubungan.
   • Gunakan <... untuk <<extend>> hubungan.
   • Gunakan rectangle "Nama Sistem" {} untuk mendefinisikan batas sistem.
2. Diagram Urutan:
   • Tentukan peserta menggunakan aktor, peserta, atau basis data.
   • Gunakan -> untuk panggilan sinkron dan --> untuk balasan.
   • Gunakan aktifkan dan nonaktifkan untuk menampilkan rentang hidup objek.
   • Gunakan alt, else, dan end untuk fragmen gabungan yang merepresentasikan alur alternatif.
3. Diagram Aktivitas:
   • Gunakan |#color|LaneName| untuk mendefinisikan jalur renang (swimlanes).
   • Gunakan :action; untuk aktivitas.
   • Gunakan if/else/endif untuk node keputusan.
   • Gunakan start dan stop untuk menandai batas proses.

---

Kesimpulan

Pendekatan Berbasis Use Case lebih dari sekadar teknik dokumentasi; ini adalah kerangka kerja untuk penyempurnaan bertahap. Dengan memulai dari gambaran besar (Diagram Use Case) dan menelusuri lebih dalam ke perilaku spesifik (Alur Peristiwa) dan interaksi teknis (Sequence/Diagram Aktivitas), tim dapat memastikan bahwa setiap baris kode dapat ditelusuri kembali ke kebutuhan pengguna yang telah diverifikasi.

Metode ini mengurangi risiko miskomunikasi antara pemangku kepentingan dan pengembang, memfasilitasi pengujian yang lebih mudah melalui skenario yang jelas, dan menghasilkan desain sistem yang kuat dan berpusat pada pengguna. Baik Anda membangun platform e-commerce sederhana maupun sistem perusahaan yang kompleks, mengikuti progresi terstruktur ini akan menghasilkan persyaratan yang lebih jelas dan perangkat lunak yang lebih berkualitas.