DOKUMEN PEMBANGUNAN PERANGKAT LUNAK

Pendekatan berorientasi Objek

PEMESANAN TIKET KERETA API ONLINE

untuk:

Masyarakat yang memerlukan tiket Kereta Api

Dipersiapkan oleh:

1201140013 M. Arif Izzudin

1201140163 Farih Jamil Rajabi

1201140353 Akbar Muflih Z

Program Studi Teknik Industri

Fakultas Rekayasa Industri
Telkom University

2017
 Daftar Isi
Bab 1 Pendahuluan...................................................................................................................................................4
1.1 Tujuan Penulisan Dokumen......................................................................................................................4
1.2 Lingkup Masalah......................................................................................................................................4
1.3 Aturan Penomoran....................................................................................................................................4
1.4 Referensi...................................................................................................................................................4
1.5 Deskripsi Umum Dokumen (Ikhtisar)......................................................................................................4
Bagian ini diisi dengan sistematika pembahasan dokumen ini...............................................................................4
2 Bab 2 Kebutuhan Perangkat Lunak..................................................................................................................4
2.1 Deskripsi Umum Sistem...........................................................................................................................5
2.2 Fitur Utama Perangkat Lunak..................................................................................................................5
2.2.1 Kebutuhan Fungsional......................................................................................................................5
2.2.2 Kebutuhan Non Fungsional..............................................................................................................5
2.3 Model Use Case........................................................................................................................................6
2.3.1 Diagram Use Case............................................................................................................................6
2.3.2 Definisi Actor....................................................................................................................................6
2.3.3 Definisi Use Case..............................................................................................................................6
2.3.4 Skenario Use Case............................................................................................................................7
2.4 Spesifikasi Tambahan.............................................................................................................................10
2.5 Glossary...................................................................................................................................................10
3 Model Analisis................................................................................................................................................11
3.1 Realisasi Use Case Tahap Analisis.........................................................................................................11
3.2 Kelas Analisis.........................................................................................................................................13
3.2.1 Tanggung-Jawab dan Atribut..........................................................................................................14
3.2.2 Asosiasi dan Agregasi.....................................................................................................................14
3.2.3 Generalisasi.....................................................................................................................................14
3.2.4 Kebutuhan Khusus..........................................................................................................................14
3.3 Paket Analisis..........................................................................................................................................14
3.3.1 Identifikasi Paket Analisis..............................................................................................................14
3.3.2 Identifikasi Kelas Analisis tiap Paket.............................................................................................15
3.4 Prototipe Antarmuka...............................................................................................................................15
3.5 Deskripsi Arsitektur................................................................................................................................15
3.6 Pedoman Perancangan............................................................................................................................15
4 Model Perancangan........................................................................................................................................16
4.1 Realisasi Use Case Tahap Perancangan.................................................................................................16
4.2 Kelas Perancangan..................................................................................................................................16
4.3 Kelas Perancangan..................................................................................................................................19
4.3.1 Operasi dan Atribut.........................................................................................................................20
4.3.2 Asosiasi dan Agregasi.....................................................................................................................20
4.3.3 Generalisasi.....................................................................................................................................20
4.3.4 Algoritma/Query.............................................................................................................................20
4.3.5 Diagram Statechart.........................................................................................................................21
4.3.6 Kebutuhan Khusus..........................................................................................................................21
4.4 Perancangan Subsistem..........................................................................................................................21
4.4.1 Subsistem Pendukung.....................................................................................................................21
4.4.2 Subsistem Aplikasi..........................................................................................................................21
4.4.3 Identifikasi Kelas Perancangan tiap Subsistem.............................................................................21
4.5 Perancangan Antarmuka........................................................................................................................22
4.6 Coding Standard dan Naming Convention............................................................................................22
4.7 Deployment Diagram..............................................................................................................................22
5 Implementasi...................................................................................................................................................23
5.1 Implementasi Komponen........................................................................................................................23
5.2 Implementasi Subsistem.........................................................................................................................23
5.3 Implementasi Antarmuka.......................................................................................................................23
6 Pengisian Bab VI Pengujian...........................................................................................................................24
6.1 Rencana dan Prosedur Pengujian...........................................................................................................24
6.1.1 Rencana Pengujian..........................................................................................................................24
6.1.2 Prosedur Pengujian.........................................................................................................................24
6.2 Kasus Uji.................................................................................................................................................24
6.2.1 Pengujian Use Case <nama use case>............................................................................................24
6.3 Defect dan Status Perbaikan...................................................................................................................24
6.4 Evaluasi Pengujian..................................................................................................................................25
7 Pengisian Lampiran........................................................................................................................................25

Halaman 2/ dari 25 halaman

Halaman 3/ dari 25 halaman
1 Bab 1 Pendahuluan
1.1 Tujuan Penulisan Dokumen
Dokumen ini berisi Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau
Software Requirement Spesification (SRS) untuk Sistem Pemesanan Tiket Kereta Api
Online. Tujuan dari penulisan dokumen ini adalah untuk memberikan kemudahan bagi
masyarakat agar dapat dengan mudah memesan tiket kereta api secara online yang dapat
diakses dimana saja dan kapan saja dan juga penjelasan mengenai perangkat lunak yang
akan dibangun baik berupa gambaran umum maupun penjelasan detil dan menyeluruh.
Pengguna dari dokumen ini adalah pengembang atau developer perangkat lunak
Sistem Pemesanan Tiket Kereta Api Online dan pengguna (User) atau anggota yang
terlibat dalam sistem ini. Perangkat lunak ini didesain untuk konsumen yang akan
memesan tiket kereta api secara online.

