SISTEM MONITORING PELANGGAN PASCABAYAR DAN PRABAYAR TIDAK BELI TOKEN MENERAPKAN MANAJEMEN TRANSAKSI MENGGUNAKAN METODE TWO PHASE LOCKING

Transkripsi

1 SISTEM MONITORING PELANGGAN PASCABAYAR DAN PRABAYAR TIDAK BELI TOKEN MENERAPKAN MANAJEMEN TRANSAKSI MENGGUNAKAN METODE TWO PHASE LOCKING (Studi Kasus : PT. PLN (Persero) Area Kuala Kapuas) SKRIPSI Diajukan Untuk Memenuhi Salah Satu Sayarat Memperoleh Gelar Sarjana Komputer Program Studi Teknik Informatika Oleh: Ni Putu Novita Puspa Dewi PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS SAINS DAN TEKNOLOGI UNIVERSITAS SANATA DHARMA YOGYAKARTA 2016 i

2 MONITORING SYSTEM OF POSTPAID AND TBT PREPAID CUSTOMERS IMPLEMENTS TRANSACTION MANAGEMENT USING METHOD TWO PHASE LOCKING (Case Study : State Electricity Company District Kuala Kapuas) A Final Project Presented as Partial Fulfillment of The Requirements To Obtain Sarjana Komputer Degree In Informatics Engineering Study Program By : Ni Putu Novita Puspa Dewi INFORMATICS ENGINEERING STUDY PROGRAM FACULTY OF SCIENCE AND TECHNOLOGY SANATA DHARMA UNIVERSITY YOGYAKARTA 2016 ii

3 iii

4 iv

5 HALAMAN PERSEMBAHAN Never regret for a thing that you never fight for it Tugas akhir ini Penulis persembahkan kepada: Mama yang tiap kali nelpon selalu kirim gambar kebaya, nanya kapan lulus, kapan wisuda, skripsi sampe mana? Papa yang tiap kali ditelpon bilang ga sabar pengen pake jas (ngefek buat wisuda) dan selalu kasih support untuk ga menunda tugas akhir. Budhi dan Widya (partner hidup di jogja) yang selalu jadi bulan-bulanan dan ocehan, spesial buat Budhi yang udah bantu buat digram,edit tulisan,dsb. My dearest geng horror yang setia menemani selama berdinamika di USD dan selalu kasih support tiada henti. v

6 PERNYATAAN KEASLIAN KARYA Saya menyatakan dengan sesungguhnya bahwa skripsi yang saya tulis ini tidak memuat karya atau bagian karya orang lain, kecuali yang telah disebutkan dalam kutipan daftar pustaka sebagimana layaknya karya ilmiah vi

7 LEMBAR PERNYATAAN PERSETUJUANPUBLIKASI KARYA ILMIAH UNTUK KEPENTINGAN AKADEMIS Yang bertanda tangan dibawah ini, saya mahasiswa Universitas Sanata Dharma : Nama : Ni Putu Novita Puspa Dewi NIM : Demi pengembangan ilmu pengetahuan, Saya memberikan kepada Perpustakaan Universitas Sanata Dharma karya ilmiah Saya yang berjudul: SISTEM MONITORING PELANGGAN PASACBAYAR DAN PRABAYAR TIDAK BELI TOKEN MENERAPKAN MANAJEMEN TRANSAKSI MENGGUNAKAN METODE TWO PHASE LOCKING Beserta perangkat yang diperlukan (bila ada). Dengan demikian saya memberikan kepada Perpustakaan Universitas Sanata Dharma hak untuk menyimpan, mengalihkan dalam bentuk media lain, mengelolanya dalam bentuk pangkalan data, mendistribusikan secara terbatas, dan mempublikasikan di Internet atau media lain untuk kepentingan akademis tanpa perlu meminta ijin dari saya maupun memberikan royalti kepada saya selama tetap mencantumkan nama saya sebagai penulis. Demikian pernyataan ini saya buat dengan sebenarnya. Dibuat di Yogyakarta vii

8 ABSTRAK Sebagai salah satu upaya pengendalian susut non teknis di PT. PLN (Persero) Area Kuala Kapuas, bagian Transaksi Energi melakukan monitoring pelanggan Pascabayar dan Prabayar secara rutin. Monitoring yang dilakukan selama ini dilakukan secara manual dan tidak ada filterisasi untuk data yang sudah diperiksa sehingga pemeriksaan kadang dilakukan berulang kali. Pemakaian tenaga listrik yang tidak normal selama ini dipantau secara manual menggunakan perangkat pengolah kata seperti Microsoft Excel. Data yang harus diperiksa setiap bulan sangat banyak sehingga akan memerlukan waktu yang lama untuk memeriksa. PT. PLN (Persero) Area Kuala Kapuas terdiri dari 6 rayon, dimana tiap rayon juga bertanggung jawab untuk melakukan monitoring pelanggan di wilayahnya. Mengingat bahwa petugas yang menggunakan sistem monitoring bukan hanya petugas lapangan melainkan juga petugas yang berada di kantor maka sistem ini menerapkan manajemen transaksi yang melayani multiuser. Sistem yang multiuser ini mengharuskan adanya sebuah penanganan transaksi ketika satu atau beberapa user akan write dan atau read data secara bersamaan. Hal ini dilakukan untuk menghindari masalah proses konkuren seperti diantaranya The Lost Update Problem, The Uncommited Dependency (Dirty Read) Problemdan The Inconsistent Analysis Problem. Sehingga diperlukan manajemen transaksi untuk mengatur kelancaran dari tiap action yang dilakukan oleh user sistem terhadap data. Metode two phase locking yang digunakan akan memberikan lock bagi tiap transaksi yang akan mengakses data, baik read atau write data. Sehingga tiap transaksi akan dibuat menunggu sampe lock dilepaskan untuk dapat mengubah data. viii

9 ABSTRACT As one of the efforts to control non-technical losses in PT. PLN (Persero) Area Kuala Kapuas, division of Energy Transactions do monitoring of postpaid and prepaid customers regularly. The monitoring that have been conducted so far done manually and there is no filter for data that have been checked so that the examination is sometimes performed repeatedly. The unnormal Electricity consumption so far being monitored manually using word processing tools such as Microsoft Excel. There is thousands ofrecords should be checked every month and took so long to be checked. PT. PLN (Persero) Area Kuala Kapuas consists of 6 rayons (small area), each rayon is also being responsible for monitoring customers in their areas. Considering that personnel using this monitoring system is not only the field officers but also officers who were in office then it will implementing transaction management that serves multiuser. This multiuser system requires a transaction handling when one or several users conduct write or read data simultaneously. This is done to avoid problems such as concurrent processes including The Lost Update Problem, The Uncommited Dependency (Dirty Read) Problem, and The Inconsistent Analysis Problem. So, this transaction management is needed to make sure transaction occurs in a good manner for every actions performed by the user towards data. Two phase locking method will provide a lock for each transaction that access the data, either read or write data. So that each transaction will be made to wait until the lock is released by the former transaction to be able to change the data. ix

10 KATA PENGANTAR Puji dan syukur Penulis panjatkan kepada Tuhan Yang Maha Esa atas karunia yang diberikan-nya. Sehingga Penulis dapat menyelesaikan skripsi dengan tepat waktu. Penulisan skripsi ini tidak lepas dari peran pentingnya berbagai pihak, sehingga dalam kesempatan ini penulis dengan kerendahan hati mengucapkan terimakasih kepada semua pihak yang teah memberikan dukungan baik secara langsung maupun tidak langsung kepada penulis dalam penyelesaian skripsi hingga selesai. Pada penulisan skripsi ini saya ucapkan terimakasih kepada: 1. Drs. Johanes Eka Priyatma, M.Sc., Ph.D. selaku Rektor dan dosen pembimbing akademik Penulis. 2. JB. Budi Darmawan, S.T., M.Sc selaku dosen pembimbing tugas akhir Penulis yang telah bersedia memberikan pengorbanan waktu dan tenaga dan pikiran untuk membimbing dengan sabar dalam penyusunan tugas akhir ini. Terima kasih atas petunjuk, arahan, dan saran yang telah diberikan kepada Penulis. 3. A.M Polina, S.Kom, M.Sc dan P.H Prima Rosa, M.Sc selaku dosen penguji yang telah memberikan saran dan masukan pada saat ujian untuk memperbaiki kesalahan dalam penulisan skripsi ini. 4. Dr. Anastasia Rita Widiarti, selaku Kaprodi Teknik Informatika yang selama pengambilan tugas akhir ini secara rutin melakukan pertemuan untuk memberikan support bagi mahasiswa yang sedang dalam tahap penyelesaian tugas akhir. 5. Dosen dan staff FST yang selama ini telah banyak memberikan bantuan dan bimbingan selama Penulis berkuliah di USD. 6. PT. PLN (Area) Kuala Kapuas yang telah membantu Penulis mulai dari proses pengambilan data hingga uji coba sistem. 7. Kedua orang tua Penulis yang selalu memberikan nasihat, doa, dan motivasi kepada Penulis untuk menyelesaikan tugas akhir ini. x

11 8. Adik-adik Penulis, widya, wira, budhi yang selalu memberikan support yang menjadi motivasi bagi Penulis. 9. Teman-teman tercinta yang selalu memberikan dukungan dan motivasi dalam mengerjakan skripsi Agustin, Monica, Riya, Eric, Bagus, Candra, Vitto, Bany, Lukas, Tegar, Andre dan seluruh teman-temanteknik Informatika angkatan 2012 yang selalu berjuang bersama dan saling menginspirasi. 10. Kepada Radha dan Stifanny terima kasih atas support dan bantuan yang telah diberikan. 11. Keluarga besar Narayana Smrti Ashram yang menjadi tempat suka dan duka Penulis selama tinggal di Jogja. Buat dana keli dasa, terima kasih support dan masukan yang telah diberikan kepada Penulis. 12. Semua pihak baik secara langsung maupun tidak langsung yang telah membantu dalam mengerjakan penyelesaian tugas akhir ini. Penulis menyadari masih banyak kekurangan dalam penyusunan skripsi ini, namun penulis tetap berharap skripsi ini dapat bermanfaat bagi pengetahuan. xi

12 DAFTAR ISI HALAMAN JUDUL... i HALAMAN PERSETUJUAN PEMBIMBING... Error! Bookmark not defined. HALAMAN PENGESAHAN... Error! Bookmark not defined. HALAMAN PERSEMBAHAN... v PERNYATAAN KEASLIAN KARYA... vi LEMBAR PERNYATAAN PERSETUJUANPUBLIKASI... vii ABSTRAK... viii ABSTRACT... ix KATA PENGANTAR... x DAFTAR ISI... xii DAFTAR GAMBAR... xvii DAFTAR TABEL... xxv BAB I PENDAHULUAN Latar Belakang Rumusan Masalah Tujuan Batasan Masalah Metodologi Penelitian Sistematika Penulisan... 7 BAB II LANDASAN TEORI Sistem Monitoring Basis Data Pengertian Basis Data Sistem Basis Data Batasan Aturan Basis Data Entity-Relationship Modelling (E-R Modelling) Manajemen Transaksi xii

13 2.3. Use Case Diagram Class Diagram Activity Diagram Oracle Penjelasan Tentang SQL Data Definition Language (DDL) Data Manipulation Language (DML) Stored Procedure Stored Function Java & JSP Semantic-UI BAB III ANALISI DAN PERANCANGAN Analisis Sistem Gambaran Umum Sistem Lama Gambaran Umum Sistem Baru Orang yang Terlibat Dalam Sistem Batasan Sistem Monitoring Pelanggan Pasca Bayar dan Prabayar Perancangan Sistem Deskripsi Rinci Kebutuhan Sistem Use Case Diagram Definisi aktor Definisi Use Case Skenario Use Case Activity Diagram Diagram Sekuensial Diagram Kelas Perancangan Basis Data Desain Konseptual Basis Data Desain Logikal Basis Data Desain Fisikal Basis Data xiii

14 BAB IV IMPLEMENTASI SISTEM Sistem Monitoring Pelanggan Pascabayar dan Prabayar Tidak Beli Token Spesifikasi Software dan Hardware yang Digunakan Spesifikasi Software Spesifikasi Hardware Implementasi Stored Procedure dan Function Implementasi Stored Procedure untuk Proses Upload Data Monitor Pascabayar Implementasi Stored Procedure untuk Proses Upload Data Monitor Prabayar Implementasi Stored Procedure Untuk Proses Approve Data Hasil MonitorPascabayar Implementasi Stored Procedure Untuk Proses Approve Data Hasil Monitoring Prabayar Implementasi Stored Procedure Untuk Proses Pembatalan Status Monitor Pascabayar Implementasi Stored Procedure Untuk Proses Pembatalan Status Monitor Prabayar Implementasi Stored Procedure Untuk Proses Pembatalan Status Approve Pascabayar Implementasi Stored Procedure Untuk Proses Pembatalan Status Approve Prabayar Implementasi Function Implementasi Program Proses Login User Proses Tambah User Proses Edit Data User Proses Monitoring Prabayar dan Pascabayar Proses Menyimpan Gambar Proses Approve Prabayar dan Pascabayar Proses Pembatalan Status Monitoring Prabayar dan Pascabayar xiv

15 Proses Pembatalan Status Approve Prabayar dan Pascabayar Proses Copy Status Bulan Terakhir Proses Cetak Report Monitoring Pelanggan Kwh Proses Cetak Report Monitoring Pelanggan Kwh Maks Proses Cetak Report Monitoring Pelanggan TBT Proses Cetak Report Rekomendasi Monitoring Pelanggan Kwh Maks Naik Daya Proses Lihat Versi Monitoring Implementasi Kelas Implementasi Basis Data Implementasi Antar Muka Implementasi User Interface Login Operator dan Administrator Halaman Utama Administrator Tingkat Area Halaman Utama Administrator Tingkat Rayon Halaman Utama Operator Tingkat Area dan Rayon Halaman Tambah User Lihat Data Monitoring Upload data dan ubah data monitoring Lihat Data Approve Approve Dan Batalkan Status Monitoring Lihat Detail Approve dan Pembatalan Status Approve Lihat Detail Pelanggan Dasboard Cetak Laporan BAB V ANALISA HASIL PENGUJIAN Analisa Perangkat Lunak Analisa Hasil Uji Coba Terhadap Program Pengujian Kasus The Lost of Update Problem Pengujian Kasus The Uncommitted Dependency Problem xv

16 Pengujian Kasus The Inconsistent Analysis Problem Analisa Hasil Uji Coba Terhadap Pengguna Form Kuesioner Hasil dan Pembahasan BAB VI KESIMPULAN DAN SARAN Kesimpulan Saran DAFTAR PUSTAKA Lampiran A. Lampiran Program B. Lampiran User Interface C. Lampiran Diagram Kelas D. Lampiran Hasil Jawaban Kuesioner xvi

17 DAFTAR GAMBAR Gambar 1. 1 Grafik Pelanggan Monitoring Pascabayar Juni 2014 (sumber : Data DPM PT.PLN (Persero) Area Kuala Kapuas Juni 2014) Gambar 1. 2Grafik Pelanggan Monitoring Prabayar Juni 2015 (sumber : Data TBT PT.PLN (Persero) Area Kuala Kapuas Juni 2015) Gambar 2. 1Representasi Diagram dari Entity Type Staff dan Branch(Connolly and Beg, 2002) Gambar 2. 2Representasi Diagram dari Entity Branch Has Staff Relationship Type(Connolly and Beg, 2002) Gambar 2. 3Representasi Diagram dari Entity Staff dan Branch Gambar 2. 4Diagram Transisi Transaksi (Connolly and Beg, 2002) Gambar 2. 5Mencegah Lost Update Problem menggunakan 2PL (Connolly and Beg, 2002) Gambar 2. 6Mencegah Uncommited Dependency Problem using 2PL(Connolly and Beg,2002) Gambar 2. 7Mencegah Inconsistent Analysis Problem using 2PL(Connolly and Beg,2002) Gambar 2. 8Daur hidup JSP Gambar 3. 1 Use case diagram untuk aktor operator area dan rayon Gambar 3. 2 Use case diagram untuk aktor admin area dan rayon Gambar 3. 3 Use case diagram package kelola monitoring pelanggan kwh 0 untuk aktor admin area Gambar 3. 4 Use case diagram package kelola monitoring pelanggan kwh maks untuk aktor admin area Gambar 3. 5 Use case diagram package kelola monitoring pelanggan TBTuntuk aktor admin area Gambar 3. 6 Use case diagram package kelola monitoring pelanggan kwh 0 untuk aktor operator area Gambar 3. 7 Use case diagram package kelola monitoring pelanggan kwh maks untuk aktor operator area xvii

18 Gambar 3. 8 Use case diagram package kelola monitoring pelanggan TBTuntuk aktor operator area Gambar 3. 9 Use case diagram package kelola monitoring pelanggan kwh 0 untuk aktor operator dan admin rayon Gambar Use case diagram package kelola monitoring pelanggan kwh maksuntuk aktor operator dan admin rayon Gambar Use case diagram package kelola monitoring pelanggan TBT untuk aktor operator dan admin rayon Gambar Use case diagram package kelola approve pelanggan kwh 0 untuk aktor admin area Gambar Use case diagram package kelola approve pelanggan kwh maks untuk aktor admin area Gambar Use case diagram package kelola approve pelanggan TBT untuk aktor admin area Gambar Use case diagram packageapprove pelanggan kwh 0 untuk aktor admin rayon Gambar 3. 16Use case diagram package approve pelanggan kwh maks untuk aktor admin rayon Gambar Use case diagram package approve pelanggan TBT untuk aktor admin rayon Gambar Use case diagram package kelola user untuk admin area Gambar Use case diagram package kelola laporan untuk admin area Gambar Use case diagram package lihat data untuk user admin area dan admin rayon Gambar Activity diagram untuk use ase login user admin Gambar Activity diagram untuk use ase login user operator Gambar Activity Diagram dari use case tambah user Gambar Activity diagram dari ubah data user Gambar Activity diagram dari use case lihat data belum monitoring untuk pelanggan kwh Gambar Activity diagram dari use case lihat data belum monitoring untuk pelanggan kwh Maks Gambar Activity diagram dari use case lihat data belum monitoring untuk pelanggan TBT Gambar Activity diagram dari use case lihat data sudah monitoring untuk pelanggan kwh Gambar Activity diagram dari use case lihat data sudah monitoring untuk pelanggan kwh Maks Gambar Activity diagram dari use case lihat data sudah monitoring untuk pelanggan kwh Maks xviii

19 Gambar Activity diagram dari use case lihat data sudah approve untuk pelanggan kwh Gambar Activity diagram dari use case lihat data sudah approve untuk pelanggan kwh maks Gambar Activity diagram dari use case lihat data sudah approve untuk pelanggan TBT Gambar Activity diagram dari use case lihat data belum approve untuk pelanggan kwh Gambar Activity diagram dari use case lihat data belum approve untuk pelanggan kwh maks Gambar Activity diagram dari use case lihat data belum approve untuk pelanggan TBT Gambar Activity diagramdari use case cek approve per-bulan untuk pelanggan kwh maks Gambar Activity diagram dari use case cek approve per-bulan untuk pelanggan TBT Gambar Activity diagram dari use case cek approve per-bulan untuk pelanggan kwh Gambar Activity diagram dari use case cek monitor per-bulan untuk pelanggan kwh Gambar Activity diagram dari use case cek monitor per-bulan untuk pelanggan kwh maks Gambar Activity diagram dari use case cek monitor per-bulan untuk pelanggan TBT Gambar Activity diagram dari use case upload data hasil monitor Gambar Activity diagram dari use case ubah data hasil monitor Gambar Activity diagram dari use case batalkan status monitor Gambar Activity diagram dari use case batalkan status approve Gambar Activity diagram dari use case approve data hasil monitor (diasumsikan pelanggan kwh 0, kwh maks, dan TBT memiliki langkah yang sama) Gambar Activity diagram dari use case lihat versi sebelum dari data hasil monitor Gambar Activity diagram dari use case lihat history monitoring dari data hasil monitor Gambar Activity diagram dari use case copy status bulan terakhir (diasumsikan pelanggan kwh 0, kwh maks, dan TBT memiliki langkah copy status yang sama) Gambar Activity diagram dari use case cetak laporan untuk pelanggan kwh xix

20 Gambar Activity diagram dari use case cetak laporan untuk pelanggan kwh maks Gambar Activity diagram dari use case cetak laporan untuk pelanggan TBT Gambar Activity diagram dari use case cetak laporan untuk pelanggan naik daya Gambar Activity diagram dari use case tampilkan data yang sama pelanggan kwh Gambar Activity diagram dari use case tampilkan data yang sama pelanggan kwh maks Gambar Activity diagram dari use case tampilkan data yang sama pelanggan TBT Gambar Activity diagram dari use case lihat detail pelanggan Gambar Diagram sekuensial untuk login admin Gambar Diagram sekuensial untuk login operator Gambar Diagram Sekuensial untuk use case tambah user Gambar Diagram sekuensial untuk use case edit data user Gambar Diagram sekeunsial untuk use case lihat daftar Kwh 0 belum cek Gambar Diagram sekeunsial untuk use case lihat daftar kwh maks belum cek Gambar Diagram sekuensial untuk use case lihat daftar TBT sudah cek Gambar Diagram sekuensial untuk use case lihat daftar kwh 0 sudah cek 140 Gambar Diagram sekuensial untuk use case lihat daftar kwh maks sudah cek Gambar Diagram sekuensial untuk use case lihat data kwh maks cek perbulan Gambar Diagram sekuensial untuk use case lihat data kwh 0 cek perbulan Gambar Diagram sekuensial untuk use case lihat data TBT cek perbulan 142 Gambar Diagram sekuensial untuk use case lihat data kwh 0 cek approve perbulan Gambar Diagram sekuensial untuk use case lihat data kwh maks cek approve perbulan Gambar Diagram sekuensial untuk use case lihat data tbt cek approve perbulan Gambar Diagram sekuensial untuk use case lihat Data TBT lihat yang sama Gambar Diagram sekuensial untuk use case lihat data kwh 0 cek data yang sama xx

21 Gambar Diagram sekuensial untuk use case lihat data data kwh maks cek data yang sama Gambar Diagram sekuensial untuk use case lihat versi sebelum data monitoring pelanggan kwh 0 (kwh maks dan TBT sama) Gambar Diagram sekuensial untuk use case lihat history monitoring pelanggan kwh 0 (kwh maks dan TBT sama) Gambar Diagram sekuensial untuk use case proses approve pelanggan kwh 0 (kwh maks dan TBT sama) Gambar Diagram sekuensial untuk use case pembatalan status monitoring pelanggan kwh 0 (kwh maks dan TBT sama) Gambar Diagram sekuensial untuk use case pembatalan status approve Gambar Diagram sekuensial untuk use case upload data monitoring pelanggan kwh 0 (kwh maks dan TBT sama) Gambar Diagram sekuensial untuk use case proses ubah data monitoring pelanggan kwh 0 (kwh maks dan TBT sama) Gambar Diagram sekuensial untuk use case proses copy status pelanggan kwh maks (kwh 0 dan TBT sama) Gambar Diagram sekuensial untuk use case cetak laporan monitoring kwh Gambar Diagram sekuensial untuk use case cetak laporan monitoring kwh maks Gambar Diagram sekuensial untuk use case cetak laporan monitoring TBT Gambar Diagram sekuensial untuk use case laporan rekomendasi monitoring naik daya pelanggan kwh maks Gambar Diagram Kelas Gambar Desain konseptual basis data dari sistem Gambar Desain logikal basis data dari sistem Gambar 4. 1 Stored Procedure monitor_pascabayar Gambar 4. 2 Stored procedure monitor_prabayar Gambar 4. 3 Implementasi stored procedure approve_pascabayar Gambar 4. 4 Impelementasi stored procedure approve_prabayar Gambar 4. 5 Implementasi stored procedure batal_monitor_pascabayar Gambar 4. 6 Implementasi stored procedure batal_monitor_prabayar Gambar 4. 7 Implementasi stored procedure batal_approve_pasca Gambar 4. 8 Implementasi Stored Procedure batal_approve_prabayar Gambar 4. 9Implementasi function tambah_idmon_pasca Gambar 4. 10Implementasi function tambah_idmon_prabayar xxi

22 Gambar Impelementasi function tambah_idapp_pasca Gambar Implementasi function tambah_idapp_prabayar Gambar Interface halaman Home Sistem Gambar Interface menu login operator Gambar Interface menu login admin Gambar Interface halaman Utama Admin Area Gambar Menu Lihat Data Gambar Menu Monitoring Gambar Menu Approve Gambar Menu Cetak Laporan Gambar Panel Logout Gambar Halaman utama admin tingkat rayon Gambar Halaman utama operator tingkat rayon dan area Gambar Halaman daftar user login Gambar Halaman tambah user login Gambar Halaman cari data user Gambar Halaman edit data user Gambar Halaman lihat daftar kwh 0 sudah cek (halaman kwh maks sama) Gambar Halaman lihat daftar kwh 0 belum cek (halaman kwh maks sama) Gambar Halaman cari data monitoring perbulan Gambar Halaman daftar monitoring kwh 0 cek perbulan Gambar Halaman daftar TBT sudah cek Gambar Halaman daftar TBT belum cek Gambar Halaman daftar TBT cek perbulan Gambar Halaman kwh 0 sudah cek untuk user admin dan operator rayon 219 Gambar Halaman kwh 0 belum cek untuk user admin dan operator rayon 219 Gambar Halaman kwh 0 cek perbulan untuk user admin dan operator rayon Gambar Halaman daftar TBT sudah cek untuk operator dan admin rayon 220 Gambar Halaman daftar TBT sudah cek untuk operator dan admin rayon 220 Gambar Halaman daftar TBT sudah cek untuk operator dan admin rayon 220 Gambar Halaman upload data monitoring kwh 0 dan kwh maks Gambar Halaman upload data monitoring TBT Gambar Halaman ubahdata monitoring kwh 0 dan kwh maks Gambar Halaman ubahdata monitoring TBT Gambar Halaman lihat data sudah approve untuk admin area Gambar Halaman lihat data belum approve untuk admin area Gambar Halaman cari data approve bulan dan tahun xxii

23 Gambar Halaman lihat daftar approve perbulan untuk admin area Gambar Halaman lihat daftar approve cek semua untuk admin area Gambar Halaman cek data yang sama Gambar Halaman lihat data approve per-unitup Gambar Halaman lihat daftar sudah approve untuk user admin rayon Gambar Halaman lihat daftar belumapprove untuk user admin rayon Gambar Halaman lihat daftar cek approve perbulan untuk user admin rayon Gambar Halaman approve data dan pembatalan status monitoring pelanggan kwh Gambar Halaman detail approve data pelanggan Gambar Halaman liat detail versi sebelum Gambar Halaman history monitoring Gambar Halaman pencarian detail pelanggan Gambar Halaman detail pelanggan Gambar Interface Laporan Monitoring Kwh Gambar Halaman cetak laporan monitoring kwh Gambar Halaman daftar pelanggan monitoring perbulan yang akan dicetak Gambar Preview dari cetak laporan monitoring kwh 0 gambar Gambar Halaman daftar pelanggan monitoring Gambar Preview dari cetak laporan monitoring kwh 0 dari gambar Gambar Halaman cetak blangko monitoring kwh maks naik daya Gambar Halaman daftar pelanggan monitoring kwh maks naik daya Gambar Preview cetak dari gambar Gambar Halaman daftar pelanggan monitoring kwh maks naik daya Gambar Preview cetak laporan rekomendasi monitoring dari gambar Gambar 5. 1 Alur proses monitoring pelanggan Gambar 5. 2 Diagram simulasi percobaan Gambar 5. 3 Data pelanggan kwh 0 belum apporve (transaksi 1) Gambar 5. 4 Data pelanggan kwh 0 sudah cek (transaksi 2) Gambar 5. 5 Halaman lihat detail pelanggan untuk proses approve (transaksi 1) Gambar 5. 6 Halaman isian untuk ubah data monitoring pelanggan (transaksi 2) xxiii

24 Gambar 5. 7 Prosedur approve_pascabayar dengan DBMS_LOCK.SLEEP selama 20 detik Gambar 5. 8 transaksi 1 akan klik tombol APPROVE untuk melakukan approve pada data tersebut Gambar 5. 9 Transaksi 2 mengubah data koordinat, verifikasi, tanggal monitor, dan keadaan MCB pada data pelanggan diatas Gambar Transaksi 1 sukses Gambar Transaksi 2 gagal Gambar Kutipan fungsi tambah_idmon_pasca jika v_status_app tidak null maka idmon = null Gambar Daftar pelanggan kwh 0 sudah cek dimana status monitor idpel berubah menjadi sudah approve Gambar Transaksi 1 yang akan approve data Gambar Transaksi 2 yang akan mengubah data yang akan diapprove oleh transaksi Gambar Klausa FOR UPDATE OF dihapus,delay diset 20 detik Gambar Transaksi 2 berhasil melakukan ubah data Gambar Transaksi ubah data berhasil dilakukan Gambar Detail monitoring telah diubah (transaksi 2) Gambar Data history monitoring yang menjadi tidak konsisten Gambar Detail approve transaksi 1 telah berubah, idmon versi sebelum seharusnya MON Gambar Diagram simulasi percobaan Gambar Daftar pelanggan kwh 0 belum approve Gambar Halaman detail approve pelanggan pada transaksi Gambar Transaksi 2 yang akan approve data pelanggan diatas Gambar Transaksi 1 berhasil dilakukan, status monitoring pelanggan menjadi null Gambar Transaksi 2 gagal dilakukan sehingga harus rollback Gambar Data pelanggan berstatus belum monitoring Gambar Transaksi 1 yang akan melakukan pembatalan monitoring Gambar Transaksi 2 yang akan melakukan approve monitoring Gambar kutipan stored procedure batal_monitor_pasca dimana delay diset 20 detik, klausa FOR UPDATE OF ditutup Gambar Transaksi 2berhasil dilakukan, status approve bernilai null Gambar Transaksi 1 berhasil, karena status approve yang dibaca sebelum delay adalah null maka data ini dapat dibatalkan. Namun, pada kenyataanya setelagh data dibaca kembali status approve menjadi YES xxiv

25 Gambar Pada daftar pelanggan sudah approve, data pelanggan memiliki status approve dengan tanda silang, ini terjadi karena syarat status monitor tidak sama dengan null tidak terpenuhi Gambar Pada data history monitoring pelanggan tersebut, referensi idmon versi sebelum menjadi tidak konsisten. Ada 2 record yang memiliki versi sebelum yang sama Gambar 5. 36Status monitoring pelanggan dengan idpel untuk blth adalah null sedangkan status approve adalah YES DAFTAR TABEL Tabel 2. 1 Notasi Use Case Tabel 2. 2 Notasi class diagram Tabel 2. 3Notasi activity diagram Tabel 3. 1 Karakteristik user sistem Tabel 3. 2 Definisi Use Case Tabel 3. 3 Skenario use case Login user bertipe admin Tabel 3. 4 Skenario use case Login user bertipe operator Tabel 3. 5 Skenario use case tambah user Tabel 3. 6 Skenario use case ubah data user Tabel 3. 7 Skenario use case Lihat daftar belum monitor kwh maks area Tabel 3. 8 Skenario use case Lihat daftar belum monitor kwh maks rayon Tabel 3. 9 Skenario use case Lihat daftar belum monitor kwh 0 area Tabel Skenario use case Lihat daftar belum monitor kwh 0 rayon Tabel Skenario use case Lihat daftar belum monitor TBT area Tabel Skenario use case Lihat daftar belum monitor TBT rayon Tabel Skenario use case Lihat daftar sudah monitor kwh maks area Tabel Skenario use case Lihat daftar sudah monitor kwh maks rayon Tabel Skenario use case Lihat daftar sudah monitor kwh 0 area Tabel Skenario use case Lihat daftar sudah monitor kwh 0 rayon Tabel Skenario use case Lihat daftar sudah monitor TBT area Tabel Skenario use case Lihat daftar sudah monitor TBT rayon Tabel Skenario use case Lihat daftar per-bulan kwh maks area Tabel Skenario use case Lihat daftar per-bulan kwh maks rayon Tabel Skenario use case Lihat daftar per-bulan kwh 0 area Tabel Skenario use case Lihat daftar per-bulan kwh 0 rayon xxv

26 Tabel Skenario use case Lihat daftar per-bulan TBT area Tabel Skenario use case Lihat daftar per-bulan TBT rayon Tabel Skenario use case Lihat daftar belum cek per-bulan kwh maks area Tabel Skenario use case Lihat daftar belum cek per-bulan kwh maks rayon Tabel Skenario use case Lihat daftar belum cek per-bulan kwh0 area Tabel Skenario use case Lihat daftar belum cek per-bulan kwh 0 rayon Tabel Skenario use case Lihat daftar belum cek per-bulan TBT area Tabel Skenario use case Lihat daftar belum cek per-bulan TBT rayon Tabel Skenario use case upload data kwh Tabel Skenario use case upload data kwh maks Tabel Skenario use case upload data TBT Tabel Skenario use case ubah data kwh maks Tabel Skenario use case ubah data kwh Tabel Skenario use case ubah data TBT Tabel Skenario Use case lihat detail pelanggan pascabayar Tabel Skenario Use case lihat detail pelanggan prabayar Tabel Skenario Use case lihat daftar belum approve kwh maks rayon Tabel Skenario Use case lihat daftar belum approve kwh 0 rayon Tabel Skenario Use case lihat daftar belum approve TBT rayon Tabel Skenario Use case lihat daftar sudah approve kwh maks rayon Tabel Skenario Use case lihat daftar sudah approve kwh 0 rayon Tabel Skenario Use case lihat daftar sudah approve TBT rayon Tabel Skenario Use case lihat daftar belum approve kwh maks area Tabel Skenario Use case lihat daftar belum approve kwh 0area Tabel Skenario Use case lihat daftar belum approve TBT area Tabel Skenario Use case lihat daftar sudahapprove TBT area Tabel Skenario Use case lihat daftar sudah approve kwh 0 area Tabel Skenario Use case lihat daftar sudah approve kwh maks area Tabel Skenario Use case batalkan status approve kwh maks Tabel Skenario Use Case batalkan status approve kwh Tabel Skenario Use Case batalkan status approvetbt Tabel Skenario Use Case approve datatbt Tabel Skenario Use Case approve data kwh maks Tabel Skenario Use Case approve data kwh Tabel Skenario Use Case batalkan status sudah monitor data kwh Tabel Skenario Use Case batalkan status sudah monitor data kwh maks Tabel Skenario Use Case Copy Status Bulan Terakhir kwh maks Tabel Skenario Use Case Copy Status Bulan Terakhir kwh xxvi

27 Tabel Skenario Use Case Copy Status Bulan Terakhir TBT Tabel Skenario use case lihat versi sebelum data pelanggan kwh maks Tabel Skenario use case lihat versi sebelum data pelanggan kwh Tabel Skenario use case lihat versi sebelum data pelanggan TBT Tabel Skenario Use Case lihat history monitoring pelanggan TBT Tabel Skenario Use Case lihat history monitoring pelanggan kwh Tabel Skenario Use Case lihat history monitoring pelanggan kwh maks Tabel Skenario use case cetak laporan kwh 0 1 bulan Tabel Skenario use case cetak laporan kwh 0 beberapa bulan Tabel Skenario use case cetak laporan kwh maks 1 bulan Tabel Skenario use case cetak laporan kwh maks beberapa bulan Tabel Skenario use case cetak laporan TBT 1 bulan Tabel Skenario use case cetak laporan TBT beberapa bulan Tabel Skenario use case cetak laporan rekomendasi monitoring naik daya pelanggan kwh maks Tabel Skenario use case cetak laporan rekomendasi monitoring naik daya pelanggan kwh maks beberapa bulan Tabel Tabel Data_Penduduk Tabel Tabel Produk Tabel Tabel Pelanggan Tabel Tabel USER_LOGIN Tabel Tabel KODE_UNIT Tabel Tabel DLPD_PRABAYAR Tabel Tabel DLPD_PRABAYAR Tabel Tabel RECORD_MONITORING_PRABAYAR Tabel Tabel MONITORING_PASCABAYAR Tabel 4. 1Tabel Implementasi Kelas Tabel 4. 2 Tabel Implementasi Basis Data Tabel 4. 3 Tabel Implementasi User Interface Tabel 5. 1 Proses yang terjadi saat approve data pelanggan dan ubah data pelanggan (subbab 5.2.1) Tabel 5. 2 Proses yang terjadi saat pembatalan status monitoring data pelanggan dan approve data pelanggan (subbab 5.2.2) xxvii

28 Tabel 5. 3 Proses yang terjadi saat approve data pelanggan dan ubah data pelanggan tanpa protokol 2PL (subbab 5.2.1) Tabel 5. 4 Proses yang terjadi saat batalkan status monitoring dan approve tanpa protokol 2PL (subbab 5.2.2) Tabel 5. 5 Tabel skenario masalah the Uncommitted Dependency Problem Tabel 5. 6 Tabel hasil pernyataan 1 user admin Tabel 5. 7 Tabel hasil pernyataan 1 user operator Tabel 5. 8 Tabel hasil pernyataan 2 user admin Tabel 5. 9 Tabel hasil pernyataan 3user admin dan operator Tabel Tabel hasil pernyataan 1 user admin dan operator Tabel Tabel hasil pernyataan 2 user admin dan operator Tabel Tabel hasil pernyataan 3 user admin Tabel Tabel hasil pernyataan 4 user admin Tabel Tabel hasil pernyataan 5 user admin Tabel Tabel hasil pernyataan 6 user admin (area) Tabel Tabel hasil pernyataan 1 user admin dan operator Tabel Tabel hasil pernyataan 2 user admin dan operator Tabel Tabel hasil pernyataan 3 user admin dan operator Tabel Tabel hasil pernyataan 4 user admin dan operator xxviii

29 BAB I PENDAHULUAN 1.1. Latar Belakang Pengendalian susut merupakan salah satu upaya penekanan jumlah susut energi listrik yang disalurkan ke pelanggan. Pengendalian susut energi listrik dibedakan menjadi 2 yaitu secara teknis dan nonteknis. Pengendalian susut teknis berkaitan dengan usaha-usaha pemeliharaan dan pengawasan di pembangkit listrik, sedangkan pengendalian susut non teknis berkaitan dengan administrasi, manajemen kwh Meter, dan penanganan pencurian tenaga listrik. Berdasarkan hasil pengamatan yang dilakukan oleh Penulis di PT. PLN (Persero) Area Kuala Kapuas khususnya di bagian Transaksi Energi, diketahui bahwa bagian Transaksi Energi memastikan daya 20 Kwh dari pembangkit didistribusikan ke pelanggan dalam bentuk listrik bertegangan 220 V. Untuk melakukan Pelanggaran Penggunaan Tenaga Listrik (P2TL) lebih mudah dilakukan pada tegangan 220V (oleh pelanggan atau oknum tertentu). Untuk menghindari kerugian akibat pelanggaran diatas maka perlu dilakukan monitoring untuk pelanggan pasca bayar dan prabayar. Monitoring pemakaian tenaga listrik oleh pelanggan merupakan salah satu bagian dari usaha pengendalian susut non teknis. Pelanggan yang perlu dimonitor adalah pelanggan pasca bayar kwh 0 dan kwh Maks ; dan pelanggan prabayar yang tidak beli token lebih dari 3 bulan. Data Pelanggan Pascabayar dan Prabayar yang harus dimonitor terbilang sangat banyak. Berdasarkan data pada gambar 1.1 terdapat sekitar pelanggan pascabayar di area Kuala Kapuas yang harus dimonitor dalam satu bulan (sumber: data DPM PT.PLN (Persero) Area Kuala Kapuas bulan Juni 2014) dan terdapat sekitar pelanggan prabayar tidak beli token yang harus dimonitor(sumber: data DPM PT.PLN (Persero) Area Kuala Kapuas bulan Juni 2015). 1

30 Jumlah Pelanggan PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI Pelanggan Monitoring Pascabayar Juni Unitup kwh 0 kwh maks Gambar 1. 1Grafik Pelanggan Monitoring Pascabayar Juni 2014 (sumber: Data DPM PT.PLN (Persero) Area Kuala Kapuas Juni 2014) Masalah yang ditemukan Penulis adalah monitoring yang dilakukan selama ini dilakukan secara manual dan tidak adafilterisasi untuk data yang sudah diperiksa sehingga pemeriksaan kadang dilakukan berulang kali. Pemakaian tenaga listrik yang tidak normal selama ini dipantau secara manual menggunakan perangkat pengolah kata seperti Microsoft Excel. Data berupa daftar pelanggan yang akan dimonitoring dalam bentuk tabel akan dicetak dan kemudian dibawa untuk diisi oleh petugas lapangan melakukan survei ke tempat pelanggan. Untuk membantu petugas baik di kantor maupun di lapangan dalam hal collecting data monitoringhingga proses persetujuan (approval). PT. PLN (Persero) Area Kuala Kapuas terdiri dari 6 rayon, dimana tiap rayon juga bertanggung jawab untuk melakukan monitoring pelanggan di wilayahnya. Mengingat bahwa petugas yang menggunakan sistem monitoring bukan hanya petugas lapangan melainkan juga petugas yang berada di kantor maka sistem ini menerapkan manajemen transaksi yang melayani multiuser. Ketika ada dua petugas lapangan ingin mengupload data hasil monitoring pada pelanggan yang sama secara bersamaan atau ketika akan petugas di kantor akan melakukan pengecekkan dan proses approval monitoring pada data pelanggan yang sama dengan pengaturan proses transaksi yang menerapkan 2PL (2 Phase

31 Jumlah Pelanggan PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI 3 Locking), maka proses update database dapat dilakukan dengan benar dan masalah lost update problem dapat diatasi, sehingga data hasil monitoring lebih akurat dan dapat dipertanggung-jawabkan. Pelanggan Monitoring Prabayar Bulan Juni Unitup Gambar 1. 2Grafik Pelanggan Monitoring Prabayar Juni 2015 (sumber: Data TBT PT.PLN (Persero) Area Kuala Kapuas Juni 2015). Sistem yang multiuser ini mengharuskan adanya sebuah penanganan transaksi ketika satu atau beberapa user akan write dan atau read data secara bersamaan. Hal ini dilakukan untuk menghindari masalah proses konkuren diantaranyathe Lost Update Problem, The Uncommited Dependency (Dirty Read) Problem, dan The Inconsistent Analysis Problem. Sehingga diperlukan manajemen transaksiuntuk mengatur kelancaran dari tiap action yang dilakukan oleh user sistem terhadap data. Untuk menjawab permasalah yang telah dipaparkan di atas maka Penulis akan membuat Sistem Monitoring Pelanggan Pascabayar dan Prabayar Tidak Beli Token Menerapkan Manajemen Transaksi Menggunakan MetodeTwo Phase Locking.

32 Rumusan Masalah Rumusan masalah yang ingin dijawab dalam karya tulis ini adalah sebagai berikut: 1. Bagaimana membangun sistem monitoring yang dapat menyimpan dokumentasi data monitoring dan approval yang dilakukan petugas serta membuat report rekomendasi monitoring naik daya bagi pelanggan kwh maks dengan menerapkan manajemen transaksi dengan menggunakan metode two phase locking? 2. Bagaimana implementasi uji coba sistem ini mampu secara efisien membantu PT. PLN (Persero) Area Kuala Kapuas dan sejauh mana sistem mudah digunakan oleh user? 1.3. Tujuan Tujuan dari sistem yang akan dibuat ini adalah sebagai berikut: 1. Membangun Sistem Monitoring Pelanggan Pascabayar dan Prabayar yang dapat memudahkan proses monitoring dan approval pelanggan dengan menerapkan manajemen transaksi dengan protokol two phase locking. 2. Membantu menghindari kesalahan yang disebabkan karena human error dan mempercepat proses monitoring pelanggan kwh 0, kwh Maks, dan tidak beli token di atas 3 bulan yang dilakukan oleh petugas di kantor maupun di lapangan dibandingkan dengan proses manual. 3. Membuat dokumentasi dan pertanggung-jawaban yang jelas terhadap tindakan monitoring pelanggan yang dilakukan oleh petugas monitoring baik di kantor dan di lapangan. 4. Mempermudah pemantauan progreskerja monitoring pelanggan, sehingga petugas non lapangan dapat memantau hasil monitoring dan melakukan approval atau pembatalan monitoring yang dilakukan di lapangan melalui sistem tersebut.

33 Batasan Masalah Sistem yang akan dibangun memiliki batasan sebagai berikut: 1. Data pelanggan monitoring kwh Maks, kwh 0, dan pelanggan tidak beli token lebih dari 3 bulan merupakan data yang didapatkan dari Sistem Informasi lain diluar Sistem Monitoring yang akan dibangun ini. 2. Ketentuan monitoring seperti alur dan data-data yang ingin didapatkan ketika monitoring ditentukan oleh PT. PLN (Persero) Area Kuala Kapuas selaku pihak yang mengerti proses bisnis dalam masalah ini. 3. Pelanggan yang perlu dimonitor adalah pelanggan pasca bayar kwh 0 dan kwh Maks ; dan pelanggan prabayar yang tidak beli token lebih dari 3 bulan. 4. Aturan untuk menentukan pelanggan naik daya yang harus dimonitoring pada pelanggan kwh Maks telah ditentukan sesuai dengan best practice dan petunjuk teknis oleh PT. PLN (Persero) Area Kuala Kapuas. 5. Terjadinya penurunan susut yang ditargetkan oleh PT. PLN (Persero) Area Kuala Kapuas bukan serta merta terjadi hanya karena diimplementasikannya Sistem Monitoring ini. 6. Sistem Monitoring yang dibangun ini dibatasi hanya untuk keperluan monitoring pelanggan pada bagian Transaksi Energi di PT. PLN (Persero) Area Kuala Kapuas. 7. Sistem Monitoring ini dibuat dengan menggunakan bahasa pemrogaman JAVAdan JSP serta menggunakan database Oracle Enterprise Edition10g dengan pertimbangan diperlukan storage yang lebih besar untuk menyimpan dan mengelola data pelanggan monitoring Metodologi Penelitian Dalam menganalisa masalah Penulis menggunakan metode-metode penelitian yang dibagi menjadi 3 tahap sebagai berikut : 1. Survei dan Pengumpulan Data Dalam pengumpulan data untuk penelitian ini, digunakan beberapa cara yaitu:

34 6 - Wawancara Merupakan suatu pengumpulan data yang dilakukan dengan cara tanya jawab atau dialog secara langsung dengan pihak PT. PLN (Persero) Area Kuala Kapuas terutama di Bagian Transaksi Energi mengenai proses bisnis dan kesulitan yang dihadapi dalam proses bisnis tersebut. - Dokumentasi Merupakan suatu cara pengumpulan data yang dilakukan dengan mengumpulkan dokumen maupun data pelanggan berkaitan dengan penggunaan tenaga listrik dalam selama jangka waktu tertentu yang didapat dari Bagian Transaksi Energi di PT. PLN (Persero) Area Kuala Kapuas. - Pengamatan Merupakan suatu cara pengumpulan data yang dilakukan dengan pengamata dan pencatatan langsung maupun tidak langsung terhadap objek yang dibahas. Disini penulis mengamati bagaimana proses monitoring penggunaan listrik pelanggan baik di lapangan maupun tidak (di kantor). 2. Pengembangan Sistem Pengembangan sistem informasi menggunakan metode FAST (Framework for the Application of Systems Thinking) menurut Whitten (2001) yang fasenya meliputi : 1. Definisi lingkup masalah. Pada fase ini dilakukan definisi ruang lingkup masalah dengan melakukan pengamatan dan wawancara kepada pihak Transaksi Energi mengenai pengelolaan data-data pelanggan monitoring beserta prosesnya dan permasalahan yang dihadapi untuk menentukan ruang lingkup masalah. 2. Analisa masalah Pada fase ini dilakukan analisa masalah yang ada pada sistem monitoringuntuk kemudian dapat mendefinisikan sebuah tujuan perbaikan.

35 7 3. Analisa Kebutuhan Pada fase ini dilakukan analisa kebutuhan-kebutuhan pengguna, untuk mencari tahu apa yang mereka perlukan atau inginkan dari sistem baru. Dimulai dengan mendeskripsikan calon pengguna sistem informasi kemudian digambarkan dalam bentuk use-case. 4. Desain logikal Pada fase ini akan dilakukan desain secara logical. Desain logical dari sistem informasi ini meliputi desain basis data mengunakan Entity Relation diagram, diagram konteks, diagram berjenjang dan diagram arus data. 5. Desain fisikal Pada fase ini hal yang dilakukan adalah membangun sistem secara fisik berdasarkan teknologi yang digunakan, desain arsitektur dan desain antarmuka pengguna (user interface). 6. Konstruksi dan Pengujian Pada fase ini dilakukan pembuatan sistem sesuai dengan desain yang sudah dibuat sebelumnya dan pengujian sistem monitoring pelanggan ini terhadap pengguna sistem yaitu karyawan dan staff Transaksi Energi. 3. Survei Pengunaan Sistem Monitoring Uji coba sistem ini dilakukan untuk mengetahui sejauh mana dapat membantu dalam memberikan informasi tentang ketersediaan, riwayat, laporan dan membantu proses monitoring pelanggan dengan menerapkan manajemen transaksidengan menggunakan kuesioner Sistematika Penulisan Sistematika penulisan dibagi menjadi 6 Bab yang terdiri atas: BAB I Pendahuluan Berisi tentang latar belakang masalah, rumusan masalah,, tujuan, batasan masalah,metodologi penelitian, dan sistematika penulisan.

36 8 BAB II Landasan Teori Berisi teori-teori yang digunakan sebagai dasar untuk mengembangkan sistem monitoring pelanggan ini meliputi sistem monitoring, definisi Basis Data, Entity-Relationship Modelling, Use Case Diagram, Manajemen transaksi, JAVA, JSP, Semantic- UI dan Oracle 10g. BAB III Analisa Dan Perancangan Sistem Berisi tentang analisa sistem meliputi gambaran umum sistem, use case diagram,pemodelan sistem dalam bentuk diagram konteks, diagram berjenjang, diagram aliran data, pemodelan data yang terdiri dari entity relationship diagram. Desain sistem yang meliputi desain antarmuka dan desain basisdata terdiri dari desain logikal basis data dan desain fisikal basis data BAB IV Implementasi Sistem Berisi tentang penjelasan implementasi monitoring pelanggan yang meliputi struktur menu system, tampilan program, implementasi stored procedure, dan function, serta method yang dijalankan dalam program. BAB V Analisa Hasil Berisi tentang analisa dari hasil implementasi sistem yang telah dibangun, hasil pengujian stored procedure yang menerapkan method two phase locking dalam manajemen transaksi, dan membahas kelebihan dan kekurangan yang ada pada sistem. Bab ini juga membahas hasil uji coba sistem terhadap petugas di lapangan maupun non lapangan yang menjadi user dari sistem ini. BAB VI Penutup Berisi tentang kesimpulan dan saran atas pengembangan sistem monitoring pelanggan prabayar dan pascabayar di PT. PLN (Persero) Area Kuala Kapuas.

37 BAB II LANDASAN TEORI 2.1. Sistem Monitoring Secara harafiah sistem monitoring terdiri dari 2 (dua) kata yaitu sistem dan monitoring. Menurut Jogiyanto (2005), sistem adalah suatu jaringan kerja dari prosedur-prosedur yang saling berhubungan, berkumpul bersama-sama untuk melakukan suatu kegiatan atau untuk menyelesaikan suatu sasaran tertentu. Sistem mempunyai karakteristik atau sifat-sifat tertentu, yaitu : Komponen Sistem, Batasan Sistem, Lingkungan Luar Sistem, Penghubung Sistem, Masukan Sistem, Keluaran Sistem, Pengolahan Sistem, dan Sasaran Sistem (Sutanta, 2009). Menurut Cassely dan Kumar (1987) monitoring merupakan program yang terintegrasi, bagian penting dipraktek manajemen yang baik dan arena itu merupakan bagian integral di manajemen sehari-hari. Sedangkan menurut Calyton dan Petry (1983) monitoring sebagai suatu proses mengukur, mencatat, mengumpulkan, memproses dan mengkomunikasikan informasi untuk membantu pengambilan keputusan manajemen program/proyek. Sistem monitoring adalah suatu jaringan kerja dari prosedur yang saling berhubungan yang dapat mencatat, mengukur, mengumpulkan, memproses, melakukan pengawasan, dan mengkomunikasiskan informasi dari tiap bagian yang diawasi sehingga dapat membantu pengambilan keputusan manajemen program/proyek dalam sebuah perusahaan atau organisasi Basis Data Berikut ini merupakan penjelasan mengenai teori tentang Basis Data: Pengertian Basis Data J.L. Whitten dan L.D. Bentley (1998) mendefinisikan basis data sebagai sekumpulan data dalam file yang saling terhubung (interrelated file), record dalam file harus mengizinkan adanya kerelasian (dapat dibayangkan sebagai pointer) ke record-record lain dalam file lain. Abraham Silberschatz, Henry F. 9

38 10 Korth, dan S.Sudarshan (2001) mendefinisikan basis data sebagai sekumpulan data yang saling berhubungan dan menjadi bagian dari DBMS Sistem Basis Data Sistem basis data berbeda dengan basis data, sistem basis data memiliki ruang lingkup yang leboh luas karena terdiri dari kumpulan beberapa basis data baik yang terhubung maupun tidak terhubung secara langsung dalam suatu sistem, tetapi secara keseluruhan mempunyai hubungan sebagai sebuah sistem dengan didukung oleh komponen lainnya. Istilah sistem basis data dapat didefiniskan sebagai sekumpulan subsistem yang terdiri atas basis data dengan para pemakai yang menggunakan basis data secara bersama-sama, personal-personal yang merancang dan mengelola basis data, teknik-teknik untuk merancang dan mengelola basis data, serta sistem komputer untuk mendukungnya (Martin, 1975) Batasan Aturan Basis Data Dalam perancangan dan penyusunan basis data dikenal adanya beberapa batasan aturan yang haris ditaati. Batasan aturan tersebut diperlukan agar file-file basis data yang disusun dapat menenuhi batasan/kriteria sebagaimana definisi basis data yang dijelaskan sebelumnya. Menurut James Martin (1975), batasan aturan tersebut berhubungan dengan lima aspek penting dalam basis data, yaitu: 1. Kerangkapan data (data redudancy) 2. Inkonsistensi data (data inconsistency) 3. Data terisolasi (data isolation) 4. Kemananan data (data security) 5. Integritas data (data integrity) Abraham Silberschatz, Henry f.korth, dan S.Sudarshan (2001) menyatakan bahwa basis data yang benar mampu mengatasi semua permasalahan yang terkait dengan batasan aturan di atas. 1. Kerangkapan data (data redudancy) Kerangkapan data (data redudancy) adalah munculnya data-data yang sama secara melimpah (berulang kali) pada file basis data yang semestinya tidak diperlukan. Kerangkapan data dalam basis data perlu dihindari (paling tidak harus diminimalkan) karena beberapa alasan, yaitu (Sutanta, 2004) :

39 11 1. Pemborosan media penyimpanan basis data 2. Biaya penyimpanan yang semakin besar 3. Kesulitan atau in-efisiensi dalam pengolahan data 4. Pemborosan waktu dalam pengolahan data 5. Resiko yang semakin besar kemungkinan munculnya inkonsistensi data. 2. Inkonsistensi data (data inconsistency) Inkonsisten data (data inconsistency) atau data tidak konsisten adalah munculnya data yang tidak konsisten pada medan/kolom yang sama dalam satu atau beberapa file data yang dihubungkan/direlasikan (Sutanta, 2011). Inkonsistensi data ini dapat terjadi diakibatkan oleh (Sutanta, 2004): 1. Proses pemasukan data (data entry) yang tidak benar 2. Proses pembaruan data (update) yang tidak benar 3. Pengendalian sistem yang tidak baik/terkontrol Menurut Edhy Sutanta dalam bukunya yang berjudul Basis Data dalam Tinjaun Konseptual (2004) penyebab utama munculnya data yang tidak konsisten adalah akibat munculnya kerangkapan data dalam file. Oleh karena itu, contoh inkonsistensi data ini juga dapat berlaku pada file yang mengalami kerangkapan data. Basis data yang baik haruslah terbebas dari inkonsistensi data karena akan berakibat kesalahan fatal pada informasi yang dihasilkan dari pengolahan data dalam basis data yang tidak dapat merepresentasikan fakta yang ada. 3. Data Terisolasi (Data Isolation) Data terisolasi disebabkan oleh pemakaian beberapa file basis data dimana program aplikasi tidak dapat mengakses data-data dan file tertentu, kecuali bila program aplikasi diubah/ditambah sehingga seolah-olah ada file yang terpisah/terisolasi terhadap file yang lain dalam basis data (Sutanta, 2009). Data terisolasi harus dihindari karena mengakibatkan ketidaklengkapan informasi yang dihasilkan dari pengolahan data dalam basis data. Ini mengakibatkan informasi hasil pengolahan dalam basis data menjadi tidak bernilai. Data terisolasi dapat terjadi (Sutanta, 2004) :

40 12 1. Tidak adanya kemungkinan untuk menghubungkan antar data dalam file. 2. Tidak adanya standarisasi data (berkaitan dengan domain/format data, meliputi tipe dan ukuran data). 4. Keamanan Data (Data Security) Kemananan data (data security) merupakan aspek penting dalam basis data. Prinsip keamanan dalam basis data adalah bahwa data-data dalam basis data merupakan sumber informasi yang bersifat sangat penting dan rahasia (Sutanta, 2011). Sehingga perlu untuk menjaga data-data dari kerusakan dan kehilangan yang dapat merusak data. Aspek keamanan basis data meliputi (Martin, 1975): 1. Recovery, adalah suatu proses menggunakan kembali basis data dan media penyimpanan cadangan untuk mengembalikan data pada kondisi yang benar karena terjadi kerusakan/kehilangan data akibat kerusakan media penyimpanan, program aplikasi, OS, basis data, hardware, dll. 2. Integrity, adalah dengan unjuk kerja sistemuntuk dapat menjaga data-data dalam basis data agar selalu berada dalam kondisi yang benar (tipe dan ukuran datanya), up to date (sesuai dengan kondisi aktual), konsisten, dan selalu tersedia. 3. Concurency, berkaitan dengan mekanisme pengendalian basis data saat digunakan oleh beberapa pemakai secara bersamaan agar terhindar dari kesalahan akibat beberapa transaksi berbeda dilakukan secara bersamaan. 4. Privacy, yaitu dimaksudkan sebagai pembatasan kewenangan akses data dalam basis data dari penggunaan oleh pengguna yang tidak berwewenang dan pengubahan yang tidak dikehendaki. 5. Security, adalah suatu mekanisme system utnuk mencegah dan melindungi basis data kehilangan akibat kerusakan pada fisik media penyimpanan, kebakaran, banjir, badai, huru-hara, dll. 5. Integritas Data (Data Integrity) Integritas data (data integritas) berhubungan dengan kinerja sistem agar dapat melakukan kendali/control pada semua bagian sistem. Integritas dimaksudkan sebagai suatu sarana untuk meyakinkan bahwa data-data yang tersimpan dalam

41 13 basis data selalu berada dalam kondisi yang benar (tipe dan ukuran datanya), up to date (sesuai dengan kondisi aktual), konsisten, dan selalu tersedia (current). Hal ini merupakan aspek kritis dalam manajemen basis data (Martin, 1975) Entity-Relationship Modelling (E-R Modelling) Entity Relationship Modelling E-R Modelling merupakan suatu model data yang dikembangkan berdasarkan obyek. E-R Modelling digunakkan untuk menjelaskan hubungan antar data dalam basis data kepada pengguna secara logic. E-R Modelling didasarkan pada suatu persepsi bahawa real world terdiri atas obyek-obyek dasar yang mempunyai hubungan/kerelasian antarobyek-obyek dasar tersebut (Martin, 1975). E-R Modelling digambarkan dalam bentuk diagram yang disebut diagram E-R (E-R Diagram/E-R_D). Untuk menggambarkan E-R_D digunakan simbol-simbol grafis tertentu. Penggunaan E-R Modelling relatif mudah dipahami, bahkan oleh para pengguna yang awam. Bagi perancang/analis sistem, E-R_D berguna untuk memodel-kan sistem yang nantinya basis datanya akan dikembangkan. Model ini juga membantu perancang/analis sistem pada saat melakukan analisis dan perancangan basis data karena model ini dapat menunjukkan macam data yang dibutuhkan dan kerelasian antardata di dalamnya. Bagi pengguna, model ini sangat membantu dalam hal pemahaman model sistem dan rancangan basis data yang akan dikembangkan oleh perancang/analis sistem (Sutanta, 2004) Tipe Entitas (Entity Type) Tipe Entitas (Entity Type)ialah sekumpulan objek yang memiliki property yang sama yang diidentifikasi dalam perusahaan serta keberadaannya independen. Setiap objek yang diidentifikasikan secara unik disebut entity occurrence (Connolly and Beg, 2002). Gambar 2.1 di bawah ini menunjukkan representasi diagram dari contoh entity type.

42 14 Gambar 2. 1Representasi Diagram dari Entity Type Staff dan Branch(Connolly and Beg, 2002) Tipe Relasi (Relationship Type) Tipe Relasi (Relationship Type)ialah sekumpulan entitas (entity) yang mempunyai hubungan dan memiliki arti (Connolly and Beg, 2002) ditunjukkan secara lebih jelas pada gambar 2.2 berikut ini: Gambar 2. 2Representasi Diagram dari Entity Branch Has Staff Relationship Type(Connolly and Beg, 2002) Atribut (Attributes) Menurut Connolly dan Beg (2002, p350), atribut adalah properti dari sebuah entity atau relationship type. Sedangkan attribute domain adalah sekumpulan nilai yang dibolehkan untuk satu atau lebih atribut. Atribut dapat diklasifikasikan sebagai :

43 15 1. Simple Attribute dan Composite Attribute Simple attribute adalah attribute yang terdiri dari komponen tunggal dimana attribute tersebut tidak dapat dibagi ke dalam komponen yang lebih kecil. Simple attribute juga dapat disebut dengan atomic attribute. Contoh dari simple attribute adalah position dan salary dari staff entity. Composite attribute adalah attribute yang terdiri dari banyak komponen dimana beberapa attribute tersebut dapat dibagi kedalam komponen yang lebih kecil. Contoh dari composite attribute adalah address dari branch entity yang dapat dibagi menjadi street, city, dan postcode. 2. Single-Valued Attribute dan Multi-Valued Attribute Single-valued attribute adalah attribute yang memiliki satu nilai pada setiap entity. Contoh dari single-valued attribute adalah branch_no dari branch entity. Multi-valued attribute adalah attribute yang memiliki beberapa nilai pada setiap entity. Contoh dari multi-valued attribute adalah tel_no dari branch entity. 3. Derived Attribute Derived Attribute adalah atribut yang nilai-nilainya diperoleh dari hasil perhitungan atau dapat diturunkan dari atribut lain yang berhubungan. Contoh dari derived attribute adalah duration dari lease entity dimana diperoleh dari perhitungan rent_start dan rent_finish. Gambar 2. 3Representasi Diagram dari Entity Staff dan BranchBeserta Atribut- Atributnya(Connolly and Beg, 2002)

44 Kunci (Keys) Menurut Connolly dan Begg (2002) jenis jenis kunci adalah sebagai berikut (ilustrasi untuk memperjelas dijelaskan pada gambar 2.3) : 1. Candidate key, jumlah minimal dari attribute yang secara unik mengidentifikasi setiap peristiwa dalam entity 2. Primary key, candidate key yang terpilih secara unik mengidentifikasi setiap peristiwa dalam entity 2. Alternate key, candidate key yang tidak terpilih menjadi primary key 3. Composite key, candidate key yang terdiri dari dua atau lebih attribute 4. Foreign key, atribut sebuah entity yang menggabungkan diri ke entity lain Manajemen Transaksi Transaksi adalah sebuah tindakan atau serangkaian tindakan, dilakukan olehuser atau program aplikasi, yang membaca atau mengubah isi dari basis data(connolly and Beg, 2002). Terdapat 4 hal dasar yang harus dimiliki semua transaksi, yaitu: 1. Atomicity Sebuah transaksi adalah sebuah unit yang tidak dapat dibagi lagi sehingga dapatmelakukan seluruhnya atau tidak melakukan apapun. Ini merupakan tanggung jawab dari subsistem recovery dari DBMS untuk memastikan ke- atom -annya. 2. Consistency Sebuah transaksi harus mentransformasikan satu keadaan konsisten ke keadaan konsisten lainnya. Ini merupakan tanggung jawab dari DBMS dan pengembang aplikasi untuk memastikan kekonsistenannya. 3. Isolation Transaksi secara bebas mengeksekusi yang lainnya. Dengan kata lain, sebagian transaksi yang tidak lengkap akan mengakibatkan transaksi yang lain menjadi tidak visible.ini merupakan tanggung jawab dari subsistem concurrency control untuk memastikan isolasi. 4. Durability Setelah DBMS memberitahu pengguna bahwa transaksi telah selesai

45 17 dengan sukses, maka efeknya tetap bertahan bahkan jika sistem mengalami crash sebelum semua perubahannya direfleksikan pada disk. Ini merupakan tanggung jawab dari recovery subsistem untuk memastikan durability. Gambar 2. 4Diagram Transisi Transaksi (Connolly and Beg, 2002) Berdasarkan Gambar 2.4 dalam diagram transisi tersebut terdapat 5 keadaan yaitu: 1. ACTIVE (aktif) 2. PARTIALLY COMMITTED (sebagian dilaksanakan) Terjadi setelah perintah terakhir dieksekusi Pada saat ini, mungkin ditemukan transaksi melanggar serializability atau melanggar integrity constraint, maka transaksi harus dibatalkan. Transaksi demikian akan menuju FAILED (keadaan gagal) dan harus dibatalkan Jika transaksi sukses, beberapa update dapat disimpan secara aman dan transaksi menuju ke keadaan COMMITTED. 3. COMMITTED (dilaksanakan) 4. FAILED (gagal) Terjadi jika transakasi tidak dapat dilaksanakan atau transaksi dibatalkan pada saat ACTIVE (keadan aktif). Kondisi ini terjadi jika user membatalkan transaksi atau protocol concurrency control membatalkan transaksi untuk memastikan serialibility. 5. ABORTED (dibatalkan)

46 Metode Locking Locking adalah sebuah prosedur yang digunakan untuk melakukan kontrol pada akses bersama pada data. Pada saat satu transaksi melakukan akses ke dalam database, sebuah lock akan menyebabkan pelarangan akses ke dalam transaksi untuk mencegah hasil yang tidak konsisten. Terdapat 2 jenis lock, yaitu Shared Lock, dan Exclusive Lock. Jika sebuah transaksi memiliki shared lock padasebuah data item, maka transaksi tersebut dapat melakukan pembacaan terhadap sebuah item tetapi tidak dapat melakukan update. Sedangkan jika sebuah transaksi yang memiliki Exclusivelock pada sebuah data item dapat melakukan pembacaan maupun update item tersebut Two Phase Locking (2PL) Transaksi dapat dilakukan menggunakan protokol 2PL jika semua operasilocking mendahului operasi yang tidak terkunci dalam transaksi tersebut.protokol 2PL memiliki 2 fase, yaitu (Connolly and Beg,2002): a. Growing phase : jika transaksi sudah mendapatkan semua lock, maka tidak boleh melepas lock. b. Shrinking phase : jika transaksi sudah melepaskan lock, maka tidak dapat mendapatkan lock baru. Beberapa masalah yang disebabkan oleh proses yang konkurenseperti dibawah ini bisa ditangani dengan menerapkan protokoltwo phase locking(2pl)(connolly and Beg,2002): a. The Lost Update Problem, merupakan kejadian dimana data transaksi yang telah diupdate dibaca oleh transaksi yang lain kemudian di update lagi. b. The Uncommited Dependency (Dirty Read) Problem, merupakan kejadian dimana data transaksi yang dilakukan dibaca oleh transaksi yang lain, lalu dibatalkan tanpa adanya penyimpanan terlebih dahulu oleh transaksi yang pertama sehingga menyebabkan data yang tidak benar. c. The Incosistent Analysis Problem, masalah ini timbul karena data diakses oleh 2 transaksi yang bersamaan, transaksi yang pertama

47 19 melakukan perubahan dan transaksi yang kedua melakukan analisis sehingga data yang diperoleh menjadi tidak konsisten Contoh Penangangan Masalah Concurrency Control Di bawah ini merupakan contoh-contoh untuk menangani masalah concurrency control : Gambar 2. 5Mencegah Lost Update Problem menggunakan 2PL(Connolly and Beg, 2002) Keterangan : Untuk mencegah terjadinya masalah hilangnya data yang diubah, maka : pertama-tama T2 meminta exclusive lock pada balₓ Setelah itu T2 dapat melakukanproses baca nilai balₓ, menambahnya dengan nilai 100, dan menuliskan nilai baru dari balₓ tersebut kedalam basis data. Saat T1 memulai transaksi, T1 juga meminta suatu exclusivelock pada balₓ, namun karena balₓ sedang berada dalam posisiexclusive lock oleh T2, maka permintaan read balₓ tidak segera diberikan kepada T1 dan T1 harus menunggu sampai lock dilepaskan oleh T2. Hal ini terjadi saat t2 melaksanakan operasi commit atau unlock bal x (Connolly and Beg, 2002).

48 20 Gambar 2. 6Mencegah Uncommited Dependency Problem using 2PL(Connolly and Beg,2002) Keterangan : Untuk mencegah terjadinya masalah ketergantungan transaksi yang belum dilaksanakan, maka : pertama-tama T4 meminta suatu exclusive lock pada balx. Setelah itu, T4 dapat melakukan proses baca nilai balx dari dalam basis data, menambahnya dengan nilai 100, dan menuliskan nilai baru balx tersebut ke dalam basis data. Rollback dieksekusi, peng-update-an pada transaksi T4 tidak jadi dilakukan dan nilai dalam basis data dikembalikan ke kondisi semula yaitu 100. Saat T3 memulai transaksi, T3 juga meminta suatu exclusive lock pada balx, namun karena balx sedang dalam posisi exclusive lock oleh T4 maka permintaan tersebut tidak segera diberikan kepada T3, dan T3 harus menunggu sampai lock dilepaskan oleh T4. Hal ini terjadi saat T4 melakukan operasi rollback atau unlock balx, barulah T3 dapat melakukan proses baca nilai balx (Connolly and Beg, 2002).

49 21 Gambar 2. 7Mencegah Inconsistent Analysis Problem using 2PL(Connolly and Beg,2002) Keterangan : Untuk mencegah terjadinya masalah analisis yang tidak konsisten, maka : T5 mengawali meminta suatu exclusive lock pada balx. T5 juga meminta suatu exclusive lock pada baly. Saat T6 ingin membaca nilai balx, ia harus menunggu sampai lock dilepaskan oleh T5. Hal ini terjadi saat T5 melaksanakan operasi commit atau unlockbalx, barulah T6 dapat membaca nilai balx(connolly and Beg, 2002). Untuk mengatasi masalah di atas, mesin basis data Oracle mempunyai kemampuan mendukung transaksi dengan metode 2PL yang dapat menjamin konsistensi data Perintah For Update Perintah for update yang digunakan untuk melakukan penguncian agar menjamin konsistensi. Untuk menjamin konsistensi data, terutama dalam kasus ketika ada banyak sesi terhadap suatu database yang sama, sebaiknya baris-baris record dalam database yang akan di-update atau dihapus, dikunci terlebih dahulu.

50 22 Penguncian record dalam database dapat dilakukan dengan perintah for update dalam kueri(oracleinc, 2004). Sintak yang digunakan : 2.3. Use Case Diagram Pembuatan use case diagram yang sesungguhnya merupakan deskripsi peringkat tinggi bagaimana perangkat lunak (aplikasi) akan digunakan oleh penggunanya. Selanjutnya use case diagram tidak hanya sangat penting pada tahap analisis, tetapi juga sangat penting untuk perancangan (design), untuk mencari (mencoba menemukan) kelas-kelas yang terlibat dalam aplikasi, dan untuk melakukan pengujian (testing). Membuat use case diagram yang komprehensif merupakan hal yang sangat penting dilakukan pada tahap analisis. Dengan menggunakan usecase diagram, akan didapatkan banyak informasi yang sangat penting yang berkaitan dengan aturan-aturan bisnis yang coba kita tangkap. Dalam hal ini, setiap objek yang berinteraksi dengan sistem/perangkat lunak (misalnya orang, suatu perangkat keras, sistem lain, dan sebagainya) merupakan actor untuk sistem perangkat lunak, use case merupakan deskripsi lengkap tentang bagaimana sistem/perangkat lunak berperilaku untk para aktornya. Dengan demikian use case diagram merupakan deskripsi lengkap tentang interaksi yang terjadi antara para actor dengan sistem/perangkat lunak yang sedang dikembangkan. Saat akan mengembangkan use case diagram, hal yang pertama kali dilakukan adalah mengenali actor untuk sistem/aplikasi yang sedang dikembangkan. Dalam hal ini, ada beberapa karakteristik untuk para actor, yaitu actor ada di luar sistem yang sedang dikembangkan dan actor berinteraksi dengan sistem yang sedang dikembangkan (Adi Nugroho, 2009). Rosa A. S dan M. Salahuddin (2013) mengungkapkan bahwa Use case atau diagram use case merupakan pemodelan untuk kelakuan (behavior) sistem informasi yang akan dibuat.

51 23 Notasi yang digunakan dalam Use Caseadalah seperti yang disajikan dalam tabel 4.1 berikut ini: Tabel 2. 1 Notasi Use Case No Notasi Keterangan <<include>> Gambar di samping adalah notasi untuk aktor. Aktor menggambarkan segala pengguna software aplikasi (user). Gambar di samping adalah notasi untuk use case. Use case menjelaskan urutan kegiatan yang dilakukan actor dan sistem untuk mencapai tujuan tertentu. Gambar di samping adalah notasi untuk interaction. Interaction digunakan untuk menunjukkan baik aliran pesan atau informasi antar objek. Gambar di samping adalah notasi untuk package. Package adalah mekanisme pengelompokan yang digunakan untuk menandakan pengelompokan elemenelemen model. Extend adalah Relasi usecase tambahan kesebuah usecase dimana use case yang ditambahkan dapat berdiri sendiri walau tanpa use case tambahan itu. Include adalah relasi usecase tambahan ke sebuah usecase dimana use case yang ditambahkanmemerlukan usecase ini untuk menjalankan fungsinya Class Diagram Class Diagram adalah diagram yang menunjukan class-class yang ada dari sebuah sistem dan hubungannya secara logika. Class diagram menggambarkan struktur statis dari sebuah sistem. Rosa A.S dan M. Shalahuddin (2014:141) menyatakan bahwa class diagram menggambarkan struktur sistem dari segi pendefenisian kelas-kelas yang akan dibuat untuk membangun sistem. Class diagram memiliki beberapa simbol-simbol yaitu:

52 24 Tabel 2. 2 Notasi class diagram (Rosa A.S dan M. Shalahuddin,2014) Nama Simbol Simbol Deskripsi Package Package merupakan sebuah bungkusan dari satu atau lebih kelas Kelas Kelas pada struktur sistem. Asosiasi/ association asosiasi berarah/ directed association Relasi antarkelas dengan makna umum, asosiasi biasanya juga disertai dengan multiplicity Relasi antar kelas dengan makna kelas yang satu digunakan oleh kelas lain, asosiasi juga biasanya disertai dengan multiplicity 2.5. Activity Diagram Activity diagram menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi. Rosa A.S & M. Shalahuddin (2010:134) menyatakan bahwa activity diagram menggambarkan workflow (aliran kerja) atau aktivitas dari sebuah sistem, proses bisnis atau menu yang ada diperangkat lunak. Tabel 2. 3Notasi activity diagram(rosa A.S & M. Shalahuddin, 2010)

53 Oracle Oracle Corporation (Oracle Corp) memberikan definisi-definisi sendiri tentang basis data relasional, yaitu kumpulan relations. Sebuah relation adalahsebuah two-dimensional table. Lebih tepatnya adalah kumpulan tabel dan obyek-obyek non tabel yang dikelompokan berdasarkan pemakai (OracleInc, 2004). Sifat-sifat basis data relasional: 1. Bisa diakses lewat bahasa pemrograman tingkat tinggi, SQL (Structured Query Language). 2. Memiliki sekumpulan tabel tanpa pointer fisik (Oracle melanggar perintah ini dengan tipe REF). 3. Memakai sekumpulan operasi set Penjelasan Tentang SQL SQL (Structured Query Language) adalah bahasa standar yang digunakan untuk memperoleh dan memanipulasi data dari basis data relasional. SQL merupakan bahasa nonprosedural yang mendefinisikan apa yang harus dilakukan oleh sebuah basis data relasional, yang kemudian akan mengimplementasikan perintah SQL tersebut. Salah satu keuntungan dari SQL adalah karena SQL benar-benar merupakan bahasa standar yang cross-platform dan cross-product. SQL beroperasi pada semua basis data relasional yang ada, dan berjalan pada semua sistem operasi. Walau mungkin masing-masing vendor database memiliki implementasi yang sedikit berbeda dengan SQL masih tetap dapat digunakan hanya dengan sedikit penyesuaian. SQL memungkinkan seorang database administrator, user, dan programmer untuk:

54 26 1. Memperoleh dan mengubah struktur database. 2. Memperoleh, mengubah, menambah, dan menghapus informasi yang ada pada database. 3. Melakukan fungsi keamanan dan mengatur hak akses pemakai pada masing-masing tabel dan basis data yang ada. 4. Mengatur proses transaksi yang terjadi Data Definition Language (DDL) Data Definition Language(DDL) adalah perintah-perintah pada SQL yang digunakan untuk mendefinisikan data pada sebuah basis data. Contoh DDL adalah: 1. Create, digunakan untuk membuat sebuah tabel, indeks, atau basis data baru. Sintaks SQLnya: 2. Drop, digunakan untuk menghapus sebuah tabel atau basis data. Contoh sintaks SQLnya: 3. Alter, digunakan untuk mengubah sebuah tabel atau basis data yang sudah dibuat. Contoh sintaks SQLnya:

55 Data Manipulation Language (DML) Data Manipulation Language(DML) adalah berbagai perintah yang digunakan untuk memanipulasi data yang ada pada sebuah database yang telah didefinisikan sebelumnya. Contoh perintah-perintah DML antarara lain: 1. Select, digunakan untuk mengambil data yang tersimpan pada tabel atau membaca isi tabel (query). Contoh sintaksnya adalah: 2. Insert, digunakan untuk menyisipkan databaru ke dalam tabel. Contoh sintaksnya adalah: 3. Update, digunakan memperbaharui data yang terdapat pada tabel. Contoh sintaksnya adalah: 4. Delete, digunakan untuk menghapus data yang ada pada tabel. Contoh sintaksnya adalah:

56 Stored Procedure Program yang dibuat dengan menggunakan bahasa SQL dan store prosedure dalam database yang memiliki prosedur mandiri, fungsi, dan paketkemudian disimpan dalam database dan membentuk komponen SQL yang dikenal sebagai stored procedure(oracle Corporation, 2002). StoredProcedure adalah salah satu tipe dari subprogram yang melakukan sebuah aksi. Prosedur akan disimpan dalam database sebagai sebuah skema untuk dapat dieksekusi kembali. Sintaks untuk membuat stored procedure adalah sebagai berikut (Rido,dkk.2013) : CREATE [OR REPLACE] PROCEDURE procedure_name [ (parameter1 [mode1] datatype1, (parameter1 [mode1] datatype1,,,, ) ] IS AS [DECLARATION SECTION] BEGIN EXECUTABLE SECTION EXCEPTION (OPTIONAL) EXCEPTION SECTION END; Keterangan : Parameter Create Replace Create or replace Procedure_name Parameter Mode Data type IS AS DECLATION SECTION Keterangan Digunakan untuk membuat prosedur baru. Digunakan untuk mengidentifikasi jika prosedur tersebut sudah ada. Memberikan fleksibilitas untuk membuat bila belum ada atau mengubah jika sudah ada. Nama dari prosedur Nama dari variabel PL/SQL yang memiliki nilai untuk dipassingkan atau dipopulate oleh calling environment tergantung dari jenis modenya. Tipe dari argumen: IN (default) OUT INOUT Tipe dari argumen yang digunakan. Keyword (dapat dipilih salah satu, tidak ada perbedaan diantara keduanya) Tidak perlu menggunakan keyword DECLARE (seperti di anonymous

57 29 EXECUTABLE SECTION EXCEPTION SECTION PL/SQL).Tempat mendeklarasikan tipe, variabel, dll. Akan dimulai dengan BEGIN atau diakhiri dengan END atau ENDprocedure_name. Isi dari prosedur yang menunjukan adanya aksi yang dilakukan oleh prosedur. Bersifat opsional. Digunakan untuk mentrapp kondisi eror. Sintaks untuk menghapus Procedure: DROP PROCEDURE procedure_name; Sintaks untuk menjalankan Proceduredari SQL Worksheet: EXECUTE procedure_name; Stored Function Fungsi adalah sebuah blok PL/SQL yang memiliki nama yang mengembalikan sebuah fungsi. Fungsi dapat disimpan dalam database sebagai sebuah object schema. Sehingga pada saat tertentu dapat diulang kembali proses eksekusinya. Fungsi dapat dipanggil sebagai bagian dari sebuah ekspresi. Berikut ini adalah sintak dari stored function (Rido,dkk.2013): CREATE [OR REPLACE] FUNCTION function_name [ (parameter1 [mode1] datatype1, (parameter1 [mode1] datatype1,,,, ) ] RETURN dataype IS AS [DECLARATION SECTION] BEGIN EXECUTABLE SECTION EXCEPTION (OPTIONAL) EXCEPTION SECTION RETURN namavar; END; Keterangan: Parameter Function_name Parameter Keterangan Nama dari fungsi Nama dari variabel PL/SQL yang nilainya akan dipassingkan ke fungsi.

58 30 Mode Data type RETURN datatype DECLARATION section RETURN namavar Executable section Tipe dari parameter, hanya IN parameter yang dikenal di dalam fungsi. Tipe data dari parameter. Tipe dari nilai kembalian (return) yang merupakan output dari fungsi. Tempat untuk mendefinisikan variabel. Nama variabel tempat pengembalian nilai. Isi dari fungsi 2.7. Java & JSP Java Java merupakan bahasa pemrograman yang saat ini sedang naik daun dan banyak digunakan oleh para programmer dan software developer untuk mengembangkan berbagai tipe aplikasi, mulai dari aplikasi console, aplikasi desktop, applet (aplikasi yang berjalan di lingkungan web browser), sampai ke aplikasi-aplikasi yang berskala enterprise. Untuk memenuhi kebutuhan tipe aplikasi yang beragam tersebut, Java dikategorikan menjadi tiga edisi, yaitu (Raharjo, Heryanto & Haryano, 2012): 1. J2SE (Java 2 Platform, Standard Edition) untuk pembuatan aplikasiaplikasi desktop dan applet 2. J2EE (Java 2 Platform, Enterprise Edition) untuk pembuatan aplikasiaplikasi multi-tier berskala enterprise 3. J2ME (Java 2 Platform, Micro Edition) untuk pembuatan aplikasiaplikasi yang dapat dijalankan di lingkungan perangkat-perangkat mikro seperti handphone dan PDA JSP (Java Servlet Pages) JSP adalah suatu teknologi web berbasis bahasa pemrograman Java dan berjalan di Platform Java, serta merupakan bagian teknologi J2EE (Java 2 Enterprise Edition). JSP sangat sesuai dan tangguh untuk menangani presentasi di web. Sedangkan J2EE merupakan platform Java untuk pengembangan sistem aplikasi enterprise dengan dukungan API (Application Programming Inteface) yang lengkap dan portabilitas serta memberikan sarana untuk membuat suatu

59 31 aplikasi yang memisahkan antara business logic (sistem), presentasi dan data. JSP merupakan bagian dari J2EE dan khususnya merupakan komponen web dari aplikasi J2EE secara keseluruhan. JSP juga memerlukan JVM (Java Virtual Machine) supaya dapat berjalan, yang berarti juga mengisyaratkan keharusan menginstal Java Virtual Machine diserver, dimana JSP akan dijalankan. Selain JVM, JSP juga memerlukan server yang disebut dengan Web Container. Teknologi JSP menyediakan cara yang lebih mudah dan cepat untuk membuat halaman-halaman web yang menampilkan isi secara dinamik. Teknologi JSP di desain untuk membuat lebih mudah dan cepat dalam membuat aplikasi berbasis web yang bekerja dengan berbagai macam web server, application server, browser dan developmenttool. Java Server Pages (JSP) adalah bahasa scripting untuk web programming yang bersifat server side seperti halnya PHP dan ASP. JSP dapat berupa gabungan antara baris HTML dan fungsi-fungsi dari JSP itu sendiri. Berbeda dengan Servlet yang harus dikompilasi oleh user menjadi class sebelum dijalankan, JSP tidak perlu dikompilasi oleh user tapi server yang akan melakukan tugas tersebut. Pada saat user membuat pertama kali atau melakukan modifikasi halaman dan mengeksekusinya pada web browser akan memakan sedikit waktu sebelum ditampilkan. Daur Hidup JSP sebagai gambaran bagaimana JSP melalui masa hidupnya bisa dilihat pada gambar 4.4 berikut: Gambar 2. 8Daur hidup JSP

60 32 Seperti tipe aplikasi java lainnya (Servlet, Applet, Midlet dll), JSP juga bertipe strong type artinya penggunaan variable pada halaman tersebut harus dideklarasikan terlebih dahulu. Misalnya pada sintaks pengulangan berikut : for (int i=1; i<13; i++) { // statement } Seperti halnya skrip-skrip server side yang lain, JSP pun memerlukan Web server. Skrip ASP memerlukan IIS sebagai web server, PHP memerlukan IIS atau Apache, sedangkan JSP bisa menggunakan Apache Tomcat sebagai salah satu web server yang mendukungnya agar bisa menjalankan file-file JSP yang berbasis Java, diperlukan web server yang mampu memproses Java, atau minimal JSP engine yang dapat terintegrasi dengan web server. Web Containermenurut spesifikasi J2EE, dikenal EJB Container, Web Container dan Application Server. Web Container adalah service yang dijalankan oleh suatu Java Application Serverkhususnya untuk service yang compliance/kompatibel dengan Servletdan JSP. Selain menjadi service oleh Java Application Server, Web Container dapat berdiri sendiri. Contoh Web Container adalah Tomcat, ServletExec, Resin, Jrun, Blazix. Web Container juga dapat bekerja sama dengan web server, misalnya Tomcat dengan Apache, Jrun dengan IIS. Web Server adalah software untuk server yang menangani request melalui protokol HTTP yang digunakan oleh situs-situs web saat ini dalam menangani request file statik HTML, sepeti Apache dan Microsoft IIS. Web server sekarang sering dibungkus oleh Java Application Server sebagai HTTP Server. Java Application Server adalah server yang terdiri atas HTTP Server (Web Server), EJB Container maupun Web Container. Contoh Java Application Server: Sun J2EE RI 1.2/1.3, Borland AppServer 4.5/Enterprise Server 5.0, Oracle9i Application Server dan lainnya.

61 Semantic-UI Semantic User Interfaces (SUI) adalah set statis yang saling terkait dengan pengguna sehingga mudah untuk diedit, lebih spesifik dalam teta letak dan konten dengan makna yang didefinisikan melalui dekorasi semantik. SUI menggunakan pendekatan berorientasi objek dimana eleman dalamsui statis yang dipetakan melalui domain ontomologi. layanan yang adal telahh disediakan sesuai dengan deklarasi aslinya dan mengasosiasikan dengan data dan logika aplikasi melalui semantik berdasrkan ontologi domain. dalam hal ini menjamin komponen semantik UI dari unsur-unsur sistem infrastruktur.

62 BAB III ANALISA DAN PERANCANGAN SISTEM 3.1. Analisis Sistem Gambaran Umum Sistem Lama Sistem khusus yang digunakan memonitoring pelanggan untuk jangka waktu lama memang secara official(resmi) belum ada. Selama ini sistem pencatat hasil monitoring untuk pelanggan sebatas trek record perbulan saja. Untuk monitoring pelanggan dengan kwh Maks, kwh 0, dan tidak beli token lebih dari 3 bulan, petugas akan mendownload list pelanggan dari AP2T (Aplikasi Pelayanan Pelanggan Terpusat) kemudian melakukan cek manual ke lapangan baru kemudian menyerahkan bukti foto dan hasil monitoring ke petugas di kantor untuk kemudian diupload dan diverifikasi oleh Asisten Manajer Transaksi Energi atau Supervisor Transaksi Energi Listrik untuk mengambil keputusan akan approve atau tidak. Sistem yang lama tidak dapat menampilkan history monitoring dari seorang pelanggan berapa kali dimonitor, diapprove, atau dibatalkan. Sistem ini tidak dapat melakukan filterisasi pelanggan yang sudah dimonitor, diapprove, atau yang belum dimonitor dan diapprove sama sekali, sehingga tidak ada reliability untuk data yang sudah diapproveatau yang sudah dimonitor Gambaran Umum Sistem Baru Sistem baru yang akan dibuat adalah sistem monitoring pelanggan prabayar dan pasca bayar berbasis web sehingga baik petugas kantor area maupun rayon dapat mengakses dan melakukan monitoring bersama melalui sistem ini. Proses bisnis yang ditangani dalam sistem ini meliputi upload data hasil monitoring, approval data hasil monitoring, lihat history monitoring pelanggan, dan cetak reportmonitoring pelanggan. Setelah login sebagai admin area, petugas dapat menambahkan user dengan tipe admin atau operator, melihat semua data monitoring di semua rayon 34

63 35 kwh maks, kwh 0, dan tidak beli token baik yang sudah dimonitor, belum dimonitor, sudah approve maupun yang belum diapprove, dan melakukan pencarian berdasarkan id pelanggan. Admin rayon memiliki hak akses yang sama seperti admin area namun tidak memiliki akses untuk menambahkan user dan akses ke data monitoring rayon lain. User bertipe admin ini memiliki hak untuk mengubah data monitoring, melakukan approve atau membatalkan approve pada data monitoring pelanggan, melihat history monitoring pelanggan, dan mencetak laporan monitoring. User yang merupakan operator area dapat melihat seluruh data monitoring pelanggan di semua rayon, mengupload data hasil monitoring atau mengubah data hasil monitoring, dan melakukan pencarian berdasarkan id pelanggan. Berbeda dengan user yang merupakan operator rayon tidak memiliki akses ke data monitoring pelanggan yang bukan pada rayonnya sendiri. Kedua user ini mampu melihat versi terdahulu dari sebuah data monitoring, namun tidak dapat melihat history keseluruhan Orang yang Terlibat Dalam Sistem Orang yang terlibat dalam sistem monitoring pelanggan pasca bayar dan prabayar ini adalah sebagai berikut : 1. Asman TE Asisten Manajer TE (Transaksi Energi) bertugas sebagai pihak yang melakukan pengawasan terhadap kegiatan monitoring pelanggan dan memiliki hak untuk mengubah data hasil monitoring, melakukan approval terhadap data monitoring atau melakukan pembatalan approve pada data tersebut, dan pihak yang mendapatkan laporan mengenai hasil monitoring pelanggan kwh Maks, kwh 0, dan tidak beli token lebih dari 3 bulan. 2. Spv TEL Spv TEL (Supervisor Transaksi Energi Listrik) bertugas sebagai pihak yang menambahkan user, mengubah data hasil monitoring, melakukan approval terhadap data monitoring atau melakukan melakukan

64 36 pembatalan approve pada data tersebut, dan mendapatkan laporan rekomendasi monitoring naik daya pelanggan kwh maks. 3. Staff transaksi energi Staff transaksi energi bertugas untuk melakukan monitoring di kantor terhadap pelanggan kwh Maks, kwh 0, dan tidak beli token, mengupload data hasil monitoring, dan membatalkan data hasil monitoring jika data tidak sesuai. 4. Petugas lapangan Sama seperti staff transaksi energi, petugas lapangan melakukan monitoring terhadap setiap pelanggan kwh Maks, kwh 0, dan tidak beli token dilapangan, mengupload data hasil monitoring seperti foto, koordinat, tgl monitoring, dan keterangan hasil monitoring Batasan Sistem Monitoring Pelanggan Pasca Bayar dan Prabayar Untuk lebih memfokuskan pada pembuatan sistem monitoring dengan manajemen transaksiguna melancarkan proses bisnis pada bagian Transaksi Energi, batasanbatasan sistem yang digunakan Penulis sebagai berikut : 1. Sistem berbasis web namun tidak tersedia untuk aplikasi mobile. 2. Data pelanggan yang dimonitoring berasal dari data pemakaian listrik pelanggan PT. PLN (Persero) Area Kuala Kapuas. 3. Sistem ini berjalan di jaringan local dan di-publish, hosting web berkaitan sistem monitoring ini berada diluar pembahasan perancangan sistem ini. 4. Pengguna sistem ini adalah karyawan/staff yang berada di lingkungan PT. PLN (Persero) Area Kuala Kapuas khususnya Bagian Transaksi Energi 5. Proses monitoring di lapangan tidak ditangani oleh sistem monitoring ini. 6. Terjadinya kegagalan saat mengupload/mengupload data hasil monitoring tidak ditangani oleh sistem monitoring ini. 7. Jika salah komputer atau device yang digunakan tidak dapat mengakses server atau database(basis data).

65 37 8. Jika terjadi pemadaman listrik dan tidak adanya cadangan listrik sehingga menyebabkankoneksi terputus. 9. Metode Two Phase Locking pada penerapan manajemen transaksi tidak akan membatalkan proses upload data monitoring bagi transaksi yang berjalan setelah proses locking namun hanya akan menunggu hingga proses sebelumnya sudah berjalan Perancangan Sistem Deskripsi Rinci Kebutuhan Sistem Pada perangkat lunak ini terdapat beberapa masukan ke dalam sistem dan juga keluaran dari proses masukan tersebut. Rincian dari proses-proses tersebut antara lain sebagai berikut: 1. Masukan ke sistem (stimulus) Masukan yang dimaksud ke dalam sistem adalah berupa data-data yang diinputkan (data text) yang nantinya akan disimpan dalam database sebagai data pelanggan yang dimonitoring. Selain itu stimulus ke dalam sistem dapat berupa aksi yang dilakukan oleh pengguna (misal: user menekan tombol upload untuk menyimpan data hasil monitoring ke database, tombol tambah untuk menambahkan data user ke database, dan tombol approve untuk menyimpan status approve data pelanggan di database). 2. Keluaran dari sistem (respon) Keluaran dari sistem adalah berupa hasil dari proses stimulus yang diberikan ke dalam sistem, antara lain peringatan ketika pengguna salah memasukkan username ataupun password pada saat login, notifikasi jika data berhasil diupload, id pelanggan yang di masukkan tidak berhasil ditemukan data-datanya pada database, report monitoring, dll.

66 Kebutuhan Antarmuka Eksternal Sistem perangkat lunak ini memiliki 4tipe user yang dapat mengakses sistem secara langsung yaitu : 1. Operator area Operator area bertugas untuk mengupload atau mengubah data hasil monitoring pelanggan (berupa foto, koordinat, tanggal monitoring, keterangan hasil monitoring) di area maupun rayon. 2. Operator rayon Operator rayon bertugas untuk mengupload atau mengubah data hasil monitoring pelanggan (berupa foto, koordinat, tanggal monitoring, keterangan hasil monitoring) di rayonnya saja. 3. Admin area Admin area bertugas untuk menambah user, melihat data hasil monitoring pelanggan, mengubah data hasil monitoring, melakukan approve atau membatalkan approve dari data hasil monitoring pelanggan di area maupun yang berada di rayon-rayon, dan mencetak report monitoring. 4. Admin rayon Admin rayon bertugas untuk melihat data hasil monitoring pelanggan, mengubah data hasil monitoring, melakukan approve atau membatalkan approve dari data hasil monitoring pelanggan di rayonnya saja. Setiap pengguna memiliki karakteristik atau perbadaan fitur dimasing-masing tampilan. Dibawah ini terdapat tabel 3.1 yang akan menjelaskan karakteristik dari masing-masing pengguna: Tabel 3. 1Karakteristik user sistem Pengguna Menu Keterangan Tambah user Admin area dapat menambahkan atau mengubah data user yang memiliki akses Admin area ke sistem monitoring pelanggan Lihat data Admin area dapat melihat data

67 39 Admin rayon pelanggan yang harus dimonitoring di semua rayon maupun yang di area Monitoring Admin area dapat mengupload atau mengubah data hasil monitoring pelanggan. Approve Admin area dapat membatalkan status monitoring, memberikan approve atau membatalkan approve terhadap hasil monitoring pelanggan. Lihat detail pelanggan Admin area dapat mencari data pelanggan dengan id pelanggan Laporan Admin area dapat mencetak laporan hasil monitoring pelanggan. Lihat data Admin rayon dapat melihat data pelanggan yang harus dimonitoring di rayon-nya. Monitoring Admin rayon dapat mengupload atau mengubah data hasil monitoring pelanggan di rayon-nya saja. Approve Admin rayon dapat lihat detail pelanggan membatalkan status monitoring, memberikan approve atau membatalkan approve terhadap hasil monitoring pelanggan di rayon-nya. Admin rayon dapat mencari data pelanggan dengan id pelanggan Operator area Monitoring Operator area dapat mengupload atau mengubah data hasil monitoring pelanggan di semua rayon. Operator rayon Lihat detail pelanggan Operator area dapat mencari data pelanggan dengan id pelanggan di semua rayon. Monitoring Operator rayon dapat mengupload atau mengubah data hasil monitoring pelanggan di rayon-nya saja. Lihat detail pelanggan Operator rayon dapat mencari data pelanggan dengan id pelanggan di rayon-nya saja.

68 Antarmuka perangkat keras Kebutuhan antarmuka perangkat keras dari sistem ini adalah: 1. Server 2. Seperangkat desktop PC, laptop, netbook, atau mobile device. - Perangkat Keyboard Keyboard diperlukan bagi pengguna sebagai alat pengetikan data yang akan diproses perangkat lunak. - Perangkat Mouse Mouse diperlukan bagi pengguna sebagai alat untuk melakukan aksi ke dalam perangkat lunak. - Perangkat Monitor Monitor diperlukan bagi pengguna sebagai alat untuk menampilkan (output) aplikasi kepada pengguna. Monitor mampu menampilkan grafis dengan kualitas gambar dan warna terbaik. 3. Printer untuk mencetak laporan hasil monitoring Antarmuka perangkat lunak Kebutuhan antarmuka perangkat lunak dari sistem ini adalah : 1. Sistem operasi yang support untuk sistem ini adalah Windows XP, Windows 7, dan Windows Database server yang digunakan adalah Oracle. 3. Web server yang digunakan adalah Apache Tomcat. 4. Internet explorer tidak support sebagai browser pada sistem ini, dibutuhkan chromium, Mozila FireFox sebagai browser yang digunakan. 5. Software pengembang yang digunakan adalah Java Antarmuka komunikasi Agar sistem monitoring yang dibuat dapat beriteraksi satu sama lain dibutuhkansatu jaringan komputer LAN untuk akses di kantor agar komputer atau laptop dapat mengakses server web dan server database; hosting atau publish web agar petugas lapangan dapat mengakses web, namun tidak akan dibahas di tulisan ini.

69 Use Case Diagram Diagram use case dari aktor yang menggunakan sistem ditunjukkan pada gambar 3.1 dan gambar 3.2. Gambar 3.1 merupakan diagram use case untuk operator area dan operator rayon, gambar 3.2 adalah diagram case untuk admin rayon dan admin area. Pada gambar 3.3 s/d 3.5 akan ditunjukkan use case dari package kelola monitoring pelanggan kwh 0, kwh maks, dan TBT untuk admin area. Pada gambar 3.6 s/d 3.8 akan ditunjukkan use case dari package kelola monitoring pelanggan kwh 0, kwh maks, dan TBT untuk operator area. Pada gambar 3.9 s/d 3.11 akan ditunjukkan use case dari package kelola monitoring pelanggan kwh 0, kwh maks, dan TBT untuk operator dan admin rayon. Pada gambar 3.12 s/d 3.14 akan ditunjukkan use case dari package kelola approve pelanggan kwh 0, kwh maks, dan TBT untuk admin area.pada gambar 3.15 s/d 3.17 akan ditunjukkan use case dari package kelola approve pelanggan kwh 0, kwh maks, dan TBT untuk admin rayon. Gambar 3.18, 3.19, dan 3.20 menunjukkan use case dari package kelola user, package kelola laporan, dan package lihat data.

70 42 System Login <<depents on>> package kelola monitoring pelanggan kwh 0 operator area package kelola monitoring pelanggan kwh maks operator rayon package kelola monitoring pelanggan TBT lihat detail pelanggan logout Gambar 3. 1Use case diagram untuk aktor operator area dan rayon

71 43 System Login <<depents on>> package kelola user package lihat data package kelola monitoring pelanggan kwh 0 package kelola monitoring pelanggan kwh maks package kelola monitoring pelanggan TBT package kelola approve pelanggan kwh 0 admin area admin rayon package kelola approve pelanggan kwh maks package kelola approve pelanggan TBT package laporan package laporan lihat detail pelanggan logout Gambar 3. 2Use case diagram untuk aktor adminarea dan rayon

72 44 Package Kelola Monitoring Pelanggan Kwh 0 lihat daftar belum monitor <<include>> lihat daftar belum monitor per-unitup <<include>> <<include>> upload data monitor * lihat daftar sudah monitor <<include>> admin area <<include>> <<include>> ubah data monitor lihat daftar sudah monitor per-unitup <<include>> <<include>> <<include>> * ** lihat daftar perbulan lihat versi sebelum Gambar 3. 3Use case diagrampackage kelola monitoring pelanggan kwh 0 untuk aktor adminarea Package Kelola Monitoring Pelanggan Kwh Maks lihat daftar belum monitor <<include>> lihat daftar belum monitor per-unitup <<include>> <<include>> upload data monitor * lihat daftar sudah monitor <<include>> admin area <<include>> <<include>> ubah data monitor lihat daftar sudah monitor per-unitup <<include>> <<include>> <<include>> * ** lihat daftar perbulan lihat versi sebelum Gambar 3. 4Use case diagrampackage kelola monitoring pelanggan kwh maks untuk aktor adminarea

73 45 Package Kelola Monitoring Pelanggan TBT lihat daftar belum monitor <<include>> lihat daftar belum monitor per-unitup <<include>> <<include>> upload data monitor * lihat daftar sudah monitor <<include>> admin area <<include>> <<include>> ubah data monitor lihat daftar sudah monitor per-unitup <<include>> <<include>> <<include>> * ** lihat daftar perbulan lihat versi sebelum Gambar 3. 5Use case diagrampackage kelola monitoring pelanggan TBTuntuk aktor adminarea Package Kelola Monitoring Pelanggan Kwh 0 lihat daftar belum monitor <<include>> <<include>> lihat daftar belum monitor per-unitup upload data monitor <<include>> * lihat daftar sudah monitor <<include>> Operator area <<include>> <<include>> ubah data monitor <<include>> lihat daftar sudah monitor per-unitup <<include>> <<include>> lihat versi sebelum * ** lihat daftar perbulan Gambar 3. 6Use case diagrampackage kelola monitoring pelanggan kwh 0 untuk aktor operator area

74 46 Package Kelola Monitoring Pelanggan kwh Maks lihat daftar belum monitor <<include>> <<include>> lihat daftar belum monitor per-unitup upload data monitor <<include>> * lihat daftar sudah monitor <<include>> Operator area <<include>> <<include>> ubah data monitor <<include>> lihat daftar sudah monitor per-unitup <<include>> <<include>> lihat versi sebelum * ** lihat daftar perbulan Gambar 3. 7Use case diagrampackage kelola monitoring pelanggan kwh maks untuk aktor operatorarea Package Kelola Monitoring Pelanggan TBT lihat daftar belum monitor <<include>> <<include>> lihat daftar belum monitor per-unitup upload data monitor <<include>> * lihat daftar sudah monitor <<include>> Operator area <<include>> <<include>> ubah data monitor <<include>> lihat daftar sudah monitor per-unitup <<include>> <<include>> lihat versi sebelum * ** lihat daftar perbulan Gambar 3. 8Use case diagrampackage kelola monitoring pelanggan TBTuntuk aktor operator area

75 47 Package Kelola Monitoring Pelanggan Kwh 0 lihat daftar belum monitor <<include>> admin rayon * <<include>> upload data monitor lihat daftar sudah monitor <<include>> ubah data monitor operator rayon <<include>> * lihat versi sebelum <<include>> *** lihat daftar perbulan * * * Gambar 3. 9Use case diagrampackage kelola monitoring pelanggan kwh 0 untuk aktor operator dan admin rayon Package Kelola Monitoring Pelanggan Kwh Maks lihat daftar belum monitor <<include>> * <<include>> upload data monitor lihat daftar sudah monitor <<include>> admin rayon ubah data monitor operator rayon <<include>> * lihat versi sebelum <<include>> *** lihat daftar perbulan * * * Gambar 3. 10Use case diagrampackage kelola monitoring pelanggan kwh maksuntuk aktor operator dan admin rayon

76 48 Package Kelola Monitoring Pelanggan TBT lihat daftar belum monitor <<include>> admin rayon * <<include>> upload data monitor lihat daftar sudah monitor <<include>> ubah data monitor operator rayon <<include>> * lihat versi sebelum <<include>> *** lihat daftar perbulan * * * Gambar 3. 11Use case diagrampackage kelola monitoring pelanggan TBTuntuk aktor operator dan admin rayon

77 49 Package Kelola Approve Pelanggan Kwh 0 lihat daftar belum aprove <<include>> <<include>> lihat daftar belum approve per-unitup <<include>> * approve data monitor <<include>> batalkan status monitor lihat daftar sudah approve per-unitup lihat daftar sudah approve <<include>> <<include>> admin area <<include>> lihat detail approve <<include>> batalkan status approve <<include>> <<include>> <<include>> lihat versi sebelum <<include>> Lihat history monitor * * * lihat daftar perbulan <<include>> lihat data yang sama <<include>> copy status bulan terakhir Gambar 3. 12Use case diagrampackage kelola approve pelanggan kwh 0 untuk aktor admin area

78 50 Package Kelola Approve Pelanggan kwh Maks lihat daftar belum aprove <<include>> <<include>> lihat daftar belum approve per-unitup <<include>> * approve data monitor <<include>> batalkan status monitor lihat daftar sudah approve per-unitup lihat daftar sudah approve <<include>> <<include>> admin area <<include>> lihat detail approve <<include>> batalkan status approve <<include>> <<include>> <<include>> lihat versi sebelum <<include>> Lihat history monitor * * * lihat daftar perbulan <<include>> lihat data yang sama <<include>> copy status bulan terakhir Gambar 3. 13Use case diagrampackage kelola approve pelanggan kwh maks untuk aktor admin area

79 51 Package Kelola Approve Pelanggan TBT lihat daftar belum aprove <<include>> <<include>> lihat daftar belum approve per-unitup <<include>> * approve data monitor <<include>> batalkan status monitor lihat daftar sudah approve per-unitup lihat daftar sudah approve <<include>> <<include>> admin area <<include>> lihat detail approve <<include>> batalkan status approve <<include>> <<include>> <<include>> lihat versi sebelum <<include>> Lihat history monitor * * * lihat daftar perbulan <<include>> lihat data yang sama <<include>> copy status bulan terakhir Gambar 3. 14Use case diagrampackage kelola approve pelanggan TBT untuk aktor admin area

80 52 Package Kelola Approve Pelanggan Kwh 0 lihat daftar belum aprove <<include>> * approve data monitor <<include>> batalkan status monitor lihat daftar sudah approve <<include>> batalkan status approve admin rayon <<include>> lihat detail approve <<include>> <<include>> <<include>> lihat versi sebelum <<include>> *** lihat daftar perbulan Lihat history monitor <<include>> lihat data yang sama <<include>> copy status bulan terakhir Gambar 3. 15Use case diagrampackageapprove pelanggan kwh 0 untuk aktoradminrayon Package Kelola Approve Pelanggan Kwh Maks lihat daftar belum aprove <<include>> * approve data monitor <<include>> batalkan status monitor lihat daftar sudah approve <<include>> batalkan status approve admin rayon <<include>> lihat detail approve <<include>> <<include>> <<include>> lihat versi sebelum <<include>> *** lihat daftar perbulan Lihat history monitor <<include>> lihat data yang sama <<include>> copy status bulan terakhir Gambar 3. 16Use case diagrampackageapprovepelanggan kwh maks untuk aktor adminrayon

81 53 Package Kelola Approve PelangganTBT lihat daftar belum aprove <<include>> * approve data monitor <<include>> batalkan status monitor lihat daftar sudah approve <<include>> batalkan status approve admin rayon <<include>> lihat detail approve <<include>> <<include>> <<include>> lihat versi sebelum <<include>> *** lihat daftar perbulan Lihat history monitor <<include>> lihat data yang sama <<include>> copy status bulan terakhir Gambar 3. 17Use case diagrampackageapprovepelanggan TBT untuk aktor adminrayon Package kelola user tambah user <<include>> lihat daftar user admin area <<include>> edit data user Gambar 3. 18Use case diagrampackage kelola user untuk admin area

82 54 Package Kelola laporan cetak laporan kwh0 1 bulan cetak laporan kwh0 beberapa bulan cetak laporan kwh maks 1 bulan cetak laporan kwh maks beberapa bulan admin area cetak laporan rekomendasi monitoring naik daya cetak laporan rekomendasi monitoring naik daya beberapa bulan cetak laporan TBT 1 bulan cetak laporan TBT beberapa bulan Gambar 3. 19Use case diagrampackage kelola laporan untuk admin area Package lihat data lihat data pelanggan kwh 0 <<include>> lihat data kwh0 per-unitup lihat data pelanggan kwh maks <<include>> admin area admin rayon lihat data kwh maks per-unitup lihat data pelanggan TBT <<include>> lihat data TBT per-unitup Gambar 3. 20Use case diagrampackage lihat data untuk user admin area danadmin rayon

83 Definisi aktor Definisi aktor sudah dijelaskan sebelumnya, dapat dilihat pada bagian kebutuhan antarmuka eksternal Definisi Use Case Berikut ini akan dijelaskan defini dari use case pada tabel 3.2 dibawah ini: Tabel 3. 2Definisi Use Case No. Use Case Deskripsi 1. Lihat data pelanggan kwh0 Sistem menampilkan daftar pelanggan pascabayar dengan total penggunaan listrik sama dengan 0 Sistem menampilkan daftar pelanggan 2. Lihat data pelanggan kwh pascabayar dengan total penggunaan maks listrik melebihi batas kwh maks sesuai dengan daya masing-masing 3. Lihat data pelanggan TBT Sistem menampilkan daftar pelanggan prabayar yang tidak beli token selama <6 bulan atau >6 bulan 4. Lihat data kwh 0 per-unitup Aktor memasukan kode unit kemudian sistem menampilkan data pelanggan kwh 0 berdasarkan masukan kode unit Aktor memasukan kode unit kemudian 5. Lihat data kwh maks perunitup kwh maks berdasarkan masukan kode sistem menampilkan data pelanggan unit 6. Lihat data TBT per-unitup Aktor memasukan kode unit kemudian sistem menampilkan data pelanggan TBT berdasarkan masukan kode unit 7. Lihat daftar user Sistem menampilkan daftar user login Aktor menambahkan data user login 8. Tambah user dan sistem menyimpan data user tersebut 9. Edit data user Aktor mengubah data user berupa ubah password atau mutasi user, kemudian sistem akan menyimpan perubahan tersebut 10. Cetak laporan kwh 0 Aktor menginput bulan dan tahun kemudian sistem akan menampilkan preview laporan dalam format pdf pelanggan kwh 0 yg sudah diapprove pada bulan tahun inputan. 11. Cetak laporan kwh maks Aktor menginput bulan dan tahun kemudian sistem akan menampilkan

84 56 preview laporan dalam format pdf pelanggan kwh maks yg sudah diapprove pada bulan tahun inputan. 12. Cetak laporan TBT Aktor menginput bulan dan tahun kemudian sistem akan menampilkan preview laporan dalam format pdf pelanggan kwh 0 yg sudah diapprove pada bulan tahun inputan. Aktor menginput bulan dan tahun sebagai bulan dan tahun acuan 13. Cetak laporan rekomendasi kemudian sistem akan menampilkan monitoring naik daya preview dalam format pdf pelanggan kwh maks yang harus dimonitoring untuk naik daya. Aktor menginput bulan dan tahun awal dan akhir kemudian sistem akan 14. Cetak laporan kwh 0 beberapa menampilkan preview laporan dalam bulan format pdf pelanggan kwh 0 yg sudah diapprove berdasarkan jangka waktu tersebut. 15. Cetak laporan kwh maks Aktor menginput bulan dan tahun tahun awal dan akhir kemudian sistem akan menampilkan preview laporan dalam format pdf pelanggan kwh maks yg sudah diapprove berdasarkan jangka waktu tersebut. 16. Cetak laporan TBT Aktor menginput bulan dan tahun tahun awal dan akhir kemudian sistem akan menampilkan preview laporan dalam format pdf pelanggan kwh 0 yg sudah diapprove berdasarkan jangka waktu tersebut. Aktor menginput bulan dan tahun tahun awal dan akhir sebagai bulan dan tahun 17. acuan kemudian sistem akan Cetak laporan rekomendasi menampilkan preview dalam format pdf monitoring naik daya pelanggan kwh maks yang harus dimonitoring untuk naik daya dalam jangka waktu tersebut. Aktor mengklik menu belum approve di 18. Lihat daftar belum approve bagian kwh 0 pada menubar approve, kwh 0 Sistem menampilkan daftar pelanggan yang belum diapprove. Aktor mengklik menu belum approve di 19. Lihat daftar belum approve bagian kwh maks pada menubar kwh maks approve, Sistem menampilkan daftar pelanggan yang belum diapprove. 20. Lihat daftar belum Aktor mengklik menu belum approve di

85 approvetbt Lihat daftar sudah approve kwh 0 Lihat daftar sudah approve kwh maks Lihat daftar sudah approve TBT 24. Lihat data yang sama kwh Lihat data yang sama kwh maks 26. Lihat data yang sama TBT 27. Lihat daftar perbulan kwh Lihat daftar perbulan kwh maks bagian TBT pada menubar approve, Sistem menampilkan daftar pelanggan yang belum diapprove. Aktor mengklik menu sudah approve di bagian kwh 0 pada menubar approve, Sistem menampilkan daftar pelanggan yang sudah diapprove. Aktor mengklik menu sudah approve di bagian kwh maks pada menubar approve, Sistem menampilkan daftar pelanggan yang sudah diapprove. Aktor mengklik menu sudah approve di bagian TBT pada menubar approve, Sistem menampilkan daftar pelanggan yang sudah diapprove. Aktor mengklik tombol lihat data yang sama pada halaman data approve pelanggan, kemudian sisem akan menampilkan daftar pelanggan bulan tertentu yang memiliki history monitoring yang sudah diapprove pada bulan sebelumnya. Aktor mengklik tombol lihat data yang sama pada halaman data approve pelanggan, kemudian sisem akan menampilkan daftar pelanggan bulan tertentu yang memiliki history monitoring yang sudah diapprove pada bulan sebelumnya. Aktor mengklik tombol lihat data yang sama pada halaman data approve pelanggan, kemudian sisem akan menampilkan daftar pelanggan bulan tertentu yang memiliki history monitoring yang sudah diapprove pada bulan sebelumnya. Aktor mengklik menu cek perbulan pada bagian kwh 0 pada menubar approve, kemudian aktor menginput bulan dan tahun. Sistem akan menampilkan daftar pelanggan kwh 0 berdasarkan bulan dan tahun inputan berikut status monitornya. Aktor mengklik menu cek perbulan pada bagian kwh maks pada menubar approve, kemudian aktor menginput bulan dan tahun. Sistem akan menampilkan daftar pelanggan kwh

86 Lihat daftar perbulan TBT 30. Approve data monitor kwh Approve data monitor kwh maks 32. Approve data monitor TBT 33. Batalkan status monitor kwh Batalkan status monitor kwh maks 35. Batalkan status monitor TBT maks berdasarkan bulan dan tahun inputan berikut status monitornya. Aktor mengklik menu cek perbulan pada bagian kwh TBT pada menubar approve, kemudian aktor menginput bulan dan tahun. Sistem akan menampilkan daftar pelanggan kwh TBT berdasarkan bulan dan tahun inputan berikut status monitornya. Aktor mengklik tombol approve pada halama detail approve pelanggan kwh 0, sistem akan mengubah status approve pelanggan tersebut menjadi sudah approve dan menampilkan pesan data berhasil diapprove. Aktor mengklik tombol approve pada halama detail approve pelanggan kwh maks, sistem akan mengubah status approve pelanggan tersebut menjadi sudah approve dan menampilkan pesan data berhasil diapprove. Aktor mengklik tombol approve pada halama detail approve pelanggan TBT, sistem akan mengubah status approve pelanggan tersebut menjadi sudah approve dan menampilkan pesan data berhasil diapprove. Aktor mengisi alasan pembatalan dan mengklik tombol batalkan pada halaman detail approve pelanggan kwh 0, sistem kemudian akan mengubah status monitor menjadi belum monitor dan menampilkan pesan data monitor berhasil dibatalkan. Aktor mengisi alasan pembatalan dan mengklik tombol batalkan pada halaman detail approve pelanggan kwh maks, sistem kemudian akan mengubah status monitor menjadi belum monitor dan menampilkan pesan data monitor berhasil dibatalkan. Aktor mengisi alasan pembatalan dan mengklik tombol batalkan pada halaman detail approve pelanggan TBT, sistem kemudian akan mengubah status monitor menjadi belum monitor dan menampilkan pesan data monitor berhasil dibatalkan.

87 Batalkan status approve kwh Batalkan status approve kwh maks 38. Batalkan status monitor TBT 39. Lihat detail approve kwh Lihat detail approve kwh maks 41. Lihat detail approve TBT 42. Lihat versi sebelum pelanggan kwh 0 Aktor mengisi alasan pembatalan dan mengklik tombol batalkan pada halaman detail approve pelanggan kwh 0, sistem kemudian akan mengubah status monitor menjadi belum monitor dan status approve menjadi belum approve kemudian menampilkan pesan data monitor berhasil dibatalkan. Aktor mengisi alasan pembatalan dan mengklik tombol batalkan pada halaman detail approve pelanggan kwh maks, sistem kemudian akan mengubah status monitor menjadi belum monitor dan status approve menjadi belum approve kemudian menampilkan pesan data monitor berhasil dibatalkan. Aktor mengisi alasan pembatalan dan mengklik tombol batalkan pada halaman detail approve pelanggan TBT, sistem kemudian akan mengubah status monitor menjadi belum monitor dan status approve menjadi belum approve kemudian menampilkan pesan data monitor berhasil dibatalkan. Aktor berada di halaman data sudah approve pelanggan kwh 0 kemudian pada daftar pelanggan, aktor mengklik tombol yg berisi bulan tahun dan idpel. Sistem akan menampilkan halaman yg berisi detail data monitor pelanggan yg sudah diapprove. Aktor berada di halaman data sudah approve pelanggan kwh maks kemudian pada daftar pelanggan, aktor mengklik tombol yg berisi bulan tahun dan idpel. Sistem akan menampilkan halaman yg berisi detail data monitor pelanggan yg sudah diapprove. Aktor berada di halaman data sudah approve pelanggan TBT kemudian pada daftar pelanggan, aktor mengklik tombol yg berisi bulan tahun dan idpel. Sistem akan menampilkan halaman yg berisi detail data monitor pelanggan yg sudah diapprove. Aktor berada di halaman detail monitoring pelanggan kwh 0, kemudian pada bagian IDMON versi sebelum

88 60 aktor mengklik tombol yg berisi id versi sebelum. Sistem akan menampilkan halaman yg berisi data monitoring dengan idmon tersebut. Aktor berada di halaman detail monitoring pelanggan kwh maks, kemudian pada bagian IDMON versi Lihat versi sebelum pelanggan 43. sebelum aktor mengklik tombol yg kwh maks berisi id versi sebelum. Sistem akan menampilkan halaman yg berisi data monitoring dengan idmon tersebut. Aktor berada di halaman detail monitoring pelanggan TBT, kemudian pada bagian IDMON versi sebelum Lihat versi sebelum pelanggan 44. aktor mengklik tombol yg berisi id versi TBT sebelum. Sistem akan menampilkan halaman yg berisi data monitoring dengan idmon tersebut. Aktor berada di halaman detail approvepelanggan kwh 0, kemudian pada bagian IDMON versi sebelum Lihat history monitor 45. aktor mengklik tombol history pelanggan kwh 0 monitoring. Sistem akan menampilkan halaman yg berisi daftar history monitoring pelanggan tersebut. Aktor berada di halaman detail approve pelanggan kwh maks, kemudian pada bagian IDMON versi sebelum aktor Lihat history monitor 46. mengklik tombol history monitoring. pelanggan kwh maks Sistem akan menampilkan halaman yg berisi daftar history monitoring pelanggan tersebut. Aktor berada di halaman detail approve pelanggan TBT, kemudian pada bagian Lihat history monitor IDMON versi sebelum aktor mengklik 47. pelanggan TBT tombol history monitoring. Sistem akan menampilkan halaman yg berisi daftar history monitoring pelanggan tersebut. Aktor berada dihalaman daftar pelanggan yang sama kemudian klik tombol pada bagian copy status bulan terakhir. Sistem akan menampilkan Copy Status bulan terakhir 48. halaman detail copy status pelanggan pelanggan kwh 0 kwh 0, kemudian aktor mengklik tombol approve. Data approve akan disimpan dan status approve akan diubah menjadi sudah approve. 49. Copy Status bulan terakhir Aktor berada dihalaman daftar

89 pelanggan kwh maks Copy Status bulan terakhir pelanggan TBT Lihat daftar belum monitor kwh 0 Lihat daftar belum monitor kwh maks Lihat daftar belum monitoring TBT Lihat daftar sudah monitor kwh 0 Lihat daftar sudah monitor kwh maks Lihat daftar sudah monitor TBT Lihat daftar sudah monitor kwh 0 per-unitup Lihat daftar belum monitor kwh 0 per-unitup pelanggan yang sama kemudian klik tombol pada bagian copy status bulan terakhir. Sistem akan menampilkan halaman detail copy status pelanggan kwh maks, kemudian aktor mengklik tombol approve. Data approve akan disimpan dan status approve akan diubah menjadi sudah approve. Aktor berada dihalaman daftar pelanggan yang sama kemudian klik tombol pada bagian copy status bulan terakhir. Sistem akan menampilkan halaman detail copy status pelanggan TBT, kemudian aktor mengklik tombol approve. Data approve akan disimpan dan status approve akan diubah menjadi sudah approve. Aktor mengklik menu belum cek di bagian kwh 0 pada menubar monitoring, Sistem menampilkan daftar pelanggan yang belum dimonitoring. Aktor mengklik menu belum cek di bagian kwh maks pada menubar monitoring, Sistem menampilkan daftar pelanggan yang belum dimonitoring Aktor mengklik menu belum cek di bagian TBT pada menubar monitoring, Sistem menampilkan daftar pelanggan yang belum dimonitoring Aktor mengklik menu sudah cek di bagian kwh 0 pada menubar monitoring, Sistem menampilkan daftar pelanggan yang sudah dimonitoring. Aktor mengklik menu sudah cek di bagian kwh maks pada menubar monitoring, Sistem menampilkan daftar pelanggan yang sudah dimonitoring. Aktor mengklik menu sudah cek di bagian TBT pada menubar monitoring, Sistem menampilkan daftar pelanggan yang sudah dimonitoring. Aktor memilih kode unit, kemudian mengklik tombol cari. Sistem akan menampilkan daftar pelanggan sudah monitor berdasarkan kode unit yg dipilih Aktor memilih kode unit, kemudian mengklik tombol cari. Sistem akan

90 Lihat daftar sudah monitor kwh maks per-unitup Lihat daftar belum monitor maks per-unitup Lihat daftar sudah monitor TBT per-unitup Lihat daftar belum monitor TBT per-unitup Lihat daftar sudah approve kwh 0 per-unitup Lihat daftar belum approve kwh 0 per-unitup Lihat daftar sudah approve kwh maks per-unitup Lihat daftar belum approve kwh maks per-unitup menampilkan daftar pelanggan belum monitor berdasarkan kode unit yg dipilih Aktor memilih kode unit, kemudian mengklik tombol cari. Sistem akan menampilkan daftar pelanggan sudah monitor berdasarkan kode unit yg dipilih Aktor memilih kode unit, kemudian mengklik tombol cari. Sistem akan menampilkan daftar pelanggan belum monitor berdasarkan kode unit yg dipilih Aktor memilih kode unit, kemudian mengklik tombol cari. Sistem akan menampilkan daftar pelanggan sudah monitor berdasarkan kode unit yg dipilih Aktor memilih kode unit, kemudian mengklik tombol cari. Sistem akan menampilkan daftar pelanggan belum monitor berdasarkan kode unit yg dipilih Aktor memilih kode unit, kemudian mengklik tombol cari. Sistem akan menampilkan daftar pelanggan sudah approve berdasarkan kode unit yg dipilih Aktor memilih kode unit, kemudian mengklik tombol cari. Sistem akan menampilkan daftar pelanggan belum approve berdasarkan kode unit yg dipilih Aktor memilih kode unit, kemudian mengklik tombol cari. Sistem akan menampilkan daftar pelanggan sudah approve berdasarkan kode unit yg dipilih Aktor memilih kode unit, kemudian mengklik tombol cari. Sistem akan menampilkan daftar pelanggan belum approve berdasarkan kode unit yg dipilih Aktor memilih kode unit, kemudian 67. Lihat daftar sudah approve mengklik tombol cari. Sistem akan TBT per-unitup menampilkan daftar pelanggan sudah TBT berdasarkan kode unit yg dipilih 68. Lihat daftar belum Aktor memilih kode unit, kemudian

91 63 approvetbt per-unitup 69. Lihat daftar perbulan kwh 0 70, Lihat daftar perbulan kwh maks 72. Lihat daftar perbulan TBT Upload data monitor pelanggan kwh 0, kwh maks, TBT Ubah data monitor pelanggan kwh 0, kwh maks, TBT 75. Login 76. Lihat detail pelanggan mengklik tombol cari. Sistem akan menampilkan daftar pelanggan belum TBT berdasarkan kode unit yg dipilih Aktor mengklik menu cek perbulan pada bagian kwh 0 pada menubar monitoring, kemudian aktor menginput bulan dan tahun. Sistem akan menampilkan daftar pelanggan kwh 0 berdasarkan bulan dan tahun inputan berikut status monitornya. Aktor mengklik menu cek perbulan pada bagian kwh maks pada menubar monitoring, kemudian aktor menginput bulan dan tahun. Sistem akan menampilkan daftar pelanggan kwh maks berdasarkan bulan dan tahun inputan berikut status monitornya. Aktor mengklik menu cek perbulan pada bagian TBT pada menubar monitoring, kemudian aktor menginput bulan dan tahun. Sistem akan menampilkan daftar pelanggan TBT berdasarkan bulan dan tahun inputan berikut status monitornya. Aktor mengisi data hasil monitor untuk pelanggan yg dimonitor, kemudian klik tombol simpan dan upload. Sistem akan menyimpan data hasil monitor dan mengubah status monitor menjadi sudah monitor. Aktor mengubah data hasil monitor untuk pelanggan yg dimonitor, kemudian klik tombol ubah dan upload. Sistem akan menyimpan data hasil monitor dan mengubah status monitor menjadi sudah monitor. Aktor menginput username, password, dan kode unit kemudian mengklik tombol admin(bagi user tipe admin) atau tombol operator (bagi user tipe aktor). Sistem akan mengecek username, password,dan tipe priviledgenya. Jika benar, maka sistem akan menampilkan halaman menubar admin/operator. Aktor mengklik menubar lihat detail pelanggan, kemudian menginput id pelanggan yg dicari. Sistem akan

92 Logout menampilkan halaman berisi detail pelanggan tersebut. Aktor mengklik tombol logout pada bagian kanan atas menubar. Sistem akan menghapus session dan menampilkan halaman login.

93 Skenario Use Case Berikut ini akan dibahas mengenai skenario use case pada tabel dibawah ini: Tabel 3. 3Skenario use case Loginuser bertipe admin Nama Use Case Aktor Deskripsi Login Admin area, admin rayon Use case ini menjelaskan bagaimana aktor harus melakukan otentikasi sebelum masuk ke dalam sistem untuk mendapat pelayanan dari sistem. Aktor telah berada di halaman home sistem dan Kondisi Awal memiliki hak untuk memasuki sistem Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Aktor klik menu admin kemudian memasukkan username, password, dan unitup 2. Aktor mengklik tombol admin 3. Sistem akan melakukan otentikasi dengan mencocokkan username, password, dan unitup yang ada di database dengan masukkan aktor. 4. Jika proses otentikasi berhasil maka sistem akan menampilkan halaman utama admin area atau halaman utama admin rayon. 5. Jika proses otentikasi gagal sistem akan akan menolak aktor untuk masuk ke sistem dengan menampilkan pesan kesalahan username, password, atau unitup. Tabel 3. 4Skenario use case Loginuser bertipe operator Nama Use Case Login Aktor operator area, operator rayon Deskripsi Use case ini menjelaskan bagaimana aktor harus melakukan otentikasi sebelum masuk ke dalam sistem untuk mendapat pelayanan dari sistem. Kondisi Awal Aktor telah berada di halaman

94 66 homesistem dan memiliki hak untuk memasuki sistem Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Aktor klik menu operator kemudian memasukkan username, password, dan unitup 2. Aktor mengklik tombol operator 3. Sistem akan melakukan otentikasi dengan mencocokkan username, password, dan unitup yang ada di database dengan masukkan aktor. 4. Jika proses otentikasi berhasil maka sistem akan menampilkan halaman utama operator area atau halaman operator admin rayon. 5. Jika proses otentikasi gagal sistem akan akan menolak aktor untuk masuk ke sistem dengan menampilkan pesan kesalahan username, password, atau unitup. Tabel 3. 5Skenario use case tambah user Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor Tambah User Admin area 1. Aktor klik menu tambah user 3. Aktor klik tombol tambah user Use case ini menjelaskan bagaimana aktor menambahkan user dengan tipe akses tertentu untuk bisa menggunakan sistem ini Aktor telah berhasil login dan berada di halaman utama admin area Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman data user login 4. Sistem merespon dengan

95 67 5. Aktor mengisi form dengan memasukkan username, password, confirm password, kode unit, priviledge, dan tingkat. 6. Aktor klik tombol OK menampilkan halaman tambah user yang berisi form isian tambah user 7. Sistem akan merespon dengan menyimpan data user yang ditambahkan aktor Tabel 3. 6Skenario use case ubah data user Nama Use Case Aktor Deskripsi Ubah Data User Admin area Use case ini menjelaskan bagaimana aktor mengganti data user Kondisi Awal Aksi Aktor 1. Aktor klik menu ubah data user 3. Aktor mengisi username dan password dari user yang ingin dicari. 4. Aktor mengklik tombol CARI 6. Jika mengganti password user, aktor akan mengisi pada bagian ubah password dengan password yang baru dan mengisi confirm password Aktor telah berhasil login dan berada di halaman utama admin area Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan menampilkan halaman cari data user 5. Sistem akan merespon dengan menampilkan halaman ubah data user yang berisi detail data user dan form ubah password dan mutasi user

96 68 7. Aktor mengklik tombol ubah 9. Jika akan mutasi user, aktor akan mengisi pada bagian mutasi user yaitu mengisi kode unit, priviledge, dan tingkat yang baru 10. Aktor klik tombol simpan 8. Sistem akan merespon dengan mengganti data password user yang lama dengan yang baru 11. Sistem merespon dengan mengganti data kode unit, priviledge, dan tingkat yang lama dari user dengan data yang baru Tabel 3. 7Skenariouse case Lihat daftar belum monitor kwh maks area Nama Use Case Aktor Deskripsi Lihat Daftar Belum Monitor Kwh Maks Admin area, Operator Area Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring yang belum dimonitor di semua unitup Aktor telah berada di halaman utama admin area Kondisi Awal atau operator area Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Aktor klik menu pulldown monitoring kemudian pada submenu kwh Maks klik belum cek 2. Sistem akan merespon dengan menampilkan halaman data kwh Maks belum monitor yang berisi tabel daftar pelanggan kwh Maks yang belum dilakukan monitoring di semua unitup

97 69 Tabel 3. 8Skenariouse case Lihat daftar belum monitor kwh maks rayon Nama Use Case Aktor Deskripsi Lihat Daftar Belum Monitor Kwh Maks Admin rayon, Operator rayon Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring yang belum dimonitor di rayon-nya Aktor telah berada di halaman utama admin rayon Kondisi Awal atau operator rayon Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Aktor klik menu pulldown monitoring kemudian pada submenu kwh Maks klik belum cek 2. Sistem akan merespon dengan menampilkan halaman data kwh Maks belum monitor yang berisi tabel daftar pelanggan kwh Maks yang belum dilakukan monitoring berdasarkan kode unit aktor Tabel 3. 9Skenariouse case Lihat daftar belum monitor kwh 0 area Nama Use Case Lihat Daftar Belum Monitor Kwh 0 Aktor Admin area, Operator Area Deskripsi Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring kwh 0 yang belum dicek di semua unitup Aktor telah berada di halaman utama admin area Kondisi Awal atau operator area Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 3. Aktor klik menu pulldown monitoring kemudian pada submenu kwh 0 klik belum cek 4. Sistem akan merespon dengan menampilkan halaman data kwh 0 belum monitor yang berisi tabel daftar pelanggan kwh 0 yang belum dilakukan monitoring di semua unitup

98 70 Tabel 3. 10Skenario use case Lihat daftar belum monitor kwh 0 rayon Nama Use Case Lihat Daftar Belum monitor Kwh 0 Aktor Admin rayon, Operator rayon Deskripsi Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring kwh 0 yang belum dicek di rayon-nya Aktor telah berada di halaman utama admin rayon Kondisi Awal atau operator rayon Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Aktor klik menu pulldown monitoring kemudian pada submenu kwh 0 klik belum cek 2. Sistem akan merespon dengan menampilkan halaman data kwh 0 belum monitor yang berisi tabel daftar pelanggan kwh 0 yang belum dilakukan monitoring berdasarkan kode unit aktor Tabel 3. 11Skenariouse case Lihat daftar belum monitor TBT area Nama Use Case Aktor Deskripsi Lihat Daftar Belum Monitor TBT Admin area, Operator Area Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring TBT yang belum dicek di semua unitup Aktor telah berada di halaman utama admin area Kondisi Awal atau operator area Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Aktor klik menu pulldown monitoring kemudian pada submenu TBT klik belum cek 2. Sistem akan merespon dengan menampilkan halaman data TBT belum monitor yang berisi tabel daftar pelanggan TBT yang belum dilakukan monitoring di semua unitup

99 71 Tabel 3. 12Skenariouse case Lihat daftar belum monitor TBT rayon Nama Use Case Aktor Deskripsi Lihat Daftar Belum Monitor TBT Admin rayon, Operator rayon Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring TBT yang belum dicek di rayon-nya Aktor telah berada di halaman utama admin rayon Kondisi Awal atau operator rayon Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Aktor klik menu pulldown monitoring kemudian pada submenu TBT klik belum cek 2. Sistem akan merespon dengan menampilkan halaman data TBT belum monitor yang berisi tabel daftar pelanggan TBT yang belum dilakukan monitoring berdasarkan kode unit aktor Tabel 3. 13Skenariouse case Lihat daftar sudah monitor kwh maks area Nama Use Case Aktor Deskripsi Lihat Daftar Sudah Monitor Kwh Maks Admin area, Operator Area Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring kwh Maks yang sudah dicek di semua unitup Aktor telah berada di halaman utama admin area Kondisi Awal atau operator area Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Aktor klik menu pulldown monitoring kemudian pada submenu kwh Maks klik sudah cek 2. Sistem akan merespon dengan menampilkan halaman data kwh Maks sudah monitor yang berisi tabel daftar pelanggan kwh Maks yang sudah dilakukan monitoring di semua

100 72 unitup Tabel 3. 14Skenariouse case Lihat daftar sudah monitor kwh maks rayon Nama Use Case Aktor Deskripsi Lihat Daftar Sudah Monitor Kwh Maks Admin rayon, Operator rayon Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring kwh Maks yang sudah dicek di rayon-nya Aktor telah berada di halaman utama admin rayon Kondisi Awal atau operator rayon Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Aktor klik menu pulldown monitoring kemudian pada submenu kwh Maks klik sudah cek 2. Sistem akan merespon dengan menampilkan halaman data kwh Maks sudah monitor yang berisi tabel daftar pelanggan kwh Maks yang sudah dilakukan monitoring berdasarkan kode unit aktor Tabel 3. 15Skenariouse case Lihat daftar sudah monitor kwh 0 area Nama Use Case Lihat Daftar Sudah Monitor Kwh 0 Aktor Admin area, Operator Area Deskripsi Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring kwh 0 yang sudah dicek di semua unitup Aktor telah berada di halaman home sistem dan Kondisi Awal memiliki hak untuk memasuki sistem Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Aktor klik menu pulldown monitoring kemudian pada submenu kwh 0 klik sudah cek 2. Sistem akan merespon dengan menampilkan halaman data kwh 0 sudah monitor yang berisi tabel daftar pelanggan

101 73 kwh 0 yang sudah dilakukan monitoring di semua unitup Tabel 3. 16Skenariouse case Lihat daftar sudah monitor kwh 0 rayon Nama Use Case Lihat Daftar Sudah Monitor Kwh 0 Aktor Admin rayon, Operator rayon Deskripsi Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring kwh 0 yang sudah dicek di rayon-nya Aktor telah berada di halaman utama admin rayon Kondisi Awal atau operator rayon Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Aktor klik menu pulldown monitoring kemudian pada submenu kwh 0 klik sudah cek 2. Sistem akan merespon dengan menampilkan halaman data kwh 0 sudah monitor yang berisi tabel daftar pelanggan kwh 0 yang sudah dilakukan monitoring berdasarkan kode unit aktor Tabel 3. 17Skenariouse case Lihat daftar sudah monitor TBT area Nama Use Case Aktor Deskripsi Lihat Daftar Sudah Monitor TBT Admin area, Operator Area Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring TBT yang sudah dicek di semua unitup Aktor telah berada di halaman utama admin area Kondisi Awal atau operator area Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Aktor klik menu pulldown monitoring kemudian pada submenu TBT klik sudah cek 2. Sistem akan merespon dengan menampilkan halaman data TBT sudah monitor yang berisi

102 74 tabel daftar pelanggan TBT yang sudah dilakukan monitoring di semua unitup Tabel 3. 18Skenario use case Lihat daftar sudah monitor TBT rayon Nama Use Case Aktor Deskripsi Lihat Daftar Sudah Monitor TBT Admin rayon, Operator rayon Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring TBT yang sudah dicek di rayon-nya Aktor telah berada di halaman utama admin rayon Kondisi Awal atau operator rayon Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Aktor klik menu pulldown monitoring kemudian pada submenu TBT klik sudah cek 2. Sistem akan merespon dengan menampilkan halaman data TBT sudah monitor yang berisi tabel daftar pelanggan TBT yang sudah dilakukan monitoring berdasarkan kode unit aktor Tabel 3. 19Skenariouse case Lihat daftar per-bulan kwh maks area Nama Use Case Lihat Daftar per-bulan kwh Maks Aktor Admin area, Operator area Use case ini menjelaskan bagaimana aktor melihat Deskripsi daftar pelanggan monitoring kwh Maks yang sudah dicek maupun belum secara keseluruhan berdasarkan bulan tertentu Kondisi Awal Aktor telah berada di halaman utama admin area atau operator area Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Aktor klik menu pulldown monitoring kemudian pada submenu kwh Maks cek per-bulan 2. Sistem akan merespon dengan menampilkan halaman cek

103 75 3. Aktor memilih bulan dan mengisi tahun, kemudian mengklik tombol cari monitoring kwh Maks perbulan yang berisi form ini bulan dan tahun 4. Sistem merespon dengan menampilkan halaman berisi tabel daftar pelanggan monitoring kwh Maks diseluruh kode unit berdasarkan masukkan bulan dan tahun dari aktor Tabel 3. 20Skenariouse case Lihat daftar per-bulan kwh maks rayon Nama Use Case Lihat Daftar per-bulan kwh Maks Aktor Admin rayon, Operator rayon Use case ini menjelaskan bagaimana aktor melihat Deskripsi daftar pelanggan monitoring kwh Maks yang sudah dicek maupun belum berdasarkan rayon aktor berdasarkan bulan tertentu Kondisi Awal Aktor telah berada di halaman utama admin rayon atau operator rayon Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Aktor klik menu pulldown monitoring kemudian pada submenu kwh Maks cek per-bulan 3. Aktor memilih bulan dan mengisi tahun, kemudian mengklik tombol cari 2. Sistem akan merespon dengan menampilkan halaman cek monitoring kwh Maks perbulan yang berisi form ini bulan dan tahun 4. Sistem merespon dengan menampilkan halaman berisi tabel daftar pelanggan monitoring kwh Maks sesuai kode unit aktor berdasarkan masukkan bulan dan tahun dari aktor

104 76 Tabel 3. 21Skenariouse case Lihat daftar per-bulan kwh 0 area Nama Use Case Lihat Daftar per-bulan kwh 0 Aktor Admin area, Operator area Use case ini menjelaskan bagaimana aktor melihat Deskripsi daftar pelanggan monitoring kwh 0 yang sudah dicek maupun belum secara keseluruhan berdasarkan bulan tertentu Kondisi Awal Aktor telah berada di halaman utama admin area atau operator area Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Aktor klik menu pulldown monitoring kemudian pada submenu kwh 0 cek per-bulan 3. Aktor memilih bulan dan mengisi tahun, kemudian mengklik tombol cari 2. Sistem akan merespon dengan menampilkan halaman cek monitoring kwh 0 per-bulan yang berisi form ini bulan dan tahun 4. Sistem merespon dengan menampilkan halaman berisi tabel daftar pelanggan monitoring kwh 0 diseluruh kode unit berdasarkan masukkan bulan dan tahun dari aktor Tabel 3. 22Skenariouse case Lihat daftar per-bulan kwh 0 rayon Nama Use Case Lihat Daftar per-bulan kwh 0 Aktor Admin rayon, Operator rayon Use case ini menjelaskan bagaimana aktor melihat Deskripsi daftar pelanggan monitoring kwh 0 yang sudah dicek maupun belum berdasarkan rayon aktor berdasarkan bulan tertentu Kondisi Awal Aktor telah berada di halaman utama admin rayon atau operator rayon Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Aktor klik menu pulldown monitoring kemudian pada submenu kwh Maks

105 77 cek per-bulan 3. Aktor memilih bulan dan mengisi tahun, kemudian mengklik tombol cari 2. Sistem akan merespon dengan menampilkan halaman cek monitoring kwh 0 per-bulan yang berisi form ini bulan dan tahun 4. Sistem merespon dengan menampilkan halaman berisi tabel daftar pelanggan monitoring kwh 0 sesuai kode unit aktor berdasarkan masukkan bulan dan tahun dari aktor Tabel 3. 23Skenariouse case Lihat daftar per-bulan TBT area Nama Use Case Lihat Daftar per-bulan TBT Aktor Admin area, Operator area Use case ini menjelaskan bagaimana aktor melihat Deskripsi daftar pelanggan monitoring TBT yang sudah dicek maupun belum secara keseluruhan berdasarkan bulan tertentu Kondisi Awal Aktor telah berada di halaman utama admin area atau operator area Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Aktor klik menu pulldown monitoring kemudian pada submenu TBT cek perbulan 2. Sistem akan merespon dengan menampilkan halaman cek monitoring TBT per-bulan yang berisi form ini bulan dan tahun 3. Aktor memilih bulan dan mengisi tahun, kemudian mengklik tombol cari 4. Sistem merespon dengan menampilkan halaman berisi tabel daftar pelanggan monitoring TBT diseluruh kode unit berdasarkan masukkan

106 78 bulan dan tahun dari aktor Tabel 3. 24Skenariouse case Lihat daftar per-bulan TBT rayon Nama Use Case Lihat Daftar per-bulan TBT Aktor Admin rayon, Operator rayon Use case ini menjelaskan bagaimana aktor melihat Deskripsi daftar pelanggan monitoring TBT yang sudah dicek maupun belum berdasarkan rayon aktor berdasarkan bulan tertentu Kondisi Awal Aktor telah berada di halaman utama admin rayon atau operator rayon Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Aktor klik menu pulldown monitoring kemudian pada submenu TBT cek per-bulan 3. Aktor memilih bulan dan mengisi tahun, kemudian mengklik tombol cari 2. Sistem akan merespon dengan menampilkan halaman cek monitoring TBT per-bulan yang berisi form bulan dan tahun 4. Sistem merespon dengan menampilkan halaman berisi tabel daftar pelanggan monitoring TBT sesuai kode unit aktor berdasarkan masukkan bulan dan tahun dari aktor Tabel 3. 25Skenariouse case Lihat daftar belum cek per-bulan kwh maksarea Nama Use Case Aktor Deskripsi Kondisi Awal Lihat Daftar Belum Cek per-bulan kwh Maks Admin area, Operator area Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring kwh Maks yang belum dicek secara keseluruhan berdasarkan bulan tertentu Aktor telah berada di halaman data pelanggan kwh Maks belum cek Urutan Jenis Kegiatan

107 79 Aksi Aktor 1. Pada bagian pencarian berdasarkan UNITUP, aktor memilih unitup 2. Aktor mengklik tombol cari Reaksi Sistem 3. Sistem akan merespon dengan menampilkan halaman yang berisi daftar pelanggan monitoring kwh Maks yang belum dicek diseluruh unitup Tabel 3. 26Skenario use case Lihat daftar belum cek per-bulankwh maksrayon Nama Use Case Lihat Daftar Sudah Cek per-bulan kwh Maks Aktor Admin area, Operator area Use case ini menjelaskan bagaimana aktor melihat Deskripsi daftar pelanggan monitoring kwh Maks yang sudah dicek secara keseluruhan berdasarkan bulan tertentu Kondisi Awal Aktor telah berada di halaman data pelanggan kwh Maks sudah cek Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Pada bagian pencarian berdasarkan UNITUP, aktor memilih unitup 2. Aktor mengklik tombol cari 3. Sistem akan merespon dengan menampilkan halaman yang berisi daftar pelanggan monitoring kwh Maks yang sudah dicek diseluruh unitup Tabel 3. 27Skenariouse case Lihat daftar belumcek per-bulan kwh0 area Nama Use Case Lihat Daftar Belum Cek per-bulan kwh 0 Aktor Admin area, Operator area Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring kwh 0 yang belum Deskripsi dicek secara keseluruhan berdasarkan bulan tertentu Aktor telah berada di halaman data pelanggan kwh Kondisi Awal 0 belum cek Urutan Jenis Kegiatan

108 80 Aksi Aktor 1. Pada bagian pencarian berdasarkan UNITUP, aktor memilih unitup 2. Aktor mengklik tombol cari Reaksi Sistem 3. Sistem akan merespon dengan menampilkan halaman yang berisi daftar pelanggan monitoring kwh 0 yang belum dicek diseluruh unitup Tabel 3. 28Skenariouse case Lihat daftar belum cek per-bulankwh 0 rayon Nama Use Case Lihat Daftar Sudah Cek per-bulan kwh 0 Aktor Admin area, Operator area Use case ini menjelaskan bagaimana aktor melihat Deskripsi daftar pelanggan monitoring kwh 0 yang sudah dicek secara keseluruhan berdasarkan bulan tertentu Kondisi Awal Aktor telah berada di halaman data pelanggan kwh 0 sudah cek Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Pada bagian pencarian berdasarkan UNITUP, aktor memilih unitup 2. Aktor mengklik tombol cari 3. Sistem akan merespon dengan menampilkan halaman yang berisi daftar pelanggan monitoring kwh 0 yang sudah dicek diseluruh unitup Tabel 3. 29Skenariouse case Lihat daftar belum cek per-bulan TBT area Nama Use Case Aktor Deskripsi Kondisi Awal Lihat Daftar Belum Cek per-bulan TBT Admin area, Operator area Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring TBT yang belum dicek secara keseluruhan berdasarkan bulan tertentu Aktor telah berada di halaman data pelanggan TBT belum cek Urutan Jenis Kegiatan

109 81 Aksi Aktor 1. Pada bagian pencarian berdasarkan UNITUP, aktor memilih unitup 2. Aktor mengklik tombol cari Reaksi Sistem 3. Sistem akan merespon dengan menampilkan halaman yang berisi daftar pelanggan monitoring kwh 0 yang belum dicek diseluruh unitup Tabel 3. 30Skenariouse case Lihat daftar belum cek per-bulan TBT rayon Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor 1. Pada bagian pencarian berdasarkan UNITUP, aktor memilih unitup 2. Aktor mengklik tombol cari Lihat Daftar Sudah Cek per-bulan TBT Admin area, Operator area Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring TBT yang sudah dicek secara keseluruhan berdasarkan bulan tertentu Aktor telah berada di halaman data pelanggan TBT sudah cek Urutan Jenis Kegiatan Reaksi Sistem 3. Sistem akan merespon dengan menampilkan halaman yang berisi daftar pelanggan monitoring TBT yang sudah dicek diseluruh unitup Tabel 3. 31Skenario use case upload data kwh 0 Nama Use Case Upload Data kwh 0 Aktor Admin area, admin rayon, operator area, operator rayon Deskripsi Kondisi Awal Use case ini menjelaskan bagaimana aktor mengisi data monitoring pelanggan kwh 0 kemudian menguploadnya Aktor telah berada di halaman data pelanggan kwh 0 belum cek

110 82 Aksi Aktor 1. Pada tabel daftar pelanggan kwh 0 belum cek, Aktor klik tombol pada kolom upload foto dan koordinat 3. Pada bagian detail pelanggan aktor mengisi koordinat MCB pelanggan, tanggal monitoring, dan verifikasi 4. Aktor klik tombol simpan 6. Aktor klik tombol ok 7. Pada bagian upload foto dibagian bawah, aktor klik tombol browse untuk memilih foto yang diupload 8. Aktor klik tombol upload 10. Aktor klik tombol ok pada dialog box untuk kembali ke kondisi awal Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman yang berisi detail pelanggan dan form isian hasil monitoring beserta upload foto 5. Sistem merespon dengan menyimpan data koordinat, tanggal, dan verifikasi ke database kemudian menampilkan dialog box berisi pesan bahwa data berhasil disimpan 9. Sistem merespon dengan menyimpan data gambar ke database kemudian menampilkan dialog box dengan pesan bahwa foto berhasil diupload

111 83 Tabel 3. 32Skenario use caseupload data kwh maks Nama Use Case Aktor Deskripsi Upload Data kwh Maks Admin area, admin rayon, operator area, operator rayon Use case ini menjelaskan bagaimana aktor mengisi data monitoring pelanggan kwh maks kemudian menguploadnya Aktor telah berada di halaman data pelanggan kwh Kondisi Awal maks belum cek Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Pada tabel daftar pelanggan kwh maks belum cek, Aktor klik tombol pada kolom upload foto dan koordinat 3. Pada bagian detail pelanggan aktor mengisi koordinat MCB pelanggan, tanggal monitoring, dan verifikasi 4. Aktor klik tombol simpan 6. Aktor klik tombol ok 7. Pada bagian upload foto dibagian bawah, aktor klik tombol browse untuk memilih foto yang diupload 8. Aktor klik tombol upload 2. Sistem akan merespon dengan menampilkan halaman yang berisi detail pelanggan dan form isian hasil monitoring beserta upload foto 5. Sistem merespon dengan menyimpan data koordinat, tanggal, dan verifikasi ke database kemudian menampilkan dialog box berisi pesan bahwa data berhasil disimpan 9. Sistem merespon dengan menyimpan data gambar ke database kemudian menampilkan dialog box

112 Aktor klik tombol ok pada dialog box untuk kembali ke kondisi awal dengan pesan bahwa foto berhasil diupload Tabel 3. 33Skenario use case upload data TBT Nama Use Case Aktor Deskripsi Upload Data TBT Admin area, admin rayon, operator area, operator rayon Use case ini menjelaskan bagaimana aktor mengisi data monitoring pelanggan TBT kemudian menguploadnya Aktor telah berada di halaman data pelanggan TBT Kondisi Awal belum cek Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Pada tabel daftar pelanggan TBT belum cek, Aktor klik tombol pada kolom upload foto dan koordinat 3. Pada bagian detail pelanggan aktor mengisi koordinat MCB pelanggan, tanggal monitoring, dan verifikasi 4. Aktor klik tombol simpan 6. Aktor klik tombol ok 7. Pada bagian upload foto dibagian bawah, aktor klik tombol 2. Sistem akan merespon dengan menampilkan halaman yang berisi detail pelanggan dan form isian hasil monitoring beserta upload foto 5. Sistem merespon dengan menyimpan data koordinat, tanggal, dan verifikasi ke database kemudian menampilkan dialog box berisi pesan bahwa data berhasil disimpan

113 85 browse untuk memilih foto yang diupload 8. Aktor klik tombol upload 10. Aktor klik tombol ok pada dialog box untuk kembali ke kondisi awal 9. Sistem merespon dengan menyimpan data gambar ke database kemudian menampilkan dialog box dengan pesan bahwa foto berhasil diupload Tabel 3. 34Skenario use case ubah data kwh maks Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor 1. Pada tabel daftar pelanggan Kwh Maks sudah cek, Aktor klik tombol berwarna merah pada kolom lihat detail 3. Pada bagian detail pelanggan aktor mengganti koordinat MCB pelanggan, tanggal monitoring, dan verifikasi yang lama dengan data yang baru 4. Aktor klik tombol ubah data Ubah Data kwh Maks Admin area, admin rayon, operator area, operator rayon Use case ini menjelaskan bagaimana aktor melakukan update atau mengubah data monitoring pelanggan yang sudah dicek Aktor telah berada di halaman data pelanggan kwh Maks sudah cek Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman yang berisi detail pelanggan dan form isian ubah data beserta upload foto 5. Sistem merespon dengan mengudate data koordinat, tanggal, dan

114 86 6. Aktor klik tombol ok 7. Jika aktor juga mengganti foto, maka pada bagian ganti foto dibagian bawah, aktor klik tombol browse untuk memilih foto yang diupload. 8. Aktor klik tombol upload 10. Aktor klik tombol ok pada dialog box untuk kembali ke kondisi awal verifikasi pada database kemudian menampilkan dialog box berisi pesan bahwa data berhasil disimpan 9. Sistem merespon dengan mengupdate data gambar pada database kemudian menampilkan dialog box dengan pesan bahwa foto berhasil diupload Tabel 3. 35Skenario use case ubah data kwh 0 Nama Use Case Ubah Data kwh 0 Aktor Admin area, admin rayon, operator area, operator rayon Deskripsi Kondisi Awal Aksi Aktor 1. Pada tabel daftar pelanggan Kwh 0 sudah cek, Aktor klik tombol berwarna merah pada kolom lihat detail 3. Pada bagian detail Use case ini menjelaskan bagaimana aktor melakukan update atau mengubah data monitoring pelanggan yang sudah dicek Aktor telah berada di halaman data pelanggan kwh 0 sudah cek Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman yang berisi detail pelanggan dan form isian ubah data beserta upload foto

115 87 pelanggan aktor mengganti koordinat MCB pelanggan, tanggal monitoring, dan verifikasi yang lama dengan data yang baru 4. Aktor klik tombol ubah data 6. Aktor klik tombol ok 7. Jika aktor juga mengganti foto, maka pada bagian ganti foto dibagian bawah, aktor klik tombol browse untuk memilih foto yang diupload. 8. Aktor klik tombol upload 10. Aktor klik tombol ok pada dialog box untuk kembali ke kondisi awal 5. Sistem merespon dengan mengudate data koordinat, tanggal, dan verifikasi pada database kemudian menampilkan dialog box berisi pesan bahwa data berhasil disimpan 9. Sistem merespon dengan mengupdate data gambar pada database kemudian menampilkan dialog box dengan pesan bahwa foto berhasil diupload Tabel 3. 36Skenario use case ubah data TBT Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor Ubah Data TBT Admin area, admin rayon, operator area, operator rayon Use case ini menjelaskan bagaimana aktor melakukan update atau mengubah data monitoring pelanggan yang sudah dicek Aktor telah berada di halaman data pelanggan TBT sudah cek Urutan Jenis Kegiatan Reaksi Sistem

116 88 1. Pada tabel daftar pelanggan TBT sudah cek, Aktor klik tombol berwarna merah pada kolom lihat detail 3. Pada bagian detail pelanggan aktor mengganti koordinat MCB pelanggan, tanggal monitoring, dan verifikasi yang lama dengan data yang baru 4. Aktor klik tombol ubah data 6. Aktor klik tombol ok 7. Jika aktor juga mengganti foto, maka pada bagian ganti foto dibagian bawah, aktor klik tombol browse untuk memilih foto yang diupload. 8. Aktor klik tombol upload 10. Aktor klik tombol ok pada dialog box untuk kembali ke kondisi awal 2. Sistem akan merespon dengan menampilkan halaman yang berisi detail pelanggan dan form isian ubah data beserta upload foto 5. Sistem merespon dengan mengudate data koordinat, tanggal, dan verifikasi pada database kemudian menampilkan dialog box berisi pesan bahwa data berhasil disimpan 9. Sistem merespon dengan mengupdate data gambar pada database kemudian menampilkan dialog box dengan pesan bahwa foto berhasil diupload

117 89 Tabel 3. 37Skenario Use case lihat detail pelanggan pascabayar Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor 1. Pada menubar, aktor klik menu lihat detail pelanggan 3. Pada bagian lihat info pelanggan, aktor memasukkan id pelanggan kemudian klik tombol cari Lihat Detail Pelanggan (pasca bayar) Admin area, admin rayon, operator area, operator rayon Use case ini menjelaskan bagaimana aktor melakukan pencarian dengan id pelanggan untuk melihat track record pelanggan Aktor telah berhasil login ke sistem Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem merespon dengan menampilkan halaman cari pelanggan 4. Sistem akan merespon dengan menampilkan halaman yang berisi tabel detail pelanggan Tabel 3. 38Skenario Use case lihat detail pelanggan prabayar Nama Use Case Lihat Detail Pelanggan (prabayar) Aktor Admin area, admin rayon, operator area, operator rayon Use case ini menjelaskan bagaimana aktor Deskripsi melakukan pencarian dengan id pelanggan prabayar tidak beli token untuk melihat track record pelanggan Kondisi Awal Aktor berada pada halaman cari pelanggan Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Jika pelanggan yang dicari adalah pelanggan prabayar tidak beli token, maka klik tulisan biru klik untuk cari pelanggan tidak beli token 2. Sistem merespon dengan

118 90 3. Pada bagian lihat info pelanggan TBT, aktor memasukkan id pelanggan atau nomor meter kemudian klik tombol cari menampilkan halaman cari pelanggan 4. Sistem akan merespon dengan menampilkan halaman yang berisi tabel detail pelanggan Tabel 3. 39Skenario Use case lihat daftar belum approve kwh maks rayon Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor 1. Aktor klik menu pulldownapprove kemudian pada submenu kwh Maks klik belum approve Lihat Daftar Belum Approve Kwh Maks Admin rayon Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring kwh Maks yang belum diapprove status monitoringnya Aktor telah berada di halaman utama admin rayon Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman data kwh Maks belum approve yang berisi tabel daftar pelanggan kwh Maks unitup admin rayon yang belum diapprove status monitoringnya Tabel 3. 40Skenario Use case lihat daftar belum approve kwh 0 rayon Nama Use Case Lihat Daftar Belum Approve Kwh 0 Aktor Admin rayon Deskripsi Kondisi Awal Aksi Aktor Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring kwh 0 yang belum diapprove status monitoringnya Aktor telah berada di halaman utama admin rayon Urutan Jenis Kegiatan Reaksi Sistem

119 91 1. Aktor klik menu pulldownapprove kemudian pada submenu kwh Maks klik belum approve 2. Sistem akan merespon dengan menampilkan halaman data kwh 0 belum approve yang berisi tabel daftar pelanggan kwh 0 unitup admin rayon yang belum diapprove status monitoringnya Tabel 3. 41Skenario Use case lihat daftar belum approvetbt rayon Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor 1. Aktor klik menu pulldownapprove kemudian pada submenu TBT klik belum approve Lihat Daftar Belum Approve TBT Admin rayon Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring TBT yang belum diapprove status monitoringnya Aktor telah berada di halaman utama admin rayon Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman data TBT belum approve yang berisi tabel daftar pelanggan TBT unitup admin rayon yang belum diapprove status monitoringnya Tabel Skenario Use case lihat daftar sudah approve kwh maks rayon Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor Lihat Daftar Sudah Approve Kwh Maks Admin rayon Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring kwh Maks yang sudah diapprove status monitoringnya Aktor telah berada di halaman utama admin rayon Urutan Jenis Kegiatan Reaksi Sistem

120 92 1. Aktor klik menu pulldownapprove kemudian pada submenu kwh Maks klik sudah approve 2. Sistem akan merespon dengan menampilkan halaman data kwh Maks sudah approve yang berisi tabel daftar pelanggan kwh Maks unitup admin rayon yang sudah diapprove status monitoringnya Tabel 3. 43Skenario Use case lihat daftar sudahapprove kwh 0 rayon Nama Use Case Lihat Daftar Sudah Approve Kwh 0 Aktor Admin rayon Deskripsi Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring kwh 0 yang sudah diapprove status monitoringnya Kondisi Awal Aksi Aktor 1. Aktor klik menu pulldownapprove kemudian pada submenu kwh 0 klik sudah approve Aktor telah berada di halaman utama admin rayon Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman data kwh 0 sudah approve yang berisi tabel daftar pelanggan kwh 0 unitup admin rayon yang sudah diapprove status monitoringnya Tabel 3. 44Skenario Use case lihat daftar sudah approvetbt rayon Nama Use Case Aktor Deskripsi Kondisi Awal Lihat Daftar Sudah Approve TBT Admin rayon Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring TBT yang sudah diapprove status monitoringnya Aktor telah berada di halaman utama admin rayon

121 93 Aksi Aktor 1. Aktor klik menu pulldownapprove kemudian pada submenu TBT klik sudah approve Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman data TBT sudah approve yang berisi tabel daftar pelanggan TBT unitup admin rayon yang sudah diapprove status monitoringnya Tabel 3. 45Skenario Use case lihat daftar belumapprove kwh maks area Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor 1. Aktor klik menu pulldownapprove kemudian pada submenu kwh Maks klik belum approve Lihat Daftar Belum Approve Kwh Maks Admin Area Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring kwh Maks yang belum diapprove status monitoringnya di seluruh rayon Aktor telah berada di halaman utama admin area Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman data kwh Maks belum approve yang berisi tabel daftar pelanggan kwh Maks di seluruh rayon yang belum diapprove status monitoringnya Tabel 3. 46Skenario Use case lihat daftar belumapprove kwh 0area Nama Use Case Lihat Daftar Belum Approve Kwh 0 Aktor Admin Area Deskripsi Kondisi Awal Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring kwh 0 yang belum diapprove status monitoringnya di seluruh rayon Aktor telah berada di halaman utama admin area Urutan Jenis Kegiatan

122 94 Aksi Aktor 1. Aktor klik menu pulldownapprove kemudian pada submenu kwh 0 klik belum approve Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman data kwh 0 belum approve yang berisi tabel daftar pelanggan kwh 0 di seluruh rayon yang belum di-approve status monitoringnya Tabel 3. 47Skenario Use case lihat daftar belumapprove TBT area Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor 1. Aktor klik menu pulldownapprove kemudian pada submenu TBT klik belum approve Lihat Daftar Belum Approve TBT Admin Area Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring TBT yang belum diapprove status monitoringnya di seluruh rayon Aktor telah berada di halaman utama admin area Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman data TBT belum approve yang berisi tabel daftar pelanggan TBT di seluruh rayon yang belum diapprove status monitoringnya Tabel 3. 48Skenario Use case lihat daftar sudahapprove TBT area Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor Lihat Daftar Sudah Approve TBT Admin Area Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring TBT yang sudah diapprove status monitoringnya di seluruh rayon Aktor telah berada di halaman utama admin area Urutan Jenis Kegiatan Reaksi Sistem

123 95 1. Aktor klik menu pullapprovekemudian pada submenu TBT klik sudah approve 2. Sistem akan merespon dengan menampilkan halaman data TBT sudah approve yang berisi tabel daftar pelanggan TBT di seluruh rayon yang sudah diapprove status monitoringnya Tabel 3. 49Skenario Use case lihat daftar sudah approve kwh 0 area Nama Use Case Lihat Daftar Sudah Approve kwh 0 Aktor Admin Area Deskripsi Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring kwh 0 yang sudah diapprove status monitoringnya di seluruh rayon Kondisi Awal Aksi Aktor 1. Aktor klik menu pulldownapprove kemudian pada submenu kwh 0 klik sudah approve Aktor telah berada di halaman utama admin area Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman data kwh 0 sudah approve yang berisi tabel daftar pelanggan kwh 0 di seluruh rayon yang sudah diapprove status monitoringnya Tabel 3. 50Skenario Use case lihat daftar sudah approve kwh maks area Nama Use Case Aktor Deskripsi Kondisi Awal Lihat Daftar Sudah Approve kwh Maks Admin Area Use case ini menjelaskan bagaimana aktor melihat daftar pelanggan monitoring kwh Maks yang sudah diapprove status monitoringnya di seluruh rayon Aktor telah berada di halaman utama admin area Urutan Jenis Kegiatan

124 96 Aksi Aktor 1. Aktor klik menu pulldownapprovekemudi an pada submenu kwh Maks klik sudah approve Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman data kwh Maks sudah approve yang berisi tabel daftar pelanggan kwh Maks di seluruh rayon yang sudah diapprove status monitoringnya Tabel 3. 51Skenario Use case batalkan status approve kwh maks Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor 1. Aktor klik tombol berwarna merah yang berisi id pelanggan pada kolom lihat detail 3. Untuk melihat foto, aktor klik tombol klik foto pada bagian data pelanggan kwh Maks, selanjutnya klik tombol kembali 4. Pada bagian pembatalan status approve, aktor mengisi alasan pembatalan status approve 5. Aktor klik tombol Membatalkan Status Approve kwh Maks Admin area, admin rayon Use case ini menjelaskan bagaimana aktor membatalkan status approve terhadap data monitoring pelanggan kwh Maks Aktor telah berada di halaman data kwh Maks sudah approve yang berisi tabel daftar pelanggan kwh Maks Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman yang berisi detail data monitoring pelanggan

125 97 batalkan 6. Sistem merespon dengan menampilkan pesan status approve berhasil dibatalkan Tabel 3. 52Skenario Use Case batalkan status approve kwh 0 Nama Use Case Membatalkan Status Approve kwh 0 Aktor Admin area, admin rayon Deskripsi Use case ini menjelaskan bagaimana aktor membatalkan status approve terhadap data monitoring pelanggan kwh 0 Kondisi Awal Aksi Aktor 1. Aktor klik tombol berwarna merah yang berisi id pelanggan pada kolom lihat detail 3. Untuk melihat foto, aktor klik tombol klik foto pada bagian data pelanggan kwh 0, selanjutnya klik tombol kembali 4. Pada bagian pembatalan status approve, aktor mengisi alasan pembatalan status approve 5. Aktor klik tombol batalkan Aktor telah berada di halaman data kwh 0 sudah approve yang berisi tabel daftar pelanggan kwh 0 Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman yang berisi detail data monitoring pelanggan 6. Sistem merespon dengan menampilkan pesan status approve berhasil dibatalkan

126 98 Tabel 3. 53Skenario Use Case batalkan status approvetbt Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor 1. Aktor klik tombol berwarna merah yang berisi id pelanggan pada kolom lihat detail 3. Untuk melihat foto, aktor klik tombol klik foto pada bagian data pelanggan TBT, selanjutnya klik tombol kembali 4. Pada bagian pembatalan status approve, aktor mengisi alasan pembatalan status approve 5. Aktor klik tombol batalkan Membatalkan Status Approve TBT Admin area, admin rayon Use case ini menjelaskan bagaimana aktor membatalkan status approve terhadap data monitoring pelanggan TBT Aktor telah berada di halaman data TBT sudah approve yang berisi tabel daftar pelanggan TBT Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman yang berisi detail data monitoring pelanggan 6. Sistem merespon dengan menampilkan pesan status approve berhasil dibatalkan Tabel 3. 54Skenario Use Caseapprove datatbt Nama Use Case Aktor Deskripsi Approve data TBT Admin area, admin rayon Use case ini menjelaskan bagaimana aktor menyetujui hasil monitoring pelanggan dengan memberikan status approve terhadap data monitoring pelanggan TBT

127 99 Kondisi Awal Aksi Aktor 1. Aktor klik tombol berwarna merah yang berisi id pelanggan pada kolom approve 3. Untuk melihat foto, aktor klik tombol klik foto pada bagian data pelanggan TBT, selanjutnya klik tombol kembali 4. Untuk menyetujui hasil monitoring, klik tombol approve 6. Aktor klik OK untuk kembali ke kondisi awal Aktor telah berada di halaman data TBT belum approve yang berisi tabel daftar pelanggan TBT Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman yang berisi detail data monitoring pelanggan 5. Sistem akan merespon dengan menyimpan status monitoring pelanggan ke database dan menampilkan pesan bahwa data berhasil di-approve Tabel 3. 55Skenario Use Caseapprove data kwh maks Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor 1. Aktor klik tombol berwarna merah yang berisi id pelanggan pada kolom approve Approve data kwh Maks Admin area, admin rayon Use case ini menjelaskan bagaimana aktor menyetujui hasil monitoring pelanggan dengan memberikan status approve terhadap data monitoring pelanggan kwh Maks Aktor telah berada di halaman data kwh Maks belum approve yang berisi tabel daftar pelanggan kwh Maks Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan

128 Untuk melihat foto, aktor klik tombol klik foto pada bagian data pelanggan kwh Maks, selanjutnya klik tombol kembali 4. Untuk menyetujui hasil monitoring, klik tombol approve 6. Aktor klik OK untuk kembali ke kondisi awal menampilkan halaman yang berisi detail data monitoring pelanggan 5. Sistem akan merespon dengan menyimpan status monitoring pelanggan ke database dan menampilkan pesan bahwa data berhasil di-approve Tabel 3. 56Skenario Use Caseapprove data kwh 0 Nama Use Case Approve data kwh 0 Aktor Admin area, admin rayon Use case ini menjelaskan bagaimana aktor Deskripsi menyetujui hasil monitoring pelanggan dengan memberikan status approve terhadap data monitoring pelanggan kwh 0 Kondisi Awal Aktor telah berada di halaman data kwh 0 belum approve yang berisi tabel daftar pelanggan kwh 0 Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Aktor klik tombol berwarna merah yang berisi id pelanggan pada kolom approve 3. Untuk melihat foto, aktor klik tombol klik foto pada bagian data pelanggan kwh 0, selanjutnya klik tombol kembali 4. Untuk menyetujui hasil 2. Sistem akan merespon dengan menampilkan halaman yang berisi detail data monitoring pelanggan

129 101 monitoring, klik tombol approve 6. Aktor klik OK untuk kembali ke kondisi awal 5. Sistem akan merespon dengan menyimpan status monitoring pelanggan ke database dan menampilkan pesan bahwa data berhasil di-approve Tabel 3. 57Skenario Use Case batalkan status sudah monitor data kwh 0 Nama Use Case Membatalkan Status Sudah Monitoring kwh 0 Aktor Admin area, admin rayon Deskripsi Use case ini menjelaskan bagaimana aktor membatalkan status sudah monitoring terhadap data pelanggan kwh 0 Kondisi Awal Aksi Aktor 1. Aktor klik tombol berwarna merah yang berisi id pelanggan pada kolom approve 3. Untuk melihat foto, aktor klik tombol klik foto pada bagian data pelanggan kwh 0, selanjutnya klik tombol kembali 4. Pada bagian pembatalan status monitoring, aktor mengisi alasan pembatalan 5. Aktor klik tombol batalkan Aktor telah berada di halaman data kwh 0 belum approve yang berisi tabel daftar pelanggan kwh 0 Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman yang berisi detail data monitoring pelanggan 6. Sistem merespon dengan menampilkan pesan status monitoring berhasil dibatalkan

130 102 Tabel 3. 58Skenario Use Case batalkan status sudah monitor data kwh maks Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor 1. Aktor klik tombol berwarna merah yang berisi id pelanggan pada kolom approve 3. Untuk melihat foto, aktor klik tombol klik foto pada bagian data pelanggan kwh Maks, selanjutnya klik tombol kembali 4. Pada bagian pembatalan status monitoring, aktor mengisi alasan pembatalan 5. Aktor klik tombol batalkan Membatalkan Status Sudah Monitoring kwh Maks Admin area, admin rayon Use case ini menjelaskan bagaimana aktor membatalkan status sudah monitoring terhadap data pelanggan kwh Maks Aktor telah berada di halaman data kwh Maks belum approve yang berisi tabel daftar pelanggan kwh Maks Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman yang berisi detail data monitoring pelanggan 6. Sistem merespon dengan menampilkan pesan status monitoring berhasil dibatalkan Tabel Skenario Use Case Copy Status Bulan Terakhir kwh maks Nama Use Case Aktor Deskripsi Kondisi Awal Copy Status Bulan Terakhir kwh Maks Admin area, admin rayon Use case ini menjelaskan bagaimana aktor dapat mengcopy status approve beserta data monitoring terhadap data pelanggan kwh Maks yang sama secara berturut-turut Aktor telah berhasil login ke sistem

131 103 Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Pada menubar, aktor mengklik menu pulldownapprove lalu mengklik cek semua pada submenu submenu kwh Maks 3. Pada bagian atas tabel daftar pelanggan, klik tombol tampilkan data yang sama 5. Aktor klik tombol berisi id pelanggan pada kolom copy status bulan terakhir, warna merah jika data pelanggan tersebut belum dimonitoring, warna biru jika sudah dilakukan monitoring tetapi belum di-approve 7. Aktor klik tombol lihat foto untuk melihat foto MCB pelanggan, kemudian klik kembali. 8. Aktor klik tombol dengan tulisan klik untuk approve untuk mengcopy status bulan terakhir pelanggan 2. Sistem akan merespon dengan menampilkan halaman yang berisi daftar semua pelanggan monitoring kwh Maks 4. Sistem merespon dengan menampilkan halaman yang berisi data pelanggan kwh Maks yang sama (pernah dimonitoring atau di-approve sebelumnya) 6. Sistem merespon dengan menampilkan halaman detail copy status monitoring pelanggan yang berisi data pada bulan yang sudah di-approve statusnya 9. Sistem merespon dengan

132 104 mengcopy data bulan terakhir tersebut kemudian menampilkan pesan data telah berhasil diapprove Tabel 3. 60Skenario Use Case Copy Status Bulan Terakhir kwh 0 Nama Use Case Copy Status Bulan Terakhir kwh 0 Aktor Admin area, admin rayon Use case ini menjelaskan bagaimana aktor dapat Deskripsi mengcopy status approve beserta data monitoring terhadap data pelanggan kwh 0 yang sama secara berturut-turut Kondisi Awal Aktor telah berhasil login ke sistem Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Pada menubar, aktor mengklik menu pulldownapprove lalu mengklik cek semua pada submenu submenu kwh 0 3. Pada bagian atas tabel daftar pelanggan, klik tombol tampilkan data yang sama 5. Aktor klik tombol berisi id pelanggan pada kolom copy status bulan terakhir, warna merah jika data pelanggan tersebut belum dimonitoring, warna biru jika sudah dilakukan monitoring tetapi belum di-approve 2. Sistem akan merespon dengan menampilkan halaman yang berisi daftar semua pelanggan monitoring kwh 0 4. Sistem merespon dengan menampilkan halaman yang berisi data pelanggan kwh 0 yang sama (pernah dimonitoring atau di-approve sebelumnya) 6. Sistem merespon dengan menampilkan halaman detail

133 Aktor klik tombol lihat foto untuk melihat foto MCB pelanggan, kemudian klik kembali. 8. Aktor klik tombol dengan tulisan klik untuk approve untuk mengcopy status bulan terakhir pelanggan copy status monitoring pelanggan yang berisi data pada bulan yang sudah di-approve statusnya 9. Sistem merespon dengan mengcopy data bulan terakhir tersebut kemudian menampilkan pesan data telah berhasil diapprove Tabel 3. 61Skenario Use Case Copy Status Bulan Terakhir TBT Nama Use Case Copy Status Bulan Terakhir TBT Aktor Admin area, admin rayon Use case ini menjelaskan bagaimana aktor dapat Deskripsi mengcopy status approve beserta data monitoring terhadap data pelanggan TBT yang sama secara berturut-turut Kondisi Awal Aktor telah berhasil login ke sistem Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Pada menubar, aktor mengklik menu pulldownapprove lalu mengklik cek semua pada submenu submenu TBT 3. Pada bagian atas tabel daftar pelanggan, klik tombol tampilkan data yang sama 2. Sistem akan merespon dengan menampilkan halaman yang berisi daftar semua pelanggan monitoring TBT 4. Sistem merespon dengan menampilkan halaman yang berisi data pelanggan TBT yang

134 Aktor klik tombol berisi id pelanggan pada kolom copy status bulan terakhir, warna merah jika data pelanggan tersebut belum dimonitoring, warna biru jika sudah dilakukan monitoring tetapi belum di-approve 7. Aktor klik tombol lihat foto untuk melihat foto MCB pelanggan, kemudian klik kembali. 8. Aktor klik tombol dengan tulisan klik untuk approve untuk mengcopy status bulan terakhir pelanggan sama (pernah dimonitoring atau di-approve sebelumnya) 6. Sistem merespon dengan menampilkan halaman detail copy status monitoring pelanggan yang berisi data pada bulan yang sudah di-approve statusnya 9. Sistem merespon dengan mengcopy data bulan terakhir tersebut kemudian menampilkan pesan data telah berhasil diapprove Tabel Skenario use case lihat versi sebelum data pelanggan kwh maks Nama Use Case Aktor Deskripsi Lihat versi sebelum data pelanggan kwh maks Admin area, admin rayon, operator area,operator rayon Use case ini menjelaskan bagaimana aktor melihat halaman berisi detail data hasil monitor pelanggan kwh maks versi sebelumnya Aktor telah berada di halaman detail data Kondisi Awal pelanggan kwh maks Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Klik tombol berisi

135 107 idmon pada bagian IDMON versi sebelum 2. Sistem akan merespon dengan menampilkan halaman berisi detail data hasil monitor pelanggan kwh maks versi sebelumnya Tabel 3. 63Skenario use case lihat versi sebelum data pelanggan kwh 0 Nama Use Case Lihat versi sebelum data pelanggan kwh 0 Aktor Admin area, admin rayon, operator area,operator rayon Deskripsi Kondisi Awal Aksi Aktor 1. Klik tombol berisi idmon pada bagian IDMON versi sebelum Use case ini menjelaskan bagaimana aktor melihat halaman berisi detail data hasil monitor pelanggan kwh 0 versi sebelumnya Aktor telah berada di halaman detail data pelanggan kwh 0 Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman berisi detail data hasil monitor pelanggan kwh 0 versi sebelumnya Tabel 3. 64Skenario use case lihat versi sebelum data pelanggan TBT Nama Use Case Aktor Deskripsi Lihat versi sebelum data pelanggan TBT Admin area, admin rayon, operator area,operator rayon Use case ini menjelaskan bagaimana aktor melihat halaman berisi detail data hasil monitor pelanggan TBT versi sebelumnya Aktor telah berada di halaman detail data Kondisi Awal pelanggan TBT Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Klik tombol berisi idmon pada bagian IDMON versi sebelum 2. Sistem akan merespon dengan

136 108 menampilkan halaman berisi detail data hasil monitor pelanggan TBT versi sebelumnya Tabel Skenario Use Case lihat history monitoring pelanggan TBT Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor 1. Klik tombol HISTORY MONITORING pada bagian IDMON versi sebelum Lihat history monitoring data pelanggan TBT Admin area, admin rayon Use case ini menjelaskan bagaimana aktor melihat halaman berisi daftar history monitoring data pelanggan TBT Aktor telah berada di halaman detail data pelanggan TBT Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman berisi daftar history monitoring data pelanggan TBT Tabel 3. 66Skenario Use Case lihat history monitoring pelanggan kwh 0 Nama Use Case Lihat history monitoring data pelanggan kwh 0 Aktor Admin area, admin rayon Deskripsi Use case ini menjelaskan bagaimana aktor melihat halaman berisi daftar history monitoring data pelanggan kwh 0 Kondisi Awal Aksi Aktor 1. Klik tombol HISTORY MONITORING pada bagian IDMON versi sebelum Aktor telah berada di halaman detail data pelanggan kwh 0 Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman berisi daftar history monitoring data pelanggan kwh 0

137 109 Tabel 3. 67Skenario Use Case lihat history monitoring pelanggan kwh maks Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor 1. Klik tombol HISTORY MONITORING pada bagian IDMON versi sebelum Lihat history monitoring data pelanggan kwh maks Admin area, admin rayon Use case ini menjelaskan bagaimana aktor melihat halaman berisi daftar history monitoring data pelanggan kwh maks Aktor telah berada di halaman detail data pelanggan kwh maks Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman berisi daftar history monitoring data pelanggan kwh maks Tabel Skenario use case cetak laporan kwh 0 1 bulan Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor 1. Pada menubar pulldown cetak laporan, pilih menu pelanggan kwh 0 3. Pada bagian cetak laporan monitoring perbulan, aktor menginput bulan dan tahun. 4. Aktor mengklik tombol cetak Cetak laporan kwh 0 1 bulan Admin area Use case ini menjelaskan bagaimana aktor mencetak laporan hasil monitoring pelanggan kwh 0 yang sudah diapprove dalam jangka waktu 1 bulan Aktor telah berhasil login sebagai admin area Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman cetak laporan pelanggan kwh 0

138 Aktor mengklik tombol berupa gambar print 5. Sistem merespon dengan menampilkan halaman preview laporan yang akan dicetak dalam format pdf. 7. Sistem merespon dengan mencetak laporan Tabel 3. 69Skenario use case cetak laporan kwh 0 beberapa bulan Nama Use Case Cetak laporan kwh 0 beberapa bulan Aktor Admin area Use case ini menjelaskan bagaimana aktor Deskripsi mencetak laporan hasil monitoring pelanggan kwh 0 yang sudah diapprove dalam jangka waktu beberapa bulan Kondisi Awal Aktor telah berhasil login sebagai admin area Urutan Jenis Kegiatan Aksi Aktor Reaksi Sistem 1. Pada menubar pulldown cetak laporan, pilih menu pelanggan kwh 0 3. Pada bagian cetak laporan monitoring, aktor menginput bulan dan tahun batas awal dan akhir 4. Aktor mengklik tombol cetak 6. Aktor mengklik tombol berupa gambar print 2. Sistem akan merespon dengan menampilkan halaman cetak laporan pelanggan kwh 0 5. Sistem merespon dengan menampilkan halaman preview laporan yang akan dicetak dalam format pdf. 7. Sistem merespon dengan mencetak laporan

139 111 Tabel 3. 70Skenario use case cetak laporan kwh maks 1 bulan Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor 1. Pada menubar pulldown cetak laporan, pilih menu pelanggan kwh maks 3. Pada bagian cetak laporan monitoring perbulan, aktor menginput bulan dan tahun. 4. Aktor mengklik tombol cetak 6. Aktor mengklik tombol berupa gambar print Cetak laporan kwh maks 1 bulan Admin area Use case ini menjelaskan bagaimana aktor mencetak laporan hasil monitoring pelanggan kwh maks yang sudah diapprove dalam jangka waktu 1 bulan Aktor telah berhasil login sebagai admin area Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman cetak laporan pelanggan kwh maks 5. Sistem merespon dengan menampilkan halaman preview laporan yang akan dicetak dalam format pdf. 7. Sistem merespon dengan mencetak laporan Tabel 3. 71Skenario use case cetak laporan kwh maksbeberapa bulan Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor 1. Pada menubar pulldown cetak Cetak laporan kwh maks beberapa bulan Admin area Use case ini menjelaskan bagaimana aktor mencetak laporan hasil monitoring pelanggan kwh maks yang sudah diapprove dalam jangka waktu beberapa bulan Aktor telah berhasil login sebagai admin area Urutan Jenis Kegiatan Reaksi Sistem

140 112 laporan, pilih menu pelanggan kwh maks 3. Pada bagian cetak laporan monitoring, aktor menginput bulan dan tahun batas awal dan akhir 4. Aktor mengklik tombol cetak 6. Aktor mengklik tombol berupa gambar print 2. Sistem akan merespon dengan menampilkan halaman cetak laporan pelanggan kwh maks 5. Sistem merespon dengan menampilkan halaman preview laporan yang akan dicetak dalam format pdf. 7. Sistem merespon dengan mencetak laporan Tabel 3. 72Skenario use case cetak laporan TBT 1 bulan Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor 1. Pada menubar pulldown cetak laporan, pilih menu Tidak Beli Token >3 bulan 3. Pada bagian cetak laporan monitoring perbulan, aktor menginput bulan dan tahun. 4. Aktor mengklik tombol cetak Cetak laporan TBT 1 bulan Admin area Use case ini menjelaskan bagaimana aktor mencetak laporan hasil monitoring pelanggan TBT yang sudah diapprove dalam jangka waktu 1 bulan Aktor telah berhasil login sebagai admin area Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman cetak laporan pelanggan TBT 5. Sistem merespon dengan menampilkan halaman preview

141 Aktor mengklik tombol berupa gambar print laporan yang akan dicetak dalam format pdf. 7. Sistem merespon dengan mencetak laporan Tabel 3. 73Skenario use case cetak laporan TBT beberapa bulan Nama Use Case Aktor Deskripsi Kondisi Awal Aksi Aktor 1. Pada menubar pulldown cetak laporan, pilih menu pelanggan TBT 3. Pada bagian cetak laporan monitoring, aktor menginput bulan dan tahun batas awal dan akhir 4. Aktor mengklik tombol cetak 6. Aktor mengklik tombol berupa gambar print Cetak laporan kwh maks beberapa bulan Admin area Use case ini menjelaskan bagaimana aktor mencetak laporan hasil monitoring pelanggan TBT yang sudah diapprove dalam jangka waktu beberapa bulan Aktor telah berhasil login sebagai admin area Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman cetak laporan pelanggan TBT 5. Sistem merespon dengan menampilkan halaman preview laporan yang akan dicetak dalam format pdf. 7. Sistem merespon dengan mencetak laporan Tabel 3. 74Skenario use case cetak laporan rekomendasi monitoring naik daya pelanggan kwh maks Nama Use Case Aktor cetak laporan rekomendasi monitoring naik daya pelanggan kwh maks Admin area

142 114 Deskripsi Use case ini menjelaskan bagaimana aktor mencetak laporan rekomendasi monitoring naik daya pelanggan kwh maks beberapa bulan Kondisi Awal Aksi Aktor 1. Pada menubar pulldown cetak laporan, pilih menu kwh maks naik daya 3. Pada cetak blangko monitoring kwh maks naik daya per-bulan, aktor menginput bulan dan tahun batas atas. 4. Aktor mengklik tombol cetak 6. Aktor mengklik tombol berupa gambar print Aktor telah berhasil login sebagai admin area Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman cetak laporan cek pelanggan kwh maks naik daya 5. Sistem merespon dengan menampilkan halaman preview laporan yang akan dicetak dalam format pdf. 7. Sistem merespon dengan mencetak laporan Tabel 3. 75Skenario use case cetak laporan rekomendasi monitoring naik daya pelanggan kwh maks beberapa bulan Nama Use Case cetak laporan rekomendasi monitoring naik daya pelanggan kwh maks beberapa bulan Aktor Deskripsi Kondisi Awal Aksi Aktor Admin area 1. Pada menubar pulldown cetak laporan, pilih menu kwh maks naik daya Use case ini menjelaskan bagaimana aktor mencetak laporan rekomendasi monitoring naik daya pelanggan kwh maks beberapa bulan Aktor telah berhasil login sebagai admin area Urutan Jenis Kegiatan Reaksi Sistem 2. Sistem akan merespon dengan menampilkan halaman cetak

143 Pada cetak blangko monitoring kwh maks naik daya, aktor menginput bulan dan tahun batas atas dan bawah 4. Aktor mengklik tombol cetak 6. Aktor mengklik tombol berupa gambar print laporan cek pelanggan kwh maks naik daya 5. Sistem merespon dengan menampilkan halaman preview laporan yang akan dicetak dalam format pdf. 7. Sistem merespon dengan mencetak laporan Activity Diagram Berikut ini adalah activity diagram dari use case login untuk user bertipe admin: User * Sistem masuk ke halaman login menampilkan halaman login menginput username, password, dan kode unit Menekan tombol admin mengecek username, password, priviledge, kode unit Username,password, priviledge, dan kode unit salah Username,password, priviledge, dan kode unit benar masuk ke halaman utama admin * Gambar 3. 21Activity diagram untuk use ase login user admin

144 116 Berikut ini adalah activity diagram dari use case login untuk user bertipe operator: User * Sistem masuk ke halaman login menampilkan halaman login menginput username, password, dan kode unit Menekan tombol operator mengecek username, password, priviledge, kode unit Username,password, priviledge, dan kode unit salah Username,password, priviledge, dan kode unit benar * masuk ke halaman utama admin Gambar 3. 22Activity diagram untuk use ase login user operator Berikut ini adalah activity diagram dari use case tambah user : User * Sistem Masuk ke halaman utama admin area menampilkan halaman daftar user login Menekan tombol tambah user Menginput data user login Menekan tombol OK Menyimpan data user login * Gambar 3. 23Activity Diagram dari use case tambah user

145 117 Berikut ini adalah activity diagram dari ubah data user : User * Sistem Masuk ke halaman utama admin area menampilkan halaman daftar user login menginput username, password, dan kode unit Menampilkan halaman cari data user Menginput username dan password Menekan tombol CARI Mencari data user Username dan password tidak ditemukan Username dan password ditemukan Menampilkan halaman edit data user Mengubah data user login Menekan tombol UBAH Menyimpan perubahan data user * Gambar 3. 24Activitydiagram dari ubah data user

146 118 Berikut ini adalah activity diagram dari use case lihat data belum monitoring untuk pelanggan kwh 0, kwh maks, dan TBT: User Sistem * mengklik submenu kwh 0 belum cek pada menubar monitoring menampilkan halaman kwh 0 belum cek * Gambar 3. 25Activity diagram dari use case lihat data belum monitoring untuk pelanggan kwh 0 User * Sistem mengklik submenu kwh maks belum cek Pada menubar monitoring menampilkan halaman kwh maks belum cek * Gambar 3. 26Activity diagram dari use case lihat data belum monitoring untuk pelanggan kwh Maks User Sistem * mengklik submenu TBT belum cek Pada menubar monitoring menampilkan halaman TBT belum cek * Gambar 3. 27Activity diagram dari use case lihat data belum monitoring untuk pelanggan TBT

147 119 Berikut ini adalah activity diagram dari use case lihat data sudah monitoring untuk pelanggan kwh 0, kwh maks, dan TBT: User Sistem * Mengklik menu pelanggan kwh maks Pada menubar cetak laporan menampilkan halaman kwh 0 sudah cek * Gambar 3. 28Activity diagram dari use case lihat data sudah monitoring untuk pelanggan kwh 0 User * Sistem mengklik submenu kwh maks sudah cek Pada menubar monitoring menampilkan halaman kwh maks sudah cek * Gambar 3. 29Activity diagram dari use case lihat data sudah monitoring untuk pelanggan kwh Maks User Sistem * mengklik submenu TBT belum cek Pada menubar monitoring menampilkan halaman TBT belum cek * Gambar 3. 30Activity diagram dari use case lihat data sudah monitoring untuk pelanggan kwh Maks

148 120 Berikut ini adalah activity diagram dari use case lihat data sudah approve untuk pelanggan kwh 0, kwh maks, dan TBT: User * Sistem mengklik submenu kwh 0 sudah approve Pada menubar approve menampilkan halaman kwh 0 sudah approve * Gambar 3. 31Activity diagram dari use case lihat data sudah approveuntuk pelanggan kwh 0 User * Sistem mengklik submenu kwh maks sudah approve Pada menubar approve menampilkan halaman kwh maks sudah approve * Gambar 3. 32Activity diagram dari use case lihat data sudah approveuntuk pelanggan kwh maks User * Sistem mengklik submenu TBT sudah approve Pada menubar approve menampilkan halaman TBT sudah approve * Gambar 3. 33Activity diagram dari use case lihat data sudah approveuntuk pelanggan TBT

149 121 Berikut ini adalah activity diagram dari use case lihat data belum approve untuk pelanggan kwh 0, kwh maks, dan TBT: User * Sistem mengklik submenu kwh 0 belum approve Pada menubar approve menampilkan halaman kwh 0 belum approve * Gambar 3. 34Activity diagram dari use case lihat data belum approve untuk pelanggan kwh 0 User * Sistem mengklik submenu kwh maks belum approve Pada menubar approve menampilkan halaman kwh maks belum approve * Gambar 3. 35Activity diagram dari use case lihat data belum approve untuk pelanggan kwh maks User * Sistem mengklik submenu TBT belum approve Pada menubar approve menampilkan halaman TBT belum approve * Gambar 3. 36Activity diagram dari use case lihat data belum approve untuk pelanggan TBT

150 122 Berikut ini adalah activity diagram dari use case cek approve per-bulan untuk pelanggan kwh 0, kwh maks, dan TBT: User Sistem * mengklik submenu kwh maks cek per-bulan Pada menubar approve menampilkan halaman isian bulan dan tahun menginput bulan dan tahun Menekan tombol CARI mencari data approve kwh maks sesuai tahun dan bulan Menampilkan daftar approve kwh maks sesuai bulan tahun * Gambar 3. 37Activity diagramdari use case cek approve per-bulan untuk pelanggan kwh maks User Sistem * mengklik submenu TBT cek per-bulan Pada menubar approve menampilkan halaman isian bulan dan tahun menginput bulan dan tahun Menekan tombol CARI mencari data approve TBT sesuai tahun dan bulan Menampilkan daftar approve TBT sesuai bulan tahun * Gambar 3. 38Activity diagram dari use case cek approve per-bulan untuk pelanggan TBT

151 123 User Sistem * Mengklik menu pelanggan kwh 0 Pada menubar cetak laporan menampilkan halaman isian bulan dan tahun menginput bulan dan tahun Menekan tombol CARI mencari data approve kwh 0 sesuai tahun dan bulan Menampilkan daftar approve kwh 0 sesuai bulan tahun * Gambar 3. 39Activity diagram dari use case cek approve per-bulan untuk pelanggan kwh 0 Berikut ini adalah activity diagram dari use case cek monitor per-bulan untuk pelanggan kwh 0, kwh maks, dan TBT: User Sistem * mengklik submenu kwh 0 cek per-bulan Pada menubar monitoring menampilkan halaman isian bulan dan tahun menginput bulan dan tahun Menekan tombol CARI mencari data monitoring kwh 0 sesuai tahun dan bulan Menampilkan daftar monitoring kwh 0 sesuai bulan tahun * Gambar 3. 40Activity diagram dari use case cek monitor per-bulan untuk pelanggan kwh 0

152 124 User Sistem * mengklik submenu kwh maks cek per-bulan Pada menubar monitoring menampilkan halaman isian bulan dan tahun menginput bulan dan tahun Menekan tombol CARI mencari data approve kwh maks sesuai tahun dan bulan Menampilkan daftar monitoring kwh maks sesuai bulan tahun * Gambar 3. 41Activity diagram dari use case cek monitor per-bulan untuk pelanggan kwh maks User Sistem * mengklik submenu TBT cek per-bulan Pada menubar monitoring menampilkan halaman isian bulan dan tahun menginput bulan dan tahun Menekan tombol CARI mencari data monitoring TBT sesuai tahun dan bulan Menampilkan daftar monitoring TBT sesuai bulan tahun * Gambar 3. 42Activity diagram dari use case cek monitor per-bulan untuk pelanggan TBT

153 125 Berikut ini adalah activity diagram dari use caseupload data hasil monitor (diasumsikan pelanggan kwh 0, kwh maks, dan TBT memiliki langkah upload yang sama): User Sistem * Menekan tombol pada kolom upload data monitoring menampilkan halaman form isian hasil monitoring mengisi koordinat,tgl monitor, verifikasi, keadaan mcb Menekan tombol SIMPAN menyimpan data hasil monitor dan mengubah status monitor memilih gambar untuk diupload Jika berhasil menyimpan Jika tidak berhasil menyimpan Menekan tombol UPLOAD menyimpan data gambar Jika tidak berhasil menyimpan Jika berhasil menyimpan menampilkan pesan upload berhasil * Gambar 3. 43Activity diagram dari use case upload data hasil monitor

154 126 Berikut ini adalah activity diagram dari use case ubah data hasil monitor (diasumsikan pelanggan kwh 0, kwh maks, dan TBT memiliki langkah ubah data yang sama): User * Sistem Menekan tombol pada kolom upload data monitoring menampilkan halaman Detail data hasil monitoring mengisi koordinat,tgl monitor, verifikasi, keadaan mcb Menekan tombol UBAH menyimpan data perubahan memilih gambar untuk diupload Jika berhasil menyimpan Jika tidak berhasil menyimpan Menekan tombol UPLOAD menyimpan data gambar Jika tidak berhasil menyimpan Jika berhasil menyimpan menampilkan pesan upload berhasil * Gambar 3. 44Activity diagram dari use case ubah data hasil monitor

155 127 Berikut ini adalah activity diagram dari use case batalkan status monitor (diasumsikan pelanggan kwh 0, kwh maks, dan TBT memiliki langkah yang sama): User * Sistem menekan tombol pada kolom lihat detail menampilkan halaman detail approve hasil monitor pelanggan mengisi alasan pembatalan status monitor Menekan tombol BATALKAN menyimpan alasan pembatalan dan mengubah status monitor Jika data tidak berhasil dibatalkan Jika data berhasil dibatalkan menampilkan pesan status berhasil dibatalkan * Gambar 3. 45Activity diagram dari use case batalkan status monitor

156 128 Berikut ini adalah activity diagram dari use case batalkan status approve (diasumsikan pelanggan kwh 0, kwh maks, dan TBT memiliki langkah yang sama): User * Sistem menekan tombol pada kolom lihat detail menampilkan halaman detail approve hasil monitor pelanggan mengisi alasan pembatalan status approve Menekan tombol BATALKAN menyimpan alasan pembatalan dan mengubah status monitor dan status approve Jika data tidak berhasil dibatalkan Jika data berhasil dibatalkan menampilkan pesan status berhasil dibatalkan * Gambar 3. 46Activity diagram dari use case batalkan status approve

157 129 Berikut ini adalah activity diagram dari use caseapprove data hasil monitor (diasumsikan pelanggan kwh 0, kwh maks, dan TBT memiliki langkah yang sama): User * Sistem menekan tombol pada kolom lihat detail menampilkan halaman detail approve hasil monitor pelanggan menekan tombol approve mengubah status approve Jika data tidak berhasil diapprove Jika data berhasil diapprove menampilkan pesan data berhasil diapprove * Gambar 3. 47Activity diagram dari use caseapprove data hasil monitor (diasumsikan pelanggan kwh 0, kwh maks, dan TBT memiliki langkah yang sama)

158 130 Berikut ini adalah activity diagram dari use case lihat versi sebelum dari data hasil monitor (diasumsikan pelanggan kwh 0, kwh maks, dan TBT memiliki langkah yang sama): User * Sistem menekan tombol berisi idmon versi sebelum menampilkan halaman detail monitoring versi sebelum * Gambar 3. 48Activity diagram dari use case lihat versi sebelum dari data hasil monitor Berikut ini adalah activity diagram dari use case lihat history monitoring dari data hasil monitor (diasumsikan pelanggan kwh 0, kwh maks, dan TBT memiliki langkah yang sama): User * Sistem menekan tombol HISTORY MONITORING menampilkan halaman Detail history monitoring * Gambar 3. 49Activity diagram dari use caselihat history monitoring dari data hasil monitor

159 131 Berikut ini adalah activity diagram dari use case copy status bulan terakhir (diasumsikan pelanggan kwh 0, kwh maks, dan TBT memiliki langkah copy status yang sama): Sistem * menekan tombol copy status pada kolom lihat detail Mencari data pelanggan dengan idpel yg sama yang sudah diapprove sebelumnya menekan tombol approve Jika data ditemukan menampilkan halaman detail copy status approve Jika data tidak ditemukan menampilkan pesan tidak data sebelumnya yang sudah diapprove menyimpan data hasil monitor dan mengubah status monitor dan approve Jika data tidak berhasil disimpan Jika data berhasil disimpan menampilkan pesan copy status berhasil * Gambar 3. 50Activity diagram dari use casecopy status bulan terakhir (diasumsikan pelanggan kwh 0, kwh maks, dan TBT memiliki langkah copy status yang sama)

160 132 Berikut ini adalah activity diagram dari use case cetak laporan monitoring untuk pelanggan kwh 0 dan kwh maks : User Sistem * Mengklik menu pelanggan kwh 0 Pada menubar cetak laporan menampilkan halaman Cetak laporan pelanggan kwh 0 menginput bulan dan tahun Menekan tombol CETAK mencari data approve kwh 0 sesuai tahun dan bulan menekan tombol print Menampilkan preview laporan yang akan dicetak mencetak laporan * Gambar 3. 51Activity diagram dari use case cetak laporan untuk pelanggankwh 0 User Sistem * Mengklik menu pelanggan kwh maks Pada menubar cetak laporan menampilkan halaman Cetak laporan pelanggan kwh maks menginput bulan dan tahun Menekan tombol CETAK mencari data approve kwh maks sesuai tahun dan bulan menekan tombol print Menampilkan preview laporan yang akan dicetak mencetak laporan * Gambar 3. 52Activity diagram dari use case cetak laporan untuk pelanggan kwh maks

161 133 Berikut ini adalah activity diagram dari use case cetak laporan monitoring untuk pelanggan TBT dan pelanggan kwh maks naik daya: User Sistem * Mengklik menu Tidak Beli Token >3 Bulan Pada menubar cetak laporan menampilkan halaman Cetak laporan pelanggan TBT menginput bulan dan tahun Menekan tombol CETAK mencari data approve TBT sesuai tahun dan bulan menekan tombol print Menampilkan preview laporan yang akan dicetak mencetak laporan * Gambar 3. 53Activity diagram dari use casecetak laporan untuk pelanggan TBT User Sistem * Mengklik menu kwh maks naik daya Pada menubar cetak laporan menampilkan halaman Cetak laporan pelanggan kwh maksnaik daya menginput bulan dan tahun Menekan tombol CETAK mencari data pelangan kwh maks naik daya sesuai tahun dan bulan menekan tombol print Menampilkan preview laporan yang akan dicetak mencetak laporan * Gambar 3. 54Activity diagram dari use case cetak laporan untuk pelanggan naik daya

162 134 Berikut ini adalah activity diagram dari use case lihat data yang sama untuk pelanggan kwh 0, kwh maks, dan TBT: User * Sistem Mengklik tombol cek data yang sama menampilkan halaman data pelanggan kwh 0 yang sama * Gambar 3. 55Activity diagram dari use case tampilkan data yang sama pelanggan kwh 0 User * Sistem Mengklik tombol cek data yang sama menampilkan halaman data pelanggan kwh maks yang sama * Gambar 3. 56Activity diagram dari use case tampilkan data yang sama pelanggan kwh maks User * Sistem Mengklik tombol cek data yang sama menampilkan halaman data pelanggantbt yang sama * Gambar 3. 57Activity diagram dari use case tampilkan data yang sama pelanggan TBT

163 135 Berikut ini adalah activity diagram dari use case lihat detail pelanggan: User * Sistem Menginput id pelanggan Menekan tombol CARI mencari data pelanggan Jika data pelanggan tidak ditemukan Jika data pelanggan ditemukan menampilkan halaman detail pelanggan * Gambar 3. 58Activity diagram dari use case lihat detail pelanggan Diagram Sekuensial Berikut ini adalah diagram sekuensial yang akan menjelaskan bagaimana suatu operasi atau sistem dijalankan secara tahap demi tahap. Gambar 5.59 s/d gambar 5.88 akan menampilkan diagram sekuensial dari setiap case yang dijelaskan sebelumnya.

164 136 Gambar Diagram sekuensial untuk login admin Gambar Diagram sekuensial untuk login operator

165 137 Gambar Diagram Sekuensial untuk use case tambah user

166 138 Gambar Diagram sekuensial untuk usecase edit data user

167 139 Gambar Diagram sekeunsial untuk use case lihat daftar Kwh 0 belum cek Gambar Diagram sekeunsial untuk usecase lihat daftar kwh maks belum cek

168 140 Gambar 3. 65Diagram sekuensial untuk usecase lihat daftar TBT sudah cek Gambar 3. 66Diagram sekuensial untuk usecase lihat daftar kwh 0 sudah cek

169 141 Gambar Diagram sekuensial untuk usecase lihat daftar kwh maks sudah cek Gambar Diagram sekuensial untuk usecase lihat data kwh maks cek perbulan

170 142 Gambar Diagram sekuensial untuk usecase lihat data kwh 0 cek perbulan Gambar Diagram sekuensial untuk usecase lihat data TBT cek perbulan

171 143 Gambar Diagram sekuensial untuk usecase lihat data kwh 0 cek approve perbulan Gambar Diagram sekuensial untuk usecase lihat data kwh maks cek approve perbulan

172 144 Gambar Diagram sekuensial untuk usecase lihat data tbt cek approve perbulan Gambar Diagram sekuensial untuk usecase lihat Data TBT lihat yang sama

173 145 Gambar Diagram sekuensial untuk usecase lihat data kwh 0 cek data yang sama Gambar Diagram sekuensial untuk usecase lihat data data kwh maks cek data yang sama

174 146 Gambar 3. 77Diagram sekuensial untuk usecase lihat versi sebelum data monitoring pelanggan kwh 0 (kwh maks dan TBT sama) Gambar Diagram sekuensial untuk usecase lihat history monitoring pelanggan kwh 0 (kwh maks dan TBT sama)

175 147 Gambar Diagram sekuensial untuk usecase proses approve pelanggan kwh 0 (kwh maks dan TBT sama)

176 148 Gambar Diagram sekuensial untuk usecase pembatalan status monitoring pelanggan kwh 0 (kwh maks dan TBT sama) Gambar Diagram sekuensial untukuse case pembatalan status approve

177 149 Gambar Diagram sekuensial untuk usecaseupload data monitoring pelanggan kwh 0 (kwh maks dan TBT sama)

178 150 Gambar Diagram sekuensial untuk usecase proses ubah data monitoring pelanggan kwh 0 (kwh maks dan TBT sama)

179 151 Gambar Diagram sekuensial untuk usecase proses copy status pelanggan kwh maks (kwh 0 dan TBT sama) Gambar Diagram sekuensial untuk usecase cetak laporan monitoring kwh 0

180 152 Gambar Diagram sekuensial untuk usecase cetak laporan monitoring kwh maks Gambar Diagram sekuensial untuk usecase cetak laporan monitoring TBT

181 153 Gambar Diagram sekuensial untuk usecase laporan rekomendasi monitoring naik daya pelanggan kwh maks

182 Diagram Kelas Berikut ini pada gambar 3.89 merupakan diagram kelas. Untuk lebih lengkap mengenai isi (atribut, tipe data, dan method) dari masing-masing kelas dapat dlihat pada Lampiran C. Display_Foto Lihat_Data LihatData_TBT DetailPelanggan_DPM uploadhandler DataPegawai Unitup DatabaseConnection approve Monitor_control +getmconnection() +getmdatasource() Naik_daya uploadhandlertbt koneksi List_history Rekapitulasi Dashboard DetailPelanggan_TBT Gambar Diagram Kelas

183 Perancangan Basis Data Desain Konseptual Basis Data Pada gambar 3.90 akan menampilkan desain konseptual basis data yang digunakan dalam sistem monitoring ini, dimana terdapat entity (entitas)dlpd_pascabayar dan dlpd_prabayar yang merupakan weak entity.entity ini keberadaan bergantung pada entity Pelanggan. Terdapat primary key blth dan idpel untuk tabel dlpd_pascabayar dan dlpd_prabayar untuk mengidentifikasikan data secara unik, karena tambahan primary key blth akan membedakan record dengan idpel yang sama (idpel sama namun blth berbeda). Gambar 3. 90Desain konseptual basis data dari sistem

184 Desain Logikal Basis Data Entity DLPD_Pascabayar dan DLPD_Prabayar merupakan weak entity, primary key blth tidak cukup untuk mengidentifikasikan data pelanggan yang harus dimonitoring, sehingga keberadaannya bergantung pada entity pelanggan dengan menambahkan primary key idpel dari entity pelanggan tersebut. Pada gambar 3.91 akan menampilkan desain logikal basis data yang digunakan dalam sistem monitoring ini: Gambar Desain logikal basis data dari sistem

185 Desain Fisikal Basis Data Di dalam pembuatan sistem monitoring ini terdapat beberapa tabel yang digunakan yaitu : Tabel 3. 76Tabel Data_Penduduk Nama Field Tipe Data Panjang Key NO_KTP Varchar2 20 Primary key ALAMAT Varchar2 20 NAMA Varchar2 20 Tabel Tabel Produk Nama Field Tipe Data Panjang Key KODE_PRODUK Varchar2 6 Primary key GOLONGAN Varchar2 20 TARIF Number 20 JENIS_TARIF Varchar2 20 Tabel Tabel Pelanggan Nama Field Tipe Data Panjang Key IDPEL Varchar2 20 Primary key NO_KTP Varchar2 20 Foreign key KODE_PRODUK Varchar2 6 Foreign key UNITUP Number 6 Foreign key DAYA Varchar2 20 Tabel Tabel USER_LOGIN Nama Field Tipe Data Panjang Key USERNAME Varchar2 20 Primary key PASSWORD Varchar2 20 NAMA Varchar2 20 UNITUP Number 6 Foreign key PRIVILEDGE Varchar2 10

186 158 Tabel Tabel KODE_UNIT Nama Field Tipe Data Panjang Key UNITUP Number 6 Primary key LOKASI Varchar2 20 ALAMAT Varchar2 50 TINGKAT Varchar2 10 Tabel Tabel DLPD_PRABAYAR Nama Field Tipe Data Panjang Key IDPEL Varchar2 30 Primary key BLTH Number 8 Primary key KWHTOT Number 15 STATUS_APP Varchar2 5 STATUS_MON Varchar2 5 IDMON Varchar2 20 Foreign key Tabel Tabel DLPD_PRABAYAR Nama Field Tipe Data Panjang Key IDPEL Varchar2 20 Primary key BLTH Number 8 Primary key NO_METER Varchar2 20 STATUS_MON Varchar2 5 STATUS_APP Varchar2 5 BULAN Varchar2 15 TGL_BAYAR Date IDMON Varchar2 20 Foreign key Tabel Tabel RECORD_MONITORING_PRABAYAR Nama Field Tipe Data Panjang Key IDMON Varchar2 20 Primary key USER_ID Varchar2 5 Foreign key IDPEL Varchar2 20 Foreign key BLTH Number 8 Foreign key KOORDINAT Varchar2 20 VERIFIKASI Varchar2 50 GAMBAR Varchar2 20 TGL_MON Date TGL_APP Date KEADAAN_MCB Number 2 KET Varchar2 50 VERSI SEBELUM Varchar2 20

187 159 Tabel Tabel MONITORING_PASCABAYAR Nama Field Tipe Data Panjang Key IDMON Varchar2 20 Primary key USER_ID Varchar2 20 Foreign key BLTH Number 8 Foreign key USERNAME Varchar2 5 Foreign key KOORDINAT Varchar2 20 VERIFIKASI Varchar2 50 GAMBAR Varchar2 20 TGL_MON Date TGL_APP Date KEADAAN_MCB Number 2 KET Varchar2 50 VERSI SEBELUM Varchar2 20

188 BAB IV IMPLEMENTASI SISTEM 4.1. Sistem Monitoring Pelanggan Pascabayar dan Prabayar Tidak Beli Token Sistem Monitoring Pelanggan Pasca Bayar kwh 0, kwh Maks, dan Prabayar Tidak Beli Token Lebih Dari 3 Bulanini merupakan sistem yang di bangun untuk digunakan oleh pihak PT. PLN (Persero) Area Kuala Kapuas khususnya pada Bagian Transaksi Energi. Secara umum, sistem monitoring ini terdiri dari 3 operasi yaitu insert, update, dan search sebagai berikut ini: i. Search Search pada sistem monitoring pelanggan ini dilakukan oleh semua tipe user. Search dilakukan untuk menampilkan daftar pelanggan yang sudah dimonitor atau belum berdasarkan bulan, unitup, atau data pelanggan yang sama lebih dari satu bulan. Search ini juga dilakukan untuk mencari pelanggan tertentu berdasarkan no meter atau id pelanggan. Hasil yang diharapkan dari operasi ini adalah daftar pelanggan berdasarkan parameter pencarian tertentu bisa ditampilkan dan data pelanggan yang dicari bisa ditemukan. ii. Insert Insert pada sistem monitoring pelanggan ini dapat dilakukan oleh admin pengelolaan data user yang akan login dan menggunakan sistem ini. Operasi ini dilakukan untuk menambahkan data user seperti username, password, tingkat, kode unit, dan priviledge. Hasil yang diharapkan dari insert data tersebut adalah data user tersimpan di basis data. iii. Update Update pada sistem monitoring pelanggan dapat dilakukan oleh admin khususnya pada pengelolaan data user dan operator dan pengelolaan data monitoring pelanggan kwh 0, kwh maks, dan TBT oleh user admin dan operator. Update dapat dilakukan jika ingin memodifikasi data yang telah disimpan. Modifikasi ini berkaitan dengan update status 160

189 161 monitoring dan approve atau menambahkan detail monitoring pada record pelanggan pada bulan tertentu seperti foto, koordinat, verifikasi, dan tanggal. Hasil yang diharapkan dari update data tersebut adalah data yang dimodifikasi dapat tersimpan di basis data. Sistem monitoring ini mencakup proses pengecekkan (monitoring) pelanggan di semua rayon, kemudian pengumpulan data hasil monitoring hingga validasi dan approval dari data pelanggan tersebut : a. Monitoring Pelanggan kwh 0 : 1. Lihat data pelanggan kwh 0 yang belum dicek. User yang bertipe admin dan operator dapa melihat daftar pelanggan kwh 0 yang belum dicek dan belum diambil data monitoringnya. 2. Lihat data pelanggan kwh 0 yang sudah dicek. User yang bertipe admin dan operator dapa melihat daftar pelanggan kwh 0 yang sudah dicek dan diambil data monitoringnya. 3. Lihat data pelanggan kwh 0 yang belum diapprove. User yang bertipe admin dan operator dapa melihat daftar pelanggan kwh 0 yang belum di-approve namun sudah dilakukan monitoring oleh petugas. 4. Lihat data pelanggan kwh 0 yang sudah diapprove. User yang bertipe admin dan operator dapa melihat daftar pelanggan kwh 0 yang sudah di-approve dan sudah dilakukan monitoring oleh petugas. 5. Upload data monitoring. User yang bertipe admin dan operator dapat menambahkan (mengupload) data monitoring pelanggan saat dilakukan pengecekkan di lapangan seperti: foto, koordinat, verifikasi, dan tanggal pengecekkan. 6. Ubah data monitoring. User yang bertipe admin dan operator dapat mengubah (mengupdate) data monitoring pelanggan kwh 0 yang sudah dilakukan pengecekkan. Update data meliputi foto, koordinat, tanggal diubahnya data, dan verifikasi pengubahan. 7. Batalkan data monitoring pelanggan. Pembatalan data monitoring ini dilakukan oleh user bertipe admin saja, dimana pembatalan adalah

190 162 memberikan status batal pada status monitoring pelanggan tertentu yang data monitoringnya belum lengkap, tidak sah, alasan tidak tepat, terjadi kesalahan upload gambar atau gambar kurang jelas sehingga perlu dilakukan monitoring ulang dengan mengubah/update data monitoring tersebut. 8. Approve data monitoring pelanggan. Approve dilakukan untuk memberikan status approve pada status monitoring pelanggan. Proses approval adalah pengecekkan data hasil monitoring dan memberikan persetujuan pada data hasil monitoring tersebut. Approve hanya bisa dilakukan oleh user dengan tipe admin. 9. Batalkan approve pada data monitoring pelanggan. Pembatalan approve pada data monitoring ini dilakukan oleh user bertipe admin saja, dimana pembatalan adalah membatalkan persetujuan pada data monitoring yang sudah diapprove, memberikan status batal pada status approve pelanggan tertentu yang data monitoringnya belum lengkap, tidak sah, alasan tidak tepat, terjadi kesalahan upload gambar atau gambar kurang jelas sehingga perlu dilakukan monitoring ulang dengan mengubah/update data monitoring tersebut. 10. Copy status bulan terakhir dilakukan untuk menyalin status monitoring, status approve dan detail lain seperti foto, koordinat, verifikasi dari data monitoring pelanggan kwh 0 yang sebelumnya dimonitoring dan disetujui hasil monitoringnya (approve) pada bulan sebelumnya. 11. Cetak laporan kwh 0 dilakukan untuk mencetak laporan hasil monitoring pelanggan kwh 0 yang datanya sudah diapprove pada bulan tertentu atau dalam jangka waktu beberapa bulan. 12. Lihat versi sebelum dilakukan untuk melihat data hasil monitoring pelanggan kwh 0 versi sebelumnya. 13. Lihat History Monitoring dilakukan untuk melihat history dari monitoring pada pelanggan kwh 0.

191 163 b. Monitoring Pelanggan kwh Maks: 1. Lihat data pelanggan kwh maks yang belum dicek. User yang bertipe admin dan operator dapa melihat daftar pelanggan kwh maks yang belum dicek dan belum diambil data monitoringnya. 2. Lihat data pelanggan kwh maks yang sudah dicek. User yang bertipe admin dan operator dapa melihat daftar pelanggan kwh maks yang sudah dicek dan diambil data monitoringnya. 3. Lihat data pelanggan kwh maks yang belum diapprove. User yang bertipe admin dan operator dapa melihat daftar pelanggan kwh maks yang belum diapprove namun sudah dilakukan monitoring oleh petugas. 4. Lihat data pelanggan kwh maks yang sudah diapprove. User yang bertipe admin dan operator dapa melihat daftar pelanggan kwh maks yang sudah diapprove dan sudah dilakukan monitoring oleh petugas. 5. Upload data monitoring. User yang bertipe admin dan operator dapat menambahkan (mengupload) data monitoring pelanggan saat dilakukan pengecekkan di lapangan seperti: foto, koordinat, verifikasi, dan tanggal pengecekkan. 6. Ubah data monitoring. User yang bertipe admin dan operator dapat mengubah (mengupdate) data monitoring pelanggan kwh maks yang sudah dilakukan pengecekkan. Update data meliputi foto, koordinat, tanggal diubahnya data, dan verifikasi pengubahan. 7. Batalkan data monitoring pelanggan. Pembatalan data monitoring ini dilakukan oleh user bertipe admin saja, dimana pembatalan adalah memberikan status batal pada status monitoring pelanggan tertentu yang data monitoringnya belum lengkap, tidak sah, alasan tidak tepat, terjadi kesalahan upload gambar atau gambar kurang jelas sehingga perlu dilakukan monitoring ulang dengan mengubah/update data monitoring tersebut. 8. Approve data monitoring pelanggan. Approve dilakukan untuk memberikan status approve pada status monitoring pelanggan.

192 164 Proses approval adalah pengecekkan data hasil monitoring dan memberikan persetujuan pada data hasil monitoring tersebut. Approve hanya bisa dilakukan oleh user dengan tipe admin. 9. Batalkan approve pada data monitoring pelanggan. Pembatalan approve pada data monitoring ini dilakukan oleh user bertipe admin saja, dimana pembatalan adalah membatalkan persetujuan pada data monitoring yang sudah diapprove, memberikan status batal pada status approve pelanggan tertentu yang data monitoringnya belum lengkap, tidak sah, alasan tidak tepat, terjadi kesalahan upload gambar atau gambar kurang jelas sehingga perlu dilakukan monitoring ulang dengan mengubah/update data monitoring tersebut. 10. Copy status bulan terakhir dilakukan untuk menyalin status monitoring, status approve dan detail lain seperti foto, koordinat, verifikasi dari data monitoring pelanggan kwh maks yang sebelumnya dimonitoring dan disetujui hasil monitoringnya (approve) pada bulan sebelumnya. 11. Cetak laporan kwh maks dilakukan untuk mencetak laporan hasil monitoring pelanggan kwh maks yang datanya sudah diapprove pada bulan tertentu atau dalam jangka waktu beberapa bulan. 12. Lihat versi sebelum dilakukan untuk melihat data hasil monitoring pelanggan kwh maks versi sebelumnya. 13. Lihat History Monitoring dilakukan untuk melihat history dari monitoring pada pelanggan kwh maks. 14. Cetak laporan rekomendasi monitoring naik daya dilakukan untuk melihat data pelanggan yang harus dimonitoring untuk naik daya dari daya yang ada saat ini. c. Monitoring Pelanggan Tidak Beli Token > 3 bulan: 1. Lihat data pelanggan TBT yang belum dicek. User yang bertipe admin dan operator dapa melihat daftar pelanggan TBT yang belum dicek dan belum diambil data monitoringnya.

193 Lihat data pelanggan TBT yang sudah dicek. User yang bertipe admin dan operator dapa melihat daftar pelanggan TBT yang sudah dicek dan diambil data monitoringnya. 3. Lihat data pelanggan TBT yang belum diapprove. User yang bertipe admin dan operator dapa melihat daftar pelanggan TBT yang belum di-approve namun sudah dilakukan monitoring oleh petugas. 4. Lihat data pelanggan TBT yang sudah di-approve. User yang bertipe admin dan operator dapa melihat daftar pelanggan TBT yang sudah di-approve dan sudah dilakukan monitoring oleh petugas. 5. Upload data monitoring. User yang bertipe admin dan operator dapat menambahkan (mengupload) data monitoring pelanggan saat dilakukan pengecekkan di lapangan seperti: foto, koordinat, verifikasi, dan tanggal pengecekkan. 6. Ubah data monitoring. User yang bertipe admin dan operator dapat mengubah (mengupdate) data monitoring pelanggan TBT yang sudah dilakukan pengecekkan. Update data meliputi foto, koordinat, tanggal diubahnya data, dan verifikasi pengubahan. 7. Batalkan data monitoring pelanggan. Pembatalan data monitoring ini dilakukan oleh user bertipe admin saja, dimana pembatalan adalah memberikan status batal pada status monitoring pelanggan tertentu yang data monitoringnya belum lengkap, tidak sah, alasan tidak tepat, terjadi kesalahan upload gambar atau gambar kurang jelas sehingga perlu dilakukan monitoring ulang dengan mengubah/update data monitoring tersebut. 8. Approve data monitoring pelanggan. Approve dilakukan untuk memberikan status approve pada status monitoring pelanggan. Proses approval adalah pengecekkan data hasil monitoring dan memberikan persetujuan pada data hasil monitoring tersebut. Approve hanya bisa dilakukan oleh user dengan tipe admin. 9. Batalkan approve pada data monitoring pelanggan. Pembatalan approve pada data monitoring ini dilakukan oleh user bertipe admin saja, dimana pembatalan adalah membatalkan persetujuan pada data

194 166 monitoring yang sudah diapprove, memberikan status batal pada status approve pelanggan tertentu yang data monitoringnya belum lengkap, tidak sah, alasan tidak tepat, terjadi kesalahan upload gambar atau gambar kurang jelas sehingga perlu dilakukan monitoring ulang dengan mengubah/update data monitoring tersebut. 10. Cetak laporan TBT dilakukan untuk mencetak laporan hasil monitoring pelanggan TBT yang datanya sudah diapprove pada bulan tertentu atau dalam jangka waktu beberapa bulan. 11. Lihat versi sebelum dilakukan untuk melihat data hasil monitoring pelanggan TBT versi sebelumnya. 12. Lihat History Monitoring dilakukan untuk melihat history dari monitoring pada pelanggan TBT. Copy status bulan terakhir dilakukan untuk menyalin status monitoring, status approve dan detail lain seperti foto, koordinat, verifikasi dari data monitoring pelanggan TBT yang sebelumnya sudah dimonitoring dan disetujui hasil monitoringnya (approve) pada bulan sebelumnya Spesifikasi Software dan Hardware yang Digunakan Spesifikasi Software Spesifikasi software yang digunakan untuk implementasi sistem monitoring ini adalah sebagai berikut: 1. Sistem Operasi Windows 7Ultimate 64bit 2. Oracle XE 3. Oracle SQL Developer 4. Netbeans Browser : Google Chrome dan Mozilla Firefox Spesifikasi Hardware Spesifikasi hardware yang digunakan untuk implementasi sistem monitoring ini adalah sebagai berikut: 1. Prosesor : Intel (R) Core (TM) i3-2350m GHz

195 RAM : 4096MB DDR3 3. Harddisk : 500GB 4.3. Implementasi Stored Procedure dan Function Berikut ini akan dijelaskan mengenai implementasi sistem dengan menggunakan Stored Procedure dan Function: Implementasi Stored Procedure untuk Proses Upload Data MonitorPascabayar Proses upload data monitor merupakan bagian dari proses monitoring bagi pelanggan pascabayar. Data yang diupload berupa koordinat MCB, tanggal monitoring, verifikasi, keadaan MCB, dan foto dari MCB. Pelanggan yang sudah dimonitor akan mendapatkan status monitoring dan IDMON (id monitoring). Stored procedure yang digunakan menerapkan method Two Phase Locking (2PL)untuk menangani aksi menyimpan data monitor, melakukan update status, dan menangani masalah concurrency control yaitu mencegah dua buah transaksi update pada row yang sama di tabel secara bersamaan. Metode locking digunakan untuk mengunci row dari idpel dan blth yg ditunjuk pada tabel DLPD_PASCABAYAR (tabel ini menyimpan data monitoring pelanggan pascabayar) agar transaksi setelahnya yang menunjuk row ini tidak dapat melakukan write data (update) pada row tersebut. Penguncian row dilakukan dengan menggunakan klausa FOR UPDATE OF. Proses locking berjalan ketika selection data dari idpel dan blth yang akan diupdate status monitor dan idmonnya. Proses selection tersebut berguna untuk mencari data dari pelanggan yang akan diubah status monitornya. Setelah itu akan dipanggil function tambah_idmon_pasca yang berguna untuk generate id monitoring. Jika proses tersebut berhasil, maka proses selection untuk mencari idmon versi sebelumnya dari idpel dan blth tersebut. Selanjutnya update tabel DLPD_PASCABAYAR dengan set status_mon = YES dan idmon dengan id yang sudah digenerate sebelumnya. Id versi sebelumnya akan dicek, jika id tidak ada maka proses insert data hasil monitor ke tabel RECORD_DLPD_PASCABAYAR akan dilakukan dengan mengosongkan kolom

196 168 versi_sebelum, jika sebaliknya maka insert akan dilakukan dengan menyertakan id versi sebelumnya. Berikut ini gambar 4.1 yang menampilkan isi dari stored procedure monitor_pascabayar: create or replace procedure monitor_pascabayar (v_idpel in dlpd_pascabayar.idpel%type, v_blth in dlpd_pascabayar.blth%type, v_koordinat in record_dlpd_pascabayar.koordinat%type, v_ket in record_dlpd_pascabayar.ket%type, v_mcb in record_dlpd_pascabayar.keadaan_mcb%type, v_verifikasi in record_dlpd_pascabayar.verifikasi%type, v_user in record_dlpd_pascabayar.user_id%type, v_date in record_dlpd_pascabayar.tgl_mon%type, p_status out number, p_idmon out varchar2, p_versisebelum out varchar2) is v_idmon dlpd_pascabayar.idmon%type; v_status_mon dlpd_pascabayar.status_mon%type; v_versi_sebelum record_dlpd_pascabayar.versi_sebelum%type; ex_no_data_found EXCEPTION; begin select idmon, status_mon into v_idmon, v_status_mon from dlpd_pascabayar where idpel=v_idpel and blth=v_blth for update of idpel,blth; v_idmon:=function_tambah_idmon_pasca(v_idpel,v_blth); p_idmon:=v_idmon; --DBMS_LOCK.SLEEP(10); IF v_idmon is not null then select idmon into v_versi_sebelum from dlpd_pascabayar where idpel=v_idpel and blth=v_blth; p_versisebelum:=v_versi_sebelum; update dlpd_pascabayar set status_mon='yes', idmon=v_idmon where idpel=v_idpel and blth=v_blth; if v_versi_sebelum is not null then insert into record_dlpd_pascabayar (idpel,blth,idmon,koordinat,tgl_mon,verifikasi,ket,keadaan_mcb,versi_sebelum,use r_id) values (v_idpel,v_blth,v_idmon,v_koordinat,to_char(v_date,'dd-mon- YY'),v_verifikasi,v_ket,v_mcb,v_versi_sebelum,v_user);

197 else insert into record_dlpd_pascabayar (idpel,blth,idmon,koordinat,tgl_mon,verifikasi,ket,keadaan_mcb,versi_sebelum, user_id) values (v_idpel,v_blth,v_idmon,v_koordinat,to_char(v_date,'dd-mon- YY'),v_verifikasi,v_ket,v_mcb,null,v_user); end if; 169 else raise ex_no_data_found; end IF; commit; p_status:=1; EXCEPTION WHEN ex_no_data_found THEN rollback; p_status:=0; WHEN OTHERS THEN rollback; p_status:=0; end monitor_pascabayar; Gambar 4. 1Stored Procedure monitor_pascabayar Implementasi Stored Procedure untuk Proses Upload Data Monitor Prabayar Sama seperti yang telah dijelaskan sebelumnya, implementasi stored procedure monitor_prabayar pada proses upload data monitor prabayar dilakukan untuk menangani proses insert data ke tabel RECORD_DLPD_PRABAYAR, update data pada row dengan idpel dan blth yang ditunjuk di tabel DLPD_PRABAYAR, serta mencegah terjadinya transaksi bersamaan oleh 2 user atau lebih untuk update row pada tabel DLPD_PRABAYAR. Proses locking terjadi saat query untuk select idmon, status_mon dari idpel dan blth yang ditunjuk dijalankan. Untuk mengunci row tersebut digunakan klausa FOR UPDATE OF idpel dan blth. Selanjutnya, sama seperti dijelaskan pada kasus upload data monitor pascabayar, function tambah_idmon_prabayar akan dijalankan untuk generate id monitoring yang baru. Jika generate idmon berhasil dijalankan maka proses selanjutnya adalah mencari id versi sebelum dari idpel dan blth yang ditunjuk. Jika id versi sebelum ditemukan, maka proses

198 170 insertke tabel RECORD_DLPD_PRABAYAR akan dilakukan dengan menyertakan id versi sebelum, jika tidak ditemukan maka kolom versi_sebelum akan diset null. Setelah semua proses selesai, maka lock akan dilepaskan dan transaksi setelahnya akan diijinkan untuk mengakses row tersebut. Berikut ini adalah isi dari stored procedur monitor_pascabayar yang ditunjukan pada gambar 4.2: create or replace procedure monitor_prabayar (v_idpel in dlpd_prabayar.idpel%type, v_blth in dlpd_prabayar.blth%type, v_koordinat in record_dlpd_prabayar.koordinat%type, v_ket in record_dlpd_prabayar.ket%type, v_mcb in record_dlpd_prabayar.keadaan_mcb%type, v_verifikasi in record_dlpd_prabayar.verifikasi%type, v_user in record_dlpd_prabayar.user_id%type, v_date in record_dlpd_prabayar.tgl_mon%type, p_status out number, p_idmon out varchar2, p_versisebelum out varchar2) is v_idmon dlpd_prabayar.idmon%type; v_status_mon dlpd_prabayar.status_mon%type; v_versi_sebelum record_dlpd_prabayar.versi_sebelum%type; ex_no_data_found EXCEPTION; begin select idmon, status_mon into v_idmon, v_status_mon from dlpd_prabayar where idpel=v_idpel and blth=v_blth for update of idpel,blth; v_idmon:=function_tambah_idmon_prabayar(v_idpel,v_blth); p_idmon:=v_idmon; IF v_idmon is not null then select idmon into v_versi_sebelum from dlpd_prabayar where idpel=v_idpel and blth=v_blth; p_versisebelum:=v_versi_sebelum; update dlpd_prabayar set status_mon='yes', idmon=v_idmon where idpel=v_idpel and blth=v_blth; if v_versi_sebelum is not null then insert into record_dlpd_prabayar (idpel,blth,idmon,koordinat,tgl_mon,verifikasi,ket,keadaan_mcb,versi_sebelum, user_id) values (v_idpel,v_blth,v_idmon,v_koordinat,to_char(v_date,'dd-mon- YY'),v_verifikasi,v_ket,v_mcb,v_versi_sebelum,v_user);

199 171 else insert into record_dlpd_prabayar (idpel,blth,idmon,koordinat,tgl_mon,verifikasi,ket,keadaan_mcb,versi_sebelum, user_id) values (v_idpel,v_blth,v_idmon,v_koordinat,to_char(v_date,'dd-mon- YY'),v_verifikasi,v_ket,v_mcb,null,v_user); end if; else raise ex_no_data_found; end IF; commit; p_status:=1; EXCEPTION WHEN ex_no_data_found THEN rollback; p_status:=0; WHEN OTHERS THEN rollback; p_status:=0; end monitor_prabayar; Gambar 4. 2Stored procedure monitor_prabayar Implementasi Stored Procedure Untuk Proses Approve Data Hasil MonitorPascabayar Proses approve pascabayar adalah proses memeriksa hasil monitor pelanggan pascabayar yang sudah memiliki status monitoring. Proses approve akan mengubah data pada tabel DPLD_PRABAYAR khususnya pada kolom status_app berdasarkan idpel dan blth yang ditunjuk menjadi YES dan mengubah data pada kolom idmon dengan idmon approve yang sudah digenerate dengan function tambah_idapp_pasca. Jika proses generate berhasil, maka query mencari data monitoring terakhir di tabel RECORD_DLPD_PRABAYAR dari idpel dan blth yang ditunjuk akan dijalankan. Jika data sebelumnya berhasil ditemukan maka proses insert ke tabel RECORD_DLPD_PRABAYAR dengan

200 172 detail data monitor dari idmon sebelumnya akan dilakukan, namun yang berbeda disini adalah kolom idmon akan diisi dengan idmon approve. Prosedur yang dibuat ini juga menerapkan method Two Phase Locking dengan klause FOR UPDATE OF yang diletakan pada query untuk mencari status_app, idmon dari idpel dan blth yang dimaksud. Locking berjalan dengan mengunci row tersebut sehingga tidak ada transaksi lain yang dapat mengakses row untuk ikut write data sampe lock dilepas. Berikut ini akan ditunjukan isi dari prosedur approve_pascabayar pada gambar 4.3: create or replace procedure approve_pascabayar (v_idpel in dlpd_pascabayar.idpel%type, v_blth in dlpd_pascabayar.blth%type, v_user in record_dlpd_pascabayar.user_id%type, p_status out number, p_idmon out varchar2) is v_idmon dlpd_pascabayar.idmon%type; v_status_mon dlpd_pascabayar.status_mon%type; v_koordinat record_dlpd_pascabayar.koordinat%type; v_ket record_dlpd_pascabayar.ket%type; v_mcb record_dlpd_pascabayar.keadaan_mcb%type; v_tgl_mon record_dlpd_pascabayar.tgl_mon%type; v_verifikasi record_dlpd_pascabayar.verifikasi%type; v_gambar record_dlpd_pascabayar.gambar%type; v_versi_sebelum record_dlpd_prabayar.versi_sebelum%type, ex_no_data_found EXCEPTION; begin select idmon, status_app into v_idmon, v_status_mon from dlpd_pascabayar where idpel=v_idpel and blth=v_blth for update of idpel,blth; v_versi_sebelum:=v_idmon; v_idmon:=function_tambah_idapp_pasca(v_idpel,v_blth); p_idmon:=v_idmon; IF v_idmon is not null then select keadaan_mcb,ket,tgl_mon,verifikasi,koordinat,gambar into v_mcb,v_ket,v_tgl_mon,v_verifikasi,v_koordinat,v_gambar from record_dlpd_pascabayar where idmon=v_versi_sebelum; update dlpd_pascabayar set status_app='yes', idmon=v_idmon where idpel=v_idpel and blth=v_blth;

201 173 if v_versi_sebelum is not null then insert into record_dlpd_pascabayar (idpel,blth,idmon,koordinat,tgl_mon,verifikasi,ket,keadaan_mcb,versi_sebelum,user _id,gambar,tgl_app) values (v_idpel,v_blth,v_idmon,v_koordinat,v_tgl_mon,v_verifikasi,v_ket,v_mcb,v_versi_se belum,v_user,v_gambar,to_char(sysdate,'dd-mon-yy')); else raise ex_no_data_found; end IF; commit; p_status:=1; EXCEPTION WHEN ex_no_data_found THEN rollback; p_status:=0; WHEN OTHERS THEN rollback; p_status:=0; end procedure approve_pascabayar; Gambar 4. 3 Implementasi stored procedureapprove_pascabayar

202 Implementasi Stored Procedure Untuk Proses Approve Data Hasil Monitoring Prabayar Impelementasi proses approve data hasil monitor pelanggan prabayar sama memiliki proses yang sama dengan proses approve pada data pelanggan pascabayar. Yang berbeda adalah tabel tujuan untuk update status_app dan idmon di tabel DLPD_PRABAYAR serta pada proses insert data di tabel RECORD_DLPD_PRABAYAR. Function yang dipanggil untuk generate idmon approve adalah function tambah_idapp_prabayar. Implementasi teknik 2PL untuk locking row yang diupdate dilakukan pada tabel DLPD_PRABAYAR. Berikut ini ditunjukan isi dari prosedur approve_prabayar pada gambar 4.4: create or replace procedure approve_prabayar (v_idpel in dlpd_prabayar.idpel%type, v_blth in dlpd_prabayar.blth%type, v_user in record_dlpd_prabayar.user_id%type, p_status out number, p_idmon out varchar2) is v_idmon dlpd_prabayar.idmon%type; v_status_mon dlpd_prabayar.status_mon%type; v_koordinat record_dlpd_prabayar.koordinat%type; v_ket record_dlpd_prabayar.ket%type; v_mcb record_dlpd_prabayar.keadaan_mcb%type; v_tgl_mon record_dlpd_prabayar.tgl_mon%type; v_verifikasi record_dlpd_prabayar.verifikasi%type; v_gambar record_dlpd_prabayar.gambar%type; v_versi record_dlpd_prabayar.versi_sebelum%type, ex_no_data_found EXCEPTION; begin select idmon, status_app into v_idmon, v_status_mon from dlpd_prabayar where idpel=v_idpel and blth=v_blth for update of idpel,blth; v_versi_sebelum:=v_idmon; v_idmon:=function_tambah_idapp_prabayar(v_idpel,v_blth); p_idmon:=v_idmon;

203 175 IF v_idmon is not null then select keadaan_mcb,ket,tgl_mon,verifikasi,koordinat,gambar into v_mcb,v_ket,v_tgl_mon,v_verifikasi,v_koordinat,v_gambar from record_dlpd_prabayar where idmon=v_versi; update dlpd_prabayar set status_app='yes', idmon=v_idmon where idpel=v_idpel and blth=v_blth; if v_versi is not null then insert into record_dlpd_prabayar (idpel,blth,idmon,koordinat,tgl_mon,verifikasi,ket,keadaan_mcb,versi_sebelum,user _id,tgl_app,gambar) values (v_idpel,v_blth,v_idmon,v_koordinat,v_tgl_mon,v_verifikasi,v_ket,v_mcb,v_versi,v_ user,to_char(sysdate,'dd-mon-yy'),v_gambar); else raise ex_no_data_found; end if; else raise ex_no_data_found; end IF; commit; p_status:=1; EXCEPTION WHEN ex_no_data_found THEN rollback; p_status:=0; WHEN OTHERS THEN rollback; p_status:=0; end approve_prabayar; Gambar 4. 4Impelementasi stored procedureapprove_prabayar

204 Implementasi Stored Procedure Untuk Proses Pembatalan Status Monitor Pascabayar Proses pembatalan status monitor pascabayar terjadi ketika data hasil monitor pelanggan pascabayar yang sudah dimonitor ingin dibatalkan sehingga status monitoringnya tidak ada atau diset null. Pembatalan dilakukan jika ada data hasil monitor yang tidak sesuai, misalnya: salah koordinat, foto tidak jelas, belum mencantumkan verifikasi, dll. Proses locking dengan metode 2PL tetap dijalankan pada row yang akan diubah status monitoringnya. Locking dimaksudkan untuk mencegah terjadinya perubahan oleh transaksi lain pada data di kolom yang dimaksud atau pada kolom lainnya. Pembatalan status monitoring akan tetap dibuatkan idmon dengan memanggil function tambah_idmon_pasca. Jika idmon berhasil digenerate maka update status_mon=null dan idmon pada tabel DLPD_PASCABAYAR dijalankan. Setelah itu dilanjutkan dengan proses insert data pembatalan ke tabel RECORD_DLPD_PASCABAYAR. Pada gambar 4.5 ditunjukkan isi dari prosedur batal_monitor_pasca: create or replace procedure batal_monitor_pasca (v_idpel in dlpd_pascabayar.idpel%type, v_blth in dlpd_pascabayar.blth%type, v_user in record_dlpd_pascabayar.user_id%type, v_alasan in record_dlpd_pascabayar.verifikasi%type, v_versi_sebelum in record_dlpd_pascabayar.versi_sebelum%type, p_status out number, p_idmon out varchar2 ) is v_idmon dlpd_pascabayar.idmon%type; v_status_mon dlpd_pascabayar.status_mon%type; v_koordinat record_dlpd_pascabayar.koordinat%type; v_mcb record_dlpd_pascabayar.keadaan_mcb%type; v_tgl_mon record_dlpd_pascabayar.tgl_mon%type; v_user_sebelum record_dlpd_pascabayar.user_id%type; v_gambar record_dlpd_pascabayar.gambar%type; v_ket record_dlpd_pascabayar.ket%type; ex_no_data_found EXCEPTION;

205 177 begin select idmon, status_mon into v_idmon, v_status_mon from dlpd_pascabayar where idpel=v_idpel and blth=v_blth for update of idpel,blth; v_idmon:=function_tambah_idmon_pasca(v_idpel,v_blth); p_idmon:=v_idmon; IF v_idmon is not null then select keadaan_mcb,tgl_mon,koordinat,user_id,gambar into v_mcb,v_tgl_mon,v_koordinat, v_user_sebelum,v_gambar from record_dlpd_pascabayar where idmon=v_versi_sebelum; update dlpd_pascabayar set status_mon=null, idmon=v_idmon where idpel=v_idpel and blth=v_blth; v_ket:='monitoring ini dibatalkan oleh: ' v_user ' tgl ' to_char(sysdate,'dd- MON-YY hh24:mi:ss'); if v_versi_sebelum is not null then insert into record_dlpd_pascabayar (idpel,blth,idmon,koordinat,tgl_mon,verifikasi,ket,keadaan_mcb,versi_sebelum,user _id,gambar) values (v_idpel,v_blth,v_idmon,v_koordinat,v_tgl_mon,v_alasan,v_ket,v_mcb,v_versi_sebe lum,v_user_sebelum,v_gambar); else raise ex_no_data_found; end if; else raise ex_no_data_found; end IF; commit; p_status:=1; EXCEPTION WHEN ex_no_data_found THEN rollback; p_status:=0; WHEN OTHERS THEN rollback; p_status:=0; end batal_monitor_pasca; Gambar 4. 5Implementasi stored procedure batal_monitor_pascabayar

206 Implementasi Stored Procedure Untuk Proses Pembatalan Status Monitor Prabayar Sama dengan proses pembatalan status pascabayar yang dijelaskan sebelumnya. Proses ini akan mengubah status monitoring di tabel DLPD_PRABAYAR menjadi null dan menambahkan idmon pembatalan dengan memanggil function tambah_idmon_prabayar untuk generate idmon. Selanjutnya detail pembatalan akan ditambahkan ke tabel RECORD_DLPD_PASCABAYAR. Jika proses pembatalan gagal, maka akan dilakukan rollback untuk mengembalikan database pada kondisi awal. Berikut ini merupakan isi dari prosedur batal_monitor_prabayar yang ditunjukan pada gambar 4.6: create or replace procedure batal_monitor_prabayar (v_idpel in dlpd_prabayar.idpel%type, v_blth in dlpd_prabayar.blth%type, v_user in record_dlpd_prabayar.user_id%type, v_alasan in record_dlpd_prabayar.verifikasi%type, v_versi_sebelum in record_dlpd_prabayar.versi_sebelum%type, p_status out number, p_idmon out varchar2 ) is v_idmon dlpd_prabayar.idmon%type; v_status_mon dlpd_prabayar.status_mon%type; v_koordinat record_dlpd_prabayar.koordinat%type; v_mcb record_dlpd_prabayar.keadaan_mcb%type; v_tgl_mon record_dlpd_prabayar.tgl_mon%type; v_user_sebelum record_dlpd_prabayar.user_id%type; v_gambar record_dlpd_prabayar.gambar%type; v_ket record_dlpd_prabayar.ket%type; ex_no_data_found EXCEPTION; begin select idmon, status_mon into v_idmon, v_status_mon from dlpd_prabayar where idpel=v_idpel and blth=v_blth for update of idpel,blth; v_idmon:=function_tambah_idmon_prabayar(v_idpel,v_blth); p_idmon:=v_idmon;

207 179 IF v_idmon is not null then select keadaan_mcb,tgl_mon,koordinat,user_id,gambar into v_mcb,v_tgl_mon,v_koordinat, v_user_sebelum,v_gambar from record_dlpd_prabayar where idmon=v_versi_sebelum; update dlpd_prabayar set status_mon=null, idmon=v_idmon where idpel=v_idpel and blth=v_blth; v_ket:='monitoring ini dibatalkan oleh: ' v_user ' tgl ' to_char(sysdate,'dd- MON-YY hh24:mi:ss'); if v_versi_sebelum is not null then insert into record_dlpd_prabayar (idpel,blth,idmon,koordinat,tgl_mon,verifikasi,ket,keadaan_mcb,versi_sebelum,user _id,gambar) values (v_idpel,v_blth,v_idmon,v_koordinat,v_tgl_mon,v_alasan,v_ket,v_mcb,v_versi_sebe lum,v_user_sebelum,v_gambar); else raise ex_no_data_found; end if; else raise ex_no_data_found; end IF; commit; p_status:=1; EXCEPTION WHEN ex_no_data_found THEN rollback; p_status:=0; WHEN OTHERS THEN rollback; p_status:=0; end batal_monitor_prabayar; Gambar 4. 6Implementasi stored procedure batal_monitor_prabayar

208 Implementasi Stored Procedure Untuk Proses Pembatalan Status Approve Pascabayar Pembatalan status approve pada sebuah data monitoring terjadi apabila data pelanggan monitoring yang sudah diapprove ingin dibatalkan karena alasan tertentu. Pembatalan ini akan mengubah status monitoring dan status approve menjadi null, yang artinya data pelanggan tersebut harus dimonitoring kembali. Proses pembatalan menggunakan stored procedure yang mengimplementasikan teknik locking untuk mengunci row pada tabel DLPD_PASCABAYAR yang akan diubah status monitoring dan approve-nya. Teknik ini berjalan ketika menjalankan query select status_app dan idmon dari idpel dan blth yang dimaksud. Setelah itu function tambah_idapp_pasca akan dijalankan untuk generate idmon pembatalan status approve tersebut. Ini dilakukan karena data yang dibatalkan harus tetap disimpan dan memiliki idmon tersendiri. Ini akan memudahkan proses tracing history monitor dari data tersebut. update tabel DLPD_PASCABAYAR akan dijalankan untuk mengubah status monitoring dan approve menjadi null dan set idmon dengan idmon yang baru. Setelah idmon didapatkan, query select data monitoring sebelumnya akan dijalankan untuk mengambil data yang akan dibatalkan. Jika idmon versi sebelum tidak kosong maka proses insert ke tabel RECORD_DLPD_PASCABAYAR akan dilakukan untuk menyimpan detail pembatalan berikut dengan alasan pembatalannya. Jika keseluruhan proses diatas tidak dapat dijalankan,maka rollback untuk mengembalikan kondisi ke awal akan dijalankan. Gambar 4.7. dibawah ini akan menunjukan isi dari prosedur batal_approve_pascabayar: create or replace procedure batal_approve_pasca (v_idpel in dlpd_pascabayar.idpel%type, v_blth in dlpd_pascabayar.blth%type, v_user in record_dlpd_pascabayar.user_id%type, v_alasan in record_dlpd_pascabayar.verifikasi%type, v_versi_sebelum in record_dlpd_pascabayar.versi_sebelum%type, p_status out number, p_idmon out varchar2 )

209 181 Is v_idmon dlpd_pascabayar.idmon%type; v_status_mon dlpd_pascabayar.status_mon%type; v_koordinat record_dlpd_pascabayar.koordinat%type; v_mcb record_dlpd_pascabayar.keadaan_mcb%type; v_tgl_mon record_dlpd_pascabayar.tgl_mon%type; v_tgl_app record_dlpd_pascabayar.tgl_app%type; v_user_sebelum record_dlpd_pascabayar.user_id%type; v_gambar record_dlpd_pascabayar.gambar%type; v_ket record_dlpd_pascabayar.ket%type; ex_no_data_found EXCEPTION; begin select idmon, status_app into v_idmon, v_status_mon from dlpd_pascabayar where idpel=v_idpel and blth=v_blth for update of idpel,blth; --dbms_lock.sleep(2); v_idmon:=function_tambah_idapp_pasca(v_idpel,v_blth); p_idmon:=v_idmon; IF v_idmon is not null then select keadaan_mcb,tgl_mon,tgl_app,koordinat,user_id,gambar into v_mcb,v_tgl_mon,v_tgl_app,v_koordinat, v_user_sebelum,v_gambar from record_dlpd_pascabayar where idmon=v_versi_sebelum; update dlpd_pascabayar set status_app=null, status_mon=null, idmon=v_idmon where idpel=v_idpel and blth=v_blth; v_ket:='approve dibatalkan oleh: ' v_user ' tgl ' to_char(sysdate,'dd-mon-yy hh24:mi:ss'); if v_versi_sebelum is not null then insert into record_dlpd_pascabayar (idpel,blth,idmon,koordinat,tgl_mon,verifikasi,ket,keadaan_mcb,versi_sebelum,user _id,tgl_app,gambar)values (v_idpel,v_blth,v_idmon,v_koordinat,v_tgl_mon,v_alasan,v_ket,v_mcb,v_versi_sebe lum,v_user_sebelum,v_tgl_app,v_gambar); else raise ex_no_data_found; end if;

210 182 else raise ex_no_data_found; end IF; commit; p_status:=1; EXCEPTION WHEN ex_no_data_found THEN rollback; p_status:=0; WHEN OTHERS THEN rollback; p_status:=0; end batal_approve_pasca; Gambar 4. 7Implementasi stored procedure batal_approve_pasca Implementasi Stored Procedure Untuk Proses Pembatalan Status Approve Prabayar Proses pembatalan untuk status approve pelanggan prabayar sama seperti yang sudah dijelaskan sebelumnya pada pembatalan status approve pelanggan pascabayar. Yang berbeda adalah tabel tujuan untuk update status monitor dan approve yaitu tabel DLPD_PRABAYAR, sedangkan untuk proses insert data pembatalan dilakukan pada tabel RECORD_DLPD_PRABAYAR. Function yang dipanggil untuk generate idmon pembatalan adalah function tambah_idapp_prabayar. Berikut ini akan ditampilkan isi dari prosedur ini pada gambar 4.8:

211 183 create or replace procedure batal_approve_prabayar (v_idpel in dlpd_prabayar.idpel%type, v_blth in dlpd_prabayar.blth%type, v_user in record_dlpd_prabayar.user_id%type, v_alasan in record_dlpd_prabayar.verifikasi%type, v_versi_sebelum in record_dlpd_prabayar.versi_sebelum%type, p_status out number, p_idmon out varchar2 ) is v_idmon dlpd_prabayar.idmon%type; v_status_mon dlpd_prabayar.status_mon%type; v_koordinat record_dlpd_prabayar.koordinat%type; v_mcb record_dlpd_prabayar.keadaan_mcb%type; v_tgl_mon record_dlpd_prabayar.tgl_mon%type; v_tgl_app record_dlpd_prabayar.tgl_app%type; v_user_sebelum record_dlpd_prabayar.user_id%type; v_gambar record_dlpd_prabayar.gambar%type; v_ket record_dlpd_prabayar.ket%type; ex_no_data_found EXCEPTION; begin select idmon, status_app into v_idmon, v_status_mon from dlpd_prabayar where idpel=v_idpel and blth=v_blth for update of idpel,blth; --dbms_lock.sleep(2); v_idmon:=function_tambah_idapp_prabayar(v_idpel,v_blth); p_idmon:=v_idmon; IF v_idmon is not null then select keadaan_mcb,tgl_mon,tgl_app,koordinat,user_id,gambar into v_mcb,v_tgl_mon,v_tgl_app,v_koordinat, v_user_sebelum,v_gambar from record_dlpd_prabayar where idmon=v_versi_sebelum; update dlpd_prabayar set status_app=null, status_mon=null, idmon=v_idmon where idpel=v_idpel and blth=v_blth; v_ket:='approve dibatalkan oleh: ' v_user ' tgl ' to_char(sysdate,'dd-mon-yy hh24:mi:ss'); if v_versi_sebelum is not null then insert into record_dlpd_prabayar (idpel,blth,idmon,koordinat,tgl_mon,verifikasi,ket,keadaan_mcb,versi_sebelum,user _id,tgl_app,gambar)

212 184 values (v_idpel,v_blth,v_idmon,v_koordinat,v_tgl_mon,v_alasan,v_ket,v_mcb,v_versi_sebe lum,v_user_sebelum,v_tgl_app,v_gambar); else raise ex_no_data_found; end if; else raise ex_no_data_found; end IF; commit; p_status:=1; EXCEPTION WHEN ex_no_data_found THEN rollback; p_status:=0; WHEN OTHERS THEN rollback; p_status:=0; end batal_approve_prabayar; Gambar 4. 8Implementasi Stored Procedure batal_approve_prabayar Implementasi Function Implementasi FunctionGenerate Idmon Proses Monitoring Berikut ini merupakan implementasi function tambah_idmon_pasca untuk generate id monitoring proses monitoring dan pembatalan status monitoring pelanggan pascabayar (gambar 4.9) dan function tambah_idmon_prabayaruntuk generate id monitoring proses monitoring dan pembatalan status monitoring pelanggan prabayar (gambar 4.10):

213 185 create or replace function function_tambah_idmon_pasca (v_idpel in dlpd_pascabayar.idpel%type, v_blth in dlpd_pascabayar.blth%type) return varchar2 is v_status_mon dlpd_pascabayar.status_mon%type; v_status_app dlpd_pascabayar.status_app%type; v_idmon dlpd_pascabayar.idmon%type; v_date dlpd_pascabayar.idmon%type; ex_no_data_found EXCEPTION; i int; cursor pascabayar_data is select distinct rownum, status_mon, status_app, substr(idpel,8,5) from dlpd_pascabayar where idpel=v_idpel and blth=v_blth; begin open pascabayar_data; loop fetch pascabayar_data into i, v_status_mon, v_status_app, v_idmon; exit when pascabayar_data%rowcount > 2 or pascabayar_data%notfound; end loop; close pascabayar_data; select to_char(sysdate,'yymmdd-hh24miss') into v_date from dual; if i is null then raise ex_no_data_found; else IF (v_status_mon is null) and (v_status_app is null) then v_idmon:=v_date '-' v_idmon '-' 'MON'; elsif (v_status_mon is not null) and (v_status_app is null) then v_idmon:=v_date '-' v_idmon '-' 'REV'; else v_idmon:=null; END IF; end if; return v_idmon; EXCEPTION WHEN ex_no_data_found THEN rollback; WHEN OTHERS THEN rollback; end function_tambah_idmon_pasca; Gambar 4. 9Implementasi function tambah_idmon_pasca

214 186 create or replace function function_tambah_idmon_prabayar (v_idpel in dlpd_prabayar.idpel%type, v_blth in dlpd_prabayar.blth%type) return varchar2 is v_status_mon dlpd_prabayar.status_mon%type; v_status_app dlpd_prabayar.status_app%type; v_idmon dlpd_prabayar.idmon%type; v_date dlpd_prabayar.idmon%type; ex_no_data_found EXCEPTION; i int; cursor prabayar_data is select distinct rownum, status_mon, status_app, substr(idpel,8,5) from dlpd_prabayar where idpel=v_idpel and blth=v_blth; begin open prabayar_data; loop fetch prabayar_data into i, v_status_mon, v_status_app, v_idmon; exit when prabayar_data%rowcount > 2 or prabayar_data%notfound; end loop; close prabayar_data; select to_char(sysdate,'yymidd-hh24miss') into v_date from dual; if i is null then raise ex_no_data_found; else IF (v_status_mon is null) and (v_status_app is null) then v_idmon:=v_date '-' v_idmon '-' 'MON'; elsif (v_status_mon is not null) and (v_status_app is null) then v_idmon:=v_date '-' v_idmon '-' 'REV'; else v_idmon:=null; END IF; end if; return v_idmon; EXCEPTION WHEN ex_no_data_found THEN rollback; WHEN OTHERS THEN rollback; end function_tambah_idmon_prabayar; Gambar 4. 10Implementasi function tambah_idmon_prabayar

215 ImplementasiFunctionGenerateIdmon ProsesApprove Berikut ini merupakan implementasi function tambah_idapp_pasca untuk generate id monitoring proses approve dan pembatalan status aprove pelanggan pascabayar (gambar 4.11) dan function tambah_idapp_prabayaruntuk generate id monitoring proses approve dan pembatalan status approve pelanggan prabayar (gambar 4.12): create or replace function function_tambah_idapp_pasca (v_idpel in dlpd_pascabayar.idpel%type, v_blth in dlpd_pascabayar.blth%type) return varchar2 is v_status_mon dlpd_pascabayar.status_mon%type; v_status_app dlpd_pascabayar.status_app%type; v_idmon dlpd_pascabayar.idmon%type; v_date record_dlpd_pascabayar.idmon%type; ex_no_data_found EXCEPTION; i int; cursor pascabayar_data is select distinct rownum, status_mon, status_app, substr(idpel,8,5) from dlpd_pascabayar where idpel=v_idpel and blth=v_blth; begin open pascabayar_data; loop fetch pascabayar_data into i, v_status_mon, v_status_app, v_idmon; exit when pascabayar_data%rowcount > 2 or pascabayar_data%notfound; end loop; close pascabayar_data; select to_char(sysdate,'yymmdd-hh24miss') into v_date from dual; if i is null then raise ex_no_data_found; else IF (v_status_mon is not null) and (v_status_app is null) then v_idmon:=v_date '-' v_idmon '-' 'APP';

216 188 then v_idmon:=v_date '-' v_idmon '-' 'APP'; elsif (v_status_mon is not null) and (v_status_app is not null) then v_idmon:=v_date '-' v_idmon '-' 'REV'; else v_idmon:=null; END IF; end if; elsif (v_status_mon is not null) and (v_status_app is not null) then v_idmon:=v_date '-' v_idmon '-' 'REV'; else v_idmon:=null; END IF; end if; return v_idmon; EXCEPTION WHEN ex_no_data_found THEN rollback; WHEN OTHERS THEN rollback; end function_tambah_idapp_pasca; Gambar Impelementasi function tambah_idapp_pasca create or replace function function_tambah_idapp_prabayar (v_idpel in dlpd_prabayar.idpel%type, v_blth in dlpd_prabayar.blth%type) return varchar2 is v_status_mon dlpd_prabayar.status_mon%type; v_status_app dlpd_prabayar.status_app%type; v_idmon dlpd_prabayar.idmon%type; v_date record_dlpd_prabayar.idmon%type; ex_no_data_found EXCEPTION; i int; cursor prabayar_data is select distinct rownum, status_mon, status_app, substr(idpel,8,5) from dlpd_prabayar where idpel=v_idpel and blth=v_blth; begin open prabayar_data; loop fetch prabayar_data into i, v_status_mon, v_status_app, v_idmon; exit when prabayar_data%rowcount > 2 or prabayar_data%notfound; end loop;

217 189 close prabayar_data; select to_char(sysdate,'yymmdd-hh24miss') into v_date from dual; if i is null then raise ex_no_data_found; else IF (v_status_mon is not null) and (v_status_app is null) then v_idmon:=v_date '-' v_idmon '-' 'APP'; elsif (v_status_mon is not null) and (v_status_app is not null) then v_idmon:=v_date '-' v_idmon '-' 'REV'; else v_idmon:=null; END IF; end if; return v_idmon; EXCEPTION WHEN ex_no_data_found THEN rollback; WHEN OTHERS THEN rollback; end function_tambah_idapp_prabayar; Gambar 4. 12Implementasi function tambah_idapp_prabayar 4.4. Implementasi Program Proses Login User Berikut ini akan ditunjukan listing program dari proses login user. User yang dapat login bertipe 2 yaitu Operator dan Admin. Method yang dipanggil untuk memvalidasi proses login user adalah method ValidateLoginCredential dengan parameter username, password, priviledge, dan kode unit. Method ini akan ditunjukan lebih lengkap pada Lampiran A nomor Proses Tambah User Proses tambah user adalah proses untuk menambahkan data user login yang memiliki akses untuk masuk ke sistem. Proses tambah user menggunakan method simpandata dengan parameter berupa objek pegawai yang terdiri dari password, username, priviledge, kode, dan nama.proses tambah user dan method simpandata ditunjukan pada Lampiran A nomor 8 dan 9.

218 Proses Edit Data User Proses edit data user terdiri dari 2 yaitu ubah password atau mutasi user. Ubah password adalah proses dimana user ingin mengubah password loginnya, sehingga data pada kolom password di tabel USER_LOGIN akan diupdate. Proses ini akan memanggil method UbahPassword (Lampiran A nomor 10) dengan parameter objek pegawai yang terdiri dari data password dan username. Sedangkan proses mutasi user adalah proses dimana user yang bertugas di suatu rayon pindah ke rayon lain, sehingga data login user tersebut harus diubah priviledge dan kode unitnya. Proses ini akan memanggil method Mutasi yang akan update tabel USER_LOGIN pada kolom priviledge, nama, dan kode unit (Lampiran A nomor 12). Listing proses edit data user ditunjukan pada Lampiran A nomor Proses Monitoring Prabayar dan Pascabayar Proses monitoring prabayar dan pascabayar adalah proses upload data hasil monitor pelanggan di lapangan. Proses ini akan menyimpan data berupa koordinat, tanggal monitor, file gambar MCB, keadaan MCB beserta verifikasinya pada tabel RECORD_DLPD_PRABAYAR (pelanggan prabayar) dan RECORD_DLPD_PASCABAYAR (pelanggan pascabayar). Proses ini akan mengupdate status monitoring pelanggan menjadi YES pada kolom status_mon dan mengupdate kolom idmon dengan idmon baru yang telah digenerate ke tabel DLPD_PRABAYAR (pelanggan prabayar) dan DLPD_PASCABAYAR (pelanggan pascabayar). Proses monitoring ini akan memanggil method monitor_pra untuk pelanggan prabayar (lampiran A nomor 16) dan method monitor_pasca untuk pelanggan pascabayar (lampiran A nomor 15). Listing program untuk monitor prabayar akan ditunjukan pada lampiran A nomor 13 dan untuk monitor pascabayar akan ditunjukan pada lampiran A nomor Proses Menyimpan Gambar Proses menyimpan gambar dilakukan dengan menyimpan link pada database dan file gambar akan disimpan disebuah folder yang ada di komputer/server. Proses ini akan memanggil kelas UploadHandler dan method simpanfoto(lihat lampiran

219 191 A) untuk menyimpan link ke database. Listing kelas UploadHandler akan ditunjukan pada lampiran A nomor Proses Approve Prabayar dan Pascabayar Proses approve prabayar dan pascabayar adalah proses menyetujui (memberikan approve) terhadap data pelanggan yang sudah dimonitor. Proses ini akan menyimpan data berupa koordinat, tanggal monitor, file gambar MCB, keadaan MCB beserta verifikasinya dari data hasil monitor terakhir yang akan diapprovepada tabel RECORD_DLPD_PRABAYAR (pelanggan prabayar) dan RECORD_DLPD_PASCABAYAR (pelanggan pascabayar). Proses ini akan mengupdate status approve pelanggan menjadi YES pada kolom status_app dan mengupdate kolom idmon dengan idmon baru yang telah digenerate ke tabel DLPD_PRABAYAR (pelanggan prabayar) dan DLPD_PASCABAYAR (pelanggan pascabayar). Proses approve ini akan memanggil method approve_pra untuk pelanggan prabayar (lampiran A nomor 20) dan method approve_pasca untuk pelanggan pascabayar (lampiran A nomor 21). Listing program untuk approve prabayar akan ditunjukan pada lampiran A nomor 18 dan untuk approve pascabayar akan ditunjukan pada lampiran A nomor Proses Pembatalan Status Monitoring Prabayar dan Pascabayar Proses status monitoring prabayar dan pascabayar adalah proses membatalkan data pelanggan yang sudah dimonitor. Proses ini akan menyimpan data berupa data hasil pembatalan beserta alasan pembatalannya pada tabel RECORD_DLPD_PRABAYAR (pelanggan prabayar) atau pada tabel RECORD_DLPD_PASCABAYAR (pelanggan pascabayar). Proses ini akan mengupdate status monitoring pelanggan menjadi null pada kolom status_mon dan mengupdate kolom idmon dengan idmon pembatalan yang telah digenerate ke tabel DLPD_PRABAYAR (pelanggan prabayar) dan DLPD_PASCABAYAR (pelanggan pascabayar). Proses pembatalan ini akan memanggil method batal_monitor_pra untuk pelanggan prabayar (lampiran A nomor 24) dan method batal_monitor_pasca untuk pelanggan pascabayar (lampiran A nomor 25). Listing program untuk pembatalan status monitoring prabayar akan ditunjukan pada

220 192 lampiran A nomor 22 dan untuk pascabayar akan ditunjukan pada lampiran A nomor Proses Pembatalan Status Approve Prabayar dan Pascabayar Proses status approve prabayar dan pascabayar adalah proses membatalkan data pelanggan yang sudah diapprovesehingga data tersebut harus dimonitoring kembali. Proses ini akan menyimpan data berupa data hasil pembatalan beserta alasan pembatalannya pada tabel RECORD_DLPD_PRABAYAR (pelanggan prabayar) atau pada tabel RECORD_DLPD_PASCABAYAR (pelanggan pascabayar). Proses ini akan mengupdatestatus approvedan status monitoring pelanggan menjadi null pada kolom status_app dan kolom status_monserta mengupdate kolom idmon dengan idmon pembatalan yang telah digenerate ke tabel DLPD_PRABAYAR (pelanggan prabayar) dan DLPD_PASCABAYAR (pelanggan pascabayar). Proses pembatalan ini akan memanggil method batal_approve_pra untuk pelanggan prabayar (lampiran A nomor 28) dan methodbatal_approve_pasca untuk pelanggan pascabayar (lampiran A nomor 29). Listing program untuk pembatalan status approve prabayar akan ditunjukan pada lampiran A nomor 27 dan untuk pascabayar akan ditunjukan pada lampiran A nomor Proses Copy Status Bulan Terakhir Proses copy status bulan terakhir adalah proses mengcopy data hasil monitor dari data pelanggan yang sudah diapprovedan mengubah status monitoring dan approvemenjadi YES serta membuat IDMON untuk data pelanggan tersebut.data pelanggan yang dijadikan master copy adalah data bulan terakhir dari data monitoring pelanggan tersebut. Prosesnya akan memanggil method copystatus_pra untuk pelanggan prabayar (lampiran A nomor 32) dan method copystatus_pasca untuk pelanggan pascabayar (lampiran A nomor 33). Lampiran A nomor 30 akan menunjukan proses copy status dari pelanggan prabayar dan lampiran A nomor 31 untuk pelanggan pascabayar.

221 Proses Cetak Report Monitoring Pelanggan Kwh0 Proses cetak report monitoring pelanggan kwh 0 adalah proses mencetak data pelanggan kwh 0 yang sudah diapprove dalam format pdf. Parameter masukan berupa bulan dan tahun. Laporan yang dicetak dapat dicetak dalam format satu bulan atau beberapa bulan. Lampiran A nomor 34 akan menunjukan listing proses cetak laporan untuk satu bulan. Laporan dalam format beberapa bulan ditunjukan dalam Lampiran A Proses Cetak Report Monitoring Pelanggan Kwh Maks Proses cetak report monitoring pelanggan kwh maks adalah proses mencetak data pelanggan kwh maks yang sudah diapprove dalam format pdf. Parameter masukan berupa bulan dan tahun. Laporan yang dicetak dapat dicetak dalam format satu bulan atau beberapa bulan. Lampiran A nomor 35 akan menunjukan listing proses cetak laporan untuk satu bulan. Laporan dalam format beberapa bulan ditunjukan dalam Lampiran A Proses Cetak Report Monitoring Pelanggan TBT Proses cetak report monitoring pelanggan TBT adalah proses mencetak data pelanggan TBT yang sudah diapprove dalam format pdf. Parameter masukan berupa bulan dan tahun. Laporan yang dicetak dapat dicetak dalam format satu bulan atau beberapa bulan. Lampiran A nomor 36 akan menunjukan listing proses cetak laporan untuk satu bulan. Laporan dalam format beberapa bulan ditunjukan dalam Lampiran A Proses Cetak Report Rekomendasi Monitoring Pelanggan Kwh Maks Naik Daya Proses cetak report rekomendasi monitoring pelanggan kwh maks naik daya merupakan proses mencetak blangko monitoring untuk mengecek pelanggan yang berdasarkan 2 aturan berikut harus menaikan daya listrik yang digunakannya:

222 Terdeteksi sebagai pelanggan dengan rata-rata pemakaian dalam beberapa bulan (biasanya diatas 3 bulan) melebihi kwh maks yang telah ditentukan berdasarkan daya yang digunakan. 2. Jika hasil perhitungan rata-rata pemakaian dibagi dengan daya dibagi dengan 1000 melebihi 720 maka pelanggan. Untuk naik daya satu tingkat dari sebelumnya tidak dapat diputuskan secara manual berdasarkan hasil perhitungan pemakaian beberapa bulan saja. Perlu dilakukan pengecekan berupa monitoring ke lapangan dimana MCB perlu dicek keadaanya, melakukan pengukuran MCB dan pembatas daya menggunakan tang ampere (ampere meter) jika misalnya hasil pengukuran lebih dari 5 ampere (dalam kasus normal) maka diharuskan ganti daya. Verifikasi hasil monitoring seperti MCB sering jeglek juga menjadi salah penanda bahwa daya yang ada sudah tidak mampu. Jadi report yang dihasilkan nanti akan melakukan filter dengan 2 aturan diatas sehinga hasilnya akan memberikan id pelanggan yang harus dicek oleh petugas ke lapangan. Report yang dicetak bisa dimulai berdasarkan bulan dan tahun tertentu atau dalam jangka waktu beberapa bulan. Parameter yang digunakan adalah bulan dan tahun. Berikut ini merupakan implementasi dari cetak report rekomendasi monitoring naik daya dengan parameter bulan dan tahun tunggal yang ditunjukan pada lampiran A nomor 37 sedangkan untuk jangka waktu beberapa bulan dapat dilihat dalam lampiran A Proses Lihat Versi Monitoring Proses lihat versi monitoring dibedakan menjadi 2 yaitu lihat versi sebelumnya dan lihat history monitoring. Lihat versi sebelum adalah melihat detail data monitoring yang diupload dalam versi yang lebih lama dari versi yang ada sekarang. Lihat hitory monitoring adalah melihat history monitoring dalam bentuk tabel yang berisikan keseluruhan monitoring yang dilakukan terhadap data suatu pelanggan. Proses yang akan dicantumkan dibagian ini adalah proses lihat versi monitoring dari data pelanggan pascabayar (untuk prabayar memiliki langkah yang sama dengan pascabayar).

223 195 Proses lihat versi sebelum (ditunjukan pada lampiran A nomor 38) akan memanggil method getdatalistriwayatpelanggan dengan parameter idpel, blth dan idmon (lampiran A nomor 40). Sedangkan untuk proses lihat historymonitoring (ditunjukan pada Lampiran A nomor 39) akan memanggil method getdatalistriwayatpelanggandengan parameter berupa idpel dan blth(lampiran A nomor 41) Implementasi Kelas Implementasi kelas pada sistem ini ditunjukkan pada tabel 4.1: Tabel 4. 1Tabel Implementasi Kelas Nama file kelas Nama file fisik Executable uploadhandler uploadhandler.java uploadhandler.class uploadhandlertbt uploadhandlertbt.java UploadHandlerTBT.class Monitor_control Monitor_control.java Monitor_control.class List_history List_history.java List_history.class Dashboard Dashboard.java Dashboard.class DataPegawai DataPegawai.java DataPegawai.class DatabaseConnection DatabaseConnection.java DatabaseConnection.class DetailPelanggan_DPM DetailPelanggan_DPM. java DetailPelanggan_DPM. class DetailPelanggan_TBT DetailPelanggan_TBT. java DetailPelanggan_TBT. class LihatData LihatData.java LihatData.class LihatData_Rayon LihatData_Rayon.java LihatData_Rayon.class LihatData_TBT LihatData_TBT.java LihatData_TBT.class Rekapitulasi Rekapitulasi.java Rekapitulasi.class Unitup Unitup.java Unitup.class Koneksi Koneksi.java Koneksi.class Naik_daya Naik_daya.java Naik_daya.class Approve Approve.java Approve.class 4.6. Implementasi Basis Data Implementasi basis data pada sistem ini ditunjukkan padatabel 4.2 berikut ini: Tabel 4. 2Tabel Implementasi Basis Data Nama kelas Nama table Nama file DataPegawai USER_LOGIN DataPegawai.class LihatData DLPD_PASCABAYAR LihatData.class

224 196 LihatData_TBT DLPD_PRABAYAR LihatData_TB.class Unitup KODE_UNIT Unitup.class DetailPelanggan_DPM RECORD_DLPD_PASCA BAYAR DetailPelanggan_DPM. Class DetailPelanggan_TBT RECORD_DLPD_PRA BAYAR DetailPelanggan_TBT. class 4.7. Implementasi Antar Muka Implementasi antarmuka (interface) pada sistem yang dibangun ini ditunjukkan pada tabel 4.3 berikut ini: Tabel 4. 3Tabel Implementasi User Interface Antar muka Nama file Executable approve-kwh-0 approve-kwh-0.jsp approve-kwh-0.class approve-kwh-0-rayon approve-kwh-0-rayon.jsp approve-kwh-0- rayon.class approve-kwh-maks approve-kwh-maks.jsp approve-kwh-maks.class approve-kwh-maks-rayon approve-kwh-maksrayon.jsp approve-kwh-maksrayon.class approve-tbt approve-tbt.jsp approve-tbt.class approve-tbt-rayon approve-tbt-rayon.jsp approve-tbt-rayon.class cari-pelanggan cari-pelanggan.jsp cari-pelanggan.class cari-pelanggan_1 cari-pelanggan_1.jsp cari-pelanggan_1.class cari-pelanggan-rayon cari-pelanggan-rayon.jsp cari-pelangganrayon.class cari-pelanggan-rayon_1 cari-pelangganrayon_1.jsp cari-pelangganrayon_1.class cari-pelanggan-tbt cari-pelanggan-tbt.jsp cari-pelanggan-tbt.class cari-pelanggan-tbt_1 cari-pelanggan- TBT_1.jsp cari-pelanggan- TBT_1.class cari-pelanggan-tbtrayon cari-pelanggan-tbtrayon.jsp cari-pelanggan-tbtrayon.class cari-pelanggan-tbtrayon_1 cari-pelanggan-tbtrayon_1.jsp cari-pelanggan-tbtrayon_1.class coba coba.jsp coba.class dashboard-0 dashboard-0.jsp dashboard-0.class dashboard-cari-blth-0 dashboard-cari-blth-0.jsp dashboard-cari-blth- 0.class dashboard-cari-blth-maks dashboard-cari-blthmaks.jsp dashboard-cari-blthmaks.class dashboard-cari-blth-tbt dashboard-cari-blthtbt.jsp dashboard-cari-blthtbt.class dashboard-maks dashboard-maks.jsp dashboard-maks.class dashboard-tbt dashboard-tbt.jsp dashboard-tbt.class

225 197 data-approve-semuakwh-0 data-approve-semuakwh-0.jsp data-approve-semuakwh-0.class data-approve-semuakwh-0-rayon data-approve-semuakwh-0-rayon.jsp data-approve-semuakwh-0-rayon.class data-approve-semuakwh-0-unitup data-approve-semuakwh-0-unitup.jsp data-approve-semuakwh-0-unitup.class data-approve-semuakwh-maks data-approve-semuakwh-maks.jsp data-approve-semuakwh-maks.class data-approve-semuakwh-maks-rayon data-approve-semuakwh-maks-rayon.jsp data-approve-semuakwh-maks-rayon.class data-approve-semuakwh-maks-unitup data-approve-semuakwh-maks-unitup.jsp data-approve-semuakwh-maks-unitup.class data-approve-semua-tbt data-approve-semuatbt.jsp data-approve-semuatbt.class data-approve-semua-tbtrayon data-approve-semua-tbtrayon.jsp data-approve-semua-tbtrayon.class data-approve-semua-tbtunitup data-approve-semua-tbtunitup.jsp data-approve-semua-tbtunitup.class data-belum-approvekwh-0 data-belum-approvekwh-0.jsp data-belum-approvekwh-0.class data-belum-approvekwh-0-blth data-belum-approvekwh-0-blth.jsp data-belum-approvekwh-0-blth.class data-belum-approvekwh-0-blth-rayon data-belum-approvekwh-0-blth-rayon.jsp data-belum-approvekwh-0-blth-rayon.class data-belum-approvekwh-0-rayon data-belum-approvekwh-0-rayon.jsp data-belum-approvekwh-0-rayon.class data-belum-approvekwh-maks data-belum-approvekwh-maks.jsp data-belum-approvekwh-maks.class data-belum-approvekwh-maks-blth data-belum-approvekwh-maks-blth.jsp data-belum-approvekwh-maks-blth.class data-belum-approvekwh-maks-blth-rayon data-belum-approvekwh-maks-blth-rayon.jsp data-belum-approvekwh-maks-blthrayon.class data-belum-approvekwh-maks-rayon data-belum-approvekwh-maks-rayon.jsp data-belum-approvekwh-maks-rayon.class data-belum-approve-tbt data-belum-approvetbt.jsp data-belum-approvetbt.class data-belum-approve-tbtblth data-belum-approve-tbtblth.jsp data-belum-approve-tbtblth.class data-belum-approve-tbtblth-rayon data-belum-approve-tbtblth-rayon.jsp data-belum-approve-tbtblth-rayon.class data-belum-approve-tbtrayon data-belum-approve-tbtrayon.jsp data-belum-approve-tbtrayon.class data-kwh-0 data-kwh-0.jsp data-kwh-0.class data-kwh0-belum-cek data-kwh0-belum-cek.jsp data-kwh0-belumcek.class data-kwh0-belum-cek_1 data-kwh0-belum- data-kwh0-belum- PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI

226 198 cek_1.jsp cek_1.class data-kwh0-belum-cekcari-unitup data-kwh0-belum-cekcari-unitup.jsp data-kwh0-belum-cekcari-unitup.class data-kwh0-belum-cekcari-unitup_1 data-kwh0-belum-cekcari-unitup_1.jsp data-kwh0-belum-cekcari-unitup_1.class data-kwh0-belum-cekrayon data-kwh0-belum-cekrayon.jsp data-kwh0-belum-cekrayon.class data-kwh0-belum-cekrayon_1 data-kwh0-belum-cekrayon_1.jsp data-kwh0-belum-cekrayon_1.class data-kwh0-cari-blth data-kwh0-cari-blth.jsp data-kwh0-cari-blth.class data-kwh0-cari-blthrayon data-kwh0-cari-blthrayon.jsp data-kwh0-cari-blthrayon.class data-kwh-0-cek-approveper-bulan data-kwh-0-cek-approveper-bulan.jsp data-kwh-0-cek-approveper-bulan.class data-kwh-0-cek-approveper-bulan-rayon data-kwh-0-cek-approveper-bulan-rayon.jsp data-kwh-0-cek-approveper-bulan-rayon.class data-kwh-0-cek-bulan data-kwh-0-cek-bulan.jsp data-kwh-0-cekbulan.class data-kwh-0-cek-bulan_1 data-kwh-0-cekbulan_1.jsp data-kwh-0-cekbulan_1.class data-kwh-0-cek-bulan_1- rayon data-kwh-0-cek-bulan_1- rayon.jsp data-kwh-0-cek-bulan_1- rayon.class data-kwh-0-cek-bulanrayon data-kwh-0-cek-bulanrayon.jsp data-kwh-0-cek-bulanrayon.class data-kwh-0-rayon data-kwh-0-rayon.jsp data-kwh-0-rayon.class data-belum-approvekwh-maks data-belum-approvekwh-maks.jsp data-belum-approvekwh-maks.class data-belum-approvekwh-maks-blth data-belum-approvekwh-maks-blth.jsp data-belum-approvekwh-maks-blth.class data-belum-approvekwh-maks-blth-rayon data-belum-approvekwh-maks-blth-rayon.jsp data-belum-approvekwh-maks-blthrayon.class data-belum-approvekwh-maks-rayon data-belum-approvekwh-maks-rayon.jsp data-belum-approvekwh-maks-rayon.class data-belum-approve-tbt data-belum-approvetbt.jsp data-belum-approvetbt.class data-belum-approve-tbtblth data-belum-approve-tbtblth.jsp data-belum-approve-tbtblth.class data-belum-approve-tbt- data-belum-approve-tbt- data-belum-approve-tbt- data-kwh0-belum-cek_1 blth-rayon.class data-belum-approve-tbtrayon.class blth-rayon blth-rayon.jsp data-belum-approve-tbtrayorayon.jsp data-belum-approve-tbt- data-kwh-0 data-kwh-0.jsp data-kwh-0.class data-kwh0-belum-cek data-kwh0-belum-cek.jsp data-kwh0-belumcek.class data-kwh0-belumcek_1.jsp data-kwh0-belumcek_1.class

227 199 data-kwh0-belum-cekcari-unitup data-kwh0-belum-cekcari-unitup.jsp data-kwh0-belum-cekcari-unitup.class data-kwh0-belum-cekcari-unitup_1 data-kwh0-belum-cekcari-unitup_1.jsp data-kwh0-belum-cekcari-unitup_1.class data-kwh0-belum-cekrayon data-kwh0-belum-cekrayon.jsp data-kwh0-belum-cekrayon.class data-kwh0-belum-cekrayon_1 data-kwh0-belum-cekrayon_1.jsp data-kwh0-belum-cekrayon_1.class data-kwh0-cari-blth data-kwh0-cari-blth.jsp data-kwh0-cari-blth.class data-kwh0-cari-blthrayon data-kwh0-cari-blthrayon.jsp data-kwh0-cari-blthrayon.class data-kwh-0-cek-approveper-bulan data-kwh-0-cek-approveper-bulan.jsp data-kwh-0-cek-approveper-bulan.class data-kwh-0-cek-approveper-bulan-rayon data-kwh-0-cek-approveper-bulan-rayon.jsp data-kwh-0-cek-approveper-bulan-rayon.class data-kwh-0-cek-bulan data-kwh-0-cek-bulan.jsp data-kwh-0-cekbulan.class data-kwh-0-cek-bulan_1 data-kwh-0-cekbulan_1.jsp data-kwh-0-cekbulan_1.class data-kwh-0-cek-bulan_1- rayon data-kwh-0-cek-bulan_1- rayon.jsp data-kwh-0-cek-bulan_1- rayon.class data-kwh-0-cek-bulanrayon data-kwh-0-cek-bulanrayon.jsp data-kwh-0-cek-bulanrayon.class data-kwh-0-rayon data-kwh-0-rayon.jsp data-kwh-0-rayon.class data-kwh0-sudah-cek data-kwh0-sudah-cek.jsp data-kwh0-sudahcek.class data-kwh0-sudah-cek_1 data-kwh0-sudahcek_1.jsp data-kwh0-sudahcek_1.class data-kwh0-sudah-cekcari-unitup data-kwh0-sudah-cekcari-unitup.jsp data-kwh0-sudah-cekcari-unitup.class data-kwh0-sudah-cekcari-unitup_1 data-kwh0-sudah-cekcari-unitup_1.jsp data-kwh0-sudah-cekcari-unitup_1.class data-kwh0-sudah-cekrayon data-kwh0-sudah-cekrayon.jsp data-kwh0-sudah-cekrayon.class data-kwh0-sudah-cekrayon_1 data-kwh0-sudah-cekrayon_1.jsp data-kwh0-sudah-cekrayon_1.class data-kwh-maks data-kwh-maks.jsp data-kwh-maks.class data-kwh-maks-belumcek data-kwh-maks-belumcek.jsp data-kwh-maks-belumcek.class data-kwh-maks-belumcek_1 data-kwh-maks-belumcek_1.jsp data-kwh-maks-belumcek_1.class data-kwh-maks-belumcek-cari-unitup data-kwh-maks-belumcek-cari-unitup.jsp data-kwh-maks-belumcek-cari-unitup.class data-kwh-maks-belumcek-cari-unitup_1 data-kwh-maks-belumcek-cari-unitup_1.jsp data-kwh-maks-belumcek-cari-unitup_1.class data-kwh-maks-belumcek-rayon data-kwh-maks-belumcek-rayon.jsp data-kwh-maks-belumcek-rayon.class

228 200 data-kwh-maks-belumcek-rayon_1 data-kwh-maks-belumcek-rayon_1.jsp data-kwh-maks-belumcek-rayon_1.class data-kwh-maks-cari-blth data-kwh-maks-cariblth.jsp data-kwh-maks-cariblth.class data-kwh-maks-cari-blthrayon data-kwh-maks-cari-blthrayon.jsp data-kwh-maks-cari-blthrayon.class data-kwh-maks-cekapprove-per-bulan data-kwh-maks-cekapprove-per-bulan.jsp data-kwh-maks-cekapprove-per-bulan.class data-kwh-maks-cekapprove-per-bulan-rayon data-kwh-maks-cekapprove-per-bulanrayon.jsp data-kwh-maks-cekapprove-per-bulanrayon.class data-kwh-maks-cekbulan_1 data-kwh-maks-cekbulan.jsp data-kwh-maks-cekbulan.class data-kwh-maks-cekbulan_1-rayon data-kwh-maks-cekbulan_1-rayon.jsp data-kwh-maks-cekbulan_1-rayon.class data-kwh-maks-cekbulan-rayon data-kwh-maks-cekbulan-rayon.jsp data-kwh-maks-cekbulan-rayon.class data-kwh-maks-rayon data-kwh-maks-rayon.jsp data-kwh-maksrayon.class data-kwh-maks-sudahcek data-kwh-maks-sudahcek.jsp data-kwh-maks-sudahcek.class data-kwh-maks-sudahcek_1 data-kwh-maks-sudahcek_1.jsp data-kwh-maks-sudahcek_1.class data-kwh-maks-sudahcek-cari-unitup data-kwh-maks-sudahcek-cari-unitup.jsp data-kwh-maks-sudahcek-cari-unitup.class data-kwh-maks-sudahcek-cari-unitup_1 data-kwh-maks-sudahcek-cari-unitup_1.jsp data-kwh-maks-sudahcek-cari-unitup_1.class data-kwh-maks-sudahcek-rayon data-kwh-maks-sudahcek-rayon.jsp data-kwh-maks-sudahcek-rayon.class data-kwh-maks-sudahcek-rayon_1 data-kwh-maks-sudahcek-rayon_1.jsp data-kwh-maks-sudahcek-rayon_1.class data-sudah-approve-kwh- 0 data-sudah-approve-kwh- 0.jsp data-sudah-approve-kwh- 0.class data-sudah-approve-kwh- 0-cek-bulan data-sudah-approve-kwh- 0-cek-bulan.jsp data-sudah-approve-kwh- 0-cek-bulan.class data-sudah-approve-kwh- 0-cek-bulan-rayon data-sudah-approve-kwh- 0-cek-bulan-rayon.jsp data-sudah-approve-kwh- 0-cek-bulan-rayon.class data-sudah-approve-kwh- 0-rayon data-sudah-approve-kwh- 0-rayon.jsp data-sudah-approve-kwh- 0-rayon.class data-sudah-approve-kwhmaks data-sudah-approve-kwhmaks.jsp data-sudah-approve-kwhmaks.class data-sudah-approve-kwhmaks-cek-bulan data-sudah-approve-kwhmaks-cek-bulan.jsp data-sudah-approve-kwhmaks-cek-bulan.class data-sudah-approve-kwhmaks-cek-bulan-rayon data-sudah-approve-kwhmaks-cek-bulan-rayon.jsp data-sudah-approve-kwhmaks-cek-bulanrayon.class data-sudah-approve-kwh- data-sudah-approve-kwh- data-sudah-approve-kwh- PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI

229 201 maks-rayon maks-rayon.jsp maks-rayon.class data-sudah-approve-tbt data-sudah-approvetbt.jsp data-sudah-approvetbt.class data-sudah-approve-tbtblth data-sudah-approve-tbtblth.jsp data-sudah-approve-tbtblth.class data-sudah-approve-tbtblth-rayon data-sudah-approve-tbtblth-rayon.jsp data-sudah-approve-tbtblth-rayon.class data-sudah-approve-tbtrayon data-sudah-approve-tbtrayon.jsp data-sudah-approve-tbtrayon.class data-tbt data-tbt.jsp data-tbt.class data-tbt-belum-cek data-tbt-belum-cek.jsp data-tbt-belum-cek.class data-tbt-belum-cek_1 data-tbt-belum-cek_1.jsp data-tbt-belumcek_1.class data-tbt-belum-cek-cariunitup data-tbt-belum-cek-cariunitup.jsp data-tbt-belum-cek-cariunitup.class data-tbt-belum-cek-cariunitup_1 data-tbt-belum-cek-cariunitup_1.jsp data-tbt-belum-cek-cariunitup_1.class data-tbt-belum-cek-rayon data-tbt-belum-cekrayon.jsp data-tbt-belum-cekrayon.class data-tbt-belum-cekrayon_1 data-tbt-belum-cekrayon_1.jsp data-tbt-belum-cekrayon_1.class data-tbt-cari-blth data-tbt-cari-blth.jsp data-tbt-cari-blth.class data-tbt-cari-blth-rayon data-tbt-cari-blthrayon.jsp data-tbt-cari-blthrayon.class data-tbt-cari-unitup data-tbt-cari-unitup.jsp data-tbt-cariunitup.class data-tbt-cek-approveper-bulan data-tbt-cek-approveper-bulan.jsp data-tbt-cek-approveper-bulan.class data-tbt-cek-approveper-bulan-rayon data-tbt-cek-approveper-bulan-rayon.jsp data-tbt-cek-approveper-bulan-rayon.class data-tbt-cek-bulan data-tbt-cek-bulan.jsp data-tbt-cek-bulan.class data-tbt-cek-bulan_1 data-tbt-cek-bulan_1.jsp data-tbt-cekbulan_1.class data-tbt-cek-bulan-rayon data-tbt-cek-bulanrayon.jsp data-tbt-cek-bulanrayon.class data-tbt-cek-bulanrayon_1 data-tbt-cek-bulanrayon_1.jsp data-tbt-cek-bulanrayon_1.class data-tbt-rayon data-tbt-rayon.jsp data-tbt-rayon.class data-tbt-sudah-cek data-tbt-sudah-cek.jsp data-tbt-sudah-cek.class data-tbt-sudah-cek_1 data-tbt-sudah-cek_1.jsp data-tbt-sudahcek_1.class data-tbt-sudah-cek-cariunitup data-tbt-sudah-cek-cariunitup.jsp data-tbt-sudah-cek-cariunitup.class data-tbt-sudah-cek-cariunitup_1 data-tbt-sudah-cek-cariunitup_1.jsp data-tbt-sudah-cek-cariunitup_1.class data-tbt-sudah-cek-rayon data-tbt-sudah-cekrayon.jsp data-tbt-sudah-cekrayon.class

230 202 data-tbt-sudah-cekrayon_1 data-tbt-sudah-cekrayon_1.jsp data-tbt-sudah-cekrayon_1.class data-tidak-beli-token data-tidak-beli-token.jsp data-tidak-belitoken.class detail-approve-copystatus-tbt detail-approve-copystatus-tbt.jsp detail-approve-copystatus-tbt.class detail-approve-copystatus-tbt-rayon detail-approve-copystatus-tbt-rayon.jsp detail-approve-copystatus-tbt-rayon.class detail-approve-kwh-0 detail-approve-kwh-0.jsp detail-approve-kwh- 0.class detail-approve-kwh-maks detail-approve-kwhmaks.jsp detail-approve-kwhmaks.class detail-approve-kwhmaks-rayon detail-approve-kwhmaks-rayon.jsp detail-approve-kwhmaks-rayon.class detail-approve-tbt detail-approve-tbt.jsp detail-approve-tbt.class detail-approve-tbtrayon detail-approve-tbtrayon.jsp detail-approve-tbtrayon.class detail-copy-status-kwh-0 detail-copy-status-kwh- 0.jsp detail-copy-status-kwh- 0.class detail-copy-status-kwhmaks detail-copy-status-kwhmaks.jsp detail-copy-status-kwhmaks.class detail-copy-status-kwhmaks-rayon detail-copy-status-kwhmaks-rayon.jsp detail-copy-status-kwhmaks-rayon.class detail-kwh-0-sudah-cek detail-kwh-0-sudahcek.jsp detail-kwh-0-sudahcek.class detail-kwh-0-sudah-cekrayon detail-kwh-0-sudah-cekrayon.jsp detail-kwh-0-sudah-cekrayon.class detail-kwh-maks-sudahcek detail-kwh-maks-sudahcek.jsp detail-kwh-maks-sudahcek.class detail-kwh-maks-sudahcek-rayon detail-kwh-maks-sudahcek-rayon.jsp detail-kwh-maks-sudahcek-rayon.class detail-pelanggan detail-pelanggan.jsp detail-pelanggan.class detail-pelanggan_1 detail-pelanggan_1.jsp detail-pelanggan_1.class detail-pelanggan-rayon_1 detail-pelangganrayon_1.jsp detail-pelangganrayon_1.class detail-pelanggan-tbt detail-pelanggan-tbt.jsp detail-pelanggan- TBT.class detail-pelanggan-tbt_1 detail-pelanggan- TBT_1.jsp detail-pelanggan- TBT_1.class detail-pelanggan-tbtrayon detail-pelanggan-tbtrayon.jsp detail-pelanggan-tbtrayon.class detail-pelanggan-tbtrayon_1 detail-pelanggan-tbtrayon_1.jsp detail-pelanggan-tbtrayon_1.class display-foto display-foto.jsp display-foto.class display-foto-copy-status display-foto-copystatus.jsp display-foto-copystatus.class display-foto-copy-status- display-foto-copy-status- display-foto-copy-status-

231 203 tbt tbt.jsp tbt.class display-foto-tbt display-foto-tbt.jsp display-foto-tbt.class edit-user edit-user.jsp edit-user.class form-edit form-edit.jsp form-edit.class gagal-approve-kwh-0 gagal-approve-kwh-0.jsp gagal-approve-kwh- 0.class gagal-approve-kwh-0- rayon gagal-approve-kwh-0- rayon.jsp gagal-approve-kwh-0- rayon.class gagal-approve-kwh-maks gagal-approve-kwhmaks.jsp gagal-approve-kwhmaks.class gagal-approve-kwhmaks-rayon gagal-approve-kwhmaks-rayon.jsp gagal-approve-kwhmaks-rayon.class gagal-approve-tbt gagal-approve-tbt.jsp gagal-approve-tbt.class gagal-approve-tbt-rayon gagal-approve-tbtrayon.jsp gagal-approve-tbtrayon.class Home home.jsp home.class kwh0-belum-cek kwh0-belum-cek.jsp kwh0-belum-cek.class kwh0-belum-cek_1 kwh0-belum-cek_1.jsp kwh0-belum-cek_1.class kwh0-belum-cek-rayon kwh0-belum-cekrayon.jsp kwh0-belum-cekrayon.class kwh0-belum-cek-rayon_1 kwh0-belum-cekrayon_1.jsp kwh0-belum-cekrayon_1.class kwh-0-cek-approve-perbulan kwh-0-cek-approve-perbulan.jsp kwh-0-cek-approve-perbulan.class kwh-0-cek-approve-perbulan-rayon kwh-0-cek-approve-perbulan-rayon.jsp kwh-0-cek-approve-perbulan-rayon.class kwh-0-cek-per-bulan kwh-0-cek-per-bulan.jsp kwh-0-cek-perbulan.class kwh-0-cek-per-bulan_1 kwh-0-cek-perbulan_1.jsp kwh-0-cek-perbulan_1.class kwh-0-cek-per-bulan_1- rayon kwh-0-cek-per-bulan_1- rayon.jsp kwh-0-cek-per-bulan_1- rayon.class kwh-0-cek-per-bulanrayon kwh-0-cek-per-bulanrayon.jsp kwh-0-cek-per-bulanrayon.class kwh-0-detail-approve kwh-0-detail-approve.jsp kwh-0-detailapprove.class kwh-0-detail-approveblth kwh-0-detail-approveblth.jsp kwh-0-detail-approveblth.class kwh-0-detail-approveblth-rayon kwh-0-detail-approveblth-rayon.jsp kwh-0-detail-approveblth-rayon.class kwh-0-detail-approverayon kwh-0-detail-approverayon.jsp kwh-0-detail-approverayon.class kwh0-sudah-cek kwh0-sudah-cek.jsp kwh0-sudah-cek.class kwh0-sudah-cek_1 kwh0-sudah-cek_1.jsp kwh0-sudah-cek_1.class kwh0-sudah-cek-lihat kwh0-sudah-cek-lihat.jsp kwh0-sudah-ceklihat.class kwh0-sudah-cek-lihat_1 kwh0-sudah-cek- kwh0-sudah-cek-

232 204 lihat_1.jsp lihat_1.class kwh0-sudah-cek-lihatrayon kwh0-sudah-cek-lihatrayon.jsp kwh0-sudah-cek-lihatrayon.class kwh0-sudah-cek-lihatrayon_1 kwh0-sudah-cek-lihatrayon_1.jsp kwh0-sudah-cek-lihatrayon_1.class kwh0-sudah-cek-rayon kwh0-sudah-cekrayon.jsp kwh0-sudah-cekrayon.class kwh0-sudah-cek-rayon_1 kwh0-sudah-cekrayon_1.jsp kwh0-sudah-cekrayon_1.class kwh-maks-belum-cek kwh-maks-belum-cek.jsp kwh-maks-belumcek.class kwh-maks-belum-cek_1 kwh-maks-belumcek_1.jsp kwh-maks-belumcek_1.class kwh-maks-belum-cekrayon kwh-maks-belum-cekrayon.jsp kwh-maks-belum-cekrayon.class kwh-maks-belum-cekrayon_1 kwh-maks-belum-cekrayon_1.jsp kwh-maks-belum-cekrayon_1.class kwh-maks-cek-approveper-bulan kwh-maks-cek-approveper-bulan.jsp kwh-maks-cek-approveper-bulan.class kwh-maks-cek-approveper-bulan-rayon kwh-maks-cek-approveper-bulan-rayon.jsp kwh-maks-cek-approveper-bulan-rayon.class kwh-maks-cek-per-bulan kwh-maks-cek-perbulan.jsp kwh-maks-cek-perbulan.class kwh-maks-cek-perbulan_1 kwh-maks-cek-perbulan_1.jsp kwh-maks-cek-perbulan_1.class kwh-maks-cek-perbulan_1-rayon kwh-maks-cek-perbulan_1-rayon.jsp kwh-maks-cek-perbulan_1-rayon.class kwh-maks-cek-per-bulanrayon kwh-maks-cek-per-bulanrayon.jsp kwh-maks-cek-per-bulanrayon.class kwh-maks-detail-approve kwh-maks-detailapprove.jsp kwh-maks-detailapprove.class kwh-maks-detailapprove-blth kwh-maks-detailapprove-blth.jsp kwh-maks-detailapprove-blth.class kwh-maks-detailapprove-blth-rayon kwh-maks-detailapprove-blth-rayon.jsp kwh-maks-detailapprove-blth-rayon.class kwh-maks-detailapprove-rayon kwh-maks-detailapprove-rayon.jsp kwh-maks-detailapprove-rayon.class kwh-maks-sudah-cek kwh-maks-sudah-cek.jsp kwh-maks-sudahcek.class kwh-maks-sudah-ceklihat kwh-maks-sudahcek_1.jsp kwh-maks-sudahcek_1.class kwh-maks-sudah-ceklihat_1 kwh-maks-sudah-ceklihat_1.jsp kwh-maks-sudah-ceklihat_1.class kwh-maks-sudah-ceklihat-rayon kwh-maks-sudah-ceklihat-rayon.jsp kwh-maks-sudah-ceklihat-rayon.class kwh-maks-sudah-ceklihat-rayon_1 kwh-maks-sudah-ceklihat-rayon_1.jsp kwh-maks-sudah-ceklihat-rayon_1.class PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI

233 205 kwh-maks-sudah-cekrayon kwh-maks-sudah-cekrayon.jsp kwh-maks-sudah-cekrayon.class kwh-maks-sudah-cekrayon_1 kwh-maks-sudah-cekrayon_1.jsp kwh-maks-sudah-cekrayon_1.class Login Login.jsp Login.class login-operator login-operator.jsp login-operator.class menubar-admin menubar-admin.jsp menubar-admin.class menubar-admin-00 menubar-admin-00.jsp menubar-admin-00.class menubar-back menubar-back.jsp menubar-back.class menubar-home menubar-home.jsp menubar-home.class menubar-operator menubar-operator.jsp menubar-operator.class menubar-operator-00 menubar-operator-00.jsp menubar-operator- 00.class Newjsp newjsp.jsp newjsp.class newjsp1 newjsp1.jsp newjsp1.class Redirect redirect.jsp redirect.class Result result.jsp result.class tambah-user tambah-user.jsp tambah-user.class tampil-data-approvesemua-kwh-0-unitup tampil-data-approvesemua-kwh-0-unitup.jsp tampil-data-approve- semua-kwh-0- unitup.class tampil-data-approvesemua-kwh-maks-unitup tampil-data-approvesemua-kwh-maksunitup.jsp tampil-data-approvesemua-kwh-maksunitup.class tampil-data-approvesemua-tbt-unitup tampil-data-approvesemua-tbt-unitup.jsp tampil-data-approvesemua-tbt-unitup.class tampil-data-yang-samakwh-0 tampil-data-yang-samakwh-0.jsp tampil-data-yang-samakwh-0.class tampil-data-yang-samakwh-0-rayon tampil-data-yang-samakwh-0-rayon.jsp tampil-data-yang-samakwh-0-rayon.class tampil-data-yang-samakwh-maks tampil-data-yang-samakwh-maks.jsp tampil-data-yang-samakwh-maks.class tampil-data-yang-samakwh-maks-rayon tampil-data-yang-samakwh-maks-rayon.jsp tampil-data-yang-samakwh-maks-rayon.class tampil-data-yang-samatbt tampil-data-yang-samatbt.jsp tampil-data-yang-samatbt.class tampil-data-yang-samatbt-rayon tampil-data-yang-samatbt-rayon.jsp tampil-data-yang-samatbt-rayon.class tbt-belum-cek tbt-belum-cek.jsp tbt-belum-cek.class tbt-belum-cek_1 tbt-belum-cek_1.jsp tbt-belum-cek_1.class tbt-belum-cek-kurang6 tbt-belum-cekkurang6.jsp tbt-belum-cekkurang6.class tbt-belum-cek-kurang6_1 tbt-belum-cekkurang6_1.jsp tbt-belum-cekkurang6_1.class tbt-belum-cek-lebih6 tbt-belum-cek-lebih6.jsp tbt-belum-ceklebih6.class tbt-belum-cek-lebih6_1 tbt-belum-cek- tbt-belum-cek-

234 206 lebih6_1.jsp lebih6_1.class tbt-belum-cek-rayon tbt-belum-cek-rayon.jsp tbt-belum-cek-rayon.class tbt-belum-cek-rayon_1 tbt-belum-cekrayon_1.jsp tbt-belum-cekrayon_1.class tbt-cek-approve-perbulan tbt-cek-approve-perbulan.jsp tbt-cek-approve-perbulan.class tbt-cek-approve-perbulan-rayon tbt-cek-approve-perbulan-rayon.jsp tbt-cek-approve-perbulan-rayon.class tbt-cek-bulan tbt-cek-bulan.jsp tbt-cek-bulan.class tbt-cek-bulan_1 tbt-cek-bulan_1.jsp tbt-cek-bulan_1.class tbt-cek-bulan-rayon tbt-cek-bulan-rayon.jsp tbt-cek-bulan-rayon.class tbt-cek-bulan-rayon_1 tbt-cek-bulan-rayon_1.jsp tbt-cek-bulanrayon_1.class tbt-detail-approve tbt-detail-approve.jsp tbt-detail-approve.class tbt-detail-approve-blth tbt-detail-approveblth.jsp tbt-detail-approveblth.class tbt-detail-approve-blthrayon tbt-detail-approve-blthrayon.jsp tbt-detail-approve-blthrayon.class tbt-detail-approve-rayon tbt-detail-approverayon.jsp tbt-detail-approverayon.class tbt-sudah-cek tbt-sudah-cek.jsp tbt-sudah-cek.class tbt-sudah-cek_1 tbt-sudah-cek_1.jsp tbt-sudah-cek_1.class tbt-sudah-cek-kurang6 tbt-sudah-cekkurang6.jsp tbt-sudah-cekkurang6.class tbt-sudah-cek-kurang6_1 tbt-sudah-cekkurang6_1.jsp tbt-sudah-cekkurang6_1.class tbt-sudah-cek-kurang6- rayon tbt-sudah-cek-kurang6- rayon.jsp tbt-sudah-cek-kurang6- rayon.class tbt-sudah-cek-kurang6- rayon_1 tbt-sudah-cek-kurang6- rayon_1.jsp tbt-sudah-cek-kurang6- rayon_1.class tbt-sudah-cek-lebih6 tbt-sudah-cek-lebih6.jsp tbt-sudah-ceklebih6.class tbt-sudah-cek-lebih6_1 tbt-sudah-ceklebih6_1.jsp tbt-sudah-ceklebih6_1.class tbt-sudah-cek-lebih6- rayon tbt-sudah-cek-lebih6- rayon.jsp tbt-sudah-cek-lebih6- rayon.class tbt-sudah-cek-lebih6- rayon_1 tbt-sudah-cek-lebih6- rayon_1.jsp tbt-sudah-cek-lebih6- rayon_1.class tbt-sudah-cek-lihat tbt-sudah-cek-lihat.jsp tbt-sudah-cek-lihat.class tbt-sudah-cek-lihat_1 tbt-sudah-cek-lihat_1.jsp tbt-sudah-ceklihat_1.class tbt-sudah-cek-lihat-rayon tbt-sudah-cek-lihatrayon.jsp tbt-sudah-cek-lihatrayon.class tbt-sudah-cek-lihatrayon_1 tbt-sudah-cek-lihatrayon_1.jsp tbt-sudah-cek-lihatrayon_1.class tbt-sudah-cek-rayon tbt-sudah-cek-rayon.jsp tbt-sudah-cek-rayon.class tbt-sudah-cek-rayon_1 tbt-sudah-cek- tbt-sudah-cek-

235 207 rayon_1.jsp rayon_1.class user-login user-login.jsp user-login.class history-monitor-pasca history-monitor-pasca.jsp history-monitorpasca.class history-monitor-tbt history-monitor-tbt.jsp history-monitor-tbt.class lihat-versi-sebelum-pasca lihat-versi-sebelumpasca.jsp lihat-versi-sebelumpasca.class lihat-versi-sebelum-tbt lihat-versi-sebelumtbt.jsp lihat-versi-sebelumtbt.class laporan-kwh-maks-naikdaya laporan-kwh-maks-naikdaya.jsp laporan-kwh-maks-naikdaya.class laporan-kwh-0 laporan-kwh-0.jsp laporan-kwh-0.class laporan-kwh-maks laporan-kwh-maks.jsp laporan-kwh-maks.class laporan-tbt laporan-tbt.jsp laporan-tbt.class lihat-data-cetak-kwh-0 lihat-data-cetak-kwh- 0.jsp lihat-data-cetak-kwh- 0.class lihat-data-cetak-kwhmaks lihat-data-cetak-kwhmaks.jsp lihat-data-cetak-kwhmaks.class lihat-data-cetak-tbt lihat-data-cetak-tbt.jsp lihat-data-cetak-tbt.class lihat-data-kwh-maksnaik-daya lihat-data-kwh-maksnaik-daya.jsp lihat-data-kwh-maksnaik-daya.class

236 Implementasi User Interface Gambar 4.13 berikut ini merupakan tampilan halaman home dari sistem monitoring pelanggan ini. Pada bagian atas Halaman home terdapat menubar yang terdiri dari menu HOME, menu OPERATOR untuk login operator, menu ADMIN untuk login administrator, dan menu DASHBOARD untuk melihat info monitoring per-unitup. Gambar 4. 13Interface halaman Home Sistem Login Operator dan Administrator Gambar 4.14 dan 4.15 berikut merupakan tampilan dari halaman login untuk user dengan tipe operator (gambar 4.14) dan administrator (gambar 4.15). User dapat mengisi username dan password kemudian memilih kode unit.

237 209 Gambar 4. 14Interface menu login operator Gambar 4. 15Interface menu login admin Halaman Utama Administrator Tingkat Area Gambar 4.16 merupakan halaman utama untuk admin area jika berhasil login ke sistem. Dalam halaman ini terdapat menu tambah user, lihat data, monitoring, approve, cetak laporan, lihat detail pelanggan, dan logout.

238 210 Gambar Interface halaman Utama Admin Area Menu Lihat Data (gambar 4.17) digunakan untuk melihat data pelanggan monitoring, menu ini terdiri dari 3 submenu yaitu Pelanggan kwh 0, Pelanggan kwh Maks, dan Tidak Beli Token > 3 bulan. Gambar Menu Lihat Data Menu Monitoring (gambar 4.18) digunakan untuk pengoleloaan data monitoring pelanggan. Menu ini terdiri dari 3 submenu yaitu kwh 0, kwh Maks, dan PPTBT >3bln. 3 submenu ini dipecah menjadi masing-masing yaitu Sudah Cek, Belum cek, Cek per-bulan. Gambar Menu Monitoring

239 211 Gambar Menu Approve Menu Approve pada gambar 4.19 diatas digunakan untuk pengoleloaan approvedata monitoring pelanggan. Menu ini terdiri dari 3 submenu yaitu kwh 0, kwh Maks, dan PPTBT >3bln. 3 (tiga) submenu ini dipecah menjadi masingmasing yaitu Sudah Cek, Belum Cek, Cek per-bulan. Gambar 4. 20Menu Cetak Laporan Menu cetak laporan terdiri atas (gambar 4.20) digunakan untuk kelola laporang monitoring pelanggan kwh 0, kwh maks, TBT, dan laporan rekomendasi untuk monitoring naik daya. Gambar 4.21 dibawah ini menunjukan panel untuk logout dari sistem.

240 212 Gambar Panel Logout Halaman Utama Administrator Tingkat Rayon Gambar 4.22 merupakan halaman utama untuk admin rayon jika berhasil login ke sistem. Dalam halaman ini terdapat menu lihat data, monitoring, approve, lihat detail pelanggan, dan logout. Untuk submenu dari menubar pada umumnya sama dengan user admin area. Gambar Halaman utama admin tingkat rayon Halaman Utama Operator Tingkat Area dan Rayon Gambar 4.23 merupakan halaman utama untuk operator area dan rayon jika berhasil login ke sistem. Dalam halaman ini terdapat menu monitoring, lihat detail pelanggan, dan logout. Untuk menubar monitoring pada umumnya sama dengan user admin area. Yang berbeda dari dua tipe user ini adalah data yang bisa diakses

241 213 oleh keduanya. Operator area dapat mengakses semua data diseluruh rayon, sedangkan untuk operator rayon hanya dapat mengakses datanya di rayon tempat diriny terdaftar sebagai user. Gambar 4. 23Halaman utama operator tingkat rayon dan area Halaman Tambah User Gambar 4.24 berikut ini adalah tampilan dari halaman tambah user yang digunakan untuk menambahkan user login ke sistem monitoring ini. Pada halaman ini ditampilkan daftar data user login dan terdapat tombol tambah user (gambar 4.24) untuk tambah user dan edit user (gambar 4.25 dan 4.27) untuk mengubah data login atau mutasi user. Namun untuk mengubah data user terlebih dahulu harus masuk ke halaman cari data user dengan memasukan data password dan username user (gambar 4.26).

242 214 Gambar Halaman daftar user login Gambar Halaman tambah user login

243 215 Gambar Halaman cari data user Gambar Halaman edit data user

244 Lihat Data Monitoring Gambar 4.28 s/d 4.31 berikut ini adalah tampilan dari menu monitoring kwh 0, yang terdiri dari halaman daftar pelanggan kwh 0 sudah cek, belum cek, dan cek perbulan. Untuk tampilan user interface daftar pelanggan kwh Maks sama seperti tampilan kwh 0. Sedangkan untuk data TBT akan ditunjukan pada gambar 4.32 s/d Operator atau admin dapat mencari daftar berdasarkan UNITUP tertentu dengan memilih pada menu dropdown UNITUP kemudian klik tombol CARI. Untuk operator dan admin rayon ditunjukan pada gambar 4.35 s/d Gambar Halaman lihat daftar kwh 0 sudah cek (halaman kwh maks sama)

245 217 Gambar Halaman lihat daftar kwh 0 belum cek (halaman kwh maks sama) Gambar Halaman cari data monitoring perbulan Gambar Halaman daftar monitoring kwh 0 cek perbulan (kwh maks sama)

246 218 Gambar Halaman daftar TBT sudah cek Gambar Halaman daftar TBT belum cek Gambar Halaman daftar TBT cek perbulan

247 219 Gambar Halaman kwh 0 sudah cek untuk user admin dan operator rayon Gambar 4. 36Halaman kwh 0 belum cek untuk user admin dan operator rayon Gambar Halaman kwh 0 cek perbulan untuk user admin dan operator rayon

248 220 Gambar Halaman daftar TBT sudah cek untuk operator dan admin rayon Gambar Halaman daftar TBT sudah cek untuk operator dan admin rayon Gambar Halaman daftar TBT sudah cek untuk operator dan admin rayon

249 Upload data dan ubah data monitoring Gambar 4.41 merupakan tampilan user inteface untuk halaman form upload hasil monitoring pelanggan kwh 0 dan kwh maks. Untuk upload data monitoring TBT ditunjukan pada gambar 4.42 semua user memiliki tampilan interfaceupload data yang sama. User mengisi koordinat, tanggal, verifikasi kemudian mengklik tombol SIMPAN, kemudian mengupload foto dengan mengklik tombol browse untuk memilih foto, untuk menyimpan foto klik UPLOAD. Data hasil monitoring untuk pelanggan tersebut akan disimpan di database. Untuk halaman ubah data akan ditunjukan pada gambar 4.43 dan Gambar Halaman upload data monitoring kwh 0 dan kwh maks

250 222 Gambar 4. 42Halaman upload data monitoring TBT

251 223 Gambar 4. 43Halaman ubahdata monitoring kwh 0 dan kwh maks

252 224 Gambar 4. 44Halaman ubahdata monitoring TBT

253 Lihat Data Approve Gambar 4.45 s/d 4.51 berikut ini adalah tampilan dari menu Approve kwh 0, yang terdiri dari halaman daftar pelanggan kwh 0 sudah Approve, belum cek, cek semua, dan cek Approve perbulan, cek data yang sama dan cek per-unitup untuk admin area. Untuk tampilan user interface daftar pelanggan kwh Maks dan TBT sama seperti tampilan kwh 0. Sedangkan interface admin rayon ditunjukan pada gambar 4.52 s/d Admin dapat mencari daftar berdasarkan bulan dan tahun tertentu dengan memilih pada menu dropdown bulan dan mengisi tahun kemudian klik tombol CARI. Gambar Halaman lihat data sudah approve untuk admin area Gambar 4. 46Halaman lihat data belumapprove untuk admin area

254 226 Gambar Halaman cari data approve bulan dan tahun Gambar Halaman lihat daftar approve perbulan untuk admin area Gambar 4. 49Halaman lihat daftar approvecek semua untuk admin area

255 227 Gambar Halaman cek data yang sama Gambar Halaman lihat data approve per-unitup

256 228 Gambar Halaman lihat daftar sudah approve untuk user admin rayon Gambar Halaman lihat daftar belumapprove untuk user admin rayon

257 229 Gambar 4. 54Halaman lihat daftar cek approveperbulan untuk user admin rayon Approve Dan Batalkan Status Monitoring Dalam halaman yang ditampilkan pada gambar 4.55 form atas petugas dapat memberikan approve terhadap data monitoring pelanggan. Namun, pada gambar 4.55 form bawah merupakan tampilan dari halaman pembatalan status monitoring dari data pelanggan yang sudah dimonitoring ini. User mengisi alasan pembatalan kemudian mengklik tombol BATALKAN. Yang akan ditampilkan pada gambar adalah contoh interface dari pelanggan kwh 0. Untuk pelanggan kwh maks dan TBT halaman interface yang dimiliki sama dengan kwh 0.

258 230 Gambar Halaman approve data dan pembatalan status monitoring pelanggan kwh Lihat Detail Approve dan Pembatalan Status Approve Data yang sudah diapprove (data yang sudah dicek dan disetujui) dapat dilihat kembali detailnya. Data ini pun dapat dibatalkan dengan alasan tertentu. Petugas akan mengisi alasan pembatalan dan kemudian klik tombol BATALKAN (gambar 4.56). Selain itu dalam halaman yang sama terdapat tombol untuk melihat versi sebelum dan history monitoring data pelanggan tersebut. Masing-masing detailnya ditunjukan pada gambar 4.57dan gambar 4.58.

259 231 Gambar Halaman detail approve data pelanggan Gambar Halaman liat detail versi sebelum

260 232 Gambar Halaman history monitoring Lihat Detail Pelanggan Gambar 4.59 dan 4.60 adalah tampilan dari halaman yang cari pelanggan. User dapat melakukan pencarian pelanggan untuk melihat informasi mengenai history monitoring tiap bulannya dari pelanggan tersebut dengan memasukkan id pelanggan atau no meter dari pelanggan tersebut. Kata kunci pencarian dari menu cari pelanggan ini adalah id pelanggan atau no meter (khusus pelanggan prabayar). Gambar Halaman pencarian detail pelanggan

261 233 Gambar Halaman detail pelanggan Dasboard Menu Dasboard terdapat pada menubar home. Gambar 4.61 berikut ini menampilan salah satu dari halaman dashboard, yaitu dasboard kwh 0 yang berisi laporan monitoring pelanggan dari semua UNITUP pada bulan tertentu. Secara default halaman yang ditampilkan akan berisi tabel monitoring yang dilakukan pada bulan terakhir.

262 234 Gambar 4. 61Interface Laporan Monitoring Kwh Cetak Laporan Berikut ini pada gambar 4.62 s/d 4.71 merupakan tampilan halaman interface cetak laporan. Yang ditampilkan pada gambar 4.62 s/d 4.67 merupakan tampilan halaman untuk cetak laporan pelanggan kwh 0 dengan parameter bulan dan tahun tertentu dan dalam format beberapa bulan. Selanjutnya pada gambar 4.68 s/d 4.71 merupakan tampilan dari cetak laporan rekomendasi monitoring naik daya dari pelanggan kwh maks dengan parameter atas bulan dan tahun dan dengan menggunakan 2 parameter yaitu bulan dan tahun untuk batas atas dan bulan dan tahun batas bawah. Petugas dapat memilih untuk mencetak langsung dengan klik tombol CETAK atau melihat data terlebih dahulu dengan klik tombol LIHAT. Untuk melihat lebih jelas dari printout laporan dapat dilihat dalam Lampiran B. Gambar Halaman cetak laporan monitoring kwh 0

263 235 Gambar Halaman daftar pelanggan monitoring perbulan yang akan dicetak Gambar Preview dari cetak laporan monitoring kwh 0 gambar 4.63

264 236 Gambar 4. 65Halaman daftar pelanggan monitoring beberapa bulan yang akan dicetak Gambar 4. 66Preview dari cetak laporan monitoring kwh 0 gambar 4.65 dari

265 237 Gambar Halaman cetak blangko monitoring kwh maks naik daya Gambar 4. 68Halaman daftar pelanggan monitoring kwh maks naik daya dengan parameter batas atas bulan dan tahun tertentu

266 238 Gambar 4. 69Preview cetak dari gambar 4.67 Gambar 4. 70Halaman daftar pelanggan monitoring kwh maks naik daya dengan parameter batas atas dan batas bawah bulan dan tahun tertentu

267 239 Gambar 4. 71Preview cetak laporan rekomendasi monitoring dari gambar 4.70

268 BAB V ANALISA HASIL PENGUJIAN 5.1. Analisa Perangkat Lunak Sistem Monitoring Pelanggan Pascabayar dan Prabayar Tidak Beli Token yang Menerapkan Manajemen Transaksi dibuat untuk membantu proses monitoring pelanggan yang dilakukan oleh bagian Transaksi Energi di PT. PLN (Persero) Area Kuala Kapuas. Monitoring ini berguna untuk melakukan pengecekan terhadap pelanggan pascabayar kwh 0 dan kwh maks serta pelanggan prabayar tidak beli token dengan cara mendatangi rumah pelanggan dan melakukan pengecekan terhadap MCB pelanggan tersebut. Data dari hasil monitoring itu akan disimpan guna ditindak lanjuti lagi oleh petugas di kantor untuk diperiksa keabsahannya. Jika dibandingkan dengan sistem manual sebelumnya dengan menginput dan melakukan cek data satu-satu dalam format excel, sistem monitoring ini akan membuat proses monitoring pelanggan lebih cepat Sistem ini akan berguna untuk menyimpan data hasil monitoring tersebut, dimana petugas akan melihat daftar pelanggan yang harus dimonitor melalui sistem kemudian mengisi data monitoring setelah itu data tersebut akan diupload. Sistem akan menyimpan data monitoring tersebut yang kemudian akan diperiksa lagi untuk diberikan persetujuan (approve). Data monitor yang salah akan diubah kembali dan data yang lama akan tetap disimpan sebagai history monitoring. Pembatalan status monitor dan status approve juga dapat dilakukan melalui sistem ini. Sistem yang ada akan digunakan untuk memonitoring pelanggan yang ada di 6 rayon yang berada di bawah pengawasan area. Karena kemungkinan untuk melakukan pengecekan data baik berupa upload, ubah data, pemberian status approve hingga pembatalannya dapat dilakukan secara bersamaan oleh dua atau lebih petugas, maka sistem dilengkapi dengan manajemen transaksi dimana proses locking akan dijalankan setiap kali ada transaksi untuk mengubah isi 240

269 241 tableyang menyimpan data status monitor dan approve pada row tertentu. Ini akan mencegah data tertumpuk atau kesalahan pengisian data lainnya. Sistem monitoring ini akan diuji coba di PT. PLN (Persero) Area Kuala Kapuas, dimana pengguna sistem adalah staff yang berada disana. Pengujian dilakukan dengan menguji sistem pada bagian lihat data, upload data, ubah data, hingga proses pembatalan status monitor dan approve. Setelah uji sistem, pengguna akan mengisis kuisioner untuk mengetahui sejauh mana sistem ini membantu proses monitoring yang dilakukan disana Analisa Hasil Uji Coba Terhadap Program Untuk menguji manajemen transaksi yang diimplementasikan pada mesin di sistem monitoring ini, maka Penulis melakukan uji coba dengan menjalankan simulasi dimana dilakukan 2 transaksi yang menerapkan metode 2PL (Two Phase Locking). Simulasi ini dilakukan untuk menjawab permasalahan lost of update yang terjadi pada saat upload data, ubah data, approve maupun proses pembatalan yang berlangsung bersamaan. Kedua transaksi yang mengakses row yang sama pada tabel akan diberikan delay untuk membuat agar keduanya saling bertabrakan. Transaksi yang berjalan lebih dulu otomatis akan menjalakan teknik lock untuk menguci row yang diaksesnya agar transaksi lain tidak dapat melakukan write data pada row tersebut. Uji coba ini dilakukan dengan menggunakan 2 browser yaitu Google Chrome untuk transaksi 1 dan Mozilla Firefox untuk transaksi 2. Berikut ini akan dijelaskan dalam subbab dan Pengujian Kasus The Lost of Update Problem Pengujian Terhadap Proses Approve dan Ubah Data Monitoring Pelanggan kwh0 A. Dengan Manajemen Transaksi (2PL) Berikut ini akan dijelaskan simulasi pengujian proses approve data pelanggan kwh 0 (transaksi 1) yang pada saat bersamaan ada transaksi 2 yang akan

270 242 melakukan ubah data monitoring pelanggan tersebut. Transaksi 1 dijalankan oleh admin area dan transaksi 2 dijalankan oleh admin rayon. Gambar 5. 1 Alur proses monitoring pelanggan Aturan untuk mendapatkan IDMON saat mengubah data monitoring adalah belum memiliki status approve artinya kolom status_app di tabel DLPD_PASCBAYAR bernilai null. Ketika transaksi lain (transaksi 1) yang mendahului transaksi ubah data ini melakukan locking terhadap row tersebut, maka transaksi ubah data (transaksi 2) tidak dapat melakukan ubah data karena status approve yang

271 243 sekarang sudah bernilai YES. Untuk diagram simulasi percobaan dapat dilihat pada gambar 5.2. Gambar 5. 2Diagram simulasi percobaan 1

272 244 Untuk langkah simulasi akan ditunjukan pada gambar 5.3 s/d gambar 5.13 berikut ini: 1. Proses melihat daftar pelanggan belum approve pada transaksi 1 ditunjukan pada gambar 5.3 yang ditunjuk anak panah. Data pelanggan yang akan diapprove oleh transaksi 1 adalah data pelanggan dengan idpel Pada saat yang bersamaan transaksi 2 juga akan melakukan ubah data terhadap pelanggan tersebut, ditunjukan pada gambar 5.4 yang ditunjuk oleh anak panah. 2. Transaksi 1 dan 2 akan mengklik tombol pada kolom lihat detail untuk melihat detail monitoring pelanggan tersebut. Pada gambar 5.5 ditunjukan bahwa transaksi 1 akan melakukan approve dengan mengklik tombol APPROVE. Sedangkan transaksi 2 (gambar 5.6) akan mengubah data pelanggan tersebut pada bagian keadaan MCB, koordinat, tanggal monitoring berikut dengan verifikasinya. Gambar 5. 3 Data pelanggan kwh 0 belum apporve (transaksi 1)

273 245 Gambar 5. 4 Data pelanggan kwh 0 sudah cek (transaksi 2) Gambar 5. 5 Halaman lihat detail pelanggan untuk proses approve (transaksi 1)

274 246 Gambar 5. 6 Halaman isian untuk ubah data monitoring pelanggan (transaksi 2) 3. Pada simulasi ini stored procedure untuk approve data akan diberi delay untuk menunggu agar transaksi 2 berjalan bersamaan dengan transaksi 1.Pemanggilan stored procedure ini dimaksudkan untuk mencegah masalah lost of update dimana data yang akan diapprove akan berubah ketika proses ubah data yang berjalan setelahnya (transaksi 2) telah commit terlebih dahulu sebelum proses approve oleh transaksi 1selesai. Pemberian delay ini dilakukan dengan memberi perintah DBMS_LOCK.SLEEP (number in seconds) setelah perintah locking. DMBS_LOCK.SLEEP ini akan membuat delay selama waktu yang ditentukan. Berikut ini pada gambar 5.7 adalah potongan stored procedure approve_pascabayar dengan menggunakan perintah DBMS_LOCK.SLEEP :

275 247 Gambar 5. 7 Prosedur approve_pascabayar dengan DBMS_LOCK.SLEEP selama 20 detik 4. Delay pada gambar 5.7 akan mengakibatkan kedua transaksi bertabrakan sehingga protokol 2PL akan dijalankan. Pada saat transaksi 1 mengklik tombol APPROVE pada gambar 5.5 dibawah ini, maka delay akan dijalankan setelah proses locking berhasil dilakukan pada data pelanggan tersebut. Transaksi 2 juga mengklik tombol UBAH DATA (gambar 5.6) dan akan menjalankan prosedur monitor_pascabayar. 5. Transaksi 1 yang lebih dulu menjalankan lock maka akan diberi kesempatan untuk write pada kolom status_app dan idmon di tabel DLPD_PASCABAYAR. Transaksi 2 yang berjalan setelahnya akan berada dalam status wait. Pada gambar 5.8 dan 5.9 diperlihatkan kedua transaksi masih dalam status menunggu karena delay 30 detik yang diberikan pada prosedur approve_pascabayar pada transaksi 1. Gambar 5. 8 transaksi 1 akan klik tombol APPROVE untuk melakukan approve pada data tersebut

276 248 Gambar 5. 9 Transaksi 2 mengubah data koordinat, verifikasi, tanggal monitor, dan keadaan MCB pada data pelanggan diatas 6. Transaksi 1 berhasil melakukan approve pada data pelanggan tersebut. Hal ini ditunjukan pada gambar 5.10 dimana terdapat pesan bahwa data monitoring telah di-approve. Sedangkan pada transaksi 2 (gambar 5.11) terjadi kegagalan ubah data dimana terdapat pesan data tidak berhasil disimpan,silakan cek kembali. Karena kedua transaksi bertabrakan, transaksi 1 berhasil melakukan lock, sehingga transaksi 2 harus menunggu transaksi 1 untuk melepas lock tersebut. Transaksi 2 dalam status WAIT. Setelah transaksi 1 melepas lock, status approve data tersebut berubah menjadi YES. Pada prosedur monitoring_pascabayar untuk menyimpan data perubahan pelanggan, terdapat fungsi tambah_idmon_pasca yang akan mengecek status monitoring dan approve dari data tersebut. Ada sebuah kondisi (gambar 5.12) dimana jika status approve tidak sama dengan null maka pemberian idmon tidak dapat dilakukan. Karena hasil keluaran fungsi ini bernilai null maka prosedur tidak dapat menjalankan

277 249 perintah lainnya. Prosedur akan melakukan rollback untuk mengembalikan data ke keadaan semula. Inilah yang menyebabkan data tidak dapat diubah setelah diapprove. Halaman pada gambar 5.4 akan dimuat ulang, setelah mengklik tombol kembali data pelangan pada halaman daftar berubah statusnya menjadi sudah diapprove (gambar 5.13). Gambar Transaksi 1 sukses

278 250 Gambar Transaksi 2 gagal Gambar Kutipan fungsi tambah_idmon_pasca jika v_status_app tidak null maka idmon = null

279 251 Gambar Daftar pelanggan kwh 0 sudah cek dimana status monitor idpel berubah menjadi sudah approve B. Tanpa Manajemen Transaksi (2PL) Jika sebelumnya telah dilakukan simulasi untuk menangani masalah lost of update dengan menggunakan method 2 phase locking, maka pada simulasi ini Penulis ini menunjukan kasus transaksi 1 approve data A yang akan disela dengan transaksi 2 ubah data A menjadi B. Tanpa adanya 2PL maka data yang diapprove oleh transaksi 1 bukan lagi data A melainkan data B. Yang dimaksudkan disini adalah id monitoring (idmon) sebagai id untuk referensi data sebelumnya yang berubah ketika approve disela dengan ubah data. Ini akan menyebabkan data menjadi tidak konsisten. 1. Data yang akan diapprove adalah data dengan idpel dengan blth Transaksi 1 akan mengakses halaman kwh-0-detail-approve sedangkan transaksi 2 akan mengakses halaman kwh0-sudah-cek yang ditunjukan pada gambar 5.14 dan 5.15.

280 252 Gambar Transaksi 1 yang akan approve data Gambar Transaksi 2 yang akan mengubah data yang akan diapprove oleh transaksi 1 2. Untuk membuat agar kedua transaksi ini bertabrakan, maka sama seperti ujicoba sebelumnya, delay selama 20 detik akan dibuat untuk transaksi 1 sehingga transaksi 2 dapat menyela. Pada stored procedure approve_pascabayar klausa FOR UPDATE OF akan dihilangkan agar tidak ada proses locking yang terjadi (gambar 5.16).

281 253 Gambar Klausa FOR UPDATE OF dihapus,delay diset 20 detik 3. Transaksi 1 akan mengklik tombol APPROVEdan akan terjadi delay selama 20 detik, disisi lain transaksi 2 juga mengubah data dan mengklik tombol UBAH. Namun, karena tidak ada delay yang dipasang pada transaksi 2 maka transaksi berjalan lancar dan data berhasil disimpan (gambar 5.17). Pada pembahasan A seharusnya proses ubah data ini tidak boleh commit (berhasil) karena status approve untuk data tersebut telah berubah menjadi YES yang artinya ubah data tidak diperkenankan lagi. Gambar 5. 17Transaksi 2 berhasil melakukan ubah data 4. Transaksi 1 masih menunggu, setelah delay selesai maka dbms akan aktif kembali, transaksi 1 berhasil dan muncul pesan data berhasil diapprove (gambar 5.18). Namun, setelah melihat data detail approve-nya Petugas akan menyadari bahwa detail monitoring dari data yang diapprove telah berubah (itulah maksud dari data A yang diapprove, berubah menjadi data B). Detail approve dapat dilihat pada gambar 5.19.

282 254 Gambar 5. 18Transaksi ubah data berhasil dilakukan Gambar Detail monitoring telah diubah (transaksi 2) 5. Jika melihat history monitoring dari pelanggan tersebut akan diketahui bahwa ada transaksi sebelumnya yang telah berhasil melakukan ubah data sebelum transaksi approve berhasil commit (gambar 5.20). Jika melihat dari detail approve, Petugas yang melakukan transaksi 1 akan menyadari bahwa data yang diapprove telah berubah (gambar 5.21).

283 255 Gambar 5. 20Data history monitoring yang menjadi tidak konsisten Gambar Detail approve transaksi 1 telah berubah, idmon versi sebelum seharusnya MON

284 Pengujian Terhadap Proses Batalkan Status Monitoring dan Proses Approve Data Pelanggan kwh 0 A. Dengan Manajemen Transaksi (2PL) Proses ujicoba pada bagian ini pada umumnya sama seperti bagian sebelumnya, masalah concurrency control yang ingin dijawab dalam simulasi ini adalah pencegahan lost of update jika 2 buah transaksi berjalan bersamaan dengan mengakses data yang sama. Berikut ini pada gambar 2.22 akan ditunjukan diagram skenario pengujian ini. Gambar 5. 22Diagram simulasi percobaan 2

285 257 Transaksi 1 adalah proses membatalkan status monitoring dan transaksi 2 adalah proses approve data monitoring. Seperti sudah dijelaskan sebelumnya, untuk melakukan approve data, seorang pelanggan harus memenuhi syarat bahwa data monitoringnya harus berstatus sudah monitor. Jika pembatalan pada data pelanggan tersebut lebih dulu dilakukan maka data pelanggan tidak lagi memiliki status monitoring. Itu artinya proses approve tidak dapat dilakukan. Jika sebaliknya terjadi, proses approve mendahului (mendapatkan lock lebih dulu) proses pembatalan status monitoring maka data tidak dapat dibatalkan oleh transaksi 1. Gambar 5.23 akan menunjukan gambar dari data pelanggan yang akan digunakan dalam uji coba kali ini. Idpel memiliki status sudah dimonitor, oleh transaksi 1 datanya akan dibatalkan untuk dimonitoring kembali (gambar 5.24). Sedangkan transaksi 2 pada gambar 5.25 akan melakukan approve terhadap data ini. Transaksi 1 berhasil melakukan lock terhadap data pelanggan tersebut, transaksi 2 harus menunggu hingga transaksi 1 melepaskan locknya. Prosedur batal_monitor_pasca pada transaksi 1 menerapkan DBMS_LOCK.SLEEP selama 30 detik. Hal ini berarti transaksi 2 yang dijalankan setelahnya akan bertabrakan dengan transaksi 1. Hasil dari transaksi 1 dapat dilihat pada gambar 5.26 dimana pembatalan status monitoring berhasil dilakukan, data pelanggan tersebut tidak memiliki status monitoring lagi. Transaksi 2 pada gambar 5.27 mengalami kegagalan sehingga harus rollback karena status monitoring pada data pelanggan menjadi null karena transaksi 1, sehingga data tidak dapat diapprove. Gambar 5.28 menunjukan daftar pelanggan belum cek dimana data pelanggan tersebut berada dalam daftar belum cek karena status monitoringnya yang null.

286 258 Gambar Daftar pelanggan kwh 0 belum approve Gambar Halaman detail approve pelanggan pada transaksi 1

287 259 Gambar Transaksi 2 yang akan approve data pelanggan diatas Gambar Transaksi 1 berhasil dilakukan, status monitoring pelanggan menjadi null

288 260 Gambar 5. 27Transaksi 2 gagal dilakukan sehingga harus rollback Gambar Data pelanggan berstatus belum monitoring Proses lain yang menerapkan proses seperti dijelaskan diatas adalah proses batalkan status approve yang jika dijalankan tidak dapat membuat transaksi lain berjalan bersamaan dengannya (seperti approve data). Untuk proses upload data yang berjalan bersamaan atau upload data yang berjalan bersamaan dengan ubah data, mekanisme yang terjadi adalah transaksi upload dan ubah yang lebih dulu melakukan locking akan disimpan datanya terlebih dahulu, baru setelah itu proses lain yang mengikutinya. Untuk mekanisme 2 transaksi yang melakukan approve data yang sama secara bersamaan, transaksi yang lebih dahulu mendapatkan lock

289 261 akan mendapatkan hak untuk melakukan approve, transaksi yang mengikuti selanjutnya tidak dapat melakukan approve tersebut. Tabel 5.1 dan 5.2 merupakan tabel pengujian yang menggambarkan proses terjadinya protokol 2PL yang dijalankan pada saat transaksi 1 dan transaksi 2 berjalan. Tabel 5.3 dan 5.4 merupakan tabel pengujian yang menggambarkan proses terjadinya transaksi 1 dan 2 tanpa protokol 2PL. B. Tanpa Manajemen Transaksi (2PL) Jika sebelumnya telah dilakukan simulasi untuk menangani masalah lost of update dengan menggunakan method 2 phase locking, maka pada simulasi ini Penulis menunjukan kasus transaksi 1 membatalkan status monitoring yang akan disela dengan transaksi 2 yang akan melakukan approve data yang sama. Tanpa adanya 2PL maka batalkan status monitoring yang disela dengan proses approve akan menyebabkan data mendapatkan idmon approve terlebih dahulu, sedangkan setelah itu data baru bisa dibatalkan sehingga status approve bernilai YES dan status monitornya bernilai null.hal ini akan menyebabkan data menjadi tidak konsisten. 1. Transaksi 1 akan melakukan pembatalan status monitoring pada gambar Transaksi 2 akan melakukan approve data yang sama (gambar 5.30). Transaksi 1 akan diberikan delay selama 20 detik (gambar 5.31)

290 262 Gambar Transaksi 1 yang akan melakukan pembatalan monitoring Gambar Transaksi 2 yang akan melakukan approve monitoring Gambar kutipan stored procedure batal_monitor_pasca dimana delay diset 20 detik, klausa FOR UPDATE OF ditutup

291 Karena terjadidelay, transaksi 1 tidak dapat langsung mengubah status monitor menjadi null. Pada saat yang bersamaan transaksi 2 berhasil melakukan approve sehingga membuat status approve bernilai YES (gambar 5.32). Setelah delay berakhir, data tetap dapat dibatalkan (gambar 5.33). Berdasarkan aturan monitoring, data pelanggan tidak dapat diapprove jika status monitornya bernilai null maupun sebaliknya. Disinilah terjadinya data yang tidak konsisten yang ditunjukan pada gambar 5.34, 5.35, dan Gambar Transaksi 2berhasil dilakukan, status approve bernilai null

292 264 Gambar Transaksi 1 berhasil, karena status approve yang dibaca sebelum delay adalah null maka data ini dapat dibatalkan. Namun, pada kenyataanya setelagh data dibaca kembali status approve menjadi YES.... Gambar 5. 34Pada daftar pelanggan sudah approve, data pelanggan memiliki status approve dengan tanda silang, ini terjadi karena syarat status monitor tidak sama dengan null tidak terpenuhi

293 265 Gambar 5. 35Pada data history monitoring pelanggan tersebut, referensi idmon versi sebelum menjadi tidak konsisten. Ada 2 record yang memiliki versi sebelum yang sama. Gambar 5. 36Status monitoring pelanggan dengan idpel untuk blth adalah null sedangkan status approve adalah YES.