Implementasi web lelang barang dengan pendekatan teknologi AJAX Push.

(1)

vii ABSTRAK

Lelang merupakan salah satu cara perdagangan yang populer saat ini. Lelang dapat diartikan sebagai proses penjualan yang dilakukan di hadapan orang banyak dengan tawaran yang atas – mengatasi yang dipimpin oleh pejabat lelang. Peserta lelang harus berkumpul di suatu tempat / balai lelang untuk menghadiri lelang.

Dengan semakin berkembangnya teknologi dan internet dimungkinkan untuk melakukan lelang dengan media tersebutDalam tugas akhir ini akan dibuat web yang dapat digunakan untuk memfasilitasi transaksi lelang. Media tersebut dituntut untuk dapat menampilkan data penawaran baru secara cepat sehingga peserta lelang dapat mengetahui harga penawaran terbaru dan dapat menentukan harga penawaran yang akan dilakukan. Untuk itu akan diterapkan mekanisme server-push pada pembuatan web ini. Server-push merupakan suatu mekanisme yang memungkinkan server untuk mengirimkan update kepada client secara terus menerus. Dalam tugas akhir ini juga akan dilakukan pengujian untuk menetahui performa web yang dibuat sehingga dapat diketahui apakah komponen yang digunakan dalam pembuatan web ini baik atau tidak.


(2)

viii

ABSTRACT

Auction is one of the popular trading today. Auction can be defined as a process of selling goods or services by offering them up for bid, taking bids, and then selling the item to the highest bidder. Auction is led by the auction official. The bidders have to gather in a place or auction house to attend the auction process.

The development of technology and internet has made this media posible to perform an auction. In this thesis (final project), the writer would create a website that can be used to facilitate the auction transaction. The media is required to display the new bid data quickly so that the bidders know the lastest bid price and then determine the bid price. Therefore, the writer would implement server-push mechanism in this website. Server-server-push is a mechanism that allows the server to send data update to the client continuously. In this thesis (final project), the writer would verify the website in order to find out the website performance. Therefore, it can be identified whether the components used in the website making process is good or not.


(3)

IMPLEMENTASI WEB LELANG BARANG DENGAN

PENDEKATAN TEKNOLOGI AJAX PUSH

Skripsi

Diajukan Untuk Memenuhi Salah Satu Syarat Memperoleh Gelar Sarjana Komputer

Program Studi Teknik Informatika

Oleh:

Bene Diktus Eki Prabowo 095314050

PROGRAM STUDI TEKNIK INFORMATIKA

JURUSAN TEKNIK INFORMATIKA

FAKULTAS SAINS DAN TEKNOLOGI

UNIVERSITAS SANATA DHARMA

YOGYAKARTA


(4)

IMPLEMENTATION OF AUCTION WEB USING

AJAX PUSH TECHNOLOGY

A Thesis

Presented As A Partial Fulfillment of The Requrements To Obtain The Sarjana Komputer Degree

in Informatics Engineering Study Program

By:

Bene Diktus Eki Prabowo 095314050

INFORMATIC ENGINEERING STUDY PROGRAM

DEPARTMENT OF INFORMATIC ENGINEERING

FACULTY OF SCIENCE AND TECHNOLOGY

SANATA DHARMA UNIVERSITY

YOGYAKARTA


(5)

ii HALAMAN


(6)

(7)

iv

LEMBAR MOTTO

“halangan dan rintangan bukan merupakan hal yang harus dihindari,

jalani dengan segenap usaha untuk dapat melewatinya”

“musuh terbesar dalam hidup adalah kemalasan, berjuang untuk tetap memerangi kemalasan”


(8)

v

PERNYATAAN KEASLIAN KARYA

Saya menyatakan dengan sesungguhnya bahwa skripsi yang saya tulis ini tidak memuat karya atau bagian karya orang lain, kecuali yang telah disebutkan dalam kutipan dan daftar pustaka sebagaimana layaknya karya ilmiah.

Yogyakarta, 13 November 2013


(9)

vii

PUBLIKASI KARYA ILMIAH UNTUK KEPERLUAN AKADEMIS

Yang bertanda tangan di bawah ini, saya mahasiswa Universitas Sanata Dharma: Nama : Bene Diktus Eki Prabowo

Nomor Mahasiswa : 095314050

Demi mengembangkan ilmu pengetahuan, saya memberikan kepada perpustakaan Universitas Sanata Dharma karya ilmiah saya yang berjudul:

IMPLEMENTASI WEB LELANG BARANG DENGAN PENDEKATAN

TEKNOLOGI AJAX PUSH

Beserta perangkat yang diperlukan. Dengan demikian saya memberikan kepada Perpustakaan Universitas Sanata Dharma hak untuk menyimpan, mengalihkan dalam bentuk media lain, mengelolanya dalam bentuk pangkalan data, mendistribusikan secara terbatas, dan mempublikasikannya di Internet atau media lain untuk kepentingan akademis tanpa perlu meminta izin dari saya maupun memberikan royalti kepada saya selama tetap mencantumkan nama saya sebagai penulis. Demikian pernyataan ini saya buat dengan sebenarnya.

Dibuat di Yogyakarta,


(10)

ABSTRAK

Lelang merupakan salah satu cara perdagangan yang populer saat ini. Lelang dapat diartikan sebagai proses penjualan yang dilakukan di hadapan orang banyak dengan tawaran yang atas – mengatasi yang dipimpin oleh pejabat lelang. Peserta lelang harus berkumpul di suatu tempat / balai lelang untuk menghadiri lelang.

Dengan semakin berkembangnya teknologi dan internet dimungkinkan untuk melakukan lelang dengan media tersebutDalam tugas akhir ini akan dibuat web yang dapat digunakan untuk memfasilitasi transaksi lelang. Media tersebut dituntut untuk dapat menampilkan data penawaran baru secara cepat sehingga peserta lelang dapat mengetahui harga penawaran terbaru dan dapat menentukan harga penawaran yang akan dilakukan. Untuk itu akan diterapkan mekanisme server-push pada pembuatan web ini. Server-push merupakan suatu mekanisme yang memungkinkan server untuk mengirimkan update kepada client secara terus menerus. Dalam tugas akhir ini juga akan dilakukan pengujian untuk menetahui performa web yang dibuat sehingga dapat diketahui apakah komponen yang digunakan dalam pembuatan web ini baik atau tidak.


(11)

viii

ABSTRACT

Auction is one of the popular trading today. Auction can be defined as a process of selling goods or services by offering them up for bid, taking bids, and then selling the item to the highest bidder. Auction is led by the auction official. The bidders have to gather in a place or auction house to attend the auction process.

The development of technology and internet has made this media posible to perform an auction. In this thesis (final project), the writer would create a website that can be used to facilitate the auction transaction. The media is required to display the new bid data quickly so that the bidders know the lastest bid price and then determine the bid price. Therefore, the writer would implement server-push mechanism in this website. Server-server-push is a mechanism that allows the server to send data update to the client continuously. In this thesis (final project), the writer would verify the website in order to find out the website performance. Therefore, it can be identified whether the components used in the website making process is good or not.


(12)

ix

KATA PENGANTAR

Puji dan syukur kepada Tuhan karena atas segala berkat dan bimbingan-Nya, penulis dapat menyelesaikan tugas akhir ini dengan baik. Tugas akhir ini ditulis untuk memenuhi salah satu syarat untuk memperoleh gelar Sarjana Komputer dari Program Studi Teknik Informatika Universitas Sanata Dharma. Penulis menyadari bahwa selesainya tugas akhir ini tak lepas dari bantuan orang – orang di sekitar penulis. Oleh sebab itu, penulis mengucapkan terima kasih kepada:

1. Tuhan Yesus Kristus yang telah menyertai, membimbing dan menuntun penulis dalam menyelesaikan tugas akhir ini sehingga tugas akhir ini dapat selesai dengan baik.

2. Bapak Puspaningtyas Sanjoyo Adi, S. T., M. T., selaku dosen pembimbing yang telah bersedia meluangkan waktu, ide, serta pikiran untuk membimbing penulis dalam menyelesaikan tugas akhir ini.

3. Dosen – dosen Teknik Informatika, Bu Rido, Pak Wawan, Bu Tatik, Bu Polina dan semua dosen yang telah membimbing penulis selama mengikuti kuliah sehingga penulis mendapatkan ilmu yang berguna untuk menyelesaikan tugas akhir ini.

4. Keluarga saya, Bapak Ig Sukirna, Ibu El Siswanti, kakak Henricus Eko Prabowo dan adik Brigitta Iko Rosario yang selalu


(13)

mendampingi, memberi semangat dan motivasi serta mendoakan penulis sehingga tugas akhir ini dapat selesai dengan baik dan tepat pada waktunya.

5. Yohana Buragoran, seorang kekasih yang sekaligus menjadi teman dan sahabat penulis yang menjadi salah satu motivasi penulis dalam menyelesaikan tugas akhir ini. Wanita yang selalu memberikan dukungan kepada penulis agar tetap semangat dan pantang menyerah untuk menyelesaikan tugas akhir ini dengan baik.

6. Teman – teman Teknik Informatika, Tinus, Ardha, Aden, Fidi, dan semua teman – teman yang tidak bisa saya sebutkan satu per satu, yang selalu memberikan semangat dan bantuan kepada penulis dalam menyelesaikan tugas akhir ini.

7. Saya sendiri yang telah berusaha dan bekerja keras mengerjakan tugas akhir ini. Orang yang mencoba melawan kemalasan diri sendiri demi selesainya tugas akhir ini.

Yogyakarta, November 2013


