Studi Kasus: Diagram Use Case untuk Platform Pengiriman Makanan - Go 2 Posts Indonesian

Pemodelan Kebutuhan Dunia Nyata dengan UML – Panduan Praktis

1. Pendahuluan

Dalam pengembangan perangkat lunak modern, diagram use case adalah alat dasar untuk menangkap kebutuhan fungsional dari sudut pandang pengguna. Studi kasus ini menyajikan analisis mendalam tentang diagram use case yang realistis untuk Platform Pengiriman Makanan, menggunakan sintaks PlantUML sebagai bahasa pemodelan. Tujuannya adalah untuk menunjukkan tidak hanya apa unsur-unsur yang digunakan dalam diagram, tetapi juga mengapa mereka dipilih — menyoroti keputusan pemodelan praktis, konvensi, dan jebakan umum.

Studi kasus ini melayani kedua kalangan pemula yang belajar UML dan praktisi yang menyempurnakan praktik pemodelan mereka. Ini menguraikan setiap elemen dalam diagram, menjelaskan tujuannya, dan membahas implikasi dunia nyata.

2. Gambaran Sistem

The 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 menelusuri 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

arah kiri ke kanan

‘ Semua aktor didefinisikan di luar persegi panjang
aktor Pelanggan
aktor “Pelanggan Terdaftar” sebagai RegCustomer
aktor “Staf Restoran” sebagai Restoran
aktor Pengemudi
aktor “Pemroses Pembayaran” sebagai PaymentGW

persegi panjang “Platform Pengiriman Makanan” {

(Telusuri Restoran)
(Pesan Pesanan)
(Lacak Pesanan)
(Kelola Menu)
(Terima / Siapkan Pesanan)
(Kirim Pesanan)
(Proses Pembayaran)
(Keluarkan Pengembalian Dana)
(Menerapkan Kode Promo)
(Menggunakan Dompet)
(Pembayaran Kartu)
(Pembayaran Dompet Digital)

‘ Asosiasi – panah melintasi batas
Pelanggan –> (Menjelajahi Restoran)
Pelanggan Terdaftar –> (Memesan Pesanan)
Pelanggan Terdaftar –> (Melacak Pesanan)

Restoran –> (Kelola Menu)
Restoran –> (Terima / Siapkan Pesanan)

Pengemudi –> (Mengantarkan Pesanan)

PaymentGW –> (Memproses Pembayaran)
PaymentGW –> (Menerbitkan Pengembalian Dana)

‘ include
(Memesan Pesanan) ..> (Memproses Pembayaran) : <<include>>

‘ extend
(Memesan Pesanan) <.. (Menerapkan Kode Promo) : <<extend>>
(Memproses Pembayaran) <.. (Menggunakan Dompet) : <<extend>>

‘ generalisasi
(Memproses Pembayaran) <|– (Pembayaran Kartu)
(Memproses Pembayaran) <|– (Pembayaran Dompet Digital)
}

‘ Generalisasi Aktor (juga di luar)
Pelanggan <|– Pelanggan Terdaftar

catatan di kanan PaymentGW
Gerbang pembayaran eksternal
(Stripe, PayPal, Adyen, …)
akhir catatan

catatan di bawah (Menerapkan Kode Promo)
Opsional – hanya jika kode yang valid dimasukkan
Catatan penutup

@enduml

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

3. Elemen Diagram: Penjelasan Mendalam dengan Makna Praktis

Berikut adalah pemecahan komprehensif untuk setiap elemen UML yang digunakan dalam diagram, beserta interpretasi dunia nyata dan alasan pemodelan.