1.2 Lingkup Masalah

Perangkat lunak yang akan dikembangkan adalah perangkat lunak Pemesanan
Tiket Kereta Api Online, yaitu merupakan pernagkat lunak yang digunakan untuk
mempermudah proses administrasi dan penjualan Tiket Kereta Api. Sistem Pemesanan
Tiket Kereta Api Online ini dapat melakukan hal-hal berikut :
a. Fasilitas Login
b. Menampilkan jadwal Kereta Api sesuai dengan waktunya
c. Pelanggan dapat memesan tiket secar online tanpa harus mengantre.
d. Untuk pembayaran dilakukan kapanpun (sesuai tenggat waktu) dan dimanapun.

1.3 Aturan Penomoran

Kami tidak melakukan aturan Penomoran dalam pengembangan perangkat lunak ini.

1.4 Referensi
BPAD Laboratory. (2017). Modul Praktikum. Bandung: BPAD Laboratory.

1.5 Deskripsi Umum Dokumen (Ikhtisar)

Bagian ini diisi dengan sistematika pembahasan dokumen ini.

2 Bab 2 Kebutuhan Perangkat Lunak

2.1 Deskripsi Umum Sistem

Melihat keadaan system pembelian tiket KA saat ini masih banyak mengalami ketidak
majuan dalam hal ini seperti mengantri di stasiun guna mendapatkan tiket dan ini merupakan
cara kuno yang terlalu merepotkan kita sebagai calon penumpang, belum lagi apabila calon

Halaman 4/ dari 25 halaman

penumpang yang tidak memndapatkan tiket harus berhadapan dengan para Calo Tiket yang
semakin merugikan calon penumpang dengan harus membeli tiket dengan harga selangit.
Tujuan pembuatan E Commerce (Penjualan tiket KA online) ini, untuk memudahkan para
calon penumpang agar tidak perlu mengantre lama-lama demi mendapatkan tiket, dan juga
terhindar dari para calo tiket.

2.2 Fitur Utama Perangkat Lunak

Bagian ini diisi dengan fitur utama perangkat lunak, yang terdiri dari kebutuhan fungsional dan
kebutuhan non fungsiona.

2.2.1 Kebutuhan Fungsional

SRS-Id Description
Menampilkan database
member,pemesanan,kereta,jadwal,gerbong,kursi.
Menyimpan data-data yang telah diinputkan user ke dalam
database.
Mencetak laporan harian pemesanan
Mengupdate status ketersediaan tempat duduk
Mengubah data jadwal dan kereta yang disediakan untuk
member

2.2.2 Kebutuhan Non Fungsional

SRS-Id Description
Perangkat lunak ini dilengkapi dengan username dan
password.
Tampilan perangkat lunak ini sangat sederhana dan mudah
dipahami sehingga operator bisa lebih mudah
menggunakannya.
Perangkat lunak ini memakai bahasa indonesia sehingga
operator lebih mudah memahami dan menjalankan perangkat
lunak ini.
Software ini bisa digunakan pada sistem operasi microsoft
windows yaitu XP, Vista, Windows 7,Windows 8 dan windows
10

Halaman 5/ dari 25 halaman

2.3 Model Use Case

2.3.1 Diagram Use Case

manager

melihat laporan

<<include>> melihat daftar <<include>>

melihat jadwal kereta <<include>>
<<include>>
Member <<include>>
<<include>> melihat harga
tiket <<include>>
Login <<include>>

<<include>>
<<include>>
mengecek kode booking
menghapus kereta
<<include>>

menghapus pesanan mengedit

kereta

melakukan konfirmasi
pembayaran menambah kereta <<extend>>

<<extend>>
memesan
<<extend>> menghapus jadwal
menambah jadwal
admin
mengedit jadwal
<<extend>>

mengkonfirmasi permintaan <<include>>

<<extend>>
mengupdate data mengedit data pemesanan

Bagian ini diisi dengan perbaikan diagram use case (lengkapi dengan extend, uses, dan lain-lain
jika perlu) dan uraiannya. Apabila pada fase ini masih ada perbaikan, daftar perubahan harus
dilengkapi.

2.3.2 Definisi Actor

Bagian ini diisi dengan daftar actor dan deskripsi role untuk actor tersebut. Bisa dibuat dalam
bentuk tabel berikut:

No Actor Deskripsi
1 Member Melakukan pemesanan,pembayaran dan melihat jadwal
2 Admin Menambah jadwal,daftar kereta.
3 Manajer Melihat laporan

Bagian ini diisi dengan daftar actor yang telah direvisi. Apabila pada fase ini masih ada
perbaikan, daftar perubahan harus dilengkapi.

2.3.3 Definisi Use Case

