ANALISIS USE CASE

Pengertian Use Case

• Dalam membuat sebuah sistem, langkah awal yang perlu dilakukan adalah menentukan kebutuhan
• Terdapat dua jenis kebutuhan :

1. Kebutuhan fungsional adalah kebutuhan pengguna dan stakeholder sehari-hari yang akan dimiliki oleh sistem, dimana kebutuhan ini akan digunakan oleh pengguna dan stakeholder.
2. -    Kebutuhan nonfungsional adalah kebutuhan yang memperhatikan hal-hal berikut yaitu performansi, kemudahan dalam menggunakan sistem, kehandalan sistem, keamanan sistem, keuangan, legalitas, dan operasional. (Nick Jenkins, 2005).

Kebutuhan fungsional akan digambarkan melalui sebuah diagram yang dinamakan diagram use case.

• Use Case Diagram atau diagram use case merupakan pemodelan untuk menggambarkan kelakuan (behavior) sistem yang akan dibuat.
• Diagram use case mendeskripsikan sebuah interaksi antara satu atau lebih aktor dengan sistem yang akan dibuat
• Singkatnya, Diagram use case digunakan untuk mengetahui fungsi apa saja yang ada di dalam sebuah sistem dan siapa saja yang berhak menggunakan fungsi-fungsi tersebut.
• Terdapat beberapa simbol dalam menggambarkan diagram use case, yaitu use cases, aktor dan relasi. Simbol ini akan dijelaskan pada Bab 6.
• Diagram use case bukan menggambarkan tampilan antarmuka (user interface)
• Penamaan use cases adalah nama didefinisikan sesimpel mungkin, dapat dipahami dan menggunakan kata kerja.

Menemukan Aktor

• Pekerjaan awal menemukan aktor, menemukan fungsionalitas dan membatasi sistem yang akan dibuat.
• Pembatasan sistem ini penting untuk menemukan aktor. Karena dari sinilah kita akan menentukan apakah sesuatu itu adalah aktor dan apakah aktor tersebut akan berbentuk orang atau sistem lain.
• Aktor adalah segala hal diluar sistem yang akan menggunakan sistem tersebut untuk melakukan sesuatu (Kurt Bittner, Ian Spence. 2002).   
• Cara mudah untuk menemukan aktor adalah dengan bertanya hal-hal berikut:
• SIAPA yang akan menggunakan sistem?
• APAKAH sistem tersebut akan memberikan NILAI bagi aktor?
• Tidak semua aktor adalah manusia, bisa saja sistem lain yang berinteraksi dengan sistem yang anda buat.
• Untuk menemukan sistem lain sebagai aktor, hal-hal di bawah ini bisa menjadi pertimbangan :
• Jika anda bergantung pada sistem lain untuk melakukan sesuatu, maka sistem lain itu adalah aktor.
• Jika sistem lain itu meminta (request) informasi dari sistem anda, maka sistem lain itu adalah aktor
• Untuk penamaan aktor diberi nama sesuai dengan PERAN-nya
• Contoh, pada sistem pencatatan penjualan di Supermarket.

Jadi, Yang Merupakan Aktor

• INGAT !! Dalam kasus ini, PELANGGAN tidak berinteraksi langsung dengan sistem, KASIR yang berinteraksi langsung dengan sistem
• Sistem dibangun untuk menyediakan kebutuhan bagi aktor, jika suatu saat nanti stakeholder akan menentukan bahwa sistem pencatatan penjualan akan berinteraksi dengan pelanggan, maka aktor di atas pun tentu saja akan berubah.
• Inilah yang dimaksud dengan batasan sistem.
• Stakeholder dan pengguna akan menentukan batasan sistem yang akan dibuat.

Menemukan Use Case

• Jika anda sudah berhasil menemukan aktor
• Maka untuk menemukan use case akan lebih mudah dilakukan.
• 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?

Kesalahan yang sering muncul di diagram use case (Kurt Bittner, Ian Spence. 2002)

• Seringkali sebuah use case dianggap sebagai sebuah “function” atau item menu. Hal ini adalah salah. Perhatikan contoh berikut:

Diagram use case pemesanan.  Diambil dari Kurt Bittner, Ian Spence. 2002. 

• Use case di atas menggambarkan mengenai apa yang harus dilakukan oleh sistem yang terdiri dari beberapa proses yaitu menyetujui pemesanan, memesan informasi, mengubah pemesanan, menghapus pemesanan, dan menambah pemesanan.
• diagram di atas memperlihatkan proses penguraian fungsi-fungsi (functional decomposition) yaitu mengurai proses kedalam bagian yang lebih kecil.
• Hal ini adalah salah karena use case di atas tidak memberikan nilai kepada aktor.
• Diagram use case adalah sebuah diagram yang menjelaskan apa yang harus dilakukan oleh sistem pada level konseptual sehingga kita akan memahami apakah keputusan yang diambil oleh sistem adalah benar atau tidak.
• Cobalah bertanya seperti ini: Apakah saya akan menggunakan proses mengubah pemesanan jika saya tidak pernah melakukan pemesanan? Tentu saja tidak. Semua proses di atas akan menjadi berguna jika terdapat proses melakukan pemesanan, dan semua proses di atas sebenarnya berkaitan dengan melakukan pemesanan.

