OOP 3 UseCase

USE CASE

Definisi Use Case● Deskripsi fungsi dari sebuah system dari prespektif user

● Mendeskripsikan tipikal interaksi antara user sebuah system dengan sistemnya sendiri melalui cerita bagaimana sistem dipakai

● Serangkaian scenario (urutan langkah-langkah antara sistem dengan user) yang digabungkan bersama-sama oleh tujuan umum user/ actor.

● Prilaku suatu sistem yang menghasilkan nilai terukur terhadap aktor

● Melukiskan segala sesuatu yang diinginkan oleh pengguna agar dikerjakan oleh sistem

Use cases• model fungionalitas sistem (tasks)

dari pandangan sisi pemakai (user)– Seorang user melakukan suatu tugas

atau– Seorang usr ingin melakukan aksi

• Menunjukkan requirements bukan desain– what not how

Kegunaan

• Alat bantu terbaik untuk mensimulasikan pengguna untuk mengatakan tentang suatu sistem dari sudut pandangnya

Notasi Use Case• Ada 3 aspek dari sistem:

– Actor– Use case– System/ sub system boundary

Actor ActorUse Case

Sistem

use cases

aktor

use case

Actor

• Orang atau sistem teorotomatisasi.

• Merepresentasikan suatu interaksi individu dengan sistem dalam suatu cata tertentu.

• Ada di luar sistem• Dihubungkan menggunakan

cases melalui asosiasi.

automated system<<stereotype>>

IDENTIFIKASI ACTOR

• Harus ditentukan pembagian tenaga kerja dan tugas-tugas yang berkaitan dengan peran pada konteks target system.

• Merupakan abstraksi dari orang dan system yang lain yang mengaktifkan fungsi dari target system.

Aktor adalah segala sesuatu yang berinteraksidengan sistem dan melaksanakan peran khusus.

Aktor selalu harus diluar sistem.

Contoh aktor: manusia, software lain,peralatan hardware, data, atau jaringan

Menetapkan Aktor

10

Pertanyaan berikut menolong menemukan aktor:

– Siapa yang menggunakan sistem?– Siapa yang melakukan instalasi sistem?– Siapa yang mengawali sistem?– Siapa yang merawat sistem?– Siapa yang menutup/menghentikan sistem?– Apakah ada sistem lain yang memanfaatkan

sistem ini?– Siapa yang memperoleh informasi dari sistem?– Siap yang meyediakan informasi bagi sistem?– Apakah ada sesuatu yang secara otomatis

menjadikan sistem dalam kondisi preset?

Deskripsi Use Case• Merupakan abstraksi dari interaksi antara

sistem dengan actor.• Contoh: saat pelanggan menelpon restoran

untuk booking, dia akan bicara pada karyawan untuk mencatat booking ke system

• Maka, karyawan resepsionis (instance dari actor) & interaksi antara karyawan dengan sistem instance use case

• Use case ‘apa’ yang dikerjakan software, bukan ‘bagaimana’ software bekerja.

12

Dalam menetapkan use cases bertanyalah dalamdiri sendiri dengan pertanyaan berikut:

– Fungsi apa yang diinginkan aktor dari sistem?– Apakah sistem menyimpan informasi? Apakah

aktor akan melakukan create, read, update, or delete informasi?

– Apakah sistem perlu memberitahu aktor tentang perubahan yang terjadi didalam state

– Apakah ada external events yang harus diketahui sistem? Aktor mana yang menginformasikan kepada sistem tentang events-2 tersebut?

13

Dalam menetapkan use cases bertanyalah dalamdiri sendiri dengan pertanyaan berikut:

– Fungsi apa yang diinginkan aktor dari sistem?– Apakah sistem menyimpan informasi? Apakah

aktor akan melakukan create, read, update, or delete informasi?

– Apakah sistem perlu memberitahu aktor tentang perubahan yang terjadi didalam state

– Apakah ada external events yang harus diketahui sistem? Aktor mana yang menginformasikan kepada sistem tentang events-2 tersebut?

14

• Use cases• Actors• Relationships

– Dependencies– Generalizations– Associations

• Notes and constraints

Use Case Diagram Contents

Stereotype• Merupakan model khusus yang terbatas

untuk kondisi tertentu• Diawali symbol “<<“ diawal dan ditutup

