BAB V

PEMODELAN SISTEM / SYSTEM MODELLING

SOFTWARE ENGINEERING 9TH EDITION

IAN SOMMERVILLE LANCASTER UNIVERSITY
ADDISON – WESLEY 2011

DITERJEMAHKAN OLEH:

OLIVER MANAHAN PASARIBU,S.T.

JURUSAN TEKNIK ELEKTRO
FAKULTAS TEKNIK
UNIVERSITAS BRAWIJAYA
MALANG 2018
Saat ini sedang bekerja sebagai Tenaga Harian Lepas/Karyawan Honorer Bagian Adm. Keuangan
dan Asset Sekretariat Daerah Kota Pematangsiantar Propinsi Sumatera Utara Republik Indonesia

Page 1
 BAB V

PEMODELAN SISTEM

(SYSTEM MODELLING)

Pemodelan Sistem (Sistem modeling) adalah proses pengembangan model-model abstrak dari suatu sistem
dengan tiap model menyajikan tampilan yang berbeda atau menyajikan perspektif dari sistem tersebut.
Pemodelan merupakan suatu cara yang umum untuk membuat representasi suatu sistem dengan
menggunakan notasi grafis berdasarkan notasi standar yang digunakan dalam Unified Modelling
Language.(UML)
Selain membuat pemodelan dengan notasi grafis menguunakan UML, pemodelan Sistem juga
mengembangkan model matematis formal untuk memodelkan sebuah Sistem, biasanya dilakukan dalam
pengembangan spesifikasi Sistem secara terperinci.
Model-model Sistem yang telah dikembangkan ini akan digunakan selama proses rekayasa/teknik-
persyaratan untuk membantu menurunkan persyaratan untuk sebuah Sistem, dan selama proses desain untuk
menjelaskan Sistem kepada para engineer yang sedang membuat implementasi sistem, dan sesudah
implementasi untuk membuat dokumentasi operasi dan struktur sistem.

Pemodelan Sistem yang akan dikembangkan itu bisa berupa:

1. Pemodelan Sistem yang sudah ada ; teknik pemodelan ini digunakan selama requirements
engineering. Tujuan dari pemodelan ini adalah untuk membantu menjelaskan apa yang dapat
dilakukan oleh Sistem yang telah ada dan dapat digunakan sebagai dasar untuk mendiskusiskan
kekuatan dan kelemahan sistem tersebut.
2. Pemodelan Sistem yang baru dilakukan selama requirements engineering sebagai alat bantu untuk
menjelaskan persyaratan yang diajukan (proposed requirements ) kepada stakeholder lain yang
berhubungan dalam pengembangan Sistem. Selain itu para engineer menggunakan model-model
ini untuk melakukan desain proposal dan membuat dokumentasi Sistem untuk implementasi.
Dalam proses engineering yang berdasarkan model-model (model-driven engineering process)
adalah mungkin untuk membangkitkan suatu implementasi Sistem secara parsial atau keseluruhan
dari sebuah model Sistem.

Model-model yang dikembangkan untuk membuat representasi Sistem bisa bermacam-macam

sesuai perspektif yang berbeda. Sebagai contoh:
1. Perspektif eksternal, yaitu pemodelan konteks atau lingkungan dari suatu Sistem.
2. Perspektif interaksi, yaitu pemodelan interaks-interaksi antara Sistem dengan lingkungannya, atau
antara komponen-komponen yang terdapat dalam Sistem tersebut.

Page 2
 3. Perspektif struktural, yaitu pemodelan organisasi Sistem atau struktur data yang diproses oleh
Sistem.
4. Perspektif behavioral, yaitu pemodelan tingkah laku dinamis (dynamic behaviour) dari suatu
Sistem dan bagaimana Sistem tersebut merespon suatu event.

5.1 Pemodelan Berdasarkan Perspektif Eksternal/Pemodelan Konstek (Context Models)

Pemodelan Konstektual memodelkan Sistem informasi environment dan relasinya dengan sistem
otomata lainnya. Gambar 5.1 menunjukkan pemodelan konteks yang menggambarkan Sistem informasi
kesehatan pasien Medical Healthcare Project Monitoring Sistem MHC-PMS terhubung dengan Sistem
record pasien, management reporting Sistems, Admision Sistem,dan yang terakhir Prescription Sistem
yang berguna untuk membuat resep obat dari seorang pasien. Sistem in menggunakan data yang sama /
berbagi data (shared data)

GAMBAR 5.1
PEMODELAN SISTEM DENGAN MENGGUNAKAN PERSPEKTIF EKSTERNAL ,PEMODELAN
KONTEKS SISTEM INFORMASI SISTEM SEBAGAI CONTOH SEDERHANA DARI MENTAL HEALTH
CARE PROJECT MONITORING CONTROL (MHC-PMC)

Page 3
 Gambar 5.2

Model Proses Yang Terjadi Dalam Suatu Sistem MHC-PCS dengan Menguunakan Diagram Aktivitas Unified
Modelling Language (UML)

5.2 Pemodelan Perspektif Interaksi / Pemodelan Interaksi (Interaction Models)

Pemodelan Interaksi, memodelkan Sistem dengan memperlihatkan masukan, dan keluaran pengguna serta
interaksi antar komponen dalam Sistem. Ada 2 macam pemodelan interaksi yaitu:

5.2.1 Use Case Modelling; memodelkan interaksi antara Sistem dan actor eksternal seperti yang
ditunjukkan pada gambar 5.3, gambar 5.4 dan gambar 5.5.

Gambar 5.3
Penggunaan Use Case Transfer Data memperlihat interaksi Aktor yang terlibat dalam proses transfer data yaitu aktor
resepsionis medis dan Sistem record pasien

Page 4
 Gambar 5.4
Penjelasan Tabular dari use case ‘transfer data’

Gambar 5.5
Pemodelan Interaksi Use Case Modelling menampilkan aktor dengan peran resepsionis medis

5.2.2 DIAGRAM ALIR (SEQUENCE DIAGRAM)

Diagram Alir (sequence diagrams) dalam UML digunakan terutama untuk memodelkan interaksi-
interaksi antara actor-aktor dan objek-objek dalam suatu Sistem, dan interaksi-interaksi antara obyek-
obyek yang ada dalam Sistem tersebut. UML memiliki berbagai macam sintaks diagram untuk
memodelkan berbagai interaksi yang berbeda-beda.

Seperti namanya, diagram alir menunjukkan urutan interaksi yang terjadi selama use case tertentu
atau use case instance. Gambar 5.6 adalah contoh dari suatu diagram alir yang mengilustrasikan notasi
dasar. Diagram ini memodelkan interaksi-interaksi yang melibatkan dalam tampilan atau view use case
informasi pasien, di mana seorang resepsionis medis (bagian pendaftaran rumah sakit atau asisten dokter)
dapat melihat beberapa informasi pasien.

