Analisis Dan Perancangan Aplikasi Pelelangan Barang Berbasis Short Message Service (SMS). Studi Kasus: Perum Pegadaian Kasuari Medan
BARANG BERBASIS SHORT MESSAGE SERVICE (SMS).
STUDI KASUS: PERUM PEGADAIAN KASUARI MEDAN
SKRIPSI
MUHAMMAD ARIFIN SIREGAR
061401070
PROGRAM STUDI S1 ILMU KOMPUTER
DEPARTEMEN ILMU KOMPUTER
FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM
UNIVERSITAS SUMATERA UTARA
MEDAN
2010
(2)
BERBASIS SHORT MESSAGE SERVICE (SMS). STUDI KASUS: PERUM PEGADAIAN KASUARI MEDAN
SKRIPSI
Diajukan untuk melengkapi tugas dan memenuhi syarat mencapai gelar Sarjana Komputer
MUHAMMAD ARIFIN SIREGAR 061401070
PROGRAM STUDI S1 ILMU KOMPUTER DEPARTEMEN ILMU KOMPUTER
FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM UNIVERSITAS SUMATERA UTARA
(3)
PERSETUJUAN
Judul : ANALISIS DAN PERANCANGAN APLIKASI
PELELANGAN BARANG BERBASIS SHORT MESSAGE SERVICE (SMS). STUDI KASUS: PERUM PEGADAIAN KASUARI MEDAN
Kategori : SKRIPSI
Nama : MUHAMMAD ARIFIN SIREGAR
Nomor Induk Mahasiswa : 061401070
Program Studi : SARJANA (S1) ILMU KOMPUTER
Departemen : ILMU KOMPUTER
Fakultas : MATEMATIKA DAN ILMU PENGETAHUAN
ALAM (FMIPA) UNIVERSITAS SUMATERA UTARA
Diluluskan di Medan,
Komisi Pembimbing :
Pembimbing 2 Pembimbing 1
Dian Rachmawati, S.Si, M.Kom Syahriol Sitorus, S.Si, MIT
NIP 198307232009122004 NIP 197103101997031004
Diketahui/Disetujui oleh
Program Studi S1 Ilmu Komputer Ketua,
Prof. Dr. Muhammad Zarlis NIP 195707011986011003
(4)
PERNYATAAN
ANALISIS DAN PERANCANGAN APLIKASI PELELANGAN BARANG BERBASIS SHORT MESSAGE SERVICE (SMS). STUDI KASUS: PERUM
PEGADAIAN KASUARI MEDAN
SKRIPSI
Saya mengakui bahwa skripsi ini adalah hasil karya saya sendiri, kecuali beberapa kutipan dan ringkasan yang masing-masing disebutkan sumbernya.
Medan, 8 Juni 2010
Muhammad Arifin Siregar 061401070
(5)
PENGHARGAAN
Alhamdulillah, puji syukur saya ucapkan kehadirat Allah SWT yang telah memberikan rahmat dan hidayahnya, sehingga saya dapat menyelesaikan penyusunan skripsi ini, sebagai syarat untuk memperoleh gelar Sarjana Komputer, Program Studi S1 Ilmu Komputer Departemen Ilmu Komputer Universitas Sumatera Utara. Shalawat beriring salam saya persembahkan kepada Nabi Besar Muhammad SAW.
Ucapan terima kasih penulis sampaikan kepada Syahriol Sitorus, S.Si, MIT selaku pembimbing pertama dan Dian Rachmawati, S.Si, M.Kom selaku pembimbing kedua yang telah banyak meluangkan waktunya dalam memberikan masukan-masukan kepada penulis. Ucapan terima kasih juga ditujukan kepada M. Andri Budiman, ST, M.Comp.Sc, MEM dan Maya Silvi Lydia, B.Sc, M.Sc yang telah bersedia menjadi dosen penguji. Ucapan terima kasih juga ditujukan kepada Ketua dan Sekretaris Departemen Ilmu Komputer, Prof. Dr. Muhammad Zarlis dan Syahriol Sitorus, S.Si, MIT, Dekan dan Pembantu Dekan Fakultas Matematika dan Ilmu Pengetahuan Alam Universitas Sumatera Utara, semua dosen serta pegawai di Program Studi S1 Ilmu Komputer Departemen Ilmu Komputer FMIPA USU.
Skripsi ini terutama saya persembahkan untuk kedua orang tua dan keluarga saya yang telah memberikan dukungan dan motivasi, ayahanda Damang Bahrium Siregar dan ibunda Eny Deniarty yang selalu sabar dalam mendidik saya. Untuk kakak saya, Rizka Signorita Siregar dan adik saya, Tamara Tria Siregar yang selalu memberikan dorongan kepada saya selama menyelesaikan skripsi ini serta Andria Syafitri Hasibuan atas perhatian dan kesabaran yang diberikan kepada saya. Terima kasih saya ucapkan kepada teman-teman yang selalu memberikan dukungan, Alfarisi, Rudi Tanaka, Reza Pahlepi, Azhari, Philipus, Azemi, Rifky, Ono dan Habrul Leni serta teman-teman satu angkatan yang sama-sama berjuang dalam penyusunan skripsi. Sekali lagi penulis mengucapkan terima kasih kepada semua pihak yang membantu dalam penyelesaian tugas akhir ini yang tidak dapat disebutkan satu persatu, terima kasih atas ide, saran dan motivasi yang diberikan.
(6)
ABSTRAK
Penggunaan Short Message Service (SMS) dalam komunikasi bukan lagi menjadi suatu hal yang baru. Layanan ini banyak digunakan karena dapat mengirim informasi kapanpun dan dimanapun dengan biaya yang relatif murah. Perum Pegadaian dalam kegiatannya melaksanakan lelang sebagai cara penjualan barang yang sudah lewat jangka waktu pembayarannya. Proses pelelangan yang dilaksanakan sering menimbulkan masalah seperti waktu pelelangan yang terlalu singkat dibandingkan jumlah barang yang dilelang, keterlambatan proses penyampaian informasi lelang dan minat peserta yang besar sementara waktu dan ruang terbatas. Oleh karena itu dibangun aplikasi pelelangan barang berbasis SMS untuk mengatasi masalah tersebut. Aplikasi ini terdiri dari aplikasi server dan aplikasi MIDlet. Analisis dan perancangan sistem menggunakan metodologi berorientasi objek dengan UML. Teknik pengujian dilakukan dengan metode blackbox. Ponsel penerima yang digunakan pada server adalah Siemens C55. Peserta lelang mengirim penawaran ke server menggunakan aplikasi MIDlet pada ponsel. Penawaran tersebut diterima server dan disimpan pada database. Pada saat lelang ditutup dilakukan pemeriksaan terhadap semua penawaran yang masuk. Pemenang adalah peserta dengan penawaran tertinggi.
(7)
ANALYSIS AND DESIGN OF THE AUCTION APPLICATION BASED ON SHORT MESSAGE SERVICE (SMS). CASE
STUDY: PERUM PEGADAIAN KASUARI MEDAN
ABSTRACT
The use of Short Message Service (SMS) in communication no longer be a novelty. This service is widely used because it can send information anywhere and anytime with the relatively cheap cost. Perum pegadaian conducting the auction as a way of selling goods which have passed the period of payment. Auction process often cause problems such as the time is too short compared to the number of items auctioned, delay auction process to deliver information and interests of participants that while time and space is limited. Therefore, the auction application based on SMS built to solve the problem. This application consists of server applications and MIDlet application. Analysis and design of systems using object-oriented methodologies with UML. Engineering tests were performed with the blackbox method. Mobile receiver used on the server is Siemens C55. Bidder send bid to the server using MIDlet application on the phone. Bid is received and stored on the database. At the time of auction close, all of incoming bid is checked. The winner is bidder with the highest bid.
(8)
DAFTAR ISI
Halaman
Persetujuan ii
Pernyataan iii Penghargaan iv Abstrak v Abstract vi Daftar Isi vii Daftar Tabel x Daftar Gambar xi Bab 1 Pendahuluan 1.1Latar Belakang 1
1.2Rumusan Masalah 2
1.3Batasan Masalah 2
1.4Tujuan Penelitian 3
1.5Manfaat Penelitian 3
1.6Diagram Proses Sistem 4
1.7Metodologi Penelitian 5
1.8Sistematika Penulisan 5
Bab 2 Landasan Teori 2.1 Lelang 7
2.2 Short Message Service (SMS) 8
2.2.1 SMS PDU Mobile Originated 9
2.2.1.1 Service Center Address (SCA) 9
2.2.1.2 PDU Type 9
2.2.1.3 Message Reference (MR) 10
2.2.1.4 Destination Address (DA) 10
2.2.1.5 Protocol Identifier (PID) 10
2.2.1.6 Data Coding Shceme (DCS) 10
2.2.1.7 Validity Period (VP) 11
2.2.1.8 User Data Length (UDL) 11
2.2.1.9 User Data (UD) 11
2.2.2 SMS PDU Mobile Terminated 12
2.2.1.1 Service Center Address (SCA) 13
2.2.1.2 PDU Type 13
2.2.1.3 Originator Address (OA) 13
2.2.1.4 Protocol Identifier (PID) 14
2.2.1.5 Data Coding Shceme (DCS) 14
2.2.1.6 Service Center Time Stamp (SCTS) 14
2.2.1.7 User Data Length (UDL) 15
(9)
2.3 AT Command 16
2.4 Paradigma Berorientasi Objek 17
2.5 UML (Unified Modeling Language) 18
2.5.1 Use-case Diagram 18
2.5.1.1 Actor 18
2.5.1.2 Use-case 18
2.5.1.3 Interaksi Actor dengan Use-case 19
2.5.2 Activity Diagram 19
2.5.3 Class Diagram 20
2.5.4 Sequence Diagram 21
2.5.5 Package Diagram 22
2.5.6 Deployment Diagram 23
2.6 Analisis Persyaratan dengan UML 23
2.7 Desain dengan UML 24
Bab 3 Analisis dan Perancangan 3.1 Analisis Persyaratan Sistem 25
3.1.1 Proses Bisnis Sistem Pelelangan Barang Berbasis SMS 25
3.1.2 Use Case Diagram Persyaratan Sistem 25
3.2 Analisis Kebutuhan Sistem 29
3.2.1 Analisis Fungsionalitas Sistem 29
3.2.2 Analisis Input dan Output Sistem 29
3.2.3 Analisis Batasan Sistem 31
3.3 Use Case Diagram Analisis Sistem 31
3.3.1 Use Case Mengajukan Penawaran 33
3.3.2 Use Case Meminta Informasi Barang 35
3.3.3 Use Case Meminta Penawaran Terakhir 37
3.3.4 Use Case Meminta Informasi Pemenang 39
3.3.5 Use Case Meminta Informasi Pelelangan Berikutnya 41
3.3.6 Use Case Login 43
3.3.7 Use Case Menambah Data Bidder 45
3.3.8 Use Case Menambah Data Barang 47
3.3.9 Use Case Mengubah Data Bidder 49
3.3.10 Use Case Mengubah Data Barang 51
3.3.11 Use Case Menghapus Data Bidder 53
3.3.12 Use Case Menghapus Data Barang 55
3.3.13 Use Case Mengirim Informasi 57
3.3.14 Use Case Mencetak Laporan 59
3.3.15 Use Case Menambah Data User 61
3.3.16 Use Case Mengubah Data User 63
3.3.17 Use Case Menghapus Data User 65
3.3.18 Use Case Manajemen Lelang 67
3.3.19 Use Case Menerima Penawaran 69
3.3.20 Use Case Menerima Request Informasi 71
3.3.21 Use Case Membalas Penawaran 73
3.3.22 Use Case Membalas Request Informasi 75
3.3.22 Use Case Menentukan Pemenang Lelang 77
3.4 Class Diagram Analisis Sistem 80
(10)
3.6 Perancangan Method Utama 82
3.6.1 Method Konversi Bilangan Desimal Ke Hexa 82
3.6.2 Method untuk Mengkoreksi Nomor 84
3.6.3 Method Konversi Bilangan Hexa ke Karakter ASCII 85
3.6.4 Method Konversi Karakter ASCII ke Bilangan Hexa 86
3.6.5 Method Pengiriman Pesan PDU 88
3.6.6 Method Penerimaan Pesan PDU 91
3.7 Class Diagram Desain Sistem 94
3.8 Sequence Diagram 94
3.8.1 Use Case Mengajukan Penawaran 95
3.8.2 Use Case Meminta Informasi Lelang 96
3.8.3 Use Case Login 96
3.8.4 Use Case Mengelola Data Bidder 98
3.8.5 Use Case Mengelola Data Barang 99
3.8.6 Use Case Mengirim Informasi 101
3.8.7 Use Case Mencetak Laporan 102
3.8.8 Use Case Menjalankan Server Lelang 103
3.8.9 Use Case Menonaktifkan Server Lelang 104
3.8.10 Use Case Mengelola Data User 105
3.8.11 Use Case Manajemen Lelang 107
3.8.12 Use Case Menerima Pesan 109
3.8.13 Use Case Membalas Pesan 110
3.8.14 Use Case Menentukan Pemenang Lelang 111
3.9 Deployment Diagram 112
3.10 Desain Database 113
3.11 Desain Interface 113
3.11.1 Interface Aplikasi Manajemen Lelang 114
3.11.2 Interface Aplikasi Server Lelang 116
3.11.3 Interface Aplikasi MIDlet Bidder 116
3.11.4 Rancangan Laporan Lelang 118
Bab 4 Implementasi dan Pengujian 4.1 Implementasi 120
4.1.1 Kebutuhan Minimum Komputer Server 120
4.1.2 Kebutuhan Minimum Ponsel Bidder 121
4.1.3 Kebutuhan Perangkat Lunak 121
4.2 Pengujian Sistem 122
4.2.1 Menjalankan Server Lelang 122
4.2.2 Proses Penawaran Barang 126
4.2.3 Informasi Lelang 127
4.2.4 Penentuan Pemenang 129
4.2.5 Laporan Lelang 130
Bab 5 Kesimpulan dan Saran 5.1 Kesimpulan 135
5.2 Saran 135
Daftar Pustaka 136
(11)
DAFTAR TABEL
Halaman
Tabel 2.1 Service Center Address Pengirim 9
Tabel 2.2 Destination Address Pengirim 10
Tabel 2.3 Validity Period Pengirim 11
Tabel 2.4 User Data Pengirim 11
Tabel 2.5 Service Center Address Penerima 13
Tabel 2.6 Originator Address Penerima 14
Tabel 2.7 Service Center Time Stamp Penerima 14
Tabel 2.8 User Data Penerima 15
Tabel 2.9 Karakter ASCII 16
Tabel 2.10 AT Command 17
Tabel 3.1 Dokumentasi Naratif Mengajukan Penawaran 33
Tabel 3.2 Dokumentasi Naratif Meminta Informasi Barang 35
Tabel 3.3 Dokumentasi Naratif Meminta Informasi Penawaran Terakhir 37
Tabel 3.4 Dokumentasi Naratif Meminta Informasi Pemenang 40
Tabel 3.5 Dokumentasi Naratif Meminta Informasi Pelelangan Berikutnya 41
Tabel 3.6 Dokumentasi Naratif Login 43
Tabel 3.7 Dokumentasi Naratif Menambah Data Bidder 45
Tabel 3.8 Dokumentasi Naratif Menambah Data Barang 47
Tabel 3.9 Dokumentasi Naratif Mengubah Data Bidder 49
Tabel 3.10 Dokumentasi Naratif Mengubah Data Barang 51
Tabel 3.11 Dokumentasi Naratif Menghapus Data Bidder 53
Tabel 3.12 Dokumentasi Naratif Menghapus Data Barang 55
Tabel 3.13 Dokumentasi Naratif Mengirim Informasi 57
Tabel 3.14 Dokumentasi Naratif Mencetak Laporan 59
Tabel 3.15 Dokumentasi Naratif Memasukkan Data User 61
Tabel 3.16 Dokumentasi Naratif Mengubah Data User 63
Tabel 3.17 Dokumentasi Naratif Menghapus Data User 65
Tabel 3.18 Dokumentasi Naratif Manajemen Lelang 67
Tabel 3.19 Dokumentasi Naratif Menerima Penawaran 69
Tabel 3.20 Dokumentasi Naratif Menerima Request Informasi 71
Tabel 3.21 Dokumentasi Naratif Membalas Penawaran 74
Tabel 3.22 Dokumentasi Naratif Membalas Request Informasi 75
Tabel 3.23 Dokumentasi Naratif Menentukan Pemenang 77
Tabel 3.24 Penjelasan Class Diagram Analisis Sistem 81
(12)
DAFTAR GAMBAR
Halaman
Gambar 1.1 Diagram Proses Pengiriman/Penerimaan Pesan 4
Gambar 2.1 Skema Format PDU Pengirim 9
Gambar 2.2 Skema Format PDU Penerima 12
Gambar 2.3 Actor 18
Gambar 2.4 Use Case 19
Gambar 2.5 Use-case Diagram 19
Gambar 2.6 Activity Diagram 20
Gambar 2.7 Class Diagram 21
Gambar 2.8 Sequence Diagram 22
Gambar 2.9 Package Diagram 22
Gambar 2.10 Deployment Diagram 23
Gambar 3.1 Use Case Diagram Persyaratan Sistem 29
Gambar 3.2 Use Case Diagram Analisis Sistem 32
Gambar 3.3 Activity Diagram untuk Use Case Mengajukan Penawaran 35 Gambar 3.4 Activity Diagram untuk Use Case Meminta Informasi Barang 37 Gambar 3.5 Activity Diagram untuk Use Case Meminta Informasi Penawaran
Terakhir 39
Gambar 3.6 Activity Diagram untuk Use Case Meminta Informasi Pemenang 41 Gambar 3.7 Activity Diagram untuk Use Case Meminta Informasi Pelelangan
Berikutnya 43
Gambar 3.8 Activity Diagram untuk Use Case Login 45
Gambar 3.9 Activity Diagram untuk Use Case Menambah Data Bidder 47 Gambar 3.10 Activity Diagram untuk Use Case Menambah Data Barang 49 Gambar 3.11 Activity Diagram untuk Use Case Mengubah Data Bidder 51 Gambar 3.12 Activity Diagram untuk Use Case Mengubah Data Barang 53 Gambar 3.13 Activity Diagram untuk Use Case Menghapus Data Bidder 55 Gambar 3.14 Activity Diagram untuk Use Case Menghapus Data Barang 57 Gambar 3.15 Activity Diagram untuk Use Case Mengirim Informasi 59 Gambar 3.16 Activity Diagram untuk Use Case Mencetak Laporan 61 Gambar 3.17 Activity Diagram untuk Use Case Menambah Data User 63 Gambar 3.18 Activity Diagram untuk Use Case Mengubah Data User 65 Gambar 3.19 Activity Diagram untuk Use Case Menghapus Data User 67 Gambar 3.20 Activity Diagram untuk Use Case Manajemen Lelang 69 Gambar 3.21 Activity Diagram untuk Use Case Menerima Penawaran 71 Gambar 3.22 Activity Diagram untuk Use Case Menerima Request Informasi 73 Gambar 3.23 Activity Diagram untuk Use Case Membalas Penawaran 75 Gambar 3.24 Activity Diagram untuk Use Case Membalas Request Informasi 77 Gambar 3.25 Activity Diagram untuk Use Case Menentukan Pemenang 79
Gambar 3.26 Class Diagram Analisis Sistem 80
Gambar 3.27 Package Diagram Analisis Sistem 82
Gambar 3.28 Flowchart Konversi Bilangan Desimal ke Bilangan Hexa 83
(13)
Gambar 3.30 Flowchart Konversi Deretan Hexa Ke Karakter ASCII 85 Gambar 3.31 Flowchart Konversi Karakter ASCII Ke Deretan Hexa 87
Gambar 3.32 Flowchart Pengiriman Pesan PDU 80
Gambar 3.33 Flowchart Penerimaan Pesan PDU 92
Gambar 3.34 Class Diagram Desain Sistem 94
Gambar 3.35 Class Diagram untuk Use Case Mengajukan Penawaran 95 Gambar 3.36 Sequence Diagram untuk Use Case Mengajukan Penawaran 95 Gambar 3.37 Class Diagram untuk Use Case Meminta Informasi Lelang 96 Gambar 3.38 Sequence Diagram untuk Use Case Meminta Informasi Lelang 96
Gambar 3.39 Class Diagram untuk Use Case Login 97
Gambar 3.40 Sequence Diagram untuk Use Case Login 97
Gambar 3.41 Class Diagram untuk Use Case Mengelola Data Bidder 98 Gambar 3.42 Sequence Diagram untuk Use Case Mengelola Data Bidder 99 Gambar 3.43 Class Diagram untuk Use Case Mengelola Data Barang 99 Gambar 3.44 Sequence Diagram untuk Use Case Mengelola Data Barang 100 Gambar 3.45 Class Diagram untuk Use Case Mengirim Informasi 101 Gambar 3.46 Sequence Diagram untuk Use Case Mengirim Informasi 102
Gambar 3.47 Class untuk Use Case Mencetak Laporan 102
Gambar 3.48 Sequence Diagram untuk Use Case Mencetak Laporan 103 Gambar 3.49 Class Diagram untuk Use Case Menjalankan Server Lelang 103 Gambar 3.50 Sequence Diagram untuk Use Case Menjalankan Server Lelang 104 Gambar 3.51 Class Diagram untuk Use Case Menonaktifkan Server Lelang 105 Gambar 3.52 Sequence Diagram untuk Use Case Menonaktifkan Server Lelang 105 Gambar 3.53 Class Diagram untuk Use Case Menge lola Data User 106 Gambar 3.54 Sequence Diagram untuk Use Case Mengelola Data User 107
Gambar 3.55 Class Diagram untuk Use Case Manajemen Lelang 107
Gambar 3.56 Sequence Diagram untuk Use Case Manajemen Lelang 108
Gambar 3.57 Class Diagram untuk Use Case Menerima Pesan 109
Gambar 3.58 Sequence Diagram untuk Use Case Menerima Pesan 110
Gambar 3.59 Class Diagram untuk Use Case Membalas Pesan 110
Gambar 3.60 Sequence Diagram untuk Use Case Membalas Pesan 111
Gambar 3.61 Class Diagram untuk Use Case Menentukan Pemenang Lelang 111 Gambar 3.62 Sequence Diagram untuk Use Case Menentukan Pemenang Lelang 112
Gambar 3.63 Deployment Diagram Arsitektur Sistem 112
Gambar 3.64 Desain Database 113
Gambar 3.65 Form Utama Aplikasi Manajemen Lelang 114
Gambar 3.66 Aplikasi Server Lelang 116
Gambar 3.67 Form Utama Aplikasi MIDlet Bidder 117
Gambar 3.68 Form Penawaran Aplikasi MIDlet Bidder 117
Gambar 3.69 Form Informasi Lelang Aplikasi MIDlet Bidder 118
Gambar 3.70 Rancangan Laporan Barang yang Dilelang 119
Gambar 3.71 Rancangan Laporan Penawaran Barang 119
Gambar 4.1 Verifikasi Login Server Lelang 122
Gambar 4.2 Server Lelang Telah Siap Digunakan 122
Gambar 4.3 Login Form Manajemen Lelang 123
Gambar 4.4 Menu Manajemen Lelang 123
Gambar 4.5 Mengaktifkan Barang Untuk Dilelang 124
Gambar 4.6 Server Melakukan Pengiriman Pesan 125
(14)
Gambar 4.8 Penawaran Pada Ponsel Bidder 126
Gambar 4.9 Server Menyimpan Penawaran Bidder 126
Gambar 4.10 Kesalahan Karena Penawaran Tidak Sesuai 127
Gambar 4.11 Informasi Penawaran Terakhir 127
Gambar 4.12 Pengiriman Informasi Penawaran Terakhir 128
Gambar 4.13 Informasi Pelelangan Berikutnya 128
Gambar 4.14 Pengiriman Informasi Pelelangan Berikutnya 129
Gambar 4.15 Penentuan Pemenang Lelang 129
Gambar 4.16 Informasi Pemenag Lelang 130
Gambar 4.17 Laporan Barang yang Dilelang 130
(15)
ABSTRAK
Penggunaan Short Message Service (SMS) dalam komunikasi bukan lagi menjadi suatu hal yang baru. Layanan ini banyak digunakan karena dapat mengirim informasi kapanpun dan dimanapun dengan biaya yang relatif murah. Perum Pegadaian dalam kegiatannya melaksanakan lelang sebagai cara penjualan barang yang sudah lewat jangka waktu pembayarannya. Proses pelelangan yang dilaksanakan sering menimbulkan masalah seperti waktu pelelangan yang terlalu singkat dibandingkan jumlah barang yang dilelang, keterlambatan proses penyampaian informasi lelang dan minat peserta yang besar sementara waktu dan ruang terbatas. Oleh karena itu dibangun aplikasi pelelangan barang berbasis SMS untuk mengatasi masalah tersebut. Aplikasi ini terdiri dari aplikasi server dan aplikasi MIDlet. Analisis dan perancangan sistem menggunakan metodologi berorientasi objek dengan UML. Teknik pengujian dilakukan dengan metode blackbox. Ponsel penerima yang digunakan pada server adalah Siemens C55. Peserta lelang mengirim penawaran ke server menggunakan aplikasi MIDlet pada ponsel. Penawaran tersebut diterima server dan disimpan pada database. Pada saat lelang ditutup dilakukan pemeriksaan terhadap semua penawaran yang masuk. Pemenang adalah peserta dengan penawaran tertinggi.
(16)
ANALYSIS AND DESIGN OF THE AUCTION APPLICATION BASED ON SHORT MESSAGE SERVICE (SMS). CASE
STUDY: PERUM PEGADAIAN KASUARI MEDAN
ABSTRACT
The use of Short Message Service (SMS) in communication no longer be a novelty. This service is widely used because it can send information anywhere and anytime with the relatively cheap cost. Perum pegadaian conducting the auction as a way of selling goods which have passed the period of payment. Auction process often cause problems such as the time is too short compared to the number of items auctioned, delay auction process to deliver information and interests of participants that while time and space is limited. Therefore, the auction application based on SMS built to solve the problem. This application consists of server applications and MIDlet application. Analysis and design of systems using object-oriented methodologies with UML. Engineering tests were performed with the blackbox method. Mobile receiver used on the server is Siemens C55. Bidder send bid to the server using MIDlet application on the phone. Bid is received and stored on the database. At the time of auction close, all of incoming bid is checked. The winner is bidder with the highest bid.
(17)
BAB 1
PENDAHULUAN
1.1Latar Belakang
Perkembangan teknologi komunikasi dewasa ini semakin meningkat seiring dengan peningkatan kebutuhan manusia untuk berkomunikasi secara cepat. Salah satu layanan komunikasi yang banyak digunakan adalah Short Message Service (SMS). Layanan ini banyak digunakan karena dapat mengirim/menerima pesan kapanpun dan di manapun dengan biaya yang relatif murah.
Media SMS sangat baik digunakan untuk transfer data atau informasi dalam kapasitas kecil. Dengan media ini pengguna dapat memperoleh informasi dari suatu server SMS dan dapat berinteraksi dengan server tersebut dengan pola – pola teks tertentu. Misalnya layanan SMS Banking yang memudahkan pengguna untuk mengetahui informasi saldo tabungan, melakukan transfer, bahkan melakukan beberapa pembayaran seperti tagihan telepon.
Perum Pegadaian merupakan perusahaan BUMN yang bergerak dalam bidang jasa pembiayaan yakni memberikan pinjaman uang kepada masyarakat berdasarkan hukum gadai. Hal ini ditegaskan dalam Keputusan Menteri Keuangan No. Kep-39/MK/6/1/1971 tanggal 20 Januari 1970 Perusahaan ini memiliki beberapa layanan yang diberikan kepada masyarakat. Salah satu diantaranya adalah proses pelelangan barang. Barang yang dilelang adalah barang yang sudah lewat jangka waktu pembayarannya. Jenis pelelangan yang digunakan adalah English Auction yaitu penawaran berikutnya lebih tinggi dibanding penawaran sebelumnya dan pelelangan akan berakhir jika tidak ada lagi partisipan yang melakukan bidding (penawaran) atau selesai pada penawaran tertinggi terakhir pada rentang waktu tertentu.
(18)
Proses pelelangan konvensional (biasa) yang dilakukan pada Perum Pegadaian yakni dilakukan dua kali dalam satu bulan dan hanya diadakan di beberapa kantor cabang. Menurut pihak perum pegadaian, barang yang dilelang memiliki jenis yang beragam dan dapat berjumlah 20 sampai 25 barang per pelelangan. Waktu pelelangan adalah sekitar 4 jam. Permasalahan utama adalah jumlah barang yang dilelang terlalu banyak jika dibandingkan dengan waktu pelelangan yang tersedia dalam satu hari. Permasalahan lain yang biasanya terjadi adalah keterlambatan pemberitahuan diadakannya proses pelelangan karena disampaikan melalui surat. Kemudian minat peserta untuk mengikuti pelelangan sangat besar, sedangkan pada lelang konvensional jumlah peserta lelang sangat terbatas dikarenakan pertimbangan ruang dan waktu sehingga proses lelang menjadi tidak efektif dan efisien. Selain itu sering terjadi perdebatan dengan pemilik barang terdahulu pada saat ia melihat proses pelelangan berlangsung.
Oleh karena itu Perum Pegadaian memerlukan suatu sistem pelelangan barang berbasis SMS untuk mengatasi permasalahan tersebut.
1.2Rumusan Masalah
Masalah yang dibahas dalam penelitian ini yaitu:
1. Bagaimana membangun sistem yang dapat melaksanakan proses mobile auction dengan menggunakan layanan SMS, mulai dari proses notification, bidding, hingga penentuan pemenang.
2. Bagaimana merancang aplikasi pelelangan barang berbasis SMS dengan pendekatan berorientasi objek menggunakan UML.
1.3Batasan Masalah
Ruang lingkup penelitian ini dibatasi pada:
1. Proses registrasi peserta (bidder) tetap dilakukan secara manual. 2. Jenis ponsel yang digunakan pada aplikasi server adalah Siemens C55. 3. Peserta lelang menggunakaan ponsel yang mendukung aplikasi Java. 4. Metode pelelangan yang digunakan adalah English Auction.
5. Pembahasan tidak mencakup penyampaian dan pembayaran barang yang telah dimenangkan.
(19)
1.4Tujuan Penelitian
Adapun tujuan penelitian ini yaitu:
1. Membangun aplikasi pelelangan barang berbasis SMS pada Perum Pegadaian Kasuari Medan.
2. Membuat desain sistem pelelangan barang berbasis SMS melalui analisis dan perancangan berorientasi objek UML.
1.5Manfaat Penelitian
Aplikasi yang dihasilkan diharapkan dapat menggantikan sistem pelelangan konvensional dengan sistem berbasis SMS sehingga dapat memberi kemudahan untuk melaksanakan proses pelelangan dan dapat mengatasi masalah yang terjadi pada sistem pelelangan terdahulu.
(20)
1.6Diagram Proses Sistem
(21)
1.7Metodologi Penelitian
Tahapan yang diambil dalam penelitian ini yaitu: 1. Studi literatur.
2. Mengamati secara langsung proses pelelangan konvensional dan melengkapi data yang dibutuhkan dari perusahaan.
3. Menganalisis dan merancang aplikasi. 4. Implementasi
5. Pengujian Sistem
6. Menyusun laporan dan dokumentasi
1.8Sistematika Penulisan
Sistematika penulisan dari skripsi ini terdiri dari beberapa bagian utama sebagai berikut:
BAB 1: PENDAHULUAN
Bab ini menjelaskan mengenai latar belakang pemilihan judul skripsi “Analisis dan Perancangan Aplikasi Pelelangan Barang Berbasis Short Message Service (SMS). Studi Kasus: Perum Pegadaian Kasuari Medan”, rumusan masalah, batasan masalah, tujuan penelitian, manfaat penelitian, metodologi penelitian, dan sistematika penulisan.
BAB 2: LANDASAN TEORI
Bab ini membahas pengertian dan jenis lelang, Short Message Service (SMS), Protocol Data Unit (PDU), proses konversi teks ke PDU dan sebaliknya, AT Command, paradigma berorientasi objek dan Unified Modeling Language (UML).
BAB 3: ANALISIS DAN PERANCANGAN SISTEM
Bab ini menguraikan analisis sistem yang dilakukan dan perancangan sistem dengan pendekatan berorientasi objek yang sesuai dengan tujuan penelitian.
(22)
BAB 4: IMPLEMENTASI DAN PENGUJIAN
Bab ini menjelaskan implementasi sistem dalam bentuk aplikasi desktop dan MIDlet dengan bahasa pemrograman Java, serta digunakan database MySQL pada server. Lalu dilakukan pengujian untuk mengetahui apakah sistem sudah sesuai dengan pelaksanaan pelelangan yang sebenarnya.
BAB 5: KESIMPULAN DAN SARAN
Bab ini memuat kesimpulan dari uraian bab-bab sebelumnya dan hasil penelitian yang diperoleh. Bab ini juga memuat saran yang diharapkan dapat bermanfaat untuk pengembangan selanjutnya.
(23)
BAB 2
LANDASAN TEORI
2.1Lelang
Lelang merupakan proses penjualan dan pembelian barang dengan menawarkan barang melalui bidding, memilih penawaran, kemudian menjual barang tersebut kepada penawar tertinggi. Dalam teori ekonomi, lelang merupakan metode untuk menentukan nilai atau harga suatu komoditas yang belum ditentukan. (Septyani, H. I, 2007).
Beberapa jenis lelang:
1. English Auction, juga dikenal sebagai open ascending price auction, lelang ini dilakukan secara terbuka, penawaran berikutnya lebih tinggi dibanding penawaran sebelumnya. Lelang akan berakhir jika tidak ada lagi partisipan yang melakukan bidding (penawaran) atau selesai pada penawaran tertinggi terakhir pada rentang waktu tertentu. Jenis lelang ini biasanya digunakan pada penjualan barang, seperti barang antik, karya seni, barang bekas dan barang tak bergerak.
2. Dutch Auction, juga dikenal sebagai open descending price auction, lelang ini dilakukan secara terbuka, diawali dengan permintaan harga yang tertinggi oleh auctioneer (juru lelang), kemudian harga diturunkan sampai partisipan menyetujui harga dari auctioneer.
3. Sealed-bid first-price auction, semua bidder (penawar) memasukkan bidding bersama-sama sehingga tidak ada bidder yang mengetahui penawaran partisipan lain. Biasanya jenis ini digunakan pada proses tender seperti pengadaan barang di suatu pemerintahan.
(24)
4. Sealed-bid second-price auction, juga dikenal sebagai Vickrey auction. Lelang ini identik dengan Sealed-bid first-price auction, tetapi pemenang adalah harga tertinggi kedua.
5. All pay auction, semua bidder harus membayar penawaran mereka meskipun tidak memenangkan lelang. Bidder tertinggi mendapatkan hadiah atau barang yang ditawarkan. Lelang ini sering digunakan untuk memodelkan lobbying (bidding yang memiliki kontribusi politik), atau kompetisi lain pada running race.
2.2Short Message Service (SMS)
SMS merupakan fasilitas standar dari Global System for Mobile Communication (GSM) yang dikembangakan dan distandarisasi oleh European Telecommunication Standard Institute (ETSI) (Wicaksono, 2007). Fasilitas ini dipakai untuk mengirim dan menerima pesan dalam bentuk teks ke dan dari sebuah ponsel. SMS pertama kali diujicobakan Desember 1992 melalui sebuah komputer ke ponsel di jaringan GSM Vodafone di Inggris. Selanjutnya teknologi SMS berkembang dan jenis aplikasi yang dapat digunakan bertambah. Panjang pesan yang dapat dikirmkan dalam satu kali pengiriman mencapai 160 karakter atau 70 karakter jika menggunakan karakter non latin, seperti Arab atau Cina (Tim Pengembangan Wahana Komputer, 2005).
Pada saat mengirim SMS dari sebuah ponsel, pesan tersebut tidak langsung dikirim ke ponsel tujuan, akan tetapi terlebih dahulu dikirim ke SMS Center (SMSC) dengan prinsip Store and Forward, setelah itu dikirimkan ke ponsel yang dituju. (Putro, 2009). Artinya SMSC berperan sebagai penghubung antara pengirim dan penerima.
Terdapat dua mode dalam pengiriman dan penerimaan SMS, yaitu mode teks dan mode Protocol Data Unit (PDU). Mode teks merupakan format teks asli yang dituliskan pada saat akan mengirim pesan sedangkan mode PDU adalah format pesan dalam bentuk oktet heksadesimal dan oktet semidesimal dengan panjang mencapai 160 (7 bit) atau 140 (8 bit) karakter. Di Indonesia tidak semua operator GSM ataupun ponsel mendukung mode teks, sehingga mode yang digunakan adalah mode PDU.
(25)
Pada pengiriman pesan terdapat dua jenis mobile, yaitu Mobile Originated (Ponsel Pengirim) dan Mobile Terminated (Ponsel Penerima). (Tim Pengembangan Wahana Komputer, 2005).
2.2.1SMS PDU Mobile Originated
SMS PDU Pengirim (Mobile Originated) adalah pesan yang dikirim dari ponsel ke SMSC. Skema format PDU pengirim telah diatur dan ditetapkan oleh ETSI sebagai berikut :
SCA PDU Type MR DA PID DCS VP UDL UD Gambar 2.1 Skema Format PDU Pengirim
Misalkan ponsel mengirim pesan SMS ke nomor +6288261535685 dengan isi pesan “Terima Kasih” dengan batas waktu penyimpanan pesan di SMSC 5 hari. Maka format PDU adalah :
0011000E91268862515386F50000AB0CD4B23CDD0E8396E1791A0D Dengan penjelasan sebagai berikut:
2.2.1.1Service Center Address (SCA)
SCA merupakan informasi dari nomor SMSC. SCA memiliki tiga komponen utama yaitu len, type of number dan service center number. Dalam pengiriman pesan nomor SMSC tidak dicantumkan.
Tabel 2.1 Service Center Address Pengirim
Oktet Len Type of Number Service Center Of Number
Keterangan
Panjang informasi SMSC dalam
oktet
Format nomor dari SMSC 91 hexa = format
internasional
Nomor SMSC dari operator pengirim. Jika panjangnya ganjil, maka
pada karakter terakhir ditambah dengan F hexa
(26)
2.2.1.2PDU Type
Nilai default dari PDU Type untuk pengiriman pesan adalah 11 hexa. Jika disertai header pada User Data, maka PDU Type adalah 51.
2.2.1.3Message Reference (MR)
Message reference adalah acuan dari pengaturan pesan SMS. Untuk membiarkan pengaturan pesan standar, maka nilai yang diberikan adalah “00”.
2.2.1.4Destination Address (DA)
Destination Address merupakan informasi nomor ponsel tujuan yang terdiri atas panjang nomor (Len), format nomor tujuan (Type of Number) dan nomor tujuan (Destination Number). Jika panjang Destination Number ganjil, maka pada karakter terakhir ditambah dengan F h.
Tabel 2.2 Destination Address Pengirim
Oktet Len Type of Number Destination Number
Nilai 14 Format internasional = 91 6288261535685F
Hasil 0E 91 268862515386F5
Jadi, hasil Destination Address adalah 0E91268862515386F5.
2.2.1.5Protocol Identifier (PID)
Protocol Identifier merupakan tipe dari cara pengiriman pesan yang diatur oleh ponsel pengirim, seperti Standart Text, Fax, E-mail dan sebagainya. Nilai default dari PID adalah ”00” untuk Standart Text.
2.2.1.6Data Coding Scheme (DCS)
Data Coding Scheme merupakan skema pengkodean data untuk menentukan kelas dari pesan tersebut, apakah berupa SMS teks standar, Flash SMS atau Blinking SMS. Pada contoh ini pesan SMS yang dikirim berupa teks standar, dimana nilai DCS adalah ”00”.
(27)
2.2.1.7Validity Period (VP)
Validity Period merupakan lama waktu pesan disimpan di SMSC apabila pesan tersebut gagal diterima oleh ponsel penerima.
Tabel 2.3 Validity Period Pengirim
Waktu VP Nilai VP
Pada contoh ini, waktu VP 5 hari, maka nilai VP adalah: 166 + 5 = 171 d = AB h
Jadi nilai Validity Period adalah AB.
2.2.1.8User Data Length (UDL)
User Data Length merupakan panjang pesan yang akan dikirim dalam bentuk teks standar. Pada contoh ini pesan yang dikirm adalah “Terima Kasih”, yang memiliki 12 karakter (0C h).
2.2.1.9User Data (UD)
User Data adalah isi pesan yang akan dikirim dalam format heksadesimal. Proses pengkodean dari nilai teks standar menjadi heksadesimal dapat dilihat pada tabel berikut :
Tabel 2.4 User Data Pengirim
Karakter T e r i m a
Desimal 84 101 114 105 109 97
Septet 1010100 110010 1 11100 10 1101 001 110 1101 11 00001
Oktet 11010100 10110010 00111100 11011101 00001110 10000011
(28)
Tabel 2.4 User Data Pengirim (lanjutan)
Karakter <spasi> K a s i h
Desimal 32 75 97 115 105 104
Septet 0 100000 1001011 1100001 111001 1 11010 01 1101 000
Oktet 10010110 - 11100001 01111001 00011010 00001101
Hexa 96 - E1 79 1A 0D
Proses Konversi Septet ke Oktet :
a. Untuk data septet pertama tidak dipisahkan. Lalu mulai dari data septet ke-2 yaitu karakter “e” (1100101) dipisahkan 1 bit terakhirnya menjadi 110010 1, kemudian data ke-3, karakter “s” (1110010) dipisahkan 2 bit terakhirnya menjadi 11100 10. Begitu seterusnya hingga data ke-8. Kemudian diulangi untuk proses pertama untuk data ke-9, 17, 25, dan seterusnya.
b. Selanjutnya data oktet pertama adalah data septet pertama ditambahkan di depannya bit yang dipisahkan pada data septet ke-2. Data oktet ke-2 adalah data septet ke-2 ditambahkan di depannya bit yang dipisahkan pada data septet ke-3. Begitu seterusnya sampai data ke-7. Karena pada data ke-8 data septet dipisahkan semua, maka tidak ada data oktet-nya. Untuk data terakhir bit septet-nya ditambahkan dengan “0” sampai bit berjumlah delapan.
Dari tabel dapat dilihat bahwa hasil dari pengkodean adalah D4B23CDD0E8396E1791A0D.
Jadi hasil keseluruhan format PDU untuk contoh tersebut adalah
0011000E91268862515386F50000AB0CD4B23CDD0E8396E1791A0D
2.2.2SMS PDU Mobile Terminated
SMS PDU Penerima (Mobile Terminated) adalah pesan yang masuk ke ponsel dari SMSC. Pada dasarnya format yang kita terima dari SMSC masih dalam format PDU. Skema format PDU penerima adalah sebagai berikut :
SCA PDU Type OA PID DCS SCTS UDL UD
(29)
Misalkan ponsel menerima pesan dari +626169933890 dengan isi pesan adalah “Terima Kasih” pada tanggal 5 Januari 2010 pukul 17:01:09 WIB, maka format PDU adalah :
06912612000060040C912616963983090000011050711090820CD4B23CDD0E8396 E1791A0D, dengan penjelasan sebagai berikut:
2.2.2.1Service Center Address (SCA)
SCA merupakan informasi dari nomor SMSC. SCA memiliki tiga komponen utama yaitu len, type of number dan service center number. Dalam pengiriman pesan nomor SMSC tidak dicantumkan.
Tabel 2.5 Service Center Address Penerima
Oktet Len Type of Number Service Center Of Number
Keterangan Panjang informasi SMSC dalam oktet Format nomor dari SMSC 91 hexa = format
internasional
Nomor SMSC dari operator pengirim. Jika panjangnya ganjil, maka pada karakter
terakhir ditambah dengan F hexa Telkomsel : 6281100000
(PDU : 2618010000) Exelcom : 62818445009
(PDU : 2618455400F9) Smart : 6288102150 (PDU : 2688011205) Flexi : 6221000006 (PDU : 2612000060)
Hasil 06 91 2612000060
2.2.2.2PDU Type
Nilai default dari PDU Type untuk pesan yang diterima adalah 04 hexa.
2.2.2.3Originator Address (OA)
Originator Address adalah alamat (nomor) dari pengirim pesan, dimana format-nya terdiri atas panjang nomor (Len), tipe nomor (Type of Number) dan nomor (Originator Number).
(30)
Oktet Len Type of Number Originator Number Keterangan Panjang nomor pengirim Format nomor pengirim 91 hexa = format
internasional
Nomor pengirim. Jika panjangnya ganjil maka pada karakter terakhir ditambahkan
dengan F h
Hasil 0C 91 261696398309
Jadi nilai OA pada contoh ini adalah 0C91261696398309.
2.2.2.4Protocol Identifier (PID)
Nilai Protocol Identifier untuk standar teks adalah 00 h.
2.2.2.5Data Coding Scheme (DCS)
Data Coding Scheme untuk teks standar bernilai 00 h.
2.2.2.6Service Center Time Stamp (SCTS)
Service Center Time Stamp merupakan waktu penerimaan pesan oleh SMSC. SCTS terdiri atas tahun, bulan, tanggal, jam, menit, detik dan zona waktu. Nilai SCTS untuk contoh ini adalah 01105071109082.
Tabel 2.7 Service Center Time Stamp Penerima
Nama Hasil Nilai
Year 10 (2010) 01
Month 01 (Januari) 10
Date 05 50
Hour 17 71
Minute 01 10
Second 09 90
Time Zone
28, dimana 1 unit = 15 menit. Jadi (15 x 28) /60 = 7 jam. Sehingga menjadi GMT + 07.00
= WIB
82
(31)
User Data Length atau panjang pesan yang diterima adalah sebanyak 12 karakter. Jadi nilai UDL adalah 0C.
2.2.2.8User Data (UD)
User Data pada contoh ini adalah D4B23CDD0E8396E1791A0D.
Tabel 2.8 User Data Penerima
Hexa D4 B2 3C DD 0E 83
Oktet 11010100 10110010 00111100 11011101 00001110 10000011 Septet 1010100 1100101 1110010 1101001 1101101 1100001
Desimal 84 101 114 105 109 97
Karakter T e r i m a
Hexa 96 - E1 79 1A 0D
Oktet 10010110 - 11100001 01111001 00011010 00001101 Septet 0100000 1001011 1100001 1110011 1101001 1101000
Desimal 32 75 97 115 105 104
Karakter <spasi> K a s i h
Proses Konversi Oket ke Septet :
a. Setiap data oktet dipisahkan bit depannya sesuai posisi data. Contoh : data D4 merupakan data pertama dimana susunan bitnya adalah 11010100, maka dipisahkan satu bit di depannya menjadi 1 1010100. Kemudian data ke-2 adalah B2, susunan bitnya 10110010, maka dipisahkan menjadi 10 110010. Begitu seterusnya hingga data ke-7. Kemudian pada data ke-9, 17, 25, 33, dan seterusnya kembali seperti aturan data pertama.
b. Selanjutnya data septet pertama adalah sisa bit oktet pertama setelah dipisahkan. Data septet ke-2 adalah sisa bit oktet ke-2 ditambah di akhirnya dengan bit yang dipisah pada oktet pertama. Data septet ke-3 adalah sisa bit oktet ke-3 ditambah di akhirnya dengan bit yang dipisah pada oktet ke-2. Begitu seterusnya. Bila tidak terdapat data oktet berikutnya berarti bit depan data terakhir merupakan tanda berhenti dari pengkodean tersebut. Kemudian kembali diulang langkah pertama.
(32)
Untuk konversi dari desimal ke ASCII dapat dilihat pada tabel berikut :
Tabel 2.9 Karakter ASCII
Desimal 0 1 2 3 4 5 6 7 8 9
1 2
3 SP ! “ # $ % & ‘
4 ( ) * + , - . / 0 1
5 2 3 4 5 6 7 8 9 : ;
6 < = > ? @ A B C D E
7 F G H I J K L M N O
8 P Q R S T U V W X Y
9 Z [ \ ] ^ _ ` a b c
10 d e f g h i j k l m
11 n o p q r s t u v w
12 x y z { | } ~ DEL
2.3AT Command
AT Command merupakan perintah yang digunakan pada ponsel untuk menjalankan fungsi tertentu. (Tim Pengembangan Wahana Komputer, 2005). Perintah ini disebut demikian karena pada penulisan perintahnya, kita harus memulainya dengan huruf AT (berasal dari attention).
(33)
Tabel 2.10 AT Command
AT Command Keterangan
AT Mengecek apakah ponsel telah terhubung
AT+CMGF=<mode>
Menetapkan format mode dari terminal <mode> :
”0” = mode PDU “1” = mode Teks
AT+CMGL=<status>
Membuka daftar SMS pada SIM Card <status> :
”0” = belum dibaca “1” = sudah dibaca ”2” = belum terkirim “3” = telah terkirim
”4” = semua pesan yang ada
AT+CMGS=<len PDU> > pesan dalam PDU
Mengirim pesan contoh:
AT+CMGS = 23
>0011000C912618628588210000AB09 CBB43CDD064D9B53
AT+CMGR = <index> Membaca pesan sesuai dengan nomor index pesan AT+CMGD=<index> Menghapus pesan
< index > adalah nomor urut penyimpanan pesan
2.4Paradigma Berorientasi Objek
Objek adalah segala sesuatu yang ada di sekitar kita, dimana objek – objeklah yang menyusun dunia ini. Misalkan : sepeda motor, mobil, bis, rumah dan lainnya. Setiap objek mempunyai informasi – informasi atau atribut – atribut dan perilaku sebagai suatu operasi pengaturnya. (Kendall, K.E dan Kendall, J. E, 2003). Atribut untuk objek tersebut antara lain: jumlah roda, warna, berat, dan seterusnya. Sedangkan perilaku atau operasi pengatur objek tesebut adalah berjalan, belok kanan, belok kiri, naikkan kecepatan dan lainnya.
Berorientasi objek atau object oriented merupakan paradigma baru dalam rekayasa perangkat lunak yang memandang sistem sebagai kumpulan objek – objek yang saling berinteraksi antara informasi, atribut dan perilaku (behaviour).
(34)
2.5UML (Unified Modeling Language)
Unified Modeling Language adalah sebuah bahasa grafis yang telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. (Agarwal, R dan Sinha, A, P, 2003). UML merupakan dasar fundamental dari teknik analisis berorientasi objek, berbentuk diagram – diagram yang digunakan untuk menampilkan konstruksi dari sistem berorientasi objek, seperti cetak biru (blue print) suatu pembangunan gedung yang menggambarkan konstruksi bangunan tersebut. (Kendall, K.E dan Kendall, J. E, 2003).
UML mendefinisikan diagram – diagram berikut:
2.5.1Use-case Diagram
Use-case diagram menggambarkan secara grafis perilaku perangkat lunak. Diagram ini memberikan gambaran menurut perspektif pengguna perangkat lunak. Sebuah use-case diagram mengandung actor, use-use-case dan interaksi antara actor dengan use-use-case. (Suhendar, A dan Gunadi, H, 2002).
2.5.1.1Actor
Actor merupakan segala sesuatu yang perlu berinteraksi dengan sistem untuk pertukaran informasi. Actor memberikan suatu gambaran jelas tentang apa yang harus dilakukan perangkat lunak.
Actor dinotasikan seperti pada gambar berikut:
Gambar 2.3 Actor
2.5.1.2Use case
Use case merupakan hasil penyusunan kembali lingkup fungsionalitas sistem menjadi banyak pernyataaan fungsionalitas sistem yang lebih kecil. Sebuah use case merepresentasikan satu tujuan tunggal dari sistem dan menggambarkan satu rangkaian
(35)
kegiatan dan interaksi pengguna untuk mencapai tujuan (Whitten, J. L., et all, 2004). Use case menggambarkan fungsi – fungsi sistem dari sudut pandang pengguna eksternal. Diagram ini juga dapat diartikan sebagai urutan transaksi berkaitan yang dilakukan satu actor dengan perangkat lunak.
Use case dinotasikan seperti pada gambar berikut:
Gambar 2.4 Use case
2.5.1.3Interaksi Actor dengan Use-case
Interaksi Actor dengan Use case dinotasikan seperti pada gambar berikut:
Gambar 2.5 Use-case Diagram
2.5.2Activity Diagram
Activity diagram memodelkan alur kerja (workflow) sebuah proses bisnis dan urutan aktifitas dalam suatu proses. Diagram ini sangat mirip dengan sebuah flowchart karena kita dapat memodelkan sebuah alur kerja dari satu aktifitas ke aktifitas lainnya atau dari satu aktifitas ke dalam keadaan sesaat (state). (Suhendar, A dan Gunadi, H, 2002).
Activity diagram menggambarkan aliran aktifitas dari sistem yang sedang dirancang, bagaimanan masing – masing aliran berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Diagram ini juga dapat menggambarkan proses parallel yang mungkin terjadi pada beberapa eksekusi.
(36)
Contoh activity diagram diperlihatkan pada gambar berikut:
Gambar 2.6 Activity Diagram
2.5.3Class Diagram
Class diagram merupakan struktur kelas – kelas dari suatu sistem yang memperlihatkan hubungan antar kelas dan penjelasan tiap – tiap kelas. Pada diagram ini terdapat nama kelas, atribut dan operasi kelas tersebut.
(37)
Selama proses analisis, class diagram memperlihatkan aturan – aturan dan tanggung jawab entitas yang menentukan perilaku sistem. Selama tahap desain, diagram ini berperan dalam menangkap struktur dari semua kelas yang membentuk arsitektur sistem yang dibuat (Suhendar, A dan Gunadi, H, 2002).
Contoh class diagram diperlihatkan pada gambar berikut:
Gambar 2.7 Class Diagram
2.5.4Sequence Diagram
Sequence diagram menjelaskan interaksi objek yang disusun dalam suatu urutan waktu. Diagram ini memperlihatkan tahap demi tahap apa yang harus terjadi untuk menghasilkan sesuatu di dalam use-case. Sequence diagram secara khusus berinteraksi dengan use-case.
Masing-masing sequence diagram menggambarkan aliran pada suatu use case. Sequence diagram dapat dibaca dengan melihat pada objek-objek dan pesan-pesan (message). Objek-objek yang berperan dalam aliran diperlihatkan pada kotak empat persegi panjang yang melintas pada bagian atas diagram. Setiap objek memiliki garis hidup (lifeline), yang digambarkan sebagai garis vertikal di bawah nama suatu objek.
(38)
Gambar 2.8 Sequence Diagram
2.5.5Package Diagram
Sebuah package adalah sebuah bentuk pengelompokkan yang memungkinkan pembangun untuk mengambil setiap bentuk di UML dan mengelompokkan elemen – elemennya dalam tingkatan unit yang lebih tinggi (Fowler, 2005). Diagram ini merupakan mekanisme pengelompokan yang digunakan untuk menandakan pengelompokan elemel – elemen model. Sebuah package dapat mengandung beberapa paket lain di dalamnya. Diagram ini digunakan untuk memudahkan mengorganisasi elemen – elemen model.
Notasi package diagram digambarkan sebagai berikut:
(39)
2.5.6Deployment Diagram
Deployment diagram menunjukkan susunan fisik sebuah sistem, menunjukkan bagian perangkat lunak yang berjalan pada perangkat keras (Fowler, 2005). Diagram ini adalah diagram dengan tipe implementasi yang digunakan untuk secara grafis menggambarkan arsitektur fisik dari perangkat lunak sistem. Diagram ini dapat digunakan untuk menunjukkan ketergantungan di antara komponen – komponen penyusun sistem. Deployment diagram menggambarkan bagaimana komponen dibangun dalam infrastruktur sistem, di mana suatu komponen (pada mesin, server atau perangkat keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server.
Sebuah node adalah server, workstation atau perangkat keras lain yang digunakan untuk membangun komponen dalam lingkungan sebenarnya.
Contoh deployment diagram diperlihatkan pada gambar berikut:
Gambar 2.10 Deployment Diagram
2.6Analisis Persyaratan dengan UML
Analisis persyaratan meliputi usaha untuk mengetahui apa kemampuan sebuah sistem yang diinginkan pengguna dan pelanggan dari sebuah pembuat perangkat lunak (Fowler, 2005). Analisis ini dilakukan untuk mendapatkan informasi atau persyaratan cukup untuk mempersiapkan model yang menggambarkan apa yang diperlukan dari perspektif pengguna. Diagram yang digunakan dalam analisis persyaratan yaitu:
(40)
1. Use case diagram yang digunakan untuk menunjukkan fungsionalitas suatu sistem dan bagaimana sistem berinterakasi dengan dunia luar.
2. Activity diagram yang menunjukkan alur kerja (work flow) sebuah proses bisnis dan urutan aktivitas dalam suatu proses.
3. Class diagram yang membantu dalam visualisasi struktur sistem yang mendeskripsikan jenis-jenis objek dalam suatu sistem dan hubungan yang terdapat diantara objek tersebut.
4. Package diagram yang digunakan untuk mengelompokkan elemen-elemen model atau kelas.
2.7Desain dengan UML
Saat membuat desain adalah saat untuk berpikir secara teknis dalam menggambarkan diagram – diagram UML. Diagram yang digunakan dalam mendesain sistem yaitu: 1. Class diagram dalam sudut pandang perangkat lunak, untuk menunjukkan class
yang terdapat di dalam perangkat lunak dan bagaimana mereka saling berhubungan.
2. Sequence diagram untuk menjelaskan interaksi objek yang disusun dalam suatu urutan waktu.
3. Package diagram yang digunakan untuk mengelompokkan elemen-elemen model atau kelas.
(41)
BAB 3
ANALISIS DAN PERANCANGAN SISTEM
Analisis sistem meliputi Analisis Persyaratan Sistem, Analisis Kebutuhan Sistem, kemudian akan digambarkan Use Case Diagram Analisis Sistem, Class Diagram Analisis Sistem dan Package Diagram Analisis Sistem dari hasil analisis tersebut.
Pada tahap perancangan sistem akan digambarkan class diagram desain sistem secara keseluruhan, sequence diagram yang menjelaskan interaksi antar objek serta diperjelas dengan hubungan antara class diagram yang berperan dan deployment diagram untuk menunjukkan arsitektur sistem yang dibangun.
3.1Analisis Persyaratan Sistem
Pada analisis sistem akan dilakukan analisis terhadap proses bisnis, identifikasi aktor, identifikasi use case, serta digambarkan class diagram persyaratan sistem dari hasil identifikasi aktor dan use case.
3.1.1Proses Bisnis Sistem Pelelangan Barang Berbasis SMS
Proses pelelangan akan dilaksanakan setiap hari kerja dan lelang aktif selama jam kerja, yakni pukul 09.00 sampai 17.00 WIB. Jenis barang yang dilelang beragam, sesuai dengan barang yang sudah lewat tanggal pembayarannya.
Peserta lelang diwajibkan mendaftarkan diri langsung ke kantor Perum Pegadaian. Pendaftaran tidak dapat dilakukan melalui SMS karena terkait dengan validitas data peserta. Peserta dapat mengajukan penawaran berulang kali, tidak ada batasan jumlah penawaran yang diajukan. Peserta lelang dapat mengikuti lebih dari satu jenis barang yang dilelang. Pemenang lelang akan ditentukan tepat pada pukul 17.00 WIB, setelah lelang ditutup.
(42)
3.1.2Use Case Diagram Persyaratan Sistem
Dilakukan identifikasi aktor dan use case dalam membangun suatu use case diagram persyaratan sistem.
Identifikasi aktor dilakukan dengan menjawab pertanyaan berikut, yaitu:
1. Siapa yang menggunakan sistem? Atau, siapa yang dipengaruhi oleh kehadiran sistem? Atau, Pihak mana yang membutuhkan sistem untuk melaksanakan tugasnya?
Jawaban:
Peserta lelang (bidder) dan pihak Perum Pegadaian.
2. Siapa yang mempengaruhi sistem? Atau, kelompok mana yang diperlukan sistem untuk melaksanakan fungsinya?
Jawaban:
Karyawan Perum Pegadaian, dalam hal ini operator.
3. Perangkat atau sistem eksternal apa yang menggunakan sistem untuk melaksanakan tugasnya?
Jawaban:
Ponsel pada server dan basis data.
4. Masalah apa yang diselesaikan sistem (dengan demikian, untuk apa)? Jawaban:
Proses notifikasi, penawaran, dan pengumuman pemenang terhadap barang yang dilelang. Agar peserta lelang dapat mengikuti proses pelelangan dimana pun dan kapan pun sesuai dengan jadwal pelelangan.
5. Bagaimana pemakai menggunakan sistem? Jawaban:
Peserta lelang menginput pin untuk verifikasi dan menginput penawaran. Peserta juga dapat meminta informasi pelelangan yang aktif, informasi penawaran terakhir dan informasi pemenang lelang. Operator login terlebih dahulu, kemudian dapat menginput data perserta, data barang yang dilelang dan mencetak laporan pelelangan.
(43)
Jawaban dari beberapa pertanyaan di atas dapat menyimpulkan bahwa aktor yang berperan terhadap sistem yaitu peserta (bidder) dan operator.
Identifikasi use case dilakukan dengan menjawab pertanyaan berikut untuk masing – masing aktor, yaitu:
A. Bidder
1. Apa tugas utama bidder? Jawaban:
Mengajukan penawaran
2. Informasi apa yang dibutuhkan bidder dari sistem? Jawaban:
a. Informasi jenis dan harga awal barang yang sedang dilelang b. Informasi batas waktu pelelangan
c. Informasi penawaran terakhir suatu barang d. Informasi pemenang lelang
3. Informasi apa yang disediakan bidder untuk sistem? Jawaban:
Informasi data bidder.
4. Apakah sistem perlu menginformasikan kepada bidder tentang segala perubahan atau kejadian yang telah terjadi?
Jawaban: Ya, perlu.
5. Apakah bidder perlu untuk menginformasikan segala perubahan yang terjadi atau kejadian – kejadian yang muncul pada operator?
Jawaban: Ya, perlu.
Jadi kegiatan yang dilakukan oleh bidder adalah: a. Mengajukan penawaran
b. Meminta informasi barang yang dilelang
c. Meminta informasi penawaran terakhir suatu barang d. Meminta informasi pemenang lelang
(44)
B. Operator
1. Apa tugas utama operator? Jawaban:
a. Memasukkan data bidder b. Memasukkan data operator
c. Memasukkan data barang yang dilelang d. Mencetak laporan
2. Informasi apa yang dibutuhkan operator dari sistem? Jawaban:
a. Verifikasi login
b. Informasi pemenang lelang c. Laporan lelang
3. Informasi apa yang disediakan operator untuk sistem? Jawaban:
a. Informasi data bidder b. Informasi data barang c. Informasi data penawaran
4. Apakah sistem perlu menginformasikan kepada operator tentang segala perubahan atau kejadian yang telah terjadi?
Jawaban: Ya, perlu
5. Apakah operator perlu untuk menginformasikan segala perubahan yang terjadi atau kejadian – kejadian yang muncul pada bidder?
Jawaban: Ya, perlu.
Jadi kegiatan yang dilakukan oleh operator adalah: a. Memasukkan data bidder
b. Memasukkan data barang yang dilelang c. Mengubah data bidder
(45)
e. Menghapus data bidder f. Menghapus data barang g. Mencetak laporan
Berikut ini adalah Use Case Diagram Persyaratan Sistem dari hasil identifikasi aktor dan use case sebelumnya:
Gambar 3.1 Use Case Diagram Persyaratan Sistem
3.2Analisis Kebutuhan Sistem
Pada tahap ini akan dibahas mengenai hasil analisis fungsi sistem, input sistem, output sistem, dan batasan sistem dari Aplikasi Pelelangan Barang Berbasis Short Message Service (SMS).
(46)
3.2.1Analisis Fungsionalitas Sistem
Dari hasil analisis terhadap proses bisnis yang berlangsung, maka aplikasi yang dirancang harus memiliki fungsi-fungsi sebagai berikut :
1. Mengirimkan penawaran lelang 2. Meminta informasi barang
3. Meminta informasi penawaran terakhir 4. Meminta informasi pemenang lelang 5. Meminta informasi pelelangan berikutnya 6. Menyimpan penawaran peserta lelang 7. Menyimpan data barang yang dilelang 8. Menyimpan data peserta lelang (bidder) 9. Menyimpan data pengguna aplikasi (user) 10.Mengatur waktu dan proses pelelangan 11.Membalas penawaran yang masuk 12.Membalas request informasi yang masuk 13.Menentukan pemenang lelang
14.Mengirim informasi lelang 15.Menyimpan data hasil pelelangan 16.Menampilkan laporan peserta lelang
17.Menampilkan laporan pemenang pelelangan 18.Menampilkan laporan barang yang dilelang
3.2.2Analisis input dan output sistem
Data yang menjadi input ke sistem adalah: 1. Data barang yang dilelang
2. Data peserta lelang
3. Data pengguna aplikasi (user) 4. Data penawaran lelang
Informasi yang menjadi output dari sistem adalah: 1. Informasi barang yang dilelang
(47)
3. Informasi pemenang lelang 4. Informasi pelelangan berikutnya
3.2.3Analisis batasan sistem
Batasan dari sistem yang akan didesain yaitu:
1. Proses registrasi peserta lelang dilakukan oleh operator (bukan melalui SMS). 2. Tidak mencakup proses pembayaran barang yang telah dimenangkan.
3.3Use Case Diagram Analisis Sistem
Setelah dilakukan analisis terhadap kebutuhan, fungsionalitas, input/output dan batasan sistem, maka perangkat lunak yang akan didesain mencakup 4 aktor yaitu: 1. Peserta lelang (bidder)
2. Operator 3. Admin
4. Thread Sistem
Use case yang diidentifikasi dari aktor bidder yaitu: 1. Mengajukan penawaran
2. Meminta informasi barang
3. Meminta informasi penawaran terakhir 4. Meminta informasi pemenang lelang 5. Meminta informasi pelelangan berikutnya
Use case yang diidentifikasi dari aktor operator yaitu: 1. Login
2. Memasukkan data bidder 3. Memasukkan data barang 4. Mengubah data bidder 5. Mengubah data barang 6. Menghapus data bidder 7. Menghapus data barang 8. Mengirim Informasi 9. Mencetak laporan
(48)
Use case yang diidentifikasi dari aktor admin yaitu: 1. Login
2. Memasukkan data operator 3. Memasukkan data admin 4. Mengubah data operator 5. Mengubah data admin 6. Menghapus data operator 7. Menghapus data admin 8. Manajemen Lelang
9. Menjalankan server lelang 10.Menonaktifkan server lelang
Use case yang diidentifikasi dari aktor Thread Sistem yaitu: 1. Menentukan pemenang lelang
2. Membalas penawaran 3. Menerima penawaran 4. Menerima request informasi 5. Membalas request informasi
Setelah aktor dan use case teridentifikasi, dapat digambarkan suatu use case diagram sebagai berikut:
(49)
Gambar 3.2 Use Case Diagram Analisis Sistem (lanjutan)
3.3.1Use case Mengajukan Penawaran
Use case Mengajukan Penawaran dapat dijelaskan pada tabel dokumentasi naratif berikut ini:
Tabel 3.1 Dokumentasi Naratif Mengajukan Penawaran Nama Use Case: Mengajukan Penawaran
ID Use Case: -- Prioritas: Tinggi
Sumber: Persyaratan
Pelaku Bisnis Utama: Bidder Pelaku Sistem Utama: Bidder Pelaku Partisipan Lain: --
(50)
Tabel 3.1 Dokumentasi Naratif Mengajukan Penawaran (lanjutan) Stakeholder yang
Berminat Lain: --
Deskripsi: Use case ini mendeskripsikan proses mengajukan penawaran. Prakondisi:
Pemicu: Hanya bidder yang terdaftar yang dapat mengirimkan penawaran. Bidang khas suatu
event:
Kegiatan Pelaku
Langkah 1: Memasukkan pin, kode barang dan jumlah penawaran. Langkah 2: Mengeksekusi perintah kirim.
Respons Sistem
Langkah 3: MIDlet mengirimkan pesan ke server lelang
Langkah 4: Memeriksa validasi pin dan no. ponsel serta kode barang dan jumlah penawaran.
Langkah 5: Menyimpan penawaran bidder ke basis data.
Bidang Alternatif: Alt-4: Sistem tidak menemukan data bidder, atau pin tidak cocok dengan no. ponsel, atau kode barang tidak terdaftar, atau jumlah penawaran tidak sesuai, maka sistem menampilkan pesan bahwa proses penawaran gagal.
Kesimpulan: Use case mengajukan penawaran dinyatakan berhasil jika data bidder terdapat pada basis data dan data bidder valid dan jumlah penawaran sesuai.
Postkondisi: Bidder menerima pesan bahwa proses penawaran telah berhasil. Aturan Bisnis: --
Batasan dan Spesifikasi Implementasi: --
Asumsi: --
Masalah terbuka: --
Alur kerja (workflow) pada use case Mengajukan Penawaran dapat digambarkan dalam activity diagram berikut:
(51)
Gambar 3.3 Activity Diagram untuk Use Case Mengajukan Penawaran
3.3.2Use case Meminta Informasi Barang
Use case Meminta Informasi Barang dapat dijelaskan pada tabel dokumentasi naratif berikut ini:
Tabel 3.2 Dokumentasi Naratif Meminta Informasi Barang Nama Use Case: Meminta Informasi Barang
ID Use Case: -- Prioritas: Sedang Sumber: Persyaratan Pelaku Bisnis Utama: Bidder Pelaku Sistem Utama: Bidder Pelaku Partisipan
Lain:
(52)
Tabel 3.2 Dokumentasi Naratif Meminta Informasi Barang (lanjutan) Stakeholder yang
Berminat Lain:
--
Deskripsi: Use case ini mendeskripsikan proses meminta informasi barang. Prakondisi: Bidder terlebih dahulu harus terdaftar pada sistem.
Pemicu: Use case ini diinisialisasi saat bidder menyeleksi pilihan untuk meminta informasi barang.
Bidang khas suatu event:
Kegiatan Pelaku Langkah 1: Masuk ke aplikasi . Langkah 2: Memilih menu info lelang.
Langkah 3: Mengeksekusi info barang.
Respons Sistem
Langkah 4: Server lelang menerima permintaan Langkah 5: Memproses dan membalas permintaan informasi barang ke bidder
Bidang Alternatif: Alt-3: Jika permintaan tidak berhasil maka bidder harus mengulangi kembali.
Kesimpulan: Use case mendeskripsikan permintaan informasi barang yang dilelang. Postkondisi: Bidder menerima pesan balasan berupa informasi barang.
Aturan Bisnis: -- Batasan dan
Spesifikasi Implementasi:
--
Asumsi: --
Masalah terbuka: --
Alur kerja (workflow) pada use case Meminta Informasi Barang dapat digambarkan dalam activity diagram berikut:
(53)
Gambar 3.4 Activity Diagram untuk Use Case Meminta Informasi Barang
3.3.3Use case Meminta Informasi Penawaran Terakhir
Use case Meminta Informasi Penawaran Terakhir dapat dijelaskan pada tabel dokumentasi naratif berikut ini:
Tabel 3.3 Dokumentasi Naratif Meminta Informasi Penawaran Terakhir Nama Use Case: Meminta Informasi Penawaran Terakhir
ID Use Case: -- Prioritas: Sedang Sumber: Persyaratan Pelaku Bisnis Utama: Bidder
(54)
Tabel 3.3 Dokumentasi Naratif Meminta Informasi Penawaran Terakhir (lanjutan)
Pelaku Sistem Utama: Bidder Pelaku Partisipan Lain: -- Stakeholder yang Berminat Lain: --
Deskripsi: Use case ini mendeskripsikan proses meminta informasi penawaran terakhir. Prakondisi: Bidder terlebih dahulu harus terdaftar pada sistem.
Pemicu: Use case ini diinisialisasi saat bidder menyeleksi pilihan untuk meminta informasi penawaran terakhir
Bidang khas suatu event:
Kegiatan Pelaku Langkah 1: Masuk ke aplikasi . Langkah 2: Memilih menu info lelang.
Langkah 3: Mengeksekusi info penawaran terakhir.
Respons Sistem
Langkah 4: Server lelang menerima permintaan Langkah 5: Memproses dan membalas permintaan informasi penawaran terakhir ke bidder Bidang Alternatif: Alt-3: Jika permintaan tidak berhasil maka bidder harus mengulangi
kembali.
Kesimpulan: Use case mendeskripsikan permintaan informasi penawaran terakhir barang yang dilelang.
Postkondisi: Bidder menerima pesan balasan berupa informasi penawaran terakhir barang – barang yang dilelang.
Aturan Bisnis: -- Batasan dan
Spesifikasi Implementasi:
--
Asumsi: --
(55)
Alur kerja (workflow) pada use case Meminta Informasi Penawaran Terakhir dapat digambarkan dalam activity diagram berikut:
Gambar 3.5 Activity Diagram untuk Use Case Meminta Informasi Penawaran Terakhir
3.3.4Use case Meminta Informasi Pemenang
Use case Meminta Informasi Pemenang dapat dijelaskan pada tabel dokumentasi naratif berikut ini:
(56)
Tabel 3.4 Dokumentasi Naratif Meminta Informasi Pemenang Nama Use Case: Meminta Informasi Pemenang
ID Use Case: -- Prioritas: Sedang Sumber: Persyaratan Pelaku Bisnis Utama: Bidder Pelaku Sistem Utama: Bidder Pelaku Partisipan Lain: -- Stakeholder yang Berminat Lain: --
Deskripsi: Use case ini mendeskripsikan proses meminta informasi pemenang. Prakondisi: Bidder terlebih dahulu harus terdaftar pada sistem.
Pemicu: Use case ini diinisialisasi saat bidder menyeleksi pilihan untuk meminta informasi pemenang.
Bidang khas suatu event:
Kegiatan Pelaku Langkah 1: Masuk ke aplikasi . Langkah 2: Memilih menu info lelang.
Langkah 3: Mengeksekusi info pemenang..
Respons Sistem
Langkah 4: Server lelang menerima permintaan Langkah 5: Memproses dan membalas permintaan informasi pemenang ke bidder
Bidang Alternatif: Alt-3: Jika permintaan tidak berhasil maka bidder harus mengulangi kembali.
Kesimpulan: Use case mendeskripsikan permintaan informasi pemenang lelang. Postkondisi: Bidder menerima pesan balasan berupa informasi pemenang lelang. Aturan Bisnis: --
Batasan dan Spesifikasi Implementasi:
--
Asumsi: --
(57)
Alur kerja (workflow) pada use case Meminta Informasi Pemenang dapat digambarkan dalam activity diagram berikut:
Gambar 3.6 Activity Diagram untuk Use Case Meminta Informasi Pemenang
3.3.5Use case Meminta Informasi Pelelangan Berikutnya
Use case Meminta Informasi Pelelangan Berikutnya dapat dijelaskan pada tabel dokumentasi naratif berikut ini:
Tabel 3.5 Dokumentasi Naratif Meminta Informasi Pelelangan Berikutnya Nama Use Case: Meminta Informasi Pelelangan Berikutnya
ID Use Case: -- Prioritas: Sedang
(58)
Tabel 3.5 Dokumentasi Naratif Meminta Informasi Pelelangan Berikutnya (lanjutan)
Sumber: Persyaratan
Pelaku Bisnis Utama: Bidder Pelaku Sistem Utama: Bidder Pelaku Partisipan Lain: -- Stakeholder yang Berminat Lain: --
Deskripsi: Use case ini mendeskripsikan proses meminta informasi pelelangan berikutnya yang akan diselenggarakan.
Prakondisi: Bidder terlebih dahulu harus terdaftar pada sistem.
Pemicu: Use case ini diinisialisasi saat bidder menyeleksi pilihan untuk meminta informasi pelelangan berikutnya
Bidang khas suatu event:
Kegiatan Pelaku Langkah 1: Masuk ke aplikasi . Langkah 2: Memilih menu info lelang.
Langkah 3: Mengeksekusi info pelelangan berikutnya
Respons Sistem
Langkah 4: Server lelang menerima permintaan Langkah 5:Memproses dan membalas permintaan informasi pelelangan berikutnya ke bidder Bidang Alternatif: Alt-3: Jika permintaan tidak berhasil maka bidder harus mengulangi
kembali.
Kesimpulan: Use case mendeskripsikan permintaan informasi pelelangan berikutnya yang akan diselenggarakan.
Postkondisi: Bidder menerima pesan balasan berupa informasi pelelangan berikutnya. Aturan Bisnis: --
Batasan dan Spesifikasi Implementasi:
--
Asumsi: --
(59)
Alur kerja (workflow) pada use case Meminta Informasi Pelelangan Berikutnya dapat digambarkan dalam activity diagram berikut:
Gambar 3.7 Activity Diagram untuk Use Case Meminta Informasi Pelelangan Berikutnya
3.3.6Use case Login
Use case Login dijelaskan pada tabel dokumentasi naratif berikut ini:
Tabel 3.6 Dokumentasi Naratif Login Nama Use Case: Login
ID Use Case: -- Prioritas: Tinggi
(60)
Tabel 3.6 Dokumentasi Naratif Login (lanjutan)
Sumber: Persyaratan
Pelaku Bisnis Utama: Admin, Operator Pelaku Sistem Utama: Admin, Operator Pelaku Partisipan Lain: --
Stakeholder yang Berminat Lain:
--
Deskripsi: Use case ini mendeskripsikan proses login user ke dalam aplikasi. Prakondisi: Bidder terlebih dahulu harus terdaftar pada sistem.
Pemicu: Hanya user (admin dan operator) yang terdaftar yang dapat mengakses aplikasi.
Bidang khas suatu event:
Kegiatan Pelaku Langkah 1: Masuk ke halaman login.
Langkah 2: Memasukkan username dan password.
Respons Sistem
Langkah 3: Mencari data user pada database dan mencocokkannya dengan password.
Langkah 4: Mengizinkan user masuk ke dalam aplikasi.
Bidang Alternatif: Alt-4: Sistem tidak menemukan data user, atau password tidak cocok dengan username, maka sistem menampilkan pesan bahwa proses login gagal. Kesimpulan: Use case login dinyatakan berhasil jika data user terdapat pada database serta
username dan password valid.
Postkondisi: User masuk ke halaman utama aplikasi. Aturan Bisnis: --
Batasan dan Spesifikasi Implementasi:
--
Asumsi: --
Masalah terbuka: --
Alur kerja (workflow) pada use case login dapat digambarkan dalam activity diagram berikut:
(61)
Gambar 3.8 Activity Diagram untuk Use Case Login
3.3.7Use Case Menambah Data Bidder
Use case Menambah Data Bidder dijelaskan pada tabel dokumentasi naratif berikut:
Tabel 3.7 Dokumentasi Naratif Menambah Data Bidder Nama Use Case: Menambah data bidder
ID Use Case: -- Prioritas: Tinggi Sumber: Persyaratan Pelaku Bisnis
Utama:
Operator
Pelaku Sistem Utama:
(62)
Tabel 3.7 Dokumentasi Naratif Menambah Data Bidder (lanjutan) Pelaku Partisipan Lain: -- Stakeholder yang Berminat Lain: --
Deskripsi: Use case ini mendeskripsikan proses menambah dan menyimpan data peserta lelang (bidder).
Prakondisi: Sudah ada data bidder yang sama sebelumnya.
Pemicu: Use case ini diinisialisasi saat operator memilih pilihan untuk menambah data bidder yang baru.
Bidang khas suatu event:
Kegiatan Pelaku Langkah 1: Memilih menu manajemen bidder.
Langkah 3: Memasukkan no. ktp no. ponsel, nama dan alamat peserta.
Langkah 5: Mengeksekusi perintah tambah.
Respons Sistem Langkah 2: Menampilkan form manajemen bidder.
Langkah 4: Mengecek apakah no. ktp sudah terdaftar atau belum.
Langkah 6: Mengecek apakah data yang diisi sudah lengkap .
Langkah 7: Menyimpan data bidder pada basis data.
Bidang Alternatif: Alt-Langkah 4: Jika no. ktp sudah ada, maka sistem akan menonaktifkan button tambah bidder dan pelaku tidak dapat melanjutkan, proses menambah data barang.
Alt-Langkah 6: Jika data yang diisi belum lengkap maka sistem akan menampilkan informasi agar data dilengkapi.
Kesimpulan: Use case ini merupakan proses menambah data bidder baru. Postkondisi: Data bidder tersimpan pada basis data sistem pelelangan Aturan Bisnis: --
Batasan dan Spesifikasi Implementasi:
--
Asumsi: --
(63)
Alur kerja (workflow) pada use case Menambah Data Bidder dapat digambarkan dalam activity diagram berikut:
Gambar 3.9 Activity Diagram untuk Use Case Menambah Data Bidder
3.3.8Use Case Menambah Data Barang
Use case Menambah Data Barang dijelaskan pada tabel dokumentasi naratif berikut:
Tabel 3.8 Dokumentasi Naratif Menambah Data Barang Nama Use Case: Menambah data barang
ID Use Case: -- Prioritas: Tinggi
Sumber: Persyaratan
Pelaku Bisnis Utama: Operator Pelaku Sistem Utama: Operator Pelaku Partisipan Lain: --
(64)
Tabel 3.8 Dokumentasi Naratif Menambah Data Barang (lanjutan). Stakeholder yang
Berminat Lain:
--
Deskripsi: Use case ini mendeskripsikan proses menambah dan menyimpan data barang yang akan dilelang.
Prakondisi: Sudah ada data barang yang sama sebelumnya.
Pemicu: Use case ini diinisialisasi saat operator memilih pilihan untuk menambah data barang yang baru.
Bidang khas suatu event:
Kegiatan Pelaku Langkah 1: Memilih menu manajemen barang.
Langkah 3: Memasukkan kode barang, nama barang, harga awal, dan tanggal lelang.
Langkah 5: Mengeksekusi perintah tambah.
Respons Sistem Langkah 2: Menampilkan form manajemen barang.
Langkah 4: Mengecek apakah kode barang sudah terdaftar atau belum.
Langkah 6: Mengecek apakah data yang diisi sudah lengkap .
Langkah 7: Menyimpan data barang pada basis data.
Bidang Alternatif: Alt-Langkah 4: Jika kode barang sudah ada, maka sistem akan
menonaktifkan button tambah barang dan pelaku tidak dapat melanjutkan, proses menambah data barang.
Alt-Langkah 6: Jika data yang diisi belum lengkap maka sistem akan menampilkan informasi agar data dilengkapi.
Kesimpulan: Use case ini merupakan proses menambah data barang baru yang akan dilelang.
Postkondisi: Data barang tersimpan pada basis data sistem pelelangan Aturan Bisnis: --
Batasan dan Spesifikasi Implementasi:
--
Asumsi: --
(65)
Alur kerja (workflow) pada use case Menambah Data Barang dapat digambarkan dalam activity diagram berikut:
Gambar 3.10 Activity Diagram untuk Use Case Menambah Data Barang
3.3.9Use Case Mengubah Data Bidder
Use case Mengubah Data Bidder dijelaskan pada tabel dokumentasi naratif berikut:
Tabel 3.9 Dokumentasi Naratif Mengubah Data Bidder Nama Use Case: Mengubah data bidder
ID Use Case: -- Prioritas: Sedang Sumber: Persyaratan Pelaku Bisnis Utama: Operator Pelaku Sistem Utama: Operator Pelaku Partisipan
Lain:
-- Stakeholder yang
Berminat Lain:
--
(1)
132 Berikut adalah tabel hasil pengujian untuk setiap modul yang ada pada Aplikasi Pelelangan Barang Berbasis SMS.
Tabel 4.1 Tabel Hasil Uji Aplikasi No. Nama Modul Prosedur Pengujian Masukan
Keluaran yang Diharapkan
Hasil
1 Memasukkan Data User
Memasukkan nama, username, password dan alamat kemudian mengeksekusi perintah Tambah nama, username, password dan alamat Konfirmasi data user berhasil tersimpan pada database √
2 Mengubah Data User
Mengubah nama, username atau alamat kemudian mengeksekusi perintah Ubah nama, username dan alamat Konfirmasi data user berhasil diubah pada database √
3 Menghapus Data User
Memilih user yang akan dihapus pada tabel kemudian mengeksekusi perintah Hapus -- Konfirmasi data user berhasil dihapus pada database √
4 Login
Memasukkan username dan password kemudian mengeksekusi perintah Tambah username dan
password Login Sukses √
5 Memasukkan Data Barang
Memasukkan kode barang, nama barang, tanggal lelang dan harga awal kemudian mengeksekusi perintah Tambah
kode barang, nama barang, tanggal lelang dan harga awal
Konfirmasi data barang berhasil tersimpan pada database √
6 Mengubah Data Barang
Mengubah kode nama barang, tanggal lelang dan harga awal
kemudian
mengeksekusi perintah Ubah
nama barang, tanggal lelang dan harga awal
Konfirmasi data barang berhasil diubah pada database √
(2)
133 Tabel 4.1 Tabel Hasil Uji Aplikasi (lanjutan)
7 Menghapus Data Barang
Memilih barang yang akan dihapus pada tabel kemudian mengeksekusi perintah Hapus -- Konfirmasi data barang berhasil dihapus pada database √
8 Memasukkan Data Bidder
Memasukkan no. ktp, no. ponsel, nama lengkap dan alamat kemudian
mengeksekusi perintah Tambah
no. ktp, no. ponsel, nama lengkap dan alamat Konfirmasi data bidder berhasil tersimpan pada database √
9 Mengubah Data Bidder
Mengubah no. ktp, no. ponsel, nama lengkap dan alamat kemudian
mengeksekusi perintah Ubah
no. ktp, no. ponsel, nama lengkap dan alamat Konfirmasi data bidder berhasil diubah pada database √
10 Menghapus Data Bidder
Memilih bidder yang akan dihapus pada tabel kemudian mengeksekusi perintah Hapus -- Konfirmasi data bidder berhasil dihapus pada database √
11 Mengaktifkan Lelang
Memilih barang yang akan dilelang --
Konfirmasi status barang berhasil diubah
√
12 Mengirim Penawaran
Memasukkan PIN, kode barang dan jumlah penawaran PIN, kode barang dan jumlah penawaran Informasi penawaran berhasil diterima √ 13 Meminta Informasi Lelang Aktif
Memilih menu Info lelang Aktif --
Informasi lelang aktif diterima √ 14 Meminta Informasi Penawaran Terakhir
Memilih menu Info Penawaran Terakhir --
Informasi penawaran terakhir diterima √ 15 Meminta Informasi Pemenang
Memilih menu Info
Pemenang --
Informasi pemenang diterima √ 16 Meminta Informasi Pelelangan Berikutnya
Memilih menu Info Lelang Berikutnya --
Informasi lelang berikutnya diterima
(3)
134 Tabel 4.1 Tabel Hasil Uji Aplikasi (lanjutan)
17 Mencetak Laporan
Memilih laporan
yang akan dicetak --
Laporan yang dipilih tercetak
√
Keterangan:
√ benar/berhasil
(4)
BAB 5
KESIMPULAN DAN SARAN
5.1 Kesimpulan
Setelah melakukan studi literatur, analisis dan perancangan, pengkodean, implementasi, dan pengujian Aplikasi Pelelangan Barang Berbasis SMS, maka dapat disimpulkan:
1. Proses pendaftaran peserta tetap dilakukan secara manual.
2. Ponsel Siemens C55 dapat digunakan sebagai ponsel penerima pada server lelang. 3. Dengan aplikasi MIDlet yang dibangun, bidder tidak perlu menghafal keyword
yang diperlukan untuk mengajukan penawaran barang dan permintaan informasi lelang.
4. Pada saat pengiriman pesan dari komputer server ke ponsel diperlukan User Data Header pada User Data yang berisi informasi port. Port ini digunakan agar pesan yang dikirim ke ponsel diterima pada aplikasi MIDlet.
5.2 Saran
Beberapa saran untuk pengembangan dan perbaikan diantaranya:
1. Mengembangkan proses pendaftaran lelang yang masih dilakukan secara manual. 2. Melakukan penelitian terhadap jenis ponsel lain yang dapat digunakan sebagai
ponsel penerima pada server.
(5)
DAFTAR PUSTAKA
Agarwal, R dan Sinha, A, P. 2003. Object Oriented Modeling with UML: A Study of Developer’s Perceptions. New York: ACM.
Fowler, M. 2004. UML Distilled. Edisi ke-3. Terjemahan Tim Penerjemah Penerbit Andi. Yogyakarta: Andi.
Kendall, K.E dan Kendall, J. E. 2003. Analisis dan Perancangan Sistem. Edisi ke-5. Terjemahan Thamir Abdul Hafedh. Jakarta: PT Index Kelompok Gramedia. Pettersson, L. 2005. 10 Mei 2010. SMS and The PDU Format.
Putro, B. L. 2009. Aplikasi Message Center: Modul Antar Muka antara Handphone dengan Komputer. Seminar Nasional Aplikasi Teknologi Informasi 2009. Yogyakarta: Universitas Sangga Buana.
Raharjo, B., Heryanto, I. dan Haryono, A. 2007. Tuntunan Pemrograman Java untuk Handphone. Bandung: Informatika.
Septyani, H. I. 2007. Analisis Teori Permainan dan Ekuilibrium Nash Pada Simulasi Lelang (Auction) Pasar Listrik. Bandung: Institut Teknologi Bandung.
Suhendar, A dan Gunadi, H. 2002. Visual Modeling Menggunakan UML dan Rational Rose. Bandung: Informatika.
Tim Penelitian dan Pengembangan Wahana Komputer. 2005. Pengembangan Aplikasi Sistem Informasi Akademik Berbasis SMS dengan Java. Jakarta: Salemba Infotek.
(6)
Whitten, J. L., Bentley, L. D., dan Dittman, K. C. 2004. Metode Desain dan Analisis Sistem. Terjemahan Tim Penerjemah Andi. Yogyakarta: Andi.
Wicaksono, M. T. 2007. Pemrograman SMS Interaktif Berbasis Java. Jakarta: Elex Media Komputindo.