3. Metodologi Perancangan
Metode perancangan yang digunakan pada pembuatan aplikasi ini yaitu model prototyping. Model prototyping merupakan proses untuk membangun
sebuah model dari sebuah sistem berdasarkan kebutuhan user. Pengembangan sistem berdasarkan model ini digunakan jika informasi tentang masukan, proses
dan detail keluaran tidak dijelaskan dengan detail. Alur model protoyping akan digambarkan seperti pada Gambar 1.
Gambar 1
Prototyping Model
Tahapan metode prototyping dalam penelitian ini, dijelaskan sebagai berikut. Tahap Listen to Customer diawali dengan proses komunikasi untuk
menentukan dan mengkaji kapabilitas yang akan diperlukan dan dimiliki oleh sistem berdasarkan latar belakang masalah yang ada. Pada penelitian ini dilakukan
wawancara dengan Hari Sunarto selaku pakar informasi lelang, untuk mendapatkan kebutuhan user berdasarkan proses bisnis yang ada. Kebutuhan user
tersebut antara lain, penjual dapat melakukan pengaturan terhadap komoditi yang dimiliki sepert edit dan hapus data. Penjual tidak mempunyai hak untuk
menambah data komoditi karena setiap penjual yang ingin menjual komoditi yang dimiliki harus memperlihatkan contoh komoditi tersebut ke kantor penyelenggara
lelang agar dapat dipastikan jenis dan kualitasnya. Penjual hanya dapat melakukan beberapa perubahan informasi komoditi. Selain itu penjual juga dapat melihat
transaksi penjualan komoditi. Kemudian pembeli dapat mengikuti setiap sesi lelang dan menawar komoditi. Pembeli dapat menawar lebih dari satu komoditi
yang akan disesuaikan dengan deposit yang dimiliki. Jika jumlah deposit kurang dari harga tawaran, maka pembeli tidak dapat melakukan penawaran. Pembeli
dapat membatalkan harga tawaran komoditi, jika waktu sesi lelang belum berakhir. Pembeli juga dapat melihat transaksi penawaran dan pembelian
komoditi. Sedangkan Administrator dapat melakukan pengaturan terhadap komoditi add, edit, delete, jadwal sesi lelang dan hari libur.
Tahapan kedua yaitu BuildRevise Mock-Up. Dalam tahapan ini akan dilakukan pemodelan informasi-informasi yang didapat dari proses sebelumnya.
Pemodelan yang dibuat menggunakan diagram-diagram UML. Pemodelan
sederhana yang dilakukan akan menjadi acuan sementara untuk pengembangan sistem dalam proses pengkodean.
Tahapan berikutnya yaitu Customer Test-Drives Mock-Up. Pada tahap ini hasil pengkodean dari tahap 2 dua akan dikomunikasikan kembali kepada
customer untuk mencari kekurangan-kekurangan yang ada. Hasilnya akan
dievaluasi kembali, jika masih ada yang belum sesuai dengan keinginan customer maka akan kembali ke tahap sebelumnya yaitu tahap buildrevise mock-up.
Analisis Sistem
Aplikasi bursa komoditi online merupakan sistem lelangpenawaran komoditi yang dilakukan secara online. Pada sistem ini akan melibatkan beberapa
entitas, yang meliputi Penjual perorangan instansi, Pembeli perorangan, perusahaan, badan usaha atau instansi, Perbankan, dan Pengelola Lelang badan
hukum yang sudah dibentuk. Penjual dan pembeli diwajibkan untuk melakukan registrasi pendaftaran terlebih dahulu untuk menjadi anggota member. Setiap
anggota akan diberikan password yang akan digunakan untuk masuk login ke dalam aplikasi.
Setelah login, pertama kali member harus melakukan verifikasi akun untuk melengkapi berkas-berkas yang diperlukan agar status keanggotaannya dapat
diaktifkan. Setelah semua berkas yang dibutuhkan terpenuhi maka masing-masing member
dapat melakukan aktifitas sesuai dengan hak akses masing-masing. Perbankan dalam hal ini bertanggung jawab dalam pemasukan deposit yang
dimiliki oleh Pembeli pada setiap sesi lelang. Pengelola lelang adalah yang bertanggung jawab terhadap keseluruhan rangkaian proses di dalam pelelangan.
Metode penyerahan barang yang digunakan dalam sistem ini menggunakan metode forward dengan menggunakan model sesi lelang. Sesi
lelang dapat diatur sesuai ketentuan yang ditetapkan sesuai aturan Pengelola Lelang. Pemenang lelang adalah pembeli dengan harga penawaran tertinggi
untuk total penawaran setiap komoditi pada setiap sesi lelang. Dimana setiap pemenang lelang akan mendapat pesan inbox yang menyatakan pembeli tersebut
sebagai pemenang lelang. Sistem ini merupakan sistem yang terpisah antara satu dengan yang lainnya, sehingga dibagi ke dalam beberapa modul, yaitu modul
Price Discovery
, Kliring, Resi Gudang dan Administrator. Sedangkan dalam sistem ini hanya akan dijabarkan mengenai modul Price Discovery pada saat
proses penawaran komoditi berlangsung.
Gambar 2 merupakan proses pembentukan price discovery pada aplikasi bursa komoditi.
Gambar 2 Proses Pembentukan Price Discovery
Proses pembentukan price discovery pada aplikasi bursa komoditi dijelaskan sebagai berikut. Penjual terlebih dahulu mendaftarkan komoditi yang
dimiliki, yang nantinya akan dilelang di bursa komoditi, dengan terlebih dahulu menentukan harga jual dan harga dasar yang diinginkan. Setelah komoditi
tersebut di jual di bursa komoditi, maka pembeli dapat melakukan penawaran. Pelelangan komoditi dibagi ke dalam dua 2 sesi, sesi pertama dimulai dari jam
09:00-12:00 dan sesi kedua dimulai dari jam 13:00-16:00. Lelang akan dimulai dari harga terendah dan akan terus naik sampai hanya ada satu penawar terakhir
yang akan jadi pemenang lelang english auction. Pada saat sesi lelang aktif, maka pembeli dapat melakukan penawaran. Akan tetapi ada beberapa aturan yang
harus dipahami agar dapat melakukan penawaran, yaitu : Harga Tawaran harus lebih besar dari Harga Jual, jika hal ini terpenuhi maka harga tawaran akan
disimpan dan ditampilkan, Harga Tawaran harus lebih besar harga tawaran penawar sebelumnya, jika hal ini terpenuhi maka tawaran akan disimpan dan
ditampilkan, Tawaran tertinggi dihitung berdasarkan pada total penawaran secara keseluruhan harga per kuantitas x kuantitas. Price discovery terbentuk ketika
harga tawaran lebih besar atau sama dengan harga dasar reserve price. Pada saat sesi lelang berakhir, maka yang menjadi pemenang lelang adalah penawar terakhir
dengan jumlah tawaran tertinggi.
Perancangan sistem menggunakan Unified Modelling Language UML yang terdiri dari use case diagram, activity diagram, sequence diagram, class
diagram
dan deployment diagram.
Di dalam use case diagram, seorang user harus melakukan login terlebih dahulu untuk masuk ke dalam sistem. Sehingga dapat ditentukan hak akses tiap
tingkatan user. Terdapat tiga hak akses yaitu penjual, pembeli, dan administrator seperti terlihat pada Gambar 2.
Gambar 2
Use Case Diagram Sistem
Gambar 3 menjelaskan mengenai bagian-bagian yang tersedia untuk hak akses Penjual, Pembeli dan Administrator. Untuk hak akses Penjual, dapat melihat
detail dan edit informasi komoditi yang dimiliki dan melihat transaksi penjualan komoditi. Kemudian hak akses Pembeli dapat melakukan penawaran terhadap
komoditi yang diinginkan dan dapat melihat transaksi penawaran dan pembelian komoditi. Sedangkan hak akses Administrator selain dapat melakukan pengaturan
terhadap komoditi juga dapat melakukan pengaturan jadwal sesi lelang dan hari libur.
Activity diagram menggambarkan berbagai alir aktivitas dalam sistem
yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi dan bagaimana mereka berakhir. Activity diagram juga dapat
menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi.
Penjual View Detail Komoditi
Input Komoditi Edit Komoditi
Delete Komoditi View Detail Komoditi
Edit Komoditi Delete Komoditi
extend extend
extend extend
Input Session Edit Session
extend extend
Input Holiday Date Edit Holiday Date
Delete Holiday Date extend
extend extend
Detail Transaksi extend
Detail Transaksi extend
extend extend
extend Manage Komoditi
Lihat Transaksi Penjualan
Lihat Transaksi Pembelian
Bidding Komoditi
Pembeli Manage Komoditi
Manage Holiday Date Manage Session
Administrat or
Login
include include
include include
include include
include
Gambar 3 Activity Diagram Penawaran Komoditi Pembeli
Gambar 3 menggambarkan aktifitas penawaran komoditi yang terjadi dalam hak akses Pembeli. Pembeli mencari komoditi yang diinginkan kemudian
menawar komoditi tersebut dengan memasukkan kuantitas dan harga tawaran yang disesuaikan dengan jumlah deposit yang dimiliki. Dengan ketentuan harga
tawaran harus kurang dari deposit yang dimiliki, harga tawaran harus lebih dari harga jual komoditi dan harus lebih dari harga tawaran sebelumnya.
Sequence diagram menggambarkan interaksi antar obyek di dalam dan di sekitar sistem termasuk user, display, dan sebagainya berupa message yang
digambarkan terhadap waktu. Sequence diagram terdiri atas dimensi vertikal waktu dan dimensi horizontal objek-objek yang terkait. Sequence diagram
biasa digunakan untuk menggambarkan skenario atau rangkaian langkah yang dilakukan sebagai tanggapan dari sebuah event untuk menghasilkan output
tertentu.
Memilih Komoditi yang akan Ditawar
Input Jumlah dan Kuantitas Tawaran
start
Mencari Komoditi
Tampil Daftar Komoditi Lelang
Menampilkan Form Tawar
Menyimpan Tawaran
end Menampilkan
Komoditi
Harga Awal Harga Tawaran Deposit Harga Tawaran Harga Tawaran Sebelumnya
yes no
System Pembeli
Gambar 4
Sequence Diagram Proses Penawaran Komoditi Pembeli
Gambar 4 merupakan sequence diagram untuk proses penawaran komoditi yang dilakukan oleh seorang pembeli. Penjelasan prosesnya sebagai berikut,
dalam Form_Utama disajikan beberapa menu, dalam diagram sequence ini, pembeli memilih menu lelang yang akan langsung menampilkan daftar komoditi
lelang. Selanjutnya pembeli memilih menu untuk melakukan penawaran komoditi sehingga akan muncul TawarKomoditiUI, dan pembeli tersebut dapat melakukan
proses penawaran. Jika harga tawaran awal kurang dari harga jual dan kurang dari harga penawaran sebelumnya, maka harga tawaran tersebut tidak akan disimpan,
sebaliknya harga tawaran akan tersimpan jika harga tawaran melebihi harga awal dan harga tawaran sebelumnya. Harga tawaran akan disimpan dalam tabel
Penawaran.
Class diagram menggambarkan struktur dan deskripsi class, package, dan
objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi dan lain-lain. Aplikasi yang dibuat memiliki class diagram seperti yang terlihat
pada Gambar 5.
: Pembeli TawarKomoditiUI
TawarKomoditiControll er
: Auctions
1: inputHargaDanKuantitasTawar 2: saveTawaran
3: openDb 4: AddHargaDanKuantitasTawar
5: closeDb 6: return done
7: return done
Gambar 5 Class Diagram Sistem
Class diagram sistem pada Gambar 5 dapat dijelaskan sebagai berikut.
Class commodity_detail
memiliki tiga
relasi yaitu
dengan class
transaction_biddingheader , class admin_session dan class admin_holiday. Relasi
class commodity_detail dengan class transaction_biddingheader adalah one to
many , dimana satu komoditi dapat ditawar berulang kali. Relasi class
commodity_detail dengan class admin_session yaitu many to one, dimana semua
komoditi dilelang dalam satu kali sesi. Sedangkan relasi class commodity_detail dengan class admin_holiday yaitu many to one, dimana semua komoditi tidak
dapat dilelang jika ada satu hari libur. Relasi class transaction_biddingheader dengan class transaction_biddingdetail adalah one to many, dimana satu kali
penawaran akan mempunyai banyak detail karena akan banyak komoditi yang ditawar dalam satu sesi.
Gambar 6 merupakan deployment diagram sistem yang menggambarkan perangkat apa saja yang digunakan saat deployment.
Gambar 6 Deployment Diagram Sistem
Perancangan Arsitektur MVC Model, View, Controller
Rancangan Model,
merupakan bagian yang merepresentasikan struktur data yang akan dibangun. Bagian Model yang dibangun berhubungan langsung dengan basis
data dan menangani validasi dari bagian Controller, namun tidak berhubungan langsung dengan View. Model dalam aplikasi ini yaitu : 1. admin_model : berisi
method
yang menangani kerja admin untuk menangani validasi dari bagian Controller
, 2. auction_model : berisi method mengenai proses lelang untuk menangani validasi dari bagian Controller, 3 commodity_model : berisi method
mengenai komoditi untuk menangani validasi dari bagian Controller.
Rancangan View,
merupakan informasi yang disajikan untuk user yang berupa tampilan atau user interface. View umumnya adalah tampilan sebuah halaman
web itu sendiri. Bagian ini tidak memiliki akses langsung ke Model. Desain yang
dilakukan pada bagian View dibagi dalam beberapa package yaitu : 1. Package Auctions
: berisi tampilan halaman yang berhubungan dengan lelang komoditi, 2. Package Commodities
: berisi tampilan halaman yang berhubungan dengan komoditi, 3. Package Sysadmin : berisi tampilan halaman yang berhubungan
dengan pengaturan komoditi dan sesi lelang yang dilakukan oleh Administrator, 3. Package Template : berisi tampilan halama untuk header dan footer.
Rancangan Controller,
bertindak sebagai penghubung antara model dan view. Di dalam controller inilah terdapat class-class dan fungsi-fungsi yang memproses
permintaan dari view ke dalam struktur data di dalam model. Controller mencakup semua proses yang terkait dengan pemanggilan database. Controller yang dibuat
dalam aplikasi ini yaitu : 1. Admins : berisi controller untuk pengaturan komoditi yang dilakukan oleh administrator, 2. Auction : berisi controller untuk mengatur
mengenai proses lelang, 3. Commodities : berisi controller untuk mengatur komoditi.
Jaringan Internet
n 1
Client Server
4. Implementasi dan Analisa Hasil