Use Case

Report
PRAKTIKUM ANALISIS
DAN PERANCANGAN
SISTEM INFORMASI
Hendro Gunawan, S.Si., M.T.
SASARAN
Setelah mempelajari materi ini, mahasiswa mampu

Memahami teknik untuk mendokumentasikan kebutuhan
dengan menggunakan use case.

Mengerti komponen-komponen use case diagram.

Mampu mencari dan menemukan aktor dan use case dari
suatu spesifikasi.

Mampu membuat deskripsi sebuah use case
Slide 2
… pendahuluan …

Hasil dari aktivitas requirement gathering perlu
didokumentasi untuk selanjutnya diproses dalam
menentukan spesifikasi kebutuhan perangkat
lunak.

Salah satu tool yang sering digunakan saat ini
adalah Unified Modeling Language.

Komponen diagram yang digunakan untuk
dokumentasi kebutuhan adalah use case diagram.
UNIFIED MODELLING LANGUAGE
• Unified Modelling Language (UML) adalah sebuah
"bahasa" yg telah menjadi standar dalam industri untuk
visualisasi, merancang dan mendokumentasikan sistem
piranti lunak. UML menawarkan sebuah standar untuk
merancang model sebuah sistem.
UNIFIED MODELLING LANGUAGE
UML mendefinisikan diagram-diagram berikut ini :
•
•
•
•
•
•
use case diagram
class diagram
behaviour diagram :
-- statechart diagram
-- activity diagram
interaction diagram :
-- sequence diagram
-- collaboration diagram
component diagram
deployment diagram
Use case diagram
• Use case modeling adalah suatu proses untuk membuat
model fungsi-fungsi dari sistem dari kejadian-kejadian
bisnis, siapa yang melakukannya, dan bagaimana sistem
bereaksi terhadap suatu kejadian.
• Use case modeling mengidentifikasi dan menjelaskan
fungsi-fungsi sistem dari perspektif pengguna eksternal
dengan menggunakan tools yang disebut use case.
• Use case adalah serangkaian langkah-langkah yang
saling berhubungan (skenario), baik otomatis maupun
manual, dengan tujuan untuk menyelesaikan suatu
kegiatan bisnis tunggal.
7
Use case
• Use case menggambarkan fungsi-fungsi sistem dari
•
perspektif pengguna luar. Use case adalah hasil dari
dekomposisi lingkup fungsi-fungsi dari sistem menjadi
statement-statement yang lebih kecil mengenai
fungsional oleh fungsi-fungsi sistem. Pembuatan use case
sudah dibuktikan merupakan suatu teknik yang baik
untuk mengerti lebih baik dan mendokumentasi
kebutuhan sistem.
Use case sendiri bukan sebagai kebutuhan fungsional,
tetapi ceritanya (skenario) yang diceritakan dari use case
menangkap essensi dari satu atau lebih kebutuhankebutuhan. Use case diawali atau dipicu oleh pengguna
eksternal atau sistem yang disebut actor.
Keuntungan Use Case
1.
2.
3.
4.
5.
6.
Sebagai dasar untuk membantu mengidentifikasi
objek-objek dan hubungan tingkat tinggi dan tanggung
jawab masing-masing.
Sebagai gambaran dari behavior sistem yang akan
dibuat dari sisi pengguna eksternal.
Sebagai alat yang efektif untuk memvalidasi
kebutuhan.
Sebagai alat komunikasi yang efektif
Sebagai dasar untuk melakukan perencanaan testing.
Sebagai dasar untuk melakukan pembuatan user
manual.
… komponen use case …
Actor:
Someone/something outside
the system that interacts
with the system
Communication – Association:
Shows the Actor and the Use Case
communicate
Sumber : IBM software group
Use Case:
Defines a piece of
functionality of the
system
Use Case Specification:
Basic flow of events,
alternate flows, error flows
and sub-flows as
appropriate
10
Lambang Use Case
USE CASE
• Use case dibuat berdasar keperluan actor, merupakan
“apa” yang dikerjakan system, bukan “bagaimana”
system mengerjakannya
• Use case diberi nama yang menyatakan apa hal yang
dicapai dari hasil interaksinya dengan actor.
• Use case dinotasikan dengan gambar (horizontal ellipse)
• Use case biasanya menggunakan kata kerja
• Nama use case boleh terdiri dari beberapa kata dan
tidak boleh ada 2 use case yang memiliki nama yang
sama
ACTOR
•
•
•
•
•
•
•
Actor menggambarkan orang, system atau external entitas /
stakeholder yang menyediakan atau menerima informasi dari system
Actor menggambarkan sebuah tugas/peran dan bukannya posisi
sebuah jabatan
Actor memberi input atau menerima informasi dari system
Actor biasanya menggunakan Kata benda
Tidak boleh ada komunikasi langsung antar actor
Indikasi <<system>> untuk sebuah actor yang merupakan sebuah
system
Adanya actor bernama “Time” yang mengindikasikan scheduled
events (suatu kejadian yang terjadi secara periodik/bulanan)
Empat Tipe Aktor
•
Primary business actor
•
•
•
•
Pihak yang secara langsung berinteraksi dengan sistem untuk
memulai kejadian bisnis atau sistem
Cth: Teller bank menginput informasi deposit
External server actor
•
•
•
Cth: karyawan yang menerima pembayaran gaji
Primary system actor
•
•
Pihak yang secara utama diuntungkan oleh eksekusi Usecase
Pihak yang merespon permintaan dari usecase
Cth: lembaga perkreditan mengotorisasi pembuatan kartu kredit
External receiver actor
•
•
PIhak yang bukan aktor utama tetapi menerima suatu nilai dari
Usecase
Cth: Bagian gudang menerima slip pengepakan
Sample Use-Case Model Diagram
Association
•
•
•
Associations bukan menggambarkan aliran
data/informasi
Associations digunakan untuk menggambarkan
bagaimana actor terlibat dalam use case
Ada 4 jenis relasi yang bisa timbul pada use case
diagram
1.
2.
3.
4.
Association antara actor dan use case
Association antara use case
Generalization/Inheritance antara use case
Generalization/Inheritance antara actors
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
Association - Use Case Diagram
<<include>>
•
•
•
•
•
•
termasuk didalam use case lain (required) / (diharuskan)
Pemanggilan use case oleh use case lain
contohnya adalah Pemanggilan sebuah fungsi program
Gambarkan association <<include>> secara horizontal
Tanda panah terbuka harus terarah ke sub use case
Tidak boleh actor dihubungkan pada use case <<include>>
Buka
Rekening
Buka
Rekening
<<include>>
catat
data pribadi
<<include>>
Nasabah
Catat
Data Pribadi
Nasabah
Buka
Rekening
<<include>>
catat
data
pribadi
Buka
Rekening
Nasabah
Nasabah
<<include>>
catat
data
pribadi
Association - Use Case Diagram
<<extend>>
•
•
•
•
•
Perluasan dari use case lain jika kondisi atau syarat terpenuhi
(Optional Behaviour)
Kurangi penggunaan association Extend ini, terlalu banyak
pemakaian association ini membuat diagram sulit dipahami.
Tanda panah terbuka harus terarah ke parent/base use case
Gambarkan association extend secara vertical (picture extending use
case below than base/parent use case)
Tidak boleh actor dihubungkan pada use case <<extend>>
Buka
Rekening
Buka
Rekening
<<extend>>
Nasabah
Nasabah
Buka
Rekening
Buka
Deposito
<<extend>>
Nasabah
Buka
Deposito
<<extend>>
Buka
Deposito
Association - Use Case Diagram
Generalization/inheritance
•
•
Generalization/inheritance digambarkan dengan sebuah garis berpanah tertutup pada salah satu ujungnya
yang menunjukkan lebih umum
Ketika beberapa aktor, sebagai bagian dari peranannya, memainkan peranan yang lebih general, maka
dapat dibuat relasi antar aktor, relasi generalization
Generalization/inheritance antara use case
•
•
Dibuat ketika ada sebuah keadaan yang lain/perlakuan khusus
Inheriting use case dibawah base/parent use case
Bayar
Bayar
Bayar
Pembayaran
Khusus
Pembayaran
Khusus
Pembayaran
Khusus
Generalization/inheritance antara actor
•
•
Dibuat ketika ada sebuah actor baru terbentuk dan mempunyai atribut dan methode yang sama dengan
actor yang sudah ada
Inheriting actor dibawah base/parent actor
Nasabah
Nasabah
Nasabah
Khusus
Nasabah
Nasabah
Nasabah
Khusus
System Boundary Boxes - Use Case Diagram
•
•
•
•
Digambarkan dengan kotak disekitar use case, untuk menggambarkan jangkauan
system anda (scope of of your system).
Sebagai bagian dari pemodelan, batasan sistem (boundaries of the system) harus
didefinisikan.
Penetapan batasan menentukan mana yang berada dalam sistem dan mana yang
berada di luar sistem.
Contoh:
Airport Check-In and Security
Screening
Online Shopping
DESKRIPSI USE CASE
Slide 27
… deskripsi use case …
A use case description is a specification of the
interaction between a system and the actors in a use
case.
Slide 28
… deskripsi use case …