Bagian ini diisi dengan daftar use case dan deskripsi singkat mengenai use case tersebut. Bisa
dibuat dalam bentuk tabel berikut:
No Use Case Deskripsi
1 Melihat jadwal Member dapat melihat jadwal kereta yang ada
2 Mengecek kode booking
3 Memesan Member dapat melakukan pemesanan yang diproses admin
4 Mengkonfirmasi Permintaan Admin mengkonfirmasi permintaan member
5 Melihat daftar kereta Member melihat daftar kereta yang ada

Halaman 6/ dari 25 halaman

6 Melihat harga tiket Member melihat dan memilih harga tiket kereta
7 Menambah jadwal Admin menginputkan jadwal kereta
8 Menambah kereta Admin menginput daftar kereta yang akan beroperasi
9 Login Admin, manajer dan member melakukan login
10 Melihat laporan Manajer melihat laporan pemesanan kereta

Bagian ini diisi dengan daftar use case yang telah direvisi. Apabila pada fase ini masih ada
perbaikan, daftar perubahan harus dilengkapi.

2.3.4 Skenario Use Case

Bagian ini diisi dengan skenario (flow of event) untuk beberapa use case utama, yang
menggambarkan urutan interaksi actor dengan use case tersebut, dari awal sampai akhir.

Nama Use Case: login

Skenario:
Aksi Actor Reaksi Sistem
Skenario Normal
1 Memasukkan username dan password
2 Mengecek valid tidaknya data inputan
3
4 Masuk ke aplikasi sistem informasi pemesanan tiket
kereta api
Skenario Alternatif
1 Memasukkan username dan password
2 Mengecek valid tidaknya data inputan
3 Menampilkan pesan login tidak valid
4
Skenario Lain ()

Nama Use Case: Melihat Jadwal

Skenario:
Aksi Actor Reaksi Sistem
Skenario Normal
1.Melihat jadwal keberangkatan kereta
2.Mengecek data jadwal keberangkatan kereta
3
4.Menampilkan data jadwal yang diminta
Skenario Alternatif
1.Melihat jadwal keberangkatan kereta
2.Mengecek data jadwal keberangkatan kereta
3 Memberikan konfirmasi data tidak ada
4
Skenario Lain ()

Nama Use Case: Menambah Jadwal

Skenario:
Aksi Actor Reaksi Sistem
Skenario Normal
1.Admin menekan tombol tambah jadwal di form data
jadwal.
2. Sistem menampilkan form tambah data jadwal
3 Admin memasukkan sejumlah data jadwal
4.Admin menekan tombol simpan
5. Siste menambah data jadwal dan menampilkan
konfirmasi data berhasil disimpan
Skenario Alternatif
1.Admin menekan tombol tambah jadwal di form data

Halaman 7/ dari 25 halaman

 Aksi Actor Reaksi Sistem
jadwal.
2. Sistem menampilkan form tambah data jadwal
3 Admin memasukkan sejumlah data jadwal
4.Admin menekan tombol simpan
5. Sistem menampilkan konfirmasi data gagal
disimpan karena ada kesalahan

Nama Use Case: Mengubah Jadwal

Skenario:
Aksi Actor Reaksi Sistem
Skenario Normal
1.Admin menekan tombol edit jadwal di form data
jadwal.
2. Sistem menampilkan form ubah data jadwal
3 Admin memasukkan sejumlah data jadwal
4.Admin menekan tombol simpan
5. Sistem mengubah data jadwal menampilkan
konfirmasi data berhasil disimpan
Skenario Alternatif
1.Admin menekan tombol tambah jadwal di form data
jadwal.
2. Sistem menampilkan form edit data jadwal
3 Admin memasukkan sejumlah data jadwal
4.Admin menekan tombol simpan
5. Sistem menampilkan konfirmasi data gagal
disimpan karena ada kesalahan

Nama Use Case: Menghapus Jadwal

Skenario:
Aksi Actor Reaksi Sistem
Skenario Normal
1.Admin menekan tombol hapus data jadwal di form
pengolahan data jadwal
2.Sistem menampilkan pesan konfirmasi hapus data
jadwal
3.Admin mengkonfirmasi penghapusan data jadwal
4.Sistem menghapus data jadwal dari database

5.Sistem menampilkan form data jadwal

Nama Use Case: Menambah Kereta

Skenario:
Aksi Actor Reaksi Sistem
Skenario Normal
1.Admin menekan tombol tambah jadwal di form data
Kereta
2. Sistem menampilkan form tambah data kereta
3 Admin memasukkan sejumlah data Kereta
4.Admin menekan tombol simpan
5. Siste menambah data kereta dan menampilkan
konfirmasi data berhasil disimpan
Skenario Alternatif
1.Admin menekan tombol tambah kereta di form data
kereta.
2. Sistem menampilkan form tambah data kereta
3 Admin memasukkan sejumlah data kereta
4.Admin menekan tombol simpan
5. Sistem menampilkan konfirmasi data gagal
disimpan karena ada kesalahan

Nama Use Case: Mengubah Kereta

Halaman 8/ dari 25 halaman

