ANALISA DESAIN

BERORIENTASI
OBJEK
Dwi Krisbiantoro, M.Kom

Program Studi Sistem Informasi

STMIK Amikom Purwokerto

Daftar Pustaka

[Pressman, 2012] Pressman, Roger S. Rekayasa

Perangkat Lunak_Buku Satu: Pendekatan Praktisi.
Edisi 7. Yogyakarta: Penerbit ANDI, 2012.
[Sommerville, 2003] Sommerville, Ian. Software
Engineering Rekayasa Perangkat Lunak Jilid 1. Edisi
6. Ciracas, Jakarta: Penerbit ERLANGGA. 2003.
[Rosa A. S-M. Shalahudin, 2013] Rosa A. S, M.
Shalahudin. Rekayasa Perangkat Lunak :
Terstruktur dan Berorientasi Objek. Bandung:
Penerbit Informatika, 2013.

Pokok Bahasan
1. Konsep Pemodelan Use Case
a.
b.
c.
d.

Aktor
Use Case
Aliran Kejadian (Flow of Events)
Relasi

2. Diagram Use Case

Pengertian
Analisa berorientasi objek adalah cara baru dalam memikirkan
sebuah masalah dengan menggunakan model yang dibuat
menurut konsep sekitar dunia nyata. Dasar pembuatan adalah
objek, yang merupakan penggabungan antar struktur data dan
perilaku dalam sebuah entitas.

Mengapa Berorientasi
Objek

Metodologi lama banyak menimbulkan masalah

Adanya kesulitan pada saat mentransformasi hasil dari suatu tahap
pengembangan ke tahap berikutnya, misalnya pada metode
Structured Analysis and Design
Jenis aplikasi yang dikembangkan saat ini berbeda dengan masa lalu.
Aplikasi yang dikembangkan pada saat ini sangat beragam (apliksi
bisnis, real-time, utility dan sebagainya) dengan platform yang
berbeda-beda, sehingga menimbulkan tuntunan kebutuhan
metodologi pengembangan yang dapat mengakomodasi ke semua
jenis aplikasi tersebut.

Keuntungan Berorentasi Objek

Meningkatkan produktivitas
Karena kelas dan objek yang ditemukan dalam suatu masalah
masih dapat

dipakai ulang untuk masalah lainnya yang

melibatkan objek tersebut (reusable).

Kecepatan pengembangan
Karena sistem yang dibangun dengan baik dan benar pada saat
analisis

dan perancangan akan menyebabkan berkurangnya

kesalahan pada saat pengkodean.

Kemudahan pemeliharaan
Karena dengan objek, pola-pola yang cenderung tetap dan stabil
dapat dipisahkan dari pola-pola yang mungkin sering berubah.

Definisi Use
Case

Pemodelan use case adalah langkah kritis

dalam pengembangan sistem informasi,
karena use case adalah alat utama untuk
menangkap
kemauan
pemakai
akhir
terhadap sistem yang akan dibangun. Pada
langkah
ini
dibutuhkan
kehati-hatian
seorang analis sistem. Oleh sebab itu, sekali
lagi, bersabarlah kalau langkah ini memakan
waktu. Sebagian besar warna sistem
ditentukan pada langkah ini. (Sholiq, 2006)

 Use
case kegiatan/aktifitas
yang
disiapkan oleh sistem. Menekankan
pada apa yang dikerjakan oleh sistem,
bukan bagaimana sistem itu bekerja.

Tentang Use Case

a. Mendeskripsikan bagaimana sistem bereaksi

terhadap aksi yang dilakukan aktor.

b. Menggambarkan aktifitas yang dilakukan
sistem dari sudut pandang user (actor).
c. Menggambarkan hubungan antara use case
dan aktor.
d. Use case dibuat berdasarkan keperluan aktor
apa yang dikerjakan sistem, bukan
bagaimana sistem mengerjakannya.
e. Diagram Use Case berkaitan dengan
kejadian-kejadian. Kejadian (scenario)
merupakan apa yang terjadi ketika

Manfaat Use case bagi

client

Dengan melihat use case, mereka dapat

melihat
fungsionalitas
yang
akan
disediakan oleh sistem
Dengan melihat aktor, mereka dapat
melihat siapa saja yang akan berinteraksi
dengan sistem
Dengan melihat kumpulan aktor dan use
case, mereka dapat mengetahui ruang
lingkup proyek yang akan dibuat

