Usecase diagram & usecase scenario

 Josua SIregar_11321012_D3TI

Usecase diagram & Usecase scenario

Mengapa Usecase?

Dalam perangkat lunak ada beberapa cara pendekatan model Dua cara yang paling umum adalah dari perspektif algoritmik dan dari perspektif berorientasi objek.

• Dalam pandangan tradisional pengembangan perangkat lunak membutuhkan perspektif algoritmik, blok pembangun utama dari perangkat lunak adalah prosedur atau fungsi. Saat kebutuhan berubah dan sistem berkembang, sistem dibangun dengan fokus algoritmik ternyata sangat sulit untuk dipertahankan.
• Dalam Operspektif blok bangunan utama jatuh sistem perangkat lunak adalah objek atau kelas.

PEMODELAN OBJEKTORORIENT

Pemodelan berorientasi objek muncul antara pertengahan 1970-an dan akhir 1980-an.

• UML awalnya dimotivasi oleh keinginan untuk menstandarisasi sistem notasi yang berbeda dan pendekatan untuk desain perangkat lunak yang dikembangkan oleh Grady Booch,Ivar Jacobson and James Rumbaughat, Rasional Perangkat lunak pada tahun 1994–1995.
• UML adalah bahasa untuk memvisualisasikan, menentukan, membangun, mendokumentasikan artefak sistem perangkat lunak intensif.

UML DIAGRAM 

• Class diagram 
• Object diagram 
• Sequence diagram 
• Collaboration diagram 
• Statechart diagram 
• Activity diagram 
• Component diagram 
• Deployment diagram

APA ITU USECASE?

Cara formal untuk merepresentasikan bagaimana sistem bisnis berinteraksi dengan lingkungannya Menggambarkan aktivitas yang dilakukan oleh pengguna sistem. Teknik berbasis skenario dalam UML Urutan tindakan yang dilakukan sistem yang menghasilkan hasil yang berharga untuk aktor tertentu.

USECASE ANALYSIS

Apa itu actor?

Seorang pengguna atau sistem luar yang berinteraksi dengan sistem yang sedang dirancang untuk mendapatkan beberapa nilai dari interaksi itu. Usecase menggambarkan skenario yang menggambarkan interaksi antara Pengguna sistem (aktor) dan sistem itu sendiri.

Usecase

Usecase diagram menggambarkan apa yang dilakukan sistem dari sudut pandang dari pengamat luar. Penekanannya adalah pada apa yang dilakukan sistem daripada bagaimana. Use case diagram berhubungan erat dengan skenario. Skenario adalah contoh dari apa yang terjadi ketika seseorang berinteraksi dengan sistem.

Langkah 1. Identifikasi aktor

Seperti yang telah kita baca skenario, tentukan orang atau sistem tersebut yang akan berinteraksi dengan skenario. "Seorang pasien menelepon klinik untuk membuat janji setahun sekali pemeriksaan. Resepsionis menemukan waktu yang tepat waktu slot di buku janji temu dan jadwalkan janji temu untuk slot waktu itu.".

Pertanyaan untuk Mengidentifikasi aktor orang

1. Siapa yang tertarik dengan skenario/sistem?
2. Di mana organisasi adalah skenario/sistem digunakan?
3. Siapa yang akan mendapat manfaat dari penggunaan skenario/sistem?
4. Siapa yang akan menyediakan skenario/sistem dengan informasi ini, menggunakan informasi ini, dan menghapus informasi ini?
5. Apakah satu orang memainkan beberapa peran yang berbeda?
6. Apakah beberapa orang memainkan peran yang sama?
   

Pertanyaan untuk Mengidentifikasi aktor lain

1. Apa entitas lain yang tertarik dengan skenario/sistem?
2. Apa entitas lain yang akan menyediakan skenario/sistem dengan ini informasi, menggunakan informasi ini, dan menghapus informasi ini?
3. Apakah sistem menggunakan sumber daya eksternal?
4. Apakah sistem berinteraksi dengan sistem lama?

ACTORS

Aktor berada di luar atau di luar sistem Itu bisa berupa:

• Manusia
• External system or sub system
• Time or time - based event
• Perangkat Peripheral (hardware) Diwakili oleh stickfigure

Usecase adalah ringkasan skenario untuk satu tugas atau tujuan. Aktor adalah siapa atau apa yang memprakarsai peristiwa yang terlibat dalam tugas kasus penggunaan. Aktor menyiratkan peran yang dimainkan orang atau objek. Jadi saat kita membaca skenario kita, apa atau siapa aktornya?

Jadi saat kita membaca skenario kita, apa atau siapa aktornya? 

"Seorang pasien menelepon klinik untuk membuat janji untuk pemeriksaan tahunan. Resepsionis menemukan slot waktu kosong terdekat di buku janji dan jadwal janji untuk slot waktu itu.". Aktornya = Pasien

Contoh kasus adalah contoh penggunaan Make Appointment untuk klinik medis. Aktor adalah Pasien. Hubungan antara aktor dan kasus penggunaan adalah komunikasi asosiasi (atau singkatnya komunikasi). Aktor adalah sosok tongkat. Kasus penggunaan berbentuk oval. Komunikasi adalah garis Aktor adalah sosok tongkat. Kasus penggunaan berbentuk oval. Komunikasi adalah jalur yang menghubungkan aktor untuk menggunakan kasus.

Usecase components

Usecase memiliki tiga komponen. Tugas usecase disebut sebagai usecase yang mewakili fitur dibutuhkan dalam sistem perangkat lunak Aktor yang memicu usecase untuk diaktifkan. Saluran komunikasi untuk menunjukkan bagaimana aktor berkomunikasi dengan kasus penggunaan.

