Modul Praktikum RE

Modul Praktikum
Analisis dan Desain Sistem Informasi

Program Studi Sistem Informasi
Dosen Pengampu Kelas [SI-A]
Aryo Pinandito, S.T, M.MT

NIK/NIP. 198305192014041001
Penyusun
[Kelompok 2]
Fikri Hernanda - NIM. 165150400111043 - FIKH

Ilham Maulana Ubaidillah - NIM. 165150401111066 - ILMU
Muhammad Irsad - NIM. 165150407111020 - SAD
Thariq Al Astagis - NIM. 165150400111040 - THR
Asisten
Qomarul Umam - NIM. 155150400111108

Irvan Dwiantono Kartomiharjo - NIM. 155150407111011

Jurusan Sistem Informasi
Fakultas Ilmu Komputer
Universitas Brawijaya
2018
Daftar Isi
Daftar Isi 2
Dasar Teori 3
Rekayasa Kebutuhan 3
Menuliskan Pernyataan Kebutuhan 4
User Story 7
Requirement Engineering 9
Tugas I: User Story 9
Tugas II: Proses Bisnis 9
Tugas III: Identifikasi Aktor 10
Tugas IV: User Requirement 10
Requirement Version: 1.0 11
User Requirement 11
System Requirement 11
User Requirement Version: 2.0 12
User Requirement 12
System Requirement 12
Tugas V: Software Requirement Specification (SRS) 13
Software Requirement Specification Version: 1.0 13
Functional Requirement 13
Non-Functional Requirement 14
Software Requirement Specification Version: 2.0 14
Functional Requirement 14
Non-Functional Requirement 15
Dasar Teori
Rekayasa Kebutuhan
Rekayasa kebutuhan atau Requirement Engineering adalah nama lain dari analisis
kebutuhan dimana setiap proses pengembangan perangkat lunak pasti melalui fase analisis
kebutuhan. Rekayasa kebutuhan itu sendiri adalah sebuah proses untuk membangun
layanan atau produk yang dibutuhkan oleh pelanggan atau pengguna beserta batasan-
batasan yang diberlakukan atau aturan yang harus dipatuhi ketika produk atau layanan
tersebut digunakan dan beroperasi serta ketika produk dan layanan tersebut sedang
dibangun atau dikembangkan. Aktivitas-aktivitas dalam rekayasa kebutuhan dapat
diwujudkan dengan cara-cara yang luas dan beragam namun memiliki tujuan untuk dapat
memahami pemahaman apa yang dibutuhkan oleh pengguna atau pelanggan.
Kebutuhan itu sendiri mengacu pada standar IEEE nomor: IEEE-STD-1220-1998,
menyatakan bahwa kebutuhan adalah sebuah pernyataan yang mengidentifikasi produk
atau proses, baik secara operasional maupun fungsional, atau diperlukan batasan atau
karakteristik dari desain, yang tidak ambigu, dapat diuji, atau terukur, dan agar produk dan
prosesnya dapat diterima oleh konsumen atau sesuai dengan petunjuk penjaminan mutu
secara internal. Selain itu, berdasarkan CMMI v1.3, sebuah kebutuhan adalah sebuah
kondisi atau kemampuan sistem yang diperlukan oleh seorang pengguna untuk
menyelesaikan suatu permasalahan atau untuk mencapau suatu tujuan. Suatu kondisi atau
kemampuan sistem tersebut harus dapat dipenuhi atau dimiliki oleh suatu produk, layanan,
komponen produk atau komponen layanan untuk memenuhi perjanjian dengan supplier,
standar, spesifikasi, atau dokumen yang diakui secara formal. Selain itu, sebuah
representasi kebutuhan dalam bentuk dokumentasi dari suatu kondisi atau kemampuan
sistem tersebut juga diperlukan.
Kebutuhan pengguna secara umum dibagi menjadi dua kategori utama, yaitu Kebutuhan
fungsional dan kebutuhan non-fungsional. Kebutuhan fungsional menggambarkan apa yang
sistem lakukan, sedangkan kebutuhan non-fungsional menggambarkan batasan-batasan
yang harus dipenuhi oleh sistem dalam hal batasan kualitas dan batasan penggunaan
(usability).
Secara umum, kebutuhan memiliki tiga tingkatan, yakni:
1. Kebutuhan normal: yaitu kebutuhan yang harus dipenuhi dan dinyatakan secara
eksplisit oleh pengguna/stakeholder seperti fungsionalitas sistem dan performa
sistem
2. Kebutuhan yang diharapkan (expected): yaitu kebutuhan yang tidak dinyatakan
secara eksplisit namun menentukan kepuasan pelanggan, seperti: kemudahan
interaksi dengan sistem, akurasi dan kebenaran proses
3. Kebutuhan yang mengejutkan (exciting): yaitu kebutuhan yang melebihi kebutuhan
normal untuk dapat lebih memuaskan customer, seperti fungsionalitas tambahan
sistem lainnya yang lebih memuaskan customer ketika menggunakan sistem dalam
menyelesaikan masalah, mencapai tujuan pengguna, dengan lebih efisien.
Hasil atau wujud nyata dari proses rekayasa kebutuhan memiliki beberapa fungsi dalam
proses rekayasa perangkat lunak, yaitu:
1. Sebagai bentuk kesepakatan antara developer, customer dan pengguna akhir akan
kebutuhan yang harus dipenuhi.
2. Menyediakan dasar yang akurat bagi proses perancangan perangkat lunak atau
sistem selanjutnya.
3. Menjadi referensi bagi proses validasi perangkat lunak untuk memastikan bahwa
seluruh kebutuhan yang telah dispesifikasikan benar, lengkap, dan konsisten.
Aktivitias-aktivitas dalam rekayasa kebutuhan terdiri dari 4 proses utama, yaitu:
1. Penggalian dan analisis kebutuhan (software requirement elicitation and analysis).
Dalam proses ini, developer harus bekerja bersama-sama dalam memahami domain
aplikasi/sistem, layanan-layanan sistem yang harus disediakan, unjuk kerja sistem
yang diperlukan, batasan-batasan perangkat keras dan sejenisnya. Proses ini lebih
difokuskan pada APA (WHAT) yang harus ada/dilakukan oleh sistem dan BUKAN
bagaimana (HOW) proses dalam sistem bekerja.
2. Spesifikasi kebutuhan (software requirement specification). Proses untuk
menjelaskan kebutuhan perangkat lunak yang telah didefinisikan sebelumnya secara
lebih detail, tepat, dan terukur, dimana pernyataan spesifikasi kebutuhan yang
didefinisikan dalam proses ini akan menjadi dasar bagi perancangan dan
implementasi. Spesifikasi adalah proses final dalam proses rekayasa kebutuhan
yang akan menghasilkan dokumen SRS (Software Requirement Specification)
3. Validasi & verifikasi kebutuhan (software requirement validation and verification).
Proses pemeriksaan untuk menjamin bahwa pernyataan kebutuhan yang telah
didefinisikan dalam dokumen SRS telah dispesifikasikan dengan benar, akurat, dan
lengkap. Proses ini dilakukan bersama-sama antara customer dan developer dan
sangat penting untuk dilakukan karena kesalahan di dalam menentukan kebutuhan
akan berdampak pada keseluruhan proses yang mengikutinya.
4. Manajemen kebutuhan (software requirement management). Aktifitas untuk
melakukan kendali terhadap kebutuhan yang sedang maupun telah didefinisikan jika
terjadi perubahan ketika sistem sedang dibangun dan dikembangkan serta setelah
sistem digunakan secara operasional.
Menuliskan Pernyataan Kebutuhan

Rekayasa kebutuhan adalah proses teknis penyusunan pernyataan kebutuhan yang harus
memperhatikan dua aspek yang perlu diseimbangkan:
1. Pernyataan kebutuhan yang didefinisikan perlu membuat dokumen kebutuhan
mudah untuk dibaca dan dipahami oleh para stakeholder.
2. Pernyataan kebutuhan yang didefinisikan harus dapat diproses dan diwujudkan.
Pernyataan kebutuhan yang baik adalah pernyataan kebutuhan yang SMART, dimana:
1. Specific. Dalam satu pernyataan menggambarkan hanya satu aspek dari kebutuhan
atau kualitas dari sistem.
2. Measurable. Dimana kualitas dari sistem yang didefinisikan dinyatakan secara
objektif dan kuantitatif.
3. Achieable. Secara teknis dan biaya, kebutuhan yang didefinisikan mampu dicapai
dan terjangkau.
4. Relevant. Kebutuhan yang dinyatakan harus sesuai di tingkat yang dispesifikasikan.
5. Traceable. Jika terdapat kebutuhan turunan (kebutuhan yang diperlukan untuk
memenuhi kebutuhan lainnya) harus dengan jelas mengalir dari pernyataan
kebutuhan induknya sehingga seluruh kebutuhan yang didefinisikan dapat ditelusuri
dengan baik.
Pernyataan kebutuhan yang baik memiliki beberapa karakteristik wajib, yaitu:
1. Secara nyata memang diperlukan oleh pengguna/stakeholder.
2. Dapat diverifikasi kesesuaiannya dengan sistem yang nantinya dibangun
3. Secara teknis, biaya, dan jadwal dapat dicapai
Dalam sebuah pernyataan kebutuhan, setiap pernyataan harus menyatakan siapa yang
bertanggung jawab/terlibat (WHO) dan apa yang harus dilakukan (WHAT). Selain itu dalam
sebuah pernyataan kebutuhan dapat mengekspresikan seberapa baik sesuatu yang
dilakukan oleh sistem harus dipenuhi, atau mengemukakan batasan apa yang harus
dipatuhi ketika sistem melakukan sesuatu. Walaupun demikian, setiap pernyataan
kebutuhan sebaiknya:
1. Hanya mengekspresikan satu pemikiran/tujuan
2. Singkat dan sederhana
3. Dinyatakan secara positif
4. Benar secara gramatikal, bebas dari salah ketik, dan salah eja.
5. Hanya dapat dipahami satu arah dan tidak ambigu
6. Menggunakan istilah-istilah yang konsisten dalam membuat acuan terhadap
sistem/produk
7. Mengikuti aturan dan gaya penulisan yang disepakati.
Pernyataan kebutuhan yang baik adalah pernyataan kebutuhan yang:
1. Bebas dari istilah-istilah yang ambigu.
2. Bebas dari kata-kata yang bersifat indefinitif, seperti: ini, itu, seperti ini, seperti itu,
demikian
3. Bebas dari istilah-istilah yang tidak dapat diverifikasi, seperti fleksibel, user-friendly,
tahan-lama, kokoh, ringan, cukup, kecil, portabel, dengan mudah, dengan cepat,
dengan baik, dan kata-kata sifat lainnya.
4. Bebas dari implementasi. Sebuah pernyataan tidak menyatakan bagaimana cara
menyelesaikan suatu kebutuhan, tapi menyatakan apa yang diperlukan. Nyatakan
masalah yang perlu diselesaikan, bukan solusinya.
5. Perlu dan memang diperlukan oleh pengguna untuk menyelesaikan masalah atau
mencapai tujuan pengguna.
6. Bebas dari deskripsi operasional.
7. Bebas dari hal-hal yang perlu didefinisikan lebih lanjut atau di lain waktu.
Kriteria penulisan sebuah pernyataan kebutuhan tunggal antara lain:
1. Atomic: setiap pernyataan hanya membawa satu elemen yang dapat ditelusuri
2. Unique: setiap pernyataan dapat diidentifikasi secara unik
3. Feasible: secara teknis dapat dicapai dan diwujudkan
4. Legal: secara hukum diperbolehkan
5. Clear: setiap pernyataan kebutuhan dapat dipahami dengan jelas.
6. Precise: setiap pernyataan presisi dan singkat
7. Verifiable: setiap pernyataan dapat diverifikasi, dan cara melakukan verifikasi
diketahui
8. Abstract: tidak menyatakan solusi atau cara menyelesaikan permasalahan.
9. Complete: seluruh kebutuhan telah didefinisikan
10. Consistent: tidak ada dua kebutuhan atau lebih yang bertolak belakang.
11. Non-redundant: kebutuhan hanya didefinisikan satu kali
12. Modular: kebutuhan yang saling berkaitan, diletakkan berdekatan
13. Structured: ada struktur yang jelas dalam mendokumentasikan kebutuhan
14. Satisfied: ada derajat cakupan terhadap penelusuran kebutuhan.
Petunjuk penulisan pernyataan kebutuhan:
1. Hindari basa-basi
2. Hindari penggunaan kata “jika diperlukan”
3. Hindari pendefinisian dua kebutuhan dalam satu kalimat.
4. Hindari spekulasi (coba-coba)
5. Hindari kata-kata yang tidak jelas: biasanya, umumnya, normalnya
6. Hindari istilah yang tidak jelas: user-friendly, bebas, fleksibel, lincah
7. Hindari berangan-angan atau sesuatu yang tidak mungkin dicapai: 100% reliable,
mudah digunakan seluruh pengguna, aman, dapat dijalankan pada semua sistem
operasi, tidak pernah gagal, dapat dijalankan terus menerus 24 jam sehari 7 hari
seminggu.
User Story
Travel JalansKuy merupakan perusahaan yang bergerak dalam bidang pariwisata di
Malang. Travel Jalanskuy menyediakan layanan berupa paket pariwisata dalam dan luar
negeri. Saat ini travel JalanSkuy melayani pelanggan secara konvensional yaitu pelanggan
harus datang ke agen perjalanan langsung. Sehingga jika pelanggan hendak mengetahui
paket berwisata dengan jasa travel JalanSkuy, pelanggan memilih paket wisata melalui
brosur dan buku katalog yang disediakan oleh pihak travel. Travel JalanSkuy menyediakan
beberapa layanan perjalanan wisata, di antaranya, pembelian tiket pesawat, tiket kereta api,
tiket bus, rental mobil, pemesanan kamar hotel, paket perjalanan wisata, dan penukaran
mata uang (money changer).
Semakin meningkatnya persaingan, travel JalansKuy berusaha meningkatkan pelayanan
untuk meningkatkan jumlah pelanggan. Oleh karena itu, pihak travel JalanSkuy perlu
menyediakan layanan online berbasis web dan mobile yang dapat memudahkan pelanggan
dalam mendapatkan informasi dan melakukan transaksi pemesanan. Pelanggan dapat
mengetahui jadwal dan harga tiket kereta, tiket pesawat, tiket bus, mengetahui informasi
terkait kamar ketersediaan dan harga kamar hotel yang dapat dipesan, serta paket
perjalanan wisata baik yang menggunakan tour guide maupun tidak. Pelanggan yang ingin
memesan tiket kereta, pesawat, bus, memesan kamar hotel, dan paket perjalan harus
memiliki akun yang diverifikasi menggunakan alamat email.
Metode pembayaran yang ditawarkan pun sangat fleksibel, pembayaran dapat dilakukan
secara tunai, transfer bank, kartu debit online, kartu kredit, e-payment minimarket, dan
SkuyCash yang merupakan layanan dompet virtual milik JalanSkuy. Pelanggan dapat
memperoleh 20 SkuyPoint setelah melakukan 5 kali transaksi. Ketika pengguna
mendaftarkan diri pada sistem JalanSkuy secara otomatis pengguna mendapatkan 20
SkuyPoint. Setiap transaksi kelipatan Rp10.000, pengguna akan mendapatkan 10
SkuyPoint. Jika pengguna bertransaksi secara online dengan menggunakan SkuyCash,
maka seluruh biaya transaksi yang dilakukan akan mendapatkan potongan tambahan
sebesar 20%. Pengguna dapat melakukan top-up SkuyCash dengan minimal setoran
sebesar Rp50.000. Untuk menarik pelanggan, diadakan diskon sebesar 15% di hari-hari
tertentu untuk pembelian tiket pesawat jika pelanggan bertransaksi minimal 1 juta.
Sementara untuk pembelian tiket kereta, pelanggan dapatkan diskon 10% jika pelanggan
melakukan 5 kali pembelian tiket kereta. Khusus pelajar, pembelian tiket bus akan
mendapatkan cashback 10% ke SkuyCash.
Pesanan tiket yang dibeli oleh pengguna dapat memiliki status dan kondisi berikut ini:
● Booked: tiket telah dipesan dan tagihan pembayaran pesanan tiket telah diterbitkan
● Confirmed: tagihan pesanan tiket telah dibayar
● Pending: tagihan telah dibayar, namun nominal yang dibayarkan tidak mencukupi
● Completed: tiket telah dibayar, dan perjalanan telah dilakukan.
CEO JalanSkuy juga menginginkan adanya laporan keuangan bulanan. Pihak manager dari
perusahaan kereta, pesawat, bus, maupun hotel juga dapat mengetahui laporan penjualan
tiket terkait dengan layanan transportasi yang mereka sediakan melalui sistem JalanSkuy.
Sementara administrator dapat menjawab pertanyaan dari pelanggan dan membuat
penjadwalan travel antarkota yang menggunakan mini bus. Selain itu, administrator dapat
melayani pelanggan secara langsung di agen travel JalanSkuy. CEO JalanSkuy
menginginkan keamanan dan privasi data yang baik. Website maupun aplikasi mobile yang
digunakan oleh pengguna dapat berjalan baik dan cepat walaupun digunakan oleh
pengguna yang banyak dalam satu waktu. Untuk mengurangi kerugian, CEO JalanSkuy
tidak menginginkan adanya permasalahan dalam proses pemesanan tiket pesawat, kereta,
minibus, dan kamar hotel, sehingga sistem perlu menyediakan mekanisme untuk
menghindari pelanggan mendapatkan nomor duduk yang sama atau nomor kamar yang
sama dengan pelanggan lainnya.
Requirement Engineering
Tugas I: Skenario User Story

