Anotasi tersebut mengatur metadata khusus yang ditanamkan java compiler ke kelas yang dihasilkan. Server akan membaca anotasi kemudian anotasi akan mengarahkan server untuk menggunakan kelas tersebut.
2.6. ICEFaces Framework
ICEFaces merupakan sebuah Rich Internet Application (RIA) development framework yang berdasar pada JavaServer Faces(JSF) 2 standar. ICEFaces memperluas kemampuan JavaServer Faces untuk menyederhanakan pengembangan dan meningkatkan fitur standar JSF sekaligus meningkatkan efisiensi developer dan memperluas kemampuan RIA yang dapat dimasukkan dalam aplikasi web berbasis JSF. ICEFaces memiliki kemampuan di atas JSF standar, terutama dua pada dua tambahan yaitu Automatic AJAX dan AJAX Push.
21
- AJAX Push
Ajax push memungkinkan aplikasi untuk secara bertahap memperbarui halaman setiap saat. Ajax push pada icefaces memanfaatkan mekanisme pemberitahuan asynchronous yang disebut icepush. Icepush menggunakan long-polling untuk memfasilitasi pemberitahuan asynchronous melalui HTTP standar. Urutan peristiwa yang terjadi dalam ajax push digambarkan sebagai berikut:
Gambar 2.5. Ajax Push
1. Perubahan kondisi aplikasi memicu event ajax push. 2. Server mengirimkan pemberitahuan ke browser.
3. Notifikasi pada browser menyebabkan browser mengirim ajax request ke server.
4. Server menangkap kondisi baru pada client dan direct-to-DOM (mekanisme yang membuat komponen JSF menjadi standar W3C DOM) memberikan update halaman kepada client.
22 BAB III
ANALISIS DAN PERANCANGAN
Pada metodologi penelitian ini akan dibahas deskripsi dari aplikasi yang akan dibuat, analisis masalah dan perancangan sistem yang akan dibuat.
3.1. Deskripsi Umum Aplikasi
Untuk melakukan transaksi lelang, orang – orang harus hadir dan berkumpul di suatu tempat yang telah disepakati untuk melakukan transaksi lelang barang. Dengan semakin berkembangnya teknologi dan internet sangat dimungkinkan untuk kita dapat bertransaksi lelang dengan media tersebut. Dengan demikian setiap peserta lelang dapat melakukan pelelangan dari tempat yang jauh dan berbeda – beda.
Aplikasi yang akan dibuat adalah aplikasi web lelang barang real-time. Server akan memberikan update penawaran terbaru sesuai dengan masukan pengguna selama waktu lelang belum selesai. Server akan mengirimkan data penawar, harga penawaran, dan waktu penawaran.
23
3.2. Analisis Masalah
3.2.1. Sistem Lelang Konvensional
Dalam sistem lelang konvensional, lelang dilakukan di hadapan banyak orang yang berkumpul di dalam satu ruangan. Lelang dipimpin oleh pejabat lelang, untuk mendapatkan barang yang dilelang peserta harus melakukan penawaran. Peserta lelang akan melakukan penawaran yang saling mengatasi dari penawaran peserta lain. Lelang selesai jika sudah didapatkan penawar tertinggi atau jika waktu lelang sudah habis.
3.2.2. Gambaran Sistem Yang Dikembangkan
Untuk mempermudah transaksi lelang, maka akan dibuat sistem baru yaitu sebuah Web Lelang Barang. Sistem ini digunakan untuk memfasilitasi transaksi lelang barang baik sebagai penjual maupun pembeli. Sistem ini akan memberikan update penawaran terbaru secara real-time agar memudahkan peserta dalam menentukan penawaran yang akan dilakukan dan memudahkan penjual dalam memantau harga barang.
Untuk dapat menjual atau melelang barang, pengguna harus terdaftar dalam sistem ini. Pengunjung dapat melakukan registrasi dengan mengisikan data diri yang dibutuhkan. Untuk dapat menjual barang member harus login terlebih dahulu kemudian mengisikan data barang yang akan dilelang. Demikian pula untuk melakukan penawaran, member harus login kemudian masuk ke halaman barang yang diinginkan kemudian memasukkan penawaran.
Orang yang Terlibat dalam sistem: 1. Member
Member adalah orang yang telah mendaftar dalam sistem. Member dapat memiliki 2 peranan yaitu:
- Penjual
Orang yang menjual barang. - Pembeli
Orang yang melakukan penawaran. 2. Pengunjung
Pengunjung merupakan pengguna web yang bukan member.
Proses yang menjadi fitur utama sistem ini merupakan proses membuat penawaran yang dilakukan oleh member yang berperan sebagai pembeli. Gambaran umum proses membuat penawaran dan arsitektur sistem dapat dilihat pada gambar 3.1. dan gambar 3.2.
25
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
Deskripsi: member memasukkan data barang yang akan dilelang
27
Buat penawaran Aktor: Member
Deskripsi: member memasukkan penawaran Cari barang Aktor: Member & Pengunjung
Deskripsi: member memilih barang berdasarkan kategori, masukkan nama barang yang dicari
Edit Profil Aktor: Member
Deskripsi: member memilih profil kemudian memasukkan data baru
Register Aktor: Pengunjung
Deskripsi: pengunjung memilih register kemudian memasukkan data
Edit Lelang Aktor: Member
Deskripsi: member memilih lekang kemudian memasukkan data baru
3.3.3. Skenario
1. Nama Use Case : Login Aktor : Pengunjung
Tabel 3.2. Skenario Use Case Login
Aksi Aktor Reaksi Sistem
Skenario Normal
1. Memasukkan user name dan password yang benar
2. Membuat session dan user akan masuk dalam sistem
Skenario Alternatif
1. Memasukkan user name dan password salah
2. Menampilkan pesan user name atau password salah
2. Nama Use Case : Buat Lelang Aktor : Member
Tabel 3.3. Skenario Use Case Buat Lelang
Aksi Aktor Reaksi Sistem
Skenario Normal
1. memilih pilihan “Sell”
2. menampilkan form barang 3. mengisi form barang &
pilih buat lelang
4. menyimpan ke database kemudian menampilkan halaman input file gambar 5. memilih gambar kemudian
pilih save
6. menyimpan gambar kemudian menampilkan pemberitahuan file berhasil disimpan
7. pilih finish
8. menampilkan halaman barang
Skenario Alternatif
3. mengisi form tidak lengkap/tidak sesuai
29
4. menampilkan pesan kesalahan
5. memilih file bukan gambar
6. menampilkan pemberitahuan file salah
3. Nama Use Case : Buat Penawaran Aktor : Member
Tabel 3.4. Skenario Use Case Buat Penawaran
Aksi Aktor Reaksi Sistem
Skenario Normal
1. memilih barang yang akan dilelang
2. menampilkan halaman barang
3. memasukkan penawaran kemudian klik “Bid”
4. menyimpan penawaran dalam database kemudian menampilkan penawaran terbaru
Skenario Alternatif
3. memasukkan bid lebih rendah dari penawaran kemudian klik “Bid”
4. menampilkan pesan kesalahan
4. Nama Use Case : Edit Profile Aktor : Member
Tabel 3.5. Skenario Use Case Edit Profile
Aksi Aktor Reaksi Sistem
Skenario Normal 1. pilih “Account”
2. menampilkan halaman profile member
3. pilih edit
4. menampilkan form edit 5. mengisi form edit kemudian
pilih simpan
6. menyimpan data baru kemudian menampilkan halaman profile yang baru Skenario Alternatif
5. mengisi form dengan tidak benar kemudian pilih simpan
6. menampilkan pesan kesalahan
31
5. Nama Use Case : Cari Barang Aktor : Pengunjung & Member
Tabel 3.6. Skenario Use Case Cari barang
Aksi Aktor Reaksi Sistem
Skenario Normal
1. pilih kategori barang yang ingin dicari
2. menampilkan semua barang dengan kategori yang dipilih 3. masukkan kata kunci
barang yang ingin dicari
4. menampilkan semua barang yang mengandung kata kunci yang dicari
Nama Use Case : Register Aktor : Pengunjung
Tabel 3.7. Skenario Use Case Register
Aksi Aktor Reaksi Sistem
Skenario Normal 1. pilh register
2. menampilkan halaman registrasi
3. mengisi form registrasi kemudian pilih daftar
4. menyimpan data yang diinputkan kemudian menampilkan halaman form input gambar
5. memilih gambar kemudian save
6. menyimpan gambar kemdian menampilkan pesan gambar berhasil disimpan
7. pilih finish
8. menampilkan halaman profile
Skenario Alternatif
3. mengisi form dengan tidak benar
4. menampilkan pesan kesalahan
5. memilih file bukan gambar
6. menampilkan pesan kesalahan
7. Nama Use Case : Edit Lelang Aktor : Member
Tabel 3.8. Skenario Use Case Edit Lelang
Aksi Aktor Reaksi Sistem
Skenario Normal
1. pilih lelang yang akan di edit
2. menampilkan halaman lelang barang
3. pilih edit
4. menampilkan form edit 5. mengisi form edit kemudian
33
6. menyimpan data baru kemudian menampilkan halaman profile yang baru Skenario Alternatif
6. mengisi form dengan tidak benar kemudian pilih simpan
7. menampilkan pesan kesalahan
Berikut ini langkah – langkah yang akan dilakukan dlam perancangan database yaitu: 3.3.4.1.Conceptual Database Design
35
3.3.4.2. Logical Database Design
Gambar 3.5. Logical Design
3.3.4.3. Physical Database Design
Desain basis data yang akan digunakan dalam web lelang barang dapat dijabarkan sebagai berikut:
1. Tabel member
Nama tabel : member Nama field kunci : email
Tabel ini berisi sejumlah field yang dijelaskan pada tabel berikut:
Tabel 3.9. Tabel Member Nama Field Tipe Data Ukuran Keterangan
Email varchar 50 e-mail pengguna sebagai field kunci tabel
first_name varchar 50 Nama depan member last_name varchar 50 Nama belakang member Password varchar 50 Password untuk login
Address varchar 100 Alamat
hometown varchar 50 Kota
Province varchar 50 Provinsi
Phone varchar 15 Nomer telepon
birth_date date Tanggal lahir
join_date date Menyimpan tanggal member
mendaftar
Sex varchar 6 Jenis kelamin
Pict varchar 50 Menyimpan lokasi file gambar
2. Tabel category
Nama tabel : category Nama field kunci : id_category
Tabel ini berisi sejumlah field yang dijelaskan pada tabel berikut:
37
Tabel 3.10. Tabel Category Nama Field Tipe Data Ukuran Keterangan
id_category varchar 5 id_category sebagai field kunci tabel
Name varchar 50 Nama kategori
3. Tabel item
Nama tabel : item Nama field kunci : id_item
Tabel ini berisi sejumlah field yang dijelaskan pada tabel berikut:
Tabel 3.11. Tabel Item Nama Field Tipe Data Ukuran Keterangan
id_item varchar 20 Id_item sebagai field kunci tabel
Name varchar 50 Nama barang
Price int 11 Harga penawaran
create_date datetime Tanggal lelang dibuat start_date datetime Waktu mulai lelang end_date datetime Waktu selesai lelang
Detail text Detail barang yang dilelang
id_category varchar 5 Sebagai foreign key dari tabel category
Email varchar 50 Sebagai foreign key dari tabel member
4. Tabel picture
Nama tabel : picture Nama field kunci : no
Tabel ini berisi sejumlah field yang dijelaskan pada tabel berikut:
Tabel 3.12. Tabel Picture Nama Field Tipe Data Ukuran Keterangan
No int 11 no sebagai field kunci tabel
file_location varchar 50 Lokasi file disimpan id_item varchar 15 Foreign key dari tabel item
5. Tabel bid
Nama tabel : bid Nama field kunci : no
Tabel ini berisi sejumlah field yang dijelaskan pada tabel berikut:
Tabel 3.13. Tabel Bid Nama Field Tipe Data Ukuran Keterangan
No int 11 No sebagai field kunci tabel
Time varchar 25 Waktu member melakukan
penawaran
Bid int 50 Nilai penawaran member
id_item varchar 11 Sebagai foreign key dari tabel item
39
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
Halaman ini merupakan halaman lelang yang memuat informasi penawaran yang meliputi pelelang, penawaran dan waktu penawaran. Pada tampilan ini pengguna dapat memasukkan penawaran pada field yang disediakan.
41
Gambar 3.8. Rancangan Tampilan Halaman Lelang 3.3.5.4.Halaman Registrasi
Halaman ini merupakan halaman registrasi yang digunakan pengguna untuk melakukan registrasi/pendaftaran untuk dapat bertransaksi menggunakan web lelang. Pengguna harus mengisi informasi yang dibutuhkan untuk dapat mendaftar.
Gambar 3.9. Rancangan Tampilan Halaman Registrasi 3.3.5.5.Halaman Profile
Halaman ini merupakan halaman profile yang berisi informasi dari member.
43
3.3.5.6.Halaman Hasil Pencarian
Halaman ini merupakan halaman hasil pencarian yang menampilkan semua hasil yang sesuai dengan kata kunci dari pencarian yang dilakukan pengguna
Gambar 3.11. Rancangan Tampilan Halaman Hasil Pencarian
3.3.5. Cara Pengujian dan Analisa Hasil
Pengujian akan dilakukan dengan melakukan percobaan terhadap aplikasi web yang telah dibuat dengan cara memberikan inputan nilai lelang secara berkala dan dalam rentang waktu tertentu. Pengujian dilakukan pada dua server yang berbeda dan dengan kemampuan prosesor yang juga berbeda. Pengujian untuk setiap server dilakukan beberapa kali dengan jumlah client yang berbeda – beda. Untuk setiap pengujian akan dicatat kecepatan server dalam mengirimkan data dan cpu ussagenya.
Pada proses analisa, data yang telah didapatkan pada proses pengujian akan dianalisa apakah prosesor berpengaruh pada performa sistem yang dibangun, seberapa cepat server dapat menyampaikan data baru kepada client. Untuk melihat apakah prosesor berpengaruh atau tidak akan dilihat dari cpu ussage dari masing – masing prosesor. Kemudian untuk kecepatan dapat dilihat dari rata – rata selisih waktu antara input dengan refresh data baru.
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 NetbeansIDE 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