BAB III ANALISIS DAN PERANCANGAN

Transkripsi

1 BAB III ANALISIS DAN PERANCANGAN Pada bab ini penulis menganalisa apa apa saja yang di butuhkan untuk membuat sebuah aplikasi pemesanan tiket kereta api. Selesai menganalisa penulis akan membuat perancangan untuk membangun sebuah aplikasi pemesanan tiket agar bisa di gunakan oleh pengguna. 3.1 Analisis Sistem Aplikasi pemesanan tiket kereta api dalam pemrosesannya diperuntukan untuk konsumen yang akan membeli tiket jarak jauh melalui stasiun regional. Aplikasi ini bersifat desktop base karena melalui peng install-an pada personal computer (PC), namun dalam pengaksesan yang berhubungan dengan menyimpan, menghapus, mengambil dan mengedit data termasuk memesan tiket kereta api, dilakukan secara on line dikarenakan tempat penyimpanan data ditempatkan berbeda dengan aplikasi sehingga untuk mengaksesnya dilakukan lewat jaringan atau dengan kata lain cara ini dinamakan database terpusat. Di sini penulis mengambil sample stasiun, stasiun regional dan stasiun pusat. Stasiun regionalnya adalah stasiun Sudimara Tangerang Selatan dan stasiun pusatnya adalah stasiun Gambir Jakarta. Konsumen dapat memesan tiket yang keberangkatannya berawal dari stasiun gambir melalui stasiun sudimara. Hal ini bertujuan untuk mengurangi antrean pada stasiun gambir dan untuk mempermudah masyarakat melakukan pemesanan tiket kereta api. 3.2 Analisis Perangkat Untuk menunjang pembuatan aplikasi ini, penulis membutuhkan perangkat keras dan lunak di antaranya: 1. Perangkat Lunak a. Bahasa pemrograman Microsoft Visual Basic b. SQL Server Management Studio Express 2005 sebagai database.

2 c. LogMeIn Hamachi VPN Client untuk berkomunikasi antar Komputer. 2. Perangkat Keras a. Dua laptop sebagai client dan server. b. Dua modem untuk koneksi ke jaringan. 3.3 Perancangan Sistem Pada tahap ini penulis merancang suatu sistem yang berisi langkah langkah operasi dalam proses pengolahan data. Adapun dalam langkah tersebut penulis merancang sistem berupa diagram alur, dilanjutkan dengan perancangan dan program Perancangan Use case diagram Use Case diagram adalah gambaran dari beberapa aktor yang bereraksi dengan sistem untuk mendeskripsikan suatu sistem yang akan dibangun. Garmbar 3.2 menjelaskan tentang alur kerja dari sistem. Gambar 3.1 Use case diagram dari sistem pemesanan tiket kereta api

3 Ulasan dari gambar 3.1 akan dijelaskan pada tabel 3.1 dan 3.2 Tabel 3.1 use case diagram admin Name Actor Description Scenario pre condition Post condition Menu Admin Admin Admin mengelola data petugas, kereta api, rute dan mengelola database 1. Admin memasukan login berupa user name dan password 2. Admin mengelola data petugas untuk pengaksesan aplikasi. 3. Admin mengelola data kereta api untuk informasi jadwal dan identitas kereta api. 4. Admin mengelola database untuk keperluan pengoptimalan akses. 5. Admin mengelola rute kereta api sebagai informasi rute pemberhentian kereta api. Sistem akan menampilkan data yang akan dikelola dengan login terlebih dahulu Data yang telah dimanipulasi akan tersimpan dalam database Tabel 3.2 use case diagram operator Name Actor Description Scenario Menu operator operator operator dapat melakukan reservasi tiket kereta api berdasarkan permaan penumpang 1. Pengguna mengaksesn menu reservasi tiket 2. Mengisikan data penumpang 3. Memilih tujuan dan tanggal keberangkatan 4. Memilih nomor tempat duduk yang masih kosong.

