Now Reading: Menguasai Hubungan Kasus Pengguna UML: Kekuatan dan Bahaya «include» dan «extend»

1
  • 01

    Menguasai Hubungan Kasus Pengguna UML: Kekuatan dan Bahaya «include» dan «extend»

Read this post in: de_DEen_USes_ESfr_FRhi_INjapl_PLpt_PTru_RUvizh_CNzh_TW

Menguasai Hubungan Kasus Pengguna UML: Kekuatan dan Bahaya «include» dan «extend»

UMLYesterday

Di dunia kebutuhan perangkat lunak dan pemodelan sistem, UML (Bahasa Pemodelan Terpadu) tetap menjadi fondasi utama untuk memvisualisasikan perilaku sistem. Di antara fitur-fitur paling kuat namun sering disalahpahami adalah «include» dan  «extend»  hubungan antar kasus pengguna. Mekanisme ini dirancang untuk mengurangi duplikasi, mengelola variasi, dan meningkatkan modularitas dalam model kasus pengguna. Namun, penyalahgunaannya sangat umum—menghasilkan diagram yang terlalu kompleks, kebingungan di kalangan pemangku kepentingan, dan kehilangan fokus pada nilai pengguna.

 

 

Artikel ini menyediakan panduan komprehensif, praktis, dan didukung oleh ahli untuk memahami, menerapkan, dan menghindari jebakan umum dari «include» dan «extend». Kami akan mengeksplorasi makna sebenarnya mereka semantik sejati, membandingkannya secara berdampingan, meneliti mengapa mereka terjebak dalam perangkap yang sama seperti DFD (dekomposisi fungsional), dan menawarkan praktik terbaik modern untuk tim 2025–2026—terutama yang bekerja dalam lingkungan agile, lean, atau hibrida.

🔹 Semantik Inti: Apa yang dimaksud dengan «include» dan «extend» Benar-benar Maksud

✅ «include»: Reuse Wajib – Alur Sub-“Selalu Diperlukan”

Definisi:
Hubungan «include» merepresentasikan alur bawah yang bersifat wajib dan selalu dieksekusi yang dipisahkan untuk digunakan kembali dalam berbagai kasus penggunaan.wajib, selalu dieksekusialur bawah yang dipisahkan untuk digunakan kembali dalam berbagai kasus penggunaan.

📌 Karakteristik Utama:

  • Selalu dieksekusi: Kasus penggunaan yang dimasukkan akan berjalan setiap kali kasus penggunaan dasar dipanggil.

  • Kasus penggunaan dasar tidak lengkap tanpa itu: Tanpa perilaku yang dimasukkan, kasus penggunaan dasar tidak dapat mencapai tujuannya.

  • Arah ketergantungan: Panah mengarah kedari dasar → yang dimasukkan.

  • Makna mandiri: Kasus penggunaan yang dimasukkan biasanyatidak bermakna secara mandiri—hanya bermakna sebagai bagian dari proses yang lebih besar.

  • Analogi: Sepertipemanggilan fungsiatausubrutindalam pemrograman—penting untuk rutin utama.

🧠 Mnemonik Klasik:

“Untuk melakukanLogin, Anda harusAutentikasi Pengguna.”
“Untuk melakukanTarik Tunai, Anda harus Validasi PIN.”

Ini adalah langkah-langkah yang tidak dapat ditawar. Anda tidak dapat masuk tanpa otentikasi. Anda tidak dapat menarik tunai tanpa memvalidasi PIN.

💡 Kapan Harus Menggunakan:

  • Ketika sebuah perilaku umum, kompleks, dan dapat digunakan kembali muncul di dua atau lebih kasus penggunaan.

  • Contoh:

    • Otentikasi Pengguna

    • Catat Jejak Audit

    • Kirim Pemberitahuan

    • Validasi Format Masukan

✅ Aturan Umum: Gunakan «include» hanya ketika perilaku yang digunakan kembali adalah signifikan, tidak sederhana, dan muncul di ≥2–3 kasus penggunaan.

✅ «extend»: Variasi Opsional – “Tambahkan Kondisional”

Definisi:
Hubungan «extend» mendefinisikanopsional, kondisional, atau varians perilaku yangterhubung kesuatu titik ekstensi tertentutitik ekstensi dari use case dasar.

