IMPLEMENTASI ARSITEKTUR MICROSERVICE

IMPLEMENTASI ARSITEKTUR MICROSERVICE

PADA BACKEND SISTEM INFORMASI ATLANTAS

BERBASIS WEBSITE

LAPORAN SKRIPSI

CALVIN SEVIRO BIMA SAKTI

4816040105

PROGRAM STUDI TEKNIK INFORMATIKA

JURUSAN TEKNIK INFORMATIKA DAN KOMPUTER

POLITEKNIK NEGERI JAKARTA

2020

IMPLEMENTASI ARSITEKTUR MICROSERVICE PADA

BACKEND SISTEM INFORMASI ATLANTAS BERBASIS

WEBSITE

LAPORAN SKRIPSI

Dibuat untuk Melengkapi Syarat-Syarat yang Diperlukan untuk Memperoleh

Diploma Empat Politeknik

CALVIN SEVIRO BIMA SAKTI

4816040105

PROGRAM STUDI TEKNIK INFORMATIKA

JURUSAN TEKNIK INFORMATIKA DAN KOMPUTER

POLITEKNIK NEGERI JAKARTA

2020

iii

HALAMAN PERNYATAAN ORISINALITAS

Skripsi ini adalah hasil karya saya sendiri, dan semua sumber baik yang

dikutip maupun dirujuk telah saya nyatakan dengan benar.

Nama : Calvin Seviro Bima Sakti

NIM : 4816040105

Tanggal : 04 Agustus 2020

Tanda Tangan :

iv

LEMBAR PENGESAHAN

Skripsi diajuakan oleh :


NIM : 4816040105

Program Studi : TI

Judul Skripsi :IMPLEMENTASI ARSITEKTUR

MICROSERVICE PADA BACKEND SISTEM

INFORMASI ATLANTAS BERBASIS WEBSITE

Telah diuji oleh tim penguji dalam Sidang Skripsi pada hari Selasa, Tanggal 04,

Bulan Agustus, Tahun 2020 Dan dinyatakan LULUS.

Disahkan oleh

Pembimbing I : Indra Hermawan, S.Kom., M.Kom.

Penguji I : Risna Sari, S.Kom., M.T.I.

Penguji II : Hata Maulana, S.Si., M.T.I.

Penguji III : Yoyok Sabar Waluyo, S.S., M.Hum.

Mengetahui :

Ketua Jurusan Teknik Informatika dan Komputer

Mauldy Laya, S.Kom., M.Kom

NIP. 197802112009121003

v

KATA PENGANTAR

Bismillahirohanirohim, Puji syukur saya panjatkan kepada Tuhan Yang Maha Esa,

karena atas berkat dan rahmat-Nya, penulis dapat menyelesaikan skripsi ini yang

berjudul “IMPLEMENTASI ARSITEKTUR MICROSERVICE PADA BACKEND

SISTEM INFORMASI ATLANTAS BERBASIS WEBSITE”. penulisan skripsi ini

dilakukan dalam rangka memenuhi salah satu syarat untuk mencapai gelar Sarjana

Terapan Politeknik. Dalam Skripsi ini dibuat sistem integrasi antar kesatuan unit

lalu lintas yaitu unit bagian kecelakaan dan tilang.

Penulis menyadari bahwa tanpa bantuan dan bimbingan dari berbagai pihak, dari

masa perkuliahan sampai pada penyusunan skripsi ini, sangatlah sulit bagi penulis

untuk menyelesaikan skripsi ini di masa pandemic sepert ini. oleh karena itu,

penulis mengucapkan terima kasih kepada:

A. Mauldy Laya, S.Kom., M.Kom., selaku ketua jurusan teknik informatika

Politeknik Negeri Jakarta yang sudah menyediakan waktu dan tenaga untuk

melaksanakan sidang skripsi.

B. Risna Sari, S.Kom., M.T.I., selaku KPS yang sudah menyediakan waktu dan

tenaga untuk melaksanakan sidang skripsi.

C. Indra Hermawan, S.Kom.,M.Kom., selaku dosen pembimbing yang telah

menyediakan waktu, tenaga dan pikiran untuk mengarahkan penulis dalam

penyusunan skripsi ini.

D. Kombes. Pol. Azis Andriansyah, S.H., S.I K., M.Hum., selaku Kepala Polres

Depok yang sudah mengizinkan penulis untuk meneliti di salah satu satuan di

polres.

E. Bripda Eka dan Pak Pranyoto, selaku staff satlantas yang sudah bersedia

diwawancara oleh penulis untuk melakukan analisis data.

F. Orang tua dan keluarga penulis yang telah memberikan bantuan dukungan

moral maupun materil.

G. Aditta Nia Rahayu dan Aditya Dirgantara, selaku teman sekelompok skripsi

penulis yang tetap kompak dalam mengerjakan skripsi ini meskipun sedang

masa pandemi.

H. Bowi Andreyano, selaku teman CCIT PNJ angkatan 2017 yang membantu dan

menghibur saat terjadi kesulitan dalam penyusunan skripsi ini.

vi

I. Rahmawati Putri, selaku teman CCIT yang membantu dan menghibur saat

terjadi kesulitan dalam penyusunan skripsi ini.

J. Teman-teman PECINTA BOBA, yang membantu dan menghibur penulis saat

terjadi kesulitan dalam penyusunan skripsi ini.

Akhir kata, penulis berharap Tuhan Yang Maha Esa berkenan membalas segala

kebaikan semua pihak yang telah membantu. Semoga laporan skripsi ini membawa

manfaat bagi pengembangan ilmu.

Depok, Juli 2020

Penulis

vii

HALAMAN PERNYATAAN PERSETUJUAN PUBLIKASI SKRIPSI

UNTUK KEPENTINGAN AKADEMIS

Sebagai sivitas akademik Politeknik Negeri Jakarta, saya yang bertanda tangan di

bawah ini:


NIM : 4816040105

Program Studi : Teknik Informatika & Komputer

Jurusan : Teknik Informatika

Jenis karya : Skripsi demi pengembangan ilmu pengetahuan, menyetujui untuk

memberikan kepada Politeknik Negeri Jakarta Hak Bebas Royalti Noneksklusif

(Non-exclusive Royalty- Free Right) atas karya ilmiah saya yang berjudul :

IMPLEMENTASI ARSITEKTUR MICROSERVICE PADA BACKEND SISTEM

INFORMASI ATLANTAS BERBASIS WEBSITE

Beserta perangkat yang ada (jika diperlukan). Dengan Hak Bebas Royalti

Noneksklusif ini Politeknik Negeri Jakarta berhak menyimpan,

mengalihmedia/format-kan, mengelola dalam bentuk pangkalan data (database),

merawat, dan memublikasikan skripsi saya selama tetap mencantumkan nama saya

sebagai penulis/pencipta dan sebagai pemilik Hak Cipta.

Demikian pernyataan ini saya buat dengan sebenarnya.

Dibuat di : Depok

Pada tanggal : 04 Agustus 2020

Yang menyatakan

( Calvin Seviro Bima Sakti )

viii

IMPLEMENTASI ARSITEKTUR MICROSERVICE PADA BACKEND

SISTEM INFORMASI ATLANTAS BERBASIS WEBSITE

Abstrak

Jumlah pelanggaran lalu lintas yang terjadi di Wilayah Depok dari tahun 2017 sampai

2019 mengalami fluktuasi, dati tahun 2017 sebanyak 33.600 kasus, 2018 sebanyak 52.100

kasus dan 2019 sebanyak 42971 kasus. Dalam setiap tahunnya peningkatan pelanggaran

terjadi dan kemampuan aplikasi dalam pendistribusian data akan menurun. Hal ini terjadi

pada Satuan Lalu Lintas Polres Metro Depok, dengan semakin banyaknya penanganan

pencatatan data kecelakaan dan data pelanggaran yang terjadi di Kota Depok tentunya

harus diimbangi dengan peningkatan sistem sebagai media pelaporan secara online. Dari

penjelasan diatas dapat disimpulkan untuk memecahkan proses tersebut perlu adanya

sebuah arsitektur baru yaitu microservice. Microservice memungkinkan pengembangan

fungsi perangkat lunak dipecah menjadi bagian – bagian service yang kecil dan terfokus

menjadikan service akan memiliki kemampuan resource yang bisa diatur dengan tepat dan

membagi fungsionalitas aplikasi menjadi layanan yang kecil dan saling berhubungan

menjadi satu kesatuan bisnis proses aplikasi. Arsitektur ini mengintegrasikan data antar

satuan dan mendistribusikan data terkait adanya kasus pelanggaran lalu lintas atau

kecelakaan yang terjadi secara realtime oleh petugas polisi setempat serta menyajikan

informasi data pelanggaran lalu lintas dan kecelakaan yang spesifik..

Kata Kunci : Pelanggaran, Microservice, Lalu Lintas, Service

ix

DAFTAR ISI

HALAMAN PERNYATAAN ORISINALITAS ................................................... iii LEMBAR PENGESAHAN ................................................................................... iv KATA PENGANTAR ............................................................................................. v HALAMAN PERNYATAAN PERSETUJUAN PUBLIKASI SKRIPSI UNTUK

KEPENTINGAN AKADEMIS ............................................................................ vii

DAFTAR ISI .......................................................................................................... ix DAFTAR GAMBAR ............................................................................................. xi DAFTAR TABLE ................................................................................................ xiii BAB I……… ........................................................................................................... 1 PENDAHULUAN ................................................................................................... 1

1.1 Latar Belakang Masalah ............................................................................ 1

1.2 Perumusan Masalah ................................................................................... 2

1.3 Batasan Masalah ........................................................................................ 2 1.4 Tujuan dan Manfaat ................................................................................... 3 1.5 Metode Pelaksanaan Skripsi ...................................................................... 3 BAB II………………………………………………………… .............................. 4

TINJAUAN PUSTAKA .......................................................................................... 4 2.1 Sistem Informasi ........................................................................................ 4

2.2 Microservice .............................................................................................. 4 2.3 Metode Pengembangan Sistem ................................................................. 4 2.4 Rapid Application Development ............................................................... 4

2.4.3 Implementation .......................................................................................... 8 2.4.4 Testing ..................................................................................................... 11

2.5 Penelitian Terdahulu ................................................................................ 11 BAB III…………. ................................................................................................. 13

PERENCANAAN DAN REALISASI ................................................................... 13 3.1 Perancangan Program Aplikasi ............................................................... 13 3.1.1 Metode Penelitan ..................................................................................... 13

3.1.2 Deskripsi Sistem ...................................................................................... 14

3.1.3 Analisis Kebutuhan ................................................................................. 14 3.1.4 Cara Kerja Program Aplikasi .................................................................. 15 3.1.5 Rancangan Program Aplikasi .................................................................. 17 3.2 Realisasi Program Aplikasi ..................................................................... 34 3.2.1 Kecelakaan Service .................................................................................. 34

3.2.2 Tilang Service .......................................................................................... 37 3.2.3 User Service ............................................................................................ 37 BAB IV……….. .................................................................................................... 63 PEMBAHASAN .................................................................................................... 63 4.1 Pengujian ................................................................................................. 63

4.2 Deskripsi Pengujian ................................................................................. 63 4.3 Prosedur Pengujian .................................................................................. 63

4.4 Data Hasil Pengujian ............................................................................... 65 4.4.1 Black Box Testing ................................................................................... 65 4.4.2 Integration Testing .................................................................................. 84 4.5 Evaluasi ................................................................................................... 91 4.5.1 Evaluasi Hasil Black Box Testing ............................................................ 91

x

4.5.2 Evaluasi Hasil Integration Testing .......................................................... 92 5.1 Kesimpulan .............................................................................................. 93 5.2 Saran ........................................................................................................ 93 DAFTAR PUSTAKA ............................................................................................ 94 LAMPIRAN ........................................................................................................... 96

xi

DAFTAR GAMBAR

Gambar 3.1 Alur Kerja Microservices sistem informasi atlantas .......................... 16 Gambar 3.2 Use Case Diagram sistem informasi atlantas ..................................... 17 Gambar 3.3 Activity Diagram Login ..................................................................... 18 Gambar 3.4 Activity Diagram Logout ................................................................... 19 Gambar 3.5 Activity Diagram Menambah Data Kecelakaan ................................. 20

Gambar 3.6 Activity Diagram Mengubah Data Kecelakaan ................................. 21 Gambar 3.7 Activity Diagram Export Data Kecelakaan ........................................ 22 Gambar 3.8 Activity Diagram Menambah Data Kendaraan .................................. 23 Gambar 3.9 Activity Diagram Mengubah Data Kendaraan ................................... 24 Gambar 3.10 Activity Diagram Menambah Data Korban ..................................... 25

Gambar 3.11 Activity Diagram Mengubah Data Korban ...................................... 26

Gambar 3.12 Activity Diagram Menambah Master Data ...................................... 27

Gambar 3.13 Activity Diagram Menghapus Master Data ..................................... 28 Gambar 3.14 Activity Diagram Mengubah Master Data ....................................... 29 Gambar 3.15 Activity Diagram Menambah Petugas ............................................. 30 Gambar 3.16 Activity Diagram Mengubah Status Petugas ................................... 31

Gambar 3.17 Activity Diagram Export Bukti Pelanggaran Lalu Lintas ................ 32 Gambar 3.18 ER Diagram Microservice ................................................................ 33

Gambar 3.18 Potongan Kode Controller Tambah Data Jenis Kendaraan .............. 38 Gambar 3.19 Potongan Kode Controller Tampil Data Jenis Kendaraan ............... 39 Gambar 3.20 Potongan Kode Controller Hapus Data Jenis Kendaraan................. 39

Gambar 3.21 Potongan Kode Controller Detail Data Jenis Kendaraan ................. 40 Gambar 3.22 Potongan Kode Controller Update Data Jenis Kendaraan ............... 40

Gambar 3.23 Potongan Kode Controller Insert Data Jenis Tabrakan .................... 41 Gambar 3.24 Potongan Kode Controller Show Data Jenis Tabrakan .................... 41

Gambar 3.25 Potongan Kode Controller Delete Data Jenis Tabrakan................... 42 Gambar 3.26 Potongan Kode Controller Detail Data Jenis Tabrakan ................... 42 Gambar 3.27 Potongan Kode Controller Update Data Jenis Tabrakan ................. 43

Gambar 3.28 Potongan Kode Controller Insert Data Jenis Kondisi Korban ......... 43

Gambar 3.29 Potongan Kode Controller Show Data Jenis Kondisi Korban ......... 44 Gambar 3.30 Potongan Kode Controller Delete Data Kondisi Korban ................. 44 Gambar 3.31 Potongan Kode Controller Detail Jenis Kondisi Korban ................. 45 Gambar 3.32 Potongan Kode Controller Update Jenis Kondisi Korban ............... 45 Gambar 3.33 Potongan Kode Controller Insert Data Pasal Pelanggaran ............... 46

Gambar 3.34 Potongan Kode Controller Show Data Pasal Pelanggaran ............... 46 Gambar 3.35 Potongan Kode Controller Delete Data Pasal Pelanggaran ............. 47 Gambar 3.36 Potongan Kode Controller Detail Data Pasal Pelanggaran .............. 47 Gambar 3.37 Potongan Kode Controller Update Data Pasal Pelanggaran ............ 48 Gambar 3.38 Potongan Kode Controller Insert Data Petugas................................ 49

Gambar 3.39 Potongan Kode Controller Show Data Petugas................................ 49 Gambar 3.40 Potongan Kode Controller Website Detail Data Petugas ................. 50

Gambar 3.41 Potongan Kode Controller Update Status Petugas ........................... 51 Gambar 3.42 Potongan Kode Controller Insert Data Kecelakaan ......................... 52 Gambar 3.43 Potongan Kode Controller Website Show Data Kecelakaan ........... 52 Gambar 3.44 Potongan Kode Controller Export Data Kecelakaan........................ 53 Gambar 3.45 Potongan Kode Controller Detail Data Kecelakaan ......................... 54

xii

Gambar 3.46 Potongan Kode Controller Update Data Kecelakaan ....................... 54 Gambar 3.47 Potongan Kode Controller Website Insert Data Kendaraan ............. 55 Gambar 3.48 Potongan Kode Controller Website Show Data Kendaraan............. 56 Gambar 3.49 Potongan Kode Controller Website Detail Data Kendaraan ............ 56 Gambar 3.50 Potongan Kode Controller Website Update Data Kendaraan .......... 57

