94
3.7 Class Diagram Desain Sistem
Gambar 3.34 Class Diagram Desain Sistem
3.8 Sequence Diagram
Pada sub bab ini akan dijelaskan masing – masing use case dengan menggambarkan sequence diagram beserta hubungan antar kelas yang berperan di dalamnya.
Universitas Sumatera Utara
95
3.8.1 Use case Mengajukan Penawaran
Pada use case ini, terdapat dua kelas yang berperan di dalamnya, yakni ApplBidder dan SendToServer. ApplBidder berperan sebagai kelas boundary, SendToServer
sebagai kelas control. Pada gambar di bawah ini dapat dilihat hubungan antara kelas tersebut:
Gambar 3.35 Class Diagram untuk Use Case Mengajukan Penawaran
Proses Mengajukan Penawaran dimulai dengan menjalankan aplikasi MIDlet pada ponsel, kemudian sistem menampilkan menu dengan konstruktor ApplBidder.
Selanjutnya bidder memilih menu Mengajukan Penawaran dan memasukkan PIN, kode barang serta jumlah penawaran, lalu mengeksekusi perintah Kirim. Pada saat
perintah Kirim dieksekusi, sistem memanggil method send. Method ini akan menjalankan
method sendSMS
pada kelas SendToServer dan
method storeLogPenawaran. Alur proses Mengajukan Penawaran dapat dilihat pada
sequence diagram berikut:
Gambar 3.36 Sequence Diagram untuk Use Case Mengajukan Penawaran
Universitas Sumatera Utara
96
3.8.2 Use case Meminta Informasi Lelang
Pada use case ini, terdapat dua kelas yang berperan di dalamnya, yakni ApplBidder dan SendToServer. ApplBidder berperan sebagai kelas boundary, SendToServer
sebagai kelas control. Pada gambar di bawah ini dapat dilihat hubungan antara kelas tersebut:
Gambar 3.37 Class Diagram untuk Use Case Meminta Informasi Lelang
Proses Meminta Informasi Lelang dimulai dengan menjalankan aplikasi MIDlet pada ponsel, kemudian sistem menampilkan menu dengan konstruktor
ApplBidder. Selanjutnya bidder memilih menu Informasi Lelang dan memilih submenu informasi yang ingin diketahui, lalu mengeksekusi perintah Kirim. Pada saat
perintah Kirim dieksekusi, sistem memanggil method send. Method ini akan menjalankan method sendSMS pada kelas SendToServer. Alur proses Meminta
Informasi Lelang dapat dilihat pada sequence diagram berikut:
Gambar 3.38 Sequence Diagram untuk Use Case Meminta Informasi Lelang 3.8.3 Use case Login
Pada use case login, terdapat beberapa kelas yang berperan di dalamnya, yakni kelas MenuUtama, LoginForm, User dan Database. MenuUtama berperan sebagai kelas
Universitas Sumatera Utara
97 boundary, LoginForm dan serta User sebagai kelas control serta Database sebagai
kelas entity. Pada gambar di bawah ini dapat dilihat hubungan kelas – kelas tersebut:
Gambar 3.39 Class Diagram untuk Use Case Login
Proses login dimulai dengan menjalankan aplikasi, kemudian sistem menampilkan LoginForm dengan konstruktor LoginForm. Selanjutnya user yang
telah terdaftar sebagai operator atau admin memasukkan username dan password dan mengeksekusi btnLogin. Pada saat btnLogin dieksekusi, sistem memanggil method
isValidUser yang akan melakukan query ke database untuk melakukan validasi user. Jika user valid, sistem akan menampilkan menu utama dengan konstruktor
MenuUtama, jika tidak sistem akan kembali menampilkan form login dengan konstruktor LoginForm. Alur proses login dapat dilihat pada sequence diagram
berikut:
Gambar 3.40 Sequence Diagram untuk Use Case Login
Universitas Sumatera Utara
98
3.8.4 Use case Mengelola Data Bidder
Pada use case ini, terdapat beberapa tiga kelas yang berperan di dalamnya, yakni kelas ManBidder, Bidder, dan Database. ManBidder berperan sebagai kelas boundary,
Bidder sebagai kelas control serta Database sebagai kelas entity. Pada gambar di bawah ini dapat dilihat hubungan antara kelas tersebut:
Gambar 3.41 Class Diagram untuk Use Case Mengelola Data Bidder
Proses Mengelola Data Bidder dimulai dengan memilih menu Manajemen Bidder pada Aplikasi Manajemen Lelang dengan konstruktor ManBidder.
Konstruktor ini akan memanggil method showTable yang akan menjalankan getDetails pada kelas Bidder dan akan mengambil data dari database dengan
menjalankan method getResult. Selanjutnya operator memilih akan menambah, mengubah atau menghapus data bidder dengan mengeksekusi btnTambah,
btnUbah atau btnHapus. Pada saat btnTambah dieksekusi, sistem menjalankan method tambahBidder pada kelas Bidder, kemudian melakukan query dengan
menjalankan exec pada kelas Database. Pada saat btnUbah dieksekusi, sistem memanggil menjalankan method ubahBidder pada kelas Bidder, kemudian
menjalankan exec pada kelas Database. Begitu juga pada saat btnHapus dieksekusi, sistem memanggil menjalankan method hapusBidder pada kelas Bidder,
kemudian menjalankan exec pada kelas Database. Alur proses Mengelola Data Bidder dapat dilihat pada sequence diagram berikut:
Universitas Sumatera Utara
99
Gambar 3.42 Sequence Diagram untuk Use Case Mengelola Data Bidder 3.8.5 Use case Mengelola Data Barang
Pada use case ini, terdapat beberapa tiga kelas yang berperan di dalamnya, yakni kelas ManBarang, Barang, dan Database. ManBarang berperan sebagai kelas boundary,
Barang sebagai kelas control serta Database sebagai kelas entity. Pada gambar di bawah ini dapat dilihat hubungan antara kelas tersebut:
Gambar 3.43 Class Diagram untuk Use Case Mengelola Data Barang
Universitas Sumatera Utara
100 Proses Mengelola Data Barang dimulai dengan memilih menu Manajemen
Barang pada Aplikasi Manajemen Lelang dengan konstruktor ManBarang. Konstruktor ini akan memanggil method showTable yang akan menjalankan
getDetails pada kelas Barang dan akan mengambil data dari database dengan menjalankan method getResult. Selanjutnya operator memilih akan menambah,
mengubah atau menghapus data barang dengan mengeksekusi btnTambah, btnUbah atau btnHapus. Pada saat btnTambah dieksekusi, sistem menjalankan
method tambahBarang pada kelas Barang, kemudian melakukan query dengan menjalankan exec pada kelas Database. Pada saat btnUbah dieksekusi, sistem
memanggil menjalankan method ubahBarang pada kelas Barang, kemudian menjalankan exec pada kelas Database. Begitu juga pada saat btnHapus
dieksekusi, sistem memanggil menjalankan method hapusBarang pada kelas Barang, kemudian menjalankan exec pada kelas Database. Alur proses Mengelola Data
Barang dapat dilihat pada sequence diagram berikut:
Gambar 3.44 Sequence Diagram untuk Use Case Mengelola Data Barang
Universitas Sumatera Utara
101
3.8.6 Use case Mengirim Informasi
Pada use case ini, terdapat beberapa kelas yang berperan di dalamnya, yakni kelas FormPesan, Bidder, Outbox dan Database. FormPesan berperan sebagai kelas
boundary, Bidder dan Outbox sebagai kelas control serta Database sebagai kelas entity. Pada gambar di bawah ini dapat dilihat hubungan antara kelas tersebut:
Gambar 3.45 Class Diagram untuk Use Case Mengirim Informasi
Proses Mengirim Informasi dimulai dengan memilih menu Kirim Pesan pada Aplikasi Manajemen Lelang dengan konstruktor FormPesan. Konstruktor ini akan
memanggil method showTable yang akan menjalankan getDetails pada kelas Bidder dan akan mengambil data dari database dengan menjalankan method
getResult. Selanjutnya operator mengeksekusi btnKirim. Pada saat btnKirim dieksekusi, sistem menjalankan insertOutbox pada kelas Outbox, kemudian
melakukan query ke database dengan method exec. Alur proses Proses Mengirim Informasi dapat dilihat pada sequence diagram berikut:
Universitas Sumatera Utara
102
Gambar 3.46 Sequence Diagram untuk Use Case Mengirim Informasi
3.8.7 Use case Mencetak Laporan
Pada use case ini, terdapat beberapa tiga kelas yang berperan di dalamnya, yakni kelas MenuUtama, ViewReport, dan Database. MenuUtama berperan sebagai kelas
boundary, ViewPort sebagai kelas control serta Database sebagai kelas entity. Pada gambar di bawah ini dapat dilihat hubungan antara kelas tersebut:
Gambar 3.47 Class untuk Use Case Mencetak Laporan
Proses Mencetak Laporan dimulai saat sistem menampilkan menu utama dengan konstruktor MenuUtama. Selanjutnya operator memilih akan mencetak
laporan peserta, barang atau lelang dengan mengeksekusi btnLaporan. Pada saat perintah laporan tersebut dieksekusi, konstruktor ViewReport akan dijalankan, lalu
konstruktor ini akan menjalankan method getDetails pada kelas Database yang akan
Universitas Sumatera Utara
103 menampilkan laporan sesuai dengan menu laporan yang dipilih. Alur proses Mencetak
Laporan dapat dilihat pada sequence diagram berikut:
Gambar 3.48 Sequence Diagram untuk Use Case Mencetak Laporan
3.8.8 Use case Menjalankan Server Lelang
Pada use case ini, terdapat beberapa kelas yang berperan di dalamnya, yakni kelas MainServer, ServerLelang, Database, ThreadGetInbox, ThreadGetOutbox, dan
ThreadGetPemenang. MainServer berperan sebagai kelas boundary, ServerLelang, ThreadGetInbox, ThreadGetOutbox dan ThreadGetPemenang sebagai kelas control
serta Database sebagai kelas entity. Pada gambar di bawah ini dapat dilihat hubungan kelas – kelas tersebut:
Gambar 3.49 Class Diagram untuk Use Case Menjalankan Server Lelang
Universitas Sumatera Utara
104 Proses Menjalankan Server Lelang dimulai dengan menjalankan Aplikasi
Server Lelang, kemudian sistem menampilkan form utama dengan konstruktor MainServer. Selanjutnya Admin mengeksekusi btnStart dengan dimana sistem
akan meminta verifikasi user yang terdaftar sebagai admin. Selanjutnya user memasukkan username dan password dan mengeksekusi perintah Ok. Pada saat
perintah Ok dieksekusi, sistem melakukan koneksi dengan database dan menjalankan ThreadGetInbox,
ThreadGetOutbox dan
ThreadSetPemenang. Alur proses Menjalankan Server Lelang dapat dilihat pada sequence diagram berikut:
Gambar 3.50 Sequence Diagram untuk Use Case Menjalankan Server Lelang 3.8.9 Use case Menonaktifkan Server Lelang
Pada use case ini, terdapat beberapa dua kelas yang berperan di dalamnya, yakni kelas MainServer dan Database. MainServer berperan sebagai kelas boundary dan
Database sebagai kelas entity. Pada gambar di bawah ini dapat dilihat hubungan antara kelas tersebut:
Universitas Sumatera Utara
105
Gambar 3.51 Class Diagram untuk Use Case Menonaktifkan Server Lelang
Proses Menonaktifkan Server Lelang dimulai ketika MainServer sudah berjalan dengan konstruktor MainServer. Selanjutnya admin mengeksekusi
btnStop. Pada saat perintah tersebut dieksekusi, sistem memanggil method stop. Method ini akan menjalankan method closeConn pada kelas Database dan exit
pada kelas MainServer. Alur proses login dapat dilihat pada sequence diagram berikut:
Gambar 3.52 Sequence Diagram untuk Use Case Menonaktifkan Server Lelang
3.8.10 Use case Mengelola Data User
User dalam Aplikasi Manajemen Lelang adalah operator dan admin. Operator memiliki hak akses pada tugas – tugas tertentu yang telah dijelaskan pada use case
diagram analisis sistem. Admin memiliki hak akses penuh terhadap aplikasi. Pada use case ini, terdapat beberapa tiga kelas yang berperan di dalamnya,
yakni kelas ManUser, User, dan Database. ManUser berperan sebagai kelas
Universitas Sumatera Utara
106 boundary, User sebagai kelas control serta Database sebagai kelas entity. Pada
gambar di bawah ini dapat dilihat hubungan antara kelas tersebut:
Gambar 3.53 Class Diagram untuk Use Case Mengelola Data User
Proses Mengelola Data User dimulai dengan memilih menu Manajemen User pada Aplikasi Manajemen Lelang dengan konstruktor ManUser. Konstruktor ini
akan memanggil method showTable yang akan menjalankan getDetails pada kelas User dan akan mengambil data dari database dengan menjalankan method getResult.
Selanjutnya admin memilih akan menambah, mengubah atau menghapus data user dengan mengeksekusi btnTambah, btnUbah atau btnHapus. Pada saat
btnTambah dieksekusi, sistem menjalankan method tambahUser pada kelas User, kemudian melakukan query dengan menjalankan exec pada kelas Database. Pada
saat btnUbah dieksekusi, sistem memanggil menjalankan method ubahUser pada kelas User, kemudian menjalankan exec pada kelas Database. Begitu juga pada saat
btnHapus dieksekusi, sistem memanggil menjalankan method hapusUser pada kelas User, kemudian menjalankan exec pada kelas Database. Alur proses
Mengelola Data User dapat dilihat pada sequence diagram berikut:
Universitas Sumatera Utara
107
Gambar 3.54 Sequence Diagram untuk Use Case Mengelola Data User
3.8.11 Use case Manajemen Lelang
Pada use case ini, terdapat tiga kelas yang berperan di dalamnya, yakni kelas ManLelang, Barang, dan Database. ManLelang berperan sebagai kelas boundary,
Barang sebagai kelas control serta Database sebagai kelas entity. Pada gambar di bawah ini dapat dilihat hubungan antara kelas tersebut:
Gambar 3.55 Class Diagram untuk Use Case Manajemen Lelang
Universitas Sumatera Utara
108 Proses Manajemen Lelang dimulai dengan memilih menu Manajemen Lelang
pada Aplikasi Manajemen Lelang dengan konstruktor ManLelang. Konstruktor ini akan memanggil method showTable yang akan menjalankan getDetails pada kelas
Barang dan akan mengambil data dari database dengan menjalankan method getResult. Selanjutnya admin memilih akan mengaktifkan atau menonaktifkan
barang yang dilelang dengan mengeksekusi btnAktif atau btnNonAktif. Pada saat btnAktif dieksekusi, sistem menjalankan aktifkanLelang pada kelas Barang,
kemudian menjalankan exec pada kelas Database. Begitu juga pada saat btnNonAktif dieksekusi, sistem memanggil method nonAktifkanLelang, lalu
kemudian menjalankan exec pada kelas Database. Alur proses Proses Manajemen Lelang dapat dilihat pada sequence diagram berikut:
Gambar 3.56 Sequence Diagram untuk Use Case Manajemen Lelang
Universitas Sumatera Utara
109
3.8.12 Use case Menerima Pesan
Pada use case ini, terdapat beberapa kelas yang berperan di dalamnya, yakni kelas ServerLelang, Inbox, Outbox, ThreadGetOutbox dan Database. ServerLelang, Inbox,
Outbox dan ThreadGetOutbox berperan sebagai kelas control serta Database sebagai kelas entity. Pada gambar di bawah ini dapat dilihat hubungan kelas – kelas tersebut:
Gambar 3.57 Class Diagram untuk Use Case Menerima Pesan
Proses Menerima Pesan dimulai dengan berjalannya ThreadGetInbox dengan method run. Ketika ada serial event pada ServerLelang, maka sistem akan
menjalankan getAt dan method ini akan memanggil getSMS. Selanjutnya SMS yang sudah diterima akan disimpan pada database dengan menjalankan method
insertInbox yang kemudian melakukan query ke database dengan method exec. ThreadGetInbox yang sedang berjalan akan memeriksa record pada tabel
inbox yang belum diproses dengan method getInbox pada kelas Inbox. Selanjutnya pesan yang diambil dari tabel akan diproses dengan menjalankan method
prosesPesan. Kemudian berdasarkan string yang diterima, sistem menentukan pesan balasan yang sesuai . Pesan balasan tersebut lalu disimpan pada tabel outbox dengan
menjalankan method insertOutbox pada kelas Outbox. Method tersebut akan melakukan query ke database. Alur proses Menerima Pesan dapat dilihat pada
sequence diagram berikut:
Universitas Sumatera Utara
110
Gambar 3.58 Sequence Diagram untuk Use Case Menerima Pesan 3.8.13 Use case Membalas Pesan
Pada use case ini, terdapat beberapa kelas yang berperan di dalamnya, yakni kelas ServerLelang, Outbox, ThreadGetOutbox dan Database. ServerLelang, Ouitbox dan
ThreadGetOutbox berperan sebagai kelas control serta Database sebagai kelas entity. Pada gambar di bawah ini dapat dilihat hubungan kelas – kelas tersebut:
Gambar 3.59 Class Diagram untuk Use Case Membalas Pesan
Universitas Sumatera Utara
111 Proses Menerima Pesan dimulai dengan berjalannya ThreadGetOutbox
dengan method run. Method ini akan selalu memanggil getOutbox dan melakukan query ke database dengan method getResult untuk memeriksa apakah ada record
yang belum diproses. Jika ada, method sendSMS akan dijalankan dan mengirimkan pesan balasan dengan sendAT. Alur proses Menerima Pesan dapat dilihat pada
sequence diagram berikut:
Gambar 3.60 Sequence Diagram untuk Use Case Membalas Pesan 3.8.14 Use case Menentukan Pemenang Lelang
Pada use case ini, terdapat beberapa kelas yang berperan di dalamnya, yakni kelas ThreadSetPemenang, MainServer, Pemenang dan Database. ThreadSetPemenang dan
Pemenang berperan sebagai kelas boundary, MainServer sebagai kelas control serta Database sebagai kelas entity. Pada gambar di bawah ini dapat dilihat hubungan kelas
– kelas tersebut:
Gambar 3.61 Class Diagram untuk Use Case Menentukan Pemenang Lelang
Universitas Sumatera Utara
112 Proses Menentukan Pemenang Lelang dimulai dengan berjalannya
ThreadSetPemenang dengan method run. Method ini akan selalu memanggil getWaktu untuk mengetahui waktu sekarang current time. Sebelumnya method
getWaktuSelesai dijalankan untuk mengetahui waktu selesai lelang. Jika waktu pada database sudah sama dengan waktu sekarang, method setPemenang akan dipanggil
untuk melakukan query ke database. Alur proses Menerima Pesan dapat dilihat pada sequence diagram berikut:
Gambar 3.62 Sequence Diagram untuk Use Case Menentukan Pemenang Lelang 3.9 Deployment Diagram
Desain arsitektur sistem dapat digambarkan dalam suatu deployment diagram sebagai berikut:
Gambar 3.63 Deployment Diagram Arsitektur Sistem
Universitas Sumatera Utara
113
3.10 Desain Database