• Tidak ada hasil yang ditemukan

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

Dokumen terkait