USE CASE DIAGRAM

• Menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang

ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”.

• Menggambarkan kebutuhan system dari sudut pandang user

• Mengfokuskan pada proses komputerisasi (automated processes)

• Menggambarkan hubungan antara use case dan actor

• Use case menggambarkan proses system (kebutuhan system dari sudut

pandang user)

• Secara umum use case adalah:

• Pola perilaku system

• Urutan transaksi yang berhubungan yang dilakukan oleh satu actor

• Use case diagram terdiri dari

• Use case

• Actors

• Relationship

• System boundary boxes (optional)

• Packages (optional)

Simbol Use Case Diagram

1. 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

2. Actors

• 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)

• Letakkan actor utama anda pada pojok kiri atas dari diagram

• Actor digambarkan dengan gambar stick figure atau dengan gambar visual

atau atau dll

• Letakkan actor utama anda pada pojok kiri atas dari diagram (in western

culture people read from left to right, top to bottom)

• (place your primary Use case in the top left corner of the diagram because

your primary actor is often directly involved with your primary/critical use

case)

• Actor jangan digambarkan ditengah-tengah use cases (actors are placed to the

outside of the diagram, and not the middle of it)

• Actors menggambarkan sebuah tugas/peran dan bukannya posisi sebuah

jabatan

KonsumenKasir

<<System Keuangan>>

Time

3. 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. Association antara actor dan use case

2. Association antara use case

3. Generalization/Inheritance antara use case

4. 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

Nasabah

Buka

Rekening

Nabung

Ambil

Tutup

Rekening

Teller

• 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 antara use case

• <<include>> termasuk didalam use case lain (required) / (diharuskan)

• Pemanggilan use case oleh use case lain, contohnya adalah pemanggilan

sebuah fungsi program

• Tanda panah terbuka harus terarah ke sub use case

• Gambarkan association include secara horizontal

Buka

Rekening

<<include>>catat

data

pribadi

Nasabah

• 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 verb

• Nama use case boleh terdiri dari beberapa kata dan tidak boleh ada 2 use case

yang memiliki nama yang sama

• Sebuah use case bisa mempunyai dokumentasi

• Gunakan dengan lambang dibawah ini dan ditarik dengan garis putus tanpa

panah

• Untuk sebuah system yang besar (lihat konsep diagram 7 +/- 2 ) dibutuhkan

use case package (lihat package diagram)

• Letakkan use case utama anda pada pojok kiri atas dari diagram

• Use case diagram tidak terpengaruh urutan waktu, meskipun demikian

supaya mudah dibaca perlu penyusunan use case

• Ada 4 jenis relasi yang bisa timbul pada use case diagram

– Association antara actor dan use case

– Association antara use case

Buka Rekening

Simpan Uang

Ambil Uang

Tutup

Rekening

Nasabah

Simpan uang

harus diatas Rp.

200.000,-

– Generalization/Inheritance antara use case

– Generalization/Inheritance antara actors

• Associations bukan menggambarkan aliran data/informasi

• Associations digunakan untuk menggambarkan bagaimana actor terlibat

dalam use case

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 antara use case

• <<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

Beli Barang

KonsumenBayar

Kasir

– Tidak boleh actor dihubungkan pada use case <<include>>

– Base use case menerangkan keterkaitan behavior dari usecase lain pada

lokasi khusus pada base.

– Included use case tidak bisa berdiri sendiri. Ini hanya menjadi bagian

dari base yang meng-include-nya.

Association antara use case

• <<extend>>

– Perluasan dari use case lain jika kondisi atau syarat terpenuhi

– 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>>

– Base use case secara tidak langsung terkait behavior dari use case lain

pada point tertentu yang di secut extension points.

– Base use case bisa saja berdiri sendiri, tetapi pada kondisi tertentu

mungkin saja diperluas oleh behavior use case lain.

Buka

Rekening

<<extend>>

Buka

Deposito

Nasabah

Generalization/inheritance

• Generalization/inheritance digambarkan dengan sebuah garis berpanah

tertutup pada salah satu ujungnya yang menunjukkan lebih umum

• Harus digambarkan secara vertikal

Generalization/inheritance antara use case

• Dibuat ketika ada sebuah keadaan yang lain/perlakuan khusus

• Inheriting use case dibawah base/parent use case

• Generalization/inheritance digambarkan dengan sebuah garis berpanah

tertutup pada salah satu ujungnya yang menunjukkan lebih umum

• Gambarkan generalization/inheritance antara use case secara vertical dengan

inheriting use case dibawah base/parent use case

• Generalization/inheritance dipakai ketika ada sebuah keadaan yang lain

sendiri/perlakuan khusus (single condition)

BayarPembayaran

KhususBayar

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

Generalization/inheritance

Contoh :

System Boundary Boxes - Use Case Diagram

• Digambarkan dengan kotak disekitar use case, untuk menggambarkan

jangkauan system anda (scope of of your system).

• Biasanya digunakan apabila memberikan beberapa alternative system yang

dapat dijadikan pilihan

• System boundary boxes are optional

• Contoh:

Nasabah