#	Elemen	Notasi	Makna & Tujuan	Keputusan Pemodelan / Komentar
1	Batas Sistem	`persegi panjang "Platform Pengiriman Makanan"`	Menentukan lingkup sistem yang dimodelkan. Semua kasus penggunaan di dalamnya merupakan bagian dari sistem ini.	Nama ini ringkas namun deskriptif. Dalam konteks perusahaan, nama yang lebih panjang (misalnya, “Sistem Manajemen Pesanan Pelanggan”) dapat digunakan.
2	Aktor Manusia Utama	`aktor Pelanggan`, `aktor Pengemudi`	Mewakili peran eksternalyang memulai atau berpartisipasi dalam use case.	Nama bersifat sederhana dan intuitif. Menghindari stereotip yang tidak perlu seperti`<<orang>>`kecuali diperlukan untuk model besar.
3	Aktor dengan Alias	`aktor "Staf Restoran" sebagai Restoran`	Memungkinkan nama aktor yang lebih panjang dan deskriptif dipersingkat untuk kejelasan dalam koneksi.	Sangat efektif ketika nama aktor mengandung spasi atau terlalu panjang. Mengurangi kekacauan dan meningkatkan keterbacaan.
4	Aktor Sistem Eksternal	`aktor "Pemroses Pembayaran" sebagai PaymentGW`	Memodelkansistem pihak ketigasistem yang berinteraksi dengan platform.	Tidak ada stereotip`«sistem»`digunakan — dapat diterima dalam diagram ringan. Namun, menambahkan`«sistem»`dapat memperjelas maksud dalam sistem yang kompleks.
5	Generalisasi Aktor	`Pelanggan <	— PelangganTerdaftar`	Menunjukkan bahwapelanggan terdaftaradalah versi khusus daripelanggan tamu.
6	Asosiasi Biasa	`Pelanggan --> (Telusuri Restoran)`	Menunjukkan bahwa aktormemulaiatauberpartisipasi dalamkasus penggunaan.	Garis padat = komunikasi. Arah diimplikasikan dari aktor ke kasus penggunaan (tidak perlu panah).
7	Hubungan «include»	`(Tempatkan Pesanan) ..> (Proses Pembayaran) : <<include>>`	`Proses Pembayaran`adalahselalu diperlukansaat memesan pesanan.	Panah mengarahdari yang mengikutkan → yang diikutkan. Ini sangat penting:`Tempatkan Pesanan` mencakup `Proses Pembayaran`sebagai langkah wajib.
8	Hubungan «extend»	`(Tempatkan Pesanan) <.. (Terapkan Kode Promo) : <<extend>>`	Menerapkan kode promo adalahopsionaldan hanya terjadi dalam kondisi tertentu.	Panah mengarahdari ekstensi → dasar. Kasus penggunaan dasar (`Tempatkan Pesanan`) dapat diperluas secara kondisional.
9	Generalisasi Kasus Penggunaan	`(Proses Pembayaran) <	— (Pembayaran Kartu)`<br>`(Proses Pembayaran) <	— (Pembayaran Dompet Digital)`
10	Catatan	`catatan di kanan PaymentGW` `catatan di bawah (Terapkan Kode Promo)`	Menyediakan penjelasan kontekstual tentang implementasi atau aturan bisnis.	Catatan sering diabaikan tetapi sangat berharga. Mereka mencegah salah pemahaman (misalnya, menjelaskan bahwa PaymentGW bersifat eksternal).
11	Aktor di Luar Batas	Semua `aktor` deklarasi mendahului persegi panjang	Menekankan bahwa tidak ada aktor yang merupakan bagian dari sistem — pemisahan tanggung jawab yang jelas.	Salah satu dari dua tata letak standar. Lebih disukai ketika aktor banyak atau eksternal.
12	Arah Diagram	`arah kiri ke kanan`	Meningkatkan tata letak ketika beberapa aktor berada di sebelah kiri.	Meningkatkan keterbacaan. Terutama efektif dengan 4–8 aktor. Alternatif: tata letak atas ke bawah untuk jumlah aktor yang lebih sedikit.

4. Keputusan Pemodelan Utama & Alasan

✅ Mengapa aktor berada di luar batas sistem

Praktik terbaik: Aktor mewakili perandi luarsistem.
Mengapa hal ini penting: Mencegah kebingungan antara komponen sistem dan entitas eksternal.
Contoh: Pengemudibukan modul dari platform — mereka adalah peran pihak ketiga yang berinteraksi dengannya.

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

✅ Mengapa menggunakan`Pelanggan <|-- Pelanggan Terdaftar`daripada menduplikasi tautan

Tanpa generalisasi, Anda harus menggambar:

Pelanggan --> (Telusuri Restoran)
Pelanggan Terdaftar --> (Telusuri Restoran)
Pelanggan Terdaftar --> (Tempatkan Pesanan)

Dengan generalisasi, Anda hanya perlu:

Pelanggan <|-- Pelanggan Terdaftar
Pelanggan --> (Telusuri Restoran)
Pelanggan Terdaftar --> (Tempatkan Pesanan)