Gambar 3.51 Potongan Kode Controller Insert Data Korban ................................ 58 Gambar 3.52 Potongan Kode Controller Show Data Korban ................................ 58 Gambar 3.53 Potongan Kode Controller Detail Data Korban Kecelakaan ............ 59 Gambar 3.54 Potongan Kode Controller Update Data Korban Kecelakaan .......... 60 Gambar 3.55 Potongan Kode Controller Insert Surat Operasi ............................... 61

Gambar 3.56 Potongan Kode Controller Show Surat Operasi ............................... 61 Gambar 3.57 Potongan Kode Controller Website Detail Surat Operasi ................ 62 Gambar 3.58 Potongan Kode Controller Website Update Surat Operasi .............. 62

Gambar 4.1 Integrasi API Gateway ke Kecelakaan Service .................................. 85 Gambar 4.2 Integrasi API Gateway ke Kecelakaan Service (Offline) ................... 86 Gambar 4.3 Integrasi API Gateway ke Tilang Service .......................................... 87 Gambar 4.4 Integrasi API Gateway ke Tilang Service (Offline) ........................... 88

Gambar 4.5 Integrasi API Gateway ke User Service ............................................. 89 Gambar 4.6 Integrasi API Gateway ke Tilang dan Kecelakaan Service................ 90

Gambar 4.7 Integrasi API Gateway ke Tilang(Offline) dan Kecelakaan Service . 91

xiii

DAFTAR TABLE

Tabel 1. Simbol Use Case Diagram ......................................................................... 5 Tabel 2. Simbol Activity Diagram ............................................................................ 7 Tabel 3. Simbol Class Diagram ............................................................................... 8 Tabel 4. Master Kendaraan Controller ................................................................... 34 Tabel 5. Master Tabrakan Controller ..................................................................... 35

Tabel 6. Master Kondisi Controller ....................................................................... 35 Tabel 7. Master Jalan Controller ............................................................................ 35 Tabel 8. Kecelakaan Controller.............................................................................. 36 Tabel 9. Kendaraan Controller ............................................................................... 36 Tabel 10. Korban Controller .................................................................................. 36

Tabel 11. Surat Operasi Controller ........................................................................ 37

Tabel 12. Tilang Controller .................................................................................... 37

Tabel 13. User Controller ....................................................................................... 38 Tabel 14. Rencana Pengujian Black Box Testing ................................................... 64 Tabel 15. Pengujian Login ..................................................................................... 66 Tabel 16. Pengujian Logout ................................................................................... 67

Tabel 17. Pengujian Melihat Data Master ............................................................. 67 Tabel 18. Pengujian Menambah Data Master Kecelakaan .................................... 68

Tabel 19. Pengujian Mengubah Data Master ......................................................... 70 Tabel 20. Pengujian Menghapus Data Master ....................................................... 74 Tabel 21. Pengujian Melihat Data Petugas ............................................................ 75

Tabel 22. Pengujian Menambah Data Petugas ....................................................... 75 Tabel 23. Pengujian Mengubah Data Petugas........................................................ 76

Tabel 24. Pengujian Melihat Data Kecelakaan ...................................................... 77 Tabel 25. Pengujian Menambah Data Kecelakaan ................................................ 77

Tabel 26. Pengujian Mengubah Data Kecelakaan ................................................. 78 Tabel 27. Pengujian Melihat Data Kendaraan ....................................................... 78 Tabel 28. Pengujian Menambah Data Kendaraan .................................................. 79

Tabel 29. Tabel Pengujian Mengubah Data Kendaraan......................................... 80

Tabel 30. Pengujian Melihat Data Korban ............................................................. 81 Tabel 31. Pengujian Menambah Data Korban ....................................................... 81 Tabel 32. Tabel Pengujian Mengubah Data Kendaraan......................................... 82 Tabel 33. Pengujian Melihat Data Surat Operasi ................................................... 83 Tabel 34. Pengujian Menambah Data Surat Operasi ............................................. 83

Tabel 35. Tabel Pengujian Mengubah Data Surat Operasi .................................... 84

1

BAB I

PENDAHULUAN

1.1. Latar Belakang Masalah

Sistem transportasi merupakan inti suatu kota, terutama di kota besar yang memiliki

banyak penduduk serta aktivitas. Selain itu sistem transportasi merupakan hal yang

krusial dalam menentukan keefektifan suatu kota. Pergerakan penduduk dan

aktifitas ekonomi yang menggerakkan kota sangat tergantung pada sistem

transportasi yang sebagian besar dilayani oleh angkutan umum. Banyak sekali

kasus pelanggaran lalu lintas di jalan raya yang dilakukan oleh pemakai jalan yang

cenderung mengakibatkan timbulnya kecelakaan dan kemacetan lalu lintas yang

semakin meningkat.

Berdasarkan data Satlantas Polres Kota Depok banyaknya kasus pelanggaran lalu

lintas dalam bentuk bukti pelanggaran atau tilang pada tahun 2017 sebanyak 33600

kasus. Pada tahun 2018 terjadi kenaikan pelanggaran lalu lintas menjadi 52100

kasus dan pada tahun 2019 terjadi penurunan pelanggaran lalu lintas menjadi 42971

kasus. Pelanggaran tersebut terjadi justru pada jam-jam sibuk dimana aktifitas

masyarakat di jalan raya meningkat. Peningkatan menjadi tantangan baru bagi

pihak Kepolisian untuk mampu menerapkan sangsi yang mendidik namun tetap

memiliki efek jera. Namun yang terjadi selama ini sistem tilang sering

disampingkan oleh oknum anggota polisi serta sipil demi tercapainya kepentingan

bersama tanpa mengikuti prosedur yang ada. (Chusminah, Haryati and Kristiani,

2018)

Berdasarkan data Satlantas Polres Kota Depok pada tahun 2017 sebanyak 253 kasus

kecelakaan, pada tahun 2018 sebanyak 217 kasus kecelakaan dan pada tahun 2019

sebanyak 428 kasus kecelakaan. Dari tahun 2017 ke 2018 terjadi penurunan kasus

sebanyak 36 tetapi dari 2018 ke 2019 mengalami kenaikan kasus sebanyak 211

kasus.

Pesatnya perkembangan teknologi pada zaman ini telah memberikan banyak

manfaat di berbagai bidang. Salah satu manfaat yang diberikan oleh pesatnya

perkembangan teknologi adalah membantu manusia dalam menyelesaikan berbagai

2

Jurusan Teknik Informatika dan Komputer – Politeknik Negeri Jakarta

macam pekerjaannya. Hal ini terjadi pada Satuan Lalu Lintas Polres Metro Depok,

dengan semakin banyaknya penanganan pencatatan data kecelakaan dan data

pelanggaran yang terjadi di Kota Depok tentunya harus diimbangi dengan

peningkatan sistem sebagai media pelaporan secara online. Berdasarkan pernyataan

dari Staff Unit Lalu Lintas semakin bertambahnya proses pencatatan data

kecelakaan yang direkap tiap bulan dari staff unit laka lantas kepada staff OP satuan

lalu lintas dan juga setiap unit pada satuan lalu lintas harus berdiri pada aplikasi

atau sistemnya masing-masing.

Dari penjelasan diatas dapat disimpulkan untuk memecahkan proses tersebut perlu

adanya sebuah arsitektur baru yaitu microservice. Arsitektur microservice

merupakan konsep arsitektur pengembangan perangkat lunak dimana keseluruhan

fungsi – fungsi perangkat lunak dibuat menjadi lebih spesifik sesuai layanan pada

perangkat lunak. Microservice memungkinkan pengelolaan service – service yang

ada pada perangkat lunak secara terpisah, dengan begitu jika dilakukan

pengembangan service maka service lain tidak akan terganggu. Selain itu

pengembangan kapasitas antar service bisa dibedakan sehingga resource yang

dipakai bisa tepat.

Oleh karena itu, penelitian ini dilakukan pengembangan sistem ini dengan konsep

arsitektur microservice. Sistem ini diperlukan untuk mengintegrasikan data antar

satuan dan mendistribusikan data terkait adanya kasus pelanggaran lalu lintas atau

kecelakaan yang terjadi secara realtime oleh petugas polisi setempat serta

menyajikan informasi data pelanggaran lalu lintas dan kecelakaan yang spesifik.

1.2. Perumusan Masalah

Berdasarkan latar belakang yang telah diuraikan diatas, maka perumusan masalah

dengan sistem ini adalah : Bagaimana mengimplementasikan arsitektur

microservice pada lingkungan satuan lalu lintas Polres Metro Depok ?

1.3. Batasan Masalah

Batasan dalam pembuatan sistem ini adalah :

a. Fokus tugas akhir lebih ke aplikasi backend dan web service.

3


b. Implementasi web service menggunakan bahasa pemograman PHP dan

RESTFul API.

c. Sistem ini dirancangan dengan model aristektur microservice.

1.4. Tujuan dan Manfaat

Tujuan pembuatan sistem ini adalah mengimplementasikan arsitektur microservice

pada sistem infomasi atlantas berbasis website.

Manfaat yang didapat dan diharapkan dari pembuatan sistem ini adalah sebagai

berikut:

a. Memberikan informasi kasus pelanggaran lalu lintas dan kecelakan yang

terintegrasi melalui website.

b. Membantu staff dalam pengolahan data yang lebih spesifik dan terfokus.

1.5. Metode Pelaksanaan Skripsi

Dalam penelitian ini dilakukan dengan menggunakan metode Rapid Application

Development. Tahapan RAD terdiri atas 3 tahap yang bergantung satu sama lain

dan terstruktur di setiap tahap, yaitu :

1. Requirement Planning

Pada tahap ini user dan pengembang melakukan analisis untuk mengidentifikasi

tujuan dan pemecahan masalah.

2. Desain Workshop

Pada tahap ini dilakukan desain sistem sesuai dari analisis kebutuhan diatas.

3. Implementasi

Pada tahap ini sistem yang telah dibangun, diuji cobakan terlebih dahulu setelah itu

dijalankan dan diperkenalkan kepada organisasi yang menjalankan.

4

BAB II

TINJAUAN PUSTAKA

2.1. Sistem Informasi

Sistem Informasi adalah sebuah sistem yang proses dan kegiatannya untuk

memproses informasi seperti menangkap, mengirimkan, menyimpan, memperoleh

kembali, mengubah dan menampilkan informasi. Sebuah sistem kerja itu sendiri

adalah sebuah sistem di mana partisipasi manusia dan/atau mesin melakukan

aktivitas menggunakan informasi, teknologi, dan sumber daya lainnya untuk

memproduksi produk yang dituju (Yudanto, Tolle and Brata, 2017).

2.2. Microservice

Microservice adalah kumpulan beberapa proses yang berkomunikasi antar service

lain untuk membentuk sebuah aplikasi yang kompleks terhadap bahasa application

programming interfaces apapun. Microservice sendiri adalah pengembangan

lanjutan dari Service-oriented Architecture karena microservice merupakan sistem

yang terdiri dari komponen servis-servis blok, kecil ,terpisah dan fokus pada tugas-

tugasnya atau bekerja secara metode modular, autonomous untuk tujuan masing-

masing namun terkoneksi satu sama lain secara protokol. Dengan arsitektur ini

maka tercapai satu tujuan utama tertentu dalam pengembangan software (Putra,

2019) .

2.3. Metode Pengembangan Sistem

Pengembangan sistem dapat diartikan merancang suatu sistem yang baru untuk

menggantikan sistem yang ada atau memperbaiki sistem yang ada. Siklus hidup

pengembangan sistem / System Development Life Cycle (SDLC) adalah metode

pendekatan yang paling umum digunakan pada pengembangan sistem. (Febriani,

2018)

2.4. Rapid Application Development

Metode Rapid Application Development (RAD) adalah proses pada pengembangan

perangkat lunak yang bertujuan menciptakan proses pembuatan aplikasi dalam

5


waktu yang singkat (Prabowo and Suprapto, 2019). Metode iterative yang

digunakan RAD dalam pengembangan sistem yaitu working model (model bekerja)

sistem dibangun pada awal tahap pengembangan dengan tujuan menetapkan

requirement analysis (analisis kebutuhan).

2.4.1. Requirement Planning

Pada dasarnya kebutuhan sistem yang mendasar adalah mengidentifikasikan

kebutuhan informasi dan masalah yang dihadapi untuk menentukan tujuan

dibuatnya sistem, kendala dan juga alternatif pemecahan masalah. Analisis juga

perlu dilakukan untuk mengetahui perilaku sistem dan juga mengetahui aktivitas

apa saja yang terdapat dalam sistem tersebut.

2.4.2. Design Workshop

Mengidentifikasi solusi alternatif dan memilih solusi terbaik adalah langkah dari

kebutuhan desain. Pada bagian ini diperlukan membuat desain pemograman dan

proses bisnis dalam bentuk pemodelan dalam arsitektur informasi yang telah

didapatkan dari data-data.

A. Use Case Diagram

Use Case atau diagram use case adalah pemodelan untuk menggambarkan

hubungan antara sistem dengan aktor. Diagram ini menggambarkan himpunan use

case dan aktor-aktor. Diagram ini sangat penting dalam mengorganisasi dan

memodelkan perilaku sistem yang diharapkan oleh pengguna. (Widianti, 2018)

Tabel 1. Simbol Use Case Diagram

Sumber : (Heriyanto, 2018)

Simbol Deskripsi

Orang, proses atau sistem lain yang

berinteraksi dengan sistem informasi

yang akan dibuat di luar sistem

informasi yang akan dibuat yang biasa

disebut dengan aktor.

6


Fungsionalitas yang disediakan sistem

sebagai unit yang saling bertukar pesan

antar unit atau aktor yang disebut Use

Case.

Asosiasi adalah komunikasi antara

aktor dan use case yang berpartisipasi

pada use case yang memiliki interaksi

dengan aktor.

Include adalah relasi use case

tambahan ke sebuah use case dimana

use case yang ditambahkan

memerlukan use case lain untuk

menjalankan fungsinya.

Ekstensi adalah relasi use case

tambahan ke use case lain dimana yang

ditambahkan dapat berdiri sendiri

walaupun tambahan use case lain.

Generalisasi adalah hubungan umum-

khusus antar dua buah use case dimana

fungsi yang satu adalah fungsi yang

lebih umumnya dari lainnya.

B. Activity Diagram

Activity diagram adalah penggambaran model yang menunjukkan aktivitas sistem

dalam bentuk kumpulan aksi yang masing-masing aksi tersebut dimulai, keputusan

yang mungkin terjadi hingga berakhirnya aksi. Activity diagram adalah diagram

yang bersifat dinamis yang memperlihatkan aliran dari suatu aktivitas ke aktivitas

lainnya dalam suatu sistem. (Suendri, 2018)

7


Tabel 2. Simbol Activity Diagram


Simbol Deskripsi

Start untuk menyatakan awal dari suatu

proses.

Action untuk menyatakan aksi yang

dilakukan dalam suatu arsitektur

sistem.

Stop untuk menyatakan akhir dari suatu

proses.

Decision untuk menyatakan kondisi

dari suatu proses.

C. Entity Relationship Diagram

Entity Relationship Diagram (ERD) adalah pemodelan objek dengan

menggambarkan hubungan suatu model untuk menunjukkan objek data dan

hubungan yang ada pada model berikutnya. ERD memakai sejumlah simbol untuk

menggambarkan struktur dan hubungan antar data. (Fauzan, 2019)

Tiga fungsi utama ERD adalah sebagai berikut:

a. Sebagai alat untuk memodelkan hasil dari analisis data.

b. Sebagai alat untuk memodelkan data konseptual (lojikal).

c. Sebagai alat untuk memodelkan Objek-objek dalam suatu sistem (dasar dari

object diagram/class diagram).

ERD adalah diagram yang menjadi dasar dalam pembuatan database suatu sistem.

Dalam diagram ini hubungan antar objek, aktor dan proses bisnis dibentuk menjadi

suatu entitas yang memiliki atribut dan saling terhubung sesuai dengan proses bisnis

yang ada. Hubungan antar entitas disebut dengan relasi. Relasi inilah yang akan

mempengaruhi susunan tabel-tabel yang ada pada database. ERD merupakan

bentuk dari pemodelan data.

8


D. Class Diagram

Class Diagram adalah kelas sebagai suatu set objek yang memiliki atribut dan

perilaku yang sama dalam satu model dari suatu sistem. Class diagram juga

merupakan aturan-aturan dan tanggung jawab entitas yang menentukan perilaku

sistem dan menunjukkan atribut dan operasi dari sebuah kelas yang berhubungan

dengan objek yang terhubung. (Fauzan, 2019)

Tabel 3. Simbol Class Diagram


Simbol Deskripsi

Simbol kelas pada stuktur sistem.

Interface yang sama dengan konsep

dalam pemograman beriorientasi pada

objek.

