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 2 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) PENEKANAN PADA FILE INI , DALAM PROSES PERANCANGAN, MENGACU PADA DOKUMEN ANALISIS TERSTRUKTUR Studi Kasus 1 3 Perancangan Data Basisdata: (1) Tabel Koin Field (1) Tipe (2) Panjang (3) Desimal (4) Nilai Default (5) Spek (6) Null (7) Keterangan (8) JenisKoin Character 4 Blank char 0..9 F Key Field NamaKoin Character 10 Blank char a..z, A..Z F Nominal Numerik 4 0 0 0..1000 F (2) Tabel Minuman Field (1) Tipe (2) Panjang (3) Desimal (4) Nilai Default (5) Spek (6) Null (7) Keterangan (8) JenisMinuman Character 2 Blank char 0..9 F Key Field NamaMinuman Character 20 Blank char a..z, A..Z F Studi Kasus 1 4 (3) Tabel Harga Field (1) Tipe (2) Panjang (3) Desimal (4) Nilai Default (5) Spek (6) Null (7) Keterangan (8) JenisMinuman Character 2 Blank char 0..9 F Key Field Harga Numerik 4 0 0 0..1000 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 5 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. Terima Pembayaran Terima harga minuman Program Utama nominal Validasi pembayaran koin sisa Terima pilihan sah pilihan pilihan Atur Keluaran sisa Keluarkan koin Keluarkan minuman pilihan objek = modul koordinator Terima pilihan jenis minuman Studi Kasus 1 6 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. 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. Terima Pembayaran Terima harga minuman Validasi pembayaran Terima pilihan sah Keluarkan koin Keluarkan minuman MPM Studi Kasus 1 7 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 8 Antarmuka Modul: (cuplikan pada Parameter Table) Proses Input Output TerimaPembayaran Objek Type: char Length: 10 Def. Val: koin Null: F Nominal Type: integer Length: 4 Def. Val: 0 Null: F TerimaHargaMinuman Minuman Type: char Length: 20 Def. Val: Null: F Harga Type: integer Length: 4 Def. Val: 0 Null: F dst Studi Kasus 1 9 (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: 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. Coca Cola 1000 Fanta 750 Sprite 1000 Pesan ditulis di sini Tombol Studi Kasus 1 10 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 11 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: jika ada, dapat mengacu pada bagian SDD yang suda mendeskripsikan struktur data tsb. Library: sebutkan lib mana yang digunakan dan harus mengacu ke direktori/mesin yang mana Lokasi: server X Database: Tabel Koin } 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