Setiap use case harus mencakupkan rincian apa yang
harus dilakukan untuk memenuhi fungsionalitas.

Rincian fungsionalitas mencakup

Fungsionalitas dasar

Fungsionalitas Alternatif

Kondisi error

Keadaan atau kondisi yang harus dipenuhi sebelum use case
dijalankan dan setelah use case selesai dijalankan.
… template deskripsi use case

Nama Use Case

Actor

Deskripsi Singkat

Pre Condition

Flow of Event

Post Condition
… pre condition …

Pre condition (pra kondisi) menyatakan (pra
syarat) apa yang harus ada sebelum use case
dijalankan.

Pre condition harus benar atau terpenuhi supaya
fungsionalitas yang dinyatakan dalam use case bisa
terpenuhi.
… post condition …

Post condition menyatakan apa yang didapat atau
terjadi setelah use case dijalankan.

Post condition merupakan kondisi yang akan
benar atau terpenuhi setelah fungsionalitas
dijalankan.
… flow of event …

Menyatakan langkah-langkah dalam use case.




deklaratif, time-ordered
Dari sudut pandang aktor
Dimulai atau diinisiasi oleh aktor yang memicu
berjalannya use case.
Good way to start …
Use case dimulai ketika <aktor> <aktivitas>
Misal :
Use case dimulai ketika pelanggan memesan produk
… flow of event …