(14)

xi

DAFTAR ISI

HALAMAN PERSETUJUAN ... ii

HALAMAN PENGESAHAN ... iii

LEMBAR MOTTO ... iv

PERNYATAAN KEASLIAN KARYA ... v

PUBLIKASI KARYA ILMIAH UNTUK KEPERLUAN AKADEMIS ... vii

ABSTRAK ... viviii

ABSTRACT ... viii

KATA PENGANTAR ... ixx

DAFTAR ISI ... ix

DAFTAR GAMBAR... xiv

DAFTAR TABEL... xvi

DAFTAR LIST... xviii

DAFTAR QUERY... xix

BAB I ... 1

PENDAHULUAN ... 1

1.1. Latar Belakang Masalah... 1

1.2. Rumusan Masalah... 3

1.3. Batasan Masalah... 3

1.4. Tujuan Penelitian... 3

1.5. Manfaat Penelitian... 4

1.6. Luaran... 4

1.7. Metodologi Penelitian... 5


(15)

BAB II ... 7

LANDASAN TEORI ... 7

2.1. Lelang... 7

2.2. Web Server... 9

2.3. Real-time... 11

2.4. HTML Dynamic Document... 15

2.5. JavaServer Faces(JSF)... 16

2.6. ICEfaces Framework... 20

BAB III ... 22

ANALISIS DAN PERANCANGAN ... 22

3.1. Deskripsi Umum Aplikasi... 22

3.2. Analisis Masalah... 23

3.2.1. Sistem Lelang Konvensional... 23

3.2.2. Gambaran Sistem Yang Dikembangkan... 23

3.3. Perancangan Aplikasi... 26

3.3.1. Diagram Use Case... 26

3.3.2. Definisi Use Case... 26

3.3.3. Skenario... 27

3.3.4. Perancangan Basis Data... 34

3.3.5. Desain Tampilan... 39

3.4. Cara Pengujian dan Analisa Hasil... 43

BAB IV ... 45

IMPLEMENTASI. ... 45

4.1. Deskripsi Umum Aplikasi... 45


(16)

4.3. Implementasi Halaman... 48

4.3.1. Halaman Utama... 48

4.3.2. Halaman Registrasi... 49

4.3.3. Halaman Profile... 51

4.3.4. Halaman Edit Profile... 51

4.3.5. Halaman Buat Lelang... 52

4.3.6. Halaman Lelang... 54

4.3.7. Halaman Edit Lelang... 55

4.3.8. Halaman Daftar Lelang... 55

BAB V ... 57

HASIL DAN PEMBAHASAN ... 57

5.1. Uji Fungsional... 57

5.1.1. Login... 57

5.1.2. Buat Lelang... 58

5.1.3. Buat Penawaran... 61

5.1.4. Edit Profile... 62

5.1.5. Logout... 63

5.1.6. Cari Barang... 64

5.1.7. Register... 65

5.2. Uji Non-Fungsional... 68

5.2.1. Performa Sistem... 68

5.2.2. Fairness dan Transparency... 81

BAB VI ... 84

PENUTUP 84 6.1. Kesimpulan... 68


(17)

6.2. Saran... 68 DAFTAR PUSTAKA ... 86 LAMPIRAN ... 88


(18)

xiv

DAFTAR GAMBAR

Gambar 2.1. Web Server ... 10

Gambar 2.1. Simulasi Polling ... 12

Gambar 2.2. Simulasi HTTP Long – Polling ... 13

Gambar 2.3. Simulasi HTTP Streaming ... 14

Gambar 2.4. Ilustrasi Ajax Push ... 21

Gambar 3.1. Skema Proses Lelang ... 25

Gambar 3.2. Arsitektur Sistem ... 25

Gambar 3.3. Diagram Use Case ... 26

Gambar 3.4. ER Diagram ... 34

Gambar 3.5. Logical Design ... 35

Gambar 3.6. Rancangan Tampilan Halaman Depan ... 39

Gambar 3.7. Rancangan Tampilan Halaman Barang ... 40

Gambar 3.8. Rancangan Tampilan Halaman Lelang ... 41

Gambar 3.9. Rancangan Tampilan Halaman Registrasi ... 42

Gambar 3.10. Rancangan Tampilan Halaman Profile ... 42

Gambar 3.11. Rancangan Tampilan Halaman Penawaran ... 43

Gambar 4.1. Implementasi Halaman Utama ... 49

Gambar 4.2. Implementasi Halaman Registrasi ... 50

Gambar 4.3. Implementasi Halaman Input Gambar Profil ... 50

Gambar 4.4. Implementasi Halaman Profil ... 51

Gambar 4.5. Implementasi Halaman Edit Profil ... 52

Gambar 4.6. Implementasi Halaman Buat Lelang ... 53


(19)

Gambar 4.8. Implementasi Halaman Lelang ... 54

Gambar 4.9. Implementasi Halaman Edit Lelang ... 55

Gambar 4.10. Implementasi Halaman Daftar Lelang ... 56

Gambar 5.1. Daftar Penawaran 1 sampai 10 ... 81

Gambar 5.2. Daftar Penawaran 11 samapai 20 ... 82


(20)

xvi

DAFTAR TABEL

Tabel 3.1. Definisi Use Case ... 26

Tabel 3.2. Skenario Use Case Login ... 27

Tabel 3.3. Skenario Use Case Buat Lelang ... 28

Tabel 3.4. Skenario Use Case Buat Penawaran ... 29

Tabel 3.5. Skenario Use Case Edit Profil ... 30

Tabel 3.6. Skenario Use Case Cari Barang ... 31

Tabel 3.7. Skenario Use Case Register ... 31

Tabel 3.8. Skenario Use Case Edit Lelang ... 32

Tabel 3.9. Tabel Member ... 36

Tabel 3.10. Tabel Category ... 37

Tabel 3.11. Tabel Item ... 37

Tabel 3.12. Tabel Picture ... 38

Tabel 3.13. Tabel Bid ... 38

Tabel 5.1. Hasil Pengujian Case Login ... 58

Tabel 5.2. Hasil Pengujian Case Buat Lelang ... 59

Tabel 5.3. Hasil Pengujian Case Buat Penawaran ... 61

Tabel 5.4. Hasil Pengujian Case Edit Profil ... 62

Tabel 5.5. Hasil Pengujian Case Logout ... 64

Tabel 5.6. Hasil Pengujian Case Cari Barang ... 65

Tabel 5.7. Hasil Pengujian Case Register ... 66

Tabel 5.8. Hasil Pengujian 20 Pengguna PC 1 – 10 (Percobaan 1) ... 70

Tabel 5.9. Hasil Pengujian 20 Pengguna PC 11 – 20 (Percobaan 1) ... 70


(21)

Tabel 5.11. Hasil Pengujian 20 Pengguna PC 11 – 20 (Percobaan 2) ... 71

Tabel 5.12. Hasil Pengujian 30 Pengguna PC 1 – 10 (Percobaan 1) ... 71

Tabel 5.13. Hasil Pengujian 30 Pengguna PC 11 – 20 (Percobaan 1) ... 71

Tabel 5.14. Hasil Pengujian 30 Pengguna PC 21 – 30 (Percobaan 1) ... 72

Tabel 5.15. Hasil Pengujian 30 Pengguna PC 1 – 10 (Percobaan 2) ... 72

Tabel 5.16. Hasil Pengujian 30 Pengguna PC 11 – 20 (Percobaan 2) ... 72

Tabel 5.17. Hasil Pengujian 30 Pengguna PC 21 – 30 (Percobaan 2) ... 73

Tabel 5.18. Selisih Waktu Update 20 Pengguna PC 1 – 10 (Percobaan 1) ... 74

Tabel 5.19. Selisih Waktu Update 20 Pengguna PC 11 – 20 (Percobaan 1) ... 74

Tabel 5.20. Selisih Waktu Update 20 Pengguna PC 1 – 10 (Percobaan 2) ... 75

Tabel 5.21. Selisih Waktu Update 20 Pengguna PC 11 – 20 (Percobaan 2) ... 75

Tabel 5.22. Selisih Waktu Update 30 Pengguna PC 1 – 10 (Percobaan 1) ... 76

Tabel 5.23. Selisih Waktu Update 30 Pengguna PC 11 – 20 (Percobaan 1) ... 76

Tabel 5.24. Selisih Waktu Update 30 Pengguna PC 21 – 30 (Percobaan 1) ... 77

Tabel 5.25. Selisih Waktu Update 30 Pengguna PC 1 – 10 (Percobaan 2) ... 77

Tabel 5.26. Selisih Waktu Update 30 Pengguna PC 11 – 20 (Percobaan 2) ... 78

Tabel 5.27. Selisih Waktu Update 30 Pengguna PC 21 – 30 (Percobaan 2) ... 78

Tabel 5.28. Performa Aplikasi Web Lelang ... 79


(22)

xviii

DAFTAR LIST

List 2.1. Contoh Elemen Sederhana ... 17 List 2.2. Contoh Elemen Majemuk ... 17 List 2.3. Elemen Standar JSF ... 17 List 2.4. Tag XML ... 18 List 2.5. Tag Identifikasi XML ... 18 List 2.6. Tag HTML ... 18 List 2.7. Managed Bean ... 19 List 2.8. Anotasi ... 20


(23)

xix

DAFTAR QUERY

Query 4.1. Query DDL Tabel Member ... 46 Query 4.2. Query DDL Tabel Category ... 46 Query 4.3. Query DDL Tabel Item ... 47 Query 4.4. Query DDL Tabel Picture ... 47 Query 4.5. Query DDL Tabel Bid ... 48


