29 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.2 Analisis 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.
Universitas Sumatera Utara
30
3.2.1 Analisis 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.2 Analisis 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
2. Informasi penawaran terakhir
Universitas Sumatera Utara
31 3.
Informasi pemenang lelang 4.
Informasi pelelangan berikutnya
3.2.3 Analisis 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.3 Use Case Diagram Analisis Sistem
Setelah dilakukan analisis terhadap kebutuhan, fungsionalitas, inputoutput 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
Universitas Sumatera Utara
32 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:
Gambar 3.2 Use Case Diagram Analisis Sistem
Universitas Sumatera Utara
33
Gambar 3.2 Use Case Diagram Analisis Sistem lanjutan
3.3.1 Use 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: --
Universitas Sumatera Utara
34
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:
Universitas Sumatera Utara
35
Gambar 3.3 Activity Diagram untuk Use Case Mengajukan Penawaran
3.3.2 Use 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:
--
Universitas Sumatera Utara
36
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:
Universitas Sumatera Utara
37
Gambar 3.4 Activity Diagram untuk Use Case Meminta Informasi Barang
3.3.3 Use 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
Universitas Sumatera Utara
38
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: --
Masalah terbuka: --
Universitas Sumatera Utara
39 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.4 Use case Meminta Informasi Pemenang
Use case Meminta Informasi Pemenang dapat dijelaskan pada tabel dokumentasi naratif berikut ini:
Universitas Sumatera Utara
40
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: --
Masalah terbuka: --
Universitas Sumatera Utara
41
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.5 Use 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
Universitas Sumatera Utara
42
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: --
Masalah terbuka: --
Universitas Sumatera Utara
43 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.6 Use 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
Universitas Sumatera Utara
44
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:
Universitas Sumatera Utara
45
Gambar 3.8 Activity Diagram untuk Use Case Login
3.3.7 Use 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: Operator
Universitas Sumatera Utara
46
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: --
Masalah terbuka: --
Universitas Sumatera Utara
47 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.8 Use 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: --
Universitas Sumatera Utara
48
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: --
Masalah terbuka: --
Universitas Sumatera Utara
49 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.9 Use 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: --
Deskripsi: Use case ini mendeskripsikan proses mengubah data bidder
Universitas Sumatera Utara
50
Tabel 3.9 Dokumentasi Naratif Mengubah Data Bidder lanjutan
Prakondisi: Sudah ada data bidder dan data tersebut ditampilkan pada tabel.
Pemicu: Use case ini diinisialisasi saat operator memilih untuk mengubah data
bidder. Bidang khas suatu
event: Kegiatan Pelaku
Langkah 1: Memilih menu manajemen bidder.
Langkah 3: Memilih data bidder yang akan diubah pada tabel.
Langkah 4: Mengganti data bidder yang telah dipilih.
Langkah 5: Mengeksekusi perintah ubah.
Respons Sistem Langkah 2: Menampilkan form
manajemen bidder.
Langkah 6: Memeriksa apakah data sudah lengkap.
Langkah 7: Menyimpan data bidder pada basis data.
Bidang Alternatif: Alt-6: Jika data yang diubah belum lengkap maka sistem akan menampilkan
informasi agar data dilengkapi. Kesimpulan:
Use case ini merupakan rincian pengubahan data bidder. Postkondisi:
Data bidder yang telah diubah tersimpan pada basis data sistem pelelangan. Aturan Bisnis:
-- Batasan dan
Spesifikasi Implementasi:
Data bidder hanya dapat diubah satu per satu baris record.
Asumsi: --
Masalah terbuka: --
Alur kerja workflow pada use case Mengubah Data Bidder dapat digambarkan dalam activity diagram berikut:
Universitas Sumatera Utara
51
Gambar 3.11 Activity Diagram untuk Use Case Mengubah Data Bidder 3.3.10 Use Case Mengubah Data Barang
Use case Mengubah Data Barang dijelaskan pada tabel dokumentasi naratif berikut:
Tabel 3.10 Dokumentasi Naratif Mengubah Data Barang
Nama Use Case: Mengubah data barang
ID Use Case: --
Prioritas: Sedang
Sumber: Persyaratan
Pelaku Bisnis Utama: Operator
Pelaku Sistem Utama: Operator
Pelaku Partisipan Lain:
-- Stakeholder yang
Berminat Lain: --
Deskripsi: Use case ini mendeskripsikan proses mengubah data barang
Prakondisi: Sudah ada data barang dan data tersebut ditampilkan pada table.
Universitas Sumatera Utara
52
Tabel 3.10 Dokumentasi Naratif Mengubah Data Barang lanjutan
Pemicu: Use case ini diinisialisasi saat operator memilih untuk mengubah data
barang. Bidang khas suatu
event: Kegiatan Pelaku
Langkah 1: Memilih menu manajemen barang.
Langkah 3: Memilih data barang yang akan diubah pada tabel.
Langkah 4: Mengganti data barang yang telah dipilih.
Langkah 5: Mengeksekusi perintah ubah.
Respons Sistem Langkah 2: Menampilkan form
manajemen barang.
Langkah 6: Memeriksa apakah data sudah lengkap.
Langkah 7: Menyimpan data barang pada basis data.
Bidang Alternatif: Alt-6: Jika data yang diubah belum lengkap maka sistem akan menampilkan
informasi agar data dilengkapi. Kesimpulan:
Use case ini merupakan rincian pengubahan data barang. Postkondisi:
Data barang yang telah diubah tersimpan pada basis data sistem pelelangan. Aturan Bisnis:
-- Batasan dan
Spesifikasi Implementasi:
Data barang hanya dapat diubah satu per satu baris record.
Asumsi: --
Masalah terbuka: --
Alur kerja workflow pada use case Mengubah Data Barang dapat digambarkan dalam activity diagram berikut:
Universitas Sumatera Utara
53
Gambar 3.12 Activity Diagram untuk Use Case Mengubah Data Barang
3.3.11 Use Case Menghapus Data Bidder
Use case Menghapus Data Bidder dijelaskan pada tabel dokumentasi naratif berikut:
Tabel 3.11 Dokumentasi Naratif Menghapus Data Bidder
Nama Use Case: Menghapus data bidder
ID Use Case: Prioritas:
Sedang Sumber:
Persyaratan Pelaku Bisnis Utama:
Operator Pelaku Sistem Utama:
Operator Pelaku Partisipan Lain: --
Stakeholder yang Berminat Lain:
-- Deskripsi:
Use case ini mendeskripsikan proses menghapus data bidder. Prakondisi:
Sudah ada data bidder dan data tersebut ditampilkan pada tabel.
Universitas Sumatera Utara
54
Tabel 3.11 Dokumentasi Naratif Menghapus Data Bidder lanjutan
Pemicu: Use case ini diinisialisasi saat operator menyeleksi pilihan untuk menghapus
data bidder Bidang khas suatu
event: Kegiatan Pelaku
Langkah 1: Memilih menu manajemen bidder.
Langkah 3: Memilih data bidder yang akan dihapus.
Langkah 4: Mengeksekusi perintah delete.
Respons Sistem Langkah 2: Menampilkan form
manajemen bidder.
Langkah 5: Menampilkan pesan konfirmasi penghapusan data
bidder. Langkah 6: Menghapus data bidder
tersebut dari basis data. Langkah 7: Menampilkan data
bidder setelah dihapus. Bidang Alternatif:
Alt-5: Operator tidak jadi untuk menghapus data bidder. Kesimpulan:
Use case ini merupakan rincian penghapusan data bidder . Postkondisi:
Data terhapus dari basis data dan sistem menampilkan data bidder setelah dihapus.
Aturan Bisnis: --
Batasan dan Spesifikasi
Implementasi: --
Asumsi: --
Masalah terbuka: --
Alur kerja workflow pada use case Menghapus Data Bidder dapat digambarkan dalam activity diagram berikut:
Universitas Sumatera Utara
55
Gambar 3.13 Activity Diagram untuk Use Case Menghapus Data Bidder
3.3.12 Use Case Menghapus Data Barang
Use case Menghapus Data Barang dijelaskan pada tabel dokumentasi naratif berikut:
Tabel 3.12 Dokumentasi Naratif Menghapus Data Barang
Nama Use Case: Menghapus data barang
ID Use Case: Prioritas:
Sedang Sumber:
Persyaratan Pelaku Bisnis Utama:
Operator Pelaku Sistem Utama:
Operator Pelaku Partisipan Lain: --
Stakeholder yang Berminat Lain:
--
Universitas Sumatera Utara
56
Tabel 3.12 Dokumentasi Naratif Menghapus Data Barang lanjutan
Deskripsi: Use case ini mendeskripsikan proses menghapus data barang.
Prakondisi: Sudah ada data barang dan data tersebut ditampilkan pada tabel.
Pemicu: Use case ini diinisialisasi saat operator menyeleksi pilihan untuk menghapus
data barang Bidang khas suatu
event: Kegiatan Pelaku
Langkah 1: Memilih menu manajemen barang.
Langkah 3: Memilih data barang yang akan dihapus.
Langkah 4: Mengeksekusi perintah delete.
Respons Sistem Langkah 2: Menampilkan form
manajemen barang.
Langkah 5: Menampilkan pesan konfirmasi penghapusan data
barang. Langkah 6: Menghapus data
tersebut dari basis data. Langkah 7: Menampilkan data
barang setelah dihapus. Bidang Alternatif:
Alt-5: Operator tidak jadi untuk menghapus data barang. Kesimpulan:
Use case ini merupakan rincian penghapusan data barang. Postkondisi:
Data terhapus dari basis data dan sistem menampilkan data barang setelah dihapus.
Aturan Bisnis: --
Batasan dan Spesifikasi
Implementasi: --
Asumsi: --
Masalah terbuka: --
Alur kerja workflow pada use case Menghapus Data Barang dapat digambarkan dalam activity diagram berikut:
Universitas Sumatera Utara
57
Gambar 3.14 Activity Diagram untuk Use Case Menghapus Data Barang
3.3.13 Use Case Mengirim Informasi
Use case Mengirim Informasi dijelaskan pada tabel dokumentasi naratif berikut:
Tabel 3.13 Dokumentasi Naratif Mengirim Informasi
Nama Use Case: Mengirim Informasi
ID Use Case: Prioritas:
Sedang Sumber:
Persyaratan Pelaku Bisnis Utama:
Operator Pelaku Sistem Utama:
Operator Pelaku Partisipan Lain: --
Stakeholder yang Berminat Lain:
--
Universitas Sumatera Utara
58
Tabel 3.13 Dokumentasi Naratif Mengirim Informasi lanjutan
Deskripsi: Use case ini mendeskripsikan proses mengirim informasi kepada perserta
lelang. Prakondisi:
Operator memilih tujuan pengiriman informasi, kepada beberapa atau semua bidder yang terdaftar.
Pemicu: Use case ini diinisialisasi saat operator menyeleksi pilihan untuk mengirim
informasi Bidang khas suatu
event: Kegiatan Pelaku
Langkah 1: Memilih menu mengirim informasi
Langkah 3: Memilih tujuan pengiriman informasi
Langkah 4: Mengeksekusi perintah Kirim
Respons Sistem Langkah 2: Menampilkan form
pengiriman informasi
Langkah 5: Menampilkan pesan konfirmasi pengiriman informasi
Langkah 6: Mengirim informasi ke tujuan
Bidang Alternatif: Alt-5: Operator membatalkan untuk mengirim informasi
Kesimpulan: Use case ini merupakan rincian pengiriman informasi kepada peserta lelang
Postkondisi: Informasi dikirim dan bidder menerima informasi tersebut pada ponsel
Aturan Bisnis: --
Batasan dan Spesifikasi
Implementasi: --
Asumsi: --
Masalah terbuka: --
Alur kerja workflow pada use case Mengirim Informasi dapat digambarkan dalam activity diagram berikut:
Universitas Sumatera Utara
59
Gambar 3.15 Activity Diagram untuk Use Case Mengirim Informasi
3.3.14 Use Case Mencetak Laporan
Use case Mencetak Laporan dijelaskan pada tabel dokumentasi naratif berikut:
Tabel 3.14 Dokumentasi Naratif Mencetak Laporan
Nama Use Case: Mencetak Laporan
ID Use Case: Prioritas:
Tinggi Sumber:
Persyaratan Pelaku Bisnis Utama:
Operator Pelaku Sistem Utama:
Operator Pelaku Partisipan Lain: --
Stakeholder yang Berminat Lain:
-- Deskripsi:
Use case ini mendeskripsikan proses mencetak laporan Prakondisi:
Operator memilih laporan yang akan dicetak
Universitas Sumatera Utara
60
Tabel 3.14 Dokumentasi Naratif Mencetak Laporan lanjutan
Pemicu: Use case ini diinisialisasi saat operator menyeleksi pilihan untuk mencetak
laporan Bidang khas suatu
event: Kegiatan Pelaku
Langkah 1: Memilih menu mencetak laporan
Langkah 2: Memilih laporan yang akan dicetak
Langkah 4: Mengeksekusi perintah cetak
Respons Sistem
Langkah 3: Menampilkan laporan yang dipilih
Langkah 5: Mencetak laporan tersebut
Bidang Alternatif: --
Kesimpulan: Use case ini merupakan rincian proses mencetak laporan lelang
Postkondisi: Laporan yang dipilih sudah dicetak
Aturan Bisnis: --
Batasan dan Spesifikasi
Implementasi: --
Asumsi: --
Masalah terbuka: --
Alur kerja workflow pada use case Mencetak Laporan dapat digambarkan dalam activity diagram berikut:
Universitas Sumatera Utara
61
Gambar 3.16 Activity Diagram untuk Use Case Mencetak Laporan
3.3.15 Use Case Menambah Data User
Use case menambah data user dijelaskan pada tabel dokumentasi naratif berikut:
Tabel 3.15 Dokumentasi Naratif Memasukkan Data User
Nama Use Case: Menambah data user
ID Use Case: --
Prioritas: Tinggi
Sumber: Persyaratan
Pelaku Bisnis Utama: Admin
Pelaku Sistem Utama: Admin
Pelaku Partisipan Lain:
-- Stakeholder yang
Berminat Lain: --
Deskripsi: Use case ini mendeskripsikan proses menambah dan menyimpan data user
Prakondisi: Sudah ada data user yang sama sebelumnya.
Universitas Sumatera Utara
62
Tabel 3.15 Dokumentasi Naratif Memasukkan Data User lanjutan
Pemicu: Use case ini diinisialisasi saat admin memilih pilihan untuk menambah data
user yang baru. Bidang khas suatu
event: Kegiatan Pelaku
Langkah 1: Memilih menu manajemen user.
Langkah 3: Memasukkan NIP, username dan alamat
Langkah 5: Mengeksekusi perintah tambah.
Respons Sistem Langkah 2: Menampilkan form
manajemen user. Langkah 4: Mengecek apakah nip
dan username sudah terdaftar atau belum.
Langkah 6: Mengecek apakah data yang diisi sudah lengkap .
Langkah 7: Menyimpan data user pada basis data.
Bidang Alternatif: Alt-Langkah 4: Jika NIP atau username sudah terdaftar, maka sistem akan
menonaktifkan button tambah user dan pelaku tidak dapat melanjutkan, proses menambah data user.
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 user baru yang akan dilelang.
Postkondisi: Data user tersimpan pada basis data sistem pelelangan
Aturan Bisnis: --
Batasan dan Spesifikasi
Implementasi: --
Asumsi: --
Masalah terbuka: --
Alur kerja workflow pada use case menambah data user dapat digambarkan dalam activity diagram berikut:
Universitas Sumatera Utara
63
Gambar 3.17 Activity Diagram untuk Use Case Menambah Data User
3.3.16 Use Case Mengubah Data User
Use case mengubah data user dijelaskan pada tabel dokumentasi naratif berikut:
Tabel 3.16 Dokumentasi Naratif Mengubah Data User
Nama Use Case: Mengubah data user
ID Use Case: --
Prioritas: Sedang
Sumber: Persyaratan
Pelaku Bisnis Utama: Admin
Pelaku Sistem Utama: Admin
Pelaku Partisipan Lain:
-- Stakeholder yang
Berminat Lain: --
Deskripsi: Use case ini mendeskripsikan proses mengubah data user.
Prakondisi: Sudah ada data user dan data tersebut ditampilkan pada tabel.
Pemicu: Use case ini diinisialisasi saat admin memilih untuk mengubah data user.
Universitas Sumatera Utara
64
Tabel 3.16 Dokumentasi Naratif Mengubah Data User lanjutan
Bidang khas suatu event:
Kegiatan Pelaku Langkah 1: Memilih menu manajemen
user. Langkah 3: Memilih data user yang
akan diubah pada tabel. Langkah 4: Mengganti data user yang
telah dipilih. Langkah 5: Mengeksekusi perintah
ubah. Respons Sistem
Langkah 2: Menampilkan form manajemen user.
Langkah 6: Memeriksa apakah data sudah lengkap.
Langkah 7: Menyimpan data user pada basis data.
Bidang Alternatif: Alt-6: Jika data yang diubah belum lengkap maka sistem akan menampilkan
informasi agar data dilengkapi. Kesimpulan:
Use case ini merupakan rincian pengubahan data user. Postkondisi:
Data user yang telah diubah tersimpan pada basis data sistem pelelangan. Aturan Bisnis:
-- Batasan dan
Spesifikasi Implementasi:
Data barang hanya dapat diubah satu per satu baris record. Asumsi:
-- Masalah terbuka:
--
Alur kerja workflow pada use case mengubah data user dapat digambarkan activity diagram berikut:
Universitas Sumatera Utara
65
Gambar 3.18 Activity Diagram untuk Use Case Mengubah Data User
3.3.17 Use Case Menghapus Data User
Use case menghapus data user dijelaskan pada tabel dokumentasi naratif berikut:
Tabel 3.17 Dokumentasi Naratif Menghapus Data User
Nama Use Case: Menghapus data user
ID Use Case: Prioritas:
Sedang Sumber:
Persyaratan Pelaku Bisnis Utama:
Admin Pelaku Sistem Utama:
Admin Pelaku Partisipan
Lain: --
Stakeholder yang Berminat Lain:
--
Universitas Sumatera Utara
66
Tabel 3.17 Dokumentasi Naratif Menghapus Data User lanjutan
Deskripsi: Use case ini mendeskripsikan proses menghapus data user.
Prakondisi: Sudah ada data user dan data tersebut ditampilkan pada tabel.
Pemicu: Use case ini diinisialisasi saat admin menyeleksi pilihan untuk menghapus
data user Bidang khas suatu
event: Kegiatan Pelaku
Langkah 1: Memilih menu manajemen user.
Langkah 3: Memilih data user yang akan dihapus.
Langkah 4: Mengeksekusi perintah delete.
Respons Sistem Langkah 2: Menampilkan form
manajemen user.
Langkah 5: Menampilkan pesan konfirmasi penghapusan data user.
Langkah 6: Menghapus data user tersebut dari basis data.
Langkah 7: Menampilkan data user setelah dihapus.
Bidang Alternatif: Alt-5: Operator tidak jadi untuk menghapus data user.
Kesimpulan: Use case ini merupakan rincian penghapusan data user.
Postkondisi: Data terhapus dari basis data dan sistem menampilkan data user setelah
dihapus. Aturan Bisnis:
-- Batasan dan
Spesifikasi Implementasi:
--
Asumsi: --
Masalah terbuka: --
Alur kerja workflow pada use case menghapus data user dapat digambarkan dalam activity diagram berikut:
Universitas Sumatera Utara
67
Gambar 3.19 Activity Diagram untuk Use Case Menghapus Data User
3.3.18 Use Case Manajemen Lelang
Use case Manajemen Lelang dijelaskan pada tabel dokumentasi naratif berikut:
Tabel 3.18 Dokumentasi Naratif Manajemen Lelang
Nama Use Case: Manajemen Lelang
ID Use Case: --
Prioritas: Tinggi
Sumber: Persyaratan
Pelaku Bisnis Utama: Admin
Pelaku Sistem Utama: Admin
Pelaku Partisipan Lain:
--
Universitas Sumatera Utara
68
Tabel 3.18 Dokumentasi Naratif Manajemen Lelang lanjutan
Stakeholder yang Berminat Lain:
-- Deskripsi:
Use case ini mendeskripsikan proses mengaktifkan dan menonaktifkan status barang yang dilelang
Prakondisi: Status barang dalam keadaan aktif atau nonaktif 0 atau 1
Pemicu: Use case ini diinisialisasi saat admin memilih pilihan untuk manajemen lelang
Bidang khas suatu event:
Kegiatan Pelaku Langkah 1: Memilih menu
manajemen lelang. Langkah 3: Memilih barang yang
akan diaktifkan atau dinonaktifkan Langkah 4: Mengeksekusi perintah
aktif atau nonaktif. Respons Sistem
Langkah 2: Menampilkan form manajemen lelang.
Langkah 5: Mengubah status barang menjadi aktif atau nonaktif
Bidang Alternatif: --
Kesimpulan: Use case ini merupakan proses mengubah status barang yang dilelang menjadi
aktif atau nonaktif yang artinya akan dilelang atau belum akan dilelang Postkondisi:
Status barang diubah pada basis data pelelangan Aturan Bisnis:
-- Batasan dan
Spesifikasi Implementasi:
--
Asumsi: --
Masalah terbuka: --
Alur kerja workflow pada use case Manajemen Lelang dapat digambarkan dalam activity diagram berikut:
Universitas Sumatera Utara
69
Gambar 3.20 Activity Diagram untuk Use Case Manajemen Lelang
3.3.19 Use Case Menerima Penawaran
Use case Menerima Penawaran dijelaskan pada tabel dokumentasi naratif berikut:
Tabel 3.19 Dokumentasi Naratif Menerima Penawaran
Nama Use Case: Menerima Penawaran
ID Use Case: --
Prioritas: Tinggi
Sumber: Persyaratan
Pelaku Bisnis Utama: Thread Sistem
Pelaku Sistem Utama: Thread Sistem
Pelaku Partisipan Lain:
-- Stakeholder yang
Berminat Lain: --
Deskripsi: Use case ini mendeskripsikan proses menerima penawaran yang dikirim bidder
Prakondisi: Thread Sistem selalu memeriksa tabel inbox pada database setiap detik
Universitas Sumatera Utara
70
Tabel 3.19 Dokumentasi Naratif Menerima Penawaran lanjutan
Pemicu: Use case ini dijalankan ketika ThreadGetInbox berjalan running
Bidang khas suatu event:
Kegiatan Pelaku Langkah 1: Memeriksa penawaran
yang masuk pada tabel inbox Langkah 2: Mengambil String
penawaran pada field pesan Langkah 3: Melakukan validasi
PIN, kode barang dan memeriksa jumlah penawaran
Langkah 4: Menyimpan penawaran pada tabel penawaran dan
informasi balasan pada tabel outbox Respons Sistem
Bidang Alternatif: Alt-1: Jika tidak ada penawaran yang masuk, Thread Sistem tetap selalu
memeriksa penawaran. Alt-3: Jika PIN tidak valid atau penawaran tidak sesuai, maka Thread Sistem
akan menyimpan pesan kesalahan pada tabel outbox Kesimpulan:
Use case ini merupakan proses menerima penawaran yang masuk, menyimpannya pada database dan memproses penawaran tersebut
Postkondisi: Informasi penawaran berhasil atau kesalahan tersimpan pada tabel outbox
Aturan Bisnis: Thread Sistem menerima penawaran dengan memeriksa penawaran yang
masuk pada tabel inbox. Record penawaran tersebut berasal dari serial event yang memeriksa jika ada pesan yang masuk pada server dengan String: PIN
spasi Kode Barang spasi Jumlah Penawaran. Batasan dan
Spesifikasi Implementasi:
--
Asumsi: --
Masalah terbuka: --
Alur kerja workflow pada use case Menerima Penawaran dapat digambarkan dalam activity diagram berikut:
Universitas Sumatera Utara
71
Gambar 3.21 Activity Diagram untuk Use Case Menerima Penawaran
3.3.20 Use Case Menerima Request Informasi
Use case Menerima Request Informasi dijelaskan pada tabel dokumentasi naratif berikut:
Tabel 3.20 Dokumentasi Naratif Menerima Request Informasi
Nama Use Case: Menerima Request Informasi
ID Use Case: --
Prioritas: Tinggi
Sumber: Persyaratan
Pelaku Bisnis Utama: Thread Sistem
Universitas Sumatera Utara
72
Tabel 3.20 Dokumentasi Naratif Menerima Request Informasi lanjutan
Pelaku Sistem Utama: Thread Sistem
Pelaku Partisipan Lain:
-- Stakeholder yang
Berminat Lain: --
Deskripsi: Use case ini mendeskripsikan proses menerima request informasi yang dikirim
bidder Prakondisi:
Thread Sistem selalu memeriksa tabel inbox pada database setiap detik Pemicu:
Use case ini dijalankan ketika ThreadGetInbox berjalan running Bidang khas suatu
event: Kegiatan Pelaku
Langkah 1: Memeriksa request informasi yang masuk pada tabel
inbox Langkah 2: Mengambil String
request informasi pada field pesan Langkah 3: Memproses String
tersebut Langkah 4: Menyimpan informasi
balasan pada tabel outbox Respons Sistem
Bidang Alternatif: Alt-1: Jika tidak ada penawaran yang masuk, Thread Sistem tetap selalu
memeriksa penawaran. Alt-3: Jika String yang masuk tidak sesuai maka pesan kesalahan akan
disimpan pada tabel outbox Kesimpulan:
Use case ini merupakan proses menerima request informasi yang masuk dan memproses request tersebut
Postkondisi: Informasi yang di- request atau informasi tersimpan pada tabel outbox
Aturan Bisnis: Thread Sistem menerima request informasi dengan memeriksa pesan yang
masuk pada tabel inbox. Record penawaran tersebut berasal dari serial event yang memeriksa jika ada pesan yang masuk pada server dengan String:
LELANG spasi AKTIF untuk memperoleh informasi barang yang dilelang; LELANG spasi AKHIR untuk memperoleh informasi penawaran terakhir;
LELANG spasi MENANG untuk memperoleh informasi pemenang; LELANG spasi NEXT untuk memperoleh informasi pelelangan berikutnya.
Universitas Sumatera Utara
73
Tabel 3.20 Dokumentasi Naratif Menerima Request Informasi lanjutan
Batasan dan Spesifikasi
Implementasi: --
Asumsi: --
Masalah terbuka: --
Alur kerja workflow pada use case Menerima Request Informasi dapat digambarkan dalam activity diagram berikut:
Gambar 3.22 Activity Diagram untuk Use Case Menerima Request Informasi
3.3.21 Use Case Membalas Penawaran
Use case Membalas Penawaran dijelaskan pada tabel dokumentasi naratif berikut:
Universitas Sumatera Utara
74
Tabel 3.21 Dokumentasi Naratif Membalas Penawaran
Nama Use Case: Membalas Penawaran
ID Use Case: --
Prioritas: Tinggi
Sumber: Persyaratan
Pelaku Bisnis Utama: Thread Sistem
Pelaku Sistem Utama: Thread Sistem
Pelaku Partisipan Lain:
-- Stakeholder yang
Berminat Lain: --
Deskripsi: Use case ini mendeskripsikan proses membalas penawaran yang masuk
Prakondisi: Thread Sistem selalu memeriksa tabel outbox pada database setiap detik
Pemicu: Use case ini dijalankan ketika ThreadGetOutbox berjalan running
Bidang khas suatu event:
Kegiatan Pelaku Langkah 1: Memeriksa record pada
tabel outbox dimana status_outbox bernilai ‘0’
Langkah 2: Mengirim record pesan pada tabel tersebut kepada bidder
yang dituju dan mengubah status_outbox menjadi bernilai ‘1’
Respons Sistem
Bidang Alternatif: Alt-1: Jika tidak ada record pada tabel outbox dimana status_outbox bernilai
‘0’, maka Thread Sistem tetap selalu memeriksa tabel tersebut. Kesimpulan:
Use case ini merupakan proses membalas penawaran yang dikirim bidder Postkondisi:
Informasi penawaran berhasil atau informasi kesalahan terkirim pada bidder Aturan Bisnis:
-- Batasan dan
Spesifikasi Implementasi:
--
Asumsi: --
Masalah terbuka: --
Universitas Sumatera Utara
75 Alur kerja workflow pada use case Membalas Penawaran dapat digambarkan dalam
activity diagram berikut:
Gambar 3.23 Activity Diagram untuk Use Case Membalas Penawaran
3.3.22 Use Case Membalas Request Informasi
Use case Membalas Request Informasi dijelaskan pada tabel dokumentasi naratif berikut:
Tabel 3.22 Dokumentasi Naratif Membalas Request Informasi
Nama Use Case: Membalas Request Informasi
ID Use Case: --
Prioritas: Tinggi
Sumber: Persyaratan
Pelaku Bisnis Utama: Thread Sistem
Pelaku Sistem Utama: Thread Sistem
Universitas Sumatera Utara
76
Tabel 3.22 Dokumentasi Naratif Membalas Request Informasi lanjutan
Pelaku Partisipan Lain:
-- Stakeholder yang
Berminat Lain: --
Deskripsi: Use case ini mendeskripsikan proses membalas request informasi yang masuk
Prakondisi: Thread Sistem selalu memeriksa tabel outbox pada database setiap detik
Pemicu: Use case ini dijalankan ketika ThreadGetOutbox berjalan running
Bidang khas suatu event:
Kegiatan Pelaku Langkah 1: Memeriksa record pada
tabel outbox dimana status_outbox bernilai ‘0’
Langkah 2: Mengirim record pesan pada tabel tersebut kepada bidder
yang dituju dan mengubah status_outbox menjadi bernilai ‘1’
Respons Sistem
Bidang Alternatif: Alt-1: Jika tidak ada record pada tabel outbox dimana status_outbox bernilai
‘0’, maka Thread Sistem tetap selalu memeriksa tabel tersebut. Kesimpulan:
Use case ini merupakan proses membalas request informasi yang dikirim bidder
Postkondisi: Informasi yang di-request atau informasi kesalahan terkirim pada bidder
Aturan Bisnis: --
Batasan dan Spesifikasi
Implementasi: --
Asumsi: --
Masalah terbuka: --
Alur kerja workflow pada use case Membalas Request Informasi dapat digambarkan dalam activity diagram berikut:
Universitas Sumatera Utara
77
Gambar 3.24 Activity Diagram untuk Use Case Membalas Request Informasi
3.3.23 Use Case Menentukan Pemenang
Use case Menentukan Pemenang dijelaskan pada tabel dokumentasi naratif berikut:
Tabel 3.23 Dokumentasi Naratif Menentukan Pemenang
Nama Use Case: Menentukan Pemenang
ID Use Case: --
Prioritas: Tinggi
Sumber: Persyaratan
Pelaku Bisnis Utama: Thread Sistem
Pelaku Sistem Utama: Thread Sistem
Pelaku Partisipan Lain:
-- Stakeholder yang
Berminat Lain: --
Universitas Sumatera Utara
78
Tabel 3.23 Dokumentasi Naratif Menentukan Pemenang lanjutan
Deskripsi: Use case ini mendeskripsikan proses menentukan pemenang lelang
Prakondisi: Thread Sistem selalu memeriksa waktu sekarang current time
Pemicu: Use case ini dijalankan ketika ThreadSetPemenang berjalan running
Bidang khas suatu event:
Kegiatan Pelaku Langkah 1: Mengambil pengaturan
waktu selesai lelang pada database Langkah 2: Memeriksa apakah
waktu pada database sesuai dengan waktu sekarang
Langkah 3: Mengubah status_barang pada tabel barang
menjadi bernilai 2 Langkah 4: Mencari penawaran
tertinggi untuk masing – masing barang yang dilelang
Langkah 5: Menyimpan data pemenang pada database
Respons Sistem
Bidang Alternatif: Alt-2: Jika waktu pada database tidak sama dengan waktu sekarang, Thread
Sistem tetap selalu memeriksa waktu tersebut. Kesimpulan:
Use case ini merupakan proses menentukan pemenang lelang dan menyimpan data pemenang tersebut pada database
Postkondisi: Lelang ditutup dan data pemenang lelang tersimpan pada database
Aturan Bisnis: Waktu selesai lelang secara default adalah pada pukul 17.00. Waktu ini dapat
diubah sesuai dengan kebijakan perusahaan Batasan dan
Spesifikasi Implementasi:
--
Asumsi: --
Masalah terbuka: --
Alur kerja workflow pada use case Menentukan Pemenang dapat digambarkan dalam activity diagram berikut:
Universitas Sumatera Utara
79
Gambar 3.25 Activity Diagram untuk Use Case Menentukan Pemenang
Universitas Sumatera Utara
80
3.4 Class Diagram Analisis Sistem
