Mesin Penjual Minuman (MPM)

MPM adalah sebuah mesin yang berfungsi untuk menjual minuman secara otomatis. Cara kerjanya adalah sebagai berikut: Seorang pembeli harus memasukkan koin dengan harga tertentu ke dalam mesin. Kemudian pembeli harus memasukkan jenis minuman yang dibeli. Jika koin yang dimasukkan sudah memenuhi syarat harga beli, maka mesin akan mengeluarkan minuman yang dibeli tersebut. Beberapa masalah yang mungkin dihadapi oleh mesin adalah: Seseorang yang berusaha memasukkan benda, tetapi bukan koin, ke dalam mesin untuk mendapatkan minuman secara ilegal Seseorang yang iseng memasukkan sampah ke dalam mesin yang akan menyebabkan kerusakan mesin Seseorang yang berusaha menekan tombol-tombol secara sembarang tanpa prosedur yang benar untuk mengacaukan mesin

Studi Kasus 1

Untuk itu MPM harus dapat melakukan: Menerima objek dari pembeli untuk membayar minuman (SRS-MPM-01) Memeriksa apakah objek yang dimasukkan adalah benar-benar koin yang sah/valid. Hal ini harus dilakukan dengan cara memeriksa ukuran, berat, dan ketebalan (SRS-MPM-02) Menerima koin dalam bentuk 1000-an, 500-an, dan 100-an. Koin dalam bentuk lain akan dianggap sampah oleh mesin dan akan dikembalikan ke pembeli (SRS-MPM-03) Perhitungan pembayaran ataupun proses pemilihan minuman hanya akan dilakukan jika koin yang dimasukkan sudah dideteksi keabsahannya (SRS-MPM-04) Menerima masukan jenis minuman dari pembeli (SRS-MPM-05) Memeriksa apakah minuman yang dibeli masih tersedia dalam jumlah cukup, jika tidak mencukupi maka mesin akan mengembalikan koin secara otomatis dan memberikan pesan ke pembeli (SRS-MPM-06) Menerima jenis bermacam-macam minuman, sehingga tabel harga juga harus dapat diubah setiap saat (SRS-MPM-07) Mengembalikan koin jika pembeli membatalkan pembelian (SRS-MPM-08) Mengeluarkan jenis minuman yang dibeli jika tersedia dan jumlahnya memenuhi (SRS-MPM-09) Mengembalikan koin kepada pembeli jika koin yang dimasukkan melebihi harga minuman yang dibeli (SRS-MPM-10) Me-nonaktif-kan tombol pemilihan minuman setelah minuman dikeluarkan dari mesin, sampai koin berikutnya terdeteksi keabsahannya (SRS-MPM-11)

Studi Kasus 1

Data Context Diagram

objek Pembeli Pilihan minuman sampah
0:

Koin kembalian MPM minuman Pembeli

DFD level 1
Tabel koin objek
0.1: terima pembayaran

Jenis koin Jenis koin pembayaran pembayaran harga pilihan minuman sah pilihan minuman sah Jenis minuman

0.5: keluarkan koin

Koin kembalian Jumlah kembalian

sampah

0.3: validasi pembayaran

minuman
0.6: keluarkan minuman

harga Tabel harga

0.2: terima harga minuman

pilihan minuman

0.4: terima pilihan sah

Jenis minuman Tabel Minuman

3

Studi Kasus 1

Data Dictionary . . {sebagian} Objek = Minuman = Koin = Koin Kembalian = P-SPEC 0.3: Input: Output: Body: If pembayaran >= harga then Jumlah kembalian = pembayaran harga Pembayaran cukup = true Else Jumlah kembalian = 0 Pembayaran cukup = false pembayaran : data masukan Harga : data masukan Jumlah kembalian : data keluaran Pembayaran cukup: kontrol keluaran [koin | sampah] [coca-cola | sprite | fanta | gatorade] [1000-an | 500-an | 100-an] [Koin lebih | Koin pembayaran]

Studi Kasus 1

Control Context Diagram

Permintaan pengembalian koin

Pembeli

0:

MPM

Minuman tersedia

Pembeli

CFD level 0
Tabel koin
Permintaan pengembalian koin Permintaan pengembalian koin

Koin sah terdeteksi

1: terima pembayaran