Skenario:
Aksi Actor Reaksi Sistem
Skenario Normal
1.Admin menekan tombol edit keretal di form data
jadwal.
2. Sistem menampilkan form ubah data kereta
3 Admin memasukkan sejumlah data kereta
4.Admin menekan tombol simpan
5. Sistem mengubah data kereta menampilkan
konfirmasi data berhasil disimpan
Skenario Alternatif
1.Admin menekan tombol tambah kereta di form data
jadwal.
2. Sistem menampilkan form edit data kereta
3 Admin memasukkan sejumlah data kereta
4.Admin menekan tombol simpan
5. Sistem menampilkan konfirmasi data gagal
disimpan karena ada kesalahan

Nama Use Case: Menghapus Kereta

Skenario:
Aksi Actor Reaksi Sistem
Skenario Normal
1.Admin menekan tombol hapus data kereta di form
pengolahan data jadwal
2.Sistem menampilkan pesan konfirmasi hapus data
kereta
3.Admin mengkonfirmasi penghapusan data kereta
4.Sistem menghapus data kereta dari database

5.Sistem menampilkan form data kereta

Nama Use Case: Melihat daftar kereta

Skenario:
Aksi Actor Reaksi Sistem
Skenario Normal
1.Member Melihat daftar kereta yang ada
2.Mengecek data daftar kereta
3
4.Menampilkan data kereta yang diminta
Skenario Alternatif
1.Melihat daftar kereta yang ada
2.Mengecek data daftar kereta
3 Memberikan konfirmasi data tidak ada

Nama Use Case: Melihat harga tiket

Skenario:
Aksi Actor Reaksi Sistem
Skenario Normal
1.Member Mengetik data kategori gerbong dan
tujuan
2.Mengecek data daftar harga tiket
3
4.Menampilkan data harga yang diminta
Skenario Alternatif
1. Mengetik data kategori gerbong dan tujuan
2.Mengecek data harga tiket
3 Memberikan konfirmasi data tidak ada

Nama Use Case: Menambah Pemesanan

Skenario:
Aksi Actor Reaksi Sistem
Skenario Normal

Halaman 9/ dari 25 halaman

 Aksi Actor Reaksi Sistem
1.Member mengisi data-data pemesanan
2.Member menekan tombol tambah
3.Sistem menanyakan konfirmasi
4.Member menekan tombol ya
5. sistem menyimpan data pemesanan
Skenario Alternatif
1.Member mengisi data-data pemesanan
2.Member menekan tombol tambah
3.Sistem memberikan pemberitahuan data belum
lengkap

2.4 Spesifikasi Tambahan

Bagian ini diisi dengan informasi tambahan mengenai setiap atau seluruh use case, terutama
mengenai kebutuhan non fungsional. Apabila pada fase ini masih ada perbaikan, daftar
perubahan harus dilengkapi.

2.5 Glossary
Bagian ini diisi dengan daftar istilah yang digunakan, terutama istilah yang spesifik terhadap
domain problem. Apabila pada fase ini masih ada perbaikan, daftar perubahan harus dilengkapi.
- Username : nama user yang digunakan untuk login
- Password : kata sandi user yang digunakan saat login
- Login : istilah dalam form untuk masuk ke sebuah sistem dengan kata
sandi dan nama user
- Logout : istilah dalam form untuk keluar dari sistem

Halaman 10/ dari 25 halaman

3 Model Analisis
3.1 Realisasi Use Case Tahap Analisis
Transaksi stasiun
- i d_transaksi : int - id_stasiun : int
- j enis_pem bayaran : Stri ng - stasiun_asal : Stri ng
- T otal_pem bayaran : int - stasiun_Tujuan : Stri ng
+ Set_no_trans () : void + Set_id_stasiun () : void
+ set_tgl_trans () : void + set_stasiun_asal () : void
+ update () : void + set_stasiun_tujuan () : void
+ delete () : void + update () : void
+ search () : void + delete () : void
+ get_no_trans () : void + search () : void
+ get_tgl_trans () : void + get_id_stasi un () : void
+ get_stasiun_asal () : void
1 + get_stasiun_tuj uan () : void

0..*
m ember
1..* 0..1
- i d_m ember : Stri ng
- Nam a_mem ber : Stri ng
- alam at_member : Stri ng Pem esanan Kereta
- No_telp_member : int - i d_pemesanan : int - id_kereta : int
- Password : Stri ng - T gl_pesan : Date - Nama_kereta : String
+ Set_ID_member () : void - Jumlah T iket : int - Jumlah_gerbong : String
1
+ set_nam a_m ember () : void - T otal_pem bayaran : int
1..* + set_id_kereta () : void
+ set_alamat_member () : void + set_no_pesan () : void + set_nam a_kereta () : void
1
+ update () : void 1 + set_tgl_pesan () : void + set_jum lah_gerbong () : void
1
+ delete () : void + set_nama_pem esan () : void + update () : void
+ displ ay () : void + update () : void + delete () : void
+ get_id_m em ber () : void + search () : void + search () : void
+ get_nam a_member () : void + get_no_pesan () : void + get_id_kereta () : void
+ get_alam at_mem ber () : void + get_tgl_pesan () : void + get_nama_kereta () : void
+ get_nama_pemesan () : void + get_jumlah_gerbong () : void

1..*
1

