Semua yang Perlu Anda Ketahui Tentang Pemodelan Kasus Penggunaan

Manfaat Diagram Kasus Penggunaan

1. Kasus penggunaan adalah teknik yang kuat untuk penggalian dan dokumentasi kebutuhan fungsional kotak hitam.
2. Karena, kasus penggunaan mudah dipahami dan memberikan cara yang sangat baik untuk berkomunikasi dengan pelanggan dan pengguna karena ditulis dalam bahasa alami.
3. Kasus penggunaan dapat membantu mengelola kompleksitas proyek besar dengan membagi masalah menjadi fitur pengguna utama (yaitu, kasus penggunaan) dan dengan menentukan aplikasi dari perspektif pengguna.
4. Skenario kasus penggunaan, yang sering diwakili oleh diagram urutan, melibatkan kolaborasi beberapa objek dan kelas, kasus penggunaan membantu mengidentifikasi pesan (operasi dan informasi atau data yang diperlukan — parameter) yang menghubungkan objek dan kelas bersama-sama.
5. Kasus penggunaan memberikan dasar yang baik untuk menghubungkan antara verifikasi model tingkat tinggi (yaitu interaksi antara aktor dan serangkaian objek kolaboratif), dan selanjutnya, untuk validasi kebutuhan fungsional (yaitu cetak biru dari pengujian kotak putih).
6. Pendekatan berbasis kasus penggunaan menyediakan tautan yang dapat dilacak untuk pelacakan proyek di mana aktivitas pengembangan kunci seperti kasus penggunaan yang diimplementasikan, diuji, dan disampaikan memenuhi tujuan dan sasaran dari sudut pandang pengguna.

Bagaimana Cara Menggambar Diagram Kasus Penggunaan?

Model Use Case dapat dikembangkan dengan mengikuti langkah-langkah di bawah ini.

1. Identifikasi Aktor (peran pengguna) dari sistem.
2. Untuk setiap kategori pengguna, identifikasi semua peran yang dimainkan oleh pengguna yang relevan dengan sistem.
3. Identifikasi apa yang dibutuhkan pengguna agar sistem dapat dijalankan untuk mencapai tujuan ini.
4. Buat use case untuk setiap tujuan.
5. Strukturkan use case.
6. Prioritaskan, tinjau, perkirakan, dan validasi pengguna.

Perhatikan bahwa: untuk membuat pendekatan use case lebih “Agile”, jangan merinci semua use case, tetapi prioritaskan mereka dalam backlog produk Anda, Anda harus memperbaiki use case dalam berbagai tingkat detail sesuai dengan fase pengembangan dengan cara yang tepat waktu dan cukup.

Anda juga dapat:

1. Gambarlah paket untuk kategorisasi logis use case ke dalam subsistem terkait.

Strukturisasi Use Cases

UML mendefinisikan tiga stereotip asosiasi antara Use Cases:

<<include>> Use Case

Waktu untuk menggunakan hubungan <<include>> adalah setelah Anda menyelesaikan deskripsi awal dari semua Use Case utama Anda. Anda sekarang dapat melihat Use Case dan mengidentifikasi urutan umum interaksi pengguna-sistem.

<<extend>> Use Case

Use case yang memperluas adalah, secara efektif, jalur alternatif dari use case dasar. Use case <<extend>> mencapai ini dengan secara konseptual menyisipkan urutan aksi tambahan ke dalam urutan use case dasar.

Use Case yang Abstrak dan Generalisasi

Use case umum adalah abstrak. Itu tidak dapat diinstansiasi, karena mengandung informasi yang tidak lengkap. Judul dari use case abstrak ditampilkan dalam huruf miring.

Contoh

Contoh ini menggambarkan model dari beberapa use case bisnis (tujuan) yang mewakili interaksi antara restoran (sistem bisnis) dan aktor utamanya.

Setelah use case dasar diidentifikasi dalam potongan pertama, mungkin kita bisa lebih lanjut menyusun use case tersebut dengan use case <<extend>> dan <<include>> dalam sentuhan putaran kedua seperti yang ditunjukkan pada Gambar di bawah ini:

Use Case Bisnis

Sebuah use case bisnis dijelaskan dalam terminologi bebas teknologi yang memperlakukan proses bisnis sebagai kotak hitam dan menggambarkan proses bisnis yang digunakan oleh aktor bisnisnya, sementara use case biasa biasanya dijelaskan pada tingkat fungsionalitas sistem dan menentukan fungsi atau layanan yang disediakan sistem untuk pengguna. Dengan kata lain, use case bisnis mewakili bagaimana pekerjaan dilakukan secara manual dalam situasi saat ini dan tidak selalu dilakukan oleh sistem atau dimaksudkan untuk diotomatisasi dalam lingkup sistem target.

Cara Mengidentifikasi Aktor

Seringkali, orang menemukan bahwa yang paling mudah untuk memulai proses penggalian kebutuhan adalah dengan mengidentifikasi aktor. Pertanyaan berikut dapat membantu Anda mengidentifikasi aktor dari sistem Anda (Schneider dan Winters — 1998):

• Siapa yang menggunakan sistem?
• Siapa yang menginstal sistem?
• Siapa yang menyalakan sistem?
• Siapa yang memelihara sistem?
• Siapa yang mematikan sistem?
• Sistem lain apa yang menggunakan sistem ini?
• Siapa yang mendapatkan informasi dari sistem ini?
• Siapa yang memberikan informasi kepada sistem?
• Apakah ada sesuatu yang terjadi secara otomatis pada saat ini?

Bagaimana Cara Mengidentifikasi Use Cases?

Mengidentifikasi Use Cases, dan kemudian proses penggalian berbasis skenario dilanjutkan dengan menanyakan nilai yang terlihat secara eksternal dan dapat diamati yang diinginkan oleh setiap aktor. Pertanyaan berikut dapat diajukan untuk mengidentifikasi use case, setelah aktor Anda diidentifikasi (Schneider dan Winters — 1998):

• Fungsi apa yang diinginkan aktor dari sistem?
• Apakah sistem menyimpan informasi? Aktor mana yang akan membuat, membaca, memperbarui, atau menghapus informasi ini?
• Apakah sistem perlu memberi tahu aktor tentang perubahan dalam keadaan internal?
• Apakah ada peristiwa eksternal yang harus diketahui sistem? Aktor mana yang memberi tahu sistem tentang peristiwa tersebut?

Tips Diagram Use Case

Sekarang, periksa tips di bawah ini untuk melihat bagaimana menerapkan use case secara efektif dalam proyek perangkat lunak Anda.

• Selalu strukturkan dan atur diagram use case dari perspektif aktor.
• Use case harus dimulai dengan sederhana dan pada pandangan tertinggi yang mungkin. Hanya kemudian mereka dapat diperbaiki dan dirinci lebih lanjut.
• Diagram use case didasarkan pada fungsionalitas dan dengan demikian harus fokus pada “apa” dan bukan “bagaimana”.

Tingkat Detail Use Case

Granularitas use case mengacu pada cara informasi diorganisir dalam spesifikasi use case, dan sampai batas tertentu, tingkat detail di mana mereka ditulis. Mencapai tingkat granularitas use case yang tepat memudahkan komunikasi antara pemangku kepentingan dan pengembang serta meningkatkan perencanaan proyek.

Alastair Cockburn dalam Menulis Use Case yang Efektif memberi kita cara yang mudah untuk memvisualisasikan berbagai tingkat level tujuan dengan berpikir dalam istilah laut:

Perhatikan bahwa:

• Sementara use case itu sendiri mungkin menggali banyak detail tentang setiap kemungkinan, diagram use case sering digunakan untuk pandangan tingkat lebih tinggi dari sistem sebagai cetak biru.
• Adalah bermanfaat untuk menulis use case pada tingkat granularitas yang lebih kasar dengan detail yang lebih sedikit ketika tidak diperlukan.