Identifikasi kebutuhan sistem yang telah diuraikan dalam dalam User Story dan lakukan
rekayasa proses bisnis beserta aktivitas-aktivitas yang dilakukan untuk memenuhi
kebutuhan pengguna tersebut. Setiap anggota kelompok diwajibkan untuk mengidentifikasi
satu kebutuhan fungsional utama (yang memiliki value bagi pengguna) dan mendeskripsikan
skenario aktivitas dalam proses bisnis yang bertujuan untuk memenuhi kebutuhan pengguna
tersebut. Orkestrasi dan koreografi proses bisnis harus terlihat dalam deskripsi yang
diuraikan. Setiap anggota kelompok diminta untuk mengidentifikasi kebutuhan fungsional
utama yang berbeda. Mahasiswa diperbolehkan untuk mengembangkan (membuat user
story) kebutuhan fungsionalnya sendiri dan membuat scenario proses bisnisnya jika User
Story yang telah diuraikan dirasa tidak mencukupi.
[ Inisial penulis ]
[ Uraian skenario fungsional kebutuhan dalam User Story ]
[SAD]
[Sistem informasi ini memfasilitasi pelanggan untuk dapat memesan tiket pesawat, kereta
api, bus, merental mobil, memesan kamar hotel, paket perjalanan wisata, dan penukaran
mata uang.
Proses diawali dengan pelanggan membuat akun SkuyCash lewat web/aplikasi SkuyCash
yang nantinya akan diverifikasi oleh pelanggan lewat akun email.
Misal pelanggan ingin memesan tiket pesawat, pelanggan dapat mengawali pemesanan
dengan memilih menu “Penerbangan”, lalu memilih destinasi keberangkatan/ketibaan yang
diinginkan, dan jadwal keberangkatan serta jumlah penumpang. Setelah memilih tombol
“Cari”, akan ditampilkan informasi atas filter yang dipilih pada menu sebelumnya. pelanggan
memilih penerbangan A dan dilanjutkan dengan pengisian data diri dan memilih metode
pembayaran.
Misal pelanggan ingin merental mobil, pelanggan dapat memilih menu “Rental mobil” dan
memasukkan wilayah penyewaan yang diinginkan, tanggal penjemputan, durasi
peminjaman, serta jumlah mobil yang ingin disewa. Lalu akan ditampilkan hasil sesuai filter
yang telah dipilih, maka akan ada informasi tentang jenis mobil dan harga yang tersedia
untuk disewa. Setelah pelanggan memilih mobil A, maka akan dilanjutkan dengan
pembayaran.
Misal pelanggan ingin memesan kamar hotel, pelanggan dapat memilih menu “Hotel” dan
memasukkan regional penginapan yang diinginkan, tanggal check-in, durasi penginapan,
jumlah penginap dan jumlah kamar. Setelah itu akan tampil informasi sesuai filter yang telah
dimasukan oleh pelanggan, seperti nama hotel, harga perkamar, ratingnya. Pelanggan juga
dapat menyortir pilihannya berdasarkan harga, rating, ataupun jarak. Setelah pelanggan
memilih kamar di hotel A, pelanggan harus memasukkan data penginap dan dilanjutkan
dengan pembayaran.
Misal pelanggan ingin memesan paket perjalanan wisata, pelanggan dapat memilih menu
“Paket Perjalanan” dan memasukkan tujuan wisata, lokasi keberangkatan, jumlah
wisatawan, dan fasilitas apa saja yang diinginkan. Setelah itu pemesanan dilanjutkan
dengan mengisi tanggal keberangkatan dan tanggal pulang, dan dilanjutkan dengan
pembayaran.]
[FIKH]
[Setelah memesan tiket kereta, pesawat, bus, memesan kamar hotel, paket perjalanan, dan
sewa mobil. pelanggan dapat melacak status pemesanan.Contoh skenario : pelanggan yang
telah melakukan pemesanan tiket/ kamar hotel/ paket perjalanan akan mendapat status
pemesananya hingga tahap apa.sistem akan memunculkan status pemesanan booked jika
telah memfinalisasi pemesanan dan tagihan pesnanan telah diterbitkan. status confirmed
akan muncul jika tagihan pemesanan telah dibayar. Status pending akan muncul jika tagihan
telah dibayar namun pembayaran kurang dari tagihan. Status completed muncul jika
pemesanan telah dibayar dan perjalanan telah dilakukan atau rental mobil telah selesai.]
[ ILMU ]
- Metode Pembayaran
Pelanggan melakukan pembayaran pemesanan dengan salah satu cara dari 6
pilihan yang disediakan. Cara pertama pelanggan melakukan pembayaran secara tunai
melalui agen travel JalanSkuy. Cara kedua pelanggan melakukan pembayaran melalui
transfer bank. Cara ketiga pelanggan melakukan pembayaran melalui kartu debit online.
Cara keempat pelanggan melakukan pembayaran menggunakan kartu kredit. Cara kelima
pelanggan melakukan pembayaran melalui E-payment minimarket. Cara keenam pelanggan
melakukan pembayaran melalui layanan dompet virtual milik JalanSkuy yang bernama
SkuyCash.
Pelanggan yang menggunakan SkuyCash mendapatkan 7 keuntungan. Keuntungan
pertama pelanggan memperoleh 20 SkuyPoint setelah melakukan 5 kali transaksi.
Keuntungan pertama pelanggan memperoleh 20 SkuyPoint setelah melakukan 5 kali
transaksi. Keuntungan kedua pelanggan memperoleh 20 SkuyPoint setelah registrasi di
system JalanSkuy. Keuntungan ketiga pelanggan memperoleh 10 SkuyPoint setelah
melakukan transaksi kelipatan Rp.10.000,-. Keuntungan keempat pelanggan memperoleh
potongan tambahan sebesar 20% setelah melakukan transaksi secara online. Keuntungan
kelima pelanggan memperoleh diskon 15% di hari-hari tertentu untuk pembelian tiket
pesawat setelah pelanggan melakukan transaksi sebesar Rp. 1.000.000,-. Keuntungan
keenam memperoleh diskon 10% untuk pembelian tiket kereta api setelah melakukan 5 kali
transaksi pembelian tiket kereta api. Keuntungan ketujuh pelanggan khususnya pelajar
memperoleh cashback 10% dari akun SkuyCash untuk pembelian tiket bus. TopUp saldo
SkuyCash minimal Rp.50.000,-.
[ THR ]
Manager dari perusahaan mitra dapat mengetahui laporan penjualan tiket terkait. Manager
perusahaan mitra memiliki sebuah akun yang dapat masuk ke dalam aplikasi dan melihat
sebuah tampilan laporan penjualan. Manager perusahaan mitra hanya memiliki akses
terhadap penjualan tiket terkait dengan perusahaannya.
Administrator dapat menjawab pertanyaan pelanggan. Saat pelanggan memasukkan
pertanyaan melalui formulir, maka pertanyaan tersebut akan masuk ke akun administrator
untuk dijawab.
Administrator dapat menjadwalkan travel. Saat pelanggan selesai melakukan transaksi
maka sebuah permintaan penjawalan akan masuk ke akun administrator. Administrator akan
membuat penjadwalan travel antarkota yang menggunakan mini bus. Administrator dapat
memasukkan data pelanggan secara manual ketika pelanggan datang langsung ke
JalanSkuy dan langsung membuatkan jadwal travel sesuai dengan permintaan pelanggan.
[ILMU]
Bagian Keuangan mendapatkan data penjualan melalui database sistem. Setelah
mendapatkan data penjualan melalui database sistem, bagian keuangan membuat laporan
keuangan bulanan lalu laporan keuangan bulanan disetorkan kepada CEO.
[SAD]
Manajer perusahaan mitra memiliki hak akses untuk mendapatkan data penjualan tiket
perusahannya.
Tugas II: Proses Bisnis
1. Modelkan proses bisnis yang telah diuraikan dalam User Story. Rekayasa story/alur
proses bisnis diperbolehkan namun hasil rekayasanya tidak boleh bertentangan dengan
user story yang sudah ditentukan.
Modelkan/gambarkan proses bisnis yang telah diuraikan dalam Tugas I dengan
menggunakan BPMN yang menggambarkan orkestrasi dan koreografi proses bisnis seluruh
aktor yang telah diuraikan dalam Tugas I.
2. Lakukan analisis singkat dan sederhana di dalam aktivitas mana sebuah sistem informasi
dapat dilibatkan dalam proses bisnis tersebut. Identifikasi Input-Proses-Output dalam
aktivitas-aktivitas yang melibatkan sistem informasi dan jabarkan pada tabel berikut:
[SAD]
1 Aktivitas Login
Aktor Pelanggan
Input Username dan Password
Proses Pencocokan Username dan Password
Output Menampilkan menu utama TravelSkuy
2 Aktivitas Memilih layanan pemesanan
Aktor Pelanggan
Input Pilihan pemesanan
Proses Memilih jenis pemesanan
Output Hasil pemesanan disimpan oleh sistem
3 Aktivitas Mengisi detail pemesanan
Aktor Pelanggan
Input Jadwal keberangkatan, Kota asal, Kota tujuan, Data pemesan, Data
pelanggan
Proses Pelanggan memasukkan filter untuk jadwal pemesanan, Mengecek

ketersediaan tiket/kamar/jasa, Melakukan pemesanan(booking)
Output Menampilkan hasil filter yang dilakukan oleh pelanggan, Menampilkan

tiket/kamar/jasa yang tersedia, Mendapatkan kode
pemesanan(booking)
4 Aktivitas Mengecek ketersediaan sesuai detail dan layanan
Aktor Sistem
Input Informasi dari pelanggan
Proses Pengecekan ketersediaan oleh sistem
Output Notifikasi tersedia atau tidaknya detail yang diinginkan oleh pelanggan
5 Aktivitas Mengirim daftar ketersediaan layanan dan harga
Aktor Sistem
Input Informasi ketersediaan dari sistem
Proses Sistem mengirim informasi ketersediaan layanan dan harga
Output Menampilkan notifikasi berisi informasi ketersediaan layanan dan harga
6 Aktivitas Memilih layanan dan harga sesuai keinginan
Aktor Pelanggan
Input Jadwal keberangkatan dan harga
Proses Memilih layanan dan harga yang diinginkan
Output Menampilkan proses pemesanan
7 Aktivitas Melakukan pemesanan
Aktor Pelanggan
Input Informasi konfirmasi pemesanan
Proses Melakukan konfirmasi pada pemesanan
Output Menampilkan pilihan pembayaran

[FIKH]
1 Aktivitas Pemesanan Tiket

Aktor Pelanggan
Input Jadwal layanan , dan Status pembayaran
Proses Validasi pembayaran yang dilakukan oleh sistem, Pelanggan

melakukan pemesanan mendapatkan status booked, lalu user
melakukan pembayaran jika pembayaran kurang dari tagihan maka
akan mendapatkan status pending , jika pembayaran lunas akan
mendapatkan status confirmed, dan jika pelanggan telah melakukan
perjalanan akan mendapatkan status completed
Output Status Pemesanan
2 Aktivitas Pembaharuan status pemesanan kepada pelanggan
Aktor Administrator
Input Nominal pembayaran , Tanggal pelayanan.
Proses Administrator mevalidasi pemesanan dan pembayaran yang dilakukan

pelanggan dan memperbaharui status pemesanan kepada pelanggan.
Output Status Pemesanan
[ILMU]
1 Aktivitas Metode Pembayaran

Aktor Pelanggan
Input Pelanggan memilih metode pembayaran
Proses Pelanggan memilih metode pembayaran yang telah disediakan olah

JalanSkuy
Output Pelanggan melakukan metode pembayaran yang telah dipilih
[THR]
1 Aktivitas Membayar tiket
Aktor Pelanggan
Input Tagihan tiket
Proses Membayar melalui prosedur tertentu
Output Bukti pembayaran

2 Aktivitas Konfirmasi Pembayaran
Aktor Administrator
Input Bukti pembayaran
Proses Mengkonfirmasi pembayar dan mencatat ke dalam laporan keuangan,

lalu mengirimkan permintaan tiket kepada perusahaan mitra
Output Permintaan tiket dan laporan keuangan
3 Aktivitas Memberikan rincian tiket
Aktor Manager Mitra
Input Permintaan tiket
Proses Mendaftarkan permintaan ke dalam perjalanan dan mencatat ke dalam

rincian tiket
Output Rincian tiket
4 Aktivitas Menjadwalkan travel antar kota
Aktor Administrator
Input Rincian tiket
Proses Mencatat semua tiket permintaan pelanggan, menyusun perjalanan,

dan membuat jadwal travel user
Output Jadwal perjalanan
[ILMU]
1 Aktivitas Pendataan laporan keuangan
Aktor Bagian Keuangan
Input Tarif layanan
Proses Bagian keuangan mengambil data penjualan dari database perusahaan

JalanSkuy
Output Laporan keuangan bulanan
2 Aktivitas Mengsinkronisasi data penjualan
Aktor Manajer perusahaan mitra
Input Data penjualan dari database JalanSkuy
Proses Mengambil dan mengolah data penjualan dari database JalanSkuy
Output Laporan penjualan bagi perusahaan mitra
Tugas III: Identifikasi Aktor

Identifikasi siapa saja aktor yang telah dideskripsikan dalam User Story.
No. Kode Aktor Nama Aktor Deskripsi Aktor (Persona)
1 ADM01 Administrator Administrator mempunyai hak untuk melakukan

kegiatan administrasi meliputi: menjawab
pertanyaan pelanggan, menjadwalkan travel
antar kota dan menjadwalkan travel secara
langsung (memasukkan biodata, pilihan, tujuan)
2 CST01 Pelanggan Pelanggan menginginkan user interface mudah,

user experience bagus, keamanan yang terjamin
dan harga murah
3 MNG01 Manager Manager mengawasi seluruh jalannya transaksi

dan kinerja karyawan
4 MNG02 Manager Mitra Manager mitra mengawasi jalannya transaksi

yang terkait dengan perusahaannya
5 KEU01 Bagian Keuangan Bagian keuangan membuat laporan keuangan

bulanan dan disetorkan kepada CEO
1. Adakah aktor yang berperan sebagai “Sistem” dalam gambaran sistem yang
diuraikan dalam User Story? Mengapa? Jelaskan dengan detail dan spesifik!
Ada, yaitu administator. Karena administrator memiliki hak untuk melakukan semua kegiatan
administrasi meliputi : menjawab pertanyaan pelanggan, menjadwalkan travel antar kota,
menjadwalkan travel secara langsung (memasukkan biodata, pilihan, tujuan), dan
melakukan maintenance secara berkala.
2. Adakah/perlukah fungsionalitas sistem: Log in dalam gambaran sistem yang
diuraikan dalam User Story? Mengapa? Jelaskan dengan detail dan spesifik!
Ada, Sistem Log In dalam gambaran sistem yang kami jelaskan pada user story memiliki
fungsi sebagai tanda pengenal pelanggan dalam melakukan transaksi.
3. Siapa saja aktor yang harus log in ke dalam sistem? Mengapa? Jelaskan dengan
detail dan spesifik!
Pelanggan, karena sistem butuh untuk mengidentifikasibiodata pelanggan untuk dicatat
pada transaksi pemesanan.
Manager Mitra, Manager mitra hanya memiliki hak akses atas data yang menyangkut
perusahaannya.
Tugas IV: User Requirement

Identifikasi seluruh kebutuhan pengguna sebagaimana yang telah dideskripsikan dalam
User Story. Uraikan kebutuhan pengguna (user requirements) dengan kalimat yang jelas,
tepat, dan tidak ambigu. Kebutuhan pengguna yang baik adalah kebutuhan yang dinyatakan
dalam sebuah kalimat yang memiliki tujuan pengguna yang jelas dan memiliki nilai (value)
atau manfaat bagi penggunanya.
Untuk setiap anggota kelompok, setidaknya dapat mengidentifikasi sekurang-kurangnya 3
kebutuhan dari pengguna termasuk berdasarkan user story yang telah diuraikan dalam
uraian User Story maupun user story yang diuraikan sendiri oleh anggota kelompok dalam
Tugas I.
Tuliskan kebutuhan pengguna (user requirement) dalam format:
<Stakeholder/Pengguna> menggunakan sistem untuk <tujuan/fungsional sistem>
[opsional: agar <manfaat>].
Requirement Version: 1.0
User Requirement
No. [ADM01] Administrator

Ins.
Kode UR Requirement
1 URADM01 Administrator dapat menggunakan sistem untuk menjadwalkan TH

perjalanan pelanggan R
2 URADM02 Administrator dapat menggunakan sistem untuk menjawab TH

pertanyaan pelanggan R
3 URADM03 Administrator dapat mengupdate status pemesanan pelanggan FIK

sesuai tahap dan kondisi yang telah dilakukan pelanggan. H
4 URADM04 Administrator dapat menunda pengiriman E-tiket karena pelanggan FIK

melakukan pembayaran kurang dari tagihan. H
[CST01] Pelanggan
Ins.
Kode UR Requirement
1 URPL01 Pelanggan dapat mengetahui status pemesanan tiket perjalanan. FIK

H
2 URPL02 Pelanggan dapat mengetahui bahwa nominal yang ia bayarkan FIK

kurang dari nominal tagihan H
3 URPL03 Pelanggan dapat melakukan Sign up ke sistem SA

D
4 URPL04 Pelanggan dapat melakukan Login ke sistem SA

D
5 URPL05 Pelanggan dapat memiih layanan pemesanan yang diinginkan SA

D
6 URPL06 Pelanggan dapat mengisi data pemesan SA

D
7 URPL07 Pelanggan dapat mengisi detail pemesanan SA

D
8 URPL08 Pelanggan dapat memilih layanan pemesanan sesuai keinginan SA

berdasarkan hasil filter dari sistem D
9 URPL09 Pelanggan dapat melakukan konfirmasi pemesanan SA

D
10 URPL10 Pelanggan dapat menerima tagihan pembayaran SA

D
11 URPL11 Pelanggan dapat memilih metode pembayaran ILM

U
12 URPL12 Pelanggan dapat menerima bukti pembayaran ILM
U
[MNG01] Manager
Ins.
Kode UR Requirement
1 URMNGA Manager dapat menggunakan sistem untuk mengawasi jalannya

bisnis JalanSkuy
2 URMNGB Manager dapat menggunakan sistem untuk memantau laporan

keuangan dari bisnis JalanSkuy
[MNG02] Manager Mitra

Ins.
Kode UR Requirement
1 URMGM01 Manager mitra dapat menggunakan sistem untuk melihat laporan TH

keuangan perusahaannya R
2 URMGM02 Manager mitra dapat menggunakan sistem untuk memasukkan TH

rincian tiket R
[KEU01] Bagian Keuangan ILM

U
Kode UR Requirement
1 URKEU01 Bagian Keuangan menggunakan sistem untuk mengakses ILM

database data pelanggan U
2 URKEU02 Bagian keuangan menggunakan sistem untuk membuat laporan ILM

keuangan U
3 URKEU03 Bagian Keuangan menggunakan sistem untuk menyerahkan ILM

laporan keuangan ke CEO U
System Requirement
Ubah sudut pandang kebutuhan pengguna ke dalam sudut pandang sistem yang diturunkan
dari kebutuhan pengguna. Satu kebutuhan pengguna dapat diturunkan ke dalam beberapa
kebutuhan sistem. Tuliskan kebutuhan sistem (system requirement) dalam format:
Sistem bisa <melakukan fungsionalitas> [opsional: <constraint>].
No. Kode SR Requirement Ins.
1 SISR01 Sistem bisa menjadwalkan perjalanan pelanggan TH

R
2 SISR02 Sistem bisa menerima input jawaban untuk pertanyaan pengguna TH

R
3 SISR03 Sistem bisa menampilkan laporan keuangan masing-masing TH

perusahaan mitra secara terpisah R
4 SISR04 Sistem bisa menerima masukkan rincian tiket oleh manager mitra TH
R
5 SISR05 Sistem bisa menampilkan status pemesanan yang dilakukan FIK

pengguna H
6 SISR06 Sistem bisa mendeteksi pelanggan yang melakukan kurang bayar FIK
H
7 SISR07 Sistem bisa menampilkan laporan keuangan JalanSkuy kepada ILM

Manager U
8 SISR08 Sistem bisa menampilkan kegiatan jual-beli kepada manager ILM

U
9 SISR09 Sistem bisa menampilkan data pelanggan kepada manager ILM

U
10 SISR10 Sistem bisa menampilkan prosentase pilihan pembayaran kepada ILM

bagian keuangan U
11 SISR11 Sistem bisa menampilkan laporan keuangan kepada bagian ILM

keuangan U
12 SISR12 Sistem bisa menginput laporan keuangan kepada manager ILM

U
13 SISR13 Sistem bisa menerima Sign Up yang dilakukan pelanggan SA

D
14 SISR14 Sistem bisa menerima Login yang dilakukan pelaggan SA

D
15 SISR15 Sistem bisa menampilkan pilihan layanan pemesanan SA

D
16 SISR16 Sistem bisa menyimpan data pelanggan yang memesan SA

D
17 SISR17 Sistem bisa menyimpan detail pemesanan yang diperoleh dari SA

pelanggan D
18 SISR18 Sistem bisa mengecek ketersediaan sesuai detail dan layanan SA

D
19 SISR19 Sistem bisa mengirim pesan detail yang dicari oleh pengguna tidak SA
tersedia D
20 SISR20 Sistem bisa mengirim pesan detaill yang dicari oleh pengguna SA
tersedia D
21 SISR21 Sistem bisa memberikan total tagihan pembayaran ke pelanggan SA

D
22 SISR22 Sistem bisa memberikan pilihan metode pembayaran kepada ILM
pelanggan U
User Requirement Version: 2.0

Setelah kebutuhan sistem yang diidentifikasi, ditransformasi ke dalam tahap analisis dan
desain, maka uraikan penyesuaian terhadap kebutuhan sistem, akibat dari proses
transformasi tersebut dalam tabel berikut ini sedemikian rupa sehingga kebutuhan apa yang
dispesifikasikan, dianalisis, dan dirancang dapat ditelusuri dan dievaluasi kebenarannya.
Uraikan kembali seluruh kebutuhan pengguna, termasuk kebutuhan mengalami perubahan
dalam proses analisis dan perancangan.
User Requirement
No. [ADM01] Administrator TH

R
Kode UR Requirement
1 TH
R
2 TH
R
3 TH
R
4 TH
R
[CST01] Pelanggan
Kode UR Requirement
[MNG01] Manager
Kode UR Requirement
4
[MNG02] Manager Mitra TH
R
Kode UR Requirement
1 TH
R
2 TH
R
3 TH
R
4 TH
R
[KEU01] Bagian Keuangan ILM

U
Kode UR Requirement
1 ILM
U
2 ILM
U
3 ILM
U
4 ILM
U
System Requirement
Ubah sudut pandang kebutuhan pengguna ke dalam sudut pandang sistem yang diturunkan
dari kebutuhan pengguna. Satu kebutuhan pengguna dapat diturunkan ke dalam beberapa
kebutuhan sistem. Tuliskan kebutuhan sistem (system requirement) dalam format:
Sistem bisa <melakukan fungsionalitas> [opsional: <constraint>].
No. Kode SR Requirement Ins.
4
Tugas V: Software Requirement Specification (SRS)
Sesuai dengan kasus penggunaan yang telah diuraikan dalam User Story. Detailkan
kebutuhan pengguna menjadi pernyataan-pernyataan kebutuhan perangkat lunak atau
Software Requirement Specifications (SRS). Detailkan setiap pernyataan kebutuhan
pengguna yang diuraikan telah diuraikan dan buatlah kalimat yang menyatakan spesifikasi
kebutuhan perangkat lunak hingga ke tingkat detail operasional dan terukur sesuai dengan
kriteria pernyataan kebutuhan yang baik.
Ubahlah kebutuhan sistem menjadi kalimat-kalimat yang menyatakan kebutuhan perangkat
lunak yang spesifik, jelas, tidak ambigu, dan terukur (dapat diperlihatkan kesesuaiannya).
Software Requirement Specification Version: 1.0
Functional Requirement
No. [ADM01] Administrator
Ins.
Kode Kode Software Requirement Statement Level
UR SRS
1 URAD SISR Sistem mampu menampilkan laporan keuangan Norm TH

