Anda di halaman 1dari 183

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
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 Dosen Pembimbing II

Ir. Lukito Edi Nugroho, M.Sc., Ph.D. Indriana Hidayah, S.T.


NIP 131 963 570 NIP 132 302 667

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

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

v
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

vi
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

vii
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

viii
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

ix
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

x
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

xi
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

xii
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

xiii
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


1
tinggi adalah penggunaan Content Management System (CMS) 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.

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

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

3
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

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

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

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

7
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

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

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

10
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

11
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

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

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

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

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

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

17
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).

18
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
2
diimplementasikan untuk laboratorium, dikenal dengan LIMS (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.

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

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

21
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).

22
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

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

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

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

26
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

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

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

1
Apache / IIS
User
2
Database

Dispatcher
8 6
3 5
7 Model
Controller
View
4
4 Redirect

requestAction()

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.

29
Tabel 2.1 Struktur file dan folder framework CakePHP
Folder Utama Sub Foler Sub Foler Keterangan
Kedua Ketiga
/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.

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

31
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

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

33
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

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

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

36
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

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

38
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 SOLUSI
- pendaftaran manual - otomatisasi pendaftaran
- pengolahan data manual - otomatisasi pengolahan data
- tidak ada repository resource praktikum - pembuatan repository resource praktikum
- belum ada media informasi online - media informasi online laboratorium
- pembatasan hak akses pengguna
CMS iLab - otomatisasi instalasi sistem
- mudah digunakan (user friendly)

Gambar 3.1 Permasalahan di laboratorium dan pemecahannya

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

40
- Sistem Operasi
- Apache Web Server
- PHP 4.3. ke atas
- MySQL server

Komputer Server

Local Area Network Workstation

Komputer PC

Komputer Laptop
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.

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

42
MULAI

Melihat profil
praktikum

Melihat
jadwal
praktikum

KOSONG ?
Tidak

Ya

Daftar
sebagai
praktikan

Cek apakah
Tampilkan
pernah mendaftar
pesan error
sebelumnya Ya

Tidak

Simpan
data
praktikan

Tampilkan
data
praktikan

Update data
praktikan BENAR ?
Tidak

Ya

SELESAI

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

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

44
MULAI

Melihat
informasi
asisten

Melihat
jadwal
praktikum

KOSONG ?
Tidak

Ya

Daftar
sebagai
asisten

Cek apakah
Tampilkan
pernah mendaftar
pesan error
sebelumnya Ya

Tidak

Simpan
data
asisten
Update data
asisten
Tampilkan
data
asisten

Hubungi
BENAR ?
laboran
Tidak

Ya

SELESAI

Gambar 3.4 Diagram alir mekanisme pendaftaran asisten

45
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

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

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

48
Menu Utama

Logo iLab

Menu Kont en ut ama modul


Pendukung

CopyrightØ 2007 iLab :: Laboratory Management System. All rights reserved.

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.

49
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

Logo iLab

USERNAME

PASSWORD

Capt cha

OK

CopyrightØ 2007 iLab :: Laboratory Management System. All rights reserved.

Gambar 3.6 Rancangan halaman login

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

Menu Utama

Anda saat ini sedang login sebagai <user>.


Klik Logout unt uk keluar dari member Area
Logo iLab

Logout

Menu
Administ rasi

Logout
Kont en ut ama modul
Menu
Pendukung

CopyrightØ 2007 iLab :: Laboratory Management System. All rights reserved.

Gambar 3.7 Rancangan halaman administrasi

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

Menu Utama

Anda saat ini sedang login sebagai <user>.


Klik Logout unt uk keluar dari member Area
Logo iLab

Logout

Administ rasi Administ rasi Administ rasi Administ rasi Administ rasi
modul 1 modul 2 modul 3 modul 4 modul 5

Logout

Administ rasi Administ rasi Administ rasi Administ rasi Administ rasi
modul 6 modul 7 modul 8 modul 9 modul 10

CopyrightØ 2007 iLab :: Laboratory Management System. All rights reserved.

Gambar 3.8 Rancangan halaman menu administrasi

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

53
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
Persegi panjang, menyatakan himpunan entitas atau
Entity name
entitas.
Belah ketupat, menyatakan himpunan relasi atau
Relationship relasi.
Garis, sebagai penghubung antara himpunan relasi
dengan himpunan entitas.

54
55
Gambar 3.9 Diagram E-R basis data CMS iLab
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”

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

57
58
Gambar 3.10 Diagram LRS basis data CMS iLab
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

59
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

60
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

61
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

62
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

63
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

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

Apache
User CMS Web Server

Database
CMS iLab

Dispatcher

FILENAME

index Model
View Controller
FILENAME

add
PAGE
FILENAME
News Controller News Model News
edit
Controller Practician Model Practician
FILENAME
Controller Practicumname Model Practicumname
delete PAGE
Practician Controller Practicumschedule Model Practicumschedule
FILENAME
Controller Assistant Model Assistant
...........
Controller Project Model Project
FILENAME PAGE Controller Resource Model Resource
........... .......... ....... .......

