Unified Modeling Language (UML)

Unified Modeling Language (UML) adalah salah satu standar bahasa yang banyak
digunakan di dunia industri untuk mendefinisikan requirement, membuat analisis dan desain,
serta menggambarkan arsitektur dalam pemrograman berorientasi objek. UML merupakan
bahasa visual untuk pemodelan dan komunikasi mengenai sebuah sistem dengan
menggunakan diagram dan teks-teks pendukung. UML muncul karena adanya kebutuhan
pemodelan visual untuk menspesifikasikan, menggambarkan, membangun, dan
dokumentasi dari sistem perangkat lunak. UML hanya berfungsi untuk melakukan
pemodelan. Jadi penggunaan UML tidak terbatas pada metodologi tertentu, meskipun pada
kenyataannya UML paling banyak digunakan pada metodologi berorientasi objek (Rosa A.S
dan M. Shalahudin, 2014:133).

Use Case Diagram

Rosa dan M. Shalahudin (2014:155), use case atau diagram use case merupakan
pemodelan untuk kelakuan (behavior) sistem informasi yang akan dibuat. Use case
mendeskripsikan sebuah interaksi antara satu atau lebih aktor dengan sistem informasi yang
akan dibuat. Secara kasar, use case digunakan untuk mengetahui fungsi apa saja yang ada
di dalam sebuah sistem informasi dan siapa saja yang berhak menggunakan fungsi-fungsi
itu.
Berikut adalah simbol-simbol yang ada pada diagram use case :

No simbol Deskripsi
1 Use Case Fungsionalitas yang disediakan
sistem sebagai unit-unit yang saling
bertukar pesan antar unit atau aktor,
biasanya dinyatakan dengan
menggunakan kata kerja diawal frase
nama use case.
2 Aktor Orang, proses, atau sistem lain yang
berinteraksi dengan sistem informasi
yang akan dibuat di luar sistem
informasi yang akan dibuat itu
sendiri, jadi walaupun simbol dari
aktor adalah gambar orang, tapi aktor
belum tentu merupakan orang,
biasanya dinyatakan menggunakan
 kata benda di awal frase nama aktor.

3 Assosiasi Komunikasi antara aktor dan use

case yang berpartisilpasi pada use
case atau use case memiliki interaksi
dengan aktor.

4 Extensi Relasi use case tambahan kesebuah

use case dimana use case yang
ditambahkan dapat berdiri sendiri
walau tanpa use case tambahan itu,
mirip dengan prinsip inheritance
pada pemrograman berorientasi
objek, biasanya use case tambahan
memiliki nama depan yang sama
dengan use case yang ditambahkan,
misal

Arah panah mengarah pada use case

yang ditambahkan, biasanya use case
yang menjadi extend-nya merupakan
jenis yang sama dengan use case
yang menjadi induknya.
5 Generalisasi Hubungan generalisasi dan spesialisasi
(umum-khusus) antara dua buah use case
dimana fungsi yang satu adalah fungsi
yang lebih umum dari lainnya, misalnya :

arah panah mengarah pada use case yang

menjadi generalisasinya (umum)
6 Include Relasi use case tambahan ke sebuah use
case dimana use case yang ditambahkan
memerlukan use case ini untuk
menjalankan fungsinya atau sebagai
syarat dijalankan use case ini
Ada dua sudut pandang yang cukup besar
mengenai include di use case :
- Include berarti use case yang
ditambahkan akan selalu di
panggil saat use case tambahan
dijalankan, missal pada kasus berikut :

- Include berarti use case yang

tambahan akan selalu melakukan
pengecekan apakah use case yang
di tambahkan telah dijalankan
sebelum use case tambahan di
jalankan, misal pada kasus berikut :
 Kedua interpretasi di atas dapat dianut
salah satu atau keduanya tergantung pada
pertimbangan dan interpretasi yang
dibutuhkan.

Activity Diagram

Rosa dan M. Shalahudin (2014:161), diagram aktivitas atau activity diagram