M01 01 al R
2 URAD SISR Sistem dapat menghitung data keuangan yang diinput Expe TH
M01 01 oleh travel cted R
3 URAD SISR Sistem dapat menerima input jawaban dari pelanggan Expe TH
M02 02 cted R
4 URAD SISR Sistem dapat merubah status pemesanan pelanggan. Norm FIK
03 05 al H
5 URAD SISR Sistem dapat menunda pengiriman e-tiket saat Expe FIK
04 06 pelanggan melaku cted H
kan kurang bayar
[CST01] Pelanggan
Ins.
UR SRS
1 URPL SISR Sistem dapat menampilkan status pemesanan tiket Norm FIK
01 05 pelanggan setelah pelanggan melakukan pemesanan. al H
2 URPL SISR Sistem dapat menampilkan status pemesanan menjadi Norm FIK
02 05 pending setelah pelanggan melakukan pelunasan tapi al H
kurang bayar.
3 URPL SISR Sistem dapat menampilkan status pemesanan menjadi Norm FIK
0 05 confirmed setelah pelanggan melakukan pelunasan al H
pembayaran.
4 URPL SISR Sistem dapat menerima Sign up yang dilakukan Expe SA

03 13 pelanggan setelah pelanggan menyelesaikan Sign up cted D
5 URPL SISR Sistem dapat menerima Login yang dilakukan oleh Expe SA
04 14 pengguna setelah pengguna selesai melakukan Login cted D
6 URPL SISR Sistem dapat menyimpan data pelanggan yang Expe SA

06 16 memesan setelah pelanggan mengisi data pemesan cted D
7 URPL SISR Sistem dapat menyimpan detail pemesanan setelah Exitin SA

07 17 pelanggan mengisi detail pemesanan yang diinginkan g D
8 URPL SISR Sistem dapat mengecek keersedian suatu detail dan Norm SA
08 18 layanan setelah pelanggan memilih sesuai keinginannya al D
9 URPL SISR Sistem dapat menampilkan detail yang dicari oleh Expe SA
08 19 pengguna tidak tersedia setelah pelanggan mengisi cted D
detail pemesanan
10 URPL SISR Sistem dapat menampilkan detail yang dicari pengguna Expe SA
08 20 tersedia setelah pelanggan mengisi detail pemesanan cted D
11 URPL SISR Sistem dapat memberikan total tagihan pembayaran ke expec SA

09 21 pelanggan setelah pelanggan mengkonfirmasi ted D
pemesanan
[MNG01] Manager
Ins.
UR SRS
1 URMN SISR Sistem dapat menampilkan data penjualan di JalanSkuy Norm ILM
GA 08 kepada manager al U
2 URMN SISR1 Sistem dapat menampilkan laporan keuangan Norm ILM

GB 1 JalanSkuy kepada manager al U
[MNG02] Manager MItra Ins.

UR SRS
1 URM SISR Sistem dapat menampilkan laporan keuangan sesuai Expe TH

GM01 03 dengan user manager mitra yang login cted R
2 URM SISR Sistem dapat menerima input berupa rincian tiket Norm TH
GM02 04 al R
Non-Functional Requirement
No. Kode Kode Software Requirement Statement Level Ins.
UR SRS
1 URPL SISR1 Sistem menerima input password yang terdiri dari Exciti SA
04 4 minimal 1 alphabet, 1 angka, 1 tanda baca ng D
2 URPL SISR1 Sistem dapat mengecek ketersediaan detail pemesanan Exciti SA
07 8 yang dilakukan oleh pelanggan secara real-time ng D
3 URAD SISR0 Sistem menampilkan laporan keuangan dalam kurun Exciti TH

M01 1 waktu tertentu ng R
4 URAD SISR0 Sistem melakukan kalkulasi tempat duduk untuk Expe TH

M01 1 pelanggan yang terjadwal agar tidak memiliki nomor cted R
sama
5 URPL SISR0 Sistem dapat memverifikasi pembayaran Pelanggan Exciti FIK

02 6 secara real-time saat pelanggan melakukan ng H
pembayaran online.
Software Requirement Specification Version: 2.0

Setelah kebutuhan sistem yang diidentifikasi ditransformasi ke dalam tahap analisis dan
desain, maka uraikan perubahan terhadap kebutuhan sistem dalam tabel berikut sedemikian
rupa sehingga kebutuhan apa yang dispesifikasikan, dianalisis, dan dirancang dapat
dievaluasi kebenarannya. Kebutuhan yang dispesifikasikan di dalam versi ini adalah
kebutuhan yang telah dispesifikasikan dalam versi sebelumnya dan kebutuhan-kebutuhan
lain yang muncul sebagai akibat atau diturunkan dari proses analisis dan perancangan
(contoh: Login). Kebutuhan yang diuraikan dalam versi ini dituliskan setelah proses desain
(modul praktikum 2 dan 3) selesai. Sehingga fungsionalitas dan non-fungsionalitas sistem
yang dirancang dengan yang dispesifikasikan menjadi sesuai dan lengkap.
Ubahlah kebutuhan sistem menjadi kalimat-kalimat yang menyatakan kebutuhan perangkat
lunak yang spesifik, jelas, tidak ambigu, dan terukur (dapat diperlihatkan kesesuaiannya).
Functional Requirement
No. [Kode Aktor] Nama Aktor
Ins.
UR SRS
[Kode Aktor] Nama Aktor
8
Non-Functional Requirement
No. Kode Kode Software Requirement Statement Level Ins.
UR SRS


NIK/NIP. 198305192014041001
Penyusun
[Kelompok 2]

Asisten

2018
DAFTAR ISI
DAFTAR ISI 2
DAFTAR GAMBAR 3
1. Abstrak 4
2. Tujuan Praktikum 4
3. Dasar Teori 4
3.1. Elemen Analisis Pemodelan 4
3.2. Pemodelan Data 5
3.3. Pemodelan Fungsional dan Alur Informasi 6
3.4. Behavior Modeling 8
3.5. Susunan Proses pada Pemodelan Terstruktur 9
3.6. Data Dictionary 10
3.7. Desain Arsitektur 10
4. Summary 16
5. User Story 16
6. Soal-soal Latihan 18
6.1. Tugas I: Pemodelan ERD 18
6.2. Tugas II: Pemodelan DFD 20
6.3. Tugas III: Pemodelan State Transition Diagram 22
6.4. Tugas IV: Pendefinisian Specification 22
6.5. Tugas V: Pemodelan Arsitektur dan Struktur Program 23
DAFTAR GAMBAR
Gambar 1 Elemen Analisis Pemodelan Terstruktur 4
Gambar 2 Penggambaran objek data, atribut dan relationship 5
Gambar 3 Entity Relationship Diagram 6
Gambar 4 Data Flow Diagram 6
Gambar 5 Dekomposisi dalam Data Flow Diagram 7
.Gambar 6 PSPEC pada process dalam DFD 8
Gambar 7 State Transition Diagram 8
Gambar 8 Pemetaan model analisis ke dalam model desain 9
Gambar 9 Contoh data dictionary 10
Gambar 10 Transform Flow pada DFD 11
Gambar 11 Transaction Flow pada DFD 11
Gambar 12 DFD Level 1 SafeHome 12
Gambar 13 Level 2 DFD SafeHome 12
Gambar 14 Level 3 DFD SafeHome 13
Gambar 15 Pendefinisian Struktur pada First Level Factoring 14
Gambar 16 Second Level Factoring 14
Gambar 17 DFD Level 2 User Interaction Sub System 15
Gambar 18 First Level Factoring Transaction Mapping 16
1. Abstrak
Level teknis pengembangan perangkat lunak dimulai pada fase pemodelan atau fase
desain. Fase desain membutuhkan input berupa definisi dan spesifikasi kebutuhan dari
aktivitas analisis kebutuhan. Fase desain menggabungkan kombinasi text dan diagram
untuk mendefinisikan kebutuhan dalam bentuk yang mudah dipahami. Diagram dan
text ini dibagi ke dalam komponen yang merepresentasikan behavior, struktur data
dan fungsi dari perangkat lunak yang akan dibangun. Artefak atau produk yang
dihasilkan dari fase desain adalah Data Object Description, Entity Relationship Diagram,
Data Flow Diagrams, State Transition Diagrams, Process Specification, Control
Specification dan Arsitektur dan Struktur Program.
2. Tujuan Praktikum
Tujuan dari pelaksanaan praktikum mata kuliah ADSI dengan materi desain terstruktur
antara lain:
a. Mahasiswa mampu memahami komponen-komponen penyusunan pada diagram
desain perangkat lunak dengan pendekatan terstruktur.
b. Mahasiswa mampu memahami aturan-aturan penyusunan komponen pada
diagram yang dibutuhkan untuk pengembangan perangkat lunak dengan
pendekatan terstruktur.
c. Mahasiswa mampu mendesain perangkat lunak berdasarkan kebutuhan dengan
pendekatan terstruktur.
3. Dasar Teori
3.1. Elemen Analisis Pemodelan
3 tujuan dari pemodelan antara lain:
a. Mendeskripsikan kebutuhan customer,
b. Sebagai basis dari tahap implementasi pengembangan software, dan
c. Sebagai acuan untuk proses validasi atas kebutuhan terhadap software yang
dibangun.
Elemen pembentuk pemodelan terstruktur didefnisikan pada Gambar 1 berikut:
Gambar 1 Elemen Analisis Pemodelan Terstruktur
Pada model diatas terdapat data dictionary yang merupakan Inti dari
pemodelan dengan pendekatan terstruktur. Data dictionary merupakan sebuah
repository yang mendeskripsikan tiap data yang digunakan pada suatu perangkat
lunak. Terdapat 3 diagram yang mengacu pada objek/data didalam data dictionary
yaitu, Entity Relationship Diagram (ERD), Data Flow Diagram (DFD) dan State
Transition Diagram (STD).
ERD mendefinisikan hubungan antar objek atau data. ERD merupakan notasi
yang digunakan untuk memodelkan aktifitas dan hubungan antar data. Atribut pada
tiap objek data dideskripsikan kedalam data object description.
DFD memiliki 2 fungsi utama yaitu:
a. Memberikan gambaran transformasi data ketika berjalan didalam sistem.
b. Mendefinisikan proses-proses yang mentranformasikan aliran data.
Deskripsi dari tiap proses dalam DFD terdapat pada penjelasan berupa teks yang
disebut dengan Process Specification (PSPEC)
Sedangkan STD menggambarkan perilaku dari sistem ketika di-trigger
(dikontrol) oleh event dari luar sistem. Informasi mengenai kontrol dari suatu
perangkat lunak dijelaskan dalam Control Specification (CSPEC).
3.2. Pemodelan Data

Pemodelan data terdiri dari 3 komponen: objek data, atribut yang
mendeskripsikan objek data dan relationship yaitu hubungan antara tiap objek data.
Objek Data. Objek data merepresentasikan informasi yang harus ada dalam sebuah
perangkat lunak. Atribut. Atribut adalah properti (ciri) dari objek data. Relationship
mendeskripsikan hubungan antar objek data.
Berikut adalah bentuk hubungan antar 2 data objek:
a. Toko Buku membeli Buku.
b. Toko Buku menjual Buku
c. Peminjam mengembalikan Buku
Dari 3 contoh di atas dapat disimpulkan bahwa objek data adalah Toko
Buku, Buku dan Peminjam, sedang relationship adalah membeli, menjual dan
mengembalikan. Sedangkan atribut dari buku merupakan ciri dari buku tersebut
seperti nomor ISBN, judul buku, tanggal terbit, pengarang, penerbit dan sebagainya.
Gambar 2 Penggambaran objek data, atribut dan relationship
Hubungan antar objek merupakan hal yang penting pada pemodelan data.
Contoh dari hubungan antar data yang didefinisikan kedalam ERD terdapat pada
gambar 3 berikut:
Gambar 3 Entity Relationship Diagram
3.3. Pemodelan Fungsional dan Alur Informasi
Informasi berubah ketika berjalan melalui sebuah sistem berbasis komputer.
Sistem menerima input dalam berbagai jenis dan bentuk dan pada perjalanannya
informasi dirubah oleh software, hardware maupun human sehingga menghasilkan
output yang juga bermacam-macam. Pemodelan terstruktur dimulai dari proses
mendefinisikan informasi ke dalam teknik flow modeling. Contoh dari flow modeling
terdapat pada Gambar 4 berikut:
Gambar 4 Data Flow Diagram
Untuk menggambarkan flow model yang merepresentasikan alur data dalam

sistem maka digunakan suatu diagram yang dikenal dengan Data Flow Diagram
(DFD). DFD merupakan representasi grafis (diagram) yang menggambarkan alur
informasi dan menggambarkan transformasi data ketika berjalan dari input ke output
pada perangkat lunak. DFD memiliki 4 notasi utama yaitu: Kotak disebut juga
terminator merepresentasikan external entity yaitu suatu elemen (berupa hardware,
manusia, atau aplikasi) atau sistem lain yang memberikan atau menerima informasi
yang akan dirubah dari dan kedalam perangkat lunak pada sistem internal.
Lingkaran disebut juga process merepresentasikan proses yang dibutuhkan oleh
perangkat lunak untuk mengubah data. Notasi panah atau disebut flow data
merepresentasikan data yang ditransformasikan oleh proses. Garis sejajar disebut
data store merepresentasikan informasi yang disimpan yang akan digunakan oleh
sebuah perangkat lunak.
Terdapat aturan didalam menggambarkan DFD, semua data flow didalam
DFD haruslah diberikan sebuah label yang mendefinisikan data yang bertransformasi
di dalam perangkat lunak. Data Flow tidak boleh menghubungkan antara terminator
dan data store tetapi harus melewati suatu proses, dan proses harus memiliki input
dan output data. Perlu diingat bahwa DFD tidak menggambarkan urutan dari proses,
tidak seperti flowchart. DFD dapat dipartisi kedalam beberapa level dan masing-
masing level dapat menggambarkan proses yang lebih detail dibanding dengan level
sebelumnya. DFD dimulai dari Level 0 atau disebut juga dengan fundamental system
model atau context model. Context model merepresentasikan seluruh elemen dari
perangkat lunak. Pada Level 0 ini DFD cukup digambarkan ke dalam satu notasi
Process yang dihubungkan ke terminator melalui flow data. Penggambaran sistem
yang lebih detail dapat digambarkan ke dalam level berikutnya yaitu Level 1 DFD.
Proses penggambaran dengan hierarki yang menjelaskan proses yang lebih detail ini
disebut dengan dekomposisi. Aturan dekomposisi adalah level pada DFD maksimal
adalah 3 level. Contoh dari proses dekomposisi dapat terlihat pada Gambar 5
berikut:
Gambar 5 Dekomposisi dalam Data Flow Diagram
DFD haruslah dilengkapi dengan teks yang dapat menjelaskan proses

dengan lebih detail. Bentuk teks ini dikenal dengan Process specification (PSPEC).
PSPEC dapat digunakan untuk mendeskripsikan detail dari tiap notasi Process
didalam DFD. PSPEC menjelaskan input, algoritma untuk mentransformasi input
serta output yang dihasilkan dari suatu proses. PSPEC juga dapat digunakan untuk
mendeskripsikan batasan pada suatu proses.
Control Flow Diagram merupakan penggambaran dari control didalam suatu
sistem. Control merupakan suatu kondisi yang dibutuhkan untuk memulai suatu
proses dalam sistem. Control Specification (CSPEC) digunakan untuk
mendeskripsikan control dengan lebih detail.
.Gambar 6 PSPEC pada process dalam DFD
3.4. Behavior Modeling

Behavior modeling pada pemodelan terstruktur diwakili oleh sebuah diagram
yang disebut State Transition Diagram (STD).STD merepresentasikan perubahan
pada state dari suatu sistem yang dipicu oleh event tertentu. STD juga
mengindikasikan aksi/feedback yang dilakukan oleh sistem sebagai akibat dari
perubahan event. State merupakan perilaku sistem yang dapat diobservasi. Berikut
merupakan contoh dari penggambaran dari STD
Gambar 7 State Transition Diagram
STD memiliki notasi berupa: Notasi kotak yang merepresentasikan states dari
sistem. Tanda panah merepresentasikan transisi yang terjadi antar state didalam
sistem. Setiap panah dilengkapi dengan dua buah deskripsi, deskripsi yang berada
di atas mengindikasikan event yang menyebabkan perubahan pada state di dalam
sistem. Sedang untuk deksripsi yang berada dibawah mengindikasikan
aksi/feedback sebagai konsekuensi dari perubahan event.
3.5. Susunan Proses pada Pemodelan Terstruktur

Berikut merupakan bahasan yang menggambarkan langkah-lankah atau alur
proses untuk mengembangkan pemodelan sistem dengan menggunakan
pendekatan terstruktur. Pada gambar di bawah ini menerangkan pemetaan dari
elemen pemodelan menggunakan pendekatan terstruktur dengan hirarki pada
proses desain menggunakan pendekatan terstruktur.
Gambar 8 Pemetaan model analisis ke dalam model desain
Pada desain terstruktur terdapat urutan langkah-langkah pemodelan.

Langkah pertama adalah desain data. Desain data merupakan aktifitas analisis yang
mentransformasikan informasi yang telah didapatkan pada fase requirement
engineering menjadi struktur data yang diperlukan untuk proses pengembangan
perangkat lunak. Diagram yang mewakili desain adalah ER-Diagram dan Data
Dictionary.
Langkah kedua adalah menentukan desain arsitektur dari sistem. Desain
arsitektur mendefinisikan hubungan antara proses utama didalam aplikasi. Pada
desain arsitektur dikembangkan Data Flow Diagram untuk menangkap hubungan
antar proses dalam sistem.
Desain interface merupakan langkah ketiga yang dilaksanakan untuk
mendeskripsikan proses komunikasi didalam perangkat lunak, komunikasi antar
perangkat lunak dengan sistem lain, dan interaksi antara perangkat lunak dengan
manusia. Penggunaan State-Transition Diagram yang mengacu pada Data Flow
Diagram diperlukan untuk dapat merepresentasikan desain interface secara
komprehensif. Pada proses ini juga didefinisikan PSPEC dan CSPEC dari proses
serta kontrol pada perangkat lunak.
Terakhir adalah langkah untuk mengembangkan desain komponen dari
perangkat lunak. Desain komponen mentransformasikan elemen-elemen yang
membentuk struktur perangkat lunak menjadi deskripsi prosedural yang menjelaskan
komponen perangkat lunak. Informasi yang didapatkan dari PSPEC, CSPEC dan
STD digunakan sebagai basis untuk mengembangan desain komponen perangkat
lunak.
3.6. Data Dictionary
Data dictionary mendeskripsikan konten dari suatu objek, Data dictionary
didefinisikan pada proses analisis struktur. Format dari data dictionary berubah-ubah
tergantung dari standar atau best practice yang digunakan. Namun pada umunya
data dictionary memuat informasi sebagai berikut:
a. Nama—merupakan nama dari data, kontrol, data store dan external entity.
b. Alias—Nama lain yang digunakan untuk merepresentasikan suatu data.
c. Where-used/how-used—list dari proses yang menggunakan data atau kontrol,
selain itu juga menjelaskan bagaimana data tersebut akan digunakan (sebagai
input proses, output proses, data store atau external entity)
d. Deskripsi konten—Notasi yang dapat merepresentasikan konten data.
e. Informasi tambahan—informasi mengenai tipe data, default value(jika ada),
batasan.
Gambar 9 berikut mengilustrasikan penulisan data dictionary dengan

menggunakan data berupa nomer telpon yang digunakan sebagai data input pada
suatu proses dalam perangkat lunak.
Gambar 9 Contoh data dictionary
3.7. Desain Arsitektur