1
1..*
1..*
Penum pang
Jadwal - i d_penum pang : int Gerbong
- j am _datang : int - j am_berangkat : int
- Nam a_penumpang : Stri ng - i d_gerbong : int
- j am _berangkat : int
- kategori : Stri ng - j eni s_gerbong : String
- tanggal_keberangkatan : Date
- harga : int
+ Set_jam_datang () : void + set_id_penumpang () : void - j um lah_kursi : int
+ set_tanggal_keberangkatan () : void + set_jam_berangkat () : void
+ set_id_gerbong () : void
+ set_j am_berangkat () : void + set_nama_penumpang () : void
+ set_jenis_gerbong () : void
+ update () : void + set_kategori () : void
+ update () : void + set_harga () : void
+ delete () : void
+ delete () : void + set_jumlah_kursi () : void
+ search () : void
+ search () : void + update () : void
+ get_jam_datang () : void
+ Get_id_penum pang () : void + delete () : void
+ get_tanggal_keberangkatan () : void
+ Get_jam_berangkat () : void + search () : void
+ get_jam_berangkat () : void
+ get_nama_penumpang () : void + get_i d_gerbong () : void
+ get_j enis_gerbong () : void
+ get_kategori () : void
+ get_harga () : void
+ Operation_12 () : void
+ get_j umlah_kursi () : void

Halaman 11/ dari 25 halaman

 SequencePemesanan

main:main p:pesan j:jadwal k:kereta

Customer
1:set_no_pesan()
1.1:get_no_pesan():void

2:get_no_jadwal():void

3:get_tgl():void

4:get_hari():void

5:get_jam_brgkt():void

6:set_nama_kereta():void

7:set_no_kursi():void

8:update()

SequencePembayaran

main:main k : pesan b : bayar C ; Customer

Customer

1: search() :void

2:get_no_pesan() : void

3: validation()

4:set_nama_cust()

5:set_jumlah():void

Halaman 12/ dari 25 halaman

6:cetakKwitansi()
3.2 Kelas Analisis
Bagian ini diisi dengan daftar kelas analisis dalam tabel berikut:

No Nama Kelas Jenis

1 Member enitity
2 Jadwal enitity
3 Penumpang enitity
4 Pemesanan entity
5 Stasiun entity
6 Gerbong enitity
7 Kereta entity
8 Transaksi Entity

Untuk setiap kelas analisis, lakukan:

identifikasi tanggung-jawab (responsibility)

identifikasi atribut

identifikasi asosiasi dan agregasi antar kelas

identifikasi generalisasi

identifikasi kebutuhan khusus untuk realisasi kelas analisis

3.2.1 Tanggung-Jawab dan Atribut

Nama Kelas Daftar Tanggung-Jawab Daftar Atribut

Member 1.Tambah Member 1.Tambah Button
2.Ubah Member 2.Edit Button
3.Hapus Member 3.Delete Button
Pemesanan 1.Tambah Pemesanan 1.Tambah Button
2.Ubah Pemesanan 2.Edit Button
3.Hapus Pemesanan 3.Delete Button
Jadwal 1.Tambah Jadwal 1.Tambah Button
2.Ubah Jadwal 2.Edit Button
3.Hapus Jadwal 3.Delete Button
Kereta 1.Tambah Kereta 1.Tambah Button
2.Ubah Kereta 2.Edit Button
3.Hapus Kereta 3.Delete Button
Transaksi 1.Tambah Transaksi 1.Tambah Button
2.Ubah Transaksi 2.Edit Button
3.Hapus Transaksi 3.Delete Button
Gerbong 1.Tambah Gerbong 1.Tambah Button
2.Ubah Gerbong 2.Edit Button
3.Hapus Gerbong 3.Delete Button
Penumpang 1.Tambah Penumpang 1.Tambah Button
2.Ubah Penumpang 2.Edit Button
3.Hapus Penumpang 3.Delete Button

3.2.2 Asosiasi dan Agregasi

Bagian ini hanya diisi jika ada.

Halaman 13/ dari 25 halaman

3.2.3 Generalisasi
Bagian ini hanya diisi jika ada.

3.2.4 Kebutuhan Khusus

Bagian ini hanya diisi jika ada.

3.3 Paket Analisis

3.3.1 Identifikasi Paket Analisis

Bagian ini diisi dengan daftar paket analisis dengan mengacu pada diagram use case. Satu atau
lebih use case dapat digabung kedalam satu paket.
Contoh:
N Nama Paket Use Case Terkait Keterangan
o
1. Paket Pemesanan 1.Memesan

3.3.2 Identifikasi Kelas Analisis tiap Paket

Bagian ini diisi dengan hasil identifikasi kelas analisis untuk setiap paket analisis dengan
mengacu pada skenario setiap use case.

N Nama Paket Nama Kelas Analisis Jenis Kelas

o (Boundary, Control, Entity)
1 Paket Pendaftaran Member Enitity
2 Paket Pemesanan Pemesanan Entity

3.4 Prototipe Antarmuka

Bagian ini diisi dengan perbaikan prototipe antarmuka perangkat lunak dan penjelasan singkat
untuk pemakaiannya. Lengkapi daftar perubahan jika terjadi perubahan.

