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 1.2 1.3 1.4 1.5 1.6
LATAR BELAKANG MASALAH ............................................................................... 1 PERUMUSAN MASALAH ......................................................................................... 2 BATASAN MASALAH .............................................................................................. 3 MAKSUD DAN TUJUAN PENELITIAN ...................................................................... 3 METODE PENELITIAN ............................................................................................. 5 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 tinggi adalah penggunaan Content Management System (CMS)
1
untuk
pengelolaan laboratorium dan praktikum. CMS didefinisikan sebagai sebuah aplikasi yang bisa dimanfaatkan untuk mengelola berbagai metode yang berhubungan dengan web publishing. Sebuah CMS secara umum bisa dikustomasi dengan menambahkan atau mengurangi fitur yang spesifik, sehingga hanya fiturfitur 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 (S1) 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 fiturfitur 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 masingmasing 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 komponenkomponen
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, serverside 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 mengenerate 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 diimplementasikan untuk laboratorium, dikenal dengan LIMS
2
(Laboratory
Information Management System). LIMS menurut Crandall dan Auping (1987, h. 2) bisa diartikan sebagai sebuah kombinasi antara perangkat lunak dan perangkat keras komputer yang digunakan di laboratorium untuk manajemen sampel, pengguna laboratorium (praktikan dan laboran), instrumen, standar, dan fungsi laboratorium lainnya dengan menggunakan database, report generator, dan kapabilitas jaringan komputer. LIM dan LIS (Laboratory Information System) memiliki tugas yang hampir serupa. Perbedaan utama antara LIMS dan LIS adalah, LIMS ditujukan untuk penelitian lingkungan dan analisis komersial, seperti farmasi, engineering purpose, dan petrokimia, sedangkan LIS ditujukan untuk penelitian klinis (seperti rumah sakit dan laboratorium klinis lainnya). Gibbon (1996, p.1-5) menjelaskan, LIMS komersial saat ini menawarkan fleksibilitas dan fungsionalitas yang cukup baik. Beberapa LIMS komersial memanfaatkan kelebihan arsitektur dan platform dari sistem open source yang menyediakan kapabilitas client/server dan akses yang luas pada seluruh informasi laboratorium. Produl LIMS berbasis web juga banyak ditawarkan oleh berbagai
2
Untuk selanjutnya akan disebut LIMS saja.
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 aktivitasaktivitas 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
memungkinkan
juga
developer
menjadi membuat
salah
satu
sebuah
framework
aplikasi
web
pilihan
yang
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 berbedabeda
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
3 7
View
5
6 Model
Controller
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 Kedua
Sub Foler Ketiga
/app
/config
/controllers /components /index.php
/models /plugins
/tmp /vendors /views
/elements /errors /helpers /layout /pages /webroot /css /files /img /js /cake /vendors
Keterangan - /app adalah folder tempat penyimpanan aplikasi utama yang dibuat. Folder ini merupakan folder yang berisi seluruh file, image, konfigurasi dari aplikasi web - berisi file-file konfigurasi untuk database, routing aplikasi, setting framework, ACL (Access Control List), dan sebagainya - folder penyimpanan Controller utama - folder penyimpanan Component, sebagai pendukung Controller utama - memungkinkan developer untuk mengembangkan aplikasi web dengan folder /app sebagai Document Root - folder tempat penyimpanan file-file Model - folder tempat penyimpanan plugins. Plugins adalah aplikasi kecil yang dibuat dari CakePHP sebagai dukungan terhadap aplikasi utama - digunakan untuk penyimpanan file-file cache dan log dari aplikasi - digunakan sebagai tempat penyimpanan filefile pustaka PHP lainnya - 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). - folder tempat penyimpanan element, yang mendukung View utama. - folder tempat penyimpanan file-file penanganan error. - folder tempat penyimpanan file-file helper - folder tempat penyimpanan file-file layout antarmuka - folder tempat penyimpanan halaman statis - webroot adalah Document Root dari aplikasi web - folder tempat penyimpanan file-file CSS - folder tempat penyimpanan file-file lain yang mendukung aplikasi - folder tempat penyimpanan file-file gambar - folder tempat penyimpanan file-file Javascript - folder utama tempat file-file pustaka framework CakePHP diletakkan - 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 - pendaftaran manual - pengolahan data manual - tidak ada repository resource praktikum - belum ada media informasi online CMS iLab
SOLUSI - otomatisasi pendaftaran - otomatisasi pengolahan data - pembuatan repository resource praktikum - media informasi online laboratorium - pembatasan hak akses pengguna - otomatisasi instalasi sistem - mudah digunakan (user friendly)
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 masingmasing 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
Tidak
KOSONG ?
Ya Daftar sebagai praktikan
Cek apakah pernah mendaftar sebelumnya
Ya
Tampilkan pesan error
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
Tidak
KOSONG ?
Ya Daftar sebagai asisten
Cek apakah pernah mendaftar sebelumnya
Ya
Tampilkan pesan error
Tidak Simpan data asisten Update data asisten Tampilkan data asisten
Hubungi laboran
BENAR ? 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 No.
SENIN (13.00-15.00) Nama Lengkap NIM
No.
Nama Lengkap
Angkatan
Asisten Praktikum 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 Pendukung
Kont en ut ama modul
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 direfresh. 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
Menu Pendukung
Kont en ut ama modul
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 modul 1
Administ rasi modul 2
Administ rasi modul 3
Administ rasi modul 4
Administ rasi modul 5
Administ rasi modul 8
Administ rasi modul 9
Administ rasi modul 10
Logout Administ rasi modul 6
Administ rasi modul 7
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 masingmasing 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.
Simbol Entity name
Relationship
Tabel 3.2 Simbol diagram E-R versi Chen Keterangan Persegi panjang, menyatakan himpunan entitas atau entitas. Belah ketupat, menyatakan himpunan relasi atau 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 entitasentitas 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.
No 1. 2. 3. 4. 5. 6. 7.
2.
No 1. 2. 3. 4. 5. 6. 7.
Nama tabel
: practicumnames
Jumlah field
:7
Primary key
: id
Foreign key
:-
Nama Field id name academic_year content activation created modified
Type Integer Varchar Varchar Text Enum Datetime Datetime
Panjang / isi 11 255 255 (‘0’,’1’)
Nama tabel
: practicumschedules
Jumlah field
:7
Primary key
: id
Foreign key
: practicumname_id
Nama Field id day practician_amount assistant_amount created modified practicumname_id
Type Integer Varchar Integer Integer Datetime Datetime Integer
Panjang / isi 11 255 5 5
11
Keterangan Kode (id) praktikum Nama praktikum Tahun ajaran praktikum Keterangan Aktivasi praktikum Tanggal upload Tanggal modifikasi
Keterangan Kode (id) jadwal praktikum Hari praktikum Jumlah praktikan Jumlah asisten Tanggal upload Tanggal modifikasi Kode (id) praktikum
59
3.
Nama tabel
: practicians
Jumlah field
:5
Primary key
: id
Foreign key
:-
No 1. 2. 3. 4. 5.
id name academic_year NIM created
4.
Nama tabel
: assistants
Jumlah field
:7
Primary key
: id
Foreign key
: practicumschedule_id, practicumname_id
No 1. 2. 3. 4. 5. 6. 7.
5.
No 1. 2.
Nama Field
Nama Field id name academic_year NIM created practicumschedule_id practicumname_id
Type Integer Varchar Varchar Varchar Datetime
Type Integer Varchar Varchar Varchar Datetime Integer Integer
Panjang / isi 11 255 255 255
Panjang / isi 11 255 255 255 11 11
Nama tabel
: practicians_practicumschedules
Jumlah field
:2
Primary key
: practicumschedule_id, practician_id
Foreign key
:-
Nama Field practicumschedule_id practician_id
Type Integer Integer
Panjang / isi 11 11
Keterangan Kode (id) praktikan Nama praktikan Angkatan masuk kuliah Nomer Induk Mahasiswa Tanggal upload
Keterangan Kode (id) asisten Nama asisten Angkatan masuk kuliah Nomer Induk Mahasiswa Tanggal upload Kode (id) jadwal praktikum Kode (id) praktikum
Keterangan Kode (id) jadwal praktikum Kode (id) praktikan
60
6.
No 1. 2.
7.
No 1. 2. 3. 4. 5. 6. 7. 8.
8.
No 1. 2.
Nama tabel
: userstatuses
Jumlah field
:2
Primary key
: id
Foreign key
:-
Nama Field id status
Type Integer Varchar
Nama tabel
: users
Jumlah field
:8
Primary key
: id
Foreign key
: userstatus_id
Nama Field id username password first_name last_name email phone userstatus_id
Type Integer Varchar Varchar Varchar Varchar Varchar Varchar Integer
Nama tabel
: newscategories
Jumlah field
:2
Primary key
: id
Foreign key
:-
Nama Field id title
Type Integer Varchar
Panjang / isi 10 50
Keterangan Kode (id) level user Status / level user
Panjang / isi 10 255 255 255 255 255 255 10
Keterangan Kode (id) user Username Password Nama depan Nama belakang Email Nomer telepon Kode (id) level user
Panjang / isi 11 255
Keterangan Kode (id) kategori berita Judul kategori
61
9.
No 1. 2. 3. 4. 5. 6. 7.
10.
No 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
11.
Nama tabel
: news
Jumlah field
:7
Primary key
: id
Foreign key
: newscategory_id, user_id
Nama Field id title content created modified newscategory_id user_id
Type Integer Varchar Text Datetime Datetime Integer Integer
Panjang / isi 11 255
11 11
Keterangan Kode (id) berita Judul berita Isi berita Tanggal upload Tanggal modifikasi Kode (id) kategori berita Kode (id) user
Nama tabel
: resources
Jumlah field
: 10
Primary key
: id
Foreign key
: practicumname_id, project_id, user_id
Nama Field id name category content filetype created modified practicumname_id project_id user_id
Type Integer Varchar Integer Text Varchar Datetime Datetime Integer Integer Integer
Nama tabel
: projects
Jumlah field
:7
Primary key
: id
Panjang / isi 11 255 2 255
11 11 11
Keterangan Kode (id) resource Nama resource Kategori resource Keterangan resource Tipe file resource Tanggal upload Tanggal modifikasi Kode (id) praktikum Kode (id) project Kode (id) user
62
Foreign key No 1. 2. 3. 4. 5. 6. 7.
12.
No 1. 2. 3. 4. 5. 6.
13.
No 1. 2. 3. 4. 5.
: user_id
Nama Field id name member content created modified user_id
Nama tabel
: links
Jumlah field
:6
Primary key
: id
Foreign key
:-
Nama Field id name url content created modified
Type Integer Varchar Text Text Datetime Datetime Integer
Panjang / isi 11 255
Type Integer Varchar Varchar Text Datetime Datetime
Panjang / isi 11 255 255
Keterangan Kode (id) link Nama link URL link Keterangan link Tanggal upload Tanggal modifikasi
Panjang / isi 11 255
Keterangan Kode (id) Profile Judul profil Keterangan profil Tanggal upload Tanggal modifikasi
Nama tabel
: Profiles
Jumlah field
:5
Primary key
: id
Foreign key
:-
Nama Field id name content created modified
Type Integer Varchar Text Datetime Datetime
11
Keterangan Kode (id) project Nama project Anggota project Keterangan project Tanggal upload Tanggal modifikasi Kode (id) user
63
14.
No 1. 2. 3. 4. 5.
15.
No 1. 2. 3. 4.
16.
No 1. 2. 3. 4. 5.
Nama tabel
: homes
Jumlah field
:5
Primary key
: id
Foreign key
:-
Nama Field id name content created modified
Type Integer Varchar Text Datetime Datetime
Nama tabel
: settings
Jumlah field
:2
Primary key
: id
Foreign key
:-
Nama Field id name content activation
Type Integer Varchar Varchar Enum
Nama tabel
: guestbooks
Jumlah field
:8
Primary key
: id
Foreign key
:-
Nama Field id name email website coment
Type Integer Varchar Varchar Varchar Text
Panjang / isi 11 255
Keterangan Kode (id) halaman depan Judul halaman depan Keterangan halaman depan Tanggal upload Tanggal modifikasi
Panjang / isi 11 255 255 (‘0’,’1’)
Keterangan Kode (id) setting Nama item setting Keterangan item setting Aktivasi setting
Panjang / isi 11 255 255 255
Keterangan Kode (id) komentar Nama pengunjung Email pengunjung Website / URL pengunjung Komentar pengunjung
64
6. 7. 8.
answer created modifies
Text Datetime Datetime
Jawaban pengelola Tanggal upload 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 Web Server
User CMS
Database CMS iLab Dispatcher
FILENAME
index
Model
Controller
View
FILENAME
add PAGE FILENAME
News
edit
Controller Practician
FILENAME
delete FILENAME
Controller Practicumname PAGE
Practician
...........
Controller Practicumschedule Controller Assistant
........... FILENAME
Controller News
Controller Project Controller Resource
PAGE
..........
.......
Model News Model Practician Model Practicumname Model Practicumschedule Model Assistant Model Project 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.
Kategori User Kode Admin
1
Tabel 3.3 Kategori user CMS iLab Keterangan 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 Nama Modul Admin Lecturer Laboran Member
No. 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 pencarian (melalui path url)
Mendapatkan ID menuju url halaman
Redirect ke halaman error Tidak
User ID dari objek atau parameter lainnya
Hasil ditampilkan ke user
Cek keamanan (apakah user diperkenankan melakukan aksi ?) Ya
Apakah objek ada di database ?
Lakukan filtering untuk objek (spam filtering, HTML formatting, data validation
Ya
Memasukkan ID yang direquest ke proses
Proses data yang dimasukkan (form, post, search)
Validasi request data dan alokasi resource (database) MODEL
Memproses data yang dimasukkan
Tidak CONTROLLER Redirect ke halaman error
Parsing layout berdasarkan aksi dari proses (html, rss, etc)
Gunakan template untuk tampilan layout modul
Tampilan akhir : layout konten + layuot modul
masukkan konten ke dalam template layout konten
Ambil konten yang akan ditampilkan Menampilkan data lakukan filtering dan validasi tampilan konten
VIEW
Gambar 3.13 Program Flow CMS iLab
Saat pertama kali mengakses sistem, user bisa mengakses item yang diinginkan dengan cara melakukan pencarian atau dengan cara mengakses item melalui menu atau navigasi yang tersedia. Sistem, dalam hal ini Model, melakukan validasi request yang dilakukan user. Bila item yang diminta tidak ada dalam database, sistem akan memberikan pesan kesalahan. Bila item yang
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 bersamasama 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 filefile 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.
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.
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). 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. '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 classclass 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 fungsifungsi (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. Bagianbagian 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
.
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. 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
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
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. 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:
input('Home/name', array('size' => '30'))?> 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 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. 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().
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
var $validate = array( 'title' => VALID_NOT_EMPTY, 'newscategory_id' => VALID_NOT_EMPTY, 'content' => VALID_NOT_EMPTY ); var $belongsTo = array( 'Newscategory' => array('className' 'conditions' => 'order' => 'foreignKey' => ), 'User' => array('className' 'conditions' => 'order' => 'foreignKey' => ) );
=> 'Newscategory', '', '', 'newscategory_id'
=> 'User', '', '', '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.
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. 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. 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
0){ foreach($result as $news) { ?>
Mohon maaf, kata kunci tidak ditemukan
Gambar 4.19. Tampilan live search pada bagian View modul News
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.
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. checkSession();
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
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. array('className' => 'Practicumschedule', 'conditions' => '', 'foreignKey' => 'practicumname_id', 'order' => 'Practicumschedule.id ASC', 'dependent' => true, 'exclusive' => false ), 'Assistant' =>
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
practicumnames. Sistem akan melakukan pengecekan flag sebelum menampikan daftar praktikum yang aktif, sebagaimana pada Gambar 4.24. 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. 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' 'conditions' 'order'
); 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
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,
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
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
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
mempermudah pengunjung menerima informasi seputar pelaksanaan praktikum. Kode sumber aktivasi pendaftaran praktikan ditunjukkan pada Gambar 4.26 di bawah ini. 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.
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
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 didownload melalui browser.
Gambar 4.27. Konverter MySQL ke spreadsheet pada file excel.thml
3. Class Practician dan PracticiansController. Model
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. 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
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.
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
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
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. 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),
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
4. Class Assistant dan AssistantsController. Model
Practicumname dan Practicumschedule. Asosiasi ini didefinisikan dengan array, sebagaimana ditunjukkan pada Gambar 4.32 di bawah ini. 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.
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. array('className' 'conditions' => 'order' => 'foreignKey' => ), 'Practicumname' => array('className' 'conditions' => 'order' => 'foreignKey' => ), 'Project' => array('className' 'conditions' => 'order' => 'foreignKey' => )
); .... ?>
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
di folder cake/. Fungsi add() secara lengkap ditampilkan pada gambar di bawah ini. 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
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. 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))
{ $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
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
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.
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.
Gambar 4.39. Antarmuka halaman detail proyek dan riset
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. 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
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
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’. 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. checkSession();
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
digunakan untuk asosiasi sederhana yang melibatkan banyak Model karena memudahkan manajemen record database. 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().
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.
Modul Tambahan Modul Login Modul Login memiliki class Model dan Controller. Selain itu, modul ini
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.
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 ;
- 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.
Modul Installer Modul Installer tidak memiliki Model. Modul ini terdiri dari sebuah file
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.
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
- 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()
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
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).
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.
Dukungan terhadap pustaka Mendukung (semua Tiny MCE pada elemen text modul berjalan area normal)
Modul iBrowser pada Modul iBrowser pada TinyMCE tidak TinyMCE tidak berfungsi berfungsi
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,
dibandingkan dengan browser lainnya. Penggunaan browser Mozilla Firefox direkomendasikan untuk menjamin semua fungsionalitas aplikasi berjalan dengan baik.
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
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.
Plugins iBrowser untuk upload gambar tetap harus disesuaikan secara manual dengan path absolut instalasi
Gambar 4.49. CMS iLab berjalan pada sistem operasi Microsoft Windows
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
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.
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
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
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/