Cara Identifikasi Use Case

Menjawab pertanyaan:
Apa yang masing-masing aktor kerjakan
dalam Sistem?
Apa yang pemakai harapkan dari sistem?
Fungsionalitas apa saja yang stakeholder
harapkan dari sistem.

Cara Menghasilkan Use

Case yang baik
1. Pilihlah nama yang baik
2. Ilustrasikan & identifikasi perilaku
dengan lengkap
3. Sediakan use case lawan (inverse)
4. Batasi use case hingga satu perilaku
saja
5. Nyatakan Use case dari sudut pandang
Aktor

Use Case Pilihlah nama

yang baik
Use case adalah sebuah behaviour (perilaku),
jadi sebaiknya dalam frase kata kerja.
Untuk membuat namanya lebih detil,
tambahkan kata benda yang meengindikasikan
dampak aksinya terhadap suatu kelas objek.
Use Case seharusnya berhubungan dengan
diagram kelas.
Contoh:
Pemesanan Kamar
Pembukaan Kartu
Mereplikasi Database

Use Case Ilustrasikan & identifikasi

perilaku dengan lengkap
Use case diinisiasi oleh aktor primer dan
berakhir pada aktor, mencapai tujuan dan
menghasilkan nilai tertentu.
Pilihlah frase kata kerja yang implikasinya
hingga selesai. Contoh:
pemesanan kamar bukan memesan kamar

Jangan membuat Use Case yang merupakan

bagian skenario dari Use Case lain. Contoh:
Use Case Memilih tempat tidur tidak dapat dijadikan
sebagai Use Case yang mandiri, karena merupakan
bagian dari Use Case Pemesanan Kamar (tidak
mungkin tamu memilih tempat tidur tanpa memesan
kamar hotel).

Use Case Sediakan use

case lawan (inverse)
Sediakan Use Case lawan untuk
membatalkan tujuan.
Contoh:
Use Case Pemesanan Kamar
Use Case lawan Pembatalan pesanan kamar

Use Case Batasi use case

hingga satu perilaku/tujuan saja
Buatlah use case yang hanya fokus pada
satu perilaku/tujuan saja supaya tidak
terjadi kerancuan.
Contoh:
Penggunaan use case Check-in dan Checkout dalam satu use case menghasilkan
ketidakfokusan, karena memiliki dua perilaku
yang berbeda.

Use Case Nyatakan Use

case dari sudut pandang Aktor
Tuliskan nama Use Case dari sudut
pandang Aktor bukan Sistem.
Contoh:
Pilih nama Use Case Pemesanan Kamar
(sudut pandang Aktor) bukan Pencatatan
Pesanan Kamar (sudut pandang Sistem)

Komponen Use
Case

Komponen Use Case

Diagram
Simbol
Penjelasan
Use case
Berisi kejadian yang berhubungan dengan
database
Aktor:
Adalah orang / bagian (database eksternal)
yang berhubungan dengan sistem
System Boundary:
Berisi kumpulan use case

<include>
<extend>

Relation:
Menghubungkan actor dengan use case

Cara pembuatan diagram

use case
1. Aktor
a. Tempatkan aktor utama dipojok kiri atas,
karena sebagian besar rancangan sistem
mengutamakan pelanggan, maka aktor
utamanya pelanggan (nasabah, klien,
siswa/ mahasiswa, dsb)
b. Gambarkan aktor terpisah dengan use
case
c. Berilah nama aktor dengan kata benda
tunggal.
d. Aktor minimal harus terhubung dengan
satu use case.

5. Berilah nama aktor

perannya
terhadap
jabatannya.

sesuai
model

6. Tambahkan <<system>>
berjenis sistem.

dengan
bukan

pada

aktor

7. Jangan menghubungkan langsung antara

aktor satu dengan yang lain (kecuali
generalisasi). Aktor satu dengan yang
lainnya harus terhubung melalui use
case.
8. Tambahkan aktor waktu (time) untuk
sistem yang terjadwal otomatis.

Penempatan Aktor
Sistem

Akto
r
UTA

Aktor
PENDUKU
NG

1.a. Aktor (Actor)