(24)

1

BAB I

PENDAHULUAN

1.1. Latar Belakang Masalah

Kebutuhan manusia akan barang – barang kebutuhan hidup mendorong manusia untuk melakukan kegiatan jual – beli barang. Kegiatan jual-beli barang sudah dikenal dari jaman dahulu dengan metode barter atau melakukan tukar – menukar barang yang dimiliki. Ada berbagai macam cara untuk melakukan transaksi jual – beli barang. Salah satu cara jual – beli yang sering digunakan manusia adalah dengan sistim lelang. Dalam kamus besar bahasa Indonesia, lelang berati penjualan di hadapan orang banyak (dengan tawaran yang atas – mengatasi) yang dipimpin oleh pejabat lelang.

Dengan semakin berkembangnya teknologi dan internet sangat dimungkinkan untuk kita dapat bertransaksi lelang dengan media tersebut. Dengan demikian lelang tidak lagi harus dilaksanakan di satu tempat melainkan setiap peserta lelang dapat melakukan pelelangan dari tempat yang jauh dan berbeda – beda.

Untuk dapat melakukan lelang dengan media internet, dibutuhkan media / web yang dapat memfasilitasi para peserta lelang dan penjual untuk dapat bertransaksi. Dengan adanya web lelang barang proses lelang akan menjadi lebih mudah dan sederhana. Di dalam lelang terdapat unsur transparency dan fairness


(25)

dimana peserta lelang dapat mengetahui siapa penawar dan berapa besar penawarannya sehingga dengan begitu dapat diketahui siapa peserta lelang yang pantas memenangkan lelang. Karena proses lelang dilakukan oleh banyak orang sekaligus, dan mungkin selang waktu antar penawaran yang terjadi sangat cepat, maka web yang akan dibuat dituntut untuk tidak hanya dapat menampilkan penawaran pada waktu tertentu, tetapi juga memberikan update penawaran secara real-time.

Dalam kegiatan lelang terdapat tahap penawaran, penentuan harga tertinggi dan proses pembayaran. Dalam tulisan ini hanya akan mengimplementasikan web yang akan memfasilitasi proses pelelangan barang. Untuk proses pembayaran dan proses lain di luar lelang tidak akan dikerjakan.

Untuk memfasilitasi kebutuhan peserta lelang yang menginginkan update penawaran secara real-time akan diterapkan mekanisme server-push. Server-push merupakan sebuah mekanisme untuk mengirim data dari web server ke web browser. Server-push memungkinkan server untuk terus – menerus mengirimkan update ke client. Untuk itu web akan dibangun dengan menggunakan komponen ICEfaces yang dapat memfasilitasi mekanisme server-push.

Dari tulisan ini akan dihasilkan sebuah web lelang barang yang tidak hanya menampilkan web yang statik tetapi web yang akan dihasilkan adalah sebuah web yang interaktif yang dapat memfasilitasi transaksi lelang barang dan dapat menerima update penawaran secara langsung.


(26)

1.2. Rumusan Masalah

Berdasarkan uraian latar belakang di atas, maka yang menjadi rumusan masalah dalam penelitian ini adalah:

1. Bagaimana merancang, implementasi dan mengukur kualitas teknologi server-push ke dalam sebuah web lelang sehingga dapat menghasilkan web interaktif yang menampilkan data secara real-time?

2. Bagaimana menangani masalah transparancy dan fairness dalam lelang online?

1.3. Batasan Masalah

Penelitian ini akan membuat web yang memfasilitasi ascending bid atau lelang Inggris. Pembuatan aplikasi ini akan menggunakan komponen ICEfaces yang kemudian akan diteliti apakah komponen tersebut dapat berjalan dengan baik atau tidak. Penelitian dilakukan dengan menguji seberapa cepat server dapat mengirim update.

1.4. Tujuan Penelitian

Tujuan yang ingin dicapai dalam penelitian ini adalah:

1. Merancang dan membangun sistem informasi lelang barang berbasis web.


(27)

1.5. Manfaat Penelitian

Dari penelitian ini diharapkan akan memberikan manfaat yaitu:

1. Memudahkan penjual untuk menjual barang dan memudahkan pemantauan terhadap penawaran harga.

2. Membantu peserta lelang/pembeli barang untuk dapat memperoleh barang yang diinginkan sesuai dengan kemampuannya.

3. Memudahkan peserta lelang dalam menentukan harga penawaran dengan selalu mengupdate penawaran yang terbaru.

1.6. Luaran

Luaran yang akan dihasilkan dari skripsi ini adalah sebuah web lelang interaktif yang dapat memfasilitasi proses lelang dan dapat menerima masukan kemudian menampilkan penawaran harga secara real-time. Manfaat dari web lelang ini adalah memudahkan transaksi lelang yang dilakukan secara online dimana peserta lelang dapat mengetahui update penawaran harga terbaru sehingga peserta lelang dapat menentukan penawaran yang sesuai.


(28)

1.7. Metodologi Penelitian

Metodologi yang akan digunakan dalam penyusunan tugas akhir ini adalah sebagai berikut:

1. Survey kebutuhan program 2. Studi literatur, meliputi :

a. Pendalaman konsep.

Memahami dan mendalami konsep tentang Server-Push dan aplikasi pendukungnya juga cara implementasinya.

b. Mempelajari perangkat lunak yang terlibat

Mempelajari konsep pemrograman web untuk membangun web real time.

3. Pengembangan perangkat lunak dengan metode pengembangan perangkat lunak berorientasi objek, dengan langkah - langkah sebagai berikut:

a. Analisis dan Desain sistem

1. Pembuatan Use case Diagram, Class Diagram, dan Sequence Diagram.

2. Perancangan database. 3. Perancangan User Interface b. Implementasi


(29)

1.8. Sistematika Penulisan

Sistematika penulisan yang digunakan dalam penelitian ini adalah sebagai berikut:

- BAB I PENDAHULUAN

Bab ini menjelaskan latar belakang penelitian, rumusan masalah, batasan masalah, tujuan penelitian, metodologi penelitian dan sistematika penulisan.

- BAB II DASAR TEORI

Bab ini menjelaskan dasar teori yang dipakai sebagai referensi dan acuan dalam penelitian yang dilakukan.

- BAB III METODOLOGI PENELITIAN

Bab ini menjelaskan mengenai metode yang dipakai dalam penelitian dan pembuatan web sebagai implementasi.

- BAB IV IMPLEMENTASI

Bab ini berisi mengenai listing dari implementasi yang telah dibuat beserta penjelasan dan output dari imlementasi tersebut serta hasil evaluasinya.

- BAB V PENUTUP


(30)

7

BAB II

LANDASAN TEORI

Pada landasan teori ini akan dijelaskan secara singkat tentang hal – hal yang berkaitan dengan mekanisme server-push dan teknologi yang digunakan dalam server-push.

2.1. Lelang

Lelang merupakan proses jual – beli barang atau jasa dengan cara menawarkan kepada banyak penawar. Penawar akan melakukan penawaran yang lebih tinggi dari penawaran sebelumnya untuk dapat membeli barang yang dijual. Penawar dengan nilai penawaran paling tinggi berhak untuk membeli barang sesuai dengan penawaran.

Lelang online adalah lelang yang diselenggarakan melalui media internet. Ruang lingkup dan jangkauan lelang kini menjadi lebih luas oleh internet. Lelang online kini telah memecah dan menghapus keterbatasan fisik lelang tradisional, seperti batasan geografi, waktu kehadiran, ruang, dan luasan sasaran.


(31)

Jenis Lelang: 1. Ascending – bid

Ascending – bid atau lelang naik juga disebut lelang Inggris. Pelelangan ini dilakukan secara interaktif dimana peserta lelang hadir baik secara fisik ataupun elektronik. Harga secara bertahap akan naik sesuai dengan penawaran peserta, penawar akan terus berkurang hingga tersisa satu penawar yang memenangkan lelang pada harga terakhir. 2. Descending – bid

Descending – bid atau lelang turun juga disebut lelang Belanda. Lelang ini adalah kebalikan dari ascending – bid, dimana penjual secara bertahap akan menurunkan harga dari harga tertinggi hingga penawar menerima dan membayar harga yang disepakati.

3. Lelang penawaran tertutup dengan penawaran terbaik

Lelang penawaran tertutup dengan penawaran terbaik adalah lelang yang dilakukan dengan cara pelelang melakukan penawaran secara tertutup kepada penjual. Nilai lelang ditulis kemudian dimasukkan dalam amplop tertutup yang kemudian akan dibuka secara bersama di hadapan peserta lelang. Penawar dengan harga tertinggi memenangkan lelang dan membayar sesuai dengan nilai penawarannya.


(32)

4. Lelang penawaran tertutup dengan harga kedua

Lelang penawaran terttutup dengan harga kedua disebut juga dengan lelang Vickrey. Lelang ini hampir mirip dengan lelang penawaran tertutup dengan penawaran terbaik, hanya saja pemenang lelang hanya akan membayar sebesar jumlah yang ditawarkan penawar tertinggi kedua.

2.2. Web Server

Web server merupakan sebuah perangkat lunak server yang berfungsi untuk menerima request(permintaan) HTTP atau HTTPS dari client atau web browser kemudian mengirimkan kembali hasilnya dalam bentuk halaman web. Prinsip kerja web server cukup sederhana karena pada dasarnya tugas web server hanya dua, yaitu:

1. Menerima permintaan dari client (request)


(33)

Gambar 2.1. Web Server