4 pre condition Post condition 5. Dan mencetak struk tiket Sistem akan menampilkan menu untuk diisi data keberangkatan penumpang Sistem akan mencetak struk untuk penumpang Tabel 3.3 use case diagram user Name Actor Description Scenario pre condition Post condition Menu user User User bertugas memvalidasi tiket penumpang sebelum memasuki area peron 1. Mengecek keabsahan tiket berdasarkan identitas penumpang sebelum memasuki area peron. 2. Akan terjadi kondisi pada sistem bila tiket tersebut sudah pernah dipakai maka tiket tersebut tidak berlaku lagi jika belum dipakai maka ke tahap selanjutnya. 3. Mengecek apakah nomor identitas penumpang sesuai dengan yang ada pada sistem jika sesuai maka penumpang dipersilahkan masuk jika tidak maka penumpang dilarang masuk. Sistem akan menampilkan menu validasi tiket untuk di cek keabsahan penumpang. Penumpang boleh menaiki kereta.

5 Tabel 3.4 Use case diagram penumpang Name Actor Description Scenario pre condition Post condition Calon penumpang Penumpang Penumpang dapat memesan tiket kereta api. 1. Penumpang datang ke loket pemesanan tiket 2. Memberikan informasi berupa identitas penumpang dan tujuan keberangkatan 3. Menyetujui pembayaran 4. Mendapatkan bukti struk Penumpang datang ke loket Penumpang mendapatkan struk tiket Perancangan Activity Diagram Activity diagram menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi. Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dan sebagian besar transisi di-trigger oleh selesainya state sebelumnya (ernal processing). Pada bahasan kali ini penulis akan menerangkan beberapa aktifitas aktor dalam bentuk activity diagram. Adapun aktor tersebut antara lain admin, operator, user dan penumpang masing masing memiliki peran dan maksud tertentu. Untuk lebih jelasnya perhatikan gambar 3.2, 3.3 dan 3.4

6 Gambar 3.2 activity diagram admin Penjelasan diatas menggambarkan admin memulai dengan membuka aplikasi kemudian sistem menampilkan menu login untuk selanjutnya di isi oleh admin berupa user name dan password. Sistem akan mengecek apakah pengguna yang akan mengakses aplikasi ini adalah admin, jika yam aka sistem menampilkan menu dan jika tidak kembali ke menu login. Didalam action state mengelola data admin, admin akan diberi pilihan proses menyimpan, meng update dan menghapus data.

7 Gambar 3.3 activity diagram operator Penjelasan tentang gambar 3.3 pada halaman sebelumnya. Aktifitas ini dimulai pada saat calon penumpang membeli tiket di loket yang dilayani oleh petugas. Petugas membuka aplikasi dan menampilkan menu reservasi tiket pada sistem, diteruskan dengan menanyakan identitas kepada penumpang dan informasi tujuan keberangkatannya. Penumpang memberikan informasi yang dima oleh petugas selanjutnya petugas mengisi identitas penumpang dan memilih tujuan serta tanggal keberangkatan kepada sistem. Sistem menampilkan informasi yang telah diisi oleh petugas kemudian mengecek apakah kursi dari kereta dengan tujuan yang diinginkan masih ada yang kosong atau tidak. Jika ya maka sistem menampilkan denah nomor tempat duduk untuk dilanjutkan memilih kursi yang di inginkan, jika tidak sistem akan mengembalikan urutan sebelumnya yaitu memilih kembali tujuan. Setelah memilih kursi, petugas mengkonfirmasi pembayaran tiket kepada penumpang dan penumpang akan mendapat pilihan jika melanjutkan pemesanan maka petugas akan menyimpan dan mencetak struk tiket ke sistem dan jika batal maka proses selesai.

8 Sistem mencetak bukti fisik berupa struk dan petugas mengecap struk tersebut untuk diserahkan kepada penumpang sebagai bukti bahwa penumpang tersebut telah memesan tiket kereta api dengan sah. Gambar 3.4 activity diagram user Pada gambar 3.3 menjelaskan aktifitas user sebagai petugas pemvalidasian tiket. Diawali dengan calon penumpang yang menuju tempat pemeriksaan tiket dan petugas akan mema identitas dan tiket untuk diperiksa apakah cocok atau tidak. Petugas akan mengecek ke sistem agar di cek apakah tiket masih berlaku dan tiket sesuai dengan identitas penumpang. Pengecekan pertama akan mengecek masa berlaku tiket jika berlaku maka kepengecekan selanjutnya yaitu kecocokan tiket dengan identitas penumpang dan jika tidak berlaku maka proses selesai. Pada decision node cek kecocokan tiket dengan identitas akan terjadi dua masalah, masalah pertama adalah cocok berarti petugas dapat mengecap tiket dan memberikan validasi tersebut ke penumpang untuk ke area peron. Masalah kedua jika tidak cocok maka akan muncul pesan error dan proses berhasil.

