Simbol Use Case Diagram 1. use case

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 ada>Pola perilaku system
• Urutan transaksi yang berhubungan yang dilakukan oleh satu a>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
>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

  Konsumen Kasir

• Indikasi <<system>> untuk sebuah actor yang merupakan sebuah system

  Time

• Adanya actor bernama “Time” yang mengindikasikan scheduled events

  (suatu kejadian yang terjadi secara periodik/bulanan)

  <<System Keuangan>>

• 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

  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 catat

  Buka <<include>> data Rekening 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

  

Buka Rekening

Simpan uang

Simpan Uang

harus diatas Rp.

  200.000,-

Ambil Uang

Nasabah

Tutup

Rekening

• Ada 4 jenis relasi yang bisa timbul pada use case diagram
• – Association antara actor dan use case
• – Association antara use case

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

  Beli Barang Konsumen Bayar Kasir

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

  Buka Deposito

  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)

  Pembayaran Bayar Khusus Pembayaran

  Bayar 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 _Khusus 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:
Usecase berdasarkan sistem usulan atau berdasar program Contoh Kasus Penggajian (Acknowledgments Evi Lutfi Muktar) Use Case Absen

  Cetak Rekap Absen TU Administrasi

  >> e d u cl In

  << Input Data Absen Harian

  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

  Use Case Rekap Biodata Pegawai

  Cetak Rekap Biodata Pegawai

  TU Administrasi

  >> e d u cl In

  <<

  Input Data Pegawai, Pendidikan, Keluarga

  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) Input Data Pegawai,data pendidikan, data keluarga

  PKS, Insentif, Fungsional, Transport, Potongan e>> ud

  

Incl

<< Cetak Slip Gaji Administrasi

  Pegawai >> e d u cl In

  <<

  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) _{nomor pelanggan tarif <<include>>} daya

_{<<include>>}

_{pendaftaran pendaftaran rubah daya formulir} <<include>> _{pengunjung <<extend>>} pelanggan data i_01

  Gambar Use case cetak surat jawaban _{nomor agenda surat jawaban surat jawaban pendaftaran pendaftaran cetak formulir cetak} <<include>> _{user <<extend>>} rubah daya _pelanggan data i_01 Gambar Use case cetak surat perjanjian jual beli _{nomor agenda cetak cetak cetak formulir} <<include>> _user surat perjanjian _{jual beli tenaga jual beli surat jawaban surat perjanjian rubah daya pendaftaran listrik pelanggan} <<extend>>

  data i_01 Gambar Use case cetak kwitansi.

pendaftaran

^formulir

data i_01 ^{<<extend>>}

^{rubah daya}

^cetak

^{surat jawaban}

^{nomor agenda pelanggan} _{data kwitansi} ^{user <<include>> <<extend>>}

^cetak

^kwitansi

  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 s imbola 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.
>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.

  terlihat bahwa yang

• Kalau kita lihat 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 pembayaran tunai} Membuat Kwitansi ^{tidak ya}

Menerima Kwitansi lunas

^{Memberikan Bukti transfer Lunas} _{Ttd Kwitansi Lunas Terima Kwitansi Lunas} ^{Bagian Keuangan Menerima kwitansi Membuat Kwitansi Lunas Menerima Kwitansi ya tidak}

  Activity Diagram Laporan

  Pimpinan Bagian Keuangan & Adm

  Membuat Laporan Pemesanan Menyerahkan laporan Terima Laporan

Procedure Berjalan

  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.

  Pegawai TU Melakukan absen harian

  Menerima laporan Tidak Absen Pegawai melapor ke Absen pegawai yang tidak TU absen Ya Absen

  Mencatat absen Melakukan absen di pegawai form daftar hadir

  Merekap absensi berdasarkan form daftar hadir

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

  Pegawai TU

  Memberikan data Menerima data pegawai pegawai Mengecek berkas Menerima data pegawai berkas data pegawai tidak lengkap Data tidak Lengkap

  Data Lengkap Mengembalikan Data Data pegawai berkas data pegawai

  Pegawai diproses 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. _{TU Administrasi Kepala Sekolah}

  Memberikan data _{Rekap Absen rekap absen & data Menerima pegawai} Memberikan data _{Pegawai daftar data pegawai Membuat} dan gaji _{daftar data pegawai daftar data pegawai} Menyerahkan Menerima _{dan gaji dan gaji daftar data pegawai} Menyetujui _{dan gaji}

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

  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.

  Kepala Sekolah Administrasi Pegawai Menyerahkan Menerima daftar data pegawai daftar data pegawai dan gaji acc dan gaji acc

  Membuat Membuat lap data pegawai dan Slip gaji lap gaji pegawai Menerima

  Menerima Lap data pegawai dan Slip gaji lap gaji pegawai