Asosiasi adalah relasi antar kelas

dengan makna umum

Asosiasi berarah adalah relasi antar

kelas dengan makna kelas yang satu

digunakan oleh kelas yang lain.

2.4.3. Implementation

Pada tahapan ini proses pembuatan aplikasi menggunakan bahasa pemograman

yang diwujudkan dalam bentuk program atau unit program.

9


A. Web Service

Web Service adalah jembatan antar aplikasi yang berhubungan yang dapat dipanggil

dan diakses menggunakan format pertukaran data sebagai pengirim/penerima

pesan. Web Service digunakan sebagai suatu fasilitas yang menyediakan layanan

dalam bentuk data kepada aplikasi lain. Format yang digunakan dalam mengirim

atau menerima pesan dari aplikasi adalah JSON atau XML sehingga data ini dapat

diakses oleh sistem lain walaupun berbeda platform dan bahasa pemograman

(Arsya, Zaman, 2017)

B. Representational State Transfer

Representational State Transfer (REST) adalah sebuah arsitektur perangkat lunak

untuk mengkomunikasikan data dan website dalam bentuk HTTP protokol.

Application Programming Interfaces (API) adalah jembatan komunikasi antar klien

– server untuk mengimplementasikan fitur – fitur yang terdapat pada perangkat

lunak. Sistem yang mengikuti prinsip REST disebut RESTFUL API (Faruqi,

Gumilang and Hasibuan, 2018). REST API terdiri dari beberapa komponen yaitu :

1. Desain URL

Karena REST API diakses menggunakan protokol HTTP diperlukan penamaan dan

struktur URL yang baik dan mudah dimengerti dalam penggunannya. URL API

biasa disebut sebagai endpoint dalam pemanggilannya. Contoh pemanggilan URL

yang baik adalah seperti berikut: users, users/1, users/export/1.

2. HTTP Verbs

Metode yang dilakukan ketika melakukan request sehingga pada bagian server

mengetahui apa yang user ingin dapatkan. Metode dalam request terdiri dari : GET,

POST, PUT, DELETE

3. Response Code

Kode yang telah menjadi standar dalam menginformasikan hasil request kepada

user. Terdapat 3 kelompok kode yang paling sering digunakan di REST API yaitu:

a. Kode 2XX yang menandakan request yang dilakukan berhasil.

b. Kode 4XX yang menandakan bahwa request mengalami kesalahan pada sisi

klien.

10


c. Kode 5XX yang menandakan bahwa request mengalami kesalahan pada sisi

server.

4. Format Response

Setiap request yang dilakukan user akan menerima data respons dari server.

Respons tersebut biasanya berupa XML ataupun JSON. Setelah mendapatkan data

respons tersebut barulah user bisa menggunakannya dengan cara mengurai data

tersebut dan diolah sesuai kebutuhan.

C. MySQL

MySQL adalah sistem manajemen basis data relasional open-source (RDBMS)

populer yang didistribusikan, dikembangkan, dan didukung oleh Oracle

Corporation. Sistem relasional seperti, MySQL menyimpan data dalam bentuk tabel

dan menggunakan bahasa query terstruktur (SQL) untuk mengakses data. Di

MySQL harus menentukan dulu skema berdasarkan persyaratan dan mengatur

aturan untuk mengontrol hubungan antar bidang dalam catatan. Di MySQL,

informasi terkait dapat disimpan dalam tabel yang berbeda, tetapi mereka dikaitkan

dengan penggunaan gabungan. Dengan demikian, duplikasi data dapat

diminimalkan (Damodaran B, Salim, dan Vargese 2016).

D. Lumen Laravel

Laravel adalah framework MVC yang didesain untuk meningkatkan kualitas

perangkat lunak dengan mengurangi biaya pengembangan dan perbaikan serta

meningkatkan produktivitas pekerja dengan sintak yang fungsional yang dapat

mengurangi banyak waktu untuk implementasi. Lavarel merupakan framework

dengan versi yang up-to-date, oleh karena itu karena Laravel mensyaratkan utama

PHP versi 5.3 keatas. Laravel merupakan framework PHP yang menekankan pada

kesederhanaan dan fleksibilitas pada desainnya (Luthfi, 2017).

Lumen adalah bagian dari laravel yang biasa disebut micro-framework yang

dikhususkan untuk pembuatan API. Berbeda dengan laravel yang digunakan untuk

pembuatan full-stack website.

11


2.4.4. Testing

Proses testing dari RAD menekankan pada pemakaian kembali komponen yang

telah diuji. Hal ini dimaksudkan untuk mengurangi waktu pengujian dan komponen

baru harus diuji (Frieyadie, 2017).

A. BlackBox Testing

Blackbox Testing adalah salah satu metode pengujian pada pengembangan sistem

atau aplikasi yang dilakukan untuk memeriksa apakah aplikasi berjalan pada

fungsional yang baik dan benar tanpa harus mengetahui bisnis proses yang terjadi.

Pengujian blackbox dilakukan dengan membuat test case yang berupa form test

input dan ouput yang diharapakan pada fungsional aplikasi. Pengujian bisa

dilakukan pada aplikasi yang tingkat granulitas rendah sehingga memungkinkan

memakan waktu yang relatif tidak lama. (Jayanto, 2017)

2.5. Penelitian Terdahulu

Penelitian terdahulu adalah penelitian yang memiliki topik atau penelitian yang

sama sehingga penelitian-penelitian tersebut menjadi acuan dalam pembuatan

tugas akhir ini. Penelitian terdahulu dapat memberikan arahan tentang bagaimana

penelitian mengenai topik tersebut harus dilakukan dan juga memberikan saran

tentang bagaimana suatu aplikasi atau sistem menjadi lebih baik.

Penelitian terdahulu pernah dilakukan oleh Dedi Puji Jayanto pada tahun 2017

berupa merancang bangun suatu aplikasi sistem informasi aspirasi dan pengaduan

masyarakat. Sistem informasi aspirasi dan pengaduan masyarakat merupakan

sistem yang berguna untuk melayani aspirasi masyarakat serta pengaduan yang

terjadi di seluruh Indonesia. Sistem ini menggunakan metode microservice

springboot dengan framework spring. Pada prinsip sistem ini, microservice ini

melibatkan satu halaman website dengan banyak controller yang dimana fungsi

dari setiap controller berbeda-beda seperti contoh untuk halaman aduan terdiri atas

microservices complaint, citizen dan customer.

Penelitian dilakukan oleh Maksy Sendiang, Sonny Kasenda dan Jerry Purnama

pada tahun 2018 dengan judul “Implementasi Teknologi Microservices pada

Pengembangan Mobile Learning”. Sistem ini berbasis website dengan

12


framework laravel dan arsitektur microservice lumen. Penelitian ini dilakukan

untuk mengimplementasi kan mobile learning kepada semua pelajar dengan

berbagai latar belakang yang berbeda serta mampu menyediakan fasilitas learning

yang berbeda pula seperti kemampuan pengambilan dan sharing gambar secara real

time, peta dan global positioning system (GPS) yang terintegrasi jaringan wireless.

Dengan fitur yang disebutkan menjadikan mobile learning menyediakan fasilitas

pembelajaran yang fleksibel dan menyenangkan.

Penelitain terdahulu selanjutnya adalah penelitian yang dilakukan oleh Muhammad

Angga Kawa Perdana pada tahun 2018 dengan judul “Pengembangan REST API

Layanan Penyimpanan Menggunakan Metode Rapid Application

Development (Studi Kasus : PT. XYZ)”. Sistem ini berbasis API framework

Restify dengan menggunakan bahasa Javascript dan database yang digunakan

MySql. Penelitian ini dilakukan untuk mengimplementasikan penambahan REST

API layanan penyimpanan untuk PT. XYZ yang sudah terlebih dahulu

menggunakan konsep arsitektur microservices sehingga dapat diintegrasikan

dengan layanan lainnya. Penelitian ini juga menggunakan standar autentikasi

OAuth yang dimana proses autentikasinya menggunakan access token untuk

mengakses resource aplikasi yang ada dengan jangka waktu yang tertentu.

Hasil pemaparan diatas menyimpulkan bahwa penelitan ini diadaptasi dari ketiga

penelitian sebelumnya. Dengan membandingkan metode dan menambahkan fitur

atau keamanan yang tidak ada pada penelitian sebelumnya. Penelitian yang akan

dilakukan dalam implementasi aristektur microservice pada backend sistem

informasi atlantas dilakukan untuk pencatatan data kecelakaan secara online

ditempat terjadinya kecelakaan serta penambahan fitur e-laporan pada staff.

Penelitian ini juga menghubungkan antara 1 layanan dengan layanan lain yaitu

pelaporan rekap bulan yang dilakukan oleh staff kecelakaan kepada staff OP.

13

BAB III

PERENCANAAN DAN REALISASI

3.1 Perancangan Program Aplikasi

Perancangan dari sistem yang terdiri dari metode penelitian, deksripsi sistem, cara

kerja sistem, rancangan sistem, dan realisasi sistem akan dibahas pada bab ini.

3.1.1. Metode Penelitan

Metode Penelitian merupakan tahapan dalam penyelesaian permasalahan pada

tugas akhir ini. Metode penelitian dapat digunakan sebagai panduan pengerjaan

tugas akhir agar lebih sistematis, teratur dan terarah. Pembuatan metode penelitian

berdasarkan model pengembangan Rapid Application Development. Tahapan-

tahapan dalam pengerjaan tugas akhir ini dapat dilihat sebagai berikut :

A. Studi Literatur

Pada tahapan ini dilakukan pengumpulan dan pengkajian pustaka tentang konsep

dan metode pengerjaan yang digunakan untuk menyelesaikan permasalahan yang

diangkat pada tugas akhir ini.

B. Analisis Kebutuhan

Pada tahap ini akan dilakukan penggalian kebutuhan mengenai sistem informasi

yang akan dibuat. Penggalian kebutuhan nantinya akan menjadi kebutuhan data,

kebutuhan fungsional dan kebutuhan non fungsional.

C. Desain Sistem

Pada tahap ini dilakukan perancangan dan desain aplikasi sistem informasi atlantas.

Perancagan dan desain menggunakan UseCase Diagram, Activity Diagram, ER

Diagram, Class Diagram.

D. Pembuatan Sistem

Implementasi desain sistem merupakan tahapan pembuatan kode aplikasi dan kode

database aplikasi berdasarkan desain yang telah disepakati. Kode aplikasi dibuat

dengan menggunakan framework lumen.

14


E. Testing

Pengujian yang akan dilakukan adalah menggunakan pengujian blackbox testing

untuk mengetahui jalannya fungsionalitas dalam aplikasi. Blackbox testing juga

dilakukan untuk memastikan aplikasi berjalan dengan baik.

3.1.2. Deskripsi Sistem

Sistem informasi ini merupakan sistem yang memberikan informasi tentang data

pelanggaran lalu lintas dan kecelakaan dengan menggunakan penghubung

komunikasi data REST API dengan model arsitektur microservice yang diterapkan

pada sistem ini membuat pengelolaan data yang terstruktur serta monitoring service

yang mudah karna service berdiri diatas fungsi-fungsi yang berbeda. Web Service

ini mengintegrasikan 2 aplikasi yaitu android dan website.

3.1.3. Analisis Kebutuhan

Perancangan web service dengan model arsitektur microservice pada sistem

informasi ATLANTAS diperlukan analisis sebagai berikut.

a. Kebutuhan Data

Kebutuhan data merupakan hal yang utama dalam membuat sebuah program

aplikasi, termasuk dalam perancangan web service REST pada sistem informasi ini

dan dengan menerapkan arsitektur microservice untuk memecah aplikasi lebih rinci

lagi dari sisi fungsionalitasnya. Data yang diperlukan yaitu data laporan kecelakaan

lalu lintas dan laporan bukti pelanggaran lalu lintas tertentu. Data tersebut

didapatkan dari wawancara dan diskusi kelompok yang dilakukan narasumber yaitu

staff tilang dan lakalantas polres kota depok.

b. Kebutuhan Fungsional

Kebutuhan fungsional dilakukan untuk mengetahui apa saja permasalahan yang

dialami oleh user dan mengetahui kebutuhan user. Dengan melakukan wawancara

kepada narasumber mengenai permasalahan yang terjadi maka dapat disimpulkan

kebutuhan fungsional terdiri atas aktor yang akan menggunakan sistem dan

deskripsi kebutuhan fungsional sebagai berikut :

1. Fitur Login

15


Staff Satuan Lalu Lintas, Staff tilang maupun admin melakukan login terlebih

dahulu sebelum mengakses sistem.

2. Fitur Mengelola Data Kecelakaan

Staff Satuan Lalu Lintas dapat menambah, mengubah dan menghapus data

kecelakaan yang meliputi data kecelakaan, data korban dan data kendaraan yang

terlibat.

3. Fitur Mengelola Data Petugas dan Data Master

Admin dapat menambah, mengubah dan menonaktifkan petugas yang terlibat

dalam pencatatan kasus pelanggaran lalu lintas. Admin dapat juga menambah,

mengubah dan menghapus data master pada website atlantas yang meliputi data

jenis kendaraan, jenis kondisi korban, jenis tabrakan untuk kecelakaan dan jenis

pelanggaran untuk pelanggaran lalu lintas.

4. Fitur Unduh Laporan

Staff Satuan Lalu Lintas dapat mengunduh data laporan lalu lintas kecelakaan

maupun bukti pelanggaran lalu lintas.

c. Kebutuhan Non – Fungsional

Implementasi REST API dengan arsitektur microservice pada sistem atlantas ini

berjalan pada web micro - framework. Pengembangan menggunakan bahasa

pemograman PHP Lumen. Spesifikasi kebutuhan hosting yang beroperasi 24 jam

dengan minimal spesifikasi berikut CPU Minimal 2,5 Ghz, RAM 1024 MB,

Penyimpanan Hardisk / SSD minimal 20 GB dan Kecepatan Internet yang baik.

3.1.4. Cara Kerja Program Aplikasi

Sistem akan berhasil dan bekerja dengan baik apabila bekerja sesuai alur atau cara

kerja yang telah ditentukan. Adapun alur konsep dari arsitektur microservices pada

sistem informasi atlantas ini yang dipaparkan pada gambar 3.1.

16


Gambar 3.1 Alur Kerja Microservices sistem informasi atlantas

Gambar 3.1 mengenai alur kerja dari arsitektur microservice sistem informasi

atlantas. Pertama melakukan login sesuai aktornya dan tiap aktor memliki fungsi

yang berbeda. Untuk role admin hanya mengakses pada bagian user service saja,

untuk staff laka pada bagian laka service, untuk staff tilang mengakses tilang

service serta untuk petugas dan kanit/kasat bisa mengakses tilang dan laka service.

Selanjutnya dari tiap aktor akan melakukan tugasnya sesuai kebutuhan

fungsionalnya masing-masing yang sudah dijelaskan sebelumnya. Semua proses

tersebut melewati proses keamanan autentikasi OAuth 2.0 yang dimana sebelum

mengakses service-service ini klien harus terautentikasi akan menerima access

token yang dapat digunakan pada jangka waktu tertentu untuk mengakses resource

tersebut. Access Token tersebut disimpan kedalam basis data pada aplikasi yang

17


terhubung dan memiliki waktu kadaluwarsa. Semua perintah yang dilakukan dari

website menggunakan HTTP Request lalu dikirimkan melewati API Gateway untuk

divalidasi dari access token. Jika sukses maka akan diteruskan ke service yang

dituju.

3.1.5. Rancangan Program Aplikasi

A. Use Case Diagram

Use Case menggambarkan fungsionalitas dari sebuah sistem dan mengetahui apa

saja yang dapat dilakukan user. Pada Gambar 3.2 merupakan diagram use case dari

sistem ini yang dapat dilakukan oleh user. Diagram ini terdiri dari 3 jenis aktor dari

masing-masing Staff Satuan Lalu Lintas. Staff Satuan Lalu Lintas terdiri dari

beberapa jabatan yaitu staff tilang, staff kecelakaan, dan admin. Staff tilang dapat

mengexport bukti pelanggaran lalu lintas, staff kecelakaan dapat mengelola data

kecelakaan, data kendaraan kecelakaan dan data korban kecelakaan, dan admin

dapat menambah, mengubah status petugas, mengelola data master.

Gambar 3.2 Use Case Diagram sistem informasi atlantas

18


B. Activity Diagram

Activity Diagram menggambarkan lebih jelas fungsi-fungsi yang akan dijalankan

pada sistem informasi atlantas ini.

Gambar 3.3 Activity Diagram Login

Gambar 3.3 merupakan diagram activity untuk melakukan login. Semua staff