Page 5
 Gambar 5.6
Diagram Alir Untuk Menampilkan Informasi Pasien

Penjelasan gambar 5.6 diagram alir untuk yang melibatkan actor dengan peran resepsionis medis untuk
menampilkan informasi pasien:
1. Resepsionis medis memicu metode ViewInfo dalam suatu instance P dari suatu kelas Objek
PatientInfo , memasukkan patient’s identifier / ID pasien yang disebut PID. P adalah objek
user interface yang ditampilkan sebagai sebuah form yang menunjukkan informasi pasien.
2. Instance P (contoh atau permintaan) memanggil database untuk memberikan informasi yang
diperlukan, memasukkan identifier resepsionis medis untuk mengijinkan pemeriksaan
sekuriti (validasi dan verifikasi login dan hak akses).
3. Database memeriksa (validasi dan verifikasi) otorisasi Sistem untuk memastikan bahwa
pengguna memiliki otoritas untuk mengakses Sistem.
4. Jika otorisasi berhasil, informasi pasien dikembalikan/dalam hal ini di berikan dan form
pada layar pengguna akan diisi dengan informasi pasien yang diminta. Jika otorisasi gagal,
Sistem akan memberikan pesan kesalahan kepada pengguna dalam hal ini resepsionis medis.

Page 6
 Gambar 5.7
Digram Alir Untuk Pengiriman Data.

Penjelasan gambar 5.7 Diagram alir untuk pengiriman data:

1. Resepsionis medis melakukan proses logon (validasi dan verifikasi) untuk masuk ke Patient
Record System (PRS) yaitu sistem yang memuat rekaman/ record pasien.
2. Tersedia 2 pilihan/opsi. Hal ini mengijinkan pengiriman secara langsung (direct transfer)
informasi pasien yang telah diperbaharui ke PRS dan kemudian mengirimkan ringkasan data
kesehatan dari MHC-PMS ke PRS.
3. Untuk masing-masing pilihan, proses verifikasi dan validasi resepsionis medis diperiksa dengan
menggunakan otorisasi sistem.
4. Informasi pribadi dapat dikirimkan secara langsung dari objek antarmuka pengguna (USER
INTERFACE OBJECT) ke PRS (PATIENT RECORD SYSTEM) atau alternatif lainnya adalah
record ringkasan /summary record dapat dibuat dengan menggunakan database yang ada lalu
kemudian di kirim ke PRS.
5. Pada tahap akhir pengiriman, Patient Record System (PRS) akan mengeluarkan pesan status, lalu
user dalam hal ini resepsionis medis akan log off atau keluar dari sistem.

5.3 Pemodelan Struktural

Pemodelan struktural menampilkan organisasi sistem dalam bentuk komponen-komponen yang
membangun sistem dan relasi-relasinya. Pemodelan structural dapat berupa pemodelan statis (static
models) yang menunjukkan struktur desain sistem, atau pemodelan dinamis (dynamic models) yang

Page 7
menunjukkan organisasi system saat melakukan proses eksekusi. Pemodelan statis dan dinamis sangat
berbeda jauh. Organisasi system secara dinamis menggambarkan system sebagai suatu himpunan dari
interaksi thread dapat berbeda jauh dari model statis dari komponen-komponen system.
Pembuatan model-model structural dari suatu system dilakukan saat para software engineer
mendiskusikan dan mendesain arsitektur system. Desain arsitektur merupakan topik penting yang khusus
dalam software engineering dan UML, komponen, bingkisan/package dan penggambaran diagram yang
digunakan saat menyejikan model-model arsitektural system. Pada bagian ini penulis akan memusatkan
pembahasan pada penggunaan diagram kelas (class diagram) untuk pemodelan struktur statis dari kelas-
kelas objek dalam sistek perangkat lunak.

5.3.1 Diagram Kelas (Class Diagram)

Diagram kelas digunakan saat mengembangkan model system berorientasi objek untuk menunjukkan
kelas-kelas dalam sebuah system dan asosiasi antara kelas-kelas dalam system. Suatu kelas objek dapat
dipikirkan sebagai suatu definisi umum dari suatu jenis objek system. Asosiasi adalah suatu hubungan
antara kelas yang menunjukkan bahwa ada relasi/hubungan antara kelas dalam system. Sebagai akibatnya,
setiap kelas boleh jadi memiliki sejumlah pengetahuan terhadap kelas-kelas lain yang berhubungan.
Saat seorang software engineer sedang mengembangkan model-model pada tahap awal proses
perangkat lunak, objek-objek merepresentasikan sesuatu dalam dunia nyata seperti pasien, resep, dokter,
dsb. Saat suatu implementasi telah dikembangkan, software engineer perlu untuk mendefinisikan objek
implementasi tambahan (additional implementation-objects) yang digunakan untuk menyediakan
fungsionalitas system yang diperlukan. Penulis (Ian Sommerville) akan memusatkan pembahasan pada
pemodelan objek-objek dunia-nyata sebagai bagian dari persyaratan atau proses awal desain perangkat
lunak.
Diagram-diagram kelas dalam UML dapat dijelaskan pada tingkatan yang berbeda untuk setiap
detilnya. Saat seorang engineer sedang mengembangkan sebuah model, tahap pertama adalah melihat
dunia, mengidentifikasi objek2 penting (identify essential objects) dan merepresentasikannya sebagai
kelas-kelas. Cara termudah untuk melakukan hal ini adalah dengan menuliskan nama kelas-kelas tersebut
dalam suatu kotak teks (text box). Pembaca juga dapat membuat catatan sederhana mengenai adanya relasi-
relasi yang ada sebagaimana ditunjukkan dalam gambar 5.8

Gambar 5.8
Kelas UML dan asosiasinya

Page 8
 Gambar 5.8 memberikan ilustrasi kelengkapan diagram kelas; kemampuan untuk menunjukkan
