Bahasa pemodelan perangkat lunak unified modeling language (UML), sejak pertama kali diperkenalkan pada tahun 1997, saat ini telah berkembang menjadi sebuah bahasa pemodelan yang baku (de facto) di dalam sebuah pengembangan perangkat lunak (Engels, et al., 2000) (Larman, 2005) (Lange, et al., 2006). UML digunakan dalam pengembangan sistem perangkat lunak yang menggunakan pendekatan berorientasi objek. Intensitas penggunaan UML yang tinggi ini didukung dengan semakin matangnya konsep pemodelan yang dirumuskan dalam setiap rilis spesifikasi UML yang dikembangkan oleh Object Management Group. Sampai tahun 2017, OMG telah merilis 11 versi spesifikasi UML, yang terakhir adalah versi 2.5.1 yang termasuk dalam revisi UML 2.02. Di sisi lain, pengembangan alat bantu untuk pemodelan dengan UML berkembang cukup pesat dan sebagiannya tergolong sebagai free software sehingga tersedia banyak pilihan bagi pengembang perangkat lunak untuk menggunakannya, antara lain: StarUML3, ArgoUML4, UML Designer5. UML menyediakan banyak sekali diagram yang diperlukan untuk menjelaskan sistem yang sedang dikembangkan, baik dari aspek statis maupun dinamisnya (OMG, 2017). Salah satu diagram penting yang digunakan untuk mengilustrasikan kebutuhan (requirements) dari sistem adalah use case (UC) diagram, yang menjelaskan secara visual konteks dari interaksi antara aktor dengan sistem. Setiap use case menyatakan spesifikasi perilaku (fungsionalitas) dari sistem yang sedang dijelaskan yang memang dibutuhkan oleh aktor untuk memenuhi tujuannya. Namun demikian, penjelasan detil dari interaksi yang terjadi antara aktor dan sistem, berkaitan dengan sebuah use case tertentu, harus dijelaskan secara deskriptif dalam sebuah use case (UC) scenario. Oleh karena itu, UC scenario dan UC diagram, yang dibutuhkan dalam pemodelan UC dari sebuah sistem, harus mampu menjelaskan fungsionalitas sistem secara lengkap dan valid.
Dalam praktiknya, pembuatan UC scenario dan UC diagram bisa dilakukan dengan cukup mudah, meskipun oleh pengembang sistem yang belum berpengalaman. Namun demikian, pembuatan sebuah penjelasan use case yang baik dan bermanfaat ternyata membutuhkan keahlian dan pengalaman yang cukup (Cockburn, 2000) (Adolph, et al., 2002). Sebagai akibat dari minimnya pengetahuan dan pengalaman dalam pemodelan UC maka UC scenario dan UC diagram yang dihasilkan ternyata masih sering mengandung kesalahan sehingga model gagal merepresentasikan fungsionalitas dari sistem dengan tepat. Terlebih lagi, tidak sedikit pengembang yang masih memiliki paradigma yang salah yang memandang bahwa program yang bisa dieksekusi (executable codes) adalah satu-satunya produk yang penting dari sebuah pengembangan perangkat lunak (Pressman, 2010), sehingga aspek pemodelan dan dokumentasi sistem menjadi terabaikan.
UC (Use Case) Skenario
UC scenario merupakan penjelasan secara tekstual dari sekumpulan skenario interaksi. Setiap kenario mendeskripsikan urutan aksi/langkah yang dilakukan aktor ketika berinteraksi dengan sistem, baik yang berhasil maupun gagal. UC scenario dijelaskan secara tekstual dalam beberapa format tergantung kebutuhannya, yaitu singkat (brief), informal (casual), atau lengkap (fully dressed) (Larman, 2005), yang bisa dijelaskan dalam bentuk tabel dengan 1 kolom atau 2 kolom (Cockburn, 2000). Pada format singkat, penjelasan diberikan cukup 1 paragraf yang mengacu hanya pada skenario yang berhasil. Pada format informal, penjelasan diberikan dalam beberapa paragraf yang mencakup semua skenario, baik yang berhasil maupun gagal. Sedangkan, pada format lengkap, penjelasan dibuat secara detil disertai dengan bagianbagian pendukung yang penting. Format terakhir ini yang banyak digunakan di dalam praktik. Bagianbagian penting tersebut adalah (Larman, 2005): - aktor primer (primary actor), yaitu aktor yang menginisiasi layanan sistem untuk mencapai tujuan dari aktor tersebut. Jumlah aktor primer dimungkinkan lebih dari 1. - prakondisi (preconditions), yaitu kondisi spesifik yang harus terpenuhi sebelum sebuah UC bisa diinisiasi atau dieksekusi oleh aktor primer. Jumlah prakondisi bisa lebih dari 1 keadaan. - alur utama (main or basic flow), yaitu jalur interaksi yang mengarahkan pada skenario yang berhasil sehingga tujuan aktor bisa terpenuhi. Jalur ini hanya terdiri dari 1 jalur saja. - alur alternatif (alternative flows), yaitu jalur alternatif dari interaksi yang terjadi antar aktor dengan sistem yang mencakup pencabangan (pilihan) maupun skenario yang gagal sehingga tujuan aktor tidak terpenuhi. Jalur ini bisa terdiri dari lebih dari 1 jalur kemungkinan. - kondisi akhir (postconditions), yaitu kondisi spesifik yang harus terjadi ketika UC berhasil dijalankan atau dieksekusi secara lengkap, sebagai representasi dari tujuan yang ingin dicapai oleh aktor primer. Jumlah kondisi akhir bisa lebih dari 1 keadaan.
UC (Use Case) Diagram
Sebuah UC diagram menyatakan visualisasi interaksi yang terjadi antara pengguna (aktor) dengan sistem. Diagram ini bisa menjadi gambaran yang bagus untuk menjelaskan konteks dari sebuah sistem sehingga terlihat jelas batasan dari sistem (Larman, 2005). Ada 2 elemen penting yang harus digambarkan, yaitu aktor dan UC. Aktor adalah segala sesuatu yang berinteraksi langsung dengan sistem, bisa merupakan orang (yang ditunjukkan dengan perannya dan bukan namanya/personilnya) atau sistem komputer yang lain. Aktor dinotasikan dengan simbol gambar orang-orangan (stick-man) dengan nama kata benda di bagian bawah yang menyatakan peran/sistem. Aktor bisa bersifat primer, yaitu yang menginisiasi berjalannya sebuah UC, atau sekunder, yaitu yang membantu berjalannya sebuah UC. UC dinotasikan dengan simbol elips dengan nama kata kerja aktif di bagian dalam yang menyatakan aktivitas dari perspektif aktor. Setiap aktor dimungkinkan untuk berinteraksi dengan sistem dalam banyak UC. Sebaliknya, setiap UC bisa dijalankan oleh lebih dari satu aktor. Antar aktor maupun antar UC bisa memiliki relasi, masing-masing dengan spesifikasi yang berbeda. Sebuah UC, disebut dengan base UC, bisa memiliki relasi dengan 1 atau lebih UC yang lain, disebut dengan supplier UC, dalam bentuk extend dan/atau include. Relasi extend menyatakan bahwa fungsionalitas dari base UC bisa diperluas oleh supplier UC, jika dibutuhkan, di dalam aksekusi alur alternatif yang ada pada UC scenario dari base UC. Sedangkan, relasi include menyatakan bahwa fungsionalitas dari base UC selalu hanya bisa dipenuhi dengan bantuan dari supplier UC di dalam eksekusi alur utama yang ada pada UC scenario dari base UC. Dalam hal ini, relasi include dan extend tidak menjelaskan urutan eksekusi apapun antara base UC dan supplier UC, baik dalam alur utama maupun alternatif yang dijelaskan dalam UC scenario dari base UC. Selanjutnya, sebuah aktor, disebut aktor induk, bisa memiliki relasi inheritance dengan aktor yang lain, disebut aktor turunan, yang menyatakan bahwa sebuah aktor merupakan turunan dari aktor yang lain. Aktor turunan akan memiliki hak akses terhadap fungsionalitas sistem yang lebih luas dibandingkan dengan aktor induk. Gambar 1 mengilustrasikan sebuah UC diagram sederhana yang terdiri dari 2 buah aktor primer, yaitu Pengguna dan Teller, serta 1 aktor sekunder, yaitu Sistem Antar Bank. Sistem tersebut memiliki fungsionalitas yang direpresentasikan dalam 5 UC, yaitu Login, Cetak Tabungan, Simpan Dana, Transfer Dana, dan Hitung Saldo. Aktor Teller merupakan turunan dari aktor Pengguna, ketika Pengguna dinyatakan valid saat melakukan login. Siapapun bisa melakukan login, itulah yang disebut dengan Pengguna. Teller, saat mentransfer dana, bisa melibatkan proses perhitungan saldo jika transfer yang dilakukan menggunakan rekening nasabah (ditunjukkan dengan relasi extend). Di sisi lain, perhitungan saldo harus selalu dilakukan saat Teller melakukan penyimpanan dana di rekening nasabah (ditunjukkan dengan relasi include). Untuk mengakhiri akses, Teller melakukan logout.
Simbol-Simbol Use Case Diagram
Simbol | Deskripsi |
Use Case  | Use case adalah fungsionalitas yang disediakan sistem sebagai unit-unit yang saling bertukar pesan antar unit atau actor. biasanya use case diberikan penamaan dengan menggunakan kata kerja di awal frase nama use case |
Aktor / actor  | Aktor adalah orang, proses, atau sistem lain yang berinteraksi dengan sistem informasi yang akan dibuat, jadi meskipun simbol dari aktor ialah gambar orang, tapi aktor belum tentu merupakan orang. biasanya penamaan aktor dinamakan menggunakan kata benda di awal frase nama aktor |
Asosiasi / association  | Asosiasi adalah komunikasi antara aktor dan use case yang berpartisipasi pada use case diagram atau use case yang memiliki interaksi dengan aktor. Asosiasi merupakan simbol yang digunakan untuk menghubungkan link antar element. |
Ekstend / extend  | Relasi use case tambahan ke sebuah use case dimana use case yang ditambahkan dapat berdiri sendiri meski tanpa use case tambahan itu arah panah mengarah pada use case yang ditambahkan |
Include  | Relasi use case tambahan ke sebuah use case dimana use case yang ditambahkan membutuhkan use case ini untuk menjalankan fungsinya atau sebagai syarat dijalankan use case ini arah panah include mengarah pada use case yang dipakai (dibutuhkan) atau mengarah pada use case tambahan. |
Generalisasi / generalization  | Hubungan generalisasi dan spesialisasi (umum - khusus) antara dua buah use case dimana fungsi yang satu merupakan fungsi yang lebih umum dari lainnya arah panah mengarah pada use case yang menjadi generalisasinya (umum) |
Penjelasan Simbol Extend
Pada gambar diatas use case Validasi User merupakan use case yang ditambahkan, dimana use case ini dapat berdiri sendiri tanpa use case tambahan (Validasi Sidik Jari). pada contoh diatas setelah pengguna melakukan validasi user, pengguna dapat mengembangkannya (opsional) dengan validasi sidik jari atau tidak.
Contoh lainnya adalah seperti pada gambar diatas. use case Buka Rekening merupakan use case yang ditambahkan sehingga use case ini dapat berdiri sendiri sedangkan use case Buka Deposito dan Buat Kartu Kredit merupakan use case tambahan yang berasal dari pengembangan use case extend. pada contoh diatas setelah pengguna melakukan Buka Rekening, pengguna dapat mengembangkannya / melanjutkannya (opsional) dengan Buka Deposito / Buat Kartu Kredit.
Penjelasan Simbol Include
Pada gambar diatas Use Case Login merupakan syarat / selalu dipanggil terlebih dahulu sebelum dijalankannya use case Mengelola Anggota atau use case Mengelola Peminjaman.
Intinya perbedaan mendasar dari use case extend dan use case include adalah : use case extend digunakan untuk mengembangkan sebuah use case (use case inti) misalnya setelah melakukan Buka Rekening selanjutnya bisa melakukan apa lagi ?, dimana pada hubungan extend arah panah mengarah pada use case inti (use case ditambahkan). sedangkan use case include digunakan untuk menjelasakan bahwa sebuah use case memiliki sebuah syarat agar / ketentuan sebelum bisa dijalankan, misalnya saat kita akan mengelola anggota maka kita diwajibkan login terlebih dahulu. pada hubungan include arah panah mengarah pada use case tambahan (use case yang dipakai / dibutuhkan). Untuk semakin memperjelas, perhatikan contoh dibawah ini:
Penjelasan Simbol Generalisasi
Pada gambar diatas use case Mengelola Pustaka merupakan use case generalisasi / umum. sedangkan use case mencari pustaka, melihat pustaka, memasukkan pustaka, mengubah pustaka dan menghapus pustaka merupakan use case spesialisasi / khusus. hubungan generalisasi ini juga merupakan hubungan yang menggambarkan inheritance baik aktor maupun use case. pada hubungan generalisasi arah panah mengarah pada use case yang menjadi generalisasinya (umum).
Skenario use case dibuat per use case terkecil, misalkan untuk generalisasi maka scenario yang dibuat adalah use case yang lebih khusus. Skenario normal adalah scenario bila system berjalan normal tanpa terjadi kesalahan atau error. Sedangkan skenario alternatif adalah scenario bila system tidak berjalan normal atau mengalami error. Skenario normal dan skenario alternatif dapat berjumlah lebih dari satu. Alur skenario inilah yang nantinya menjadi landasan pembuatan sequence diagram / diagram sekuen.
Namun tidak semua Aktor adalah manusia, aktor juga dapat berupa sistem lain (yang berada diluar sistem yang akan dibuat), ciri system sebagai actor adalah sebagai berikut:
Untuk kasus sistem lain yang bertindak sebagai aktor, dapat di ilustrasikan sebagai berikut : misalkan sebuah Sistem Akademik baru dapat menampilkan nilai mahasiswa apabila pembayaran mahasiswa sudah lunas, artinya system akademik memerlukan info dari sistem pembayaran. maka saat kita akan memodelkan use case diagram Sistem Akademik, kita akan memasukkan sistem pembayaran sebagai aktor.
Untuk menemukan use cases, mulailah dari sudut pandang aktor, misalnya dengan bertanya:
Sedangkan dari sudut pandang sistem, misalnya dengan pertanyaan sebagai berikut:
Penjelasan Simbol Include
Intinya perbedaan mendasar dari use case extend dan use case include adalah : use case extend digunakan untuk mengembangkan sebuah use case (use case inti) misalnya setelah melakukan Buka Rekening selanjutnya bisa melakukan apa lagi ?, dimana pada hubungan extend arah panah mengarah pada use case inti (use case ditambahkan). sedangkan use case include digunakan untuk menjelasakan bahwa sebuah use case memiliki sebuah syarat agar / ketentuan sebelum bisa dijalankan, misalnya saat kita akan mengelola anggota maka kita diwajibkan login terlebih dahulu. pada hubungan include arah panah mengarah pada use case tambahan (use case yang dipakai / dibutuhkan). Untuk semakin memperjelas, perhatikan contoh dibawah ini:
 |