sebelum megelola data harus melakukan login terlebih dahulu dengan mengisi NRP

dan password. Kemudian akan divalidasi apakah staff tersebut terdaftar dalam

sistem ini atau tidak. Jika terdafta maka akan menampilkan halaman utama website

19


sesuai jabatan yang didapat. Setiap staff memiliki tampilan yang berbeda sesuai

dengan jabatannya.

Gambar 3.4 Activity Diagram Logout

Gambar 3.4 merupakan diagram activity untuk melakukan logout. Semua aktor

dapat melakukan logout. Jika memilih logout, maka sistem akan memproses akun

yang telah melakukan login dengan menghapus session dan kembali menuju

halaman login.

20


Gambar 3.5 Activity Diagram Menambah Data Kecelakaan

Pada Gambar 3.5 merupakan diagram activity menambah data kecelakaan.

Menambah data kecelakaan hanya dilakukan oleh staff kecelakaan. Setelah staff

kecelakaan login lalu masuk ke halaman utama website dan memilih managemen

laka. Data yang ditambah berisikan data kecelakaan, korban yang terlibat serta

kendaraan yang terlibat. Jika sudah selesai maka staff kecelakaan dapat mengklik

simpan lalu sistem akan memproses tambah data tersebut.

21


Gambar 3.6 Activity Diagram Mengubah Data Kecelakaan

Pada gambar 3.6 merupakan diagram activity mengubah data kecelakaan. Proses

ini hanya dilakukan oleh staff kecelakaan dan jika ada kekeliruan atau kesalahan

dalam menambah data kecelakaan. Setelah staff kecelakaan login lalu masuk ke

halaman utama website dan memilih managemen kecelakaan lalu klik menu Data

Kecelakaan, maka akan menampilkan list data kecelakaan. Staff kecelakaan akan

memilih data kecelakaan yang ingin diubah lalu klik tombol ubah maka sistem akan

memproses perubahan data kecelakaan.

22


Gambar 3.7 Activity Diagram Export Data Kecelakaan

Pada gambar 3.7 merupakan diagram activity export data kecelakaan. data

kecelakaan hanya dilakukan oleh staff laka. Setelah staff laka login lalu masuk ke

halaman utama website dan memilih managemen kecelakaan lalu klik data

kecelakaan. Lalu input nomor laporan kecelakaan pada pencarian data kecelakaan

lalu klik cari. Selanjutnya jika data yang dicari muncul lalu klik export. Sistem akan

mengubah data tersebut menjadi dokumen pdf.

23


Gambar 3.8 Activity Diagram Menambah Data Kendaraan

Pada gambar 3.8 merupakan diagram activity menambah data kendaraan.

Menambah data kecelakaan hanya dilakukan oleh staff kecelakaan. Setelah staff

kecelakaan login lalu masuk ke halaman utama website dan memilih managemen

laka lalu klik Data Kendaraan. Data yang ditambah berisikan detail data kendaraan

berdasarkan nomor laporan kecelakaan yang sudah diinput sebelumnya.

24


Gambar 3.9 Activity Diagram Mengubah Data Kendaraan

Pada gambar 3.9 merupakan diagram activity mengubah data kendaraan. Proses ini

hanya dilakukan oleh staff kecelakaan dan jika ada kekeliruan atau kesalahan dalam

menambah data kendaraan. Setelah staff kecelakaan login lalu masuk ke halaman

utama website dan memilih managemen kecelakaan lalu klik menu Data

Kendaraan, maka akan menampilkan list data kendaraan. Staff kecelakaan akan

memilih data kendaraan yang ingin diubah lalu klik tombol ubah maka sistem akan

memproses perubahan data kendaraan.

25


Gambar 3.10 Activity Diagram Menambah Data Korban

Pada gambar 3.10 merupakan diagram activity menambah data korban. Menambah

data korban hanya dilakukan oleh staff kecelakaan. Setelah staff kecelakaan login

lalu masuk ke halaman utama website dan memilih managemen laka lalu klik Data

Korban. Data yang ditambah berisikan detail data korban berdasarkan nomor

laporan kecelakaan yang sudah diinput sebelumnya dan data kendaraan sudah

diinput.

26


Gambar 3.11 Activity Diagram Mengubah Data Korban

Pada gambar 3.11 merupakan diagram activity mengubah data korban. Proses ini

hanya dilakukan oleh staff kecelakaan dan jika ada kekeliruan atau kesalahan dalam

menambah data korban. Setelah staff kecelakaan login lalu masuk ke halaman

utama website dan memilih managemen kecelakaan lalu klik menu Data Korban,

maka akan menampilkan list data korban. Staff kecelakaan akan memilih data

korban yang ingin diubah lalu klik tombol ubah maka sistem akan memproses

perubahan data korban.

27


Gambar 3.12 Activity Diagram Menambah Master Data

Pada gambar 3.12 merupakan diagram activity menambah master data. Menambah

master data hanya dilakukan oleh admin. Setelah admin login lalu masuk ke

halaman utama website dan memilih menu Master Data. Data yang ditambah

berisikan jenis kendaraan (kendaraan bermotor, kendaraan tak bermotor), jenis

tabrakan (tunggal, depan-depan, samping-depan), kondisi korban (MD, LR, LB),

pasal pelanggaran (pasal tilang) dan nama jalan (alamat jalan, longitude dan

latitude). Jika sudah selesai maka staff kecelakaan dapat mengklik simpan lalu

sistem akan memproses tambah data tersebut.

28


Gambar 3.13 Activity Diagram Menghapus Master Data

Pada gambar 3.13 merupakan diagram activity menghapus master data. Yang

mampu melakukan menghapus master data adalah admin. Setelah admin

melakukan login lalu masuk ke halaman utama website dan memilih menu Master

Data. Kemudian menampilkan form tambah master data dan tabel, pilih salah satu

master data yang akan dihapus. Setelah klik button delete maka data yang di dalam

database akan terhapus.

29


Gambar 3. 14 Activity Diagram Mengubah Master Data

Pada gambar 3.14 merupakan diagram activity mengubah master data. Proses ini

hanya dilakukan oleh admin dan jika ada kekeliruan atau kesalahan dalam

menambah master data. Setelah admin login lalu masuk ke halaman utama website

dan memilih menu Master Data lalu pilih salah satu menu master, maka akan

menampilkan form tambah master data dan tabel. Admin akan memilih master data

yang ingin diubah lalu klik tombol ubah maka sistem akan memproses perubahan

master data.

30


Gambar 3.15 Activity Diagram Menambah Petugas

Pada gambar 3.15 merupakan diagram activity menambah petugas. Yang dapat

melakukan aktivitas ini adalah admin. Setelah admin melakukan login lalu pilih

menu Managemen Petugas kemudian pilih sub menu Data Petugas maka akan

menampilkan form tambah data petugas dan tabel data petugas. Selanjutnya input

petugas baru dan jika sudah selesai maka admin dapat mengkilk tombol submit lalu

sistem memproses tambah data petugas.

31


Gambar 3.16 Activity Diagram Mengubah Status Petugas

Pada gambar 3.16 merupakan diagram activity mengubah status petugas. Yang

dapat melakukan aktivitas ini adalah admin. Setelah admin melakukan login lalu

pilih menu Managemen Petugas kemudian pilih sub menu Data Petugas maka akan

menampilkan form tambah data petugas dan tabel data petugas. Selanjutnya pilih

salah satu petugas yang akan di aktifkan/nonaktifkan statusnya, hasil perubahan

status akan ter-update ke dalam database.

32


Gambar 3.17 Activity Diagram Export Bukti Pelanggaran Lalu Lintas

Pada gambar 3.17 merupakan diagram activity export bukti pelanggaran lalu lintas.

Export bukti pelanggaran lalu lintas hanya dilakukan oleh staff tilang. Setelah staff

tilang login lalu masuk ke halaman utama website dan memilih managemen tilang

lalu klik data tilang. Lalu input nomor blangko pada pencarian data tilang lalu klik

cari. Selanjutnya jika data yang dicari muncul lalu klik export. Sistem akan

mengubah data tersebut menjadi dokumen pdf.

33


C. ER Diagram

ER Diagram menggambarkan hubungan suatu model untuk menunjukkan objek

data dan hubungan yang ada pada model berikutnya.

Gambar 3.18 ER Diagram Microservice

Pada Gambar 3.18 merupakan hubungan Entity Relationship Diagram (ERD) pada

satuan unit lalu lintas. Table master_kondisi, master_kendaraan dan

master_tabrakan untuk menampung jenis acuan data yang akan dipakai untuk table

34


data orang, data_kecelakaan dan surat_tanda_nomor_kendaraan. Master_kondisi

memiliki relasi dengan data_orang untuk mencatat korban yang terlibat.

Master_kendaraan memiliki relasi dengan surat_tanda_nomor_kendaraan untuk

mencatat jenis kendaraan berdasarkan data dari STNK kendaraan yang terlibat.

Master_tabrakan memiliki relasi dengan data_kecelakaan untuk mencatat jenis

tabrakan dari kecelakaan yang terjadi. Data_kecelakaan juga berelasi dengan

surat_tanda_nomor_kendaraan dan data_orang untuk mencatat korban dan

kendaaran yang terlibat dari 1 laporan kecelakaan. Surat_tilang memiliki relasi

dengan surat_operasi untuk mencatat laporan kegiatan operasi. Surat_tilang juga

memiliki relasi dengan master_pelanggaran untuk mencatat jenis pelanggarn yang

dikenakan. Surat_tilang memiliki relasi dengan master_penduduk dan

surat_izin_mengemudi untuk mencatat data pelanggar serta kendaraannya.

3.2 Realisasi Program Aplikasi

Realisasi sistem meliputi implementasi dari microservice sistem. Berikut dibawah

ini penjelasan dari setiap service-nya :

3.2.1 Kecelakaan Service

Terdapat 2 aktor yang menjalakan service kecelakaan, admin dan staff laka.

Kecelakaan service mempunyai fungsi dalam kelola data yang berhubungan dengan

proses pencatatan laporan kecelakaan. Pada tabel 4 adalah class master kendaraan

controller yang berisi method-method dalam kelola data yang berhubungan dengan

master data kendaraan yang akan digunakan dalam proses pencatatan data

kendaraan kecelakaan yang terlibat.

Tabel 4. Master Kendaraan Controller

Controller Master Kendaraan

Kebutuhan Microservice Method Rest URL REST

Menampilkan data jenis kendaraan GET /MKendaraan

Menampilkan detail jenis kendaraan GET /MKendaraan/{id}

Menambah data jenis kendaraan POST /MKendaraan

Menghapus data jenis kendaraan DELETE /MKendaraan/{id}

Mengubah data jenis kendaraan PUT /MKendaraan/{id}

35


Pada tabel 5 adalah class master tabrakan controller yang berisi method-method

dalam kelola data yang berhubungan dengan master data tabrakan yang akan

digunakan dalam proses pencatatan data kecelakaan.

Tabel 5. Master Tabrakan Controller

Controller Master Tabrakan

Kebutuhan Microservice Method

Rest URL REST

Menampilkan data jenis tabrakan GET /MTabrakan

Menampilkan detail jenis tabrakan GET /MTabrakan/{mtabrakan}

Menambah data jenis tabrakan POST /MTabrakan

Menghapus data jenis tabrakan DELETE /MTabrakan/{mtabrakan}

Mengubah data jenis tabrakan PUT /MTabrakan/{mtabrakan}

Pada tabel 6 adalah class master kondisi controller yang berisi method-method

dalam kelola data yang berhubungan dengan master data kondisi korban yang akan

digunakan dalam proses pencatatan data korban kecelakaan.

Tabel 6. Master Kondisi Controller

Controller Master Kondisi


Menampilkan data kondisi korban GET /MKondisi

Menampilkan detail kondisi korban GET /MKondisi/{mkondisi}

Menambah data kondisi korban POST /MKondisi

Menghapus data kondisi korban DELETE /MKondisi/{mkondisi}

Mengubah data kondisi korban PUT /MKondisi/{mkondisi}

Pada tabel 7 adalah class master jalan controller yang berisi method-method dalam

kelola data yang berhubungan dengan master data nama jalanyang akan digunakan

dalam proses pencatatan data kecelakaan.

Tabel 7. Master Jalan Controller

Controller Master Jalan


Menampilkan data nama jalan GET /jalan

Menampilkan detail nama jalan GET /jalan/{jalan}

36


Menambah data nama jalan POST /jalan

Menghapus data nama jalan DELETE /jalan/{jalan}

Mengubah data nama jalan PUT /jalan/{jalan}

Pada tabel 8 adalah class kecelakaan controller yang berisi fungsi-fungsi yang

berhubungan dengan proses pencatatan data kecelakaan yang terjadi.

Tabel 8. Kecelakaan Controller

Controller Kecelakaan


Menampilkan data kecelakaan GET /kcl

Menampilkan detail kecelakaan GET /kcl/{kcl}

Menambah data kecelakaan POST /kcl

Mengubah data kecelakaan PUT /kcl/{kcl}

Export data kecelakaan PUT /kcl/export-{id}

Pada tabel 9 adalah class kendaraan controller yang berisi fungsi-fungsi yang

berhubungan dengan proses pencatatan data kendaraan yang terlibat kecelakaan.

Tabel 9. Kendaraan Controller

Controller Kendaraan


Menampilkan data kendaraan GET /kstnk

Menampilkan detail kendaraan GET /kstnk/{kstnk}

Menambah data kendaraan POST /kstnk

Mengubah data kendaraan PUT /kstnk/{kstnk}

Pada tabel 10 adalah class korban controller yang berisi fungsi-fungsi yang

berhubungan dengan proses pencatatan data korban yang terlibat kecelakaan.

Tabel 10. Korban Controller

Controller Korban


Menampilkan data korban GET /orang

Menampilkan detail korban GET /orang/{orang}

Menambah data korban POST /orang

37


Mengubah data korban PUT /orang/{orang}

3.2.2 Tilang Service

Terdapat 2 aktor yang menjalakan service tilang, admin dan staff tilang. Kecelakaan

service mempunyai fungsi dalam kelola data yang berhubungan dengan proses

input surat operasi tilang dan menampilkan data pelanggaran lalu lintas. Pada tabel

11 adalah class surat operasi controller yang berisi fungsi-fungsi yang berhubungan

dengan proses pendataan surat operasi untuk tindakan pelanggaran lalu lintas secara

represif, preventif dan preemtif.

Tabel 11. Surat Operasi Controller

Controller Surat Operasi


Menampilkan data surat operasi GET /soperasi

Menampilkan detail surat operasi GET /soperasi/{soperasi}

Menambah data surat operasi POST /soperasi

Mengubah data surat operasi PUT /soperasi/{soperasi}

Pada Tabel 12 adalah class tilang controller yang berisi fungsi menampilkan

informasi semua dan detail pada pelanggar lalu lintas.

Tabel 12. Tilang Controller

Controller Surat Operasi


Menampilkan data tilang GET /tilang

Menampilkan detail tilang GET /tilang /{tilang}

3.2.3 User Service

Terdapat 1 aktor yang menjalankan service user yaitu admin. User service

mempunyai fungsi dalam proses login, menambah dan mengubah status aktor .

Service ini juga mempunyai peran sebagai API Gateway yang mengatur

management API dari service kecelakaan dan tilang, merge beberapa API serta

autentikasi API . Dikirimkan berbentuk REST API menggunakan protokol HTTP

Request. Berikut daftar tabel controller dibawah ini pada user service.

38


Tabel 13. User Controller

Controller User


Login POST /login

Mengambil data petugas GET /users

Mengambil detail petugas GET /users/{id}

Menambah data petugas POST /users

Mengubah status petugas PUT /users/{id}

Generate Token POST /oauth/token

Berikut dibawah ini implementasi fungsi microservice pada sistem informasi

atlantas.

a. Implementasi Data Jenis Kendaraan

Pada implementasi data jenis kendaraan memanggil fungsi controller master

kendaraan di microservice kecelakaan. Untuk menyimpan dan memunculkan data

jenis kendaraan membutuhkan kode dibawah ini.

Gambar 3.18 Potongan Kode Controller Tambah Master Data Jenis Kendaraan

Fungsi pada gambar 3.18 adalah untuk menambah data master jenis kendaraan

dengan memanggil fungsi service menambah data jenis kendaraan. Data yang sudah

diisi pada form harus divalidasi dengan variabel $rules lalu data yang sudah

disimpan pada variabel $MKendaraan kemudian disimpan ke database melalui

service function insertJKendaraan. Jika sukses maka akan langsung ke halaman

utama data jenis kendaraan.

39


