BAB III
METODOLOGI PENELITIAN DAN PERANCANGAN SISTEM
3.1 Metodologi Penelitian
Metode penelitian yang digunakan dalam perancangan dan pembangunan sistem Mobile Bulletin untuk implementasi Smart Poster menggunakan teknologi Near Field Communication (NFC) dan metode Salt Tokenization digambarkan pada Gambar 3.1. Adapun penjelasan dari tiap tahap penelitian, yaitu sebagai berikut.
Gambar 3.1 Metode Penelitian yang Digunakan
1. Studi Fisibilitas
Studi fisibilitas dilakukan untuk mengukur efektivitas dari penggunaan mading di Universitas Multimedia Nusantara (UMN). Pengukuran ini dilakukan dengan menggunakan kuesioner digital yang disebar secara online maupun melalui media sosial. Target responden dari kuesioner studi fisibilitas ini adalah mahasiswa UMN dengan jumlah minimal 30 orang dari tiap fakultas, yaitu Fakultas Teknologi Informasi dan Komunikasi, Fakultas Ilmu Komunikasi, Fakultas Seni dan Desain,
maupun Fakultas Bisnis. Pencarian dasar teori dari pembuatan kuesioner juga dilakukan pada tahap penelitian ini. Selain melalui kuesioner, studi fisibilitas juga dilakukan dengan mewawancarai Christian Wijasa selaku ketua Badan Eksekutif Mahasiswa (BEM) periode 2015/2016 sekaligus anggota Public Relation BEM periode 2014/2015.
2. Studi Literatur
Dalam studi literatur, pembelajaran terhadap berbagai teori yang berhubungan dengan perancangan, pembangunan, dan pengujian sistem Mobile Bulletin dilakukan. Teori-teori tersebut antara lain adalah studi fisibilitas, pengukuran efektivitas sistem informasi, pengukuran kegunaan (usability) sistem, Near Field Communication, Smart Poster, metode Tokenisasi, dan Salt.
3. Perancangan dan Pembuatan Sistem
Pada tahap ini dilakukan perancangan pada sistem Mobile Bulletin, baik secara konsep maupun teknis. Perancangan secara konsep meliputi arsitektur dari sistem secara keseluruhan, sedangkan perancangan teknis dilakukan dengan menggunakan diagram Unified Modeling Language (UML). Pada tahapan ini juga dilakukan perancangan desain antarmuka pengguna dari sistem yang dibangun.
4. Pengujian Sistem
Proses pengujian sistem dimulai dengan membuat satu buah Smart Poster yang ditanamkan NFC Tag sejumlah kategori jenis pengumuman mading UMN.
Terdapat sembilan kategori pengumuman mading yang telah didefinisikan oleh Public Relation BEM. Pengujian sistem dilakukan dengan menggunakan metode studi lapangan, dimana mahasiswa UMN mencoba menggunakan aplikasi mobile untuk mendapatkan informasi mading. Metode pengujian dengan studi lapangan
dilakukan agar dapat mengukur kegunaan dari sistem yang dibuat. Menurut Scholtz (2004), pengukuran kegunaan cocok dilakukan pada tahap akhir siklus pengembangan sistem. Pengukuran kegunaan sistem juga dilakukan karena merujuk pada penelitian sebelumnya oleh Ceipidor dkk. (2013) yang mengukur usability setelah sistem berhasil dibuat. Setelah mencoba, pengguna akan diberikan kuesioner mengenai pengalaman yang dirasakan ketika menggunakan aplikasi.
Pengujian content management system (CMS) terhadap administrator juga menggunakan metode yang sama dengan pengujian aplikasi mobile. Responden dari pengujian aplikasi mobile berjumlah minimal 30 orang dari tiap fakultas, sesuai ukuran sampel minimum yang dibutuhkan dalam suatu penelitan (Sugiyono, 2012).
5. Evaluasi Sistem
Evaluasi sistem dilakukan dengan menganalisis kuesioner yang dihasilkan dari studi lapangan pengujian sistem. Hasil evaluasi akan disimpulkan melalui penggunaan Skala Likert agar dapat mengukur kegunaan dari penerapan sistem Mobile Bulletin terhadap pemerolehan, penyebaran, dan pengelolaan informasi mading di UMN.
6. Penulisan Laporan
Setelah sistem yang dibuat selesai dievaluasi, penelitian dilanjutkan dengan penulisan laporan penelitian.
3.2 Variabel Penelitian
Pada studi fisibilitas, variabel penelitian yang digunakan untuk mengukur efektivitas mading digambarkan pada Gambar 3.2. Setiap variabel diukur dengan Skala Likert lima tingkat, lalu dihasilkan nilai persentase skor. Persentase skor dihitung dengan mencari rata-rata dari hasil rekapitulasi jawaban responden
menggunakan metode yang dijelaskan oleh Sugiyono (2012), lalu hasil tersebut dicocokkan dengan kategori interpretasi skor yang dijabarkan pada Tabel 3.1. Tabel 3.2 menunjukkan hasil perhitungan persentase skor tiap variabel dalam pengukuran efektivitas mading.
Gambar 3.2 Variabel Pengukuran Efektivitas Mading Tabel 3.1 Kategori Interpretasi Skor Skala Likert
Interval Kategori
Kepuasan Intensitas Kesetujuan Skor >= 80% Sangat Puas Sangat Sering Sangat Setuju
80% > Skor >= 60% Puas Sering Setuju
60% > Skor >= 40% Cukup Kadang-kadang Netral 40% > Skor >= 20% Tidak Puas Jarang Tidak Setuju
20% > Skor >= 0% Sangat Tidak
Puas Sangat Jarang Sangat Tidak Setuju
Tabel 3.2 Hasil Rekapitulasi Perhitungan Persentase Skor Pengukuran Efektivitas Mading
Variabel Persentase Skor Hasil
Kepuasan Pengguna 55.1% Cukup
Tingkat Penggunaan 44.9% Kadang-kadang
Performa 55.1% Netral
Kemudahan Pemakaian 57.2% Netral
Kemudahan Penyebaran Informasi 56.2% Netral
Adapun penjelasan dari hasil pengukuran tiap variabel, yaitu sebagai berikut.
a. Kepuasan pengguna
Kepuasan pengguna diukur melalui pertanyaan nomor enam pada lampiran kedua, yaitu “Apakah Anda sudah merasa puas dengan pemberitahuan informasi, baik informasi mengenai seminar, lomba, maupun lowongan pekerjaan, yang dilakukan melalui penempelan poster di mading UMN?”. Variabel ini mempengaruhi tujuan organisasi dan tingkat penggunaan mading secara sukarela (Cyrus, 1991). Berdasarkan Tabel 3.2, persentase skor kepuasan pengguna bernilai 55,1%. Hal ini menunjukkan bahwa tingat kepuasan mahasiswa UMN terhadap penyebaran informasi dengan penempelan poster di mading hanya sampai pada tingkatan cukup.
b. Tingkat Penggunaan Mading
Variabel tingkat penggunaan mading diukur melalui pertanyaan nomor lima pada lampiran kedua, yaitu “Seberapa sering anda mencari informasi di mading UMN?”. Berdasarkan Tabel 3.2, persentase skor tingkat penggunaan mading bernilai 44.9%. Hal ini menunjukkan bahwa tingkat penggunaan mading oleh
mahasiswa UMN hanya sampai pada frekuensi kadang-kadang atau sesekali waktu saja.
c. Performa Mading
Pengukuran tingkat penggunaan mading juga berhubungan dengan performa yang dihasilkan oleh mading itu sendiri. Performa mading diukur melalui tingkat kesetujuan dari pernyataan nomor tujuh pada lampiran kedua, yaitu
“Menurut Anda, penempelan pengumuman di mading UMN sudah dapat menyampaikan informasi kepada mahasiswa UMN secara efektif”. Berdasarkan Tabel 3.2, persentase skor performa mading bernilai 55.1%. Hal ini menunjukkan bahwa mahasiswa UMN masih belum berpendapat bahwa mading sudah menyebarkan informasi di lingkungan kampus secara efektif.
d. Kemudahan Pemakaian
Variabel kemudahan pemakaian mading diukur melalui kesetujuan terhadap pernyataan nomor delapan pada lampiran kedua, yaitu “Menurut Anda, penempelan pengumuman di mading UMN sudah memudahkan Anda dalam pencarian informasi yang Anda butuhkan”. Berdasarkan Tabel 3.2, persentase skor kemudahan pemakaian bernilai 57.2%. Hal ini menunjukkan bahwa mahasiswa UMN masih belum merasa penggunaan mading memudahkan pencarian informasi yang dibutuhkan.
e. Kemudahan Penyebaran Informasi
Variabel kemudahan penyebaran informasi diukur melalui kesetujuan terhadap pernyataan nomor sembilan pada lampiran kedua, yaitu “Menurut Anda, penempelan informasi di mading sudah memudahkan Anda untuk membagikan suatu informasi yang ada pada mading UMN kepada teman-teman Anda”.
Berdasarkan Tabel 3.2, persentase skor bernilai 56.2%. Hal ini menunjukkan bahwa mahasiswa UMN masih belum merasa penggunaan mading memudahkan penyebaran informasi ke teman-teman pembaca.
Pada tahap pengujian, dilakukan pengukuran kegunaan terhadap sistem yang dibangun. Variabel yang digunakan untuk mengukur kegunaan sistem mengacu pada teori pengukuran kegunaan yang dijelaskan oleh Nayebi dkk. (2012), yaitu efficiency, learnability, dan satisfaction. Pengukuran terhadap ketiga variabel ini menggunakan alat yang sama seperti yang dilakukan pada studi fisibilitas, yaitu dengan kuesioner dan Skala Likert. Alat ini dipilih karena mengacu pada penelitian sebelumnya yang dilakukan Rahadi (2014) dalam mengukur kegunaan aplikasi mobile dengan menggunakan kuesioner dan Skala Likert. Namun, dalam pengujian sistem terhadap administrator, tidak menggunakan kuesioner, melainkan dengan wawancara personal. Namun demikian, variabel yang diukur tetap sama seperti pengujian aplikasi mobile.
3.3 Teknik Pengumpulan Data
Pada tahap studi fisibilitas, data dikumpulkan dengan menggunakan kuesioner digital yang disebar secara online. Wawancara anggota ketua BEM periode 2015/2016 juga dilakukan untuk menambah keakuratan dari data yang didapat. Pada tahap pengujian, data dikumpulkan menggunakan metode studi lapangan dengan menyediakan aplikasi Android ke mahasiswa UMN dan menanyakan pengalaman dari pemakaian aplikasi tersebut dalam bentuk kuesioner.
Alat pengukur yang digunakan dalam pembuatan kedua kuesioner, baik pada studi fisibilitas maupun pengujian sistem, adalah Skala Likert lima tingkat. Pengumpulan
data saat pengujian sistem terhadap administrator dilakukan dengan teknik wawancara.
3.4 Teknik Pengambilan Sampel
Teknik pengambilan sampel yang digunakan pada penelitian ini, baik dalam studi fisibilitas, maupun pengujian sistem, adalah Proportionate Stratified Random Sampling (Dawson, 2009). Teknik pengambilan sampel ini digunakan karena mahasiswa UMN dipisahkan ke dalam empat fakultas sehingga anggota populasi UMN memiliki unsur yang tidak homogen. Penerapan teknik ini mengharuskan agar jumlah sampel yang diambil harus dapat mewakili setiap strata dalam populasi.
Menurut Roscoe dalam bukunya Research Methods for Business (Sugiyono, 2012), ukuran sampel yang layak untuk mewakili setiap strata minimal berjumlah 30. Oleh karena itu, pengumpulan data dari sampel dilakukan terhadap minimal 30 mahasiswa dari tiap fakultas di UMN.
3.5 Perancangan Sistem
Perancangan sistem Mobile Bulletin dimulai dengan membuat arsitektur secara keseluruhan, dilanjutkan dengan pembuatan database schema. Setelah itu, perancangan sistem dilanjutkan dengan membuat perancangan CMS, API, dan aplikasi mobile.
3.5.1 Arsitektur Sistem
Arsitektur sistem Mobile Bulletin secara keseluruhan ditunjukkan pada Gambar 3.3. Sistem Mobile Bulletin terdiri dari tiga jenis aplikasi, yaitu aplikasi mobile berbasis Android, web service (API), dan content management system (CMS) berbasis web. Seluruh data informasi pengumuman mading akan tersimpan
di dalam sebuah sistem basis data pada server. Aplikasi mobile ditujukan kepada mahasiswa UMN untuk mendapatkan informasi mading. Selain ditujukan untuk mahasiswa UMN, aplikasi mobile juga dapat digunakan oleh administrator untuk menulis token ke dalam NFC Tag di Smart Poster. Seluruh interaksi antara aplikasi mobile dengan sistem basis data server dikomunikasikan melalui web service, yaitu server yang melayani permintaan dari pengguna. Content management system (CMS) terdiri dari frontend dan backend. Backend ditujukan kepada administrator untuk mengelola informasi pengumuman mading UMN secara terkomputerisasi, sedangkan frontend dapat digunakan oleh mahasiswa UMN untuk melihat seluruh informasi mading secara online melalui situs yang disediakan.
Gambar 3.3 Arsitektur Sistem Mobile Bulletin
3.5.2 Database Schema
Gambar 3.4 Database Schema Sistem Mobile Bulletin
Setelah arsitektur sistem dibuat, perancangan dilanjutkan dengan membuat database schema terhadap sistem basis data yang akan digunakan. Gambar 3.4 menunjukkan database schema pada sistem basis data Mobile Bulletin. Schema yang dibuat terdiri dari 10 tables, yaitu Faculties, Categories, Locations, Users,
Roles, Tokens, Posters, Meta Posters, Faculty Poster, dan Access Histories. Table Faculties menyimpan informasi mengenai daftar fakultas yang ada di UMN, seperti fakultas Teknologi Informasi & Komunikasi, Desain Komunikasi Visual, Ilmu Komunikasi, dan Bisnis. Table Categories menyimpan informasi mengenai jenis kategori dari pengumuman poster di mading. Sesuai kebutuhan dari BEM UMN, pengumuman poster di mading dapat dikelompokkan menjadi sembilan kategori, yaitu peraturan kampus, acara kampus, rekrutmen, lomba, seminar, lowongan pekerjaan, akademik, media kampus, dan pengumuman lainnya. Table Locations menyimpan informasi mengenai daftar gedung kampus UMN. Table Roles menyimpan tingkatan akses administrator terhadap CMS Mobile Bulletin. Sesuai struktur organisasi BEM UMN, terdapat tiga tingkatan akses yang didefinisikan, yaitu ketua, koordinator, dan anggota. Seluruh data pengurus mading disimpan dalam table Users.
Table Tokens menyimpan informasi mengenai token yang dibuat dengan metode Salt Tokenization. Setiap token menyimpan informasi mengenai nama kategori dan lokasi yang diwakili. Table Posters menyimpan informasi mengenai poster pengumuman di mading. Setiap poster memiliki satu kategori sehingga table Categories dan Posters memiliki relasi one-to-many. Sebuah poster dapat ditujukan ke satu atau banyak fakultas dan sebuah fakultas dapat memiliki banyak poster sehingga hubungan antar kedua table ini bersifat many-to-many. Oleh karena hubungan many-to-many tersebut, dibuatlah sebuah pivot antara table Posters dan Faculties dengan nama Faculty Poster. Sebuah poster juga dapat memiliki satu atau banyak informasi tambahan yang disimpan dalam table Meta Posters. Poster yang berjenis acara (event), seperti seminar, lomba, ataupun acara-acara kampus lainnya,
dan bersifat dari dalam kampus (internal), dapat memiliki satu lokasi pelaksanaan acara. Tipe acara dan lokasi ini akan digunakan untuk melakukan penyorotan informasi mengenai acara, baik yang sedang maupun akan, dilaksanakan di lokasi yang diwakili token. Setiap pengaksesan informasi mading, baik melalui tapping NFC maupun scan QR-Code, disimpan ke dalam table Access Histories.
3.5.3 Perancangan Content Management System
Perancangan dari content management system (CMS), baik frontend maupun backend, dibuat dengan menggunakan konsep pemrograman berorientasi objek menurut buku System Analysis and Design (Dennis dkk., 2012). Adapun tiga diagram yang dibuat pada perancangan CMS, yaitu use case diagram, sequence diagram, dan class diagram.
A. Use Case Diagram
Gambar 3.5 menunjukkan use case diagram dari content management system (CMS) Mobile Bulletin. CMS yang dibuat terdiri dari frontend dan backend.
Backend digunakan oleh anggota Public Relation BEM dalam mengatur konten pada sistem basis data, sedangkan frontend digunakan oleh mahasiswa UMN untuk melihat daftar dan detail informasi poster secara keseluruhan. Aktor Administrator dalam use case diagram ditujukan bagi anggota Public Relation BEM, sedangkan Super Administrator ditujukan bagi koordinator bagian Public Relation dan ketua BEM. Aktor Pengguna dalam CMS ditujukan bagi mahasiswa UMN. Adapun penjelasan mengenai seluruh use case dari Gambar 3.5 ditunjukkan pada Tabel 3.3 sampai Tabel 3.31.
Gambar 3.5 Use Case Diagram dari Content Management System Mobile Bulletin
<< extend >>
Admin
Menampilkan Daftar Poster
Menampilkan Daftar Kategori
Menampilkan Daftar Gedung Kampus Menampilkan Daftar Fakultas
Menampilkan Daftar Token
Mengedit Poster Menghapus Poster
Menampilkan Detail Poster
Menambah Kategori
Mengedit Kategori
Menghapus Kategori
Menambah Gedung Kampus
Mengedit Gedung Kampus
Menghapus Gedung Kampus Menambah Fakultas
Mengedit Fakultas
Menghapus Fakultas
Menambah Token
Mengedit Token
Menghapus Token
Super Admin Menampilkan Daftar
Admin Menambah
Admin
Mengedit Peran Admin
Menghapus Admin
Menampilkan Data Diri Admin
Pengguna
<< extend >>
<< extend >>
<< extend >>
<< extend >>
<< extend >>
<< extend >>
<< extend >>
<< extend >>
<< extend >>
<< extend >>
<< extend >>
<< extend >>
<< extend >>
<< extend >>
<< extend >>
Logout
Login Mengedit Data
Diri Admin << extend >> Menambah Poster
Tabel 3.3 Use Case Proses Login Use Case Name Login.
Actor Administrator.
Description Kejadian ketika aktor masuk ke dalam backend CMS.
Trigger Aktor ingin masuk ke dalam backend CMS.
Normal Flow of Event
1. Aktor membuka laman Login dari backend CMS.
2. Aktor memasukkan data akun yang sesuai.
3. Sistem memeriksa data akun aktor.
4. Apabila data akun tidak ditemukan, maka sistem menampilkan laman Login dari backend CMS beserta pesan kesalahan.
5. Apabila data akun ditemukan, maka sistem mengarahkan aktor ke halaman awal backend CMS.
Pre-Condition Aktor membuka laman situs dari backend CMS.
Post-Condition Aktor berhasil masuk ke dalam backend CMS.
Tabel 3.4 Use Case Proses Logout Use Case Name Logout.
Actor Administrator.
Description Kejadian ketika aktor keluar dari backend CMS.
Trigger Aktor ingin keluar dari backend CMS.
Normal Flow of Event
1. Aktor memilih tombol Logout pada sistem.
2. Sistem menampilkan laman Login dari backend CMS.
Pre-Condition Aktor sudah masuk sebagai administrator ke dalam backend CMS.
Post-Condition Aktor berhasil keluar dari backend CMS.
Tabel 3.5 Use Case Proses Menampilkan Daftar Poster Use Case Name Menampilkan Daftar Poster.
Actor Administrator dan Pengguna.
Description Kejadian ketika aktor melihat daftar poster.
Trigger Aktor ingin melihat daftar poster.
Normal Flow of Event
1. Aktor membuka laman List Poster.
2. Sistem mengambil seluruh data dan menampilkannya di laman List Poster.
Pre-Condition Bagi administrator, aktor sudah masuk sebagai administrator ke dalam backend CMS.
Bagi pengguna, aktor sudah mengarahkan browser ke laman frontend CMS.
Post-Condition Aktor berhasil melihat daftar poster.
Tabel 3.6 Use Case Proses Menampilkan Detail Poster Use Case Name Menampilkan Detail Poster.
Actor Administrator dan Pengguna.
Description Kejadian ketika aktor melihat detail informasi dari poster yang dipilih.
Trigger Aktor ingin melihat detail informasi mengenai suatu poster.
Normal Flow of Event
1. Aktor menekan tombol View Detail pada poster yang ingin dilihat.
2. Sistem menampilkan laman Detail Poster sesuai poster yang dipilih.
Pre-Condition Aktor membuka laman List Posters.
Post-Condition Aktor berhasil melihat detail informasi poster.
Tabel 3.7 Use Case Proses Menambah Poster Use Case Name Menambah Poster.
Actor Administrator.
Description Kejadian ketika aktor menambah data poster.
Trigger Aktor ingin menambah data poster.
Normal Flow of Event
1. Aktor menekan tombol Add pada laman List Posters.
2. Sistem menampilkan laman Add Poster.
3. Aktor mengisi data-data poster yang dibutuhkan.
4. Apabila input tidak valid, sistem akan menampilkan notifikasi yang berisi pesan kesalahan input aktor.
5. Sistem menyimpan data poster terbaru.
Pre-Condition Aktor membuka laman List Posters.
Post-Condition Aktor berhasil menambah poster.
Tabel 3.8 Use Case Proses Menghapus Poster Use Case Name Menghapus Poster.
Actor Administrator.
Description Kejadian ketika aktor menghapus data poster tertentu.
Trigger Aktor ingin menghapus data poster tertentu.
Normal Flow of Event
1. Aktor menekan tombol Delete pada laman Detail Poster yang ingin dihapus.
2. Sistem menampilkan pesan konfirmasi.
3. Aktor memeriksa kembali nama poster yang ingin dihapus, kemudian klik tombol Yes.
4. Sistem menghapus poster dan menampilkan laman List Posters.
Pre-Condition Aktor membuka laman Detail Poster.
Post-Condition Aktor berhasil menghapus poster.
Tabel 3.9 Use Case Proses Mengedit Poster Use Case Name Mengedit Poster.
Actor Administrator.
Description Kejadian ketika aktor mengedit data poster tertentu.
Trigger Aktor ingin mengedit data poster tertentu.
Normal Flow of Event
1. Aktor menekan tombol Edit pada laman Detail Poster yang ingin diubah.
2. Sistem menampilkan laman Edit Poster.
3. Aktor mengisi data-data poster yang ingin diubah.
4. Apabila input tidak valid, sistem akan menampilkan notifikasi yang berisi pesan kesalahan input aktor.
5. Sistem menyimpan data poster terbaru.
Pre-Condition Aktor membuka laman Detail Poster.
Post-Condition Aktor berhasil mengedit poster.
Tabel 3.10 Use Case Proses Menampilkan Daftar Kategori Use Case Name Menampilkan Daftar Kategori.
Actor Administrator.
Description Kejadian ketika aktor melihat daftar kategori poster.
Trigger Aktor ingin melihat daftar kategori poster.
Normal Flow of Event
1. Aktor membuka laman List Categories.
2. Sistem mengambil seluruh data kategori dan menampilkannya di laman List Categories.
Pre-Condition Aktor sudah masuk sebagai administrator ke dalam backend CMS.
Post-Condition Aktor berhasil melihat daftar kategori poster.
Tabel 3.11 Use Case Proses Menambah Kategori Use Case Name Menambah Kategori.
Actor Administrator.
Description Kejadian ketika aktor menambah data kategori.
Trigger Aktor ingin menambah data kategori.
Normal Flow of Event
1. Aktor menekan tombol Add pada laman List Category.
2. Sistem menampilkan laman Add Category.
3. Aktor mengisi data-data kategori yang dibutuhkan.
4. Apabila input tidak valid, sistem akan menampilkan notifikasi yang berisi pesan kesalahan input aktor.
5. Sistem menyimpan data kategori terbaru.
Pre-Condition Aktor membuka laman List Categories.
Post-Condition Aktor berhasil menambah kategori.
Tabel 3.12 Use Case Proses Mengedit Kategori Use Case Name Mengedit Kategori.
Actor Administrator.
Description Kejadian ketika aktor mengedit data kategori tertentu.
Trigger Aktor ingin mengedit data kategori tertentu.
Normal Flow of Event
1. Aktor menekan tombol Edit pada baris data kategori yang ingin diubah.
2. Sistem menampilkan laman Edit Category.
3. Aktor mengisi data-data poster yang ingin diubah.
4. Apabila input tidak valid, sistem akan menampilkan notifikasi yang berisi pesan kesalahan input aktor.
5. Sistem menyimpan data kategori terbaru.
Pre-Condition Aktor membuka laman List Categories.
Post-Condition Aktor berhasil mengedit kategori.
Tabel 3.13 Use Case Proses Menghapus Kategori Use Case Name Menghapus Kategori.
Actor Administrator.
Description Kejadian ketika aktor menghapus data kategori tertentu.
Trigger Aktor ingin menghapus data kategori tertentu.
Normal Flow of Event
1. Aktor menekan tombol Delete pada baris data kategori yang ingin dihapus.
2. Sistem menampilkan pesan konfirmasi.
3. Aktor memeriksa kembali nama kategori yang ingin dihapus, kemudian klik tombol Yes.
4. Sistem menghapus kategori dan menampilkan laman List Categories.
Pre-Condition Aktor membuka laman List Categories.
Post-Condition Aktor berhasil menghapus kategori.
Tabel 3.14 Use Case Proses Menampilkan Daftar Gedung Kampus Use Case Name Menampilkan Daftar Gedung Kampus.
Actor Administrator.
Description Kejadian ketika aktor melihat daftar gedung kampus.
Trigger Aktor ingin melihat daftar gedung kampus.
Normal Flow of Event
1. Aktor membuka laman List Locations.
2. Sistem mengambil seluruh data gedung kampus dan menampilkannya di laman List Locations.
Pre-Condition Aktor sudah masuk sebagai administrator ke dalam backend CMS.
Post-Condition Aktor berhasil melihat daftar gedung kampus.
Tabel 3.15 Use Case Proses Menambah Gedung Kampus Use Case Name Menambah Gedung Kampus.
Actor Administrator.
Description Kejadian ketika aktor menambah data gedung kampus.
Trigger Aktor ingin menambah data gedung kampus.
Normal Flow of Event
1. Aktor menekan tombol Add pada laman List Locations.
2. Sistem menampilkan laman Add Location.
3. Aktor mengisi data-data gedung kampus yang dibutuhkan.
4. Apabila input tidak valid, sistem akan menampilkan notifikasi yang berisi pesan kesalahan input aktor.
5. Sistem menyimpan data gedung kampus terbaru.
Pre-Condition Aktor membuka laman List Locations.
Post-Condition Aktor berhasil menambah gedung kampus.
Tabel 3.16 Use Case Proses Mengedit Gedung Kampus Use Case Name Mengedit Gedung Kampus.
Actor Administrator.
Description Kejadian ketika aktor mengedit data gedung kampus tertentu.
Trigger Aktor ingin mengedit data gedung kampus tertentu.
Normal Flow of Event
1. Aktor menekan tombol Edit pada baris data gedung kampus yang ingin diubah.
2. Sistem menampilkan laman Edit Location.
3. Aktor mengisi data-data gedung kampus yang ingin diubah.
4. Apabila input tidak valid, sistem akan menampilkan notifikasi yang berisi pesan kesalahan input aktor.
5. Sistem menyimpan data gedung kampus terbaru.
Pre-Condition Aktor membuka laman List Locations.
Post-Condition Aktor berhasil mengedit gedung kampus.
Tabel 3.17 Use Case Proses Menghapus Gedung Kampus Use Case Name Menghapus Gedung Kampus.
Actor Administrator.
Description Event ketika aktor menghapus data gedung kampus tertentu.
Trigger Aktor ingin menghapus data gedung kampus tertentu.
Normal Flow of Event
1. Aktor menekan tombol Delete pada baris data gedung kampus yang ingin dihapus.
2. Sistem menampilkan pesan konfirmasi.
3. Aktor memeriksa kembali kode gedung kampus yang ingin dihapus, kemudian klik tombol Yes.
4. Sistem menghapus gedung kampus dan menampilkan laman List Locations.
Pre Condition Aktor membuka laman List Locations.
Post Condition Aktor berhasil menghapus gedung kampus.
Tabel 3.18 Use Case Proses Menampilkan Data Diri Administrator Use Case Name Menampilkan Data Diri Administrator.
Actor Administrator.
Description Kejadian ketika aktor melihat data diri aktor tersebut.
Trigger Aktor ingin melihat data diri aktor tersebut.
Normal Flow of Event
1. Aktor membuka laman Profile.
2. Sistem menampilkan laman Profile.
Pre-Condition Aktor sudah masuk sebagai administrator ke dalam backend CMS
Post-Condition Aktor berhasil melihat data diri aktor tersebut.
Tabel 3.19 Use Case Proses Mengedit Data Diri Administrator Use Case Name Mengedit Data Diri Administrator.
Actor Administrator
Description Kejadian ketika aktor mengedit data diri aktor tersebut.
Trigger Aktor ingin mengedit data diri aktor tersebut.
Normal Flow of Event
1. Aktor menekan tombol Edit pada laman Profile 2. Sistem menampilkan laman Edit Profile.
3. Aktor mengisi data-data diri yang ingin diubah.
4. Apabila input tidak valid, sistem akan menampilkan notifikasi yang berisi pesan kesalahan input aktor.
5. Sistem menyimpan data diri administrator terbaru.
Pre-Condition Aktor membuka laman Data Diri Administrator.
Post-Condition Aktor berhasil mengedit data diri aktor.
Tabel 3.20 Use Case Proses Menampilkan Daftar Fakultas Use Case Name Menampilkan Daftar Fakultas.
Actor Administrator.
Description Kejadian ketika aktor melihat daftar fakultas.
Trigger Aktor ingin melihat daftar fakultas.
Normal Flow of Event
1. Aktor membuka laman List Faculties.
2. Sistem mengambil seluruh data fakultas dan menampilkannya di laman List Faculties.
Pre-Condition Aktor sudah masuk sebagai administrator ke dalam backend CMS.
Post-Condition Aktor berhasil melihat daftar fakultas.
Tabel 3.21 Use Case Proses Menambah Fakultas Use Case Name Menambah Fakultas.
Actor Administrator.
Description Kejadian ketika aktor menambah data fakultas.
Trigger Aktor ingin menambah data fakultas.
Normal Flow of Event
1. Aktor menekan tombol Add pada laman List Faculties.
2. Sistem menampilkan laman Add Faculty.
3. Aktor mengisi data-data fakultas yang dibutuhkan.
4. Apabila input tidak valid, sistem akan menampilkan notifikasi yang berisi pesan kesalahan input aktor.
5. Sistem menyimpan data fakultas terbaru.
Pre-Condition Aktor membuka laman List Faculties.
Post-Condition Aktor berhasil menambah fakultas.
Tabel 3.22 Use Case Proses Mengedit Daftar Fakultas Use Case Name Mengedit Fakultas.
Actor Administrator.
Description Kejadian ketika aktor mengedit data fakultas tertentu.
Trigger Aktor ingin mengedit data fakultas tertentu.
Normal Flow of Event
1. Aktor menekan tombol Edit pada baris data fakultas yang ingin diubah.
2. Sistem menampilkan laman Edit Faculty.
3. Aktor mengisi data-data fakultas yang ingin diubah.
4. Apabila input tidak valid, sistem akan menampilkan notifikasi yang berisi pesan kesalahan input aktor.
5. Sistem menyimpan data fakultas terbaru.
Pre-Condition Aktor membuka laman List Faculties.
Tabel 3.23 Use Case Proses Menghapus Fakultas Use Case Name Menghapus Fakultas.
Actor Administrator.
Description Kejadian ketika aktor menghapus data fakultas tertentu.
Trigger Aktor ingin menghapus data fakultas tertentu.
Normal Flow of Event
1. Aktor menekan tombol Delete pada baris data fakultas yang ingin dihapus.
2. Sistem menampilkan pesan konfirmasi.
3. Aktor memeriksa kembali nama fakultas yang ingin dihapus, kemudian klik tombol Yes.
4. Sistem menghapus fakultas dan menampilkan laman List Faculties.
Pre-Condition Aktor membuka laman List Faculties.
Post-Condition Aktor berhasil menghapus fakultas.
Tabel 3.24 Use Case Proses Menampilkan Daftar Token Use Case Name Menampilkan Daftar Token.
Actor Administrator.
Description Kejadian ketika aktor melihat daftar token.
Trigger Aktor ingin melihat daftar token.
Normal Flow of Event
1. Aktor membuka laman List Tokens.
2. Sistem mengambil seluruh data token dan menampilkannya di laman List Tokens.
Pre-Condition Aktor sudah masuk sebagai administrator ke dalam backend CMS.
Post-Condition Aktor berhasil melihat daftar token.
Tabel 3.25 Use Case Proses Menambah Token Use Case Name Menambah Token.
Actor Administrator.
Description Kejadian ketika aktor menambah data token.
Trigger Aktor ingin menambah data token.
Normal Flow of Event
1. Aktor menekan tombol Add pada laman List Tokens.
2. Sistem menampilkan laman Add Token.
3. Aktor mengisi data-data yang dibutuhkan untuk membuat suatu token.
4. Apabila masukan tidak valid, sistem akan menampilkan notifikasi yang berisi pesan kesalahan input aktor.
5. Sistem menyimpan data token terbaru.
Pre-Condition Aktor membuka laman List Tokens.
Post-Condition Aktor berhasil menambah token.
Tabel 3.26 Use Case Proses Mengedit Token Use Case Name Mengedit Token.
Actor Administrator.
Description Kejadian ketika aktor mengedit data token tertentu.
Trigger Aktor ingin mengedit data token tertentu.
Normal Flow of Event
1. Aktor menekan tombol Edit pada baris data token yang ingin diubah.
2. Sistem menampilkan laman Edit Token.
3. Aktor mengisi data-data terkait token yang ingin diubah.
4. Apabila masukan tidak valid, sistem akan menampilkan notifikasi yang berisi pesan kesalahan input aktor.
5. Sistem menyimpan data token terbaru.
Pre-Condition Aktor membuka laman List Tokens.
Post-Condition Aktor berhasil mengedit data terkait token yang ingin diubah.
Tabel 3.27 Use Case Proses Menghapus Token Use Case Name Menghapus Token.
Actor Administrator.
Description Kejadian ketika aktor menghapus data token tertentu.
Trigger Aktor ingin menghapus data token tertentu.
Normal Flow of Event
1. Aktor menekan tombol Delete pada baris data token yang ingin dihapus.
2. Sistem menampilkan pesan konfirmasi.
3. Aktor memeriksa kembali token yang ingin dihapus, kemudian klik tombol Yes.
4. Sistem menghapus token dan menampilkan laman List Tokens.
Pre-Condition Aktor membuka laman List Tokens.
Post-Condition Aktor berhasil menghapus token.
Tabel 3.28 Use Case Proses Menampilkan Daftar Administrator Use Case Name Menampilkan Daftar Administrator.
Actor Super Administrator.
Description Kejadian ketika aktor melihat daftar administrator.
Trigger Aktor ingin melihat daftar administrator.
Normal Flow of Event
1. Aktor membuka laman List Admins.
2. Sistem menampilkan laman List Admins.
Pre-Condition Aktor sudah masuk sebagai admin ke dalam backend CMS dan memiliki peran sebagai Super Administrator.
Post-Condition Aktor berhasil melihat daftar administrator.
Tabel 3.29 Use Case Proses Menambah Administrator Use Case Name Menambah Administrator.
Actor Super Administrator.
Description Kejadian ketika aktor menambah data administrator.
Trigger Aktor ingin menambah data administrator.
Normal Flow of Event
1. Aktor menekan tombol Add pada laman List Admin.
2. Sistem menampilkan laman Add Admin.
3. Aktor mengisi data-data administrator yang dibutuhkan.
4. Apabila input tidak valid, sistem akan menampilkan notifikasi yang berisi pesan kesalahan input aktor.
5. Sistem menyimpan data administrator terbaru.
Pre-Condition Aktor membuka laman List Admins.
Post-Condition Aktor berhasil menambah administrator.
Tabel 3.30 Use Case Proses Mengedit Peran Administrator Use Case Name Mengedit Peran Administrator.
Actor Super Administrator.
Description Kejadian ketika aktor mengedit peran administrator tertentu.
Trigger Aktor ingin mengedit data peran administrator tertentu.
Normal Flow of Event
1. Aktor menekan tombol Edit Role pada baris data peran admin yang ingin diubah.
2. Sistem menampilkan laman Edit Role Admin.
3. Aktor mengubah peran administrator.
4. Sistem menyimpan data administrator terbaru.
Pre-Condition Aktor membuka laman List Admins.
Post-Condition Aktor berhasil mengedit peran administrator.
Tabel 3.31 Use Case Proses Menghapus Administrator Use Case Name Menghapus Administrator.
Actor Super Administrator.
Description Kejadian ketika aktor menghapus data administrator tertentu.
Trigger Aktor ingin menghapus data administrator tertentu.
Normal Flow of Event
1. Aktor menekan tombol Delete pada baris data administrator yang ingin dihapus.
2. Sistem menampilkan pesan konfirmasi.
3. Aktor memeriksa kembali nama administrator yang ingin dihapus, kemudian klik tombol Yes.
4. Sistem menghapus administrator.
Pre-Condition Aktor membuka laman List Admins.
Post-Condition Aktor berhasil menghapus administrator.
B. Sequence Diagram
Setelah use case diagram dibuat, perancangan CMS bagi administrator dilanjutkan dengan pembuatan sequence diagram dari tiap use case.
B.1 Sequence Diagram Login Administrator
Gambar 3.6 Sequence Diagram Proses Login Administrator
Sequence diagram proses login oleh administrator ditunjukkan pada Gambar 3.6, dengan penjelasan sebagai berikut.
1. Administrator memasukkan data akun yang sesuai di laman Login.
2. Laman Login mengirimkan data akun tersebut ke Controller.
3. Controller melakukan validasi terhadap data masukan administrator melalui User Validator.
4. User Validator mengirimkan kembali hasil validasi masukan pengguna beserta pesan kesalahan yang sesuai.
5. Controller mengirimkan data akun administrator ke Authentication untuk dilakukan proses autentikasi.
6. Authentication akan mengirimkan hasil autentikasi kembali ke Controller.
SequenceDiagram ProsesLogin
6: LoginAuthenticationMessage 4: ValidationMessage
7: loadPage() 2: sendEntryData() 1: entry()
5: attemptLogin() 3: validate()
Admin LoginPage AdminMainPage Ctrl UserValidator Authentication
6: LoginAuthenticationMessage 4: ValidationMessage
7: loadPage() 2: sendEntryData() 1: entry()
5: attemptLogin() 3: validate()
7. Controller menampilkan laman utama dari backend CMS.
B.2 Sequence Diagram Proses Logout Administrator
Gambar 3.7 Sequence Diagram Proses Logout Administrator
Sequence diagram proses logout oleh administrator ditunjukkan pada Gambar 3.7, dengan penjelasan sebagai berikut.
1. Administrator memilih menu Logout di laman backend CMS manapun.
2. Laman tersebut mengirimkan permintaan logout ke Controller.
3. Controller menjalankan prosedur logout melalui objek Authentication.
4. Controller menampilkan laman Login dari backend CMS.
B.3 Sequence Diagram Proses Menampilkan Daftar Poster
Sequence diagram proses menampilkan daftar poster, baik oleh administrator maupun pengguna, ditunjukkan pada Gambar 3.8, dengan penjelasan sebagai berikut.
1. Controller mengambil seluruh data poster melalui objek Poster Model.
2. Controller mengambil seluruh data kategori poster melalui objek Category Model.
SequenceDiagramProsesLogout
3: logout() 1: chooseLogoutMenu()
2: sendRequest()
4: loadPage()
Admin AdminPage LoginPage Ctrl Authentication
3: logout() 1: chooseLogoutMenu()
2: sendRequest()
4: loadPage()
3. Controller mengambil seluruh data fakultas melalui objek Faculty Model.
4. Setelah Controller mendapatkan ketiga jenis data tersebut, Controller akan menampilkan daftar poster di laman List Posters.
5. Pengguna ataupun administrator dapat memberikan parameter pencarian poster pada laman List Posters.
6. Laman List Posters akan mengirimkan permintaan pencarian tersebut ke Controller.
7. Controller akan mencari data poster yang sesuai dengan parameter pencarian melalui objek Poster Model.
8. Controller menampilkan data poster kembali ke laman List Posters.
Gambar 3.8 Sequence Diagram Proses Menampilkan Daftar Poster
B.4 Sequence Diagram Proses Menampilkan Detail Informasi Poster Sequence diagram proses menampilkan detail informasi poster, baik oleh administrator maupun pengguna, ditunjukkan pada Gambar 3.9, dengan penjelasan sebagai berikut.
SequenceDiagramProsesMenampilkanDaftarPoster
11: Posters 6: Faculties 4: Categories
2: Posters
12: displayPosters()
10: getPoster(searchParam) 9: sendRequest()
8: entrySearchParam()
7: displayPosters()
5: getFaculties() 3: getCategories()
1: getPosters()
Admin / Pengguna ListPostersPage Ctrl CategoryModel FacultyModel PosterModel
11: Posters 6: Faculties 4: Categories
2: Posters
12: displayPosters()
10: getPoster(searchParam) 9: sendRequest()
8: entrySearchParam()
7: displayPosters()
5: getFaculties() 3: getCategories()
1: getPosters()
1. Administrator ataupun pengguna memilih poster yang ingin ditampilkan secara detail pada laman List Posters.
2. Laman List Posters mengirimkan permintaan tersebut ke Controller.
3. Controller meminta detail informasi dari poster melalui Poster Model sesuai id yang dikirimkan.
4. Poster Model mengirimkan informasi detail poster kembali ke Controller.
5. Controller menampilkan detail informasi poster di laman Detail Poster.
Gambar 3.9 Sequence Diagram Proses Menampilkan Detail Informasi Poster
B.5 Sequence Diagram Proses Menambah Poster
Sequence diagram proses menambah poster oleh administrator ditunjukkan pada Gambar 3.10, dengan penjelasan sebagai berikut.
1. Controller mengambil seluruh data kategori, fakultas, dan lokasi sesuai model yang bersangkutan, lalu menampilkan laman Add Poster.
2. Administrator memasukkan data-data yang dibutuhkan untuk menambahkan poster, lalu laman tersebut mengirimkan data formulir ke Controller.
SequenceDiagramProsesMelihatDetailPoster
4: Poster 5: displayPoster()
3: getPosterDetail( id ) 2: sendRequest( id )
1: clickDetailButton()
Admin / Pengguna ListPostersPage DetailPosterPage Ctrl PosterModel
4: Poster 5: displayPoster()
3: getPosterDetail( id ) 2: sendRequest( id )
1: clickDetailButton()
3. Controller mengambil aturan validasi masukan administrator yang telah didefinisikan pada objek Poster Request, lalu melakukan validasi melalui objek Validator.
4. Validator mengirimkan konfirmasi hasil proses validasi masukan administrator.
5. Controller menyimpan data poster baru melalui objek Poster Model dan menampilkan pesan konfirmasi penambahan data poster di laman List Posters.
B.6 Sequence diagram Proses Mengedit Poster
Sequence diagram proses mengedit poster oleh administrator ditunjukkan pada Gambar 3.11, dengan penjelasan sebagai berikut.
1. Administrator menekan tombol Edit di laman Detail Poster, lalu Controller 2. Controller mengambil data kategori, fakultas, lokasi, dan poster sesuai model yang bersangkutan, lalu menampilkan laman formulir pengeditan poster.
3. Administrator mengubah data-data poster, lalu laman tersebut mengirimkan data formulir tersebut ke Controller.
4. Controller mengambil aturan validasi masukan yang telah didefinisikan pada objek Poster Request, lalu melakukan validasi melalui objek Validator.
5. Validator mengirimkan konfirmasi hasil proses validasi masukan administrator.
6. Controller menyimpan data poster terbaru melalui objek Poster Model dan menampilkan pesan konfirmasi pengeditan poster di laman Detail Poster.
59
Gambar 3.10 Sequence Diagram Proses Menambah Poster
SequenceDiagramMenambahPoster
13: ValidationMessage 11: Rules
6: Locations 4: Categories 2: Faculties
15: DisplayConfirmationMessage()
14: saveNewPoster() 12: validate( rules ) 10: getRules() 9: sendRequest()
8: entryData() 7: displayPage()
5: getLocations() 3: getCategories() 1: getFaculties()
AddPosterPage Ctrl Validator
Admin ListPostersPage FacultyModel CategoryModel LocationModel PosterRequest PosterModel
13: ValidationMessage 11: Rules
6: Locations 4: Categories 2: Faculties
15: DisplayConfirmationMessage()
14: saveNewPoster() 12: validate( rules ) 10: getRules() 9: sendRequest()
8: entryData() 7: displayPage()
5: getLocations() 3: getCategories() 1: getFaculties()
60
Gambar 3.11 Sequence Diagram Proses Mengedit Poster
SequenceDi agramMengeditPoster
17: ValidationMessage 15: Rules
10: Locations 8: Categories 6: Faculties
4: Poster 3: getPoster( id ) 2: sendRequest( id )
1: clickEditButton()
19: DisplayConfirmationMessage() 18: savePoster( id )
16: validate( rules ) 14: getRules() 13: sendRequest( id )
12: entryData()
11: displayPoster()
9: getLocations() 7: getCategories() 5: getFaculties()
EditPosterPage Ctrl Validator
Admin DetailPosterPage FacultyModel CategoryModel LocationModel PosterRequest PosterModel
17: ValidationMessage 15: Rules
10: Locations 8: Categories 6: Faculties
4: Poster 3: getPoster( id ) 2: sendRequest( id )
1: clickEditButton()
19: DisplayConfirmationMessage() 18: savePoster( id )
16: validate( rules ) 14: getRules() 13: sendRequest( id )
12: entryData()
11: displayPoster()
9: getLocations() 7: getCategories() 5: getFaculties()
B.7 Sequence Diagram Proses Menghapus Poster
Gambar 3.12 Sequence Diagram Proses Menghapus Poster
Sequence diagram proses menghapus poster oleh administrator ditunjukkan pada Gambar 3.12, dengan penjelasan sebagai berikut.
1. Administrator menekan tombol Delete pada laman Detail Poster.
2. Laman Detail Poster menampilkan kotak dialog konfirmasi penghapusan poster.
3. Administrator melakukan konfirmasi lalu permintaan tersebut dikirimkan ke Controller.
4. Controller menghapus data poster melalui objek Poster Model, lalu menampilkan pesan konfirmasi penghapusan poster ke laman List Posters.
B.8 Sequence Diagram Proses Menampilkan Daftar Kategori
Sequence diagram proses menampilkan daftar kategori oleh administrator ditunjukkan pada Gambar 3.13, dengan penjelasan sebagai berikut.
1. Controller mengambil seluruh data kategori melalui objek Category Model.
2. Controller menampilkan data kategori pada laman List Categories.
SequenceDiagramProsesMenghapusPoster
6: showConfirmationMessage()
5: deletePoster( id ) 4: sendRequest( id )
3: confirm()
2: showConfirmationMessage() 1: clickDeleteButton()
Admin ListPostersPage DetailPosterPage Ctrl PosterModel
6: showConfirmationMessage()
5: deletePoster( id ) 4: sendRequest( id )
3: confirm()
2: showConfirmationMessage() 1: clickDeleteButton()
3. Administrator dapat memberikan parameter pencarian di laman List Categories.
4. Laman List Categories mengirimkan parameter pencarian tersebut ke Controller.
5. Controller mengambil data kategori sesuai parameter pencarian melalui objek Category Model.
6. Controller menampilkan data hasil pencarian kategori ke laman List Categories.
Gambar 3.13 Sequence Diagram Proses Menampilkan Daftar Kategori
B.9 Sequence Diagram Proses Menghapus Kategori
Sequence diagram proses menghapus kategori oleh administrator ditunjukkan pada Gambar 3.14, dengan penjelasan sebagai berikut.
1. Administrator menekan tombol Delete pada baris data kategori tertentu di laman List Categories.
SequenceDiagramProsesMel ihatDaftarKategori
7: Categories 6: getCategories(searchParam) 5: SendRequest()
2: Categories
8: displayCategories() 4: entrySearchParam()
3: displayCategories()
1: getCategories()
Admin ListCategoriesPage Ctrl CategoryModel
7: Categories 6: getCategories(searchParam) 5: SendRequest()
2: Categories
8: displayCategories() 4: entrySearchParam()
3: displayCategories()
1: getCategories()
2. Laman List Categories menampilkan kotak dialog konfirmasi penghapusan kategori.
3. Administrator melakukan konfirmasi, lalu laman tersebut mengirimkan permintaan penghapusan kategori ke Controller.
4. Controller menghapus data kategori melalui Category Model, lalu menampilkan pesan konfirmasi penghapusan kategori di laman List Categories.
Gambar 3.14 Sequence Diagram Proses Menghapus Kategori
B.10 Sequence Diagram Proses Menambah Kategori
Sequence diagram proses menambah kategori oleh administrator ditunjukkan pada Gambar 3.15, dengan penjelasan sebagai berikut.
1. Administrator memasukkan data-data yang dibutuhkan dalam penambahan kategori pada laman Add Category, lalu laman tersebut mengirimkan data formulir penambahan kategori ke Controller.
SequenceDiagramProsesMenghapusKategori
6: showConfirmationMessage()
5: deleteCategory( id ) 1: clickDeleteButton()
3: confirm()
4: sendRequest( id ) 2: showConfirmationDialog()
Admin ListCategoriesPage Ctrl CategoryModel
6: showConfirmationMessage()
5: deleteCategory( id ) 1: clickDeleteButton()
3: confirm()
4: sendRequest( id ) 2: showConfirmationDialog()