berapa banyak objek yang terlibat dalam asosiasi/hubungan. Dalam contoh ini, setiap akhir dari suatu
relasi/asosiasi di berikan penjelasan dengan sebuah angka 1 yang berarti bahwa ada suatu hubungan 1:1
antara objek-objek dari kelas-kelas (Ingat kembali pelajaran matematika yang berhubungan dengan teori
himpunan, fungsi, relasi dan perkawanan satu-satu one to one, one to many, many to one). Setiap pasien
mempunyai tepat atau hanya mempunyai satu record dan setiap record berisi informasi mengenai tepat atau
hanya satu pasien.
Ilustrasi pada gambar 5.9 memberikan penjelasan yang lebih lengkap. Gambar 5.9
mengembangkan diagram kelas jenis ini untuk menunjukkan bahwa objek-objek dari kelas Pasien juga
memiliki suatu relasi dengan sejumlah kelas lainnya. Dalam contoh ini penulis akan menunjukkan bahwa
pembaca dapat menamai tiap relasi untuk memberikan penunjukan jenis relasi yang ada kepada pembaca.
UML juga mengijinkan untuk menjelaskan peran dari objek-objek yang memiliki relasi.
Pada tingkatan detil ini, diagram kelas terlihat seperti model-model data semantik. Model data
semantik digunakan dalam desain basis data. Model data semantic menunjukan entitas-entitas data, atribut
yang berhubungan dengan model data semantic tersebut dan dan hubungan antara entitas-entitas tersebut.
Pendekatan pemodelan ini pertamakali diperkenalkan oleh Chen (1976); beberapa varian telah
dikembangkan pada masa berikutnya oleh Codd (1979), Hammer dan McLeod (1981), Hull dan King
(1987) dengan bentuk dasar yang sama.
UML tidak menyertakan notasi spesifik untuk pemodelan database ini sebab UML
mengasumsikannya sebagai proses pengembangan berorientasi objek dan data model menggunakan objek-
objek dan relasi atau hubungannya. Pembaca dapat menggunakan UML untuk merepresentasikan model
data semantic dan memikirkan entitas-entitas dalam model data semantic sebagai kelas-kelas objek yang
disederhanakan (tidak ada operasi), dan atribut-atribut sebagai atribut kelas objek dan dinamakan
berhubungan dengan kelas-kelas objek.
Saat menggambarkan hubungan antar kelas, akan menyenangkan untuk menggambarkan kelas-
kelas dalam cara yang sesederhana mungkin. Untuk mendefinisikan kelas secara detail, pembaca dapat
menambahkan informasi atribut (karakteristik dari sebuah objek) dan operasinya. Sebagai contoh objek
pasien akan memiliki atribut alamat dan pembaca dapat mentertakan suatu operasi yang disebut
ChangeAddress/UbahAlamat yang dipanggil saat pasien menunjukkan bahwa mereka telah berpindah
alamat dari satu alamat ke alamat lainnya. Dalam UML, pembaca menunjukkan atribut-atribut dan operasi-
operasi dengan memperluas persegipanjang sederhana yang merepresentasikan sebuah kelas sebagaimana
ditunjukkan dalam gambar 5.10.

Page 9
 Gambar 5.9
Kelas-Kelas dan Asosiasinya dalam suatu MHC-PMS

Gambar 5.10
Kelas Konsultasi Memiliki Atribut Dokter, Tanggal,Waktu,Klinik,Alasan, Medication Prescribed, Treatment
Prescribed, Catatan Suara, Dan Transkrip serta Operasi New(), Prescribe(), RecordNotes(), Transcribe() dsb.

5.3.2 Generalisasi
Generalisasi adalah teknik yang digunakan dalam kehidupan sehari-hari saat menangani situasi
yang rumit. Untuk mengatasi kebingungan dalam mempelajari karakteristik detail dari setiap entitas yang
kita alami, pembaca akan menempatkan entitas-entitas ini dalam kelas-kelas yang lebih umum (misalnya
binatang, mobil, rumah, dsb) dan mempelajari karakteristik tiap kelas. Ini akan memungkinkan pembaca
menduga anggota-anggota yang berbeda memiliki kesamaan karakteristik tertentu. (misalnya tupai dan
tikus dapat digeneralisasikan dalam kelas pengerat karena sama-sama mengerat.).
Gambar 5.11 memberikan penjelasan yang lebih baik mengenai generalisasi. Generalisasi
ditunjukkan oleh sebuah panah berujung yang menunjuk ke atas kepada kelas yang lebih umum. Ini

Page 10
menunjukkan bahwa dokter praktek umum (general practicioner) dan dokter rumah sakit (hospital
doctors) dapat digeneralisasi sebagai dokter. Ada tiga jenis dokter rumah sakit (hospital doctor) yaitu
dokter yang baru lulus dari fakultas kedokteran harus disupervisi (Trainee Doctor), dokter yang dapat
bekerja tanpa pengawasan sebagai bagian tim konsultan (registered doctor) dan konsultan, yaitu dokter
senior yang mempunyai tanggung jawab penuh dalam pengambilan keputusan.
Dalam suatu generalisasi, atribut dan operasi diasosiasikan dengan kelas yang memiliki tingkatan
lebih tinggi dan juga dengan kelas-kelas yang memiliki tingkatan yang lebih rendah. Artinya, kelas dengan
level yang lebih rendah merupakan sub kelas yang mewarisi sifat atribut dan operasi dari kelas yang lebih
tinggi. Kelas-kelas dengan level yang lebih rendah juga memiliki atribut dan operasi lain yang lebih
spesifik. Sebagai contoh, semua dokter memiliki nama dan nomor telepon; semua dokter rumah sakit
memiliki nomor staf dan departemen, tetapi dokter praktek umum (general practicioner) tidak memiliki
atribut-atribut ini dan mereka bekerja secara independen. Dokter umum juga memiliki tempat/nama
praktek dan alamat seperti yang ditunjukkan dalam gambar 5.12.

Gambar 5.11
Hierarki Generalisasi Dokter merupakan contoh Generalisasi

Page 11
 Gambar 5.12
Hierarki Generalisasi dengan penambahan Detail Staf, Pager,Praktek dan Alamat

5.3.3 Agregasi
Objek-objek dalam dunia nyata seringkali merupakan gabungan dari bagian-bagian yang berbeda.
Sebagai contoh, paket belajar dari suatu kursus dapat terdiri dari sebuah buku, slide PowerPoint, kuis-kuis,
dan rekomendasi bacaan selanjutnya. Kadang-kadang dalam sebuah model system, seorang engineer perlu
untuk mengilustrasikannya. UML menyediakan hubungan tipe khusus antara kelas-kelas yang disebut
agregasi. Agregasi berarti bahwa sebuah objek (seluruh objek) tersusun dari objek lain sebagaimana
ditunjukkan dalam gambar 5.13. Rekord pasien merupakan komposisi atau gabungan dari Pasien dan
sejumlah konsultasi pasien dan dokter.

5.4 Pemodelan Behavioural

Pemodelan behavioral adalah pemodelan tingkah laku dinamis (dynamic behavior models) pada saat
melakukan eksekusi. Pemodelan behavioural menunjukkan apa yang terjadi atau apa yang seharusnya
terjadi saat suatu system merespon/menanggapi stimulus dari lingkungannya. Ada dua jenis stimuli yaitu:
1. Data. Data yang masuk harus diproses oleh system
2. Kejadian/Events. Beberapa event terjadi dan selanjutnya akan memicu pemrosesan oleh system.
Event atau kejadian data memilik data yang berhubungan tetapi tidak harus.

Gambar 5.13
Asosiasi Agregasi Pasien dan Dokter Serta Jumlah Konsultasi Yang direkam dalam Rekaman
Pasien.

Sistem-sistem bisnis merupakan sistem pemrosesan data yang terutama di kendalikan