“>>” diakhirnya.• <<extend>> menunjukkan bahwa satu use

case merupakan tambahan dari use case yang lain, jika kondisi atau syarat tertentu dipenuhi.

• <<include>> menggambarkan bahwa satu use case seluruhnya merupakan fungsionalitas dari use case yang lain

• Base use case explicitly incorporates the behavior of another use case.

• The included use case cannot stand alone.

• Example of delegation.• Rendered as a stereotyped

dependency.

Use Case Inclusion

Use Case Inclusion

Catat Booking

Resepsionis

Tampilkan Booking

<<include>>

• Base use case incorporates the behavior of another use case.

• The extending use case indicates where the extended behavior occurs in the base use case.

• Base use case only extended through extension points.

• Used to model optional behavior.• Rendered as a stereotyped dependency.

Extending a Use Case

Use Case Extension

Catat yg langsung datang

Pelayan

Catat Kedatangan

<<extend>>

Actor Generalisasi

• Spesialisasi actor yang bisa berpartisipasi di semua use case yang diasosiasikan dengan actor yang lebih general.

Actor Generalisasi

Catat BookingResepsionis

Tampilkan BookingStaf

Palayan Catat Kedatangan

Catat Booking

Tampilkan BookingStaf

Catat Kedatangan

Resepsionis

Batalkan Booking <<include>>

<<include>>

<<include>>Transfer Meja

<<include>>

Palayan

Catat yang langsung datang

<<include>>

Contoh text use case (Pembelian Product)

Scenario utama:1. Pelanggan melihat catalouge dan memilih item

yang akan dibeli2. Pelanggan menuju ke bagian check out3. Pelanggan mengisi blangko pengiriman4. Sistem menampilkan info harga penuh5. Pelanggan mengisi informasi kartu kredit6. Sistem melakukan otorisasi7. Sistem melakukan konfirmasi penjualan segera8. Sistem mengirim email konfirmasi ke pelanggan

Extension 3.a. Pelanggan adalah pelanggan reguler

1. Sistem menampilkan default informasi pengiriman barang, harga, dan tagihan saat ini

2. Pelanggan mungkin menerima informasi default, ke langkah 6

6.a. Sistem gagal melakukan otorisasi pemesanan kredit. Pelanggan boleh memasukkan informasi kartu kredit lagi atau dibatalkan

Use Cases (contoh: sistem ATM)

• System start-up Use Case:

– Sistem aktif ketika operator merubah ke posisi ‘on’.

– Operator diminta untuk memasukkan sejumlah uang dalam ‘cash dispenser’ dan suatu koneksi dengan bank mulai dibangun.

– Kemudian pelayanan customer dapat dimulai.

• System Shutdown Use Case

– Dilakukan ketika operator memastikan bahwa tidak ada customer menggunakan mesin dan kemudian giliran operator merubah posisi ‘off’.Koneksi ke bank akan di shut down.

– Operator bebas melakukan pemindahan kertas, melengkapi uang, dll.

• Session Use Case– Sebuah session diawali ketika seorang customer

memasukkan suatu ATM card ke mesin.– ATM menarik card ke mesin dan membacanya.(Tidak

dapat terbaca bila kesalahan pemasukan atau adanya cacat garis sehingga card dikeluarkan, ada pesan kesalahan di layar dan session dibatalkan)

– Customer diminta memasukkan PIN dan mengijinkan untuk melakukan satu/ lebih transaksi.

– Ketika customer melewati penyelenggaraan transaksi, kartu dikeluarkan dari mesin dan session berakhir.

– Jika suatu transaksi digagalkan karena terlalu banyak kesalahan memasukkan PIN, session juga digagalkan.

– Customer mungkin membatalkan session dengan menekan tombol ‘Cancel’ ketika memasukkan PIN atau jenis transaksi.

• Transaction Use Case– Bermula dalam session ketika customer memilih jenis transaksi

dari menu pilihan.– Customer diminta untuk melengkapi detail yang tepat(seperti:

nomor rekening, amount). Transaksi dikirim ke bank, dengan informasi dari kartu customer dan PIN yang telah dimasukkan.

– Jika bank menyetujui transaksi, beberapa langkah dibutuhkan untuk dilengkapi dalam transaksi dan kemudian suatu bukti akan dicetak.