Usecase diagram-usecase

Proses utama yang dilakukan oleh sistem yang menguntungkan aktor dalam beberapa cara model dialog antara aktor dan sistem Mewakili fungsionalitas yang disediakan oleh sistem usecase  yang digunakan dalam diagram kasus menggambarkan satu dan hanya satu fungsi di mana pengguna berinteraksi dengan sistem. 

Mungkin berisi beberapa "jalur" yang dapat diambil oleh pengguna saat berinteraksi dengan sistem. Setiap jalur disebut sebagai skenario.

Usecase

Diberi label menggunakan frase kata kerja-kata benda deskriptif diwakili oleh lingkaran.

Usecase actor

Dilabeli menggunakan kata benda atau frasa deskriptif

Usecase relationship

Relationships:

• Mewakili komunikasi antara aktor dan use case
• Digambarkan dengan garis atau garis panah berkepala dua
• Disebut juga hubungan asosiasi 

Boundary

Sebuah persegi panjang batas ditempatkan di sekeliling sistem untuk menunjukkan bagaimana aktor berkomunikasi dengan sistem. Dilabeli menggunakan kata benda atau frasa deskriptif.

Usecase diagram

Diagram usecase adalah kumpulan aktor, use case, dan komunikasi mereka.

Jenis Hubungan Lain untuk Kasus Penggunaan

1. Generalization 
2. Include 
3. Extend

Generalization relathion: diwakili oleh garis dan panah berlubang dari anak ke orang tua.

Include relathion: Mewakili penyertaan fungsionalitas satu kasus penggunaan dalam yang lain. Panah diambil dari kasus penggunaan dasar ke kasus penggunaan yang digunakan. Tulis << include >> di atas garis panah.

Extend ralathion: Mewakili perpanjangan kasus penggunaan untuk menyertakan fungsionalitas opsional. Panah diambil dari kasus penggunaan ekstensi ke kasus penggunaan dasar. Tulis << extend >> di atas garis panah.

Manfaat Usecase

Usecase adalah kendaraan utama untuk menangkap persyaratan di RUP Kasus penggunaan dijelaskan menggunakan bahasa pelanggan (bahasa domain yang didefinisikan dalam glosarium). Usecase menyediakan proses pengiriman kontrak (RUP adalah Use Case Driven). Usecase menyediakan mekanisme komunikasi yang mudah dipahami. Ketika persyaratan dilacak, mereka mempersulit persyaratan untuk jatuh melaluimretak. Gunakan kasus memberikan ringkasan singkat tentang apa sistem harus dilakukan pada tingkat abstrak (biaya modifikasi rendah).

Kesulitan dengan Usecase

Sebagai dekomposisi fungsional, seringkali sulit untuk melakukan transisi dari fungsional deskripsi ke deskripsi objek ke desain kelas Penggunaan kembali di tingkat kelas dapat dihalangi oleh setiap pengembang yang “mengambil UseCase and running with it”. Karena UC tidak berbicara tentang kelas, pengembang sering kali kehabisan ruang hampa selama objek analisis, dan sering kali dapat menyelesaikan sesuatu dengan caranya sendiri, sehingga sulit digunakan kembali. UseCase membuat pernyataan persyaratan non-fungsional menjadi sulit (di mana Anda mengatakan bahwa X harus dieksekusi pada Y/detik?). Fungsionalitas pengujian langsung, tetapi pengujian unit secara khusus implementasi dan persyaratan non-fungsional tidak jelas.

Identifying Usecases 

• Lihat persyaratan pengguna dan persyaratan fungsional Apa tugas utama aktor?
• Informasi apa yang dibutuhkan aktor dari sistem?
• Informasi apa yang diberikan aktor ke sistem?
• Apakah sistem perlu memberi tahu aktor tentang setiap perubahan yang terjadi telah terjadi?
• Apakah aktor perlu menginformasikan sistem tentang setiap perubahan yang terjadi telah terjadi?
• Kasus penggunaan harus diberi nama dengan frase kata kerja

Usecase ID Number	UC_002
Usecase Name	Melakukan approve request IB
Brief Description	Usecase ini menggambarkan keasramaan untuk melakukan approve terhadap request IB yang dilakukan mahasiswa
Primary Actor	Keasramaan
Pre-condition	Keasramaan telah login untuk mengakses sistem
Post-condition	Keasramaan berhasil melakukan approveval terhadap request IB
Include Usecase	Login
Basic Flow of Event	Actor Action	System’s Response
	1.      Keasramaan menerima notifikasi request IB yang diajukan mahasiswa
		2.      System menampilkan hasil form request IB mahasiswa
	3.      Keasramaan melakukan cek request IB
	4.      Keasramaan melakukan approval
		5.      System mengirimkan notifikasi approve ke mahasiswa
Alternative flow of events	4a.   Jika dosen wali, dosen pengampu, atau staff akademik tidak memberikan izin maka keasramaan dapat me-Reject request IB
Extension points	-

Referensi 

AMS Slide RPL 

First part of slide taken from wikipedia 

Whitten, JeffreyL, Bentley, LonnieD, System Analysis and Design Methods, 7th Edition, McGraw-Hill Irwin, 2007 (Chapter 10) 

Dennis, Alan, et.al, System Analysis and Design with UML3rd Edition, John Wiley & Sons, 2010. 

Mursanto, Petrus., Budiharjo, Eko., Slide Perkuliahan RPL Fakultas Ilmu Komputer UI, 2009.