Gambar 3.19 Potongan Kode Controller Tampil Master Data Jenis Kendaraan

Fungsi pada gambar 3.19 untuk menampilkan semua data jenis kendaraan dengan

memanggil fungsi service menampilkan data jenis kendaraan, variabel

$Mkendaraan memanggil function service getMKendaraan dan mengambil seluruh

data yang ada pada master data jenis kendaraan lalu ditampilkan dalam bentuk json

yang kemudian ditampilkan pada tabel di halaman awal jenis kendaraan.

Gambar 3.20 Potongan Kode Controller Hapus Master Data Jenis Kendaraan

Fungsi pada gambar 3.20 untuk melakukan hapus data jenis kendaraan dengan

memanggil fungsi service detail dan hapus jenis kendaraan. Melalui function

deletejKendaraan yang id terpilih. Variabel $MKendaraan mengambil data yang

ada pada master data dengan memanggil function service getDetailMKendaraan

sesuai dengan variabel id-nya. Setelah mendapatkan idnya lalu dijalankan function

service deletejKendaraan. Jika sukses, maka redirect ke halaman awal jenis

kendaraan. Untuk menampilkan detail dan mengubah data jenis kendaraan

membutuhkan kode dibawah ini.

40


Gambar 3.21 Potongan Kode Controller Detail Master Data Jenis Kendaraan

Fungsi pada gambar 3.21 untuk mengambil data jenis kendaraan berdasarkan id

yang dipilih dengan memanggil fungsi service detail data jenis kendaraan. Variabel

$MKendaraan mengambil data yang ada pada master data dengan memanggil

function service getDetailMKendaraan sesuai dengan variabel id-nya dan

ditampilkan sesuai dengan textboxnya masing-masing pada halaman detail jenis

kendaraan.

Gambar 3.22 Potongan Kode Controller Update Master Data Jenis Kendaraan

Fungsi pada gambar 3.22 adalah untuk mengubah data jenis kendaraan dengan

memanggil fungsi service ubah data jenis kendaraan. Data yang sudah diisi pada

form harus divalidasi pada variabel $rules dengan data dari request yang diisi.

Variabel $MKendaraan mengambil data yang ada pada master data dengan

memanggil function web service getDetailMKendaraan sesuai dengan variabel id-

nya. Setelah mendapatkan idnya lalu dijalankan function service updatejKendaraan.

Jika sukses, maka redirect ke halaman awal jenis kendaraan.

41


b. Implementasi Data Jenis Tabrakan

Pada implementasi data jenis tabrakan memanggil fungsi controller master tabrakan

di microservice kecelakaan. Untuk menyimpan dan memunculkan data jenis

tabrakan membutuhkan kode dibawah ini.

Gambar 3.23 Potongan Kode Controller Insert Master Data Jenis Tabrakan

Fungsi pada gambar 3.23 adalah untuk menambah data jenis tabrakan dengan

memanggil fungsi service menambah data jenis tabrakan. Data yang sudah diisi

pada form harus divalidasi dengan variabel $rules lalu data yang sudah disimpan

pada variabel $MTabrakan kemudian disimpan ke database melalui service

function insertjTabrakan. Jika sukses maka akan langsung redirect ke halaman

utama data jenis tabrakan.

Gambar 3.24 Potongan Kode Controller Show Master Data Jenis Tabrakan

Fungsi pada gambar 3.24 untuk menampilkan semua data jenis tabrakan dengan

memanggil fungsi service menampilak data jenis tabrakan, variabel $MTabrakan

memanggil function getMTabrakan dari service dan mengambil seluruh data yang

ada pada master data jenis tabrakan lalu ditampilkan dalam bentuk json yang

kemudian ditampilkan pada tabel di halaman awal jenis tabrakan.

42


Gambar 3.25 Potongan Kode Controller Delete Master Data Jenis Tabrakan

Fungsi pada gambar 3.25 untuk melakukan fungsi hapus data jenis tabrakan dengan

memanggil fungsi service menghapus jenis tabrakan. Melalui function

deleteMTabrakan yang id terpilih. Variabel $MTabrakan mengambil data yang ada

pada master data dengan memanggil function service getDetailMTabrakan sesuai

dengan variabel id-nya. Setelah mendapatkan idnya lalu dijalankan function service

deleteMTabrakan. Jika sukses, maka redirect ke halaman awal jenis tabrakan.

Untuk menampilkan dan mengubah data jenis tabrakan membutuhkan kode

dibawah ini.

Gambar 3.26 Potongan Kode Controller Detail Master Data Jenis Tabrakan

Fungsi pada gambar 3.26 untuk mengambil data jenis tabrakan berdasarkan id yang

dipilih dengan memanggil fungsi service menampilkan detail jenis tabrakan.

Variabel $MTabrakan mengambil data yang ada pada master data dengan

memanggil function service getDetailMTabrakan sesuai dengan variabel id-nya dan

ditampilkan sesuai dengan textboxnya masing-masing pada halaman detail jenis

tabrakan.

43


Gambar 3.27 Potongan Kode Controller Update Master Data Jenis Tabrakan

Fungsi pada gambar 3.27 adalah untuk mengubah data jenis tabrakan dengan

memanggil fungsi service mengambil detail dan menghapus jenis tabrakan. Data

yang sudah diisi pada form harus divalidasi pada variabel $rules dengan data dari

request yang diisi. Variabel $MTabrakan mengambil data yang ada pada master

data dengan memanggil function service getDetailMTabrakan sesuai dengan

variabel id-nya. Setelah mendapatkan idnya lalu dijalankan function service

updateMTabrakan. Jika sukses, maka redirect ke halaman awal jenis tabrakan.

c. Implementas Data Jenis Kondisi Korban

Pada implementasi data jenis tabrakan memanggil fungsi controller master kondisi

korban di microservice kecelakaan. Untuk menyimpan dan memunculkan data

kondisi korban membutuhkan kode dibawah ini.

Gambar 3.28 Potongan Kode Controller Insert Master Data Jenis Kondisi Korban

Fungsi pada gambar 3.28 adalah untuk menambah data master jenis kondisi korban

dengan memanggil fungsi service menambah data kondisi korban. Data yang sudah

44



disimpan pada variabel $MKondisi kemudian disimpan ke database melalui service

function insertKKorban. Jika sukses maka akan langsung redirect ke halaman

utama data kondisi korban.

Gambar 3.29 Potongan Kode Controller Show Master Data Jenis Kondisi Korban

Fungsi pada gambar 3.29 untuk menampilkan detail data jenis kondisi korban

dengan memanggil fungsi service menampilkan detail kondisi korban, variabel

$MKondisi memanggil function getDetailMKondisi dari web service dan

mengambil seluruh data yang ada pada master data kondisi korban lalu ditampilkan

dalam bentuk json yang kemudian ditampilkan pada tabel di halaman awal detail

kondisi korban.

Gambar 3.30 Potongan Kode Controller Delete Master Data Kondisi Korban

Fungsi pada gambar 3.30 untuk melakukan fungsi hapus data dengan memanggil

fungsi service mengambil detail dan menghapus data kondisi korban. Melalui

function deleteMKondisi yang id terpilih. Variabel $MKondisi mengambil data

yang ada pada master data dengan memanggil function web service

getDetailMKondisi sesuai dengan variabel id-nya. Setelah mendapatkan idnya lalu

dijalankan function web service deleteMKondisi. Jika sukses, maka redirect ke

45


halaman awal kondisi korban. Untuk menampilkan dan mengubah data jenis

kondisi korban membutuhkan kode dibawah ini.

Gambar 3.31 Potongan Kode Controller Detail Jenis Kondisi Korban

Fungsi pada gambar 3.31 untuk mengambil data jenis kondisi korban berdasarkan

id yang dipilih dengan memanggil fungsi service menampilkan detail kondisi

korban. Variabel $MKondisi mengambil data yang ada pada master data dengan

memanggil function service getDetailMKondisi sesuai dengan variabel id-nya dan

ditampilkan sesuai dengan textboxnya masing-masing pada halaman detail kondisi

korban.

Gambar 3.32 Potongan Kode Controller Update Jenis Kondisi Korban

Fungsi pada gambar 3.32 adalah untuk mengubah data jenis kondisi korban dengan

memanggil fungsi service mengambil detail dan mengubah data kondisi korban.

Data yang sudah diisi pada form harus divalidasi pada variabel $rules dengan data

dari request yang diisi. Variabel $MKondisi mengambil data yang ada pada master

data dengan memanggil function web service getDetailMKondisi sesuai dengan

46


variabel id-nya. Setelah mendapatkan idnya lalu dijalankan function service

updateMKondisi. Jika sukses, maka redirect ke halaman awal jenis kondisi korban.

d. Implementasi Data Pasal Pelanggaran

Pada implementasi data jenis tabrakan memanggil fungsi controller master pasal

pelanggaran di microservice tilang. Untuk menyimpan dan memunculkan data

pasal pelanggaran kode dibawah ini.

Gambar 3.33 Potongan Kode Controller Insert Master Data Pasal Pelanggaran

Fungsi pada gambar 3.33 adalah untuk menambah data master pasal pelanggaran

dengan memanggil fungsi service menambah data pasal pelanggaran. Data yang

sudah diisi pada form harus divalidasi dengan variabel $rules lalu data yang sudah

disimpan pada variabel $pasal kemudian disimpan ke database melalui service

function insertjPasalPelanggaran. Jika sukses maka akan langsung redirect ke

halaman utama data pasal pelanggaran.

Gambar 3.34 Potongan Kode Controller Show Master Data Pasal Pelanggaran

47


Fungsi pada gambar 3.34 untuk menampilkan semua data pasal pelanggaran dengan

memanggil fungsi service menampilkan data pasal pelanggaran, variabel $pasal

memanggil function getMPasal dari service dan mengambil seluruh data yang ada

pada master data pasal pelanggaran lalu ditampilkan dalam bentuk json array yang

kemudian ditampilkan pada tabel di halaman awal pasal pelanggaran.

Gambar 3.35 Potongan Kode Controller Website Delete Master Data Pasal Pelanggaran

Fungsi pada gambar 3.35 untuk melakukan fungsi hapus data dengan memanggil

fungsi service menghapus data pasal pelanggaran. Melalui function

deletePPelanggaran yang id terpilih. Variabel $pasal mengambil data yang ada pada

master data dengan memanggil function service getDetailPPelanggaran sesuai

dengan variabel id-nya. Setelah mendapatkan idnya lalu dijalankan function service

deletePPelanggaran. Jika sukses, maka redirect ke halaman awal pasal pelanggaran.

Untuk menampilkan dan mengubah data pasal pelanggaran membutuhkan kode

dibawah ini.

Gambar 3.36 Potongan Kode Controller Detail Master Data Pasal Pelanggaran

Fungsi pada gambar 3.36 untuk mengambil data pasal pelanggaran berdasarkan id

yang dipilih dengan memanggil fungsi menampilkan detail pasal pelanggaran.

48


Variabel $pasal mengambil data yang ada pada master data dengan memanggil

function service getDetailPPelanggaran sesuai dengan variabel id-nya dan

ditampilkan sesuai dengan textboxnya masing-masing pada halaman detail pasal

pelanggaran.

Gambar 3.37 Potongan Kode Controller Update Data Pasal Pelanggaran

Fungsi pada gambar 3.37 adalah untuk mengubah data pasal pelanggaran dengan

memanggil fungsi service mengambil detail data dan menghapus data pasal

pelanggaran. Data yang sudah diisi pada form harus divalidasi pada variabel $rules

dengan data dari request yang diisi. Variabel $pasal mengambil data yang ada pada

master data dengan memanggil function web service getDetailPPelanggaran sesuai

dengan variabel id-nya. Setelah mendapatkan idnya lalu dijalankan function web

service updatePPelanggaran. Jika sukses, maka redirect ke halaman awal pasal

pelanggaran.

e. Implementasi Data Petugas

Pada implementasi data jenis tabrakan memanggil fungsi controller master pasal

pelanggaran di microservice user. Untuk menyimpan dan memunculkan data

petugas membutuhkan kode dibawah ini.

49


Gambar 3.38 Potongan Kode Controller Insert Data Petugas

Fungsi pada gambar 3.38 adalah untuk menambah data petugas dengan memanggil

fungsi service menambah data petugas. Data yang sudah diisi pada form harus

divalidasi dengan variabel $rules lalu data yang sudah disimpan pada variabel $user

kemudian disimpan ke database melalui service function insertPetugas. Jika sukses

maka akan langsung redirect ke halaman utama data petugas.

Gambar 3.39 Potongan Kode Controller Show Data Petugas

50


Fungsi pada gambar 3.39 untuk menampilkan semua data petugas dengan

memanggil fungsi service menampilkan data petugas, variabel $users memanggil

function getPetugasAll dari web service dan mengambil seluruh data yang ada pada

master data petugas lalu ditampilkan dalam bentuk json yang kemudian ditampilkan

pada tabel di halaman awal petugas. Untuk menampilkan dan mengubah data

seperti gambar 3.49 membutuhkan kode dibawah ini.

Gambar 3.40 Potongan Kode Controller Website Detail Data Petugas

Fungsi pada gambar 3.40 untuk mengambil data petugas berdasarkan id yang

dipilih dengan memanggil fungsi service menampilkan detail data petugas.

Variabel $users mengambil data yang ada pada master data dengan memanggil

function web service detailPetugas sesuai dengan variabel id-nya dan ditampilkan

sesuai dengan textboxnya masing-masing pada halaman detail petugas.

51


Gambar 3.41 Potongan Kode Controller Update Status Petugas

Fungsi pada gambar 3.41 adalah untuk mengubah data petugas dengan memanggil

mengambil detail dan mengubah data petugas. Data yang sudah diisi pada form

harus divalidasi pada variabel $rules dengan data dari request yang diisi. Variabel

$users mengambil data yang ada pada master data dengan memanggil function

service getPetugas sesuai dengan variabel id-nya. Setelah mendapatkan idnya lalu

dijalankan function service updatePetugas. Jika sukses, maka redirect ke halaman

awal data petugas.

f. Implementasi Data Kecelakaan

Pada implementasi data kecelakaan memanggil fungsi controller kecelakaan, jenis

kendaraan, jenis tabrakan, kondisi korban, jalan, kendaraan dan korban di

microservice kecelakaan. Untuk menyimpan dan memunculkan data membutuhkan

kode dibawah ini.

52


Gambar 3.42 Potongan Kode Controller Insert Data Kecelakaan

Fungsi pada gambar 3.42 adalah untuk menambah data kecelakaan dengan

memanggil fungsi service menambah data kecelakaan. Data yang sudah diisi pada

form harus divalidasi dengan variabel $rules lalu data yang sudah disimpan pada

variabel $kcl kemudian disimpan ke database melalui service function insertLaka.

Jika sukses maka akan langsung redirect ke halaman utama data kecelakaan.

Gambar 3.43 Potongan Kode Controller Website Show Data Kecelakaan

53


Fungsi pada gambar 3.43 untuk menampilkan semua data kecelakaan dengan

memanggil fungsi service menampilkan data kecelakaan, menampilkan data jalan

dan menampilkan data jenis tabrakan. Variabel $kcl memanggil service function

getKecelakaan, variabel $jalan memanggil service function getJalan, variabel

$tabrakan memanggil service function getMTabrakan dari web service dan

mengambil seluruh data yang ada pada master data jenis tabrakan, data jalan, dan

data kecelakaan. Lalu ditampilkan dalam bentuk json yang kemudian ditampilkan

pada tabel di halaman awal kecelakaan. Untuk menampilkan export data kecelakaan


Gambar 3.44 Potongan Kode Controller Export Data Kecelakaan

Fungsi pada gambar 3.44 untuk export data kecelakaan ke bentuk PDF berdasarkan

id yang dipilih dengan memanggil fungsi service export data kecelakaan,

menampilkan data jalan, menampilkan data jenis kendaraan dan menampilkan data

kondisi korban. Variabel $kcl memanggil function web service exportKecelakaan

berdasarkan id yang dipilih, $jalan, $tabrakan dan $kondisi mengambil data dengan

memanggil function service getMKendaraan, getJalan, getMTabrakan dan

ditampilkan sesuai dengan format pada tampilan PDF halaman export data

kecelakaan. Untuk menampilkan dan mengubah data membutuhkan kode dibawah

ini.

54


Gambar 3.45 Potongan Kode Controller Detail Data Kecelakaan

Fungsi pada gambar 3.45 untuk mengambil data kecelakaan berdasarkan id yang

dipilih dengan memanggil menampilkan detail data kecelakaan, menampilkan data

jalan dan menampilkan data jenis tabrakan. Variabel $kcl, $jalan, $tabrakan