oleh data. Sistem bisnis ini dikendalikan oleh data masukan ke dalam system dengan
Page 12
pemrosesan event eksternal yang relatif kecil. Pemrosesan ini melibatkan sejumlah
urutan aksi terhadap data dan pembangkitan suatu keluaran. Sebagai contoh, suatu
sIstem tagihan telepon TELEKOM akan menerima informasi mengenai panggilan yang
masuk dari pelanggan, menghitung biaya panggilan dan membuat atau membangkitkan
5.4.1 Data-Driven Modeling
Pemodelan dikendalikan oleh Data (Data Driven Modelling) menunjukkan sejumlah aksi yang
berurutan dalam pemrosesan data masukan dan menghasilkan atau membangkitkan keluaran yang
berhubungan. Pemodelan dikendalikan oleh data ini sangat berguna khususnya selama analisis persyaratan
karena dapat dipergunakan untuk menunjukkan pemrosesan end-to-end dalam system.
Pada tahun 1970, metode yang terstruktur seperti DeMarco’s Structured Analysis
memperkenalkan data-flow-diagrams (DFD) sebagi cara untuk menjelaskan langkah-langkah pemrosesan
dalam system. Model aliran data ini sangat berguna karena penjejakan dan dokumentasi bagaimana data
diasosiasikan dengan proses khusus bergerak atau mengalir dalam system dan membantu analis system dan
para desainer untuk memahami apa yang sedang terjadi. DFD sangat sederhana dan intuitif dan biasanya
sangat potensial untuk memberikan penjelasan kepada engineer mengenai pengguna system potensial yang
dapat berpartisipasi dalam melakukan validasi model.
Gambar 5.14 menunjukan urutan rantai pemrosesan yang terlibat dalam perangkat lunak pompa
insulin. Dalam gambar 5.14 pembaca dapat melihat langkah atau tahapan pemrosesan (direpresentasikan
sebagai aktivitas) dan aliran data antara tiap langkah.

Gambar 5.14
Model Aktivitas Operasi Pompa Insulin
Page 13
5.4.2 Pemodelan Dikendalikan Kejadian (Event Driven Modelling)
Event-driven modeling menunjukkan bagaimana system menanggapi event eksternak dan internal.
Pemodelan ini berdasarkan asumsi bahwa system memiliki sejumlah keadaan tertentu dan bahwa kejadian-
kejadian (stimuli) dapat menyebabkan terjadinya transisi dari satu keadaaan ke keadaan lainnya. Sebagai
contoh, suatu system pengendali katup dapat bergerak dari keadaan ‘katup terbuka ’ kepada ‘katup
tertutup’ saat perintah operator diterima. Event-based modeling ini pertama kali diperkenalkan dalam
metode desain waktu nyata oleh Ward dan Mellor (1985) dan Harel (1987,1988).
Diagram keadaan (state diagram) menunjukkan keadaan system dan event-event yang
menyebabkan transisi dari satu keadaan ke keadaan lainnya. Diagram keadaan tidak menunjukkan aliran
data dalam system melainkan menyertakan informasi tambahan pada komputasi yang dilakukan pada
setiap keadaan.
Sebagai contoh adalah suatu perangkat lunak pengendali untuk oven gelombang mikro sederhana.
Oven microwave sebenarnya jauh lebih rumit, tetapi system yang disederhanakan ini lebih mudah untuk
dipahami. Oven microwave sederhana ini memiliki saklar untuk memilih suplai daya maksimum atau
setengah daya, papan kunci numeric untuk memasukkan waktu memasak, tombol start/stop, dan tampilan
alfanumerik.
Penulis mengasumsikan urutan aksi untuk menggunakan oven microwave sbb:
1. Memilih level daya daya penuh atau setengah daya.
2. Memasukkan waktu memasak menggunakan keypad numerik
3. Menekan tombol start dan makanan dimasak sesuai waktu yang ditentukan.

Gambar 5.16

Diagram Keadaan Oven Microwave

Page 14
 Untuk alasan keamanan, oven tidak boleh beroperasi saat pintu terbuka. Pada saat selesai memasak
buzzer pada oven akan mengeluarkan suara untuk notifikasi. Oven memiliki alat penampil alfa numeric
untuk menampilkan berbagai peringatan dan pemberitahuan.

Dalam diagram keadaan UML, persegi panjang dengan ujung bulat merepresentasikan keadaan-
keadaan system. Diagram keadaan dapat menyertakan penjelasana singkat (diikuti oleh ‘Do’) dari tindakan
yang diambil dalam suatu keadaan. Panah berlabel merepresentasikan stimuli yang memaksa terjadinya
transisi dari satu keadaan ke keadaan lain. Pembaca dapat menunjukkan keadaan ‘START’ dan ‘END’
menggunakan lingkaran terisi sebagaimana dalam diagram aktivitas.

Berdasarkan gambar 5.16 pembaca dapat melihat bahwa system mulai dalam keadaan menunggu
dan memberikan respon permulaan terhadap tombol daya penuh atau setengah daya. Pengguna dapat
mengubah daya yang disuplai. Tombol waktu dapat diatur jika pintu oven telah tertutup dengan baik,
dan tombol ‘START’ akan enabled. Jika pengguna oven menekan tombol start, oven akan mulai
beroperasi dalam hal ini memasak sesuai waktu yang telah ditentukan. Gambar 5.17 menunjukkan
penjelasan tabular tiap keadaan dan bagaimana stimuli akan memaksa terjadinya perubahan keadaan.
Kelemahan pemodelan berdasarkan keadaan ini adalah untuk system yang lebih besar engineer perlu
menyembunyikan detail model dengan menggunakan ide superstate yang melakukan enkapsulasi sejumlah
keadaan luar biasa. Superstate akan terlihat seperti keadaan tunggal atau single state pada high-level model
tetapi kemudian dapat diperluas untuk menunjukkan detail pada diagram terpisah. Sebagai ilustrasi
perhatikan keadaan operasi dalam gambar 5.15. Ini adalah suatu superstate yang dapat diperluas
sebagaimana ditunjukkan dalam gambar 5.18.

Page 15
 Gambar 5.17
Tabulasi Keadaan dan Stimuli Oven Microwave

Gambar 5.18

Enkapsulasi untuk Superstate dalam Oven Microwave

Page 16
 Oven microwave dalam keadaan beroperasi menyertakan sejumlah sub-keadaan. Gambar 5.18
menunjukkan bahwa operasi mulai dengan pemeriksaan status dan jika ada masalah ditemukan, suatu
alarm ditunjukkan dan operasi akan disable. Memasak melibatkan menjalankan generator microwave untuk
durasi waktu yang telah ditentukan. Saat aktivitas memasak selesai, buzzer akan berbunyi. Jika pintu
oven terbuka saat oven sedang memasak, maka sistem akan berpindah ke keadaan disabled
sebagaimana ditunjukkan dalam gambar 5.15.

