BAB 2 TINJAUAN PUSTAKA
2.1 Internet
2.1.1 Sejarah Internet Menurut Haas (2005: 5) Jaringan fisik dibangun pada tahun 1969, menghubungkan empat node, yaitu : Universitas California di Los Angeles, SRI (di Stanford), University of California di Santa Barbara, dan University of Utah. Jaringan itu ditransfer bersama-sama melalui 50 Kbps sirkuit. IMP pertama didasarkan pada komputer jenis Honeywell DDP-516 dan Forts. IMP itu adalah pendahulu dari router dan melayani hubungan antara komputer yang berbeda. Host pertama di mana komputer dari IBM, DEC dan SDS, dan semua sistem berjalan dengan operasi yang berbeda.
Pada tahun 1969 Steve Crocker menulis RFC pertama untuk membentuk dokumen dan untuk membahas teknologi terbaru. NCP (Network Control Protocol) adalah protokol pertama yang menghubungkan semua host di ARPANET dan pada bulan Juli 1970 protokol NCP distandarisasi dengan bantuan dari RFC. ARPANET mulai tumbuh dan menghubungkan 15 host.
Pada tahun 1973 multiple IMPS yang ada dimulai. DDP-516 lama melakukan perubahan ke Honeywell 316 dan mendapat nama TIP (Terminal IMP).
Sebuah masalah baru terjadi. Jaringan lain harus terhubung ke ARPANET, tapi setiap jaringan menggunakan protokol yang berbeda. Robert Khan dan Vinton Cerf mulai merancang sebuah jaringan overlapping protocol. Pada Mei 1974 workgroup dengan nama "A Protocol for Packet Network Intercommunication" diterbitkan, dan pada Desember RFC pertama (RFC 675) "Specification of Internet Transmission Control Protocol" di-edit. TCP diciptakan dan memungkinkan ekspansi ke seluruh dunia. Jumlah host meningkat menjadi 62.
Setelah 5 tahun pembangunan pada protokol TCP / IP, mereka beralih dari eksperimental ke protokol operasional. Untuk mendorong pembangunan di TCP / IP 6
7
mereka membuat ICCB (Internet Configuration Control Board). DARPA beralih dari arsitektur ARPANET ke arsitektur Internet menggunakan TCP / IP sebagai protokol dasar.
Pada tahun 1989 dua organisasi baru didirikan yang harus meningkatkan pembangunan TCP / IP dan Internet. (Haas, 2005: 7-10)
2.1.2 World Wide Web Menurut Haas (2005: 17-18) Penemuan World Wide Web (WWW) memiliki dampak yang paling penting untuk pertumbuhan dan perkembangan internet. WWW telah dibuat oleh Tim Berners-Lee, seorang lulusan MIT, bekerja untuk CERN di Swiss. Browser pertama yang ditulis disebut "Nexus" yang juga mampu menampilkan graphic inline. Jaringan Backbone dari berbagai organisasi telah dibuat, seperti General Atomics (CERFnet) dan Performance Systems International (PSINet) dan UUNET Technologies (AlterNet). Proses upgrade dari kecepatan awal modem untuk T3 dan lainnya dibuat selama awal 1990-an. Dengan bantuan dari ISOC pembangunan terus meningkat dan menciptakan protokol baru, misalnya : Multipurpose Internet Mail Extensions (MIME).
Dalam tahun-tahun berikutnya WWW secara signifikan mempengaruhi perkembangan Internet. Meskipun hanya beberapa pengguna bisa memanfaatkan layanan baru ini, banyak wartawan menaruh perhatian besar terhadap WWW, dan segera semua orang ingin "surfing di Internet". Tahun 1993 adalah tonggak dalam sejarah WWW, seperti NCSA yang merilis browser web penuh fitur grafis pertama yang disebut "Mosaic". NSP berencana mengganti struktur utama internet dan memilih untuk meninggalkan internet. Dengan struktur utama internet banyak NAP (Network Access Point) yang telah dibuat. Pertumbuhan Internet adalah 100% per tahun dan jadi ada sekitar 2 jutaan host dan lebih dari 16.000 jaringan yang terhubung satu sama lain.
8
2.1.3 Domain Domain adalah nama unik yang diberikan untuk mengidentifikasi alamat (IP address) server komputer seperti web server atau email server di internet.
Domain memberikan kemudahan pengguna internet untuk melakukan akses ke server dan memudahkan mengingat server yang dikunjungi dibandingkan harus mengingat sederetan angka-angka IP address.
Domain memiliki beberapa level, salah satunya : Top Level Domain adalah deretan kata dibelakang nama domain seperti .com (dotcommercial) .net (dotnetwork) .org(dotorganization) .edu(doteducation) .gov(dotgoverment) .mil(dotmilitary) .info (dotinfo) Dll.
2.1.4 Hosting Hosting adalah space harddisk dalam komputer server yang digunakan untuk penyimpanan database, email dan file web. Ada banyak spesifikasi hosting, tetapi beberapa yang penting adalah : -
Space / kapasitas hosting : Ini adalah besarnya data yang bisa Anda taruh di hosting. Ukurannya adalah Megabytes, Gigabytes, Terabytes.
-
Bandwidth atau besarnya kuota transfer data per bulan. Ukurannya adalah Megabytes/bulan, Gigabytes/bulan. Bandwidth ini direset ke nol tiap bulannya.
-
Jumlah database : Ini adalah menentukannya banyaknya database yang bisa Anda buat / taruh di hosting.
-
Jumlah addon domain : Banyaknya domain lain yang bisa Anda tambahkan ke hosting.
-
Jumlah akun email : Banyaknya akun email yang bisa Anda buat.
9
2.1.5 Website Website adalah halaman informasi yang disediakan melalui jalur internet sehingga bisa diakses di seluruh dunia selama terkoneksi dengan jaringan internet.
Website merupakan kumpulan komponen yang terdiri dari teks, gambar, suara, animasi, video sehingga lebih merupakan media informasi yang menarik untuk dikunjungi.
2.2 Unified Modeling Language (UML)
2.2.1 Sejarah UML UML adalah penerus dalam metode Object-Oriented analysis and design (OOAD) yang pertama kali muncul pada sekitar akhir tahun 80-an dan awal 90-an. Mulanya metode ini menyatukan metode Booch, Rumbaugh (OMT). Dan Jacobson, namun jangkauannya lebih luas dari itu. UML telah melalui proses standarisasi dengan OMG (Object Management Group) dan kini menjadi standar OMG. (Fowler, 2000: 1)
Menurut Fowler (2000: 1) UML disebut juga modeling language, bukan sebuah metode. Secara garis besar metode mengandung paling tidak di dalam prinsip, dari kedua modeling language dan sebuah proses. Modelling language adalah sebuah notasi yang metodenya berguna untuk express design. Sedangkan proses lebih kepada mengambil langkah-langkah dalam membuat desain.
10
2.2.2 Use Case Menurut Fowler (2000: 39-42) Use Case adalah fenomena yang menarik, Untuk waktu yang lama, baik di pengembangan software berbasis objek maupun secara tradisional, orang menggunakan interaksi tertentu untuk membantu mereka mengetahui apa saja yang dibutuhkan. Sementara itu, skenario tersebut diperlakukan secara tidak formal- selalu selesai tetapi jarang didokumentasikan. Ivar Jacobson dikenal sebagai orang yang merubah hal ini dengan metode objectory dan buku ciptaannya.
Skenario adalah urutan langkah yang mendeksripsikan sebuah interaksi Antara pengguna dan sistem. Jadi, Use Case adalah sebuah kumpulan skenario yang disatukan oleh kebutuhan pengguna yang sama. (Fowler, 2000: 39-42)
Sebuah UML use case diagram adalah gambaran dari semua kasus penggunaan dan bagaimana mereka berhubungan. Ini memberikan gambaran besar dari fungsi sistem. Sebagai contoh, aplikasi mesin penjual otomatis mungkin memiliki tiga aktor yang mewakili pelanggan, teknisi perbaikan, dan vendor yang mengisi ulang mesin.
Dalam diagram use case, seperti contoh pada Gambar 2.1. kasus penggunaan ditampilkan sebagai oval. Para aktor terhubung oleh garis dengan kasus penggunaan yang mereka lakukan. Perhatikan bahwa tidak ada rincian kasus penggunaan termasuk didalam diagram dan sebagai gantinya perlu disimpan secara terpisah. Perhatikan juga bahwa kasus penggunaan ditempatkan dalam persegi panjang tapi aktor tidak. Persegi panjang ini adalah pengingat visual dari batas-batas sistem dan bahwa aktor berada di luar sistem.
Beberapa kasus penggunaan dalam sistem yang mungkin berkaitan satu sama lain. Misalnya, ada beberapa langkah yang sama dalam "membakar" daftar lagu ke CD dan memuat daftar lagu ke iPod. Dalam kedua kasus, pengguna pertama menciptakan daftar kosong dan kemudian menambahkan lagu dari perpustakaan ke dalam daftar. Untuk menghindari duplikasi dalam kasus penggunaan, biasanya lebih baik untuk membuat kasus penggunaan baru yang mewakili kegiatan yang
11
digandakan, dan kemudian membiarkan kegunaan lain kasus ini termasuk kasus penggunaan baru sebagai salah satu langkah mereka (Pressman, 2010: 847-848).
Gambar 2.1 Contoh Use-Case Diagram (Pressman, 2010: 848)
2.2.3 Sequence Diagrams Sebuah diagram urutan digunakan untuk menunjukkan komunikasi yang dinamis antara obyek selama pelaksanaan tugas. Ini menunjukkan urutan temporal di mana pesan yang dikirim antara objek untuk menyelesaikan tugas itu. Orang mungkin menggunakan diagram urutan untuk menunjukkan interaksi dalam satu kasus penggunaan atau di salah satu skenario dari sistem perangkat lunak. Sebuah diagram urutan, seperti contoh Gambar 2.2. menunjukkan panggilan metode menggunakan panah horizontal dari pemanggil ke penerima, diberi label dengan nama metode dan secara opsional termasuk parameter, jenis mereka, dan jenis pengembalian (Pressman, 2010: 848-850).
12
Gambar 2.2 Contoh Sequence Diagram (Pressman, 2010: 850)
2.2.4 Activity Diagrams Menurut Fowler (2000: 129-131) Activity diagrams adalah salah satu bagian yang paling tidak terduga di dalam UML. Tidak seperti kebanyakan teknik lainnya di UML, Activity diagrams tidak memiliki asal-usul yang jelas dalam karya-karya dari three amigos. Sebaliknya, Activity diagrams mengkombinasikan ide dari beberapa teknik, yaitu: the event diagram dari Jim Odell, SDL state modeling techniques, wokflow modeling dan Petri nets. Diagram ini sangat berguna di dalam koneksi dengan workflow dan dalam menggambarkan perilaku yang memiliki banyak pemrosesan paralel.
Perilaku bersyarat digambarkan oleh branches dan merges. Branch memiliki satu transisi masuk dan beberapa transisi keluar yang dilindungi. Hanya satu transisi keluar yang bisa diambil. Sedangkan merge memiliki beberapa input dan satu output. Merge menandai akhir dari perilaku bersyarat yangdimulai oleh branch.
Menurut
Pressman
(2010:
853)
Sebuah
diagram
aktivitas
UML
menggambarkan perilaku dinamis dari suatu sistem atau bagian dari sistem melalui
13
aliran kontrol antara aksi yang dilakukan sistem. Sebuah diagram aktivitas UML, seperti contoh pada Gambar 2.3. menggambarkan perilaku dinamis dari suatu sistem atau bagian dari sistem melalui aliran kontrol antara aksi bahwa sistem melakukan.
Hal ini mirip dengan flowchart kecuali bahwa suatu diagram aktivitas dapat menunjukkan aliran bersamaan. Komponen utama dari suatu diagram aktivitas adalah Node aksi, diwakili oleh persegi panjang bulat, yang sesuai dengan tugas yang dilakukan oleh sistem perangkat lunak. Panah dari satu node aksi lainnya menunjukkan aliran kontrol. Artinya, panah antara dua node aksi berarti bahwa setelah aksi pertama selesai aksi kedua dimulai.
Sebuah titik hitam pekat membentuk node awal yang menunjukkan titik awal kegiatan. Sebuah titik hitam yang dikelilingi oleh lingkaran hitam adalah node akhir yang menunjukkan akhir kegiatan. Fork merupakan pemisahan kegiatan menjadi dua atau lebih kegiatan bersamaan.
Hal ini digambarkan sebagai bar hitam horizontal dengan satu panah menunjuk kepadanya dan dua atau lebih anak panah menunjuk darinya. Setiap panah keluar mewakili aliran kontrol yang dapat dijalankan bersamaan dengan arus yang sesuai dengan panah keluar lainnya. Kegiatan bersamaan ini dapat dilakukan pada komputer dengan menggunakan benang yang berbeda atau bahkan menggunakan komputer yang berbeda.
14
Gambar 2.3 Contoh Activity Diagram (Pressman, 2010: 854)
Sebuah node keputusan berkaitan dengan suatu cabang di aliran kontrol berdasarkan kondisi. Seperti node ditampilkan sebagai segitiga putih dengan panah masuk dan dua atau lebih anak panah keluar. Setiap panah keluar diberi label dengan penjaga (suatu kondisi di dalam tanda kurung siku). Aliran kontrol mengikuti panah keluar penjaga yang benar. Dianjurkan untuk memastikan bahwa kondisi mencakup semua kemungkinan sehingga tepat satu dari mereka benar setiap kali node keputusan tercapai (Pressman, 2010: 853-855).
2.2.5 Class Diagrams Menurut Fowler (2000: 49-58) Class Diagrams mendeskripsikan tipe objek yang ada di dalam sistem dan berbagai macam relasi statis yang ada diantara objekobjek tersebut. Ada 2 macam bentuk dari relasi statis, yaitu: 1.
Associations
2.
Subtypes
15
Class Diagram, Contoh pada Gambar 2.4 juga menampilkan atribut dan operasi yang ada di dalam class dan batasan yang ada pada setiap objek yang terkoneksi. Contoh class diagram :
Gambar 2.4 Contoh Class Diagram (Fowler, 2000: 50)
2.2.5.1 Association Association mempresentasikan hubungan antara class.
2.2.5.2 Attributes Attributes sangat mirip dengan asosiasi, tidak ada perbedaan secara konseptual. Hanya saja Attributes memiliki notasi berjenis lain lebih banyak.
2.2.5.3 Operations Operations adalah proses yang dilaksanakan oleh suatu class.
16
2.2.6 Interaction Diagrams Menurut Fowler (2000: 67) Interaction diagrams adalah model yang mendeskripsikan bagaimana grup dari objek-objek berkolaborasi.
2.2.7 State Diagrams Menurut Fowler (2000: 199) state diagrams adalah teknik yang mendeskripsikan tingkah laku dari sistem. State diagram menggambarkan semua kemungkinan yang mungkin bahwa objek tertentu bisa masuk dan bagaimana perubahan kemungkinan obyek sebagai akibat dari peristiwa yang mencapai objek.
2.3
Database
2.3.1 Pengertian Database Menurut Connolly dan Begg (2010: 15), Basis data adalah sekumpulan data yang saling berhubungan satu dengan yang lain secara logika dan suatu deskripsi data yang di rancang untuk memenuhi kebutuhan informasi suatu organisasi. •
Data yang sama dapat digunakan oleh banyak aplikasi dan sistem.
•
Data disimpan dalam format yang fleksibel, karena basis data didefinisikan secara terpisah dari sistem informasi dan program-program aplikasi yang akan menggunakan basis data.
•
Teknologi basis data menyediakan skalabilitas superior, dalam arti basis data dan sistem yang menggunakannya dapat di tingkatkan atau di kembangkan untuk memenuhi kebutuhan-kebutuhan perubahan pada sebuah organisasi.
•
Kemajuan independensi data yang sangat mengurangi redudansi data telah meningkatkan fleksibilitas.
2.3.2 MySQL Menurut Welling dan Thomson (2001: 3), MySQL merupakan sistem manajemen hubungan antara basis data yang sangat cepat dan sempurna. MySQL merupakan alat bantu untuk memanipulsai basis data, sehinga basis data dapat dengan mudah diisi, diambil, disusun dan diubah datanya. Server MySQL pun dapat mengatur kontrol akses dari data, sehingga beberapa pengguna dapat sekaligus bekerja pada waktu yang bersamaan.
17
2.4
Entity Relationship Diagram (ERD) Menurut Connolly dan Begg (2010: 371) Entity-Relationship Diagram
digunakan untuk mendapatkan pemahaman yang tepat mengenai sifat dan bagaimana data digunakan oleh perusahaan. 1.
Entity
Entitas adalah objek yang berbeda dalam organisasi yang akan direpresentasikan dalam database. 2.
Relationship
Relationship merupakan hubungan antara entitas. 3.
Attribute
Atribut merupakan properti yang mendeskripsikan beberapa aspek dari objek.
2.5
Key Menurut Connolly dan Begg (2010: 150), keys digunakan untuk
mengidentifikasikan satu atribut atau lebih yang secara unik mengidentifikasikan relasi. 1.
Candidate key
Menurut Connolly dan Begg (2010: 381), candidate key merupakan sebuah atribut atau sekumpulan atribut yang secara unik mengidentifikasikan keberadaan setiap tipe entitas. 2.
Alternate key
Menurut Connolly dan Begg (2010: 151) alternate key merupakan sebuah candidate key yang tidak terpilih untuk menjadi primary key. 3.
Composite key
Menurut Connolly dan Begg (2010: 382), composite key merupakan candidate key yang terdiri dari dua atribut atau lebih. 4.
Primary key
Menurut Connolly dan Begg (2010: 151), primary key merupakan candidate key yang dipilih untuk mengidentifikasikan setiap kejadian tipe entitas secara unik. 5.
Foreign key Menurut Connolly dan Begg (2010: 151), foreign key merupakan sebuah
atribut atau sekumpulan atribut dalam sebuah relasi yang mencocokkan candidate key dari beberapa relasi.
18
2.6 Software dan Software Engineering
2.6.1 Pengertian Software Software adalah sebuah instruksi (aplikasi komputer) yang ketika di eksekusi akan memberikan fungsi dan performa yang diinginkan, merupakan struktur data yang memungkinkan aplikasi untuk memanipulasi informasi, dan dokumen yang menjelaskan operasi dan guna aplikasi tersebut. (Pressman, 2010: 4)
2.6.2 Pengertian Software Engineering Sedangkan Menurut Pressman (2010: 13) Software Engineering adalah pembentukan dan penggunaan prinsip-prinsip suara Engineering untuk mendapatkan software ekonomis yang handal dan bekerja secara efisien pada mesin nyata.
2.6.3 Model Waterfall Menurut Pressman (2010: 39) Model Waterfall adalah model klasik yang bersifat sistematis dan terurut dalam membangun perangkat lunak. Berikut gambaran dari model waterfall :
1.
Communication Merupakan langkah menganalisis kebutuhan akan perangkat lunak yang akan
dikembangkan, pengumpulan data dan pertemuan dengan customer serta mencari referensi dari jurnal dan buku. 2.
Planning Proses planning merupakan lanjutan dari proses communication. Tahapan ini
akan menghasilkan dokumen user requirement atau bisa dikatakan sebagai data yang berhubungan dengan keinginan user dalam pembuatan software, termasuk rencana yang akan dilakukan. 3.
Modelling Proses modelling ini akan menerjemahkan syarat kebutuhan ke sebuah
perancangan software yang dapat diperkirakan sebelum diimplementasikan. Proses ini berfokus pada rancangan struktur data, arsitektur software, representasi interface, dan detail (algoritma) procedural. Tahapan ini akan menghasilkan dokumen yang disebut software requirement. 4.
Construction
19
Construction merupakan proses membuat kode. Coding atau pengkodean merupakan penerjemahan desain dalam bahasa yang bisa dikenali oleh komputer. Programmer akan menerjemahkan transaksi yang diminta oleh user. Tahapan inilah yang merupakan tahapan secara nyata dalam mengerjakan suatu software, artinya penggunaan komputer akan dimaksimalkan dalam tahapan ini. Setelah pengkodean selesai maka akan dilakukan testing terhadap sistem yang telah dibuat tadi. Tujuan testing adalah menemukan kesalahan terhadap sistem tersebut untuk kemudian bisa diperbaiki. 5.
Deployment Tahapan ini bisa dikatakan final dalam pembuatan sebuah software atau
sistem. Setelah melakukan analisis, desain dan pengkodean maka sistem yang sudah jadi akan digunakan oleh user. Kemudian software yang telah dibuat harus dilakukan pemeliharaan secara berkala.
2.7 Interaksi Manusia Dan Komputer Menurut Shneiderman dan Plaisant (2005: 74), terdapat delapan aturan emas dalam desain antarmuka yaitu: 1.
Berusaha untuk konsisten Aturan ini merupakan aturan yang paling sering dilanggar, karena
terdapat banyak bentuk konsistensi. Konsisten dalam hal urutan aksi, istilah yang digunakan, menu, layout, penggunaan warna, tata letak, kapitalisasi, font, dan sebagainya. 2.
Menyediakan kebutuhan universal Dengan memahami kebutuhan user yang bermacam-macam dan
membuat desain fleksibel yang mendukung perubahan dalam konten. 3.
Memberikan umpan balik yang informatif Untuk setiap aksi user, harus ada sistem umpan balik. Untuk aksi
kecil yang sering dilakukan, respon dapat dibuat dengan sederhana. Sedangkan untuk aksi yang besar dan jarang dilakukan, respon harus dibuat lebih tegas dan jelas. 4.
Desain dialog untuk menghasilkan penutupan atau keadaan akhir Urutan aksi hendaknya disusun ke dalam kelompok kategori awal,
tengah, dan akhir. Umpan balik yang informatif dapat memberikan kepuasan
20
pencapaian, rasa lega, sinyal untuk mempersiapkan diri memasuki kelompok kategori aksi selanjutnya. 5.
Penawaran pencegahan dan penanganan kesalahan sederhana Usahakan dalam mendesain suatu sistem, diarahkan agar user
tidak membuat kesalahan yang serius. Misalnya menyediakan pilihan menu, tidak mengizinkan karakter alfabet pada kotak entri numerik. Jika user melakukan kesalahan, sistem harus dapat mendeteksi kesalahan dan menawarkan instruksi yang sederhana, konstruktif, dan spesifik untuk perbaikan. Contoh, user tidak perlu mengetik ulang seluruh perintah, melainkan hanya memperbaiki bagian yang salah saja. 6.
Mengizinkan pembalikan aksi yang mudah Pada suatu sistem aplikasi harus terdapat pembalikan aksi. Fitur ini
dapat memperkecil kesalahan, selama user tahu bahwa aksi dapat dibatalkan. Pembalikan aksi dapat berupa tindakan tunggal, tugas data entri, atau serangkaian aksi seperti entri nama dan alamat. 7.
Mendukung pusat kendali internal User yang sudah terbiasa dengan suatu aplikasi, biasanya ingin
memiliki kendali atas antarmuka dan tanggapan dari aksinya. Aksi antarmuka yang tidak umum, urutan entri data yang membosankan, kesulitan dalam memperoleh
informasi
yang
dibutuhkan,
serta
ketidakmampuan
menghasilkan aksi yang diinginkan dapat menimbulkan keresahan dan ketidakpuasan pada user. 8.
Mengurangi beban ingatan jangka pendek Manusia mempunyai keterbatasan dalam memproses informasi
dengan waktu yang singkat. Oleh karena itu diperlukan tampilan yang sederhana, pengurangan jendela-gerak frekuensi, pemberian waktu pelatihan yang cukup untuk kode-kode, hafalan dan rangkaian aksi. Jika diperlukan, akses online untuk sintaks, singkatan, kode, dan informasi yang terkait harus disediakan.
2.8 HTML (Hypertext Markup Language) Menurut Lemay (2011: 50) HTML singkatan dari Hypertext Markup Language. HTML didasarkan pada Standar Generalized Markup Language (SGML), pengolahan dokumen yang jauh lebih besar akan lebih rumit sistemnya. Untuk
21
menulis halaman HTML, Anda tidak akan perlu tahu banyak tentang SGML. Namun, mengetahui bahwa salah satu fitur utama dari SGML adalah bahwa hal itu menggambarkan secara umum struktur isi di dalam dokumen, bukan penampilan sebenarnya pada halaman atau layar.
HTML
mendefinisikan
tiga
bagian
yang
menggambarkan
struktur
keseluruhan halaman dan memberikan beberapa informasi header yang sederhana. Ketiga bagian itu, yaitu html, head, dan body membentuk dasar kerangka setiap halaman web. Mereka juga memberikan informasi sederhana tentang halaman (seperti judul atau penulis) sebelum memuat seluruh hal. Struktur bagian halaman tidak mempengaruhi apa halaman tampak seperti ketika ditampilkan, itu hanya alat untuk membantu menafsirkan atau menyaring file HTML.
2.9
PHP (Hypertext Preprocessor) Menurut Welling dan Thomson (2001: 2-3) PHP adalah bahasa pemrograman
berbasis server yang dirancang khusus untuk web. Dalam halaman HTML, dapat dimasukkan kode PHP yang akan dieksekusi setiap kali halaman web tersebut diakses. Kode PHP ini akan diterjemahkan oleh web server dan akan dijalankan bersamaan dengan HTML atau output lainnya, yang akan dilihat oleh pengunjung situs web.
2.10
Yii Framework
2.10.1 Pengertian Yii Framework Yii adalah framework pengembangan aplikasi Web open-source gratis yang dibuat dengan PHP5 untuk membantu perancangan DRY (Don’t Repeat Yourself) yang rapi dan mendorong pemgembangan dengan pendekatan Rapid Development. Yii digunakan untuk mempermudah pengembangan aplikasi serta membantu menjamin end-product yang sangat efisien, bisa dikembangkan lebih lanjut, dan mudah dikelola.
Yii sangat cocok untuk pengembangan proyek dengan skala apapun, mulai dari proyek kecil maupun besar, hal ini dikarenakan Yii sangat dioptimisasi untuk Performance. Yii Framework memungkinkan pengembangan dengan kendali penuh
22
terhadap konfigurasi yang membantu pengembangan berdasarkan model bisnis yang dibutuhkan dalam proses pengembangan aplikasi. Yii menyediakan tools untuk membantu melakukan testing terhadap aplikasi, dan memiliki dokumentasi yang jelas dan komprehensif.
2.10.2 Sejarah Yii Framework Yii dibuat oleh Qiang Xue, yang memulai proyek Yii pada 1 Januari 2008. Qiang sebelumnya mengembangkan dan mengelola Prado Framework. Pengalaman yang didapat bertahun-tahun dan umpan balik yang didapat dari proyek tersebut mendorong kebutuhan akan framework yang cepat, aman, dan profesional yang dibuat untuk pengembangan aplikasi Web 2.0. Pada 3 Desember 2008, setelah hampir setahun dikembangkan, Yii 1.0 akhirnya resmi dirilis ke publik.
Performance yang sangat baik secara metrik dibandingkan dengan framework berbasis PHP lainnya langsung menarik perhatian positif publik dan popularitas serta penggunaannya berkembang sangat pesat sampai sekarang.
2.11. Model View Controller (MVC)
2.11.1 Definisi MVC (Model-View-Controller) Asumsikan sebuah aplikasi Web terdiri dari beberapa sub-aplikasi, yaitu: •
Front-end: Website yang bersifat publik (informasi bisa dilihat oleh
siapa saja) untuk end user biasa. •
Back-end: Sebuah Website yang menampilkan fungsionalitas
administratif untuk mengatur aplikasi. Fitur ini biasanya hanya boleh digunakan oleh staf administrasi. •
Console: Sebuah aplikasi yang terdiri atas perintah-perintah konsol
untuk dijalankan dalam terminal window atau sebagai pekerjaan terjadwal untuk mendukung keseluruhan aplikasi.
23
•
Web API: Menyediakan interface untuk aplikasi third-party agar bisa
diintegrasikan dengan aplikasi utama.
1. Model Sebuah Model merepresentasikan struktur data dari sebuah aplikasi. Model biasanya di share dengan sub-aplikasi yang berbeda di dalam sebuah aplikasi. Model umumnya berinteraksi dengan
data dari dalam database. Model mempunyai
karakteristik sebagai berikut: •
Harus memiliki property untuk merepresentasikan data tertentu.
•
Harus memiliki logika bisnis (aturan validasi) untuk memastikan data
memenuhi kebutuhan desain. •
Bisa mengandung kode untuk memanipulasi data.
Umumnya, sebuah model hendaknya tidak mengandung logika atau kode yang berinteraksi langsung dengan end user. Berikut adalah hal-hal yang hendaknya tidak dilakukan oleh sebuah model: •
Jangan menggunakan $_GET, $_POST, atau variabel sejenis lainnya
yang berhubungan dengan permintaan end user. Variabel-variabel seperti ini harusnya ditangani oleh controller. •
Hindari embed (menggabung) kode HTML atau kode untuk tampilan
(presentational) lainnya. Hal ini dikarenakan kode tampilan bervariasi berdasarkan kebutuhan end user (Front-end dan Back-end mungkin akan menampilkan detil dari sebuah informasi dalam format yang berbeda), hal ini hendaknya ditangani oleh view.
2. View View bertanggungjawab atas merepresentasikan model ke dalam format yang diinginkan end user. Umumnya, view memiliki karakteristik sebagai berikut:
24
•
Hanya mengandung kode untuk tampilan (presentational), seperti
HTML, dan kode PHP sederhana untuk menelusuri, format, dan render data. •
Tidak mengandung kode yang melakukan query database. Kode
seperti itu hendaknya diletakkan dalam model. •
Tidak melakukan akses langsung terhadap variabel seperti $_GET,
$_POST, atau variabel sejenis lainnya yang merepresentasikan permintaan end user. Ini adalah pekerjaan sebuah controller. View hendaknya difokuskan terhadap tampilan dan layout dari data yang disediakan oleh controller dan/atau model, dan tidak melakukan akses variabel permintaan (request) atau database secara langsung. •
Bisa mengakses property dan method dari controller dan model secara
langsung. Namun, hal ini hanya boleh dilakukan untuk tujuan presentasi (tampilan).
View bisa digunakan berulang kali dalam beberapa cara: •
Layout: Daerah presentasional umum (seperti header, footer) bisa
diletakkan dalam layout view. •
Partial views: Menggunakan partial views (view yang tidak
didekorasi dengan layout) untuk menggunakan ulang bagian dari kode presentasional (tampilan). Misalnya, menggunakan _form.php partial view untuk menampilkan model form input yang digunakan untuk membuat sebuah model dan update laman website. •
Widgets: Jika dibutuhkan banyak logika untuk menampilkan sebuah
partial view, partial view tersebut bisa diubah menjadi sebuah widget, dimana file class nya digunakan untuk menaruh logika-logika tersebut (logical codes). Untuk widget yang membuat banyak sekali HTML markup,
25
hendaknya menggunakan file view untuk widget tertentu agar bisa mengandung HTML markup tersebut. •
Helper classes: Dalam sebuah view umumnya dibutuhkan snippet
kode untuk melakukan tugas seperti format data atau membuat HTML tags. Daripada meletakkan kode tersebut langsung ke dalam file view, pendekatan yang lebih baik adalah meletakkan kode-kode tersebut di dalam sebuah view helper class. Setelah itu, hanya cukup menggunakan helper class tersebut di dalam file view. Yii memiliki helper class CHtml yang bisa membuat kode HTML yang paling umum atau sering digunakan.
3. Controller Controller adalah komponen yang menghubungkan antara model, view, dan komponen lainnya menjadi sebuah aplikasi yang bisa dijalankan. Controller memiliki karakteristik sebagai berikut: •
Boleh mengakses $_GET, $_POST, dan variabel PHP lainnya yang
merepresentasikan permintaan user. •
Boleh membuat instance dari model dan mengatur siklus hidup
mereka. Misalnya, di dalam sebuah action model update yang umum, controller membuat sebuah instance dari model; lalu mengisi model tersebut dengan input user dari $_POST; setelah sukses menyimpan model tersebut, controller tersebut bisa redirect (mengarahkan) browser user ke dalam laman rincian model. Ingat bahwa implementasi dari penyimpanan sebuah model sebenarnya dilakukan dalam model, bukan di dalam controller. •
Tidak mengandung kode SQL statements, yang harusnya diletakkan
di dalam model.
26
•
Tidak mengandung kode HTML atau markup presentasional lainnya.
Kode tersebut hendaknya diletakkan dalam view.
Di dalam sebuah aplikasi MVC yang dirancang dengan baik, controller biasanya sangat tipis dan hanya mengandung sedikit baris kode; sedangkan model sangat tebal dan mengandung banyak kode yang bertanggung jawab atas representasi dan manipulasi data. Hal ini karena struktur data dan logika bisnis yang direpresentasikan oleh model umumnya sangat spesifik terhadap kebutuhan aplikasi; sedangkan logika controller biasanya mengikuti sebuah pola yang sama melewati aplikasi-aplikasi dan bisa disederhanakan dengan framework atau class utama yang digunakan.
2.11.2 MVC (Model-View-Controller) Yii Framework Yii mengimplementasikan pola perancangan Model-View-Controller (MVC), yang sering digunakan dalam Web programming. MVC bertujuan untuk memisahkan logika bisnis dari user interface, agar pengembang bisa mengganti setiap bagian aplikasi dengan mudah tanpa mempengaruhi bagian lainnya. Dalam MVC, model mewakili informasi (data) dan aturan bisnis; view mengandung elemen dari user interface seperti text, form input; dan controller mengatur komunikasi antara model dan view.
Selain mengimplementasikan MVC, Yii juga mengenalkan sebuah frontcontroller yang dinamakan Application, yang mengenkapsulasi konteks eksekusi untuk pemrosesan permintaan (request). Application mengumpulkan beberapa informasi tentang sebuah permintaan user dan selanjutnya diteruskan ke sebuah controller untuk pemrosesan lebih lanjut. Diagram Contoh Gambar 2.5. berikut menunjukkan struktur statis dari sebuah aplikasi Yii:
27
Gambar 2.5 Diagram Struktur Statis Aplikasi Yii http://www.yiiframework.com/doc/guide/1.1/en/basics.mvc
2.12 E-Government Seperti sudah disebutkan sebelumnya, di Indonesia pernah dikembangkan aplikasi E-government setingkat Kabupaten di Sidoarjo, Jawa Timur. Pengembangan aplikasi tersebut bertujuan untuk meningkatkan efisiensi, efektifitas, transparansi, dan akuntabilitas penyelenggaraan pemerintahan. (Sudarmaningtyas, Nugroho, Nugroho, 2012: 21)
E-government harus mampu memberikan layanan publik terhadap masyarakat maupun dunia bisnis melalui internet atau teknologi yang lain sebagai enabler. Egovernment tidak hanya sekedar membangun website, tetapi merupakan cara baru untuk mencapai tujuan pemerintah secara keseluruhan melalui elektronik bisnis antara masyarakat, kalangan
bisnis, dan unsur pemerintahan yang lain.
(Sudarmaningtyas, Nugroho, Nugroho, 2012: 22)
E-government dapat dilihat sebagai socio-technical system yang terdiri dari 2 subsistem yang saling berinteraksi yaitu subsistem technical (elektronik) dan subsistem socio (pemerintahan). (Sudarmaningtyas, Nugroho, Nugroho, 2012: 22) Hasil evaluasi menunjukkan bahwa purwarupa e-gov sudah berada pada level pemantapan, karena masyarakat dapat melakukan transaksi dengan kantor pemerintah secara timbal balik melalui layanan publik yang disediakan. Layanan ini
28
mampu berkomunikasi dengan aplikasi/data dari Dinas/Badan terkait meskipun memiliki platform yang berbeda. (Sudarmaningtyas, Nugroho, Nugroho, 2012: 26-27)
Aplikasi untuk tingkat RT memiliki beberapa fitur yang sudah dimiliki oleh aplikasi E-government untuk Kabupaten Sidoarjo, seperti pendataan penduduk ke dalam database, komunikasi timbal balik antara warga dan administrasi terkait, dan sistem pengaduan secara elektronik yang bisa diakses kapan saja dan dimana saja. Secara level kompleksitas, aplikasi yang akan dibuat bersifat sederhana, dengan fokus terhadap fungsionalitas, integritas dan keamanan data, serta kemudahan dalam mengakses data oleh warga maupun administrasi. Perbedaan antara aplikasi Egovernment di atas adalah tingkat pemerintahan yang bersangkutan, dimana aplikasi E-gov setingkat Kabupaten, sedangkan aplikasi yang dibuat setingkat RT. Namun, tujuan dan manfaat dari pengembangan aplikasi serupa, yaitu meningkatkan efisiensi dan efektifitas pelayanan terhadap publik melalui medium elektronik, serta sebagai solusi atas kendala jarak dan waktu.
2.13 Basis Data Berorientasi Objek Data di dalam aplikasi yang dibuat disimpan di dalam suatu database yang dalam pengembangannya difokuskan pada integritas data yang kuat, keamanan yang baik, serta kemudahan akses pada data oleh warga maupun administrasi. Data di dalam aplikasi ini diperlakukan sebagai objek, yang pada dasarnya diturunkan oleh fungsionalitas data dalam bentuk Basis Data Relasional (Relational Database). Solusi representasi data sebagai objek menggunakan salah satu MVC Framework untuk PHP5, yang secara otomatis memperlakukan data di dalam database sebagai objek yang disebut Basis Data Berorientasi Objek (Object Oriented Database).
Sebelumnya pernah dilakukan penelitian perbandingan kinerja antara Basis Data Relasional dengan Basis Data Berorientasi Objek yang bertujuan untuk menemukan kelebihan dan kekurangan dari 2 metode tersebut. Di dalam penelitian tersebut, aplikasi yang digunakan menggunakan Framework Struts yang memiliki pola desain MVC (Model-View-Controller) (Rahman, Mursanto, 2009: 80)
29
Penggunaan Basis Data Berorientasi Objek (BDBO) cukup beragam, mulai dari embedded system sampai sistem informasi manajemen. Walaupun demikian, penggunaan BDBO tidak sebanyak penggunaan Basis Data Relasional. Proyek aplikasi yang berorientasi objek seperti Java atau C# jauh lebih banyak menggunakan Basis Data Relasional dibandingkan menggunakan BDBO. (Rahman, Mursanto, 2009: 76)
Sedikitnya penggunaan BDBO disebabkan belum adanya standarisasi dalam teknologi BDBO, dan dominasi vendor Basis Data Relasional (BDR) dalam pasar basis data. Standar yang dimaksud adalah standar konsep-konsep yang digunakan untuk pemodelan, standar perancangan skema, standar mekanisme akses data, dan standaar lain yang mencakup fitur minimal dari sebuah BDBO. (Rahman, Mursanto, 2009: 76)
Dalam penelitian atas perbandingan kinerja BDR dan BDBO, bagian View dan Controller dalam Struts Framework tidak mengalami perubahan yang signifikan. Sedangkan bagian Model, mengalami perubahan yang cukup signifikan. Hal ini karena Model berinteraksi langsung dengan basis data dan terdiri atas class yang disebut sebagai Modul Pengelola Data (MPD). Berdasarkan penelitian tersebut, Modul Pengelola Data (MPD) diubah menjadi 2 versi, yaitu MySQL (BDR) dan DB40 (BDBO). Dalam proses penelitian, disimpulkan bahwa kinerja BDBO lebih baik dibandingkan BDR dan lebih cepat dalam menyimpan objek data, serta kinerja basis data untuk membaca data objek tergantung dari struktur data yang akan dibaca. (Rahman, Mursanto, 2009: 81-83).
2.14 Volatile Functionalities Pembahasan
penelitian
tersebut
merupakan
suatu
motivasi
dalam
pengembangan aplikasi untuk menyajikan basis data yang efisien, aman, dan memiliki integritas data yang kuat. Dalam aspek fungsional, yaitu berupa fitur-fitur aplikasi dan hal-hal yang bisa dilakukan pengguna terhadap aplikasi, hendaknya bersifat tetap dan tidak sering berubah-ubah, kecuali dalam keadaan tertentu.
Salah satu karakteristik dari aplikasi Web adalah pengembangan yang berkelanjutan berdasarkan kebutuhan pengguna. Suatu fungsionalitas yang
30
diimplementasikan sekali, berdasar dari suatu kejadian yang tidak menentu, dan dihilangkan setelahnya, atau hanya digunakan pada saat periode tertentu disebut dengan Volatile Functionalities (Fungsionalitas yang sering berubah-ubah). (Urbieta, Rossi, Distante, Ginzburg, 2012: 130)
Volatile Functionalities sangat umum dalam kebanyakan aplikasi Web; kadangkala ada fitur baru yang dieksperimentasikan dalam periode tertentu dan kemudian dihilangkan karena pengguna menganggapnya tidak berguna. Kadangkala suatu fungsionalitas dijalankan pada periode atau kondisi tertentu. Biasanya fiturfitur tersebut diaktivasi dan di-deaktivasi berdasarkan periode tertentu setiap tahun. (Urbieta, Rossi, Distante, Ginzburg, 2012: 130)
Bicara tentang fungsionalitas yang bersifat volatile, ada kemungkinan hal ini akan ditambahkan atau dikurangi ke dalam aplikasi yang dibuat. Periode yang umumnya mendorong penambahan atau pengurangan fitur setiap tahun yaitu adalah berbagai Hari Raya, Libur Nasional seperti 17 Agustus, Bulan Ramadhan, atau periode lainnya. Contoh fitur-fitur yang dimaksud adalah seperti penambahan tabel database untuk daftar peserta lomba 17-Agustusan, daftar rumah yang terendam banjir, atau daerah dalam RT yang rusak karena bencana alam, dan lain-lain. Hal ini adalah hal yang mungkin terjadi dalam implementasi aplikasi secara jangka panjang dan suatu hal yang tidak bisa diabaikan.
