31
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,
Rancang bangun..., Audy, FTI UMN, 2016
32
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
Rancang bangun..., Audy, FTI UMN, 2016
33
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
Rancang bangun..., Audy, FTI UMN, 2016
34
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
Rancang bangun..., Audy, FTI UMN, 2016
35
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
Rancang bangun..., Audy, FTI UMN, 2016
36
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”.
Rancang bangun..., Audy, FTI UMN, 2016
37
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
Rancang bangun..., Audy, FTI UMN, 2016
38
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
Rancang bangun..., Audy, FTI UMN, 2016
39
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
Rancang bangun..., Audy, FTI UMN, 2016
40
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,
Rancang bangun..., Audy, FTI UMN, 2016
41
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,
Rancang bangun..., Audy, FTI UMN, 2016
42
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.
Rancang bangun..., Audy, FTI UMN, 2016
43
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 >>
LogoutLogin
Mengedit Data Diri Admin
<< extend >> Menambah Poster
Rancang bangun..., Audy, FTI UMN, 2016
44
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.
Rancang bangun..., Audy, FTI UMN, 2016
45
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.
Rancang bangun..., Audy, FTI UMN, 2016
46
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.
Rancang bangun..., Audy, FTI UMN, 2016
47
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.
Rancang bangun..., Audy, FTI UMN, 2016
48
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.
Rancang bangun..., Audy, FTI UMN, 2016
49
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.
Rancang bangun..., Audy, FTI UMN, 2016
50
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. Post-Condition Aktor berhasil mengedit fakultas.
Rancang bangun..., Audy, FTI UMN, 2016
51
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.
Rancang bangun..., Audy, FTI UMN, 2016
52
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.
Rancang bangun..., Audy, FTI UMN, 2016
53
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.
Rancang bangun..., Audy, FTI UMN, 2016
54
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.
SequenceDiagramProsesLogin
6: LoginAuthenticationMessage
4: ValidationMessage
7: loadPage()
2: sendEntryData()1: entry()
5: attemptLogin()
3: validate()
Admin Ctrl UserValidator AuthenticationLoginPage AdminMainPage
6: LoginAuthenticationMessage
4: ValidationMessage
7: loadPage()
2: sendEntryData()1: entry()
5: attemptLogin()
3: validate()
Rancang bangun..., Audy, FTI UMN, 2016
55
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 Ctrl AuthenticationAdminPage LoginPage
3: logout()
1: chooseLogoutMenu()2: sendRequest()
4: loadPage()
Rancang bangun..., Audy, FTI UMN, 2016
56
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 PosterModelCategoryModel FacultyModel
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()
Rancang bangun..., Audy, FTI UMN, 2016
57
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.
SequenceDiagramProsesMelihatDetai lPoster
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()
Rancang bangun..., Audy, FTI UMN, 2016
58
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.
Rancang bangun..., Audy, FTI UMN, 2016
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 ValidatorAdmin PosterRequestFacultyModel CategoryModel LocationModel PosterModelListPostersPage
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()
Rancang bangun..., Audy, FTI UMN, 2016
60
Gambar 3.11 Sequence Diagram Proses Mengedit Poster
SequenceDiagramMengeditPoster
17: ValidationMessage
15: Rules
10: Locations
8: Categories
6: Faculties
4: Poster3: 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 ValidatorAdmin PosterRequestFacultyModel CategoryModel LocationModel PosterModelDetailPosterPage
17: ValidationMessage
15: Rules
10: Locations
8: Categories
6: Faculties
4: Poster3: 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()
Rancang bangun..., Audy, FTI UMN, 2016
61
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 DetailPosterPage Ctrl PosterModelListPostersPage
6: showConfirmationMessage()5: deletePoster( id )
4: sendRequest( id )3: confirm()2: showConfirmationMessage()
1: clickDeleteButton()
Rancang bangun..., Audy, FTI UMN, 2016
62
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()
Rancang bangun..., Audy, FTI UMN, 2016
63
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()
Rancang bangun..., Audy, FTI UMN, 2016
64
2. Controller mengambil aturan validasi masukan melalui objek Category
Request, lalu melakukan validasi terhadap masukan pengguna melalui
objek Validator.
3. Validator mengirimkan konfirmasi hasil validasi masukan administrator.
4. Controller menyimpan data kategori baru melalui objek Category Model,
lalu menampilkan pesan konfirmasi penambahan kategori pada laman List
Categories.
B.11 Sequence Diagram Proses Mengedit Kategori
Sequence diagram proses mengedit kategori oleh administrator ditunjukkan
pada Gambar 3.16, dengan penjelasan sebagai berikut.
1. Administrator menekan tombol Edit pada baris data kategori di laman List
Categories.
2. Controller mengambil data kategori yang ingin diedit lalu menampilkannya
di laman Edit Category.
3. Administrator mengubah data-data kategori yang ingin diubah pada laman
Edit Category, lalu laman tersebut mengirimkan data formulir pengeditan
kategori ke Controller.
4. Controller mengambil aturan validasi masukan melalui objek Category
Request dan melakukan validasi terhadap masukan administrator melalui
objek Validator.
5. Validator mengirimkan konfirmasi hasil validasi masukan administrator.
6. Controller menyimpan data kategori yang telah diedit melalui objek
Category Model, lalu menampilkan pesan konfirmasi pengeditan kategori
pada laman List Categories.
Rancang bangun..., Audy, FTI UMN, 2016
65
Gambar 3.15 Sequence Diagram Proses Menambah Kategori
SequenceDiagramMenambahKategori
6: ValidationMessage
4: Rules
8: showConfirmationMessage()7: saveNewCategory()
5: validate( rules )
3: getRules()2: sendFormData()1: entryData()
Admin AddCategoryPage Ctrl CategoryRequest Validator CategoryModelListCategoriesPage
6: ValidationMessage
4: Rules
8: showConfirmationMessage()7: saveNewCategory()
5: validate( rules )
3: getRules()2: sendFormData()1: entryData()
Rancang bangun..., Audy, FTI UMN, 2016
66
Gambar 3.16 Sequence Diagram Proses Mengedit Kategori
SequenceDiagramProsesMengeditKategori
11: ValidationMesage
9: Rules
4: Category
7: sendRequest( id )6: entryData()5: showCategory()
3: getCategory( id )2: sendRequest( id )1: clickEditButton()
8: getRules()
10: validate( rules )
12: saveCategory( id )13: showConfirmationMessage()
Admin EditCategoryPage Ctrl CategoryRequest Validator CategoryModelListCategoriesPage
11: ValidationMesage
9: Rules
4: Category
7: sendRequest( id )6: entryData()5: showCategory()
3: getCategory( id )2: sendRequest( id )1: clickEditButton()
8: getRules()
10: validate( rules )
12: saveCategory( id )13: showConfirmationMessage()
Rancang bangun..., Audy, FTI UMN, 2016
67
B.12 Sequence Diagram Proses Menampilkan Daftar Gedung Kampus
Gambar 3.17 Sequence Diagram Proses Menampilkan Daftar Gedung Kampus
Sequence diagram proses menampilkan daftar gedung kampus oleh
administrator ditunjukkan pada Gambar 3.17, dengan penjelasan sebagai berikut.
1. Controller mengambil seluruh data gedung kampus melalui objek Location
Model, lalu menampilkan data gedung kampus pada laman List Locations.
2. Administrator dapat memberikan parameter pencarian di laman List
Locations.
3. Laman List Locations mengirimkan parameter pencarian tersebut ke
Controller, lalu mengambil data gedung kampus sesuai parameter pencarian
melalui objek Location Model.
4. Controller menampilkan data hasil pencarian gedung kampus ke laman List
Locations.
B.13 Sequence Diagram Proses Menghapus Gedung Kampus
Sequence diagram proses menghapus gedung kampus oleh administrator
ditunjukkan pada Gambar 3.18, dengan penjelasan sebagai berikut.
SequenceDiagramProsesMelihatDaftarGedungKampus
7: Locations8: displayLocations()
2: Locations1: getLocations()
3: displayLocations()4: entrySearchParam()
5: sendRequest()6: getLocations(searchParam)
Admin ListLocationsPage Ctrl LocationModel
7: Locations8: displayLocations()
2: Locations1: getLocations()
3: displayLocations()4: entrySearchParam()
5: sendRequest()6: getLocations(searchParam)
Rancang bangun..., Audy, FTI UMN, 2016
68
1. Administrator menekan tombol Delete pada baris data gedung kampus
tertentu di laman List Locations.
2. Laman List Locations menampilkan kotak dialog konfirmasi penghapusan
gedung kampus.
3. Administrator melakukan konfirmasi, lalu laman tersebut mengirimkan
permintaan penghapusan gedung kampus ke Controller.
4. Controller menghapus data gedung kampus melalui Location Model, lalu
menampilkan pesan konfirmasi penghapusan gedung kampus di laman List
Locations.
Gambar 3.18 Sequence Diagram Proses Menghapus Gedung Kampus
B.14 Sequence Diagram Proses Menampilkan Daftar Fakultas
Sequence diagram proses menampilkan daftar fakultas oleh administrator
ditunjukkan pada Gambar 3.19, dengan penjelasan sebagai berikut.
1. Controller mengambil seluruh data fakultas melalui objek Faculty Model.
2. Controller menampilkan data fakultas pada laman List Faculties.
3. Administrator dapat memberikan parameter pencarian di laman List
Faculties.
SequenceDiagramProsesMenghapusGedungKampus
2: showConfirmationDialog()
4: sendRequest( id )3: confirm()
1: clickDeleteButton()
5: deleteLocation( id )
6: showConfirmationMessage()
Admin ListLocationsPage Ctrl LocationModel
2: showConfirmationDialog()
4: sendRequest( id )3: confirm()
1: clickDeleteButton()
5: deleteLocation( id )
6: showConfirmationMessage()
Rancang bangun..., Audy, FTI UMN, 2016
69
4. Laman List Faculties mengirimkan parameter pencarian tersebut ke
Controller.
5. Controller mengambil data fakultas sesuai parameter pencarian melalui
objek Faculty Model.
6. Controller menampilkan data hasil pencarian fakultas ke laman List
Faculties.
Gambar 3.19 Sequence Diagram Proses Menampilkan Daftar Fakultas
B.15 Sequence Diagram Proses Menambah Gedung Kampus
Sequence diagram proses menambah gedung kampus oleh administrator
ditunjukkan pada Gambar 3.20, dengan penjelasan sebagai berikut.
1. Administrator memasukkan data-data yang dibutuhkan dalam penambahan
gedung kampus pada laman Add Location.
2. Laman Add Location mengirimkan data formulir penambahan gedung
kampus tersebut ke Controller.
3. Controller mengambil aturan validasi masukan administrator melalui objek
Location Request.
SequenceDiagramProsesMelihatDaftarFakultas
7: Faculties
2: Faculties1: getFaculties()
3: displayFaculties()4: entrySearchParam()
5: sendRequest()6: getFaculties(searchParam)
8: displayFaculties()
Admin ListFacultiesPage Ctrl FacultyModel
7: Faculties
2: Faculties1: getFaculties()
3: displayFaculties()4: entrySearchParam()
5: sendRequest()6: getFaculties(searchParam)
8: displayFaculties()
Rancang bangun..., Audy, FTI UMN, 2016
70
4. Controller melakukan validasi terhadap masukan pengguna melalui objek
Validator menggunakan aturan-aturan yang telah didapatkan sebelumnya.
5. Validator mengirimkan konfirmasi hasil validasi masukan administrator.
6. Controller menyimpan data gedung kampus baru melalui objek Location
Model, lalu menampilkan pesan konfirmasi penambahan gedung kampus
pada laman List Locations.
B.16 Sequence Diagram Proses Mengedit Gedung Kampus
Sequence diagram proses mengedit gedung kampus oleh administrator
ditunjukkan pada Gambar 3.21, dengan penjelasan sebagai berikut.
1. Administrator menekan tombol Edit pada baris data kategori di laman List
Locations.
2. Controller mengambil data gedung kampus yang ingin diedit lalu
menampilkannya di laman Edit Location.
3. Administrator mengubah data-data gedung kampus yang ingin diubah pada
laman Edit Location.
4. Laman Edit Location mengirimkan data formulir pengeditan gedung
kampus tersebut ke Controller.
5. Controller mengambil aturan validasi masukan melalui objek Location
Request, lalu melakukan validasi terhadap masukan administrator melalui
objek Validator.
6. Validator mengirimkan konfirmasi hasil validasi masukan administrator.
7. Controller menyimpan data gedung kampus yang telah diedit melalui objek
Location Model, lalu menampilkan pesan konfirmasi pengeditan gedung
kampus pada laman List Locations.
Rancang bangun..., Audy, FTI UMN, 2016
71
Gambar 3.20 Sequence Diagram Proses Menambah Gedung Kampus
SequenceDiagramProsesMenambahGedungKampus
6: ValidationMessage
4: Rules
1: entryData()2: sendFormData() 3: getRules()
5: validate( rules )
7: saveNewLocation()8: showConfirmationMessage()
Admin AddLocationPage Ctrl LocationRequest Validator LocationModelListLocationsPage
6: ValidationMessage
4: Rules
1: entryData()2: sendFormData() 3: getRules()
5: validate( rules )
7: saveNewLocation()8: showConfirmationMessage()
Rancang bangun..., Audy, FTI UMN, 2016
72
Gambar 3.21 Sequence Diagram Proses Mengedit Gedung Kampus
SequenceDiagramProsesMengeditGedungKampus
11: ValidationMessage
9: Rules
4: Location
13: showConfirmationMessage()12: saveLocation( id )
10: validate( rules )
8: getRules()
1: clickEditButton() 2: sendRequest( id ) 3: getLocation( id )
5: showLocation()6: entryData() 7: sendRequest( id )
Admin EditLocationPage Ctrl LocationRequest Validator LocationModelListLocationsPage
11: ValidationMessage
9: Rules
4: Location
13: showConfirmationMessage()12: saveLocation( id )
10: validate( rules )
8: getRules()
1: clickEditButton() 2: sendRequest( id ) 3: getLocation( id )
5: showLocation()6: entryData() 7: sendRequest( id )
Rancang bangun..., Audy, FTI UMN, 2016
73
B.17 Sequence Diagram Proses Menghapus Fakultas
Gambar 3.22 Sequence Diagram Proses Menghapus Fakultas
Sequence diagram proses menghapus fakultas oleh administrator
ditunjukkan pada Gambar 3.22, dengan penjelasan sebagai berikut.
1. Administrator menekan tombol Delete pada baris data fakultas tertentu di
laman List Faculties.
2. Laman List Faculties menampilkan kotak dialog konfirmasi penghapusan
fakultas.
3. Administrator melakukan konfirmasi, lalu laman tersebut mengirimkan
permintaan penghapusan fakultas ke Controller.
4. Controller menghapus data fakultas melalui Faculty Model, lalu
menampilkan pesan konfirmasi di laman List Faculties.
B.18 Sequence Diagram Proses Menampilkan Daftar Token
Sequence diagram proses menampilkan daftar token oleh administrator
ditunjukkan pada Gambar 3.23, dengan penjelasan sebagai berikut.
1. Controller mengambil seluruh data token melalui objek Token Model, lalu
menampilkan data tersebut pada laman List Tokens.
SequenceDiagramProsesMenghapusFakultas
2: showConfirmationDialog()
4: sendRequest( id )3: confirm()
1: clickDeleteButton()
5: deleteFaculty( id )
6: showConfirmationMessage()
Admin ListFacultiesPage Ctrl FacultyModel
2: showConfirmationDialog()
4: sendRequest( id )3: confirm()
1: clickDeleteButton()
5: deleteFaculty( id )
6: showConfirmationMessage()
Rancang bangun..., Audy, FTI UMN, 2016
74
2. Administrator dapat memberikan parameter pencarian di laman List
Tokens.
3. Laman List Tokens mengirimkan parameter pencarian tersebut ke
Controller.
4. Controller mengambil data token sesuai parameter pencarian melalui objek
Tokens Model.
5. Controller menampilkan data hasil pencarian tersebut ke laman List Tokens.
Gambar 3.23 Sequence Diagram Proses Menampilkan Daftar Token
B.19 Sequence Diagram Proses Menambah Fakultas
Sequence diagram proses menambah fakultas oleh administrator
ditunjukkan pada Gambar 3.24, dengan penjelasan sebagai berikut.
1. Administrator memasukkan data-data yang dibutuhkan dalam penambahan
fakultas pada laman Add Faculty.
2. Laman Add Faculty mengirimkan data formulir penambahan fakultas
tersebut ke Controller.
SequenceDiagramProsesMelihatDaftarAccessKey
7: Tokens
2: Tokens
1: getTokens()
3: displayTokens()4: entrySearchParam()
5: sendRequest()6: getTokens(searchParam)
8: displayTokens()
Admin ListTokensPage Ctrl TokensModel
7: Tokens
2: Tokens
1: getTokens()
3: displayTokens()4: entrySearchParam()
5: sendRequest()6: getTokens(searchParam)
8: displayTokens()
Rancang bangun..., Audy, FTI UMN, 2016
75
3. Controller mengambil aturan validasi masukan melalui objek Faculty
Request, lalu melakukan validasi terhadap masukan administrator melalui
objek Validator.
4. Validator mengirimkan konfirmasi hasil validasi masukan administrator.
5. Controller menyimpan data kategori baru melalui objek Faculty Model, lalu
menampilkan pesan konfirmasi penambahan fakultas pada laman List
Faculties.
B.20 Sequence Diagram Proses Mengedit Fakultas
Sequence diagram proses mengedit fakultas oleh administrator ditunjukkan
pada Gambar 3.25, dengan penjelasan sebagai berikut.
1. Administrator menekan tombol Edit pada baris data fakultas di laman List
Faculties.
2. Controller mengambil data fakultas yang ingin diedit lalu menampilkannya
di laman Edit Faculty.
3. Administrator mengubah data-data fakultas yang ingin diubah pada laman
Edit Faculty, lalu laman tersebut mengirimkan data formulir pengeditan
fakultas ke Controller.
4. Controller mengambil aturan validasi masukan administrator dari objek
Faculty Request, lalu melakukan validasi terhadap masukan administrator
melalui objek Validator.
5. Validator mengirimkan konfirmasi hasil validasi masukan administrator.
6. Controller menyimpan data fakultas yang telah diedit melalui objek Faculty
Model, lalu menampilkan pesan konfirmasi pengeditan fakultas pada laman
List Faculties.
Rancang bangun..., Audy, FTI UMN, 2016
76
Gambar 3.24 Sequence Diagram Proses Menambah Fakultas
SequenceDiagramProsesMenambahFakultas
6: ValidationMessage
4: Rules
1: entryData()2: sendFormData() 3: getRules()
5: validate( rules )
7: saveNewFaculty()8: showConfirmationMessage()
Admin AddFacultyPage Ctrl FacultyRequest Validator FacultyModelListFacultiesPage
6: ValidationMessage
4: Rules
1: entryData()2: sendFormData() 3: getRules()
5: validate( rules )
7: saveNewFaculty()8: showConfirmationMessage()
Rancang bangun..., Audy, FTI UMN, 2016
77
Gambar 3.25 Sequence Diagram Proses Mengedit Fakultas
SequenceDiagramProsesMengeditFakultas
11: ValidationMessage
9: Rules
4: Faculty
13: showConfirmationMessage()12: saveFaculty( id )
10: validate( rules )
8: getRules()
1: clickEditButton() 2: sendRequest( id ) 3: getFaculty( id )
5: showFaculty()6: entryData() 7: sendRequest( id )
Admin EditFacultyPage Ctrl FacultyRequest Validator FacultyModelListFacultiesPage
11: ValidationMessage
9: Rules
4: Faculty
13: showConfirmationMessage()12: saveFaculty( id )
10: validate( rules )
8: getRules()
1: clickEditButton() 2: sendRequest( id ) 3: getFaculty( id )
5: showFaculty()6: entryData() 7: sendRequest( id )
Rancang bangun..., Audy, FTI UMN, 2016
78
B.21 Sequence Diagram Proses Menghapus Token
Sequence diagram proses menghapus token oleh administrator ditunjukkan
pada Gambar 3.26, dengan penjelasan sebagai berikut.
Gambar 3.26 Sequence Diagram Proses Menghapus Token
1. Administrator menekan tombol Delete pada baris data token tertentu di
laman List Tokens.
2. Laman List Tokens menampilkan kotak dialog konfirmasi penghapusan
token.
3. Administrator melakukan konfirmasi, lalu laman tersebut mengirimkan
permintaan penghapusan token ke Controller.
4. Controller menghapus data token melalui Token Model, lalu menampilkan
pesan konfirmasi penghapusan token di laman List Tokens.
B.22 Sequence Diagram Proses Menampilkan Daftar Administrator
Sequence diagram proses menampilkan daftar administrator oleh Super
Administrator ditunjukkan pada Gambar 3.27, dengan penjelasan sebagai berikut.
1. Controller mengambil seluruh data administrator melalui objek User Model,
lalu menampilkan data tersebut pada laman List Admins.
SequenceDiagramProsesMenghapusAccessKey
2: showConfirmationDialog()
4: sendRequest( id )3: confirm()
1: clickDeleteButton()
5: deleteToken( id )
6: showConfirmationMessage()
Admin ListTokensPage Ctrl TokenModel
2: showConfirmationDialog()
4: sendRequest( id )3: confirm()
1: clickDeleteButton()
5: deleteToken( id )
6: showConfirmationMessage()
Rancang bangun..., Audy, FTI UMN, 2016
79
2. Super Administrator dapat memberikan parameter pencarian di laman List
Admins, lalu laman tersebut mengirimkan parameter pencarian ke
Controller.
3. Controller mengambil data administrator sesuai parameter pencarian
melalui objek User Mode, lalu menampilkan data pencarian tersebut ke
laman List Admins.
Gambar 3.27 Sequence Diagram Proses Menampilkan Daftar Administrator
B.23 Sequence Diagram Proses Menambah Token
Sequence diagram proses menambah token oleh administrator ditunjukkan
pada Gambar 3.28, dengan penjelasan sebagai berikut.
1. Controller mengambil data seluruh lokasi dan kategori melalui objek Model
yang bersangkutan, lalu menampilkan laman Add Token.
2. Administrator memasukkan data-data yang dibutuhkan dalam penambahan
kode akses pada laman Add Token, lalu laman tersebut mengirimkan data
formulir penambahan kode akses tersebut ke Controller.
SequenceDiagramProsesMelihatDaftarAdmin
7: Users
2: Users
8: displayUsers()
6: getUsers(searchParam)5: sendRequest()
4: entrySearchParam()
3: displayUsers()
1: getUsers()
SuperAdmin ListAdminsPage Ctrl UserModel
7: Users
2: Users
8: displayUsers()
6: getUsers(searchParam)5: sendRequest()
4: entrySearchParam()
3: displayUsers()
1: getUsers()
Rancang bangun..., Audy, FTI UMN, 2016
80
3. Controller mengambil aturan validasi masukan melalui objek Token
Request, lalu melakukan validasi terhadap masukan administrator melalui
objek Validator.
4. Validator mengirimkan konfirmasi hasil validasi masukan administrator.
5. Controller menyimpan data token baru melalui objek Token Model, lalu
menampilkan pesan konfirmasi penambahan token pada laman List Tokens.
B.24 Sequence Diagram Proses Mengedit Token
Sequence diagram proses mengedit token oleh administrator ditunjukkan
pada Gambar 3.29, dengan penjelasan sebagai berikut.
1. Administrator menekan tombol Edit pada baris data token di laman List
Tokens.
2. Controller mengambil seluruh data lokasi gedung kampus, kategori, token
yang ingin diedit melalui objek Model yang bersangkutan.
3. Setelah semua data yang diperlukan didapatkan, Controller menampilkan
data-data tersebut di laman Edit Token.
4. Administrator mengubah data-data token yang ingin diubah pada laman Edit
Token, lalu laman tersebut a mengirimkan data formulir pengeditan token
ke Controller.
5. Controller mengambil aturan validasi masukan melalui objek Token
Request, lalu melakukan validasi terhadap masukan administrator melalui
objek Validator.
6. Validator mengirimkan konfirmasi hasil validasi masukan administrator.
7. Controller menyimpan data token yang telah diedit melalui objek Token
Model, lalu menampilkan pesan konfirmasi pada laman List Tokens.
Rancang bangun..., Audy, FTI UMN, 2016
81
Gambar 3.28 Sequence Diagram Proses Menambah Token
SequenceDiagramProsesMenambahAccessKey
11: ValidationMessage
9: Rules
4: Locations
2: Categories
5: displayPage()
3: getLocations()
1: getCategories()
6: entryData()7: sendFormData() 8: getRules()
10: validate( rules )
12: saveNewToken()13: showConfirmationMessage()
Admin AddTokenPage Ctrl TokenRequest Validator TokenModelListTokensPage LocationModelCategoryModel
11: ValidationMessage
9: Rules
4: Locations
2: Categories
5: displayPage()
3: getLocations()
1: getCategories()
6: entryData()7: sendFormData() 8: getRules()
10: validate( rules )
12: saveNewToken()13: showConfirmationMessage()
Rancang bangun..., Audy, FTI UMN, 2016
82
Gambar 3.29 Sequence Diagram Proses Mengedit Token
SequenceDiagramProsesMengeditAccessKey
15: ValidationMessage
13: Rules
8: Category
6: Locations
4: Categories
5: getLocations()
3: getCategories()
17: showConfirmationMessage() 16: saveToken( id )
14: validate( rules )
12: getRules()
1: clickEditButton() 2: sendRequest( id )
7: getCategory( id )
9: showCategory()10: entryData()
11: sendRequest( id )
Admin EditTokenPage Ctrl TokenRequest Validator TokenModelListTokensPage CategoryModel LocationModel
15: ValidationMessage
13: Rules
8: Category
6: Locations
4: Categories
5: getLocations()
3: getCategories()
17: showConfirmationMessage() 16: saveToken( id )
14: validate( rules )
12: getRules()
1: clickEditButton() 2: sendRequest( id )
7: getCategory( id )
9: showCategory()10: entryData()
11: sendRequest( id )
Rancang bangun..., Audy, FTI UMN, 2016
83
B.25 Sequence Diagram Proses Menambah Administrator
Sequence diagram proses menambah administrator oleh Super
Administrator ditunjukkan pada Gambar 3.30, dengan penjelasan sebagai berikut.
1. Controller mengambil data peran administrator, seperti ketua, koordinator,
dan anggota, melalui objek Role Model, lalu menampilkan laman Add
Admin.
2. Super Administrator memasukkan data-data yang dibutuhkan dalam
penambahan administrator pada laman Add Admin, lalu laman tersebut
mengirimkan data formulir penambahan administrator ke Controller.
3. Controller mengambil aturan validasi masukan yang diperlukan dalam
menambahkan administrator melalui objek User Request, lalu melakukan
validasi terhadap masukan Super Administrator melalui objek Validator.
4. Validator mengirimkan konfirmasi hasil validasi masukan Super
Administrator.
5. Controller menyimpan data administrator baru melalui objek User Model,
lalu menampilkan pesan konfirmasi penambahan administrator pada laman
List Admins.
B.26 Sequence Diagram Proses Mengedit Peran Administrator
Sequence diagram proses mengedit peran administrator oleh Super
Administrator ditunjukkan pada Gambar 3.31, dengan penjelasan sebagai berikut.
1. Super Administrator menekan tombol Edit Role pada baris data
administrator di laman List Admins.
2. Controller mengambil data peran dari administrator yang ingin diedit lalu
menampilkannya di laman Edit Role Admin.
Rancang bangun..., Audy, FTI UMN, 2016
84
3. Super Administrator mengubah data peran administrator pada laman Edit
Role Admin., lalu laman tersebut mengirimkan data formulir pengeditan
peran administrator ke Controller.
4. Controller mengambil aturan validasi masukan yang diperlukan dalam
mengubah peran administrator melalui objek User Request, lalu melakukan
validasi terhadap masukan Super Administrator melalui objek Validator.
5. Validator mengirimkan konfirmasi hasil validasi masukan pengubahan
peran administrator.
6. Controller menyimpan data administrator yang telah diedit melalui objek
User Model, lalu menampilkan pesan konfirmasi pengeditan peran
administrator pada laman List Admins.
B.27 Sequence Diagram Proses Menghapus Administrator
Gambar 3.30 Sequence Diagram Proses Menghapus Administrator
Sequence diagram proses menghapus administrator oleh Super
Administrator ditunjukkan pada Gambar 3.32, dengan penjelasan sebagai berikut.
1. Super Administrator menekan tombol Delete pada baris data administrator
tertentu di laman List Admins.
SequenceDiagramProsesMenghapusAdmin
6: showConfirmationMessage()
5: deleteAdmin( id )
1: clickDeleteButton()
3: confirm()4: sendRequest( id )
2: showConfirmationDialog()
Admin ListAdminsPage Ctrl UserModel
6: showConfirmationMessage()
5: deleteAdmin( id )
1: clickDeleteButton()
3: confirm()4: sendRequest( id )
2: showConfirmationDialog()
Rancang bangun..., Audy, FTI UMN, 2016
85
Gambar 3.31 Sequence Diagram Proses Menambah Administrator
SequenceDiagramProsesMenambahAdmin
9: ValidationMessage
7: Rules
2: Roles3: displayPage()
1: getRoles()
11: showConfirmationMessage()10: saveNewAdmin()
8: validate( rules )
6: getRules()5: sendFormData()4: entryData()
Admin AddAdminPage Ctrl UserRequest Validator UserModelListAdminsPage RoleModel
9: ValidationMessage
7: Rules
2: Roles3: displayPage()
1: getRoles()
11: showConfirmationMessage()10: saveNewAdmin()
8: validate( rules )
6: getRules()5: sendFormData()4: entryData()
Rancang bangun..., Audy, FTI UMN, 2016
86
Gambar 3.32 Sequence Diagram Proses Mengedit Peran Administrator
SequenceDiagramProsesMengeditPeranAdmin
13: ValidationMessage
11: Rules
6: AdminRole
4: Roles3: getRoles()
9: sendRequest( id )8: entryData()
7: showAdminRole()
5: getAdminRole( id )
2: sendRequest( id )1: clickEditButton()
10: getRules()
12: validate( rules )
14: saveAdmin( id )15: showConfirmationMessage()
Admin EditRoleAdminPage Ctrl UserRequest Validator UserModelListAdminsPage RoleModel
13: ValidationMessage
11: Rules
6: AdminRole
4: Roles3: getRoles()
9: sendRequest( id )8: entryData()
7: showAdminRole()
5: getAdminRole( id )
2: sendRequest( id )1: clickEditButton()
10: getRules()
12: validate( rules )
14: saveAdmin( id )15: showConfirmationMessage()
Rancang bangun..., Audy, FTI UMN, 2016
87
2. Laman List Admins menampilkan kotak dialog konfirmasi penghapusan
administrator.
3. Super Administrator melakukan konfirmasi, lalu laman tersebut
mengirimkan permintaan penghapusan administrator ke Controller.
4. Controller menghapus data administrator melalui User Model, lalu
menampilkan pesan konfirmasi penghapusan administrator di laman List
Admins.
B.26 Sequence Diagram Proses Mengedit Data Diri
Sequence diagram proses mengedit data diri oleh administrator ditunjukkan
pada Gambar 3.33, dengan penjelasan sebagai berikut.
1. Administrator menekan tombol Edit Profile pada laman Profile.
2. Laman Profile mengirimkan permintaan pengeditan data diri administrator
ke Controller beserta ID dari administrator yang sedang masuk di dalam
backend CMS.
3. Controller mengambil data diri administrator melalui objek User Model lalu
menampilkannya di laman Edit Profile.
4. Administrator melakukan pengeditan terhadap data diri yang ingin diubah.
5. Controller mengambil aturan validasi masukan melalui objek User Request,
lalu melakukan validasi terhadap masukan administrator melalui objek
Validator.
6. Validator mengirimkan konfirmasi hasil validasi masukan administrator.
7. Controller menyimpan data administrator terbaru melalui objek User
Model, lalu menampilkan pesan konfirmasi pengeditan data diri
administrator di laman Profile.
Rancang bangun..., Audy, FTI UMN, 2016
88
Gambar 3.33 Sequence Diagram Proses Mengedit Data Diri
SequenceDiagramProsesMengubahDataDiriAdmin
11: ValidationMessage
9: Rules
4: Profile
10: validate( rules )
8: getRules()7: sendRequest( id )
6: entryData()5: displayProfile()
3: getProfile( id )2: sendRequest( id )
1: clickEditButton()
13: showConfirmationMessage()12: saveAdmin( id )
ProfilePage Ctrl UserModelAdmin UserRequest ValidatorEditProfilePage
11: ValidationMessage
9: Rules
4: Profile
10: validate( rules )
8: getRules()7: sendRequest( id )
6: entryData()5: displayProfile()
3: getProfile( id )2: sendRequest( id )
1: clickEditButton()
13: showConfirmationMessage()12: saveAdmin( id )
Rancang bangun..., Audy, FTI UMN, 2016
89
B.28 Sequence Diagram Proses Menampilkan Data Diri Administrator
Gambar 3.34 Sequence Diagram Proses Menampilkan Data Diri Administrator
Sequence diagram proses menampilkan data diri oleh administrator
ditunjukkan pada Gambar 3.34, dengan penjelasan sebagai berikut.
1. Controller mengambil data ID dari administrator yang sedang berada di
dalam backend CMS melalui objek Authentication.
2. Authentication mengembalikan data ID administrator ke Controller.
3. Controller mengambil data diri administrator berdasarkan ID yang telah
didapat melalui objek User Model, lalu menampilkan data tersebut di laman
Profile.
C. Class Diagram
Setelah use case dan sequence diagram dibuat, perancangan CMS Mobile
Bulletin dilanjutkan dengan membuat class diagram seperti yang ditunjukkan
Gambar 3.35. Dalam perancangan, CMS terdiri dari lima class utama, yaitu
Controller, Validator, Model, Request, dan Authentication. Class Controller
memiliki tujuh class turunan, yaitu Poster Controller, Category Controller, Faculty
SequenceDiagramProsesMelihatDataDiriAdmin
4: ProfileAdmin
2: LoggedAdminID
1: getLoggedAdminID()
3: getProfileAdmin( id )
5: displayProfile()
ProfilePage Ctrl UserModelAuthentication
4: ProfileAdmin
2: LoggedAdminID
1: getLoggedAdminID()
3: getProfileAdmin( id )
5: displayProfile()
Rancang bangun..., Audy, FTI UMN, 2016
90
Controller, Token Controller, User Controller, Location Controller, dan Auth
Controller. Controller berfungsi sebagai penghubung dan pengatur dari setiap class
lainnya sesuai fungsi yang dijalankan, contohnya adalah Poster Controller
digunakan untuk mengatur dan menghubungkan segala proses yang berkaitan
dengan data poster. Setiap turunan dari class Controller dapat berhubungan dengan
satu ataupun lebih class turunan Model. Class turunan dari Model
merepresentasikan suatu table tertentu di dalam sistem basis data, contoh Model
dapat memiliki class turunan Poster Model yang mewakili table Posters. Class
Model juga berperan sebagai penyedia fitur-fitur dasar manajemen terhadap data
sesuai table yang direpresentasikan, seperti melihat, menambah, mengubah, dan
menghapus data.
Request merepresentasikan objek formulir yang dikirimkan dari laman situs
ke Controller. Request dapat memiliki beberapa class turunan sesuai objek formulir
yang diwakilkan, contohnya adalah Poster Request merupakan class turunan dari
Request yang mewakili objek formulir dari penambahan ataupun pengeditan data
poster. Setiap Controller berhubungan dengan satu objek Request sesuai fungsi
yang dijalankan. Pada Request didefinisikan serangkaian aturan dan pesan
kesalahan masukan pengguna sesuai objek yang bersangkutan. Validator
merupakan class untuk melakukan validasi terhadap masukan pengguna
berdasarkan aturan yang telah didefinisikan pada Request dan mengembalikan
daftar kesalahan masukan kembali ke Controller. Class Authentication digunakan
untuk melakukan autentikasi pada saat proses login dan logout dijalankan oleh Auth
Controller. Selain proses login dan logout, Authentication juga digunakan untuk
mengembalikan data ID dari administrator yang sedang masuk ke dalam sistem.
Rancang bangun..., Audy, FTI UMN, 2016
91
Gambar 3.35 Class Diagram CMS Mobile Bulletin
1..1
1..1
1..1
1..1
1..1
1..1
1..*
1..1
Validator
+ validate (Request request, String rules[], String messages[])
: boolean
Controller
+++++
getAll ()show (Integer id)create (Request request)edit (Integer id, Request request)destroy (Integer id)
: Collection: Collection: boolean: boolean: boolean
Model- fillable : String[]+++++
all ()find (Integer id)create (Request request)update (Request request)delete (Integer id)...
: Collection: Collection: boolean: boolean: boolean
Request
++
getRules ()getMessages ()
: String[]: String[]
Authentication
+ authenticate () : void
CategoryController PosterController FacultyController UserControllerLocationController TokenControllerAuthController
++
getLogin ()postLogin (Request request)...
: void: void
Rancang bangun..., Audy, FTI UMN, 2016
92
3.5.4 Perancangan Application Program Interface (API)
Perancangan sistem Mobile Bulletin dilanjutkan dengan membuat use case
dan activity diagram dari API yang akan dibangun.
A. Use Case Diagram
Gambar 3.36 Use Case Diagram API
Use case diagram dari API ditunjukkan pada Gambar 3.36. Terdapat dua
aktor di dalam use case, yaitu pengguna dan administrator. Pengguna ditujukan
kepada mahasiswa UMN, sedangkan administrator ditujukan kepada anggota
Public Relation dari BEM. API yang dibangun memiliki dua fungsi utama, yaitu
untuk mendapatkan informasi-informasi mading bagi pengguna dan memperoleh
informasi token bagi admin untuk dituliskan ke dalam NFC Tag.
B. Activity Diagram
Perancangan dilanjutkan dengan membuat activity diagram untuk
menunjukkan langkah-langkah dari tiap use case.
B.1 Activity Diagram Proses Mendapatkan Informasi Mading
Activity diagram proses mendapatkan informasi mading pada API
ditunjukkan Gambar 3.37. Proses dimulai dengan pengguna mengirimkan request
melalui aplikasi mobile ke API. Jika parameter Device di dalam request bernilai
Mendapatkan Informasi Mading
Mendapat Informasi Token
Pengguna
Administrator
Rancang bangun..., Audy, FTI UMN, 2016
93
“nfc” ataupun “qrcode”, maka program dilanjutkan dengan mengambil data token
dari objek Token Model. Namun, jika parameter Device tidak sama, baik dengan
“nfc” maupun “qrcode”, maka program akan langsung mengembalikan pesan
kesalahan kepada pengguna dan program selesai. Setelah data token didapatkan,
program dilanjutkan mengambil nama lokasi dan poster sesuai data yang diwakili
token. Lalu, seluruh poster akan dilakukan penyaringan hanya pada poster yang
masih memiliki interval waktu publikasi informasi.
Setelah mendapatkan daftar informasi poster, program dilanjutkan dengan
melakukan penyorotan (highlight) pada poster yang bertipe acara, seperti seminar,
lomba, ataupun acara-acara kampus lainnya, dan berlangsung di lokasi yang
diwakili token. Proses penyorotan ini dilakukan dengan menentukan waktu acara
tersebut berlangsung, mencakup perbedaan hari, jam, dan menit dari waktu
pengguna melakukan tapping NFC atau scan QR-Code. Program dilanjutkan
dengan menyimpan waktu akses API dan metode dari cara pemerolehan informasi
yang digunakan. Setelah itu, program melakukan decode pada data lokasi dan
poster sehingga terbentuk satu objek JSON, lalu mengirimkannya kembali ke
pengguna dan program selesai.
B.2 Activity Diagram Proses Mendapatkan Informasi Token
Activity diagram proses mendapatkan informasi token ditunjukkan pada
Gambar 3.38. Proses dimulai dengan program mengambil seluruh data kategori dan
lokasi. Kedua data ini digunakan bagi pengguna dalam memilih token yang ingin
ditulis ke dalam NFC Tag. Setelah itu, program dilanjutkan dengan mencari
kategori dan lokasi yang dipilih. Jika lokasi ataupun kategori tidak ditemukan, maka
program akan mengembalikan pesan kesalahan dan selesai. Namun, jika lokasi dan
Rancang bangun..., Audy, FTI UMN, 2016
94
kategori ditemukan, maka program akan mencari dan mengambil data token
berdasarkan lokasi dan kategori yang telah didapatkan. Jika token tidak ditemukan,
maka program akan mengembalikan pesan kesalahan dan selesai. Namun, jika
token ditemukan, maka program mengembalikan nilai dari token tersebut kembali
ke aplikasi mobile administrator.
Gambar 3.37 Activity Diagram Proses Mendapatkan Informasi Mading
Pengguna Controller TokenModel PosterModel
Mengirimkan Request Membaca Request
Device = NFC?
Device = QRCode?
Mengambil Data Token
Token ditemukan?
Ambil Lokasi yang Diwakili Token
Mengambil Data Poster
Filter Poster yang Masih Memiliki Interval Waktu Publikasi
Highlight Poster yang Bertipe Event dan Memiliki Lokasi Sesuai Token
Simpan Waktu Akses Informasi
Decode Variabel JSON
Mengembalikan Response JSON
Mengembalikan Pesan Error
Ya
Tidak
Ya
Tidak
Tidak
Mengembalikan Data Token
Mengembalikan Data Poster Sesuai Kategori
Ya
Rancang bangun..., Audy, FTI UMN, 2016
95
Gambar 3.38 Activity Diagram Proses Mendapatkan Informasi Token
Pengguna Controller LocationModel CategoryModel TokenModel
Memilih Token berdasarkan kategori dan lokasi
Mengirim Request
Mengambil seluruh data kategori
Mengambil seluruh data lokasi
Mengembalikan JSON
Membaca parameter lokasi dan kategori
Lokasi ditemukan?
Kategori ditemukan?
Mengambil data token
Token ditemukan?
Mengembalikan data tokenMengembalikan pesan error
Ya
Tidak
Ya
T idak
T idak
Decode JSON
Ya
Mengembalikan data lokasi
Mengembalikan data kategori
Mengembalikan data token berdasarkan kategori dan lokasi
Rancang bangun..., Audy, FTI UMN, 2016
96
3.5.5 Perancangan Aplikasi Android
Perancangan aplikasi Android dari sistem Mobile Bulletin dilakukan
dengan pendekatan pemrograman berorientasi objek sesuai buku Systems Analysis
and Design (Dennis dkk., 2012). Adapun tiga diagram yang dibuat dalam
perancangan aplikasi Android ini, yaitu use case diagram, sequence diagram, dan
class diagram.
A. Use-Case Diagram
Use-case diagram aplikasi Android ditunjukkan pada Gambar 3.39. Aktor
dalam use-case diagram ini terdiri dari pengguna dan administrator. Pengguna
adalah seluruh mahasiswa UMN, sedangkan administrator adalah anggota Public
Relation BEM UMN. Adapun penjelasan dari tiap use case dijelaskan pada Tabel
3.32 sampai 3.43.
Tabel 3.32 Use Case Mendapatkan Informasi Poster
Use Case Name Mendapatkan Informasi Poster. Actor Pengguna. Description Kejadian ketika pengguna ingin mendapatkan data
informasi poster mading. Trigger Aktor ingin mendapatkan data informasi terbaru
mading. Normal Flow of Event
1. Aktor membuka menu dan memilih “Tapping NFC” untuk mendapatkan informasi pada Smart Poster.
2. Jika ponsel Aktor didukung teknologi NFC, maka Aktor mendekatkan ponsel ke NFC Tag.
3. Jika ponsel Aktor tidak didukung teknologi NFC, maka Aktor memilih menu “Scan QR-Code” lalu melakukan scanning pada QR-Code yang tersedia.
4. Sistem berkomunikasi dengan API untuk mendapatkan data informasi poster sesuai token.
5. Sistem menampilkan daftar informasi poster. Pre-Condition Aktor telah melakukan instalasi aplikasi di ponselnya. Post-Condition Aktor berhasil mendapatkan informasi poster.
Rancang bangun..., Audy, FTI UMN, 2016
97
Gambar 3.39 Use Case Diagram Aplikasi Android
<< include >>
<< extend >>
<< extend >>
<< extend >>
Pengguna
Mendapatkan Informasi Poster
Melihat Detail Informasi Poster
Melihat Daftar Bookmark
Melakukan Penyaringan Informasi
Melihat Tutorial Aplikasi
Berbagi Informasi ke Media Sosial
Melakukan Bookmark Poster
Hapus Bookmark
<< extend >>
<< include >>
Admin
Memilih Token Berdasarkan Kategori dan Lokasi
Menulis Token ke NFC Tag
<< include >>
Mencari Informasi Poster Berdasarkan Judul
<< include >>
Mencari Informasi Bookmark Berdasarkan Judul
<< include >>
Rancang bangun..., Audy, FTI UMN, 2016
98
Tabel 3.33 Use Case Melihat Detail Informasi Poster
Use Case Name Melihat Detail Informasi Poster. Actor Pengguna. Description Kejadian ketika pengguna ingin melihat detail informasi
poster. Trigger Aktor ingin melihat detail informasi suatu poster. Normal Flow of Event
1. Aktor melihat daftar informasi poster. 2. Aktor memilih salah satu poster. 3. Sistem menampilkan detail informasi poster yang
dipilih pengguna. Pre-Condition Aktor telah mendapatkan daftar informasi poster. Post-Condition Aktor berhasil melihat detail informasi suatu poster.
Tabel 3.34 Use Case Berbagi ke Media Sosial
Use Case Name Berbagi ke Media Sosial. Actor Pengguna. Description Kejadian ketika pengguna ingin berbagi informasi suatu
poster ke media sosial. Trigger Aktor ingin berbagi suatu informasi poster ke media sosial. Normal Flow of Event
1. Aktor memilih tombol untuk berbagi informasi ke media sosial.
2. Aktor memilih media sosial yang diinginkan. 3. Sistem berbagi content ke media sosial yang dipilih
pengguna. Pre-Condition Aktor telah melihat detail informasi suatu poster. Post-Condition Aktor berhasil berbagi informasi suatu poster ke media
sosial.
Tabel 3.35 Use Case Melakukan Bookmark Poster
Use Case Name Melakukan Bookmark Poster. Actor Pengguna. Description Kejadian ketika pengguna menyimpan suatu informasi
poster. Trigger Aktor ingin menyimpan suatu informasi poster. Normal Flow of Event
1. Aktor memilih tombol untuk melakukan bookmark poster.
2. Sistem menyimpan detail informasi tersebut ke ponsel pengguna.
Pre-Condition Aktor telah melihat detail informasi suatu poster. Post-Condition Aktor berhasil menyimpan informasi suatu poster.
Rancang bangun..., Audy, FTI UMN, 2016
99
Tabel 3.36 Use Case Menghapus Bookmark Poster
Use Case Name Menghapus Bookmark Poster. Actor Pengguna. Description Kejadian ketika pengguna menghapus informasi poster
yang sudah disimpan pada ponsel. Trigger Aktor ingin menghapus suatu informasi poster yang sudah
disimpan. Normal Flow of Event
1. Aktor memilih tombol untuk menghapus bookmark pada poster.
2. Sistem menghapus detail informasi tersebut dari ponsel pengguna.
Pre-Condition Aktor telah melihat detail informasi suatu poster melalui menu Bookmark.
Post-Condition Aktor berhasil menghapus informasi suatu poster.
Tabel 3.37 Use Case Melihat Daftar Bookmark
Use Case Name Melihat Daftar Bookmark. Actor Pengguna. Description Kejadian ketika pengguna melihat daftar informasi poster
yang sudah disimpan pada ponsel (bookmark). Trigger Aktor ingin melihat daftar informasi poster yang sudah
disimpan. Normal Flow of Event
1. Aktor memilih menu Bookmark pada aplikasi. 2. Sistem menampilkan daftar informasi poster yang
telah disimpan di dalam ponsel. Pre-Condition Aktor telah menyimpan detail informasi poster. Post-Condition Aktor berhasil melihat daftar informasi poster yang telah
disimpan di dalam ponsel.
Tabel 3.38 Use Case Memilih Token Berdasarkan Kategori dan Lokasi
Use Case Name Memilih Token Berdasarkan Kategori dan Lokasi. Actor Administrator. Description Kejadian ketika administrator memilih token berdasarkan
kategori dan lokasi. Trigger Aktor ingin menulis token ke NFC Tag. Normal Flow of Event
1. Sistem mengambil data kategori dan lokasi dari API.
2. Aktor memilih token berdasarkan kategori dan lokasi yang diinginkan.
3. Sistem mengambil data token sesuai kategori dan lokasi yang telah dipilih administrator.
Pre-Condition Aktor telah melakukan instalasi aplikasi. Post-Condition Aktor berhasil memilih token yang diinginkan.
Rancang bangun..., Audy, FTI UMN, 2016
100
Tabel 3.39 Use Case Melakukan Penyaringan Informasi
Use Case Name Melakukan Penyaringan Informasi. Actor Pengguna. Description Kejadian ketika pengguna melakukan penyaringan
terhadap informasi poster yang didapatkan. Trigger Aktor ingin menyaring informasi yang telah didapatkan. Normal Flow of Event
1. Aktor memilih tab Filter pada aplikasi. 2. Sistem menampilkan daftar fakultas dan tipe
informasi yang dapat dilakukan penyaringan. 3. Pengguna melakukan pengaturan pada penyaringan
informasi poster. 4. Sistem menyimpan pengaturan tersebut dan
menerapkannya pada daftar poster. Pre-Condition Aktor telah melakukan instalasi aplikasi. Post-Condition Aktor berhasil melakukan penyaringan pada daftar poster.
Tabel 3.40 Use Case Melihat Tutorial Aplikasi
Use Case Name Melihat Tutorial Aplikasi. Actor Pengguna. Description Kejadian ketika pengguna melihat panduan penggunaan
aplikasi. Trigger Aktor ingin melihat panduan penggunaan aplikasi. Normal Flow of Event
1. Jika aplikasi baru dibuka pertama kali, maka sistem mengarahkan pengguna secara otomatis ke panduan penggunaan aplikasi.
2. Jika aplikasi sudah pernah dibuka sebelumnya, maka aktor dapat memilih menu Tutorial Aplikasi.
3. Sistem menampilkan beberapa gambar dan keterangan sebagai panduan penggunaan aplikasi.
Pre-Condition Aktor telah melakukan instalasi aplikasi. Post-Condition Aktor berhasil melihat panduan penggunaan aplikasi.
Tabel 3.41 Use Case Menulis Token ke NFC Tag
Use Case Name Menulis Token ke NFC Tag. Actor Administrator. Description Kejadian ketika administrator menulis token ke NFC Tag. Trigger Aktor ingin menulis token ke NFC Tag. Normal Flow of Event
1. Sistem mengambil data token berdasarkan kategori dan lokasi yang telah dipilih.
2. Aktor melakukan tapping pada NFC Tag dengan ponsel yang didukung NFC.
3. Sistem menulis token ke NFC Tag. Pre-Condition Aktor telah memilih kategori dan lokasi dari token. Post-Condition Aktor berhasil menulis token ke NFC Tag.
Rancang bangun..., Audy, FTI UMN, 2016
101
Tabel 3.42 Use Case Mencari Informasi Poster Berdasarkan Judul
Use Case Name Mencari Informasi Poster Berdasarkan Judul. Actor Pengguna. Description Kejadian ketika pengguna mencari informasi berdasarkan
judul poster tertentu. Trigger Aktor ingin mencari informasi berdasarkan judul poster
tertentu. Normal Flow of Event
1. Pengguna mengklik tombol Search pada daftar poster.
2. Sistem menampilkan text box untuk mengisi judul poster.
3. Pengguna mengisikan judul poster yang ingin dicari.
4. Sistem mencari dan menampilkan daftar poster sesuai judul yang dicari.
Pre-Condition Aktor telah memilih mendapatkan daftar informasi poster. Post-Condition Aktor berhasil mencari informasi berdasarkan judul poster
yang dimasukkan.
Tabel 3.43 Use Case Mencari Informasi Bookmark Berdasarkan Judul
Use Case Name Mencari Informasi Bookmark Berdasarkan Judul. Actor Pengguna. Description Kerjadian ketika pengguna mencari informasi bookmark
berdasarkan judul poster tertentu. Trigger Aktor ingin mencari mencari informasi bookmark
berdasarkan judul poster. Normal Flow of Event
1. Pengguna mengklik tombol Search pada daftar bookmark.
2. Sistem menampilkan text box untuk mengisi judul poster.
3. Pengguna mengisikan judul poster yang ingin dicari.
4. Sistem mencari dan menampilkan daftar informasi yang disimpan dalam ponsel (bookmark) sesuai judul yang dicari.
Pre-Condition Aktor telah menyimpan informasi poster ke dalam ponsel. Post-Condition Aktor berhasil mencari informasi bookmark berdasarkan
judul poster.
Rancang bangun..., Audy, FTI UMN, 2016
102
B. Sequence Diagram
Perancangan aplikasi mobile berbasis Android pada sistem Mobile Bulletin
dilanjutkan dengan pembuatan sequence diagram dari tiap use-case.
B.1 Sequence Diagram Proses Mendapatkan Informasi Poster
Sequence diagram proses mendapatkan informasi poster oleh pengguna
ditunjukkan pada Gambar 3.40, dengan penjelasan sebagai berikut.
1. Pengguna melakukan inisiasi untuk mendapatkan informasi poster pada
Main Activity.
2. Main Activity mengirimkan permintaan tersebut ke Controller.
3. Controller melakukan pembacaan token melalui objek Reader, kemudian
mengirimkan token tersebut ke API melalui objek Network API.
4. Network API mengembalikan hasil response dalam bentuk daftar poster.
5. Controller melakukan pengaturan objek Adapter pada Poster Fragment
dengan daftar poster yang telah didapat.
6. Controller menyimpan data daftar poster dan informasi waktu pengambilan
informasi terbaru ke sistem basis data melalui objek DB Handler.
7. Controller melakukan pengaturan Adapter pada objek Recycler View yang
digunakan untuk menampilkan daftar poster di Poster Fragment, lalu daftar
poster ditampilkan ke pengguna.
Rancang bangun..., Audy, FTI UMN, 2016
103
Gambar 3.40 Sequence Diagram Proses Mendapatkan Informasi Poster
SequenceDiagramMendapatkanInformasiPoster
12: showListPoster()
11: setRecyclerViewAdapter( adapter )
9: saveListPoster( List < poster > )
10: saveLatestUpdate( timestamp )
8: Adapter
7: setAdapter ( List < poster > )6: List < poster >
5: getPosters( token )
4: token
3: readToken()2: sendRequest()
1: getPosterInformation()
Pengguna CtrlMainActivity Reader NetworkAPIAdapter DBHandlerPosterFragment
12: showListPoster()
11: setRecyclerViewAdapter( adapter )
9: saveListPoster( List < poster > )
10: saveLatestUpdate( timestamp )
8: Adapter
7: setAdapter ( List < poster > )6: List < poster >
5: getPosters( token )
4: token
3: readToken()2: sendRequest()
1: getPosterInformation()
Rancang bangun..., Audy, FTI UMN, 2016
104
B.2 Sequence Diagram Proses Mencari Informasi Poster Berdasarkan
Judul
Sequence diagram proses mencari informasi poster berdasarkan judul oleh
pengguna ditunjukkan pada Gambar 3.41, dengan penjelasan sebagai berikut.
1. Pengguna memasukkan kata kunci judul pencarian poster pada Poster
Fragment.
2. Poster Fragment mengirimkan permintaan pencarian tersebut ke Controller.
3. Controller melakukan pencarian poster berdasarkan kata kunci yang
dimasukkan.
4. Controller melakukan pengaturan pada objek Adapter dengan daftar poster
yang sesuai dengan kata kunci pencarian.
5. Controller melakukan pengaturan pada objek Recycler View dengan
Adapter yang baru dan menampilkan daftar poster.
Gambar 3.41 Sequence Diagram Proses Mencari Informasi Poster Berdasarkan Judul
SequenceDiagramMencari InformasiPoster
7: showListPoster()6: setRecyclerViewAdapter( adapter )
5: Adapter
4: setNewAdapter( List < poster > )
3: findPoster( keyword )2: sendRequest( keyword )1: setTitleKeyword( keyword )
Pengguna PosterFragment Adapter Ctrl
7: showListPoster()6: setRecyclerViewAdapter( adapter )
5: Adapter
4: setNewAdapter( List < poster > )
3: findPoster( keyword )2: sendRequest( keyword )1: setTitleKeyword( keyword )
Rancang bangun..., Audy, FTI UMN, 2016
105
B.3 Sequence Diagram Proses Melihat Detail Informasi Poster
Sequence diagram proses melihat detail informasi poster oleh pengguna
ditunjukkan pada Gambar 3.42, dengan penjelasan sebagai berikut.
1. Pengguna mengklik salah satu poster pada Poster Fragment.
2. Poster Fragment mengirimkan posisi dari poster yang diklik pengguna ke
Controller.
3. Controller mencari poster berdasarkan posisi yang didapat.
4. Controller mengirimkan objek poster ke Detail Activity untuk menampilkan
detail informasi.
Gambar 3.42 Sequence Diagram Proses Melihat Detail Informasi Poster
B.4 Sequence Diagram Proses Berbagi Informasi ke Media Sosial
Sequence diagram proses berbagi informasi ke media sosial oleh pengguna
ditunjukkan pada Gambar 3.43, dengan penjelasan sebagai berikut.
1. Pengguna mengklik tombol Share pada Detail Activity.
2. Detail Activity mengirimkan permintaan tersebut ke Controller.
SequenceDiagramMelihatDetailPoster
4: showDetail ( poster )
3: getPoster( position )2: sendRequest( position )1: clickPoster()
Pengguna PosterFragment DetailActivity Ctrl
4: showDetail ( poster )
3: getPoster( position )2: sendRequest( position )1: clickPoster()
Rancang bangun..., Audy, FTI UMN, 2016
106
3. Controller membuat tautan untuk berbagi informasi ke media sosial
berdasarkan ID dari poster yang sedang dilihat.
4. Controller berbagi informasi poster melalui tautan yang telah dibuat ke
media sosial.
Gambar 3.43 Sequence Diagram Proses Berbagi Informasi ke Media Sosial
B.5 Sequence Diagram Proses Melakukan Bookmark Poster
Gambar 3.44 Sequence Diagram Proses Melakukan Bookmark Poster
SequenceDiagramBerbagiInformasiKeMediaSosial
4: shareInformation( link )
3: createShareLink( id )2: sendRequest()
1: clickShareInfo()
Pengguna Detail Activity Controller Media Sosial
4: shareInformation( link )
3: createShareLink( id )2: sendRequest()
1: clickShareInfo()
SequenceDiagramBookmarkPoster
4: disableBookmarkButton()3: saveBookmark( poster )
2: sendRequest()1: clickBookmark()
Pengguna DetailActivity Ctrl DBHandler
4: disableBookmarkButton()3: saveBookmark( poster )
2: sendRequest()1: clickBookmark()
Rancang bangun..., Audy, FTI UMN, 2016
107
Sequence diagram proses menyimpan informasi poster ke ponsel
(bookmark) oleh pengguna ditunjukkan pada Gambar 3.44, dengan penjelasan
sebagai berikut.
1. Pengguna mengklik tombol Bookmark pada Detail Activity.
2. Detail Activity mengirimkan permintaan tersebut ke Controller.
3. Controller menyimpan poster ke sistem basis data aplikasi dalam ponsel
melalui objek DB Handler, lalu membuat tombol Bookmark menjadi tidak
dapat diklik pada Detail Activity sehingga pengguna tidak dapat
menyimpan poster yang telah ada di dalam sistem basis data ponsel.
B.6 Sequence Diagram Proses Melihat Daftar Bookmark
Sequence diagram proses melihat daftar informasi poster yang telah
disimpan dalam ponsel (bookmark) oleh pengguna ditunjukkan pada Gambar 3.45,
dengan penjelasan sebagai berikut.
1. Pengguna mengklik menu Bookmark pada Main Activity.
2. Main Activity mengirimkan permintaan tersebut ke Controller.
3. Controller mengambil seluruh data bookmark melalui objek DB Handler.
4. Controller melakukan pengaturan objek Adapter dengan daftar bookmark.
5. Controller melakukan pengaturan Adapter pada objek Recycler View di
Bookmark Fragment dan menampilkan daftar bookmark.
B.7 Sequence Diagram Proses Menghapus Bookmark
Sequence diagram proses menghapus bookmark oleh pengguna ditunjukkan
pada Gambar 3.46, dengan penjelasan sebagai berikut.
1. Pengguna mengklik tombol Delete Bookmark pada Detail Activity.
Rancang bangun..., Audy, FTI UMN, 2016
108
2. Detail Activity mengirimkan permintaan tersebut ke Controller.
3. Controller menghapus bookmark dari sistem basis data aplikasi pada ponsel.
4. Controller mengambil data bookmark yang telah diperbarui.
5. Controller melakukan pengaturan objek Adapter dengan daftar bookmark
terbaru.
6. Controller melakukan pengaturan Adapter pada objek Recycler View di
Bookmark Fragment lalu menampilkan daftar bookmark terbaru.
B.8 Sequence Diagram Proses Mencari Informasi Bookmark Berdasarkan
Judul
Sequence diagram proses mencari bookmark berdasarkan judul poster oleh
pengguna ditunjukkan pada Gambar 3.47, dengan penjelasan sebagai berikut.
1. Pengguna memasukkan kata kunci judul pencarian poster pada Bookmark
Fragment.
2. Bookmark Fragment mengirimkan permintaan pencarian tersebut ke
Controller.
3. Controller melakukan pencarian bookmark berdasarkan kata kunci yang
dimasukkan.
4. Controller melakukan pengaturan pada objek Adapter dengan daftar
bookmark yang sesuai dengan kata kunci pencarian.
5. Controller melakukan pengaturan pada objek Recycler View dengan
Adapter yang baru dan menampilkan daftar bookmark.
Rancang bangun..., Audy, FTI UMN, 2016
109
Gambar 3.45 Sequence Diagram Proses Melihat Daftar Bookmark
SequenceDiagramMelihatDaftarBookmark
2: sendRequest()1: chooseBookmarkMenu()
8: showBookmark()7: setRecyclerViewAdapter ( adapter )
6: Adapter5: setAdapter( List < bookmark > )
4: List < bookmark >
3: getBookmark()
Pengguna Adapter CtrlBookmarkFragment DBHandlerMainActivity
2: sendRequest()1: chooseBookmarkMenu()
8: showBookmark()7: setRecyclerViewAdapter ( adapter )
6: Adapter5: setAdapter( List < bookmark > )
4: List < bookmark >
3: getBookmark()
Rancang bangun..., Audy, FTI UMN, 2016
110
Gambar 3.46 Sequence Diagram Proses Menghapus Bookmar
SequenceDiagramMenghapusBookmark
9: showUpdatedBookmark()8: setRecyclerViewAdapter( adapter )
7: Adapter6: setAdapter( List < bookmark > )
5: List < bookmark >4: getUpdatedBookmark()
3: deleteBookmark( id )2: sendRequest()
1: clickDeleteButton()
Pengguna DetailActivity BookmarkFragment Ctrl DBHandlerAdapter
9: showUpdatedBookmark()8: setRecyclerViewAdapter( adapter )
7: Adapter6: setAdapter( List < bookmark > )
5: List < bookmark >4: getUpdatedBookmark()
3: deleteBookmark( id )2: sendRequest()
1: clickDeleteButton()
Rancang bangun..., Audy, FTI UMN, 2016
111
Gambar 3.47 Sequence Diagram Proses Mencari Bookmark Berdasarkan Judul
B.9 Sequence Diagram Proses Melihat Tutorial Penggunaan Aplikasi
Gambar 3.48 Sequence Diagram Proses Melihat Tutorial Aplikasi
Sequence diagram proses melihat tutorial penggunaan aplikasi oleh
pengguna ditunjukkan pada Gambar 3.48, dengan penjelasan sebagai berikut.
1. Pengguna memilih menu Tutorial pada Main Activity
2. Main Activity mengirimkan permintaan tersebut ke Controller.
3. Controller menampilkan panduan penggunaan aplikasi pada objek Tutorial
Activity.
SequenceDiagramMencariBookmark
7: showListBookmark()
6: setRecyclerViewAdapter( adapter )
5: Adapter4: setNewAdapter( List < bookmark > )
3: findBookmark( keyword )2: sendRequest( keyword )
1: inputTitleKeyword()
Pengguna BookmarkFragment Adapter Ctrl
7: showListBookmark()
6: setRecyclerViewAdapter( adapter )
5: Adapter4: setNewAdapter( List < bookmark > )
3: findBookmark( keyword )2: sendRequest( keyword )
1: inputTitleKeyword()
SequenceDiagramMelihatTutorial
3: showTutorial()
2: sendRequest()1: clickTutorialMenu()
Pengguna MainActivity TutorialActivity Ctrl
3: showTutorial()
2: sendRequest()1: clickTutorialMenu()
Rancang bangun..., Audy, FTI UMN, 2016
112
B.10 Sequence Diagram Melakukan Penyaringan Informasi
Sequence diagram proses melakukan penyaringan informasi poster oleh
pengguna ditunjukkan pada Gambar 3.49, dengan penjelasan sebagai berikut.
1. Controller mengambil seluruh data pengaturan penyaringan poster dari
sistem basis data melalui DB Handler.
2. Controller melakukan pengaturan pada setiap pilihan penyaringan sesuai
data yang telah disimpan, lalu menampilkan pilihan penyaringan tersebut ke
Filter Fragment.
3. Pengguna melakukan pengaturan pada penyaringan informasi di Filter
Fragment.
4. Filter Fragment mengirimkan permintaan pengaturan pengguna ke
Controller.
5. Controller menyimpan data pengaturan penyaringan informasi poster baru
ke sistem basis data melalui objek DB Handler.
6. Controller melakukan penyaringan informasi sesuai pengaturan yang telah
dilakukan pengguna, lalu melakukan pengaturan pada objek Adapter
dengan data poster yang telah tersaring.
7. Controller melakukan pengaturan Adapter pada objek Recycler View di
Poster Fragment, lalu menampilkan daftar poster yang telah tersaring.
Rancang bangun..., Audy, FTI UMN, 2016
113
Gambar 3.49 Sequence Diagram Proses Melakukan Penyaringan Informasi
SequenceDiagramPenyaringanInformasi
12: showListPoster()
11: setRecyclerViewAdapter( adapter )10: Adapter
9: setAdapter( List < poster > )
8: filterPoster( checkedList )7: saveNewCheckedFilter( checkedList )
6: sendRequest()5: setCheckedFilter()
4: showFilterOptions()
3: setCheckedFilter( checkedList )
2: CheckedList1: getCheckedFilter()
Pengguna FilterFragment PosterFragment Ctrl DBHandlerAdapter
12: showListPoster()
11: setRecyclerViewAdapter( adapter )10: Adapter
9: setAdapter( List < poster > )
8: filterPoster( checkedList )7: saveNewCheckedFilter( checkedList )
6: sendRequest()5: setCheckedFilter()
4: showFilterOptions()
3: setCheckedFilter( checkedList )
2: CheckedList1: getCheckedFilter()
Rancang bangun..., Audy, FTI UMN, 2016
114
B.11 Sequence Diagram Proses Memilih Token Berdasarkan Kategori dan
Lokasi.
Sequence diagram proses memilih token berdasarkan kategori dan lokasi
oleh administrator ditunjukkan pada Gambar 3.50, dengan penjelasan sebagai
berikut.
1. Controller mengambil data kategori dan lokasi dari API melalui objek
Network API.
2. Controller menampilkan daftar kategori dan lokasi yang dapat dipilih
pengguna di Main Activity.
3. Pengguna memilih kategori dan lokasi.
4. Main Activity mengirimkan permintaan tersebut ke Controller.
5. Controller mengambil data token berdasarkan kategori dan lokasi dari API
melalui objek Network API.
Gambar 3.50 Sequence Diagram Proses Memilih Token Berdasarkan Kategori dan Lokasi.
SequenceDiagramMemilihKodeAkses
9: Token
8: getToken( category, location )
7: sendRequest( category, location )6: chooseCategoryAndLocation()
5: showCategoriesAndLocations()4: Locations
3: getLocations()
2: Categories1: getCategories()
Admin MainActivity Ctrl NetworkAPI
9: Token
8: getToken( category, location )
7: sendRequest( category, location )6: chooseCategoryAndLocation()
5: showCategoriesAndLocations()4: Locations
3: getLocations()
2: Categories1: getCategories()
Rancang bangun..., Audy, FTI UMN, 2016
115
B.12 Sequence Diagram Proses Menulis Token ke NFC Tag
Gambar 3.51 Sequence Diagram Proses Menulis Token ke NFC Tag
Sequence diagram proses menulis token ke NFC Tag oleh administrator
ditunjukkan pada Gambar 3.51, dengan penjelasan sebagai berikut.
1. Controller membuat data yang ingin ditulis ke dalam NFC Tag sesuai token
yang telah didapat.
2. Controller menulis data tersebut ke NFC Tag melalui NFC Scanning
Activity.
3. NFC Scanning Activity mengirimkan pesan konfirmasi kembali ke
Controller.
4. Contoller menampilkan pesan konfirmasi penulisan token ke Main Activity.
C. Class Diagram
Perancangan aplikasi Android sistem Mobile Bulletin dilanjutkan dengan
pembuatan class diagram seperti yang ditunjukkan pada Gambar 3.53. Main
Activity merupakan class utama dalam aplikasi ini. Class ini memiliki atribut
berupa Fragment Manager dan Fragment Transaction yang digunakan untuk
SequenceDiagramMenulisToken
4: showConfirmationMessage( confirmation )
3: Confirmation
2: writeToNFCTag( data )
1: createData( token )
Ctrl NFCScanningActivity MainActivity
4: showConfirmationMessage( confirmation )
3: Confirmation
2: writeToNFCTag( data )
1: createData( token )
Rancang bangun..., Audy, FTI UMN, 2016
116
menampilkan objek Main Fragment dan Bookmark Fragment. Terdapat dua buah
class Fragment yang berhubungan asosiasi dengan Main Fragment, yaitu Poster
Fragment dan Filter Fragment. Poster Fragment digunakan untuk menampilkan
daftar poster dari API, sedangkan Filter Fragment digunakan untuk melakukan
pengaturan pada penyaringan poster. Poster Fragment memiliki hubungan one-to-
many terhadap class Poster Adapter karena terdapat perbedaan instance dari objek
Adapter pada daftar poster secara keseluruhan dengan daftar poster yang sesuai
dengan kata kunci pencarian. Daftar poster secara keseluruhan akan ditampung
dalam atribut Poster List, sedangkan daftar poster yang sesuai dengan kata kunci
pencarian akan ditampung dalam atribut Search Poster List. Kedua data ini akan
ditampilkan pada laman antarmuka melalui atribut Recycler View.
Selain Main Fragment, Main Activity juga berhubungan asosiasi dengan
class Bookmark Fragment, yaitu instance dari objek Fragment untuk menampilkan
daftar poster yang telah disimpan di dalam ponsel (bookmark). Cara menampilkan
daftar poster pada Bookmark Fragment sama dengan Poster Fragment, yaitu
melalui class Poster Adapter dan atribut Recycler View. Kedua objek Fragment ini,
baik Poster Fragment maupun Bookmark Fragment, memiliki hubungan asosiasi
dengan class Poster Detail Activity, yaitu class yang digunakan untuk menampilkan
informasi poster secara detail. Pada class ini terdapat beberapa fungsi, seperti
Bookmark Poster untuk melakukan penyimpanan informasi poster ke dalam ponsel,
Share Poster untuk melakukan penyebaran informasi poster melalui media sosial,
dan Delete Bookmark untuk menghapus poster dari daftar bookmark.
Rancang bangun..., Audy, FTI UMN, 2016
117
Gambar 3.52 Class Diagram Aplikasi Android Sistem Mobile Bulletin
1..1
1..1 1..1
1..1
1..1
1..1
1..1
1..1
1..1
1..1
1..1
1..1 1..1
1..1
1..1
1..1
1..1
1..11..*
1..1
1..1
1..1
1..1
1..1
1..1
1..1
1..1
1..1
1..1
1..1
1..*1..1
1..1
1..1
1..1
1..1
MainActivity--
fragmentManagerfragmentTransaction
: FragmentManager: FragmentTransaction
+++
onCreate ()onNavigationItemSelected (MenuItem item)saveToDB (String token)...
: void: boolean: void
MainFragment--
tabLayoutviewPager
: TabLayout: ViewPager
++
onCreateView ()setupViewPager (ViewPager viewPager)
: void: void
BookmarkFragment-----
listBookmarklistSearchBookmarklistIdJSONBookmarkrecyclerViewtxtSearch
: List: List: List: RecyclerView: EditText
+++
onCreateView ()onResume ()onItemClick (int position)...
: void: void: void
PosterFragment----
posterListsearchPosterListrecyclerViewtxtSearch
: List: List: RecyclerView: EditText
++++
onCreateView ()setMenuVisibility ()updateListPoster ()onItemClick (int position)
: void: void: void: void
FilterFragment------
facultyCodeListsbFacultiesfacultyCheckedFiltertypeCheckedFiltersbInternalsbExternal
: List: List: List: List: SwitchButton: SwitchButton
++++
onCreateView ()saveFilter ()addFaculty (String facultyCode)setMenuVisibility ()
: void: void: void: void
PosterAdapter--
posterListmDataSetTypes
: List: List
++++
onCreateViewHolder (int viewType)onBindViewHolder ()PosterAdapter (List posterList)posterAdapter (List posterList, List dataSetTypes)...
: ViewHolder: void
Reader- tag : Tag++
Reader (Tag tag)readToken () : String
NFCScanningActivity- nfcAdapter : NFCAdapter+++++
onCreate ()onResume ()onPause ()onNewIntent ()saveToDB ()
: void: void: void: void: void
QRCodeScanningActivity- cameraScanner : CameraScanner++++
onCreate ()onResume ()onPause ()handleResult ()
: void: void: void: void
PosterDetailActivity--
posteridJSON
: Poster: int
+++++
onCreate ()updatePosterInformationUI ()bookmarkPoster ()sharePoster ()deleteBookmark ()...
: void: void: void: void: void
Model
++
setter ()getter ()
NetworkAPI
+ getDataPoster () : List
TutorialActivity--
viewPagerimages
: ViewPager: Integer[]
+++
onCreate ()init ()onBackPressed ()...
: void: void: void
ImageAdapter- images : List++
destroyItem ()instantiateItem (int position)
: void: Object
Rancang bangun..., Audy, FTI UMN, 2016
118
Main Activity juga berhubungan asosiasi dengan class yang digunakan
untuk membaca token, baik dari NFC Tag maupun QR-Code. Dalam membaca
NFC Tag, Main Activity berhubungan dengan class NFC Scanning Activity,
sedangkan untuk melakukan scanning pada QR-Code, Main Activity berhubungan
dengan class QRCode Scanning Activity. Kedua class Activity ini berhubungan
dengan Network API, yaitu interface yang digunakan untuk melakukan komunikasi
antara aplikasi mobile dengan API yang dibuat, seperti mengambil data poster dari
sistem basis data server ke aplikasi Android. Interface ini mengembalikan response
API dalam bentuk list of object sehingga memiliki hubungan one-to-many dengan
class Model. Model mewakili beberapa instance, seperti Poster, Location, Meta
Poster, Faculty, dan Category. NFC Scanning Activity berhubungan asosiasi
dengan Reader, yaitu class untuk membaca isi NFC Tag dan mengembalikan hasil
dalam bentuk String. Selain NFC Scanning Activity, class Main Activity juga
berhubungan asosiasi dengan Reader untuk menangani Intent Filter yang
didefinisikan pada Android Manifest ketika aplikasi mendeteksi NFC Tag. Hal ini
bertujuan agar pengguna dapat melakukan tapping ponsel ke NFC Tag dan
mendapatkan informasi poster tanpa harus membuka aplikasi.
Tutorial Activity merupakan class yang digunakan untuk menampilkan
beberapa gambar panduan penggunaan aplikasi Android pengguna. Dalam
menampilkan gambar-gambar tersebut, digunakan atribut View Pager sehingga
navigasi dari panduan penggunaan aplikasi dapat dilakukan dengan menggeser
gambar ke kiri ataupun ke kanan. Oleh karena konsep navigasi panduan yang
digunakan, Tutorial Activity berhubungan asosiasi dengan class Image Adapter
Rancang bangun..., Audy, FTI UMN, 2016
119
untuk menampung seluruh data gambar panduan dan menampilkannya di layar
ponsel.
3.5.6 Perancangan Tampilan Antarmuka
Perancangan tampilan yang dilakukan mencakup desain antarmuka CMS
dan aplikasi mobile.
A. Perancangan Tampilan Antarmuka pada Backend CMS
Secara umum, perancangan tampilan antarmuka pada backend CMS
ditunjukkan pada Gambar 3.53. Rancangan tampilan ini digunakan pada laman
awal pengaturan konten fakultas, kategori, lokasi, dan token. Laman ini
menampilkan daftar informasi dalam bentuk tabel dengan tombol Edit dan Delete
pada kolom terakhir dari tiap data. Pada laman ini juga disediakan objek combo box
untuk memilih jumlah data yang ingin ditampilkan dan text box untuk memasukkan
kata kunci dalam melakukan pencarian data. Pada bagian kanan atas dari kedua
objek ini terdapat tombol Add untuk menambah data sesuai informasi yang sedang
ditampilkan. Pada bagian bawah tabel terdapat suatu pagination sehingga data tidak
ditampilkan secara keseluruhan, tetapi per halaman. Hal ini bertujuan agar
pengambilan data menjadi lebih cepat dan ringan.
Perancangan tampilan antarmuka bagian daftar poster berbeda dengan
tampilan antarmuka pada informasi lain. Rancangan tampilan antarmuka daftar
poster ditunjukkan pada Gambar 3.54. Tampilan ini hanya menampilkan gambar
poster dalam bentuk seperti kartu dengan jumlah maksimal empat poster di tiap
barisnya. Tiap gambar poster memiliki tombol Detail untuk mengarahkan pengguna
ke laman untuk melihat informasi poster secara detail. Pada bagian kiri atas gambar
Rancang bangun..., Audy, FTI UMN, 2016
120
poster terdapat berbagai parameter pencarian, seperti judul, kategori, tipe informasi,
dan fakultas. Parameter pencarian ini berguna untuk melakukan penyaringan
terhadap poster yang ditampilkan di laman daftar poster. Pada bagian kanan atas
terdapat combo box untuk mengatur jumlah poster yang ingin ditampilkan di suatu
halaman. Di bagian atas dari parameter pencarian dan pengaturan jumlah tampilan
data terdapat tombol Add untuk mengarahkan pengguna ke laman formulir
penambahan data poster. Tampilan antarmuka daftar informasi poster pada frontend
sama seperti tampilan pada administrator. Namun, pada bagian frontend, tidak
terdapat menu pada bagian kiri ataupun tombol Add.
Gambar 3.53 Rancangan Tampilan Antarmuka Daftar Informasi Secara Umum di Backend CMS
Rancang bangun..., Audy, FTI UMN, 2016
121
Gambar 3.54 Rancangan Tampilan Antarmuka Daftar Informasi Poster
Gambar 3.55 Rancangan Tampilan Antarmuka Formulir Penambahan Pengubahan Informasi
Rancangan tampilan formulir, baik penambahan maupun pengubahan, data
kategori, fakultas, lokasi, maupun token, ditunjukkan pada Gambar 3.55. Konten
dari formulir disesuaikan dengan data yang bersangkutan. Namun, secara umum,
terdapat tombol Save untuk menyimpan data formulir yang telah diisi oleh
Rancang bangun..., Audy, FTI UMN, 2016
122
pengguna dan tombol Back untuk kembali ke laman daftar informasi. Jika tombol
Save diklik, maka akan muncul pesan konfirmasi seperti yang ditunjukkan pada
Gambar 3.56. Berbagai komponen formulir digunakan pada laman ini, seperti
combo box, radio button, text box, dan button untuk unggah berkas. Setiap
komponen disesuaikan dengan kebutuhan dari data yang ingin dimasukkan.
Gambar 3.56 Rancangan Tampilan Antarmuka Pesan Konfirmasi
Gambar 3.57 Rancangan Tampilan Antarmuka Detail Informasi Poster
Rancang bangun..., Audy, FTI UMN, 2016
123
Berbeda dengan laman Daftar Informasi umumnya yang menampilkan
detail informasi secara keseluruhan, laman Daftar Informasi Poster hanya
menampilkan gambar poster saja. Oleh karena itu, dibuatlah laman untuk melihat
informasi poster secara detail seperti yang ditunjukkan pada Gambar 3.57. Pada
laman ini, gambar poster berada di sebelah kiri dengan beberapa keterangan
tambahan di bawah gambar, seperti kategori, tipe informasi, ataupun informasi-
informasi tambahan lainnya yang disimpan dalam tabel Meta Posters. Di sebelah
kanan gambar poster terdapat judul informasi, tujuan fakultas, dan deskripsi
informasi poster. Di bagian bawah deskripsi poster terdapat tombol Edit untuk
mengarahkan pengguna ke laman pengeditan data informasi poster dan tombol
Delete untuk menghapus poster. Pada bagian atas dari judul poster juga disediakan
tombol Back untuk kembali ke laman daftar informasi poster. Tampilan laman
detail informasi poster pada frontend serupa seperti tampilan pada administrator.
Namun, perbedaan tampilan informasi detail poster pada frontend dengan
administrator adalah tidak terdapat tombol Edit ataupun Delete.
B. Perancangan Tampilan Antarmuka pada Aplikasi Mobile
Rancangan tampilan laman utama pada aplikasi mobile pengguna dibuat
dengan menggunakan konsep Tab Layout yang terdiri dari dua, yaitu tab untuk
menampilkan daftar poster dan tab untuk melakukan penyaringan data poster.
Tampilan untuk menampilkan daftar poster dibuat dengan menggunakan Card
View seperti yang ditunjukkan Gambar 3.58. Dalam menampilkan daftar poster,
penyorotan poster berdasarkan tanggal dan lokasi acara juga dilakukan dengan
membagi poster ke dalam tiga segmentasi, yaitu “Hari ini”, “Akan datang”, dan
“Lainnya”. Segmen “Hari ini” menampilkan acara yang akan berlangsung pada hari
Rancang bangun..., Audy, FTI UMN, 2016
124
dan lokasi pengguna mendapatkan informasi. Segmen “Akan datang” menampilkan
acara yang akan berlangsung dengan minimal selang waktu satu hari dan berlokasi
di tempat pengguna mendapatkan informasi. Segmen “Lainnya” menampilkan
informasi poster lain yang tidak tercakup dalam kedua segmen sebelumnya, seperti
acara-acara lain yang berlokasi di gedung yang berbeda ataupun acara yang tidak
bersifat acara. Pada laman ini juga disediakan tombol Search untuk mencari
informasi berdasarkan judul poster. Tampilan antarmuka pada daftar dari poster
yang disimpan dalam ponsel (bookmark) sama dengan tampilan daftar informasi
poster utama. Namun, pada tampilan daftar bookmark, tidak terdapat segmentasi
informasi.
Gambar 3.58 Rancangan Tampilan Antarmuka Daftar Poster Aplikasi Mobile
Tampilan tab untuk melakukan penyaringan informasi mading ditunjukkan
Gambar 3.59 Penyaringan informasi dilakukan dengan menggunakan tombol
Switch pada Android yang dapat memiliki satu dari dua nilai, yaitu “On” atau
Rancang bangun..., Audy, FTI UMN, 2016
125
“Off”. Penyaringan informasi dibagi menjadi dua segmentasi, yaitu penyaring
fakultas dan tipe informasi.
Gambar 3.59 Rancangan Tampilan Antarmuka Penyaringan Informasi Aplikasi Mobile
Gambar 3.60 Rancangan Tampilan Antarmuka Detail Informasi Poster Aplikasi Mobile
Rancang bangun..., Audy, FTI UMN, 2016
126
Rancangan tampilan antarmuka laman detail informasi poster ditunjukkan
Gambar 3.60. Tampilan antarmuka terdiri dari tiga komponen, yaitu Image View
untuk menampilkan gambar poster, Card View untuk menampilkan detail informasi
poster, dan tombol Menu. Seluruh informasi poster ditampilkan pada Card View,
seperti judul informasi, tanggal waktu acara, informasi tambahan, dan deskripsi
poster. Tombol Menu menggunakan komponen Floating Action Button dan
digunakan untuk menampilkan dua tombol lainnya, yaitu tombol Bookmark dan
Share. Tombol Bookmark digunakan untuk menyimpan informasi poster ke dalam
ponsel pengguna, sedangkan tombol Share digunakan untuk membagikan informasi
poster tersebut ke media sosial pengguna. Kedua tombol ini juga menggunakan
komponen Floating Action Button seperti tombol Menu, tetapi dengan ukuran yang
lebih kecil.
Gambar 3.61 Rancangan Tampilan Antarmuka Petunjuk Metode Mendapatkan Informasi
Rancang bangun..., Audy, FTI UMN, 2016
127
Aplikasi Android sistem Mobile Bulletin dilengkapi dengan teknologi untuk
mendapatkan informasi poster, baik melalui tapping NFC maupun scan QR-Code.
Rancangan tampilan antarmuka, baik laman tapping NFC maupun scan QR-Code
dilengkapi dengan petunjuk tentang cara penggunaan dari metode mendapatkan
informasi yang dipilih. Petunjuk penggunaan metode tersebut ditunjukkan Gambar
3.61. Petunjuk ini dilengkapi dengan gambar bertipe GIF dan keterangan berbentuk
teks untuk memberikan informasi cara penggunaan metode yang dipilih dalam
mendapatkan informasi poster.
Rancang bangun..., Audy, FTI UMN, 2016
Top Related