9 3.4 Perancangan database Perancangan database berguna untuk memberikan informasi yang dibutuhkan dari penguna. Untuk memenuhi kebutuhan tersebut perancangan database harus dilakukan dengan baik agar dalam pemrosesannya menjadi optimal. Pada proses ini penulis mengumpulkan data berupa atribut atribut apa saja yang di butuhkan. Setelah mengetahui atribut atribut apa saja yang akan di gunakan, langkah selanjutnya adalah mengelompokan atribut atribut tersebut menjadi beberapa entitas hal ini bertujuan agar setiap entitas menampung informasi informasi tertentu untuk memberikan informasi yang di butuhkan pengguna Perancangan entity relationship diagram Dalam tahap pembuatan database diperlukan metode pe relasian antar tabel atau yang lebih dikenal sebagai ERD (entity relationship di agram). ERD adalah adalah suatu penyajian data dengan menggunakan entity dan relationship. Berikut penulis menyajikan ERD pada gambar 3.5 Gambar 3.5 ERD

10 Gambar 3.5 menjelaskan terjadi hubungan antar tabel, untuk lebih jelasnya penulis akan memberikan penjelasan sebagai berikut: Entitas Petugas mempunyai relasi dengan entitas Stasiun. IdStasiun pada entitas Petugas sebagai foreign key sedangkan IdStasiun pada entitas StasiunRegional sebagai primary key. Entitas transaksi memilki relasi dengan entitas rute. Dimana IdRute pada entitas rute sebagai primary key dan IdRute pada entitas transaksi sebagai foreign key. Entitas rute mempunyai relasi dengan entitas kereta. Idkereta pada entitas rute berperan sebagai foreign key dan IdKereta pada entitas kereta sebagai primary key. Entitas transaksi dengan entitas penumpang memiliki relasi. idtiket pada entitas transaksi sebagai primary key dan idtiket pada entitas penumpang sebagai foreign key. Entitas transaksi memiliki relasi dengan entitas petugas. Dimana IdPetugas pada entitas transaksi sebagai foreign key dan IdPetugas pada entitas petugas sebagai primary key Normalisasi database Tahap berikutnya dalam merancang database adalah tahap normalisasi, tahap normalisasi adalah penormalan suatu entitas dari atribut yang memilki nama identitas yang sama ini berujuan agar tidak terjadi sesuatu yang tidak diaharapkan yang menyebabkan ketidak konsistenan data. Untuk menormalkan entitas tersebut diperlukan beberapa langkah langkah sebagai berikut: 1. Mengumpulkan atribut yang akan diperlukan ke dalam entitas un normal. 2. Memasukan beberapa atribut yang setiap atributnya tidak memiliki identitas yang sama antara satu dengan yang lainnya, ini disebut juga dengan bentuk normal ke satu.

11 3. Setelah itu kelangkah berikutnya dimana membuat entitas baru berisi atribut yang memiliki record yang spesifik, hal ini dimaksudkan agar setiap entitas dapat bekerja dengan optimal. Ini adalah bentuk normal ke dua untuk dilanjutkan ke normal ke tiga. 4. Normal ke tiga di gunakan agar tidak ada data yang samar. Pada tahap ini penulis menemukan bentuk entitas yang baik. Berikut tahap normalisasi database dari un normal sampai bentuk normal ke tiga. Tabel 3.5 Bentuk un normal dan bentuk ke satu. IdKereta NamaKereta Asal TujuanAkhir Kelas JumlahGerbongEksekutif KapasitasGerbongEksekutif JumlahGerbongBisnis KapasitasGerbongBisnis KapasitasKereta WaktuBerangkat IdPenumpang IdTiket NoIdentitas NamaPenumpang Usia IdPetugas NamaPetugas Alamat NomorTelepon HakAkses KataSandi IdStasiun IdRute IdKereta Tujuan Kelas KapasitasTujuan NamaGerbong WaktuTiba Tarif IdTiket IdKereta * NamaKereta Asal TujuanAkhir Kelas JumlahGerbongEksekutif KapasitasGerbongEksekutif JumlahGerbongBisnis KapasitasGerbongBisnis KapasitasKereta WaktuBerangkat IdPenumpang * IdTiket * NoIdentitas NamaPenumpang Usia IdPetugas* NamaPetugas Alamat NomorTelepon HakAkses KataSandi IdStasiun* IdRute* Tujuan Kelas KapasitasTujuan NamaGerbong WaktuTiba Tarif TanggalKeberangkatan TanggalPemesanan