Gambar di atas merupakan gambaran cara kerja web server menangani request. Berikut ini merupakan penjelasan dari gambar:

1. Web browser mengirimkan HTTP request ke web server melalui internet. 2. Setelah menerima request, web server mengambil file yang diminta dan

mengirimkan halaman web ke web browser.

3. Web browser menanalisa file halaman web untuk menentukan apakah ada file yang dimasukkan (seperti gambar, animasi, uara, dan sebagainya) yang dibutuhkan web browser dari server.

4. Web browser mengirimkan beberapa HTTP request ke web server(satu request untuk satu file).


(34)

5. Web server menerima request untuk file, server menemukan setiap file dan mengirimkannya ke web browser.

6. Web browser mengambil file halaman web kemudian menggabungkan halaman web dengan file kemudian akan ditampilkan di layar.

2.3. Real-time

Sistem komputer real-time merupakan suatu sistem komputer dimana luaran dari sistem tidak hanya mementingkan ketepatan pelaksanaan instruksi, tetapi juga interval waktu ketika output sampai kepada pengguna(Kopetz, 2011). Sistem real-time merupakan sistem yang menggunakan batasan waktu dalam menghasilkan output (mementingkan respon yang cepat).

Berikut adalah beberapa metode yang sering digunakan: - Polling

Polling mengambil event dari browser untuk mengotomatisasi proses mendapatkan informasi baru. Pengembang harus membuat set interval seperti fungsi Javascript setInterval() untuk memeriksa update setiap detiknya. Simulasi polling dapat dilihat pada Gambar 2.1.


(35)

Gambar 2.2. Simulasi Polling

Meskipun polling ini merupakan solusi yang dapat dipakai, tetapi polling memiliki kekurangan. Kekurangan yang paling jelas terlihat adalah polling menciptakan banyak permintaan kosong yang tidak diperlukan dalam sebuah aplikasi.

- HTTP Long-Polling

HTTP long-polling membuka HTTP request untuk jangka waktu tertentu untuk mendapatkan respon dari server. Jika terdapat data baru, server akan mengirimkan data dan menutup permintaan/request, jika tidak permintaan tersebut akan ditutup setelah batas interval habis dan kemudian akan membuka permintaan baru.


(36)

Gambar 2.3. Simulasi HTTP Long – Polling

Dibandingkan dengan polling standar, long-polling jauh lebih efisien. Hal ini dikarenakan long-polling dapat mengrangi jumlah permintaan yang dikirim oleh aplikasi. Pendekatan ini menyediakan mekanisme dimana server dapat memberi tahu client jika terdapat data baru.

- HTTP Streaming

Http streaming sangat mirip dengan Http long-polling, hanya saja pada HTTP streaming koneksi tidak akan tertutup ketika data baru tersedia atau pada interval waktu tertentu. Data baru akan dikirimkan server dari koneksi yang ada.


(37)

Gambar 2.4. Simulasi HTTP Streaming

Manfaat dari model ini adalah koneksi antara client dan server selalu bertahan sehingga data baru yang tersedia langsung dapat dikirimkan ke server, dan setiap terdapat data baru selanjutnya juga akan dikirim dengan koneksi yang sama. Hal ini menjamin bahwa client dan server tetap sinkron.

HTTP streaming memiliki keterbatasan dalam komunikasi dua arah. Oleh karena itu HTTP streaming harus melibatkan sumberdaya lain yang digunakan untuk koneksi kedua untuk komunikasi antara client dengan server.

Masalah lain dalam pendekatan HTTP streaming ini adalah inkonsistensi bagaimana HTTP streaming dapat dicapai oleh web browser yang tidak berbasis Gecko. Dalam browser yang berbasis Gecko dimungkinkan untuk menggunakan multipart replace headers yang memberitahu browser untuk mengganti konten lama deangan konten baru. Dalam browser lain hal ini tidak dimungkinkan, sehingga buffer respon


(38)

akan terus tumbuh hingga tidak ada pilihan lain selain menutup dan membuka lagi koneksi ke server.

2.4. HTML Dynamic Document

Model dokumen HTML standar merupakan model statik dimana dokumen merupakan dokumen tetap yang tidak dapat berubah. Berkebalikan dengan dokumen statis, dokumen dinamis merupakan model dimana isi dari dokumen dapat berubah secara dinamis. Dokumen dinamis merupakan hasil dari beberapa transaksi yang dimulai dari sisi client maupun server.

Terdapat dua mekanisme untuk dinamik dokumen yaitu client-pull dan server-push. Pada client-pull client melakukan serangkaian transaksi untuk mendapatkan pembaruan dokumen, sedangkan pada server-push transaksi dilakukan oleh server (server yang aktif melakukan pembaruan dokumen).

- Server-Push

Dalam mekanisme server-push, dinamik dokumen dikendalikan dari sisi server. Mekanisme ini memungkinkan server untuk mengirim (push) data kepada client. Koneksi antara client dengan server akan tetap terbuka setelah transaksi awal dan server secara berkala akan megirimkan data baru ke client kemudian memperbarui tampilan. Koneksi akan tetap terbuka sampai data terakhir terkirim.

- Client-Pull

Client-pull merupakan mekanisme dalam dokumen dinamik dimana cleint melakukan serangkaian transaksi/request untuk mendapatkan


(39)

dokumen dan memperbarui tampilan. Dalam dokumen client-pull terdapat kode html yang memberitahu client untuk secara berkala melakukan request dan men-download dokumen dari satu atau lebih server yang ada pada network dan meng-update tampilan secara dinamis.

Dokumen client-pull relatif mudah untuk digunakan. Yang diperlukan hanya menambahkan tag <meta> ke dalam header dokumen HTML. Tag tersebut berfungsi untuk memberi tahu browser untuk menampilkan dokumen dalam rentang waktu tertentu.

2.5. Java Server Faces(JSF)

Java Server Faces merupakan framework java untuk membuat antarmuka aplikasi web. JSF menyederhanakan pengembangan tampilan antarmuka yang terkadang sulit dalam pengembangan aplikasi web. JSF mendefinisikan satu set komponen dasar antarmuka ditambah dengan beberapa kemampuan tambahan, serta API (Application Programming Interface) untuk memperluas komponen standar atau mengembangkan komponen baru.

- Dasar Tag JSF

Halaman JSF terdiri dari berbagai elemen. Elemen merupakan sebuah string yang dipisahkan oleh tag. Setiap tag memiliki nama dan atribut yang dimulai dengan ‘<’ dan diakhiri dengan ‘>’. Terdapat dua jenis elemen dalam JSF, yaitu elemen sederhana dan elemen majemuk.

Elemen sederhana terdiri dari satu tag yang berakhiran ‘/>’. Sebagai contoh adalah tag commandButton:


(40)

<h:commandButton value="Save"/>

List 2.1. Contoh Elemen Sederhana

Elemen majemuk terdiri dari pasangan tag awal dan tag akhir dengan nama yang sama. Sebagai contoh adalah tag panelGrid:

<h:panelGrid columns="2"> Masukkan nama anda:

<h:inputText value="#{user.name}"/> </ h:panelGrid>

List 2.2. Contoh Elemen Majemuk - Elemen standar halaman JSF

Semua halaman JSF memiliki struktur dasar sbagai berikut: <?xml version='1.0' encoding='UTF-8' ?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html"> <h:head> <title>A Title</title> </h:head> <h:body>

<!-- Body contents go here. --> </h:body>

</html>


(41)

Karena JSF merupakan aplikasi XML, baris pertama merupakan tag khusus yang mengidentifikasi sebagai XML.

<?xml version='1.0' encoding='UTF-8' ?> List 2.4. Tag XML

Tag kedua berfungsi untuk mengidentifikasi aplikasi XML yang digunakan dalam dokumen.

<DOCTYPE html PUBLIC "- / / W3C / / DTD XHTML 1.0 Transitional / / EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

List 2.5. Tag Identifikasi XML

Tag html menandai awal dan akhir halaman. Tag ini berisi satu atau lebih atribut namespace XML yang menyatakan library yang digunakan dalam dokumen.

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html">

List 2.6. Tag HTML - Managed Beans

Managed beans merupakan kelas java yang pada umumnya digunakan untuk mewakili input pengguna. Berikut ini merpakan contoh Managed Beans sederhana:


(42)

import javax.faces.bean.ManagedBean; import javax.faces.bean.SessionScoped; @ ManagedBean

@ SessionScoped

public class Mahasiswa{ public Mahasiswa(){}

private String nama; private String nim;

public void setNama(String nama){ this.nama = nama;

}

public String getNama(){ return nama;

}

public void setNama(String nama){ this.nama = nama; }

public String getNama(){ return nama;

} }


(43)

Sebuah kelas Java Bean adalah kelas yang harus memiliki konstruktor tanpa parameter dan satu atau lebih atribut. Setiap atribut harus memiliki metode set dan get untuk mengakses atribut tersebut.

Dalam kelas Java Bean terdapat sepasang anotasi: @ ManagedBean

@ SessionScoped

List 2.8. Anotasi

Anotasi tersebut mengatur metadata khusus yang ditanamkan java compiler ke kelas yang dihasilkan. Server akan membaca anotasi kemudian anotasi akan mengarahkan server untuk menggunakan kelas tersebut.

2.6. ICEFaces Framework

ICEFaces merupakan sebuah Rich Internet Application (RIA) development framework yang berdasar pada JavaServer Faces(JSF) 2 standar. ICEFaces memperluas kemampuan JavaServer Faces untuk menyederhanakan pengembangan dan meningkatkan fitur standar JSF sekaligus meningkatkan efisiensi developer dan memperluas kemampuan RIA yang dapat dimasukkan dalam aplikasi web berbasis JSF. ICEFaces memiliki kemampuan di atas JSF standar, terutama dua pada dua tambahan yaitu Automatic AJAX dan AJAX Push.