Hasil: Diagram yang lebih bersih dan lebih mudah dipelihara.

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

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

Hubungan	Tujuan	Arah	Contoh
`<<include>>`	Aliran sub wajib	Dari termasuk → termasuk	`Tempatkan Pesanan` harus termasuk `Proses Pembayaran`
`<<extend>>`	Perluasan opsional	Dari perluasan → dasar	`Terapkan Kode Promo` mengembangkan `Tempatkan Pesanan`hanya jika kode valid

❗ Kesalahan Umum: Membalik arah panah. Selalu diingat:

termasuk: Dasar ..> Termasuk

kembangkan: Perluasan <.. Dasar

✅ Mengapa `Proses Pembayaran`memiliki generalisasi

Pembayaran KartudanPembayaran Dompet Digitaladalahbentuk khususdariProses Pembayaran.
Ini menunjukkan bahwa platform mendukungberbagai metode pembayaran, tetapi semuanya mengikuti alur inti yang sama.
Generalisasi memungkinkan untukperilaku bersama dan ekstensibilitas 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 hanya bantuan visual — ia menjawab pertanyaan penting mengenai bisnis dan teknis:

Pertanyaan	Jawaban dari Diagram
Siapa pengguna utama?	Pelanggan, Pelanggan Terdaftar, Staf Restoran, Pengemudi, Gateway Pembayaran
Apakah pengguna yang belum terdaftar dapat memesan?	❌ Tidak — hanya `PelangganTerdaftar` dapat `Tempatkan Pesanan`. `Pelanggan` hanya dapat `Telusuri Restoran`.
Apakah pembayaran selalu diperlukan?	✅ Ya — `Tempatkan Pesanan` mencakup `Proses Pembayaran`. Wajib.
Apakah pelanggan dapat menggunakan kode promosi?	✅ Ya — tetapi hanya secara opsional melalui `<<perluas>>`. Hanya jika kode yang valid dimasukkan.
Metode pembayaran apa saja yang didukung?	Kartu dan Dompet Digital (melalui generalisasi). Sistem eksternal menangani pemrosesan sebenarnya.
Siapa yang menangani pembayaran?	Eksternal `PaymentGW` — bukan bagian dari platform.
Apakah restoran dapat mengelola menu mereka?	✅ Ya — `Restoran` aktor berinteraksi dengan `Kelola Menu` dan `Terima / Siapkan Pesanan`.

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

6. Panduan Pemodelan Umum yang Ditunjukkan

Diagram ini menunjukkan beberapapraktik terbaikdalam pemodelan use case UML:

Panduan	Cara Penerapannya
Gunakan nama use case berbasis tujuan	`Tempatkan Pesanan`, `Lacak Pesanan`, `Terapkan Kode Promo`— semua dimulai dengan kata kerja dan menggambarkan tujuan pengguna.
Jaga agar diagram mudah dibaca	Hanya10 use caseditampilkan — ideal untuk sebagian besar bidang bisnis (5–12 direkomendasikan).
Sistem eksternal sebagai aktor	`PaymentGW`diproyeksikan sebagai aktor, bukan sebagai use case. Secara benar memisahkan perhatian.
Gunakan catatan untuk mengklarifikasi ambiguitas	Catatan menjelaskan bahwa`PaymentGW`adalah eksternal dan kode promo bersifat opsional — penting untuk menghindari salah tafsir.
Gunakan generalisasi aktor untuk mengurangi kekacauan	`Pelanggan <
Gunakan`include`dan`extend` dengan benar	Perbedaan yang jelas antara perilaku wajib dan opsional.

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

7. Perbaikan Potensial & Kritik

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

🔧 1. Tambahkan Stereotip untuk Kejelasan

aktor "Pemroses Pembayaran" sebagai PaymentGW <<system>>

Mengapa: Menunjukkan secara jelas bahwa ini adalah sistem eksternal, bukan peran manusia.
Manfaat: Mengurangi ambiguitas, terutama pada model yang besar.

🔧 2. Perjelas `Terapkan Kode Promo` Kondisi Ekstensi

Saat ini:

catatan di bawah (Terapkan Kode Promo)
  Opsional – hanya ketika kode yang valid dimasukkan
akhir catatan

Lebih baik: Gunakan notasi kondisi atau penjaga di dalam <<perluas>> panah:

(Tempatkan Pesanan) <.. (Terapkan Kode Promo) : <<perluas>> [kode promo yang valid]

Mengapa: Lebih presisi daripada catatan — secara langsung menghubungkan perluasan dengan suatu kondisi.

🔧 3. Pertimbangkan Menambahkan `Lihat Riwayat Pesanan` Kasus Penggunaan

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

🔧 4. Kelompokkan Kasus Penggunaan yang Terkait (Opsional)

Untuk diagram yang lebih besar, kelompokkan kasus penggunaan menjadi paket:

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

Manfaat: Meningkatkan skalabilitas dan kemudahan pembacaan.

8. Langkah Selanjutnya?

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

🔄 Opsi 1: Tampilan Berpusat pada Restoran

Model domain yang sama dari sudut pandang 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 menerima pesanan).

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

🔄 Opsi 2: Tambahkan Titik Ekstensi Lebih Banyak

Tingkatkan Tempatkan Pesanan dengan:

Terapkan Kupon (jika kode promosi tidak valid → <<perpanjang>> dengan pesan kesalahan)
Permintaan Instruksi Khusus (opsiional)
Jadwalkan Pesanan (untuk pengiriman di masa depan)

🔄 Opsi 3: Bandingkan `termasuk` vs `perpanjang` dengan Contoh

Kasus Penggunaan	`<<termasuk>>`	`<<perpanjang>>`
`Tempatkan Pesanan` → `Proses Pembayaran`	✅ Wajib	❌ Bukan opsi
`Tempatkan Pesanan` → `Terapkan Kode Promosi`	❌ Bukan wajib	✅ Bersyarat
`Masuk` → `Verifikasi Identitas`	✅ Selalu dibutuhkan	❌ Tidak berlaku
`Keluar` → `Terapkan Diskon`	✅ Selalu	✅ Hanya jika diskon tersedia

📌 Aturan Umum:

Gunakan <<masukkan>> ketika perilaku harus terjadi.

Gunakan <<perluas>> ketika perilaku mungkin terjadi dalam kondisi tertentu.

🔄 Opsi 4: Konversi ke Diagram Urutan atau Diagram Aktivitas

Untuk analisis yang lebih mendalam:

Diagram Urutan: Menampilkan alur dari Tempatkan Pesanan → Proses Pembayaran → Kirim Pesanan dengan pesan antara aktor dan sistem.
Diagram Aktivitas: Model titik keputusan dalam Proses Pembayaran (contoh: kartu ditolak → coba lagi atau beralih ke dompet digital).

9. Kesimpulan

Studi kasus ini menunjukkan bahwa diagram use case yang dirancang dengan baik jauh lebih dari sekadar gambaran visual — itu adalah alat komunikasi strategis yang:

Mengklarifikasi cakupan sistem,
Mencatat aturan bisnis,
Membimbing pengembangan,
Mencegah salah paham.

The Platform Pengiriman Makanan diagram adalah contoh yang kuat dari:

Penggunaan notasi UML yang tepat,
Keputusan pemodelan yang baik,
Pemisahan tanggung jawab yang jelas,
Penggunaan catatan dan generalisasi yang efektif.

Dengan mengikuti prinsip-prinsip yang ditunjukkan di sini — penamaan berorientasi tujuan, penggunaan yang benar dari include/perluas, generalisasi aktor, dan penggunaan catatan secara strategis — Anda dapat membuat diagram use case yang keduanya akuratdan dapat diambil tindakan.

✅ Kesimpulan Akhir

Prinsip	Diterapkan Di Sini?	Mengapa Ini Penting
Gunakan nama diagram use case berbasis tujuan	✅ Ya	Meningkatkan kejelasan dan fokus pengguna
Jaga ukuran diagram tetap terkelola	✅ Ya (10 diagram use case)	Mencegah kelebihan beban kognitif
Sistem eksternal sebagai aktor	✅ Ya	Pemisahan peran yang benar
Gunakan catatan untuk konteks	✅ Ya	Mencegah salah paham
Gunakan generalisasi untuk mengurangi redundansi	✅ Ya	Membuat diagram dapat diskalakan dan mudah dipelihara
Benar `<<masukkan>>` dan `<<perluas>>` arah	✅ Ya	Memastikan pemodelan perilaku yang akurat