Gambar 3.11 Arsitektur MVC pada CMS iLab

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

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

67
Gambar 3.12 Use Case CMS iLab

68
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

69
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

70
memiliki peran yang berbeda-beda. Program flow dari CMS iLab dijelaskan pada

Gambar 3.13.

Keyword Mendapatkan ID
Redirect ke
pencarian menuju url Validasi request
halaman error
(melalui path url) halaman data dan alokasi
resource
User Tidak (database)

ID dari objek Memasukkan ID MODEL


atau parameter Apakah objek ada
yang direquest
lainnya di database ? Ya ke proses

Lakukan filtering
Cek keamanan
untuk objek (spam Proses data yang
(apakah user
filtering, HTML dimasukkan (form,
diperkenankan Memproses data
formatting, data post, search)
melakukan aksi ?) Ya yang
Hasil validation
dimasukkan
ditampilkan
Tidak
ke user
CONTROLLER
Redirect ke
halaman error

Parsing layout
Gunakan template
berdasarkan aksi dari Ambil konten yang
untuk tampilan
proses (html, rss, akan ditampilkan
layout modul
etc)
Menampilkan
data

lakukan filtering dan


Tampilan akhir : masukkan konten ke
validasi tampilan VIEW
layout konten + dalam template layout
konten
layuot modul konten

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

71
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

72
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

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

74
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

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

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

77
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

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

79
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

80
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

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

82
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

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

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

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

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

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

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

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

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

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

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

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

94
Gambar 3.23 Diagram Inheritance class-class Model

95
96
Gambar 3.24 Diagram Inheritance class-class Controller (1)
97
Gambar 3.25 Diagram Inheritance class-class Controller (2)
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.

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

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

100
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

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

102
<?php
...
function niceShort($date_string = null, $return = false) {
$date = $date_string ? $this->fromString($date_string) :
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)." WIB";
} 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.

103
<?
....
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_date ? ', '
: '') . $minutes . ' menit' . ($minutes > 1 ? '' : '') : '';
} elseif($minutes > 0) {
// minutes only

104
$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’

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

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

107
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

108
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 Your Admin
!','/');
}