Aktor adalah seseorang atau apa saja
yang berhubungan dengan sistem yang
sedang dibangun
Aktor merupakan semua yang berada di
luar ruang lingkup sistem

1.a. Aktor (Actor)

[Lanjut]
Terdapat 3 (tiga) tipe aktor, yaitu:
1. Pengguna sistem,
2. Sistem lain yang berhubungan dengan
sistem yang sedang dibangun, dan
3. Waktu.

Simbol Aktor

Admin

1.a. Aktor (Actor)

[Lanjut]
Aktor-Pengguna sistem, contoh:
Aktor secara fisik atau pengguna
sistem:

Petugas penjualan
Kasir
Manajer
Pelanggan
Admin

1.a. Aktor (Actor)

[Lanjut]
Aktor-Sistem lain, contoh:
Aktor sistem lain:

Antarmuka dengan aplikasi ekternal untuk

memvalidasi pembelian menggunakan kartu
kredit/debit.

1.a. Aktor (Actor)

[Lanjut]
Aktor-waktu, contoh:
Ketika waktu tertentu memicu beberapa
kejadian dalam sistem.
Contoh:
Pada hari tertentu atau jam tertentu sistem
secara otomatis akan mengirimkan email
tagihan kartu kredit.

Actor Aktor Bisnis

Utama [1]
Pengertian Stakeholder yang terutama
mendapatkan keuntungan dari
pelaksanaan Use-Case dengan menerima
nilai yang terukur atau terobservasi.
Contoh:
Karyawan (Stakeholder) yang menerima Gaji
(nilai terukur) akibat dari pelaksanaan UseCase/Sistem (catatan: aktor Karyawan tidak
berhubungan langsung dengan Sistem Penggajian).

Actor Aktor Sistem

Utama [1]

Pengertian Stakeholder yang secara langsung

berhadapan dengan sistem untuk menginisialisasi
atau memicu kegiatan atau sistem.
Aktor Sistem Utama dapat berinteraksi dengan
Aktor Bisnis Utama untuk menggunakan sistem
Aktual. Contoh:
Operator Telepon dengan pelanggan (informasi)
Kasir Bank dengan Nasabah (transaksi perbankan)

Aktor Sistem Utama dan Aktor Bisnis Utama

terkadang dapat menjadi pelaku bisnis yang
sama-sama berhadapan langsung dengan sistem.
Contoh:
Jasa Pelayanan melalui Website

Actor Aktor Pelayan

Eskternal [1]
Pengertian Stakeholder yang melayani
kebutuhan pengguna Use-Case di luar
sistem/Use-Case.
Contoh:
Biro Kredit yang memiliki kuasa atas
perubahan Kartu Kredit

Actor Aktor Penerima

Eksternal [1]
Pengertian Stakeholder yang bukan
pelaku utama (aktor bisnis utama & aktor
sistem utama) tapi menerima nilai yang
terukur atau teramati dari Use-Case.
Contoh:
Gudang/Kurir yang menerima permintaan
untuk menyiapkan pengiriman setelah
seorang pelanggan memesan.

2. Use case
a. Use case diberi nama dengan menyatakan

apa hal yang dicapai dari hasil interaksinya

dengan aktor.
b. Use case dinotasikan dengan gambar elips.
c. Use case biasanya dimulai dengan kata
kerja.
d. Penulisan nama use case biasanya di
dalam gambar elips.
e. Nama use case boleh terdiri dari beberapa
kata dan tidak boleh ada 2 use case yang
memiliki nama yang sama.
f. Susunlah use case berdasarkan urutannya

Penempatan Use Case

Sist
em

Akto
r1

Use
Case 1

Use
Case 2

Use
Case 3

Akto
r3

Relasi pada Use

Case

Relasi pada Use Case

Terdapat 4 jenis relasi yang mungkin terjadi pada use
case diagram:
a. Relasi antara aktor dan use case (Asosiasi)
b. Relasi antar use case (include) (Extend)
(Generalisasi)
c. Generalisasi/Inheritance antar aktor
d. Generalisasi/Inheritance antar use case
Asosiasi adalah.
Asosiasi = gabungan
Asosiasi bukan menggambarkan aliran
data/informasi.

Asosiasi Antara Aktor

Use Case
Gunakan garis tanpa panah untuk asosiasi

