PERCOBAAN 1

USE CASE DIAGRAM

(Laporan Praktikum Rekayasa Perangkat Lunak)

Oleh :
Sawitri Fina Kartika 1815061008

PROGRAM STUDI TEKNIK INFORMATIKA

JURUSAN TEKNIK ELEKTRO
FAKULTAS TEKNIK
UNIVERSITAS LAMPUNG
2020
I. JUDUL PERCOBAAN

USE CASE DIAGRAM

II. TUJUAN PERCOBAAN

Adapun tujuan dari percobaan ini adalah sebagai berikut:

1. Dapat memahami hubungan antara aktor dengan use case diagram.
2. Dapat membuat use case diagram dari skenario yang telah ada.
3. Dapat menganalisis dan membuat sebuah skenario suatu sistem yang nantinya
dapat diimplementasikan menjadi sebuah perangkat lunak.

III. TEORI DASAR

Unified Modeling Language merupakan arsitektur yang bekerja dalam OOAD dengan
satu bahasa yang konsisten untuk menentukan, visualisasi, mengkontruksi, dan
mendokumentasikan artifact yang terdapat dalam sistem software. UML merupakan
kesatuan dari dari ketiga pemodelan tersebut dan ditambah kemampuan lebih karena
mengandung metode tambahan untuk mengatasi masalah pemodelan yang tidak dapat
ditangani ketiga metode tersebut. Tujuan UML diantaranya, memberikan model yang
bisa dipakai siapa saja dengan model yang ekspresif, memberikan pemodelan yang
dapat dipakai oleh semua program, menyatukan praktek-praktek terbaik yang terdapat
dalam pemodelan.

Use case diagram adalah suatu urutan interaksi yang saling berkaitan antara sistem
dan aktor. Use case diagram juga merupakan rangkaian/uraian sekelompok yang
saling terkait dan membentuk sistem secara teratur yang dilakukan atau diawasi oleh
sebuah aktor. Use case melalui sebuah cerita yang mana sebuah sistem itu dipakai.
Use case juga dipakai untuk membentuk perilaku sistem yang akan dibuat.

Tabel 3.1 Simbol pada Use case diagram

Simbol Penjelasan
Aktor
Menspesifikasikan seperangkat peranan yang user sistem
dapat diperankan ketika berinteraksi dengan use case.

Association
Menggambarkan interaksi antara aktor dan use case.
Generalization
Relasi antar use case, dimana salah satunya dalam
bentuk yang lebih umum dari yang lain.

Use Case
Sebuah deskripsi dari seperangkat aksi-aksi berurutan
Use Case
yang ditampilkan pada sebuah sistem.
System
SYSTEM Tempat seluruh aktivitas-aktivitas sistem yang sedang
berjalan.
Dependancy
Untuk menggambarkan ketergantungan sebuah use case
dengan use case lainnya.
< Include
<<<Include>> Menggambarkan bahwa keseluruhan dari sebuah use
case merupakan fungsionalitas use case lainnya.
Extend
<< Extend>> Menggambarkan hubungan antar use case dimana
 bahwa sebuah use case merupakan fungsionalitas use
case lainnya apabila kondisi tertentu terpenuhi.

Sebuah UC diagram menyatakan visualisasi interaksi yang terjadi antara pengguna

dengan sistem. Diagram ini bisa menjadi gambaran yang bagus untuk menjelaskan
konteks dari sebuah sistem sehingga terlihat jelas batasan dari sistem . Ada 2 elemen
penting yang harus digambarkan, yaitu aktor dan UC. Aktor adalah segala sesuatu
yang berinteraksi langsung dengan sistem, bisa merupakan orang atau sistem
komputer yang lain. Aktor bisa bersifat primer, yaitu yang menginisiasi berjalannya
sebuah UC, atau sekunder, yaitu yang membantu berjalannya sebuah UC. UC
dinotasikan dengan simbol elips dengan nama kata kerja aktif di bagian dalam yang
menyatakan aktivitas dari perspektif aktor. Setiap aktor dimungkinkan untuk
berinteraksi dengan sistem dalam banyak UC. Sebaliknya, setiap UC bisa dijalankan
oleh lebih dari satu aktor.