menggambarkan workflow (aliran kerja) atau aktivitas dari sebuah sebuah sistem atau
proses bisnis atau menu yang ada pada perangkat lunak. Yang perlu di perhatikan disini
adalah bahwa diagram aktivitas menggambarkan aktivitas sistem bukan apa yang dilakukan
aktor, jadi aktivitas yang dapat dilakukan oleh sistem.

Berikut adalah simbol-simbol yang ada pada diagram aktivitas :

No Simbol Deskripsi
1 Status Awal Status awal aktivitas sistem, sebuah
diagram aktivitas memiliki sebuah status
awal.

2 Aktivasi Aktivitas yang dilakukan sistem,

aktivitas biasanya diawali dengan kata
kerja.

3 Percabangan Asosiasi percabangan dimana jika ada

pilihan aktivitas lebih dari satu.
4 Status Akhir Status akhir yang dilakukan oleh sistem,
sebuah diagram aktivitas memiliki
sebuah status akhir.

Class Diagram

Rosa dan M. Shalahudin (2014:141), diagram kelas atau class diagram

menggambarkan struktur sistem dari segi pendefinisian kelas-kelas yang akan dibuat untuk
membangun sistem. Kelas memiliki apa yang disebut atribut dan method atau operasi.
Berikut penjelasan atribut dan method :
1. Atribut merupakan variable-variabel yang dimiliki oleh suatu kelas.
2. Operasi atau method adalah fungsi-fungsi yang dimiliki oleh suatu kelas.
Berikut adalah simbol-simbol yang ada pada diagram kelas :

No Simbol Deskripsi
1 Kelas Kelas pada struktur sistem

2 Antarmuka/Interface Sama dengan konsep interface dalam

pemrograman berorientasi objek

3 Asosiasi Relasi antar kelas dengan makna

umum, asosiasi biasanya juga disertai
dengan multiplicity

4 Asosiasi Berarah Relasi antar kelas dengan makna kelas

yang satu digunakan oleh kelas yang
lain, asosiasi biasanya juga disertai
dengan multiplicity

5 Generalisasi Relasi antar kelas dengan makna

generalisasi-spesialisasi (umumkhusus)
6 Kebergantungan/depedensi Relasi antar kelas dengan makna
kebergantungan antar kelas

7 Agrgasi/aggregation Relasi antar kelas dengan makna

semua-bagian (whole-part)

Sequence Diagram
Rosa dan M. Shalahudin (2014:165), diagram sekuen menggambarkan kelakuan
objek pada use case dengan mendeskripsikan waktu hidup objek dengan massage yang
dikirimkan dan diterima antar objek. Oleh karena itu untuk menggambarkan diagram sekuen
maka harus diketahui objek-objek yang terlibat dalam sebuah use case beserta metode-
metode yang dimiliki kelas yang diinstansiasi menjadi objek itu. Membuat diagram sekuen
juga dibutuhkan untuk melihat skenario yang ada pada use case. Banyaknya diagram
sekuen yang harus digambar adalah minimal sebanyak pendefinisian use case yang
memiliki proses sendiri atau yang penting semua use case yang telah didefinisikan interaksi
jalannya pesan sudah dicakup dalam diagram sekuen sehingga semakin banyak use case
yang didefinisikan maka diagram sekuen yang harus dibuat juga semakin banyak.
Berikut adalah simbol-simbol yang ada pada diagram sekuen :

No Simbol Deskripsi
1 Aktor Orang, proses, atau sistem lain yang
berinteraksi dengan sistem informasi
yang akan dibuat diluar sistem
informasi yang akan dibuat itu sendiri,
jadi walaupun simbol dari aktor adalah
gambar orang, tapi aktor belum tentu
Atau
merupakan orang, biasanya dinyatakan
dalam menggunakan kata benda
diawal frase nama aktor.
Tanpa waktu aktif
2 Garis Hidup/ lifeline Menyatakan kehidupan suatu objek
3 Objek Menyatakan objek yang berinteraksi
Pesan