antara aktor dan use case.

Asosiasi Antara Aktor

Use Case

Contoh: customer melakukan pemesanan

tiket secara online

Kusto
mer

Memes
an
Tiket

Petugas Tiket

Asosiasi Antara Use Case

Ada 2 jenis relasi asosiasi (association

relationship) antar sesama use case,

yaitu:

Relasi Includes
Relasi Extends

Relasi Includes
Include adalah Relasi use case tambahan

ke sebuah use case dimana use case yang

ditambahkan memerlukan use case ini
untuk menjalankan fungsinya.
Relasi includes: Gunakan <<include>>
jika kita yakin suatu use case harus
melibatkan use case lain.
jika terdapat dua atau lebih use case yang
memiliki sebuah fungsi besar yang identik,
yang selalu dilakukan jika suatu use case
lain dilakukan.

 Relasi include memungkinkan terjadinya

penambahan perilaku (behaviour) ke
dalam use case awal yang pada dasarnya
use case ini tidak dapat berdiri sendiri
tanpa adanya penambahan use case, dan
use case awal tidak akan lengkap tanpa
adanya use case tambahan ini. Use case
yang berada pada kepala anak panah
adalah use case awal, dan pada sisi lain
adalah use case penambah

Contoh Relasi Include

Contoh narasinya :
setiap pelanggan dapat melihat barang dan pesan
barang tanpa harus melalui proses login dan admin harus
login terlebih dahulu untuk dapat mengisi barang dsb

Contoh Relasi
Includes
Contoh narasinya:
Setiap melakukan pembelian tiket,
selama proses tersebut dilakukan juga
pengecekan ketersediaan tiket dan
menampilkan
rincian
harga
tiket.
<<includ
Membeli
Tiket

e>>

<<includ
e>>

Cek
Ketersediaan
tiket
Lihat
Rincian
Harga
Tiket

Relasi Includes
selengkapnya
Contoh narasinya:

Sebelum melakukan penjualan tiket, penjual tiket

memasukkan ketersediaan tiket dan rincian harga
tiket.
Setiap melakukan pembelian tiket, selama proses tersebut
dilakukan juga pengecekan ketersediaan tiket dan
input
menampilkan rincian harga tiket.
Ketersediaan
tiket

Penjual
tiket

Input Rincian
Harga Tiket
<<inclu
de>>
Membeli
Tiket

<<inclu
de>>

Pembeli
tiket

Larangan dalam <<include>>

Use case utama/
Parent/base use caseSub use case
Arah panah menuju use case utama

Tidak terdapat arah panah

Association Antara Use Case

<<extend>>
Satu use case SECARA OPSIONAL menggunakan
fungsionalitas yang disediakan oleh use case lain
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

Relasi Extends

Relasi extend: Gunakan <<extend>> jika

suatu use case mungkinkan melibatkan use
case lain.
Tempatkan extend use case dibawah use
case dasar.

Contoh Relasi Extends

Contoh narasinya:
Setiap melakukan ganti pesanan, lakukan cek
harga tiket jika dan hanya jika harga tiket
berubah. Jika setelah ganti pesanan harga tiket
tidak berubah, maka tidak perlu melakukan cek
harga tiket.
Karena Cek harga tiket tidak selalu dilakukan,
maka ada sebuah relasi extend dari use case
yang secara opsional berjalan (Cek harga tiket)
<<exten
Gantiyang di-extend
Cek Rincian
ke use case
(Ganti Pesanan
tiket).
d>>
Pesanan
tiket

Use Case
Extension

Harga Tiket

Relasi Extends
selengkapnya
Contoh narasinya:
Sebelum melakukan penjualan tiket, penjual tiket memasukkan
ketersediaan tiket dan rincian harga tiket. Setiap melakukan
pembelian tiket, selama proses tersebut dilakukan juga pengecekan
ketersediaan tiket dan menampilkan rincian harga tiket. Setiap
melakukan ganti pesanan, lakukan cek harga tiket jika dan hanya
jika harga tiket berubah. Jika setelah ganti pesanan harga tiket tidak
berubah, maka tidak perlu melakukan cek harga tiket.
input
Ketersediaan
Input Rincian
Penjual
tiket
tiket
Harga Tiket
<<includ
e>>
Pembeli
<<includ
tiket