– Kemudian customer diminta apakah ingin melakukan transaksi lain.

– Jika bank melaporkan PIN customer adalah invalid, diadakan perpanjangan waktu invalid PIN untuk dicoba lagi dan kemudian diteruskan transaksi. Jika terlalu banyak invalid PIN, transaksi digagalkan, dan customer tidak ditawarkan pilihan melakukan yg lain.

– Customer mungkin membatalkan transaksi dengan menekan ‘Cancel’

– Seluruh pesan ke bank dan merespon balik tercatat dalam ATM log.

• Withdrawal Transaction Use Case– Meminta customer memilih jenis keterangan

untuk melakukan penarikan kembali dan memilih jumlah uang dari menu yang ada.

– Sistem memverifikasi apakah uangnya mencukupi sebelum pengiriman transaksi ke bank.

– Jika transaksi disetujui oleh bank, jumlah uang yang sesuai dikeluarkan oleh mesih sebelum diterbitkan suatu bukti.

– Transaksi ini dapat dibatalkan customer dengan menekan tombol ‘cancel’ sebelum memilih jumlah uang.

• Deposit Transaction Use Case– Meminta customer memilih jenis keterangan untuk

mendeposit dari menu yang ada dan mengetikkan jumlah uang pada keyboard.

– Transaksi dimulai mengirim ke bank untuk memverifikasi bahwa ATM can dapat menerima suatu deposit dari customer ini ke account ini.

– Jika transaksi disetujui, mesin menerima suatu bingkisan dari customer berisi uang dan atau cek sebelum ditetapkan suatu bukti. Sekali bingkisan diterima, sesaat kemudian pesan dikirim ke bank, untuk dikonfirmasi bahwa bank dapat credit account customer yang diisi oleh operator kemudian.

– Deposit transaction dapat dicancel oleh customer dengan menekan tombol ‘cancel’ sebelum memasukan isian deposit. Transaksi secara otomatis dibatalkan jika customer gagal memasukkan isian deposit dengan periode waktu yang sudah ditentukan.

• Transfer Transaction Use Case– Meminta customer untuk memilih jenis

keterangan untuk mentransfer dari menu account, memilih account yang berbeda untuk ditransfer dan mengetikkan jumlah uang pada keyboard.

– Transfer dapat dibatalkan oleh customer dengan menekan tombol ‘cancel’ sebelum memasukkan jumlah uang.

• Inquiry Transaction Use Case– Transaksi ini meminta customer untuk

memilih jenis keterangan untuk menanyakan suatu hal dari menu ada.

– Suatu transaksi dapat dibatalkan sebelum menekan tombol ‘cancel’ sebelum memilih jenis permintaan.

• Invalid PIN extention– Bermula dari dalam suatu transaksi ketika bank

melaporkan bahwa transaksi tidak disetujui oleh karena kesalahan PIN.

– Customer diminta memasukkan PIN dan permintaan asli dikirim ke bank lagi.

– Sekali PIN berhasil dimasukkan, digunakan untuk transaksi berikutnya.

– Jika customer gagal tiga kali untuk memasukkan PIN yang benar, card dikeluarkan, ditampilkan informasi ke customer hal ini dan disarankan untuk menghubungi ke bank dan segala sesion customer dibatalkan.

– Jika customer menekan ‘cancel’ daripada memasukkan PIN, transaksi semula dapat dibatalkan.

35

Actor

View Report Card

Register For Courses

Login

36

Membuat Sub Uses Cases

Jika Use Cases yang dibuat terlalu besar danmembingungkan, maka dianjurkan untuk dilakukanpemecahan Use Cases menjadi beberapa sub Use Cases.

Contoh:Paket Pendaftaran Calon Mahasiswa Baru

37

Pendaftaran Testing

camaru panitia

Mengisi formulir

MembayarBiaya daftar

MencekStatus bayar

Membuat Kartu Test

MerekapPendaftar

Pendaftaran Use Cases :

38

Testing Use Cases:

panitia

fakultas rektorat

MencetakHasil test

Membuat Soal Test

Menetapkan KelulusanUmumkan

Hasil test

Tim Soal

MengoreksiTest

MerekapPendaftar

39

camaru

panitia