3.5 Deskripsi Arsitektur

Bagian ini diisi dengan gambaran umum arsitektur perangkat lunak. Dengan demikian, dapat
diketahui pula batasan implementasi dari perangkat lunak yang akan dikembangkan.
Pada sistem informasi reservasi kereta ini semua data inputan dari user akan disimpan dalam
database, kecuali case untuk melihat laporan pemesanan

Untuk database, sistem ini menggunakan MySQL sebagai servernya. Sistem informasi
perpustakaan ini tedapat 3 pemakai yaitu member, admin dan manajer.

3.6 Pedoman Perancangan

Bagian ini diisi dengan pedoman perancangan yang perlu dituliskan.

Halaman 14/ dari 25 halaman

Halaman 15/ dari 25 halaman
4 Model Perancangan
4.1 Realisasi Use Case Tahap Perancangan
Bagian ini diisi dengan diagram kelas untuk setiap use case. Selanjutnya, untuk setiap use case
dibuat sequence diagram yang menggambarkan interaksi setiap objek dari kelas perancangan
yang terlibat di dalam use case tersebut. Sequence diagram perlu dibuat ulang apabila ada
perubahan yang cukup besar dari diagram kelas analisis menjadi diagram kelas perancangan.
Lengkapi daftar perubahan.

4.2 Kelas Perancangan

Bagian ini diisi dengan daftar kelas perancangan dalam tabel berikut:

No Nama Kelas Perancangan Nama Kelas Analisis (jika ada)

Untuk setiap kelas, lakukan:

identifikasi operasi (mengacu pada tanggung-jawab kelas), termasuk visibility-nya

identifikasi atribut, termasuk visibility-nya

identifikasi asosiasi dan agregasi antar kelas

identifikasi generalisasi

untuk operasi yang kompleks, sertakan algoritmanya

identifikasi kebutuhan khusus untuk implementasi k

Halaman 16/ dari 25 halaman

 SequencePembayaran

main:main k : pesan b : bayar C ; Customer

Customer
1: search() :void

2:get_no_pesan() : void

3: validation()

4:set_nama_cust()

5:set_jumlah():void

6:cetakKwitansi()

Halaman 17/ dari 25 halaman

 SequencePemesanan

main:main p:pesan j:jadwal k:kereta

Customer
1:set_no_pesan()
1.1:get_no_pesan():void

2:get_no_jadwal():void

3:get_tgl():void

4:get_hari():void

5:get_jam_brgkt():void

6:set_nama_kereta():void

7:set_no_kursi():void

8:update()

Halaman 18/ dari 25 halaman

 Transaksi stasiun
- id_transaksi : int - id_stasiun : int
- jenis_pembayaran : String - stasiun_asal : String
- Total_pembayaran : int - stasiun_Tujuan : String
+ Set_no_trans () : void + Set_id_stasiun () : void
+ set_tgl_trans () : void + set_stasiun_asal () : void
+ update () : void + set_stasiun_tujuan () : void
+ delete () : void + update () : void
+ search () : void + delete () : void
+ get_no_trans () : void + search () : void
+ get_tgl_trans () : void + get_id_stasiun () : void
+ get_stasiun_asal () : void
1 + get_stasiun_tujuan () : void

0..*
member
1..* 0..1
- id_member : String
- Nama_member : String
- alamat_member : String Pemesanan Kereta
- No_telp_member : int - id_pemesanan : int - id_kereta : int
- Password : String - Tgl_pesan : Date - Nama_kereta : String
+ Set_ID_member () : void - Jumlah Tiket : int - Jumlah_gerbong : String
1
+ set_nama_member () : void - Total_pembayaran : int
1..* + set_id_kereta () : void
+ set_alamat_member () : void + set_no_pesan () : void + set_nama_kereta () : void
1
+ update () : void 1 + set_tgl_pesan () : void + set_jumlah_gerbong () : void
1
+ delete () : void + set_nama_pemesan () : void + update () : void
+ display () : void + update () : void + delete () : void
+ get_id_member () : void + search () : void + search () : void
+ get_nama_member () : void + get_no_pesan () : void + get_id_kereta () : void
+ get_alamat_member () : void + get_tgl_pesan () : void + get_nama_kereta () : void
+ get_nama_pemesan () : void + get_jumlah_gerbong () : void

1..* 1

1
1..*
1..*
Penumpang
Jadwal - id_penumpang : int Gerbong
- jam_datang : int - jam_berangkat : int
- Nama_penumpang : String - id_gerbong : int
- jam_berangkat : int
- kategori : String - jenis_gerbong : String
- tanggal_keberangkatan : Date
- harga : int
+ Set_jam_datang () : void + set_id_penumpang () : void - jumlah_kursi : int
+ set_tanggal_keberangkatan () : void + set_jam_berangkat () : void
+ set_id_gerbong () : void
+ set_jam_berangkat () : void + set_nama_penumpang () : void
+ set_kategori () : void + set_jenis_gerbong () : void
+ update () : void
+ update () : void + set_harga () : void
+ delete () : void
+ delete () : void + set_jumlah_kursi () : void
+ search () : void
+ search () : void + update () : void
+ get_jam_datang () : void
+ delete () : void
+ get_tanggal_keberangkatan () : void + Get_id_penumpang () : void
+ search () : void
+ get_jam_berangkat () : void + Get_jam_berangkat () : void
+ get_id_gerbong () : void
+ get_nama_penumpang () : void
+ get_kategori () : void + get_jenis_gerbong () : void
+ Operation_12 () : void + get_harga () : void
+ get_jumlah_kursi () : void