Setelah pelaksanaan analisis terstruktur maka pemodelan dengan
pendekatan terstruktur akan memasuki tahapan untuk dapat merepresentasikan flow
dan model data kedalam arsitektur dan struktur program yang menjadi acuan bagi
fase implementasi perangkat lunak.
Arsitektur perangkat lunak didefinisikan sebagai “Seluruh struktur perangkat
lunak yang merepresentasikan integrasi antar komponen-komponen dalam sistem”.
Arsitektur menjelaskan struktur hirarki, interaksi dan struktur data dari komponen
(modul) dalam perangkat lunak. Transisi dari DFD kedalam struktur program
sehingga menjadi arsitektur perangkat lunak dilakukan dengan 5 langkah:
a. Penentuan tipe dari information flow
b. Penentuan batasan dari flow
c. Pemetaan DFD kedalam struktur program
d. Pendefinisian hirarki dari komponen perangkat lunak
e. Memperbaiki struktur hirarki.
Terdapat dua tipe information flow yaitu Transform Flow dan Transaction
Flow, transform flow merepresentasikan perubahan informasi didalam DFD.
Transform flow memiliki 3 elemen. Incoming Flow – mendefinisikan aliran/jalur
informasi eksternal yang masuk kedalam sistem untuk ditransformasi. Transform
Center – mendefinisikan pusat transformasi dalam sistem yang akan
mentransformasi informasi. Outgoing Flow – aliran/jalur informasi yang keluar dari
suatu proses untuk kemudian ditransformasikan di proses selanjutnya. Berikut
adalah penggambaran dari transform flow pada DFD
Gambar 10 Transform Flow pada DFD
Transaction Flow memiliki ciri satu data item yang disebut transaction yang
men-trigger pengeksekusian data flow lain pada jalur yang berbeda. Transaction flow
memiliki 3 elemen yaitu transaction – data tunggal yang mentriger atau atau
beberapa aliran data. Transaction center – proses yang menghubungkan aliran
data dari transaction menjadi aliran data yang menuju jalur yang berbeda. Action
path – aliran/jalur informasi yang akan dipilih sebagai output dari proses trigger dari
data transaction. Perlu diingat bahwa kemungkinan bagi transform flow dan
transaction flow berada pada satu DFD yang sama sangat besar.
Gambar 11 Transaction Flow pada DFD
Untuk mengubah DFD menjadi arsitektur dapat dilakukan dengan dua

pendekatan yang masing-masing memiliki set langkah tertentu sesuai dengan hasil
identifikasi transform flow serta transaction flow dalam DFD. Apabila dalam DFD
terdapat transform flow maka untuk mengubah menjadi format arsitektur perangkat
lunak menggunakan proses transform mapping, sedang apabila didalam DFD
terdapat transaction flow maka untuk mengubah dari DFD menjadi arsitektur
perangkat lunak dapat menggunakan proses transaction mapping.
TRANSFORM MAPPING
Langkah-langkah dalam transform mapping antara lain:
a. Review dan refine DFD sampai ke level paling bawah. Berikut adalah contoh
dari dekomposisi DFD pada sistem SafeHome sampai level ke 3 yaitu level
paling bawah dari DFD.
Gambar 12 DFD Level 1 SafeHome
Gambar 13 Level 2 DFD SafeHome

Gambar 14 Level 3 DFD SafeHome
b. Tentukan apakah DFD tsb. memiliki karakteristik tipe transform flow atau
transaction flow
c. Tentukan batas antara incoming flow, transform center dan outgoing flow
d. Bangun first level factoring. Pada proses ini jika terdapat transform flow maka
DFD akan dipetakan kedalam 3 proses yang merepresentasikan alur
informasi yaitu incoming, transform dan outgoing. Pada gambar 15
didefinisikan struktur sebagai berikut: Sensor input controller mendefinisikan
aktifitas incoming information secara umum. Alarm condition controller
mendefinisikan aktifitas transform information secara umum. Alarm output
controller mendefinisikan secara umum aktifitas outgoing information.
e. Bangun second level factoring. Proses ini dilaksanakan dengan memetakan
proses-proses pada outgoing flow yang sebelumnya pada proses first level
factoring didefinisikan menjadi satu struktur utama outgoing flow yaitu alarm
output controller. Pada DFD SafeHome terlihat bahwa terdapat 6 proses
terkait struktur alarm output controller yang menjadi outgoing information
yaitu Format display → generate display. Generate alarm. Set up connection
to phone net → Genereate pulses to line. Enam proses ini kemudian akan
digambarkan sebagai struktur dengan hirarki dibawah struktur alarm output
controller. Gambar 16 menggambarkan proses second level factoring pada
sistem SafeHome. Proses dilakukan secara menyeluruh pada tiap incoming,
transform dan outgoing information sehingga menghasilkan struktur yang
komprehensif.
f. Refine first iteration
Gambar 15 Pendefinisian Struktur pada First Level Factoring
Gambar 16 Second Level Factoring

TRANSACTION MAPPING
Langkah-langkah dalam transaction mapping antara lain:
a. Review dan refine DFD sampai ke level paling bawah. Gambar 17
menggambarkan level 2 dari DFD User Interaction Sub System pada sistem
SafeHome
Gambar 17 DFD Level 2 User Interaction Sub System
b. Tentukan apakah DFD tsb. memiliki karakteristik tipe transform flow atau
transaction flow. Pada gambar 17 diatas merupakan tipe transaction flow
dengan proses invoke command processing menjadi transaction center yang
mentrigger proses read system data, activate/deactivate system serta read
password. Perlu diingat bahwa data/informasi dapat diteruskan ke salah satu
dari 3 jalur tersebut.
c. Tentukan batas antara incoming path/transaction, transaction center dan
action path
d. Bangun first level factoring. Dari DFD yang telah didefinisikan pada Gambar
17 kemudian dibangun first level factoring. Pada first level factoring ini
struktur user interaction executive menjadi struktur utama sedang proses
pada incoming flow disusun pada hirarki dibawah struktur utama dan
menempati bagian kiri. Sedangkan transaction center yaitu Invoke command
processing membawahi action path yang ditrigger oleh transaction center itu
sendiri, antara lain system configuration controller, activate/deactivate system
dan password processing controller. Gambar 18 merupakan pendefinisian
struktur dalam first level factoring.
e. Bangun second level factoring
f. Refine first iteration
Gambar 18 First Level Factoring Transaction Mapping
4. Summary
Analisis terstruktur merupakan pendekatan yang banyak digunakan untuk
menggambarkan pemodelan dari kebutuhan. Analisis terstruktur disusun dengan
berbasis pada data modeling dan flow modeling yang direpresentasikan dengan diagram
yang disebut entity-relationship diagram, dan data flow diagram, dengan diagram ini
pengembang perangkat lunak dapat melihat data object yang penting serta dapat
mendefiniskan alur serta proses transformasi data didalam perangkat lunak/sistem. Data
dan control flow diagram digunakan sebagai basis untuk mengidentifikasikan data dan
kontrol flow dari sebuah sistem. Behavioral model dirancang dengan menggunakan state
transition diagram dan isi dari data serta kontrol didefinisikan didalam data dictionary.
5. User Story
negeri. Saat ini travel JalanSkuy melayani pelanggan secara konvensional yaitu
pelanggan harus datang ke agen perjalanan langsung. Sehingga jika pelanggan hendak
mengetahui paket berwisata dengan jasa travel JalanSkuy, pelanggan memilih paket
wisata melalui brosur dan buku katalog yang disediakan oleh pihak travel. Travel
JalanSkuy menyediakan beberapa layanan perjalanan wisata, di antaranya, pembelian
tiket pesawat, tiket kereta api, tiket bus, rental mobil, pemesanan kamar hotel, paket
perjalanan wisata, dan penukaran mata uang (money changer).
menyediakan layanan online berbasis web dan mobile yang dapat memudahkan
pelanggan dalam mendapatkan informasi dan melakukan transaksi pemesanan.
Pelanggan dapat mengetahui jadwal dan harga tiket kereta, tiket pesawat, tiket bus,
mengetahui informasi terkait kamar ketersediaan dan harga kamar hotel yang dapat
dipesan, serta paket perjalanan wisata baik yang menggunakan tour guide maupun
tidak. Pelanggan yang ingin memesan tiket kereta, pesawat, bus, memesan kamar hotel,
dan paket perjalan harus memiliki akun yang diverifikasi menggunakan alamat email.
Sementara untuk pembelian tiket kereta, pelanggan dapatkan diskon 10% jika
pelanggan melakukan 5 kali pembelian tiket kereta. Khusus pelajar, pembelian tiket bus
akan mendapatkan cashback 10% ke SkuyCash.
● Booked: tiket telah dipesan dan tagihan pembayaran pesanan tiket telah
diterbitkan
CEO JalanSkuy juga menginginkan adanya laporan keuangan bulanan. Pihak manager
dari perusahaan kereta, pesawat, bus, maupun hotel juga dapat mengetahui laporan
penjualan tiket terkait dengan layanan transportasi yang mereka sediakan melalui sistem
JalanSkuy. Sementara administrator dapat menjawab pertanyaan dari pelanggan dan
membuat penjadwalan travel antarkota yang menggunakan mini bus. Selain itu,
administrator dapat melayani pelanggan secara langsung di agen travel JalanSkuy. CEO
JalanSkuy menginginkan keamanan dan privasi data yang baik. Website maupun
aplikasi mobile yang digunakan oleh pengguna dapat berjalan baik dan cepat walaupun
digunakan oleh pengguna yang banyak dalam satu waktu. Untuk mengurangi kerugian,
CEO JalanSkuy tidak menginginkan adanya permasalahan dalam proses pemesanan
tiket pesawat, kereta, minibus, dan kamar hotel, sehingga sistem perlu menyediakan
mekanisme untuk menghindari pelanggan mendapatkan nomor duduk yang sama atau
nomor kamar yang sama dengan pelanggan lainnya.
6. Soal-soal Latihan
6.1. Tugas I: Pemodelan DFD
Pada Pemodelan DFD gambarkan DFD dari Level 0/ Diagram konteks
sampai ke dalam level yang terendah. Sesuai dengan teori maka DFD level
terendah adalah DFD Level 3. Gunakan user story di atas dan Pemodelan
ERD untuk menentukan data store, proses dan terminatornya terlebih dahulu
baru digambarkan DFD mulai Level 0 sampai Level terendah.
Terminator
Tentukan terminator atau external entity dengan menggunakan format
sebagai berikut:
External Entity Terminator INS

Administrator Administrator THR & FIKH
Pelanggan Pelanggan FIKH & SAD
Manager JalanSkuy Manager ILMU
Manager Mitra Manager Mitra THR
Bagian Keuangan Keuangan ILMU
A. Data Store
Tentukan data store dari user story diatas dan deskripsikan dengan
format sebagai berikut:
Objek Data Data Store INS

ID_Pelanggan, Nama, Pelanggan SAD
Alamat, Poin
ID_Pegawai, Jadwal Perjalanan SAD & THR
ID_Pelanggan,
ID_Tiket,
Waktu_Berangkat,
Durasi
ID_Pegawai, Nama, Bagian Keuangan ILMU
Alamat
ID_Pegawai, Nama, Administrator ILMU & THR
Alamat
ID_Tiket,ID_Pelangga Tiket FIKH
n,Status,
Waktu_Pemberangkat
an, Tujuan
ID_Perusahaan, Manager Mitra THR
Nama_Manager,
Nama_Perusahaan
B. Proses
Tentukan proses yang harus ada didalam DFD dengan memetakannya ke
dalam deskripsi pada kebutuhan
Definisi Kebutuhan Process INS

Sistem dapat Menampilkan pilihan #DFD level 1 (?)
menampilkan metode metode pembayaran
pembayaran
Sistem dapat Menampilkan jadwal SAD
menampilkan jadwal sesuai jenis pesanan
sesuai jenis pesanan yang tersedia pada satu
yang tersedia pada waktu
waktu itu
Sistem dapat Menampilkan laporan ILMU
menampilkan laporan keuangan bulanan
keuangan bulanan
Sistem dapat Menampilkan status FIKH
mengupdate status pesanan pelanggan
pemesanan pelanggan
Sistem dapat Menampilkan laporan ILMU
menampilkan laporan penjualan tiket jalanSkuy
penjualan tiket
Sistem dapat Menampilkan laporan THR
menampilkan laporan penjualan
penjualan perusahaan
mitra terkait
Sistem dapat menerima Mengajukan pertanyaan THR
masukan untuk
menerima pertanyaan
dan memberikan
jawaban
Sistem dapat mengatur Menjadwalkan THR
jadwal sesuai perjalanan
permintaan pelanggan
dan tiket
Sistem dapat Mengotentifikasi THR
mengotentifikasi perusahaan mitra
manager perusahaan
yang login ke sistem
Sistem dapat Mengirim jadwal kepada THR
memperbarui data pelanggan
pelanggan untuk
memasukkan jadwal
perjalanan
C. Penggambaran DFD
[THR]
Level 0
Level 1
Level 2
[FIKH]
Level 0
Level 1
Level 2
[SAD]
Level 0
Level 1
Gambarkan DFD Level 0
[ILMU]
Level 0
Level 1
6.2. Tugas II: Pemodelan ERD

Berdasarkan User Story tentukan objek data yang mewakili entitas didalam
user story, atribut dari tiap objek data dan relationship antar objek data dalam
bentuk deskriptif.Setelah didefinisikan tiap objek data, atribut dan relationship
kedalam bentuk Entity Relationship Diagram.
A. Objek Data dan Atribut
Definisikan Objek Data dan atributnya dengan menggunakan format tabel
seperti di bawah ini
Objek Data Atribut

Mahasiswa Nim
Nama
Jurusan
Pelanggan id_pelanggan
nama
alamat
Administrator id_pegawai
nama
alamat
Jadwal Perjalanan id_pelanggan
id_tiket
waktu_berangkat
durasi
Manager Mitra id_perusahaan
nama_manager
nama_perusahaan
Tiket id_tiket
id_pelanggan
status
waktu_brgkt
tujuan
Manager JalanSkuy id_pegawai
nama_manager
alamat
Bagian Keuangan id_pegawai
nama
alamat
B. Relationship antar Objek Data

Definisikan hubungan antar Objek Data dengan menggunakan format
seperti di bawah ini
Contoh Pengisian:
Pembeli membeli Mobil
[SAD]
Pelanggan menghubungi Administrasi
Pelanggan mendapatkan Tiket
Administrasi memvalidasi Tiket
Administrasi mengupdate Jadwal Perjalanan
[THR]
Pelanggan mendapat Jadwal Perjalanan
Jadwal Perjalanan memuat Tiket
Administrator membuat Jadwal Perjalanan
Manager Mitra merinci Tiket
[ILMU]
Bagian Keuangan membuat Laporan Keuangan
Manager JalanSkuy mendapat Laporan Keuangan
C. Entity Relationship Diagram

Gambarkan Entity Relationship Diagram sesuai dengan ketentuan dan
aturan penggambaran ERD
6.3. Tugas III: Pemodelan State Transition Diagram
Pada pemodelan State Transition Diagram dilakukan pendefinisian event dengan
acuan DFD. Setelah event didefinisikan selanjutnya dilakukan pendefinisian
feedback/activity.
Dari DFD yang telah didefinisikan diatas gambarkan State-Transition Diagram
[THR]
[FIKH]
[SAD]
[ILMU]
6.4. Tugas IV: Pendefinisian Specification
Tentukan Process Specification yang mendefinisikan deskripsi dari tiap proses
didalam DFD dan Control Specification yang mendefinisikan deskripsi kontrol
dalam DFD. Pada bab ini juga didefinisikan data dictionary dari perangkat lunak.
A. Process Specification
Process Specification dideskripsikan dengan menggunakan format sebagai
berikut:
Kode PSPEC
[THR]
Nama Proses Mengajukan Pertanyaan
Input Pertanyaan
Output Jawaban
Tujuan Proses Untuk menjawab pertanyaan dari pelanggan
Batasan Memasukkan pertanyaan
Algoritma
input pertanyaan
sendNotificationTo(administratorX, pertanyaan)
input jawaban
sendNotificationTo(pelangganX, jawaban)
Nama Proses Membuat jadwal sesuai tiket

Input Rincian tiket, biodata
Output Jadwal perjalanan
Tujuan Proses Untuk menjadwalkan perjalanan pelanggan
sesuai rincian tiket yang ada
Batasan Memasukkan rincian tiket, biodata

Algoritma
input rincianTiket[]
input biodata
read id_pelanggan from
print id_pelanggan, biodata
foreach(rincianTiket[]) {
data = id_pelanggan + rincianTiket[i]
commit data to database jadwal
}
read tiket from database jadwal
where id_pelanggan = id_pelanggan
printeach tiket
Nama Proses Memperbarui akun pelanggan

Input Jadwal perjalanan
Output isSuccess
Tujuan Proses Untuk memasukkan jadwal perjalanan yang
tersusun ke akun pelanggan
Batasan Memmasukkan jadwal perjalanan
Algoritma
input jadwalPerjalanan
read id_pelanggan from jadwalPerjalanan
commit jadwalPerjalanan to pelanggan
where id_pelanggan = id_pelanggan
sendNotificationTo(pelangganX)
Nama Proses Mengotintifikasi perusahaan mitra

Input Username, password
Output Status login
Tujuan Proses Untuk mengecek apakan akun yang masuk
benar dari perusahaan mitra
Batasan Memasukkan username dan password
Algoritma
input username
input password
read form managerMitra
status = match(username, password)
return status
Nama Proses Menampilkan laporan penjualan

Input Status_login, nama_perusahaan
Output Laporan penjualan
Tujuan Proses Untum menampilkan laporan penjualan
perusahaan yang terkait
Batasan Menerima status dan nama perusahaan dari
proses 3.1
Algoritma
if status{
laporan = read from riwayatTransaksi
where nama_perusahaan = nama_perusahaan
}
print laporan
Nama Proses Menampilkan pesan error

Input Status_login
Output Pesan error
Tujuan Proses Untuk menampilkan pesan error jika login gagal
Batasan Menerima status login dari proses 3.1

Algoritma
if !status{
throw errorMessage(“login gagal”)
}
[FIKH]
Nama Proses Mevalidasi Pembayaran

Input bukti
Pembayaran,ID_Pelanggan,ID_Tiket,Jumlah
pembayaran,Jumlah Tagihan
Output Pembayaran Valid
Tujuan Proses untuk membuktikan pembayaran yang dilakukan
n benar adanya
Batasan memasukkan ID_pelanggan,ID_Tiket,Jumlah

Pembayaran,jumlah tagihan
Algoritma
input ID_pelanggan
ID_tiket
ID_Pelanggan
Jumlah Tagihan
Jumlah Pembayaran
Bukti Pembayaran
if Jumlah pembayaran < jumlah tagihan
pembayaran=tidak sesuai
else if jumlah pembayaran == jumlah tagihan
pembayaran=sesuai
Nama Proses Mengubah status pesanan

Input Kesesuaian Pembayaran,
Waktu_Pemberangkatan,Status,ID_tiket
Output Status Baru
Tujuan Proses Untuk merubah status pesanan sesuai
pembayaran yang dilakukan dan
waktu_pemberangkatan
Batasan Memasukkan status pesanan, kesesuaian

pembayaran dan waktu pemberankatan
Algoritma
input Kesesuaian Pembayaran,
if pembayaran == sesuai
status = confirm
commit to status on database Tiket
else if pembayaran =! sesuai
status = pending
if pembayaran == sesuai &&
waktu_pemberangkatan<Tanggal_sekarang
status= completed
commit to status on databse Tiket
[SAD]
Nama Proses Mengotentikasi pengguna

Input Kesesuaian Pembayaran,
Output Mengotentikasi pengguna
Tujuan Proses Untuk merubah status pesanan sesuai
pembayaran yang dilakukan dan
waktu_pemberangkatan
Batasan Memasukkan status pesanan, kesesuaian

pembayaran dan waktu pemberankatan
Algoritma
input Kesesuaian Pembayaran,
if pembayaran == sesuai
status = confirm
else if pembayaran =! sesuai
status = pending
if pembayaran == sesuai &&
waktu_pemberangkatan<Tanggal_sekarang
status= completed
commit to status on databse Tiket
Nama Mengotentikasi pengguna

Proses
Input Email, Password
Output Status login
Tujuan Untuk mengptentikasi pengguna

Proses akun
Batasa Memasukkan email dan password
n
Algoritma
input email
input password
if email, password == sesuai
return status login berhasil
else if email, password =! Sesuai
return status login gagal
Nama Status pemesanan

Proses
Input Status pemesanan, riwayat

pemesanan
Output Status
Tujuan Untuk melihat status pemesanan

Proses
Batasa Memasukkan riwayat pemesanan

n dan status login dari otentikasi
pengguna
Algoritma
Input status login
input password
if riwayat pemesanan == 0
return status pemesanan kosong
else if riwayat pemesanan == 1
return status pemesanan
print riwayat pemesanan
Nama Menyewa mobil

Proses
Input Waktu, tempat_peminjaman,

durasi, pembayaran
Output Form_pembayaran
Tujuan Untuk menyewa kendaraan mobil

Proses
Batasa Memasukkan waktu,

n tempat_peminjaman, durasi,
pembayaran
Algoritma
Input waktu
input tempat_peminjaman
input durasi
input pembayaraan
if waktu, tempat_peminjaman,durasi, pembayaran =!
tersedia
return to input
waktu,tempat_peminjaman,duasi,pembayaran
else if waktu, tempat_peminjaman, durasi, pembayaran
== tersedia
return status tersedia
print form pembayaran
Nama Memesan paket wisata

Proses
Input Waktu, tujuan, durasi
Output Form_pembayaran, jadwal
Tujuan Memesan paket wisata

Proses
Batasa Memasukkan waktu, tujuan, durasi

n
Algoritma
Input waktu
input tujuan
input durasi
if waktu, tujuan,durasi =! tersedia
return to input waktu,tujuan,durasi
else if waktu, tujuan, durasi == tersedia
return status tersedia
print form jadwal
Nama Memesan tiket perjalanan