e>>
<<exte
nd>>

Membeli
Tiket
Ganti
tiket

Sudah jelas
perbedaan antara
relasi include dan
relasi extends?

Perbedaan Include dan

Extend
Include

extends

Use case included (terpanggil) Use case extended tidak selalu

selalu diperlukan oleh case dibutuhkan oleh use case dasar
dasar
Yang
memutuskan
kapan Yang
memutuskan
kapan
dipanggilnya use case included dipanggilnya use case ekstensi
adalah use case dasar
adalah use case ekstensi itu
sendiri
dimana use case yang dituju
harus melewati sebuah proses
yang lain.

dimana use case yang dituju

berdiri sendiri tanpa harus
melewati sebuah proses yang
lain.

Larangan dalam
<<extend>>
Parent/base use case
Arah panah menuju sub use case
Sub use case

Contoh <<extend>>

Contoh (salah)

Diagram ini mengatakan bahwa dalam

memesan kursi pesawat penumpang harus
memesan kursi penumpang bagian jendela
dan bagian tengah sekaligus.

Contoh (benar)

Diagram ini mengatakan bahwa ada dua

pilihan dalam memesan kursi penumpang,
pesan kursi di pinggir jendela atau kursi
tengah, namun pemesan hanya boleh
memilih satu dari dua kursi tersebut.

Relasi selengkapnya
Petugas

input tempat
duduk
Dekat jendela
input tempat
Duduk di tengah

<<extends
>>

<<extend
s>>
Memilih
tempat
duduk
<<includ
e>>
Melakukan
Cek-in

Penumpan
g

Generalisasi
Aktor dan Use
Case

Generalisasi antar Aktor

Generalisasi pada aktor dan use case

digunakan untuk menyederhanakan model

dengan cara menarik keluar sifat-sifat pada
aktor maupun use case yang sejenis.
Aktor generalisasi - beberapa aktor yang
memiliki beberapa persamaan dan
melakukan use case yang sama.
Digambarkan dengan garis dengan panah
tertutup yang mengarah ke aktor abstrak.

Generalisasi antar Aktor

Contoh:

Aktor dosen dan aktor mahasiswa

sama -sama diizinkan untuk melihat
forum.
Dalam hal ini dibuatkan satu aktor
generalisasi (aktor abstrak) yang akan
menuju ke use case Melihat Forum.
Aktor dosen dan aktor mahasiswa
sama-sama mewarisi aktor abstrak
tersebut.
Contoh use case diagramnya

Generalisasi antar Aktor

Aktor Abstrak
Relasi Generalisasi
Melih
at
Foru
m

Mahasis
wa

Dos
en

Sivitas
Akademik

Ungg
ah
Tuga
s
Ungg
ah
Slid
e

Mahasis
wa

Dos
en

Melih
at
Foru
m

Ungg
ah
Tuga
s
Ungg
ah
Slid
e

Contoh Generalisasi

Generalisasi Use Case

Generalisasi Actor

Contoh

(use case tanpa

generalisasi)
System
Mereplikasi database
Database Administrator
Membackup data user

Star Up
Backup Administrator

Shutdown

Deploy Aplikasi Web

Deployment Administrator

Contoh generalisasi pada aktor

System
System Administrator
Star Up

Shutdown

Mereplikasi database
Database Administrator

Membackup data user

Backup Administrator
Deploy Aplikasi Web
Deployment Administrator

 Untuk mengurangi kerumitan diagram

diatas, maka kita bisa menambahkan satu
aktor lagi, misalnya system administrator
yang menjalankan fungsi star up dan
shutdown database yang merupakan
generalisasi dari database, backup dan
deployment
administrator.
Notasi
generalisasi yg bisa dipakai adalah anak
panah tertutup.

Generalisasi antar Use

Case

Use case generalisasi = Use case

inheritance (pewarisan)
Dari [Miles & Hamilton, 2006]:
Kondisi dimana satu use case merupakan
tipe spesial dari use case yang lain.
Langkah yang baik untuk menggunakan
kembali use case general sehingga analis
hanya butuh melakukan spesifikasi langkah
ekstranya (spesifiknya) pada use case
spesifik.

Contoh: Generalisasi pada use case

System

Pemesan kamar