4.3 Kelas Perancangan

Bagian ini diisi dengan daftar kelas perancangan dalam tabel berikut:
No Nama Kelas Jenis
1 member enitity
2 jadwal enitity
3 Penumpang enitity
4 Pemesanan entity
5 stasiun entity
6 Gerbong enitity
7 Kereta entity
8 Transaksi Entity

Untuk setiap kelas, lakukan:

identifikasi operasi (mengacu pada tanggung-jawab kelas), termasuk visibility-nya

identifikasi atribut, termasuk visibility-nya

identifikasi asosiasi dan agregasi antar kelas

identifikasi generalisasi

Halaman 19/ dari 25 halaman

 untuk operasi yang kompleks, sertakan algoritmanya

identifikasi kebutuhan khusus untuk implementasi kelas.

4.3.1 Operasi dan Atribut

Bagian ini diisi dengan daftar operasi dan atribut Buat untuk setiap kelas.

Nama Kelas: ..

Nama Operasi Visibility Keterangan

(private, public)
Diisi dengan signature operasi

Nama Atribut Visibility Tipe

(private, public)
Diisi dengan nama atribut Tuliskan tipenya sesuai dengan
yang dikenal pada bahasa
pemrograman yang digunakan

4.3.2 Asosiasi dan Agregasi

Bagian ini hanya diisi jika ada.

4.3.3 Generalisasi
Bagian ini hanya diisi jika ada.

4.3.4 Algoritma/Query
Bagian ini hanya diisi untuk kerangka algoritma untuk proses-proses yang dianggap cukup
penting. Implementasi skeleton code juga sudah dapat dilakukan untuk kelas-kelas yang
terdefinisi pada bahasa pemrograman tertentu
Contoh:
Nama Kelas :
Nama Operasi :
Algoritma : (Algo-xxx)

{Jika mengacu query tertentu, lengkapi tabel query di bawah}

Query :
No Query Query Keterangan
Q-xxx Tuliskan fungsi dari querynya

4.3.5 Diagram Statechart

Bagian ini hanya diisi jika ada kelas yang kompleks. Perubahan status kelas tersebut harus
digambarkan dalam bentuk diagram statechart.
Halaman 20/ dari 25 halaman
4.3.6 Kebutuhan Khusus
Bagian ini hanya diisi jika ada.

4.4 Perancangan Subsistem

Bagian ini diisi dengan gambar subsistem pendukung dan subsistem aplikasi dalam bentuk
lapisan aplikasi (application layer) serta gambar diagram package yang menggambarkan
ketergantungan antar subsistem (berbeda dengan diagram package analisis yang hanya berisi
paket analisis saja, tanpa subsistem pendukung).

4.4.1 Subsistem Pendukung

Identifikasi subsistem yang akan digunakan untuk PL ini, misalnya:

aplikasi lain yang akan dimanfaatkan

middleware dan software-system yang akan digunakan

Bagian ini diisi dengan daftar subsistem pendukung dan alokasinya pada node yang telah
teridentifikasi. Mis. dengan melengkapi tabel berikut:
No Subsistem Pendukung Alokasi Node

4.4.2 Subsistem Aplikasi

Bagian ini diisi dengan hasil identifikasi subsistem yang bersifat application-specific, dengan
mengacu pada hasil identifikasi paket analisis dan diagram paket, termasuk apabila ada
subsistem yang akan di-reuse (dari yang sudah ada sebelumnya). Sertakan pula alokasi
subsistem tersebut pada node yang telah teridentifikasi. Boleh dibuat dalam bentuk tabel seperti
berikut:

N Nama Subsistem Paket Analisis terkait (jika ada) Alokasi Node

o
1. Subsistem xxx

4.4.3 Identifikasi Kelas Perancangan tiap Subsistem

Bagian ini diisi dengan identifikasi kelas perancangan untuk setiap subsistem di atas, dengan
mengacu pada kelas analisis.
Contoh:
N Nama Subsistem Nama Kelas Perancangan Nama Kelas Analisis (jika ada)
o
1 Subsistem xxx 1.
2.
3.

4.5 Perancangan Antarmuka

Bagian ini diisi dengan hasil identifikasi rancangan antarmuka aplikasi disini. Apabila tidak ada
perubahan dari prototipe antarmuka di bab sebelumnya, cukup diacu nomornya saja. Misalnya
dengan melengkapi tabel berikut:
Halaman 21/ dari 25 halaman
 No Use Case Antarmuka Nama Kelas
1 {diisi dengan nama use case yang {disi dengan no. layar {disi dengan nama
langsung berhubungan dengan actor, atau no. gambar kelas untuk
sehingga perlu dibuat antarmukanya} rancangan antarmuka} implementasi
antarmuka}

