BAB III METODOLOGI PENELITIAN DAN PERANCANGAN …

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


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


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


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


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”.


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


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


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


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,


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,


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.


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


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.


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.


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


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



5. Sistem menyimpan data kategori terbaru. Pre-Condition Aktor membuka laman List Categories. Post-Condition Aktor berhasil menambah kategori.


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



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.


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



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


5. Sistem menyimpan data gedung kampus terbaru.

Pre-Condition Aktor membuka laman List Locations. Post-Condition Aktor berhasil mengedit gedung kampus.


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


5. Sistem menyimpan data diri administrator terbaru.

Pre-Condition Aktor membuka laman Data Diri Administrator. Post-Condition Aktor berhasil mengedit data diri aktor.


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



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



5. Sistem menyimpan data fakultas terbaru. Pre-Condition Aktor membuka laman List Faculties. Post-Condition Aktor berhasil mengedit fakultas.


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


5. Sistem menyimpan data token terbaru. Pre-Condition Aktor membuka laman List Tokens. Post-Condition Aktor berhasil menambah token.


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


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.


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



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.


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


7: loadPage()

2: sendEntryData()1: entry()

5: attemptLogin()

3: validate()


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()


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()


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()


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


1. Administrator menekan tombol Edit di laman Detail Poster, lalu Controller

2. Controller mengambil data kategori, fakultas, lokasi, dan poster sesuai

model yang bersangkutan, lalu menampilkan laman formulir pengeditan

poster.

3. Administrator mengubah data-data poster, lalu laman tersebut mengirimkan

data formulir tersebut ke Controller.

4. Controller mengambil aturan validasi masukan yang telah didefinisikan

pada objek Poster Request, lalu melakukan validasi melalui objek Validator.

5. Validator mengirimkan konfirmasi hasil proses validasi masukan

administrator.

6. Controller menyimpan data poster terbaru melalui objek Poster Model dan

menampilkan pesan konfirmasi pengeditan poster di laman Detail Poster.


59

Gambar 3.10 Sequence Diagram Proses Menambah Poster

SequenceDiagramMenambahPoster


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


11: Rules

6: Locations

4: Categories

2: Faculties

15: DisplayConfirmationMessage()14: saveNewPoster()


10: getRules()9: sendRequest()

8: entryData()7: displayPage()

5: getLocations()

3: getCategories()

1: getFaculties()


60

Gambar 3.11 Sequence Diagram Proses Mengedit Poster

SequenceDiagramMengeditPoster


15: Rules

10: Locations

8: Categories

6: Faculties

4: Poster3: getPoster( id )2: sendRequest( id )1: clickEditButton()

19: DisplayConfirmationMessage()18: savePoster( id )


14: getRules()13: sendRequest( id )

12: entryData()11: displayPoster()

9: getLocations()

7: getCategories()

5: getFaculties()

EditPosterPage Ctrl ValidatorAdmin PosterRequestFacultyModel CategoryModel LocationModel PosterModelDetailPosterPage


15: Rules

10: Locations

8: Categories

6: Faculties

4: Poster3: getPoster( id )2: sendRequest( id )1: clickEditButton()

19: DisplayConfirmationMessage()18: savePoster( id )



12: entryData()11: displayPoster()

9: getLocations()

7: getCategories()

5: getFaculties()


61

B.7 Sequence Diagram Proses Menghapus Poster

Gambar 3.12 Sequence Diagram Proses Menghapus Poster

Sequence diagram proses menghapus poster oleh administrator ditunjukkan


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()



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


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()


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


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 )


3: confirm()4: sendRequest( id )

2: showConfirmationDialog()

Admin ListCategoriesPage Ctrl CategoryModel


5: deleteCategory( id )





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


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.


6. Controller menyimpan data kategori yang telah diedit melalui objek

Category Model, lalu menampilkan pesan konfirmasi pengeditan kategori

pada laman List Categories.


65

Gambar 3.15 Sequence Diagram Proses Menambah Kategori

SequenceDiagramMenambahKategori


4: Rules

8: showConfirmationMessage()7: saveNewCategory()


3: getRules()2: sendFormData()1: entryData()

Admin AddCategoryPage Ctrl CategoryRequest Validator CategoryModelListCategoriesPage


4: Rules

8: showConfirmationMessage()7: saveNewCategory()




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()


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()


12: saveCategory( id )13: showConfirmationMessage()


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.


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


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)


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.


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


1. Controller mengambil seluruh data fakultas melalui objek Faculty Model.

2. Controller menampilkan data fakultas pada laman List Faculties.


Faculties.

SequenceDiagramProsesMenghapusGedungKampus


4: sendRequest( id )3: confirm()


5: deleteLocation( id )


Admin ListLocationsPage Ctrl LocationModel




5: deleteLocation( id )



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



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()


70

4. Controller melakukan validasi terhadap masukan pengguna melalui objek

Validator menggunakan aturan-aturan yang telah didapatkan sebelumnya.


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


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.


7. Controller menyimpan data gedung kampus yang telah diedit melalui objek

