Perancangan dan Pembuatan CMS iLab - Bachelor Degree Final Report
-
Upload
sunu-wibirama -
Category
Documents
-
view
7.493 -
download
2
description
Transcript of Perancangan dan Pembuatan CMS iLab - Bachelor Degree Final Report
PERANCANGAN DAN PEMBUATAN CONTENT
MANAGEMENT SYSTEM (CMS) LABORATORIUM ‘iLAB’
MENGGUNAKAN FRAMEWORK CakePHP
SKRIPSI
Diajukan untuk memenuhi salah satu syarat
memperoleh gelar Sarjana Teknik pada Jurusan Teknik Elektro
Fakultas Teknik Universitas Gadjah Mada
Diajukan oleh
SUNU WIBIRAMA
NIM 03/165034/TK/28452
JURUSAN TEKNIK ELEKTRO FAKULTAS TEKNIK
UNIVERSITAS GADJAH MADA
2007
ii
HALAMAN PENGESAHAN
PERANCANGAN DAN PEMBUATAN CONTENT
MANAGEMENT SYSTEM (CMS) LABORATORIUM ‘iLAB’
MENGGUNAKAN FRAMEWORK CakePHP
TUGAS AKHIR
Diajukan untuk memenuhi salah satu syarat memperoleh gelar sarjana
di Jurusan Teknik Elektro Fakultas Teknik
Universitas Gadjah Mada
Telah disetujui dan disahkan sebagai tugas akhir
di Yogyakarta pada hari Selasa, 2 Oktober 2007
Dosen Pembimbing I
Ir. Lukito Edi Nugroho, M.Sc., Ph.D.
NIP 131 963 570
Dosen Pembimbing II
Indriana Hidayah, S.T.
NIP 132 302 667
iii
HALAMAN PERSEMBAHAN
“Khoirunnas Anfauhum Linnas”
Sebaik-baik manusia adalah yang bermanfaat untuk manusia lain
(Muhammad SAW.)
“Antum Ar Ruhul Jadid fii Jasad Al Ummah”
Engkau adalah semangat baru yang menginspirasi umat manusia
(Hasan Al Banna)
iv
v
KATA PENGANTAR
Tema pemrograman selalu menjadi hal yang menarik untuk penulis. Awal
tahun 2002, penulis tertarik dengan pemrograman aplikasi web menggunakan
bahasa PHP dan database MySQL. Interaksi penulis bersama dunia pemrograman
web selama empat tahun mengantarkan penulis pada keahlian khusus
pemrograman berorientasi objek dan pendalaman framework berbasis PHP.
Berbagai macam framework dan Content Management System (CMS) telah dicoba.
Sampai saat ini, masih sangat sedikit CMS open source yang diimplementasikan
untuk manajemen laboratorium.
Penulis mengangkat tema “Perancangan dan Pembuatan Content
Management System (CMS) Laboratorium ’iLab’ Menggunakan Framework
CakePHP” untuk mengetahui lebih jauh implementasi framework CakePHP dalam
pembuatan Content Management System berskala menengah yang memiliki
fungsionalitas spesifik. Selain itu, penulis masih melihat minimnya implementasi
teknologi informasi untuk manajemen laboratorium di Jurusan Teknik Elektro
UGM, sesuatu yang bertolak belakang dengan kondisi laboratorium di berbagai
universitas bertaraf internasional.
Dalam kesempatan ini, penulis mengucapkan terima kasih kepada dosen
pembimbing, Bapak Lukito Edi Nugroho dan Ibu Indriana Hidayah, atas
bimbingan, pengarahan, serta dukungannya terhadap skripsi dalam bidang
perancangan sistem informasi; semua anggota keluarga penulis yang selalu
memberi dukungan baik moral maupun finansial bagi penulis selama mengerjakan
vi
tugas akhir ini; Bapak Mujiharjo yang selalu setia memberikan saran dan kritik
untuk sistem manajemen Laboratorium Informatika yang lebih baik; “keluarga
kedua”-ku, seluruh kru Nightlogin 2001-2005, terima kasih atas dukungan
semangat kalian; seluruh kru Magatrika 2003 yang rela menyisihkan waktunya
untuk menjadi penguji aplikasi iLab ini; “keluarga ketiga”-ku yang memberi
semangat dan saran, Ustadz Nurkholis Wijayanto, Ustadz Wahid Musthofa, Arif
Kurniawan, Susilo, Tyas Ikhsan Hikmawan, Trapsi Haryadi, dan Lukman Hakim
yang selalu berapi-api; seluruh kru remaja masjid, pengurus Masjid Margo
Rahayu, Forum Silaturrahim Remaja Masjid Yogyakarta (FSRMY) yang
memberikan kesempatan kepada penulis untuk menyelesaikan naskah tugas akhir;
seluruh staf Teknik Elektro Universitas Gadjah Mada, atas bantuannya dalam hal
administrasi; Larry E. Masters dan kawan-kawan di Cake Software Foundation
yang membantu penulis mendalami framework CakePHP melalui email dan
forum diskusi; seluruh kru Idcake.Web.Id yang memberi saran dan semangat;
Nicholas Mario Wardhana atas dukungan, saran dan kerelaannya menjadi penguji
aplikasi; teman-teman Teknik Elektro Universitas Gadjah Mada angkatan 2003,
yang senasib seperjuangan dalam memperoleh kelulusan; dan tentunya kepada
Allah SWT. Tanpa kekuatan-Nya, penulis bukanlah apa-apa.
Akhir kata, penulis mengharapkan saran dan kritik yang membangun bagi
pengembangan aplikasi ini.
Yogyakarta, 1 September 2007
Penulis
vii
DAFTAR ISI
HALAMAN JUDUL ..........................................................................................................I
HALAMAN PENGESAHAN.......................................................................................... II
HALAMAN PERSEMBAHAN .....................................................................................III
KATA PENGANTAR...................................................................................................... V
DAFTAR ISI.................................................................................................................. VII
DAFTAR GAMBAR........................................................................................................ X
DAFTAR TABEL ........................................................................................................XIII
BAB I PENDAHULUAN.................................................................................................. 1
1.1 LATAR BELAKANG MASALAH ............................................................................... 1 1.2 PERUMUSAN MASALAH ......................................................................................... 2 1.3 BATASAN MASALAH .............................................................................................. 3 1.4 MAKSUD DAN TUJUAN PENELITIAN ...................................................................... 3 1.5 METODE PENELITIAN ............................................................................................. 5 1.6 SISTEMATIKA PENULISAN...................................................................................... 5
BAB II LANDASAN TEORI ........................................................................................... 7
2.1 CONTENT MANAGEMENT SYSTEM............................................................................ 7 2.1.1 Definisi CMS................................................................................................... 7 2.1.2 Elemen Utama CMS ....................................................................................... 8
2.1.2.1 Content Management Application (CMA) ............................................... 8 2.1.2.2 Metacontent Management Application (MMA) ..................................... 13 2.1.2.3 Content Delivery Application (CDA) ..................................................... 17
2.1.3 CMS untuk Laboratorium............................................................................. 19 2.2 FRAMEWORK CAKEPHP ....................................................................................... 21
2.2.1 Aplikasi Berbasis Framework....................................................................... 21 2.2.2 Sekilas Framework CakePHP ...................................................................... 22 2.2.3 Konsep Object Oriented Programming (OOP) ............................................ 23 2.2.4 Konsep Model-View-Controller (MVC) ....................................................... 25 2.2.5 Arsitektur CakePHP ..................................................................................... 29 2.2.6 Kelebihan dan Kekurangan .......................................................................... 31
BAB III ANALISIS DAN PERANCANGAN SISTEM............ ................................... 34
3.1 ANALISIS KEBUTUHAN SISTEM ........................................................................... 34 3.1.1 Kebutuhan Umum Laboratorium.................................................................. 34 3.1.2 Prosedur Manajemen Praktikum.................................................................. 41 3.1.3 Pengolahan Data Pendaftaran Praktikum ................................................... 46 3.1.4 Fitur Tambahan............................................................................................ 47
3.2 PERANCANGAN ANTARMUKA .............................................................................. 48 3.2.1 Halaman Pengunjung................................................................................... 48 3.2.2 Halaman Login............................................................................................. 50
viii
3.2.3 Halaman Administrasi..................................................................................51 3.2.4 Halaman Menu Administrasi........................................................................ 52
3.3 PERANCANGAN BASIS DATA ............................................................................... 53 3.3.1 Diagram E-R (ERD / Entity Relationship Diagram).................................... 53 3.3.2 Diagram LRS (Logical Record Structure).................................................... 56 3.3.3 Rancangan Tabel Basis Data ....................................................................... 59
3.4 DISAIN ARSITEKTUR SISTEM ............................................................................... 65 3.4.1 Arsitektur MVC pada CMS iLab................................................................... 65 3.4.2 Hak Akses User............................................................................................. 66 3.4.3 Use Case....................................................................................................... 67 3.4.4 Program Flow............................................................................................... 70
3.5 KOMPONEN CMS................................................................................................. 72 3.5.1 Framework CakePHP................................................................................... 72 3.5.2 Pustaka Utama (webroot)............................................................................. 73 3.5.3 Pustaka Tambahan ....................................................................................... 75 3.5.4 Konfigurasi ................................................................................................... 78 3.5.5 Modul utama................................................................................................. 81
3.5.5.1 Modul Home........................................................................................... 82 3.5.5.2 Modul News ........................................................................................... 83 3.5.5.3 Modul Profile.......................................................................................... 85 3.5.5.4 Modul Practicum .................................................................................... 86 3.5.5.5 Modul Resource...................................................................................... 89 3.5.5.6 Modul Project and Research................................................................... 90 3.5.5.7 Modul Guestbook ................................................................................... 91 3.5.5.8 Modul Link............................................................................................. 92 3.5.5.9 Modul User............................................................................................. 92 3.5.5.10 Modul Setting........................................................................................ 93
3.5.6 Diagram Inheritance Modul Utama ............................................................. 94 3.5.7 Modul tambahan........................................................................................... 98
3.5.7.1 Modul Login........................................................................................... 98 3.5.7.2 Modul Installer ....................................................................................... 99
BAB IV IMPLEMENTASI DAN PENGUJIAN APLIKASI ......... ........................... 100
4.1 ALAT DAN BAHAN YANG DIGUNAKAN .............................................................. 100 4.1.1 Peralatan yang Digunakan......................................................................... 100 4.1.2 Bahan yang Digunakan .............................................................................. 101
4.2 IMPLEMENTASI KOMPONEN CMS...................................................................... 101 4.2.1 Framework CakePHP................................................................................. 101 4.2.2 Modul Utama.............................................................................................. 105
4.2.2.1 Modul Home......................................................................................... 105 4.2.2.2 Modul News ......................................................................................... 110 4.2.2.3 Modul Profile........................................................................................ 117 4.2.2.4 Modul Practicum .................................................................................. 118 4.2.2.5 Modul Resource.................................................................................... 133 4.2.2.6 Modul Project and Research................................................................. 137 4.2.2.7 Modul Guestbook ................................................................................. 139 4.2.2.8 Modul Link........................................................................................... 141 4.2.2.9 Modul User........................................................................................... 142 4.2.2.10 Modul Setting...................................................................................... 144
4.2.3 Modul Tambahan........................................................................................145
ix
4.2.3.1 Modul Login......................................................................................... 145 4.2.3.2 Modul Installer ..................................................................................... 146
4.3 PENGUJIAN SISTEM ............................................................................................ 148 4.3.1 Metode Pengujian....................................................................................... 148 4.3.2 Pengujian Antarmuka................................................................................. 149 4.3.3 Pengujian Instalasi Sistem.......................................................................... 152
4.3.3.1 Implementasi pada sistem operasi Microsoft Windows ....................... 152 4.3.3.2 Implementasi pada sistem operasi Ubuntu Linux................................. 153 4.3.3.3 Implementasi pada sistem operasi OpenBSD....................................... 155 4.3.3.4 Rekomendasi Metode Instalasi ............................................................. 156
4.3.4 Interaksi User dan Sistem........................................................................... 159 4.3.4.1 Uji Praktikan......................................................................................... 159 4.3.4.2 Uji Administrasi ................................................................................... 161
4.3.5 Analisis Umum Hasil Pengujian................................................................. 163 4.4 EVALUASI SISTEM.............................................................................................. 164
4.4.1 Evaluasi terhadap Tujuan Penelitian ......................................................... 164 4.4.2 Hambatan terhadap Penelitian................................................................... 165 4.4.3 Kemungkinan Pengembangan Sistem Lebih Lanjut ................................... 165
BAB V KESIMPULAN DAN SARAN........................................................................ 167
5.1 KESIMPULAN......................................................................................................167 5.2 SARAN ................................................................................................................ 168
DAFTAR PUSTAKA.................................................................................................... 169
x
DAFTAR GAMBAR
Gambar 2.1 Content Management Application............................................................... 10
Gambar 2.2 Metacontent Management Application........................................................ 14
Gambar 2.3 Bagan alir CMS........................................................................................... 18
Gambar 2.4 Logo resmi framework CakePHP................................................................ 23
Gambar 2.5 Diagram Model-View-Controller................................................................ 26
Gambar 2.6 Alur kerja dan konsep MVC pada CakePHP.............................................. 28
Gambar 2.7 Arsitektur framework CakePHP.................................................................. 29
Gambar 3.1 Permasalahan di laboratorium dan pemecahannya.................................... 39
Gambar 3.2 Implementasi CMS iLab di jaringan lokal...................................................41
Gambar 3.3 Diagram alir mekanisme pendaftaran praktikan........................................ 43
Gambar 3.4 Diagram alir mekanisme pendaftaran asisten............................................. 45
Gambar 3.5 Rancangan halaman pengunjung................................................................ 49
Gambar 3.6 Rancangan halaman login........................................................................... 50
Gambar 3.7 Rancangan halaman administrasi............................................................... 51
Gambar 3.8 Rancangan halaman menu administrasi..................................................... 52
Gambar 3.9 Diagram E-R basis data CMS iLab............................................................. 55
Gambar 3.10 Diagram LRS basis data CMS iLab........................................................... 58
Gambar 3.11 Arsitektur MVC pada CMS iLab............................................................... 65
Gambar 3.12 Use Case CMS iLab................................................................................... 68
Gambar 3.13 Program Flow CMS iLab.......................................................................... 71
Gambar 3.14 Struktur pustaka utama.............................................................................. 74
Gambar 3.15 Teks editor TinyMCE................................................................................. 74
Gambar 3.16 Konfigurasi pustaka Kcaptcha.................................................................. 75
Gambar 3.17 CAPTCHA dari pustaka Kcaptcha............................................................ 76
Gambar 3.18 Implementasi pustaka Pagination............................................................. 77
Gambar 3.19 Pustaka XSLT aktif.................................................................................... 78
Gambar 3.20 Sebagian konfigurasi core.php.................................................................. 79
Gambar 3.21 Konfigurasi pada routes.php..................................................................... 80
Gambar 3.22 Konfigurasi koneksi database.................................................................... 81
Gambar 3.23 Diagram Inheritance class-class Model.................................................... 95
Gambar 3.24 Diagram Inheritance class-class Controller (1)........................................ 96
xi
Gambar 3.25 Diagram Inheritance class-class Controller (2)........................................ 97
Gambar 4.1. Penggunaan fungsi niceShort()................................................................ 102
Gambar 4.2. Penggunaan fungsi niceShort() pada antarmuka..................................... 102
Gambar 4.3. Fungsi niceShort() yang sudah dimodifikasi............................................ 103
Gambar 4.4. Penggunaan fungsi timeAgoInWords() pada antarmuka......................... 103
Gambar 4.5. Fungsi timeAgoInWords() yang sudah dimodifikasi................................ 105
Gambar 4.6. Validasi input pada Model Home............................................................. 106
Gambar 4.7. Penulisan pesan kesalahan pada View..................................................... 106
Gambar 4.8. Fungsi beforeFilter()................................................................................ 107
Gambar 4.9. Info login saat user ’sunu’ sedang login.................................................. 108
Gambar 4.10. Fungsi index() pada class HomesController.......................................... 108
Gambar 4.11. Fungsi add() pada class HomesController............................................. 109
Gambar 4.12. Halaman administrasi modul Home....................................................... 110
Gambar 4.13. Class Model Home.................................................................................. 111
Gambar 4.15. Deklarasi variabel class NewsController............................................... 112
Gambar 4.15. Fungsi edit() pada class NewsController............................................... 113
Gambar 4.16. Mengambil record dari field ’name’ tabel newscategories.................... 114
Gambar 4.17. Hasil pengambilan record oleh NewsController.................................... 114
Gambar 4.18. Fungsi search() pada class NewsController.......................................... 115
Gambar 4.19. Tampilan live search pada bagian View modul News............................ 115
Gambar 4.20. Tiga kondisi fitur Live Search................................................................ 116
Gambar 4.21. Halaman depan modul News.................................................................. 117
Gambar 4.22. Fungsi main() pada class ProfilesController......................................... 118
Gambar 4.23. Asosiasi has many pada class Practicumname...................................... 119
Gambar 4.24. Fungsi index() pada class PracticumnamesController.......................... 120
Gambar 4.25. Fungsi index() pada class PracticumnamesController.......................... 121
Gambar 4.26. Setting aktivasi pada fungsi index() PracticumschedulesController...... 123
Gambar 4.27. Fungsi register() pada PracticumschedulesController.......................... 124
Gambar 4.27. Fungsi cetak() pada PracticumschedulesController.............................. 125
Gambar 4.27. Konverter MySQL ke spreadsheet pada file excel.thml.......................... 125
Gambar 4.28. Asosiasi HABTM pada Model Practicumname...................................... 126
Gambar 4.29. Form isian data praktikan...................................................................... 128
Gambar 4.29. Form isian jadwal praktikum................................................................. 128
Gambar 4.30. CAPTCHA pada bagian akhir halaman pendaftaran praktikan............ 129
xii
Gambar 4.31. Massive Checking pada PracticiansController...................................... 130
Gambar 4.31. Form update data praktikan................................................................... 131
Gambar 4.32. Asosiasi belongs to pada Model Assistant.............................................. 132
Gambar 4.33. Asosiasi belongs to pada Model Resource............................................. 133
Gambar 4.34. Fungsi add() pada ResourcesController................................................ 134
Gambar 4.35. Fungsi delete() dan rdel() pada ResourcesController............................ 136
Gambar 4.36. Halaman depan modul Resource............................................................ 136
Gambar 4.37. Pilihan yang muncul saat link download diakses................................... 137
Gambar 4.38. Asosiasi pada Model Project.................................................................. 138
Gambar 4.39. Antarmuka halaman detail proyek dan riset.......................................... 139
Gambar 4.40. Model Guestbook.................................................................................... 140
Gambar 4.41. Antarmuka halaman komentar buku tamu.............................................. 140
Gambar 4.42. Antarmuka halaman link dan referensi.................................................. 141
Gambar 4.43. Asosiasi belongs to pada Model User.................................................... 142
Gambar 4.44. Fungsi add() pada UsersController....................................................... 143
Gambar 4.45. Asosiasi pada Model Userstatus............................................................. 144
Gambar 4.46. Model Login............................................................................................ 145
Gambar 4.47. Proses pembuatan file database.php...................................................... 147
Gambar 4.48. Fungsi __executeSQLScript()................................................................. 148
Gambar 4.49. CMS iLab berjalan pada sistem operasi Microsoft Windows................ 153
Gambar 4.50. CMS iLab berjalan pada sistem operasi Ubuntu Linux......................... 154
Gambar 4.51. CMS iLab berjalan pada sistem operasi OpenBSD............................... 156
Gambar 4.52. Konfigurasi pada Apache Web Server.................................................... 158
Gambar 4.53. Konfigurasi tambahan pada file .htaccess.............................................. 158
Gambar 4.54. Konfigurasi lengkap pada file .htaccess................................................. 158
Gambar 4.55. Konfigurasi tambahan file index.php..................................................... 158
Gambar 4.56. Pengujian aplikasi oleh staf Laboratorium Informatika........................ 160
Gambar 4.57. Pengujian aplikasi oleh laboran Laboratorium Informatika ................. 162
xiii
DAFTAR TABEL
Tabel 2.1 Struktur file dan folder framework CakePHP.................................................. 30
Tabel 3.1 Contoh tabel pendaftaran praktikum............................................................... 46
Tabel 3.2 Simbol diagram E-R versi Chen....................................................................... 54
Tabel 3.3 Kategori user CMS iLab.................................................................................. 66
Tabel 3.4 Administrasi modul utama CMS iLab.............................................................. 67
Tabel 4.1 Hasil pengujian antarmuka............................................................................ 150
Tabel 4.2 Implementasi CMS iLab pada Microsoft Windows XP.................................. 152
Tabel 4.3 Implementasi CMS iLab pada Ubuntu Linux 6.0........................................... 153
Tabel 4.4 Implementasi CMS iLab pada OpenBSD 3.9................................................. 155
Tabel 4.5 Hasil uji praktikan.......................................................................................... 159
Tabel 4.6 Hasil uji administrasi .................................................................................... 161
1
BAB I
PENDAHULUAN
1.1 Latar Belakang Masalah
Teknologi informasi sebagai salah satu cabang ilmu pengetahuan di bidang
ilmu komputer kontemporer memberikan banyak alternatif solusi untuk
pengembangan manajemen dan otomatisasi proses lalu lintas data di berbagai
lapangan pekerjaan. Selain kebutuhan manajemen dan otomatisasi proses,
teknologi informasi juga mempercepat waktu transfer informasi, sehingga terjadi
peningkatan efektivitas konsumsi informasi di lapangan kerja terkait.
Salah satu implementasi teknologi informasi yang menjadi kebutuhan
mahasiswa, dosen, laboran, dan karyawan institusi pendidikan atau perguruan
tinggi adalah penggunaan Content Management System (CMS) 1 untuk
pengelolaan laboratorium dan praktikum. CMS didefinisikan sebagai sebuah
aplikasi yang bisa dimanfaatkan untuk mengelola berbagai metode yang
berhubungan dengan web publishing. Sebuah CMS secara umum bisa dikustomasi
dengan menambahkan atau mengurangi fitur yang spesifik, sehingga hanya fitur-
fitur tertentu yang diinginkan saja yang akan ditampilkan kepada publik. Dalam
perkembangan teknologi saat ini, CMS banyak dikembangkan untuk membuat
forum diskusi, website jual beli online, website komunitas, galeri foto online, dan
masih banyak lagi (Douglas et.al, 2006).
1 Untuk selanjutnya akan disebut dengan CMS saja.
2
CMS untuk pengelolaan laboratorium dan praktikum yang dalam tugas
akhir ini diberi nama “iLab” merupakan sebuah CMS yang digunakan untuk
mempermudah laboran, mahasiswa, dosen dan karyawan insitusi pendidikan atau
perguruan tinggi dalam melakukan pengelolaan segala hal yang terkait dengan
laboratorium dan pelaksanaan praktikum. Dengan menggunakan CMS ini,
diharapkan proses riset dan praktikum yang ada di laboratorium akan semakin
meningkat. Selain itu, CMS ini juga akan memudahkan laboran dalam melakukan
mekanisme penjadwalan praktikum, penggunaan ruangan laboratorium,
pendaftaran praktikum, penyediaan modul dan bahan-bahan praktikum, publikasi
hasil penemuan dan penelitian mahasiswa serta penjadwalan asisten praktikum
dan laboran sesuai dengan jadwal yang telah disepakati. CMS laboratorium ini
nantinya bisa dikembangkan menjadi sebuah sistem informasi dengan modul yang
lebih kompleks dan beragam yang sesuai dengan perkembangan teknologi
informasi saat ini, seperti pendaftaran dan penjadwalan praktikum dengan
memanfaatkan SMS (Short Message Service) atau otomatisasi pengelolaan dan
pemantauan sarana praktikum (komputer, alat-alat dan perlengkapan praktikum)
jarak jauh.
1.2 Perumusan Masalah
Laboratorium–laboratorium membutuhkan sebuah sistem informasi untuk
pengelolaan informasi mulai dari pendataan praktikum, pendaftaran, resources
dan informasi laboratorium.
3
Pembuatan sistem informasi laboratorium diwujudkan dengan CMS
karena sistem CMS mampu diaplikasikan ke dalam semua lapisan, tidak hanya
untuk sebuah instansi tertentu.
Setiap laboratorium mempunyai ciri khas sendiri, oleh karena itu dibuat
sistem informasi dengan CMS karena CMS mampu dikembangkan dan
dipersonalisasi sesuai dengan kebutuhan pada masing–masing laboratorium.
1.3 Batasan Masalah
Dalam tugas akhir ini, penelitian, pengambilan contoh data, perancangan
dan pembuatan CMS berdasarkan kebutuhan laboratorium secara umum di
Jurusan Teknik Elektro Fakultas Teknik Universitas Gadjah Mada Yogyakarta.
CMS ini nantinya diharapkan bisa dikembangkan menjadi sebuah sistem
informasi yang lebih kompleks dan spesifik, sesuai dengan tujuan penggunaan
masing-masing laboratorium yang ada. Pengembangan CMS “iLab” difokuskan
pada pengembangan business logic dan database logic.
1.4 Maksud dan Tujuan Penelitian
Maksud dilakukannya penulisan tugas akhir dengan judul “Perancangan
dan Pembuatan CMS Laboratorium ’iLab’ Menggunakan Framework CakePHP”
ini adalah sebagai salah satu syarat untuk memperoleh gelar sarjana strata satu (S-
1) di Jurusan Teknik Elektro Fakultas Teknik, Universitas Gadjah Mada.
4
Pemilihan tema tugas akhir terkait dengan perancangan dan pembuatan CMS
untuk laboratorium didasarkan pada beberapa hal berikut ini :
1. Belum adanya CMS Open Source berbasis web buatan Indonesia yang
ditujukan khusus untuk manajemen laboratorium. CMS ini diharapkan
akan berkembang menjadi aplikasi yang lebih luas apabila menjadi
perangkat lunak Open Source.
2. Pengembangan CMS dengan framework yang sudah ada. Selain
melakukan eksplorasi terhadap framework tersebut, penggunaan
framework akan memudahkan programmer untuk mengembangkan
aplikasi ini secara simultan.
3. Kemudahan dalam implementasi. CMS ini akan dilengkapi dengan modul
instalasi, sehingga jauh lebih mudah digunakan dibandingkan beberapa
CMS Open Source buatan Indonesia yang sudah beredar di internet,
seperti Aura, eNDONESIA, dan semacamnya.
4. Sederhana dan mudah digunakan. CMS yang dikembangkan akan
diarahkan pada sebuah aplikasi yang user friendly dengan navigasi yang
jauh lebih sederhana dari CMS yang sudah ada.
Adapun tujuan dari penulisan tugas akhir ini adalah :
1. Mengetahui dan memahami implementasi framework CakePHP untuk
membuat CMS.
2. Mengembangkan CMS untuk pengelolaan laboratorium yang diberi nama
“iLab” sehingga CMS ini bisa digunakan untuk pengelolaan laboratorium
5
manapun yang meliputi pengelolaan info laboratorium, pendaftaran,
recources, dan info praktikum.
1.5 Metode Penelitian
Secara sekuensial, perancangan dan pembuatan CMS “iLab” direncanakan
akan dilakukan dengan urutan sebagai berikut :
1. Mengumpulkan dan menganalisis contoh data-data praktikum, pendataan
praktikan, dan resource laboratorium yang ada di Jurusan Teknik Elektro
Fakultas Teknik Universitas Gadjah Mada Yogyakarta .
2. Merancang alur, modul dan logika kerja CMS dengan menggunakan UML
(Unified Modelling Language).
3. Merancang struktur dan mengimplementasikan database yang akan
digunakan untuk membangun CMS .
4. Membangun modul dan class-class menjadi sebuah CMS secara utuh.
5. Melakukan benchmarking, debugging aplikasi dan penyempurnaan
aplikasi.
1.6 Sistematika Penulisan
Penulisan Tugas Akhir ini dilakukan dengan sistematika sebagai berikut:
Bab I : Pendahuluan. Di sini akan dibahas mengenai latar belakang masalah,
perumusan masalah, batasan masalah, tujuan penulisan, metode
penelitian dan sistematika penulisan Tugas Akhir.
6
Bab II : Dasar Teori. Bab ini berisi teori-teori dasar mengenai sistem
informasi, framework CakePHP, pemrograman web dengan PHP dan
CSS, dan database MySQL.
Bab III : Analisis dan Perancangan Sistem. Bab ini membahas kebutuhan
dasar laboratorium, konsep perancangan CMS, gambaran umum, dan
implementasi framework CakePHP ke dalam pembuatan CMS
“iLab” dengan dukungan pemrograman PHP dan CSS serta database
MySQL. Detail CMS juga akan dibahas pada bab ini, mulai dari
halaman user, administrator, tampilan dan script CMS-nya.
Bab IV : Implementasi dan Pengujian Aplikasi. Bagian ini menjelaskan
kinerja CMS dan pengujian CMS dalam penerapan secara nyata,
serta kajian terhadap mekanisme penggunaannya.
Bab V : Kesimpulan dan Saran. Bab ini berisi kesimpulan dan saran
mengenai CMS yang dibuat.
7
BAB II
LANDASAN TEORI
2.1 Content Management System
2.1.1 Definisi CMS
Menurut Douglas (2006, h. xxvii), CMS didefinisikan sebagai sebuah
aplikasi yang bisa dimanfaatkan untuk mengelola berbagai metode yang
berhubungan dengan web publishing. Sebuah CMS secara umum bisa dikustomasi
dengan menambahkan atau mengurangi fitur yang spesifik, sehingga hanya fitur-
fitur tertentu yang diinginkan saja yang akan ditampilkan kepada publik. Dalam
perkembangan teknologi saat ini, CMS banyak dikembangkan untuk membuat
forum diskusi, website jual beli online, website komunitas, galeri foto online, dan
masih banyak lagi.
Menurut Fraser (2002, h. 5-7), content bisa diartikan “sesuatu” yang
terkandung dalam sebuah website. “Sesuatu” ini bisa diklasifikasikan kembali
menjadi dua kategori :
- Informasi, seperti teks dan gambar, yang bisa dilihat saat sebuah situs
diakses oleh pengunjung.
- Aplikasi atau perangkat lunak yang berjalan pada server website dan
menampilkan informasi tersebut.
8
CMS lebih banyak mengacu pada aplikasi yang mengatur bagaimana informasi
tersebut ditampilkan. Masyarakat yang membuat dan mengatur dua tipe kategori
content yang telah disebutkan di atas, sebenarnya bekerja pada dua hal yang
berbeda. Developer informasi lebih banyak berkutat untuk merancang informasi
yang persuasif dan menarik untuk ditampilkan, sedangkan developer aplikasi
(dalam hal ini adalah orang yang membuat dan bertanggung jawab terhadap
aplikasi yang menampilkan informasi tersebut) lebih bersifat teknis secara
kelilmuan. Proses pembuatan dan pengembangan CMS mengabaikan jenis
informasi yang ditampilkan, meskipun proses perancangan informasi dan
perancangan CMS memiliki alur yang mirip, yakni Create, Change, Approve, Test
dan Deploy.
2.1.2 Elemen Utama CMS
Fraser (2002, h. 9-18) juga menerangkan, CMS setidaknya terdiri dari tiga
hal, yakni Content Management Application (CMA), Metacontent Management
Application (MMA), dan Content Delivery Application (CDA).
2.1.2.1 Content Management Application (CMA)
Content Management Application (CMA) mengatur siklus manajemen
komponen content (bisa berupa teks, gambar, tabel, dan sebagainya) mulai dari
pembuatan sampai dengan penghapusan. Sebuah CMA akan membuat (create),
merawat (maintain) dan menghapus (remove) komponen content, ke dan dari
sebuah repository. Repository bisa diartikan sebuah basis data (database), sebuah
9
kumpulan berkas (file) atau kombinasi dari keduanya. Proses manajemen ini
berjalan secara sekuensial dan membentuk sebuah aliran kerja (workflow). CMA
bisa juga diartikan sebagai porsi administrasi dari CMS.
CMA memungkinkan kontributor artikel untuk mengembangkan content
tanpa harus memahami secara detail Hypertext Markup Language (HTML) atau
mempelajari arsitektur website tersebut. Hal ini akan memungkinkan adanya
proses pembaharuan (update) content dan maintenance website tanpa harus
melibatkan webmaster.
CMA biasanya melibatkan banyak user (multiuser), dimana masing-
masing user memiliki satu atau lebih aturan pada siklus manajemen komponen
content. Sebagian besar CMA memiliki sistem keamanan berbasis hak akses user
(role-based security), dalam arti user hanya diperbolehkan untuk melakukan
tugas-tugas yang diperuntukkan baginya saat user ditambahkan ke dalam sistem.
Sebuah website yang melibatkan sedikit orang dalam manajemennya mungkin
membutuhkan aturan-aturan yang tidak terlalu banyak. Namun, untuk sebuah
website besar dengan banyak birokrasi akan membutuhkan aturan-aturan yang
berbeda dengan fungsionalitas yang terbatas.
Tujuan sebuah CMA adalah untuk mengembangkan komponen content
melalui siklus manajemennya secepat mungkin. Gambar 2.1. menggambarkan
sebuah siklus yang seharusnya dimiliki oleh CMA. Adapun bagian dari siklus
CMA antara lain :
10
1. Approval
Sebelum semua proses siklus dilaksanakan dan dimulai, seseorang dengan
otoritas tertentu harus melakukan approval (penyetujuan) terhadap semua
perubahan komponen content yang dilakukan. Proses approval sangat bervariasi
pada masing-masing website, meskipun menggunakan CMS yang sama. Pada
website dengan birokrasi yang rumit, pihak yang berbeda atau user dengan tingkat
otoritas yang lebih tinggi harus melakukan approval sebelum proses dilanjutkan
ke tahap berikutnya dari siklus CMA. Sebaliknya, pada website yang lebih simpel,
seseorang bisa mengubah content sekaligus melakukan approval atas hasil
kerjanya.
Gambar 2.1 Content Management Application (Fraser, 2002)
11
2. Design
Tahap ini berupa identifikasi dan penentuan komponen content yang akan
di-publish pada website. Pada beberapa CMS, tahapan ini melibatkan beberapa
perangkat lunak pihak ketiga (third party software) yang memudahkan pembuat
CMS menyelesaikan tahapan ini tanpa harus menghabiskan banyak waktu
membuat perangkat lunak baru yang bersesuaian.
3. Authoring
Authoring adalah sebuah tahapan berupa pengambilan komponen content
yang sudah dibuat untuk di-publish ke halaman website. Pada beberapa CMS,
authoring dimungkinkan pula dilakukan melalui sebuah script khusus yang
mengambil sebuah artikel dari website lain (berupa feed atau RSS) kemudian
ditampilkan pada halaman website secara otomatis, tanpa melibatkan peran
manusia.
4. Editing
Setelah komponen content dibuat, seringkali diperlukan beberapa kali
pengubahan dan penulisan ulang pada content. Tahapan ini memerlukan
koordinasi yang cukup baik antara penulis artikel (author) dengan editor, sebab
bisa jadi keduanya melakukan overwrite content pada saat yang bersamaan.
5. Layout
Setelah semua komponen content lengkap, tahapan berikutnya adalah
menyusun komponen-komponen tersebut pada sebuah halaman website untuk
ditampikan. Tugas dari CMA adalah menyediakan cara terbaik untuk memberikan
12
saran kepada MMA (Metacontent Management Application) terkait dengan layout
dan lokasi penempatan komponen content.
6. Testing
Tahapan ini adalah pengujian terhadap tampilan halaman website yang
sudah diisi dengan content. Tahapan ini bisa berupa pengujian halaman web
terhadap beberapa software browser (seperti Internet Explorer, Mozilla Firefox,
Opera, Camino, Safari, dan sebagainya) atau bisa berupa pengujian hyperlink,
tampilan gambar, style paragraf teks, dan sebagainya. Beberapa browser
terkadang tidak mendukung beberapa model client-side scripting (seperti
Javascript atau CSS), sehingga pengujian ini menjadi penting karena pengunjung
website akan melihat halaman web sebagaimana yang ditampilkan di browser
komputer mereka.
7. Staging
Setelah semua komponen website siap untuk di-publish secara online di
internet, semua komponen web dipindahkan ke staging server. Tujuan dari sebuah
staging server adalah membuat proses produksi web secara cepat dan utuh tanpa
terganggu oleh user. Pada website dengan skala kecil tahap ini bisa diabaikan
karena tahap staging membutuhkan biaya yang tidak sedikit. Biasanya setelah
tahap testing selesai dilakukan, komponen content langsung dipindahkan ke
proses produksi.
8. Deployment
Tahap deployment bisa berarti pembaharuan komponen website, sehingga
website terkesan dinamis dan tidak stagnan. Tingkat kerumitan tahapan
13
deployment sangat bergantung pada jumlah server yang dimiliki dan jumlah
website yang dikelola.
9. Maintenance
Seringkali, pada tahap deployment dijumpai kesalahan-kesalahan yang
perlu diperbaiki. Cara terbaik untuk melakukan maintenance adalah tidak
melakukan maintenance secara langsung pada sistem yang sedang online di server.
Maintenance bisa dilakukan secara offline dan perbaikan menyeluruh dilakukan
pada sistem yang sedang online, sebagaimana saat admin meng-upload semua file
komponen website untuk pertama kalinya.
10. Archival
Komponen content yang sudah tidak up to date bisa dikumpulkan dan
diarsipkan. Pengarsipan komponen content ini bisa dilakukan secara otomatis
tanpa mengganggu proses pembaharuan content.
11. Removal
Apabila komponen content tidak lagi memerlukan update dan sudah tidak
dibutuhkan, komponen tersebut harus segera dihapus. Hal ini bisa berarti sebuah
bentuk penghematan sumber daya yang dimiliki, utamanya pada space harddisk
yang dialokasikan untuk website tersebut.
2.1.2.2 Metacontent Management Application (MMA)
MMA adalah sebuah aplikasi yang mengatur seluruh siklus metacontent.
Metacontent bisa diartikan sebagai informasi tentang komponen-komponen
content, dengan kata lain informasi yang menjelaskan bagaimana komponen-
14
komponen content diletakkan pada sebuah halaman website. Tujuan dari MMA
adalah mengembangkan metacontent melalui siklusnya. Sebagaimana CMA,
MMA juga memiliki siklus yang dijelaskan pada Gambar 2.2.
Gambar 2.2 Metacontent Management Application (Fraser, 2002)
Adapun bagian dari siklus MMA antara lain sebagai berikut :
1. Approval
Sebagaimana pada CMA, sebelum semua tahapan siklus dimulai,
seseorang dengan otoritas tertentu harus melakukan approval. Pada MMA,
approval lebih banyak dilakukan oleh sebuah badan atau komite daripada
individual sebagaimana pada CMA. Komite biasanya dibentuk dari perwakilan
semua departemen yang memiliki kepentingan terhadap website atau sistem
tersebut.
15
2. Analysis
Sebelum membuat perubahan yang cukup berarti, beberapa tipe analisis
bisnis harus dilakukan. Beberapa pertanyaan yang biasanya menjadi bahan acuan
analisis adalah : Bagaimana respon pasar terhadap perubahan yang dilakukan pada
sistem? Bagaimana pengaruh perubahan terhadap waktu respon? Apakah
perubahan skema warna pada halaman website lebih enak dipandang? Apakah
perubahan-perubahan layout memang sangat diperlukan?
3. Design
Tahapan ini menjelaskan secara detail metacontent yang akan di-deploy
pada website tersebut karena desain dari sistem harus benar-benar disetujui oleh
komite yang berwenang.
4. Creation
Pembuatan metacontent harus didasarkan pada hasil tahapan analysis dan
design yang telah dilakukan sebelumnya. Tanpa mengacu pada analysis dan
design, metacontent akan banyak mengalami kesalahan, selain karena tingkat
kerumitannya, metacontent juga saling terkait satu sama lain.
5. Build
Setelah semua tahapan pembuatan selesai, metacontent yang ada perlu
disusun dan digabungkan sedemikian rupa. Pada beberapa bahasa pemrograman,
metacontent berbentuk file ASP.NET dan C# yang memerlukan proses compiling.
6. Test
Setelah metacontent dibuat dan digabungkan, tahapan selanjutnya adalah
melakukan testing terhadap metacontent tersebut. Tidak seperti komponen-
16
komponen content, tahapan testing metacontent adalah sebuah tahapan testing
dengan tingkat akurasi yang tinggi. Testing ini mengikuti standar proses
pengembangan perangkat lunak, meliputi : tes unit, tes string, tes sistem dan tes
rilis software.
7. Stage
Setelah tahapan testing dilalui, metacontent dipindahkan ke staging server.
Pada website dengan skala kecil, tahapan ini biasanya diabaikan dan metacontent
langsung dipindahkan ke proses produksi.
8. Deployment
Deployment adalah pemindahan metacontent ke website yang sudah online.
Prosedur deployment memiliki tingkat kerumitan tersendiri, tergantung dari
jumlah server yang dikelola.
9. Maintenance
Tahapan deployment sedikit banyak menimbulkan kesalahan yang mesti
diperbaiki. Tahapan maintenance lebih banyak terfokus pada bagaimana
metacontent selalu berada dalam kondisi yang baik dan memiliki algoritma yang
paling ringkas dan paling cepat untuk dieksekusi.
10. Removal
Saat metacontent sudah tidak lagi dibutuhkan, file metacontent harus
dihapus dari server.
Tujuan dari metacontent adalah menyediakan antarmuka yang simple,
user-friendly dan konsisten untuk sebuah website. Metacontent yang di-generate
melalui MMA adalah salah satu atau kombinasi dari tiga tipe di bawah ini :
17
1. Templates
Biasanya berbentuk HTML dengan beberapa form penempatan komponen-
komponen content. Sesuai dengan fungsionalitasnya, template sangat
memungkinkan menjadi tempat bagi template lainnya yang memudahkan
developer mengatur tata letak komponen-komponen content.
2. Scripts
Sebagian besar CMS saat ini mendukung setidaknya satu bahasa
pemrograman. Bahasa pemrograman web bisa dikategorikan menjadi dua, server-
side scripting yang berjalan pada server (seperti PHP dan ASP) serta client-side
scripting yang berjalan pada browser (seperti Javascript dan CSS).
3. Program
Program berbeda dengan script karena memerlukan kompilasi sebelum
dijalankan pada server. Proses kompilasi ini diperlukan supaya program bisa
berjalan lebih cepat. Program juga memiliki fungsionalitas yang lebih luas dari
script karena mereka bisa menyediakan fungsionalitas yang terdapat pada server
dimana program tersebut berjalan. Kesalahan dan kecerobohan dalam
menjalankan program ini bisa mempengaruhi kecepatan dan performa dari server.
2.1.2.3 Content Delivery Application (CDA)
Tugas dari Content Delivery Application adalah mengambil komponen-
komponen content dari repository (tempat penyimpan) kemudian
menampilkannya, dengan menggunakan metacontent, kepada pengguna website.
Pengelola CMS biasanya hanya perlu meng-install dan mengonfigurasi CDA.
18
CDA yang baik biasanya diatur secara penuh oleh metacontent. Hal ini
berarti metacontent menentukan apa yang akan ditampilkan dan bagaimana hal
tersebut ditampilkan. Ada banyak cara yang bisa dilakukan oleh metacontent
untuk menampilkan komponen-komponen content, tergantung dari kreativitas
para developer.
Dengan demikian, secara penuh, CMS bisa didefinisikan sebagai sebuah
sistem yang terdiri dari minimal tiga aplikasi, yakni Content Management
Application (CMA), Metacontent Management Application (MMA) dan Content
Delivery Application (CDA). Bagan alir (flowchart) simpel dari CMS bisa dilihat
pada Gambar 2.3.
Gambar 2.3 Bagan alir CMS (Fraser, 2002)
CMA mengatur semua aspek yang terkait dengan content, sedangkan
MMA mengatur semua aspek yang berhubungan dengan metacontent. CDA men-
generate halaman web dengan cara melakukan ekstraksi komponen-komponen
content dan metacontent dari repository (dalam hal ini server tempat file-file
tersebut disimpan).
19
2.1.3 CMS untuk Laboratorium
Di internet tersedia puluhan, bahkan ratusan CMS dengan berbagai jenis
dan fungsionalitas khusus. Sebagian besar dari mereka adalah project open source
sekaligus free software. Dari berbagai jenis CMS tersebut, ada CMS yang
diimplementasikan untuk laboratorium, dikenal dengan LIMS 2 (Laboratory
Information Management System).
LIMS menurut Crandall dan Auping (1987, h. 2) bisa diartikan sebagai
sebuah kombinasi antara perangkat lunak dan perangkat keras komputer yang
digunakan di laboratorium untuk manajemen sampel, pengguna laboratorium
(praktikan dan laboran), instrumen, standar, dan fungsi laboratorium lainnya
dengan menggunakan database, report generator, dan kapabilitas jaringan
komputer. LIM dan LIS (Laboratory Information System) memiliki tugas yang
hampir serupa. Perbedaan utama antara LIMS dan LIS adalah, LIMS ditujukan
untuk penelitian lingkungan dan analisis komersial, seperti farmasi, engineering
purpose, dan petrokimia, sedangkan LIS ditujukan untuk penelitian klinis (seperti
rumah sakit dan laboratorium klinis lainnya).
Gibbon (1996, p.1-5) menjelaskan, LIMS komersial saat ini menawarkan
fleksibilitas dan fungsionalitas yang cukup baik. Beberapa LIMS komersial
memanfaatkan kelebihan arsitektur dan platform dari sistem open source yang
menyediakan kapabilitas client/server dan akses yang luas pada seluruh informasi
laboratorium. Produl LIMS berbasis web juga banyak ditawarkan oleh berbagai
2 Untuk selanjutnya akan disebut LIMS saja.
20
perusahaan. XML (eXtensible Markup Language) digunakan dalam LIMS karena
XML mampu mengefektifkan informasi yang dikirimkan, meringkas proses
otomatisasi berbasis web, dan mengintegrasikan aplikasi ini pada sebuah lingkup
organisasi atau institusi. XML tidak hanya menawarkan kemudahan transfer
informasi, tapi juga validasi informasi yang dikirimkan. Pada generasi LIMS
sebelumnya, proses ini dilakukan oleh teknologi dari prosesor dan sistem operasi
yang digunakan. Tapi tanpa teknologi prosesor terbaru dari komputer saat ini,
perkembangan LIMS akan terhenti begitu saja. Oleh karena itu, XML bisa disebut
sebagai sebuah teknologi pembaharu yang mendobrak kebuntuan pengembangan
LIMS, terlepas dari teknologi sistem operasi dan perangkat keras komputer yang
digunakan.
Gillespie (1994, p.1) menambahkan, LIMS modern juga memanfaatkan
database relasional. Teknologi ini memungkinkan LIMS dikembangkan menjadi
sebuah aplikasi level enterprise yang mudah disesuaikan dengan strategi
korporasi. Teknologi ini juga memudahkan akses data, pencarian data, dan
penggunaan query sesuai dengan standard SQL. Sebagian besar LIMS saat ini
terdiri dari beberapa layer dan modul yang terintegrasi dengan fungsi-fungsi yang
spesifik pada tiap-tiap modul, seperti fungsi audit, analisis statistik, dan pelaporan
hasil analisis. Teknologi database relasional memungkinkan adanya performa
yang efektif dari kinerja tiap-tiap modul LIMS. Selain itu, penggunaan database
relasional memudahkan proses maintenance data dan informasi laboratorium yang
dikelola oleh LIMS.
21
2.2 Framework CakePHP
2.2.1 Aplikasi Berbasis Framework
PHP adalah sebuah bahasa pemrograman yang memungkinkan seorang
developer (programmer atau system analist) membuat sebuah aplikasi berbasis
web yang powerful sekaligus mampu mengampu database dengan skala besar.
Dalam perkembangannya, seorang programmer PHP seringkali dituntut untuk
menyelesaikan berbagai macam aplikasi dengan tingkat kerumitan yang cukup
tinggi dalam waktu singkat. Di sisi lain, programmer juga dituntut untuk
menciptakan sebuah dasar aplikasi yang bisa dikembangkan menjadi aplikasi lain
dengan skala yang lebih besar dengan melibatkan banyak anggota tim. Menurut
Siswoutomo (2005 a, h. 2-3), aplikasi web berskala besar seringkali diasosiasikan
dengan indikasi-indikasi sebagai berikut :
• Diakses oleh banyak orang (public access)
• Melibatkan database dengan skala record diatas 1000
• Mempunyai banyak modul, seperti modul berita, modul administrasi,
modul keuangan, modul pencarian tingkat lanjut, modul polling dan
sebagainya
• Dikerjakan oleh sebuah tim developer dengan spesialisasi tugas
Aplikasi web dengan skala besar tentu tidak bisa dilepaskan dari
pembagian peran anggota tim. Aplikasi web, terutama web berskala besar, tidak
hanya membutuhkan seorang programmer saja, akan tetapi melibatkan pula
seorang web designer, system analist, database maintainer, manajer keuangan,
22
manajer riset dan promosi dan manajer proyek yang akan mengatur jalannya
pembuatan, pengembangan dan pemeliharaan aplikasi tersebut. Tingkat kerumitan
dan kesamaan cara pandang inilah yang melahirkan konsep kerangka kerja
(framework) dalam pengembangan aplikasi berbasis web.
Shan dan Hua (2006, h. 1) menjelaskan definisi web application
framework sebagai berikut, “A framework is a defined support structure in which
other software applications can be organized and developed. A framework may
include support programs, code libraries, a scripting language, common services,
interfaces, or other software packages/utilities to help develop and glue together
the different components of a software application. A software framework is a
reusable design and building blocks for a software system and / or subsystem.”
Framework bertujuan untuk mengurangi overhead (beban) dari aktivitas-
aktivitas yang sering dilakukan pada saat pelaksanaan proses pengembangan web.
Sebagai contoh, beberapa framework menyediakan pustaka untuk akses database,
templating framework, dan session management serta menawarkan kode-kode
program yang dapat digunakan kembali (reusable).
2.2.2 Sekilas Framework CakePHP
CakePHP adalah sebuah framework open source yang digunakan untuk
mengembangkan aplikasi web dengan dasar kerja CRUD (Create, Read, Update,
Delete). CakePHP juga menjadi salah satu framework pilihan yang
memungkinkan developer membuat sebuah aplikasi web dengan pola
pengembangan RAD (Rapid Application Developments) (Cevasco, 2006).
23
Sunarfrihantono (2006, h.9) menjelaskan, Rapid Application Development
adalah pola pengembangan aplikasi web yang menekankan keterlibatan user
secara luas dalam konstruksi kerja prototype dari suatu sistem yang berkembang
secara cepat, untuk mempercepat pengembangan sistem.
Pada tahun 2005, Michal Tatarynowicz mulai menulis beberapa class
untuk sebuah dasar aplikasi RAD dengan menggunakan bahasa pemrograman
PHP. Ia menyadari bahwa beberapa class yang ia ciptakan sangat memungkinkan
untuk dikembangkan menjadi sebuah framework yang lebih lengkap dan praktis.
Akhirnya, Michal mempublikasikan hasil kerjanya di bawah lisensi MIT Amerika
Serikat, menamainya dengan Cake dan menawarkan pengembangannya pada
komunitas developer PHP dan saat ini proyek tersebut dikenal dengan nama
CakePHP (Anderson & Masters, 2006a).
Gambar 2.4 Logo resmi framework CakePHP
(Anderson & Masters, 2007)
2.2.3 Konsep Object Oriented Programming (OOP)
Menurut Wagito (2003, h. 1), Object Oriented Programming (OOP) 3 atau
Pemrograman Berorientasi Objek adalah pemrograman yang memiliki orientasi
kebendaan. Jika dibuat program tentang hewan, programmer harus berpikir apa
3 Untuk selanjutnya akan disebut OOP saja
24
nama hewan, apa warna hewan, bagaimana hewan berkembang, bagaimana hewan
bergerak dan seterusnya. Jika dibuat program tentang sebuah benda, maka
programmer harus berpikir tentang data yang berhubungan dengan benda tersebut
dan apa yang dapat dikerjakan oleh maupun terhadap benda tersebut. OOP
mempunyai tiga pilar pendukung, yakni :
• Encapsulation (enkapsulasi)
• Inheritance (pewarisan)
• Polimorphism (polimorfisme)
Prinsip enkapsulasi merupakan dasar pertama bagi OOP. Menurut
Siswoutomo (2005b, h. 6-8), enkapsulasi berarti menyembunyikan (membungkus)
detail class dari object yang mengirimkan pesan kepadanya. Class adalah sebuah
tipe data yang user-defined, berisi karakteristik abstrak dari sebuah object (benda),
seperti atribut, properti, serta aksi yang bisa dilakukan oleh benda tersebut, atau
sering dikenal dengan istilah method. Object adalah instance dari class, atau
dengan kata lain object adalah implementasi dari class dengan data atau parameter
yang lebih konkrit.
Inheritance atau pewarisan adalah sebuah usaha untuk menurunkan class
turunan (sub class) dari class induk yang memiliki sifat-sifat khusus, namun
memiliki pula sifat-sifat yang dimiliki oleh class induk. Sub class ini biasanya
memiliki karakter yang lebih khusus bila dibandingkan dengan class induk. Selain
single inheritance, dikenal pula multiple inheritance. Multiple inheritance adalah
sebuah usaha inheritance dengan class induk lebih dari satu, antara class induk
yang satu dengan yang lain tidak terdapat hubungan inheritance.
25
Polimorfisme memungkinkan object memiliki karakter yang berbeda-beda
saat program dijalankan, tergantung dari class induk yang dirujuk oleh object.
Dengan polimorfisme ini, object mampu mengeksekusi method yang berbeda-
beda dan menghasilkan keluaran yang berbeda-beda pula, meskipun
menggunakan nama object yang sama.
2.2.4 Konsep Model-View-Controller (MVC)
Krasner dan Pope (1988, h.2) mendefinisikan konsep arsitektur Model-
View-Controller (MVC) sebagai berikut, “Model-View-Controller (MVC)
programming is the application of this three-way factoring, whereby objects of
different classes take over the operations related to the application domain (the
model), the display of the application's state (the view), and the user interaction
with the model and the view (the controller).“
Pada aplikasi komputer dengan skala besar yang melibatkan banyak user,
developer biasanya memisahkan penanganan data (Model) dan antarmuka (View),
sehingga perubahan antarmuka tidak akan mempengaruhi penanganan data atau
sebaliknya, pengorganisasian data dapat dilakukan dengan leluasa tanpa
mengubah antarmuka. MVC menyediakan solusi pemisahan data dan antarmuka
ini dengan memperkenalkan elemen baru yang dikenal dengan Controller, yang
bertugas menghubungkan business logic (berupa akses ke database) dan
presentation logic (antarmuka aplikasi). Diagram MVC sederhana bisa dilihat
pada Gambar 2.5.
26
Keterangan :
- - - - = hubungan tidak langsung
____ = hubungan langsung
Gambar 2.5 Diagram Model-View-Controller (Krasner & Pope, 1988)
Penjelasan lebih lanjut mengenai pembagian arsitektur perangkat lunak
menjadi Model, View dan Controller sebagai berikut :
1. Model
Model adalah representasi spesifik dari informasi yang diolah oleh sebuah
aplikasi atau sering dikenal dengan domain logic. Model berperan dalam
memberikan data mentah yang terdapat pada database untuk diolah pada
Controller, kemudian ditampilkan dengan menggunakan View.
2. View
View bertugas menampilkan Model pada format yang dibutuhkan oleh
pengguna aplikasi, biasanya dalam bentuk elemen-elemen antarmuka.
27
3. Controller
Controller bertugas memproses dan merespon event, biasanya saat user
melakukan aksi dan melakukan request ke aplikasi.
Secara garis besar, proses request dan respond antara user dan aplikasi
dengan arsitektur MVC adalah sebagai berikut :
1. User berinteraksi dengan suatu antarmuka. Sebagai contoh, user
menekan sebuah tombol.
2. Controller menangani masukan yang diberikan user melalui
antarmuka.
3. Contoller melakukan akses ke Model dan meminta data sesuai
dengan apa yang diminta oleh user.
4. View menggunakan data keluaran hasil olahan Contoller untuk
ditampilkan pada antarmuka, sebagai bentuk respon aplikasi
terhadap request dari user.
Pada terminologi CakePHP, Model merepresentasikan sebuah tabel yang
terdapat pada sebuah database, serta relasi antara tabel tersebut dengan tabel yang
lain. Model juga berisi aturan-aturan validasi data, yang digunakan saat data
ditambahkan ke dalam database. View merepresentasikan file-file HTML yang
diselingi dengan script PHP. Contoller CakePHP menangani request yang berasal
dari server, dalam hal ini request dari user melalui antamuka. Contoller
mengambil masukan dari user (yang biasanya berupa URL dan POST data),
mengeksekusi business logic, menggunakan Model untuk membaca dan menulis
data ke dan dari database serta sumber yang lain, dan terakhir, mengirimkan
28
keluaran ke file View yang sesuai. Untuk memudahkan programmer, CakePHP
menggunakan konsep MVC tidak hanya dalam hal metode interaksi obyek dengan
aplikasi, tapi juga sistem penataan file-file aplikasi tersebut. Bird
(www.grahambird.co.uk, 16 Agustus 2007) menggambarkan alur kerja CakePHP
pada Gambar 2.6.
Gambar 2.6 Alur kerja dan konsep MVC pada CakePHP (Bird, 2006)
29
2.2.5 Arsitektur CakePHP
Sebagaimana dijelaskan pada subbab 2.1.4, CakePHP dengan arsitektur
MVC memiliki alur kerja yang spesifik. Gambar 2.8 memberikan penjelasan lebih
lengkap mengenai arsitektur CakePHP. Pada framework CakePHP, Dispatcher
memegang peranan yang cukup penting karena Dispatcher adalah komponen
pertama yang menerima request sebelum diteruskan kepada Controller. Apabila
Dispatcher tidak berfungsi, browser tidak akan menampilkan hasil dari request
user.
Database
UserApache / IIS
Dispatcher
View Controller
requestAction()
Redirect
Model
1
2
3
4
5
4
6
7
8
Gambar 2.7 Arsitektur framework CakePHP (Bird, 2006)
CakePHP memiliki tiga buah folder utama, yakni folder /app, folder /cake
dan folder /vendors. Struktur penyimpan file dan folder pada framework CakePHP
dijelaskan pada tabel 2.1.
30
Tabel 2.1 Struktur file dan folder framework CakePHP Folder Utama Sub Foler
Kedua Sub Foler
Ketiga Keterangan
/app - /app adalah folder tempat penyimpanan aplikasi utama yang dibuat. Folder ini merupakan folder yang berisi seluruh file, image, konfigurasi dari aplikasi web
/config - berisi file-file konfigurasi untuk database, routing aplikasi, setting framework, ACL (Access Control List), dan sebagainya
/controllers - folder penyimpanan Controller utama /components - folder penyimpanan Component, sebagai
pendukung Controller utama /index.php - memungkinkan developer untuk
mengembangkan aplikasi web dengan folder /app sebagai Document Root
/models - folder tempat penyimpanan file-file Model /plugins - folder tempat penyimpanan plugins. Plugins
adalah aplikasi kecil yang dibuat dari CakePHP sebagai dukungan terhadap aplikasi utama
/tmp - digunakan untuk penyimpanan file-file cache dan log dari aplikasi
/vendors - digunakan sebagai tempat penyimpanan file-file pustaka PHP lainnya
/views - folder tempat penyimpanan file-file View dengan ekstensi *.thtml (untuk CakePHP versi 1.1.x.xxxx) dan *.tpl (untuk CakePHP versi 1.2.x.xxxx).
/elements - folder tempat penyimpanan element, yang mendukung View utama.
/errors - folder tempat penyimpanan file-file penanganan error.
/helpers - folder tempat penyimpanan file-file helper /layout - folder tempat penyimpanan file-file layout
antarmuka /pages - folder tempat penyimpanan halaman statis /webroot - webroot adalah Document Root dari aplikasi
web /css - folder tempat penyimpanan file-file CSS /files - folder tempat penyimpanan file-file lain yang
mendukung aplikasi /img - folder tempat penyimpanan file-file gambar /js - folder tempat penyimpanan file-file Javascript /cake - folder utama tempat file-file pustaka
framework CakePHP diletakkan /vendors - digunakan sebagai tempat penyimpanan
aplikasi web third party untuk seluruh aplikasi yang di-hosting di server tersebut.
31
2.2.6 Kelebihan dan Kekurangan
Framework CakePHP menjadi pilihan untuk pengembangan CMS “iLab”
ini karena beberapa kelebihan yang dimiliki (Anderson & Masters, 2006a) , antara
lain :
1. Open Source
CakePHP bebas didapatkan dan dikembangkan. CakePHP mempunyai
lisensi GPL (General Pubic License). Ini adalah salah satu syarat yang baik untuk
berkembangnya sebuah framework.
2. Riset yang terorganisasi dengan baik
CakePHP dikembangkan dalam riset yang terorganisasi dan
berkesinambungan di bawah Cake Software Foundation.
3. Dokumentasi yang lengkap
CakePHP memiliki dokumentasi dan manual yang memadai dan
mendukung pemakaiannya sebagai kerangka kerja inti yang siap dikembangkan
menjadi aplikasi berbasis web yang lebih kompleks.
4. Kompatibel dengan PHP 4 dan PHP 5
CakePHP berjalan dengan baik pada server Apache yang menggunakan
PHP 4 maupun PHP 5. Fleksibilitas dan kompatibilitas inilah yang banyak
menarik minat para programmer untuk menggunakan framework CakePHP
sebagai dasar untuk pengembangan aplikasi mereka.
32
5. Konsep CRUD terintegrasi
CakePHP menerapkan konsep CRUD (Create, Read, Update, Delete)
terintegrasi yang membantu interaksinya dengan database dan menyederhanakan
query.
6. Arsitektur OOP dan MVC
Class-class yang menjadi dasar dari CakePHP ditulis dengan konsep OOP
yang memudahkan programmer untuk melakukan penambahan, pengurangan dan
modifikasi class dan method yang digunakan. CakePHP menggunakan arsitektur
MVC yang memisahkan business logic dan presentation logic .
7. Fitur Scaffolding
CakePHP mempunyai fitur yang mampu men-generate prototype aplikasi,
sebelum menyusun source code-nya secara lengkap.
8. Manajemen akses bagi user
CakePHP memungkinkan pengaturan user sekaligus hak aksesnya dalam
aplikasi yang dikembangkan, dengan sarana yang lebih mudah dipahami. Fitur ini
dikenal dengan nama Access Control List (ACL).
9. Validasi dan sanitasi data
CakePHP mempunyai class–class dasar yang membantu programmer
untuk melakukan sanitasi dan validasi data pada aplikasinya.
10. Komponen Security, Session, and Request Handling yang terintegrasi
CakePHP menyediakan komponen-komponen untuk menangani masalah
session, keamanan (security) dan request handling yang sudah terintegrasi dalam
class–class dasar CakePHP. Pemrogram cukup meng-include-kan komponen
33
tersebut pada Controller aplikasi dan memasukkan parameter-parameter untuk
mendapatkan hasil yang diinginkan.
11. Metode templating yang sederhana
CakePHP mendukung metode templating yang sangat mudah digunakan
untuk membantu programmer dan disainer web menciptakan tampilan aplikasi
yang indah dan mudah dimodifikasi. CakePHP mempunyai class helper yang
mendukung templating HTML, Ajax, Javascript, dan lain-lain.
12. Cocok untuk segala strukutur direktori
CakePHP mempunyai sistem konfigurasi yang menyediakan berbagai
macam pilihan konfigurasi, sesuai dengan struktur direktori pengembangan
aplikasi berbasis framework CakePHP.
Selain beberapa kemudahan dan keunggulan di atas, CakePHP juga
memiliki kelemahan, antara lain belum adanya dukungan internasionalisasi bahasa.
Sampai saat ini, rilis terbaru dari CakePHP belum memasukkan class yang
mendukung i18n atau internasionalisasi bahasa-bahasa yang ada di dunia.
34
BAB III
ANALISIS DAN PERANCANGAN SISTEM
3.1 Analisis Kebutuhan Sistem
3.1.1 Kebutuhan Umum Laboratorium
CMS yang akan dibuat bertujuan untuk memenuhi kebutuhan laboratorium
secara umum. Pemilihan nama “iLab” disesuaikan dengan fungsionalitas CMS
yang berbasis web (disimbolkan dengan huruf “i” pada kata “iLab”) dan
implementasi CMS yang dikhususkan untuk pengelolaan laboratorium
(disimbolkan dengan frase “Lab” pada kata “iLab).
Penelitian dan pengambilan data dilakukan dengan melakukan pengamatan
di beberapa laboratorium Jurusan Teknik Elektro, Fakultas Teknik Universitas
Gadjah Mada. Selain pengamatan, metode lain yang digunakan adalah wawancara
dengan pengelola laboratorium (dalam hal ini adalah laboran dan asisten) dan
pengambilan contoh berkas data pendaftaran praktikum dari salah satu
laboratorium, yakni Laboratorium Informatika Jurusan Teknik Elektro Fakultas
Teknik Universitas Gadjah Mada. Pemilihan Laboratorium Informatika sebagai
salah satu objek pendukung penelitian karena beberapa alasan berikut ini :
- Laboratorium Informatika adalah laboratorium yang sangat relevan untuk
penerapan otomatisasi manajemen praktikum berbasis web. Selain sarana
dan prasarana yang memungkinkan, yakni dengan adanya server khusus
35
yang digunakan di jaringan lokal laboratorium (server Poseidon, dengan
sistem operasi OpenBSD) dan jaringan lokal (Local Area Network) yang
sudah terinstalasi dengan baik, Laboratorium Informatika juga sering
dijadikan sebagai lokasi utama untuk data entry pada saat pengisian KRS
(Kartu Rencana Studi) semester baru.
- Hampir seluruh laboratorium di Jurusan Teknik Elektro menggunakan cara
manual untuk pendaftaran praktikum, kecuali Laboratorium Sistem Digital.
Laboratorium Sistem Digital sudah menerapkan sistem pendaftaran
praktikum secara online, namun demikian hanya diperuntukkan untuk
beberapa praktikum tertentu. Selain itu, sistem informasi ini tidak
menyediakan modul yang mendukung penyajian informasi kegiatan
laboratorium dan repository kebutuhan pendukung praktikum (seperti
panduan praktikum, tata cara praktikum, prosedur penggunaan alat, karya
tulis dan hasil penelitian, dan sebagainya). Pembuatan CMS berbasis web
yang mengakomodasi kebutuhan umum laboratorium dan implementasi
awal pada salah satu laboratorium, yakni Laboratorium Informatika,
diharapkan dapat mendorong laboratorium lainnya untuk menggunakan
CMS yang serupa, sehingga akan tercipta sebuah prosedur pendaftaran
praktikum yang simpel, seragam, efektif dan cepat di seluruh laboratorium
Jurusan Teknik Elektro.
Secara umum, permasalahan-permasalahan yang dijumpai hampir di
seluruh laboratorium Jurusan Teknik Elektro adalah sebagai berikut :
36
- Sistem pendaftaran manual yang mudah sekaligus rawan disalahgunakan.
Sistem pendaftaran praktikum yang selama ini digunakan oleh sebagian
besar laboratorium adalah pendaftaran dengan menuliskan nama dan NIM
(nomer induk mahasiswa) pada kertas pendaftaran yang disediakan oleh
laboran (pengelola laboratorium). Pendaftaran ini, selain mudah dan
simpel, juga mengandung kelemahan. Kelemahan tersebut adalah
kemungkinan dihapusnya nama praktikan (peserta praktikum) yang telah
terdaftar lebih dahulu oleh praktikan lain yang terdaftar setelahnya.
- Pengolahan data hasil pendaftaran praktikum juga dilakukan secara
manual. Laboran harus menuliskan ulang data calon peserta praktikum
dari berkas-berkas pendaftaran ke dalam komputer. Selain melelahkan,
pemindahan data secara manual ini juga memiliki kelemahan, yakni
kemungkinan adanya data yang keliru saat dilakukan entry data. Beberapa
laboran mengungkapkan bahwa data praktikum ini nantinya akan diolah
dalam bentuk spreadsheet menggunakan aplikasi Microsoft Excel atau
aplikasi open source lainnya yang sejenis.
- Kebutuhan pendukung praktikum, seperti panduan atau modul praktikum,
selama ini diberikan dalam bentuk hard copy. Untuk mendapatkannya,
praktikan terkadang harus membayar agak mahal dan tidak jarang
beberapa praktikan memilih untuk meminjam modul dari kakak angkatan
atau teman satu angkatannya daripada membeli modul sendiri. Kenyataan
ini bisa diminimalisasi dengan memberikan modul praktikum dalam
bentuk soft copy (misalnya berbentuk file PDF). Selain penghematan biaya,
37
dengan disajikannya kebutuhan praktikum dalam bentuk soft copy, tidak
ada lagi alasan bagi praktikan untuk tidak menjalankan praktikum sesuai
dengan peraturan.
- Tidak adanya media yang mudah diakses (online) dan informatif, yang
memberikan informasi akurat tentang jadwal pemakaian laboratorium,
jadwal dosen saat berada di laboratorium, informasi seputar praktikum
atau kegiatan yang sedang berjalan di laboratorium saat ini. Kurangnya
media informasi ini sedikit banyak berpengaruh saat ada dua buah institusi
yang ingin menggunakan laboratorium pada saat bersamaan dan pengelola
laboratorium harus memberikan kesempatan kepada salah satu institusi
dengan mengorbankan institusi lainnya. Peristiwa ini pernah beberapa kali
dialami oleh Laboratorium Informatika yang sampai dengan saat ini
digunakan untuk pelaksanaan praktikum mahasiswa S1, pelaksanaan
sebagian praktikum mahasiswa S2 reguler, pelaksanaan kegiatan belajar
mengajar mahasiswa Magister Teknik Informatika (MTI) dan pelaksanaan
kegiatan workshop Keluarga Mahasiswa Teknik Elektro (KMTE).
- Kurangnya media dokumentasi hasil penelitian, karya tulis dan karya
ilmiah yang dilakukan oleh mahasiswa dan dosen laboratorium yang
bersangkutan. Sebagai contoh, Laboratorium Sistem Digital adalah
laboratorium produktif yang senantiasa memberikan kontribusi berharga
untuk Jurusan Teknik Elektro dengan berbagai inovasi di bidang
microController dan robotika. Kontribusi ini dipersembahkan dengan
keikutsertaan mahasiswa Teknik Elektro pada KRI (Kontes Robot
38
Indonesia) yang diselenggarakan setiap tahun. Namun demikian,
dokumentasi dan publikasi hasil penelitian ini dirasa masih sangat kurang,
sehingga kegiatan penelitian di bidang robotika ini tidak menyentuh minat
mahasiswa baru Teknik Elektro. Hal ini dibuktikan dengan sedikitnya
jumlah peserta penelitian robotika di Jurusan Teknik Elektro yang berasal
dari mahasiswa baru.
- Kurangnya keterlibatan dosen dalam pelaksanaan praktikum. Kenyataan
ini banyak dijumpai di seluruh laboratorium Jurusan Teknik Elektro.
Keterlibatan dosen seringkali berakhir pada pembuatan modul praktikum
dan pengambilan nilai hasil praktikum saja. Keterlibatan lain yang
berhubungan dengan pengembangan fungsi laboratorium sebagai sarana
utama penelitian dirasa belum optimal.
Beberapa permasalahan di atas memberikan sebuah gambaran awal untuk
perancangan sebuah CMS dengan beberapa ketentuan sebagai berikut :
1. CMS memiliki sebuah modul instalasi sehingga bisa diimplementasikan
dengan mudah di seluruh laboratorium yang menggunakannya.
2. Sistem pendaftaran praktikan dan asisten dilakukan secara otomatis
dengan beberapa pertimbangan khusus, antara lain :
- pembatasan jumlah praktikan dan asisten secara otomatis;
- penggunaan antarmuka yang sederhana;
- penyajian informasi yang mudah dipahami;
- metode filtering praktikan dan asisten untuk mencegah terjadinya
kerancuan record database.
39
3. Otomatisasi pengolahan data pendaftaran praktikum dengan cara
pengubahan data praktikum dari format MySQL ke format spreadsheet .
4. CMS memiliki modul untuk manajemen kebutuhan pendukung praktikum.
Manajemen ini berbentuk fungsi penyimpanan file (upload file), fungsi
pengunduhan file (download file) dan penyajian informasi yang terkait
dengan kebutuhan pendukung praktikum yang dimaksud.
5. CMS memiliki modul untuk penyajian informasi kegiatan dan project
yang sedang dilaksanakan di laboratorium. Modul ini nantinya akan sangat
bermanfaat untuk memberikan informasi yang terkait dengan laboratorium,
seperti pengumuman pendaftaran dan batas akhir praktikum, format
laporan praktikum, jadwal kegiatan laboratorium, jadwal konsultasi
dengan dosen pengampu praktikum, penelitian dan riset yang dilakukan
oleh mahasiswa, dan masih banyak lagi.
Apabila disajikan dalam bentuk gambar, analisis permasalahan dan pemecahan
masalah bisa dilihat pada Gambar 3.1 di bawah ini.
PERMASALAHAN- pendaftaran manual - pengolahan data manual- tidak ada repository resource praktikum- belum ada media informasi online
SOLUSI- otomatisasi pendaftaran- otomatisasi pengolahan data- pembuatan repository resource praktikum- media informasi online laboratorium- pembatasan hak akses pengguna- otomatisasi instalasi sistem- mudah digunakan (user friendly)
CMS iLab
Gambar 3.1 Permasalahan di laboratorium dan pemecahannya
40
Sistem informasi berupa CMS laboratorium ini juga mensyaratkan
beberapa kebutuhan dasar, supaya bisa diimplementasikan dengan baik, yakni :
1. Komputer server sebagai server iLab. CMS iLab akan di-install pada
server ini. CMS iLab dibangun dengan bahasa pemrograman PHP dan
memanfaatkan database MySQL. Selain sistem operasi, server juga harus
dilengkapi dengan web server, dalam hal ini disarankan menggunakan
Apache Web Server karena kemudahannya, instalasi PHP versi 4.3 ke atas,
dan instalasi MySQL server.
2. Komputer client, sebagai client iLab. Praktikan, laboran, atau dosen akan
menggunakan komputer client untuk memasukkan data ke dalam database.
3. Jaringan komputer yang menghubungkan server dengan client.
Apabila iLab ingin digunakan secara lokal di internal Jurusan Teknik
Elektro, iLab bisa dipasang pada server lokal Jurusan Teknik Elektro dan masing-
masing laboratorium diberikan account yang berbeda. Akses ke CMS iLab bisa
dilakukan dengan komputer PC biasa yang terhubung ke jaringan lokal Teknik
Elektro melalui kabel UTP atau dengan menggunakan komputer portabel (laptop)
melalui akses nirkabel (wi-fi).
Apabila iLab ingin digunakan secara lokal di laboratorium yang
bersangkutan, komputer server yang digunakan bisa juga bertindak sebagai
komputer client, dengan catatan akses ke web server dilakukan dengan mengakses
localhost atau IP Address 127.0.01 . Skema implementasi iLab pada sebuah
jaringan lokal (LAN) bisa dilihat pada Gambar 3.2.
41
Komputer Server
- Sistem Operasi - Apache Web Server - PHP 4.3. ke atas - MySQL server
Local Area Network
Komputer Laptop
Komputer PC
Workstation
Palm Computer
Gambar 3.2 Implementasi CMS iLab di jaringan lokal
3.1.2 Prosedur Manajemen Praktikum
Sebuah laboratorium seringkali menyelenggarakan mata praktikum lebih
dari satu dengan jadwal yang berbeda untuk masing-masing mata praktikum. Oleh
karena itu, perlu adanya sebuah aturan main yang jelas untuk mekanisme
pendaftaran praktikan. Pada perancangan CMS iLab ini, diasumsikan sebuah
laboratorium membuka secara bersamaan pendaftaran praktikum-praktikum yang
akan diselenggarakan di laboratorium tersebut. Dengan dibukanya pendaftaran
untuk seluruh praktikum secara bersamaan, praktikan bisa memasukkan data diri
satu kali untuk beberapa praktikum yang ia ambil dalam satu semester.
42
Keuntungan lainnya adalah, praktikan akan lebih mudah menyesuaikan diri
dengan jadwal kuliah dan praktikum di laboratorium lain apabila masing-masing
laboratorium memiliki kejelasan jadwal. Namun demikian, CMS juga
menyediakan sebuah mekanisme update data apabila praktikan ingin mengganti
jadwal, baik melalui laboran maupun secara manual dilakukan oleh praktikan
sendiri. Untuk lebih jelasnya, aturan pendaftaran praktikan yang akan diterapkan
pada CMS iLab digambarkan pada diagram alir Gambar 3.3 .
Pada bagian awal diagram alir pendaftaran praktikum, praktikan melihat
profil atau nama-nama praktikum yang tersedia, kemudian melihat jadwal-jadwal
praktikum dari praktikum yang bersangkutan. Setelah praktikan memperoleh
informasi terkait dengan praktikum yang akan ia ambil, praktikan mendaftarkan
diri sesuai dengan jadwal yang bersesuaian. Halaman pendaftaran berisi data diri
praktikan dan pilihan-pilihan jadwal yang akan ia ambil. Pendaftaran ini
memungkinkan adanya mekanisme validasi data praktikan, sehingga praktikan
tidak akan mendaftarkan diri pada jadwal yang sama apabila ia sudah pernah
memasukkan data sebelumnya. Hal ini sangat mungkin terjadi pada saat
melakukan update atau penggantian jadwal praktikum. Selain mekanisme tersebut,
CMS juga akan dilengkapi sebuah mekanisme yang akan menghilangkan pilihan
jadwal praktikum yang sudah memenuhi quota pada halaman pendaftaran
praktikan.
43
MULAI
Melihat profil praktikum
Melihat jadwal
praktikum
KOSONG ?
Ya
Tidak
Daftar sebagai praktikan
Simpandata
praktikan
Tampilkandata
praktikan
BENAR ?
Ya
Tidak
Update datapraktikan
SELESAI
Cek apakahpernah mendaftar
sebelumnya
Tampilkan pesan error
Ya
Tidak
Gambar 3.3 Diagram alir mekanisme pendaftaran praktikan
Selain fitur pendaftaran praktikan, CMS iLab juga dilengkapi dengan
mekanisme pendaftaran asisten. Pada CMS iLab, seorang asisten hanya
diperbolehkan mengampu satu buah praktikum di sebuah laboratorium. Selain
44
aspek pemerataan lowongan asisten kepada seluruh mahasiswa, asisten
diharapkan lebih berdedikasi terhadap tugasnya apabila ia tidak mengampu lebih
dari satu praktikum di laboratorium yang sama. Pembatasan ini juga didasarkan
pada pengamatan, dimana asisten-asisten praktikum yang ada selama ini hanya
didominasi oleh beberapa orang saja untuk tiap-tiap angkatan mahasiswa.
Mekanisme pendaftaran asisten tidak jauh berbeda dengan mekanisme
pendaftaran praktikan. Sebelum melakukan pendaftaran, asisten diharapkan
melihat terlebih dahulu halaman khusus informasi untuk asisten yang
menampilkan mata praktikum yang ada dan jadwal praktikum yang terkait.
Setelah itu, asisten dipersilahkan untuk mendaftarkan diri sesuai dengan jadwal
yang masih tersedia. Fasilitas pendaftaran asisten ini tidak dilengkapi dengan
fasilitas update data secara manual. Apabila nantinya ditemukan kesalahan pada
data yang dimasukkan atau asisten membatalkan kesediaannya sebagai asisten
praktikum, asisten harus menghubungi laboran untuk mengganti data yang sudah
dimasukkan ke dalam database. Hal ini diperlukan supaya asisten praktikum
benar-benar diampu oleh mahasiswa yang memiliki kesungguhan dan kompetensi
sesuai dengan kemampuannya. Diagram alir pendaftaran asisten pada CMS iLab
ditunjukkan pada Gambar 3.4.
45
MULAI
Melihat informasi asisten
Melihat jadwal
praktikum
KOSONG ?
Ya
Tidak
Daftar sebagai asisten
Simpandata
asisten
Tampilkandata
asisten
BENAR ?
Ya
Tidak
Update dataasisten
SELESAI
Cek apakahpernah mendaftar
sebelumnya
Tampilkan pesan error
Ya
Tidak
Hubungi laboran
Gambar 3.4 Diagram alir mekanisme pendaftaran asisten
46
3.1.3 Pengolahan Data Pendaftaran Praktikum
Setelah masa pendaftaran praktikum usai, laboran akan mengolah data
pendaftaran praktikan dan asisten yang sudah masuk dalam database. Pada
mekanisme pendaftaran manual, laboran harus memasukkan kembali satu per satu
data mahasiswa ke dalam komputer. Proses ini tentu membutuhkan waktu yang
tidak sedikit. CMS iLab mempersingkat hal ini dengan memberikan fitur konversi
data MySQL ke dalam bentuk spreadsheet (MySQL to XLS Converter). Dengan
fitur ini, laboran hanya perlu menekan tombol Export Data untuk mengekspor
daftar praktikan dan asisten sesuai dengan jadwal yang praktikum yang diinginkan.
Setelah dilakukan konversi, secara otomatis data praktikan dan asisten akan
diisikan pada tabel pendaftaran praktikum sesuai dengan jadwal praktikum. Proses
konversi ini biasanya memakan waktu kurang dari 10 detik. Adapun contoh
format tabel pendaftaran praktikum digambarkan pada Tabel 3.1 di bawah ini.
Tabel 3.1 Contoh tabel pendaftaran praktikum
Nama Praktikum
SENIN (13.00-15.00) No. Nama Lengkap NIM Angkatan
Asisten Praktikum No. Nama Lengkap NIM Angkatan
Selain fitur tersebut, CMS iLab juga dilengkapi dengan fitur Hapus Massal
yang memungkinkan laboran menghapus seluruh data praktikan dan asisten
47
apabila diperlukan. Penghapusan massal ini diperlukan saat pergantian semester
atau tahun ajaran. Namun demikian, diharapkan laboran melakukan back up data
terlebih dahulu sebelum dilakukan penghapusan massal. Back up data bisa
dilakukan dengan mengekspor data ke bentuk spreadsheet untuk disimpan di
komputer.
3.1.4 Fitur Tambahan
CMS iLab juga dilengkapi beberapa fitur tambahan, antara lain :
1. Fitur halaman depan dan informasi profil laboratorium.
2. Fitur informasi berita aktual laboratorium, dilengkapi dengan fitur
pencarian berita secara live dengan teknologi AJAX (Asynchronous
Javascript and XML) untuk mempersingkat dan mempermudah
mekanisme pencarian berita.
3. Fitur repository resource pendukung praktikum, seperti modul praktikum,
tata cara penggunaan laboratorium, tata cara peminjaman alat, dan
sebagainya.
4. Fitur informasi aktual tentang penelitian dan riset yang sedang
berlangsung di laboratorium.
5. Fitur informasi referensi online yang dapat dimanfaatkan oleh peserta
praktikum untuk memperkaya pengetahuan yang berhubungan dengan
praktikum yang sedang diselenggarakan oleh laboratorium.
6. Fitur buku tamu sebagai wahana interaktif dan diskusi pengelola
laboratorium dan pengguna laboratorium lainnya.
48
7. Fitur halaman administrasi (modul administrasi) yang memudahkan
laboran, dosen, member (anggota), dan administrator untuk mengelola
content CMS.
8. Fitur CAPTCHA (Complete Automatic Turing Test To Tell Computer and
Human Apart) untuk mencegah adanya automatic spamming pada buku
tamu dan serangan brute force pada halaman login.
Sebagian dari fitur-fitur tersebut diwujudkan dalam bentuk modul, sebagaimana
modul utama CMS iLab, yakni modul manajemen pendaftaran dan pengolahan
data praktikum.
3.2 Perancangan Antarmuka
3.2.1 Halaman Pengunjung
Halaman pengunjung adalah halaman CMS iLab yang diakses oleh asisten,
praktikan atau pengunjung lainnya yang mengakses CMS iLab. Halaman
pengujung didisain sesederhana mungkin untuk memudahkan pengunjung
menggunakan menu dan navigasi yang ada. Rancangan antarmuka halaman
pengunjung ditunjukkan pada Gambar 3.5 di bawah ini.
49
Menu Utama
CopyrightØ 2007 iLab :: Laboratory Management System. All rights reserved.
Logo iLab
Menu Pendukung
Konten utama modul
Gambar 3.5 Rancangan halaman pengunjung
Bagian atas halaman adalah menu utama. Menu utama berisi link-link ke
modul-modul utama CMS iLab. Untuk membedakan modul yang sedang aktif dan
tidak aktif, saat sebuah modul diakses warna latar belakang menu yang terkait
dengan modul tersebut berubah. Logo iLab berupa tulisan “::iLab laboratory
management system” diletakkan di kiri atas. Tepat di bawah logo, diletakkan
menu pendukung yang berisi link-link terkait dengan modul yang sedang aktif.
Bagian tengah adalah konten utama modul yang berisi informasi utama yang
disajikan. Bagian bawah adalah footer berupa copyright dan tahun pembuatan
produk iLab.
50
3.2.2 Halaman Login
Halaman login memiliki antarmuka yang tidak jauh berbeda dengan
halaman pengunjung. Konten utama halaman login berupa form isian username
dan password, serta dilengkapi dengan fitur CAPTCHA yang akan menampilkan
kombinasi huruf dan angka yang berbeda-beda setiap kali halaman browser di-
refresh. Fitur CAPTCHA digunakan di halaman login untuk mencegah serangan
brute force yang mengotomatisasi input data username dan password secara acak
pada halaman login.
Menu Utama
CopyrightØ 2007 iLab :: Laboratory Management System. All rights reserved.
Logo iLab
OK
USERNAME
PASSWORD
Captcha
Gambar 3.6 Rancangan halaman login
51
3.2.3 Halaman Administrasi
Halaman administrasi sedikit berbeda dengan halaman pengunjung. Saat
user berhasil login, halaman pengunjung akan berubah menjadi halaman
administasi. Pada halaman administrasi, menu pendukung modul digeser ke
bawah dan digantikan oleh link logout dan menu administrasi. Menu administrasi
adalah menu khusus administrasi terkait dengan modul yang sedang aktif. Menu
administrasi hanya akan muncul saat user memiliki hak akses ke modul yang
sedang aktif. Di bagian atas konten utama, aplikasi CMS iLab akan memberikan
informasi terkait dengan nama user yang saat itu sedang login disertai dengan link
untuk logout.
Logout
Menu Utama
CopyrightØ 2007 iLab :: Laboratory Management System. All rights reserved.
Logo iLab
Menu Administrasi
Menu Pendukung
Logout
Anda saat ini sedang login sebagai <user>. Klik Logout unt uk keluar dari member Area
Konten utama modul
Gambar 3.7 Rancangan halaman administrasi
52
3.2.4 Halaman Menu Administrasi
Halaman menu administrasi adalah halaman yang pertama kali dijumpai
user pada saat user berhasil login. Halaman ini mirip dengan halaman administrasi,
hanya saja konten utama halaman berisi menu utama administrasi modul-modul
yang ada pada CMS iLab. Untuk memudahkan user, menu utama ini dilengkapi
dengan simbol-simbol khusus yang menggambarkan masing-masing modul.
Logout
Menu Utama
CopyrightØ 2007 iLab :: Laboratory Management System. All rights reserved.
Logo iLab
Logout
Anda saat ini sedang login sebagai <user>. Klik Logout unt uk keluar dari member Area
Administ rasi modul 1
Administ rasi modul 2
Administ rasi modul 3
Administ rasi modul 4
Administrasi modul 5
Administrasi modul 6
Administ rasi modul 7
Administ rasi modul 8
Administrasi modul 9
Administ rasi modul 10
Gambar 3.8 Rancangan halaman menu administrasi
53
3.3 Perancangan Basis Data
3.3.1 Diagram E-R (ERD / Entity Relationship Diagram)
Untuk merancang basis data (database) CMS iLab, langkah pertama
adalah menyusun hubungan antar entitas basis data yang ada. Berdasarkan
kebutuhan sistem, entitas yang ada adalah sebagai berikut :
1. Practicumnames. Entitas ini mewakili nama-nama praktikum yang
diselenggarakan di laboratorium.
2. Practicumschedules. Entitas ini mewakili jadwal penyelenggaraan masing-
masing praktikum.
3. Practicians. Entitas ini mewakili peserta praktikum (praktikan).
4. Assistants. Entitas ini mewakili asisten praktikum.
5. Userstatuses. Entitas ini mewakili tingkat hak akses pengguna CMS.
6. Users. Entitas ini mewakili semua pengguna yang berhak memiliki hak
akses ke halaman administrasi.
7. Projects. Entitas ini mewakili proyek dan riset yang dilakukan di
laboratorium
8. Resources. Entitas ini mewakili semua kebutuhan pendukung praktikum
dan semua resource laboratorium yang tersimpan di repository CMS iLab.
9. Newscategories. Entitas ini mewakili kategori berita.
10. News. Entitas ini mewakili berita dan informasi kegiatan laboratorium.
11. Links. Entitas ini mewakili referensi online yang direkomendasikan
laboratorium.
12. Guestbooks. Entitas ini mewakili buku tamu.
54
13. Homes. Entitas ini mewakili halaman depan CMS iLab.
14. Profiles. Entitas ini mewakili halaman profil laboratorium.
15. Settings. Entitas ini mewakili konfigurasi CMS iLab.
Pada framework CakePHP, terdapat sebuah aturan baku metode penamaan
tabel basis data. Penamaan tabel merupakan bentuk jamak bahasa Inggris dari
entitas, diawali dengan huruf kecil. Sebagai contoh, entitas “buku tamu” nantinya
akan menggunakan nama tabel “guestbooks”. Untuk memudahkan perancangan,
nama entitas dibuat serupa dengan nama tabel. Adapun perancangan diagram E-R
menggunakan diagram E-R versi Chen. Beberapa simbol yang digunakan
dijelaskan pada Tabel 3.2 di bawah ini.
Tabel 3.2 Simbol diagram E-R versi Chen
Simbol Keterangan
Entity name
Persegi panjang, menyatakan himpunan entitas atau entitas.
Relationship
Belah ketupat, menyatakan himpunan relasi atau relasi.
Garis, sebagai penghubung antara himpunan relasi dengan himpunan entitas.
55
Gam
bar
3.9
Dia
gra
m E
-R b
asi
s d
ata
CM
S iL
ab
56
3.3.2 Diagram LRS (Logical Record Structure)
Setelah perancangan diagram E-R selesai, langkah selanjutnya adalah
melakukan transformasi diagram E-R ke diagram LRS (Logical Record Structure).
Transformasi dilakukan untuk mengetahui hubungan kardinalitas antar entitas
dengan lebih jelas. Selain itu, diagram LRS juga berfungsi untuk mengetahui hasil
normalisasi dua buah entitas yang memiliki kardinalitas many to many
(disimbolkan dengan M:N). Pada diagram E-R sebelumnya, entitas
practicumschedules memiliki kardinalitas many to many dengan practicians.
Artinya, antara dua entitas tersebut harus dilakukan normalisasi sehingga tidak
ada kerancuan primary key dalam rancangan tabel basis data. Adapun entitas-
entitas lain yang memiliki hubungan one to many (1:N) tidak memerlukan
normalisasi. Selain itu, ada juga beberapa entitas yang tidak memiliki kardinalitas
dengan entitas lain atau dikenal dengan entitas bebas. Pada diagram LRS, entitas
bebas ini akan digambarkan sebagai sebuah struktur bebas yang berdiri sendiri
(tidak memiliki hubungan dengan struktur lain).
Framework CakePHP memiliki aturan khusus untuk dua buah entitas yang
memiliki kardinalitas many to many (M:N). Kardinalitas ini diistilahkan sebagai
asosiasi has and belongs to many (HABTM). Asosiasi HABTM memerlukan
sebuah tabel normalisasi dari dua tabel yang berasosiasi. Peraturan penamaan
tabel hasil normalisasi HABTM adalah [nama jamak entitas pertama]_[nama
jamak entitas kedua]. Adapun urutan penamaan disesuaikan dengan urutan abjad,
sehingga untuk entitas “practicumschedules” yang memiliki tabel
“practicumschedules” dan entitas “practicians” yang memiliki tabel “practicians”
57
memerlukan sebuah tabel tambahan bernama “practicians_practicumschedules”.
Tabel tambahan ini berisi primary key dari dua buah tabel yang berasosiasi,
dengan aturan penamaan [nama tunggal entitas_id]. Primary key pada tabel
normalisasi tersebut ada dua, yakni practicumschedule_id dan practician_id.
Adapun entitas-entitas lain yang memiliki kardinalitas one to many (1:N),
diatur dalam CakePHP dengan konvensi penamaan asosiasi has many untuk
entitas yang berada di sisi kardinalitas pertama (1) dan belongs to untuk entitas
yang berada di sisi kardinalitas yang lain (N). Entitas practicumnames yang
memiliki kardinalitas one to many dengan entitas practicumschedules akan
memiliki asosiasi has many terhadap practicumschedules. Dengan kata lain, satu
buah entitas practicumnames bisa saja memiliki banyak (has many) entitas
practicumschedules. Entitas practicumschedules akan memiliki asosiasi belongs to
terhadap entitas practicumnames. Dengan kata lain, masing-masing entitas
practicumschedules hanya boleh menjadi milik satu entitas practicumnames yang
sama. Diagram LRS memberikan notasi satu buah bintang (*) untuk menunjukkan
field tabel yang menjadi primary key dan dua buah bintang (**) untuk field tabel
yang menjadi foreign key. Hasil transformasi diagram E-R menjadi diagram LRS
bisa dilihat selengkapnya pada Gambar 3.10 .
58
Gam
bar
3.10
Dia
gra
m L
RS
ba
sis
da
ta C
MS
iLab
59
3.3.3 Rancangan Tabel Basis Data
Rancangan tabel basis data adalah gambaran utuh dan lengkap dari semua
tabel yang ada pada database CMS iLab. Rancangan tabel ini juga menyertakan
informasi tiap-tiap atribut dan keterangan dari masing-masing field yang ada pada
tabel. Adapun rancangan tabel basis data selengkapnya adalah sebagai berikut :
1. Nama tabel : practicumnames
Jumlah field : 7
Primary key : id
Foreign key : -
No Nama Field Type Panjang / isi Keterangan 1. id Integer 11 Kode (id) praktikum 2. name Varchar 255 Nama praktikum 3. academic_year Varchar 255 Tahun ajaran praktikum 4. content Text Keterangan 5. activation Enum (‘0’,’1’) Aktivasi praktikum 6. created Datetime Tanggal upload 7. modified Datetime Tanggal modifikasi
2. Nama tabel : practicumschedules
Jumlah field : 7
Primary key : id
Foreign key : practicumname_id
No Nama Field Type Panjang / isi Keterangan 1. id Integer 11 Kode (id) jadwal praktikum 2. day Varchar 255 Hari praktikum 3. practician_amount Integer 5 Jumlah praktikan 4. assistant_amount Integer 5 Jumlah asisten 5. created Datetime Tanggal upload 6. modified Datetime Tanggal modifikasi 7. practicumname_id Integer 11 Kode (id) praktikum
60
3. Nama tabel : practicians
Jumlah field : 5
Primary key : id
Foreign key : -
No Nama Field Type Panjang / isi Keterangan 1. id Integer 11 Kode (id) praktikan 2. name Varchar 255 Nama praktikan 3. academic_year Varchar 255 Angkatan masuk kuliah 4. NIM Varchar 255 Nomer Induk Mahasiswa 5. created Datetime Tanggal upload
4. Nama tabel : assistants
Jumlah field : 7
Primary key : id
Foreign key : practicumschedule_id, practicumname_id
No Nama Field Type Panjang / isi Keterangan 1. id Integer 11 Kode (id) asisten 2. name Varchar 255 Nama asisten 3. academic_year Varchar 255 Angkatan masuk kuliah 4. NIM Varchar 255 Nomer Induk Mahasiswa 5. created Datetime Tanggal upload 6. practicumschedule_id Integer 11 Kode (id) jadwal praktikum 7. practicumname_id Integer 11 Kode (id) praktikum
5. Nama tabel : practicians_practicumschedules
Jumlah field : 2
Primary key : practicumschedule_id, practician_id
Foreign key : -
No Nama Field Type Panjang / isi Keterangan 1. practicumschedule_id Integer 11 Kode (id) jadwal praktikum 2. practician_id Integer 11 Kode (id) praktikan
61
6. Nama tabel : userstatuses
Jumlah field : 2
Primary key : id
Foreign key : -
No Nama Field Type Panjang / isi Keterangan 1. id Integer 10 Kode (id) level user 2. status Varchar 50 Status / level user
7. Nama tabel : users
Jumlah field : 8
Primary key : id
Foreign key : userstatus_id
No Nama Field Type Panjang / isi Keterangan 1. id Integer 10 Kode (id) user 2. username Varchar 255 Username 3. password Varchar 255 Password 4. first_name Varchar 255 Nama depan 5. last_name Varchar 255 Nama belakang 6. email Varchar 255 Email 7. phone Varchar 255 Nomer telepon 8. userstatus_id Integer 10 Kode (id) level user
8. Nama tabel : newscategories
Jumlah field : 2
Primary key : id
Foreign key : -
No Nama Field Type Panjang / isi Keterangan 1. id Integer 11 Kode (id) kategori berita 2. title Varchar 255 Judul kategori
62
9. Nama tabel : news
Jumlah field : 7
Primary key : id
Foreign key : newscategory_id, user_id
No Nama Field Type Panjang / isi Keterangan 1. id Integer 11 Kode (id) berita 2. title Varchar 255 Judul berita 3. content Text Isi berita 4. created Datetime Tanggal upload 5. modified Datetime Tanggal modifikasi 6. newscategory_id Integer 11 Kode (id) kategori berita 7. user_id Integer 11 Kode (id) user
10. Nama tabel : resources
Jumlah field : 10
Primary key : id
Foreign key : practicumname_id, project_id, user_id
No Nama Field Type Panjang / isi Keterangan 1. id Integer 11 Kode (id) resource 2. name Varchar 255 Nama resource 3. category Integer 2 Kategori resource 4. content Text Keterangan resource 5. filetype Varchar 255 Tipe file resource 6. created Datetime Tanggal upload 7. modified Datetime Tanggal modifikasi 8. practicumname_id Integer 11 Kode (id) praktikum 9. project_id Integer 11 Kode (id) project 10. user_id Integer 11 Kode (id) user
11. Nama tabel : projects
Jumlah field : 7
Primary key : id
63
Foreign key : user_id
No Nama Field Type Panjang / isi Keterangan 1. id Integer 11 Kode (id) project 2. name Varchar 255 Nama project 3. member Text Anggota project 4. content Text Keterangan project 5. created Datetime Tanggal upload 6. modified Datetime Tanggal modifikasi 7. user_id Integer 11 Kode (id) user
12. Nama tabel : links
Jumlah field : 6
Primary key : id
Foreign key : -
No Nama Field Type Panjang / isi Keterangan 1. id Integer 11 Kode (id) link 2. name Varchar 255 Nama link 3. url Varchar 255 URL link 4. content Text Keterangan link 5. created Datetime Tanggal upload 6. modified Datetime Tanggal modifikasi
13. Nama tabel : Profiles
Jumlah field : 5
Primary key : id
Foreign key : -
No Nama Field Type Panjang / isi Keterangan 1. id Integer 11 Kode (id) Profile 2. name Varchar 255 Judul profil 3. content Text Keterangan profil 4. created Datetime Tanggal upload 5. modified Datetime Tanggal modifikasi
64
14. Nama tabel : homes
Jumlah field : 5
Primary key : id
Foreign key : -
No Nama Field Type Panjang / isi Keterangan 1. id Integer 11 Kode (id) halaman depan 2. name Varchar 255 Judul halaman depan 3. content Text Keterangan halaman depan 4. created Datetime Tanggal upload 5. modified Datetime Tanggal modifikasi
15. Nama tabel : settings
Jumlah field : 2
Primary key : id
Foreign key : -
No Nama Field Type Panjang / isi Keterangan 1. id Integer 11 Kode (id) setting 2. name Varchar 255 Nama item setting 3. content Varchar 255 Keterangan item setting 4. activation Enum (‘0’,’1’) Aktivasi setting
16. Nama tabel : guestbooks
Jumlah field : 8
Primary key : id
Foreign key : -
No Nama Field Type Panjang / isi Keterangan 1. id Integer 11 Kode (id) komentar 2. name Varchar 255 Nama pengunjung 3. email Varchar 255 Email pengunjung 4. website Varchar 255 Website / URL pengunjung 5. coment Text Komentar pengunjung
65
6. answer Text Jawaban pengelola 7. created Datetime Tanggal upload 8. modifies Datetime Tanggal modifikasi
3.4 Disain Arsitektur Sistem
3.4.1 Arsitektur MVC pada CMS iLab
Disain arsitektur CMS iLab sebenarnya tidak jauh berbeda dengan konsep
arsitektur MVC framework CakePHP sebagaimana dijelaskan pada subbab 2.2.5.
Bagian Model dari CMS iLab berisi class-class yang berhubungan langsung
dengan database dan mengatur hubungan antar tabel. Bagian Controller dari
CMS iLab berisi class-class yang mengatur dan menangani request dari user
CMS iLab. Sedangkan bagian View dari CMS iLab berisi semua file thtml yang
bertugas menampilkan data dari Controller. Penjelasan lengkap ditunjukkan
Gambar 3.11.
DatabaseCMS iLab
Apache Web Server
Dispatcher
View Controller Model
User CMS
Model NewsModel PracticianModel PracticumnameModel PracticumscheduleModel AssistantModel ProjectModel Resource.......
Controller News
Controller Practician
Controller Practicumname
Controller Practicumschedule
Controller Assistant
Controller Project
Controller Resource
.......
PAGE
News
PAGE
Practician
PAGE
..........
FILENAME
index
FILENAME
add
FILENAME
edit
FILENAME
delete
FILENAME
...........
FILENAME
...........
Gambar 3.11 Arsitektur MVC pada CMS iLab
66
3.4.2 Hak Akses User
Selain sistem yang diakses oleh semua pengunjung, CMS iLab memiliki
sistem administrasi yang hanya bisa diakses oleh user yang memiliki akses ke
halaman administrasi. CMS iLab memiliki empat kategori user, yakni : Admin
(Super User), Lecturer (Dosen), Laboran, dan Member (Anggota). Penjelasan
kategori user ditunjukkan pada Tabel 3.3.
Tabel 3.3 Kategori user CMS iLab
Kategori User Kode Keterangan
Admin 1 Admin adalah kategori user dengan hak akses paling tinggi pada
CMS iLab. Seorang user yang memiliki kategori admin diijinkan
untuk mengelola seluruh fitur yang ada di iLab. Karena hak akses
yang tidak terbatas inilah, sebaiknya kategori admin hanya
dipegang oleh satu atau dua orang user saja.
Lecturer 2 Lecturer atau dosen adalah kategori user yang ditujukan untuk staf
pengajar yang ada di laboratorium. Lecturer hanya diberi
kewenangan untuk mengakses beberapa modul tertentu, sesuai
dengan kompetensi dan hak yang diberikan oleh pengelola
laboratorium.
Laboran 3 Laboran adalah kategori user yang paling bertanggung jawab
dalam pengelolaan praktikum. Oleh karena itu, pengelolaan
praktikum selain diakses oleh Admin juga bisa diakses oleh
Laboran, termasuk penggantian dan penghapusan jadwal
praktikum, data praktikan dan asisten, serta pembatasan jumlah
praktikan.
Member 4 Member adalah kategori terakhir dari keempat kategori user pada
iLab. Kategori Member bisa diisi oleh siapa saja, seperti
mahasiswa, asisten, praktikan, maupun mereka yang ingin
berkontribusi pada riset-riset yang dilakukan laboratorium.
67
Adapun hak akses user untuk melakukan administrasi (manajemen)
modul-modul utama pada CMS iLab akan dijelaskan pada Tabel 3.4 di bawah ini.
Tabel 3.4 Administrasi modul utama CMS iLab
Kategori User No. Nama Modul
Admin Lecturer Laboran Member
1. Home (halaman depan) • X • X
2. News (berita) • • • •
3. Profile (profil laboratorium) • • • X
4. Practicum (praktikum) • X • X
5. Resource • • • •
6. Project and research (info riset) • • • •
7. Guestbook (buku tamu) • • • X
8. User Management • X X X
9. Link (referensi) • • • •
10. Setting System • X • X
Keterangan :
• = diperbolehkan melakukan administrasi
X = tidak diperbolehkan melakukan administrasi
3.4.3 Use Case
Sebagai langkah awal pembuatan disain arsitektur aplikasi CMS iLab,
dibuat diagram Use Case. Pada Gambar 3.12 ditampilkan diagram Use Case. Ada
5 aktor yang menggunakan CMS iLab, yakni Admin, Lecturer, Laboran, Member,
dan Guest. Guest adalah praktikan dan asisten, sedangkan keempat aktor lainnya
adalah user yang memiliki akses dengan tingkat akses yang berbeda. Berikut ini
penjelasan rinci dari diagram Use Case CMS iLab.
68
Gambar 3.12 Use Case CMS iLab
69
Use Case : Aplikasi CMS iLab
Tipe Use Case : Analisis Sistem (umum)
Aktor utama : Admin, Lecturer, Laboran, Member dan Guest
Tugas aktor :
- Mengakses sistem informasi.
- Melakukan manajemen sistem informasi bagi aktor yang memiliki hak akses
ke sistem administrasi.
Pra kondisi :
Untuk bisa mengakses sistem administrasi, keempat aktor selain Guest harus
sudah terdaftar terlebih dahulu dan memiliki account aktif di sistem iLab.
Asumsi :
- keempat aktor selain Guest yang terdaftar pada sistem memiliki e-mail yang
valid.
- keempat aktor selain Guest yang terdaftar adalah civitas institusi atau mereka
yang diberi wewenang oleh pengelola laboratorium untuk mengelola sistem.
Deskripsi :
Use Case ini merupakan Use Case umum CMS iLab yang terdiri dari sepuluh sub
sistem (modul). Use Case ini menggunakan bahasa Inggris untuk memudahkan
pemahaman terhadap berbagai istilah-istilah kontekstual yang biasa digunakan
dalam disain sistem informasi. Sistem sebelah kiri (default system) adalah sistem
yang dijalankan oleh semua aktor. Masing-masing aktor diperkenankan untuk
menjalankan modul-modul yang ada pada default system. Sistem sebelah kanan
(administration system) adalah sistem yang hanya bisa dijalankan oleh aktor yang
70
memiliki hak akses untuk masuk ke dalam sistem. Untuk masuk dan melakukan
administrasi (manajemen) sistem, aktor harus memiliki account di database iLab.
Sistem administrasi dibagi menjadi empat bagian, masing-masing bagian terdiri
dari modul-modul manajemen yang memiliki permission yang berbeda. Modul
dengan permission Admin Privilege hanya bisa diakses oleh admin. Modul dengan
permission Admin and Laboran Privileges bisa diakses oleh admin dan laboran.
Modul dengan permission Admin, Lecturer, Laboran Privileges bisa diakses oleh
admin, lecturer, dan laboran. Modul dengan permission All User Registered
(except Guest) bisa diakses oleh semua aktor kecuali Guest.
Pengecualian :
Apabila aktor yang login ke sistem administrasi tidak melakukan aksi untuk
selang waktu tertentu (kurang lebih 2 menit), sistem secara otomatis akan
menghapus session dan aktor harus melakukan login ulang untuk mengakses
sistem administrasi.
Informasi yang dibutuhkan aktor :
- Status / hak akses aktor
- Informasi dan data praktikum
- Informasi login (username dan password)
3.4.4 Program Flow
Program flow adalah kombinasi antara disain arsitektur dan cara kerja
sistem berdasarkan arsitektur tersebut. CMS iLab yang dibangun dari framework
CakePHP menggunakan arsitektur MVC. Masing-masing bagian dari MVC
71
memiliki peran yang berbeda-beda. Program flow dari CMS iLab dijelaskan pada
Gambar 3.13.
User
Keyword pencarian
(melalui path url)
Mendapatkan ID menuju url halaman
ID dari objek atau parameter
lainnyaApakah objek ada
di database ?
Redirect ke halaman error
Memasukkan ID yang direquest
ke proses
Cek keamanan (apakah user
diperkenankan melakukan aksi ?)
Redirect ke halaman error
Ya
Tidak
Tidak
Lakukan filtering untuk objek (spam
filtering, HTML formatting, data
validation
Proses data yang dimasukkan (form,
post, search)
Parsing layout berdasarkan aksi dari
proses (html, rss, etc)
Gunakan template untuk tampilan
layout modul
Ambil konten yang akan ditampilkan
lakukan filtering dan validasi tampilan
konten
masukkan konten ke dalam template layout
konten
Tampilan akhir : layout konten +
layuot modul
YaHasil
ditampilkan ke user
Validasi request data dan alokasi
resource (database)
Memproses data yang
dimasukkan
Menampilkan data
MODEL
CONTROLLER
VIEW
Gambar 3.13 Program Flow CMS iLab
Saat pertama kali mengakses sistem, user bisa mengakses item yang
diinginkan dengan cara melakukan pencarian atau dengan cara mengakses item
melalui menu atau navigasi yang tersedia. Sistem, dalam hal ini Model,
melakukan validasi request yang dilakukan user. Bila item yang diminta tidak ada
dalam database, sistem akan memberikan pesan kesalahan. Bila item yang
72
diminta ada pada database, sistem akan melakukan validasi hak akses user
terhadap item yang akan diakses. Apabila user tidak memiliki hak akses terhadap
item tersebut, sistem akan mengeluarkan pesan kesalahan. Apabila user diijinkan
mengakses item, sistem melakukan filtering pada data yang masuk. Setelah itu,
sistem akan memproses parameter dan data yang dimasukkan sesuai dengan
request dari user. Hal ini menjadi tugas dari Controller.
Setelah data selesai diproses dan hasil diperoleh, sistem melakukan
parsing berdasar aksi yang diinginkan oleh user. Parsing tampilan diawali dengan
mengambil layout yang sesuai dengan modul yang diakses. Setelah itu, sistem
mengambil hasil pengolahan data dari Controller dan menampilkannya bersama-
sama dengan tampilan dasar modul yang diakses. Hasil parsing inilah yang dilihat
user melalui browser.
3.5 Komponen CMS
CMS iLab disusun berdasarkan beberapa komponen utama. Pembagian
jenis komponen ini berdasarkan fungsionalitasnya. Komponen-komponen tersebut
adalah, framework CakePHP, pustaka utama (webroot), pustaka tambahan,
konfigurasi, modul utama, modul tambahan.
3.5.1 Framework CakePHP
Framework CakePHP adalah bagian inti yang digunakan untuk
membangun CMS iLab. Pada struktur aplikasi, file-file class CakePHP terletak di
folder cake/. Pada pembuatan CMS iLab ini digunakan framework CakePHP versi
73
1.1.10.3825 (stabil). Sampai saat ini, framework CakePHP dikembangkan sampai
dengan versi 1.2.xx.xxxx (alfa). Perbedaan utama versi 1.1 dengan versi 1.2
adalah ekstensi file-file template (layout). Pada versi 1.1, ekstensi file adalah
*.thtml, sedangkan versi 1.2 menggunakan ekstensi *.tpl. Selain itu, ada beberapa
perubahan pada penggunaan class-class dan konvensi penulisan kode program
untuk versi 1.2. Pertimbangan pemakaian versi stabil adalah untuk mencegah
kelemahan-kelemahan yang mungkin muncul karena adanya bug (kesalahan pada
logika program atau sintaks program) pada sistem. Sebagai contoh, ada beberapa
fungsi dan pustaka tambahan (semacam AJAX) yang tidak lagi disertakan pada
versi alfa 1.2. Keputusan untuk meniadakan dukungan ini tentu bukan keputusan
final dan masih sangat mungkin akan dimunculkan kembali pada pengembangan
versi 1.2 selanjutnya. Penggunaan versi stabil 1.1 lebih aman karena dokumentasi
dan konvensi penulisan kode program sudah final.
3.5.2 Pustaka Utama (webroot)
Pustaka utama (webroot) berisi file-file yang dibutuhkan untuk mendukung
tampilan antarmuka sebagaimana yang diharapkan. Pustaka utama ini berisi file-
file gambar, CSS (cascading style sheet), Javascript, dan file-file yang mendukung
fungsi instalasi dan pengunduhan (download). Pustaka utama ini disimpan pada
folder app/webroot/. Beberapa pustaka utama yang terdapat pada file webroot
ditunjukkan pada Gambar 3.14
74
Gambar 3.14 Struktur pustaka utama
Framework CakePHP melakukan pengorganisasian file-file pustaka
dengan mengelompokkannya berdasarkan jenis file tersebut. Sebagaimana
Gambar 3.13, file-file CSS diletakkan pada folder css/, demikian pula file-file
gambar diletakkan pada folder img/. Adapun seluruh file Javascript, berikut
beberapa framework pendukung berbasis Javascript, seperti TinyMCE yang
digunakan untuk membuat tool-tool teks editor pada komponen HTML text area.
Implementasi framework TinyMCE tersebut akan tampak pada browser
sebagaimana digambarkan pada Gambar 3.15
Gambar 3.15 Teks editor TinyMCE
Secara default, framework CakePHP meletakkan file index.php pada folder
app/webroot/. File index.php ini memiliki peran penting pada beberapa tipe
instalasi aplikasi. Untuk keperluan produksi (pembuatan) aplikasi, konfigurasi
khusus yang terdapat file index.php ini tidak perlu diubah.
75
3.5.3 Pustaka Tambahan
Selain pustaka utama, aplikasi CMS iLab ini juga memerlukan beberapa
pustaka tambahan. Beberapa pustaka tambahan itu antara lain :
1. Kcaptcha
Pustaka ini terletak di folder vendors/ paling luar, sejajar dengan folder
app/ dan cake/. Pustaka Kcaptcha ini berisi class-class yang men-generate
gambar dari huruf dan angka yang diacak melalui fungsi random(). Untuk
berjalan dengan baik, instalasi PHP harus dilengkapi dengan GDLibrary,
yakni sebuah class pustaka PHP yang bertugas menghasilkan gambar dari
fungsi-fungsi PHP. Pustaka Kcaptcha ini merupakan produk open source
yang bisa didapatkan pada situs http://www.captcha.ru . Pustaka Kcaptcha
memberikan pilihan kepada programmer untuk melakukan konfigurasi
pada tampilan CAPTCHA. Untuk pembuatan CMS iLab, konfigurasi
CAPTCHA ditunjukkan pada kode program di bawah ini.
<?php $alphabet = "0123456789abcdefghijklmnopqrstuvwxyz"; $allowed_symbols = "23456789abcdeghkmnpqsuvxyz"; $fontsdir = 'fonts'; $length = 3; $width = 110; $height = 50; $fluctuation_amplitude = 1; $no_spaces = false; $show_credits = false; $foreground_color = array(0, 0, 0); $background_color = array(255, 255, 255); $jpeg_quality = 90; ?>
Gambar 3.16 Konfigurasi pustaka Kcaptcha
76
Variabel-variabel tersebut merupakan parameter dasar yang akan
ditampillkan pada CAPTCHA. Untuk menghasilkan gambar yang terbaik, kualitas
gambar diatur dengan memberikan nilai tertinggi untuk variabel $jpeg_quality.
Untuk membatasi jumlah karakter yang muncul pada CAPTCHA, nilai 3
diberikan pada variabel $length. CAPTCHA yang dihasilkan oleh pustaka
Kcaptcha ini ditunjukkan oleh Gambar 3.17.
Gambar 3.17 CAPTCHA dari pustaka Kcaptcha
2. Pagination
Pustaka Pagination digunakan untuk membagi konten halaman yang
terlalu panjang menjadi beberapa halaman. Pustaka ini juga didapatkan
secara gratis dari situs resmi milik pengembang CakePHP, yakni
http://cakeforge.org . Pustaka pagination ini membutuhkan beberapa file
Javascript untuk bisa berjalan dengan baik, yakni file prototype.js dan
scriptaculous.js. File-file ini disimpan di folder app/webroot/js/ . Pustaka
pagination secara fisik berbentuk sebuah file php yang diletakkan pada
folder app/view/helper/ . Implementasi pustaka ini ditunjukkan dengan
munculnya navigasi yang membagi halaman tampilan sesuai dengan batas
maksimal jumlah item yang boleh ditampilkan untuk tiap-tiap halaman,
sebagaimana ditunjukkan pada Gambar 3.18.
77
Gambar 3.18 Implementasi pustaka Pagination
3. Multiple Checkbox Helper
Pustaka Multiple Checkbox Helper (MCH) digunakan untuk membantu
komponen HTML checkbox. Pustaka ini digunakan pada halaman
pendaftaran praktikan untuk menampilkan daftar praktikum yang masih
tersedia. Pustaka ini secara fisik berbentuk file php yang terletak di folder
app/view/helper/ .
4. MySQL to XLS Converter
Pustaka ini merupakan pustaka vital yang digunakan oleh fungsi-fungsi
yang melakukan konversi data MySQL ke bentuk spreadsheet. Secara
fisik, pustaka ini berbentuk file php yang tersimpan pada folder
app/view/helper dan file thtml sebagai penampil tabel yang terdapat pada
folder app/view/layout. Pustaka ini memerlukan dukungan pustaka XSLT
pada instalasi PHP. Apabila pustaka XLST ini terpasang bersama instalasi
PHP, tampilan informasi sebagaimana pada Gambar 3.19 akan terlihat
apabila fungsi phpinfo( ) dijalankan pada sebuah file php.
78
Gambar 3.19 Pustaka XSLT aktif
3.5.4 Konfigurasi
Aplikasi CMS iLab membutuhkan beberapa variabel konfigurasi, terkait
dengan tipe instalasi, konfigurasi database, konfigurasi session, konfigurasi tipe
produksi dan sebagainya. Semua kebutuhan konfigurasi diletakkan oleh
framework CakePHP pada folder app/config/. Tiga buah file konfigurasi yang
cukup penting adalah core.php, routes.php dan database.php .
1. File core.php
File ini merupakan file penting yang menentukan mekanisme kerja framework
CakePHP. File core.php memiliki beberapa variabel yang bisa digunakan
untuk menambah fungsionalitas CakePHP yang secara default tidak diaktifkan.
Untuk kebutuhan produksi, CakePHP memiliki fungsi khusus yang akan
menampilkan pesan kesalahan dan saran saat programmer melakukan
kesalahan dalam membuat program. Sebagaimana kode program yang tampak
di bawah ini, CakePHP menyediakan empat buah pilihan metode debugging.
Apabila CakePHP digunakan untuk pembuatan aplikasi dan pengembangan
framework (development), disarankan mengisi variabel DEBUG dengan angka
79
1, 2 atau 3. Apabila CakePHP digunakan untuk menjalankan aplikasi yang
telah selesai dibuat, disarankan untuk mengubah isi variabel menjadi 0. Saat
variabel DEBUG berisi 0, semua pesan kesalahan dan peringatan yang
mungkin muncul akan dihilangkan, sehingga pengguna aplikasi tidak akan
menjumpai pesan tersebut saat menjalankan aplikasi.
<?php ............. /** * Set debug level here: * - 0: production * - 1: development * - 2: full debug with sql * - 3: full debug with sql and dump of the current object * * In production, the "flash messages" redirect aft er a time
interval. * With the other debug levels you get to click the "flash
message" to continue. */ define('DEBUG', 1); .......... ?>
Gambar 3.20 Sebagian konfigurasi core.php
2. File routes.php
File ini berisi konfigurasi halaman yang diakses pertama kali saat browser
diarahkan ke folder CMS iLab. Untuk keperluan instalasi, file ini harus
dimodifikasi sedemikian rupa, sehingga saat pertama kali dijalankan, CMS
iLab akan melakukan checking file konfigurasi database dan instalasi sample
database. Pada pilihan pertama, aplikasi akan memeriksa keberadaan file
konfigurasi database.php. Apabila file tersebut sudah belum ada, modul
Installer akan membuat file konfigurasi database.php. Apabila file tersebut
80
sudah ada, langkah selanjutnya adalah memeriksa keberadaan sample
database. Apabila aplikasi belum memasang sample database, modul Installer
akan melakukan instalasi. Apabila sample database sudah ada, modul instalasi
akan memeriksa keberadaan file installed.txt, yang menandakan sample
database sudah terpasang pada instalasi sebelumnya. Langkah terakhir adalah
memastikan CMS iLab berjalan dengan baik, dengan mengarahkan browser
ke halaman utama (home).
<?php /* cek, apakah file konfigurasi sudah ada atau belum */ if (! file_exists('../config/ database.php')){ $Route->connect('/', array(' Controller' => 'pages', 'action'
=> 'display', 'home')); } /* cek, apakah sample database sudah diupload atau belum */ else if (! file_exists('../tmp/installed.txt')){ $Route->connect('/', array(' Controller' => 'pages', 'action'
=> 'display', 'nosample')); } /* jika sudah, maka iLab siap digunakan */ else{ $Route->connect('/', array(' Controller' => 'homes', 'action'
=> 'index')); } ?>
Gambar 3.21 Konfigurasi pada routes.php
3. File database.php
File ini adalah file utama yang menghubungkan aplikasi dengan server
database. File ini secara default disediakan oleh framework CakePHP. Namun
dalam pembuatan CMS iLab, file ini akan dihilangkan dan sebagai gantinya
akan diberikan sebuah file database-sample.php sebagai dasar pembuatan file
database.php. File database.php berisi konfigurasi database yang akan
81
digunakan oleh CMS iLab, seperti nama host, username, password, nama
database, dan prefiks (awalan) yang digunakan untuk tabel database. Secara
default, CMS iLab tidak menggunakan prefiks untuk nama tabel. Penggunaan
prefiks disarankan apabila dilakukan instalasi dua buah aplikasi pada satu
database.
<?php //Ini adalah file konfigurasi CMS iLab define('DB_NAME', 'ilab'); define('DB_USER', 'root'); define('DB_PASSWORD', 'root'); define('DB_HOST', 'localhost'); define('TABLE_PREFIX', ''); class DATABASE_CONFIG { var $default = array('driver' => 'mysql', 'connect' => 'mysql_connect', 'host' => DB_HOST, ' login' => DB_USER, 'password' => DB_PASSWORD, ' database' => DB_NAME, 'prefix' => TABLE_PREFIX); } ?>
Gambar 3.22 Konfigurasi koneksi database
3.5.5 Modul utama
Sebagaimana telah dijelaskan pada sub bab 3.4.1, CMS iLab memiliki
sepuluh modul utama yang dirancang untuk memenuhi kebutuhan umum
laboratorium. Masing-masing modul memiliki bagian yang terdiri dari bagian
Model, bagian Controller, dan bagian View. Beberapa modul membutuhkan class-
class Model dan Controller lebih dari satu. Penamaan file Model, View dan
Controller pada framework CakePHP juga menggunakan konvensi tersendiri. File
Model diberi nama dengan nama tunggal dari tabel / entitas, diakhiri dengan
82
ekstensi *.php. File Controller diberi nama dengan [nama jamak
entitas]_controller.php. Penamaan View, nama folder merupakan nama jamak
entitas, yang berisi file-file berekstensi *.thtml, yang merepresentasikan fungsi-
fungsi (atau lebih dikenal dengan istilah action pada aturan penamaan CakePHP)
yang didefinisikan pada class-class Controller.
Sebagai contoh :
Nama Entitas : homes
Nama Tabel : homes
Nama File Model : home.php
Nama Class Model : Home
Nama File Controller : homes_controller.php
Nama Class Controller : HomesController
Nama Folder View : homes
Isi Folder : action1.thtml, action2.thtml, action3.thtml, dan
seterusnya.
3.5.5.1 Modul Home
Modul yang menampilkan konten halaman depan CMS iLab. Modul home
merupakan modul yang diakses pertama kali saat pengunjung mengakses CMS
iLab. Bagian-bagian dari modul ini adalah :
a. Model : pada perancangan basis data, entitas homes tidak memiliki
kardinalitas dengan entitas lainnya. Oleh karena itu, Model dari modul
Home tidak memiliki asosiasi dengan Model yang lainnya.
83
b. Controller : class Controller untuk modul Home memiliki beberapa
fungsi, antara lain :
- Fungsi untuk menampilkan informasi login;
- Index. Pada fungsi ini ditampilkan halaman depan;
- Main. Pada fungsi ini ditampilkan halaman utama manajemen modul;
- View. Pada fungsi ini ditampilkan data yang telah dimasukan database;
- Add. Fungsi ini digunakan untuk penambahan data;
- Edit. Fungsi ini digunakan untuk update data ;
- Delete. Fungsi untuk penghapusan data.
c. View : bagian View merupakan kumpulan kode-kode program yang
merepresentasikan fungsi-fungsi yang ada pada class Controller. Tiap-tiap
fungsi membutuhkan tampilan tersendiri. Sebagai contoh, fungsi
penambahan data (add) akan membutuhkan tampilan tersendiri yang
terkait dengan form isian untuk input data. Fungsi penghapusan (delete),
dalam hal ini tidak memerlukan tampilan karena tidak mem-parsing
keluaran.
3.5.5.2 Modul News
Modul yang menampilkan berita dan informasi yang terkait dengan
pelaksanaan praktikum dan penggunaan laboratorium. Bagian-bagian dari modul
ini adalah :
a. Model : modul News memerlukan dua buah Model, yakni News dan
Newscategory. Dua buah Model ini memiliki hubungan kardinalitas one to
84
many, yakni satu buah entitas newscategory memiliki banyak entitas news.
Model Newscategory memiliki asosiasi has many terhadap Model News,
sedangkan Model News memiliki asosiasi belongs to terhadap Model
Newscategory dan Model User.
b. Controller : class NewsController memiliki beberapa fungsi,
antara lain :
- Fungsi untuk menampilkan informasi login;
- Index. Pada fungsi ini ditampilkan halaman utama Modul News ;
- Daftar. Pada fungsi ini ditampilkan daftar berita berdasarkan kategori;
- Detail. Pada fungsi ini ditampilkan detail berita yang dibaca pengunjung;
- Main. Pada fungsi ini ditampilkan halaman utama manajemen modul;
- View. Pada fungsi ini ditampilkan data yang telah dimasukan database;
- Add. Fungsi ini digunakan untuk penambahan data;
- Edit. Fungsi ini digunakan untuk update data ;
- Delete. Fungsi untuk penghapusan data;
- Search. Fungsi ini digunakan untuk melakukan pencarian data berita.
Fungsi ini memanfaatkan teknologi AJAX (Asynchronous Javascript and
XML), sehingga saat kata kunci dimasukkan, fungsi segera mengeksekusi
kata kunci, mencocokkan dengan database dan menampilkannya secara
live.
Class NewscategoriesController memiliki beberapa fungsi, antara lain :
- Fungsi untuk menampilkan informasi login;
- Index. Pada fungsi ini ditampilkan halaman manajemen modul ;
85
- Add. Fungsi ini digunakan untuk penambahan data;
- Edit. Fungsi ini digunakan untuk update data ;
- Delete. Fungsi untuk penghapusan data.
c. View : sebagaimana jumlah Controller yang dibutuhkan, folder View
yang dibutuhkan juga menyesuaikan kebutuhan. Modul News memiliki
dua buah folder View, yakni News dan Newscategories.
3.5.5.3 Modul Profile
Modul yang menampilkan profil laboratorium. Bagian-bagian dari modul
ini adalah :
a. Model : pada perancangan basis data, entitas Profiles tidak memiliki
kardinalitas dengan entitas lainnya. Oleh karena itu, Model dari modul
Profile tidak memiliki asosiasi dengan Model yang lainnya.
b. Controller : class ProfilesController memiliki beberapa fungsi yakni :
- Fungsi untuk menampilkan informasi login;
- Index. Pada fungsi ini ditampilkan halaman Profile;
- Main. Pada fungsi ini ditampilkan halaman utama manajemen modul;
- View. Pada fungsi ini ditampilkan data yang telah dimasukan database;
- Add. Fungsi ini digunakan untuk penambahan data;
- Edit. Fungsi ini digunakan untuk update data ;
- Delete. Fungsi untuk penghapusan data.
c. View : bagian View dari Modul Profile menggunakan sebuah folder
Profiles untuk menyimpan file-file View.
86
3.5.5.4 Modul Practicum
Modul Practicum adalah modul dengan jumlah class Model dan Controller
yang paling banyak apabila dibandingkan dengan modul-modul lainnya. Modul
ini memerlukan banyak class karena banyaknya logic-logic yang dibutuhkan
untuk manajemen praktikum. Selain itu, modul ini juga membutuhkan banyak
pustaka pendukung, seperti Kcaptcha, Pagination, Multiple Checkbox Helper, dan
MySQL to XLS Converter. Bagian-bagian dari modul Practicum adalah :
a. Model : modul Practicum membutuhkan empat buah class Model, antara
lain Assistant, Practician, Practicumname, dan Practicumschedule. Model
Assistant memiliki beberapa asosiasi belongs to terhadap Model
Practicumname dan Practicumschedule. Model Practician memiliki
asosiasi has and belongs to many terhadap Model Practicumschedule.
Model Practicumname memiliki asosiasi has many terhadap Model
Practicumschedule, Resource, dan Assistant. Model Practicumschedule
memiliki tiga buah asosiasi, yakni :
- has and belongs to many terhadap Model Practician ;
- belongs to terhadap Model Practicumname ;
- has many terhadap Model Assistant.
b. Controller : Modul Practicum memiliki empat buah class Controller,
antara lain AssistantsController, PracticiansController,
PracticumnamesController, dan PracticumschedulesController.
AssistantsController memiliki beberapa fungsi, antara lain :
- Fungsi untuk menampilkan informasi login;
87
- Index. Pada fungsi ini ditampilkan halaman informasi asisten;
- Main. Pada fungsi ini ditampilkan halaman utama manajemen modul;
- View. Pada fungsi ini ditampilkan data yang telah dimasukan database;
- Add. Fungsi ini digunakan untuk registrasi asisten ;
- Edit. Fungsi ini digunakan untuk update data ;
- Delete. Fungsi ini digunakan untuk penghapusan data ;
- Deleteall. Fungsi untuk menghapus data asisten secara massal ;
- Captcha. Fungsi untuk menampilkan CAPTCHA di halaman pendaftaran
asisten.
PracticiansController memiliki beberapa fungsi, antara lain :
- Fungsi untuk menampilkan informasi login;
- Index. Pada fungsi ini ditampilkan halaman informasi praktikan;
- Detail. Pada fungsi ini ditampilkan detail data dari praktikan yang telah
mendaftarkan diri.
- Correction. Fungsi yang dibuat agar praktikan bisa melakukan perbaikan
data praktikum apabila terdapat kesalahan saat melakukan pendaftaran.
- Main. Pada fungsi ini ditampilkan halaman utama manajemen modul;
- View. Pada fungsi ini ditampilkan data yang telah dimasukan database;
- Add. Fungsi ini digunakan untuk registrasi praktikan ;
- Edit. Fungsi ini digunakan untuk update data ;
- Delete. Fungsi ini digunakan untuk penghapusan data ;
- Deletesub. Fungsi untuk menghapus data praktikan pada jadwal
praktikum tertentu ;
88
- Deleteall. Fungsi untuk menghapus data praktikan secara massal ;
- Captcha. Fungsi untuk menampilkan CAPTCHA di halaman pendaftaran
praktikan.
PracticumnamesController memiliki beberapa fungsi, antara lain :
- Fungsi untuk menampilkan informasi login;
- Index. Pada fungsi ini ditampilkan halaman daftar praktikum yang aktif;
- Main. Pada fungsi ini ditampilkan halaman utama manajemen modul;
- View. Pada fungsi ini ditampilkan data yang telah dimasukan database;
- Add. Fungsi ini digunakan untuk penambahan data;
- Edit. Fungsi ini digunakan untuk update data ;
- Delete. Fungsi ini digunakan untuk penghapusan data ;
PracticumschedulesController memiliki beberapa fungsi, antara lain :
- Fungsi untuk menampilkan informasi login;
- Index. Pada fungsi ini ditampilkan daftar jadwal praktikum sesuai nama
praktikum serta jumlah peserta terdaftar;
- Indexast. Pada fungsi ini ditampilkan daftar jadwal praktikum sesuai
nama praktikum serta jumlah asisten terdaftar;
- Detail. Pada fungsi ini ditampilkan detail pelaksanaan salah satu jadwal
praktikum, peserta dan asisten praktikum pada jadwal tersebut.
- Cetak. Fungsi ini digunakan melakukan konversi data MySQL ke bentuk
spreadsheet. Fungsi inilah yang mengeksekusi pustaka tambahan MySQL
to XLS Converter.
89
- Register. Fungsi ini digunakan untuk menampilkan halaman registrasi
asisten sesuai dengan jadwal praktikum yang dipilih.
- Main. Pada fungsi ini ditampilkan halaman utama manajemen modul;
- View. Pada fungsi ini ditampilkan data yang telah dimasukan database;
- Add. Fungsi ini digunakan untuk penambahan data;
- Edit. Fungsi ini digunakan untuk update data ;
- Delete. Fungsi ini digunakan untuk penghapusan data ;
c. View : bagian View Modul Practicum memerlukan empat buah folder,
yakni folder Assistants, Practicians, Practicumnames, dan
Practicumschedules. Selain itu, pada folder layout, bagian View dari
Modul ini membutuhkan layout khusus saat melakukan konversi data dari
MySQL ke spreadsheet.
3.5.5.5 Modul Resource
Modul ini berfungsi melakukan manajemen resource pendukung
praktikum dan penelitian di laboratorium. Bagian-bagian dari modul ini adalah :
a. Model : bagian Model dari modul Resource ini memiliki asosiasi
belongs to terhadap Model User, Practicumname, dan Project.
b. Controller : class ResourcesController memiliki beberapa fungsi
yakni :
- Fungsi untuk menampilkan informasi login;
- Index. Pada fungsi ini ditampilkan halaman utama modul Resources;
- Main. Pada fungsi ini ditampilkan halaman utama manajemen modul;
90
- Detail. Pada fungsi ini ditampilkan detail informasi resource.
- Add. Fungsi ini digunakan untuk penambahan data dan upload resource;
- Edit. Fungsi ini digunakan untuk update data ;
- Delete. Fungsi untuk penghapusan data. Fungsi ini juga memanggil
fungsi rdel() saat item data dihapus ;
- Rdel. Fungsi untuk menghapus secara fisik file-file resource;
c. View : bagian View dari Modul Resource menggunakan sebuah folder
Resources untuk menyimpan file-file View.
3.5.5.6 Modul Project and Research
Modul ini berfungsi untuk menampilkan informasi penelitian dan proyek
yang sedang dikembangkan di laboratorium tersebut. Bagian-bagian dari modul
ini adalah :
a. Model : untuk mempermudah, class Model dinamakan dengan class
Project saja. Class ini memiliki asosiasi belongs to terhadap Model User
dan has many terhadap Model Resource.
b. Controller : class ProjectsController memiliki beberapa fungsi yakni :
- Fungsi untuk menampilkan informasi login;
- Index. Pada fungsi ini ditampilkan halaman utama modul Project and
Research;
- Main. Pada fungsi ini ditampilkan halaman utama manajemen modul;
- Detail. Pada fungsi ini ditampilkan detail informasi project ;
- Add. Fungsi ini digunakan untuk penambahan data ;
91
- Edit. Fungsi ini digunakan untuk update data ;
- Delete. Fungsi untuk penghapusan data ;
- View. Pada fungsi ini ditampilkan data yang telah dimasukan database;
c. View : bagian View dari Modul Project and Research menggunakan
sebuah folder Projects untuk menyimpan file-file View.
3.5.5.7 Modul Guestbook
Modul ini berfungsi sebagai sarana diskusi antara pengunjung dan
pengelola laboratorium, serta sebagai kotak saran bagi pengembangan manajemen
laboratorium. Bagian-bagian dari modul ini adalah :
a. Model : Model Guestbook tidak memiliki asosiasi dengan Model
lainnya.
b. Controller : class GuestbooksController memiliki beberapa fungsi
yakni :
- Fungsi untuk menampilkan informasi login;
- Index. Pada fungsi ini ditampilkan halaman manajemen modul ;
- All. Pada fungsi ini ditampilkan daftar pesan yang masuk ;
- Add. Fungsi ini digunakan untuk penambahan pesan ;
- Edit. Fungsi ini digunakan untuk update data ;
- Delete. Fungsi untuk penghapusan data ;
- View. Pada fungsi ini ditampilkan data yang telah dimasukan database;
- Captcha. Fungsi untuk menampilkan CAPTCHA di halaman
penambahan pesan.
92
c. View : bagian View dari Modul Guestbook menggunakan sebuah folder
Guestbooks untuk menyimpan file-file View.
3.5.5.8 Modul Link
Modul ini berfungsi untuk menampilkan referensi online dan link ke situs
lain. Bagian-bagian dari modul ini adalah :
a. Model : Model Link tidak memiliki asosiasi dengan Model lainnya.
b. Controller : class LinksController memiliki beberapa fungsi yakni :
- Fungsi untuk menampilkan informasi login;
- Index. Pada fungsi ini ditampilkan halaman utama modul Link ;
- Main. Pada fungsi ini ditampilkan halaman manajemen modul ;
- Add. Fungsi ini digunakan untuk penambahan data ;
- Edit. Fungsi ini digunakan untuk update data ;
- Delete. Fungsi untuk penghapusan data ;
- View. Pada fungsi ini ditampilkan data yang telah dimasukan database;
c. View : bagian View dari Modul Link menggunakan sebuah folder Links
untuk menyimpan file-file View.
3.5.5.9 Modul User
Modul ini berfungsi untuk manajemen user CMS iLab. Bagian-bagian dari
modul ini adalah :
93
a. Model : membutuhkan dua buah Model, yakni User dan Userstatus.
Model Userstatus memiliki asosiasi has many terhadap Model User.
Model User memiliki asosiasi belongs to terhadap Model Userstatus.
b. Controller : class UserstatusesController memiliki beberapa fungsi
yakni :
- Fungsi untuk menampilkan informasi login;
- Index. Pada fungsi ini ditampilkan halaman manajemen modul ;
- Edit. Fungsi ini digunakan untuk update data ;
Class UsersController memiliki beberapa fungsi, antara lain :
- Fungsi untuk menampilkan informasi login;
- Index. Pada fungsi ini ditampilkan halaman manajemen modul ;
- Add. Fungsi ini digunakan untuk penambahan data ;
- Edit. Fungsi ini digunakan untuk update data ;
- Delete. Fungsi untuk penghapusan data ;
c. View : bagian View dari Modul User menggunakan dua buah folder,
yakni folder Users dan Userstatses, untuk menyimpan file-file View.
3.5.5.10 Modul Setting
Modul ini berperan pada pengaturan CMS iLab secara umum. Bagian-
bagian dari modul ini adalah :
a. Model : Model Setting tidak memiliki asosiasi dengan Model lainnya.
b. Controller : class SettingsController memiliki beberapa fungsi yakni :
- Fungsi untuk menampilkan informasi login;
94
- Index. Pada fungsi ini ditampilkan halaman utama modul Link ;
- Edit. Fungsi ini digunakan untuk update data ;
c. View : bagian View dari Modul Setting menggunakan sebuah folder
Settings untuk menyimpan file-file View.
3.5.6 Diagram Inheritance Modul Utama
Class-class Model diatas diturunkan dari class AppModel dan class Object.
Secara garis besar, hubungan inheritance (pewarisan) antara Model dan class
induknya ditunjukkan pada Gambar 3.23.
Class-class Controller diturunkan dari class AppController. Hubungan
inheritance (pewarisan) antara class-class Controller dengan class induknya
ditunjukkan pada Gambar 3.24 dan 3.25. Dari diagram tersebut dapat disimpulkan
bahwa beberapa fungsi dan variabel yang digunakan pada class-class Controller
adalah fungsi dan variabel yang bersifat public dari class induknya. Tiap-tiap
class Controller diberi fungsi beforeFilter() yang berisi inisialisasi informasi
login dan nama modul yang akan ditampilkan pada tag <title></title>.
95
Gambar 3.23 Diagram Inheritance class-class Model
96
Gam
bar
3.24
Dia
gra
m I
nh
eri
tan
ce c
lass
-cla
ss C
on
tro
ller
(1)
97
Gam
bar
3.25
Dia
gra
m I
nh
eri
tan
ce c
lass
-cla
ss C
on
tro
ller
(2)
98
3.5.7 Modul tambahan
Selain beberapa modul utama, CMS iLab juga menggunakan beberapa
modul tambahan, yakni modul Login dan Installer. Modul-modul ini adalah
modul yang tidak memerlukan tabel database, karena tidak memiliki entitas basis
data.
3.5.7.1 Modul Login
Digunakan sebagai penyeleksi hak akses user sebelum masuk ke sistem
administrasi CMS. Bagian-bagian dari modul ini adalah :
a. Model : class Login tidak memiliki asosiasi dengan Model yang lain.
b. Controller : class LoginsController memiliki beberapa fungsi yakni :
- Login. Fungsi ini digunakan untuk otentifikasi user sebelum memasuki
sistem administrasi. Apabila username, password dan karakter CAPTCHA
yang dimasukkan benar, user akan masuk ke halaman menu administrasi.
Namun apabila data yang dimasukkan salah, sistem akan mengeluarkan
pesan kesalahan ;
- Logout. Fungsi untuk menghapus session user saat user keluar dari
sistem administrasi.
- Captcha. Fungsi ini digunakan untuk men-generate CAPTCHA
c. View : bagian View dari Modul Login menggunakan folder Logins untuk
menyimpan file-file View.
99
3.5.7.2 Modul Installer
Digunakan untuk instalasi CMS iLab secara default. Modul Installer akan
diakses oleh sistem apabila file database.php dan contoh konten database belum
ada. Bagian-bagian dari modul ini adalah :
a. Model : tidak ada.
b. Controller : class InstallerController memiliki beberapa fungsi yakni :
- Fungsi yang melakukan checking keberadaan contoh konten database
CMS iLab.
- Database. Berperan saat instalasi konten database. Fungsi ini akan
melakukan pemeriksaan hak akses folder app/config/. Selain itu, fungsi ini
akan mengeksekusi fungsi __executeSQLScript() untuk memasukkan
konten database yang sudah disediakan oleh sebuah file *.sql.
- Thanks. Setelah instalasi konten database selesai, fungsi ini membuat file
installed.txt pada folder app/tmp/ sebagai tanda bahwa aplikasi sudah bisa
dijalankan dengan baik.
- __executeSQLScript. Fungsi inilah yang membaca isi file *.sql yang
berisi perintah-perintah SQL dan contoh data yang akan digunakan sistem.
c. View : bagian View dari Modul Installer menggunakan folder Installer
untuk menyimpan file-file View.
d. Komponen tambahan lain adalah sebuah file yang melakukan checking
keberadaan file database.php serta file *.sql yang berisi contoh konten
database.
100
BAB IV
IMPLEMENTASI DAN PENGUJIAN APLIKASI
4.1 Alat dan Bahan yang Digunakan
4.1.1 Peralatan yang Digunakan
Pembuatan CMS ini menggunakan beberapa peralatan, yakni :
1. Komputer notebook iBook G4, dengan prosesor Power PC G4 1,33 GHz,
memori 512 MB, hard disk 40 GB, kartu grafis ATI Mobility Radeon
9550 (32 MB).
2. Sistem operasi Mac OS X versi 10.4.10, dengan kernel inti Unix Darwin
versi 8.10.0. Aplikasi ini dikembangkan pada sistem operasi berbasis Unix
dengan harapan permasalahan-permasalahan hak akses direktori dan
metode instalasi sistem dapat dirancang sedemikian rupa sehingga sesuai
untuk sistem operasi Microsoft Windows maupun sistem operasi berbasis
Unix.
3. Apache Web Server 2.0.55 Unix Version. Instalasi Apache Web Server ini
dilengkapi dengan semua modul pendukung, termasuk modul
Mod_rewrite.
4. PHP versi 4.4.2, lengkap dengan pustaka GD Library dan XSLT
5. Database MySQL versi 4.1.12 dan phpMyAdmin 2.7.0-pl2 untuk
manajemen database menggunakan antarmuka berbasis web.
101
6. Browser yang digunakan untuk proses produksi adalah Mozilla Firefox
2.0.0.6 untuk Unix
7. Smultron versi 2.1.5, digunakan untuk penulisan program.
8. Adobe Photoshop CS 2, digunakan untuk editing gambar dan disain web.
9. Concept Draw Web Wave versi 5.8 dan Omni Graffle Professional untuk
disain database, UML, dan diagram kelas.
4.1.2 Bahan yang Digunakan
Bahan yang digunakan untuk pembuatan CMS ini adalah beberapa file
gambar dan ikon yang digunakan untuk navigasi, judul halaman (modul), dan
layout aplikasi. File-file ini bisa didapatkan secara gratis dari internet maupun dari
situs-situs khusus yang ditujukan untuk kelengkapan disain website. Semua bahan
berupa gambar dan ikon disimpan dalam satu folder, yakni folder img/ yang ada
di bawah folder pustaka utama (webroot).
4.2 Implementasi Komponen CMS
4.2.1 Framework CakePHP
Pada pembuatan CMS iLab ini framework CakePHP tidak terlalu banyak
dimodifikasi. Namun untuk menyesuaikan setting waktu lokal (Indonesia Bagian
Barat) dan penggunaan bahasa Indonesia pada penulisan waktu, beberapa
parameter class Helper perlu diubah. Salah satu class yang mengalami sedikit
102
perubahan adalah class TimeHelper pada file time.php yang terletak di folder
cake/libs/view/helpers.
CakePHP menyediakan beberapa fungsi untuk penyederhanaan penulisan
waktu. Class TimeHelper berisi beberapa fungsi yang bisa digunakan untuk
penulisan waktu. Fungsi yang perlu dimodifikasi ada dua, yakni fungsi
niceShort() dan fungsi timeAgoInWords(). Fungsi niceShort() biasanya digunakan
untuk menampilkan format waktu menjadi bentuk yang mudah dibaca. Beberapa
parameter fungsi yang berbahasa Inggris disesuaikan dengan bahasa Indonesia.
Penggunaan fungsi niceShort() ditunjukkan pada gambar di bawah ini.
<? echo $time->niceShort($news['News']['created']); ?>
Gambar 4.1. Penggunaan fungsi niceShort().
Saat variabel yang mengandung nilai waktu dimasukkan ke dalam fungsi
sebagai parameter masukan, secara otomatis CakePHP akan men-generate hasil
fungsi dengan menampilkan nilai waktu dalam format yang simpel dan mudah
dimengerti. Hasil penggunaan fungsi niceShort() pada tampilan bisa dilihat di
Gambar 4.2 .
Gambar 4.2. Penggunaan fungsi niceShort() pada antarmuka.
103
<?php ... function niceShort($date_string = null, $return = f alse) { $date = $date_string ? $this->fromString($date_st ring) :
time(); $y = $this->isThisYear($date) ? '' : ' Y'; if ($this->isToday($date)) { $ret = "Hari ini, " . " ". date("H:i", $date)." WIB"; } elseif($this->wasYesterday($date)) { $ret = "Kemarin, " . " ". date("H:i", $date)." W IB"; } else { $ret = date("j M {$y}, H:i", $date)." WIB"; } return $this->output($ret, $return); } .... ?>
Gambar 4.3. Fungsi niceShort() yang sudah dimodifikasi.
Serupa dengan fungsi niceShort(), fungsi timeAgoInWords() juga
digunakan untuk menampilkan format penulisan waktu yang lebih mudah
dipahami. Namun demikian, fungsi ini menghitung selisih waktu tampilan data
saat ini dengan saat data tersebut dibuat. Fungsi ini menghitung selisih dan
menampilkannya dengan format detik, menit, jam, hari, dan seterusnya, sesuai
dengan besarnya selisih waktu tersebut. Hasil penggunaan fungsi
timeAgoInWords() ditunjukkan pada gambar di bawah ini.
Gambar 4.4. Penggunaan fungsi timeAgoInWords() pada antarmuka.
104
<? .... function timeAgoInWords($datetime_string, $ format = 'j/n/y',
$backwards = false, $return = false) { $datetime = $this->fromString($datetime_string); $in_seconds = $datetime; if ($backwards) { $diff = $in_seconds - time(); } else { $diff = time() - $in_seconds; } $months=floor($diff / 2419200); $diff -= $months * 2419200; $weeks=floor($diff / 604800); $diff -= $weeks * 604800; $days=floor($diff / 86400); $diff -= $days * 86400; $hours=floor($diff / 3600); $diff -= $hours * 3600; $minutes=floor($diff / 60); $diff -= $minutes * 60; $seconds=$diff; if ($months > 0) { // over a month old, just show date (mm/dd/yyyy format) $relative_date = 'on ' . date($ format, $in_seconds); $old = true; } else { $relative_date = ''; $old = false; if ($weeks > 0) { // weeks and days $relative_date .= ($relative_date ? ', ' : '') . $weeks
. ' minggu' . ($weeks > 1 ? '' : ''); $relative_date .= $days > 0 ? ($relative_date ? ', ' :
'') . $days . ' hari' . ($days > 1 ? '' : '') : ''; } elseif($days > 0) { // days and hours $relative_date .= ($relative_date ? ', ' : '') . $days .
' hari' . ($days > 1 ? '' : ''); $relative_date .= $hours > 0 ? ($relative_date ? ', ' :
'') . $hours . ' jam' . ($hours > 1 ? '' : '') : '' ; } elseif($hours > 0) { // hours and minutes $relative_date .= ($relative_date ? ', ' : '') . $hours
. ' jam' . ($hours > 1 ? '' : ''); $relative_date .= $minutes > 0 ? ($relative_dat e ? ', '
: '') . $minutes . ' menit' . ($minutes > 1 ? '' : '') : ''; } elseif($minutes > 0) { // minutes only
105
$relative_date .= ($relative_date ? ', ' : '') . $minutes . ' menit' . ($minutes > 1 ? '' : '');
} else { // seconds only $relative_date .= ($relative_date ? ', ' : '') .
$seconds . ' detik' . ($seconds != 1 ? '' : ''); } } $ret = $relative_date; // show relative date and add proper verbiage if (!$backwards && !$old) { $ret .= ' yang lalu'; } return $this->output($ret, $return); } ..... ?>
Gambar 4.5. Fungsi timeAgoInWords() yang sudah dimodifikasi.
4.2.2 Modul Utama
Setelah disain aplikasi dan class dibuat dengan rinci, tahapan selanjutnya
adalah menerjemahkan disain aplikasi ke dalam bentuk kode sumber. Kode
sumber tidak menggambarkan arsitektur program secara menyeluruh karena
ditampilkan hanya untuk memberi gambaran peran dan fungsi modul.
4.2.2.1 Modul Home
Modul Home adalah modul yang pertama kali diakses saat aplikasi
dijalankan dalam keadaan normal dan terinstalasi secara benar. Bagian Model dari
modul ini tidak memiliki asosiasi dengan Model lainnya. Namun demikian, perlu
ada sebuah validasi masukan pada form isian halaman administrasi. Validasi ini
digunakan untuk mencegah kesalahan saat memasukkan data, sehingga form isian
menjadi kosong. Validasi ini dilakukan dengan mengisikan elemen array ‘name’
106
dan ‘content’ dengan parameter VALID_NOT_EMPTY. Kedua elemen array
tersebut mewakili field ‘name’ dan ‘content’ dari tabel homes.
<? .... var $validate = array( 'name' => VALID_NOT_EMPTY, 'content' => VALID_NOT_EMPTY ); .... ?>
Gambar 4.6. Validasi input pada Model Home
Apabila tidak ada masukan pada form isian yang divalidasi, sistem akan
menampilkan pesan kesalahan. Pesan kesalahan ini diletakkan di bawah penulisan
kode program form tersebut pada file View dari Modul Home. Gambar 4.7
menunjukkan salah satu penulisan pesan kesalahan dengan menggunakan metode
tagErrorMsg() dari objek $html. Pesan kesalahan yang ditampilkan apabila isian
‘Judul’ tidak terisi adalah ‘Silahkan masukkan judul.’.
Judul:<br> <?php echo $html->input('Home/name', array( 'size' =>
'30'))?> <?php echo $html->tagErrorMsg('Home/name', 'Silahkan
masukkan judul.') ?>
Gambar 4.7. Penulisan pesan kesalahan pada View
Pada semua class Controller, termasuk class HomesController,
ditambahkan sebuah fungsi beforeFilter(). Fungsi ini akan dijalankan terlebih
dahulu sebelum fungsi-fungsi lainnya. Fungsi ini berisi variabel $this->pageTitle
yang berisi judul modul. Selain itu, fungsi ini juga digunakan untuk menampilkan
informasi login apabila ada seorang user yang masuk ke halaman administrasi.
107
Pertama-tama, fungsi akan membaca session yang dibuat oleh user yang saat itu
sedang login. Session tersebut dicocokkan dengan hak akses dari user tersebut.
Hasil pencocokan tadi digunakan untuk menampilkan nama username yang saat
<? .... function beforeFilter(){ $this->pageTitle = 'Home'; if(isset($_SESSION['User']['username'])){ if(($_SESSION['priv'] == '1')) { $sesi = $_SESSION['User']['username']; $this->set('admin',$sesi); } else if(($_SESSION['priv'] == '2')) { $sesi = $_SESSION['User']['username']; $this->set('lecturer',$sesi); } else if(($_SESSION['priv'] == '3')) { $sesi = $_SESSION['User']['username']; $this->set('laboran',$sesi); } else{ $sesi = $_SESSION['User']['username']; $this->set('member',$sesi); } $nama = $_SESSION['User']['username']; $this->set('nama',$nama); } } .... ?>
Gambar 4.8. Fungsi beforeFilter()
108
Gambar 4.9 menunjukkan user ‘sunu’ sedang login dalam sistem. Sistem
akan memberikan informasi login tepat di bagian atas layout konten modul (lihat
Bab 3, Gambar 3.7).
Gambar 4.9. Info login saat user ’sunu’ sedang login
Pada modul Home, fungsi index() akan diimplementasikan di file
index.thtml pada bagian View. CakePHP memiliki fungsi khusus untuk
menggantikan perintah SQL ‘SELECT * FROM ...‘, yakni fungsi findAll().
Fungsi ini dijalankan sebagai metode dari objek Model yang didefinisikan, dalam
hal ini Home. Parameter dari fungsi findAll() adalah kondisi-kondisi yang biasa
disertakan saat perintah SQL ‘SELECT’ dijalankan.
<? .... function index() { $this->Home->recursive = 0; $home = $this->Home->findAll( null, null, 'Home.id DESC', 1 ); $this->set('home',$home); } .... ?>
Gambar 4.10. Fungsi index() pada class HomesController
Fungsi add() diimplementasikan di file add.thtml. Berbeda dengan fungsi
index(), fungsi add() ini hanya boleh diakses oleh user Admin dan Laboran (lihat
Bab 3, Tabel 3.4). Oleh karena itu, fungsi add() membutuhkan validasi user
109
sebelum dieksekusi. Validasi user dilakukan dengan metode checkSession() dan
pencocokan session yang saat itu sedang aktif. Apabila session yang aktif bukan
session Admin atau Laboran, sistem akan mengeluarkan pesan kesalahan
‘Restricted Area. Please Contact Your Admin !’ dan akan melakukan redirect ke
halaman awal (home). Validasi ini juga disertakan di fungsi-fungsi lain pada class
HomesController, seperti fungsi main(), edit(), delete(), dan view().
<? .... function add() { $this->checkSession(); if(($_SESSION['priv'] != '1')&&($_SESSION['priv'] != '3')) { $this->flash('Restricted Area. Please Contact Y our Admin
!','/'); } if (!empty($this->data)) { if ($this->Home->save($this->data)) { $this->flash('Konten home tersimpan .','/'); } else { $this->Session->setFlash('Mohon koreksi ke salahan Anda
!'); } } } .... ?>
Gambar 4.11. Fungsi add() pada class HomesController
Pada halaman administrasi, elemen HTML text area dilengkapi dengan
tool editor teks yang di-generate oleh framework TinyMCE. Editor teks tersebut
membantu penulis artikel untuk melakukan pengeditan konten sebagaimana
110
dilakukan dengan perangkat lunak Microsoft Office atau OpenOffice Writer.
Gambar 4.12 menunjukkan salah satu halaman administrasi modul Home. Saat
user ‘admin’ sedang login, pada sisi kiri muncul menu navigasi administrasi yang
diberi label ‘Home Administration’.
Gambar 4.12. Halaman administrasi modul Home
4.2.2.2 Modul News
Pada modul News, Model News memiliki asosiasi dengan Model
Newscategory dengan asosiasi belongs to. Asosiasi ini didefinisikan pada Model
News, sebagaimana ditunjukkan oleh Gambar 4.13. Selain asosiasi pertama,
Model News juga memiliki asosiasi kedua dengan Model User. Model News
berasosiasi belongs to terhadap Model User.
Editor teks TinyMCE
Menu Administrasi
111
<?php class News extends AppModel { var $name = 'News'; var $useTable = 'news'; var $validate = array( 'title' => VALID_NOT_EMPTY, 'newscategory_id' => VALID_NOT_EMPTY, 'content' => VALID_NOT_EMPTY ); var $belongsTo = array( 'Newscategory' => array(' className' => 'Newscategory', 'conditions' => '', 'order' => '', 'foreignKey' => 'newscategor y_id' ), 'User' => array(' className' => 'User', 'conditions' => '', 'order' => '', 'foreignKey' => ' user_id' ) ); } ?>
Gambar 4.13. Class Model Home
Pada Model News, asosiasi didefinisikan dengan menggunakan array.
Elemen-elemen array adalah Model lain yang berasosiasi dengan Model News.
Model News memiliki foreign key newscategory_id yang menghubungkannya
dengan Model Newscategory, sedangkan foreign key user_id menghubungkan
Model News dengan Model User. Validasi masukan juga masih tetap digunakan
untuk meminimalisasi kesalahan pada saat memasukkan data.
112
Pada bagian awal class NewsController didefinisikan terlebih dahulu
variabel-variabel class yang kesemuanya merupakan variabel public. Variabel
$components berisi beberapa Component (Controller pendukung) yang akan
digunakan oleh NewsController dan bagian View dari modul News. Variabel
$name menunjukkan nama Controller tersebut. Variabel $layout berisi file layout
yang akan digunakan, dalam hal ini NewsController menggunakan file layout
news.thtml. Variabel $helpers berisi semua Helper yang dibutuhkan oleh
NewsController. Helper adalah sebuah class dari framework CakePHP yang
digunakan untuk mempermudah programmer menampilkan komponen dan tag
HTML pada bagian View dari modul.
<?php class NewsController extends AppController { var $components = array('Pagination','RequestHandler','NewsCategory') ; var $name = 'News'; var $ layout = 'news'; var $helpers = array('Html','Javascript','Time',' Form','Pagination','Fck','Text')
; ... } ?>
Gambar 4.15. Deklarasi variabel class NewsController
Sebagaimana fungsi add() pada modul Home, fungsi add(), main(), view(),
edit(), delete() pada NewsController hanya bisa diakses oleh user tertentu. Sesuai
dengan Tabel 3.4, halaman administrasi modul News bisa diakses oleh semua
user kecuali Guest (pengujung). Fungsi lain yang tidak termasuk fungsi
administrasi, yakni index(), daftar(), detail(), bisa diakses oleh semua user
termasuk Guest. Metode pencocokan session dilakukan dengan meletakkan
113
metode checkSession() di bagian awal fungsi yang akan diproteksi. Apabila semua
user yang memiliki account di sistem diperbolehkan mengakses fungsi, metode
checkSession() tidak perlu ditambah dengan pencocokan session sebagaimana
pada modul Home.
<? .... function edit($id = null){ $this->checkSession(); $this->set('newscategoryArray', $this->News->News category-
>generateList()); if (empty($this->data)) { $this->News->id = $id; $this->data = $this->News->read(); } else { $this->data['News']['user_id'] =
$_SESSION['User']['id']; if ($this->News->save($this->data['News']) ) { $this->flash('Berita telah
terupdate','/news/main'); } else { $this->Session->setFlash('Mohon koreksi ke salahan Anda
!'); } } } .... ?>
Gambar 4.15. Fungsi edit() pada class NewsController
Asosiasi belongs to antara Model News dan Model Newscategory
digunakan untuk menampilkan item-item record tabel newscategories di halaman
News. Class NewsController akan mengambil record dari Model Newscategory
melalui foreign key newscategory_id yang menghubungkan Model News dan
Model Newcategory. Saat kedua Model sudah terhubung, maka hanya dengan
114
menuliskan sintaks sebagaimana terdapat pada Gambar 4.16, record field tertentu
dari tabel newscategories sudah bisa ditampilkan.
$this->set('newscategory Array', $this->News->Newscategory->generateList());
Gambar 4.16. Mengambil record dari field ’name’ tabel newscategories
Hasil dari pengambilan record tersebut bisa dilihat pada Gambar 4.17.
Gambar 4.17. Hasil pengambilan record oleh NewsController
Selain itu, modul News juga dilengkapi dengan fungsi search(). Fungsi ini
digunakan untuk melakukan pencarian record database sesuai dengan kata kunci
yang dimasukkan pada form isian. Fungsi search() pada modul News ini
dimodifikasi sedemikian rupa, sehingga menjadi sebuah fungsi pencarian
langsung (Live Search). Untuk memodifikasi fungsi search() dibutuhkan dua buah
pustaka Javascript, yakni file prototype.js dan file scriptaculous.js, yang berperan
dalam efek animasi tampilan hasil pencarian. Dengan dua pustaka Javascript ini,
hasil pencarian tidak lagi ditampilkan di halaman yang berbeda, akan tetapi
langsung di bawah form isian seketika itu juga saat kata kunci dimasukkan.
Cara kerja fungsi search() ini cukup sederhana. Pertama-tama, fungsi akan
menangkap karakter yang dimasukkan melaui form isian. Setelah karakter tersebut
disimpan dalam sebuah variabel, karakter tersebut dicocokkan dengan seluruh
115
record tabel news. Apabila ada satu atau lebih record yang mengandung karakter
yang sama dengan karakter masukan, maka fungsi akan memberikan hasil.
Apabila tidak ada record yang cocok, fungsi akan memberikan pesan kepada
pengunjung. Fungsi search() ditunjukkan pada Gambar 4.18, sedangkan kode
sumber tampilan pencarian ditunjukkan pada Gambar 4.19.
<? ... function search(){ if (!empty($this->params['form']['livesearch '])) { $word = $this->params['form']['livesearch' ]; $result = $this->News->query("SELECT * FRO M news WHERE
title LIKE '%".$word."%' OR content LIKE '%".$word. "%' ") ; $this->set('result',$result); } } } .... ?>
Gambar 4.18. Fungsi search() pada class NewsController
<?php if (isset($result)&&count($result)>0){ foreach($result as $news) { ?> <div id="result"> <a href="<?php echo $html-
>url('/news/detail/'.$news['news']['id']);?>"> <? echo $news['news']['title'] ; ?> </a> </div> <? } } else { echo '<div>Mohon maaf, kata kunci tidak
ditemukan</div>'; } ?>
Gambar 4.19. Tampilan live search pada bagian View modul News
116
Selain pustaka Javascript, untuk memperindah tampilan disertakan pula
sebuah file gambar loader.gif. File ini akan memberikan kesan “sistem sedang
melakukan proses pencarian” saat pengunjung memasukkan kata kunci pada form
isian. Pada Gambar 4.20 ditunjukkan tampilan Live Search pada saat karakter
huruf ‘p’ dimasukkan pada form isian. Saat karakter ‘p’ ditemukan pada judul dan
isi berita, Live Search akan menampilkan hasilnya tepat di bawah form isian.
Apabila karakter lain dimasukkan, misalnya ‘xi’, dan fungsi search tidak
menemukan record database dengan karakter tersebut, secara otomatis akan
tampil pesan bahwa karakter yang dimasukkan tidak terdapat pada judul dan isi
berita.
Gambar 4.20. Tiga kondisi fitur Live Search
Gambar 4.21 menunjukkan halaman depan modul News yang diakses oleh
pengunjung saat memilih menu ‘news’ pada navigasi utama. Saat modul News
ditampilkan, menu ‘news’ pada navigasi utama akan berubah warna latar
belakangnya.
117
Gambar 4.21. Halaman depan modul News
4.2.2.3 Modul Profile
Sebagaimana Model Home, Model Profile tidak memiliki asosiasi dengan
Model lainnya. Adapun class ProfilesController memiliki beberapa fungsi,
sebagaimana pada class HomeController. Namun demikian, pembatasan akses
user pada halaman administrasi sedikit berbeda. Halaman administrasi modul
Profile bisa diakses oleh user Admin, Lecturer, dan Laboran. Hal ini dilakukan
dengan memberikan filtering setelah pemanggilan fungsi checkSession(), yakni
dengan mencocokkan hak akses user yang saat itu sedang login. Apabila user
tersebut memenuhi kriteria akses yang diperbolehkan, maka user bisa masuk ke
halaman administrasi. Salah satu penerapan filtering ditunjukkan pada fungsi
main() di bawah ini.
<? .... function main() { $this->checkSession();
118
if(($_SESSION['priv'] != '1')&&($_SESSION[' priv'] != '2')&&($_SESSION['priv'] != '3')) {
$this->flash('Restricted Area. Please Contact Y our Admin !','/');
exit(); } $pro file = $this->Pro file->findAll(); $this->set('profile',$pro file); } .... ?>
Gambar 4.22. Fungsi main() pada class ProfilesController
4.2.2.4 Modul Practicum
Modul Practicum merupakan modul dengan jumlah class Model dan
Controller paling banyak apabila dibandingkan dengan modul lainnya.
Pembahasan implementasi kali ini akan difokuskan dengan membahas satu
persatu pasangan class Model-Controller yang terdapat di modul Practicum.
1. Class Practicumname dan PracticumnamesController.
Model Practicumname memiliki asosiasi has many dengan beberapa
Model yang lain, yakni Practicumschedule, Assistant, dan Resource. Hubungan
ini didefinisikan sebagaimana terdapat pada gambar di bawah ini.
<? class Practicumname extends AppModel { ....... var $hasMany = array( 'Practicumschedule' => array(' className' => 'Practicumschedule', 'conditions' => '', 'foreignKey' => 'practicumname_id ', 'order' => 'Practicumschedule.id ASC', 'dependent' => true, 'exclusive' => false ), 'Assistant' =>
119
array(' className' => 'Assistant', 'conditions' => '', 'foreignKey' => 'practicumname_id ', 'order' => 'Assistant.id ASC', 'dependent' => true , 'exclusive' => false ), 'Resource' => array(' className' => 'Resource', 'conditions' => '', 'foreignKey' => 'practicumname_id ', 'order' => 'Resource.id ASC', 'dependent' => true, 'exclusive' => false ) ) ; } ?>
Gambar 4.23. Asosiasi has many pada class Practicumname
Dari Gambar 4.23 tersebut dapat diketahui, bahwa tabel practicumnames
memiliki tiga buah foreign key yang menghubungkannya dengan tabel
practicumschedules, assistants, dan resources. Metode validasi masih digunakan
pada Model Practicumname. Adapun class PracticumnamesController memiliki
dua buah fungsi umum (bisa diakses semua user), yakni index() dan view(), serta
empat buah fungsi administrasi, yakni main(), add(), edit(), dan delete(). Hak
administrasi diberikan hanya pada user Admin dan Laboran.
Class PracticumnamesController mengurusi segala sesuatu yang terkait
dengan tabel practicumnames, seperti menampilkan praktikum yang aktif,
menampilkan profil masing-masing praktikum, manajemen profil praktikum, dan
sebagainya. Praktikum yang aktif dan ditampilkan kepada pengunjung adalah
praktikum yang memiliki flag aktivasi bernilai 1. Flag ini disimpan pada tabel
120
practicumnames. Sistem akan melakukan pengecekan flag sebelum menampikan
daftar praktikum yang aktif, sebagaimana pada Gambar 4.24.
<? .... function index() { $criteria = "Practicumname.activation='1'" ; list($order,$limit,$page) = $this->Paginati on-
>init($criteria); $Practicumnames = $this->Practicumname->findAll($ criteria,
NULL, $order, $limit, $page); $this->set('Practicumnames',$Practicumnames); } .... ?>
Gambar 4.24. Fungsi index() pada class PracticumnamesController
2. Class Practicumschedule dan PracticumschedulesController.
Model Practicumschedule memiliki tiga buah asosiasi, sebagaimana
ditunjukkan pada Gambar 4.25 di bawah ini.
<? ... var $hasAndBelongsToMany = array('Practician' => array(' className' => 'Practician', 'joinTable' => 'practicians_practic umschedules', 'foreignKey' => 'practicumschedule_i d', 'associationForeignKey'=> 'practician_ id', 'conditions' => '', 'order' => '', 'limit' => '', 'uniq' => true, 'finderQuery' => '', 'deleteQuery' => '', 'dependent' => true, 'exclusive' => false ) ); var $belongsTo = array('Practicumname' => array(' className' => 'Practicumname', 'conditions' => '', 'order' => '',
121
'foreignKey' => 'practicumname_id' ) ); var $hasMany = array('Assistant' => array(' className' => 'Assistant', 'conditions' => '', 'foreignKey' => 'practicumschedule_id', 'order' => '', 'dependent' => '' , 'exclusive' => '' ) ) ; ... ?>
Gambar 4.25. Fungsi index() pada class PracticumnamesController
Tabel practicumnames memiliki kardinalitas many to many dengan tabel
practicians dan memerlukan normalisasi. Tabel normalisasi ini didefinisikan pada
Model Practicumschedules melalui asosiasi HABTM (has and belongs to many).
Pada asosiasi tersebut didefinisikan elemen array ‘joinTable’ yang berisi nama
tabel hasil normalisasi. Elemen ‘foreignKey’ merujuk pada field ‘id’ Model ini,
yakni field ‘id’ dari tabel practicumschedules. Elemen ‘associationForeignKey’
merujuk pada field ‘id’ dari tabel yang berasosiasi dengan tabel
practicumschedules, yakni tabel practicians. Elemen ‘uniq’ berisi ‘true’, yang
berarti apabila ada satu atau lebih objek serupa yang memiliki asosiasi sama akan
diabaikan oleh sistem dan hanya akan ditampilkan sekali pada tabel. Dengan
demikian, apabila record serupa dimasukkan lebih dari dua kali pada tabel
asosiasi, akan ditampilkan sekali saja saat array hasil query ditampilkan. Sebagai
contoh, apabila diasumsikan ada lima orang praktikan mengisikan jadwal
praktikum yang sama dan disimpan pada tabel practicians_practicumschedules,
122
saat query dieksekusi hanya akan ditampilkan satu buah jadwal praktikum yang
memiliki anggota lima orang praktikan.
Adapun elemen array ‘dependent’ diberi nilai ‘true’ supaya saat sebuah
record tabel practicumschedules dihapus sekaligus menghapus asosiasi yang ada
pada tabel practicians_practicumschedules. Selain asosiasi HABTM, Model
Practicumschedule juga memiliki asosiasi belongs to terhadap Model
Practicumname dan has many terhadap Model Assistant.
Class PracticumschedulesController mengurusi semua logic yang
berhubungan dengan manajemen jadwal praktikum. Class ini memiliki empat
buah fungsi umum, yakni index(), indexast(), detail(), dan register(). Fungsi
administrasi yang dimiliki oleh class ini berjumlah enam buah, yakni main(),
cetak(), view(), delete(), add(), dan edit().
Sebelum praktikan melakukan pendaftaran, class
PracticumschedulesController akan melakukan pengecekan aktivasi pendaftaran
melalui fungsi index(). Pengecekan dilakukan dengan memeriksa record dari field
‘activation’ yang terdapat di tabel settings. Apabila isi record adalah ‘1’, maka
praktikan bisa melakukan pendaftaran. Sebaliknya, apabila isi record adalah ‘0’,
muncul peringatan bahwa pendaftaran praktikum sudah ditutup. Selain
pengecekan aktivasi pendaftaran praktikan, class ini juga mengurusi pengecekan
aktivasi pendaftaran asisten. Pengecekan aktivasi pendaftaran asisten memiliki
cara kerja yang hampir sama dengan pengecekan aktivasi pendaftaran praktikan,
hanya saja ditempatkan pada fungsi yang berbeda, yakni indexast(). Pemisahan
halaman informasi pendaftaran praktikan dan asisten ini diharapkan akan
123
mempermudah pengunjung menerima informasi seputar pelaksanaan praktikum.
Kode sumber aktivasi pendaftaran praktikan ditunjukkan pada Gambar 4.26 di
bawah ini.
<? .... /* Setting aktivasi pendaftaran praktikan*/ $PraktikanAktif = $this->Practicumschedule->query ("SELECT *
FROM settings WHERE id='1'") ; if($PraktikanAktif['0'][' settings']['activation']=='1'){ $this->set('PraktikanAktif',$PraktikanAktif); } .... ?>
Gambar 4.26. Setting aktivasi pada fungsi index() PracticumschedulesController
Fungsi register() pada PracticumschedulesController mengurusi tampilan
halaman pendaftaran asisten pada masing-masing jadwal praktikum. Fungsi
register() secara otomatis akan menolak pendaftaran asisten baru apabila jumlah
asisten untuk satu jadwal sudah memenuhi quota yang diinginkan pengelola
praktikum. Metode filtering ini dilakukan dengan langkah sebagai berikut :
- menghitung jumlah asisten yang terdaftar dan menyimpan hasilnya pada
sebuah variabel ;
- mengambil informasi quota asisten pada jadwal tersebut dan menyimpan
hasilnya pada sebuah variabel ;
- membandingkan variabel pertama dan variabel kedua. Apabila variabel
kedua lebih besar dari variabel pertama, pendaftaran asisten masih dibuka.
Apabila variabel kedua lebih kecil atau sama dengan variabel pertama,
pendaftran asisten ditutup.
Penjelasan lebih lengkap bisa dilihat pada Gambar 4.27 di bawah ini.
124
<? .... function register($id) { $this->pageTitle = 'Assistant Registration'; $this->cleanUp Fields(); $aktif = $this->Practicumschedule->query("S ELECT * FROM
settings WHERE id='4'") ; //hitung jumlah asisten terdaftar $jumlah= $this->Practicumschedule->query("S ELECT COUNT(*)
FROM assistants WHERE practicumschedule_id='".$id." '") ; //hitung jumlah quota asisten $ quota=$this->Practicumschedule->findById($id); // bandingkan jumlah quota dan jumlah asisten terdaftar
if($ quota['Practicumschedule']['assistant_amount']>$jumlah[' 0']['0']['COUNT(*)']){
if($aktif['0'][' settings']['activation']=='1'){ $Practicumschedule = $this->Practicumsched ule-
>read(null,$id) ; $this->set('Practicumschedule',$Practicums chedule); } else{ $this->Session->setFlash('Mohon maaf, fasilitas registrasi
asisten ditutup'); $this->redirect('/assistants/index/'); } } else{ $this->Session->setFlash('Mohon maaf, asisten pa da jadwal
terpilih sudah memenuhi quota'); $this->redirect('/assistants/index/'); } } .... ?>
Gambar 4.27. Fungsi register() pada PracticumschedulesController
Class PracticumschedulesController juga memiliki fungsi cetak() yang
berfungsi untuk mengubah data MySQL menjadi spreadsheet. Fungsi ini
memanfaatkan file layout excel.thtml yang berisi infomasi header file hasil
125
konversi. Cara kerja fungsi ini cukup sederhana, yakni fungsi akan membaca
record jadwal praktikum berikut asisten dan praktikan yang terdaftar pada jadwal
tersebut. Setelah itu, data akan disimpan pada variabel tertentu dan dikirimkan ke
layout excel.thtml.
function cetak($id) { $this->checkSession(); if(($_SESSION['priv'] != '1')&&($_SESSION[' priv'] !=
'3')){ $this->flash('Restricted Area. Please Contact Yo ur Admin
!','/'); exit(); } $this-> layout='excel'; $data = array(); $data['sheet1'] = $this->Practicumschedule->read( null,$id) ; $this->set('data', $data); }
Gambar 4.27. Fungsi cetak() pada PracticumschedulesController
File layout excel.thtml inilah yang berfungsi sebagai konverter MySQL ke
spreadsheet. File ini akan menyertakan beberapa informasi header, sehingga data
yang dikirim dari Controller akan diolah sedemikian rupa dan diubah dalam
bentuk file berekstensi *.xls (ekstensi data aplikasi Microsoft Excel) yang bisa di-
download melalui browser.
<?php (empty($type)) ? $type = 'applications' : $type = $ type; header("Content-type: application/vnd.ms-excel"); header("Content-Disposition: attachment; filename=data-
praktikum.xls"); header("Pragma: no-cache"); header("Expires: 0"); ?> <?php echo $content_for_ layout ?>
Gambar 4.27. Konverter MySQL ke spreadsheet pada file excel.thml
126
3. Class Practician dan PracticiansController.
Model Practician memiliki asosiasi HABTM dengan Model
Practicumschedule. Definisi asosiasi diletakkan pada class Practician.
Sebagaimana pada Model Practicumschedule, Model Practician memanfaatkan
tabel asosiasi practicians_practicumschedules. Elemen array ‘foreignKey’
merupakan id dari tabel practicians. Elemen array ‘associationForeignKey’
merupakan id dari tabel practicumschedules. Elemen array ‘uniq’ diberi nilai
‘true’ yang berarti record yang sama pada tabel asosiasi hanya akan ditampilkan
sekali saat query dieksekusi.
<? ... var $hasAndBelongsToMany = array('Practicumschedule' => array(' className' => 'Practicumschedule', 'joinTable' => 'practicians_practicu mschedules', 'foreignKey' => 'practician_id', 'associationForeignKey'=> 'practicumsch edule_id', 'conditions' => '', 'order' => '', 'limit' => '', 'uniq' => true, 'finderQuery' => '', 'deleteQuery' => '', 'dependent' => true, 'exclusive' => false ) ); ... ?>
Gambar 4.28. Asosiasi HABTM pada Model Practicumname
Class PracticiansController mengurus segala sesuatu yang terkait dengan
informasi data praktikan dan proses pendaftaran praktikan. Apabila class
PracticumschedulesController menentukan boleh dan tidaknya praktikan
melakukan pendaftaran, maka class PracticiansController menentukan proses
127
masuknya data praktikan ke dalam database pada saat melakukan pendaftaran.
Logic paling rumit dari class PracticiansController terdapat pada fungsi add(),
update(), dan edit().
Pendaftaran praktikum dilakukan secara simultan. Seorang praktikan
hanya boleh mendaftarkan diri satu kali saja dengan memasukkan data-data
praktikum yang ia pilih. Dengan demikian, seorang praktikan bisa mendaftarkan
diri pada satu atau lebih praktikum dalam waktu bersamaan, dengan catatan
masing-masing praktikum hanya boleh diikuti pada satu jadwal pelaksanaan saja.
Implementasi halaman pendaftaran ditunjukkan pada Gambar 4.29 dan Gambar
4.30.
Pada halaman pendaftaran bagian atas, praktikan diminta untuk
mengisikan data akademik yang terdiri dari ‘Nama Praktikan’, ‘Angkatan Masuk’,
dan ‘No. Induk Mahasiswa’. Setelah itu, praktikan mengisikan jadwal praktikum
pada checkbox form pendaftaran praktikum. Masing-masing praktikum hanya
boleh diisi dengan satu buah jadwal. Untuk keperluan itu, elemen HTML
checkbox harus dimodifikasi sedemikian rupa, sehingga checbox hanya boleh
diisi satu saja, untuk praktikum yang sama. Modifikasi ini dilakukan dengan
menggunakan script Javascript.
128
Gambar 4.29. Form isian data praktikan
Gambar 4.29. Form isian jadwal praktikum
Selain itu, form pendaftaran praktikum dilengkapi dengan CAPTCHA
untuk memastikan bahwa user adalah manusia, bukan mesin spam. Validasi ini
129
dilakukan dengan menampilkan deretan karakter di akhir form pendaftaran.
Apabila user tidak memasukkan karakter ini, sistem tidak memasukkan data
praktikan dan pendaftaran harus diulangi kembali.
Gambar 4.30. CAPTCHA pada bagian akhir halaman pendaftaran praktikan
Pada penerapan sistem secara nyata, sangat dimungkinkan dua orang
praktikan atau lebih mendaftarkan diri pada saat yang bersamaan. Untuk
membatasi quota praktikan sesuai dengan ketentuan pelaksana praktikum, sistem
pendaftaran dilengkapi dengan metode Massive Checking yang akan memeriksa
quota praktikan secara real time, tepat pada saat praktikan menekan tombol
‘Save’ setelah memasukkan data pendaftaran. Sistem ini akan memeriksa record
pada database, membandingkan quota praktikan dan jumlah praktikan yang sudah
terdaftar. Apabila pada saat bersamaan ada dua orang atau lebih praktikan yang
mendaftar praktikum, seketika itu juga sistem akan melakukan filtering dan
130
menampilkan informasi apabila jumlah praktikan sudah melampaui batas.
Praktikan yang terkena filtering harus memilih jadwal lainnya yang masih kosong,
untuk praktikum yang sama. Kode program Massive Checking diletakkan di
dalam fungsi add() dan ditunjukkan pada Gambar 4.31.
<? ..... function add() { ...... /*massive checking untuk memeriksa quota apabila ada pendaftar
yang mendaftar bersamaan : */ for($x=0;$x<sizeof($this-
>params['data']['Practicumschedule']['Practicumsche dule']);$x++){
$id = $this->params['data']['Practicumschedule']['Practicumsche dule'][$x];
$jumlah[$x] = $this->Practician->query("SELECT COUNT(*) FROM practicians_practicumschedules WHERE practicumschedule_id='".$id."'") ;
$quota[$x] = $this->Practician->query("SELECT practician_amount FROM practicumschedules WHERE id= '".$id."'") ;
if($jumlah[$x]['0']['0']['COUNT(*)']>=$quota[$x][' 0']['practicumschedules']['practician_amount']){
$this->flash('ERROR : Mohon ulangi pendaftaran karena salah satu jadwal yang Anda pilih sudah penuh','/practicians/add');
exit(); } } /* end massive checking */ ...... } /*akhir fungsi pendaftaran*/ ..... ?>
Gambar 4.31. Massive Checking pada PracticiansController
Halaman update data praktikan diatur dengan kebijaksanaan pengelola
praktikum, dalam hal ini laboran. Apabila laboran menghendaki praktikan untuk
melakukan perbaikan data secara manual (dilakukan sendiri oleh praktikan),
131
laboran bisa mengaktifkan fitur update data supaya memungkinkan untuk diakses
praktikan. Halaman update data, meskipun menerapkan Massive Checking, tidak
menerapkan pembatasan elemen HTML checkbox, sebagaimana pada halaman
pendaftaran. Hal ini ditujukan untuk mempermudah laboran dan praktikan
melakukan koreksi data pendaftaran praktikum. Halaman update data juga
dilengkapi dengan link khusus untuk melihat jadwal praktikum yang masih
kosong. Implementasi halaman update data ditunjukkan pada Gambar 4.32 di
bawah ini.
Gambar 4.31. Form update data praktikan
132
4. Class Assistant dan AssistantsController.
Model Assistant memiliki asosiasi belongs to terhadap Model
Practicumname dan Practicumschedule. Asosiasi ini didefinisikan dengan array,
sebagaimana ditunjukkan pada Gambar 4.32 di bawah ini.
<? .... var $belongsTo = array( 'Practicumname' => array(' className' => 'Practicumname', 'conditions' => '', 'order' => '', 'foreignKey' => 'practicumna me_id' ), 'Practicumschedule' => array(' className' => 'Practicumschedule', 'conditions' => '', 'order' => '', 'foreignKey' => 'practicumsc hedule_id' ) ); .... ?>
Gambar 4.32. Asosiasi belongs to pada Model Assistant
Adapun class AssistantsController memiliki dua buah fungsi umum dan
enam buah fungsi administrasi. Fungsi umum ini adalah fungsi index() dan fungsi
add(). Fungsi add() mengurusi logic pendaftaran asisten. Apabila fungsi register()
yang terdapat pada class PracticumschedulesController mengurusi tampilan
halaman pendaftaran asisten, fungsi add() dieksekusi saat proses penyimpanan
data asisten ke database. Pendaftaran asisten dibatasi satu asisten untuk satu
praktikum saja. Asisten tidak diperkenankan untuk mendaftarkan diri lebih dari
satu kali di laboratorium yang sama. Halaman pendaftaran asisten, sebagaimana
halaman pendaftaran praktikan, dilengkapi dengan CAPTCHA.
133
4.2.2.5 Modul Resource
Model Resource memiliki asosiasi belongs to terhadap tiga buah Model
yang lain, yakni Model User, Model Practicumname, dan Model Project. Asosiasi
didefinisikan dengan menggunakan array pada class Resource sebagaimana
ditunjukkan pada Gambar 4.33 di bawah ini.
<? ... var $belongsTo = array( 'User' => array(' className' => 'User', 'conditions' => '', 'order' => '', 'foreignKey' => ' user_id' ), 'Practicumname' => array(' className' => 'Practicumname', 'conditions' => '', 'order' => '', 'foreignKey' => 'practicumna me_id' ), 'Project' => array(' className' => 'Project', 'conditions' => '', 'order' => '', 'foreignKey' => 'project_id' ) ); .... ?>
Gambar 4.33. Asosiasi belongs to pada Model Resource
Fungsi add() pada class ResourcesController, selain melakukan upload
data berupa string juga berupa file resource. Jenis resource yang di-upload adalah
file Ms.Word, Ms.Excel, Ms.Power Point, PDF, Archive (zip atau rar), dan file
yang tidak termasuk lima kategori sebelumnya. Secara default, CakePHP
membatasi batas maksimum upload sebesar 8 MB. Namun batasan ini bisa
diperbesar, dengan cara melakukan modifikasi pada file basics.php yang terletak
134
di folder cake/. Fungsi add() secara lengkap ditampilkan pada gambar di bawah
ini.
<? .... function add(){ $this->checkSession(); $this->set('practicumArray', $this->Resource->Pra cticumname-
>generateList()); $this->set('projectArray', $this->Resource->Proje ct-
>generateList()); if (!empty($this->data)) { $this->data['Resource'][' user_id'] =
$_SESSION['User']['id']; if ($this->Resource->save($this->data)) { $this->my Folder = new Folder(); $this->my Folder-
>mkdirr(WWW_ROOT.DS.' upload'.DS.' resource'.DS.$this->Resource->getLastInsertId(),0777);
$this->my Folder->mkdirr(WWW_ROOT.DS.' upload'.DS.' resource'.DS.$this->Resource->getLastInsertId().DS." file",0777);
copy(WWW_ROOT.DS."house".DS.".htaccess",WWW_ROOT.D S.' upload'.DS.' resource'.DS.$this->Resource->getLastInsertId().DS." file".DS.".htaccess");
move_uploaded_ file($_ FILES["data"]["tmp_name"][" File"][' file'], WWW_ROOT.DS.' upload'.DS.' resource'.DS.$this->Resource->getLastInsertId().DS." file".DS.$_ FILES["data"]["name"][" File"][' file']);
$this->flash('Resource Anda telah tersimpan.','/resources/index');
} else { $this->Session->setFlash('Mohon koreksi ke salahan Anda
!'); } } }
Gambar 4.34. Fungsi add() pada ResourcesController
Pada fungsi add(), saat sistem menyimpan data resource, fungsi akan
membuat direktori baru dengan nomer id item data yang disimpan. Jadi saat, data
135
nomer 13 disimpan, sistem akan membuat folder baru dengan nama 13. CakePHP
memanfaatkan fungsi mkdir() untuk pembuatan direktori. Pada akhir fungsi,
dimasukkan parameter 0777, yang akan mengubah hak akses direktori tersebut
supaya bisa diakses oleh sistem (hanya berlaku apabila iLab dijalankan pada
sistem operasi berbasis Unix). Di dalam direktori tersebut, dibuat lagi sebuah
direktori dengan nama ‘file’. Setelah itu, sistem akan mengopikan sebuah
file .htaccess ke dalam folder ‘file’. File .htaccess ini berisi script yang
memungkinkan file resource yang berada di dalam folder tersebut diakses oleh
sistem. Setelah itu, sistem akan meng-upload file resource ke dalam folder ‘file’.
Dengan demikian, struktur folder penyimpanan resource tersebut sebagai berikut :
app/webroot/upload/[nomer id item]/file/[file resource] .
Pada saat menghapus resource, sistem juga mengekseskusi sebuah fungsi
yang bertugas menghapus folder tempat penyimpanan resource tersebut. Fungsi
ini adalah fungsi rdel(). Fungsi ini secara recursive (menyeluruh) akan menghapus
folder dan seluruh isi folder penyimpanan resource saat sistem mengeksekusi
fungsi delete(). Pemanggilan fungsi rdel() di dalam fungsi delete() ditunjukkan
pada gambar di bawah ini.
<? .... function delete($id) { $this->checkSession(); $this->Resource->del($id); $this->rdel(WWW_ROOT.' upload'.DS.' resource'.DS.$id); $this->flash('Resource dengan ID : '.$id.' ter hapus.',
'/ resources/index'); } function rdel($path) { $this->checkSession(); $this->my Folder2 = new Folder(); if(@opendir($path))
136
{ $this->my Folder2->path=$path; $ files = $this->my Folder2->findRecursive(); foreach($ files as $ file) un link($ file); @rmdir($path.DS."thumbnail"); @rmdir($path.DS." file"); @rmdir($path); } } .... ?>
Gambar 4.35. Fungsi delete() dan rdel() pada ResourcesController
Modul Resource membagi resource menjadi tiga kategori. Kategori
pertama adalah resource praktikum. Resource praktikum adalah segala kebutuhan
pendukung praktikum, termasuk modul dan bahan praktikum. Kategori kedua
adalah resource proyek. Resource proyek ini berupa hasil riset yang dilakukan di
laboratorium tersebut. Kategori ketiga adalah resource lain, yang tidak termasuk
pada dua kategori sebelumnya.
Gambar 4.36. Halaman depan modul Resource
137
Modul Resource menyediakan halaman detail informasi sekaligus link
download resource tersebut. Apabila pengunjung mengakses link tersebut, secara
otomatis browser akan menampilkan pilihan untuk menyimpan atau membuka file
yang di-download, sebagaimana ditunjukkan pada gambar di bawah ini. Gambar
4.37 dibuat saat modul Resource diakses dengan browser Mozilla Firefox.
Gambar 4.37. Pilihan yang muncul saat link download diakses
4.2.2.6 Modul Project and Research
Modul Project and Research adalah modul yang menangani informasi
proyek dan penelitian yang sedang dikerjakan di laboratorium. Bagian Model dari
modul ini memiliki dua buah asosiasi, yakni belongs to terhadap Model User dan
has many terhadap Model Resource. Kode sumber definisi asosiasi Model Project
dapat dilihat pada gambar di bawah ini.
138
<? .... var $belongsTo = array( 'User' => array(' className' => 'User', 'conditions' => '', 'order' => '', 'foreignKey' => ' user_id' ) ); var $hasMany = array( 'Resource' => array(' className' => 'Resource', 'conditions' => '', 'foreignKey' => 'project_id', 'order' => 'Resource.id ASC', 'dependent' => true, 'exclusive' => false ) ); .... ?>
Gambar 4.38. Asosiasi pada Model Project
Class ProjectsController memiliki dua buah fungsi umum dan lima buah
fungsi administratif. Fungsi umum terdiri dari fungsi index() dan detail(). Fungsi
administrasi terdiri dari fungsi main(), view(), add(), delete(), dan edit(). Fungsi
administrasi ini bisa diakses oleh semua user kecuali Guest. Pada saat diakses,
Modul Project and Research akan menampilkan daftar proyek dan penelitian yang
sedang berlangsung di laboratorium tersebut. Pengunjung bisa melihat penjelasan
lebih lanjut dari penelitian atau proyek yang ada dengan mengakses ke halaman
detail keterangan proyek atau penelitian. Tampilan halaman detail ini ditunjukkan
oleh Gambar 4.39.
139
Gambar 4.39. Antarmuka halaman detail proyek dan riset
4.2.2.7 Modul Guestbook
Model Guestbook tidak memiliki asosiasi dengan Model lainnya. Untuk
menjamin validitas data yang dimasukkan, termasuk alamat email, Model
Guestbook menyertakan array validasi. CakePHP menyediakan parameter khusus
untuk validasi alamat email, yakni dengan mengisikan ‘VALID_EMAIL’ pada
elemen array ‘email’. Secara otomatis, CakePHP akan melakukan validasi alamat
email yang dimasukkan oleh pengunjung.
<?php class Guestbook extends App Model { var $name = 'Guestbook'; var $useTable = 'Guestbooks'; // validasi array yang masuk var $validate = array( 'name' => VALID_NOT_EMPTY,
140
'email' => VALID_EMAIL, 'comment' => VALID_NOT_EMPTY ); } ?>
Gambar 4.40. Model Guestbook
Adapun GuestbookController memiliki dua buah fungsi umum dan empat
buah fungsi administrasi. Fungsi umum add() digunakan untuk menambah isi
buku tamu, sedangkan fungsi umum all() digunakan untuk menampilkan semua
komentar yang masuk ke buku tamu. Fungsi administrasi terdiri dari fungsi
index(), view(), delete(), dan edit(). Modul Guestbook menyertakan CAPTCHA
untuk memastikan komentar berasal dari pengunjung, bukan mesin spam.
Implementasi halaman komentar buku tamu ditunjukkan pada gambar di bawah
ini.
Gambar 4.41. Antarmuka halaman komentar buku tamu
141
4.2.2.8 Modul Link
Model Link tidak memiliki asosiasi dengan Model lainnya. Class
LinksController mengurusi segala sesuatu yang berhubungan dengan administrasi
dan manajemen referensi online yang akan ditampilkan. Implementasi
LinksController tidak jauh berbeda dengan implemetasi class Controller lainnya.
Adapun secara umum, class LinksController memiliki satu buah fungsi umum dan
lima buah fungsi administratif. Fungsi umum terdiri dari fungsi index() yang
memungkinkan untuk diakses oleh semua user. Fungsi administrasi terdiri dari
fungsi main(), view(), add(), delete(), dan edit(). Implementasi antarmuka modul
Link ditunjukkan pada gambar di bawah ini.
Gambar 4.42. Antarmuka halaman link dan referensi
142
4.2.2.9 Modul User
Modul User terdiri atas dua pasangan class Model-Controller sebagai
berikut :
1. Class User dan UsersController
Class User adalah bagian Model dari pasangan class ini. Model User
memiliki asosiasi belongs to terhadap Model Userstatus. Foreign key yang
menghubungkan Model User dan Userstatus adalah ‘userstatus_id’.
<? .... var $belongsTo = array('Userstatus' => array(' className' => 'Userstatus', 'conditions' => '', 'order' => '', 'foreignKey' => ' userstatus_id' ) ); .... ?>
Gambar 4.43. Asosiasi belongs to pada Model User
Adapun UsersController hanya memiliki fungsi administratif saja, yakni
index(), delete(), add(), dan edit(). Semua fungsi administrasi hanya boleh diakses
oleh Admin. Pada bagian fungsi add(), password yang dimasukkan saat
pembuatan user baru akan dienkripsi dengan fungsi md5(). Enkripsi password ini
dilakukan untuk meningkatkan keamanan password yang tersimpan pada
database. Kode sumber fungsi add() secara lengkap dapat dilihat pada gambar di
bawah ini.
<? .... function add() { $this->checkSession();
143
if($_SESSION['priv'] != '1'){ $this->flash('Restricted Area. Please Contact Yo ur Admin
!','/'); exit(); } $this->set(' userstatus Array', $this->User->Userstatus-
>generateList()); if (!empty($this->data)) { $this->data['User'][' password']=md5($this-
>data['User'][' password']); if ($this->User->save($this->data)) { $this->flash('User tersimpan.','/ users'); } else { $this->Session->setFlash('Mohon koreksi ke salahan Anda
!'); } } } ... ?>
Gambar 4.44. Fungsi add() pada UsersController
2. Class Userstatus dan UserstatusesController
Model Userstatus memiliki asosiasi has many terhadap Model User.
Foreign key yang menghubungkan Model Userstatus dengan Model User adalah
‘userstatus_id’. Asosiasi ini ditunjukkan pada Gambar 4.45. Elemen array
‘dependent’ berisi parameter ‘true’ yang berarti apabila salah satu record tabel
userstatuses dihapus, maka semua record pada tabel users yang berasosiasi
dengan record tersebut akan dihapus. Sebagai contoh, apabila record ‘Admin’
dihapus dari tabel userstatuses, maka semua user dengan hak akses ‘Admin’ pada
tabel users akan terhapus. Elemen array ‘exclusive’ diberi nilai ‘false’. Apabila
elemen ini diberi nilai ‘true’, maka semua objek yang memiliki asosiasi dengan
Model ini akan dihapus dengan sebuah perintah SQL saja. Konfigurasi ini bisa
144
digunakan untuk asosiasi sederhana yang melibatkan banyak Model karena
memudahkan manajemen record database.
<? .... var $hasMany = array ( 'User' => array ( ' className' => 'User', 'conditions' => '', 'foreignKey' => ' userstatus_id', 'order' => 'User.id ASC', 'dependent' => true, 'exclusive' => false ) ) ; .... ?>
Gambar 4.45. Asosiasi pada Model Userstatus
Class UserstatusesController hanya memilik dua buah fungsi administrasi,
yang kesemuanya hanya bisa diakses oleh Admin. Fungsi administrasi tersebut
adalah fungsi index() dan edit(). Pada saat iLab di-install, isi record dari tabel
userstatuses sudah disertakan sehingga UserstatusesController tidak menyertakan
fungsi add() maupun delete().
4.2.2.10 Modul Setting
Model Setting tidak memiliki asosiasi dengan Model lainnya. Class
SettingsController hanya memiliki dua buah fungsi administrasi yang bisa diakses
oleh Admin dan Laboran, yakni fungsi index() dan edit(). Modul Setting ini berisi
beberapa konfigurasi kecil yang dibutuhkan oleh sistem, terutama aktivasi yang
berhubungan dengan manajemen praktikum secara umum. Record dari tabel
settings sudah disertakan saat iLab di-install.
145
4.2.3 Modul Tambahan
4.2.3.1 Modul Login
Modul Login memiliki class Model dan Controller. Selain itu, modul ini
juga memanfaatkan fungsi checkSession() yang didefinisikan di file
app_controller.php. Pada bagian Model, modul login menggunakan variabel
khusus karena tidak memiliki tabel basis data. Variabel $useTable diberi nilai
‘false’ karena Model Login sama sekali tidak menggunakan tabel.
<?php class Login extends App Model { var $name = 'Login'; var $useTable = false; } ?>
Gambar 4.46. Model Login
Class LoginsController berisi tiga buah fungsi, yakni fungsi captcha(),
login(), dan logout(). Fungsi login() memiliki mekanisme kerja sebagai berikut :
- Cek data masukan (username dan password). Apabila data kosong,
tampilkan pesan kesalahan dan gagalkan login ;
- Apabila data diisikan, cek apakah data yang diisikan sesuai record
pada tabel users. Apabila data tidak sesuai, tampilkan pesan kesalahan
dan gagalkan login. Apabila data benar, lanjutkan proses login ;
- Cek apakah karakter CAPTCHA benar. Apabila benar, lanjutkan
proses login. Apabila salah, tampilkan pesan kesalahan dan gagalkan
login ;
146
- Setelah validasi berhasil, tuliskan level akses pada parameter variabel
session, sesuai dengan level akses yang telah didefinisikan pada record
user tersebut. Level akses inilah yang akan divalidasi saat user
mengakses halaman administrasi modul-modul lainnya ;
- Arahkan user ke halaman menu administrasi.
Adapun fungsi logout() berfungsi untuk menghapus session lama dan
menuliskan session baru yang berupa session kosong. Fungsi captcha() digunakan
untuk menampilkan karakter CAPTCHA pada halaman login.
4.2.3.2 Modul Installer
Modul Installer tidak memiliki Model. Modul ini terdiri dari sebuah file
Controller dan beberapa file pendukung yang terletak di folder
app/webroot/installation/. Adapun proses instalasi CMS iLab menggunakan
prosedur sebagai berikut :
- Saat CMS iLab diakses pertama kali, sistem akan melakukan pengecekan
apakah file database.php sudah terbentuk. Apabila file sudah ada,
lanjutkan ke tahap instalasi sampel database. Apabila file tidak ada, sistem
akan mengakses file pendukung modul Installer. File pendukung ini akan
melakukan proses pembentukan file database.php berdasarkan data
konfigurasi server database yang dimasukkan user. Proses pembuatan file
database.php ini ditunjukkan pada gambar di bawah ini.
147
Gambar 4.47. Proses pembuatan file database.php
- Setelah file database.php terbentuk, tahap berikutnya adalah instalasi
sampel database. Pada tahap ini, sistem akan mengakses class
InstallerController. Pada tahapan ini, hal pertama yang dilakukan adalah
melakukan pengecekan keberadaan file installed.txt yang dibentuk oleh
fungsi thanks() apabila sampel database sudah terpasang sebelumnya.
Apabila file installed.txt sudah ada, aplikasi iLab sebenarnya sudah
berjalan dengan normal dan tahap instalasi dinyatakan selesai. Apabila
belum, maka tahap instalasi sampel database dimulai ;
- Instalasi sampel database dilakukan dengan membaca dan mengekstrak
file ilab.sql yang ada di folder app/webroot/installation/. Eksekusi file
ilab.sql dilakukan oleh fungsi __executeSQLScript(). Fungsi ini
ditunjukkan pada Gambar 4.48 ;
148
- Apabila semua proses sudah dilakukan, fungsi thanks() akan membuat
file installed.txt di dalam folder app/tmp/ yang menginformasikan bahwa
sistem sudah terinstalasi dengan baik. Proses instalasi selesai.
function __executeSQLScript($db, $ fileName) { $statements = file_get_contents($ fileName); $statements = explode(';', $statements); foreach ($statements as $statement) { if (trim($statement) != '') { $db->query($statement); } } }
Gambar 4.48. Fungsi __executeSQLScript()
4.3 Pengujian Sistem
4.3.1 Metode Pengujian
Pengujian terhadap aplikasi dilakukan untuk menguji apakah modul
berfungsi sesuai yang diharapkan. Dengan adanya pengujian, diharapkan bug
(kelemahan dan kesalahan) dalam aplikasi berkurang. Pengujian sistem dilakukan
dengan tiga metode, yakni :
1. Pengujian Antarmuka. Pengujian antarmuka aplikasi dilakukan dengan
menjalankan aplikasi pada beberapa browser terkemuka yang sering
digunakan oleh pengguna untuk mengakses internet. Pengujian antarmuka
ini dilakukan untuk menguji dukungan browser terhadap validitas program
dan pustaka pendukung yang digunakan oleh aplikasi.
2. Pengujian instalasi sistem. Pengujian instalasi sistem dilakukan dengan
mengimplementasikan sistem pada tiga buah sistem operasi berbeda dan
149
mengoperasikannya, baik melalui jaringan lokal laboratorium maupun
jaringan intranet kampus.
3. Interaksi user dan sistem. Pengujian ini menunjukkan respon pengguna
terhadap aplikasi CMS iLab. Pengujian dilakukan dengan mengedarkan
lembar quesioner kepada beberapa orang tim penguji yang terdiri dari
laboran, tim admin laboratorium, dan pengguna (praktikan dan asisten).
Pengujian dilaksanakan di dua buah laboratorium Jurusan Teknik Elektro,
yakni Laboratorium Informatika (lantai 2) dan Laboratorium Teknik
Tenaga Listrik III (lantai 1).
4.3.2 Pengujian Antarmuka
Pengujian antarmuka dilakukan dengan menjalankan CMS iLab melalui
empat buah browser yang berbeda, yakni Internet Explorer 6, Mozilla Firefox
2.0.0.6, Opera 9.0.2 dan Safari 2.0.4. Hasil pengujian dijelaskan melalui tabel di
bawah ini.
150
Saf
ari
Men
duku
ng
Bel
um s
empu
rna
Mod
ul iB
row
ser
pada
T
inyM
CE
tida
k be
rfun
gsi
Men
duku
ng
Men
duku
ng
1, 2
8 de
tik
Ope
ra
Men
duku
ng
Men
duku
ng
Mod
ul iB
row
ser
pada
T
inyM
CE
tida
k be
rfun
gsi
Men
duku
ng
Men
duku
ng
1,30
det
ik
Moz
illa
Fire
fox
Men
duku
ng
Men
duku
ng
Men
duku
ng (
sem
ua
mod
ul b
erja
lan
norm
al)
Men
duku
ng
Men
duku
ng (
berja
lan
deng
an b
aik)
2, 7
3 de
tik
Inte
rnet
Exp
lore
r
Men
duku
ng
Men
duku
ng
Men
duku
ng (
sem
ua
mod
ul b
erja
lan
norm
al)
Men
duku
ng
Bel
um s
empu
rna
2,09
det
ik
Bro
wse
r P
engu
jian
Duk
unga
n te
rhad
ap
XH
TM
L
Duk
unga
n te
rhad
ap p
usta
ka
Java
scrip
t sec
ara
umum
Duk
unga
n te
rhad
ap p
usta
ka
Tin
y M
CE
pad
a el
emen
text
ar
ea
Duk
unga
n te
rhad
ap p
usta
ka
AJA
X
Duk
unga
n te
rhad
ap C
SS
Par
sing
hal
aman
dal
am d
etik
(u
ntuk
hal
aman
aw
al /
Mod
ul
Hom
e).
No.
1.
2.
3.
4.
5.
6.
Tab
el 4
.1 H
asi
l pen
gu
jian
an
tarm
uka
151
Hasil pengujian yang ditampilkan pada Tabel 4.1 menunjukkan CMS iLab
secara umum berjalan dengan baik pada saat diakses dengan browser yang
berbeda. Namun demikian dari segi antarmuka dan tampilan, CMS iLab belum
bisa mengakomodasi seluruh browser. Beberapa browser tertentu, seperti Safari
dan Opera, tidak berhasil mem-render modul iBrowser pada pustaka TinyMCE.
Modul iBrowser berperan saat user CMS akan meng-upload dan meletakkan
gambar pada editor teks. Sebaliknya, Internet Explorer dan Mozilla Firefox
berhasil mem-render tampilan modul iBrowser dan menjalankannya dengan baik.
Masing-masing browser memiliki kecepatan yang berbeda saat melakukan
rendering tampilan modul Home. Dari hasil pengujian dapat dilihat bahwa Safari
me-render tampilan paling cepat dibandingkan dengan browser lainnya. Browser
Mozilla Firefox, meskipun memiliki dukungan yang baik terhadap aplikasi,
menempati urutan terakhir pada pengujian kecepatan rendering halaman web.
Internet Eksplorer, browser yang ter-install secara default pada sistem operasi
Microsoft Windows menempati urutan keempat pada pengujian kecepatan
rendering halaman web.
Dengan demikian CMS iLab berjalan sempurna pada browser Mozilla
Firefox, meskipun memerlukan waktu rendering halaman lebih lama
dibandingkan dengan browser lainnya. Penggunaan browser Mozilla Firefox
direkomendasikan untuk menjamin semua fungsionalitas aplikasi berjalan dengan
baik.
152
4.3.3 Pengujian Instalasi Sistem
Pengujian instalasi sistem dilakukan dengan mengimplementasikan CMS
iLab pada tiga buah sistem operasi yang berbeda, yakni Microsoft Windows XP
Service Pack II, Ubuntu Linux 6.0, dan OpenBSD 3.9 . Selain instalasi, pengujian
juga meliputi jalannya sistem secara keseluruhan.
4.3.3.1 Implementasi pada sistem operasi Microsoft Windows
Pengujian CMS iLab pada sistem operasi Microsoft Windows tidak
mengalami banyak hambatan. Hal ini banyak dipengaruhi oleh karakteristik
Windows yang tidak memperhatikan hak akses folder dan file, sebagaimana pada
Unix dan Linux. Hasil pengujian ditunjukkan oleh Tabel 4.2 di bawah ini.
Tabel 4.2 Implementasi CMS iLab pada Microsoft Windows XP
Nama Sistem Operasi Microsoft Windows XP Service Pack II
Spesifikasi Mesin Intel P III 700 MHz, RAM 256 MB, Hard disk 60 GB
Spesifikasi Environment PHP 5.0.1 , Apache 1.3.31, MySQL 3.23.57
URL http://192.168.0.1/ilab/
Path Absolut D:\www\ilab
Metode Instalasi Menggunakan script installer
Komentar Instalasi iLab di windows berjalan lancar, dengan asumsi
semua persyaratan sudah dipenuhi oleh Apache Web
Server. Instalasi iLab di server windows tidak terlalu
bermasalah karena Windows tidak terlalu memperhatikan
hak akses. Pada instalasi windows, script download iLab
bisa berjalan dengan baik.
Masalah Plugins iBrowser untuk upload gambar tetap harus
disesuaikan secara manual dengan path absolut instalasi
153
Gambar 4.49. CMS iLab berjalan pada sistem operasi Microsoft Windows
4.3.3.2 Implementasi pada sistem operasi Ubuntu Linux
Sebagaimana implementasi sebelumnya, instalasi iLab pada sistem operasi
Ubuntu Linux tidak mengalami kendala banyak selain beberapa proses
pengubahan hak akses direktori supaya bisa diakses oleh sistem. Instalasi iLab
pada Ubuntu Linux dilaksanakan dengan mengonfigurasi direktori iLab sebagai
Document_Root yang akan diakses oleh Apache Web Server sebagai direktori
default untuk semua aplikasi web di server tersebut.
Tabel 4.3 Implementasi CMS iLab pada Ubuntu Linux 6.0
Nama Sistem Operasi Ubuntu Linux 6.0
Spesifikasi Mesin Intel P IV 2,8 GHz, RAM 256 MB, Hard disk 40 GB
Spesifikasi Environment PHP 4.4.2 , Apache 2.0 , MySQL 5.0.22
URL http://172.16.11.110/ilab/
Path Absolut /var/www/ilab
154
Metode Instalasi Menggunakan script installer
Komentar Instalasi CMS iLab pada sistem operasi Ubuntu Linux
berjalan dengan baik, menggunakan script installer , dengan
asumsi direktori iLab sebagai Document_Root yang akan
diakses Apache Web Server. Beberapa direktori perlu
diubah hak aksesnya, supaya bisa diakses oleh sistem.
Selain itu, penggunaan file .htaccess harus benar-benar
diperhatikan karena harus mempertimbangkan pula hak
akses direktori.
Masalah Plugins iBrowser untuk upload gambar tetap harus
disesuaikan secara manual dengan path absolut instalasi
Gambar 4.50. CMS iLab berjalan pada sistem operasi Ubuntu Linux
155
4.3.3.3 Implementasi pada sistem operasi OpenBSD
Instalasi CMS iLab pada sistem operasi OpenBSD 3.9 mengalami sedikit
kendala karena beberapa konfigurasi server yang cukup berbeda dengan sistem
operasi lainnya. Kendala tersebut terkait dengan konfigurasi direktori
Document_Root yang diletakkan di bawah direktori masing-masing user,
meskipun alokasi direktori tersebut tetap di dalam direktori /var/www, sehingga
memiliki path lengkap /var/www/<direktori user>/public_html/ilab. Untuk
mengatasi hal tersebut, dilakukan metode instalasi yang serupa dengan
implementasi pada sistem operasi Ubuntu Linux, yakni dengan membuat direktori
iLab sebagai Alias yang akan diakses oleh Apache Web Server sebagai direktori
dengan status sejajar Document_Root .
Tabel 4.4 Implementasi CMS iLab pada OpenBSD 3.9
Nama Sistem Operasi OpenBSD 3.9
Spesifikasi Mesin Intel Pentium/MMX ("GenuineIntel" 586-class) 233 MHz
RAM 128 MB, Hard disk 40 GB
Spesifikasi Environment PHP 5.0.5 , Apache 1.3.29 , MySQL 5.0.18
URL http://172.16.11.234/sunu/
Path Absolut /var/www/sunu
Metode Instalasi Instalasi manual
Komentar Instalasi manual dilakukan dengan membuat sendiri file
database.php melalui editor teks Vi, serta melakukan
instalasi sampel database melalui phpMyadmin. Beberapa
direktori harus diubah hak aksesnya supaya bisa diakses
oleh sistem.Penggunaan file .htaccess benar-benar
diperhatikan karena pertimbangan hak akses direktori.
156
Masalah Plugins iBrowser untuk upload gambar tetap harus
disesuaikan secara manual dengan path absolut instalasi
Gambar 4.51. CMS iLab berjalan pada sistem operasi OpenBSD
4.3.3.4 Rekomendasi Metode Instalasi
Implementasi instalasi pada tiga buah sistem operasi dengan karakteristik
yang berbeda menunjukkan perlunya penanganan yang berbeda pula. Pada sistem
operasi dengan konfigurasi khusus, sebagaimana sistem operasi OpenBSD 3.9,
instalasi iLab harus dilakukan secara manual (tidak menggunakan script installer ).
Instalasi dan konfigurasi dilakukan secara manual karena beberapa direktori
memiliki hak akses yang hanya bisa diubah oleh user ‘root’ dari sistem. Dengan
demikian, pengubahan hak akses direktori mutlak diperlukan supaya direktori
tersebut bisa diakses oleh sistem, dalam hal ini oleh server HTTPD (HTTP
Daemon atau Apache Web Server). Implementasi iLab pada sistem operasi
Ubuntu Linux dan Open BSD mengharuskan konfigurasi ulang Apache Web
157
Server. Beberapa hal yang menjadi syarat utama agar CMS iLab bisa berjalan
dengan baik yakni :
1. Modul mod_rewrite harus aktif karena secara default framework CakePHP
menggunakan mod_rewrite untuk mengakses seluruh direktori yang ada di
dalamnya.
2. Pustaka GD Library (untuk rendering gambar) dan XSLT (untuk
rendering file spreadsheet) harus diaktifkan pada instalasi PHP.
3. Penggunaan file .htaccess diperbolehkan.
4. Direktori app/config harus bisa diakses oleh sistem. Dengan demikian,
harus diubah terlebih dahulu hak aksesnya menjadi 755 atau 777 dengan
perintah chmod melalui command prompt atau konsole. Hal ini mutlak
diperlukan apabila iLab diimplementasikan pada server dengan sistem
operasi Unix dan Linux.
5. Konfigurasi modul / plugins iBrowser pada pustaka TinyMCE dilakukan
secara manual dengan menyesuaikan path absolut instalasi iLab di server
tersebut.
6. Pada beberapa kondisi tertentu, metode instalasi secara manual tetap
diperlukan untuk menjamin CMS iLab berjalan dengan baik.
Apabila Admin ingin mengimplementasikan CMS iLab sebagai aplikasi utama
pada server, sebaiknya dilakukan dengan membuat Alias untuk memastikan
direktori Document_Root tetap bisa digunakan. Konfigurasi iLab sebagai Alias
bisa dilakukan dengan cara sebagai berikut :
158
1. Pada konfigurasi Apache (terletak di file httpd.conf), tambahkan kode
program berikut ini.
Alias /ilab "/path/absolut/ke/instalasi/ilab/app/we broot" <Directory "/path/absolut/ke/instalasi/ilab/app/web root"> Options Indexes FollowSymLinks Includes AllowOverride All #Order allow,deny Allow from all </Directory>
Gambar 4.52. Konfigurasi pada Apache Web Server
2. Pada file app/webroot/.htaccess, tambahkan kode program di bawah ini.
RewriteBase /ilab
Gambar 4.53. Konfigurasi tambahan pada file .htaccess
Sehingga secara lengkap akan tertulis sebagai berikut :
<IfModule mod_rewrite.c> RewriteEngine On RewriteBase /ilab RewriteCond %{REQUEST_ FILENAME} !-d RewriteCond %{REQUEST_ FILENAME} !-f RewriteRule ^(.*)$ index.php?url=$1 [QSA,L] </IfModule>
Gambar 4.54. Konfigurasi lengkap pada file .htaccess
3. Pada file app/webroot/index.php, ubah parameter dari variabel
WEBROOT_DIR dengan kode program di bawah ini.
define('WEBROOT_DIR', 'ilab');
Gambar 4.55. Konfigurasi tambahan file index.php
159
4.3.4 Interaksi User dan Sistem
4.3.4.1 Uji Praktikan
Uji praktikan adalah percobaan implementasi sistem secara langsung
kepada calon praktikan atau pengguna sistem secara umum. Pengujian meliputi
usability testing (uji kemudahan penggunaan sistem) dan functionality testing (uji
fungsionalitas sistem). Uji praktikan dilakukan dengan mengambil sampel
mahasiswa di Laboratorium Informatika dan Laboratorium Teknik Tenaga Listrik
Dasar III. Hasil pengujian ditunjukkan pada tabel di bawah ini.
Tabel 4.5 Hasil uji praktikan (jumlah responden = 7 orang) Responden dan Skala Jawaban
No Pengujian Skala
1
Skala
2
Skala
3
Skala
4
Skala
5 Abstain
1 Tampilan / antarmuka aplikasi 4 orang 3 orang
2 Tingkat kemudahan penggunaan
menu / navigasi aplikasi iLab
4 orang 3 orang
3 Tingkat kemudahan akses ke
halaman-halaman sistem CMS
secara umum
4 orang 3 orang
4 Tingkat kemudahan penggunaan
halaman praktikum dan
pendaftaran praktikum
1
orang
6 orang
5 Tingkat kemudahan akses ke
halaman download resource (pada
halaman Resource)
1
orang
5
orang
1 orang
Keterangan : Skala 1 = sangat sulit / sangat kurang Skala 2 = sulit digunakan / kurang Skala 3 = cukup mudah Skala 4 = mudah digunakan / baik Skala 5 = sangat mudah digunakan / sangat baik
160
Saran dan kritik dari responden :
1. Perlu ada logo khusus untuk masing-masing laboratorium yang
mengimplementasikan CMS iLab.
2. Perlu dicantumkan daftar pengelola laboratorium dan dosen pengampu
praktikum yang ada di laboratorium tersebut.
3. Perlu dicantumkan tata tertib laboratorium.
4. Cabang-cabang navigasi utama (menu pendukung) masih membingungkan
pengguna. Perlu disederhanakan.
5. Pada isian “Angkatan Masuk” di form pendaftaran praktikan sebaiknya
digunakan combo box untuk membatasi angkatan yang diperbolehkan
mengikuti pelaksanaan praktikum.
6. Pada isian “NIM” dan “Angkatan Masuk” perlu mekanisme validasi string
yang masuk, karena string selain angka masih bisa dimasukkan.
Gambar 4.56. Pengujian aplikasi oleh staf Laboratorium Informatika
161
4.3.4.2 Uji Administrasi
Uji administrasi dilakukan untuk menguji tingkat kemudahan (usability
testing) dan fungsionalitas sistem (functionality testing) administrasi CMS.
Pengujian ini melibatkan secara langsung pengelola Laboratorium Informatika.
Hasil pengujian ditunjukkan oleh Tabel 4.6 di bawah ini.
Tabel 4.6 Hasil uji administrasi (jumlah responden = 7 orang)
Responden dan Skala Jawaban
No Pengujian Skala
1
Skala
2
Skala
3
Skala
4
Skala
5 Abstain
1 Tampilan / antarmuka aplikasi 5 orang 2 orang
2 Tingkat kemudahan penggunaan
menu / navigasi aplikasi iLab
6 orang 1 orang
3 Tingkat kemudahan penggunaan
editor teks untuk memasukkan
konten berita pada halaman
manajemen berita (Add News)
1
orang
4 orang 2 orang
4 Tingkat kemudahan manajemen
halaman praktikum
3
orang
2 orang 2 orang
5 Tingkat kemudahan ekspor data
MySQL ke Microsoft Excel
dengan link “export to Excel”
pada halaman :
http://172.16.11.234/sunu/practic
umschedules/detail/10
1
orang
2 orang 2 orang 3 orang
6 Tingkat kemudahan upload
kebutuhan pendukung praktikum
pada halaman “Add Resource”
1
orang
2 orang 4 orang
7 Tingkat kemudahan manajemen
halaman-halaman selain halaman
praktikum
2
orang
4 orang 1 orang
162
Keterangan : Skala 1 = sangat sulit / sangat kurang Skala 2 = sulit digunakan / kurang Skala 3 = cukup mudah Skala 4 = mudah digunakan / baik Skala 5 = sangat mudah digunakan / sangat baik
Saran dan kritik dari responden :
1. Istilah practicum pada antarmuka sebaiknya diganti dengan istilah lab
work, sebagaimana biasa digunakan pada situs-situs universitas di luar
negri. Istilah practicant diganti dengan istilah participant.
2. Pembatasan besarnya ukuran resource yang diupload sebaiknya tidak
terlalu besar (cukup maksimal 7 atau 8 MB supaya tidak terlalu cepat
memenuhi hard disk).
3. Validasi pendaftaran user diperketat (pada modul User) karena user
dengan email yang sudah terdaftar sebelumnya masih bisa melakukan
pendaftaran kembali.
Gambar 4.57. Pengujian aplikasi oleh laboran Laboratorium Informatika
163
4.3.5 Analisis Umum Hasil Pengujian
Secara umum, sistem sudah berjalan sesuai dengan perancangan dan alur
kerja yang diharapkan. Pengujian antarmuka memberikan gambaran penerapan
aplikasi terhadap beberapa browser yang sering digunakan oleh pengunjung untuk
mengakses internet. Hasil pengujian antarmuka menunjukkan CMS iLab
didukung oleh seluruh browser meskipun masing-masing browser memberikan
tanggapan yang berbeda saat mengakses CMS iLab. Beberapa kelemahan yang
ditemukan saat pengujian, selain berasal dari kode program iLab yang masih
membutuhkan penyempurnaan juga disebabkan oleh perbedaan kapasitas
dukungan masing-masing browser terhadap script-script client side, seperti
HTML, Javascript dan CSS.
Pengujian instalasi sistem memberikan gambaran riil instalasi CMS iLab
pada berbagai kondisi dan konfigurasi sistem. Secara umum, iLab bisa berjalan
dengan baik pada semua sistem operasi dan instalasi Apache-PHP-MySQL
apabila syarat-syarat yang diperlukan CMS iLab terpenuhi. Pada beberapa server
dengan konfigurasi yang spesifik, instalasi iLab membutuhkan penyesuaian dan
penanganan secara manual (tidak menggunakan modul Installer yang disediakan
oleh CMS iLab).
Pengujian interaksi user dan sistem memberikan gambaran bahwa
antarmuka secara umum mudah digunakan (user friendly). Beberapa kelemahan
dan kekurangan teknis akan disempurnakan sejalan dengan proses implementasi
iLab di laboratorium yang memerlukan.
164
4.4 Evaluasi Sistem
4.4.1 Evaluasi terhadap Tujuan Penelitian
Untuk mengukur tingkat keberhasilan penelitian, hasil yang didapatkan
dibandingkan dengan tujuan penulisan pada subbab 1.4. Perbandingannya adalah
sebagai berikut :
1. Tujuan : Mengetahui dan memahami implementasi framework CakePHP
untuk membuat CMS.
Hasil : Framework CakePHP sebelumnya lebih banyak digunakan untuk
pengembangan aplikasi praktis yang terdiri dari satu atau dua buah modul
saja. Perancangan dan pembuatan CMS iLab menunjukkan kemampuan
CakePHP sebagai komponen pembangun dasar CMS terintegrasi yang
melibatkan puluhan modul. Dengan melakukan pembelajaran tentang
karakteristik dan komponen file-file pustakanya, framework CakePHP bisa
dikembangkan menjadi berbagai macam aplikasi berbasis web.
2. Tujuan : Mengembangkan CMS untuk pengelolaan laboratorium yang
diberi nama “iLab” sehingga CMS ini bisa digunakan untuk pengelolaan
laboratorium manapun yang meliputi pengelolaan info laboratorium,
pendaftaran, recources, dan info praktikum.
Hasil : Perancangan dan pembuatan CMS iLab, meliputi antarmuka
(presentation logic), business logic, dan database logic berhasil
dilaksanakan. CMS iLab memiliki sepuluh modul utama yang
mengakomodasi kebutuhan laboratorium secara umum.
165
4.4.2 Hambatan terhadap Penelitian
Salah satu hambatan yang terjadi pada saat pengujian aplikasi adalah
penggunaan sistem web cache pada server proxy jaringan internal Jurusan Teknik
Elektro. Penggunaan web cache dimaksudkan untuk menghemat bandwidth
karena server proxy mampu menyimpan halaman-halaman web yang sering
diakses. Namun demikian, dalam pengujian aplikasi iLab halaman web harus
sering di-refresh untuk melihat perubahan yang terjadi setelah dilakukan update
konten database karena halaman web sebelum konten database di-update muncul
kembali saat sebuah modul diakses.
Salah satu solusi untuk mengatasi hal tersebut adalah melakukan bypass
alamat url aplikasi iLab sehingga akses iLab dilakukan secara langsung antara
komputer client dan server tanpa melalui server proxy. Solusi lain yang digunakan
dalam pengujian adalah instalasi aplikasi iLab pada komputer lokal (localhost).
4.4.3 Kemungkinan Pengembangan Sistem Lebih Lanjut
CMS ini masih sangat mungkin dikembangkan menjadi sebuah aplikasi
lain yang lebih kompleks. Beberapa hal yang memungkinkan untuk
dikembangkan antara lain :
1. Penyempurnaan antarmuka CMS dan penyederhanaan menu pendukung
navigasi utama.
2. Pengembangan dan penyempurnaan logic-logic sistem pada class-class
Model dan Controller yang sudah ada.
166
3. Pengembangan modul sistem dengan membuat modul baru atau membuat
sebuah mekanisme instalasi modul berbasis web yang memudahkan
pengguna CMS untuk menambah atau mengurangi modul CMS.
4. Penyempurnaan sistem instalasi iLab sehingga meminimalisasi
kemungkinan digunakannya instalasi manual untuk berbagai konfigurasi
server. Selama ini sistem instalasi yang disediakan iLab hanya bisa
berjalan sempurna apabila server memiliki konfigurasi ideal sebagaimana
konfigurasi server yang digunakan pada saat proses pengembangan
aplikasi. Penyempurnaan sistem instalasi ini termasuk penyempurnaan
pustaka TinyMCE yang masih memerlukan penyesuaian konfigurasi saat
proses instalasi CMS iLab.
5. Penerapan validasi sistem yang lebih spesifik pada setiap form isian CMS
iLab, baik form isian yang diakses pengunjung maupun form isian yang
hanya bisa diakses oleh user yang memiliki akses ke halaman administrasi.
6. Penggunaan sistem pendaftaran praktikum berbasis SMS (Short Message
Service) yang diintegrasikan dengan CMS iLab.
7. Pendokumentasian class-class aplikasi CMS iLab dan pembuatan petunjuk
pemakaian (user manual) CMS iLab.
167
BAB V
KESIMPULAN DAN SARAN
5.1 Kesimpulan
Kesimpulan dari penelitian ini sebagai berikut :
1. Framework CakePHP bisa digunakan sebagai dasar perancangan dan
pembuatan aplikasi CMS terintegrasi yang melibatkan puluhan modul.
Dengan melakukan pembelajaran terhadap file-file pustakanya, framework
CakePHP bisa dikembangkan menjadi berbagai macam aplikasi berbasis
web.
2. Perancangan dan pembuatan CMS iLab berhasil dilaksanakan. CMS iLab
memiliki sepuluh modul utama yang mengakomodasi kebutuhan
laboratorium di Jurusan Teknik Elektro UGM secara umum.
168
5.2 Saran
Untuk pengembangan lebih lanjut, beberapa hal yang dapat dilakukan
adalah sebagai berikut :
1. Pembelajaran fungsionalitas class-class pustaka framework CakePHP
lebih dalam untuk menghasilkan aplikasi yang seefisien dan seoptimal
mungkin.
2. Penyempurnaan business logic proses penjadwalan praktikum sampai
dengan akhir pelaksanaan praktikum.
3. Penyempurnaan modul instalasi untuk mempersingkat proses instalasi dan
meminimalisasi konfigurasi secara manual.
4. Pembuatan modul khusus yang menangani manajemen modul-modul CMS,
sehingga pengguna bisa menambah atau mengurangi modul sesuai dengan
kebutuhan mereka.
5. Pendokumentasian class-class aplikasi CMS iLab dan pembuatan panduan
penggunaan (user manual).
6. Tampilan jadwal praktikum dibuat dalam bentuk matriks atau grafik agar
lebih mudah dibaca.
7. Repository praktikum dilengkapi dengan soal-soal pre test dan post test
sesuai dengan pelaksanaan praktikum.
8. Penyempurnaan tampilan antarmuka dan validasi form isian lebih spesifik.
169
DAFTAR PUSTAKA
Anderson, J.; & Masters, L.E. (ed). 2006a. CakePHP Programmer's Reference
Guide. USA : CakePHP Software Foundation, Inc. 141 p. Anderson, J.; & Masters, L.E. (ed). 2006b. CakePHP-API Documentation version
1.1.8.3544. USA : CakePHP Software Foundation, Inc. Anderson, J.; & Masters, L.E. (ed). 2007.CakePHP Framework. [Online]. http://www.cakephp.org/ Diakses pada tanggal 16 Agustus 2007 Bird, Graham. 2006. How Cake Works. [Online]. http://grahambird.co.uk/cake/tutorials/howitworks.php. Diakses pada tanggal 16 Agustus 2007 Cevasco, Fabio. 2006. An Overview with CakePHP Framework. [Online]
http://hades.phparch.com/ceres/public/article/index.php/art::cakephp::overview. Diakses pada tanggal 3 Januari 2007
Crandall, Karen S.; & Auping, Judith V. 1987. Laboratory Information
Management System (LIMS)- A Case Study. Ohio, USA : National Aeronautics and Space Administration (NASA). 18 p
Douglas, Robert T.; Little, Mike; & Smith, Jared W. 2006. Building Online
Communities with Drupal, phpBB, and Wordpress. USA : Apress. 561p. Fraser, Stephen R.G. 2002. Real World ASP.NET : Building a Content
Management System. USA : Apress. 405 p. Gibbon, Dr. Gerst. 1996. A Brief History of LIMS. USA : Laboratory Automation
and Information Management (journal issue 32, 1996). Gillespie, Helen. 1994. Lab Data Management. USA : Scientific Computing and
Automation (journal July 1994). Krasner, G.E.; & Pope, Stephen T. 1988. A Description of the Model-View-
Controller User Interface Paradigm in the Smalltalk-80 System. California, USA : Parc Place Systems. 34 p
Shan, Tony C.; & Hua, Winnie W. 2006. Taxonomy of Java Web Application
Frameworks. Beijing, China : IEEE International Conference on e-Business Engineering (ICEBE '06). 8 p.
170
Siswoutomo, Wiwit. 2005a. PHP Enterprise : Kiat Jitu Membangun Web Skala Besar. Jakarta : Elex Media Komputindo. 356 h.
Siswoutomo, Wiwit. 2005b. PHP Undercover : Mengungkap Rahasia
Pemrograman PHP. Jakarta : Elex Media Komputindo. 356 h. Smith, L.; & Scheeper, Inus. 2004. Bika Lab System Workflow. [Online]. http://bikalabs.com/images/diagrams/flowdiagramstandard. Diakses pada tanggal 16 Agustus 2007 Sunarfrihantono, Bimo. 2006. Makalah Kuliah Analisis dan Perancangan Sistem
Informasi : Pengembangan Sistem Informasi. Yogyakarta : Teknik Elektro UGM. 22 h.
Wagito. 2003. Pemrograman Berorientasi Objek : Teori dan Aplikasi dengan
C++ Berbasis Windows dan Linux. Yogyakarta : Gavamedia. 238 h.