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.
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.
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
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
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”
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
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,
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.
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.
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.
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
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
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
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
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
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
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
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
Tabel 5.11. Hasil Pengujian 20 Pengguna PC 11 – 20 (Percobaan 2) ... 71
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
xviii
DAFTAR LIST
xix
DAFTAR QUERY
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.
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.
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.
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
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.
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
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.
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
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)
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.
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
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
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
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.
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
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.
<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>
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
import javax.faces.bean.ManagedBean;
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;
}
}
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
- 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.
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.
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.
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.
Gambar 3.1. Skema Proses Lelang
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
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
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
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
3. memasukkan bid lebih rendah dari penawaran kemudian klik “Bid”
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
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
5. memilih gambar kemudian save
6. menyimpan gambar kemdian menampilkan pesan gambar
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
6. menyimpan data baru kemudian menampilkan halaman profile yang baru Skenario Alternatif
6. mengisi form dengan tidak benar kemudian pilih simpan
Berikut ini langkah – langkah yang akan dilakukan dlam perancangan database yaitu:
3.3.4.1.Conceptual Database Design
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 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 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
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
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.
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
Gambar 3.8. Rancangan Tampilan Halaman Lelang
3.3.5.4.Halaman Registrasi
Gambar 3.9. Rancangan Tampilan Halaman Registrasi
3.3.5.5.Halaman Profile
Halaman ini merupakan halaman profile yang berisi informasi dari member.
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
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
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;
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;
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
Gambar 4.1. Implementasi Halaman Utama
4.3.2.Halaman Registrasi
Gambar 4.2. Implementasi Halaman Registrasi
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
Gambar 4.5. Implementasi Halaman Edit Profil
4.3.5.Halaman Buat Lelang
Gambar 4.6. Implementasi Halaman Buat Lelang
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.
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
kunci yang ingin dicari pada textfield yang berada di atas daftar lelang. Halaman daftar lelang ditunjukkan pada gambar 4.10.
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
Hasil Pengujian
Tabel 5.1. Hasil Pengujian Case Login
Keterangan Masukan Hasil yang diharap Hasil yang didapat
Input data
Hasil Pengujian
Tabel 5.2. Hasil Pengujian Case Buat lelang
Keterangan Masukan Hasil yang diharap Hasil yang didapat
Keterangan Masukan Hasil yang
diharapkan
Hasil yang didapat
Input file gambar
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 lebih tinggi dari
harga /
penawaran terakhir.
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
Province:
Jawa Tengah
Phone number:
081514160412
Birth date:
1992-07-09
Sex:
Male
5.1.5.Logout
Skenario
Hasil pengujian
Tabel 5.5. Hasil Pengujian Case Logout
Keterangan Masukan Hasil yang
diharapkan
Hasil pengujian
Tabel 5.6. Hasil Pengujian Case Cari Barang
Keterangan Masukan Hasil yang
diharapkan barang dengan keyword raket.
5.1.7.Register
Skenario
Hasil Pengujian
Tabel 5.7. Hasil Pengujian Case Register
Keterangan Masukan Hasil yang
Phone number: 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
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.
Tabel 5.8. Hasil Pengujian 20 Pengguna PC 1 – 10 (Percobaan 1)
Tabel 5.9. Hasil Pengujian 20 Pengguna PC 11 - 20 (Percobaan 1)
Tabel 5.11. Hasil Pengujian 20 Pengguna PC 11 – 20 (Percobaan 2)
Tabel 5.12. Hasil Pengujian 30 Pengguna PC 1 – 10 (Percobaan 1)
Tabel 5.14. Hasil Pengujian 30 Pengguna PC 21 – 30 (Percobaan 1)
Tabel 5.15. Hasil Pengujian 30 Pengguna PC 1 – 10 (Percobaan 2)
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.
Tabel 5.18. Selisih Waktu Update 20 Pengguna PC 1 – 10 (Percobaan 1)
Tabel 5.20. Selisih Waktu Update 20 Pengguna PC 1 – 10 (Percobaan 2)
Tabel 5.22. Selisih Waktu Update 30 Pengguna PC 1 – 10 (Percobaan 1)
Tabel 5.24. Selisih Waktu Update 30 Pengguna PC 21 – 30 (Percobaan 1)
Tabel 5.26. Selisih Waktu Update 30 Pengguna PC 11 – 20 (Percobaan 2)
Tabel 5.27. Selisih Waktu Update 30 Pengguna PC 21 – 30 (Percobaan 2)
Sebagai contoh kita ambil data dari tabel 5.18. pada penawaran pertama terdapat data sebagai berikut:
Data tersebut berasal dari selisih waktu update dengan waktu input penawaran pertama pada tabel 5.8.
Tabel 5.28. Performa Aplikasi Web Lelang Jeda
waktu
penawaran
Jml
pengguna
Rata – rata waktu update Jumlah yang berhasil
Tabel 5.29. Hasil Pengujian Non-Fungsional
update kurang dari 1 detik
update kurang dari 5 detik
- semua pengguna mendapat update - rata – rata waktu update 0.615 detik
Dari pengujian yang telah dilakukan didapatkan kemampuan yang didapatkan setelah pengujian adalah server mampu menangani input penawaran dengan jeda waktu setiap penawaran 1 detik dan dapat menangani 30 pengguna pada prosesor Intel core i5. Untuk jeda waktu yang lebih kecil dan jumlah pengguna yang lebih banyak belum dapat diuji karena berbagai keterbatasan.
5.2.2. Fairness dan Transparency Skenario
Pengujian fairness dan transparency dilakukan dengan melakukan penawaran pada barang tertentu. Penawaran akan dilakukan oleh 2 pengguna dimana masing masing pengguna melakukan 10 penawaran. Dari skenario tersebut akan dilihat apakah setiap penawaran ditampilkan dan setelah lelang berakhir akan dilihat apakah pemenang lelang sesuai dengan yang seharusnya.
Hasil Pengujian
Gambar 5.1. merupakan hasil capture screen yang memperlihatkan data penawaran 1 sampai 10 dari pengujian yang ditampilkan dalam halaman lelang.
Gambar 5.2. Daftar Penawaran 11 Sampai 20
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
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
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.
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.
88
LAMPIRAN