Location Model, lalu menampilkan pesan konfirmasi pengeditan gedung

kampus pada laman List Locations.


71

Gambar 3.20 Sequence Diagram Proses Menambah Gedung Kampus

SequenceDiagramProsesMenambahGedungKampus


4: Rules

1: entryData()2: sendFormData() 3: getRules()


7: saveNewLocation()8: showConfirmationMessage()

Admin AddLocationPage Ctrl LocationRequest Validator LocationModelListLocationsPage


4: Rules



7: saveNewLocation()8: showConfirmationMessage()


72

Gambar 3.21 Sequence Diagram Proses Mengedit Gedung Kampus

SequenceDiagramProsesMengeditGedungKampus


9: Rules

4: Location

13: showConfirmationMessage()12: saveLocation( id )


8: getRules()

1: clickEditButton() 2: sendRequest( id ) 3: getLocation( id )

5: showLocation()6: entryData() 7: sendRequest( id )

Admin EditLocationPage Ctrl LocationRequest Validator LocationModelListLocationsPage


9: Rules

4: Location

13: showConfirmationMessage()12: saveLocation( id )


8: getRules()

1: clickEditButton() 2: sendRequest( id ) 3: getLocation( id )

5: showLocation()6: entryData() 7: sendRequest( id )


73

B.17 Sequence Diagram Proses Menghapus Fakultas

Gambar 3.22 Sequence Diagram Proses Menghapus Fakultas

Sequence diagram proses menghapus fakultas oleh administrator


1. Administrator menekan tombol Delete pada baris data fakultas tertentu di

laman List Faculties.

2. Laman List Faculties menampilkan kotak dialog konfirmasi penghapusan

fakultas.


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


1. Controller mengambil seluruh data token melalui objek Token Model, lalu

menampilkan data tersebut pada laman List Tokens.

SequenceDiagramProsesMenghapusFakultas




5: deleteFaculty( id )


Admin ListFacultiesPage Ctrl FacultyModel




5: deleteFaculty( id )



74


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



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()


75

3. Controller mengambil aturan validasi masukan melalui objek Faculty


objek Validator.


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


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.


6. Controller menyimpan data fakultas yang telah diedit melalui objek Faculty

Model, lalu menampilkan pesan konfirmasi pengeditan fakultas pada laman

List Faculties.


76

Gambar 3.24 Sequence Diagram Proses Menambah Fakultas

SequenceDiagramProsesMenambahFakultas


4: Rules



7: saveNewFaculty()8: showConfirmationMessage()

Admin AddFacultyPage Ctrl FacultyRequest Validator FacultyModelListFacultiesPage


4: Rules



7: saveNewFaculty()8: showConfirmationMessage()


77

Gambar 3.25 Sequence Diagram Proses Mengedit Fakultas

SequenceDiagramProsesMengeditFakultas


9: Rules

4: Faculty

13: showConfirmationMessage()12: saveFaculty( id )


8: getRules()

1: clickEditButton() 2: sendRequest( id ) 3: getFaculty( id )

5: showFaculty()6: entryData() 7: sendRequest( id )

Admin EditFacultyPage Ctrl FacultyRequest Validator FacultyModelListFacultiesPage


9: Rules

4: Faculty

13: showConfirmationMessage()12: saveFaculty( id )


8: getRules()

1: clickEditButton() 2: sendRequest( id ) 3: getFaculty( id )

5: showFaculty()6: entryData() 7: sendRequest( id )


78

B.21 Sequence Diagram Proses Menghapus Token

Sequence diagram proses menghapus token oleh administrator ditunjukkan


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.


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




5: deleteToken( id )


Admin ListTokensPage Ctrl TokenModel




5: deleteToken( id )



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


1. Controller mengambil data seluruh lokasi dan kategori melalui objek Model

yang bersangkutan, lalu menampilkan laman Add Token.


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()


80

3. Controller mengambil aturan validasi masukan melalui objek Token


objek Validator.


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


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


objek Validator.


7. Controller menyimpan data token yang telah diedit melalui objek Token

Model, lalu menampilkan pesan konfirmasi pada laman List Tokens.


81

Gambar 3.28 Sequence Diagram Proses Menambah Token

SequenceDiagramProsesMenambahAccessKey


9: Rules

4: Locations

2: Categories

5: displayPage()

3: getLocations()

1: getCategories()



12: saveNewToken()13: showConfirmationMessage()

Admin AddTokenPage Ctrl TokenRequest Validator TokenModelListTokensPage LocationModelCategoryModel


9: Rules

4: Locations

2: Categories

5: displayPage()

3: getLocations()

1: getCategories()



12: saveNewToken()13: showConfirmationMessage()


82

Gambar 3.29 Sequence Diagram Proses Mengedit Token

SequenceDiagramProsesMengeditAccessKey


13: Rules

8: Category

6: Locations

4: Categories

5: getLocations()

3: getCategories()

17: showConfirmationMessage() 16: saveToken( id )


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


13: Rules

8: Category

6: Locations

4: Categories

5: getLocations()