Nasabah

Khusus

Nasabah

Nasabah

Khusus

Usecase berdasarkan sistem usulan atau berdasar program

Contoh Kasus Penggajian (Acknowledgments Evi Lutfi Muktar)

Use Case Absen

Deskripsi use case Absen

Nama : Use Case Diagram Absen

Actor : TU dan Administrasi

Deskripsi : TU mencetak Rekap Absen kemudian diserahkan kepada

Administrasi

Nama Use Case : <<Include>> input data absen harian

Cetak Rekap Absen

TU Administrasi

Input Data Absen Harian

<<In

clu

de>>

Use Case Rekap Biodata Pegawai

Deskripsi Use Case Rekap Biodata Pegawai

Nama : Use Case Rekap Biodata Pegawai

Actor : TU dan Administrasi

Deskripsi : TU mencetak Rekap Biodata Pegawai kemudian diserahkan

kepada Administrasi

Nama Use Case : <<Include>> input data pegawai, Pendidikan dan Keluarga.

Use Case Pengolahan Daftar Data Pegawai dan Gaji (DDPG)

Cetak Rekap Biodata

Pegawai

TU Administrasi

Input Data Pegawai,

Pendidikan, Keluarga

<<In

clu

de>>

Administrasi

Cetak Slip Gaji

Pegawai

Input Total Absensi Pegawai

<<In

clude>>

Input Data Pegawai,data

pendidikan, data keluarga

PKS, Insentif, Fungsional,

Transport, Potongan

<<Include>>

Deskripsi Use Case Pengolahan Data Pegawai dan gaji (DDPG)

Nama : Use Case Pengolahan Data Pegawai dan Gaji

Actor : Administrasi dan Pegawai

Deskripsi : Administrasi Mencetak Slip Gaji kemudian diserahkan kepada

Pegawai

Nama Use Case : <<Include>> Input total absensi pegawai dan input data

pegawai, data pendidikan, data keluarga, PKS, insentif,

fungsional, transport dan potongan.

Gambar Use case formulir pendaftaran rubah daya (Acknowledgments Toeko

triyanto)

pendaftaran

pengunjung pelanggan

formulir

nomor pelanggandaya

tarif

data i_01

<<include>>

<<include>>

<<include>>

<<extend>>

pendaftaran

rubah daya

Gambar Use case cetak surat jawaban

Gambar Use case cetak surat perjanjian jual beli

pendaftaran

formulir

nomor agenda

data i_01

rubah daya

pendaftaran

pelanggan

cetak

surat jawaban

user

<<extend>>

<<include>>

cetak

surat jawaban

pendaftaran

formulir

nomor agenda

data i_01

rubah daya

cetak

surat jawaban

pelanggan

cetak

surat perjanjian

jual beli tenaga

listrik

user

<<extend>>

<<include>>

cetaksurat perjanjian

jual beli

Gambar Use case cetak kwitansi.

pendaftaran

formulir

data i_01

rubah daya

cetak

surat jawaban

nomor agenda

pelanggan

data kwitansi

user

<<extend>>

<<include>>

<<extend>>

cetak

kwitansi

ACTIVITY DIAGRAM

Activity diagram – diagram yang digunakan untuk menggambarkan

Proses bisnis,

Langkah-langkah use case

Logika perilaku obyek/ metode

Activity diagram adalah cara lain menggambarkan flow of events.

Menunjukkan kontrol aliran dari activity ke activity.

Activity menggambarkan sebuah pekerjaan/tugas dalam workflow.

Pada UML, activity digambarkan dengan simbola belah ketupat=‘lozenge’

(horizontal top and bottom with convex sides).

Simbol Activity

1. Start State

• Start state dengan tegas menunjukkan dimulainya suatu workflow pada

sebuah activity diagram.

• Hanya ada satu start state dalam sebuah workflow.

• Pada UML, start state digambarkan dengan simbol lingkaran yang solid.

2. End State

• End state menggambarkan akhir atau terminal dari pada sebuah activity

diagram.

• Bisa terdapat lebih dari satu end state pada sebuah activity diagram.

• Pada UML, end state digambarkan dengan simbol sebuah bull’s eye.

3. State Transitions

• State transition menunjukkan kegiatan apa berikutnya setelah suatu kegiatan

sebelumnya.

• Pada UML, state transition digambarkan oleh sebuah solid line dengan panah.

4. Decisions

• Decision adalah suatu titik/point pada activity diagram yang

mengindikasikan suatu kondisi dimana ada kemungkinan perbedaan

transisi.

• Pada UML, decision digambarkan dengan sebuah simbol diamond.

5. Swimlanes

• A swimlane is used to partition an activity diagram to help us better

understand who or what is initiating the activity.

Contoh Activity diagram

• Gambar di atas menggambarkan Aplikasi mempunyai satu Actor/user yaitu

Pustakawan dan 7 use case. Hal ini menjelaskan bahwa dalam aplikasi,

pustakawan bisa Menambah Anggota, Mencetak Kartu Anggota, Menambah

Buku, Mencetak Stiker Kode Buku, Melihat Katalog, Meminjam Buku, dan