Saya harap Anda dapat menjawab “apa itu diagram use case” sekarang dan dapat menerapkan use case dalam proyek Anda. Jika Anda ingin belajar lebih banyak tentang jenis diagram UML lainnya, silakan periksa panduan UML: Ikhtisar dari 14 Jenis Diagram UML.

Hanya menunjukkan diagram use case dalam UML notasi tidak cukup. Setiap use case disertai dengan teks yang menjelaskan tujuan dari use case serta fungsi apa yang dicapai ketika use case dieksekusi.

Spesifikasi use case biasanya dibuat dalam fase analisis dan desain secara iteratif.

• Pada awalnya, hanya deskripsi singkat tentang langkah-langkah yang diperlukan untuk melaksanakan alur normal dari use case (yaitu, fungsi apa yang disediakan oleh use case) yang ditulis.
• Seiring dengan kemajuan analisis, langkah-langkah tersebut diperluas untuk menambahkan lebih banyak detail.
• Akhirnya, alur pengecualian ditambahkan ke use case
• Setiap proyek dapat mengadopsi template use case standar untuk pembuatan spesifikasi use case.

Use Case vs Spesifikasi Use Case

Sebuah Use Case menggambarkan tugas yang dilakukan oleh seorang aktor yang menghasilkan hasil nilai bisnis untuk sebuah bisnis. Sebuah use case dapat divisualisasikan sebagai diagram use case atau/yang dalam format spesifikasi teks terstruktur:

Use Case (tugas — yang ingin dilakukan pelanggan) dapat berupa:

• Interaktif — Sebuah use case sistem menggambarkan interaksi seorang aktor dengan sistem dalam mengejar tujuan bisnis yang ditentukan
• Manual — Sebuah urutan tindakan yang dilakukan oleh seorang aktor
• Otomatis — Sebuah urutan langkah yang dilakukan oleh program atau skrip

Karakteristik dari Use Cases

Sebuah use case memiliki:

• Hanya satu tujuan
• Satu titik awal
• Satu titik akhir
• Beberapa jalur untuk mencapai dari awal hingga akhir
• yaitu. Menentukan perilaku untuk berbagai kemungkinan kondisi
• Setiap kondisi mungkin memerlukan tindakan tertentu

Sebagai Contoh — Pelanggan membayar tagihan:

Ada beberapa jalur untuk mencapai tujuan:

• Pembayaran melalui telepon
• Melalui pos
• Secara langsung
• dengan cek
• dengan uang tunai, dll.

Sebuah jalur yang tidak mengarah ke tujuan:

• Kartu kredit ditolak

Pendekatan Use Case Agile

Model use case dan use case individu berkembang tingkat demi tingkat seiring waktu. Tidak semua use case dari sebuah model perlu ditentukan pada tingkat detail yang sama.

Just-in-Time dan Just-Enough

Use case dapat ditulis pada tingkat data dan cakupan yang berbeda, masing-masing memiliki tujuan:

• Ringkasan: Deskripsi umum dan gambaran luas tentang fungsionalitas sistem atau proses bisnis.
• Tingkat Pengguna: Deskripsi terkait tugas pengguna dan bagaimana mereka berinteraksi dengan sistem; deskripsi dari proses bisnis tertentu. Use case Tingkat Pengguna biasanya dianggap berada pada tingkat tugas yang merupakan pekerjaan utama pengguna.
• Sub-fungsi: Deskripsi aktivitas tingkat lebih rendah yang digunakan untuk menyelesaikan bagian-bagian dari use case inti.

Catatan: Beberapa use case mungkin cukup ditentukan hingga tingkat II. Anda berhenti ketika detail yang cukup dicapai dengan cara just-in-time dan just-enough.

Spesifikasi Use Case yang Detail

Use case yang terperinci adalah representasi tekstual yang menggambarkan urutan peristiwa bersama dengan informasi use case terkait lainnya dalam format tertentu. Orang biasanya mengadopsi template use case standar untuk mencatat informasi terperinci untuk use case.