Langkah-langkah
harus
jelas
menimbulkan ambiguitas …

Contoh :
dan
tidak
Detil pelanggan dimasukkan.
Mengapa langkah di atas dianggap tidak jelas … ?
… flow of event …

Langkah-langkah
harus
jelas
menimbulkan ambiguitas …

Contoh :
dan
tidak
Detil pelanggan dimasukkan.
Siapa yang memasukkan detil pelanggan ?
Informasi apa saja yang dimasukkan sebagai “detil
pelanggan”
… basic flow …

Menyatakan langkah-langkah yang terjadi di mana
semuanya berjalan dengan baik

happy day scenario

Harus ada satu basic flow untuk setiap use case.

Berisi sederatan langkah tanpa ada percabangan (if)
atau alternatif.

Pada setiap langkah, asumsikan semua berjalan
dengan benar.
… alternative flow …

Berisi langkah-langkah yang dipandang bukan
sebagai normal flow


Memungkinkan flow yang berbeda terjadi.
Termasuk dokumentasi langkah yang dilakukan
jika terjadi error.
… alternative flow …
Menemukan alternatif flow
Untuk setiap langkah dalam basic flow ….

Apakah ada aksi lain yang dapat dilakukan ?

Apakah ada kemungkinan terjadinya kesalahan ?