📌 Karakteristik Utama:

  • Dijalankan secara kondisional: Hanya berjalan dalam kondisi tertentu.

  • Use case dasar lengkap secara mandiri: Alur normal berjalan tanpa ekstensi.

  • Arah ketergantungan: Panah mengarah kedari yang diperluas → dasar (ke belakang).

  • Makna mandiri: Use case yang diperluas adalahhampir tidak pernah bermakna secara mandiri—hanya bermaknadalam konteks.

  • Analogi: Sepertikait, plugin, atausaran AOP (Pemrograman Berorientasi Aspek)—menambahkan perilaku pada titik yang ditentukan.

🧠 Mnemonik Klasik:

“Saat melakukan Pesan Penerbangan, Anda mungkin ingin Pilih Kursi Favorit.”
“Saat melakukan Bayar dengan Kartu Kredit, Anda mungkin harus Masukkan Kode 3D Secure.”

Ini adalah peningkatan opsional—tidak wajib untuk alur utama.

💡 Kapan Harus Menggunakan:

  • Untuk memodelkan jalur alternatif, pengecualian, atau fitur opsional.

  • Ketika suatu kasus penggunaan memiliki perilaku yang bervariasi berdasarkan kondisi (misalnya, peran pengguna, status sistem, preferensi).

  • Contoh:

    • Terapkan Diskon (extend Tempatkan Pesanan)

    • Permintaan Pengembalian Dana (extend Proses Pembayaran)

    • Hasilkan Bukti PDF (extend Selesaikan Transaksi)

✅ Aturan Umum: Gunakan «extend» secara hemat—hanya untuk variasi yang bermakna dengan jelas titik ekstensi.

🔍 Perbandingan Cepat: «include» vs «extend»

Aspek «include» «extend»
Eksekusi Selalu Kadang-kadang / secara kondisional
UC Dasar Selesai Sendiri? ❌ Tidak — tergantung pada yang dimasukkan ✅ Ya — selesai tanpa ekstensi
Arah Ketergantungan Dasar → Termasuk Memperluas → Dasar
Arah Panah Menunjuk ke kasus penggunaan yang termasuk Menunjuk ke kasus penggunaan dasar
Tujuan Utama Gunakan kembali langkah-langkah wajib dan bersama Kelola alur opsional/variannya
Analogi Pemanggilan fungsi / subrutin Hook / plugin / saran AOP
Arti Mandiri? Jarang Hampir tidak pernah
Terbaik Digunakan Untuk Dapat digunakan kembali, kompleks, dan melintasi berbagai aspek Perilaku bersyarat, opsional, atau alternatif

⚠️ Perangkap “Pemecahan Fungsional”: Mengapa Diagram Kasus Penggunaan Menyimpang dari Jalur

Sama sepertiDFD (Diagram Aliran Data)mengalami perangkap pemecahan fungsional, diagram kasus penggunaan juga rentan terhadap penyakit mematikan yang sama: pemecahan berlebihan.

📉 Perangkap Pemecahan Fungsional DFD (Ringkasan):

  • Tim terus membagi proses menjadi gelembung yang semakin kecil.

  • Diagram meledak menjadi puluhan fungsi kecil tingkat rendah.

  • The tujuan awal—memberikan nilai kepada pengguna—hilang.

  • Akhirnya terlihat seperti kodifikasi semu atau desain algoritma internal, bukan perilaku pengguna.

🧨 Kasus Penggunaan “Penyakit Dekomposisi Fungsional”:

  • Setiap langkah kecil menjadi kasus penggunaan tersendiri:

    • Masukkan Nama Pengguna

    • Masukkan Kata Sandi

    • Klik Tombol Masuk

    • Validasi Format

    • Tampilkan Pesan Kesalahan

  • «include» diterapkan secara luas untuk memecah setiap tindakan.

  • Hasil: Sebuah hirarki yang dalam kasus penggunaan (A → B → C → D…) tanpa tujuan aktor yang jelas.

  • Diagram menjadi tidak dapat dipelihara, membingungkan, dan tidak berguna bagi pemangku kepentingan.

❌ Bendera Merah: Jika diagram use case Anda memilikilebih dari 15–20 use case, atau jikakebanyakan use case dasar panjangnya 2–4 langkah, Anda kemungkinan sedang terjebak.

🛠️ Mengapa Ini Terjadi: Kesalahan Umum & Kesalahpahaman