Proses
Input Waktu, tujuan
Output Form_pembayaran, jadwal,

nomor_kursi
Tujuan Untuk memesan tiket perjalanan

Proses
Batasa Memasukkan waktu, tujuan

n
Algoritma
Input waktu
input tujuan
if waktu, tujuan =! tersedia
return to input waktu,tujuan
else if waktu, tujuan, durasi == tersedia
print harga_tiket
if pelanggan == setuju
print form pembayaran, jadwal
else if pelanggan =! setuju
return to input waktu, tujuan
Nama Menukar mata uang

Proses
Input Asal_mata_uang, jumlah
Output Mata_uang_tujuan
Tujuan Untuk menukar mata uang asing

Proses
Batasa Memasukkan asal_mata_uang

n
Algoritma
Input Asal_mata_uang
input jumlah
if mata_uang_tujuan =! tersedia
return to input asal_mata_uang
else if mata_uang_tujuan == tersedia
print harga_kurs
return to input asal_mata_uang
Nama Memesan kamar hotel

Proses
Input Waktu, hotel, durasi
Output Form_pembayaran,
detail_pemesanan
Tujuan Untuk menukar mata uang asing

Proses
Batasa Memasukkan asal_mata_uang

n
Algoritma
Input waktu
input hotel
input durasi
if waktu, hotel, durasi =! tersedia
return to input waktu, hotel, durasi
else if waktu, hotel, durasi == tersedia
print harga_hotel
return to input waktu, hotel, durasi
[ILMU]
Nama Proses Menyunting laporan keuangan

Input Data Jasa, Harga, Tanggal Penjualan, Laba-Rugi
Output Laporan keuangan
Tujuan Proses Bagian Keuangan dapat menyunting informasi
laporan keuangan setiap bulan agar tercapai
laporan keuangan tiap bulan
Batasan Hanya dapat diakses oleh Bagian Keuangan
Algoritma
input username
input password
read form BagianKeuangan
status = match(username, password)
return status
else
print Menu tidak tersedia
ENDIF
B. Control Specification
Control Specification dideskripsikan dengan menggunakan format dan acuan
sebagai berikut:
Contoh:
Kode CSPEC
Coin Product Get Change Coin Get Payment Coin

Return Available (Activity/Feedback (Activity/Feedback
Request (Event 2) 1) 2)
(Event 1)
True True 1 0
D/C False 0 1
[THR]
Status Menampilkan Menampilkan
Login Pesan Error Laporan Penjualan
True 0 1
False 1 0
[FIKH]
Pem Pemba Waktu Pembayar Status Status Status
baya yaran _pemb an Tidak Confirme Pending Complete
ra sesuai erangk sesuai d d
Valid tagiha atan taguhan
n Sudah
lewat
dari
tangga
sekara
ng
True True False False 1 0
True False False True 0 1 0
False False False False 0 0 0
True True True False 0 0 1
[ILMU]
Status Menampilkan Menampilkan

Login = penyuntingan Laporan Penjualan
Bagian Laporan
Keuangan Keuangan
True 1 1
False 0 0
C. Data Dictionary
Data dictionary dideskripsikan dengan menggunakan 2 format tabel. Untuk
format tabel pertama adalah format tabel seluruh data dan format tabel kedua
menggambarkan detail dari data pada tabel pertama. Data dictionary
dituliskan dengan format sebagai berikut:
Format data pertama yang mendata seluruh data atau kontrol yang
digunakan perangkat lunak
[FIKH]
No. Nama Data Elemen pada Data Tipe
DD_01 Nomor [local number|long data
Telepon distance number]
DD_02 nama [Nama depan | nama data
Pelanggan tengah | nama belakang]
DD_03 ID_Pelangg [long number] data

an
DD_04 Kesesuaian [True|False] control
Pembayaran
Format data kedua yang menjelaskan tiap data pada tabel pertama
DD_01
Nama Data Nomer Telepon

Alias -
Penggunaan Diakses saat dial phone (input)
Deskripsi Data
Telephone number = [local number|long distance number]
Local number = prefix + access number
Long distance number = 1 + area code + local number
Area code = [800 | 888 | 561]
Prefix = *a three digit number that never starts with 0 or 1*
Access number = * any four number string *
DD_02
Nama Data Nama Pelanggan
Alias -
Penggunaan Diakses saat melakukan Pemesanan tiket
Deskripsi Data
nama Pelanggan = [Nama depan | nama tengah | nama belakang]
nama depan = karakter valid
nama tengah = karakter valid
karakter valid = A-Z
DD_03
Nama Data ID_Pelanggan
Alias -
Penggunaan Diakses saat Pemesanan Tiket dan
Pembayaran
Deskripsi Data
ID_Pelanggan = [Long Number]
long number = 16 digit valid number (0,1,2,3,4,5,6,7,8,9)
DD_04
Nama Control Kesesuaian Pembayaran
Alias -
Penggunaan kontrol saat update status
Deskripsi Data
True = Jumlah yang dibayarkan Valid + Sesuai dengan tagihan
False = jumlah yang dibayarkan valid + kurang dengan tagihan
6.5. Tugas V: Pemodelan Arsitektur dan Struktur Program

Untuk mendefinisikan arsitektur program maka terlebih dahulu harus
didefinisikan apakah DFD memiliki ciri dari transform atau transaction flow.
Mengikuti 6 proses pada penjelasan di bab 3.7 Desain Arsitektur.
A. TRANSFORM MAPPING
A.1 Pada sub bab ini digambarkan bagian dari DFD yang memiliki ciri transform
mapping. Pada sub bab ini juga digambarkan batasan antara incoming flow,
transform flow dan outgoing flow.
[FIKH]
[THR]
[ILMU]
A.2 Gambarkan proses first level factoring dari DFD menjadi struktur diagram.
Contoh dapat dilihat pada Gambar 15
[FIKH]
[THR]
[ILMU]
A.3 Gambarkan proses second level factoring dari DFD menjadi struktur diagram
yang komprehensif
[FIKH]
[THR]
[ILMU]
B. TRANSACTION MAPPING
B.1 Pada sub bab ini digambarkan bagian dari DFD yang memiliki ciri
transaction mapping. Pada sub bab ini juga digambarkan batasan antara
transaction center, transaction dan action path. Contoh dapat dilihat pada
Gambar 17.
[SAD]
B.2 Gambarkan proses first level factoring dari DFD menjadi struktur diagram.
Contoh pada Gambar 18
[SAD]
B.3 Gambarkan proses second level factoring dari DFD menjadi struktur diagram
yang komprehensif
[SAD]
C. ARSITEKTUR PROGRAM
Gambarkan arsitektur program dengan menggabungkan hasil factoring dari
transform mapping dan transaction mapping
[FIKH]
Modul Pendekatan Pemodelan Berorientasi Object

NIK/NIP. 198305192014041001
Penyusun
[Kelompok 2]

Asisten


2018
1.Abstrak
Level teknis pengembangan perangkat lunak dimulai pada fase pemodelan atau fase
desain. Fase desain membutuhkan input berupa definisi dan spesifikasi kebutuhan dari
aktivitas analisis kebutuhan. Fase desain menggabungkan kombinasi text dan diagram
untuk mendefinisikan kebutuhan dalam bentuk yang mudah dipahami. Diagram dan text ini
dibagi ke dalam komponen yang merepresentasikan behavior, struktur data dan fungsi
dari perangkat lunak yang akan dibangun. Artefak atau produk yang dihasilkan dari fase
desain adalah Data Object Description, Entity Relationship Diagram, Data Flow Diagrams,
State Transition Diagrams, Process Specification, Control Specification dan Arsitektur dan
Struktur Program.
2.Tujuan Praktikum
Tujuan dari pelaksanaan praktikum mata kuliah ADSI dengan materi desain
terstruktur antara lain:
a. Mahasiswa mampu memahami komponen-komponen penyusunan pada diagram desain
perangkat lunak dengan pendekatan berorientasi objek.
b. Mahasiswa mampu memahami aturan-aturan penyusunan komponen pada diagram yang
dibutuhkan untuk pengembangan perangkat lunak dengan pendekatan berorientasi
object.
c. Mahasiswa mampu mendesain perangkat lunak berdasarkan kebutuhan dengan
pendekatan object.
3.Dasar Teori
Berikut ini beberapa pengertian Rekayasa Perangkat Lunak
a. IEEE Computer Society : Rekayasa Perangkat Lunak sebagai penerapan suatu
pendekatan yang sistematis, disiplin dan terkuantifikasi atas pengembangan,
penggunaan dan pemeliharaan perangkat lunak, serta studi atas pendekatan-
pendekatan ini, yaitu penerapan pendekatan engineering atas perangkat lunak.
b. Roger R. Pressman: Rekayasa Perangkat Lunak adalah pengubahan perangkat lunak
itu sendiri guna mengembangkan, memelihara, dan membangun kembali dengan
menggunakan prinsip reakayasa untuk menghasilkan perangkat lunak yang dapat
bekerja lebih efisien dan efektif untuk pengguna.
3.1.Konsep Perancangan
Perancangan adalah sebuah proses mendefinisikan sesuatu yang akan dikerjakan
dengan teknik bervariasi serta di dalamnya melibatkan deskripsi mengenai arsitektur
serta detail komponen dan juga keterbatasan yang akan dialami dalam proses
pengerjaannya (Rizky, 2011). Menurut Pressman (2010), perancangan perangkat lunak
adalah proses dimana analisis diterjemahkan menjadi blueprint untuk membangun
perangkat lunak. Awalnya, blueprint menggambarkan pandangan menyeluruh perangkat
lunak, yaitu desain pada abstraksi tingkat tinggi yang dapat langsung ditelusuri pada
sistem tertentu, objektif, data rinci, dan fungsionalitas. Namun perbaikan berikutnya
mengarah pada representasi desain dengan tingkat abstraksi yang jauh lebih rendah.
3.2.Konsep OOAD
Menurut Kendall dan Kendall (2011), Object Oriented Analysis and Design merupakan sebuah
pendekatan untuk memikirkan suatu masalah dengan menggunakan model yang dibuat menurut konsep
sekitar dunia nyata. Dasar pembuatan adalah objek merupakan kombinasi antara struktur data dan
perilaku dalam satu entitas.
Beberapa konsep yang manjadi dasar dalam perancangan sistem dengan Object Oriented Analysis
and Design menurut Whitten dan Bentley (2007) adalah:
1. Objek adalah sesuatu yang ada atau dapat dilihat, disentuh, atau dirasakan dan pengguna
menyimpan data serta mencatat perilaku mengenai sesuatu itu.
2. Atribut adalah data yang mewakili karakterikstik tentang sebuah objek.
3. Object instance adalah setiap orang khusus, tempat, sesuatu, atau kejadian, dan juga nilai untuk
atribut dari objek.
4. Behavior adalah kumpulan dari sesuatu yang dapat dilakukan oleh objek dan terkait dengan fungsi-
fungsi yang bertindak pada data objek (atribut). Pada siklus berorientasi objek, perilaku objek
merajuk kepada metode, operasi, atau fungsi.
5. Enkapsulasi adalah pengemasan beberapa item ke dalam unit.
Pendekatan ini menggunakan sebuah standar untuk pemodelan sistem berorientasi objek yang
disebut UML (Unified Modeling Language). UML bukanlah sebuah metode untuk mengembangkan
sistem, melainkan hanya notasi yang saat ini menjadi standar untuk memodelkan desain berorientasi
objek. Berbagai diagram UML, antara lain: use case diagram, activity diagram, class diagram, object
diagram, state machine diagram, composite structure diagram, sequence diagram, communication
diagram, interaction overview diagram, timing diagram, component diagram, deployment diagram, dan
package diagram (Whitten dan Bentley, 2007).Unified Model Language (UML) adalah bahasa
umum untuk :
● Memvisualisasikan grafis model yang tepat.
● Menetapkan model yang tepat, lengkap, dan tidak ambigu untuk mengambil
semua keputusan penting dalam analisis, desain dan implementasi.
● Membangun model yang dapat dihubungkan langsung dengan bahasa
pemrograman.
● Mendokumentasikan semua informasi yang dikumpulkan oleh tim sehingga
memungkinkan untuk berbagi informasi.
3.3.Diagram-diagram UML (Unified Modeling Language)
Unified Modeling Language (UML) memiliki beberapa diagram yang digunakan untuk
menggambarkan suatu sistem. Tujuan pembuatan diagram ini adalah agar sistem mudah dimengerti oleh
semua pihak.
1. Use Case Diagram
Use case diagram dipakai untuk menggambarkan relasi antara sistem, sistem eksternal, dan user
dengan kasus yang disesuaikan dengan langkah-langkah yang telah ditentukan (Whitten dan Bentley,
2007). Use case diagram merupakan cara atau metode yang cocok untuk menggambarkan interaksi yang
jelas antara sistem dengan pengguna. Use case diagram tidak menjelaskan secara detail tentang
penggunaan use case, namun hanya memberi gambaran singkat hubungan antara use case, aktor, dan
sistem. Melalui use case diagram, dapat diketahui fungsi-fungsi apa saja yang ada pada sistem. Nama
suatu usecase harus didefinisikan sesederhana mungkin dan dapat dipahami.
Berikut ini adalah simbol-simbol dalam use case diagram yang terdapat pada Tabel 3.1.
Tabel 3.1 Simbol-simbol pada use case diagram
Simbol Deskripsi
Use case mendeskripsikan fungsi dari
sebuah sistem dilihat dari sudut pandang
pengguna.
Actors merupakan sesuatu yang
berinteraksi dengan sistem untuk saling
bertukar informasi. Actors tidak harus
berupa manusia, tetapi dapat berupa suatu
organisasi atau sistem informasi.
Communicates relationship diguankan

untuk menghubungkan aktor dengan use
case.
Include relationship atau disebut juga uses

relationship menggambarkan situasi dalam
suatu use case yang termasuk dalam use
case lainnya. Bertujuan untuk mengurangi
redundansi di antara dua use case atau
lebih dengan menggabungkan langkah-
langkah yang sama tersebut Sebuah panah
putus-putus yang mengarah pada suatu
use case menandakan memiliki hubungan
dengan use case lainnya.
Extends relationship bertujuan untuk

menggambarkan situasi dimana sebuah
use case memiliki behavior yang
memungkinkan use case lain dapat
menggunakannya sebagai dasar variasi
ataupun pengecualian.
Generalizes relationship menunjukkan
bahwa satu hal lebih umum daripada hal
lain. Hubungan ini memungkinkan terjadi
antara dua aktor maupun dua use case.
Associations adalah sebuah relasi antara

seorang actor dengan sebuah use case di
mana terjadi interaksi antara mereka.
Asosiasi dengan panah tertutup (1) di ujung
yang menyentuh use case mengindikasikan
bahwa actor di ujung yang satu lagi
melakukan use case tersebut. Sedangkan
asosiasi tanpa panah (2) mengindikasikan
sebuah interaksi dari use case ke actor
yang menerima hasil dari use case
tersebut.
Sumber: Kendall dan Kendall (2011)
2. Class Diagram
Menurut Whitten dan Bentley (2007), class diagram digunakan untuk menggambarkan struktur
objek statis dalam sebuah sistem, menunjukkan sistem tersusun dari kelas-kelas apa saja dan hubungan
apa saja yang terbentuk di antara kelas tersebut. Simbol-simbol dalam class diagram terdapat pada Tabel
3.2.
Tabel 3.2 Simbol-simbol pada class diagram
Simbol Deskripsi
Attribute adalah sekumpulan data
yang dimiliki oleh objek.
Behavior adalah kumpulan dari
sesuatu yang dapat dilakukan oleh
objek dan terkait dengan fungsi-fungsi
yang bertindak pada data objek
(atribut). Pada siklus berorientasi
objek, perilaku objek merajuk kepada
metode, operasi, atau fungsi.
Inheritance, menunjukkan bahwa

satu kelas merupakan turunan dari
kelas lain.
Association, menunjukkan bahwa

objek dari satu kelas berhubungan
dengan kelas lain.
Agregation, menunjukkan bahwa
contoh objek dari satu kelas terdiri
dari contoh objek dari kelas lain.
Composition, menunjukkan hubungan
dimana satu kelas bertanggung jawab
atas pembuatan dan perusakan
bagian-bagian dalam kelas lainnya.
Jika satu kelas rusak, maka kelas lain
juga rusak.
Sumber: Whitten dan Bentley (2007)
3. Activity Diagram
Menurut Whitten dan Bentley (2007), activity diagram merupakan gambaran dari alur yang
berurutan dari aktivitas use case atau proses bisnis. Activity diagram juga bisa dipakai untuk
memodelkan berbagai aksi yang dilakukan saat sebuah operasi dieksekusi, dan memodelkan
hasil dari aksi tersebut. Dari diagram ini, dapat dilihat bagaimana aktivitas dalam suatu sistem,
dari mulai hingga saat sistem berakhir. Activity diagram dibentuk oleh beberapa notasi, antara
lain initial node, actions, flow, decision, merge, fork, join, dan activity final. Swimlane terkadang
digunakan untuk mempartisi aksi yang terjadi berdasarkan pelaku. Activity diagram secara
grafis digunakan untuk menggambarkan rangkaian aliran aktivitas baik proses bisnis maupun
use case.
Fungsi dari activity diagram antara lain :
● Menggambarkan proses bisnis dan urutan aktivitas dalam sebuah proses
● Memperlihatkan urutan aktifitas proses pada sistem
● Activity diagram dibuat berdasarkan sebuah atau beberapa use case pada use case
diagramSimbol-simbol dalam activity diagram terdapat pada Tabel 3.3.
Tabel 3.3 Simbol-simbol pada activity diagram
Simbol Deskripsi
Initial node berupa lingkaran
penuh yang menggambarkan titik
mulai suatu proses.
Actions adalah notasi yang
menggambarkan langkah-langkah
yang terjadi.
Flow (alur) merupakan panah
dalam diagram yang
mengindikasikan alur antar–
actions.
Decision memiliki bentuk seperti
wajik dengan satu alur masuk dan
resolved
dua atau lebih alur keluar, alur
Problem not resolved keluar ditentukan dengan kondisi
tertentu.
Merge adalah wajik dengan dua
atau lebih alur masuk dan satu
alur keluar untuk menggabungkan
alur yang sebelumnya terpisah
oleh decision.
Fork adalah bar hitam dengan
satu alur masuk dan dua atau
lebih alur keluar, aksi di bawah
percabangan dapat terjadi dalam
urutan apapun atau bahkan
secara bersamaan.
Join adalah bar hitam dengan dua
atau lebih alur masuk dan satu
alur keluar untuk menyatukan lagi
alur aksi yang dipisahkan oleh
fork.
Activity final berbentuk lingkaran
penuh dengan satu lingkaran di
luarnya untuk menggambarkan
titik akhir proses.
Sumber: Whitten dan Bentley (2007)
Sedangkan menurut Sugiarti (2013), activity diagram juga dapat digunakan untuk
memodelkan action yang akan dilakukan saat sebuah operasi dieksekusi, dan memodelkan
hasil dari action tersebut. Contoh activity diagram terdapat pada Gambar 3.1.
Gambar 3.1 Activity diagram untuk memodelkan action

Sumber: Sugiarti (2013)
4. Sequence Diagram
Sequence diagram secara grafis menggambarkan bagaimana objek berinteraksi dengan
satu sama lain melalui pesan pada sekuensi sebuah use case atau operasi. Diagram ini
mengilustrasikan bagaimana pesan terkirim dan diterima oleh objek dalam sekuensi atau timing
(Sugiarti, 2013). Pesan dapat berupa sinyal atau panggilan terhadap suatu operasi. Notasi
pesan untuk panggilan terhadap suatu operasi dapat dituliskan dalam sintaks UML atau sintaks
bahasa pemrograman tertentu. Simbol-simbol dalam sequence diagram terdapat pada Tabel
3.4.
Tabel 3.4 Simbol-simbol pada sequence diagram
Simbol Deskripsi
Entity, entitas yang mempunyai atribut yang

atau
memiliki data yang bisa direkam.
Boundary, menghubungkan user dengan