Mengembalikan Buku.

• Mungkin ada kebingungan, mengapa yang meminjam dan mengembalikan

buku adalah Pustakawan, bukan anggota perpustakaan.

• Kalau kita lihat Business Process atau Activity Diagram , terlihat bahwa yang

berinteraksi langsung dengan aplikasi adalah Pustakawan, bukan anggota.

Anggota meminjam dan mengembalikan buku kepada Pustakawan,

selanjutnya Pustakawan lah yang menginput ke aplikasi.

• Diagram di atas menggambarkan 3 Activity utama di dalam

perpustakaan,yaitu:

• Menambah anggota/member perpustakaan.

• Anggota meminjam buku.

• Anggota mengembalikan buku.

• Walaupun mungkin masih banyak activity-activity lain yang terkait dengan

perpustakaan tetapi bukan merupakan business process yang utama dari

perpustakaan.

Contoh activity diagram(Activity Diagram Pembayaran)

Client Marketing

Menanyakan sisa pembayaran Melihat data pesanan

Memberikan jawaban sisa pembayarantunai

Membuat Kwitansi

tidak

ya

Menerima Kwitansi lunas

Memberikan Bukti transfer

Lunas

Ttd Kwitansi LunasTerima Kwitansi Lunas

Bagian Keuangan

Menerima kwitansi

Membuat Kwitansi Lunas

Menerima Kwitansi

ya

tidak

Activity Diagram Laporan

Procedure Berjalan

Proses pembuatan Daftar Data Pegawai dan Gaji pada SMP PGRI 1

Depok adalah sebagai berkut :

1. Proses Absensi

Pegawai melakukan absensi harian melalui form daftar hadir pegawai.

Berdasarkan form daftar hadir pegawai tersebut bagian Tata Usaha (TU)

akan membuat Rekap Absen (RA) harian untuk diserahkan kepada

Administrasi.

Bagian Keuangan & Adm Pimpinan

Membuat Laporan Pemesanan

Menyerahkan laporan Terima Laporan

Melakukan absen

harian

Absen

Melakukan absen di

form daftar hadir

Pegawai melapor ke

TU

Menerima laporan

pegawai yang tidak

absen

Mencatat absen

pegawai

Merekap absensi

berdasarkan form

daftar hadir

Pegawai TU

Ya Absen

Tidak Absen

2. Proses Pemberian Rekap Biodata Pegawai (RBP)

Pegawai memberikan data pribadi pegawai, data pendidikan, data

keluarga yang dijadikan satu menjadi data pegawai kepada bagian Tata Usaha

yang kemudian diarsipkan menjadi Rekap Biodata Pegawai (RBP). Lalu Rekap

Biodata Pegawai (RBP) diserahkan kepada bagian administrasi untuk proses

pengolahan Daftar Data Pegawai Dan Gaji (DDPG).

Memberikan data

pegawai

Data

Pegawai

Mengembalikan

berkas data pegawai

tidak lengkap

Menerima data

pegawai

Mengecek berkas

data pegawai

Data pegawai

diproses

Pegawai TU

Data LengkapData tidak Lengkap

Menerima

berkas data pegawai

tidak lengkap

3. Proses Pengolahan Daftar Data Pegawai dan Gaji (DDPG)

Setelah bagian administrasi menerima Rekap Biodata Pegawai (RBP) dan

Rekap Absen (RA) akan mengolah kedua data tersebut untuk dibuatkan

menjadi Daftar Data Pegawai dan Gaji (DDPG) yang kemudian diserahkan

kepada Kepala Sekolah untuk ditanda tangani atau di Acc.

4. Proses Pembuatan Laporan

Daftar Data Pegawai dan Gaji (DDPG) yang sudah diterima dan ditanda

tangani oleh Kepala Sekolah akan diserahkan kembali kepada bagian

Administrasi untuk dibuatkan Laporan Data Pegawai (LDP) dan Laporan Gaji

Pegawai (LGP).

Memberikan data

Rekap Absen

Memberikan data

Pegawai

Menerima

rekap absen & data

pegawai

Menerima

daftar data pegawai

dan gaji

Menyetujui

daftar data pegawai

dan gaji

TU Administrasi

Membuat

daftar data pegawai

dan gaji

Menyerahkan

daftar data pegawai

dan gaji

Kepala Sekolah

Setelah bagian administrasi menerima Daftar Data Pegawai dan Gaji yang

sudah di Acc akan membuatkan Laporan Data Pegawai (LDP) dan Laporan

Gaji Pegawai (LGP) yang nantinya akan diserakan kepada Kepala Sekolah.selain itu

bagian Administrasi akan membuatkan slip gaji untuk diserahkan kepada

pegawai.

Menyerahkan

daftar data pegawai

dan gaji acc

Menerima

daftar data pegawai

dan gaji acc

Menerima

Slip gaji

Kepala Sekolah Administrasi

Membuat

lap data pegawai dan

lap gaji pegawai

Membuat

Slip gaji

Pegawai

Menerima

Lap data pegawai dan

lap gaji pegawai