BAB V DIAGRAM USE CASE 5. 5.1 Pendahuluan Menurut Grady Booch (2007) dalam bukunya yang berjudul ObjectOriented Analysis and Design With Application, use case diagram digunakan untuk menggambarkan konteks dari sistem yang akan dibangun dan fungsi yang dihasilkan dari sistem tersebut. Secara sederhana use case diagram dapat mendeskripsikan serangkaian interaksi antara pengguna dengan sistem. Dengan membuat serangkaian use case, kita dapat mendeskripsikan keseluruhan sistem yang akan dibuat dengan singkat dan jelas. Sebuah use case diagram dapat menjelaskan manfaat dari suatu sistem jika dilihat menurut sudut pandang orang diluar sistem. Use case diagram dapat juga digunakan selama proses analisa untuk mendapatkan kebutuhan-kebutuhan (requirement) suatu sistem dan untuk merencanakan bagaimana sistem tersebut bekerja. Dalam sebuah sistem memungkinkan hanya terdapat satu atau beberapa use case. Adapun komponen pembentuk use case diagram antara lain: • Aktor (actor), menggambarkan suatu hal diluar sistem yang berinteraksi dengan sistem. • Use case, kegiatan/aktifitas yang disiapkan oleh sistem. Menekankan pada “apa” yang dikerjakan oleh sistem, bukan “bagaimana” sistem itu bekerja. • Hubungan (link), penjelasan tentang hubungan suatu komponen use case diagram dengan komponen lainnya. Pada Gambar 5.1 ditunjukkan contoh use case diagram dari sistem penjualan tiket. Aktor yang berinteraksi dengan sistem terdiri dari Admin, Penjual tiket dan Manajer. Sedangkan use case terdiri dari lihat jadwal, lihat daftar kereta, pemesanan, lihat laporan, tambah jadwal dan tambah kereta api. Aktor penjual tiket berinteraksi dengan use case lihat jadwal, lihat daftar kereta, pemesanan, dan lihat laporan. Sedangkan aktor Admin berinteraksi dengan use case tambah jadwal dan tambah kereta api. Adapun aktor Manajer hanya berinteraksi dengan use case lihat laporan.
Gambar 5.1 Gambar 5.1 Gambar 5.1 Contoh aktor dan use case pada sistem penjualan tiket
5.2
Aktor Sebuah use case tidak dapat menjalankan tindakan sendiri, oleh sebab itu use case memerlukan aktor untuk memulai suatu aksi. Aktor adalah gambaran dari orang atau benda diluar sistem yang berinteraksi dengan sistem. Contoh hal atau sesuatu yang dapat menjadi aktor adalah: ♦ Pengguna sistem, gambaran aktor secara umum yang sering kali ada pada setiap sistem. Pada contoh sistem Rental Mobil aktornya adalah orang yang secara langsung berhubungan dengan sistem. ♦ Sistem lain yang berhubungan dengan sistem yang dirancang. ♦ Waktu dapat menjadi aktor apabila dalam waktu tertentu akan menjadi pemicu use case. Contoh, pada waktu tertentu sistem akan meng-update dirinya sendiri. Aktor dapat menerima suatu informasi dari sistem atau memberikan informasi kepada sistem. Karena aktor bukanlah bagian dari use case, maka aktor hanya dapat berinteraksi dengan use case dan tidak memiliki kontrol terhadap use case tersebut.
Gambar 5. 2 Notasi aktor Sebagaimana dijelaskan sebelumnya, aktor mempunyai relasi dengan use case dan aktor pasti akan memulai suatu use case. Kita dapat menggambarkan relasi dalam diagram use case dengan menghubungkan notasi aktor dengan notasi use case.
Gambar 5.3 Relasi aktor dengan use case Aktor tidak harus berinteraksi dengan satu use case saja, tetapi aktor dapat berinteraksi dengan banyak use case dan suatu use case dapat berinteraksi dengan banyak aktor. Hal ini yang menyebabkan terciptanya use case diagram. Pada saat akan membangun sistem, sebaiknya dilakukan identifikasi siapa/apa saja yang terlibat dalam sistem yang akan dibuat sebelum membuat use case dan aktornya. Pihak yang terlibat biasanya dinamakan stakeholder. Langkah selanjutnya adalah mempertimbangkan kebutuhan pengguna (user)
sebelum membentuk use case. Sebuah sistem dapat memiliki stakeholder potensial yang harus dipertimbangkan bila terlibat dalam sistem. Sebagai contoh Peretas (Cracker) dapat menjadi stakeholder dalam sistem. Saat menentukan actor, kita harus mempertimbangkan kepentingan aktor tersebut terhadap sistem. Sebagai contoh, pada sistem toko swalayan dibutuhkan masukan (input) nama barang, harga, jumlah pembelian dan lain-lain. Dalam hal ini, misalnya manajer toko yang seharusnya memberi masukan data-data tersebut. Jadi manajer toko merupakan aktor dalam sistem toko swalayan ini. Terdapat empat tipe aktor (Whitten, 2004) yaitu : 1. Primary business actor yaitu stakeholder yang menerima keuntungan dari pelaksanaan use case dengan menerima nilai terukur dan terobservasi. Primary business actor bisa jadi tidak berelasi dengan suatu use case. Sebagai contoh, seorang pensiunan menerima gaji pensiun (nilai terukur) setiap tanggal 25 dari sistem yang ada. Orang tersebut tidak memulai use case pembayaran gaji tersebut, tetapi merupakan penerima utama dari sesuatu yang bernilai. 2. Primary sistem actor yaitu stakeholder yang berelasi langsung dengan suatu sistem untuk memulai suatu use case. Contoh seorang manajer toko swalayan yang memberi masukan data-data barang. 3. External server actor yaitu stakeholder yang menanggapi kebutuhan pengguna use case. Contohnya biro kredit melakukan otorisasi dari sebuah kartu kredit. 4. External receiving actor yaitu stakeholder yang bukan pelaku utama tetapi menerima sesuatu yang bernilai dari use case. Contohnya pihak gudang menerima packing slip dari pelanggan.
5.3
Relasi Antar Use case Menurut James Rumbaugh (1999) terdapat 4 tipe relasi yang digunakan pada use case diagram, yaitu asosiasi, generalisasi, extend dan include. Berikut adalah penjelsan dari masing-masing relasi tersbut. 1. Asosiasi Asosiasi digunakan untuk menggambarkan interaksi antara aktor dengan setiap use case tertentu. Relasi ini digambarkan sebagai garis penghubung aktor terhadap use case yang berelasi dengan aktor tersebut.
Gambar 5. 4 Relasi asosiasi antara aktor dan use case
2. Generalisasi Suatu relasi antara use case umum (induk) dan use case yang lebih spesifik (anak). Relasi Generalisasi memungkinkan use case yang lebih spesifik memiliki perilaku (behaviour) yang sama dengan use case yang lebih umum atau bisa disebut use case induk. Relasi generalisasi digambarkan dengan anak panah segitiga. Use case yang terletak di sisi anak panah adalah use case induk dan yang terletak di sisi lainnya adalah use case yang mewarisi perilaku use case induk.
Gambar 5.5 Relasi generalisasi dengan use case pembayaran sebagai induk 3.
Extend Relasi extend memungkinkan terjadinya penambahan beberapa behaviour (tingkah laku) ke dalam use case awal yang pada dasarnya use case tersebut sudah dapat berdiri sendiri tanpa adanya penambahan. Extend digambarkan dengan anak panah yang mempunyai garis putus-putus. Use case yang berada pada kepala anak panah adalah use case awal dan yang berada di lain sisi adalah use case tambahan.
Gambar 5.6 Penggunaan relasi extend 4. Include Relasi include memungkinkan terjadinya penambahan perilaku (behaviour) ke dalam use case awal yang pada dasarnya use case ini tidak dapat berdiri
sendiri tanpa adanya penambahan use case, dan use case awal tidak akan lengkap tanpa adanya use case tambahan ini. Use case yang berada pada kepala anak panah adalah use case awal, dan pada sisi lain adalah use case penambah.
Gambar 5.7 Penggunaan relasi include Baik relasi bertipe include atau extend semuanya bertujuan memperluas atau menambah perilaku use case dasarnya. Perbedaan diantara keduanya adalah: Jika relasi include, use case penambah selalu diperlukan oleh use case awal (dasar). Jika relasi extend, tidak selalu dibutuhkan oleh use case dasar. Jika relasi include, yang memutuskan kapan dipanggilnya use case penambah adalah use case dasar. Berbeda dengan relasi Extend, yang memutuskan kapan dipanggilnya use case tambahan adalah use case tambahan itu sendiri.
5.4
Use case Sederhana Meskipun use case dan aktor memiliki definisi yang sederhana, dan juga visualisasi dari use case diagram juga terlihat sederhana, namun sebenarnya use case sangat penting dalam pemodelan. Adapun use case secara umum dapat dijabarkan sebagai berikut: • Use case diagram mendefinisikan cakupan dari sistem. Jadi use case diagram dapat memvisualisasikan sistem yang akan dibuat. • Use case dapat digunakan untuk menggali kebutuhan (requirement) dari sistem. • Use case sangat sederhana dan dapat mudah dipahami. • Use case dapat membantu developer dalam membangun suatu sistem, dapat kita lihat use case adalah tulang punggung bagi pembangunan suatu sistem, dan developer pasti merujuk ke use case dalam membangun sistem. • Use case dapat juga sebagai pengukur lama waktu pengerjaan suatu sistem. • Use case juga dapat membantu pembuatan “user guide” dalam berinteraksi dengan sistem yang telah jadi. Beberapa cara yang dapat dilakukan untuk membuat use case yang baik yaitu:
Pilihlah nama yang baik. Use case adalah sebuah behaviour (perilaku), jadi penulisan use case sebaiknya dalam kata kerja. Sebagai penjelas dari kata kerja ditambah kata benda. Diagram use case juga biasanya berhubungan dengan diagram kelas. Contoh, buat akun. Gambarkan perilaku dengan lengkap. Jangan membuat use case bila tidak tahu tujuan yang dicapai dengan membuat use case tersebut. Sebagai contoh, memilih nomor kursi pada kereta api pada saat pengunjung datang ke loket penjualan tidak dapat dijadikan use case karena merupakan bagian dari use case pemesanan tiket dan tidak dapat berdiri sendiri tanpa use case pemesanan tiket. Dengan kata lain pengunjung tidak mungkin memilih kursi apabila belum memesan tiket suatu kereta api. Menggunakan use case kebalikan (inverse). Untuk membangun sistem yang baik, sistem sering kali membuatuhkan use case yang dapat membatalkan use case lainnya, contohnya pada saat pelanggan memesan tiket, ternyata pelanggan ingin membatalkannya, sistem harus dapat menanganinya. Untuk kasus ini diperlukanlah use case pembatalan tiket. Use case hendaknya hanya mempunyai satu perilaku saja. Untuk mencegah kerancuan, sebaiknya dalam membuat satu use case hanya satu perilaku saja yang dimiliki oleh use case tersebut, misalnya penggunaan use case meminjam dan mengembalikan buku dalam satu use case menghasilkan kerancuan karena memiliki dua perilaku yang berbeda. Membuat use case dari sudut pandang aktor. Pilihlah nama use case pemesanan tiket, bukanya inputan pesanan tiket ,karena pemesanan tiket dibuat berdasarkan sudut pandang aktor sedangkan inputan pesanan tiket adalah sudut pandang perusahaan kereta api.
Pembuatan Aktor Aktor harus dibuat sejelas mungkin untuk mempermudah orang lain dalam memahami diagram use case yang telah dibuat. Adapun panduan untuk membuat aktor adalah sebagai berikut: Aktor harus terpisah dengan use case , dan aktor harus mempunyai relasi minimal dengan satu use case. Nama aktor sesuai dengan peranannya bukan jabatannya, dan nama aktor sebaiknya dengan kata benda tunggal. Tambahkan <<sistem>> pada aktor berjenis sistem, dan tambahkan “waktu” bila sistem terjadwal otomatis. Jangan menghubungkan aktor satu dengan aktor yang lain bila bukan generalisasi. Aktor satu dengan yang lain bisa terhubung melalui use case. Pembuatan Use case Panduan dalam membuat use case yang baik seperti : Nama use case sejelas mungkin dan pemberian nama use case dilihat dari sudut pandang aktor bukan dari sudut pandang sistem.
Penamaan use case menggunakan kata kerja dan diperjelas dengan kata benda. Sebaiknya use case disusun dari atas kebawah berdasarkan urutanya untuk mempermudah orang lain dalam membaca, meskipun use case tidak mengenal pewaktuan.
Pembuatan Relasi Relasi berguna untuk memberi penjelasan hubungan antara aktor dan use case, sehingga bila terjadi kesalahan dalam pembuatan relasi maka diagram akan sulit untuk dipahami. Berikut dijelaskan cara-cara pembuatan relasi yang baik: • Gunakan <
> dan <<extend>> apabila kita sudah yakin benar. • Sebaiknya tempatkan use case induk diatas use case anak bila terjadi generalisasi. • Jangan menggunakan anak panah antara aktor dan use case kecuali salah satunya bersifat pasif. Pada Gambar 5. 8 ditunjukkan contoh use case diagram sistem penjualan tiket lengkap dengan relasi antara aktor dengan use case.
Gambar 5. 8 Use case diagram tiket kereta api
5.5
Latihan