sistem.
Control, untuk mengontrol aktivitas-aktivitas
yang dilakukan oleh sebuah kegiatan.
Message, pengiriman pesan.
Return Values, ditampilkan dengan garis
panah terputus yang menggambarkan hasil
dari pengiriman pesan. Digambarkan arah
dari kanan ke kiri.
Garis kehidupan (Lifelines), Garis ertical
putus-putus yang memanjang kebawah dari
simbol actor dan sistem yang
mengindikasikan urutan kehidupan.
Bar aktivasi, Bar didalam garis kehidupan
(lifetime) yang menunjukkan periode waktu
ketika peserta aktif dalam interaksi.
Menurut Pressman (2010), sequence diagram digunakan untuk menunjukkan komunikasi
dinamis antara objek selama pelaksanaan tugas. Contoh sequence diagram terdapat pada
Gambar 3.2.
Gambar 3.2 Contoh model sequence diagram login
Sumber: Pressman (2010)
5.User Story
negeri. Saat ini travel JalanSkuy melayani pelanggan secara konvensional yaitu pelanggan
harus datang ke agen perjalanan langsung. Sehingga jika pelanggan hendak mengetahui
paket berwisata dengan jasa travel JalanSkuy, pelanggan memilih paket wisata melalui
brosur dan buku katalog yang disediakan oleh pihak travel. Travel JalanSkuy menyediakan
beberapa layanan perjalanan wisata, di antaranya, pembelian tiket pesawat, tiket kereta api,
tiket bus, rental mobil, pemesanan kamar hotel, paket perjalanan wisata, dan penukaran
mata uang (money changer).
menyediakan layanan online berbasis web dan mobile yang dapat memudahkan pelanggan
dalam mendapatkan informasi dan melakukan transaksi pemesanan. Pelanggan dapat
mengetahui jadwal dan harga tiket kereta, tiket pesawat, tiket bus, mengetahui informasi
terkait kamar ketersediaan dan harga kamar hotel yang dapat dipesan, serta paket
perjalanan wisata baik yang menggunakan tour guide maupun tidak. Pelanggan yang ingin
memesan tiket kereta, pesawat, bus, memesan kamar hotel, dan paket perjalan harus
memiliki akun yang diverifikasi menggunakan alamat email.
Sementara untuk pembelian tiket kereta, pelanggan dapatkan diskon 10% jika pelanggan
melakukan 5 kali pembelian tiket kereta. Khusus pelajar, pembelian tiket bus akan
mendapatkan cashback 10% ke SkuyCash.
● Booked: tiket telah dipesan dan tagihan pembayaran pesanan tiket telah diterbitkan
CEO JalanSkuy juga menginginkan adanya laporan keuangan bulanan. Pihak manager dari
perusahaan kereta, pesawat, bus, maupun hotel juga dapat mengetahui laporan penjualan
tiket terkait dengan layanan transportasi yang mereka sediakan melalui sistem JalanSkuy.
Sementara administrator dapat menjawab pertanyaan dari pelanggan dan membuat
penjadwalan travel antarkota yang menggunakan mini bus. Selain itu, administrator dapat
melayani pelanggan secara langsung di agen travel JalanSkuy. CEO JalanSkuy
menginginkan keamanan dan privasi data yang baik. Website maupun aplikasi mobile yang
digunakan oleh pengguna dapat berjalan baik dan cepat walaupun digunakan oleh
pengguna yang banyak dalam satu waktu. Untuk mengurangi kerugian, CEO JalanSkuy
tidak menginginkan adanya permasalahan dalam proses pemesanan tiket pesawat, kereta,
minibus, dan kamar hotel, sehingga sistem perlu menyediakan mekanisme untuk
menghindari pelanggan mendapatkan nomor duduk yang sama atau nomor kamar yang
sama dengan pelanggan lainnya.
6.Soal – Soal latihan
5.1 Tugas I: Pemodelan Use Case Diagram
Pada Pemodelan Use Case Diagram gambarkan Use Case Diagram dari kebutuhan pengguna
tersebut sesuai dengan teori use case diagram. Gunakan user story di atas serta user story
baru yang sudah Anda buat kemudian modelkan dengan use case diagram untuk menentukan
data aktor dan aktivitas yang dilakukan serta relasi antar aktivitas setelah itu buatkan pula use
case scenarionya.
Kode
Aktor Usecas Usecase
e
Administrator UC001 Mengupdate status
pemesanan
Administrator UC004 Menjadwalkan perjalanan
Pelanggan UC002 Mengajukan pertanyaan
Pelanggan UC005 Memesan layanan
Pelanggan UC006 Melihat jadwal perjalanan
Manager UC003 Melihat laporan keuangan
Mitra perusahaan terkait
Bagian UC007 Membuat laporan keuangan
Keuangan
Sistem
Manager UC008 Melihat Laporan Keuangan
JalanSkuy
[UC001 - FIKH]
[SAD]
[THR]
[UC007 ILMU]
Analisis Use Case
[FIKH]
Asosiasi
Aktivitas
Include Extend
Memesan layanan otentikasi Cetak Tiket
Mengetahui status pesanan otentikasi
Merubah Status Pesanan otentikasi
Pelanggan
[SAD]
Asosiasi
Aktivitas
Include Extend
Memilih layanan Otentikasi, Cetak
mengisi detail Booking,
pemesanan Mengisi data
pelanggan
Melihat status pesanan otentikasi
Konfirmasi pemesanan otentikasi
[THR]
Asosiasi
Aktivitas
Include Extend
Mengajukan pertanyaan Otentikasi -
Menjadwalkan perjalanan Otentikasi -
Melihat jadwal perjalanan Otentikasi Cetak Jadwal
Perjalanan
Melihat laporan keuangan Otentikasi Unduh laporan
perusahaan terkait
[ILMU]
Asosiasi
Aktivitas
Include Extend
Meminta laporan keuangan Otentikasi Unduh laporan
JalanSkuy
Meminta laporan keuangan Otentikasi Unduh laporan
perusahaan mitra
Membuat laporan keuangan Otentikasi -
Generalisasi Aktor
Aktor Aktor Generalisasi
Use Case Specification
Use Case ID: UC001

Use Case Mengupdate Status Pesanan
Name:
Created By: Fikri Hernanda Last Updated By:
Date Created: 23/04/2018 Date Last
Updated:
Actor: Pelanggan,Administrator
Description: Use case ini menjelaskan tentang tahapan status pelanggan
Usecase Goal: Pelanggan Dapat Mengetahui status pesananya hingga
melakukan perjalanan
Preconditions: Pelanggan Sudah Memesan layanan
Main Flow:
1. Pelanggan memesan Layanan
2. Administrator mengupdate status Pesanan menjadi
Booked
3. Pelanggan memberikan bukti pembayaran
4. Administrator memverifikasi pembayaran
5. Administrator mengupdate status pesanan menjadi
Confirmed
6. Administrator Memberikan Tiket layanan
7. Pelanggan melakukan perjalanan.
8. Administrator Mengupdate status pesanan menjadi
completed
Alternative Flow - 1: 6a. Pelanggan melakukan kurang bayar.
6a1. Administrator mengupdate status pesanan menjadi
pending
6a1. flow ke (5)
Alternative Flow - 2: 6b.Pelanggan melakukan pembayaran yang tidak
terverifikasi
6b1.Administrator mengupdate status pesanan menjadi
pending
6b2.flow ke 5
Postconditions: Status pesanan Pelanggan adalah Completed
Use Case ID: UC002

Use Case Mengajukan pertanyaan
Name:
Created By: Thariq Al A. Last Updated By:
Date Created: Date Last
Updated:
Actor: Pelanggan, Administrator

Description: Pelanggan dan administrator melakukan tanya jawab melalui
sistem
Usecase Goal: Pelanggan mendapat jawaban atas pertanyaannya
Preconditions: Pelanggan sudah melakukan login
Main Flow: 1. Pelanggan memilih menu ‘Ajukan pertanyaan’
2. Sistem menampilkan formulir pertanyaan
3. Pelanggan memasukkan pertanyaan pada formulir
4. Sistem menampilkan ‘Pertanyaan telah dikirim’
5. Sistem memberikan notifikasi, menampilkan pertanyaan
dan formulir jawaban kepada administrator
6. Administrator memasukkan jawaban pada formulir
7. Sistem menampilkan ‘Jawaban telah dikirim’
8. Sistem memberikan notifikasi, menampilkan pertanyaan
dan jawaban kepada pelanggan
Alternative Flow - 1: -
Postconditions: Pelanggan mendapat jawaban
Use Case ID: UC003

Use Case Melihat laporan keuangan perusahaan terkait
Name:
Updated:
Actor: Manager mitra

Description: Manager mitra melihat laporan keuangan penjualan
perusahaan terkait
Usecase Goal: Manager mitra berhasil menampilkan laporan keuangan
perusahaan terkait
Preconditions: Manager mitra telah melakukan login
Main Flow: 1. Manager mitra memilih menu laporan keuangan
penjualan perusahaan
2. Sistem menampilkan laporan keuangan
Alternative Flow - 1: 2a. Manager mitra mengunduh laporan keuangan
2a. 1. Sistem mengubah laporan menjadi PDF
2a. 2. Sistem menyimpan PDF pada perangkat manager
mitra
Postconditions: Sistem menampilkan laporan keuangan perusahaan terkait
Use Case ID: UC004

Use Case Menjadwalkan perjalanan
Name:
Updated:
Actor: Administrator
Description: Administrator melakukan penjadwalan pada perjalanan yang
dipesan pelanggan
Usecase Goal: Administrator membuat jadwal pejalanan
Preconditions: Administrator telah melakukan login, administrator mendapat
rincian tiket
Main Flow: 1. Administrator membuka menu ‘Jadwalkan perjalanan’
2. Sistem menampilkan seluruh pelanggan yang perlu
penjadwalan perjalanan
3. Administrator memilih pelanggan yang akan dijadwalkan
4. Sistem menampilkan daftar tiket dari seluruh perusahaan
yang terkait perjalanan pelanggan
5. Adminsitrator memilih tiket yang sesuai dan menyimpan
jadwal
6. Sistem menampilkan pratinjau jadwal dan menampilkan
konfirmasi kebenaran
7. Administrator memilih pilihan benar
8. Sistem mengirim jadwal kepada pelanggan terkait dan
memberikan notifikasi
Alternative Flow - 1: 5a. Jadwal tiket bertabrakan
5a. 1. Sistem menampilkan pesan terdapat jadwal yang
bertabrakan
5a. 2. Flow ke (4)
Alternative Flow - 2: 7a. Administrator memilih pilihan batal
7a. 1. Flow ke (4)
Postconditions: Pelanggan mendapat jadwal perjalanan
Use Case ID: UC005

Use Case Memesan layanan
Name:
Created By: Muhammad Irsad Last Updated By:
Updated:
Actor: Pelanggan, Administrator

Description: Menjelaskan proses pemesanan layanan oleh pelanggan dan
administrator
Usecase Goal: Pelanggan dapat memesan layanan
Preconditions: Pelanggan ingin memesan suatu layanan
Main Flow: 1. Pelanggan mengawali dengan login
2. Sistem menampilkan menu
3. Pelanggan memilih pesan tiket
4. Sistem menampilkan form detail pemesanan perjalanan
5. Pelanggan mengisi form detail pemesanan perjalanan
6. Sistem menampilkan form detail pemesan
7. Pelanggan mengisi form detail pemesan
8. Sistem memberi pilihan cara pembayaran
9. Pelanggan memilih cara pembayaran
10. Sistem memberikan kode booking
11. Pelanggan mencetak kode booking
Alternative Flow - 1: 1a. Login gagal
1a. 1. Sistem menampilkan username/password sakah
1a. 2. Flow ke (1)
Alternative Flow - 2: 3a. Pelanggan memilih lihat status pemesanan
3a. 1. Sistem menampilkan masukkan kode booking
3a. 2. Pelanggan memasukkan kode booking
3a. 3. Sistem menampilkan detail pemesanan
Postconditions: Pelanggan mendapatkan tiket pemesanan
Use Case ID: UC006

Use Case Melihat jadwal perjalanan
Name:
Updated:
Actor: Pelanggan
Description: Pelanggan melihat jadwal perjalanan yang telah dibuat oleh
administrator
Usecase Goal: Pelanggan mengetahui jadwal perjalanan
Preconditions: Pelanggan telah melakukan login
Main Flow: 1. Pelanggan memilih menu lihat jadwal perjalanan
2. Sistem menampilkan jadwal perjalanan
Alternative Flow - 1: 2a. Pelanggan mengunduh jadwal perjalanan
2a. 1. Sistem mengubah jadwal menjadi PDF
2a. 2. Sistem menyimpan PDF pada perangkat pelanggan
2b. Jadwal belum dibuat
2b. 1. Sistem menampilan pesan ‘Jadwal belum dibuat’
Postconditions: Sistem menampilkan jadwal perjalanan pelanggan
Use Case ID: UC007

Use Case Membuat Laporan Keuangan
Name:
Created By: Ilham Maulana Last Updated By:
Ubaidillah
Updated:
Actor: Bagian keuangan, Manajer JalanSkuy, Manajer Mitra

Description: Use case ini menjelaskan tentang tahapan pembuatan
laporan keuangan
Usecase Goal: - Manajer JalanSkuy Dapat Mengetahui Laporan
Keuangan JalanSkuy
- Manajer Mitra Dapat Mengetahui Laporan Keuangan
Perusahaan Mitra
Preconditions: - Manajer JalanSkuy meminta laporan keuangan
JalanSkuy
- Manajer Mitra meminta laporan keuangan
perusahaan mitra
Main Flow: - Bagian Keuangan melakukan otentikasi
- Bagian Keuangan memilih menu edit laporan
keuangan
- Sistem Menampilkan menu edit laporan
- Bagian Keuangan memilih menu buat neraca saldo
- Sistem menampilkan menu buat neraca saldo
- Bagian Keuangan membuat jurnal penyesuaian
- Bagian Keuangan menyusun neraca lajur
- Sistem menampilkan menu menyusun neraca lajur
- Bagian Keuangan menutup rekening
- Sistem menampilkan menu tutup rekening
- Bagian Keuangan membuat laporan keuangan
- Sistem menampilkan laporan keuangan
Alternative Flow - 1: - 1. Sistem menampilkan jurnal penyesuaian
- 1.a Sistem menampilkan update jurnal
- 1.a.1 Sistem menampilkan kembali menu membuat
jurnal penyesuaian
- 1.b Sistem menampilkan verifikasi semua transaksi
tercatat dan sesuai dengan akhir periode
Postconditions: - Manajer JalanSkuy melihat laporan keuangan
JalanSkuy
- Manajer Mitra melihat laporan keuangan perusahaan
mitra
5.2 Tugas II: Pemodelan Activity Diagram
Berdasarkan pemodelan Use Case Diagram dan Use Case Scenario pada tugas I, buatlah
activity diagram dari use case tersebut berdasarkan use case scenario. Isikan data aktivitas
yang dilakukan pada scenario sesuai dengan urutan yang ada pada use case scenario pada
kolom activity, aktor yang melakukan dan jika dibutuhkan persyaratan pada aktivitas tersebut
tuliskan dalam kolom precondition activity.
Activity ID: AD001

Activity title: Mengupdate Status Pesanan
Use Case UC001
Scenario ID :
Updated:
Main Flow
Precondition Activity
Activity Aktor
Memesan Layanan Pelanggan
Merubah Status menjadi Administrat Memesan Layanan
Booked or
Memberikan Bukti Pembayaran Pelanggan Status sudah Menjadi
booked
Memverifikasi Pembayaran Administrat Bukti pembayaran
or diberikan
Merubah status menjadi Administrat Bukti Pembayaran valid
confirmed or dan tidak sesuai tagihan
Memberikan Tiket Administrat Status sudah Confirmed
or
Melakukan Perjalanan Pelanggan Sudah diberikan TIket
Alternative Flow
Precondition
Activity Aktor
Activity
Memesan Layanan Pelanggan
Merubah Status Administrator Memesan Layanan
menjadi Booked
Memberikan Bukti Pelanggan Status sudah
Pembayaran Menjadi booked
Memverifikasi Administrator Bukti pembayaran
Pembayaran diberikan
Merubah status Administrator Bukti Pembayaran
menjadi Pending tidak valid atau
tidak sesuai
tagihan
kembali ke Flow Pelanggan Status menjadi
Memberikan Bukti Pending
Pembayaran
Activity ID: AD002
Activity title: Mengajukan Pertanyaan
Use Case UC002
Scenario ID :
Updated:
Main Flow
Activity Aktor
Memilih menu ajukan Pelanggan Pelanggan dan
pertanyaan adminsitrator telah
melakukan login
Menampilkan formulir Sistem Menu ajukan
pertanyaan pertanyaan dipilih
Memasukkan pertanyaan Pelanggan Formulir telah dimuat
sepenuhnya
Menampilkan pesan bahwa Sistem Pertanyaan telah
pertanyaan telah terkirim selesai dimasukkan
Memberikan notifikasi, Sistem Pertanyaan telah
menampilkan pertanyaan dan disimpan
formulir jawaban kepada
administrator
Memasukkan jawaban Administrat Formulir telah dimuat
or sepenuhnya
Menampilkan pesan bahwa Sistem Jawaban telah selesai
jawaban telah terkirim dimasukkan
Memberikan notifikasi, Sistem Jawaban telah disimpan
menampilkan pertanyaan dan
jawaban kepada pelanggan
Activity ID: AD003
Activity title: Melihat laporan keuangan perusahaan terkait
Use Case UC003
Scenario ID :
Updated:
Main Flow
Activity Aktor
Memilih menu laporan Manager Manager mitra telah
keuangan mitra melakukan login
Menampilkan laporan keuangan Sistem Menu laporan keuangan
dipilih
Alternative Flow
Precondition
Activity Aktor
Activity
Mengubah laporan Sistem Laporan keuangan
keuangan menjadi telah dimuat dan
PDF manager mitra
memilih cetak
Menyimpan PDF Sistem Laporan keuangan
pada perangakt telah berhasil
manager mitra diubah ke PDF
Activity ID: AD004

Activity title: Menjadwalkan perjalanan
Use Case UC004
Scenario ID :
Updated:
Main Flow
Activity Aktor
Membuka menu jadwalkan Administrat Administrator telah login
perjalanan or
Menampilkan seluruh Sistem Menu jadwalkan
pelanggan yang perlu perjalanan telah dibuka
dijadwalkan
Memilih salah satu pelanggan Administrat Seluruh daftar
or pelanggan telah termuat
Menampilkan seluruh rincian Sistem Pelanggan telah dipilih
tiket
Memilih tiket yang sesuai dan Administrat Seluruh rincian tiket
menyimpan jadwal or telah termuat
Menampilkan pratinjau jadwal Sistem Jadwal telah disimpan
perjalanan dan menampilkan
menu konfirmasi
Memilih pilihan konfirmasi Administrat Pratinjau telah termuat
or
Mengirim jadwal kepada Sistem Konfirmasi yang dipilih
pelanggan terkait dan adalah benar
memberikan notifikasi
Alternative Flow
Precondition
Activity Aktor
Activity
Menampilkan pesan Sistem Tiket yang
bahwa terdapat dijawalkan
jadwal yang memiliki waktu
bertabrakan yang bertabrakan
Activity ID: AD005
Activity title: Melihat jadwal perjalanan
Use Case UC006
Scenario ID :
Updated:
Main Flow
Activity Aktor
Memilih menu lihat jadwal Pelanggan Pengguna telah
perjalanan melakukan login
Menampilkan jadwal perjalanan Sistem Jadwal telah tersedia
dan menu lihat jadwal
perjalanan dipilih
Alternative Flow
Precondition
Activity Aktor
Activity
Menampilkan pesan Sistem Jadwal belum
jadwal belum dibuat tersedia
Mengubah jadwal Sistem Jadwal telah
menjadi PDF tersedia dan
pelanggan memilih
menu cetak
Menyimpan PDF Sistem Jadwal perjalanan
pada perangakat telah berhasil
pelanggan diubah ke PDF
Activity ID: AD006
Activity title: Memesan layanan
Use Case UC005
Scenario ID :
Updated:
Main Flow
Activity Aktor
Menampilkan pilihan menu Sistem Pelanggan telah
terotentikasi
Memilih menu pemesanan Pelanggan Pilihan menu telah
ditampilkan
Memasukkan detail pemesanan Pelanggan Detail pemesanan
belum ada
Mengisi detail pemesan Pelanggan Detail pemesan masih
kosong
Memilih cara pembayaran Pelanggan Detail pemesanan dan
detail pemesan telah
terisi
Menampilkan kode booking Sistem Kode booking sudah
tersedia
Mencetak kode booking Sistem Kode booking belum
dicetak
Alternative Flow
Precondition
Activity Aktor
Activity
Memilih menu Status Pelanggan Menu telah
pemesanan ditampilkan
Memasukkan kode Pelanggan Pelanggan ingin
booking melihat status
pemesanan
Menampilkan detail Sistem Detail pemesanan
pemesanan yang lalu sudah
ada, ingin dilihat
kembali
Activity ID: AD007
Activity title: Membuat laporan keuangan
Use Case UC007
Scenario ID :
Ubaidillah
Updated:
Main Flow
Activity Aktor
Memilih menu edit laporan Bagian Pengguna telah
keuangan Keuangan melakukan login
Menampilkan menu edit laporan Sistem Sistem menyediakan
keuangan prosedur membuat
laporan keuangan
Memilih menu buat neraca Bagian Pengguna telah
saldo Keuangan mengamati data nomor
akun, nomor rekening,
debet, kredit sudah
tersedia
Menampilkan menu buat neraca Sistem Data nomor akun,
saldo nomor rekening, debet,
kredit sudah tersedia
Membuat jurnal penyesuaian Bagian Pengguna telah
Keuangan mendapatkan data
semua transaksi
sebelumnya
Menyusun neraca lajur Bagian Sistem telah mencatat
Keuangan semua transaksi
sebelumnya
Menampilkan menu menyusun Sistem Sistem telah mencatat
neraca lajur Kolom Nama Rekening
Perkiraan. Berisi nama
seluruh kode akun
perkiraan yang telah
disusun sebelumnya,
dari nama rekening
perkiraan ini juga akan
ditentukan, apakah
sebuah akun bernilai
debet atau kredit pada
setiap lajur kolom.
Kolom Neraca
Saldo.Kolom
Penyesuaian. Kolom
Neraca. Kolom Rugi
Laba.
Menutup rekening Bagian Pengguna telah