5.5 Teknik Dikendalikan Model (Model-Driven Engineering)

Model-driven engineering (MDE) adalah suatu pendekatan dalam pengembangan perangkat lunak.
Model lebih dari sekadar program. Model merupakan keluaran utama dari proses development. Program
yang melaksanakan platform perangkat keras dan perangkat lunak dibuat secara otomatis dari model yang
sudah dibuat. Pihak-pihak yang mendukung MDE ini beralasan bahwa ini meningkatkan level abstraksi
dalam software engineering atau teknik perangkat lunak, sehingga para engineer tidak perlu lagi
berhubungan dengan detail bahasa pemrograman atau mengeksekusi suatu platform khusus.
Model-driven engineering berakar dari model-driven architecture yang diajukan oleh Object
Management Group (OMG) pada tahun 2001 sebagai paradigma baru dalam pengembangan perangkat
lunak. MDE memilik ruang lingkup yang lebih luas dari MDA. Ada 2 golongan pendapat penting
mengenai MDE:

1. Pendukung MDE
model-based-engineering memungkinkan para engineer untuk memikirkan mengenai sistem pada
abstraksi tingkat tinggi, tanpa memperhatikan detail implementasinya. Hal ini akan mengeurangi
kemungkinan terjadinya kesalahan, meningkatkan kecepatan proses desain dan implementasi,
memungkinkan pembuatan reusable dan aplikasi platform model yang independen.

2. Penentang MDE
Model sangat baik untuk memfasilitasi diskusi mengenai desain perangkat lunak. Akan tetapi
abstraksi model itu tidak selalu dapat untuk diimplementasikan.

Page 17
5.5.1 Model-Driven Architecture

Gambar 5.19
Transformasi Model Driven Architecture suatu sistem perangkat lunak secara umum

Metode model-driven-architecture (MDA) merekomendasikan 3 jenis pemodelan sistem abstrak

yang harus dihasilkan yaitu:

1. Model Komputasi Independen/Computation Independent Model (CIM)

CIM adalah pemodelan domain abstraksi yang penting yang digunakan dalam sistem. CIMM kadang-
kadang disebut domain-models. Pembaca dapat mengembangkan beberapa CIM yang berbeda, yang
mencerminkan tampilan/perspektif yang berbeda dari suatu sistem. Sebagai contoh kemungkinan ada
CIM sekuriti yang penting yang mengidentifikasi abstraksi sekuriti yang penting seperti suatu aset dan
suatu peran atau CIM rekaman pasien yang menjelaskan abstraksi seperti pasien-pasien, konsultasi-
konsultasi, dsb.

2. Model Platform Independen/Platform Independent Models (PIM)

PIM adalah pemodelan abstrak yang memodelkan operasi dari suatu sistem tanpa acuan terhadap
implementasinya. PIM biasanya dijelaskan menggunakan pemodelan UML untuk menunjukkan
struktur sistem statis dan bagaimana sistem tersebut menanggapi event-event eksternal dan internal.

3. Model Platform Spesifik/Platform Specific Models (PSM)

Pemodelan PSM merupakan transformasi dari Platform Independent Models (PIM) dengan PSM yang
terpisah untuk setiap platform aplikasi. Secara prinsip ada lapisan-lapisan/layers dari PSM. Setiap
lapisan/layer menambahkan detail yang bersifat platform-specific. Dengan demikian, level pertama
PSM dapat berupa middleware-specific tetapi basis data yang independen. Ketika suatu dabatase
spesifik dipilih, PSM dapat dibuat atau dibangkitkan.

Page 18
 Gambar 5.20
Model Spesifik Multiple-Platform

5.5.2 Executable UML

Ide dasar yang melatarbelakangi model-driven-engineering adalah bahwa adalah memungkinkan
untuk membuat tarasformasi model dari suatu sistem otomasi yang lengkap menjadi kode. Untuk
melakukan ini, pembaca harus dapat membuat model grafis yang memiliki semantik yang terdefinisi
dengan baik. Selain itu juga diperlukan suatu cara penambahan informasi ke dalam model grafis mengenai
cara operasional yang didefinisikan dalam model yang diimplementasikan. Hal ini mungkin dilakukan
dengan menggunakan himpunan bagian UML atau UML 2 yang disebut Executable UML atau Xuml
(Mellor dan Balcer 2002).
UML didesain sebagai sebuah bahasa untuk mendukung dan mendokumentasikan desain perangkat
lunak, dan bukan sebagai bahasa pemrograman. Desainer UML pada awalnya tidak berhubungan dengan
detail semantik suatu bahasa melainkan dengan ekspresifnes atau kejelasannya. Desainer UML telah
memperkenalkan ide-ide yang berguna seperti diagram use-case yang menolong dalam desain tetapi terlalu
informal untuk mendukung eksekusi. Untuk membuat xUML, sejumlah model telah direduksi secara
menjadi 3 jenis yaitu:

1. Pemodelan Domain/Domain Model;

Pemodelan domain mengidentifikasi relasi-relasi yang prinsipal dalam suatu sistem/ Model-model ini
didefinisikan menggunakan diagram-diagram kelas yang menyertakan objek-objek, atribut-atribut dan
asosiasi-asosiasi.
2. Pemodelan Kelas / Class Model
Pemodelan kelas ini mendefinisikan kelas-kelas bersamaan dengan atribut-atribut dan operasi-operasi
yang dimiliki oleh kelas.
3. Pemodelan Keadaan/State Models
Pemodelan ini menghubungkan diagram keadaan dengan masing-masing kelas dan digunakan untuk
menjelaskan siklus hidup kelas.

Page 19
 Tingkah laku dinamis suatu sistem dapat ditentukan secara deklaratif menggunakan object
constraint language (OCL) atau dijelaskan menggunakan UML action language atau bahasa tindakan
UML. Action Language ini adalah semacam suatu bahasa pemrograman tingkat tinggi yang dapat mengacu
pada objek-objek dan atribut-atribut dari objek dan menentukan tindakan atau actions yang akan dilakukan.

Page 20
LATIHAN

5.1. Explain why it is important to model the context of a system that is being developed. Give two
examples of possible errors that could arise if software engineers do not understand the system
context.

Berikan penjelasan saudara mengapa membuat model konteks dari suatu sistem yang
sedang dikembangkan itu sangat penting?
penting? Berikan dua contoh kesalahan yang mungkin
timbul jika para insinyur perangkat lunak yang terlibat dalam tim pengembangan
perangkat lunak tidak memahami konteks system!

5.2. How might you use a model of a system that already exists? Explain why it is not always
necessary for such a system model to be complete and correct. Would the same be true if you
were developing a model of a new system?

Bagaimana anda dapat menggunakan model dari suatu sIstem

stem yang ttelah ada? Berikan
penjelasan anda mengapa pembuatan suatu model sistem yang benar dan lengkap tidak
selalu diperlukan?