Kesalahan Penjelasan Cara Menghindari
Terlalu sering menggunakan «include» Menganggap setiap langkah sub sebagai use case yang dapat digunakan kembali. Hanya gunakan «include» untuksignifikan, dapat digunakan kembali, melintasiperilaku (misalnya, otentikasi, pencatatan).
Kesalahan arah panah Menggambar panah «include» ke belakang (base ← included) atau panah «extend» ke depan. Ingat:include = base → included; extend = extending → base.
Menggunakan «extend» untuk alternatif Memodelkan alur alternatifdi dalamsatu use case sebagai «extend» alih-alih menggunakan alternatif teks. Gunakan alur alternatif teks untuk sebagian besar variasi. Cadangkan «extend» untuk ekstensi opsional yang sebenarnya.
Membuat rantai include A → B → C → D → E… Hindari rantai yang dalam. Jika Anda membutuhkan beberapa include, pertimbangkan refactoring menjadi satu use case yang dapat digunakan kembali.
titik ekstensi yang samar Menambahkan hubungan «extend» tanpa titik penyisipan yang jelas dan bernama. Tentukan titik ekstensi yang eksplisit (contoh: “Setelah konfirmasi pembayaran”) dalam use case dasar.
Kerumitan diagram Terlalu banyak use case dan hubungan → kebisingan visual. Jaga diagram kecil, fokus, dan berpusat pada aktor. Gunakan beberapa diagram per subsistem.
Kerancuan pemangku kepentingan Pemangku kepentingan non-teknis merasa sulit memahami «include/extend». Gunakan skenario teks atau peta cerita pengguna untuk kejelasan.
pemodelan tingkat desain Memodelkan arsitektur internal (contoh: “panggil database”) alih-alih tujuan pengguna. Tetap fokus pada nilai aktor—bukan implementasi.
Perdebatan tak berujung Tim berdebat tentang ‘apakah ini include atau extend?’ alih-alih menulis skenario. Gunakan heuristik praktis dan utamakan kejelasan daripada formalitas.

✅ Praktik Terbaik untuk 2025–2026: Pendekatan Modern dan Agile

Lanskap rekayasa kebutuhan telah berubah. Tim Agile, lean, dan berbasis produk semakin menjauh dari diagram UML yang berat demi teknik ringan dan berfokus pada nilai teknik.

🎯 Prinsip Utama: Fokus pada Nilai Aktor, Bukan Struktur Internal

❗ Ajukan pertanyaan ini sebelum menambahkan «include» atau «extend»:
“Apakah hubungan ini membantu pengguna memahami tujuan, atau hanya memecah sistem?”

✅ Praktik Modern yang Direkomendasikan:

1. Gunakan «include» Secara Bijak — Hanya untuk Perilaku Reusable Utama

  • Gunakan hanya untuk masalah lintas-kemampuan yang muncul di beberapa kasus penggunaan.

  • Contoh:

    • Autentikasi Pengguna

    • Kirim Pemberitahuan Email

    • Catat Kejadian Keamanan

    • Terapkan Aturan Bisnis

❌ Hindari: Masukkan Nama Pengguna, Klik Kirim, Validasi Format Email

2. Utamakan Alur Alternatif Teks Daripada «extend»

  • Alih-alih:

    «extend»: Pilih Kursi Favorit → Pesan Penerbangan

  • Gunakan:

    Use Case: Pesan Penerbangan
...
Alur Alternatif:
  1. Pengguna memilih opsi "Kursi Favorit".
  2. Sistem menampilkan peta kursi.
  3. Pengguna memilih kursi.
  4. Sistem menerapkan preferensi kursi.

✅ Mengapa?Alur teks adalahlebih mudah dibaca, lebih fleksibel, dan lebih sedikit rentan terhadap penyalahgunaan.

3. Jaga Diagram Use Case Kecil dan Fokus

  • Satu diagram per aktor atau subsistem.

  • Batas hingga 5–10 kasus penggunaan per diagram.

  • Gunakan diagram paket atau diagram konteks untuk menunjukkan struktur tingkat tinggi.

4. Tanyakan: “Apakah Peta Cerita Pengguna akan menyampaikan ini lebih baik?”

  • Jika Anda menggunakan hubungan 10+ «include»/«extend», pertimbangkan mengganti diagram ini dengan:

    • Sebuah peta cerita pengguna

    • Sebuah tabel berbasis skenario

    • Sebuah bagan alir sederhana dengan jalur kunci