Terdapat 3 aktor dalam Use case diagram. Pertama, pengguna system merupakan
aktor secara fisik atau seorang pengguna, gambaran secara umum dan selalu ada pada
setiap system. Kedua, sistem yang lain dan berhubungan dengan sistem yang
dibangun. Misalkan pada sebuah sistem Informasi Puskesmas memerlukan koneksi
dengan aplikasi sistem yang lain, semisal SIM rumah sakit. Maka dalam kasus ini,
SIM rumah sakit adalah aktor. Ketiga, Waktu. Dapat menjadi aktor jika seiring
perjalan waktu dapat memicu event/kejadian dalam sistem.

Langkah-langkah yang dibutuhkan untuk menyusun diagram use case adalah

mengidentifikasi pelaku bisnis, mengidentifikasi use case persyaratan bisnis,
membuat diagram model use case, mendokumentasikan naratif use case persyaratan
bisnis.
 Gambar 3.1 Contoh Use case diagram
Sumber : https://sis.binus.ac.id/2016/06/15/use-case-description/

Kesalahan yang terjadi dalam pembuatan UC diagram ada beberapa hal . Pertama,
Batasan sistem yang inkonsisten, kesalahan ini terjadi karena kita tidak konsisten
dalam menentukan batasan sistem yang akan dijelaskan dalam diagram, apakah pada
level model aplikasi, atau level model bisnis. Sehingga, kedua level model tersebut
akan tergambar pada diagram yang sama. Kedua,identifikasi aktor yang tidak tepat
Kesalahan ini terjadi ketika kita menentukan aktor dari sebuah UC yang tidak sesuai
dengan penjelasan yang ada pada UC scenario, berkaitan dengan prakondisi dan
kondisi akhir. Dalam praktiknya, kesalahan ini sering terjadi dalam menentukan aktor
untuk UC Login. Ketiga, UC tidak lengkap tergambarkan, kesalahan ini terjadi
karena kita menganggap bahwa UC diagram yang dibuat tidak perlu mengilustrasikan
seluruh UC yang ada pada sistem, cukup UC yang penting-penting saja yang sesuai
dengan fungsionalitas utama sistem. Semua UC yang (dianggap) semestinya sudah
ada tidak perlu digambarkan, yang dalam praktiknya UC Login dan UC Logout
sering diabaikan.
Practical guidance dalam membangun diagram use case secara bertahap dengan
melakukan set konteks dari target system, identifikasi semua aktor, identifikasi semua
use case, definisikan asosiasi antara setiap aktor dan setiap use case, evaluasi setiap
aktor dan setiap use case untuk mendapatkan kemungkinan perbaikan, evaluasi setiap
use case untuk dependensi <<include>>, evaluasi setiap use case untuk dependensi
<<extend>>, evaluasi setiap aktor dan setiap use case untuk generalisasi.

Setelah berhasil mendefine Use Case tahap selanjutnya adalah masing masing dari
Use Case tersebut akan di Breakdown serta akan dijelaskan lebih detail menggunakan
diagram yang bernama Use Case Description. Dalam pembuatan deskripsi use case
ini beiasanya terlebih dahulu akan membuat sebuah activity diagram yang
memberikan sebuah gambaran dari use case diagram.

Gambar 3.2 Contoh Use Case Description.

Sumber : https://sis.binus.ac.id/2016/06/15/use-case-description/
 IV. PROSEDUR PERCOBAAN

Adapun prosedur percobaan ini adalah sebagai berikut:

Studi Kasus : Vending Machine
Terdapat sebuah mesin penjual minuman kaleng otomatis di samping pintu lab
komputer teknik elektro. Mesin tersebut menjual 5 macam minuman dengan harga
sama yaitu Rp.5.000,-. Pembeli dapat menggunakan pecahan uang kertas Rp. 1.000,-
hingga 5.000,-, namun harus sesuai jumlahnya dengan harga (tidak ada kembalian).
Setiap 14 hari sekali, operator akan datang dan mengganti minuman dengan stok yang
baru, serta mengambil uang yang telah terkumpul pada mesin untuk disetorkan
kepada perusahaan penjual.
Membuat sebuah use case diagram dari kasus vending machine tersebut!

4.1. Percobaan 1 : Mengidentifikasi Aktor.

Aktor dapat diidentifikasi dari adanya kata ganti orang, maupun entitas eksternal di
luar sistem. Dalam kasus ini, hanya terdapat 2 kata ganti orang, yaitu : Pembeli dan
Operator.
1. Menggambar entitas sistem menggunakan template SimpleClass :

Gambar 4.1.1 Simple Class

 2. Menambahkan 2 buah aktor dengan menggunakan template Aktor :

Gambar 4.1.2 Penambahan Aktor

3. Mengubah nama kedua aktor tersebut (serta nama sistem) sesuai dengan apa
yang telah kita identifikasi :

Gambar 4.1.3 Penyesuaian dengan kasus

4.2. Percobaan 2 : Mengidentifikasi Use Case Langsung

Use case langsung dapat diidentifikasi dengan cara menurunkan “tema interaksi
utama” antara aktor dan sistem. Mulai dengan pertanyaan seperti :
 “Untuk apa pembeli berinteraksi dengan vending machine? Untuk membeli
minuman”.
 “Untuk apa operator berinteraksi dengan vending machine? Untuk mengganti
stokdan/atau menarik uang hasil penjualan”.

1. Membuat 3 use case baru menggunakan template Use Case 2 (latar biru):

Gambar 4. 2.1 Pembuatan Use Case

2. Memberi nama ketiga use case tersebut sesuai dengan apa yang telah
diidentifikasi. Atur ukuran jika diperlukan.
 Gambar 4.2.2 Penamaan use case

3. Menghubungkan masing-masing use case kepada aktor terkait :

Gambar 4.2.3 Menghubungkan Use Case dengan aktor

4.3. Percobaan 3 : Mengidentifikasi Use Case bawaan(Include)

Use case bawaan dapat diidentifikasi dengan melakukan break down terhadap
Use case utama yaitu sebagai barikut:
1. Apa saja skenario dalam kegiatan “MembeliMinuman”?
 a. Memasukkan uang
b. Memilih minuman
c. Mendapatkan minuman
2. Apa saja skenario dalam kegiatan “MenggantiStok”?
a. Membuka kunci
b. Mengganti stok
3. Apa saja skenario dalam kegiatan “Menarik uangpenjualan”?
a. Membuka kunci
b. Menarik uang penjualan

Menggambar ke dalam use case dengan menggunakan template Use Case 1 dan
panah Include :

Gambar 4.3.1 Menentukan Include

Catatan : Untuk menjaga simplisitas, hanya use case utama (latar biru) yang perlu
garis penghubung langsung kepada aktor. Selain itu, skenario yang redundan dengan
use case utama (perhatikan mengganti stok / menarik uang penjualan) tidak perlu lagi
dibuatkan included use case.

4.4. Percobaan 4: Mengidentifikasi Use Case spesifik(Extend)

Use case spesifik ditandai dengan kondisi-kondisi khusus yang harus dipenuhi untuk
sebuah skenario dapat berjalan. Contoh dari skenario spesifik pada kasus di atas
antara lain:
1. Menolak uang jika pada skenario “Memasukkan uang” pembeli memasukkan
jenis uang yang tidak dikenal oleh sistem.
2. Menolak pemilihan minuman jika pada skenario “Memilih minuman” pembeli
memilih minuman yang out of stock.

Membuat 2 use case baru untuk skenario spesifik tersebut menggunakan template Use
Case 3. Setelah itu, hubungkan dengan skenario yang terkait (dalam hal ini
“Memasukkan uang” dan “Memilih minuman”) menggunakan panah Extend.
Perbesar ukuran gambar jika diperlukan, dan jangan lupa menambahkan juga kondisi
dari skenario spesifik pada deskripsi penghubung.