Keuangan memastikan bahwa
tidak ada perubahan
dalam metode
sebelumnya
Menampilkan menu tutup Sistem Sistem telah mencatat
rekening semua perubahan
metode
Laporan Keuangan Bagian Semua laporan sudah
Keuangan tersusun dalam bentuk
laporan keuangan
Menampilkan Laporan Sistem Semua laporan sudah
Keuangan tersusun dalam bentuk
laporan keuangan
Alternative Flow
Precondition
Activity Aktor
Activity
Menampilkan jurnal Sistem Sistem telah
penyesuaian mencatat riwayat
transaksi
sebelumnya
5.3 Tugas III : Pemodelan Sequence Diagram
Berdasarkan pemodelan Activity Diagram pada tugas II, buatlah sequence diagram dari
activity diagram tersebut. Isikan data sesuai dengan tabel dibawah ini yaitu aktor yang
melakukan, boundary kelas, entitas pada kelas yang berhubungan, control kelas sebagai
penghubung dengan boundary dan meesage sebagai pesan yang dikirimkan atau diterima.
Sequence ID: SD001

Sequence title: Mengupdate Status Pesanan
Activity AD001
Diagram ID :
Date Created: 3 Mei 2018 Date Last
Updated:
Aktor Boundary Kontrol Entitas

Kelas Kelas Kelas
Pelangga Menu Admin Rekening
n Layanan, Verifikasi JalanSkuy
Pemesana Control
n
Pelanggan,
Konfirmasi
Pembayar
an
Sequence ID: SD002
Sequence title: Memesan layanan
Activity AD006
Diagram ID :
Updated:
Aktor Boundary Kelas Kontrol Entitas Kelas

Kelas
Pelangga Login, pesan login Login Akun
n gagal, menu, masukkan control, jalanskuy,
kode booking, pesan kode kode
kode booking salah, booking booking,
detail pemesanan fix, control, ketersediaan
isidan detail booking layanan, data
pemesanan, pesan control, pemesan
detail yang diinginkan detail
tidak tersedia, isian pemesana
form pemesan, cara n control
pembayaran,
menampilkan kode
booking
Sequence ID: SD003

Sequence title: Mengajukan Pertanyaan
Activity AD002
Diagram ID :
Updated:

Kelas Kelas Kelas
Pelangga Menu Kontrol Pelanggan
n, Utama, Pertanyaan
Administr Tampilan
ator Formulir,
Notifikasi
Sequence ID: SD004
Sequence title: Melihat Laporan Keuangan Perusahaan Terkait
Activity AD003
Diagram ID :
Updated:

Kelas Kelas Kelas
Manager Menu Kontrol Catatan
Mitra Utama, Transaksi Penjualan
Tampilan
Laporan
Keuangan,
Pencetak
PDF
Sequence ID: SD005
Sequence title: Menjadwalkan Perjalanan
Activity AD004
Diagram ID :
Updated:

Kelas Kelas Kelas
Adminsitr Menu Kontrol Basis Data
ator Utama, Jadwal
Tampilan
Daftar
Pelanggan,
Tampilan
Daftar
Tiket,
Tampilan
Pratinjau
Sequence ID: SD006
Sequence title: Melihat Jadwal Perjalanan
Activity AD005
Diagram ID :
Updated:

Kelas Kelas Kelas
Pelangga Menu Kontrol Catalan
n Utama, Transaksi Jadwal
Jadwal Perjalanan
Perjalanan,
Pesan
Error,
Pencetak
PDF
Sequence ID: SD007
Sequence title: Membuat Laporan Keuangan
Activity AD007
Diagram ID :
Ubaidillah
Updated:
Aktor Boundary Kelas Kontrol Entitas Kelas

Kelas
Pelangga Menu edit laporan, Update Laporan
n menu buat neraca,buat Jurnal Keuangan
jurnal penyesuaian,
menyusun neraca jalur,
menutup rekening,
laporan keuangan
Analisis messages digunakan untuk memetakan messages yang digunakan pada sequence
diagram. Pemetaan meesages ini melibatkan object pada sequence, meesage yang dikirimkan,
parameter pada message, object tujuan dari messages dan return value dari messages
tersebut. Analisa messages dapat ditulisakan pada tabel berikut.
Tabel Analisis Messages

[FIKH SD001]
Messag Object Asal Object Messages Data / Return Value
e Tujuan Parameter
Number
1 Pelanggan Menu Memesan Data
Layanan Layanan Layanan
1.1 Menu Pesanan tambah() pesanan,St Menampilkan
Layanan Pelanggan atus Status
Booked,No pesanan
minal Menjadi
Tagihan Booked
2 Pelanggan konfirmasi tampilkan konfirmasi menampilkan
Pembayara konfirmasi bukti halaman
n Bukti pembayara konfirmasi
Pembayaran ni pembayaran
3 Pelanggan Konfirmasi lampirkan bukti
Pembayara Bukti pembayara
n Pembayaran n
3.1 Konfirmasi AdminVerifi meneruskan bukti
Pembayaran kasi Bukti Pembayara
Control Pembayaran n
3.1.1 Admin Rekening CekPembayar nomor Valid
Verifikasi JalanSkuy an() transaksi
Control
8 Rekening Admin tidak valid bukti tidak
JalanSkuy Verifikasi valid
Control
8.1 Admin Pesanan updateStatus( status
Verifikasi Pelanggan ) Pending
Control
8.1.1 Pesanan Pelanggan menampilkan status
Pelanggan status Pending
pending
4.1 Admin Rekening cekNominal() nominal Nominal
Verifikasi JalanSkuy pembayara Sesuai
Control n
7 Rekening Admin update Status
JalanSkuy Verifikasi Status() Pending
Control
7.1.1 Pesanan Pelanggan menampilkan Status
Pelanggan status Pending
Pending
5.1 Admin Pesanan updateStatus( confirmed,
Verifikasi Pelanggan ),Berikan() Tiket
control
5.1.1 Pesanan Pelanggan Menampilkan Tiket
Pelanggan Status
Confirmed
dan Tiket
6 Pelanggan Admin melakukan tanggal UpdateStatus(
Verifikasi perjalanan perjalanan completed)
Control sesuai tanggal
6.1 Admin Pesanan UpdateStatus( Status
Verifikasi Pelanggan ) Completed
Control
6.1.1 Pesanan Pelanggan Menampilkan
Pelanggan Status
Completed
[SAD SD002]
e Tujuan Parameter
Number
1 Pelanggan Login Login username,
password
1.1 Login Login username/pas username,
control word password
1.1.1 Login control Akun Cek login username,
jalanskuy akun password
1.1.3 Akun Login True login valid Pesan true
jalanskuy control
1.1.3.1 Login control Menu tampilkan() login valid
1.1.3.1. Menu Pelanggan Menampilkan Pilihan Halaman
1 menu utama menui menu utama
2 Pelanggan Menu Cek status Pilihan
pemesanan menu
2.1 Menu Masukkan tampilkan() Pilihan
kode menu
booking
2.1.1 Masukkan Pelanggan menampilkan Isian kode Halaman isi
kode booking masukkan booking kode booking
kode booking
3 Pelanggan Kode Kode booking kodebookin
booking g
control
3.1 Kode Entity kode cek kodebookin
booking booking kodebooking g
control
3.3 Entity kode Kode True Kode Pesan true
booking booking booking
control valid
3.3.1 Kode Fix detail tampilkan() Kode
booking pemesana booking
contol n valid
3.3.1.1 Fix detail Pelanggan Menampilkan Detail Halaman
pemesanan detail pemesanan detail
pemesanan pemesanan
pelanggan pelanggan
sesuai sesuai
dengan kode dengan kode
booking booking
4 Pelanggan Menu Pemesanan Pilihan
pemesanan
4.1 Menu Isian detail tampilkan() Pilihan
pemesana pemesanan
n
4.1.1 Isian detail Pelanggan Menampilkan Form isian Halaman isian
pemesanan form isian detail detail
detail pemesanan pemesanan
pemesanan
5 Pelanggan Booking Detail waktu,
control pemesanan tempat,
harga,
durasi
5.1 Booking Ketersedia Cek waktu,
control an layanan ketersediaan tempat,
harga,
durasi
5.3 Ketersediaan Booking True waktu, Pesan true
layanan control tempat,
harga,
durasi
5.3.1 Booking Isian form tampilkan() Status true
control pemesan
5.3.1.1 Isian form Pelanggan Menampilkan Isian form Halaman isian
pemesan isian detail form
pemesan
6 Pelanggan Data Data nama,
pemesan pemesan alamat,
control email
6.1 Data Entity data Isi nama,
pemesan pemesan alamat,
control email
6.1.1 Entity data Cara tampilkan() Data
pemesan pemayaran pemesan
6.1.1.1 Cara Pelanggan Menampilkan Opsi cara Halaman cara
pembayaran halaman cara pembayara pembayaran
pembayaran n
7 Pelanggan Booking Memilih cara Cara
control pembayaran pembayara
n
7.1 Booking Entity kode Buat kode kode
control booking booking booking
7.1.1 Entity kode Menampilk tampilkan() kode kode booking
booking an kode booking
booking
7.1.1.1 Menampilkan Pelanggan Menampilkan kode Halaman
kode booking kode booking booking tampilan kode
sementara booking
untuk
melakukan
pembayaran
[THR SD003]
e Tujuan Parameter
Number
1 Pelanggan Menu Pilihan Ajukan
Tujuan Pertanyaan
1.1 Menu Utama Tampilan tampilkanPert
Formulir anyaan()
1.1.1 Tampilan Pelanggan Tampilan
Formulir Formulir
Pertanyaan
2 Menu Utama Tampilan Mengisi Pertanyaan
Formulir Pertanyaan
dan Tekan
Kirim
2.1 Tampilan Kontrol setPertanyaan Pertanyaan
Formulir Pertanyaan
2.1.1 Kontrol Pelanggan simpanPertan Pertanyaan
Pertanyaan (entity) yaan
2.1.2 Kontrol Tampilan pop “Sukses”
Pertnayaan Formulir
2.1.3 Tampilan Pelanggan Tampilan Pop
Formulir Up Sukses
2.1.3 Kontrol Notifikasi notifikasiPerta id_pegawai
Pertanyaan nyaan ,
pertanyaan
2.1.3.1 Notifikasi Adminsitrat Notifikasi
or Pertanyaan
3 Pelanggan Notifikasi Menekan
Jawab
3.1 Notifikasi Kontrol jawabPertany id_pegawai
Pertanyaan aan ,
pertnyaaan
3.1.1 Kontrol Tampilan tampilkanJaw pertanyaan
Pertanyaan Formulir aban
3.1.1.1 Tampilan Administrat Tampilan
Formulir or Formulir
Jawaban
4 Administrator Tampilan Jawaban Jawaban
Formulir
4.1 Tampilan Kontrol setJawaban id_pelangg
Formulir Pertanyaan an,
pertanyaan
, jawaban
4.1.1 Kontrol Pelanggan( setJawaban pertanyaan
Pertanyaan entity) , jawaban
4.1.2 Kontrol Tampilan pop “Sukses”
Jawaban Formulir
4.1.3 Tampilan Administrat Tampilan Pop
Formulir or Up Sukses
4.1.3 Kontrol Notifikasi notifikasi id_pelangg
Jawaban an,
pertanyaan
, jawaban
4.1.3.1 Notifikasi Pelanggan Notifikasi Jawaban
Jawaban
[THR SD004]
e Tujuan Parameter
Number
1 Manager Menu Pilihan
Mitra Utama Laporan
Keuangan
1.1 Menu Utama Tampilan tampilkan
Laporan
Keuangan
1.1.1 Tampilan Kontrol cekLaporanKe
Laporan Transaksi uangan
Keuangan
1.1.1.1 Kontrol Catatan getLaporanKe id_perusah Laporan
Transaksi Penjualan uangan aan
1.1.1.2 Catatan Kontrol laporan laporan
Keuangan Transaksi
1.1.1.3 Kontrol Tampilan tampilkanLap laporan
Transaksi Laporan oran
Keuangan
1.1.1.3. Tampilan Manager Tampilkan
1 Laporan Mitra Laporan
Keuangan Keuangan
2 Manager Tampilan Cetak
Mitra Laporan Laporan
Keuangan Keuangan
2.1 Tampilan Kontrol cetakLaporan
Laporan Transaksi
Keuangan
2.1.1 Kontrol Pencetak cetakLaporan laporan
Transakasi PDF
2.1.1.1 Pencetak Manager File PDF PDF
PDF Mitra Laporan Laporan
Keuangan Keuangan
[THR SD005]
e Tujuan Parameter
Number
1 Administrator Menu Pilihan
utama penjadwalan
perjalanan
1.1 Menu utama Tampilan tampilkan
daftar
pelanggan
1.1.1 Tampilan Kontrol printPelangga
daftar jadwal nPenjadwalan
pelanggan
1.1.1.1 Kontrol Basis data getPelanggan pelanggan
jadwal Penjadwalan
1.1.1.3 Kontrol Tampilan tampilkan pelanggan
jadwal Daftar
Pelanggan
1.1.1.3. Tampilan Administrat Halaman
1 daftar or Daftar
pelanggan pelanggan
2 Pilihan Tampilan Pilihan
pelanggan daftar pelanggan
pelanggan
2.1 Tampilan Tampilan tampilkan id_pelangg
daftar daftar tiket an
pelanggan
2.1.1 Tampilan Kontrol getTiket id_pelangg tiket
daftar tiket jadwal an
2.1.1.1 Kontrol Basis data getTipePemes id_pelangg tipe_pemesan
jadwal anan an an
2.1.1.3 Kontrol Basis data getTiket id_pelangg tiket
jadwal an
2.1.3 Tampilan Administrat Daftar tiket
Daftar Tiket or
[THR SD006]
e Tujuan Parameter
Number
1 Pelanggan Menu Memilih menu
utama jadwal
perjalanan
1.1 Menu utama Jawal tampilkan
perjalanan
1.1.1 Jadwal Kontrol cekJadwal id_pelangg
perjalanan transaksi an
1.1.1.1 Kontrol Catatan cekKetersedia id_pelangg boolean
transaksi jadwal an an
perjalanan
1.1.1.3 Kontrol Catatan getJadwal id_pelangg jadwal
transaksi jadwal an
perjalanan
1.1.1.5 Kontrol jadwal tampilkanJad jadwal
transaksi perjalanan wal
1.1.1.5. Jadwal Pelanggan tampilan
1 perjalaan jadwal
perjalanan
[ILMU SD007]
e Tujuan Parameter
Number
1 Bagian Menu Edit Tampilkan Data Menampilkan
Keuangan laporan Layanan Menu edit
laporan
1.1 Menu Edit Bagian Tampilkan Data Menampilkan
laporan Keuangan Layanan menu edit
laporan
1.2 Menu edit Menu buat Tampilkan Pertanyaan
laporan neraca menu buat
neraca
1.2.1 Menu buat Bagian Menampilkan Data Menampilkan
Neraca Keuangan menu buat layanan menu buat
neraca neraca
1.2.2 Menu buat Buat jurnal Tampilkan Data Menampilkan
neraca penyesuaia menu buat layanan Menu buat
n jurnal jurnal
penyesuaian penyesuaian
1.2.2.1 Buat jurnal Bagian menu buat Data Menampilkan
penyesuaian Keuangan jurnal layanan menu buat
penyesuaian jurnal
penyesuaian
1.2.2.2 Buat Jurnal kontrol Update Jurnal Data Menampilkan
Penyesuaian update layanan menu update
jurnal jurnal
1.2.2.2. Kontrol Bagian Tampilkan Data Menampilkan
1 update jurnal Keuangan Update Jurnal layanan menu update
jurnal
2 Buat Jurnal Menyusun Tampilkan Data Menampilkan
penyesuaian neraca menu layanan menu
jalur menyusun menyusun
neraca jalur neraca jalur
3 Menyusun Menutup Tampilkan Data Menampilkan
neraca jalur Rekening pilihan menu layanan pilihan menu
tutup rekening tutup rekening
3.1 Menutup Bagian Menampilkan Data Menampilkan
Rekening keuangan menu tutup layanan menu tutup
rekening rekening
3.2 Menutup Laporan Tampilkan Data Menampilkan
rekening keuangan laporan layanan laporan
keuangan keuangan
3.2.1 Laporan Bagian Tampilkan Data Menampilkan
Keuangan Keuangan Laporan layanan laporan
keuangan keuangan
5.4 Tugas IV : Pemodelan Class Diagram

Pada tugas sebelumnya telah dibuat sequence diagram untuk studi kasus ini, terdapat method-
method yang sudah dijelaskan sebelumnya. Pada tugas ini buatlah pemetaan class dan
diagram sesuai dengan tabel – tabel berikut.
[Template]
NamaKelas
Sifat
Attribut Tipe data Privat Publi Protecte
e c d
✔
Method para Retur

m n
[FIKH SD001]
Menu
Sifat
e c d
✔
Method para Retur