(44)

- AJAX Push

Ajax push memungkinkan aplikasi untuk secara bertahap memperbarui halaman setiap saat. Ajax push pada icefaces memanfaatkan mekanisme pemberitahuan asynchronous yang disebut icepush. Icepush menggunakan long-polling untuk memfasilitasi pemberitahuan asynchronous melalui HTTP standar. Urutan peristiwa yang terjadi dalam ajax push digambarkan sebagai berikut:

Gambar 2.5. Ajax Push

1. Perubahan kondisi aplikasi memicu event ajax push. 2. Server mengirimkan pemberitahuan ke browser.

3. Notifikasi pada browser menyebabkan browser mengirim ajax request ke server.

4. Server menangkap kondisi baru pada client dan direct-to-DOM (mekanisme yang membuat komponen JSF menjadi standar W3C DOM) memberikan update halaman kepada client.


(45)

22

BAB III

ANALISIS DAN PERANCANGAN

Pada metodologi penelitian ini akan dibahas deskripsi dari aplikasi yang akan dibuat, analisis masalah dan perancangan sistem yang akan dibuat.

3.1. Deskripsi Umum Aplikasi

Untuk melakukan transaksi lelang, orang – orang harus hadir dan berkumpul di suatu tempat yang telah disepakati untuk melakukan transaksi lelang barang. Dengan semakin berkembangnya teknologi dan internet sangat dimungkinkan untuk kita dapat bertransaksi lelang dengan media tersebut. Dengan demikian setiap peserta lelang dapat melakukan pelelangan dari tempat yang jauh dan berbeda – beda.

Aplikasi yang akan dibuat adalah aplikasi web lelang barang real-time. Server akan memberikan update penawaran terbaru sesuai dengan masukan pengguna selama waktu lelang belum selesai. Server akan mengirimkan data penawar, harga penawaran, dan waktu penawaran.


(46)

3.2. Analisis Masalah

3.2.1. Sistem Lelang Konvensional

Dalam sistem lelang konvensional, lelang dilakukan di hadapan banyak orang yang berkumpul di dalam satu ruangan. Lelang dipimpin oleh pejabat lelang, untuk mendapatkan barang yang dilelang peserta harus melakukan penawaran. Peserta lelang akan melakukan penawaran yang saling mengatasi dari penawaran peserta lain. Lelang selesai jika sudah didapatkan penawar tertinggi atau jika waktu lelang sudah habis.

3.2.2. Gambaran Sistem Yang Dikembangkan

Untuk mempermudah transaksi lelang, maka akan dibuat sistem baru yaitu sebuah Web Lelang Barang. Sistem ini digunakan untuk memfasilitasi transaksi lelang barang baik sebagai penjual maupun pembeli. Sistem ini akan memberikan update penawaran terbaru secara real-time agar memudahkan peserta dalam menentukan penawaran yang akan dilakukan dan memudahkan penjual dalam memantau harga barang.

Untuk dapat menjual atau melelang barang, pengguna harus terdaftar dalam sistem ini. Pengunjung dapat melakukan registrasi dengan mengisikan data diri yang dibutuhkan. Untuk dapat menjual barang member harus login terlebih dahulu kemudian mengisikan data barang yang akan dilelang. Demikian pula untuk melakukan penawaran, member harus login kemudian masuk ke halaman barang yang diinginkan kemudian memasukkan penawaran.


(47)

Orang yang Terlibat dalam sistem: 1. Member

Member adalah orang yang telah mendaftar dalam sistem. Member dapat memiliki 2 peranan yaitu:

- Penjual

Orang yang menjual barang. - Pembeli

Orang yang melakukan penawaran. 2. Pengunjung

Pengunjung merupakan pengguna web yang bukan member.

Proses yang menjadi fitur utama sistem ini merupakan proses membuat penawaran yang dilakukan oleh member yang berperan sebagai pembeli. Gambaran umum proses membuat penawaran dan arsitektur sistem dapat dilihat pada gambar 3.1. dan gambar 3.2.


(48)

Gambar 3.1. Skema Proses Lelang


(49)

3.3. Perancangan Aplikasi

3.3.1. Diagram Use Case

Gambar 3.3. Diagram Use Case

3.3.2. Definisi Use Case

Tabel 3.1. Definisi Use Case

Use Case Deskripsi

Login Aktor: Member

Deskripsi: member memasukkan user name dan password

Buat Lelang Aktor: Member

Deskripsi: member memasukkan data barang yang akan dilelang


(50)

Buat penawaran Aktor: Member

Deskripsi: member memasukkan penawaran Cari barang Aktor: Member & Pengunjung

Deskripsi: member memilih barang berdasarkan kategori, masukkan nama barang yang dicari

Edit Profil Aktor: Member

Deskripsi: member memilih profil kemudian memasukkan data baru

Register Aktor: Pengunjung

Deskripsi: pengunjung memilih register kemudian memasukkan data

Edit Lelang Aktor: Member

Deskripsi: member memilih lekang kemudian memasukkan data baru

3.3.3. Skenario

1. Nama Use Case : Login Aktor : Pengunjung

Tabel 3.2. Skenario Use Case Login

Aksi Aktor Reaksi Sistem

Skenario Normal

1. Memasukkan user name dan password yang benar

2. Membuat session dan user akan masuk dalam sistem


(51)

Skenario Alternatif

1. Memasukkan user name dan password salah

2. Menampilkan pesan user name atau password salah

2. Nama Use Case : Buat Lelang Aktor : Member

Tabel 3.3. Skenario Use Case Buat Lelang

Aksi Aktor Reaksi Sistem

Skenario Normal

1. memilih pilihan “Sell”

2. menampilkan form barang 3. mengisi form barang &

pilih buat lelang

4. menyimpan ke database kemudian menampilkan halaman input file gambar 5. memilih gambar kemudian

pilih save

6. menyimpan gambar kemudian menampilkan pemberitahuan file berhasil disimpan

7. pilih finish

8. menampilkan halaman barang

Skenario Alternatif

3. mengisi form tidak lengkap/tidak sesuai


(52)

4. menampilkan pesan kesalahan

5. memilih file bukan gambar

6. menampilkan pemberitahuan file salah

3. Nama Use Case : Buat Penawaran Aktor : Member

Tabel 3.4. Skenario Use Case Buat Penawaran

Aksi Aktor Reaksi Sistem

Skenario Normal

1. memilih barang yang akan dilelang

2. menampilkan halaman barang

3. memasukkan penawaran kemudian klik “Bid”

4. menyimpan penawaran dalam database kemudian menampilkan penawaran terbaru

Skenario Alternatif

3. memasukkan bid lebih rendah dari penawaran kemudian klik “Bid”

4. menampilkan pesan kesalahan


(53)

4. Nama Use Case : Edit Profile Aktor : Member

Tabel 3.5. Skenario Use Case Edit Profile

Aksi Aktor Reaksi Sistem

Skenario Normal 1. pilih “Account”

2. menampilkan halaman profile member

3. pilih edit

4. menampilkan form edit 5. mengisi form edit kemudian

pilih simpan

6. menyimpan data baru kemudian menampilkan halaman profile yang baru Skenario Alternatif

5. mengisi form dengan tidak benar kemudian pilih simpan

6. menampilkan pesan kesalahan


(54)

5. Nama Use Case : Cari Barang Aktor : Pengunjung & Member

Tabel 3.6. Skenario Use Case Cari barang

Aksi Aktor Reaksi Sistem

Skenario Normal

1. pilih kategori barang yang ingin dicari

2. menampilkan semua barang dengan kategori yang dipilih 3. masukkan kata kunci

barang yang ingin dicari

4. menampilkan semua barang yang mengandung kata kunci yang dicari

Nama Use Case : Register Aktor : Pengunjung

Tabel 3.7. Skenario Use Case Register

Aksi Aktor Reaksi Sistem

Skenario Normal 1. pilh register

2. menampilkan halaman registrasi

3. mengisi form registrasi kemudian pilih daftar

4. menyimpan data yang diinputkan kemudian menampilkan halaman form input gambar


(55)

5. memilih gambar kemudian save

6. menyimpan gambar kemdian menampilkan pesan gambar berhasil disimpan

7. pilih finish

8. menampilkan halaman profile

Skenario Alternatif

3. mengisi form dengan tidak benar

4. menampilkan pesan kesalahan

5. memilih file bukan gambar

6. menampilkan pesan kesalahan

7. Nama Use Case : Edit Lelang Aktor : Member

Tabel 3.8. Skenario Use Case Edit Lelang

Aksi Aktor Reaksi Sistem

Skenario Normal

1. pilih lelang yang akan di edit

2. menampilkan halaman lelang barang

3. pilih edit

4. menampilkan form edit 5. mengisi form edit kemudian


(56)

6. menyimpan data baru kemudian menampilkan halaman profile yang baru Skenario Alternatif

6. mengisi form dengan tidak benar kemudian pilih simpan

7. menampilkan pesan kesalahan


(57)

Berikut ini langkah – langkah yang akan dilakukan dlam perancangan database yaitu:

3.3.4.1.Conceptual Database Design


(58)

3.3.4.2. Logical Database Design

Gambar 3.5. Logical Design

3.3.4.3. Physical Database Design

Desain basis data yang akan digunakan dalam web lelang barang dapat dijabarkan sebagai berikut:

1. Tabel member