12 IdKereta IdRute TanggalKeberangkatan TanggalPemesanan NomorTempatDuduk TotalBiaya StatusKeberangkatan NIKPetugas IdStasiun NamaStasiun Alamat NomorTelepon NomorTempatDuduk TotalBiaya StatusKeberangkatan NamaStasiun Alamat NomorTelepon Tabel 3.6 Bentuk normal ke dua Penumpang IdPenumpang * NomorIdentitas Varchar (20) NamaPenumpang Varchar (50) Usia Int Stasiun IdStasiun * Varchar (10) NamaStasiun Varchar (50) Alamat Varchar (300) NomorTelepon Varchar (20) Petugas IdPetugas * Varchar (20) NamaPetugas Varchar (50) Alamat Varchar (300) HakAkses Varchar (10) NomorTelepon Varchar (20) KataSandi Varchar (20)

13 Kereta IdKereta * Varchar (3) NamaKereta Varchar (30) Kelas Varchar (30) Asal Varchar (20) TujuanAkhir Varchar (30) JumlahGerbongEksekutif KapasitasGerbongEksekutif JumlahGerbongBisnis KapasitasGerbongBisnis KapasitasKereta WaktuBerangkat Varchar (7) IdRute Tujuan Varchar (30) Kelas Varchar (10) WaktuTiba Varchar (7) Tarif Float Transaksi IdTiket * Varchar (20) IdKereta ** Varchar (3) IdRute ** TanggalKeberangkatan Date/time TanggalPemesanan Date/time NomorTempatDuduk Varchar (10) TotalBiaya Float StatusKeberangkatan Varchar (10) IdPetugas ** Varchar (20)

14 Tabel 3.7 Bentuk normal ke tiga Petugas IdPetugas * Varchar (20) NamaPetugas Varchar (50) Alamat Varchar (300) HakAkses Varchar (10) NomorTelepon Varchar (20) KataSandi Varchar (20) IdStasiun Varchar (10) Penumpang IdPenumpang * NomorIdentitas Varchar (20) NamaPenumpang Varchar (50) Usia Int IdTiket ** Varchar (20) Stasiun IdStasiun * Varchar (10) NamaStasiun Varchar (50) Alamat Varchar (300) NomorTelepon Varchar (20)

15

16 Kereta IdKereta * Varchar (3) NamaKereta Varchar (30) Kelas Varchar (30) Asal Varchar (20) TujuanAkhir Varchar (30) JumlahGerbongEksekutif KapasitasGerbongEksekutif JumlahGerbongBisnis KapasitasGerbongBisnis KapasitasKereta WaktuBerangkat Date/time Transaksi IdTiket * Varchar (20) IdRute ** TanggalKeberangkatan Date/time TanggalPemesanan Date/time NomorTempatDuduk Varchar (10) TotalBiaya Float StatusKeberangkatan Varchar (10) IdPetugas ** Varchar (20)

17 IdRute * Rute Tujuan Varchar (30) Kelas Varchar (10) KapasitasTujuan NamaGerbong Varchar (10) WaktuTiba Date/time Tarif Float Idkereta** Varchar (3) Bentuk normal ke tiga menurut penulis sudah cocok untuk diterapkan sebagai database pemesanan tiket kereta api, karena kebutuhan pengguna sudah terpenuhi. Pada tabel 3.5, 3.6 dan 3.7 terdapat tanda * dan ** selain sebagai tanda primary key dan foreign key, tanda tersebut adalah penanda bahwa ada relasi.