Disajikan untuk Lingkungan FIT Dosen : Ferra Arik Tridalestari., M.T. APSI [DMH2F3] Disajikan untuk Lingkungan FIT Dosen : Ferra Arik Tridalestari., M.T.

PENDAHULUAN Dalam membuat sebuah sistem, langkah awal yang perlu dilakukan adalah menentukan kebutuhan Terdapat dua jenis kebutuhan : 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.

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

USE CASE DIAGRAM UNTUK SIAPA? Stakeholder Pengembang Sistem (Developer) Project Manager Tim integrasi dan pengujian sistem Setiap orang yang terlibat dalam fungsionalitas di sistem, seperti tim marketing, tim sales, tim pendukung dan tim dokumentasi.

Contoh use case diagram

Contoh lagi (lebih kompleks)

Aktor Langkah awal dalam membuat use case diagram adalah dengan menemukan aktor kemudian fungsionalitas dan terakhir membuat batasan sistem yang akan dibangun Aktor adalah segala hal diluar sistem yang akan menggunakan sistem tersebut untuk melakukan sesuatu Cara mudah untuk menemukan aktor adalah dengan bertanya hal-hal berikut: SIAPA yang akan menggunakan sistem? APAKAH sistem tersebut akan memberikan NILAI bagi aktor?

Lanjutan.. Aktor terbagi menjadi DUA jenis, yaitu : Active actor : aktor yang berinteraksi langsung dengan sistem dalam memberi nilai atau menerima suatu nilai ke/dari sistem (exp. User) Passive actor : aktor yang tidak pernah berinteraksi langsung dengan sistem namun hanya berpartisipasi dalam memberi atau menerima nilai ke dalam satu atau lebih use case (exp, hardware, sistem lain, dll)

Bagaimana menemukan Aktor? Siapa yang akan menggunakan fungsi utama sistem? Siapa yang akan membutuhkan nilai dari sistem untuk pekerjaannya sehari-hari? Siapa yang merawat dan mengontrol sistem dan menjaga agar sistem terus berjalan? Perangkat keras apa yang dibutuhkan dalam mendukung sistem ini? Apakah ada sistem lain yang mensupport sistem yang dibangun? Siapa atau apa yang membutuhkan hasil/nilai keluaran/value dari proses yang ada dalam sistem?

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.

Relasi antar aktor Relasi antar aktor hanyalah untuk menggambarkan GENERALISASI

Contoh lain… Catatan : Dalam menggambarkan fungsi login ada yang menjadikan login itu use case yang di mana use case lain akan mengarah semua ke login, namun ada alternatif lain yang bisa digambarkan dengan generalisasi actor yang nantinya hanya registered user yang mengarah ke login.

Use case Sebuah use case harus mendeskripsikan sebuah pekerjaan dimana pekerjaan tersebut akan memberikan NILAI yang bermanfaat bagi actor dan stakeholder Karakteristik use case : Use case selalu diawali oleh aktor Use case selalu menyediakan suatu nilai untuk actor Use case adalah fungsionalitas yang komplit

Bagaimana mendapatkan use case ? Untuk menemukan use case, mulailah dari sudut pandang aktor, misalnya dengan bertanya : Value 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 value yang perlu disimpan atau diambil dari sistem? Apakah ada value yang harus dimasukkan oleh aktor? Pertanyaan lain : Input/output apa yang dibutuhkan oleh sistem? Dari mana/ke mana input atau output berasal? Masalah besar apa yang muncul saat implementasi di sistem?

Relasi antar use case GENERALISASI, hubungan turunan yang menentukan bagaimana child use case dapat semua perilaku dan karakteristik dari parent use case namun terdapat perilaku dan karakteristik khusus

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

System Boundary Boxes Merupakan batas antara sistem dan aktor Biasa dinotasikan dengan bujur sangkar Semua use case harus berada di dalam system boundary

Simbol-symbol pada use case diagram

Hal-hal yang perlu diperhatikan Use case diagram tidak terpengaruh urutan waktu, meskipun demikian supaya mudah dibaca perlu penyusunan use case Tidak boleh ada komunikasi langsung antar actor (Actors don’t interact with one another )

Lanjutan… 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