| Perbedaan Include dan Extend |
Penjelasan Simbol Generalisasi
Use Case Skenario
Setiap use case diagram dilengkapi dengan skenario, skenario use case / use case skenario adalah alur jalannya proses use case dari sisi aktor dan system. Berikut adalah format tabel skenario use case.Nama Aktor | Reaksi Sistem |
Skenario Normal | |
Skenario Alternatif | |
Skenario use case dibuat per use case terkecil, misalkan untuk generalisasi maka scenario yang dibuat adalah use case yang lebih khusus. Skenario normal adalah scenario bila system berjalan normal tanpa terjadi kesalahan atau error. Sedangkan skenario alternatif adalah scenario bila system tidak berjalan normal atau mengalami error. Skenario normal dan skenario alternatif dapat berjumlah lebih dari satu. Alur skenario inilah yang nantinya menjadi landasan pembuatan sequence diagram / diagram sekuen.
Menentukan Aktor pada Use Case Diagram
Aktor adalah segala hal diluar sistem yang akan menggunakan sistem tersebut untuk melakukan sesuatu (Kurt Bittner, Ian Spence. 2002). Cara termudah untuk menemukan aktor adalah dengan bertanya "SIAPA yang akan menggunakan sistem ?"Namun tidak semua Aktor adalah manusia, aktor juga dapat berupa sistem lain (yang berada diluar sistem yang akan dibuat), ciri system sebagai actor adalah sebagai berikut:
- Jika system yang akan dibuat / dimodelkan bergantung pada sistem lain untuk melakukan sesuatu, maka sistem lain itu adalah aktor.
- Jika sistem yang akan dibuat / dimodelkan meminta (request) informasi dari sistem lain, maka sistem lain itu adalah aktor
Untuk kasus sistem lain yang bertindak sebagai aktor, dapat di ilustrasikan sebagai berikut : misalkan sebuah Sistem Akademik baru dapat menampilkan nilai mahasiswa apabila pembayaran mahasiswa sudah lunas, artinya system akademik memerlukan info dari sistem pembayaran. maka saat kita akan memodelkan use case diagram Sistem Akademik, kita akan memasukkan sistem pembayaran sebagai aktor.
Menentukan Use Case pada Use Case Diagram
Sebuah use case harus mendeskripsikan sebuah pekerjaan dimana pekerjaan tersebut akan memberikan NILAI yang bermanfaat bagi aktor (Kurt Bittner, Ian Spence. 2002).Untuk menemukan use cases, mulailah dari sudut pandang aktor, misalnya dengan bertanya:
- Informasi apa sajakah yang akan didapatkan aktor dari sistem ?
- Apakah ada kejadian dari sistem yang perlu diberitahukan ke aktor ?
Sedangkan dari sudut pandang sistem, misalnya dengan pertanyaan sebagai berikut:
- Apakah ada informasi yang perlu disimpan atau diambil dari sistem ?
- Apakah ada informasi yang harus dimasukkan oleh aktor?
Pengertian ini penting untuk diingat, karena dari hal inilah akan menentukan bahwa sebuah use case tidak akan menjadi terlalu kecil. Karena use case yang terlalu kecil tidak akan memberikan nilai bagi aktor.
PERHATIKAN STUDI KASUS DIBAWAH INI
Studi Kasus
Studi kasus ini juga akan digunakan pada berbagai macam diagram pemodelan di beberapa artikel lain. Diharapkan dengan adanya studi kasus yang menyatu, sobat dapat lebih memahami proses pemodelan dengan berbagai macam diagram pemodelan pada proses rekayasa perangkat lunak. Berikut studi kasus yang akan kita gunakan:
Nama Aplikasi: Sistem Informasi Manajemen Perpustakaan
Deskripsi:
Sistem informasi manajemen perpustakaan adalah sebuah sistem informasi untuk mengelola informasi yang diperlukan dalam sebuah perpustakaan yang meliputi pengelolaan pustaka, pengelolaan anggota, pengelolaan petugas dan pengelolaan peminjaman pustaka. Aturan perpustakaan yang harus dipenuhi pada sistem informasi manajemen perpustakaan yang akan dimodelkan adalah sebagai berikut:
- Pustaka dapat memiliki lebih dari satu pengarang
- Anggota dapat meminjam lebih dari satu buku (pustaka) dalam satu waktu (waktu yang bersamaan)
- Anggota dapat memiliki lebih dari satu nomor telepon
- Anggota dapat mengembalikan pustaka yang dipinjam tidak dalam waktu yang bersamaan, meskipun pustaka-pustaka tersebut dipinjam pada waktu yang bersamaan.
- Pengunjung yang bukan anggota diperbolehkan mencari data pustaka yang ingin dibacanya.
- Pengunjung yang bukan anggota tidak diperbolehkan meminjam pustaka.
- Proses pendaftaran pustaka, anggota, dan peminjaman dilakukan oleh petugas perpustakaan.
- Anggota dan pengunjung dapat melakukan pencarian pustaka.
- Satu pustaka akan disimpan sebagai satu data dengan id yang unik
Sistem Informasi Manajemen Perpustakaan yang akan dimodelkan memiliki fungsi-fungsi sebagai berikut:
Validasi Petugas
- Login
Mengelola data Pustaka
- Memasukkan data pustaka baru
- Mengubah data pustaka
- Menghapus data pustaka
- Mencari data pustaka
- Melihat data pustaka
Mengelola data petugas
- Memasukkan data petugas baru
- Mengubah data petugas
- Menghapus data petugas
- Mencari data petugas
- Melihat data petugas
Mengelola data Anggota
- Memasukkan data anggota baru
- Mengubah data anggota
- Menghapus data anggota
- Mencari data anggota
- Melihat data anggota
Mengelola data Peminjaman
- Memasukkan data peminjaman
- Mengubah data peminjaman
- Mencari data peminjaman
- Melihat data peminjaman
Penyelesaian Studi Kasus menjadi sebuah Use Case Diagram
Untuk menyelesaikan studi kasus diatas menjadi sebuah use case diagram, umumnya terdapat 4 tahapan yang harus dilalui yaitu :
- Pendefinisian Aktor
- Pendefinisian Use Case
- Pembuatan Use Case Skenario
- Menggambarkan Use Case Diagram
Untuk lebih jelasnya, mari langsung saja kita menuju ke tahapan pertama.
1. Pendefinisian Aktor
Berikut adalah hasil pendefinisian aktor pada Sistem Informasi Manajemen Perpustakaan:
No | Aktor | Deskripsi |
1 | Petugas Perpustakaan | Petugas perpustakaan adalah orang yang bertugas dan memiliki hak akses untuk melakukan operasi pengelolaan data pustaka, anggota, dan proses peminjaman pustaka |
2 | Anggota / Pengunjung Perpustakaan | Anggota adalah orang yang diperbolehkan meminjam pustaka sesuai dengan hak aksesnya, sedangkan pengunjung hanya memiliki hak akses melihat pustaka dan membaca di perpustakaan tanpa memiliki hak untuk meminjam pustaka. |
2. Pendefinisian Use Case
Berikut adalah hasil pendefinisian use case pada Sistem Informasi Manajemen Perpustakaan:
3. Pembuatan Use Case Skenario
Berikut adalah hasil pendefinisian beberapa use case skenaio (tidak kami sertakan semua) dari masing-masing use case yang telah didefinisikan sebelumnya:
Nama Use Case : Login
Skenario:
Nama Use Case : Memasukkan Pustaka
Skenario:
Nama Use Case : Melihat Pustaka
Skenario:
Nama Use Case : Mengubah Pustaka
Skenario:
Nama Use Case : Menghapus Pustaka
Skenario:
Nama Use Case : Mencari Pustaka
Skenario:
4. Menggambarkan Use Case Diagram
Berikut adalah hasil pendefinisian use case pada Sistem Informasi Manajemen Perpustakaan:
No | Use Case | Deskripsi |
1 | Login | Merupakan proses untuk melakukan login petugas perpustakaan |
2 | Mengelola Pustaka | Mengelola Pustaka merupakan proses pengelolaan data pustaka yang meliputi memasukkan pustaka, melihat pustaka, mengubah pustaka, menghapus pustaka dan mencari pustaka. |
3 | Memasukkan Pustaka | Merupakan proses memasukkan data pustaka ke dalam basis data |
4 | Melihat Pustaka | Merupakan proses menampilkan data pustaka yang ada di dalam basis data |
5 | Mengubah Pustaka | Merupakan proses mengubah data pustaka yang ada di dalam basis data |
6 | Menghapus Pustaka | Merupakan proses menghapus data pustaka yang ada di dalam basis data |
7 | Mencari Pustaka | Merupakan proses mencari data pustaka yang ada di dalam basis data |
8 | Mengelola Anggota | Mengelola Anggota merupakan proses pengelolaan data anggota yang meliputi memasukkan anggota, melihat anggota, mengubah anggota, menghapus anggota dan mencari anggota. |
9 | Memasukkan Anggota | Merupakan proses memasukkan data anggota ke dalam basis data |
10 | Melihat Anggota | Merupakan proses menampilkan data anggota yang ada di dalam basis data |
11 | Mengubah Anggota | Merupakan proses mengubah data anggota yang ada di dalam basis data |
12 | Menghapus Anggota | Merupakan proses menghapus data anggota yang ada di dalam basis data |
13 | Mencari Anggota | Merupakan proses mencari data anggota yang ada di dalam basis data |
14 | Mengelola Peminjaman | Mengelola Peminjaman merupakan proses pengelolaan data peminjaman yang meliputi memasukkan peminjaman, melihat peminjaman, mengubah peminjaman, menghapus peminjaman dan mencari peminjaman. |
15 | Memasukkan Peminjaman | Merupakan proses memasukkan data peminjaman ketika ada anggota yang meminjam pustaka |
16 | Melihat Peminjaman | Merupakan proses menampilkan / melihat data peminjaman yang ada di dalam basis data |
17 | Mengubah Peminjaman | Merupakan proses mengubah data peminjaman yang dapat dilakukan untuk mengubah status peminjaman begitu pustaka dikembalikan |
18 | Menghapus Peminjaman | Merupakan proses menghapus data peminjaman jika ternyata peminjaman tidak jadi dilakukan atau data sudah terlalu banyak dan data sudah di backup terlebih dahulu |
19 | Mencari Peminjaman | Merupakan proses mencari data peminjaman yang ada di dalam basis data |
20 | Mengelola Petugas | Mengelola Petugas merupakan proses pengelolaan data pemtugas yang meliputi memasukkan petugas, melihat petugas, mengubah petugas, menghapus petugas dan mencari petugas. |
21 | Memasukkan Petugas | Merupakan proses memasukkan data petugas ke dalam basis data |
22 | Melihat Petugas | Merupakan proses menampilkan data petugas yang ada di dalam basis data |
23 | Mengubah Petugas | Merupakan proses mengubah data petugas yang ada di dalam basis data |
24 | Menghapus Petugas | Merupakan proses menghapus data petugas yang ada di dalam basis data |
25 | Mencari Petugas | Merupakan proses mencari data petugas yang ada di basis data |
3. Pembuatan Use Case Skenario
Berikut adalah hasil pendefinisian beberapa use case skenaio (tidak kami sertakan semua) dari masing-masing use case yang telah didefinisikan sebelumnya:
Nama Use Case : Login
Skenario:
Aksi Aktor | Reaksi Sistem |
Skenario Normal | |
1. Memasukka username dan password | |
2. Memeriksa valid tidaknya data masukan dengan memeriksa ke tabel petugas | |
3. Masuk ke aplikasi pengelolaan data perpustakaan | |
Skenario Alternatif | |
1. Memasukkan username dan password | |
2. Memeriksa valid tidaknya data masukan dengan memeriksa ke tabel petugas | |
3. Menampilkan pesan login tidak valid | |
4. Memasukkan username dan password yang valid | |
5. Memeriksa valid tidaknya data masukan dengan memriksa ke tabel petugas | |
6. Masuk ke aplikasi pengelolaan data perpustakaan | |
Nama Use Case : Memasukkan Pustaka
Skenario:
Aksi Aktor | Reaksi Sistem |
Skenario Normal | |
1. Memeriksa status login | |
2. Memasukkan data pustaka sesuai kolom yang ada | |
3. Memeriksa valid tidaknya data masukan | |
4. Menyimpan data pustaka ke basis data | |
5. Menampilkan pesan sukses disimpan | |
Skenario Alternatif | |
1. Memeriksa status login | |
2. Memasukkan data pustaka sesuai kolom yang ada | |
3. Memeriksa valid tidaknya data masukan | |
4. Mengeluarkan pesan bahwa data masukan tidak valid | |
5. Memperbaiki data masukan yang tidak valid | |
6. Memeriksa valid tidaknya data masukan | |
7. Menyimpan data pustaka ke basis data | |
8. Menampilkan pesan sukses disimpan | |
Nama Use Case : Melihat Pustaka
Skenario:
Aksi Aktor | Reaksi Sistem |
Skenario Normal | |
1. Memeriksa status login | |
2. Menampilkan data pustaka yang dicari (belum detail, missal hanya judulnya saja dan tampil dalam bentuk list) | |
3. Memilih pustaka yang dicari | |
4. Menampilkan data pustaka (detail sebuah data pustaka) dari pustaka yang dipilih | |
Nama Use Case : Mengubah Pustaka
Skenario:
Aksi Aktor | Reaksi Sistem |
Skenario Normal | |
1. Memeriksa status login | |
2. Memasukkan kata kunci dan kategori pencarian | |
3. Mencari data pustaka yang akan diubah | |
4. Menampilkan data pustaka yang dicari (belum detail, missal hanya judulnya saja dan tampil dalam bentuk list) | |
5. Memilih data pustaka yang akan diubah | |
6. Menampilkan data pustaka (detail sebuah data pustaka) dari pustaka yang akan diubah | |
7. Mengubah data pustaka | |
8. Memeriksa valid tidaknya data masukan | |
9. Menyimpan data yang telah diubah ke basis data | |
10. Menampilkan pesan bahwa data sukses disimpan | |
Skenario Alternatif | |
1. Memeriksa status login | |
2. Memasukkan kata kunci dan kategori pencarian | |
3. Mencari data pustaka yang akan diubah | |
4. Menampilkan data pustaka yang dicari (belum detail, missal hanya judulnya saja dan tampil dalam bentuk list) | |
5. Memilih data pustaka yang akan diubah | |
6. Menampilkan data pustaka (detail sebuah data pustaka) dari pustaka yang akan diubah | |
7. Mengubah data pustaka | |
8. Memeriksa valid tidaknya data masukan | |
9. Menampilkan pesan bahwa data masukan tidak valid | |
10. Memperbaiki data masukan yang diubah dan tidak valid | |
11. Memeriksa valid tidaknya data masukan | |
12. Menyimpan data yang telah diubah ke basis data | |
13. Menampilkan pesan bahwa data sukses disimpan | |
Nama Use Case : Menghapus Pustaka
Skenario:
Aksi Aktor | Reaksi Sistem |
Skenario Normal | |
1. Memeriksa status login | |
2. Memasukkan kata kunci dan kategori pencarian | |
3. Mencari data pustaka yang akan dihapus | |
4. Menampilkan data pustaka yang dicari (belum detail, missal hanya judulnya saja dan tampil dalam bentuk list) | |
5. Memilih data pustaka yang akan dihapus | |
6. Menampilkan pesan konfirmasi apakah data akan benar-benar dihapus | |
7. Mengklik pilihan setuju data dihapus | |
8. Menghapus data pustaka dari basis data | |
9. Menampilkan pesan bahwa data sukses dihapus | |
Skenario Alternatif | |
1. Memeriksa status login | |
2. Memasukkan kata kunci dan kategori pencarian | |
3. Mencari data pustaka yang akan dihapus | |
4. Menampilkan data pustaka yang dicari (belum detail, missal hanya judulnya saja dan tampil dalam bentuk list) | |
5. Memilih data pustaka yang akan dihapus | |
6. Menampilkan pesan konfirmasi apakah data akan benar-benar dihapus | |
7. Mengklik pilihan tidak setuju data dihapus | |
8. Kembali ke form pencarian pustaka | |
Nama Use Case : Mencari Pustaka
Skenario:
Aksi Aktor | Reaksi Sistem |
Skenario Normal | |
1. Memasukkan kata kunci dan kategori pencarian | |
2. Mencari data pustaka yang dicari | |
3. Menampilkan data pustaka yang dicari (belum detail, missal hanya judulnya saja dan tampil dalam bentuk list) | |
4. Memilih data pustaka yang akan dicari | |
5. Menampilkan data pustaka (detail sebuah data pustaka) dari pustaka yang dipilih | |
Skenario Alternatif | |
1. Memasukkan kata kunci dan kategori pencarian | |
2. Mencari data pustaka yang dicari | |
3. Menampilkan pesan data pustaka tidak ada | |
4. Memasukkan kata kunci dan kategori pencarian | |
5. Mencari data pustaka yang dicari | |
6. Menampilkan data pustaka yang dicari (belum detail, missal hanya judulnya saja dan tampil dalam bentuk list) | |
7. Memilih data pustaka yang akan dicari | |
8. Menampilkan data pustaka (detail sebuah data pustaka) dari pustaka yang dipilih | |
4. Menggambarkan Use Case Diagram
Berikut adalah use case diagram / diagram use case dari Sistem Informasi Manajemen Perpustakaan:
 |
| Use case diagram sistem informasi manajemen perpustakaan |
TUGAS KELOMPOK
- DI CETAK DAN DIBERIKAN SAMPUL BESERTA NAMA KELOMPOK
- DI MINTAKAN TANDA TANGAN DAN CAP GURU PIKET
- KETIKA JAM PELAJARAN HABIS DAN BELUM MENGUMPULKAN MAKA TIDAK DIBERIKAN PENILAIAN
- 1 KELOMPOK MAKSIMAL 3 ORANG
- TUGAS 1 KELOMPOK DAN KELOMPOK LAIN HARUS BERBEDA
Buatlah salah satu studi kasus pembuatan Use Case seperti contoh studi kasus diatas. Dengan kasus yang tidak boleh sama dengan contoh studi kasus diatas. Namun, penyelesaiannya harus sama dengan alur penyelesaian studi kasus pada contoh.
SELAMAT MENGERJAKAN
Tags:
smkn1jatiroto