![\"A](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a0ed6385d42a.png\")
<\/p>\n
Melalui studi kasus ini, Anda akan mengeksplorasi elemen struktural utama use case UML 2.0, belajar bagaimana memfaktorkan perilaku menggunakan Tantangan:<\/strong>Persyaratan awal NexusBook disimpan dalam spreadsheet yang tersebar dan dokumen dengan kalimat pasif. Pengembang sering salah memahami kasus tepi, QA kesulitan melacak skenario pengujian, dan manajer produk tidak bisa membayangkan batas sistem. Alur pembayaran, khususnya, mengalami logika login yang ganda, jalur pembatalan yang tidak jelas, dan deskripsi yang terlalu berat pada antarmuka yang menyebabkan detail desain bocor ke dalam persyaratan.<\/p>\n Solusi:<\/strong> Tim beralih ke pendekatan use case UML 2.0 yang terstruktur, menerapkan batasan diagram yang ketat dan pemfaktoran perilaku<\/p>\n . Bagian-bagian berikut menjelaskan bagaimana prinsip-prinsip ini diterapkan dalam praktik.<\/p>\n Sebuah use case memodelkan satuan fungsionalitas sistem yang didefinisikan oleh interaksi antara entitas eksternal dan sistem itu sendiri untuk mencapai tujuan bisnis tertentu. Di NexusBook, tim menetapkan upaya pemodelan mereka pada empat pilar dasar:<\/p>\n Aktor<\/strong>: Mewakili peran yang koheren yang dimainkan oleh entitas eksternal. NexusBook mengidentifikasi aktor manusia seperti Subjek<\/strong>: Batas sistem yang sedang dikembangkan. NexusBook secara eksplisit membatasi\u00a0 Alur Kejadian<\/strong>:<\/p>\n Alur Utama (Kursus Dasar)<\/strong>: Jalur ‘bahagia’ di mana aktor utama berhasil tanpa kesalahan. Contoh: Seorang pelanggan berhasil menyelesaikan proses checkout.<\/p>\n<\/li>\n Alur Khusus (Kursus Alternatif)<\/strong>: Kondisi kesalahan, kasus batas, atau cabang opsional. Contoh: Pembayaran ditolak, waktu sesi habis, atau pembatalan pesanan opsional.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n Contoh Kasus Penggunaan<\/strong>: Jalur eksekusi runtime tunggal. Setiap transaksi pelanggan di NexusBook mewakili contoh kasus penggunaan yang unik, memungkinkan pemetaan uji QA yang tepat.<\/p>\n<\/li>\n<\/ul>\n Untuk mencegah kasus penggunaan yang monolitik dan sulit dipelihara, NexusBook memanfaatkan tiga mekanisme hubungan UML 2.0 untuk memisahkan perilaku umum dan menangani jalur yang bervariasi.<\/p>\n Konsep<\/strong>: Kasus penggunaan dasar secara eksplisit menarik perilaku dari kasus penggunaan sertakan pada titik yang ditentukan. Kasus penggunaan yang disertakan tidak dapat berdiri sendiri.<\/p>\n<\/li>\n Aplikasi NexusBook<\/strong>: Kedua\u00a0 Tujuan<\/strong>: Menghilangkan redundansi dan mengonsentrasikan perilaku bersama.<\/p>\n<\/li>\n<\/ul>\n Konsep<\/strong>: Sebuah kasus penggunaan variasi secara implisit menyisipkan perilakunya ke dalam kasus penggunaan dasar hanya pada titik perluasan yang secara eksplisit diberi nama\u00a0Titik Perluasan<\/strong>.<\/p>\n<\/li>\n Aplikasi NexusBook<\/strong>: Selama\u00a0 Tujuan<\/strong>: Menangani perilaku opsional, kondisional, atau jarang terjadi tanpa membuat alur utama menjadi kacau.<\/p>\n<\/li>\n<\/ul>\n Konsep<\/strong>: Berfungsi seperti pewarisan kelas. Kasus penggunaan induk mendefinisikan pola perilaku yang dapat dikhususkan atau diganti oleh anak-anaknya. Aktor juga dapat mewarisi hak akses.<\/p>\n<\/li>\n Aplikasi NexusBook<\/strong>:\u00a0 Tujuan<\/strong>: Memungkinkan klasifikasi taksonomi dan pemodelan akses berbasis peran.<\/p>\n<\/li>\n<\/ul>\n Diagram menyediakan kerangka arsitektur dari pemodelan kasus penggunaan. Di bawah ini adalah spesifikasi PlantUML yang digunakan NexusBook secara tepat, lengkap dengan kontrol tata letak untuk mencegah grafik yang berantakan.<\/p>\n Memetakan batas sistem, aktor, dan faktor perilaku untuk subsistem checkout.<\/p>\n\u00abinclude\u00bb<\/code>,\u00a0\u00abextend\u00bb<\/code>, dan generalisasi, menguasai teknik pemetaan PlantUML, serta menerapkan panduan teks yang terbukti untuk menulis use case yang kuat dan siap digunakan oleh pengembang.<\/p>\n
\nKonteks Studi Kasus: Platform NexusBook<\/h2>\n
\n1. Konsep Utama & Elemen Struktural dalam Praktik<\/h2>\n
Pilar-Pilar Utama yang Diterapkan<\/h3>\n
\n
Pelanggan<\/code> danAgen Dukungan<\/code>, bersama dengan aktor sistem sepertiPaymentGateway<\/code> danEmailService<\/code>.<\/p>\n<\/li>\nSistem Check Out Toko Buku<\/code>\u00a0dan\u00a0Sistem Persediaan & Buku Besar<\/code>\u00a0untuk memisahkan perilaku internal dari ketergantungan eksternal.<\/p>\n<\/li>\n\n
\n2. Mengorganisasi & Menata Kasus Penggunaan<\/h2>\n
I. Sertakan (
\u00absertakan\u00bb<\/code>)<\/h3>\n\n
Tambahkan ke Daftar Keinginan<\/code>\u00a0dan\u00a0Check Out<\/code>\u00a0memerlukan otentikasi. Alih-alih menggandakan langkah, tim membuat\u00a0Masuk<\/code>\u00a0kasus penggunaan dan menyertakannya di mana pun diperlukan.<\/p>\n<\/li>\nII. Perluas (
\u00abperluas\u00bb<\/code>)<\/h3>\n\n
Periksa Status Pesanan<\/code>, pelanggan dapat secara opsional memicu\u00a0Batalkan Pesanan<\/code>. Ini dimodelkan sebagai perluasan yang terkait dengan titik perluasan\u00a0[Permintaan Pembatalan]<\/code>\u00a0titik perluasan.<\/p>\n<\/li>\nIII. Generalisasi<\/h3>\n
\n
Lakukan Pencarian<\/code>\u00a0berfungsi sebagai induk bagi\u00a0Cari berdasarkan Judul<\/code>,\u00a0Cari berdasarkan Penulis<\/code>, dan\u00a0Cari berdasarkan ISBN<\/code>. Demikian pula,\u00a0Personil Akuntansi<\/code>\u00a0mengalihkan izin dasar ke\u00a0Akuntan<\/code>\u00a0dan\u00a0Klerikal Akuntansi<\/code>.<\/p>\n<\/li>\n
\n3. Strategi Pemodelan Visual dan Tata Letak PlantUML<\/h2>\n
Skenario A: Hubungan Struktural (
\u00abinclude\u00bb<\/code>\u00a0&\u00a0\u00abextend\u00bb<\/code>)<\/h3>\n![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a0ed4d511704.png\")
<\/p>\n
\n
\n