3: getCategories()

17: showConfirmationMessage() 16: saveToken( id )


12: getRules()

1: clickEditButton() 2: sendRequest( id )

7: getCategory( id )

9: showCategory()10: entryData()

11: sendRequest( id )


83

B.25 Sequence Diagram Proses Menambah Administrator

Sequence diagram proses menambah administrator oleh Super


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


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.


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


1. Super Administrator menekan tombol Delete pada baris data administrator

tertentu di laman List Admins.

SequenceDiagramProsesMenghapusAdmin


5: deleteAdmin( id )




Admin ListAdminsPage Ctrl UserModel


5: deleteAdmin( id )





85

Gambar 3.31 Sequence Diagram Proses Menambah Administrator

SequenceDiagramProsesMenambahAdmin


7: Rules

2: Roles3: displayPage()

1: getRoles()

11: showConfirmationMessage()10: saveNewAdmin()



Admin AddAdminPage Ctrl UserRequest Validator UserModelListAdminsPage RoleModel


7: Rules

2: Roles3: displayPage()

1: getRoles()

11: showConfirmationMessage()10: saveNewAdmin()




86

Gambar 3.32 Sequence Diagram Proses Mengedit Peran Administrator

SequenceDiagramProsesMengeditPeranAdmin


11: Rules

6: AdminRole

4: Roles3: getRoles()

9: sendRequest( id )8: entryData()

7: showAdminRole()

5: getAdminRole( id )

2: sendRequest( id )1: clickEditButton()

10: getRules()


14: saveAdmin( id )15: showConfirmationMessage()

Admin EditRoleAdminPage Ctrl UserRequest Validator UserModelListAdminsPage RoleModel


11: Rules

6: AdminRole

4: Roles3: getRoles()

9: sendRequest( id )8: entryData()

7: showAdminRole()

5: getAdminRole( id )

2: sendRequest( id )1: clickEditButton()

10: getRules()


14: saveAdmin( id )15: showConfirmationMessage()


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


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.


7. Controller menyimpan data administrator terbaru melalui objek User

Model, lalu menampilkan pesan konfirmasi pengeditan data diri

administrator di laman Profile.


88

Gambar 3.33 Sequence Diagram Proses Mengedit Data Diri

SequenceDiagramProsesMengubahDataDiriAdmin


9: Rules

4: Profile



6: entryData()5: displayProfile()

3: getProfile( id )2: sendRequest( id )

1: clickEditButton()

13: showConfirmationMessage()12: saveAdmin( id )

ProfilePage Ctrl UserModelAdmin UserRequest ValidatorEditProfilePage


9: Rules

4: Profile



6: entryData()5: displayProfile()

3: getProfile( id )2: sendRequest( id )

1: clickEditButton()

13: showConfirmationMessage()12: saveAdmin( id )


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


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()


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.


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


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


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


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


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


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.


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 >>


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.


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.


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.


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.


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


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.


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



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()


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 )


105

B.3 Sequence Diagram Proses Melihat Detail Informasi Poster

Sequence diagram proses melihat detail informasi poster oleh pengguna


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


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()


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()


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.


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.


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


1. Pengguna mengklik tombol Delete Bookmark pada Detail Activity.


108


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.


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


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.


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 )


4: List < bookmark >

3: getBookmark()


110

Gambar 3.46 Sequence Diagram Proses Menghapus Bookmar

SequenceDiagramMenghapusBookmark

9: showUpdatedBookmark()8: setRecyclerViewAdapter( adapter )


5: List < bookmark >4: getUpdatedBookmark()

3: deleteBookmark( id )2: sendRequest()


Pengguna DetailActivity BookmarkFragment Ctrl DBHandlerAdapter

9: showUpdatedBookmark()8: setRecyclerViewAdapter( adapter )


5: List < bookmark >4: getUpdatedBookmark()

3: deleteBookmark( id )2: sendRequest()



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


1. Pengguna memilih menu Tutorial pada Main Activity


3. Controller menampilkan panduan penggunaan aplikasi pada objek Tutorial

Activity.

SequenceDiagramMencariBookmark

7: showListBookmark()


5: Adapter4: setNewAdapter( List < bookmark > )

3: findBookmark( keyword )2: sendRequest( keyword )

1: inputTitleKeyword()

Pengguna BookmarkFragment Adapter Ctrl

7: showListBookmark()


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()


112

B.10 Sequence Diagram Melakukan Penyaringan Informasi

Sequence diagram proses melakukan penyaringan informasi poster oleh


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.


Poster Fragment, lalu menampilkan daftar poster yang telah tersaring.


113

Gambar 3.49 Sequence Diagram Proses Melakukan Penyaringan Informasi

SequenceDiagramPenyaringanInformasi


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


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()


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.


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()


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


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 )


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.


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 ()


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 ()


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


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


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


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


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


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


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


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


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


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


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.


BAB III METODOLOGI PENELITIAN DAN PERANCANGAN …

Documents

Transcript of BAB III METODOLOGI PENELITIAN DAN PERANCANGAN …