Gambar 4.4.1 Menetukan Extend

V. PEMBAHASAN

Adapun pembahasan pada percobaan ini adalah sebagai berikut:

Nama Kasus : Aplikasi Pemesanan Ruangan Online (PRO)
Aplikasi Pemesanan Ruangan Online (PRO) berfungsi untuk memudahkan user
dimana merupakan dosen dan mahasiswa untuk mengetahui keberadaan ruangan yang
tidak ditempati sebagai tempat pembelajaran matakuliah tambahan atau pengganti di
geduh H Teknik Elektro. Juga digunakan agar ruangan tersebut tetap terjaga baik
properti maupun suasana yang ada di dalam ruangan. Dalam aplikasi ini, admin
bertanggung jawab mengelola semua aktivitas dari user. Sedangkan user yang telah
didaftarkan oleh admin dapat langsung melakukan login untuk memasuki aplikasi.
Baik itu admin atau user dapat melihat jadwal dan memesan ruangan kecuali user
dengan sepsifikasi mahasiswa. Mahasiswa dapat melakukan pemesanan jika
mendapat persetujuan dari dosen yang berupa pemberitaan melalui aplikasi tersebut
kepada dosen.

5.1 Percobaan 1 : Mengidentifikasi Aktor

Tabel 5.1 Percobaan 1 : Mengidentifikasi Aktor

Actor Deskripsi
Admin Aktor dengan role ini mempunyai wewenang untuk melakukan
pendaftaran akan mahasiswa dan dosen, melakukan pemesanan
ruangan, melihat jadwal ruangan dan daftar pesanan ruangan,
serta dapat masuk maupun keluar dari aplikasi.
Mahasiswa Aktor dalam mempunyai wewenang untuk melakukan
pemesanan ruangan dengan syarat harus menerima konfirmasi
dari dosen, meihat jadwal ruangan dan daftar pesanan ruangan,
serta dapat masuk maupun keluar dari aplikasi.
Dosen Aktor dalam mempunyai wewenang untuk melakukan
pemesanan ruangan, meihat jadwal ruangan dan daftar pesanan
ruangan, serta dapat masuk maupun keluar dari aplikasi.
5.2 Percobaan 2 : Mengidentifikasi Use Case Langsung

Tabel 5.2 Percobaan 2 : Mengidentifikasi Use Case Langsung

Use Case Langsung Deskripsi
Log in Aktor akan masuk kedalam aplikasi untuk mengakses fitur
Melihat jadwal Sistem menampilkan jadwal tetap dan pesanan ruangan,
ruangan sehingga aktor dapat melihat ruangan yang belum dipesan.
Konfirmasi dosen Mahasiswa harus mendapat persetujuan dosen matakuliah
bersangkutan untuk memesan ruangan.
Pemesanan ruangan Sistem menampilkan pilihan ruangan yang belum dipesan
beserta waktu sesuai matakuliah.
Mendaftarkan akun Hanya admin yang dapat mendaftarkan mahasiswa dan
mahasiswa dan dosen dosen kedalam aplikasi PRO.
Daftar pesanan Sistem akan menampilkan daftar ruangan yang telah
ruangan dipesan akun aktor.
Log out Aktor akan dapat keluar dari aplikasi PRO

5.3 Percobaan 3 : Mengidentifikasi Use Case bawaan (Include)

Tabel 5.3 Percobaan 3 : Mengidentifikasi Use Case bawaan (Include)

Use Case Langsung Use Case Bawaan Deskripsi
Konfirmasi dosen Pemesanan ruangan Sistem menampilkan pilihan
ruangan yang belum dipesan
beserta waktu sesuai matakuliah.
Pemesanan ruangan Mendapatkan kode Sistem akan menampilkan kode
QR QR setelah berhasil melakukan
pemesanan untuk membuka
ruangan.

