• Tidak ada hasil yang ditemukan

Implementasi web lelang barang dengan pendekatan teknologi AJAX Push.

N/A
N/A
Protected

Academic year: 2017

Membagikan "Implementasi web lelang barang dengan pendekatan teknologi AJAX Push."

Copied!
111
0
0

Teks penuh

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

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

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

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

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

(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

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

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

(23)

xix

DAFTAR QUERY

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

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

(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

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

(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

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

(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

(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

(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

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

(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

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

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

(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

(42)

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;

}

}

(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

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

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

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

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

(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

(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

(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

(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

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

(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

(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

(55)

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

(56)

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

6. mengisi form dengan tidak benar kemudian pilih simpan

(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

(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

(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

(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

(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

(64)

Gambar 3.8. Rancangan Tampilan Halaman Lelang

3.3.5.4.Halaman Registrasi

(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

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

(72)

Gambar 4.1. Implementasi Halaman Utama

4.3.2.Halaman Registrasi

(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

(75)

Gambar 4.5. Implementasi Halaman Edit Profil

4.3.5.Halaman Buat Lelang

(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

(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

(81)

Hasil Pengujian

Tabel 5.1. Hasil Pengujian Case Login

Keterangan Masukan Hasil yang diharap Hasil yang didapat

Input data

(82)

Hasil Pengujian

Tabel 5.2. Hasil Pengujian Case Buat lelang

Keterangan Masukan Hasil yang diharap Hasil yang didapat

(83)

Keterangan Masukan Hasil yang

diharapkan

Hasil yang didapat

Input file gambar

(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 lebih tinggi dari

harga /

penawaran terakhir.

(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

(86)

Province:

Jawa Tengah

Phone number:

081514160412

Birth date:

1992-07-09

Sex:

Male

5.1.5.Logout

Skenario

(87)

Hasil pengujian

Tabel 5.5. Hasil Pengujian Case Logout

Keterangan Masukan Hasil yang

diharapkan

(88)

Hasil pengujian

Tabel 5.6. Hasil Pengujian Case Cari Barang

Keterangan Masukan Hasil yang

diharapkan barang dengan keyword raket.

5.1.7.Register

Skenario

(89)

Hasil Pengujian

Tabel 5.7. Hasil Pengujian Case Register

Keterangan Masukan Hasil yang

(90)
(91)

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

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

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

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

(101)

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)

(102)

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

(103)

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

(104)

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

(105)

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

(106)

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

(107)

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

(108)

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.

(109)

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.

(110)
(111)

88

LAMPIRAN

Gambar

Gambar 2.1. Web Server
Gambar 2.2. Simulasi Polling
Gambar 2.3. Simulasi HTTP Long – Polling
Gambar 2.4. Simulasi HTTP Streaming
+7

Referensi

Dokumen terkait

Bab ini menguraikan landasan teori yang akan digunakan sebagai acuan dasar bagi penelitian, khususnya mengenai pengaruh kepemilikan manajerial,

Tujuan penelitian ini adalah (1) untuk mendeskripsikan nilai pendidikan karakter yang berkaitan dengan ketuhanan, (2) untuk mendeskripsikan nilai pendidikan karakter yang

Aku menjahit kain putih berenda Bukan untuk menghias peti matimu Tapi untuk menutup atas kepala kita Saat hari ijab qobul yang kau janjikan… Sapu tangan ini kuambil dari sakumu

- Dalam Negara yang berbentuk Republik dengan sistim demokrasi, maka mempertahankan kekuasaan atas Negara itu dilakukan melalui sistim pemilu yang

Konversi karbohidrat dalam pati ubi gadung menjadi LA digunakan suatu katalis yaitu asam sulfat untuk mempercepat reaksi- nya seperti pada penelitian-penelitian yang

Dapat dilihat bahwa di setiap saat, grafik amplitudo sel[1,1] pada simulasi tanpa anomali (warna merah) selalu lebih tinggi daripada grafik simulasi dengan anomali.

Setiap kelasnya memiliki kapasitas maksimal 15 orang. Dengan sistem pelatihan di kelas diawali dengan pengantar berupa teori singkat tarian yang akan diajarkan kemudian

Penyimpangan tersebut yaitu: penanganan sampah, limbah dan peralatan tidak baik, di lokasi TPI dan lingkungan masih terdapat sampah berserakan; sistem pembuangan