mengambil data dengan memanggil function web service getDetailMKendaraan,

getJalan, getMTabrakan sesuai dengan variabel id kecelakaan dan ditampilkan

sesuai dengan textboxnya masing-masing pada halaman detail data kecelakaan.

Gambar 3.46 Potongan Kode Controller Update Data Kecelakaan

55


Fungsi pada gambar 3.46 adalah untuk mengubah data kecelakaan dengan

memanggil fungsi service mengambil detail dan mengubah data kecelakaan. Data


request yang diisi. Variabel $kcl mengambil data dengan memanggil function web

service getDetailKecelakaan sesuai dengan variabel id-nya. Setelah mendapatkan

idnya lalu dijalankan function web service updateKecelakaan. Jika sukses, maka

redirect ke halaman awal data kecelakaan.

g. Implementasi Data Kendaraan Terlibat Kecelakaan

Pada implementasi data kendaraan yang terlibat kecelakaan memanggil fungsi

controller kendaraan, kecelakaan dan jenis kendaraan di microservice kecelakaan.

Untuk menyimpan dan memunculkan data pada tabel seperti gambar 3.60 seperti

dibawah ini, membutuhkan kode seperti berikut.

Gambar 3.47 Potongan Kode Controller Website Insert Data Kendaraan

Fungsi pada gambar 3.47 adalah untuk menambah data kendaraan dengan

memanggil fungsi service menambah data kendaraan. Data yang sudah diisi pada

form harus divalidasi dengan variabel $rules lalu data yang sudah disimpan pada

variabel $kstnk kemudian disimpan ke database melalui service function

insertKendaraan. Jika sukses maka akan langsung redirect ke halaman utama data

kendaraan.

56


Gambar 3.48 Potongan Kode Controller Website Show Data Kendaraan

Fungsi pada gambar 3.48 untuk menampilkan semua data kendaraan dengan

memanggil fungsi service menampilkan data kendaraan, menampilkan data

kecelakaan dan menampilkan data jenis kendaraan. Variabel $ksntk memanggil

service function getKendaraan, variabel $laka memanggil service function

getKecelakaan, variabel $jkendaraan memanggil service function getMKendaraan

dari web service dan mengambil seluruh data yang ada pada master data jenis

kendaraan, data kecelakaan, dan data kendaraan. Lalu ditampilkan dalam bentuk

json array yang kemudian ditampilkan pada tabel di halaman awal kendaraan.

Untuk menampilkan dan mengubah data kendaraan membutuhkan kode dibawah

ini.

Gambar 3.49 Potongan Kode Controller Website Detail Data Kendaraan

Fungsi pada gambar 3.49 untuk mengambil data kendaraan berdasarkan id yang

dipilih dengan memanggil fungsi service menampilkan detail kendaraan,

57


menampilkan data kecelakaan dan menampilkan jenis kendaraan. Variabel $kstnk,

$laka, $jkendaraan mengambil data dengan memanggil function web service

getDetailSTNK, getKecelakaan, getMKendaraan sesuai dengan variabel id

kendaraan dan ditampilkan sesuai dengan textboxnya masing-masing pada halaman

detail data kendaraan.

Gambar 3.50 Potongan Kode Controller Website Update Data Kendaraan

Fungsi pada gambar 3.50 adalah untuk mengubah data kendaraan dengan

memanggil fungsi service mengambil detail dan mengubah data kendaraan. Data


request yang diisi. Variabel $kstnk mengambil data yang ada pada master data

dengan memanggil function web service getDetailSTNK sesuai dengan variabel id-

nya. Setelah mendapatkan idnya lalu dijalankan function web service

updateKendaraan. Jika sukses, maka redirect ke halaman awal jenis kendaraan.

h. Implementasi Data Korban Kecelakaan

Pada implementasi data korban kecelakaan memanggil fungsi controller korban,

kondisi korban, kendaraan dan kecelakaan di microservice kecelakaan. Untuk

menyimpan dan memunculkan data pada tabel seperti gambar 3.66 seperti dibawah

ini, membutuhkan kode seperti berikut.

58


Gambar 3.51 Potongan Kode Controller Insert Data Korban

Fungsi pada gambar 3.51 adalah untuk menambah data korban. Data yang sudah


disimpan pada variabel $orang kemudian disimpan ke database melalui service

function insertKorban. Jika sukses maka akan langsung redirect ke halaman utama

data korban.

Gambar 3.52 Potongan Kode Controller Show Data Korban

59


Fungsi pada gambar 3.52 untuk menampilkan semua data korban dengan

memanggil service menampilkan data korban, menampilkan data kecelakaan,

menampilkan data kendaraan dan menampilkan data kondisi korban. Variabel

$korban memanggil service function getKorban, variabel $stnk memanggil service

function getKendaraan, variabel $laka memanggil service function getKecelakaan,

variabel $kondisi memanggil service function getMKondisi dari service dan

mengambil seluruh data yang ada pada master data jenis kondisi korban, data

kecelakaan, dan data kendaraan. Lalu ditampilkan dalam bentuk json yang

kemudian ditampilkan pada tabel di halaman awal kecelakaan.Untuk menampilkan

dan mengubah data korban kecelakaan membutuhkan kode dibawah ini.

Gambar 3.53 Potongan Kode Controller Detail Data Korban Kecelakaan

Fungsi pada gambar 3.53 untuk mengambil data korban berdasarkan id yang dipilih

dengan memanggil fungsi service menampilkan detail data korban dengan

memanggil service menampilkan data korban, menampilkan data kecelakaan,

menampilkan data kendaraan dan menampilkan data kondisi korban.. Variabel

$kcl, $orang, $laka, $kondisi mengambil data dengan memanggil function service

getDetailKorban, getKecelakaan, getKendaraan, getMKondisi sesuai dengan

variabel id kecelakaan dan ditampilkan sesuai dengan textboxnya masing-masing

pada halaman detail detail orang.

60


Gambar 3.54 Potongan Kode Controller Update Data Korban Kecelakaan

Fungsi pada gambar 3.54 adalah untuk mengubah data korban kecelakaan dengan

memanggil fungsi service mengambil detail dan mengubah data korban kecelakaan.

Data yang sudah diisi pada form harus divalidasi pada variabel $rules dengan data

dari request yang diisi. Variabel $orang mengambil data dengan memanggil

function service getDetailKorban sesuai dengan variabel id-nya. Setelah

mendapatkan idnya lalu dijalankan function service updateKorban. Jika sukses,

maka redirect ke halaman awal data korban.

i. Implementasi Surat Operasi

Pada implementasi data korban kecelakaan memanggil fungsi controller surat

operasi di microservice kecelakaan. Untuk menyimpan dan memunculkan surat

operasi, membutuhkan kode seperti berikut.

61


Gambar 3.55 Potongan Kode Controller Insert Surat Operasi

Fungsi pada gambar 3.55 adalah untuk menambah surat operasi dengan memanggil

fungsi service menambah data surat operasi. Data yang sudah diisi pada form harus

divalidasi dengan variabel $rules lalu data yang sudah disimpan pada variabel

$soperasi kemudian disimpan ke database melalui service function insertSOperasi.

Jika sukses maka akan langsung redirect ke halaman utama data surat operasi.

Gambar 3.56 Potongan Kode Controller Show Surat Operasi

Fungsi pada gambar 3.56 untuk menampilkan semua data surat operasi dengan

memanggil fungsi service menampilkan data surat operasi, variabel $soperasi

memanggil function getSOPerasi dari service dan mengambil seluruh data lalu

ditampilkan dalam bentuk json array yang kemudian ditampilkan pada tabel di

halaman awal surat operasi. Untuk menampilkan dan mengubah data surat operasi


62


Gambar 3.57 Potongan Kode Controller Website Detail Surat Operasi

Fungsi pada gambar 3.57 untuk mengambil data surat operasi berdasarkan id yang

dipilih dengan memanggil fungsi service menampilkan detail surat operasi.

Variabel $soperasi mengambil data dengan memanggil function service

getDetailSOperasi sesuai dengan variabel id-nya dan ditampilkan sesuai dengan

textboxnya masing-masing pada halaman detail surat operasi.

Gambar 3.58 Potongan Kode Controller Website Update Surat Operasi

Fungsi pada gambar 3.58 adalah untuk mengubah data surat operasi dengan

memanggil fungsi service menampilkan detail dan mengubah surat operasi. Data


request yang diisi. Variabel $soperasi mengambil data dengan memanggil function

web service getDetailSOperasi sesuai dengan variabel id-nya. Setelah mendapatkan

idnya lalu dijalankan function service updateSOperasi. Jika sukses, maka redirect

ke halaman awl surat operasi.

63


BAB IV

PEMBAHASAN

4.1 Pengujian

Tujuan dari pengujian ini agar sistem yang digunakan oleh pengguna dapat berjalan

secara optimal dan memenuhi rangkaian kebutuhan pengguna, serta untuk

mengetahui apakah masukan dan keluaran yang dihasilkan sistem sudah sesuai alur

yang ada.

4.2 Deskripsi Pengujian

Setelah selesai pembuatan suatu sistem langkah berikutnya yang dilakukan yaitu

pengujian sistem. Pengujian memiliki tujuan untuk memastikan bahwa sistem yang

dibangun telah sesuai dengan kebutuhan yang sebelumnya telah ditentukan.

Pengujian dilakukan untuk menjamin kualitas dari sistem serta mengetahui apabila

terjadinya kesalahan yang terdapat pada sistem yang dirancang. Dengan

ditemukannya kesalahan-kesalahan pada sistem maka dapat dilakukan perbaikan

sistem. Pengujian black box digunakan agar dapat mengetahui fungsional sistem

dan kesesuaian dari data masukan hingga keluaran yang dihasilkan dari sistem yang

telah dirancang dan pengujian integration digunakan untuk mengetahui status log

melalui layanan API pada saat pengujian dan menampilkan response yang didapat

pada saat melakukan request.

4.3 Prosedur Pengujian

Prosedur pengujian yang dilakukan adalah dengan menggunakan black box testing

dan integration testing. Berikut penjelasan dari prosedur pengujian.

A. Black Box Testing

Pada tabel 14 merupakan daftar rencana pengujian pada sistem informasi atlantas

dengan menggunakan black box testing

64


Tabel 14. Rencana Pengujian Black Box Testing

No Item Uji Butir Uji Jenis

Pengujian

1

Autentfikasi

Melakukan Login Black Box

Melakukan Logout Black Box

2

Menu Data

Master

Admin Melihat Data Master Black Box

Admin Menambah Data Master Black Box

Admin Mengubah Data Master Black Box

Admin Menghapus Data Master Black Box

3

Menu Data

Petugas

Admin Dapat Melihat Data Petugas Black Box

Admin Dapat Menambah Data Petugas Black Box

Admin Dapat Mengubah Data Petugas Black Box

4

Menu Data

Kecelakaan

Staff Kecelakaan Dapat Melihat Data

Kecelakaan Black Box

Staff Kecelakaan Dapat Menambah Data


Staff Kecelakaan Dapat Mengubah Data


Staff Kecelakaan Dapat Mengexport Data


5

Menu Data

Kendaraan

Staff Kecelakaan Dapat Melihat Data

Kendaraan yang terlibat kecelakaan Black Box



Staff Kecelakaan Dapat Mengubah Data


6

Menu Data

Korban

Staff Kecelakaan Dapat Melihat Data Korban

yang terlibat kecelakaan Black Box


Korban yang terlibat kecelakaan Black Box

65


Staff Kecelakaan Dapat Mengubah Data Korban

yang terlibat kecelakaan Black Box

7 Menu Data

Surat Operasi

Staff Tilang Dapat Melihat Data Surat Operasi Black Box

Staff Tilang Dapat Menambah Surat Operasi Black Box

Staff Tilang Dapat Mengubah Data Surat

Operasi Black Box

B. Integration Testing

Prosedur pengujian ini melibatkan 3 service yaitu API Gateway, Kecelakaan

Service dan Tilang Service dengan menggunakan 2 jenis pengujian yaitu kedua

service dinyalakan dan salah satu service dimatikan / offline. Pengujian dilakukan

untuk mengetahui integrasi antar service dapat terkoneksi dan berfungsi dengan

service yang lain sesuai yang diharapkan (Khoirunnisa, 2019).

4.4 Data Hasil Pengujian

Data hasil pengujian fungsionalitas sistem berupa tabel pengujian per item uji atau

hasil uji dari sistem, tabel terdiri dari dua jenis hasil uji yaitu data normal dan data

salah. Pengujian dilakukan untuk data yang dimasukan sehingga dapat dilihat hasil

dari pengujiannya sesuai dengan yang diharapkan. Jika data yang dimasukan sesuai

dengan harapan. Maka, pada kolom kesimpulan pada tabel pengujian, diberikan

tanda ceklis dalam tanda kurung diterima. Namun, apabila tidak sesuai maka tanda

ceklis akan berada pada tanda kurung ditolak. Data hasil pengujian integration

testing juga berupa uraian pengujian per item dan hasil pengujian yang dilakukan.

4.4.1 Black Box Testing

1. Pengujian Autentifikasi

Pengujian autentifikasi ditunjukkan untuk masuk kesistem dan keluar dari sistem.

Pengujian ini berisi pengujian login yang skenarionya terhadap semua role ketika

melakukan login dan pengujian logout yang skenarionya untuk keluar dari sistem.

66


Tabel 15. Pengujian Login

No

Hasil Pengujian (Data Normal)

Data Masukkan Harapan Hasil Uji Kesimpulan

A.1

Mengetik NRP

dan Password

kemudian klik

login

Sistem menerima akses

login dan kemudian

menampilkan halaman

yang dituju

Penguna

berhasil login

dan

menampilkan

halaman yang

dituju

[√] Diterima

[] Ditolak

Hasil Pengujian (Data Salah)

No Data Masukkan Harapan Hasil Uji Kesimpulan

A.2

NRP dan

password tidak

diisi atau kosong

kemudian klik

tombol login

Sistem akan menolak

dan menampilkan pesan

pada textbox “Harap isi

Bidang ini”

Sistem

menolak dan

menampilkan

pesan pada

textbox “Harap

isi Bidang ini”

[√] Diterima

[] Ditolak

A.3

NRP atau

password tidak

sesuai kemudian

klik tombol login

Sistem akan menolak


error “These credentials

do not match our

records”

Sistem

menolak dan

menampilkan

pesan error

“These

credentials do

not match our

records”

[√] Diterima

[] Ditolak

67


Tabel 16. Pengujian Logout

No



A.4

Memilih tombol

logout pada

header

Pengguna dapat keluar

dari sistem dan

kembali ke halaman

login

Pengguna keluar

dari sistem dan

kembali ke

halaman login

[√] Diterima

[] Ditolak

2. Pengujian Menu Data Master

Pengujian menu master ditunjukkan kepada admin untuk melakukan proses

melihat, menambah, mengubah dan menghapus data master yang akan digunakan

oleh pengguna lain.

Tabel 17. Pengujian Melihat Data Master

No



B.1

Admin memilih

menu jenis

kecelakaan pada

management

kecelakaan.

Sistem akan

menampilkan halaman

utama jenis

kecelakaan dan data

table

Sistem

menampilkan

halaman jenis

kecelakaan

utama

[√] Diterima

[] Ditolak

B.2

Admin memilih

menu jenis

tabrakan pada

management

kecelakaan.

Sistem akan

menampilkan halaman

utama jenis tabrakan

dan data table

Sistem

menampilkan

halaman jenis

kecelakaan

tabrakan

[√] Diterima

[] Ditolak

B.3

Admin memilih

menu kondisi

korban pada

management

kecelakaan.

Sistem akan

menampilkan halaman

kondisi korban dan

data table

Sistem

menampilkan

halaman kondisi

korban

[√] Diterima

[] Ditolak

68


B.4

Admin memilih

menu nama jalan

pada management

kecelakaan.

Sistem akan

menampilkan halaman

nama jalan dan data

table

Sistem

menampilkan

halaman nama

jalan

[√] Diterima

[] Ditolak

B.5

Admin memilih

menu pasal

pelanggaran pada

management

tilang.

Sistem akan

menampilkan halaman

pasal pelanggaran dan

data table

Sistem

menampilkan

halaman pasal

pelanggaran

[√] Diterima

[] Ditolak

Tabel 18. Pengujian Menambah Data Master Kecelakaan

No


Data

Masukkan Harapan Hasil Uji Kesimpulan

B.6

Admin mengisi

form jenis

kecelakaan pada

halaman utama

jenis kecelakaan

Sistem dapat

menyimpan data ke

database dan sistem

menampilkan data

jenis kecelakaan

yang telah