fakultas

rektorat

Mengisi formulir

MembayarBiaya daftar

MencekStatus bayar

Membuat Kartu Test

MencetakHasil test

Membuat Soal Test

Menetapkan Kelulusan

UmumkanHasil test

MerekapPendaftar

Tim Soal

MengoreksiTest

40

Manfaat model Use Case Digunakan untuk berkomuikasi dengan end user dandomain expert

Meneyediakan buy-in pada tahap awal pengembangan system

Memastikan pemahaman yang tepat tentang requirement/kebutuhan system

Digunakan untuk mengidentifikasi Siapa yang berinteraksi dengan system dan apa yang

harus dilakukan system Interface yang harus dimiliki system

Digunakan untuk verifikasi Semua requirement yang telah dicapture Tim pengembang memehami requirement

41

Contoh Use Case Diagram

Customer

Informasi J adwal Penerbangan

Informasi Ketersediaan Kursi

Pemesanan Tiket

Konfirmasi Pembayaran

Pembatalan Tiket

Informasi Harga Tiket

<<extend>>

<<extend>>

<<extend>>

Login

<<uses>>

<<uses>>

42

Use case specification

Nama Deskripsi singkat Aliran event (Flow of Event) Relationship Activity diagram Kebutuhan khusus (special

requirement) Pre-Condition Post-Condition

43

Contoh :Use Case Specification

Use Case Name: Submit New Member OrderActor(s): MemberDescription: This use case describes the process of a member submitting an order for

SoundStage products. On completion, the member will be sent a notification that

the order was accepted.References: MSS-1.0Typical Courseof Events: Actor Action

Step 1: This use case isinitiated when a member submits an order to beprocessed

Step 7: This use case concludes when the member receives the order confirmation notice.

System responseStep 2: The member’s personal information such as

address is validated against what is currently recorded in member services.

Step 3: The member’s credit status is checked with Accounts Receivable to make sure no

payments are outstanding.Step 4: For each product being ordered, validate the

product number and then check the availability in inventory and record the ordered product

information.Step 5: Create a picking ticket for the member order

containing all ordered products that are available and route it to the warehouse for

processing.Step 6: Generate an order confirmation notice

indicating the status of the order and send it to the member.

1

2

Alternate Step 2: If the club member has indicated an address or telephone number change on theCourses: promotion order, update the club member’s record with the new information.

Step 3: If Accounts Receivable returns a credit status that the customer is in arrears, send an

order rejection notice to the member.Step 4: If the product number is not valid, send a notification to the member

requesting them tosubmit a valid product number. If the product being ordered is not available,

record theordered product information and mark as “back-ordered.”

Pre-condition: Orders can only be submitted by members.

Post-condition: Member order has been recorded and the picking ticket has been routed to the warehouse.

Assumptions:

3: Dokumentasi

3

4

5

6

Nama Mengubah Pemesanan

Deskripsi singkat

Pelanggan dapat mengubah pemesanan dengan syarat kurang dari 24 jam

Aktor terlibat Pelanggan

Flow of event Sistem menampilkan laman menu pengubahan pemesanan kamar

Pelanggan mengisi form pengubahan pemesanan berupa nama, alamat, tanggal pesan, type kamar yang telah dipesan

Sistem memberikan peringatan, ketika pelanggan salah memasukkan data atau format data.

Pelanggan submit data pengubahanSistem menampilkan jenis pengubahan pemesananPelanggan memilih jenis pengubahan pemesanan

Relationship Proses pengubahan pemesanan mengharuskan pelanggan untuk mengisi data pribadi dan data pemesanan kamar

Kebutuhan khusus

-

Pre-condition Sistem menampilkan laman menu pengubahan pemesanan

Post-condition Pelanggan memilih jenis pilihan pengubahan pemesanan

Activity Diagram

47

NomorNama use caseActor Tujuan Deskripsi

UCH.04Memeriksa ketersediaan kamarKaryawan (Resepsionis)Memastikan ketersediaan kamar hotelResepsionis memeriksa ketersediaan kamar hotel sesuai dengan keinginan tamu.

AKTOR SISTEM

Resepsionis melakukan pemeriksaan ketersediaan kamar hotel

2.Sistem menampilkan data kamar hotel yang tersedia saat itu.