Pembayaran cukup 3: validasi pembayaran Minuman tersedia

5: keluarkan koin

Pembayaran cukup

Minuman sudah dikeluarkan

Tabel harga

2: terima harga minuman

6: keluarkan minuman Minuman tersedia 4: terima pilihan sah Minuman tersedia

Tabel Minuman
5

Studi Kasus 1

C-SPEC 0: Tabel Aktivasi Proses

Aksi Keluarkan koin Terima permintaan 0 Keluarkan minuman 1 Terima koin baru 0 Kembalikan pembayaran 1 Keluarkan minuman 0 1 0 0 Terima pilihan sah 1 0 0 0 Terima pembayaran 0 0 1 0

C-SPEC 0: State Transition Diagram

inisialisasi Terima koin baru Pembayaran dikembalikan Terima koin baru

Menunggu koin
Koin sah terdeteksi Terima permintaan Minuman dikeluarkan Terima koin baru Permintaan pengembalian koin Kembalikan pembayaran

Menunggu masukan pilihan

Pembayaran mencukupi Keluarkan minuman Minuman tersedia = 0 Kembalikan pembayaran

Mengembalikan pembayaran

Mengeluarkan minuman

Studi Kasus 1

Perancangan Data
Basisdata: (1) Tabel Koin Field (1) JenisKoin NamaKoin Nominal (2) Tipe Panjang (2) (3) Character 4 Character 10 Numerik 4 Desimal (4) Nilai Default Spek (5) (6) Blank char 0..9 Blank char a..z, A..Z 0 0..1000 Null (7) F F F Keterangan (8) Key Field

Tabel Minuman Field Tipe Panjang (1) (2) (3) JenisMinuman Character 2 NamaMinuman Character 20 Desimal (4) Nilai Default Spek (5) (6) Blank char 0..9 Blank char a..z, A..Z Null Keterangan (7) (8) F Key Field F

Studi Kasus 1

(3)

Tabel Harga Field (1) JenisMinuman Harga Tipe Panjang Desimal Nilai Default (2) (3) (4) (5) Character 2 Blank char Numerik 4 0 0 Spek (6) 0..9 0..1000 Null Keterangan (7) (8) F Key Field F

Catatan: (1) - Perancangan awal / preliminary design dapat menghasilkan deskripsi data setidaknya pada kolom 1 4, dan 8 - Perancangan rinci harus menanbahkan deskripsi pada kolom 5 7, serta harus disesuaikan dengan lingkungan DBMS-nya. Misal, jika menggunakan MS Access, tentukan juga masalah Mask, Referential Integrity, dll. (2) Disamping itu, jika ada struktur data utama yang harus diimplementasikan pada perangkat lunak maka hal itu harus dideskripsikan di sini juga. Misalnya terbentuknya struktur List Sirkular atau Array 3 dimensi dll. Dalam kasus MPM ini kebetulan tidak ada.

Studi Kasus 1

Perancangan Arsitektural
Perancangan arsitektural membutuhkan DFD sebagai masukan awal proses pembentukan Structure Chart (SC). Pada dasarnya proses pembentukan SC merupakan proses mapping dari DFD ke struktur kendali PL. Bubble yang ada pada DFD merupakan sebuah modul yang menjalankan fungsi tertentu. DFD baru merepresentasikan aliran data yang terjadi pada PL dan tidak merepresentasikan kendali jalannya PL. Pada kenyataannya, agar sebuah modul dapat aktif melakukan fungsinya harus diaktifkan atau dipanggil oleh modul lain. Modul yang berfungsi mengaktifkan modul lain biasa disebut modul koordinator. Modul jenis ini biasanya tidak nampak pada DFD namun keberadaannya pada PL sangat berarti. Untuk itu modul ini harus dimunculkan pada SC untuk mengetahui Siapa mengaktifkan siapa. = modul koordinator
sisa koin Terima Pembayaran sisa Validasi pembayaran pilihan Terima pilihan jenis minuman pilihan Terima pilihan sah Keluarkan koin Atur Keluaran pilihan Keluarkan minuman

objek nominal

Program Utama

Terima harga minuman

Studi Kasus 1