5.3. You have been asked to develop a system that will help with planning large-
large-scale events and parties
such as weddings, graduation celebrations, birthday parties, etc. Using an activity diagram, model
the process context for such a system that shows the activities involved in planning a party (booking
a venue, organizing invitations, etc.) and the system elements that may be used at e each stage.

Saudara diminta untuk mengembangkan sebuah sistem yang akan membantu perencanaan
event dan acara pesta seperti pernikahan, perayaan kelulusan, pesta ulang tahun,dsb.
Gunakan diagram aktivitas untu memodelkan konteks proses dari suatu sistem yan yang
menunjukkan aktivitas-aktivitas
aktivitas aktivitas yang terlibat dalam merencanakan suatu pesta. (pemesanan
tempat/lokasi pesta, pengorganisasian undangan pesta, dsb) dan elemenelemen-elemen sistem
yang dapat digunakan dalam setiap tingkatan.

Petunjuk:

Ini merupakan sistem informasi yang akan digunakan oleh suatu event organizer skala besar.

5.4. For the MHC-PMS,

PMS, propose a set of use cases that illustrates the interactions between a doctor,
who sees patients and prescribes medicine and treatments, and the MHC-PMS.
PMS.

Dalam suatu sistem pemeliharaan kesehatan medis – sistem monitoring proyek (MHC
(MHC-
PMS) buatlah suatu himpunan uses cases yang memberikan gabaran interaksi
interaksi-interaksi
yang terjadi antara seorang dokter, yang menangani pasien yang menderita suatu
penyakit, memberikan resep obat dan perawatan dan berhubungan dengan suatu MHC MHC-
PMS.

5.5. Develop a sequence diagram showing the interactions involved when a student registers for a
course in a university. Courses may have limited enrollment, so the registration process must
include checks that places are available. Assume that the student accesses an electronic course
catalog to find out about available courses.

Coba saudara gambarkan suatu diagram alir yang menunjukkan interaksi

interaksi-interaksi yang terjadi
saat seorang mahasiswa melakukan proses pendaftaran kursus/pelatihan dalam suatu
universitas.Kursus/pelatihan
Kursus/pelatihan memiliki jumlah peserta yang terbatas, sehingga dalam proses
registrasi harus menyertakan pemeriksaan ketersediaan tempat bagi seorang pendaf pendaftar.

Page 21
 Anggaplah bahwa mahasiswa tersebut mengakses catalog kursus elektronik untuk menemukan
informasi lebih lanjut mengenai kursus yang akan diadakan.

5.6. Look carefully at how messages and mailboxes are represented in the e-mail system that you use.
Model the object classes that might be used in the system implementation to represent a mailbox
and an e-mail message.
Perhatikan baik-baik bagaimana pesan dan kotak sorat direpresentasikan dalam sistem email yang
anda gunakan. Buatlah model kelas-kelas objek yang digunakan dalam implementasi sistem untuk
merepresentasikan sebuah kotak surat/mailbox dan sebuah pesan surat elektronik/e-mail.

5.7. Based on your experience with a bank ATM, draw an activity diagram that models the data
processing involved when a customer withdraws cash from the machine.
Berdasarkan pengalaman anda menggunakan Anjungan Tunai Mandiri/Automatic Trasfer
Machine/Cash Dispenser, gambarkan diagram aktivitas yang memodelkan pemrosesan data yang
terlibat ketika seorang pelanggan melakukan penarikan uang secara tunai melalui ATM.

5.8. Draw a sequence diagram for the same system. Explain why you might want to develop both activity
and sequence diagrams when modeling the behavior of a system.

Gambarkan diagram alir untuk sistem yang sama. Berikan penjelasan mengapa seorang insinyur
harus menggunakan diagram aktivitas dan diagram alir, keduanya secara bersama-sama dalam
membuat model sistem?

5.9. Draw state diagrams of the control software for:

An automatic washing machine that has different programs for different types of clothes.

The software for a DVD player.

A telephone answering system that records incoming messages and displays the number of
accepted messages on an LED. The system should allow the telephone customer to dial in from
any location, type a sequence of numbers (identified as tones), and play any recorded messages.

Gambarkan diagram keadaan untuk perangkat lunak kendali sistem-sistem berikut:

Sebuah mesin cuci otomatis yang memiliki jenis-jenis pilihan program yang berbeda untuk mencuci
jenis pakaian yang berbeda pula.

Perangkat lunak untuk sebuah alat pemutar DVD

Suatu sistem penjawab telepon otomatis yang dapat merekam pesan masuk dan menampilkan jumlah
total pesan yang diterima pada suatu penampil LED. Sistem harus memungkinkan pelanggan untuk
melakukan sambungan/panggilan dari suatu lokasi, memasukkan urutan nomor (disebut juga nada
dual tone multi frequency DTMF,) dan memutar kembali setiap pesan (elektronik dan suara) yang telah
direkam.

5.10. You are a software engineering manager and your team proposes that model-driven engineering
should be used to develop a new system. What factors should you take into account when
deciding whether or not to introduce this new approach to software development?

Jika saudara adalah seorang manager software engineering. Tim saudara mengajukan bahwa
teknik rekayasa berdasarkan model / model driven engineering seharusnya digunakan untuk

Page 22
 mengembangkan suatu sistem yang baru. Berikan penjelasan saudara mengenai factor-faktor apa
saja yang harus dimasukkan dalam perhitungan saaat saudara ingin melakukan proses
pengambilan keputusan apakah perlu memperkenalkan/menggunakan suatu pendekatan baru
dalam mengembangkan perangkat lunak?

PEMBAHASAN
1. Pemodelan sistem khususnya pemodelan konteks penting untuk dilakukan:

- untuk existing system: pemodelan sistem (khususnya pemodelan konstekstual) dengan

grafis dan notasi lainnya dapat digunakan untuk mengevaluasi/mendiskusikan kelebihan
dan kekurangan sistem tersebut sehingga memungkinkan terjadinya continous
improvement.

- untuk pengembangan sistem yang baru, model sistem yang telah dibuat selama proses
requirement engineering akan digunakaan sebagai alat bantu untuk menjelaskan
persyaratan yang telah diajukan kepada stakeholder lain yang berhubungan dalam
proses pengembangan sistem.

- secara khusus, pemodelan konteks itu memodelkan sistem dengan sistem lain di luarnya
(dalam hal ini kelas lain dalam sistem), memahami hubungan antar sistem dengan entitas
sistem lain di luarnya, jenis relasi/asosiasinya, bisnis prosesnya untuk menghindar
kesalahan dalam tahapan interaksi dengan sistem yang dapat menyebabkan kesalahan
lainnya.

Jika insinyur dalam tim pengembangan perangkat lunak tidak memahami konteks sistem
maka tidak dapat menangkap urutan aktivitas proses bisnis yang akan dibuat, akan timbul
kesalahan logika alur program karena salah menerjemahkan proses bsnis, kesalahan
dalam komputasi, mungkin akan menyebabkan kesalahan pada sistem lain yang
berhubungan, dan berpotensi menyebabkan terjadinya hazard.

2. Pemodelan sistem yang sudah ada hanya digunakan untuk memfasilitasi diskusi kelebihan
dan kekurangan sistem yang sudah ada. Melalui diskusi ini diharapkan akan timbul ide-ide
baru untuk melakukan perbaikan berkesinambungan untuk meningkatkan kemampuan sistem
(upgradeable sistem) di masa yang akan dating atau mengembangkan sistem yang baru
(iterative development)

3. Proses model yang terjadi dalam event organizer:

1. Pesanan / Order masuk dari pelanggan untuk mengorganisir suatu event

2. Pesanan masuk di catat dalam register EO atau work order task berisi rincian pesta yang
dilakukan, tempat dan waktu pelaksanaan, jumlah undangan,kostum sesuai dengan

Page 23
 dress code ,konsumsi, hiburan, publikasi (undangan pesta), dan dokumentasi
pesta/acara yang diinginkan user atau pengguna jasa EO.
3. Event Organizer melakukan aktivitas sesuai dengan order yang masuk, meyakinkan
tersedianya tempat pada waktu yang telah dilakukan, mempersiapkan undangan sesuai
dengan jumlah undangan yang ditentukan,kursi, menyediakan kostum yang sesuai bagi
penyelenggara pesta, mempersiapkan konsumsi sesuai dengan harga yang disepakati
dan perkiraan jumlah undangan yang hadir, melakukan dekorasi gedung atau tempat
kegiatan pesta,mempersiapkan dokumentasi pesta sesuai dengan permintaan user.
4. Customer membayar seluruh/atau uang muka rincian biaya pesta yang telah
dikalkulasikan oleh pihak event organizer sebagai bayaran penggunaan jasa event
organizer dalam penyelenggaraan pesta.
5. Pesta diadakan pada hari-H sesuai dengan yang telah direncanakan berdasarkan
pesanan user.
6. Pesta selesai, pihak event organizer memenuhi semua kewajiban atas penggunaaan
semua sarana dan pra-sarana atau perlengkapan pesta.
7. Pihak pengguna jasa EO memenuhi segala kewajiban dan melunasi sisa biaya pesta
sesuai dengan harga yang telah disepakati.
8. Sistem membangkitan laporan tertulis mengenai detil pesta yang diselenggarakan dan
rincian finansial, sekaligus bukti pembayaran yang menunjukkan bahwa pengguna jasa
telah memenuhi kewajibannya 9melunasi biaya pesta sebagai bukti hukum yang
berkekuatan tetap.

Page 24
 Gambar proses model aktivitas Event Organizer EO (mengacu pada gambar 5.1) :

<<sistem>>

BOOKING/VENUE
RESERVASI
<<sistem>> <<sistem>>

PENYEWAAN CATERING/KONSUMSI
PERLENGKAPAN

<<sistem>>

EVENT ORGANIZER
EO-PMS

<<sistem>> <<sistem>>

PENYEWAAN PEMBAYARAN/TAGIHAN
PERLENGKAPAN

4. Use CaSE MHC-PMC

1. Pasien penderita penyakit mendaftar pada resepsionis medis untuk berobat ke dokter.
2. Resepsionis medis mencatat pendaftaran pasien, identitas pasien, alamat, umur,
keluhan atas penyakit yang dialami dalam suatu sistem.
3. Pasien berobat ke dokter sesuai dengan keluhan penyakit yang disampaikan.

4. Dokter membaca rekaman data pasien yang telah dicatat oleh resepeionis medis,
melakukan pemeriksaan yang diperlukan atau diagnosa atas penyakit yang diderita pasien.
5. Dokter memberikan resep obat yang sesuai untuk pasien sesuai dengan hasil

diagnosis yang telah dibuat.

6. Dokter memutuskan apakah perlu perawatan lanjut berkala, atau perawatan

yang lebih mendalam untuk pengobatan pasien. Jika diperlukan pengobatan
lanjut, dokter membuat surat rujukan untuk melakukan pengobatan lanjutan.

5. – Calon peserta kursus datang ke tempat pendaftaran untuk mendaftarkan diri

mengikuti kursus yang dimaksud.
- Resepsionis pendaftaran mencatat data calon peserta kursus/pelatihan berupa nama, jenis
kelamin, umur, alamat, dan jenis kursus yang akan diikuti.
- Resepsionis menyampaikan mengenai materi pelatihan, tempat, waktu
pelaksanaan/jadwal kursus, biaya, durasi pelaksanaan dan persyaratan lain yang harus
dipatuhi calon peserta.
Page 25
- Calon peserta membayar biaya kursus dan memenuhi persyaratan lain yang diminta.
- Resepsionis memberi bukti pembayaran kursus dan ID peserta kursus sebagai bukti calon
peserta telah melakukan pembayaran dan telah terdaftar sebagai peserta kursus.

Resepsionis pendaftaran sistem record peserta kursus

kursus

P: D: AS: Autorisasi
pendaftaran_peserta_ SISTEM_INFORMASI_ sistem
baru KURSUS_UNIVERSITAS

LOGIN_KE_SISTEM_INFORMASI_KURSUS

Update_Info()
Update_sistem_
informas_KURSUS UID
Otorisasi(TF,UID)

Otorisasi_ACK

Perbaharui (PID)

Acknowledgement_perbarui_OK
Message(OK)

Perbaharui()
Perbaharui(UID)
Otorisasi TF_UID

OTORISASI_ACK

summary

Update(PID)

Update(OK)

Logout dari sistem

Page 26
Penggambaran use case – use case:
a. use case transfer data.

Use case transfer data rekaman medis pasien yang telah dibuat/direkam oleh resepsionis ke
dalam database sistem Rekaman pasien /Patient Record System (Pada kenyataannya ini
merupakan suatu proses memasukkan data rekaman kesehatan pasien ke dalam suatu
database sistem rekaman pasien/patient record system.

b. use case yang melibatkan peran resepsionis medis:

seorang resepsionis medis di klinik.prakter pribadi atau rumah sakit dapat melakukan
registrasi pasien yang akan berobat, membatalkan registrasi pasien. Menampilkan informasi
pasien tertentu yang diinginkan.

Registrasi pasien

Membatalkan
registrasi pasien

Menampilkan
informasi pasien

Mengirim data

Menghubungi
pasien

RESEPSIONIS MEDIS

Page 27
c. Use case yang melibatkan peran dokter yang melakukan pemeriksaan/diagnosis, penulisan
resep obat dan pemberian treatment yang sesuai untuk menyembuhkan pasien.
Aktor dokter

Melakukan
diagnosis

Menuliskan
resep obat

Memberikan
treatment yang
sesuai

Page 28
6. Penggambaran kotak surat dan pesan elektronik dengan class models:

Kelas email Disimpan dalam Kelas mailbox

email
Tanggal
Waktu
Pengirim
Subjek
…
Tulis()
Edit()
Hapus()
Balas()
Kirim()
Forward()
Pindah()
…

mailbox
Inbox
Outbox
Draft
Spam
Terkirim
Grup
…
Hapus()
Pindahkan()
Urutkan()
…

Keterangan:

Kelas email memiliki atribut tanggal, waktu,pengirim, subjek, dengan metode/operasi yang berhubungan
dengan kelas email adalah tulis(), edit(), hapus(), balas(), kirim(), teruskan(), spam(), dsb. Kelas kotak surat
atau kelas mailbox memiliki atribut inbox, outbox,draft,terkirim,grup dan sebagainya. Selain itu kelas
mailbox memiliki mtode/operasi yang berhubungan dengan kelas mailbox seperti hapus(), pindahkan(),
urutkan(), dan masih banyak metode atau operasi lainnya yang berhubungan dengan kelas mailbox.

Page 29
7. Gambar Diagram aktivitas penarikan uang tunai dari Anjungan Tunai Mandiri (Automated

Transfer Machine) adalah sebagai berikut:

START

MASUKAN KARTU
ATM KE MESIN ATM

BACA DATA
AUTENTIFIKASI DAN
VALIDASI NOMOR PIN

Autentifikasi
PIN FALSE

Pilih Menu Transaks

yang diinginkan
pada layar ATM

Proses transaksi yang dipilih

sesuai pilihan transaksi dan
nominal yang dipilih dengan
keypad alfa numerik

INGIN MELAKUKAN
TRANSAKSI LAINNYA?

CETAK DATA
TRANSAKSI

Page 30
SELESAI
Page 31
  Seleksi kondisi autentifikasi PIN nasabah/customer BANK atau proses validasi dan verifikasi
nasabah BANK v&v, selain menggunakan seleksi kondisi dengan menggunakan nomor PIN,
juga dapat ditambahkan perulangan dengan pencacah untuk membatasi sebanyak 3 kali
memasukkan nomor PIN. Jika terjadi kesalahan memasukkan nomor PIN sebanyak 3 kali
berturut-turut maka transaksi nasabah ditolak oleh ATM atau kartu nasabah diblokir oleh
BANK yang menyediakan layanan Anjungan Tunai Mandiri.

8.Diagram alir yang menggambarkan urutan proses penarikan uang dari ATM adalah sebagai berikut:

sistem rekaman data akun tabungan nasabah BNRI

nasabah BNRI

Instance P: insert D: Sistem Informasi AS: Autorisasi

sard into ATM card Akun BANK Bank sistem
reader Negara Republik
Indonesia

Instance P

ALT

Sistem mengirimkan permintaan v&v PIN

SEND PIN

Nasabah memasukkan PIN untuk v&v SENT PIN

ACK PIN ERROR permintaan transaksi ditolak ACK PIN error

[PIN]
Nasabah memasukkan PIN untuk v&v ]SENT PIN]