Pemesanan kamar via internet

Pemesanan via agen

Generalisasi antar Use

Case
Hal yang harus diperhatikan saat membuat
use case generalisasi:

Setiap langkah di use case general

harus terjadi di use
case spesial.
Setiap relasi dari use case general
dengan aktor juga harus sesuai dengan
use case spesial.

Jika tidak ingin use case spesial melakukan

apapun yang dilakukan oleh use case
general, maka jangan gunakan generalisasi
use case.

Generalisasi antar Use

Case
Conto Pada saat membuat blog akun baru, ada dua tipe
h:

blog yang tersedia, blog regular dan blog editorial.

Kedua blog ini memiliki spesifikasi berbeda,
namun secara umum sama-sama membuat suatu
blog akun baru.

Buat Akun Blog

Baru merupakan
use case general

Buat
Akun
Blog
Baru

Buat Akun Blog

Regular Baru dan Buat
Akun Blog Editorial
Baru menjadi use case
spesifiknya.
Buat Akun
Blog
Editorial
Baru

Buat Akun
Blog
Regular
Baru

Relasi

Aliran kejadian
(flow of events)

Aliran Kejadian
Tujuan:
Untuk mendokumentasikan aliran logika
dalam setiap use case yang menjelaskan
secara rinci apa yang pemakai akan lakukan
dan reaksi sistem.
Untuk menjelaskan apa yang sistem lakukan,
bukan bagaimana sistem bekerja.

Sifat:
Rinci
Independen terhadap implementasi

Bagian dari aliran kejadian

Nama Use case
Actor
Deskripsi singkat
Kondisi
Aliran kejadian utama dan alternatif
Kondisi awal dan kondisi akhir

Deskripsi Singkat
Deskripsi harus singkat dan langsung ke
fokus persoalan, tetapi juga harus
menyertakan tipe-tipe pemakai yang
menjalankan use case
Deskripsi harus menjelaskan kondisi akhir
dari use case

Kondisi
Kondisi Awal
Adalah kondisi yang harus dipenuhi sebelum
sebuah use case dijalankan.
Sebuah use case lain yang harus dieksekusi
sebelum use case tertentu dijalankan.

Tidak semua use case memiliki kondisi awal.

Kondisi Akhir
Adalah kondisi yang harus selalu benar
setelah sebuah use case selesai dijalankan
Tidak semua use case memiliki kondisi awal.

Aliran Kejadian
Menjelaskan spesifikasi rinci dari setiap use
case
Aliran kejadian meliputi:
Bagaimana use case dimulai
Berbagai lintasan yang melalui use case
Aliran utama (primary flow/basic flow) yang
melewati use case
Beberapa penyimpangan aliran utama yang disebut
sebagai aliran alternatif (alternate flow)
Beberapa aliran kesalahan (error flow)
Bagaimana use case berakhir

contoh

contoh

Sudah SIAP Untuk

Membuat USE
CASE DIAGRAM?

Mari kita latihan

Contoh Kasus 1:
Sistem Informasi Rekapitulasi Keuangan

Sebuah perusahaan yang sedang berkembang

ingin membuat aplikasi rekapitulasi keuangan
perusahaan untuk melakukan proses pembukuan.
Akuntan dapat melakukan input data keuangan,
ubah data keuangan, dan hapus data keuangan
pada sistem ini.
Untuk membuat rekapitulasi keuangan, Akuntan
harus masuk ke fitur melihat rekapitulasi
keuangan terlebih dahulu, kemudian
memasukkan input tanggal yang diinginkan dan
program rekapitulasi akan secara otomatis
membuat laporan pembukuan dari input akuntan.

Contoh Kasus 1:

Aktor:
Akuntan
Input data keuangan
Ubah data keuangan,
Hapus data keuangan,
Rekap Data Keuangan,
Lihat Rekapitulasi Keuangan

Contoh Kasus 1:
Sist
em

Akunt
an

Input
Data
Keuang
an
Update
Data
Keuangan

<<exten
d>>

Ubah
Data
Keuang
an
Rekap

<<exten
d>>

Data
Keuanga
n
<<includ

e>>

Melihat
Rekapitulasi
Keuangan

Hapus
Data
Keuanga
n

