Studi Kasus: Diagram Use Case untuk Platform Pengiriman Makanan

Pemodelan Kebutuhan Dunia Nyata dengan UML – Panduan Praktis

1. Pendahuluan

Dalam pengembangan perangkat lunak modern, diagram use casemerupakan alat dasar untuk menangkap persyaratan fungsional dari perspektif pengguna. Studi kasus ini menyajikan analisis mendetail tentang sebuah diagram use case yang realistisuntuk sebuah Pengiriman Makanan, menggunakan sintaks PlantUMLsebagai bahasa pemodelan. Tujuannya adalah untuk tidak hanya mendemonstrasikan apaelemen yang digunakan dalam diagram, tetapi juga mengapaelemen-elemen tersebut dipilih — dengan menyoroti keputusan pemodelan yang praktis, konvensi, dan jebakan umum.

Studi kasus ini bermanfaat bagi pemula yang mempelajari UMLdan praktisi yang menyempurnakan praktik pemodelan mereka. Studi ini menguraikan setiap elemen diagram, menjelaskan tujuannya, dan membahas implikasi dunia nyata.

2. Gambaran Sistem

Platform Pengiriman Makanan adalah pasar digital yang menghubungkan:

• Pelanggan(individu yang memesan makanan),
• Restoran(penyedia makanan),
• Pengemudi(personel pengiriman),
• Gerbang Pembayaran Eksternal(sistem pihak ketiga yang menangani transaksi).

Platform ini memungkinkan pengguna untuk menjelajahi restoran, memesan makanan, melacak pengiriman, mengelola pembayaran, dan menerapkan promosi. Sistem ini terintegrasi dengan layanan eksternal seperti pemroses pembayaran dan tidak menangani logika pembayaran secara internal.

Kode PlantUML:

@startuml
skinparam monochrome true
skinparam shadowing false

left to right direction

' Semua aktor didefinisikan di luar persegi panjang
actor Customer
actor "Pelanggan Terdaftar" as RegCustomer
actor "Staf Restoran" as Restaurant
actor Driver
actor "Pemroses Pembayaran" as PaymentGW

rectangle "Platform Pengiriman Makanan" {

(Jelajahi Restoran)
(Pesan Makanan)
(Lacak Pesanan)
(Kelola Menu)
(Terima / Siapkan Pesanan)
(Kirim Pesanan)
(Proses Pembayaran)
(Terbitkan Pengembalian Dana)
(Terapkan Kode Promo)
(Gunakan Dompet)
(Pembayaran Kartu)
(Pembayaran Dompet Digital)

' Asosiasi – panah melintasi batas
Customer --> (Jelajahi Restoran)
RegCustomer --> (Pesan Makanan)
RegCustomer --> (Lacak Pesanan)

Restaurant --> (Kelola Menu)
Restaurant --> (Terima / Siapkan Pesanan)

Driver --> (Kirim Pesanan)

PaymentGW --> (Proses Pembayaran)
PaymentGW --> (Terbitkan Pengembalian Dana)

' include
(Pesan Makanan) ..> (Proses Pembayaran) : <<include>>

' extend
(Pesan Makanan) <.. (Terapkan Kode Promo) : <<extend>>
(Proses Pembayaran) <.. (Gunakan Dompet) : <<extend>>

' generalisasi
(Proses Pembayaran) <|-- (Pembayaran Kartu)
(Proses Pembayaran) <|-- (Pembayaran Dompet Digital)
}

' Generalisasi aktor (juga di luar)
Customer <|-- RegCustomer

note right of PaymentGW
Gerbang pembayaran eksternal
(Stripe, PayPal, Adyen, ...)
end note

note bottom of (Terapkan Kode Promo)
Opsional – hanya ketika kode yang valid dimasukkan
end note

@enduml

✅ Wawasan Utama: Diagram ini berfokus pada interaksi eksternal — diagram ini menunjukkan apa yang dilakukan sistem untuk pengguna dan sistemnya, bukan bagaimana sistem tersebut diimplementasikan.

3. Elemen Diagram: Penjelasan Mendalam dengan Makna Praktis

Di bawah ini adalah uraian komprehensif dari setiap elemen UML yang digunakan dalam diagram, bersama dengan interpretasi dunia nyata dan alasan pemodelan.

