penulis lakukan meliputi perancangan aplikasi dan perancangan database. Untuk tampilan antarmuka interface aplikasi sendiri,
penulis melakukan perancangan Graphical User Interface GUI dari aplikasi ini.
a. Perancangan Aplikasi
Pada tahap perancangan aplikasi, penulis menggunakan alat bantu tools yaitu Unified Modelling Language UML.
Unified Modeling Language UML merupakan satu kumpulan konvensi pemodelan yang digunakan untuk menentukan
atau menggambarkan sebuah sistem software yang terkait dengan objek Whitten et al. 2004. Dalam perancangan dengan UML ini,
penulis menggunakan software StarUML 5.2, Umbrello dan Microsoft Office Visio 2007. Perancangan aplikasi ini dapat dilihat
pada bab IV point 4.3.1.
b. Perancangan Database
Setelah melakukan perancangan aplikasi, penulis dapat menyimpulkan bahwa diperlukan field-field dari modul-modul yang
telah ada. Sehingga perancangan dilakukan dengan membuat tabel- tabel serta field-field-nya dan kemudian membuat relationship dari
tabel-tabel yang telah dibuat. Perancangan database ini dapat dilihat pada bab IV pada point 4.3.2.
c. Perancangan Tampilan
Penulis melakukan perancangan terhadap user interface dari aplikasi ini. Perancangan yang dilakukan meliputi halaman-
halaman yang ada di dalam sistem ini. Perincian mengenai rancangan tampilan dapat dilihat pada bab IV pada point 4.4.3.
3.2.3 Implementation
Pada tahap ini penulis mengimplementasikan rancangan- rancangan yang telah di buat pada tahap sebelumnya. Desain database
yang telah dibuat diimplementasikan langsung, dalam hal ini penulis menggunakan database mysql dengan interface phpmyadmin. Setelah
implementasi database
selesai dilakukan,
penulis selanjutnya
mengimplementasikan aplikasi. Pada implementasi aplikasi, penulis melakukan pengembangan aplikasi dengan mengacu pada design
aplikasi yang telah dilakukan. Implementasi dan tahap pengembangan ini dapat dilihat di bab IV pada sub bab 4.4.
Dalam tahap implementasi penulis juga melakukan pengujian aplikasi, yang bertujuan untuk menguji apakah fitur-fitur yang ada di
aplikasi yang penulis rancang telah berjalan dengan baik dan dapat
terintegrasi dengan sistem yang sudah ada pada Dinas Infokom Kota Tangerang. Pengujian menggunakan pendekatan black box testing.
Pengujian dapat dilihat pada bab IV sub bab 4.4.3.
3.3 Kerangka Berfikir
Dalam melakukan penelitian ini, penulis melakukan tahapan-tahapan kegiatan dengan mengikuti rencana kegiatan yang tertuang dalam model
konseptual penelitian ini.
Gambar 3.2 Kerangka Berfikir
BAB IV
IMPLEMENTASI DAN HASIL
4.1
Sekilas Tentang Dinas Informasi dan Komunikasi Kota Tangerang
Dinas Informasi dan Komunikasi INFOKOM dibentuk tahun 2009, instansi yang menggabungkan fungsi Kantor Pengolahan Data Elektronik
KPDE bagian Humas dan Pos dan Telekomunikasi POSTEL. Dinas Informasi dan Komunikasi terdiri dari 3 bidang, yaitu :
1. Bidang Telematika
Terbentuk dari Pengolahan Data Elektronik PDE yang mempunyai tugas pengolahan Sistem Manajemen Daerah SIMDA,
website, E-Government, dan Pemberdayaan Telematika Sarana dan Prasarana.
2. Bidang Pos dan Telekomunikasi
Seiring dengan perkembangan waktu ada kegiatan Center Pengolahan Data dan Diseminasi Informasi, kegiatan penyebaran
informasi.
3. Bidang Pengolahan Data dan Diseminasi
Ada kegiatan Media Center, Mobil Penyebaran Informasi, Closed –
Cicuit Television CCTV, penganganan kegiatan Koran Banten, SMS Gateway, dan AIM Anjungan Internet Mandiri.
4.1.1 Visi dan Misi Dinas Informasi dan Komunikasi Kota Tangerang
4.1.1.1 Visi
Pengembangan Teknologi Informasi dan Komunikasi yang terintegrasi menuju terwujudnya visi kota Tangerang
4.1.1.2 Misi
1. Pengembangan kualitas SDM dalam bidang manajemen data
dan informasi. 2.
Peningkatan kualitas layanan public dalam memperoleh data dan informasi yang lengkap, akurat, valid, dan terkini dengan
memanfaatkan teknologi informasi dan komunikasi. 3.
Peningkatan daya jangkauan jaringan teknologi informasi dan komunikasi untuk mempermudah akses masyarakat.
4. Terbangunnya sistem informasi dan komunikasi yang
terintegrasi antar institusi pengelola data dan informasi menuju
terciptanya GOOD
GOVERNANCE dan
CLEAN GOVERNANCE melalui penerapan E- GOVERNMENT.
4.1.2 Struktur Organisasi
Gambar 4.1 Struktur Organisasi Dinas Infokom Kota Tangerang
Gambar 4.2 Struktur Organisasi Divisi Networking Dinas Infokom Kota Tangerang
4.2
Requirement Planning 4.2.1
Analisis Sistem Berjalan dan Sistem yang Ditawarkan
Berdasarkan observasi yang penulis telah lakukan mengenai kegiatan monitoring jaringan network monitoring yang ada pada Dinas Informasi dan
Komunikasi Kota Tangerang serta berdasarkan hasil wawancara mengenai kebutuhan admin jaringan Dinas Infokom akan suatu tools yang dapat
membantu pekerjaannya. Berikut ini penulis jabarkan hasil Analisis terhadap sistem yang berjalan pada Dinas Infokom adalah sebagai berikut :
Tabel 4.1 Analisa Sistem yang Berjalan
No Sistem yang Sedang Berjalan
Keunggulan Kekurangan
Solusi
1 Untuk memeriksa
koneksi host dan device yang ada
menggunakan perintah ping pada
command prompt Jika
memeriksanya satu per satu
tidak membebani
jaringan Jika yang
diperiksa banyak akan
memerlukan waktu untuk
melakukannya Pembuatan
modul yang bisa
digunakan untuk
memeriksa koneksi host
secara sekaligus.
2 Data device yang
ada belum Data
tersimpan Tidak teratur
dan mudah Pembuatan
sistem
menggunakan database
dalam kertas dan tidak
tergantung pada komputer
hilang bila berkas
disimpan dengan tidak
rapih inventory
yang dapat menyimpan
data device yang ada ke
dalam database
3 Menggunakan squid
Sebagai proxy server squid
dapat membantu
keamanan dengan cara
melakukan filter lalu
lintas, selain itu juga dapat
mempercepat kinerja
jaringan dengan
caching yang dilakukanya.
Hasil monitoring
yang ditampilkan
melalui layar terminal tidak
menggunakan interface yang
memudahkan untuk
membacanya. Pembuatan
modul yang bisa
menampilkan hasil
monitoring yang mudah
dibaca dalam sistem yang
akan dibuat
4 Menggunakan sqstat URL yang
sedang diakses oleh client
dapat Terinstall
secara terpisah mengharuskan
berpindah- Pembuatan
modul yang dapat berkerja
seperti sqstat
terpantau pindah
aplikasi di dalam
sistem yang akan dibuat
Untuk menjawab permasalahan-permasalahan yang dihadapi dalam proses monitoring jaringan pada Dinas Informasi dan Komunikasi Kota
Tangerang, penulis bermaksud mengusulkan sebuah sistem untuk membantu kegiatan monitoring jaringan yang dilakukan network administrator Dinas
Informasi dan Komunikasi Kota Tangerang. Pada pengembangannya, penulis melakukan studi kasus pada Dinas Informasi dan Komunikasi Kota
Tangerang, namun pada kenyataanya sistem yang penulis rancang ini nantinya dapat juga digunakan oleh dinas-dinas lain yang ada di kota
tangerang. Usulan sistem yang dimaksud adalah sebagai berikut: Tabel 4.2 Sistem yang Ditawarkan
No Sistem yang Ditawarkan
Keunggulan Kekurangan
Solusi
1 Pembuatan tools
monitoring koneksi jaringan
Selain memeriksa
koneksi dapat juga melihat
portservice yang sedang
Memungkinkan terjadinya
beban pada jaringan
Penyempurnaan modul
monitoring
aktif
2 Pembuatan sistem
inventory untuk menyimpan data
device yang ada Data lebih
teratur dan rapih karena
tersipan dalam
database Bila datanya
banyak memerlukan
memory yang besar pada
database Optimalisasi
pada database yang telah
dibuat
3 Pembutan modul
untuk membuat laporan hasil
monitoring yang dilakukan oleh
sqiud Memudahkan
untuk membaca
hasil monitoring
yang dilakukan
oleh squid, selain itu
laporan dapat di download
untuk disimpan
sebagai arsip Laporan dalam
file berformat html bukan pdf
ataupun excel Penyempurnaan
modul report
4 Pembuatan modul
yang bisa berkerja seperti sqstat dalam
Jika terdapat dalam satu
aplikasi tidak perlu repot
Kemungkinan adanya bug
pada modul ini masih sangat
Penyempurnaan modul active
request
sistem yang dibuat berpindah-
pindah aplikasi
besar
Berdasarkan penjabaran dari analisis diatas keunggulan dari penelitian yang penulis lakukan, perbedaan dari aplikasi yang penulis buat dengan 2
penelitian sebelumnya adalah terletak pada tujuan pembuatannya dan juga fitur yang terdapat pada aplikasi. Pada penelitian yang dilakukan oleh Dhika
Rizki Ambia, disituh menerapkan framework Codeigniter untuk perancangan social networking yang dilengkapi fitur-fitur kebutuhan kerja yang dimana
semua modul yang dibuat pada aplikasi tersebut menggunakan framework Codeigniter.
Sedangakan NetworkView merupakan salah satu tools yang digunakan untuk memonitoring koneksi host dalam suatu jaringan. NetworkView
aplikasi berbasis desktop dan tidak open source. Aplikasi ini tidak dapat diakses dari tempat lain hanya dapat digunakan oleh komputer yang
didalamnya terinstall aplikasi ini saja, tidak seperti aplikasi berbasis web yang dapat digunakan dari komputer mana saja.
Sementara itu aplikasi yang penulis buat menerapkan framework Codeigniter untuk perancangan sistem monitoring jaringan. Aplikasi ini
berbasiskan web, sehingga untuk mengakses aplikasi ini tidak hanya pada satu komputer saja. Fitur-fitur yang terdapat didalamnya merupakan
kebutuhan yang diperlukan oleh network administrator Dinas Informasi dan Komunikasi Kota Tangerang, aplikasi ini juga dirancang untuk dapat
terintegrasi dengan aplikasi yang sudah ada pada dinas tersebut.
4.3
Workshop Design 4.3.1
Perancangan Aplikasi a.
Penentuan Aktor
Pada sistem ini, penulis memisahkan aktor menjadi 3 tiga tingkatan yaitu super admin, admin dan sub-admin. Tiap aktor
mempunyai wewenang yang berbeda-beda, seperti yang penulis jabarkan sebagai berikut:
1. Super Admin
Super admin merupakan aktor yang menempati tingkat tertinggi pada sistem. Super admin memiliki wewenang sebagai berikut:
a. Menambahkan user baru, mengedit user dan menghapus user
yang ada. b.
Administrasi inventory, yaitu menambahkan data device, mengedit data device dan juga menghapus data device.
c. Memonitor status updown setiap host.
d. Melihat report hasil monitoring.
2. Admin
Admin merupakan aktor yang menempati tingkat menengah pada sistem. Wewenang yang dimiliki admin adalah sebagai berikut:
a. Administrasi inventory, yaitu menambahkan data device,
mengedit data device dan juga menghapus data device. b.
Memonitor status updown setiap host. c.
Melihat report hasil monitoring.
3. Sub-Admin
Tingkatan sub-admin menempati level terbawah dalam sistem ini. Sub-Admin memiliki wewenang sebagai berikut:
a. Memonitor status updown setiap host.
b. Melihat report hasil monitoring.
Wewenang dari masing-masing aktor dapat pula dilihat pada tabel berikut ini:
Tabel 4.3 Wewenang Aktor
No Super Admin
Admin Sub Admin
1 Add, edit dan delete user Add, edit dan
delete data device
Monitoring status koneksi
host
2 Add, edit dan delete data
device Monitoring
status koneksi host
View report
3 Monitoring status
koneksi host View report
4 View report
b. Perancangan Use Case Diagram
Use Case Diagram digunakan untuk menjelaskan apa yang akan dilakukan sistem serta aktor-aktor yang akan berhubungan
dengan proses-proses yang ada pada sistem.
Gambar 4.3 Use Case System yang Dirancang Berikut ini adalah penjabaran dari use case tersebut yang ditampilkan
tiap modul.
Gambar 4.4 Use Case Login
Gambar 4.5 Use Case Monitoring
Gambar 4.6 Use Case View Report
Gambar 4.7 Use Case Device
Gambar 4.8 Use Case User Untuk dapat masuk ke dalam sistem dan menggunakan modul-
modul yang ada pada sistem, seluruh actor harus login terlebih dahulu.
c. Use Case Scenario
Use Case Scenario merupakan penjelasan yang lebih terperinci mengenai masing-masing use case yang terjadi dalam
sistem.
1 Login
Tabel 4.4 Use Case Scenario Login Nama Use Case
Login Deskripsi
usecase ini menjelaskan seorang user yang akan masuk kedalam
sistem
Aktor yang terlibat Super Admin, Admin dan Sub
Admin Pre Condition
Actor harus memiliki username dan password yang terdaftar dalam
sistem
Trigger Actor ingin masuk ke dalam sistem
Basic Flows Kegiatan Actor
Respon Sistem Langkah 1:
Actor memasukan
username dan password
kemudian menekan
tombol masuk Langkah 2:
Sistem merespon dengan
mengarahkan user ke halaman
baranda
Alternate Flows Alternatif Langkah 2a: Jika user
tidak terdaftar dalam database sistem maka sistem akan
mengarahkan user ke halaman login
Post Condition Actor berada di halaman beranda
Aturan Bisnis
Gambar 4.9 Activity Diagram Login
2 Cek Host
Tabel 4.5 Use Case Scenario Cek Host Nama Use Case
Cek Host Deskripsi
usecase ini menjelaskan actor yang akan melihat daftar host yang ada
dalam sistem
Aktor yang terlibat Super Admin, Admin dan Sub
Admin Pre Condition
Actor harus memiliki username
dan password yang terdaftar dalam sistem
Trigger Usecase ini dimulai ketika actor
ingin melihat daftar host Basic Flows
Kegiatan Actor Respon Sistem
Langkah 1: Actor mengklik
menu utama Cek Host
Langkah 2: Sistem merespon
dengan mengarahkan ke
halaman cek host dengan
menampilkan daftar host yang
ada di database
Alternate Flows Post Condition
Actor dapat melihat daftar host yang ada dalam dalam sistem
Aturan Bisnis 1. Actor harus memiliki username
dan password yang sesuai.
Gambar 4.10 Activity Diagram Cek Host
3 Status Host
Tabel 4.6 Use Case Scenario Status Host Nama Use Case
Status Host Deskripsi
usecase ini menjelaskan actor yang akan melihat status host yang
ada dalam sistem
Aktor yang terlibat Super Admin, Admin dan Sub
Admin Pre Condition
Actor harus memiliki username dan password yang terdaftar
dalam sistem
Trigger Actor ingin melihat status host
Basic Flows Kegiatan Actor
Respon Sistem Langkah 1:
Actor mengklik menu utama
Cek Host Langkah 3:
Actor mengklik menu Status
pada salah satu host yang ada
pada daftar host Langkah 2:
Sistem merespon
dengan mengarahkan
ke halaman cek host dengan
menampilkan daftar host yang
ada di database Langkah 4:
Sistem merespon
dengan menampilkan
status host updown, port
Alternate Flows Post Condition
Actor dapat melihat status host yang ada pada daftar host
Aturan Bisnis 1. Actor harus memiliki username
dan password yang sesuai.
Gambar 4.11 Activity Diagram Status Host
4 Detail Host
Tabel 4.7 Use Case Scenario Detail Host Nama Use Case
Detail Host Deskripsi
usecase ini menjelaskan actor yang akan melihat informasi detail
host yang ada dalam sistem
Aktor yang terlibat Super Admin, Admin dan Sub
Admin Pre Condition
Actor harus memiliki username dan password yang terdaftar
dalam sistem
Trigger Actor ingin mengetahui informasi
host secara detail Basic Flows
Kegiatan Actor Respon Sistem
Langkah 1: Actor mengklik
menu utama Cek Host
Langkah 3: Actor mengklik
menu Detail pada salah satu
host yang ada pada daftar host
Langkah 2: Sistem
merespon dengan
mengarahkan ke halaman cek
host dengan menampilkan
daftar host yang ada di database
Langkah 4: Sistem
merespon dengan
mengarahkan ke halaman
Host Detail dan menampilkan
informasi host secara detail
Alternate Flows Post Condition
Actor dapat melihat informasi detail host yang ada pada daftar
host
Aturan Bisnis 1. Actor harus memiliki username
dan password yang sesuai.
Gambar 4.12 Activity Diagram Detail Host
5 Request Aktif
Tabel 4.8 Use Case Scenario Request Aktif Nama Use Case
Active Request Deskripsi
usecase ini menjelaskan actor yang akan melihat request url
yang sedang dilakukan oleh host
Aktor yang terlibat Super Admin, Admin dan Sub
Admin Pre Condition
Actor harus memiliki username dan password yang terdaftar
dalam sistem
Trigger actor ingin melihat request url
yang sedang dilakukan oleh host Basic Flows
Kegiatan Actor Respon Sistem
Langkah 1: Actor mengklik
menu utama Request Aktif
Langkah 2: Sistem
merespon dengan
mengarahkan ke halaman
request aktif untuk
menampilkan daftar request
url yang sedang aktif
Alternate Flows Post Condition
Actor dapat mengetahui kemana saja host melakukan request url
Aturan Bisnis 1. Actor harus memiliki username
dan password yang sesuai.
Gambar 4.13 Activity Diagram Request Aktif
6 Laporan
Tabel 4.9 Use Case Scenario Laporan Nama Use Case
Laporan Deskripsi
usecase ini menjelaskan actor yang akan melihat laporan hasil
monitoring yang dilakukan sistem
Aktor yang terlibat Super Admin, Admin dan Sub
Admin Pre Condition
Actor harus memiliki username dan password yang terdaftar
dalam sistem
Trigger Actor ingin melihat laporan hasil
monitoring Basic Flows
Kegiatan Actor Respon Sistem
Langkah 1: Langkah 2:
Actor menekan menu utama
Laporan Sistem
merespon dengan
menampilkan laporan hasil
monitoring
Alternate Flows Post Condition
Actor dapat melihat laporan hasil monitoring yang telah dilakukan
Aturan Bisnis 1. Actor harus memiliki username
dan password yang sesuai.
Gambar 4.14 Activity Diagram Laporan
7 Add Device
Tabel 4.10 Use Case Scenario Add Device Nama Use Case
Add Device Deskripsi
Usecase ini menjelaskan seorang actor yang akan menambahkan
data device baru.
Aktor yang terlibat Super Admin dan Admin
Pre Condition Actor harus memiliki username dan
password yang terdaftar dalam sistem
Trigger Adanya penambahan device yang
akan dimonitoring Basic Flows
Kegiatan Actor Respon Sistem
Langkah 1: Actor memilih
Langkah 2: Sistem merespon
menu utama Inventaris
Langkah 3: Actor mengklik
tombol Tambah Data Baru
Langkah 5: Actor mengisi
form tambah data baru
dengan informasi
device kemudian
mengklik tombol Tambah
dengan mengarahkan ke
halaman inventaris
Langkah 4: Sistem merespon
dengan menampilkan
form tambah data baru
Langkah 6: Sistem merespon
dengan menampilkan
notifikasi tambah data
berhasil
Alternate Flows Langkah 6a: Jika data yang
diisikan tidak valid sistem akan akan menampilkan pesan error dan
kembali menampikan form isian tambah data baru
Post Condition Data device baru telah masuk ke
dalam sistem Aturan Bisnis
1. Actor harus memiliki username dan password yang sesuai.
2. Hanya Super Admin dan Admin yang dapat mengakses menu
Inventaris
Gambar 4.15 Activity Diagram Add Device
8 Edit Device
Tabel 4.11 Use Case Scenario Edit Device Nama Use Case
Edit Device Deskripsi
Usecase ini menjelaskan seorang actor yang akan mengedit data
device yang telah ada dalam sistem
Aktor yang terlibat Super Admin dan Admin
Pre Condition Actor harus memiliki username
dan password yang terdaftar dalam sistem
Trigger Diperlukannya perubahan
terhadap data device yang telah ada dalam sistem
Basic Flows Kegiatan Actor
Respon Sistem Langkah 1:
Actor memilih menu utama
Inventaris Langkah 3:
Actor mengklik tombol Edit
Langkah 5: Actor mengisi
form isian edit data dengan
informasi device
kemudian mengklik
tombol Perbarui
Langkah 2: Sistem
merespon dengan
mengarahkan ke halaman
inventaris Langkah 4:
Sistem merespon
dengan menampilkan
form isian edit data
Langkah 6: Sistem
merespon dengan
menampilkan notifikasi edit
device berhasil
Alternate Flows Langkah 6a: Jika data yang
diisikan tidak valid sistem akan akan menampilkan pesan error
dan kembali menampikan form isian edit device
Post Condition Perubahan berhasil dilakukan
Aturan Bisnis 1. Actor harus memiliki username
dan password yang sesuai. 2. Hanya Super Admin dan Admin
yang dapat mengakses menu Inventaris
Gambar 4.16 Activity Diagram Edit Device
9 Delete Device
Tabel 4.12 Use Case Scenario Delete Device Nama Use Case
Delete Device Deskripsi
Usecase ini menjelaskan seorang actor yang akan menghapus data
device yang ada pada database
Aktor yang terlibat Super Admin dan Admin
Pre Condition Actor harus memiliki username
dan password yang terdaftar dalam sistem
Trigger Device tidak ada lagi dalam
lingkup monitoring Basic Flows
Kegiatan Actor Respon Sistem
Langkah 1: Actor memilih
menu utama Inventaris
Langkah 3: Actor memilih
device yang akan dihapus
Langkah 5: Actor mengklik
tombol Hapus yang terpilih
Langkah 2: Sistem
merespon dengan
mengarahkan ke halaman
inventaris Langkah 4:
Sistem merespon
dengan mengarahkan
ke halaman konfirmasi
penghapusan data device
Langkah 6: Sistem
merespon dengan
menampilkan notifikasi delete
device berhasil
Alternate Flows Langkah 5a: Actor mengklik
tombol Cancel Post Condition
Data device berhasil dihapus Aturan Bisnis
1. Actor harus memiliki username dan password yang sesuai.
2. Hanya Super Admin dan Admin yang dapat mengakses menu
Inventaris
Gambar 4.17 Activity Diagram Delete Device
10 Create User
Tabel 4.13 Use Case Scenario Create User Nama Use Case
Create User Deskripsi
Usecase ini menjelaskan seorang actor yang akan menambahkan
user baru.
Aktor yang terlibat Super Admin
Pre Condition Actor harus memiliki username dan
password yang terdaftar dalam sistem
Trigger Diperlukannya user baru dalam
sistem Basic Flows
Kegiatan Actor Respon Sistem
Langkah 1: Actor memilih
menu utama Pengguna
Langkah 3: Actor mengklik
menu Tambah Data Baru
Langkah 5: Actor mengisi
form dengan informasi user
login name, password,
nama, privilege
kemudian mengklik
tombol Tambah Langkah 2:
Sistem merespon dengan
mengarahkan ke halaman
pengguna Langkah 4:
Sistem merespon dengan
menampilkan form isian user
baru Langkah 6:
Sistem merespon dengan
menampilkan notifikasi create
user berhasil
Alternate Flows Langkah 6a: Jika data yang diisikan
tidak valid sistem akan akan menampilkan pesan error dan
kembali menampikan form isian create user
Post Condition User baru berhasil ditambahkan
dalam sistem Aturan Bisnis
1. Actor harus memiliki username dan password yang sesuai.
2. Hanya Super Admin yang dapat mengakses menu Pengguna
Gambar 4.18 Activity Diagram Create User
11 Edit User
Tabel 4.14 Use Case Scenario Edit User Nama Use Case
Edit User Deskripsi
Usecase ini menjelaskan seorang actor yang akan mengedit user
yang telah ada dalam sistem
Aktor yang terlibat Super Admin
Pre Condition Actor harus memiliki username
dan password yang terdaftar dalam sistem
Trigger Diperlukannya perubahan
terhadap informasi user yang ada Basic Flows
Kegiatan Actor Respon Sistem
Langkah 1: Actor memilih
menu utama Pengguna
Langkah 3: Actor mengklik
tombol Edit Langkah 5:
Actor mengisi form dengan
informasi user login name,
password, nama,
privilege kemudian
mengklik tombol
Perbarui Langkah 2:
Sistem merespon
dengan mengarahkan
ke halaman pengguna
Langkah 4: Sistem
merespon dengan
menampilkan form isian edit
user Langkah 6:
Sistem merespon
dengan menampilkan
notifikasi edit user berhasil
Alternate Flows Langkah 6a: Jika data yang
diisikan tidak valid sistem akan akan menampilkan pesan error
dan kembali menampikan form isian edit user
Post Condition Perubahan berhasil dilakukan
Aturan Bisnis 1. Actor harus memiliki username
dan password yang sesuai. 2. Hanya Super Admin yang dapat
mengakses menu Pengguna
Gambar 4.19 Activity Diagram Edit User
12 Delete User
Tabel 4.15 Use Case Scenario Delete User Nama Use Case
Delete User Deskripsi
Usecase ini menjelaskan seorang actor yang akan menghapus user
yang ada pada database
Aktor yang terlibat Super Admin
Pre Condition Actor harus memiliki username
dan password yang terdaftar dalam sistem
Trigger User sudah tidak ditugaskan untuk
memonitoring jaringan, sehingga tidak berhak lagi memakai sistem
Basic Flows Kegiatan Actor
Respon Sistem Langkah 1:
Actor memilih menu utama
Pengguna Langkah 3:
Actor memilih user yang akan
dihapus Langkah 5:
Actor mengklik tombol Hapus
yang terpilih Langkah 2:
Sistem merespon
dengan mengarahkan
ke halaman pengguna
Langkah 4: Sistem
merespon dengan
mengarahkan ke halaman
konfirmasi penghapusan
data user Langkah 6:
Sistem merespon
dengan menampilkan
notifikasi delete user berhasil
Alternate Flows Langkah 5a: Actor mengklik
tombol Cancel Post Condition
Data user berhasil dihapus Aturan Bisnis
1. Actor harus memiliki username dan password yang sesuai.
2. Hanya Super Admin yang dapat mengakses menu pengguna
Gambar 4.20 Activity Diagram Delete User
d. Sequence Diagram