PIN (OK)

ACK v&v PIN nasabah berhasil

ACK PILIH JENIS TRANSAKSI YANG DIINGINKAN

NASABAH MEMILIH JENIS TRANSAKSI YANG DIINGINKAN ,

DAN MEMASUKKAN JUMLAH PENARIKAN YANG DIINGINKAN,

ATM mengeluarkan uang tunai sesuai dengan permintaan nasabah

Catat transaksi

ATM mencetak bukti transaksi penarikan uang tunai

transaksi

Nasabah logout dari sistem, atm mengeluarkan

Page 32
 Kartu ATM milik nasabah nasabah, transaksi selesai

9. Gambar Diagram keadaan (state diagram) sistem:

a. Mesin cuci untuk berbagai jenis pakaian yang akan dicuci

. KEADAAN MATI MESIN CUCI PILIH JENIS

HIDUP/ON
Menekan tombol on
INDIKATOR
CUCIAN
MENYALA

Pengaturan
Timer

OPERASI MENCUCI SELESAI

MENENTUKAN PAKET CUCI,

YAITU MENCUCI DENGAN
LEVEL SABUN, MEMBILAS,
MENGERINGKAN ATAU
KETINGGIAN AIR
KETIGANYA SEKALIGUS

LEVEL AIR LEVEL AIR>=THRESHOLD