Apa yang salah dari diagram di atas?

• Diagram di atas tidak memberikan nilai kepada aktor, atau dengan kata lain jika kita menggambarkan diagram seperti di atas, nilai akan menjadi hilang.
• Sebuah use case seharusnya dibuat untuk menghasilkan suatu nilai kepada aktor, pada level tertentu jika aktor melakukan pemesanan maka proses tersebut akan memberikan nilai kepada aktor.
• Tapi jika proses pemesanan saja tidak pernah dilakukan, apakah hal ini akan memberikan nilai? Tentu saja tidak.

Diagram yang BENAR

• Oleh karena itu, gambarlah diagram use case yang berfokus pada nilai yang akan diberikan kepada aktor.

Simbol-simbol pada Use case

Use Case Diagram

ACTOR-USE CASE DIAGRAM

• Tidak boleh ada komunikasi langsung antar actor (Actors don’t interact with one another )

ACTOR-USE CASE DIAGRAM

• Letakkan actor utama anda pada pojok kiri atas dari diagram (in western culture people read from left to right, top to bottom)
• Actor jangan digambarkan ditengah-tengah use cases

RELATIONSHIP

• Ada 4 jenis relasi yang bisa timbul pada use case diagram
• Association antara actor dan use case
• Association antara use case :
• Include
• Extend
• Generalization/Inheritance antara use case
• Generalization/Inheritance antara actors

Assocciation – Use Case Diagram

Association antara actor dan use case

• Ujung panah pada association antara actor dan use case mengindikasikan siapa/apa yang meminta interaksi dan bukannya mengindikasikan aliran data
• Sebaiknya gunakan garis tanpa panah untuk association antara actor dan use case
• association antara actor dan use case yang menggunakan panah terbuka untuk mengindikasikan bila actor berinteraksi secara pasif dengan system anda.

Include

• X include Y berarti use case X menggunakan use case Y sepenuhnya
• Include digunakan untuk menghindari redundansi flow of event (seperti fungsi)

Contoh Include

Extend

Generalisasi

• Hubungan antara induk dan anak
• Anak mewarisi sifat dan method dari induk
• Induk disebut root / base
• Terbagi menjadi 2
• Actor Generalization
• Use Case Generalization

Generalisasi Use case

• Use case anak mewarisi arti dari use case
• induk sambil menambahkan/memodifikasi
• behaviour dari induk

Generalisasi Actor

System Boundary Boxes

• Merupakan batas antara sistem dan aktor
• Biasa dinotasikan dengan bujur sangkar
• Semua use case harus berada didalam system boundary

Deskripsi Use Case

• Setiap use case harus dijelaskan alur prosesnya melalui sebuah deskripsi use case (use case description) atau scenario use case
• Deskripsi use case berisi:
• Nama use case yaitu penamaan use case yang menggunakan kata kerja
• Deskripsi yaitu penjelasan mengenai tujuan use case dan nilai yang akan didapatkan oleh aktor
• Kondisi sebelum (pre-condition) yaitu kondisi-kondisi yang perlu ada sebelum use case dilakukan.

• Kondisi sesudah (post-condition) yaitu kondisi-kondisi yang sudah dipenuhi ketika uses case sudah dilaksanakan
• Alur dasar (basic flow) yaitu alur yang menceritakan jika semua aksi yang dilakukan adalah benar atau proses yang harusnya terjadi
• Alur alternatif (alternatif flow) yaitu alur yang menceritakan aksi alternatif, yang berbeda dari alur dasar.

Contoh Deskripsi dengan Tabel

Identifikasi Masalah
Nama	Login
Tujuan	Masuk ke dalam sistem sebagai pengguna
Deskripsi	Proses login ini sebagai  autentifikasi  kewenangan sebagai pengguna  dalam sistem
Aktor	Semua Pengguna
Usecase Yang Berkaitan	-
Skenario Utama
Kondisi Awal	Form Login di tampilkan
Aksi Aktor	Reaksi Sistem
Mengisi form Login	Mengautentifikasi data login dengan data pengguna pada basis data
	Menampilkan halaman utama untuk pengguna
Skenario Alternatif (Jika Gagal)
Aksi Aktor	Reaksi Sistem
	Menampilkan pesan tidak terdaftar di database
	Menampilkan form Login
Mengisi Kembali form Login
	Menampilkan pesan bahwa data login salah
	Mengautentifikasi data login dengan data pengguna pada basis data
	Menampilkan halaman utama untuk pengguna
Kondisi Akhir	Pengguna dapat melakukan kegiatan pada sistem sesuai kewenangan  masing-masing