ABSTRACT
DIKA AGUS SATRIA. Power Monitoring System for Network Operations Center. Supervised by HENDRA RAHMAWAN.
Electricity power events such as power goes off and on can affect performance of a computer, especially a server. Often such power events occurred and noticed, but ignored. Computer intensive activity like servers in Network Operations Center (NOC) should has a power monitoring software. So, an administrator of NOC will have log of power events. Administrator should be noticed also when power goes off.
Network Operations Center Power Monitor (NOCPM) is developed to meet this needs. It was developed using extreme programming (XP) methodology with object oriented approach. NOCPM evolved iteration by iteration in XP lifecycle. Each iteration will be explained using ICONIX process. NOCPM consists of two subsystems: Watch Tower and Data Viewer. Watch Tower concerns about monitoring certain serial port and make log for each data that received. A short message alert for each data that received from serial port will be sent also to an administrator. Data Viewer acts as data log visualizer and make graph from data log.
PENDAHULUAN Latar Belakang
Kejadian pemadaman listrik dapat mengganggu kegiatan yang berhubungan dengan komputer. Kejadian pemadaman listrik tidak dapat diprediksi. Parahnya, dalam sehari bisa saja terjadi beberapa kali pemadaman listrik. Begitu juga apabila dilihat dalam rentang bulanan dan tahunan. Semua kejadian pemadaman listrik tersebut tidak terpantau.
Oleh karena itu, dibutuhkan suatu aplikasi yang dapat memonitor kejadian pemadaman listrik dan kapan listrik kembali menyala. Saat listrik padam, suplai energi akan digantikan oleh Uninterruptible Power Supply (UPS). UPS ada yang sudah dipaketkan dengan aplikasi monitoring sendiri dan ada juga yang tidak memiliki aplikasi monitoring tersebut.
Beberapa dari aplikasi tersebut, misalnya WinPower1, pada dasarnya memiliki fitur pencatatan kejadian pemadaman listrik. Pencatatan tersebut berupa tabel log kejadian pemadaman listrik. Di antara aplikasi tersebut ada yang memiliki fitur pemberitahuan via pesan singkat bahwa telah terjadi pemadaman listrik.
Contoh aplikasi serupa yang lain adalah Spiceworks2. Spiceworks memiliki fitur
manajemen UPS seperti memonitor level baterai. Spiceworks juga memiliki fitur visualisasi log kejadian pemadaman listrik.
Penelitian ini mencoba untuk membuat suatu perangkat lunak yang menggabungkan fitur-fitur seperti yang dijelaskan sebelumnya. Selain itu, pada penelitian ini data log yang dihasilkan akan divisualisasikan dalam bentuk grafik sehingga lebih mudah dibaca dibandingkan dengan melihat tabel log.
Ide awalnya, aplikasi ini akan dipasang pada Network Operations Center (NOC) seperti ruang server. Listrik di NOC dimonitor 24 jam sehari, sehingga akan tercatat seberapa sering terjadinya gangguan listrik. Selain NOC, aplikasi ini juga dapat dipasang pada komputer biasa untuk monitoring listrik rumahan.
Tujuan
Tujuan penelitian ini adalah membuat suatu perangkat lunak yang dapat memantau pemadaman listrik di ruang NOC. Perangkat lunak ini diharapkan juga dapat memberikan
alert atau peringatan via pesan singkat untuk setiap kejadian pemadaman listrik kepada administrator.
Ruang Lingkup
Pada penelitian ini dilakukan pembatasan masalah pada:
pengembangan suatu perangkat lunak yang dapat membaca data dari serial port tertentu. Port serial ini terhubung ke suatu alat yang dapat mendeteksi keadaan listrik (padam atau hidup). Jika listrik padam alat tersebut mengirimkan sinyal 0 ke serial port, sebaliknya jika listrik kembali menyala maka yang dikirim adalah sinyal 1
penelitian ini berfokus pada pengembangan perangkat lunak untuk menangani kejadian setelah data/sinyal diterima oleh serial port. alat yang dapat mendeteksi pemadaman listrik tidak menjadi fokus dalam penelitian ini
pembuatan log untuk setiap data yang diterima dari serial port. Log yang terkumpul divisualisasikan dalam bentuk grafik
perangkat lunak ini dapat mengirimkan pesan singkat ketika terjadi pemadaman listrik dan ketika listrik kembali menyala. Manfaat Penelitian
Memberikan informasi tentang keadaan kelistrikan di ruang NOC. Administrator dapat mengetahui tentang pemadaman listrik di ruang NOC saat terjadi gangguan listrik. Administrator juga memiliki data log kejadian kelistrikan pada NOC dan dapat menampilkannya dalam bentuk grafik.
TINJAUAN PUSTAKA Sistem Monitoring
Sistem monitoring merupakan proses untuk mengumpulkan data dari berbagai sumber daya. Biasanya data yang dikumpulkan adalah data real time. Aksi yang terjadi dalam sebuah sistem monitoring berbentuk service, yaitu proses yang berjalan terus-menerus pada waktu interval tertentu (Ohara 2005).
Komunikasi Serial
PENDAHULUAN Latar Belakang
Kejadian pemadaman listrik dapat mengganggu kegiatan yang berhubungan dengan komputer. Kejadian pemadaman listrik tidak dapat diprediksi. Parahnya, dalam sehari bisa saja terjadi beberapa kali pemadaman listrik. Begitu juga apabila dilihat dalam rentang bulanan dan tahunan. Semua kejadian pemadaman listrik tersebut tidak terpantau.
Oleh karena itu, dibutuhkan suatu aplikasi yang dapat memonitor kejadian pemadaman listrik dan kapan listrik kembali menyala. Saat listrik padam, suplai energi akan digantikan oleh Uninterruptible Power Supply (UPS). UPS ada yang sudah dipaketkan dengan aplikasi monitoring sendiri dan ada juga yang tidak memiliki aplikasi monitoring tersebut.
Beberapa dari aplikasi tersebut, misalnya WinPower1, pada dasarnya memiliki fitur pencatatan kejadian pemadaman listrik. Pencatatan tersebut berupa tabel log kejadian pemadaman listrik. Di antara aplikasi tersebut ada yang memiliki fitur pemberitahuan via pesan singkat bahwa telah terjadi pemadaman listrik.
Contoh aplikasi serupa yang lain adalah Spiceworks2. Spiceworks memiliki fitur
manajemen UPS seperti memonitor level baterai. Spiceworks juga memiliki fitur visualisasi log kejadian pemadaman listrik.
Penelitian ini mencoba untuk membuat suatu perangkat lunak yang menggabungkan fitur-fitur seperti yang dijelaskan sebelumnya. Selain itu, pada penelitian ini data log yang dihasilkan akan divisualisasikan dalam bentuk grafik sehingga lebih mudah dibaca dibandingkan dengan melihat tabel log.
Ide awalnya, aplikasi ini akan dipasang pada Network Operations Center (NOC) seperti ruang server. Listrik di NOC dimonitor 24 jam sehari, sehingga akan tercatat seberapa sering terjadinya gangguan listrik. Selain NOC, aplikasi ini juga dapat dipasang pada komputer biasa untuk monitoring listrik rumahan.
Tujuan
Tujuan penelitian ini adalah membuat suatu perangkat lunak yang dapat memantau pemadaman listrik di ruang NOC. Perangkat lunak ini diharapkan juga dapat memberikan
1
http://www.ups-software-download.com/winpower.htm
2http://www.spiceworks.com
alert atau peringatan via pesan singkat untuk setiap kejadian pemadaman listrik kepada administrator.
Ruang Lingkup
Pada penelitian ini dilakukan pembatasan masalah pada:
pengembangan suatu perangkat lunak yang dapat membaca data dari serial port tertentu. Port serial ini terhubung ke suatu alat yang dapat mendeteksi keadaan listrik (padam atau hidup). Jika listrik padam alat tersebut mengirimkan sinyal 0 ke serial port, sebaliknya jika listrik kembali menyala maka yang dikirim adalah sinyal 1
penelitian ini berfokus pada pengembangan perangkat lunak untuk menangani kejadian setelah data/sinyal diterima oleh serial port. alat yang dapat mendeteksi pemadaman listrik tidak menjadi fokus dalam penelitian ini
pembuatan log untuk setiap data yang diterima dari serial port. Log yang terkumpul divisualisasikan dalam bentuk grafik
perangkat lunak ini dapat mengirimkan pesan singkat ketika terjadi pemadaman listrik dan ketika listrik kembali menyala. Manfaat Penelitian
Memberikan informasi tentang keadaan kelistrikan di ruang NOC. Administrator dapat mengetahui tentang pemadaman listrik di ruang NOC saat terjadi gangguan listrik. Administrator juga memiliki data log kejadian kelistrikan pada NOC dan dapat menampilkannya dalam bentuk grafik.
TINJAUAN PUSTAKA Sistem Monitoring
Sistem monitoring merupakan proses untuk mengumpulkan data dari berbagai sumber daya. Biasanya data yang dikumpulkan adalah data real time. Aksi yang terjadi dalam sebuah sistem monitoring berbentuk service, yaitu proses yang berjalan terus-menerus pada waktu interval tertentu (Ohara 2005).
Komunikasi Serial
dan komunikasi dengan fiber optic. Komunikasi dengan menggunakan kabel terbagi atas teknologi komunikasi analog dan digital.
Teknologi komunikasi modern banyak menggunakan transfer data digital. Secara umum, komunikasi digital pada teknologi komputer dapat dikategorikan atas dua jenis: komunikasi paralel dan komunikasi serial.
Komunikasi paralel dapat melakukan pertukaran data antara dua perangkat secara paralel, artinya sejumlah bit data (8 bit, 16 bit, atau 32 bit data) dapat ditransfer secara bersamaan. Pada komunikasi paralel, kedua perangkat harus terhubung melalui beberapa kawat. Hubungan antara kawat dengan data yang dikirim adalah satu ke satu, artinya satu bit data “berjalan” pada satu kabel.
Komunikasi serial melakukan pertukaran data antara dua perangkat dengan cara mengirim data satu per satu seperti sebuah rangkaian dengan menggunakan satu kawat. Komunikasi serial membutuhkan jumlah kawat yang lebih sedikit sehingga koneksi perangkat kerasnya lebih sederhana. Diagram komunikasi pararel dan serial ditunjukkan oleh Gambar 1.
Gambar 1 (a) komunikasi paralel dan (b) serial (Bai 2005).
Pada Gambar 1 terlihat bahwa paralel port (a) menggunakan kawat lebih banyak. Hal ini membuat interface paralel lebih rumit. Keuntungannya, dari banyak kawat tersebut akan didapatkan kecepatan transfer data yang cepat. Kecepatan ini didapat karena semua kabel memproses data secara bersamaan. Serial port (b) hanya menggunakan satu kawat untuk mentransfer data. Data dikirim satu per satu, artinya dalam satu waktu hanya satu bit data yang ditransfer dari device 1 ke device 2. Oleh karena itu, komunikasi serial lebih lambat daripada komunikasi paralel.
Beberapa contoh komunikasi serial adalah
parameter dalam komunikasi serial di antaranya baud rate, parity, stop bits, dan data bits. Baud rate menyatakan kecepatan transmisi (biasanya dalam satuan bps). Parity bit digunakan untuk pengecekan error yang terjadi saat pengiriman dan penerimaan data. Stop bits digunakan untuk menyatakan selesainya satu kali pengiriman data. Data bits menyatakan jumlah bit (7 atau 8) yang ditransmisikan untuk setiap unit data (Bai 2005).
JpGraph
JpGraph adalah library yang digunakan untuk membuat grafik berorientasi objek untuk PHP versi 5.1 atau yang lebih baru. Library ini sepenuhnya ditulis dalam PHP dan siap dipakai dalam skrip PHP apapun. JpGraph menyediakan banyak jenis grafik yang bisa dibentuk, di antaranya grafik batang, grafik garis, pie chart, scatter, impulse, baloon, radar, dan lain-lain (JpGraph Documentation).
Gammu
Gammu adalah sebuah proyek yang menyediakan layer abstrak untuk mengakses telepon seluler. Gammu dapat digunakan pada sebagian besar merek telepon seluler, terutama telepon seluler berbasis AT. Gammu dapat digunakan untuk (The Gammu Manual):
membuat, menangani, dan membuat daftar panggilan
pengiriman, backup, dan pengambilan (retrieval) SMS
pengambilan MMS
melihat daftar kontak pada telepon seluler dan dapat melakukan export dan import kontak
mengakses informasi jaringan dan jenis telepon selular
menyediakan akses kepada file system telepon selular.
Extreme Programming (XP)
XP merupakan turunan dari System Development Life Cycle (SDLC) untuk kategori agile development (Dennis 2006).
Menurut Shore dan Warden (2008), metode XP tidak melakukan tahap requirements, desain, dan testing serta dokumentasi formal untuk tiap tahapan tersebut secara terpisah. Akan tetapi, setiap tahapan tersebut dikerjakan secara tumpang tindih. Artinya, jika programmer berada pada tahap desain dia bisa kembali ke tahap analisis untuk melakukan koreksi terhadap hasil pada tahap analisis.
Perangkat lunak yang dikembangkan dengan motode XP akan mengalami iterasi. Untuk setiap iterasi telah ditetapkan user stories/use cases/requirements yang mana yang akan diimplementasikan. Gambar 2 menjelaskan tentang siklus hidup perangkat lunak yang dikembangkan dengan motode XP.
Gambar 2 XP lifecycle (Shore & Warden 2008).
Proses ICONIX
Proses ICONIX adalah pemodelan objek minimum yang cocok untuk agile development. Dengan kata lain, proses ICONIX adalah inti dari proses pemodelan objek. Proses ICONIX merupakan sebuah subset inti praktis dari Unified Modeling Language (UML) (Rosenberg 2005). Bagian UML yang juga menjadi bagian proses ICONIX dijelaskan oleh Gambar 3.
Gambar 3 Proses ICONIX merupakan subset inti dari UML (Rosenberg et al. 2005).
Domain Model
Domain model adalah pola/artefak kolaboratif. Domain model selalu disempurnakan dan diperbarui sepanjang proyek, sehingga domain model selalu mencerminkan pemahaman terhadap masalah yang dihadapi. Dibuatnya domain model bertujuan untuk memecahkan masalah miskomunikasi pada proyek dengan cara membuat kosakata umum yang memetakan ruang masalah (Rosenberg & Stephens 2007).
Dalam prakteknya, domain model merupakan diagram kelas yang sederhana. Pada domain model juga terdapat garis yang menghubungkan kosakata yang satu dengan kosakata lainnya. Garis tersebut menggambarkan bagaimana kosakata (kelas) tersebut berhubungan dengan kosakata lainnya.
Domain model dibuat pada permulaan pengerjaan proyek untuk menggambarkan dan menyamakan pemahamanan awal setiap orang yang terlibat dalam proyek tersebut. Domain model yang dibuat pada tahap awal boleh saja tidak sempurna. Oleh karena itu, domain model akan selalu berkembang mengikuti perkembangan pemahaman orang-orang yang terlibat dalam proyek tersebut.
Diagram Use Cases
Use cases dibuat setelah domain model ada. Use cases menggambarkan cara terstruktur dalam menangkap behavioral requirements dari sebuah sistem, sehingga sebuah rancangan/desain sistem dapat dibuat dari use cases tersebut. Use cases menjawab pertanyaan fundamental mengenai “apa yang bisa dilakukan pengguna terhadap sistem? Apa user experiences-nya?” (Rosenberg & Stephens 2007).
Use cases dapat dibuat dari functional requirements, wawancara dengan pengguna, dan storyboard (Rosenberg & Stephens 2007). Diagram Robustness
Diagram robustness adalah gambar objek dari use cases. Diagram robustness dan teks dari use cases harus sama persis sehingga diagram robustness memaksa pengembang untuk menggunakan teks use cases pada objek. Dibuatnya diagram robustness memastikan use cases dibuat dalam konteks domain model sehingga semua kosakata (kata benda dan frasa nomina) yang ada pada domain model harus digunakan secara langsung pada teks use cases (Rosenberg & Stephens 2007).
It
Masih menurut Rosenberg dan Stephens (2007), diagram robustness menjembatani tahap analisis dan desain. Jika tahap analisis (use cases) dianggap sebagai “apa” dan desain sebagai “bagaimana”, maka analisis robustness merupakan desain sistem yang sangat awal. Pada tahap ini dibuat asumsi awal tentang desain. Jadi, tahap ini dapat menjadi bagian dari tahap analisis dan dapat menjadi bagian dari tahap desain.
Diagram robustness merupakan representasi bergambar dari perilaku (behavior) yang dideskripsikan oleh use cases. Diagram robustness menunjukkan perilaku dari kelas-kelas dan perilaku dari perangkat lunak. Pada diagram ini tidak digambarkan kelas mana yang bertanggung jawab terhadap perilaku tertentu. Walaupun demikian, diagram robustness dapat dibaca seperti diagram aktivitas (activity diagram) atau sebagai sebuah flowchart dalam arti suatu objek “berbicara” dengan objek lainnya. Simbol-simbol yang terlibat dalam diagram robustness ditunjukkan oleh Gambar 4.
Gambar 4 Simbol-simbol pada diagram robustness (Rosenberg & Stephens 2007).
Boundary object adalah antarmuka antara sistem dengan segala sesuatu di luar sistem. Contohnya adalah layar atau halaman web. Entity object merupakan kelas-kelas dari domain model. Controller adalah penghubung antara boundary dan entity object. Aturan-aturan dalam menggambar diagram robustness adalah (Rosenberg & Stephens 2007):
1. objek (noun) dapat berbicara kepada controller (verb) dan sebaliknya
2. objek tidak dapat berbicara kepada objek lainnya
3. controller dapat berbicara kepada controller lainnya.
Diagram Sequence
Pada tahap ini desain awal sistem telah ada (dari diagram robustness). Selain itu, pada tahap ini use cases sudah lengkap, benar, detail, dan eksplisit. Jika pada tahap sebelumnya adalah proses menemukan kelas-kelas yang terlibat,
proses mengalokasikan perilaku (behavior) kepada kelas-kelas yang sudah ada. Pada tahap sebelumnya dibuat tebakan bagaimana satu kelas berinteraksi dengan kelas lainnya, maka pada tahap ini pernyataan tadi akan dibuat lebih akurat dan benar dan membentuknya menjadi desain yang mendetail (Rosenberg & Stephens 2007).
METODE PENELITIAN
Metode pengembangan perangkat lunak yang dipakai dalam penelitian ini adalah extreme programming (XP). Alur penelitian ini mengikuti tahapan yang dijelaskan oleh Gambar 2. Untuk menjelaskan pemodelannya akan digunakan proses ICONIX.
Perencanaan
Perencanaan membahas tentang tujuan dikembangkannya perangkat lunak. Selain itu juga dibuat user stories, dan release plan (Shore & Warden 2008).
Analisis
Pada tahap ini ditentukan requirements apa saja yang dibutuhkan oleh perangkat lunak (Shore & Warden 2008). Tahap ini dimodelkan oleh domain modelling, use case, dan robustness diagram (Rosenberg & Stephens 2007).
Desain
Tahap Desain berfokus pada cara sistem beroperasi dalam hal perangkat keras, perangkat lunak, dan infrastruktur network. Desain juga berfokus pada user interface. Selain itu, tahap ini juga berfokus pada program, database, dan file yang akan dibutuhkan (Dennis 2006). Tahap ini akan dimodelkan oleh sequence diagram (Rosenberg & Stephens 2007).
Implementasi
Berdasarkan hasil desain yang telah dibuat, maka langkah selanjutnya adalah mengimplementasikannya menjadi kode program (Shore & Warden 2008).
Pengujian
Masih menurut Rosenberg dan Stephens (2007), diagram robustness menjembatani tahap analisis dan desain. Jika tahap analisis (use cases) dianggap sebagai “apa” dan desain sebagai “bagaimana”, maka analisis robustness merupakan desain sistem yang sangat awal. Pada tahap ini dibuat asumsi awal tentang desain. Jadi, tahap ini dapat menjadi bagian dari tahap analisis dan dapat menjadi bagian dari tahap desain.
Diagram robustness merupakan representasi bergambar dari perilaku (behavior) yang dideskripsikan oleh use cases. Diagram robustness menunjukkan perilaku dari kelas-kelas dan perilaku dari perangkat lunak. Pada diagram ini tidak digambarkan kelas mana yang bertanggung jawab terhadap perilaku tertentu. Walaupun demikian, diagram robustness dapat dibaca seperti diagram aktivitas (activity diagram) atau sebagai sebuah flowchart dalam arti suatu objek “berbicara” dengan objek lainnya. Simbol-simbol yang terlibat dalam diagram robustness ditunjukkan oleh Gambar 4.
Gambar 4 Simbol-simbol pada diagram robustness (Rosenberg & Stephens 2007).
Boundary object adalah antarmuka antara sistem dengan segala sesuatu di luar sistem. Contohnya adalah layar atau halaman web. Entity object merupakan kelas-kelas dari domain model. Controller adalah penghubung antara boundary dan entity object. Aturan-aturan dalam menggambar diagram robustness adalah (Rosenberg & Stephens 2007):
1. objek (noun) dapat berbicara kepada controller (verb) dan sebaliknya
2. objek tidak dapat berbicara kepada objek lainnya
3. controller dapat berbicara kepada controller lainnya.
Diagram Sequence
Pada tahap ini desain awal sistem telah ada (dari diagram robustness). Selain itu, pada tahap ini use cases sudah lengkap, benar, detail, dan eksplisit. Jika pada tahap sebelumnya adalah proses menemukan kelas-kelas yang terlibat, maka pada tahap desain ini semuanya adalah
proses mengalokasikan perilaku (behavior) kepada kelas-kelas yang sudah ada. Pada tahap sebelumnya dibuat tebakan bagaimana satu kelas berinteraksi dengan kelas lainnya, maka pada tahap ini pernyataan tadi akan dibuat lebih akurat dan benar dan membentuknya menjadi desain yang mendetail (Rosenberg & Stephens 2007).
METODE PENELITIAN
Metode pengembangan perangkat lunak yang dipakai dalam penelitian ini adalah extreme programming (XP). Alur penelitian ini mengikuti tahapan yang dijelaskan oleh Gambar 2. Untuk menjelaskan pemodelannya akan digunakan proses ICONIX.
Perencanaan
Perencanaan membahas tentang tujuan dikembangkannya perangkat lunak. Selain itu juga dibuat user stories, dan release plan (Shore & Warden 2008).
Analisis
Pada tahap ini ditentukan requirements apa saja yang dibutuhkan oleh perangkat lunak (Shore & Warden 2008). Tahap ini dimodelkan oleh domain modelling, use case, dan robustness diagram (Rosenberg & Stephens 2007).
Desain
Tahap Desain berfokus pada cara sistem beroperasi dalam hal perangkat keras, perangkat lunak, dan infrastruktur network. Desain juga berfokus pada user interface. Selain itu, tahap ini juga berfokus pada program, database, dan file yang akan dibutuhkan (Dennis 2006). Tahap ini akan dimodelkan oleh sequence diagram (Rosenberg & Stephens 2007).
Implementasi
Berdasarkan hasil desain yang telah dibuat, maka langkah selanjutnya adalah mengimplementasikannya menjadi kode program (Shore & Warden 2008).
Pengujian
HASIL DAN PEMBAHASAN Perangkat lunak yang akan dikembangkan diberi nama Network Operations Center Power Monitor (NOCPM). Tujuan utama dibuatnya perangkat lunak ini adalah untuk memantau setiap kejadian pemadaman listrik.
NOCPM akan dibagi menjadi dua subsistem. Subsistem pertama yang menyusun NOCPM adalah Watch Tower. Watch Tower bertugas untuk mendeteksi ada atau tidak
adanya aliran listrik dan mencatatnya pada database (sebagai log). Watch Tower juga bertugas untuk mengirimkan pesan singkat (SMS) pemberitahuan kepada administrator untuk setiap log yang terjadi.
Subsistem yang kedua disebut dengan Data Viewer. Data Viewer bertugas untuk memvisualisasikan log yang telah dibuat Watch Tower. Alur kejadian pada NOCPM ditunjukkan oleh Gambar 5.
phone cable data
power checker device
power outlet
messaging device
administrator
Watch Tower Data Viewer
nocpm: MySQL
Gambar 5 Diagram interaksi sistem Network Operations Center Power Monitor (NOCPM). 1 Iterasi Pertama
1.1 Watch Tower
Perencanaan dan Analisis 1.1.1
Tujuan utama dari Watch Tower adalah mencatat data tentang kejadian pemadaman listrik dan kapan listrik kembali hidup. Watch Tower akan mendapatkan data ada atau tidak adanya arus listrik dari sistem luar (atau device atau perangkat keras lain) yang dapat disebut dengan power checker device. Power checker device terhubung ke komputer melalui serial port. Watch Tower akan memantau serial port
Sistem luar ini akan mengirimkan sinyal ke serial port. Sinyal 0 untuk menandakan bahwa tidak ada arus listrik (listrik padam) dan sinyal 1 untuk menandakan bahwa ada arus listrik (listrik hidup).
Data yang diterima akan ditampilkan pada window utama dari Watch Tower. Untuk setiap data yang diterima akan dibuatkan log-nya pada database. Log ini berupa waktu kejadian kapan data dari serial port tersebut diterima. Selain itu, Watch Tower juga akan mengirimkan pesan pemberitahuan kepada administrator.
Pada Watch Tower juga dapat dilakukan
1. Power checkerdevice terhubung langsung pada power outlet. Jika terjadi pemadaman listrik maka
device tersebut akan mengetahuinya
2. Device tersebut memberitahukan komputer bahwa terjadi pemadaman listrik (melalui serial port) 3. Subsistem Watch Tower akan menerima pemberitahuan dan akan mencatatnya pada database
4. Pemberitahuan tercatat pada database sebagai log
5. Watch Tower juga mengirimkan pesan singkat pemberitahuan 6. Pesan singkat diterima oleh administrator
dipantau dan pengaturan untuk koneksi ke database.
Watch Tower dibuat dalam bentuk aplikasi desktop. Watch Tower akan ikut menyala selama komputer tempat Watch Tower dipasang juga menyala.
Gambar 6 Domain model awal untuk Watch Tower.
Hal pertama yang dilakukan dalam membuat Watch Tower adalah membuat domain model awal. Domain model dibuat untuk menyamakan persepsi mengenai requirements yang ada. Domain model awal untuk Watch Tower ditunjukkan oleh Gambar 6.
Gambar 7 Use cases untuk Watch Tower. Berdasarkan domain model awal yang telah ada maka dibuatlah use cases yang ditulis dalam konteks domain model tersebut. Gambar 7 menjelaskan deskripsi Watch Tower yang telah dituangkan dalam bentuk use cases.
Berdasarkan use cases pada Gambar 7, maka dibuatlah rencana iterasi atau release plan untuk Watch Tower seperti yang dijelaskan pada Tabel 1.
Tabel 1 Release plan untuk Watch Tower Release Kode Use Cases
1 WT-01 Menerima dan menampilkan data yang diterima serial port WT-02 Melihat current log WT-03 Menerima pesan
pemberitahuan 2 WT-04 Pengaturan serial port
WT-05 Pengaturan database
Desain 1.1.2
1.1.2.1 Lingkungan Pengembangan
Watch Tower dikembangkan pada perangkat keras dengan spesifikasi sebagai berikut: 1. prosesor AMD Athlon™ 64 3000+ 1.80
GHz
2. RAM dengan kapasitas 2 GB
3. monitor dengan resolusi 1280 × 960 pixels 4. media penyimpanan sebesar 330 GB.
Spesifikasi perangkat lunak yang digunakan selama pengembangan Watch Tower adalah: 1. sistem operasi Microsoft® Windows 7
Ultimate Service Pack 1 2. .NET Framework 4
3. IDE Microsoft® Visual Studio 2010 Service Pack 1.
4. database MySQL 5.1.33
5. MySQL Connector 6.3.6 untuk .NET. 1.1.2.2 Desain Database
Log yang dihasilkan oleh Watch Tower akan disimpan dalam database MySQL. Database ini hanya memiliki satu tabel utama dengan nama power_log2. Desainnya ditunjukkan oleh Tabel 2.
Tabel 2 Desain database Field Tipe Atribut
id integer primary key, unsigned, auto_increment down datetime -
Tabel-tabel lain yang terdapat pada database ini adalah tabel-tabel yang dibuat sendiri oleh Gammu agar dapat berjalan dengan baik.
1.1.2.3 Use Case: Menerima dan Menampilkan Data yang Diterima
Serial Port serta Menerima Pesan Pemberitahuan
Use case dengan kode WT-01 dan WT-03 ini dibahas secara bersamaan. Penyebabnya adalah terjadinya penerimaan pesan pemberitahuan akan dipicu oleh kejadian penerimaan data port. Untuk setiap data yang diterima pada serial port, maka akan terdapat pula pesan singkat yang diterima. Deskripsi untuk kedua use case ini dapat dilihat pada Tabel 3.
Tabel 3 Use case menerima dan menampilkan data port serta menerima pesan pemberitahuan
Penjelasan
Aktor Power checker device dan administrator
Tujuan Menerima data yang dikirimkan oleh power checker device melalui serial port. Untuk setiap data yang diterima ada pesan pemberitahuan yang dikirim Watch Tower dan diterima oleh administrator
Pre-condition
Watch Tower telah dijalankan (bisa berupa dalam keadaan minimize di system tray atau window utama telah terbuka) Deskripsi Ketika terjadi pemadaman listrik,
maka Watch Tower akan
menerima sinyal 0 dari serial port dari power checker device dan kemudian administrator menerima pesan pemberitahuan bahwa telah terjadi pemadaman listrik. Sebaliknya ketika listrik kembali menyala maka sinyal yang diterima adalah sinyal 1 dan pesan yg dikirimkan adalah listrik kembali menyala
Post-condition
Data yang diterima Watch Tower dari power checker device ditampilkan pada window Watch Tower. Selain itu data yang diterima juga tersimpan waktu kejadiannya pada database. Administrator menerima pesan pemberitahuan
Diagram robustness ditunjukkan oleh Gambar 8.
Gambar 8 Diagram robustness untuk menerima data port.
Diagram sequence untuk use case menerima data port dapat dilihat pada Lampiran 1. 1.1.2.4 Use Case: Melihat CurrentLog
Deskripsi untuk use case melihat current log dapat diperhatikan pada Tabel 4.
Tabel 4 Use case melihat current log Penjelasan
Aktor Administrator
Tujuan Menampilkan log tentang pemadaman listrik sejak saat Watch Tower dijalankan
Pre-condition
Watch Tower telah dibuka dan berada dalam keadaan minimize di system tray
Deskripsi Administrator melakukan double click pada icon Watch Tower yang terdapat pada system tray. Cara lain adalah dengan melakukan klik kanan pada icon Watch Tower, kemudian memilih menu Restore
Diagram robustness untuk melihat current log dapat dilihat pada Gambar 9.
Administrator
dobel klik icon
Window Watch Tower
icon Watch Tower padasystem tray
klik kananicon
restore
Gambar 9 Diagram robustness untuk melihat current log.
Diagram sequence untuk use case ini ditunjukkan oleh Gambar 10.
Gambar 10 Diagram sequence untuk melihat current log.
Implementasi 1.1.3
1.1.3.1 Menerima Data pada SerialPort
Kelas CommunicationManager mengatur koneksi ke serial port. Kelas ini menggunakan objek dari kelas SerialPort yang terdapat dalam namespace System.IO.Ports pada .NET Framework 4.0. Kelas SerialPort dari .NET ini menyediakan fungsi-fungsi dasar untuk komunikasi dengan serial port.
Fungsi dari kelas SerialPort yang dipakai di antaranya:
1. Open() dan Close(). Kedua fungsi tersebut digunakan untuk membuka dan menutup koneksi serial port
2. DataReceived(). Fungsi ini merepresentasikan suatu fungsi yang akan menangani data yang diterima oleh objek SerialPort
3. ReadExisting(). Fungsi ini membaca semua data yang tersedia pada objek SerialPort. Objek dari SerialPort akan digunakan dalam kelas CommunicationManager. Konfigurasi atau parameter serial port yang ingin dibuka diimplementasikan pada constructor CommunicationManager. Pada constructor juga ditentukan fungsi mana yang akan menangani data yang diterima oleh serial port. Semua data yang diterima akan ditangani oleh salah satu fungsi dari kelas CommunicationManager yang disebut dengan comPort_DataReceived(). Data yang diterima oleh fungsi ini selanjutnya akan ditampilkan pada window utama Watch Tower oleh fungsi DisplayData(). Window utama Watch Tower ditunjukkan oleh Gambar 11.
Fungsi utama lain dari kelas CommunicationManager ini adalah melakukan buka dan tutup dari suatu serial port. Hal ini ditangani oleh fungsi openPort().
Kelas lain yang juga mengatur komunikasi dengan serial port adalah kelas Port. Port merupakan kelas turunan dari kelas CommunicationManager. Dibuatnya kelas CommunicationManager adalah untuk menangani fungsi-fungsi dasar yang berhubungan dengan komunikasi serial. Kelas Port juga bertugas untuk berkomunikasi dengan serial port dengan menambahkan fungsi-fungsi tambahan lain yang diperlukan oleh Watch Tower. Oleh karena itu, yang dilakukan oleh Watch Tower adalah menginstantiasi kelas Port, bukan kelas CommunicationManager.
Gambar 11 Window utama Watch Tower. 1.1.3.2 Melihat CurrentLog
Berdasarkan diagram robustness pada Gambar 9, untuk melihat current log dapat dilakukan dengan dua cara. Cara utama adalah dengan melakukan dobel klik pada icon Watch Tower yang terdapat pada system tray. Cara alternatif adalah dengan melakukan klik kanan pada icon Watch Tower (yang berada pada system tray) dan kemudian memilih menu Restore.
Gambar 12 Langkah untuk melihat current log. Data atau log yang ingin dilihat ditampilkan dalam rich text box yang terdapat pada bagian bawah window utama Watch Tower (lihat Gambar 11).
1.2 Data Viewer
Perencanaan dan Analisis 1.2.1
Salah satu fungsi Watch Tower adalah
kapan data diterima, kemudian menyimpannya pada database MySQL (membuat log kejadian). Data Viewer bertugas untuk memvisualisasikan record pada MySQL dalam bentuk grafik.
Data Viewer dibuat dalam bentuk website. Grafik yang tersedia terdiri atas grafik harian, bulanan, dan tahunan. Masing-masing grafik memiliki dua kategori, yaitu grafik lamanya pemadaman listrik (dalam menit) dan grafik frekuensi mati listrik. Dari bentuk visualisasi grafik ini diharapkan dapat memudahkan dalam membaca data log atau data kejadian yang telah diterima Watch Tower.
Default controller untuk Data Viewer adalah kelas loader. Default controller adalah controller yang akan menangangi request ketika administrator mengetikkan URL Data Viewer pada browser. Default controller dapat juga dikatakan sebagai home page (dari Data Viewer).
Data Viewer akan menyimpan cookies pada browser pengguna. Cookies ini menyimpan informasi mengenai preferensi untuk Data Viewer. Preferensi pada Data Viewer pada dasarnya mengatur tentang:
grafik apa saja yang akan ditampilkan data tanggal berapa yang digunakan untuk menampilkan grafik pada poin di atas. Pada saat mengakses Data Viewer, tampilannya akan selalu disesuaikan dengan preferensi yang telah dipilih oleh pengguna. Oleh karena itu, dibutuhkan suatu kelas controller yang akan selalu memastikan bahwa preferensi tersebut selalu dipakai. Kelas controller yang akan menangani hal ini adalah kelas My_Controller.
Sebagaimana yang telah dijelaskan pada default controller, kelas loader merupakan home page dari Data Viewer. Supaya preferensi pengguna dapat diaplikasikan pada home page, maka diaturlah agar kelas loader dapat memakai fungsi-fungsi dari kelas My_Controller. Oleh karena itu, dibuatlah kelas loader sebagai turunan dari kelas My_Controller.
Pada home page, terdapat enam check box dari berbagai macam visualisasi dalam bentuk grafik (grafik mingguan, bulanan, dan tahunan, dan untuk masing-masing grafik terdiri atas grafik lama mati dan grafik frekuensi). Untuk menangani grafik-grafik ini akan dibuat tiga controller (weekly, monthly, yearly), sedangkan untuk jenis grafik lama mati dan grafik frekuensi akan diimplementasikan sebagai fungsi (method) dari tiga controller tadi.
Tiga controller untuk grafik tersebut memiliki beberapa kesamaan fungsi dan kesamaan properti/atribut. Oleh karena itu, dibutuhkan suatu generalisasi dan dibuatlah kelas abstrak Visualization. Jadi, tiga controller untuk menangangi grafik tersebut merupakan turunan dari kelas Visualization.
Grafik-grafik ini dibuat dengan menggunakan library JpGraph. Oleh karena itu, kelas JpGraph akan menjadi bagian (agregasi) dari kelas Visualization.
Gambar 13 Domain model awal untuk Data Viewer.
Berdasarkan penjelasan sebelumnya, maka domain model awal untuk Data Viewer
ditunjukkan oleh Gambar 13. Use cases untuk Data Viewer dijelaskan oleh Gambar 14.
Gambar 14 Use cases untuk Data Viewer. Berdasarkan use case untuk Data Viewer pada Gambar 11 maka dibuatlah release plan sesuai dengan Tabel 5.
Tabel 5 Release plan untuk Data Viewer Release Kode Use Cases
1 DV-01 Melihat lama mati
mingguan DV-02 Melihat frekuensi
mati mingguan
2 DV-03 Melihat lama mati
bulanan
DV-04 Melihat frekuensi mati bulanan DV-05 Melihat lama mati
tahunan
DV-06 Melihat frekuensi mati tahunan
3 DV-07 Mengatur tampilan
Desain 1.2.2
1.2.2.1 Lingkungan Pengembangan
Data Viewer dikembangkan pada lingkungan perangkat keras yang sama dengan Watch Tower. Hal ini dijelaskan oleh subbab 1.1.2.1.
Lingkungan perangkat lunak yang digunakan untuk pengembangan Data Viewer adalah sebagai berikut:
1. sistem operasi Microsoft® Windows 7 Ultimate Service Pack 1
2. XAMPP 1.7.1 yang berisi Apache HTTPD 2.2.11, MySQL 5.1.33, PHP 5.2.9, dan phpMyAdmin 3.1.3.1.
3. framework CodeIgniter 1.7.1
4. PHP graph plotting library JpGraph 2.3.4 5. Library and command line utility for mobile
phones Gammu 1.24.0 6. browser Mozilla Firefox 5.
1.2.2.2 Use Case: Melihat Lama Mati Mingguan
Use case untuk melihat lama mati mingguan dideskripsikan oleh Tabel 6.
Tabel 6 Use case melihat lama mati mingguan Penjelasan
Aktor Administrator
Tujuan Menampilkan grafik mingguan untuk kategori lama mati listrik
Pre-condition
Administrator berada pada home page Data Viewer
Deskripsi Administrator memberikan tanda centang pada pilihan weekly time
Post-condition
Tampilan grafik lama mati mingguan ditambahkan pada home page
Berdasarkan deskripsi use case pada Tabel 6, maka robustness diagram untuk melihat lama mati mingguan ditunjukkan oleh Gambar 15.
Administrator home page
log showing weekly time graph
put a tick on weekly time
graph
prepare chart of amount of time
make chart using JpGraph
display chart
datetime
format to weekly
Gambar 15 Diagram robustness untuk melihat lama mati mingguan.
Diagram sequence untuk use case melihat lama mati mingguan dapat dilihat pada Lampiran 3.
1.2.2.3 Use Case: Melihat Frekuensi Mati Mingguan
Use case untuk melihat frekuensi mati mingguan dideskripsikan oleh Tabel 7.
Tabel 7 Use case melihat frekuensi mati mingguan
Penjelasan Aktor Administrator
Tujuan Menampilkan grafik mingguan untuk kategori frekuensi mati listrik
Pre-condition
Administrator berada pada home page Data Viewer
Deskripsi Administrator memberikan tanda centang pada pilihan weekly frequent
Post-condition
Tampilan grafik frekuensi mati mingguan ditambahkan pada home page
Administrator home page
log showing weekly frequent graph
put a tick on weekly frequent
graph
prepare chart of frequent
make chart using JpGraph
display chart
datetime
format to weekly
Gambar 16 Diagram robustness untuk melihat frekuensi mati mingguan.
Diagram sequence untuk use case frekuensi mati mingguan dapat dilihat pada Lampiran 4.
Implementasi 1.2.3
1.2.3.1 Melihat Lama Mati Mingguan Berdasarkan Tabel 6 dan penjelasan pada subbab 1.2.1, maka administrator harus memberikan tanda centang pada check box weekly time untuk menampilkan grafik lama mati mingguan. Check box tersebut terdapat pada home page Data Viewer.
Home page ditangani oleh kelas loader. loader merupakan turunan dari My_Controller. Maka kelas My_Controller akan dieksekusi pertama kali. Proses untuk menampilkan home page diterangkan oleh diagram sequence pada Lampiran 2. Jika ini adalah untuk pertama kalinya administrator mengakses Data Viewer, maka Data Viewer akan menggunakan preferensi standar. Jika bukan, maka Data Viewer akan membaca cookies pada browser, dan menggunakannya sebagai preferensi.
Fungsi index() pada kelas loader akan dijalankan pada saat controller loader dipanggil. Fungsi index() ini melakukan pengecekan pada salah satu cookies, jika cookies dianggap tidak valid maka pengguna diberikan cookies/preferensi standar. Jika valid maka pengguna langsung diberikan home page seperti yang terlihat pada Gambar 17.
Setelah pengguna memperoleh home page, pengguna harus memberikan tanda centang pada weekly time pada menu Live Control yang berada disebelah kanan home page. Setelah dicentang maka browser akan melakukan proses AJAX untuk memanggil controller dari weekly time, yaitu kelas controller weekly.
Fungsi pada kelas controller weekly yang menangani weekly time adalah count_second(). Kelas controller weekly sendiri merupakan turunan dari kelas abstrak Visualization. Fungsi count_second() akan membuat grafik
dengan memanggil fungsi
create_visualization(). Jenis grafik yang akan
dibuat ditentukan dengan memanggil fungsi get_visual_type() dan menjadikannya sebagai parameter pada fungsi create_visualization(). get_visual_type() akan membaca cookies mengenai tipe grafik apa yang telah dipilih oleh pengguna (grafik garis atau grafik batang).
create_visualization() membuat grafik menggunakan JpGraph. Data yang akan divisualisasikan diperoleh dari model Graph_weekly. Data yang dipakai oleh model Graph_weekly berasal dari tabel log pada database. Grafik melihat lama mati mingguan yang dihasilkan dapat dilihat pada Gambar 18.
Gambar 18 Grafik lama mati mingguan dalam bentuk garis (atas) dan batang (bawah).
1.2.3.2 Melihat Frekuensi Mati Mingguan Implementasi dari use case ini tidak jauh berbeda dari use case melihat lama mati mingguan seperti yang telah dijelaskan sebelumnya. Fungsi count_second() sebelumnya akan digantikan oleh fungsi count_frequent(). Kedua fungsi tersebut
Gambar 19 Grafik frekuensi mati mingguan dalam bentuk garis (atas) dan batang (bawah).
2 Iterasi Kedua 2.1 Watch Tower
Perencanaan dan Analisis 2.1.1
Pada iterasi pertama, Watch Tower telah dapat menjalankan fungsi utamanya dengan baik. Watch Tower dapat memantau sinyal yang akan dikirimkan oleh power checker device, kemudian menampilkannya dalam bentuk current log dan mencatatkan waktu kejadian sinyal diterima pada database.
Untuk iterasi ke-2, requirement yang akan diimplementasikan adalah use case pengaturan database dan use case pengaturan serial port. Sebelumnya pada iterasi 1, konfigurasi serial port dan database dilakukan dari dalam program atau hard code.
Pada tahap analisis awal pada iterasi pertama, kedua use case ini dianggap sebagai dua use case terpisah. Namun, setelah dilakukan analisis lagi pada iterasi kedua, kedua use case tersebut dapat dijadikan satu karena implementasinya dapat dilakukan secara bersamaan. Jadi, kedua use case ini akan digabunggkan menjadi satu denngan nama use case pengaturan Watch Tower.
Use case pengaturan Watch Tower ini selain akan mengatur tentang konfigurasi serial port dan database juga akan ditambahkan pengaturan tentang konfigurasi nomor kontak
yang akan dikirimi pesan singkat. Jadi, use case pengaturan Watch Tower ini akan mengatur tiga hal tersebut.
Setelah analisis pada iterasi kedua, maka terjadi pengubahan use case dan release plan untuk Watch Tower. Tabel 1 mengalami pengubahan, yaitu penggabungan WT-04 dengan WT-05. Penggabungan ini akan memiliki kode WT-04 dengan nama use case pengaturan Watch Tower. Diagram use case pada Gambar 7 akan berubah menjadi seperti yang ditunjukkan oleh Gambar 20.
Desain 2.1.2
2.1.2.1 Use Case: Pengaturan Watch Tower Deskripsi untuk use case pengaturan Watch Tower dapat dilihat pada Tabel 8.
Tabel 8 Use case pengaturan Watch Tower Penjelasan
Aktor Administrator
Tujuan Mengatur konfigurasi Watch Tower berupa konfigurasi serial port, database, dan nomor kontak
Pre-condition
Watch Tower telah dibuka dan sampai pada window Preferences Deskripsi Administrator menginputkan
semua nilai (konfigurasi) yang berhubungan dengan parameter serial port, database, dan nomor kontak. Kemudian administrator mengkonfirmasi pengubahan
Post-condition
Konfigurasi disimpan (window Preferences menghilang) dan kembali pada window utama Watch Tower
Robustness diagram untuk pengaturan Watch Tower dapat dilihat pada Gambar 21.
Administrator
serial port, database, and contact number configurations
Gambar 21 Robustness diagram untuk pengaturan Watch Tower.
Diagram sequence untuk use case pengaturan Watch Tower dapat dilihat pada Lampiran 5.
Implementasi 2.1.3
2.1.3.1 Pengaturan Watch Tower
Antarmuka pengaturan Watch Tower terletak pada kelas Preferences. Oleh karena itu ketika administrator melakukan klik pada menu Preferences maka kelas WatchTower akan menginstantiasi kelas Preferences. Pada objek dari Preferences inilah administrator memasukkan parameter yang dibutuhkan untuk konfigurasi Watch Tower.
Window pengaturan Watch Tower terdiri atas 3 tabs. Tab pertama mengatur tentang konfigurasi serial port, tab kedua mengatur tentang koneksi ke database, dan tab ketiga mengatur tentang nomor kontak yang akan dikirimi pesan singkat. Tab pertama ditunjukkan oleh Gambar 22. Tab kedua dan ketiga ditunjukkan oleh Lampiran 6 dan Lampiran 7.
Watch Tower telah selesai pada iterasi kedua. Diagram kelas lengkap dapat dilihat pada Lampiran 13.
Gambar 22 Window pengaturan serial port. 2.2 Data Viewer
Perencanaan dan Analisis 2.2.1
Pada iterasi pertama Data Viewer telah dapat menampilkan log mingguan dalam bentuk grafik batang. Untuk log mingguan terdapat dua grafik batang (grafik lama mati dan grafik frekuensi). Pada iterasi ke-2 ini akan diimplemementasikan grafik batang untuk kategori bulanan dan tahunan.
Use case dan release plan tidak ada yang berubah. Keduanya masih mengacu pada Gambar 14 dan Tabel 5.
Desain 2.2.2
02), maka rancangan untuk iterasi kedua (use case DV-03 sampai DV-06) tidak jauh berbeda. Oleh karena itu, use case DV-03 sampai DV-06 akan dijelaskan secara bersamaan.
Diagram robustness untuk 03 dan DV-05 akan memiliki kemiripan dengan diagram robustness untuk DV-01 pada Gambar 15. Perbedaannya terletak pada controller format to weekly menjadi format to monthly dan yearly. Selain itu controller put a tick on weekly time graph diubah menjadi put a tick on monthly (atau yearly) time graph.
Diagram robustness untuk 04 dan DV-06 akan memiliki kemiripan dengan diagram robustness untuk DV-02 pada Gambar 16. Perbedaannya terletak pada controller format to
weekly menjadi format to monthly dan yearly. Selain itu controller put a tick on weekly frequent graph diubah menjadi put a tick on monthly (atau yearly) frequent graph.
Diagram sequence untuk DV-03 dan DV-05 juga mirip dengan digaram sequence untuk DV-01 pada Lampiran 3. Begitu juga dengan DV-04 dan DV-06, akan memiliki kemiripan dengan diagram sequence untuk DV-02 pada Lampiran 4.
Implementasi 2.2.3
Penjelasan untuk implementasi use case DV-03 sampai DV-06 dimulai dari kelas controller dan kelas model mana yang akan menangani masing-masing use case. Hal ini dijelaskan pada Tabel 9.
Tabel 9 Dekomposisi fisik controller dan model untuk iterasi kedua
Kode Controller Model
Kelas Fungsi Kelas Fungsi
DV-03 monthly count_second() Graph_monthly count_second() DV-04 monthly count_frequent() Graph_monthly count_frequent() DV-05 yearly count_second() Graph_yearly count_second() DV-06 yearly count_frequent() Graph_yearly count_frequent()
Implementasi use case 03 dampai DV-06 memiliki implementasi yang hampir sama dengan DV-01 dan DV-02. Kelas controller monthly dan yearly juga merupakan turunan dari kelas abstrak Visualization. Oleh karena itu, kedua kelas tersebut harus mengimplementasikan semua fungsi abstrak pada kelas Visualization. Grafik yang dihasilkan dapat dilihat pada Lampiran 9 sampai dengan Lampiran 12.
3 Iterasi Ketiga
Iterasi ketiga hanya dilakukan pada Data Viewer karena semua use cases untuk Watch Tower telah selesai diimplementasikan.
3.1 Data Viewer Perencanaan 3.1.1
Setelah mengalami iterasi sebanyak dua kali, Data Viewer telah dapat menjalankan fungsi utamanya, yaitu memvisualisasikan data log dalam bentuk grafik batang. Pada iterasi ketiga ini akan diimplementasikan use case yang memungkinkan agar pengguna (administrator) dapat mengatur tampilan Data Viewer.
Gambar 23 Pengubahan pada use cases Data Viewer.
Disebabkan adanya pengubahan pada use cases Data Viewer, maka tabel release plan pada Tabel 5 juga ikut mengalami pengubahan. Pengubahan pada Tabel 5 hanya terjadi pada relase ke-3 seperti yang ditunjukkan oleh Tabel 10.
Tabel 10 Pengubahan release plan untuk Data Viewer
Release Kode Use Cases
3 DV-07 Mengatur tampilan Data Viewer
DV-08 Mengubah tanggal data yang dilihat
Desain 3.1.2
3.1.2.1 Use Case: Mengatur Tampilan Data Viewer
Use case ini dideskripsikan oleh Tabel 11.
Tabel 11 Use case mengatur tampilan Data Viewer
Penjelasan Aktor Administrator
Tujuan Mengatur tampilan Data Viewer
Pre-condition
Administrator berada pada home page Data Viewer
Deskripsi Administrator melakukan klik pada menu Preferences. Data Viewer kemudian menampilkan halaman preferensi. Administrator memberikan konfigurasi Data Viewer yang diinginkan dan kemudian melakukan klik pada tombol OK untuk mengkonfirmasi penyimpanan preferensi
Post-condition
Administrator dikembalikan ke home page dan tampilan halaman tersebut sesuai dengan preferensi yang telah dipilih
Gambar 24 Diagram robustness untuk mengatur tampilan Data Viewer. Diagram sequence untuk use case ini ditunjukkan oleh Lampiran 8.
3.1.2.2 Use Case: Mengubah Tanggal Data yang Dilihat
Use case ini dideskripsikan oleh Tabel 12. Tabel 12 Use case mengubah tanggal data yang
dilihat Penjelasan Aktor Administrator
Tujuan Mengubah tanggal data log yang ingin ditampilkan
Pre-condition
Administrator berada pada home page Data Viewer
Deskripsi Administrator melakukan klik pada tanggal yang terdapat kalender yang berada pada home page.
Post-condition
Semua tanggal grafik yang sedang ditampilkan berubah menjadi tampilan grafik yang sesuai dengan tanggal yang telah dipilih oleh administrator
Berdasarkan deskripsi use case pada Tabel 12, maka diagram robustness untuk use case ini ditunjukkan oleh Gambar 25.
Gambar 25 Diagram robustness untuk mengubah tanggal data yang ingin dilihat.
Use case (grafik) dengan kode DV-01 sampai dengan DV-06 akan di-reload ulang setelah administrator melakukan klik pada tanggal. Grafik yang di-reload hanya grafik yang sudah diberi tanda centang. Grafik yang tidak dicentang tidak akan di-reload.
Diagram robustness untuk grafik yang dicentang sama dengan diagram robustness untuk masing-masing use case dan disini hanya dilambangkan dengan elips berisi tulisan DV-01 s.d. DV-06. Artinya, kelanjutan diagram robustness pada Gambar 25 sesuai dan sama dengan diagram robustness untuk DV-01 sampai dengan DV-06. Diagram sequence untuk use case mengubah tanggal data log dijelaskan oleh Gambar 26.
Implementasi 3.1.3
3.1.3.1 Mengatur Tampilan Data Viewer Kelas controller yang mengatur tentang preferensi pada Data Viewer adalah kelas Preferences. Kelas Preferences merupakan turunan dari kelas My_Controller. Oleh karena itu, sebelum halaman preferensi ditampilkan maka fungsi validate_cookies() pada My_Controller akan dipanggil terlebih dahulu.
Setelah halaman preferensi ditampilkan, kemudian administrator memberikan inputan konfigurasi tampilan Data Viewer yang diinginkan. Preferensi yang dapat diatur dapat dilihat pada Gambar 27.
Gambar 27 Potongan halaman preferensi pada Data Viewer.
Setelah konfigurasi preferensi diberikan kemudian administrator melakukan klik pada tombol Save Preferences supaya preferensinya dapat disimpan. Konfigurasi preferensi disimpan pada cookies yang terdapat pada browser. Jika proses penyimpanan preferensi
dikembalikan ke home page. Tampilan home page akan sesuai dengan preferensi yang telah dipilih.
Apabila proses penyimpanan mengalami kegagalan, maka halaman yang menyatakan bahwa proses penyimpanan preferensi gagal dilakukan akan ditampilkan. Potongan halaman ini ditunjukkan oleh Gambar 28.
Gambar 28 Halaman yang dimunculkan ketika menyimpan preferensi gagal dilakukan.
3.1.3.2 Mengubah Tanggal Data yang Dilihat
Seperti yang ditunjukkan oleh diagram robustness pada Gambar 26, maka implementasi dari use case ini hanya pada pengubahan tanggal data. Pengubahan tanggal data ini dilakukan dengan melakukan klik pada tanggal pada kalender. Setelah itu Data Viewer akan melakukan reload terhadap semua grafik yang sedang ditampilkan. Proses reload ini akan sama implementasinya dengan use case menampilkan grafik 01 sampai dengan DV-06.
Gambar 29 Data Viewer sebelum dan setelah penambahan kalender.
setelah ditambahkan dengan kalender ditunjukkan oleh Gambar 29.
Data Viewer telah selesai pada iterasi ketiga. Diagram kelas lengkap dapat dilihat pada Lampiran 13. Tampilan akhir dari Data Viewer dapat dilihat pada Lampiran 14.
Pengujian Sistem 1. Pengujian Fungsional
Setelah mengalami beberapa iterasi maka NOCPM selesai diimplementasikan. Meskipun pada saat implementasi pada tiap iterasi telah dilakukan pengujian, namun pengujian secara menyeluruh tetap perlu dilakukan. Pengujian dilakukan dengan berfokus pada data masukan dan data keluaran sistem. Jadi, pengujian yang dilakukan tergolong pengujian black box, yaitu pengujian yang memeriksa apakah masukan dari pengguna memberikan hasil keluaran yang benar tanpa memperhatikan proses di dalamnya. Setelah dilakukan pengujian terhadap NOCPM, maka didapatkan hasil semua use cases berjalan dengan baik. Semua use cases diuji dengan input yang sesuai dan use cases tersebut menghasilkan output yang benar. Hasil pengujian dapat dilihat pada Lampiran 15. 2. Pengujian Kinerja (Performance)
Pengujian kinerja dilakukan dengan mengukur waktu respon dimulai ketika sinyal diterima oleh Watch Tower sampai sinyal tersebut tercatat (sebagai log) pada database. Hasil pengujian kinerja dapat dilihat pada Lampiran 16. Pada lampiran tersebut terlihat bahwa waktu respon sangat cepat. Respon terlama hanya memakan waktu satu detik.
Waktu respon untuk sampainya pesan peringatan kepada administrator tidak dapat diukur secara pasti karena waktu SMS pada telepon seluler ketelitiannya hanya sampai menit. Namun, dari hasil pengujian, sampainya SMS pemberitahuan tidak memakan waktu lama. Rata-rata waktu untuk sampainya SMS tidak lebih dari satu menit.
Sampainya SMS pemberitahuan dapat memakan waktu yang lebih lama apabila operator jaringan seluler sedang padat/sibuk. Selain itu dapat juga disebabkan oleh buruknya kualitas sinyal yang didapat oleh telepon selular penerima.
KESIMPULAN DAN SARAN Kesimpulan
Network Operations Center Power Monitor (NOCPM) adalah perangkat lunak yang dapat memantau keadaan kelistrikan (listrik padam atau listrik menyala). NOCPM terbagi menjadi dua subsitem, yaitu Watch Tower dan Data Viewer.
Watch Tower bertugas untuk memantau kelistrikan dan membuatkan log untuk setiap kejadian pemadaman listrik (dan log listrik kembali menyala). Waktu respon Watch Tower ketika menerima sinyal pemadaman listrik sampai sinyal tersebut tercatat pada database sangat cepat, yaitu tidak lebih dari satu detik.
Watch Tower juga dapat mengirimkan pesan singkat pemberitahuan telah terjadi pemadaman listrik pada administrator. Waktu yang ditempuh sejak sinyal pemadaman listrik diterima Watch Tower sampai pesan pemberitahuan diterima oleh administrator tidak lebih dari satu menit.
Data Viewer bertugas untuk memvisualisasikan log yang didapat Watch Tower kedalam bentuk grafik sehingga ide/informasi dari log dapat dibaca dengan mudah.
Saran
Pengembangan lebih lanjut dari perangkat lunak ini dapat diarahkan pada:
1. membuat alat atau device yang dapat memantau pemadaman listrik untuk digunakan bersamaan dengan perangkat lunak ini
2. membuat fasilitas tambahan seperti melakukan perintah tertentu via pesan singkat terhadap komputer yang dipasangi perangkat lunak NOCPM
3. menyediakan fasilitas mekanisme log seperti back up log (database). Database akan dipakai terus menerus selama NOCPM menyala, oleh karena itu harus disediakan fitur back up agar database tidak penuh 4. menyediakan mekanisme otentikasi untuk
Watch Tower sehingga tidak semua orang dapat membuka dan mengubahnya
DAFTAR PUSTAKA
setelah ditambahkan dengan kalender ditunjukkan oleh Gambar 29.
Data Viewer telah selesai pada iterasi ketiga. Diagram kelas lengkap dapat dilihat pada Lampiran 13. Tampilan akhir dari Data Viewer dapat dilihat pada Lampiran 14.
Pengujian Sistem 1. Pengujian Fungsional
Setelah mengalami beberapa iterasi maka NOCPM selesai diimplementasikan. Meskipun pada saat implementasi pada tiap iterasi telah dilakukan pengujian, namun pengujian secara menyeluruh tetap perlu dilakukan. Pengujian dilakukan dengan berfokus pada data masukan dan data keluaran sistem. Jadi, pengujian yang dilakukan tergolong pengujian black box, yaitu pengujian yang memeriksa apakah masukan dari pengguna memberikan hasil keluaran yang benar tanpa memperhatikan proses di dalamnya. Setelah dilakukan pengujian terhadap NOCPM, maka didapatkan hasil semua use cases berjalan dengan baik. Semua use cases diuji dengan input yang sesuai dan use cases tersebut menghasilkan output yang benar. Hasil pengujian dapat dilihat pada Lampiran 15. 2. Pengujian Kinerja (Performance)
Pengujian kinerja dilakukan dengan mengukur waktu respon dimulai ketika sinyal diterima oleh Watch Tower sampai sinyal tersebut tercatat (sebagai log) pada database. Hasil pengujian kinerja dapat dilihat pada Lampiran 16. Pada lampiran tersebut terlihat bahwa waktu respon sangat cepat. Respon terlama hanya memakan waktu satu detik.
Waktu respon untuk sampainya pesan peringatan kepada administrator tidak dapat diukur secara pasti karena waktu SMS pada telepon seluler ketelitiannya hanya sampai menit. Namun, dari hasil pengujian, sampainya SMS pemberitahuan tidak memakan waktu lama. Rata-rata waktu untuk sampainya SMS tidak lebih dari satu menit.
Sampainya SMS pemberitahuan dapat memakan waktu yang lebih lama apabila operator jaringan seluler sedang padat/sibuk. Selain itu dapat juga disebabkan oleh buruknya kualitas sinyal yang didapat oleh telepon selular penerima.
KESIMPULAN DAN SARAN Kesimpulan
Network Operations Center Power Monitor (NOCPM) adalah perangkat lunak yang dapat memantau keadaan kelistrikan (listrik padam atau listrik menyala). NOCPM terbagi menjadi dua subsitem, yaitu Watch Tower dan Data Viewer.
Watch Tower bertugas untuk memantau kelistrikan dan membuatkan log untuk setiap kejadian pemadaman listrik (dan log listrik kembali menyala). Waktu respon Watch Tower ketika menerima sinyal pemadaman listrik sampai sinyal tersebut tercatat pada database sangat cepat, yaitu tidak lebih dari satu detik.
Watch Tower juga dapat mengirimkan pesan singkat pemberitahuan telah terjadi pemadaman listrik pada administrator. Waktu yang ditempuh sejak sinyal pemadaman listrik diterima Watch Tower sampai pesan pemberitahuan diterima oleh administrator tidak lebih dari satu menit.
Data Viewer bertugas untuk memvisualisasikan log yang didapat Watch Tower kedalam bentuk grafik sehingga ide/informasi dari log dapat dibaca dengan mudah.
Saran
Pengembangan lebih lanjut dari perangkat lunak ini dapat diarahkan pada:
1. membuat alat atau device yang dapat memantau pemadaman listrik untuk digunakan bersamaan dengan perangkat lunak ini
2. membuat fasilitas tambahan seperti melakukan perintah tertentu via pesan singkat terhadap komputer yang dipasangi perangkat lunak NOCPM
3. menyediakan fasilitas mekanisme log seperti back up log (database). Database akan dipakai terus menerus selama NOCPM menyala, oleh karena itu harus disediakan fitur back up agar database tidak penuh 4. menyediakan mekanisme otentikasi untuk
Watch Tower sehingga tidak semua orang dapat membuka dan mengubahnya
DAFTAR PUSTAKA
SISTEM
MONITORING
KELISTRIKAN PADA
NETWORK
OPERATIONS CENTER
DIKA AGUS SATRIA
DEPARTEMEN ILMU KOMPUTER
FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM
INSTITUT PERTANIAN BOGOR
___. The Gammu Manual. [terhubung berkala]. http://wammu.eu/docs/manual/ [26 Sep 2011].
Bai Y. 2005. The Windows Serial Port Programming Handbook. United States of America: Auerbach.
Dennis A et al. 2006. System Analysis and Design 3rd ed. Indiana: John Wiley & Sons, Inc.
Ohara GJ. 2005. Aplikasi Sistem Monitoring Berbasis Web untuk Open Cluster [Skripsi]. Bandung. Jurusan Teknik Elektro Sekolah Tinggi Teknologi Telkom.
Rosenberg D, Stephens M, Cope MC. 2005. Agile Development with ICONIX Process: People, Process, and Pragmatism. New York: Apress.
Rosenberg D, Stephens M. 2007. Use Case Driven Object Modelling with UML: Theory and Practice. New York: Apress.
SISTEM
MONITORING
KELISTRIKAN PADA
NETWORK
OPERATIONS CENTER
DIKA AGUS SATRIA
DEPARTEMEN ILMU KOMPUTER
FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM
INSTITUT PERTANIAN BOGOR
ABSTRACT
DIKA AGUS SATRIA. Power Monitoring System for Network Operations Center. Supervised by HENDRA RAHMAWAN.
Electricity power events such as power goes off and on can affect performance of a computer, especially a server. Often such power events occurred and noticed, but ignored. Computer intensive activity like servers in Network Operations Center (NOC) should has a power monitoring software. So, an administrator of NOC will have log of power events. Administrator should be noticed also when power goes off.
Network Operations Center Power Monitor (NOCPM) is developed to meet this needs. It was developed using extreme programming (XP) methodology with object oriented approach. NOCPM evolved iteration by iteration in XP lifecycle. Each iteration will be explained using ICONIX process. NOCPM consists of two subsystems: Watch Tower and Data Viewer. Watch Tower concerns about monitoring certain serial port and make log for each data that received. A short message alert for each data that received from serial port will be sent also to an administrator. Data Viewer acts as data log visualizer and make graph from data log.
SISTEM
MONITORING
KELISTRIKAN PADA
NETWORK
OPERATIONS CENTER
DIKA AGUS SATRIA
Skripsi
Sebagai salah satu syarat untuk memperoleh gelar
Sarjana Komputer pada
Departemen Ilmu Komputer
DEPARTEMEN ILMU KOMPUTER
FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM
INSTITUT PERTANIAN BOGOR
Judul : Sistem Monitoring Kelistrikan pada Network Operations Center Nama : Dika Agus Satria
NRP : G64053109
Menyetujui: Pembimbing,
Hendra Rahmawan, S.Kom, M.T. NIP 19820501 200912 1 004
Mengetahui:
Ketua Departemen Ilmu Komputer Institut Pertanian Bogor
Dr. Ir. Sri Nurdiati, M.Sc. NIP. 19601126 198601 2 001
PRAKATA
Alhamdulillahi Rabbil ‘alamin, puji dan syukur penulis ucapkan kepada Allah SWT atas limpahan rahmat dan hidayah-Nya sehingga tugas akhir dengan judul Sistem Monitoring Kelistrikan pada Network Operations Center dapat diselesaikan. Salawat serta salam selalu tercurah kepada Nabi Muhammad SAW, keluarga, para sahabat, dan para pengikutnya.
Penulis menyadari bahwa dalam penyelesaian tugas akhir ini tidak terlepas dari bantuan dan dukungan dari berbagai pihak. Oleh karena itu, melalui lembar ini penulis ingin menyampaikan penghargaan dan terima kasih yang sebesar-besarnya kepada keluarga besar penulis terutama mama, papa, dan adik Ibut. Terima kasih atas dukungan, doa, dan kesabarannya dalam mendorong penulis agar tetap tekun dalam menyelesaikan tugas akhir ini. Penulis juga ingin berterima kasih kepada keluarga besar Departemen Ilmu Komputer Institut Pertanian Bogor khususnya kepada Bapak Hendra Rahmawan, S.Kom, M.T. selaku dosen pembimbing yang telah sabar membimbing dan memberikan ilmunya kepada penulis dalam penelitian ini. Terima kasih juga kepada Bapak Heru Sukoco, S.Si, M.T. yang telah sempat membimbing penulis pada awal penelitian ini.
Ucapan terima kasih tidak lupa penulis tujukan kepada teman-teman Program Studi Ilmu Komputer angkatan 42 atas persahabatan, ilmu, dan motivasi selama menuntut ilmu di IPB. Terima kasih kepada Graderz atas kebersamaan yang tidak tergantikan. Selain itu, terima kasih juga kepada teman-teman Wisma Byru yang sudah penulis anggap sebagai keluarga penulis sendiri selama berada di Bogor.
Penulis berharap semoga bantuan yang telah diberikan mendapat balasan dari Allah SWT, aamiin. Semoga tulisan ini bermanfaat dan dapat dikembangkan lagi bagi pendidikan negeri tercinta, Indonesia.
Bogor, Agustus 2011
RIWAYAT HIDUP
Penulis dilahirkan di Payakumbuh, Sumatera Barat, pada tanggal 1 Agustus 1986 dan merupakan anak pertama dari dua bersaudara dengan ayah bernama Syahrial dan ibu bernama Elmisdar.
DAFTAR ISI
Halaman DAFTAR TABEL ... vi DAFTAR GAMBAR ... vi DAFTAR LAMPIRAN ... vii PENDAHULUAN ... 1 Latar Belakang ... 1 Tujuan ... 1 Ruang Lingkup ... 1 Manfaat Penelitian ... 1 TINJAUAN PUSTAKA ... 1 Sistem Monitoring ... 1 Komunikasi Serial ... 1 JpGraph ... 2 Gammu... 2 Extreme Programming (XP) ... 2 Proses ICONIX ... 3 Domain Model ... 3 Diagram Use Cases ... 3 Diagram Robustness ... 3 Diagram Sequence ... 4 METODE PENELITIAN ... 4 Perencanaan ... 4 Analisis ... 4 Desain ... 4 Implementasi ... 4 Pengujian... 4 HASIL DAN PEMBAHASAN ... 5 1 Iterasi Pertama ... 5 1.1 Watch Tower ... 5 Perencanaan dan Analisis ... 5 1.1.1
Desain... 6 1.1.2
1.1.2.1 Lingkungan Pengembangan ... 6 1.1.2.2 Desain Database ... 6 1.1.2.3 Use Case: Menerima dan Menampilkan Data yang Diterima Serial Port serta Menerima Pesan Pemberitahuan ... 7
1.1.2.4 Use Case: Melihat Current Log ... 7 Implementasi ... 8 1.1.3
1.1.3.1 Menerima Data pada Serial Port ... 8 1.1.3.2 Melihat Current Log ... 9 1.2 Data Viewer ... 9 Perencanaan dan Analisis ... 9 1.2.1
Desain... 11 1.2.2
1.2.2.1 Lingkungan Pengembangan ... 11 1.2.2.2 Use Case: Melihat Lama Mati Mingguan ... 11 1.2.2.3 Use Case: Melihat Frekuensi Mati Mingguan ... 11 Implementasi ... 12 1.2.3
2 Iterasi Kedua ... 14 2.1 Watch Tower ... 14 Perencanaan dan Analisis ... 14 2.1.1
Desain... 15 2.1.2
2.1.2.1 Use Case: Pengaturan Watch Tower... 15 Implementasi ... 15 2.1.3
2.1.3.1 Pengaturan Watch Tower ... 15 2.2 Data Viewer ... 15 Perencanaan dan Analisis ... 15 2.2.1
Desain... 15 2.2.2
Implementasi ... 16 2.2.3
3 Iterasi Ketiga ... 16 3.1 Data Viewer ... 16 Perencanaan ... 16 3.1.1
Desain... 17 3.1.2
3.1.2.1 Use Case: Mengatur Tampilan Data Viewer ... 17 3.1.2.2 Use Case: Mengubah Tanggal Data yang Dilihat ... 18 Implementasi ... 19 3.1.3