Nama tabel : member Nama field kunci : email

Tabel ini berisi sejumlah field yang dijelaskan pada tabel berikut:


(59)

Tabel 3.9. Tabel Member Nama Field Tipe Data Ukuran Keterangan

Email varchar 50 e-mail pengguna sebagai field kunci tabel

first_name varchar 50 Nama depan member last_name varchar 50 Nama belakang member Password varchar 50 Password untuk login

Address varchar 100 Alamat

hometown varchar 50 Kota

Province varchar 50 Provinsi

Phone varchar 15 Nomer telepon

birth_date date Tanggal lahir

join_date date Menyimpan tanggal member

mendaftar

Sex varchar 6 Jenis kelamin

Pict varchar 50 Menyimpan lokasi file gambar

2. Tabel category

Nama tabel : category Nama field kunci : id_category

Tabel ini berisi sejumlah field yang dijelaskan pada tabel berikut:


(60)

Tabel 3.10. Tabel Category Nama Field Tipe Data Ukuran Keterangan

id_category varchar 5 id_category sebagai field kunci tabel

Name varchar 50 Nama kategori

3. Tabel item

Nama tabel : item Nama field kunci : id_item

Tabel ini berisi sejumlah field yang dijelaskan pada tabel berikut:

Tabel 3.11. Tabel Item Nama Field Tipe Data Ukuran Keterangan

id_item varchar 20 Id_item sebagai field kunci tabel

Name varchar 50 Nama barang

Price int 11 Harga penawaran

create_date datetime Tanggal lelang dibuat start_date datetime Waktu mulai lelang end_date datetime Waktu selesai lelang

Detail text Detail barang yang dilelang

id_category varchar 5 Sebagai foreign key dari tabel category

Email varchar 50 Sebagai foreign key dari tabel member


(61)

4. Tabel picture

Nama tabel : picture Nama field kunci : no

Tabel ini berisi sejumlah field yang dijelaskan pada tabel berikut:

Tabel 3.12. Tabel Picture Nama Field Tipe Data Ukuran Keterangan

No int 11 no sebagai field kunci tabel

file_location varchar 50 Lokasi file disimpan id_item varchar 15 Foreign key dari tabel item

5. Tabel bid

Nama tabel : bid Nama field kunci : no

Tabel ini berisi sejumlah field yang dijelaskan pada tabel berikut:

Tabel 3.13. Tabel Bid Nama Field Tipe Data Ukuran Keterangan

No int 11 No sebagai field kunci tabel

Time varchar 25 Waktu member melakukan

penawaran

Bid int 50 Nilai penawaran member

id_item varchar 11 Sebagai foreign key dari tabel item


(62)

Email varchar 50 Sebagai foreign key dari tabel member

3.3.5. Desain Tampilan

3.3.5.1.Halaman Depan

Halaman ini merupakan halaman pertama yang akan tampil ketika pengguna masuk web site. Halaman depan menampilkan sejumlah lelang yang terakhir dibuat. Pada halaman ini juga menampilkan sejumlah barang dengan penawaran terbanyak.


(63)

3.3.5.2.Halaman Barang

Halaman ini merupakan halaman barang yang berisi informasi – informasi dan detail barang yang dilelang.

Gambar 3.7. Rancangan Tampilan Halaman Barang

3.3.5.3.Halaman Lelang

Halaman ini merupakan halaman lelang yang memuat informasi penawaran yang meliputi pelelang, penawaran dan waktu penawaran. Pada tampilan ini pengguna dapat memasukkan penawaran pada field yang disediakan.


(64)

Gambar 3.8. Rancangan Tampilan Halaman Lelang

3.3.5.4.Halaman Registrasi

Halaman ini merupakan halaman registrasi yang digunakan pengguna untuk melakukan registrasi/pendaftaran untuk dapat bertransaksi menggunakan web lelang. Pengguna harus mengisi informasi yang dibutuhkan untuk dapat mendaftar.


(65)

Gambar 3.9. Rancangan Tampilan Halaman Registrasi

3.3.5.5.Halaman Profile

Halaman ini merupakan halaman profile yang berisi informasi dari member.


(66)

3.3.5.6.Halaman Hasil Pencarian

Halaman ini merupakan halaman hasil pencarian yang menampilkan semua hasil yang sesuai dengan kata kunci dari pencarian yang dilakukan pengguna

Gambar 3.11. Rancangan Tampilan Halaman Hasil Pencarian

3.3.5. Cara Pengujian dan Analisa Hasil

Pengujian akan dilakukan dengan melakukan percobaan terhadap aplikasi web yang telah dibuat dengan cara memberikan inputan nilai lelang secara berkala dan dalam rentang waktu tertentu. Pengujian dilakukan pada dua server yang berbeda dan dengan kemampuan prosesor yang juga berbeda. Pengujian untuk setiap server dilakukan beberapa kali dengan jumlah client yang berbeda – beda. Untuk setiap pengujian akan dicatat kecepatan server dalam mengirimkan data dan cpu ussagenya.


(67)

Pada proses analisa, data yang telah didapatkan pada proses pengujian akan dianalisa apakah prosesor berpengaruh pada performa sistem yang dibangun, seberapa cepat server dapat menyampaikan data baru kepada client. Untuk melihat apakah prosesor berpengaruh atau tidak akan dilihat dari cpu ussage dari masing – masing prosesor. Kemudian untuk kecepatan dapat dilihat dari rata – rata selisih waktu antara input dengan refresh data baru.


(68)

45

BAB IV

IMPLEMENTASI

Pada bagian ini, penulis akan memaparkan mengenai proses implementasi sistem ke dalam bahasa pemrograman.

4.1. Deskripsi Umum Aplikasi

Aplikasi dibuat dengan menggunakan sebuah IDE (Integrated Development Environment), yakni Netbeans IDE 7.2. dengan plugin ICEfaces 3.3. dan dengan application server glassfish v3. Sistem manajemen basis data (DBMS) yang digunakan adalah MySQL versi 5.6. Perangkat keras yang digunakan dalam pembuatan aplikasi untuk penelitian ini adalah sebuah notebook dengan spesifikasi sebagai berikut:

Processor : AMD A6-3420M APU with Radeon(tm) HD Graphics 1.50 GHz

Memory : 6,00 GB RAM


(69)

4.2. Implementasi Tabel Basis Data

Bagian ini akan memaparkan query pembuatan tabel pada basis data. Terdapat 5 (lima) tabel yang digunakan dalam implementasi sistem, yaitu tabel member, tabel category, tabel item, tabel picture dan tabel bid.