dimasukkan

Sistem menyimpan

ke database dan

menampilkan data

jenis kecelakaan

yang telah

dimasukkan

[√] Diterima

[] Ditolak

B.7

Admin mengisi

form jenis

tabrakan pada

halaman utama

jenis tabrakan

Sistem dapat

menyimpan data ke

database dan sistem

menampilkan data

yang telah

dimasukkan

Sistem menyimpan

ke database dan

menampilkan data

jenis tabrakan yang

telah dimasukkan

[√] Diterima

[] Ditolak

B.8

Admin mengisi

form kondisi

korban pada

Sistem dapat

menyimpan data ke

database dan sistem

menampilkan data

Sistem menyimpan

ke database dan

menampilkan data

kondisi korban

[√] Diterima

[] Ditolak

69


halaman utama

kondisi korban

kondisi korban yang

telah dimasukkan

yang telah

dimasukkan

B.9

Admin mengisi

form nama jalan

pada halaman

utama nama

jalan

Sistem dapat

menyimpan data ke

database dan sistem

menampilkan data

nama jalan yang

telah dimasukkan

Sistem menyimpan

ke database dan

menampilkan data

nama jalan yang

telah dimasukkan

[√] Diterima

[] Ditolak

B.10

Admin mengisi

form pasal

pelanggaran

pada halaman

utama pasal

pelanggaran

Sistem dapat

menyimpan data ke

database dan sistem

menampilkan data

pasal pelanggaran

yang telah

dimasukkan

Sistem menyimpan

ke database dan

menampilkan data

pasal pelanggaran

telah dimasukkan

[√] Diterima

[] Ditolak


Data


B.11

Admin memilih

tombol tambah

sementara form

jenis kecelakaan

dibiarkan

kosong

Sistem akan

menolak dan

menampilkan pesan

“Harap isi bidang

ini” pada textbox

yang kosong

Sistem menolak

dan menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang

kosong

[√] Diterima

[] Ditolak

B.12

Admin memilih

tombol tambah

sementara form

jenis tabrakan

dibiarkan

kosong

Sistem akan

menolak dan

menampilkan pesan

“Harap isi bidang

ini” pada textbox

yang kosong

Sistem menolak

dan menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang

kosong

[√] Diterima

[] Ditolak

70


B.13

Admin memilih

tombol tambah

sementara form

Kondisi korban

dibiarkan

kosong

Sistem akan

menolak dan

menampilkan pesan

“Harap isi bidang

ini” pada textbox

yang kosong

Sistem menolak

dan menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang

kosong

[√] Diterima

[] Ditolak

B.14

Admin memilih

tombol tambah

sementara form

nama jalan

dibiarkan

kosong

Sistem akan

menolak dan

menampilkan pesan

“Harap isi bidang

ini” pada textbox

yang kosong

Sistem menolak

dan menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang

kosong

[√] Diterima

[] Ditolak

B.15

Admin memilih

tombol tambah

sementara form

pasal

pelanggaran

dibiarkan

kosong

Sistem akan

menolak dan

menampilkan pesan

“Harap isi bidang

ini” pada textbox

yang kosong

Sistem menolak

dan menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang

kosong

[√] Diterima

[] Ditolak

Tabel 19. Pengujian Mengubah Data Master

No


Data


B.16

Admin memilih

detail salah satu

data jenis

kendaraan dan

mengisi

perubahan data

Sistem dapat

menyimpan data ke

database dan sistem

menampilkan data

jenis kendaraan yang

telah diubah

Sistem menyimpan

ke database dan

menampilkan data

jenis kendaraan

yang diubah

[√] Diterima

[] Ditolak

71


B.17

Admin memilih

detail salah satu

data jenis

tabrakan dan

mengisi

perubahan data

Sistem dapat

menyimpan data ke

database dan sistem

menampilkan data

jenis tabrakan yang

telah diubah

Sistem menyimpan

ke database dan

menampilkan data

jenis tabrakan yang

diubah

[√] Diterima

[] Ditolak

B.18

Admin memilih

detail salah satu

data kondisi

korban dan

mengisi

perubahan data

Sistem dapat

menyimpan data ke

database dan sistem

menampilkan data

kondisi korban yang

telah diubah

Sistem menyimpan

ke database dan

menampilkan data

kondisi korban

telah diubah

[√] Diterima

[] Ditolak

B.19

Admin memilih

detail salah satu

data nama jalan

dan mengisi

perubahan data

Sistem dapat

menyimpan data ke

database dan sistem

menampilkan data

nama jalan yang

telah diubah

Sistem menyimpan

ke database dan

menampilkan data

nama jalan yang

telah diubah

[√] Diterima

[] Ditolak

B.20

Admin memilih

detail salah satu

data pasal

pelanggaran dan

mengisi

perubahan data

Sistem dapat

menyimpan data ke

database dan sistem

menampilkan data

pasal pelanggaran

yang telah diubah

Sistem menyimpan

ke database dan

menampilkan data

pasal pelanggaran

yang telah diubah

[√] Diterima

[] Ditolak


Data


B.21

Admin memilih

tombol ubah

sementara form

detail jenis

Sistem akan

menolak dan

menampilkan pesan

Sistem menolak

dan menampilkan

pesan “At least one

value must change”

[√] Diterima

[] Ditolak

72


kecelakaan

diberi nilai yang

sama

“At least one value

must change”

B.22

Admin memilih

tombol ubah

sementara form

detail jenis

kecelakaan

dibiarkan

kosong

Sistem akan

menolak dan

menampilkan pesan

“Harap isi bidang

ini” pada textbox

yang kosong

Sistem menolak

dan menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang

kosong

[√] Diterima

[] Ditolak

B.23

Admin memilih

tombol ubah

sementara form

detail jenis

tabrakan diberi

nilai yang sama

Sistem akan

menolak dan

menampilkan pesan


must change”

Sistem menolak

dan menampilkan



[√] Diterima

[] Ditolak

B.24

Admin memilih

tombol ubah

sementara form

detail jenis

tabrakan

dibiarkan

kosong

Sistem akan

menolak dan

menampilkan pesan

“Harap isi bidang

ini” pada textbox

yang kosong

Sistem menolak

dan menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang

kosong

[√] Diterima

[] Ditolak

B.25

Admin memilih

tombol ubah

sementara form

detail kondisi

korban tabrakan

diberi nilai yang

sama

Sistem akan

menolak dan

menampilkan pesan


must change”

Sistem menolak

dan menampilkan



[√] Diterima

[] Ditolak

73


B.26

Admin memilih

tombol ubah

sementara form

detail kondisi

korban

dibiarkan

kosong

Sistem akan

menolak dan

menampilkan pesan

“Harap isi bidang

ini” pada textbox

yang kosong

Sistem menolak

dan menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang

kosong

[√] Diterima

[] Ditolak

B.27

Admin memilih

tombol ubah

sementara form

detail nama

jalan diberi nilai

yang sama

Sistem akan

menolak dan

menampilkan pesan


must change”

Sistem menolak

dan menampilkan



[√] Diterima

[] Ditolak

B.28

Admin memilih

tombol ubah

sementara form

detail nama

jalan dibiarkan

kosong

Sistem akan

menolak dan

menampilkan pesan

“Harap isi bidang

ini” pada textbox

yang kosong

Sistem menolak

dan menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang

kosong

[√] Diterima

[] Ditolak

B.29

Admin memilih

tombol ubah

sementara form

detail pasal

pelanggaran

diberi nilai yang

sama

Sistem akan

menolak dan

menampilkan pesan


must change”

Sistem menolak

dan menampilkan



[√] Diterima

[] Ditolak

B.30

Admin memilih

tombol ubah

sementara form

detail pasal

pelanggaran

Sistem akan

menolak dan

menampilkan pesan

“Harap isi bidang

Sistem menolak

dan menampilkan

pesan “Harap isi

bidang ini” pada

[√] Diterima

[] Ditolak

74


dibiarkan

kosong

ini” pada textbox

yang kosong

textbox yang

kosong

Tabel 20. Pengujian Menghapus Data Master

No



B.31

Admin memilih

tombol hapus

pada jenis

kecelakaan yang

dipilih

Sistem akan

menghapus data dan

menampilkan halaman

utama jenis

kecelakaan

Sistem

menghapus data

dan

menampilkan

halaman utama

jenis kecelakaan

[√] Diterima

[] Ditolak

B.32

Admin memilih

tombol hapus

pada jenis

tabrakan yang

dipilih

Sistem akan

menghapus data dan

menampilkan halaman

utama jenis tabrakan

Sistem

menghapus data

dan

menampilkan

halaman utama

jenis tabrakan

[√] Diterima

[] Ditolak

B.33

Admin memilih

tombol hapus

pada kondisi

korban yang

dipilih

Sistem akan

menghapus data dan

menampilkan halaman

utama kondisi korban

Sistem

menghapus data

dan

menampilkan

halaman utama

kondisi korban

[√] Diterima

[] Ditolak

B.34

Admin memilih

tombol hapus

pada nama jalan

yang dipilih

Sistem akan

menghapus data dan

menampilkan halaman

utama nama jalan

Sistem

menghapus data

dan

menampilkan

halaman utama

nama jalan

[√] Diterima

[] Ditolak

75


B.35

Admin memilih

tombol hapus

pada pasal

pelanggaran yang

dipilih

Sistem akan

menghapus data dan

menampilkan halaman

utama pasal

pelanggaran

Sistem

menghapus data

dan

menampilkan

halaman utama

pasal

pelanggaran

[√] Diterima

[] Ditolak

3. Pengujian Menu Data Petugas

Pengujian menu data petugas ditunjukkan kepada admin untuk melakukan proses

melihat, menambah dan mengubah status data petugas.

Tabel 21. Pengujian Melihat Data Petugas

No



C.1

Admin memilih

menu data petugas

pada management

petugas.

Sistem akan

menampilkan halaman

data petugas dan data

table

Sistem

menampilkan

halaman data

petugas

[√] Diterima

[] Ditolak

Tabel 22. Pengujian Menambah Data Petugas

No



C.2

Admin mengisi

form data petugas

pada halaman

utama jenis

tabrakan

Sistem dapat

menyimpan data ke

database dan

sistem

menampilkan data

yang telah

dimasukkan

Sistem menyimpan

data ke database

dan menampilkan

data petugas

[√] Diterima

[] Ditolak



76


C.3

Admin memilih

tombol tambah

sementara form

data petugas

dibiarkan kosong

Sistem akan

menolak dan

menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang

kosong

Sistem menolak

dan menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang

kosong

[√] Diterima

[] Ditolak

Tabel 23. Pengujian Mengubah Data Petugas

No



C.4

Admin memilih

detail salah satu

data petugas dan

mengisi perubahan

status data

Sistem dapat

menyimpan data ke

database dan sistem

menampilkan data

yang telah diubah

Sistem

menyimpan data

ke database dan

menampilkan data

petugas yang

telah diubah

[√] Diterima

[] Ditolak



C.5

Admin memilih

tombol ubah

sementara form

detail data

petugas diberi

nilai yang sama

Sistem akan menolak

dan menampilkan



Sistem menolak

dan menampilkan

pesan “At least

one value must

change”

[√] Diterima

[] Ditolak

C.6

Admin memilih

tombol ubah

sementara form

detail data

petugas dibiarkan

kosong

Sistem akan menolak

dan menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang kosong

Sistem menolak

dan menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang

kosong

[√] Diterima

[] Ditolak

77


4. Pengujian Menu Data Kecelakaan

Pengujian menu data ditunjukkan kepada staff kecelakaan untuk melakukan proses

melihat, menambah dan mengubah data kecelakaan yang terjadi.

Tabel 24. Pengujian Melihat Data Kecelakaan

No


Data Masukkan Harapan Pengamatan Kesimpulan

D.1

Staff kecelakaan

memilih menu data

kecelakaan pada

management

kecelakaan.

Sistem akan

menampilkan

halaman data

kecelakaan dan

data table

Sistem

menampilkan

halaman data

kecelakaan

[√] Diterima

[] Ditolak

Tabel 25. Pengujian Menambah Data Kecelakaan

No



D.2

Staff kecelakaan

mengisi form data

kecelakaan pada

halaman utama

data kecelakaan

Sistem dapat

menyimpan data ke

database dan sistem

menampilkan data

yang telah

dimasukkan

Sistem

menyimpan ke

database dan

menampilkan data

kecelakaan yang

telah dimasukkan

[√] Diterima

[] Ditolak



D.3

Staff kecelakaan

memilih tombol

tambah sementara

form data

kecelakaan

dibiarkan kosong

Sistem akan

menolak dan

menampilkan pesan

“Harap isi bidang

ini” pada textbox

yang kosong

Sistem menolak

dan menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang

kosong

[√] Diterima

[] Ditolak

78


Tabel 26. Pengujian Mengubah Data Kecelakaan

No



D.4

Staff kecelakaan

memilih detail

salah satu data

kecelakaan dan

mengisi

perubahan data

Sistem dapat

menyimpan data ke

database dan sistem

menampilkan data

yang telah diubah

Sistem dapat

menyimpan ke

database dan

menampilkan

data kecelakaan

data telah

diubah

[√] Diterima

[] Ditolak


Data


D.5

Staff kecelakaan

memilih tombol

ubah sementara

form detail data

kecelakaan

diberi nilai yang

sama

Sistem akan

menolak dan

menampilkan pesan


must change”

Sistem menolak

dan menampilkan



[√] Diterima

[] Ditolak

D.6

Staff kecelakaan

memilih tombol

ubah sementara

form detail data

kecelakaan

dibiarkan

kosong

Sistem akan

menolak dan

menampilkan pesan

“Harap isi bidang

ini” pada textbox

yang kosong

Sistem menolak

dan menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang

kosong

[√] Diterima

[] Ditolak

5. Pengujian Menu Data Kendaraan

Pengujian menu data kendaraan ditunjukkan kepada staff kecelakaan untuk

melakukan proses melihat, menambah dan mengubah data kendaraan yang terlibat

kecelakaan.

79


Tabel 27. Pengujian Melihat Data Kendaraan

No



E.1

Staff kecelakaan

memilih menu data

kendaraan pada

management

kecelakaan.

Sistem akan

menampilkan

halaman data

kendaraan dan data

table

Sistem

menampilkan

halaman data

kendaraan

[√] Diterima

[] Ditolak

Tabel 28. Pengujian Menambah Data Kendaraan

No



E.2

Staff kecelakaan

mengisi form data

kecelakaan pada

halaman utama

data kendaraan

Sistem dapat

menyimpan data ke

database dan sistem

menampilkan data

yang telah

dimasukkan

Sistem

menyimpan data

ke database dan

menampilkan data

kendaraan yang

telah dimasukkan

[√] Diterima

[] Ditolak



E.3

Staff kecelakaan

memilih tombol

tambah sementara

form data

kendaraan

dibiarkan kosong

Sistem akan

menolak dan

menampilkan pesan

“Harap isi bidang

ini” pada textbox

yang kosong

Sistem menolak

dan menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang

kosong

[√] Diterima

[] Ditolak

80


Tabel 29. Tabel Pengujian Mengubah Data Kendaraan

No



E.4

Staff kecelakaan

memilih detail

salah satu data

kendaraan dan

mengisi

perubahan data

Sistem dapat

menyimpan data ke

database dan sistem

menampilkan data

yang telah diubah

Sistem

menyimpan data

ke database dan

menampilkan

data kendaraan

telah diubah

[√] Diterima

[] Ditolak


Data


E.5

Staff kecelakaan

memilih tombol

ubah sementara

form detail data

kendaraan diberi

nilai yang sama

Sistem akan menolak


“At least one value must

change”

Sistem menolak

dan

menampilkan

pesan “At least

one value must

change”

[√] Diterima

[] Ditolak

E.6

Staff kecelakaan

memilih tombol

ubah sementara

form detail data

kendaraan

dibiarkan

kosong

Sistem akan menolak


“Harap isi bidang ini”

pada textbox yang

kosong

Sistem menolak

dan

menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang

kosong

[√] Diterima

[] Ditolak

6. Pengujian Menu Data Korban

Pengujian menu data korban ditunjukkan kepada staff kecelakaan untuk melakukan

proses melihat, menambah dan mengubah data korban yang terlibat kecelakaan.

81


Tabel 30. Pengujian Melihat Data Korban

No



F.1

Staff kecelakaan

memilih menu data

korban pada

management

kecelakaan.

Sistem akan

menampilkan

halaman data

korban dan data

table

Sistem

menampilkan

halaman data

korban

[√] Diterima

[] Ditolak

Tabel 31. Pengujian Menambah Data Korban