Selanjutnya, untuk setiap antarmuka/layar, tuliskan spesifikasi detilnya, misalnya seperti di

bawah ini:

Antarmuka : {diisi dengan no. layar atau no gambar rancangan antarmuka}

Id_Objek Jenis Nama Keterangan

Diisi dengan Diisi dengan penjelasan reaksi sistem, misalnya
string yg tampil membuka layar apa, link kemana. Jika
pd layar menyangkut suatu kode yang cukup rumit, acu
algoritma yang telah diuraikan di atas.
Button1 Button OK Jika diklik, akan mengaktifkan Proses AlgoXXX.
RTF1 RTF Box Isi Teks yang disimpan pada File xxx
DB1 Data Diasosiasikan ke QueryXYZ dengan mengacu
control query uang telah diuraikan di atas.

Jika objek dikaitkan ke File lain (misalnya file gambar, file teks), berikan nama file terkait dan deskripsi
ringkas dalam kolom keterangan

4.6 Coding Standard dan Naming Convention

Bagian ini diisi dengan versi final dari coding standard dan naming convention. Lengkapi
daftar perubahan jika terjadi perbaikan.

4.7 Deployment Diagram

Bagian ini diisi dengan deployment diagram versi final. Lengkapi daftar perubahan jika terjadi
perbaikan.

Halaman 22/ dari 25 halaman

5 Implementasi
Bagian ini diisi dengan informasi tentang elemen dari perangkat lunak yang dikembangkan
(executable files, configuration files, data files, dsb) serta perubahannya.

5.1 Implementasi Komponen

Bagian ini diisi dengan daftar kelas yang telah diimplementasikan. Misalnya dalam bentuk tabel
berikut:
No Nama Kelas Nama File Fisik Nama File Executable
Mis. Account Mis. Account.java Mis. Account.class

5.2 Implementasi Subsistem

Bagian ini diisi dengan daftar subsistem yang telah diimplementasikan. Misalnya dalam bentuk
tabel berikut:
No Nama Subsistem Nama File Fisik Nama Kelas
Subsistem xxxx 1 1
2 2

5.3 Implementasi Antarmuka

Bagian ini diisi dengan daftar implementasi antarmuka. Misalnya dalam bentuk tabel berikut:
No Antarmuka Nama File Fisik Nama File Executable

Halaman 23/ dari 25 halaman

6 Pengisian Bab VI Pengujian

6.1 Rencana dan Prosedur Pengujian

6.1.1 Rencana Pengujian

Bagian ini diisi dengan rencana pengujian, misalnya dalam bentuk tabel berikut:
No Use Case Pengujian Jenis Pengujian Identifikasi
1 xxx 1. Skenario normal 1. Black box dan White Box U-1-xxx
2. Skenario xxx (acu 2. Black Box U-1-xxx
no.skenario) 3. U-1-xxx
3. Skenario yyy
U-2-xxx
Bagian ini diisi dengan tabel rencana pengujian versi final. Lengkapi daftar perubahan jika ada
perbaikan.

6.1.2 Prosedur Pengujian

Bagian ini diisi dengan prosedur pengujian, misalnya persiapan pengujian, urutan pengujian
yang harus dilakukan, dll

6.2 Kasus Uji

Bagian ini diisi dengan kasus uji untuk setiap use case dalam subbab. Contohnya adalah sebagai
berikut:

6.2.1 Pengujian Use Case <nama use case>

Identifikasi Deskripsi Prosedur Pengujian Masukan Keluaran yang Kriteria Hasil yang Kesimpulan
Diharapkan Evaluasi Didapat
Hasil
U-1-01 Pengujian hasil o Buka Kode 01<tgl_lahir>001 01<tgl_ 01<tgl_ ditolak
pemasukan data File data modus 01<tgl_lahir>002 lahir> lahir><no_
pelanggan oleh pelanggan pemasukan 01<tgl_lahir>003 <nomor loncat
operator o Cari operator dst terurut>
rekord dengan (01)
U-1-02 Pengujian hasil data modus Kode 02<tgl_lahir>001 02<tgl_ 02<tgl_ diterima
pemasukan data pemasukan modus 02<tgl_lahir>002 lahir> lahir><no_
pelanggan oleh yang diinginkan pemasukan 02<tgl_lahir>003 <nomor terurut>
pelanggan o Lihat on-line dst terurut>
secara on-line tanggal lahir (02)
pelanggan
o Lihat
kode pelanggan
o Banding
kan dengan
rumus
pembangkitan
kode pelanggan

Bagian ini diisi dengan kasus uji versi final untuk seluruh use case. Lengkapi daftar perubahan
jika ada perbaikan.

6.3 Defect dan Status Perbaikan

Bagian ini diisi dengan defect yang ditemukan setelah melakukan pengujian dan status
perbaikannya

Halaman 24/ dari 25 halaman

6.4 Evaluasi Pengujian
Bagian ini diisi dengan uraian evaluasi hasil pengujian.

7 Pengisian Lampiran
Bagian lampiran diisi dengan daftar resiko, user manual dan training material dibuat pada
dokumen terpisah. Lampirkan pula hasil pertemuan dengan user, maupun hasil review.

Halaman 25/ dari 25 halaman