Contoh Kasus 2:
Sistem Waspada Banjir
BMKG ingin membuat suatu sistem yang dengan
segera dapat memberi peringatan dini bencana
banjir ke pada masyarakat.
Petugas BMKG mengirimkan informasi cuaca
ke dalam sistem. Informasi cuaca hanya
dapat dilihat oleh Petugas PU dan petugas
BMKG sendiri.
Petugas PU Memberikan update informasi
geografis banjir, yaitu menentukan daerah
berpotensi banjir dan tips seputar banjir.
Masyarakat menerima semua informasi yang
dikirimkan oleh petugas PU.

Contoh Kasus 2:

Aktor:

Petugas BMKG
Mengirimkan informasi cuaca
Melihat informasi cuaca
Petugas PU
Melihat informasi cuaca
Memberikan update informasi geografis
banjir, yaitu menentukan daerah berpotensi
banjir dan tips seputar banjir.
Masyarakat
Melihat informasi daerah potensi banjir dan
tips seputar banjir.

Contoh Kasus 2:
Sist
em
Petug
as

Melihat
Informasi
Cuaca

Petugas
BMKG

Mengirimka
n
Informasi
Cuaca
Mengir
im
Inform
asi

<<Exten
d>>
Petugas
PU

Menentuka
n Daerah
Potensi
Banjir

<<Exten
d>>
Memberi
Tips
Seputar
Banjir

Masyara
kat

Contoh Kasus
3:
Validasi
login
Petug
as

Petugas
BMKG

login

<<exten
d>>
<<includ
e>>

logout

<<exten
d>>

Validasi
user

<<includ
e>>
Melihat
Informasi
Cuaca

Mengirimka
n
Informasi
Cuaca
Mengir
im
Inform
<<exten asi

d>>
Petugas
PU

Sist
em

Menentuka
n Daerah
Potensi
Banjir

<<includ
e>>

<<exten
d>>

Memberi
Tips
Seputar

Masyara
kat

Studi Kasus No.7

Sistem Informasi Akademik SMA (SIAK SMA)
SIAK SMA digunakan untuk membantu proses akademis di SMA.
Sistem Informasi akademis ini mempunyai fitur-fitur utama seperti
menyimpan data siswa, mengelola nilai siswa, dan mengelola
jadwal belajar mengajar sekolah.
Dalam penggunaannya, bagian Tata Usaha mempunyai tugas
untuk memasukkan data siswa ke SIAK. Data siswa tersebut bisa
dilihat oleh staf tata usaha, siswa, guru, dan kepala sekolah. Siswa
mempunyai akun untuk membuka profil mereka dan bisa
mengubah data profil mereka jika ada kesalahan.
Nantinya para guru bisa memasukkan nilai para siswa ke sistem
sehingga siswa bisa melihat perkembangan nilainya melalui
sistem. Kepala sekolah dan guru dapat melihat nilai dari
semua siswa, sedangkan siswa hanya dapat melihat nilainya
sendiri di sistem.
Terdapat guru yang berperan sebagai wali kelas. Guru
tersebut bisa memberikan pesan khusus melalui sistem ke
siswa bimbingannya. Siswa bisa melihat pesan tersebut dan
bisa membalas pesan melalui sistem. Guru
juga
bisa
merencanakan jadwal terkait kegiatan belajar mengajar
melalui sistem, misalnya menambahkan tanggal ujian atau

Studi Kasus No.3

Sistem Informasi Manajemen Hotel (SI Mano)
Sebuah hotel membangun sebuah sistem informasi yang bisa
membantu proses pengelolaan customer, pengelolaan kamar,
dan proses penyewaan kamar.
Pada proses penyewaan kamar, proses yang terlibat antara lain
proses pemesanan, proses check-in dan proses check-out.
Customer

diharapkan

bisa

melakukan

pemesanan

melalui

sistem. Customer bisa melakukan pencarian terhadap kamar

yang diinginkan yang masih tersedia. Setelah menentukan
pilihan, customer perlu mengisi formulir yang tersedia

yang

berisi tentang data diri customer. Setelah proses pengisian data

diri selesai, customer harus membayar lewat transfer ke bank.
Resepsionis akan mengecek pemesanan yang datang melalui
sistem dan mengecek pembayarannya. Apabila pembayaran
sudah dilakukan maka resepsionis akan mengubah status kamar