No



F.2

Staff kecelakaan

mengisi form data

korban pada

halaman utama

data korban

Sistem dapat

menyimpan data ke

database dan sistem

menampilkan data

yang telah

dimasukkan

Sistem

menyimpan data

ke database dan

menampilkan

data korban

yang telah

dimasukkan

[√] Diterima

[] Ditolak



F.3

Staff kecelakaan

memilih tombol

tambah sementara

form data korban

dibiarkan kosong

Sistem akan menolak

dan menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang kosong

Sistem menolak

dan

menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang

kosong

[√] Diterima

[] Ditolak

82


Tabel 32. Tabel Pengujian Mengubah Data Kendaraan

No



F.4

Staff kecelakaan

memilih detail

salah satu data

korban dan

mengisi

perubahan data

Sistem dapat

menyimpan data ke

database dan sistem

menampilkan data

yang telah diubah

Sistem

menyimpan data

ke database dan

menampilkan

data korban

yang telah

diubah

[√] Diterima

[] Ditolak



F.5

Staff kecelakaan

memilih tombol

ubah sementara

form detail data

korban diberi

nilai yang sama

Sistem akan menolak

dan menampilkan



Sistem menolak

dan

menampilkan

pesan “At least

one value must

change”

[√] Diterima

[] Ditolak

F.6

Staff kecelakaan

memilih tombol

ubah sementara

form detail data

korban dibiarkan

kosong

Sistem akan menolak

dan menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang kosong

Sistem menolak

dan

menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang

kosong

[√] Diterima

[] Ditolak

7. Pengujian Menu Surat Operasi

Pengujian menu surat operasi ditunjukkan kepada staff tilang untuk melakukan

proses melihat, menambah dan mengubah data surat operasi yang dilakukan

memulai proses tilang.

83


Tabel 33. Pengujian Melihat Data Surat Operasi

No



G.1

Staff tilang memilih

menu data surat

operasi pada

management

kecelakaan.

Sistem akan

menampilkan

halaman data surat

operasi dan data

table

Sistem

menampilkan

halaman data

surat operasi

[√] Diterima

[] Ditolak

Tabel 34. Pengujian Menambah Data Surat Operasi

No



G.2

Staff tilang

mengisi form data

surat operasi pada

halaman utama

data surat operasi

Sistem dapat

menyimpan data ke

database dan sistem

menampilkan data

yang telah

dimasukkan

Sistem

menyimpan ke

database dan

menampilkan

data surat

operasi yang

telah

dimasukkan

[√] Diterima

[] Ditolak



G.3

Staff tilang

memilih tombol

tambah sementara

form data surat

operasi dibiarkan

kosong

Sistem akan menolak

dan menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang kosong

Sistem menolak

dan

menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang

kosong

[√] Diterima

[] Ditolak

84


Tabel 35. Tabel Pengujian Mengubah Data Surat Operasi

No



G.4

Staff tilang

memilih detail

salah satu data

surat operasi dan

mengisi

perubahan data

Sistem dapat

menyimpan data ke

database dan sistem

menampilkan data

yang telah diubah

Sistem dapat

menyimpan data

ke database dan

menampilan

data surat

operasi telah

diubah

[√] Diterima

[] Ditolak



G.5

Staff tilang

memilih tombol

ubah sementara

form detail data

surat operasi

diberi nilai yang

sama

Sistem akan menolak

dan menampilkan



Sistem menolak

dan

menampilkan

pesan “At least

one value must

change”

[√] Diterima

[] Ditolak

G.6

Staff tilang

memilih tombol

ubah sementara

form detail data

surat operasi

dibiarkan kosong

Sistem akan menolak

dan menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang kosong

Sistem menolak

dan

menampilkan

pesan “Harap isi

bidang ini” pada

textbox yang

kosong

[√] Diterima

[] Ditolak

4.4.2 Integration Testing

Pada integration testing ini penulis menggunakan aplikasi postman untuk melihat

response yang dikiriminkan oleh user melalui API gateway. API gateway

menggunakan url localhost:8010, kecelakaan service menggunakan url

85


localhost:8001 dan tilang service menggunakan url localhost:8002. Berikut

pengujian yang dilakukan :

1. Integrasi API Gateway ke Kecelakaan Service

Berikut pengujian dengan kondisi 2 service yang online pada gambar 4.1.

Gambar 4.1 Integrasi API Gateway ke Kecelakaan Service

Pada gambar 4.1 menunjukkan bahwa API gateway melakukan request ke

kecelakaan service untuk mendapatkan data jenis kendaraan. Berikut rincian REST

API dair gambar diatas :

HTTP Request :

• Method : GET

• URI : http://localhost:8010/MKendaraan

• Header : client_credentials

Response :

• Response Code : 200

• Time : 479ms

• Response Body : data berupa id, jenis_kendaraan dan keterangan

Berikut pengujian dengan kondisi kecelakaan service yang offline pada gambar 4.2.

http://localhost:8010/MKendaraan

86


Gambar 4.2 Integrasi API Gateway ke Kecelakaan Service (Offline)


kecelakaan service untuk mendapatkan data jenis kendaraan jika kondisi

kecelakaan service dalam keadaan offline. Berikut rincian output REST API pada

gambar diatas :

HTTP Request :

• Method : GET

• URI : http://localhost:8010/MKendaraan


Response :


• Time : 2.98 s

• Response Body : Error menampilkan pesan cURL error 7 failed connect to

localhost:8001

2. Integrasi API Gateway ke Tilang Service

Berikut pengujian dengan kondisi 2 service yang online pada gambar 4.3.

http://localhost:8010/MKendaraan

87


Gambar 4.3 Integrasi API Gateway ke Tilang Service

Pada gambar 4.3 menunjukkan bahwa API gateway melakukan request ke tilang

service untuk mendapatkan data surat operasi tilang. Berikut rincian output REST

API dari gambar diatas :

HTTP Request :

• Method : GET

• URI : http://localhost:8010/soperasi


Response :


• Time : 712ms

• Response Body : data berupa id, nomor_surat, pemberi perintah,

pertimbangan, dasar_hukum, penerima_perintah, tanggal_dikeluarkan dan

tempat_dikeluarkan

Berikut pengujian dengan kondisi tilang service yang offline pada gambar 4.4.

http://localhost:8010/soperasi

88


Gambar 4.4 Integrasi API Gateway ke Tilang Service (Offline)


kecelakaan service untuk mendapatkan data jenis kendaraan jika kondisi

kecelakaan service dalam keadaan offline. Berikut rincian output REST API gamabr

diatas :

HTTP Request :

• Method : GET

• URI : http://localhost:8010/soperasi


Response :


• Time : 3.69 s

• Response Body : Error menampilkan pesan cURL error 7 failed connect to

localhost:8002

3. Integrasi API Gateway ke User Service

Berikut pengujian dengan menggunakan 2 service online pada gambar 4.5.

http://localhost:8010/soperasi

89


Gambar 4.5 Integrasi API Gateway ke User Service

Pada gambar 4.5 menunjukkan bahwa API gateway melakukan request ke user

service untuk mendapatkan detail data petugas. Berikut rincian output REST API

gambar diatas :

HTTP Request :

• Method : GET

• URI : http://localhost:8010/users/1


Response :


• Time : 1809ms

• Response Body : data petugas

4. Integrasi API Gateway ke Tilang Service dan Kecelakaan Service

Berikut pengujian dengan kondisi semua service online pada gambar 4.6.

http://localhost:8010/users/1

90


Gambar 4.6 Integrasi API Gateway ke Tilang dan Kecelakaan Service


service(stnk) dan kecelakaan service untuk mendapatkan data korban terlibat

kecelakaan. Berikut rincian output REST API gambar diatas :

HTTP Request :

• Method : GET

• URI : http://localhost:8010/orang


Response :


• Time : 519ms

• Response Body : data korban kecelakaan

Berikut pengujian dengan kondisi 2 service yang online dan 1 service offline (tilang

service) pada gambar 4.6.

http://localhost:8010/orang

91


Gambar 4.7 Integrasi API Gateway ke Tilang(Offline) dan Kecelakaan Service


service(stnk) dalam keadaan offline dan kecelakaan service untuk mendapatkan

data korban terlibat kecelakaan. Berikut rincian output REST API gambar diatas :

HTTP Request :

• Method : GET

• URI : http://localhost:8010/orang


Response :


• Time : 759ms

• Response Body : data korban kecelakaan

4.5 Evaluasi

4.5.1 Evaluasi Hasil Black Box Testing

Pengujian black box telah dilakukan dengan menggunakan 69 skenario yang seperti

sudah dijelaskan sebelumnya. Hasil dari testing yang telah dilakukan adalah sebagai

berikut :

𝑃𝑒𝑟𝑠𝑒𝑛𝑡𝑎𝑠𝑒 𝑘𝑒𝑏𝑒𝑟ℎ𝑎𝑠𝑖𝑙𝑎𝑛 = 69

69× 100% = 100%

http://localhost:8010/orang

92


Berdasarkan hasil testing yang telah dilakukan, maka dapat ditarik kesimpulan

bahwa fungsi pada backend sistem informasi atlantas dapat berjalan dengan baik

secara fungsional dan sesuai yang diharapkan.

4.5.2 Evaluasi Hasil Integration Testing

Pengujian integration telah dilakukan dengan menggunakan 7 skenario pengujian

yang telah dilakukan diatas. Dari 7 skenario yang dilakukan, 2 diantara

menunjukkan hasil response code yaitu 500 atau error. Hasil dari integration

testing sebagai berikut :

𝑃𝑒𝑟𝑠𝑒𝑛𝑡𝑎𝑠𝑒 𝑘𝑒𝑏𝑒𝑟ℎ𝑎𝑠𝑖𝑙𝑎𝑛 = 5

7× 100% = 71%

Berdasarkan dari presentase keberhasilan yang dihitung maka dapat ditarik

kesimpulan bahwa pengujian integrasi antar microservice pada backend sistem

informasi atlantas terintegrasi dengan cukup baik.

93

BAB V

PENUTUP

5.1 Kesimpulan

Berdasarkan hasil implementasi arsitektur microservice pada backend sistem

informasi atlantas berbasis website, maka dapat ditarik kesimpulan :

1. Pembuatan sistem backend pada sistem informasi atlantas berhasil dibuat

dengan konsep arsitektur microservice yang memberikan informasi kasus

pelanggaran dan kebutuhan setiap unit akan saling terintegrasi.

2. Dalam membangun sistem backend menggunakan arsitektur microservice

maka kebutuhan fungsional harus dipecah menjadi beberapa microservice yang

dipanggil melalui API Gateway.

3. Pengujian black box terhadap backend sistem informasi atlantas dengan

skenario melakukan login, mengelola data master, mengelola petugas,

mengelola data kecelakaan, mengelola data kendaraan yang terlibat dan

mengelola data korban yang terlibat kecelakaan dinyatakan berhasil.

4. Pengujian integration terhadap antar microservice yang terintegrasi satu sama

lain berhasil.

5.2 Saran

Adapun saran yang diberikan untuk pengembangan selanjutnya dari impementasi

arsitektur microservice agar selalu memenuhi kebutuhan pengguna :

1. Implementasi ini masih berfokus pada pengembangan sisi back-end sehingga

mengesampingkan front-end aplikasi. Oleh karena itu diharapkan hal tersebut

lebih diperhatikan lagi pada pengembangan selanjutnya.

2. Ada baiknya pada pengembangan sistem ini pada tahap selanjutnya dilakukan

testing dengan menggunakan metode white box testing karena memungkinkan

kedepannya pengembangan yang akan dilakukan akan lebih mendalam.

3. Untuk mendapatkan skalabilitas dengan integrasi yang lebih tinggi perlu

diterapkan command query separation dan multiple server pada penelitian

selanjutnya.

94


DAFTAR PUSTAKA

Chusminah, C., Haryati, R. A. & Kristiani, D, 2018 Efektifitas Implementasi E-

Tilang Kendaraan Bermotor Dalam Rangka Tertib Berlalu Lintas Pada Korps

Lalu Lintas Polri, Jurnal Sekretari dan Manajemen Widya Cipta, 2(2), pp. 1–

9.

Damodaran B, D., Salim, S. and Vargese, S. M. (2016) Performance Evaluation of

MySQL and MongoDB Databases, International Journal on Cybernetics &

Informatics, 5(2), pp. 387–394.

Faruqi, I. A., Gumilang, S. F. S. & Hasibuan, M. A, 2018 Perancangan Back-End

Aplikasi Rumantara Dengan Gaya Arsitektur Rest Menggunakan Metode

Iterative Incremental, eProceedings of Engineering, 5(1), pp. 1411–1417.

Fauzan, M. 2019. Rancang Bangun Sistem Pendukung Keputusan Kinerja Pegawai

Menggunakan Metode Simple Multi Attribute Rating Technique.

Febriani, Y, 2018. Pengembangan Sistem Informasi Penjualan, Pembelian Dan

Persediaan Berbasis Web, Sitech, Vol 1, No, pp. 1–6.

Heriyanto, Y, 2018. Perancangan Sistem Informasi Rental Mobil Berbasis Web

Pada Pt.Apm Rent Car, 2(2), pp. 64–77.

Jayanto, D. P, 2017. Informasi Web Application Backend Development Of “ Siap

” : “ Sistem Informasi Aspirasi Dan Pengaduan Masyarakat ” Application

Based On Web Using Microservice Springboot.

Khoirunnisa, L. 2019. Rancang Bangun Sistem E-Learning Berbasis Microservices

Dan Domain Driven Design (Studi Kasus Probistek Uin Maulana Malik

Ibrahim Malang) .

Luthfi, F, 2017. Penggunaan Framework Laravel Dalam Rancang Bangun Modul

Back-End Artikel Website Bisnisbisnis.ID, JISKA (Jurnal Informatika Sunan

Kalijaga), 2(1), p. 34

Prabowo, M. & Suprapto, A, 2019. Implementasi Metode Profile Matching Dalam

Aplikasi Penerimaan Siswa Baru pada SMK Ma’arif NU 2 Boyolali’, Jusifo

(Jurnal Sistem Informasi), 5(2), pp. 71–80.

95


Putra, R. A, 2019. Analisa Implementasi Arsitektur Microservices Berbasis

Kontainer Pada Komunitas Pengembang Perangkat Lunak Sumber Terbuka (

Opendaylight Devops Community )’, 9, pp. 150–162.

Sendiang, M., Kasenda, S. & Purnama, J, 2018. Implementasi Teknologi

Mikroservice pada Pengembangan Mobile Learning’, Journal of Applied

Informatics and Computing, 2(2), pp. 63–66.

Suendri, 2018. Implementasi Diagram UML (Unified Modelling Language) Pada

Perancangan Sistem Informasi Remunerasi Dosen Dengan Database Oracle

(Studi Kasus: UIN Sumatera Utara Medan)’, 6341(November), pp. 1–9.

Widianti, R, 2018. Implementasi Algoritma Firefly Untuk Penjadwalan Piket

Karyawan ( Studi Kasus : Toko Maju Jaya ).

Yudanto, A. L., Tolle, H. & Brata, A. H, 2017. Rancang Bangun Aplikasi Sistem

Informasi Manajemen Laboratorium Biomedik Fakultas Kedokteran

Universitas Brawijaya, Jurnal Pengembangan Teknologi Informasi dan Ilmu

Komputer, 1(8), pp. 628–634.

Zaman, G. A. P., 2017. Perancangan Dan Implementasi Web Service Sebagai

Media Pertukaran Data Pada Aplikasi Permainan. Jurnal Informatika,

Volume 11, pp. 22-30.

LAMPIRAN

Daftar Riwayat Hidup Penulis

Calvin Seviro Bima Sakti

Lahir di Depok, 28 September 1997, putra ke-1 dari 2

bersaudara dari pasangan Bapak Rosidi dan Ibu Pardiyah.

Lulus Dari SDN Mekarjaya 30 pada tahun 2009, SMPN 4

Depok pada tahun 2012, dan SMK Taruna Bakti Depok

pada tahun 2015. Saat ini sedang menempuh Pendidikan

Diploma IV Program Studi Teknik Informatika Jurusan

Teknik Informatika dan Komputer di Politeknik Negeri

Jakarta.

Lampiran 1 Hasil Wawancara

Wawancara bersama Kapolres Depok, Bapak Aziz


Wawancara bersama Staff bagian tilang, Bripda Eka


Wawancara bersama Staff bagian Laka Lantas, Pak Pranyoto


Wawancara bersama Staff bagian Lalu Lintas, Pak Purwanto

Documents

IMPLEMENTASI ARSITEKTUR MICROSERVICE