Apakah ada perilaku lain yang bisa terjadi kapan
saja ?
… alternative flow …
Beberapa contoh yang mengakibatkan alternative
flow ..

Aktor membatalkan operasi atau aktivitas

Aktor meminta bantuan (help)

Aktor memberikan data tidak lengkap atau data
yang salah.

Sistem crash

Aktor memilih alternative lain
… guideline menulis deskripsi uc


Tuliskan setiap langkah dalam SVD[PI] – Subject Predicate
Direct object Proposition Indirect object.*
Nyatakan dengan jelas siapa/apa inisiator aksi dan siapa
yang terkena atau penerima aksi (receiver)


*
Biasanya inisiator adalah subject dan receiver adalah direct object.
Tuliskan setiap langkah dalam perspektif independen
(bukan inisiator atau receiver)
tidak semua langkah mungkin bisa menggunakan bentuk ini, akan tetapi jika memungkinkan gunakan
bentuk ini.
… guideline menulis deskripsi uc


Tuliskan setiap langkah dalam level abstraksi yang sama.
Pastikan bahwa use case berisi sederatan aksi. Setiap use
case pada dasarnya melakukan sebuah transaksi, sehingga
terdiri atas 4 bagian :
1.
Aktor menginisiasi use case dengan mengirimkan request ke sistem.
2.
Sistem memastikan request valid.
3.
Sistem memproses request
4.
Sistem mengirimkan pada aktor hasil proses
… guideline menulis deskripsi uc

KISS – Keep It So Simple
Sample Expanded Version of a Use-Case
Narrative
continued
Sample Expanded Version of a Use-Case Narrative
(cont)
continued
Sample Expanded Version of a Use-Case Narrative
(cont)
ACTIVITY DIAGRAM
ACTIVITY DIAGRAM
• Menggambarkan proses bisnis dan urutan aktivitas
dalam sebuah proses
• Dipakai pada business modeling untuk
memperlihatkan urutan aktifitas proses bisnis
• Struktur diagram ini mirip flowchart atau Data Flow
Diagram pada perancangan terstruktur
• Sangat bermanfaat apabila kita membuat diagram ini
terlebih dahulu dalam memodelkan sebuah proses
untuk membantu memahami proses secara
keseluruhan
• Activity diagram dibuat berdasarkan sebuah atau
beberapa use case pada use case diagram
Simbol Activity Diagram
Simbol
Keterangan
Start Point
End Point
Activities
Fork (Percabangan)
Join (Penggabungan)
Decision
Swimlane
Sebuah cara untuk mengelompokkan
activity berdasarkan Actor
(mengelompokkan activity dalam
sebuah urutan yang sama)
CONTOH ACTIVITY DIAGRAM
Bagian Gudang
Memberi informasi data
Barang yang akan dipesan
Bagian Pembelian
Menerima
informasi
Buat
SPP
Terima
SPP
Kirim Barang
disertai Faktur
Terima Barang
dan Faktur
Buat
SPBJ
Supplier
Tandatangani
SPBJ
Melakukan
pembayaran
Terima
SPBJ
Konfirmasi
pembayaran
Terima
pembayaran
Terima
Kwitansi
Buat
kwitansi
… your turn …
• Pada ATM Bank A, seorang nasabah dapat melakukan
penarikan, penyetoran, menampilkan jumlah saldo,
melakukan transfer dana, mengubah PIN ATM ke bank,
dan melakukan pembayaran tagihan/kredit ke system
credit bank. Gambarkan Use Case Diagram dan deskripsi
use case dari skenario diatas !
Terima kasih...

similar documents