Disamping SC, arsitektur PL juga harus direpresentasikan dalam bentuk Hierarchy Chart (HC) untuk merepresentasikan dekomposisi PL menjadi komponen-komponen elementer. Berbeda dengan SC, HC ini tidak menyatakan kendali program melainkan menyatakan dekomposisi modul-modul dari modul yang lebih besar (superordinat subordinat). Untuk membuat HC dapat digunakan DCD dan DFD sebagai bahan acuan.

MPM

Terima Pembayaran

Terima harga minuman

Keluarkan minuman

Validasi pembayaran

Terima pilihan sah

Keluarkan koin

Catatan: Jika pada salah satu kotak di atas masih terbagi menjadi modul-modul di bawahnya maka dekomposisi tersebut harus ditambahkan pada HC. Acuan untuk membentuk ini dapat dilihat pada DFD level di bawahnya, jika ada.

Studi Kasus 1

10

Perancangan Antarmuka
Dapat direpresentasikan dalam bentuk: - Interface file, file yang berisi daftar spesifikasi prosedur dan keterangannya, seperti bagian interface pada sebuah Unit Pascal atau file yang berisi prototype pada kompilator C. - Paramater table, tabulasi yang berisi daftar parameter dan keterangannya (1) Antarmuka Modul: (cuplikan pada Interface file) Procedure TerimaPembayaran(objek: char, var nominal: integer) {Prosedur untuk menerima masukan objek dan mendeteksi jenis objek yang dimasukkan oleh user Initial State: sistem sedang menunggu masukan koin Final State: objek terdeteksi apakah koin atau sampah } Procedure TerimaHargaMinuman(Minuman: Char, var Harga: integer) {Prosedur untuk memberikan harga minuman yang dibeli sesuai dengan jenis minuman Initial State: sistem sudah mendeteksi adanya koin yang sah dan user sudah memasukkan jenis minuman yang dibeli Final State: memberikan Harga minuman yang di beli } . . . dst

Studi Kasus 1

11

Antarmuka Modul: (cuplikan pada Parameter Table) Proses TerimaPembayaran Input Objek Type: Length: Def. Val: Null: Minuman Type: Length: Def. Val: Null: char 10 koin F char 20 F Nominal Type: Length: Def. Val: Null: Harga Type: Length: Def. Val: Null: Output integer 4 0 F integer 4 0 F

TerimaHargaMinuman

dst

Studi Kasus 1

12

(2) Antarmuka Layar: MPM memiliki layar sederhana (embedded pada h/w-nya) yang berisi jenis minuman dan harganya serta sebaris tempat untuk pesan/ message. Bentuk antarmuka layar tersebut adalah sbb:

Coca Cola Tombol Fanta Sprite

1000 750 1000

Pesan ditulis di sini

Maka antarmuka yang lebih kompleks tidak perlu dirancang di sini. Untuk PL yang diimplementasikan pada sebuah komputer, antarmuka layar harus dibuat untuk setiap modul yang membutuhkan/berkaitan, khususnya yang terkait dengan input/output dari/ke user.

Studi Kasus 1

13

Perancangan Prosedural
Bahan acuan utamanya adalah P-Spec pada proses analisis. P-Spec tersebut di-copy dan ditambahkan dengan atribut-atribut yang diperlukan programmer untuk mengimplementasikan modul tersebut, yaitu setidaknya harus ada: kamus lokal struktur data yang digunakan library yang dipakai lokasi penyimpanan (client atau server atau mesin tertentu) Database yang terlibat

Studi Kasus 1

14

Procedure TerimaPembayaran(objek: char, var nominal: integer) {Prosedur untuk menerima masukan objek dan mendeteksi jenis objek yang dimasukkan oleh user Initial State: sistem sedang menunggu masukan koin Final State: objek terdeteksi apakah koin atau sampah Struktur data: Library: Lokasi: Database: } Kamus lokal: Sah: boolean Algoritma: Buka Tabel Koin Sah := false; If objek = Koin.JenisKoin then Sah := true; Nominal := Koin.Nominal Else Nominal := 0; {sampah} Tutup Tabel Koin . . . dst jika ada, dapat mengacu pada bagian SDD yang suda mendeskripsikan struktur data tsb. sebutkan lib mana yang digunakan dan harus mengacu ke direktori/mesin yang mana server X Tabel Koin

Studi Kasus 1

15