5.4 Percobaan 4: Mengidentifikasi Use Case spesifik (Extend)

Tabel 5.4 Percobaan 4: Mengidentifikasi Use Case spesifik (Extend)

 Use Case Langsung Use Case Spesifikasi Deskripsi
Konfirmasi dosen Tidak terkonfirmasi Mahasiwa tidak mendapat
persetujuan dosen untuk memesan
ruagan

5.5 Diagram Use Case

Gambar 5.5 Diagram Use Case

Berdasarkan gambar 5.4 menjelaskan diagram use case tentang Aplikasi Pemesanan
Ruangan Online (PRO). Dimana pada sistem ini terdapat 3 aktor yang terdiei
mahasiswa, dosen, dan admin. Aktor mahasiswa mempunyai beberapa hak pada
sistem yaitu, dapat melakuakan login, dapat melihat jadwal ruangan, dapat melihat
daftar pesanan ruangan,dapat melakukan pemesanan ruangan namun harus menerima
konfirmasi dosen, dan dapat melakukan log out. Aktor dosen mempunyai beberapa
hak pada sistem antara lain dapat melakukan login, dapat melihat jadwal ruangan,
dapat melihat daftar pesanan ruangan,dapat melakukan pemesanan ruangan, dan
dapat melakukan log out. Aktor terakhir yaitu admin mempunyai beberapa hak
penting, dapat melakukan login,dapat mendaftarkan akun mahasiswa dan dosen,
dapat melihat jadwal ruangan, dapat melihat daftar pesanan ruangan,dapat melakukan
pemesanan ruangan, dan dapat melakukan log out. Ketiga aktor ini akan mendapatkan
kode QR jika telah sukses melakukan pemesanan atau ruangan telah dipesan yang
berda pada daftar pesanan ruangan.
VI. KESIMPULAN

Adapun kesimpulan dari percobaan ini adalah sebagai berikut:

1. Relasi include mempunyai bentuk panah putus-putus dengan arah panah
mengarah dari use case langsung ke use case bawaan yang fungsinya
menjalankan usecase bawaan setelah usecase langsung dijalankan
2. Mahasiswa merupakan aktor primary yang umumnya diletakkan di sebelah
kiri sistem, sedangkan admin merupakan aktor secondary yang umumnya
diletakkan disebelah kanan.
3. Relasi generalization mempunyai bentuk panah yang mengarah ke arah
usecase orangtua dikarenakan usecase anak merupakah hasil dari sifat umum
usecase orang tua.
4. Relasi assosiation hanya digunakan pada relasi antar usecase dengan aktor.
5. Relasi extend mempunyai bentuk panah putus-putus yang arah panahnya
mengarah ke use case langsung yang fungsinya sebagai pendukung sehingga
use case spesifikasinya tidak harus dijalankan saat use case langsung
dijalankan
DAFTAR PUSTAKA

Hartono, Milawati 2016. Pengertian, Komponen dan Contoh Use Case Diagram.
Diperoleh 1 Mei 2020 dari
https://milawatihartono.wordpress.com/2016/03/31/use-case-diagram/
Hendini, Ade. 2016. Pemodelan Uml Sistem Informasi Monitoring Penjualan Dan
Stok Barang (Studi Kasus: Distro Zhezha Pontianak). Jurnal Khatulistiwa
Informatika. 4 (2) : 107-116
Kurniawan ,Tri A.. 2018. Pemodelan Use Case (Uml): Evaluasi Terhadap Beberapa
Kesalahan Dalam Praktik. Jurnal Teknologi Informasi Dan Ilmu Komputer
(JTIIK). 5, (1) : 77-86.
Nurmoslim, Arilla. 2016. Use Case Description. Diperoleh 1 Mei 2020 dari
https://sis.binus.ac.id/2016/06/15/use-case-description/.
Pccontrol, 2012. Pengetahuan Dasar Diagram Use Case. Diperoleh 1 Mei 2020 dari
https://pccontrol.wordpress.com/2012/08/23/pengetahuan-dasardiagram-use-
case/
 TUGAS AKHIR