4. Keputusan Pemodelan Utama & Rasionalnya

✅ Mengapa aktor berada di luar batas sistem

• Praktik Terbaik: Aktor mewakili peran di luar sistem.
• Mengapa hal ini penting: Mencegah kebingungan antara komponen sistem dan entitas eksternal.
• Contoh: Pengemudi bukan modul dari platform — mereka adalah peran pihak ketiga yang berinteraksi dengannya.

📌 Tips Pro: Jika semua aktor berada di dalam batas, itu akan menyiratkan bahwa sistem mencakup mereka — yang menyesatkan.

✅ Mengapa menggunakan Customer <|-- RegCustomer daripada menduplikasi tautan

• Tanpa generalisasi, Anda harus menggambar:
  PlantUML
  
  
  Edit PlantUML di VPasCode
  

  PlantUML Edit PlantUML in VPasCode

  Customer --> (Jelajahi Restoran)
  RegCustomer --> (Jelajahi Restoran)
  RegCustomer --> (Pesan Pesanan)
  

  Edit PlantUML in VPasCode

  
  
  Edit PlantUML di VPasCode
  
• Dengan generalisasi, Anda hanya perlu:
  PlantUML
  
  
  Edit PlantUML di VPasCode
  

  PlantUML Edit PlantUML in VPasCode

  Customer <|-- RegCustomer
  Customer --> (Jelajahi Restoran)
  RegCustomer --> (Pesan Pesanan)
  

  Edit PlantUML in VPasCode

  
  
  Edit PlantUML di VPasCode
  
• Hasil: Diagram yang lebih bersih dan lebih mudah dipelihara.

📌 Praktik Terbaik: Gunakan generalisasi aktor setiap kali aktor khusus mewarisi semua perilaku dari aktor yang lebih umum.

✅ Mengapa <<include>> dan <<extend>> digunakan dengan benar

❗ Kesalahan Umum: Membalik arah panah. Selalu ingat:

• include: Dasar ..> Termasuk
• perluas: Ekstensi <.. Basis

✅ Mengapa Proses Pembayaran memiliki generalisasi

• Pembayaran Kartu dan Pembayaran Dompet Digital adalah bentuk khusus dari Proses Pembayaran.
• Ini menunjukkan bahwa platform mendukung berbagai metode pembayaran, tetapi semuanya mengikuti alur inti yang sama.
• Generalisasi memungkinkan perilaku bersama dan ekstensibilitas di masa depan.

📌 Kasus Penggunaan: Menambahkan metode pembayaran baru (misalnya, Apple Pay) hanyalah generalisasi lain dari Proses Pembayaran.

5. Interpretasi Dunia Nyata & Pertanyaan yang Dijawab

Diagram ini bukan sekadar bantuan visual — diagram ini menjawab pertanyaan bisnis dan teknis yang kritis:

✅ Nilai Bisnis: Diagram ini dengan jelas mengkomunikasikan apa yang dilakukan sistem, siapa yang menggunakannya, dan perilaku mana yang wajib vs. opsional.

6. Pedoman Pemodelan Umum yang Ditunjukkan

Diagram ini mengilustrasikan beberapa praktik terbaik dalam pemodelan kasus penggunaan UML:

📌 Peringatan: Banyak diagram menyalahgunakan <<extend>> untuk berarti “opsional” tanpa memahami sifat bersyarat dari ekstensi. Diagram ini menghindari kesalahan tersebut.

7. Potensi Perbaikan & Kritik

Meskipun diagram ini kuat, berikut adalah saran konstruktif untuk penyempurnaan:

🔧 1. Tambahkan Stereotipe untuk Kejelasan

actor "Payment Processor" as PaymentGW <<system>>

• Mengapa: Membuat jelas bahwa ini adalah sistem eksternal, bukan peran manusia.
• Manfaat: Mengurangi ambiguitas, terutama dalam model besar.

🔧 2. Perjelas Terapkan Kode PromoKondisi Ekstensi

Saat ini:

note bottom of (Terapkan Kode Promo)
  Opsional – hanya ketika kode yang valid dimasukkan
end note

• Lebih Baik: Gunakan notasi kondisi atau guard pada <<extend>> panah:

(Pesan Pesanan) <.. (Terapkan Kode Promo) : <<extend>> [kode promo valid]

• Mengapa: Lebih tepat daripada catatan — secara langsung mengaitkan ekstensi dengan kondisi.

🔧 3. Pertimbangkan Menambahkan Lihat Riwayat Pesanan Kasus Penggunaan

• Saat ini belum ada, tetapi kemungkinan besar penting bagi pelanggan dan restoran.
• Dapat ditambahkan sebagai Pelanggan Terdaftar kasus penggunaan.

🔧 4. Kelompokkan Kasus Penggunaan yang Terkait (Opsional)

Untuk diagram yang lebih besar, kelompokkan kasus penggunaan ke dalam paket:

package "Manajemen Pesanan" {
    (Pesan Pesanan)
    (Lacak Pesanan)
    (Terapkan Kode Promo)
}
package "Pembayaran" {
    (Proses Pembayaran)
    (Gunakan Dompet)
    (Pembayaran Kartu)
    (Pembayaran Dompet Digital)
}

• Manfaat: Meningkatkan skalabilitas dan keterbacaan.

8. Apa Selanjutnya?

Studi kasus ini telah menunjukkan bagaimana diagram kasus penggunaan yang terstruktur dengan baik dapat menangkap logika bisnis yang kompleks dengan jelas dan ringkas. Untuk memperdalam pemahaman Anda, berikut adalah langkah selanjutnya yang disarankan:

🔄 Opsi 1: Pandangan Berpusat pada Restoran

Pemodelan domain yang sama dari perspektif restoran:

• Fokus pada Kelola Menu, Terima / Siapkan Pesanan, Lihat Pesanan, Perbarui Status.
• Tampilkan Restoran sebagai aktor utama.
• Sertakan Pelanggan sebagai aktor sekunder (misalnya, Pelanggan mengirim pesanan → Restoran menerimanya).

✅ Manfaat: Mengungkapkan tujuan sistem dan peran aktor yang berbeda.

🔄 Opsi 2: Tambahkan Lebih Banyak Titik Ekstensi

Perkuat Tempatkan Pesanan dengan:

• Terapkan Kupon (jika kode promosi tidak valid → <<perluas>> dengan pesan kesalahan)
• Minta Instruksi Khusus (opsional)
• Jadwalkan Pesanan (untuk pengiriman di masa depan)

🔄 Opsi 3: Bandingkan sertakan vs perluas dengan Contoh

📌 Aturan Umum:

• Gunakan <<include>> ketika perilaku harus terjadi.
• Gunakan <<extend>> ketika perilaku mungkin terjadi dalam kondisi tertentu.

🔄 Opsi 4: Konversi ke Diagram Urutan atau Diagram Aktivitas

Untuk analisis yang lebih mendalam:

• Diagram Urutan: Menunjukkan alur Tempatkan Pesanan → Proses Pembayaran → Serahkan Pesanandengan pesan antara aktor dan sistem.
• Diagram Aktivitas: Pemodelan titik keputusan dalam Proses Pembayaran (misalnya, kartu ditolak → coba lagi atau beralih ke dompet digital).

9. Kesimpulan

Studi kasus ini menunjukkan bahwa diagram kasus penggunaan yang dirancang dengan baikjauh lebih dari sekadar sketsa visual — ini adalah alat komunikasi strategisyang:

• Memperjelas ruang lingkup sistem,
• Menangkap aturan bisnis,
• Memandu pengembangan,
• Mencegah kesalahpahaman.

Diagram Platform Pengiriman Makananmerupakan contoh yang kuatdari:

• Penggunaan notasi UML yang tepat,
• Keputusan pemodelan yang tepat,
• Pemisahan kekhawatiran yang jelas,
• Pemanfaatan catatan dan generalisasi yang efektif.

Dengan mengikuti prinsip-prinsip yang ditunjukkan di sini — penamaan yang berorientasi pada tujuan, penggunaan yang tepat dari termasuk/memperluas, generalisasi aktor, dan penggunaan catatan secara strategis — Anda dapat membuat diagram kasus penggunaan yang sekaligus akurat dan dapat ditindaklanjuti.

✅ Poin Penting Akhir