CREATE TABLE `member` ( `email` varchar(50) NOT NULL, `first_name` varchar(50) DEFAULT NULL,

`last_name` varchar(50) DEFAULT NULL, `password` varchar(50) DEFAULT NULL, `address` varchar(100) DEFAULT NULL, `hometown` varchar(50) DEFAULT NULL, `province` varchar(50) DEFAULT NULL, `phone` varchar(15) DEFAULT NULL, `birth_date` date DEFAULT NULL, `join_date` date DEFAULT NULL, `sex` varchar(6) DEFAULT NULL, `pict` varchar(50) DEFAULT NULL, PRIMARY KEY (`email`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Query 4.1. Query DDL Tabel Member

CREATE TABLE `category` (

`id_category` varchar(5) NOT NULL, `name` varchar(50) DEFAULT NULL, PRIMARY KEY (`id_category`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;


(70)

CREATE TABLE `item` (

`id_item` varchar(20) NOT NULL, `name` varchar(50) DEFAULT NULL, `price` int(11) DEFAULT NULL,

`create_date` datetime DEFAULT NULL, `start_date` datetime DEFAULT NULL, `end_date` datetime DEFAULT NULL, `detail` text,

`id_category` varchar(5) DEFAULT NULL, `email` varchar(50) DEFAULT NULL, PRIMARY KEY (`id_item`),

KEY `FK_item-category` (`id_category`), KEY `FK_item-member` (`email`),

CONSTRAINT `FK_item-category` FOREIGN KEY

(`id_category`) REFERENCES `category` (`id_category`),

CONSTRAINT `FK_item-member` FOREIGN KEY (`email`)

REFERENCES `member` (`email`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Query 4.3. Query DDL Tabel Item

CREATE TABLE `picture` (

`no` int(11) NOT NULL AUTO_INCREMENT, `file_location` varchar(50) DEFAULT NULL, `id_item` varchar(15) DEFAULT NULL,

PRIMARY KEY (`no`),

KEY `FK_picture` (`id_item`),

CONSTRAINT `FK_picture` FOREIGN KEY (`id_item`)

REFERENCES `item` (`id_item`)

) ENGINE=InnoDB AUTO_INCREMENT=19 DEFAULT CHARSET=utf8;


(71)

CREATE TABLE `bid` (

`no` int(11) NOT NULL AUTO_INCREMENT, `time` varchar(25) DEFAULT NULL, `bid` int(11) DEFAULT NULL,

`id_item` varchar(20) DEFAULT NULL, `email` varchar(50) DEFAULT NULL, PRIMARY KEY (`no`),

KEY `FK_bid-item` (`id_item`), KEY `FK_bid-member` (`email`),

CONSTRAINT `FK_bid-item` FOREIGN KEY (`id_item`)

REFERENCES `item` (`id_item`),

CONSTRAINT `FK_bid-member` FOREIGN KEY (`email`)

REFERENCES `member` (`email`)

) ENGINE=InnoDB AUTO_INCREMENT=4213 DEFAULT CHARSET=utf8;

Query 4.5. Query DDL Tabel Bid

4.3. Implementasi Halaman

4.3.1.Halaman Utama

Halaman ini merupakan halaman utama yaitu halaman pertama yang ditampilkan ketika pengguna membuka website. Dalam halaman utama ini ditampilkan delapan daftar lelang terbaru dan juga delapan daftar lelang dengan penawaran terbanyak.


(72)

Gambar 4.1. Implementasi Halaman Utama

4.3.2.Halaman Registrasi

Halamin ini merupakan halaman yang digunakan untuk pendaftaran anggota. Halaman ini terbagi menjadi dua bagian yaitu bagian input data dan input file gambar untuk gamb ar profile. Pengguna harus memasukkan data yang dibutuhkan kemudian menekan tombol ‘Create account’ untuk mendaftar. Pengguna akan dibawa ke halaman input gambar yang digunakan untuk gambar profile. Halaman registrasi ditunjukkan pada Gambar 4.2. dan halaman input gambar ditunjukkan pada Gambar 4.3.


(73)

Gambar 4.2. Implementasi Halaman Registrasi


(74)

4.3.3.Halaman Profile

Pada halaman profile ditampilkan data diri dari member dan juga daftar lelang yang pernah dibuat oleh member. Terdapat menu edit untuk yang dapat digunakan oleh member untuk mengubah data profilnya. Halaman profil ditunjukkan dalam Gambar 4.4.

Gambar 4.4. Implementasi Halaman Profil

4.3.4.Halaman Edit Profile

Halaman ini berfungsi untuk mengubah data profil member. Member dapat mengubah profilnya dengan memasukkan data baru kemudian menekan tombol ‘Save change’. Halaman edit profil ditunjukkan pada Gambar 4.5.


(75)

Gambar 4.5. Implementasi Halaman Edit Profil

4.3.5.Halaman Buat Lelang

Halaman ini merupakan halaman yang digunakan member untuk membuat lelang. Halaman ini juga terbagi menjadi dua bagian yaitu halaman input data dan halaman input file gambar. Member harus memasukkan data yang dibutuhkan kemudian menekan tombol ‘Create Auction’. Halaman buat lelang ditunjukkan pada Gambar 4.6. dan halaman input gambar ditunjukkan pada gambar 4.7.


(76)

Gambar 4.6. Implementasi Halaman Buat Lelang


(77)

4.3.6.Halaman Lelang

Di halaman ini berisi detail barang yang dilelang sekaligus menjadi halaman lelang. Di halaman ini member yang merupakan pemilik barang memiliki menu edit yang dapat digunakan untuk mengganti informasi barang yang dilelang. Pada halaman ini member lain juga dapat membuat penawaran selama watu yang telah ditentukan. Halaman lelang ditunjukkan pada Gambar 4.8.


(78)

4.3.7.Halaman Edit Lelang

Halaman ini berfungsi untuk mengubah data barang yang dilelang. Member dapat mengubah data dengan memasukkan data baru kemudian menekan tombol ‘Update’. Halaman edit lelang ditunjukkan pada Gambar 4.9.

Gambar 4.9. Impelementasi Halaman Edit Lelang

4.3.8.Halaman Daftar Lelang

Halaman ini dapat dibuka dari menu kategori yang terdapat di bagian kiri tampilan. Pengguna memilih salah satu kategori kemudian akan ditampilkan daftar lelang sesuai kategori tersebut. Di halaman ini pengguna dapat melakukan pencarian lelang dengan memasukkan kata


(79)

kunci yang ingin dicari pada textfield yang berada di atas daftar lelang. Halaman daftar lelang ditunjukkan pada gambar 4.10.


(80)

57

BAB V

HASIL DAN PEMBAHASAN

Pada bab ini akan dipaparkan mengenai hasil dan analisa dari hasil percobaan yang telah dilakukan.

5.1. Uji Fungsional

Uji fungsional dilakukan untuk mengetahui apakah web dapat berjalan dengan baik sesuai dengan yang diharapkan. Pengujian dilakukan dengan memberikan berbagai macam masukkan pada setiap case. Dari situ akan dilihat apakah sistem dapat memberikan output sesuai yang diharapkan atau tidak.

5.1.1.Login

Skenario

Pengujian skenario login dilakukan dengan dua macam masukan. Masukan pertama berisi informasi login yang salah dan masukkan kedua berisi informasi login yang benar. Dari kedua masukan tersebut akan dilihat apakah luaran yang dihasilkan sesuai dengan yang diharapkan atau tidak.


(81)

Hasil Pengujian

Tabel 5.1. Hasil Pengujian Case Login

Keterangan Masukan Hasil yang diharap Hasil yang didapat

Input data yang benar User: ecx_q@yahoo. com Password: password

Sistem akan

memasukkan

pengguna ke dalam sistem kemudian kembali ke halaman awal.

Pengguna berhasil masuk ke dalam sisitem dan kembali ke halaman awal.

Input data yang salah

User:

asdf

Password:

asdf

Menampilkan pesan kesalahan kemudian kembali ke halaman awal.

Muncul pesan

kesalahan kemudian kembali ke halaman awal.

5.1.2.Buat Lelang

Skenario

Pengujian skenario buat lelang dilakukan dengan dua macam masukan. Masukan pertama berisi informasi barang yang valid dan masukkan kedua berisi informasi barang yang tidak valid. Dari kedua masukan tersebut akan dilihat apakah luaran yang dihasilkan sesuai dengan yang diharapkan atau tidak.


(82)

Hasil Pengujian

Tabel 5.2. Hasil Pengujian Case Buat lelang

Keterangan Masukan Hasil yang diharap Hasil yang didapat

Informasi barang valid Name: raket tenis Category: sport Detail:

raket tenis baru, murah Price: 300000 Start date: 2013-08-21 00:00:00 End date: 2013-08-31 00:00:00

Sistem akan

menyimpan masukan item da berpindah ke halaman input file gambar.

Sistem berhasil menyimpan item kemudian berpindah ke halaman input file gambar.


(83)

Keterangan Masukan Hasil yang

diharapkan

Hasil yang didapat

Input file gambar

File gambar Gambar tersimpan dan berpindah ke halaman barang yang telah dibuat.

Halaman berpindah ke halaman barang yang telah dibuat.

Informasi barang tidak valid Name: Category: antique Detail: Price: 0 Start date: End date:

Sistem akan

menampilkan pesan kesalahan.

Muncul pesan

kesalahan “required”.


(84)

5.1.3.Buat Penawaran

Skenario

Pengujian skenario buat penawaran dilakukan dengan dua macam masukan. Masukan pertama bernilai lebih kecil dari harga barang. Masukkan yang kedua bernilai lebih tinggi dari harga barang. Dari semua masukan tersebut akan dilihat apakah luaran yang dihasilkan sesuai dengan yang diharapkan atau tidak.

Hasil pengujian

Tabel 5.3. Hasil Pengujian Case Buat Penawaran Keterangan Masukan Hasil yang

diharapkan

Hasil yang didapat

Penawaran lebih kecil dari harga /

Bid: 1000 Sistem akan

menampilkan pesan kesalahan.

Muncul pesan

kesalahan penawaran terlalu kecil.

Penawaran lebih tinggi dari

harga /

penawaran terakhir.

Bid:300000 Sistem akan menampilkan

penawaran baru dan mengupdate

tampilan di semua pengguna.

Muncul penawaran

baru di semua


(85)

5.1.4.Edit Profile

Skenario

Pengujian skenario edit profile dilakukan dengan memasukkan informasi profile yang baru. Dari masukan tersebut akan dilihat apakah luaran yang dihasilkan sesuai dengan yang diharapkan atau tidak.

Hasil pengujian

Tabel 5.4. Hasil Pengujian Case Edit Profile

Keterangan Masukan Hasil yang

diharapkan

Hasil yang didapat

Input data baru User: ecx_q@yahoo.com First name: Benediktus Last name: Prabowo Address: Nglinggi Hometown: Klaten

Sistem akan menyimpan

data baru

kemudian berpindah ke tampilan profil yang sudah diedit.

Tampilan berpindah ke halaman profil dengan data baru.


(86)

Province:

Jawa Tengah

Phone number:

081514160412

Birth date:

1992-07-09

Sex:

Male

5.1.5.Logout

Skenario

Pengujian skenario logout dilakukan dengan menekan pilihan logout. Dari skenaro tersebut akan dilihat apakah sistem dapat mengeluarkan pengguna dari sistem.


(87)

Hasil pengujian

Tabel 5.5. Hasil Pengujian Case Logout

Keterangan Masukan Hasil yang

diharapkan

Hasil yang didapat

Menekan link logout

Link logout Sistem akan mngeluarkan pengguna dari dalam sistem kemudian kembali ke halaman awal.

Pengguna berhasil keluar dari dalam sisitem dan kembali ke halaman awal.

5.1.6.Cari Barang

Skenario

Pengujian skenario cari barang dilakukan dengan cara memilih kategori barang kemudian memasukkan kata kunci barang yang dicari. Dari masukkan tersebut akan dilihat apakah daftar barang yang ditampilkan sesuai dengan kata kunci yang dicari.


(88)

Hasil pengujian

Tabel 5.6. Hasil Pengujian Case Cari Barang

Keterangan Masukan Hasil yang

diharapkan

Hasil yang didapat

Masukan keyword

Keyword:

raket

Sistem akan

menampilkan semua

barang yang

mengandung kata ‘raket’.

Menampilkan semua barang dengan keyword raket.

5.1.7.Register

Skenario

Pengujian skenario register dilakukan dengan dua macam masukan. Masukan pertama berisi informasi data diri yang salah dan masukkan kedua berisi informasi data diri yang benar. Dari kedua masukan tersebut akan dilihat apakah luaran yang dihasilkan sesuai dengan yang diharapkan atau tidak.


(89)

Hasil Pengujian

Tabel 5.7. Hasil Pengujian Case Register

Keterangan Masukan Hasil yang

diharapkan

Hasil yang

didapat

Input data yang benar Emal: ekiprabowo@gmail. com Password: password Retype password: password First name: Beediktus Last name: Prabowo Address: Klaten Hometown:

Sistem akan menyimpan data

user baru

kemudian

berpindah ke halaman input file gambar.

Berpindah ke halaman input file gambar.


(90)

Klaten

Province:

Jawa tengah

Phone number:

085725630179

Birth date:

1992-07-07

Sex:

Male Input data

yang salah

Emal:

Password:

Retype password:

First name:

Last name:

Address:

Hometown:

Province:

Menampilkan pesan kesalahan.

Muncul pesan kesalahan.


(91)

Phone number:

Birth date:

Sex:

Dari tabel pengujian di atas dapat dilihat bahwa sistem dapat berjalan dengan baik di semua case. Sistem dapat memberikan tanggapan sesuai dengan masukan pengguna dengan benar. Dari semua case pengujian fungsional ini sistem dapat memberikan luaran sesuai dengan yang diharapkan.

5.2. Uji Non-Fungsional

5.2.1. Performa Sistem

Skenario

Pengujian dilakukan pada server yang memiliki spesifikasi prosesor Intel core i5 2.54 GHz dan ram 4 GB sedangkan komputer client masing – masing memiliki spesifikasi prosesor Intel core i3 3.3 GHz dan ram 2 GB. Pengujian dilakukan dengan jumlah client yang berbeda, pada pengujian pertama dilakukan dengan 20 (dua puluh) client dan 30 (tiga puluh) client pada pengujian kedua. Untuk setiap pengujian dilakukan 2 (dua) kali percobaan dengan jeda waktu setiap penawaran 1 detik. Setiap pengujian dilakukan dengan penawaran sebanyak sepuluh kali. Dari pengujian akan dihitung rata – rata waktu update yang didapatkan dari setiap pengujian.


(92)

Berikut ini merupakan variabel dan harapan hasil yang digunakan sebagai acuan dalam pengujian non-fungsional ini:

- Variabel yang diubah : Jumlah pengguna - Variabel yang diukur : Waktu update - Hasil yang diharapkan :

1. Data penawaran terbaru berubah di setiap user.

2. Waktu update yang diterima user kurang dari 1 detik dari waktu input.

Pengambilan data waktu update dilakukan dengan melihat waktu yang tertera pada halaman website. Waktu pengguna memasukkan penawaran akan dicatat, begitu juga setiap kali terjadi perubahan data, waktu akan dicatat ketika terjadi perubahan tersebut. Dari waktu update yang didapat akan diketahui berapa selisih waktu antara input penawaran dengan update yang diterima dari setiap pengguna.

Berikut ini merupakan tabel hasil pengujian yang menampilkan waktu input penawaran dan waktu pengguna mendapat update:


(93)

Tabel 5.8. Hasil Pengujian 20 Pengguna PC 1 – 10 (Percobaan 1)

Tabel 5.9. Hasil Pengujian 20 Pengguna PC 11 - 20 (Percobaan 1)


(94)

Tabel 5.11. Hasil Pengujian 20 Pengguna PC 11 – 20 (Percobaan 2)

Tabel 5.12. Hasil Pengujian 30 Pengguna PC 1 – 10 (Percobaan 1)


(95)

Tabel 5.14. Hasil Pengujian 30 Pengguna PC 21 – 30 (Percobaan 1)

Tabel 5.15. Hasil Pengujian 30 Pengguna PC 1 – 10 (Percobaan 2)


(96)

Tabel 5.17. Hasil Pengujian 30 Pengguna PC 21 – 30 (Percobaan 2)

Tabel 5.8. sampai 5.17. merupakan tabel pengujian yang berisi data waktu input dan waktu pengguna mendapatkan update, data waktu yang disimpan dalam tabel tersebut memiliki format jam:menit:detik. Kolom “waktu input” menyimpan data waktu ketika pengguna (PC 1) memasukkan penawaran, kemudian kolom “waktu mendapatkan update” merupakan kolom yang menyimpan waktu dimana pengguna menerima update penawaran. Kolom “waktu mendapat update” terbagi menjadi beberapa sub-kolom yang berjumlah sesuai dengan jumlah pengguna aktif yang ditandai dengan label “PC 1” sampai dengan “PC n”, setiap kolom pengguna menyimpan waktu update ketika pengguna tersebut menerima update.

Tabel pengujian di atas menunjukkan waktu input dan waktu mendapat update dari masing – masing pengguna. Dari tabel di atas terlihat aplikasi dapat bekerja dengan baik pada setiap pengujian baik pada pengujian dengan 20 pengguna maupun 30 pengguna.

Untuk mengetahui waktu yang dibutuhkan dalam mengupdate penawaran maka akan dihitung rata – rata waktu update setiap penawaran. Berikut ini merupakan tabel selisih waktu dan rata – rata waktu update setiap penawaran dari pengujian dengan prosesor i5:


(97)

Tabel 5.18. Selisih Waktu Update 20 Pengguna PC 1 – 10 (Percobaan 1)


(98)

Tabel 5.20. Selisih Waktu Update 20 Pengguna PC 1 – 10 (Percobaan 2)


(99)

Tabel 5.22. Selisih Waktu Update 30 Pengguna PC 1 – 10 (Percobaan 1)


(100)

Tabel 5.24. Selisih Waktu Update 30 Pengguna PC 21 – 30 (Percobaan 1)


(1)

Gambar 5.3. Daftar Penawaran Barang Dengan id_item itm10000000020 Gambar 5.3. merupakan hasil capture screen dari data yang terdapat dalam database. Gambar tersebut memperlihatkan semu data penawaran 1 sampai 20 dengan id_item ‘itm10000000020’.

Dari gambar 5.1. sampai gambar 5.3. dapat dilihat halaman web dapat

menampilkan semua penawaran yang dilakukan oleh kedua pengguna (terlihat pada gambar 5.1. dan gambar 5.2.), sesuai dengan data yang terdapat dalam database (gambar 5.3.) yang berarti web telah memenuhi unsur transparency dan pemenang lelang yang ditampilkan sesuai dengan pemenang lelang yang seharusnya, hal tersebut telah memenuhi unsur fairness.


(2)

84

BAB VI

PENUTUP

Pada bab ini akan disajikan kesimpulan dan saran dari hasil analisis implementasi permasalahan pada bab sebelumnya. Berdasarkan kesimpulan yang diperoleh, kemudian akan dikemukakan saran-saran yang diharapkan dapat bermanfaat.

6.1. Kesimpulan

Dari penelitian yang dilakukan, dapat disimpulkan bahwa:

1. Penelitian ini berhasil membangun sebuah aplikasi Web lelang barang interaktif dengan menggunakan komponen ICEfaces ajax push. Aplikasi telah diuji pada server dengan spesifikasi prosesor Interl core I5 2.54 GHz dengan ram 4 GB dan menggunakan client dengan spesifikasi prosesor Intel core i3 dengan ram 2 GB. Aplikasi berhasil menampilkan data secara real-time dengan rata rata waktu update 0.4 detik pada 20 client dan 0.615 detik pada 30 client. Aplikasi dapat menangani inputan dengan jeda waktu 1 detik dan dapat memberikan update penawaran pada 30 pengguna.

2. Masalah transparancy dan fairness telah berhasil ditangani dengan cara menampilkan seluruh data penawaran barang pada halaman lelang barang.


(3)

6.2. Saran

Saran untuk pengembangan sistem yang akan datang yaitu:

1. Perancangan sistem selanjutnya dapat menggunakan mekanisme lain selain long-polling.

2. Perancangan sistem dapat menggunakan komponen lain selain ICEfaces.

3. Penelitian dapat dilakukan dengan melakukan perbandingan antara komponen – komponen yang berbeda.


(4)

86

DAFTAR PUSTAKA

_________. Kamus Besar Bahasa Indonesia (KBBI). From http://kbbi.web.id/lelang, 8 November 2012.

Burns, Ed, Chris Schalk & Neil Griffin (2010). JavaServer Faces 2.0: The

Complete Reference. Indianapolis:McGraw-Hill Education.

Easley, David, & Jon Kleinberg (2010). Networks, Crowds, and Markets:

Reasoning about Highly Connected World. England : Cambridge

University Press.

Fyten, Ken (2012). Getting Started with ICEfaces 3. Dari http://www.icesoft.org/wiki/display/ICE/Getting+Started+with+ICEfaces +3, 22 Juli 2013.

Jamsa, Kris, Konrad King & Andy Anderson (2002). HTML & Web Design Tips & Techniques. New York : McGraw-Hill/Osborne.

Kopetz, Hermann (2011). Real-Time System:Design Principles for

Distributed Emberdded Applications. New York : Springer Science+Business Media.

Lengstorf, Jason, & Phil Leggetter (2013). Realtime Web Apps: With HTML5

WebSocket, PHP, and jQuery. New York : Springer Science+Business

Media.

Musciano, Chuck, & Bill Kennedy (1998). HTML:The Definitive Guide, 3rd


(5)

Nasser, Feras (2012). Ajax Push Overview. Dari

http://www.icesoft.org/wiki/display/ICE/Ajax+Push+-+Overview, 11


(6)

88

LAMPIRAN