Studi Kasus : Mesin ATM

Sebuah mesin ATM beroperasi 24 jam untuk melayani nasabah yang akan melakukan
transaksi perbankan. Transaksiyang dapat dilayani oleh ATM tersebut hanyalah
penarikan tunai dan informasi saldo. Seperti layaknya mesin ATM lainnya, mesin
tersebut akan melakukan verifikasi keamanan menggunakan kode PIN. Jika pengguna
salah memasukkan PIN sebanyak 3 kali, maka kartu ATM yang digunakan akan
“ditelan” oleh mesin tersebut. Uang tunai dalam mesin ATM tersebut diisi ulang rutin
2 hari sekali, maupun insidental jika stok uang tunai habis sebelumwaktunya.

1. Mengidentifikasi Aktor

Tabel 1 Mengidentifikasi Aktor

Actor Deskripsi
Nasabah Aktor dalam mempunyai wewenang untuk melakukan
memasukkan kartu, mengeluarkan kartu, melakukan
transaksi, melakukan verivikasi.
Oprator Aktor dalam mempunyai wewenang untuk melakukan
melakukan pengisian uang pada ATM.

2. Mengidentifikasi Use Case Langsung

Tabel 2 Mengidentifikasi Use Case Langsung

Use Case Langsung Deskripsi
Masukkan kartu Kartu nasabah dimasukkan sebagai tanda login akun
Pengisian uang Dilakukan pengisian uang rutin 2 kali sehari maupun
insidental jika stok uang tunai habis sebelum waktunya

3. Mengidentifikasi Use Case bawaan (include)

Tabel 3 Mengidentifikasi Use Case bawaan (include)
Use Case Langsung Use Case Bawaan Deskripsi
Masukkan kartu dan Kartu dikeluarkan Kartu nasabah dikeluarkan sebagai
Transaksi perbankan tanda logout akun
Verivikasi keamanan Transaksi perbankan Sistem menampilkan fungsi-fungsi
dalam melakukan transaksi dalam
ATM
Masukkan kartu Verifikasi keamanan Sistem melakukan verifikasi
keamanan menggunakan kode PIN
untuk menarik uang dari ATM

4. Mengidentifikasi Use Case spesifik (Extend)

Tabel 4 Mengidentifikasi Use Case spesifik (Extend)

Use Case Langsung Use Case Spesifikasi Deskripsi
Verivikasi keamanan Kartu ditelan Sistem tidak mengizinkan kartu
keluar jika pengguna salah
memasukkan PIN sebanyak 3 kali.

5. Mengidentifikasi Use Case anak (Generalization)

Tabel 5 Mengidentifikasi Use Case anak (Generalization)

Use Case Orang Use Case Anak Deskripsi
Tua
Penarikan tunai Salah satu turunan transaksi perbankan
untuk melakukan penarikan uang
Transaksi perbankan
Informasi saldo Salah satu turunan transaksi perbangkan
untuk melihat informasi saldo

6. Diagram Use Case

 Gambar 6 Diagram Use Case

Berdasarkan gambar 1 menjelaskan diagram usecase tentang diagram mesin ATM.

Pada sistem mesin ATM mempunyai 2 aktor yaitu nasabah dan operator. Kedua aktor
ini tidak mempunyai kesamaan pada fungsi sistem. Perbedaan keduanya ialah,
nasabah harus memasukkan kartu untuk melakukan transaksi perbankan dan dapat
mengeluarkan kartu sedangkan operator dapat melakukan pengisian uang pada ATM.
Untuk melakukan transaksi, nasabah harus melakukan verifikasi keamanan. Jika saat
verifikasi nasabah salah menginputkan pin hingga 3 kali, maka kartu nasabah akan
ditelan. Jika verifikasi berhasil, maka nasabah dapat melakuakn transaksi perbankan
berupa penarikan tunai dan informasi saldo