< THRESHOLD

OPERASI
DISABLED
OPERASI MENCUCI
DO:BUZZER SET BASED ON
THE TIMER

PINTU TERTUTUP

DISABLED

DO:MENUNGGU Pintu terbuka

Page 33
b.Pemutar VCD/DVD

PLAYER ON/IDLE MASUKKAN DISK

PLAYER OFF STATE
tekan tombol power

GANTI DISK

PINTU DVD PLAYER TERTUTUP

RESUME
PUTAR DISK

DISABLE STATE PINTU PEMUTAR DVD TERBUKA

DO:WAITING

c. Penjawab Telepon Otomatis TELEKOM:

INCOMING CALL/INCOMING

MESSAGE

MULAI ANSWERED ON HOOK/ READY

TELEPON IDLE MODE
STATE/READY/OFF
HOOK

CALL TERMINATED

ATUR TIMER PENJAWAB

REKAM PESAN TELEPON OTOMATIS

TAMPILKAN PENCATATAN
SUARA (NOT ANSWERED)
PANGGILAN/PESAN YANG
DITERIMA DI LAYAR CALL/CONNECTION
TAMPILAN ALFANUMERIK
ESTABLISHED

Page 34
10. Faktor-faktor yang harus dipertimbangkan apakah perlu menggunakan metode model-driven
engineering dalam proses software-development yang sedang dilakukan sebagaimana
disarankan oleh tim:

a. Faktor finansial, apakah keputusan untuk menggunakan MDE saat ini akan
menguntung atau layak dilakukan secara financial mengingat ketersediaan atau
perkembangan teknologi saat ini apakah memungkinkan untuk penerapan MDE?
Apakah itu sesuai dengan tuntutan kebutuhan yang diajukan oleh stakeholder
untuk memenuhi ekspektasi stakeholder dalam sistem yang dikembangkan?

b. Faktor teknikal, apakah perusahaan untuk saat ini dengan keadaan sumber daya
yang tersedia baik itu SDM, teknologi, knowledge dan skill telah mampu
menyediakan sistem yang dikembangkan dengan model-driven engineering?

c. Apakah penerapan model-driven engineering dalam pengembangan perangkat

lunak di perusahaan ini akan memberi kontribusi positif bagi seluruh stakeholder
dan shareholder yang ada? Misalnya akan ada pengaruh positif untuk brand
management software development perusahaan, ada peningkatan volume
pemasaran dan penjualan produk yang dihasilkan yang akan memberi dampak
positif untuk peningkatan kesejahteraan pegawai perusahaan.

Page 35
Page 36