4 Waktu aktif Menyatakan objek dalam keadaan

aktif dan berinteraksi, semuanya yang
terhubungdengan waktu aktif ini
adalah sebuah tahapan yang dilakukan
di dalamnya, misalnya

Maka cekStatusLogin() dan open()

dilakukan didalam metode login(). Aktor
tidak memiliki waktu aktif
5 Pesan tipe create Menyatakan suatu objek membuat objek
yang lain, arah panah mengarah pada
objek yang dibuat
6 Pesan tipe call Menyatakan suatu objek memanggil
operasi/metode yang ada pada objek lain
atau dirinya sendiri,

Arah panah mengarah pada objek yang

memiliki operasi/metode, karena ini
memanggil operasi/metode maka
operasi/metode yang dipanggil harus ada
pada diagram kelas sesuai dengan kelas
objek yang berinteraksi
7 Pesan tipe send
8 Pesan tipe return
Menyatakan bahwa suatu objek
mengirimkan data/masukkan/informasi
ke objek lainnya, arah panah mengarah
pada objek yang dikirim
Menyatakan bahwa suatu objek yang
telah menjalankan suatu operasi atau
metode menghasilkan suatu kembalian ke
objek tertentu, arah panah mengarah pada
objek yang menerima kembalian

9 Pesan tipe destroy Menyatakan suatu objek mengakhiri

hidup objek yang lain, arah panah
mengarah pada objek yang diakhiri,
sebaliknya jika ada create maka ada
destroy

Metode Penelitian prototype

Metode Pengembangan Sistem yang digunakan dalam perancangan Sistem

Informasi ini menggunakan Model Prototype. Dimulai dengan mengumpulkan kebutuhan
user, kemudian membuat prototype sistem yang akan dibangun. Prototype tersebut
dievaluasi oleh pelanggan/pemakai dan dipakai untuk mendefinisakan kebutuhan
pengembangan perangkat lunak.
 1. Mendengarkan Pelanggan

Pada tahap ini dilakukan pengumpulan kebutuhan dari sistem dengan cara
mendengar keluhan dari pelanggan . Untuk membuat suatu sistem yang sesuai kebutuhan ,
maka harus diketahui terlebih dahulu bagaimana sistem yang sedang berjalan untuk
kemudian mengetahui masalah yang terjadi .

2. Merancang dan Membuat Prototype

Pada tahapan ini , dilakukan perancangan dan pembuatan prototype system .

Prototype yang dibuat disesuaikan dengan kebutuhan sistem yang telah didefinisikan
sebelumnya dari keluhan pelanggan atau pengguna.

3. Uji Coba

Pada tahap ini , Prototype dari sistem di uji coba oleh pelanggan atau pengguna .
Lalu dilakukan evaluasi kekurangan - kekurangan dari kebutuhan pelanggan .
Pengembangan kemudian kembali mendengarkan keluhan dari pelanggan untuk
memperbaiki Prototype yang ada.

Black Box Testing

Black Box Testing (disebut juga fungsional test) adalah pengujian yang mengabaikan
mekanisme internal dari sistem atau komponen dan hanya berfokus pada output yang
dihasilkan sebagai respon terhadap input yang dipilih dan kondisi eksekusi. Ada beberapa
jenis pengujian yang harus dilakukan pada software. Masing-masing jenis tes memiliki
"spesifikasi" yang mendefinisikan perilaku yang benar, tes ini memeriksa bahwa ada
perilaku yang salah (kegagalan) yang diidentifikasi. Ada 7 (tujuh) jenis level pengujian yang
terlibat dalam jenis tes. Ada dua hal yang perlu dipertimbangkan dalam jenis pengujian,
yang pertama adalah opacity yaitu pandang kode penguji (yaitu Black Box atau White Box
Testing). Yang kedua adalah masalah adalah ruang lingkup. Ke-tujuh pengujian dirangkum
dalam Tabel 2.2 (Williams, 2006).