if (!empty($this->data))
{
if ($this->Home->save($this->data))
{

$this->flash('Konten home tersimpan.','/');


}
else {
$this->Session->setFlash('Mohon koreksi kesalahan 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

109
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’.

Menu
Administrasi

Editor teks TinyMCE

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.

110
<?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' => 'newscategory_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.

111
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

112
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->Newscategory-
>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 kesalahan 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

113
menuliskan sintaks sebagaimana terdapat pada Gambar 4.16, record field tertentu

dari tabel newscategories sudah bisa ditampilkan.

$this->set('newscategoryArray', $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

114
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 * FROM 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

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

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

117
if(($_SESSION['priv'] != '1')&&($_SESSION['priv'] !=
'2')&&($_SESSION['priv'] != '3')) {
$this->flash('Restricted Area. Please Contact Your Admin
!','/');
exit();
}
$profile = $this->Profile->findAll();
$this->set('profile',$profile);
}
....
?>

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

118
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

119
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->Pagination-
>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_practicumschedules',
'foreignKey' => 'practicumschedule_id',
'associationForeignKey'=> 'practician_id',
'conditions' => '',
'order' => '',
'limit' => '',
'uniq' => true,
'finderQuery' => '',
'deleteQuery' => '',
'dependent' => true,
'exclusive' => false
)
);

var $belongsTo =
array('Practicumname' =>
array('className' => 'Practicumname',
'conditions' => '',
'order' => '',

120
'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,

121
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

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

123
<?
....
function register($id)
{

$this->pageTitle = 'Assistant Registration';


$this->cleanUpFields();
$aktif = $this->Practicumschedule->query("SELECT * FROM
settings WHERE id='4'") ;

//hitung jumlah asisten terdaftar


$jumlah= $this->Practicumschedule->query("SELECT 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->Practicumschedule-
>read(null,$id) ;
$this->set('Practicumschedule',$Practicumschedule);
}
else{
$this->Session->setFlash('Mohon maaf, fasilitas registrasi
asisten ditutup');

$this->redirect('/assistants/index/');
}
}
else{
$this->Session->setFlash('Mohon maaf, asisten pada 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

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

125
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_practicumschedules',
'foreignKey' => 'practician_id',
'associationForeignKey'=> 'practicumschedule_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

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

127
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

128
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

129
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']['Practicumschedule']);$x++
){
$id = $this-
>params['data']['Practicumschedule']['Practicumschedule'][$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']['practi
cumschedules']['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),

130
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

131
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' => 'practicumname_id'
),
'Practicumschedule' =>
array('className' => 'Practicumschedule',
'conditions' => '',
'order' => '',
'foreignKey' => 'practicumschedule_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.

132
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' => 'practicumname_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

133
di folder cake/. Fungsi add() secara lengkap ditampilkan pada gambar di bawah

ini.

<?
....
function add(){
$this->checkSession();
$this->set('practicumArray', $this->Resource->Practicumname-
>generateList());
$this->set('projectArray', $this->Resource->Project-
>generateList());

if (!empty($this->data))
{
$this->data['Resource']['user_id'] =
$_SESSION['User']['id'];
if ($this->Resource->save($this->data))
{
$this->myFolder = new Folder();
$this->myFolder-
>mkdirr(WWW_ROOT.DS.'upload'.DS.'resource'.DS.$this->Resource-
>getLastInsertId(),0777);
$this->myFolder-
>mkdirr(WWW_ROOT.DS.'upload'.DS.'resource'.DS.$this->Resource-
>getLastInsertId().DS."file",0777);

copy(WWW_ROOT.DS."house".DS.".htaccess",WWW_ROOT.DS.'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 kesalahan 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

134
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.' terhapus.',
'/resources/index');
}

function rdel($path) {
$this->checkSession();
$this->myFolder2 = new Folder();
if(@opendir($path))

135
{
$this->myFolder2->path=$path;
$files = $this->myFolder2->findRecursive();
foreach($files as $file)
unlink($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

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

137
<?
....
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.

138
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 AppModel
{
var $name = 'Guestbook';
var $useTable = 'Guestbooks';

// validasi array yang masuk


var $validate = array(
'name' => VALID_NOT_EMPTY,

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

140
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

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

142
if($_SESSION['priv'] != '1'){
$this->flash('Restricted Area. Please Contact Your Admin
!','/');
exit();
}
$this->set('userstatusArray', $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 kesalahan 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

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

144
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 AppModel
{
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 ;

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

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

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

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

149
Tabel 4.1 Hasil pengujian antarmuka

No. Browser Internet Explorer Mozilla Firefox Opera Safari

Pengujian

1. Dukungan terhadap XHTML Mendukung Mendukung Mendukung Mendukung

2. Dukungan terhadap pustaka Mendukung Mendukung Mendukung Belum sempurna


Javascript secara umum

3. Dukungan terhadap pustaka Mendukung (semua Mendukung (semua Modul iBrowser pada Modul iBrowser pada
Tiny MCE pada elemen text modul berjalan modul berjalan TinyMCE tidak TinyMCE tidak
area normal) normal) berfungsi berfungsi

4. Dukungan terhadap pustaka Mendukung Mendukung Mendukung Mendukung


AJAX

5. Dukungan terhadap CSS Belum sempurna Mendukung (berjalan Mendukung Mendukung


dengan baik)

6. Parsing halaman dalam detik 2,09 detik 2, 73 detik 1,30 detik 1, 28 detik

150
(untuk halaman awal / Modul
Home).
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.

151
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

152
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

153
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

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

155
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

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

157
1. Pada konfigurasi Apache (terletak di file httpd.conf), tambahkan kode

program berikut ini.

Alias /ilab "/path/absolut/ke/instalasi/ilab/app/webroot"


<Directory "/path/absolut/ke/instalasi/ilab/app/webroot">
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

158
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 Skala Skala Skala Skala
Abstain
1 2 3 4 5
1 Tampilan / antarmuka aplikasi 4 orang 3 orang
2 Tingkat kemudahan penggunaan 4 orang 3 orang
menu / navigasi aplikasi iLab
3 Tingkat kemudahan akses ke 4 orang 3 orang
halaman-halaman sistem CMS
secara umum
4 Tingkat kemudahan penggunaan 1 6 orang
halaman praktikum dan orang
pendaftaran praktikum
5 Tingkat kemudahan akses ke 1 5 1 orang
halaman download resource (pada orang orang
halaman Resource)

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

159
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

160
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 Skala Skala Skala Skala
Abstain
1 2 3 4 5
1 Tampilan / antarmuka aplikasi 5 orang 2 orang
2 Tingkat kemudahan penggunaan 6 orang 1 orang
menu / navigasi aplikasi iLab
3 Tingkat kemudahan penggunaan 1 4 orang 2 orang
editor teks untuk memasukkan orang
konten berita pada halaman
manajemen berita (Add News)
4 Tingkat kemudahan manajemen 3 2 orang 2 orang
halaman praktikum orang
5 Tingkat kemudahan ekspor data 1 2 orang 2 orang 3 orang
MySQL ke Microsoft Excel orang
dengan link “export to Excel”
pada halaman :
http://172.16.11.234/sunu/practic
umschedules/detail/10
6 Tingkat kemudahan upload 1 2 orang 4 orang
kebutuhan pendukung praktikum orang
pada halaman “Add Resource”
7 Tingkat kemudahan manajemen 2 4 orang 1 orang
halaman-halaman selain halaman orang
praktikum

161
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

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

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

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

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

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

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

168
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::over
view. 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.

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

170