🔄 Tren modern: Banyak tim agile menghindari diagram kasus pengguna sama sekali atau menggunakannya hanya untuk penemuan tingkat tinggi.

5. Gunakan «extend» Hanya untuk Variasi yang Bermakna

  • Cadangkan «extend» untukopsional, bukan intifitur yang:

    • Adalahjarang digunakan

    • Adalahbergantung konteks

    • Adalahbebasdari tujuan utama

✅ Contoh:
Proses Pembayaran (utama)
Terapkan Otentikasi 3D Secure (extend) — hanya jika dibutuhkan oleh bank

❌ Hindari:
Masukkan Nomor Kartu → Validasi Kartu → Proses Pembayaran (semuanya harus menjadi langkah dalam use case yang sama)

📊 Ringkasan: Aturan Emas dari «include» dan «extend»

Aturan Panduan
1. «include» = Wajib Gunakan hanya untukesensial, dapat digunakan kembali langkah-langkah yang muncul dalam ≥2 use case.
2. «extend» = Opsional Gunakan hanya untukbersyarat, bervariasi, atau jarang perilaku.
3. Kasus penggunaan dasar harus lengkap «extend»: dasar berfungsi sendiri. «include»: dasar tidak lengkap tanpa itu.
4. Jaga agar tetap sederhana Jika suatu kasus penggunaan memiliki <4–6 langkah setelah «include»/«extend», Anda telah terlalu memecahnya.
5. Utamakan kemudahan pembacaan Skenario teks > diagram yang kompleks.
6. Hindari rantai Tidak ada A → B → C → D. Refaktor menjadi satu kasus penggunaan yang dapat digunakan kembali.
7. Kenali audiens Anda Pemangku kepentingan tidak peduli dengan panah «include»—mereka peduli pada nilai.
Tanyakan: “Apakah ini tujuan pengguna atau langkah internal?” Jika bukan tujuan bagi aktor, kemungkinan besar tidak seharusnya berada dalam kasus penggunaan.

🎯 Pikiran Akhir: Alat, Bukan Perangkap

«include» dan «extend» adalahalat yang kuat—bukan aturan kaku. Mereka dirancang untuk:

  • Mengurangi duplikasi

  • Mengelola variasi

  • Meningkatkan kemudahan pemeliharaan

Tetapi sepertidekomposisi fungsional dalam DFD, mereka menjadisenjata berbahaya ketika digunakan berlebihan. Bahaya sebenarnya bukan pada hubungan itu sendiri—tetapi padakehilangan fokus pada tujuan pengguna.

🔥 Ingat:
Use case bukanlah proses teknis.
Ini adalahcerita tentang apa yang ingin dicapai pengguna—dan bagaimana sistem membantu.

Jika ragu, tanyakan pada diri sendiri:

“Apakah pengguna akan memahami ini tanpa mengetahui UML?”
Jika tidak, sederhanakan.
Jika iya, Anda berada di jalur yang benar.

📚 Bacaan Lebih Lanjut & Referensi

  • Spesifikasi UML (OMG): www.omg.org/spec/UML

  • Martin Fowler – Pemodelan Use Case: Pola Analisis & UML Ringkas

  • Ivar Jacobson – Keunggulan Objek: Karya dasar tentang use case

  • Pemodelan Agile (AM) oleh Scott W. Ambler

  • Pemetaan Cerita Pengguna oleh Jeff Patton – Alternatif modern untuk diagram yang rumit

✅ Aturan Satu Kalimat

Gunakan «include» untuk penggunaan kembali yang wajib, «extend» untuk variasi opsional—tetapi hanya jika benar-benar menambah nilai. Jika tidak, pertahankan kesederhanaan.

Karena pada akhirnya, tujuan bukan untuk menggambar diagram UML—tetapi untuk membangun sistem yang memberikan nilai nyata kepada orang-orang nyata.

📌 Catatan Penulis (2025–2026):
Ketika tim beralih ke arah berfokus pada produk, berbasis nilai, dan kolaboratif pengembangan, peran diagram UML tradisional sedang berkembang. «include» dan «extend» tetap berguna—tetapi hanya bila digunakan dengan pengendalian, kejelasan, dan tujuan. Biarkan mereka melayani pengguna, bukan diagram.

Related Posts

Recent Comments

Tidak ada komentar untuk ditampilkan.
Sidebar Search
Loading

Signing-in 3 seconds...

Signing-up 3 seconds...