m n
Pesanan Pelanggan
Sifat
e c d
pesana string ✔
n
nomina double ✔
l
Method param Retu
rn
tambah pesana ✔
() n,statu
s,Nomi
nal
Update status ✔
Status
berikan tiket ✔
Konfirmasi Pembayaran
Sifat
e c d
pesana string ✔
n
nomina double ✔
l
Method param Retu
rn
tambah pesana ✔
() n,statu
s,Nomi
nal
Update status ✔
Status
berikan tiket ✔
adminVerifikasiControl
Sifat
Attribut Tipe data Private Pu Protec
blic ted
buktiPe BLOB ✔
mbayar
an
melaku boolean
kanPerj
alanan
Method param Return
Kirim() bukti(p ✔
embay
aran
rekeningJalanSkuyEntitiy
Sifat
Pr Publi Protecte
Attribut Tipe data iv c d
at
e
Method param Retur
n
cekPe noPemba ✔
mbayar yaran
an
cekNo nominalP ✔
minal embayara
n
[SAD - SD002]
Login
Sifat
e c d
Method param Retu

rn
Login control
Sifat
e c d
userna String ✔
me
Passw String ✔
ord
Method param Retu
rn
isi userna ✔
me,
passwo
rd
Menu
Sifat
e c d
pilihan String ✔
Method param Retu
rn
tampilk ✔
an
isi pilihan ✔
Pesan login gagal

Sifat
e c d
Method param Retu
rn
tampilk ✔
an()
Masukkan kode booking

Attribut Tipe data Sifat
Privat Publi Protecte
e c d
Method param Retu
rn
tampilk ✔
an
Kode booking control

Sifat
e c d
kodebo string ✔
oking
Method param Retu
rn
isi kodebo ✔
oking
Kode booking entity

Sifat
e c d
kodebo String ✔
oking
Method param Retu
rn
cek kodebo ✔
oking
Pesan kode booking salah

Sifat
e c d
Method param Retu
rn
tampilk ✔
an
Fix detail pemasanan

e c d
waku DateTime ✔
tempat String ✔
harga double ✔
durasi String ✔
nama String ✔
alamat String ✔
email String ✔
Method param Retu
rn
tampilk waktu, ✔
an tempat,
harga,
durasi,
nama,
alamat,
email
Isian detail pemesanan

Sifat
e c d
Method param Retu
rn
tampilk ✔
an
Booking control
Sifat
e c d
kodebo String ✔
oking
Method param Retu
rn
buat kodebo ✔
oking
Ketersediaan layanan entity

e c d
waktu DateTime ✔
tempat String ✔
harga double ✔
durasi String ✔
Method param Retu
rn
cek waktu, ✔
tempat,
harga,
durasi
Pesan detail yang diinginkan tidak tersedia

Sifat
e c d
Method param Retu
rn
tampilk ✔
an
Isian form pemesan

Sifat
e c d
Method param Retu
rn
tampilk ✔
an
Data pemesan control

Sifat
e c d
nama String ✔
alamat String ✔
email String ✔
Method param Retu
rn
isi nama, ✔
alamat,
email
Data pemesan entity

Sifat
e c d
nama String ✔
alamat String ✔
email String ✔
Method param Retu
rn
isi nama, ✔
alamat,
email
Cara pembayaran
Sifat
e c d
Method param Retu
rn
tampilk ✔
an
Data pemesan control

Sifat
e c d
nama String ✔
alamat String ✔
email String ✔
Method param Retu
rn
isi nama, ✔
alamat,
email
booking control
e c d
kodebo String ✔
oking
Method param Retu
rn
buat kodebo ✔
oking
Menampilkan kode booking

Sifat
e c d
kodebo String ✔
oking
Method param Retu
rn
tampilk kodebo ✔
an oking
[THR - SD003]
MenuUtama
Sifat
e c d
Method para Retur
m n
TampilanFormulir
Sifat
e c d
Method para Retur

m n
tampilk - - ✔
anPert
anyaan
tampilk String - ✔
anJaw
aban
pop String - ✔
KontrolPertanyaan
Sifat
e c d
id_pela String ✔
nggan
id_peg String ✔
awai
pertany String ✔
aan
jawaba String ✔
n
Method para Retur
m n
setPert String - ✔
anyaan
setJaw String - ✔
aan ,
String
,
String
jawabP String - ✔
ertanyy ,
an String
Notifikasi
Sifat
e c d
Method para Retur

m n
notifika String - ✔
siPerta ,Strin
nyaan g,
String
notifika String - ✔
siJawa ,
ban String
Pelanggan
Sifat
e c d
Method para Retur

m n
simpan String - ✔
Pertan
yaan
simpan String - ✔
Jawab ,
an String
[THR - SD004]
MenuUtama
Sifat
e c d
Method para Retur

m n
TampilanLaporanKeuangan
Sifat
e c d
Method para Retur

m n
tampilk - - ✔
an
tampilk Lapor - ✔
anLapo an
ran
KontrolTransaksi
Sifat
e c d
idPerus String ✔
ahaan
Lapora Laporan ✔
n
Method para Retur
m n
cekLap - - ✔
oranKe
uangan
cetakL - - ✔
aporan
cetakL Lapor - ✔
aporan an
PDF
CatatanPenjualan
Sifat
e c d
Method para Retur

m n
hetLap idPer - ✔
oranKe usaha
uangan an
PencetakPDF
Sifat
e c d
Method para Retur

m n
[THR - SD005]
MenuUtama
Sifat
e c d
Method para Retur

m n
TampilanDaftarPelanggan
Sifat
e c d
✔
Method para Retur
m n
tampilk - - ✔
an
tampilk Pelan - ✔
an ggan[]
TampilanDaftarTiket
Sifat
e c d
Method para Retur

m n
an
KontrolJadwal
Sifat
e c d
Method para Retur

m n
printPel - - ✔
anggan
Penjad
walan
getTike - Tiket[] ✔
t
setTike Tiket[] - ✔
t
cekTike - boole ✔
t an
konfirm - - ✔
asiTiket
TampilanPratinjau
Sifat
e c d
Method para Retur

m n
tampilk Tiket[] - ✔
an
BasisData
Sifat
e c d
Method para Retur

m n
getPela - Pelan ✔
nggan ggan[]
Penjad
walan
getTipe String String ✔
Pemes
anan
getTike String Tiket[] ✔
t
setTike Tiket[] - ✔
t
[THR - SD006]
MenuUtama
Sifat
e c d
Method para Retur

m n
JadwalPerjalanan
Sifat
e c d
Method para Retur

m n
tampila - - ✔
kn
tampilk Jadw - ✔
an al
KontrolTransaksi
Sifat
e c d
Method para Retur

m n
cetakP String - ✔
DF
cetakJ Jadw - ✔
adwal al
PencetakPDF
Sifat
e c d
Method para Retur

m n
CatatanJadwal
Sifat
e c d
Method para Retur

m n
cekJad String boole ✔
wal an
getJad String Jadwa ✔
wal l
PesanError
Sifat
e c d
Method para Retur

m n
anError
[ILMU - SD007]
NamaKelas
Sifat
e c d
✔
Method para Retur

m n
5.5 Tugas V : Pemodelan Data

Tahapan berikutnya adalah membuat pemodelan data untuk kebutuhan implementasi pada
DBMS. Pada class diagram sudah dilakukan analisa atribut yang bisa digunakan sebagai acuan
penyusunan data model.
Lakukan analisis kelas dan sub kelas untuk masing – masing entitas yang terdapat pada
sequence diagram. Identifikasi relasi yang mungkin antar entitas yang telah diidentifikasi
beserta kardinalitas dan modalitas pada relasi tersebut
Analisis Entitas Class

[FIKH SD001]
Berdasarkan kelas yang di gambarkan tersebut detailkan tabel berikut ini dan pastikan bahwa
tipe data yang ditentukan sesuai dengan contoh data yang diberikan pada setiap atribut yang di
uraikan.
[FIKH]
Nama Kelas Atribut Tipe dan Key (Primary, Constraint Contoh
Entitas Panjang foreinkey) data
Data
Akun idPelanggan varchar(5) Primar Key not Null AZ001
Akun nama varchar(1 not Null Fikri
2) Hernanda
Akun alamat varchar not Null Pesona
Pesanan idPelanggan Varchar(5) Foreign Key not Null AZ001
Pesanan JadwalPerjalan Date ForeignKey not Null 2018/05/12
an
Pesanan tiket BLOB tiket
pesawat
tiketPesanan idTiket varchar(5) primary key not null AVKZ
tiketPesanan JadwalPerjalan Date 2018/05/12
an
KonfirmasiPe buktiPembayara BLOB not null
mbayaran n
KonfirmasiPe Waktu Date not null 2018/05/12
mbayaran 12:12:12
KonfirmasiPe noTransaksi Varchar(2 Primary key not null 092131AB
mbayaran 0)
Hubungan Antar Kelas

Nama Kelas I Nama Kelas II Modalitas Kardinalitas Relasi
Akun Pesanan zero zero to many Agregasi
Pesanan TiketPesanan one one to many Agregasi
Pelanggan Akun one one to many Agregasi
pelanggan KonfirmasiPe one one to many asosiasi
mbayaran
[SAD - SD002]
Berdasarkan kelas yang di gambarkan tersebut detailkan tabel berikut ini dan pastikan bahwa
tipe data yang ditentukan sesuai dengan contoh data yang diberikan pada setiap atribut yang di
uraikan.
[SAD]
Data
Akun usename varchar(1 Primary Key not Null irsad21
0)
Akun password varchar(1 Primary Key not Null 123456
0)
Akun nama varchar(3 not Null Muhamma
0) d Irsad
Akun alamat Varchar(5 Foreign Key not Null Jl.
0) sarangan
atas
Akun email Varchar(5 ForeignKey not Null muhamma
0) dirsad@gm
ail.com
CekDetailPe waktu DateTime not null 21.00
mesanan
CekDetailPe tempat varchar(5 not null Jakarta
mesanan 0)
CekDetailPe harga double not null Rp190.000
mesanan
CekDetailPe durasi varchar(1 not null 3 hari
mesanan 5)
CekDetailPe nama varchar(3 not null Muhamma
mesanan 0) d irsad
CekDetailPe alamat Varchar(5 not null Jl. mulu
mesanan 0) jadian kaga
CekDetailPe email varchar(5 not null muhamma
mesanan 0) dirsad@gm
ail.com
PesanLayana waktu DateTime not null 21.00
n
PesanLayana tempat varchar(5 not null Bandung
n 0)
PesanLayana harga double not null Rp250.000
n
PesanLayana durasi varchar(1 not null 27 Jam
n 5)
TiketPesanan kodebooking Varchar(1 Primary Key not null abc123defg
0)

Pelanggan Akun zero one to many Agregasi
Akun CekDetailPe one zero to many Agregasi
mesanan
Akun PesanLayana one zero to many Agregasi
n
PesanLayanan TiketPesanan one one Agregasi
[THR]

Data
Pelanggan idPelanggan varchar(5) Primary key Not Null PR001
nama varchar(2 Thariq Al
55) Astagis
Jadwal idJadwal varchar(1 Primary key Not null JDWL1917
0) 15
idPelanggan varchar(5) Foreign key PR001
Tiket idTiket varchar(1 Primary key not null TKT127361
0) 938
idJadwal varchar(1 Foreign key JDWL1873
0) 91
waktu date 26-08-2018
nomor char(6) CA19A
status varchar(1 Sukses
0)
Transaksi waktu timestamp Primary key not null 26-09-17
s 14:05:12
LaporanKeua transaksi timestamp Foreign key not null 26-09-17
ngan s 14:05:12
ManagerMitr idPerusahaan char(5) Primary key not null BS001
a
Administrator idAdministrator char(5) Primary key not null AD009
nama varchar(5 Thariq
0)
Pertanyaan idPertanyaan varchar(1 Primary key not null PRT18661
0) 8
pertanyaan varchar(2 Bagaimana
55)
jawaban varchar(2 Caranya
55)

Pelanggan Jadwal one zero to many Agregasi
Pelanggan Pertanyaan one zero to many Agregasi
Jadwal Tiket one one to many Agregasi
Transaksi Tiket one zero to many asosiasi
Laporan Transaksi one to many zero to may asosiasi
Keuangan
Manager Mitra Laporan one one asosiasi
Keruangan
Jadwal Administrator one zero to many asosiasi
Analisis Entitas Class

[ILMU - SD007]

Data
BagianKeuan Id_Pegawai Varchar Foreign Key not Null BKEU_08
gan (25)
Nama Varchar(3 Foreign Key not Null Ilham
0) Maulana
Ubaidillah
Alamat Varchar(5 Foreign Key not Null Jl.
0) Cikampek
No. 17A
LaporanKeua Neraca Varchar Primary Key not Null Rp.854.342
ngan (150) .213
JurnalPenyesua MediumB Primary Key not Null
ian LOB
NeracaLajur MediumB Primary Key not Null
LOB
LaporanLaba MediumB Primary Key not Null
LOB
LaporanRugi MediumB Primary Key not Null
LOB
LaporanPeruba MediumB Primary Key not Null
hanModal LOB
ManajerJalan Id_Pegawai Varchar(2 Foreign Key not Null MNG002
Skuy 5)
Nama Varchar(3 Foreign Key not Null Ilham
0) Maulana
Alamat Varchar(5 Foreign Key not Null Jl. Sesama
0)
5.6 Tugas VI : Pembuatan Pseudo-Code

Pada komponen Class diagram terdapat beberapa method yang digunakan, untuk pseudo-code
hanya method yang digunakan pada controller bukan pada bagian user interface.
Pseudo-Code PC001
ID:
Pseudo-Code Mengecek kevalidan Pembayaran
title:
Method Name: cekPembayaran()
Updated:
Input Bukti Pembayaran

Proses if(noPembayaran==exist){
pembayaran = true
}else{
pembayaran = false
return pembayaran
Output Status Pembayaran
Pseudo-Code PC002
ID:
Pseudo-Code Mengecek kesesuaian nominal pembayaran
title:
Method Name: cekNominal()
Updated:
Input Nominal pembayaran

Proses if(nominal == tagihan){
status= confirmed
else{
status = pending
return status
Output Status pemesanan
Pseudo-Code PC0011
ID:
Pseudo-Code Meneruskan bukti pembayaran ke adminverifikasi kontrol
title:
Method Name: kirim()
Updated:
Input BuktiPembayaran
Proses if(BuktiPembayaran == true){
return BuktiPembayaran
}
Output BuktiPembayaran
Pseudo-Code PC003
ID:
Pseudo-Code Update Jurnal
title:
Method Name: UpdateJurnal()
Ubaidillah
Updated:
Input DebitLama, DebitBaru, KreditLama, KreditBaru

Proses Mengupdate JurnalPenyesuaian
Output JurnalPenyesuaian yang terbaru
Pseudo-Code PC004
ID:
Pseudo-Code Mengecek kevalidan Kode booking
title:
Method Name: cek(kodebooking)
Updated:
Input Kode booking

Proses mengecek valid atau tidak kode booking sesuai yang tersimpan di data store
Output Detail pemesanan yang pernah dipesan
Pseudo-Code PC005
ID:
Pseudo-Code Mengecek kevalidan username dan password
title:
Method Name: cek(username, password)
Updated:
Input Username dan password

Proses mengecek valid atau tidak username dan password berdasarkan akun yang ada
Output Menu utama
Pseudo-Code PC006
ID:
Pseudo-Code Mengecek ketersediaan detail pemesanan
title:
Method Name: cek(waktu, tempat, harga, durasi)
Updated:
Input Detail pemesanan

Proses mengecek tersedia atau tidak detail pemesanan yang ingin dipesan user
Output Detail pemesanan tersedia
Pseudo-Code PC007
ID:
Pseudo-Code Membuat kode booking
title:
Method Name: buat(kodebooking)
Updated:
Input Detail pemesan

Proses membuat kode booking pembayaran berdasarkan detail pemesanan dan
pemesan
Output kode booking
Pseudo-Code PC008
ID:
Pseudo-Code Mencetak jadwal ke pencetak jadwal PDF
title:
Method Name: cetakJadwal
Created By: Thariq AL Astagis Last Updated By:
Updated:
Input Jadwal
Proses Tiket[] = Jadwal.getTiket()
for(i=0, i<tiket.length, i++) {
print Tiket[i];
}
Output Tampilan jadwal
Pseudo-Code PC009
ID:
Pseudo-Code Mencetak transaksi yang sesuai dengan manager yang login
title:
Method Name: cetakLaporan
Updated:
Input idPerusahaan
Proses transaksi[] = getLaporan(idPerusahaan)
for(i=0, i<tiket.length, i++) {
pirint transaksi[i];
}
Output Tampilan laporan keuangan
Pseudo-Code PC010
ID:
Pseudo-Code Menyimpan pertanyaan pelanggan
title:
Method Name: setPertanyaan
Updated:
Input idPerlanggan
Proses pertanyaan = pertanyaan
pelanggan = getPelanggan(idPelanggan)
pelanggan.pertanyaan = pertanyaan
Output pertanyaan user disimpan
5.7 Tugas VIII : Sketsa UI

Untuk setiap boundary yang terdapat pada sequence diagram gambarkan UI-nya.
UI-ID: UI001
UI-title: Menu Layanan
UI Function : Input
Updated:
Form Element Fungsi Element

Pesan - Button Digunakan untuk
memesan layanan
suatu rute dan
merubah status pada
pesanan menjadi
booked
options- Select digunakan untuk
mencari lokasi asal
atau tujuan
pemberangkatan
layanan
Cari-Select Digunakan untuk
mencari jadwal
perjalanan
berdasarkan
tanggal ,asal,dan
lokasi tujuan.
UI-ID: UI002
UI-title: Pesanan Pelanggan
UI Function : Input ,output
Updated:

placeholder Untuk Menampilkan
tiket yang sudah
disimpan
Konfirmasi-Button digunakan untuk
memunculkan
halaman konfirmasi
pembayaran untuk
pemasanan yang
sudah berstatus
booked]
UI-ID: UI003
UI-title: Halaman Konfirmasi Pembayaran
UI Function : Input
Updated:

Detail Pemesanan - Digunakan untuk
box menampilkan detail
pemesanan
upload- button Digunakan untuk
mengupload foto
bukti pembayaran
submit-button Digunakan untuk
mengirimkan
finalisasi konfirmasi
pembayaran
UI-ID: UI004
UI-title: Login
UI Function : Input
Updated:

Placeholder Untuk menampilkan
logo
Text Input Tempat user untuk
mengisi username
dan password
Button - Masuk Untuk
mengkonfirmasi isian
dari user
UI-ID: UI005
UI-title: Pesan login gagal
UI Function : Input
Updated:

logo
Text Input Tempat user untuk
mengisi username
dan password
Button - Masuk Untuk
mengkonfirmasi isian
dari user
Text Untuk memperingati
user bahwa isian
salah
UI-ID: UI006
UI-title: Menu Utama
UI Function : Input
Updated:

Search input Untuk mencari
layanan yang
diinginkan
pilihan menu
Banner Untuk menampilkan
promo yang sedang
ada
UI-ID: UI007
UI-title: Masukkan kode booking
UI Function : Input
Updated:

Text input Tempat untuk user
mengisi kode
booking
Button - cari Tombol untuk user
mencari kode
booking
UI-ID: UI008
UI-title: Pesan kode booking salah
UI Function : Input
Updated:

Text input Tempat untuk user
mengisi kode
booking
Button - cari Tombol untuk user
mencari kode
booking
Text Mengingatkan user
bahwa kode booking
salah
UI-ID: UI009
UI-title: Detail pemesanan fix
UI Function : Input
Updated:

Tabs Pilihan user untuk
menampilkan opsi
halaman
Placeholder Menampilkan detail
pemesanan
pengguna
UI-ID: UI0010
UI-title: Isian detail pemesanan
UI Function : Input
Updated:

Submit - Cari Untuk mencari sesuai
detail pemesanan
pemesanan
pengguna
UI-ID: UI0011
UI-title: Pesan detail yang diinginkan tidak tersedia
UI Function : Input
Updated:

detail pemesanan
pemesanan
pengguna
Text - Tidak tersedia Untuk memberitahu
pelanggan bahwa
detail pemesanan
tidak tersedia
UI-ID: UI0012
UI-title: Isian form pemesan
UI Function : Input
Updated:

detail pemesanan
Input text Tempat untuk
pelanggan mengisi
data pemesan
UI-ID: UI0013
UI-title: Cara pembayaran
UI Function : Input
Updated:

Radio Option Tempat pelanggan
untuk memilih cara
pembayaran
Submit - Buat Untuk pelanggan
mensubmit dan
membuat kode
booking
UI-ID: UI0014
UI-title: Tampilkan kode booking
UI Function : Input
Updated:

Text area - kode Untuk menampilkan
booking kode booking untuk
pelanggan
Submit - Menu Untuk mengakhiri
proses pemesanan
dan kembali ke menu

Modul Praktikum RE

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Modul Praktikum RE

Diunggah oleh

Hak Cipta:

Format Tersedia

Modul Praktikum

Analisis dan Desain Sistem Informasi

Dosen Pengampu Kelas [SI-A]

Aryo Pinandito, S.T, M.MT

Fikri Hernanda - NIM. 165150400111043 - FIKH

Qomarul Umam - NIM. 155150400111108

Program Studi Sistem Informasi

Menuliskan Pernyataan Kebutuhan

Tugas I: Skenario User Story

Tugas II: Proses Bisnis

Input Username dan Password

Proses Pencocokan Username dan Password

Output Menampilkan menu utama TravelSkuy

2 Aktivitas Memilih layanan pemesanan

Input Pilihan pemesanan

Proses Memilih jenis pemesanan

Output Hasil pemesanan disimpan oleh sistem

3 Aktivitas Mengisi detail pemesanan

Proses Pelanggan memasukkan filter untuk jadwal pemesanan, Mengecek

Output Menampilkan hasil filter yang dilakukan oleh pelanggan, Menampilkan

4 Aktivitas Mengecek ketersediaan sesuai detail dan layanan

Input Informasi dari pelanggan

Proses Pengecekan ketersediaan oleh sistem

5 Aktivitas Mengirim daftar ketersediaan layanan dan harga

Input Informasi ketersediaan dari sistem

Proses Sistem mengirim informasi ketersediaan layanan dan harga

Output Menampilkan notifikasi berisi informasi ketersediaan layanan dan harga

6 Aktivitas Memilih layanan dan harga sesuai keinginan

Input Jadwal keberangkatan dan harga

Proses Memilih layanan dan harga yang diinginkan

Output Menampilkan proses pemesanan

7 Aktivitas Melakukan pemesanan

Input Informasi konfirmasi pemesanan

Proses Melakukan konfirmasi pada pemesanan

Output Menampilkan pilihan pembayaran

1 Aktivitas Pemesanan Tiket

Input Jadwal layanan , dan Status pembayaran

Proses Validasi pembayaran yang dilakukan oleh sistem, Pelanggan

Output Status Pemesanan

2 Aktivitas Pembaharuan status pemesanan kepada pelanggan

Input Nominal pembayaran , Tanggal pelayanan.

Proses Administrator mevalidasi pemesanan dan pembayaran yang dilakukan

Output Status Pemesanan

1 Aktivitas Metode Pembayaran

Input Pelanggan memilih metode pembayaran

Proses Pelanggan memilih metode pembayaran yang telah disediakan olah

Output Pelanggan melakukan metode pembayaran yang telah dipilih

1 Aktivitas Membayar tiket

Input Tagihan tiket

Proses Membayar melalui prosedur tertentu

Output Bukti pembayaran

Input Bukti pembayaran

Proses Mengkonfirmasi pembayar dan mencatat ke dalam laporan keuangan,

Output Permintaan tiket dan laporan keuangan

3 Aktivitas Memberikan rincian tiket

Aktor Manager Mitra

Input Permintaan tiket

Proses Mendaftarkan permintaan ke dalam perjalanan dan mencatat ke dalam

Output Rincian tiket

4 Aktivitas Menjadwalkan travel antar kota

Input Rincian tiket

Proses Mencatat semua tiket permintaan pelanggan, menyusun perjalanan,

Output Jadwal perjalanan