BOOK-Systems Analysis and Design in A Changin-147-178

Machine Translated by Google
5
Memperluas Persyaratan
Model
Garis besar bab

ÿ Deskripsi Kasus Penggunaan
ÿ Diagram Aktivitas untuk Kasus Penggunaan
ÿ Diagram Urutan Sistem—Mengidentifikasi Input dan Output
ÿ Diagram Mesin Status—Mengidentifikasi Perilaku Objek
ÿ Mengintegrasikan Model Persyaratan
Tujuan pembelajaran
Setelah membaca bab ini, Anda seharusnya dapat:
ÿ Tulis deskripsi kasus penggunaan yang dikembangkan sepenuhnya
ÿ Mengembangkan diagram aktivitas untuk memodelkan alur aktivitas
ÿ Mengembangkan diagram urutan sistem
ÿ Mengembangkan diagram mesin negara untuk memodelkan perilaku objek
ÿ Jelaskan bagaimana deskripsi kasus penggunaan dan diagram UML bekerja sama untuk menentukan
persyaratan fungsional
119
120 BAGIAN 2 ÿ Kegiatan Analisis Sistem
PEMBUKAAN KASUS
Electronics Unlimited: Mengintegrasikan Rantai Pasokan

Electronics Unlimited adalah distributor pergudangan yang membeli mungkin sudah biasa bagi Anda, namun model berorientasi objek sangat
peralatan elektronik dari berbagai pemasok dan menjualnya ke pengecer di mirip dengan bahasa dan kerangka kerja pemrograman berorientasi objek
seluruh Amerika Serikat dan Kanada. Ia memiliki operasi dan gudang di Los yang baru.”
Angeles, Houston, Baltimore, Atlanta, New York, Denver, dan Minneapolis. William baru saja melakukan pemanasan.
Pelanggannya berkisar dari pengecer besar berskala nasional, seperti “Cara berpikir tentang suatu sistem dalam kaitannya dengan objek
Target, hingga toko elektronik independen skala menengah. sangat menarik,” tambahnya. “Ini juga konsisten dengan teknik pemrograman
berorientasi objek yang Anda pelajari di kelas pemrograman. Anda mungkin
Banyak pengecer besar yang beralih ke rantai pasokan terintegrasi. pertama kali belajar berpikir tentang objek ketika Anda mengembangkan
Sistem informasi dulunya berfokus pada pemrosesan data internal; namun, layar untuk antarmuka pengguna. Semua kontrol di layar, seperti tombol,
saat ini, rantai ritel tersebut menginginkan pemasok menjadi bagian dari kotak teks, dan kotak drop-down, adalah objek.
sistem rantai pasokan yang sepenuhnya terintegrasi. Dengan kata lain,
sistem perlu berkomunikasi antar perusahaan untuk membuat rantai Masing-masing memiliki rangkaian peristiwa pemicunya sendiri yang mengaktifkan
pasokan lebih efisien. fungsi programnya.”
“Bagaimana hal ini dapat diterapkan pada situasi kita?” salah satu
Untuk mempertahankan posisinya sebagai distributor grosir terkemuka, analis bertanya.
Electronics Unlimited harus mengubah sistemnya agar terhubung dengan “Anda cukup memperluas proses berpikir itu,” jelas William. “Anda
pemasoknya (produsen peralatan elektronik) dan pelanggannya (pengecer). menganggap hal-hal seperti pesanan pembelian dan karyawan sebagai
objek juga. Kita dapat menyebutnya domain masalah atau objek bisnis
Ini sedang mengembangkan sistem yang benar-benar baru yang untuk membedakannya dari objek layar, seperti jendela dan tombol. Selama
menggunakan teknik berorientasi objek untuk menyediakan tautan ini. analisis, kita harus mengetahui semua peristiwa pemicu dan metode yang
Teknik berorientasi objek memfasilitasi antarmuka sistem-ke-sistem dengan terkait dengan setiap objek bisnis.”
menggunakan komponen dan objek yang telah ditentukan sebelumnya
untuk mempercepat proses pengembangan. Untungnya, banyak anggota “Dan bagaimana kita melakukan itu?” analis lain bertanya.
staf pengembangan sistem memiliki pengalaman dengan pengembangan “Anda melanjutkan aktivitas pencarian fakta dan membangun
berorientasi objek dan bersemangat untuk menerapkan teknik dan model pemahaman yang lebih baik tentang setiap kasus penggunaan,” kata
pada proyek pengembangan sistem. William. “Cara objek bisnis berinteraksi satu sama lain dalam use case
menentukan bagaimana Anda mengidentifikasi aktivitas awal. Kami
William Jones menjelaskan pengembangan berorientasi objek kepada menyebut aktivitas tersebut sebagai pesan antar objek.
sekelompok analis sistem yang dilatih dalam pendekatan ini. Bagian tersulitnya adalah Anda perlu berpikir dalam kerangka objek, bukan
sekadar proses. Terkadang, ada baiknya saya berpura-pura menjadi sebuah
“Kami mengembangkan sebagian besar sistem baru kami dengan objek. Saya akan berkata, 'Saya adalah objek pesanan pembelian. Fungsi
menggunakan prinsip-prinsip berorientasi objek,” katanya kepada mereka. dan layanan apa yang diminta oleh objek lain untuk saya lakukan?' Setelah
“Kompleksitas sistem baru, bersama dengan interaktivitasnya, menjadikan Anda memahaminya, ini bekerja dengan sangat baik, dan sangat
pendekatan berorientasi objek sebagai cara alami untuk mengembangkan mencerahkan melihat bagaimana persyaratan sistem berkembang saat
persyaratan. Dibutuhkan proses berpikir yang sedikit berbeda dari beberapa orang
Anda mengembangkan diagramnya.”
Ringkasan
Tujuan utama dari pendefinisian kebutuhan dalam pengembangan sistem adalah
memahami kebutuhan pengguna, bagaimana proses bisnis dijalankan, dan bagaimana
sistem akan digunakan untuk mendukung proses bisnis tersebut. Seperti yang kami
tunjukkan di Bab 2, pengembang sistem menggunakan serangkaian model untuk
menemukan dan memahami persyaratan sistem baru. Kegiatan ini merupakan bagian
penting dari analisis sistem dalam proses pengembangan sistem. Langkah pertama dalam
proses mengembangkan pemahaman ini memerlukan keterampilan mencari fakta yang Anda pelajari
Kegiatan pencarian fakta disebut juga kegiatan penemuan, dan tentunya penemuan harus
mendahului pemahaman.
Model yang diperkenalkan di Bab 3 dan 4 berfokus pada dua aspek utama persyaratan
fungsional: kasus penggunaan dan hal-hal yang terlibat dalam pekerjaan pengguna.
Kasus penggunaan diidentifikasi dengan menggunakan teknik tujuan pengguna dan teknik
dekomposisi peristiwa. Diagram use case UML diperkenalkan untuk menunjukkan use case
BAB 5 ÿ Memperluas Model Persyaratan 121
dan aktor. Sebuah sistem informasi juga perlu mencatat dan menyimpan informasi tentang hal-hal yang
terlibat dalam proses bisnis. Dalam sistem manual, informasi dicatat di atas kertas dan disimpan dalam
lemari arsip. Dalam sistem otomatis, informasi disimpan dalam file elektronik atau database. Persyaratan
penyimpanan informasi suatu sistem didokumentasikan dengan diagram hubungan entitas (ERD) atau
dengan diagram kelas model domain UML.
Dalam bab ini, Anda mempelajari teknik dan model tambahan yang memungkinkan Anda memperluas
model persyaratan untuk menampilkan informasi tambahan tentang kasus penggunaan dan kelas domain
untuk sistem. Deskripsi kasus penggunaan yang dikembangkan sepenuhnya, diagram aktivitas UML, dan
diagram urutan sistem (SSD) UML diperkenalkan untuk menampilkan lebih banyak informasi tentang setiap
kasus penggunaan. Kemudian, diagram mesin negara UML diperkenalkan; ini membantu Anda menampilkan
lebih banyak informasi tentang kelas domain. Ingat, ketika menentukan persyaratan untuk suatu sistem,
Anda juga akan melakukan pekerjaan desain dan implementasi, seperti yang diilustrasikan dalam aplikasi
Pameran Dagang yang dikembangkan di Bab 1. Bab berikutnya mulai mencakup aktivitas desain sistem.
Deskripsi Kasus Penggunaan Daftar kasus
penggunaan dan diagram kasus penggunaan memberikan gambaran umum tentang semua kasus
penggunaan suatu sistem. Informasi rinci tentang setiap use case dijelaskan dengan deskripsi use case.
deskripsi kasus penggunaan model tekstual yang Deskripsi singkat kasus penggunaan diperkenalkan di Bab 3.
mencantumkan dan menjelaskan detail pemrosesan untuk Deskripsi kasus penggunaan mencantumkan dan menjelaskan detail pemrosesan untuk kasus penggunaan.
kasus penggunaan
Tersirat dalam semua kasus penggunaan adalah orang yang menggunakan sistem. Dalam UML, orang
tersebut disebut aktor, seperti yang ditunjukkan pada diagram use case. Seorang aktor selalu berada di luar
batas otomasi sistem tetapi mungkin menjadi bagian dari bagian manual sistem. Dengan mendefinisikan
aktor seperti itu—yaitu mereka yang berinteraksi dengan sistem—kita dapat mendefinisikan dengan lebih
tepat interaksi yang harus ditanggapi oleh sistem otomatis. Fokus yang lebih ketat ini membantu menentukan
persyaratan spesifik dari sistem otomatis itu sendiri—untuk menyempurnakannya saat kita beralih dari tabel
peristiwa ke detail kasus penggunaan.
Cara lain untuk memikirkan seorang aktor adalah sebagai sebuah peran. Misalnya, dalam kasus RMO,
kasus penggunaan Buat akun pelanggan mungkin melibatkan perwakilan layanan pelanggan yang berbicara
dengan pelanggan melalui telepon. Atau pelanggan mungkin menjadi aktor jika pelanggan menambah atau
memperbarui informasi secara langsung secara online.
Untuk menciptakan sistem yang komprehensif dan kuat yang benar-benar memenuhi kebutuhan
pengguna, kita harus memahami langkah-langkah mendetail dari setiap kasus penggunaan. Secara internal,
use case mencakup seluruh rangkaian langkah untuk menyelesaikan proses bisnis. Seringkali, beberapa
variasi langkah bisnis ada dalam satu kasus penggunaan. Kasus penggunaan Buat akun pelanggan akan
memiliki aliran aktivitas terpisah tergantung pada aktor mana yang memanggil kasus penggunaan tersebut.
Proses bagi perwakilan layanan pelanggan untuk memperbarui informasi melalui telepon mungkin sangat
berbeda dengan proses bagi pelanggan untuk memperbarui informasinya sendiri. Setiap alur aktivitas
merupakan urutan yang valid untuk kasus penggunaan Buat akun pelanggan. Alur aktivitas yang berbeda
ini disebut skenario atau terkadang contoh kasus penggunaan. Dengan demikian, skenario adalah
skenario atau contoh kasus penggunaan kumpulan serangkaian aktivitas internal unik dalam sebuah use case dan mewakili jalur unik melalui use case tersebut.
aktivitas internal unik di dalamnya
kasus penggunaan
Deskripsi Singkat Use Case Tergantung pada

kebutuhan analis, deskripsi use case cenderung ditulis pada dua tingkat detail yang terpisah: deskripsi
singkat dan deskripsi yang dikembangkan sepenuhnya.
Beberapa deskripsi singkat kasus penggunaan ditunjukkan pada Bab 3 (lihat Gambar 5-1).
Deskripsi singkat dapat digunakan untuk kasus penggunaan yang sangat sederhana, terutama bila sistem
yang akan dikembangkan adalah aplikasi kecil yang dapat dipahami dengan baik. Kasus penggunaan
sederhana biasanya memiliki satu skenario dan sangat sedikit—jika ada—kondisi pengecualian. Contohnya
adalah Tambahkan komentar produk atau Kirim pesan.
GAMBAR 5-1 Kasus penggunaan Deskripsi kasus penggunaan singkat

Kasus penggunaan dan deskripsi
Buat akun pelanggan Pengguna/aktor memasukkan data akun pelanggan baru, dan sistem menetapkan
singkat kasus penggunaan
nomor akun, membuat catatan pelanggan, dan membuat catatan akun.
Cari pelanggan Pengguna/pelaku memasukkan nomor rekening pelanggan, dan sistem

mengambil serta menampilkan data pelanggan dan rekening.
Proses penyesuaian akun Pengguna/pelaku memasukkan nomor pesanan, dan sistem mengambil
data pelanggan dan pesanan; Aktor memasukkan jumlah penyesuaian, dan sistem
membuat catatan transaksi untuk penyesuaian tersebut.
Kasus penggunaan seperti Isi keranjang belanja cukup kompleks sehingga deskripsi yang
dikembangkan sepenuhnya juga ditulis.
Deskripsi Use Case yang Dikembangkan Sepenuhnya

Deskripsi yang dikembangkan sepenuhnya adalah metode paling formal untuk mendokumentasikan
sebuah use case. Salah satu kesulitan utama bagi pengembang perangkat lunak adalah mereka sering
kesulitan memperoleh pemahaman mendalam tentang kebutuhan pengguna. Namun jika Anda
membuat deskripsi kasus penggunaan yang dikembangkan sepenuhnya, Anda meningkatkan
kemungkinan bahwa Anda memahami proses bisnis secara menyeluruh dan cara sistem harus
mendukungnya. Gambar 5-2 adalah contoh deskripsi kasus penggunaan yang dikembangkan
sepenuhnya dari kasus penggunaan Buat akun pelanggan.
Gambar 5-2 juga berfungsi sebagai templat standar untuk mendokumentasikan deskripsi
yang dikembangkan sepenuhnya untuk kasus dan skenario penggunaan lainnya. Kompartemen
pertama dan kedua digunakan untuk mengidentifikasi kasus penggunaan dan skenario dalam
kasus penggunaan (jika diperlukan) yang sedang didokumentasikan. Dalam proyek yang lebih
besar atau formal, pengidentifikasi unik juga dapat ditambahkan untuk kasus penggunaan,
dengan ekstensi yang mengidentifikasi skenario tertentu. Terkadang, nama pengembang sistem
yang membuat formulir ditambahkan.
Kompartemen ketiga mengidentifikasi kejadian yang memicu use case. Kompartemen
keempat adalah penjelasan singkat tentang use case atau skenario. Analis mungkin saja
menduplikasi deskripsi singkat yang mereka buat sebelumnya di sini. Kompartemen kelima
mengidentifikasi aktor atau aktor. Kompartemen keenam mengidentifikasi use case lain dan
bagaimana mereka berhubungan dengan use case ini. Referensi silang ke kasus penggunaan
lain ini membantu mendokumentasikan semua aspek kebutuhan pengguna.
Kompartemen ketujuh mengidentifikasi pemangku kepentingan yang merupakan pihak
berkepentingan selain aktor tertentu. Mereka mungkin adalah pengguna yang tidak benar-benar
memanggil use case namun memiliki ketertarikan pada hasil yang dihasilkan dari use case
tersebut. Misalnya, pada Gambar 5-2, departemen akuntansi tertarik untuk menangkap informasi
penagihan dan kartu kredit secara akurat. Meskipun tidak ada seorang pun di departemen
pemasaran yang benar-benar membuat akun pelanggan baru, mereka melakukan analisis statistik
terhadap pelanggan baru dan membuat promosi pemasaran. Dengan demikian, pemasar
memiliki kepentingan dalam data yang diambil dan disimpan dari kasus penggunaan Buat akun
pelanggan. Departemen penjualan tertarik untuk memiliki antarmuka pengguna yang mudah
digunakan dan menarik untuk memastikan penjualan tidak hilang karena pengalaman pengguna
yang buruk. Mempertimbangkan semua pemangku kepentingan adalah penting bagi pengembang
sistem untuk memastikan bahwa mereka telah memahami semua persyaratan.
Kompartemen kedelapan dan kesembilan—prakondisi dan pascakondisi—memberikan
informasi penting tentang keadaan sistem sebelum dan sesudah use case dijalankan. Prakondisi
prasyarat suatu kondisi yang harus mengidentifikasi keadaan sistem yang harus ada agar use case dapat dimulai, termasuk objek
benar sebelum use case dimulai apa yang harus sudah ada, informasi apa yang harus tersedia, dan bahkan kondisi aktor sebelum
memulai use case.
postcondition apa yang harus benar Postconditions mengidentifikasi apa yang harus benar setelah selesainya use case. Yang
setelah berhasil menyelesaikan use case paling penting, mereka menunjukkan objek baru apa yang dibuat atau diperbarui oleh use case
dan bagaimana objek perlu dikaitkan. Kondisi pasca adalah
GAMBAR 5-2 Deskripsi kasus penggunaan yang dikembangkan sepenuhnya untuk Membuat akun pelanggan
Gunakan nama kasus: Buat akun pelanggan.
Skenario: Buat akun pelanggan online.
Peristiwa pemicu: Pelanggan baru ingin membuat akun secara online.
Deskripsi singkat: Pelanggan online membuat akun pelanggan dengan memasukkan informasi dasar
dan kemudian menindaklanjuti dengan satu atau lebih alamat dan kartu kredit atau debit.
Aktor: Pelanggan.
Kasus penggunaan terkait: Mungkin dipanggil oleh kasus penggunaan Periksa keranjang belanja.
Pemangku kepentingan: Akuntansi, Pemasaran, Penjualan.
Prasyarat: Subsistem akun pelanggan harus tersedia.

Layanan otorisasi kredit/debit harus tersedia.
Kondisi pasca: Pelanggan harus dibuat dan disimpan.

Satu atau lebih Alamat harus dibuat dan disimpan.
Informasi kartu kredit/debit harus divalidasi.
Akun harus dibuat dan disimpan.
Alamat dan Rekening harus dikaitkan dengan Pelanggan.
Alur kegiatan: Aktor Sistem
1. Pelanggan menunjukkan keinginan untuk 1.1 Sistem menciptakan pelanggan baru.

membuat akun pelanggan dan 1.2 Perintah sistem untuk pelanggan
memasukkan informasi dasar pelanggan. alamat.
2. Pelanggan memasukkan satu atau lebih 2.1 Sistem membuat alamat.

alamat. 2.2 Sistem meminta kredit/debit
kartu.
3. Pelanggan memasukkan kartu kredit/debit 3.1 Sistem membuat akun.

informasi. 3.2 Sistem memverifikasi otorisasi
untuk kartu kredit/debit.
3.3 Sistem mengasosiasikan pelanggan,
alamat, dan akun.
3.4 Sistem mengembalikan pelanggan yang valid
Detail akun.
Pengecualian 1.1 Data dasar pelanggan tidak lengkap.

kondisi: 2.1 Alamatnya tidak valid.
3.2 Informasi kredit/debit tidak valid.
penting karena dua alasan. Pertama, mereka menjadi dasar untuk menyatakan apa yang diharapkan
hasil test case yang akan digunakan untuk menguji use case tersebut setelah diimplementasikan.
Misalnya, dalam kasus penggunaan Buat akun pelanggan, ini penting
untuk menguji apakah catatan pelanggan, catatan alamat, dan catatan akun berhasil ditambahkan
ke database. Kedua, objek-objek di postconditions menunjukkan yang mana
objek yang terlibat dalam use case penting untuk desain. Anda akan melihat di
Bab 10 dan 11 bahwa perancangan use case mencakup identifikasi dan penugasan tanggung
jawab kepada objek yang berkolaborasi untuk menyelesaikan use case. Di dalam
situasi, pelanggan, satu atau lebih alamat, dan objek akun berkolaborasi
untuk membuat akun pelanggan baru.
Kompartemen kesepuluh dalam template menjelaskan alur aktivitas use case secara rinci.
Dalam contoh ini, kami telah menunjukkan versi dua kolom, yang mengidentifikasi langkah-langkah
yang dilakukan oleh aktor dan respons yang diperlukan oleh aktor.
sistem. Nomor item membantu mengidentifikasi urutan langkah-langkah. Alternatif
aktivitas dan kondisi pengecualian dijelaskan di kompartemen kesebelas.
Penomoran kondisi pengecualian juga membantu mengaitkan pengecualian dengan kondisi tertentu
langkah-langkah dalam alur kegiatan.
Gambar 5-3 menunjukkan deskripsi use case untuk item use case Ship. Itu
skenario untuk uraian ini mengasumsikan mereka mengirimkan penjualan baru, bukan
item yang dipesan sebelumnya dari penjualan sebelumnya. Perhatikan bahwa deskripsi use case
meminimalkan deskripsi pekerjaan manual yang dilakukan bersamaan dengan
barang pengiriman. Beberapa analis memasukkan rincian tersebut, namun yang lain tidak melakukannya karena
penekanannya adalah pada interaksi dengan aplikasi komputer. Dalam kasus penggunaan ini,
prasyarat menunjukkan objek apa yang ada harus sudah ada sebelum digunakan
kasus dapat dijalankan. Mereka tidak dapat mengirimkan barang yang bukan merupakan bagian dari penjualan yang sudah ada
pelanggan. Postconditions sekali lagi menunjukkan apa yang harus dicari ketika menyatakan
hasil yang diharapkan untuk kasus uji dan menunjukkan objek yang perlu dikolaborasikan dalam desain.
GAMBAR 5-3 Deskripsi kasus penggunaan yang dikembangkan sepenuhnya untuk item Kapal
Gunakan nama kasus: Kirimkan barang.
Skenario: Kirim item untuk penjualan baru.
Peristiwa pemicu: Pengiriman diberitahukan penjualan baru yang akan dikirimkan.
Deskripsi singkat: Pengiriman mengambil detail penjualan, menemukan setiap item dan mencatat pengirimannya,
mencatat barang mana yang tidak tersedia, dan mengirimkan pengiriman.
Aktor: Petugas Pengiriman.
Kasus penggunaan terkait Tidak ada.
Pemangku kepentingan: Penjualan, Pemasaran, Pengiriman, manajer gudang.
Prasyarat: Pelanggan dan alamat harus ada.

Penjualan harus ada.
Barang penjualan harus ada.
Kondisi pasca: Pengiriman dibuat dan dikaitkan dengan pengirim.

Item penjualan yang dikirim diperbarui saat dikirim dan dikaitkan dengan pengiriman.
Barang yang belum terkirim ditandai sebagai pesanan kembali.
Label pengiriman diverifikasi dan diproduksi.
Alur kegiatan: Aktor Sistem
1. Pengiriman permintaan jual beli 1.1 Sistem mencari penjualan dan

informasi barang. mengembalikan pelanggan, alamat, penjualan,
dan informasi barang penjualan.
2. Pengiriman menugaskan pengirim. 2.1 Sistem membuat pengiriman dan

mengaitkannya dengan pengirim.
3. Untuk setiap item yang tersedia, pengiriman 3.1 Sistem memperbarui item penjualan sebagai
item catatan dikirim. dikirimkan dan dikaitkan dengannya
pengiriman.
4. Untuk setiap item yang tidak tersedia, 4.1 Sistem memperbarui item penjualan sebagai
catatan pengiriman pesanan kembali. pada pesanan kembali.
5. Pengiriman meminta label pengiriman 5.1 Sistem menghasilkan label pengiriman

menyediakan ukuran paket dan untuk pengiriman.
berat. 5.2 Sistem mencatat biaya pengiriman.
Pengecualian 2.1 Pengirim tidak tersedia untuk lokasi tersebut, jadi pilih yang lain.
kondisi: 3.1 Jika barang pesanan rusak, dapatkan barang baru dan perbarui jumlah barang.
3.1 Jika kode batang barang tidak dipindai, pengiriman harus memasukkan kode batang secara manual.
5.1 Jika label pencetakan tidak tercetak dengan benar, label harus diberi alamat
secara manual.
Diagram Aktivitas untuk Use Case Cara lain untuk
mendokumentasikan use case adalah dengan diagram aktivitas. Di Bab 2, Anda mempelajari
diagram aktivitas sebagai bentuk diagram alur kerja. Anda mempelajari bahwa diagram aktivitas
adalah diagram yang mudah dipahami untuk mendokumentasikan alur kerja proses bisnis.
Diagram aktivitas adalah diagram UML standar, dan juga merupakan teknik efektif untuk
mendokumentasikan aliran aktivitas untuk setiap use case.
Gambar 5-4 adalah diagram aktivitas yang mendokumentasikan alur aktivitas untuk kasus
penggunaan Buat akun pelanggan. Terkadang, diagram aktivitas dapat menggantikan bagian
alur aktivitas dalam deskripsi use case, dan terkadang, dibuat untuk melengkapi deskripsi use
case. Terdapat dua jalur renang: satu untuk pelanggan dan satu lagi untuk sistem. Pelanggan
memiliki tiga aktivitas, dan sistem memiliki lima aktivitas.
Diagram aktivitas berguna ketika aliran aktivitas untuk use case rumit. Kasus penggunaan
Isi keranjang belanja rumit karena tiga kasus penggunaan lainnya mungkin dipanggil saat
menambahkan item ke keranjang belanja. Misalnya, aktor mungkin mencari suatu produk dan
kemudian melihat ulasan produk sebelum menambahkan item tersebut ke keranjang. Setelah
item ditambahkan, aktor mungkin mencari dan melihat aksesori yang tersedia lalu menambahkan
satu atau lebih ke keranjang.
GAMBAR 5-4
Diagram aktivitas untuk Membuat akun Pelanggan Sistem
pelanggan menunjukkan cara alternatif
untuk memodelkan aliran aktivitas
Minta akun Buat pelanggan
Masukkan alamat Buat alamat
Masukkan informasi kredit Buat Akun
Verifikasi informasi kredit
Kembalikan
detail akun
GAMBAR 5-5
Diagram aktivitas untuk Isi keranjang belanja Pelanggan Sistem

menunjukkan pengalaman pengguna yang lebih kaya
Cari produk
Lihatlah ulasan
produk
Pilih opsi dan

kuantitas
Cari dan lihat aksesori

Masukkan ke keranjang
Pilih opsi dan

kuantitas aksesori
Masukkan ke keranjang
Diagram aktivitas yang ditunjukkan pada Gambar 5-5 menunjukkan alur aktivitas use case Isi
keranjang belanja. Oval kuning menunjukkan kasus penggunaan lain yang dipanggil saat
mengisi keranjang belanja. Aktivitas use case berjalan di antara use case lainnya. Kasus
penggunaan Isi keranjang belanja mencakup opsi dan jumlah tertentu, tambahkan ke
keranjang, pilih opsi aksesori dan kuantitas, dan tambahkan ke keranjang.
Namun, maksud dari pengalaman pengguna yang lebih kaya menjadi jelas ketika diagram
aktivitas menunjukkan kasus penggunaan dalam konteks.
Diagram Urutan Sistem—Mengidentifikasi Input dan Output Dalam pendekatan berorientasi
objek, aliran informasi dicapai melalui

diagram urutan sistem (SSD) diagram
yang menunjukkan urutan pesan antara pengiriman pesan ke dan dari aktor atau bolak-balik antar objek internal. Diagram urutan
aktor eksternal dan sistem selama sistem (SSD) digunakan untuk menggambarkan aliran informasi masuk dan keluar dari sistem
kasus penggunaan atau skenario otomatis. Dengan demikian, SSD mendokumentasikan masukan dan keluaran serta
mengidentifikasi interaksi antara aktor dan sistem. SSD adalah jenis diagram interaksi.
diagram interaksi baik diagram
komunikasi maupun diagram urutan yang
menunjukkan interaksi antar objek
Notasi SSD Gambar
5-6 menunjukkan SSD generik. Seperti halnya diagram use case, stick figure mewakili aktor—
seseorang (atau peran) yang berinteraksi dengan sistem. Dalam diagram use case, aktor
“menggunakan” sistem, namun penekanan dalam SSD adalah pada bagaimana aktor “berinteraksi”
dengan sistem dengan memasukkan data masukan dan menerima data keluaran. Kotak berlabel :Sistem
adalah objek yang mewakili keseluruhan sistem otomatis. Di SSD dan semua diagram interaksi
lainnya, analis menggunakan notasi objek, bukan notasi kelas. Dalam notasi objek, kotak mengacu
pada objek individual, bukan kelas dari semua objek serupa. Notasinya hanyalah sebuah persegi
panjang dengan nama objek yang digarisbawahi. Titik dua sebelum nama kelas yang digaris bawahi
adalah bagian notasi objek yang sering digunakan namun opsional.
Dalam diagram interaksi, pesan dikirim dan diterima oleh objek individual, bukan oleh kelas. Dalam
SSD, satu-satunya objek yang disertakan adalah objek yang mewakili keseluruhan sistem.
Di bawah aktor dan :System terdapat garis putus-putus vertikal yang disebut garis hidup.
lifeline atau garis hidup objek garis vertikal di Garis hidup, atau garis hidup objek, hanyalah perpanjangan dari objek tersebut—baik aktor atau objek
bawah suatu objek pada diagram urutan untuk —selama use case. Tanda panah di antara garis hidup mewakili pesan yang dikirimkan oleh aktor.
menunjukkan perjalanan waktu bagi objek tersebut
Setiap anak panah mempunyai asal dan tujuan. Asal pesan adalah aktor atau objek yang
mengirimkannya, seperti yang ditunjukkan oleh garis hidup di ujung panah. Demikian pula, aktor tujuan
atau objek pesan ditunjukkan oleh garis hidup yang disentuh oleh panah. Tujuan dari garis hidup
adalah untuk menunjukkan urutan pesan yang dikirim dan diterima oleh aktor dan objek. Urutan
pesan dibaca dari atas ke bawah dalam diagram.
Sebuah pesan diberi label untuk menjelaskan tujuannya dan data masukan apa pun yang dikirim.
Nama pesan harus mengikuti sintaksis kata kerja-kata benda agar tujuannya jelas. Sintaks label pesan
memiliki beberapa pilihan; bentuk paling sederhana ditunjukkan pada Gambar 5-6. Ingatlah bahwa
panah digunakan untuk mewakili pesan dan memasukkan data. Namun apa yang dimaksud dengan
istilah pesan di sini? Dalam diagram urutan, pesan adalah tindakan yang dijalankan pada objek tujuan,
seperti perintah. Perhatikan pada Gambar 5-6 bahwa pesan masukan disebut inquireOnItem.
GAMBAR 5-6
Contoh diagram urutan sistem Aktor yang Sebuah
(SSD) objek (yang
berinteraksi
dengan sistem digarisbawahi)
mewakili sistem otomatis
:Sistem
Pesan masukan
Staf
inquireOnItem (catalogID, prodID, ukuran) Garis hidup objek; menunjukkan

“urutan” pesan, dari atas ke bawah
informasi barang informasi barang:

deskripsi, harga, kuantitas
Nilai yang dikembalikan
Catatan opsional untuk

menjelaskan sesuatu dalam diagram
Petugas mengirimkan permintaan (pesan) ke sistem untuk mencari suatu barang. Data masukan
yang dikirim bersama pesan terdapat di dalam tanda kurung, dan dalam hal ini adalah data untuk
mengidentifikasi item tertentu. Sintaksnya hanyalah nama pesan diikuti dengan parameter
masukan dalam tanda kurung. Bentuk sintaksis ini dilampirkan pada panah padat.
Nilai yang dikembalikan memiliki format dan arti yang sedikit berbeda. Perhatikan bahwa
panah tersebut adalah panah putus-putus. Panah putus-putus menunjukkan respons atau
jawaban, dan seperti yang ditunjukkan pada gambar, panah tersebut langsung mengikuti pesan
awal. Format labelnya juga berbeda. Karena merupakan respon maka hanya data yang
dikirimkan pada respon saja yang dicatat. Tidak ada pesan yang meminta layanan—hanya data
yang dikembalikan. Dalam hal ini, respons yang valid mungkin berupa daftar semua informasi
yang dikembalikan—misalnya, deskripsi, harga, dan kuantitas suatu barang. Namun, versi
singkatnya juga memuaskan. Dalam hal ini, informasi yang dikembalikan diberi nama informasi
item. Dokumentasi tambahan diperlukan untuk menunjukkan detailnya. Pada Gambar 5-6,
informasi tambahan ini ditampilkan sebagai catatan. Catatan dapat ditambahkan ke diagram
UML mana pun untuk menambahkan penjelasan. Detail informasi item juga dapat
didokumentasikan dalam narasi pendukung atau bahkan hanya direferensikan oleh atribut di
kelas Pelanggan.
Seringkali, pesan yang sama dikirim beberapa kali. Misalnya, ketika seorang aktor
memasukkan item pada pesanan, pesan untuk menambahkan item ke pesanan dapat dikirim
beberapa kali. Gambar 5-7(a) mengilustrasikan notasi untuk menunjukkan operasi berulang ini.
Pesan dan pengembaliannya terletak di dalam persegi panjang yang lebih besar yang disebut
GAMBAR 5-7
Pengulangan pesan dalam (a) notasi bingkai
lingkaran rinci dan (b) notasi alternatif
Kondisi pengujian untuk :Sistem
pengulangan
Staf
Ulangi untuk semua Ulangi semuanya

item addItem (ID item, kuantitas) di persegi panjang
deskripsi, harga, harga diperpanjang
(a) Notasi rinci
:Sistem
Staf
* [item lain] deskripsi, harga, harga tambahan
:= addItem (ID item, jumlah)
(b) Notasi alternatif

notasi bingkai lingkaran pada diagram bingkai lingkaran. Dalam persegi panjang yang lebih kecil di bagian atas bingkai terdapat teks deskriptif
urutan yang menunjukkan pesan berulang untuk mengontrol perilaku pesan dalam persegi panjang yang lebih besar. Perulangan kondisi untuk
semua item menunjukkan bahwa pesan di dalam kotak berulang berkali-kali atau dikaitkan dengan
banyak kejadian.
Gambar 5-7(b) menunjukkan notasi alternatif. Di sini, tanda kurung siku dan teks di dalamnya
kondisi benar/salah bagian pesan antar objek yang disebut kondisi benar/salah untuk pesan tersebut. Tanda bintang (*) sebelum kondisi benar/salah
dievaluasi sebelum transmisi untuk menunjukkan bahwa pesan berulang selama kondisi benar/salah bernilai benar. Analis menggunakan
menentukan apakah pesan dapat dikirim
notasi singkat ini karena beberapa alasan. Pertama, pesan dan data yang dikembalikan dapat ditampilkan
dalam satu langkah.
Perhatikan bahwa data yang dikembalikan diidentifikasi sebagai nilai kembalian di sisi kiri operator
penugasan—tanda :=. Alternatif ini hanya menunjukkan nilai yang dikembalikan.
Kedua, kondisi benar/salah ditempatkan pada pesan itu sendiri. Perhatikan bahwa dalam contoh ini,
kondisi benar/salah digunakan untuk mengontrol perulangan. Kondisi benar/salah juga digunakan untuk
mengevaluasi semua jenis pengujian yang menentukan apakah suatu pesan terkirim. Misalnya,
perhatikan kondisi benar/salah [pembayaran kartu kredit]. Jika benar yang diuji adalah pembayaran
kartu kredit, maka pesan dikirimkan ke sistem untuk memverifikasi nomor kartu kredit. Terakhir, tanda
bintang ditempatkan pada pesan itu sendiri untuk menunjukkan pesan tersebut berulang. Jadi, untuk
pesan berulang yang sederhana, notasi alternatifnya lebih pendek. Namun, jika beberapa pesan
disertakan dalam pengulangan atau terdapat beberapa pesan—masing-masing dengan kondisi benar/
salahnya sendiri—bingkai perulangan akan lebih eksplisit dan tepat.
Berikut notasi lengkap untuk sebuah pesan:
[kondisi benar/salah] nilai kembalian := nama-pesan (daftar parameter)
Bagian mana pun dari pesan dapat dihilangkan. Secara singkat, komponen notasi melakukan hal
berikut: ÿ Tanda
bintang (*) menunjukkan pesan yang berulang atau berulang. ÿ Tanda kurung [ ]
menunjukkan kondisi benar/salah. Ini adalah ujian untuk pesan itu saja. Jika dinilai benar, pesan
akan dikirim. Jika dinilai salah, pesan tidak terkirim.
ÿ Nama pesan adalah deskripsi layanan yang diminta. Ini dihilangkan pada pesan pengembalian
garis putus-putus, yang hanya menampilkan parameter data pengembalian.
ÿ Daftar parameter (dengan dan tanpa tanda kurung saat memulai pesan
tanda kurung pada pesan balasan) menunjukkan data yang dikirimkan bersama pesan tersebut.
ÿ Nilai kembalian pada baris yang sama dengan pesan (wajib :=) yang biasa digunakan
mendeskripsikan data yang dikembalikan dari objek tujuan ke objek sumber sebagai respons
terhadap pesan.
Diagram urutan menggunakan dua bingkai tambahan untuk menggambarkan logika pemrosesan,
notasi bingkai opt pada diagram urutan yang seperti yang ditunjukkan pada Gambar 5-8. Bingkai opt pada Gambar 5-8(a) digunakan ketika sebuah
menampilkan pesan opsional pesan atau serangkaian pesan bersifat opsional atau berdasarkan pada kondisi benar/salah. Bingkai alt
notasi bingkai alt pada diagram urutan yang digunakan dengan logika if-then-else, seperti yang ditunjukkan pada Gambar 5-8(b). Bingkai alt pada
menunjukkan logika if-then-else gambar ini menunjukkan bahwa jika suatu barang dikenakan pajak, maka tambahkan pajak penjualan;
jika tidak, tambahkan kode pembebasan pajak untuk pembebasan pajak penjualan.
Mengembangkan Diagram Urutan Sistem (SSD)

SSD biasanya digunakan bersama dengan deskripsi use case untuk membantu mendokumentasikan
detail satu use case atau skenario dalam use case. Untuk mengembangkan SSD, ada gunanya memiliki
deskripsi rinci tentang kasus penggunaan—baik dalam bentuk yang dikembangkan sepenuhnya atau
sebagai diagram aktivitas. Kedua model ini mengidentifikasi aliran aktivitas dalam use case, namun tidak
secara eksplisit mengidentifikasi input dan output. SSD akan memberikan identifikasi input dan output
secara eksplisit. Salah satu keuntungan menggunakan diagram aktivitas adalah mudahnya
mengidentifikasi kapan suatu masukan atau keluaran terjadi. Input dan output terjadi setiap kali panah
dalam diagram aktivitas berpindah dari aktor eksternal ke sistem komputer.
GAMBAR 5-8
Notasi diagram urutan untuk (a) bingkai opt
dan (b) bingkai alt
:Sistem
Pelanggan
Memilih
[aksesori dipilih]
addAccessory (anAccessory)
rincian tambahan
(a) Notasi bingkai opt
:Sistem
Pegawai sales
alternatif
[barang kena pajak]
addSalesTax (Kode lokasi)
rincian pajak penjualan
[kalau tidak]
tambahkanKode Pembebasan Pajak (eCode)
rincian pembebasan pajak
(b) Notasi bingkai alternatif
Ingat diagram aktivitas untuk Membuat akun pelanggan yang ditunjukkan pada Gambar 5-4.
Ada dua jalur renang: pelanggan dan sistem komputer. Dalam hal ini, batas sistem bertepatan dengan
garis vertikal antara jalur renang pelanggan dan jalur renang sistem komputer.
Pengembangan SSD berdasarkan diagram aktivitas terbagi dalam empat langkah:
1. Identifikasi pesan masukan—Pada Gambar 5-4, terdapat tiga lokasi dengan panah alur kerja
yang melintasi garis batas antara pelanggan dan sistem. Di setiap lokasi di mana alur kerja
melintasi batas otomatisasi, diperlukan input data; oleh karena itu, diperlukan sebuah
pesan.
2. Jelaskan pesan dari aktor eksternal ke sistem dengan menggunakan
notasi pesan yang dijelaskan sebelumnya—Dalam kebanyakan kasus, Anda memerlukan pesan
GAMBAR 5-9
SSD untuk Buat akun pelanggan
kasus penggunaan
:Sistem
Pelanggan
createNewCustomer (nama, telepon, email)
ID khusus, nama, telepon, email
*detail alamat := enterAddress (alamat)
masukkanCreditCard (cc-info)
rincian info kartu kredit
nama yang menggambarkan layanan yang diminta dari sistem dan parameter input
yang diteruskan. Gambar 5-9—SSD untuk kasus penggunaan Buat akun pelanggan
—mengilustrasikan tiga pesan berdasarkan diagram aktivitas. Perhatikan bahwa
nama pesan mencerminkan layanan yang diminta aktor dari sistem: createNewCustomer,
enterAddress, dan enterCreditCard. Nama lain juga bisa digunakan. Misalnya, alih-alih
enterAddress, namanya bisa jadi createAddress. Yang penting adalah nama pesan
menggambarkan layanan yang diminta dari sistem dan berbentuk kata kerja-kata benda.
Informasi lain yang diperlukan adalah daftar parameter untuk setiap pesan.
Menentukan dengan tepat item data mana yang harus diteruskan lebih sulit.
Faktanya, pengembang sering kali menemukan bahwa penentuan parameter data
memerlukan beberapa iterasi sebelum diperoleh daftar yang benar dan lengkap.
Prinsip penting untuk mengidentifikasi parameter data adalah mendasarkannya pada
diagram kelas. Dengan kata lain, atribut yang sesuai dari kelas dicantumkan
sebagai parameter. Melihat atribut, serta pemahaman tentang apa yang perlu dilakukan
sistem, akan membantu Anda menemukan atribut yang tepat.
Dengan pesan pertama yang baru saja disebutkan—createNewCustomer—parameternya
harus mencakup informasi dasar tentang pelanggan, seperti nama, telepon, dan
alamat email. Perhatikan bahwa ketika sistem membuat pelanggan, sistem
menetapkan ID pelanggan baru dan mengembalikannya dengan informasi pelanggan lainnya.
Dalam pesan kedua—enterAddress—parameter diperlukan untuk mengidentifikasi
alamat lengkapnya. Biasanya, itu mencakup alamat jalan, kota, negara bagian, dan
kode pos. SSD menyederhanakan pesan untuk menampilkan alamat sebagai parameter.
Pesan ketiga—berdasarkan diagram aktivitas—masuk ke kartu kredit
informasi. Parameter—cc-info—mewakili nomor akun, tanggal kedaluwarsa, dan
kode keamanan.
3. Identifikasi dan tambahkan kondisi khusus apa pun pada pesan masukan, termasuk
iterasi dan kondisi benar/salah—Dalam hal ini, pesan enterAddress diulangi
untuk setiap alamat yang dibutuhkan pelanggan. Simbol tanda bintang di depan pesan
ditampilkan.
4. Identifikasi dan tambahkan keluaran pesan pengembalian—Ingatlah bahwa ada dua opsi
untuk menampilkan informasi pengembalian: sebagai nilai pengembalian pada pesan
itu sendiri atau sebagai pesan pengembalian terpisah dengan panah putus-putus.
Diagram aktivitas dapat memberikan beberapa petunjuk tentang pesan balik, namun
tidak ada aturan standar yang menyatakan bahwa ketika panah transisi dalam alur
kerja berpindah dari sistem ke aktor eksternal, keluaran selalu terjadi. Pada Gambar
5-4, terdapat tiga anak panah dari swimlane sistem komputer ke swimlane
pelanggan. Pada Gambar 5-9, ini ditampilkan sebagai data kembalian pada garis
putus-putus. Perhatikan bahwa masing-masing diberi nama dengan kata benda yang
menunjukkan apa yang dikembalikan. Terkadang, tidak ada data keluaran yang dikembalikan.
Ingatlah bahwa tujuannya adalah penemuan dan pemahaman, jadi Anda harus bekerja
sama dengan pengguna untuk menentukan dengan tepat bagaimana alur kerja berlangsung
dan informasi apa yang perlu diteruskan dan disediakan sebagai keluaran. Ini adalah proses
berulang, dan Anda mungkin perlu menyempurnakan diagram ini beberapa kali sebelum
diagram tersebut secara akurat mencerminkan kebutuhan pengguna.
Mari kita kembangkan SSD untuk kasus penggunaan item Kapal yang ditunjukkan sebagai
deskripsi kasus penggunaan yang dikembangkan sepenuhnya pada Gambar 5-3. Perhatikan
bahwa aktor memiliki lima langkah bernomor dalam alur aktivitas, sehingga akan ada lima
pesan masukan di SSD seperti yang ditunjukkan pada Gambar 5-10: getNextSale, setShipper,
recordShippedItem, recordBackorder, dan getShippingLabel. Tidak diperlukan parameter untuk
getNextSale karena sistem akan mengembalikan informasi untuk penjualan berikutnya yang
akan dikirimkan. Pengirim dipilih oleh aktor—mungkin dari daftar di formulir atau halaman—
jadi parameternya adalah ID pengirim. Dua pesan diulangi secara berulang: recordShippedItem
dan recordBackorder. Pada SSD ini, notasi frame loop digunakan. Terakhir, pesan
getShippingLabel memerlukan dua parameter: ukuran paket dan berat. Sistem menggunakan
informasi tersebut, beserta pengirim dan alamatnya, untuk membuat label pengiriman dan
mencatat biayanya.
Bagian pertama bab ini telah menjelaskan model yang digunakan dalam pengembangan
berorientasi objek untuk menentukan aspek pemrosesan sistem baru. Deskripsi use case,
seperti yang disediakan oleh narasi tertulis atau diagram aktivitas, memberikan rincian langkah-
langkah internal dalam setiap use case. Pernyataan prakondisi dan pascakondisi membantu
menentukan konteks kasus penggunaan—yaitu, apa yang harus ada sebelum dan sesudah
pemrosesan. Terakhir, SSD menjelaskan input dan output yang terjadi dalam use case.
Bersama-sama, model-model ini memberikan gambaran komprehensif tentang persyaratan
pemrosesan sistem dan memberikan landasan untuk desain sistem.
Sekarang kasus penggunaan telah dijelaskan, mari kita cari tahu cara menangkapnya
informasi status objek penting.
Diagram Mesin Status—Mengidentifikasi Perilaku Objek Terkadang, penting bagi
sistem komputer untuk
memelihara informasi tentang status objek domain yang bermasalah. Misalnya, pelanggan
mungkin ingin mengetahui apakah penjualan tertentu telah dikirimkan atau manajer mungkin
ingin mengetahui apakah penjualan pelanggan telah dibayar. Oleh karena itu, sistem harus
mampu melacak status penjualan pelanggan. Saat menentukan persyaratan, analis perlu
mengidentifikasi dan mendokumentasikan objek domain mana yang memerlukan pemeriksaan
status dan aturan bisnis mana yang menentukan kondisi status valid. Merujuk kembali ke
RMO, contoh aturan bisnis adalah penjualan pelanggan tidak boleh dikirimkan sampai sudah
dibayar.
Kondisi status suatu objek dunia nyata sering disebut sebagai keadaan objek. Didefinisikan
menyatakan suatu kondisi selama masa hidup suatu benda
ketika benda tersebut memenuhi kriteria tertentu, melakukan suatu secara tepat, keadaan suatu benda adalah suatu kondisi yang terjadi selama hidupnya ketika
tindakan, atau menunggu suatu peristiwa memenuhi kriteria tertentu, melakukan suatu tindakan, atau menunggu.
GAMBAR 5-10
SSD untuk kasus penggunaan Item pengiriman
:Sistem
Petugas Pengiriman
dapatkan Penjualan Berikutnya ()
info pelanggan, alamat, penjualan, dan barang penjualan
setShipper (ID pengirim)
Lingkaran
[barang yang dikirim]
catatanItem yang Dikirim (Item penjualan)
Konfirmasi pengiriman
Lingkaran
[item pesanan awal]
catatanBackorder (Item penjualan)
konfirmasi pemesanan di awal
getShippingLabel (ukuran paket, berat)
data label pengiriman
untuk suatu acara. Untuk objek di dunia nyata, kita menyamakan keadaan suatu objek dengan
kondisi statusnya.
Konvensi penamaan kondisi status membantu mengidentifikasi status yang valid. Suatu
negara bagian mungkin memiliki nama kondisi sederhana, seperti On atau In Repair. Negara
bagian lain lebih aktif, dengan nama yang terdiri dari gerund atau frasa kata kerja, seperti
Sedang dikirim atau Bekerja. Misalnya, objek Penjualan tertentu muncul ketika pelanggan
membeli sesuatu. Tepat setelah dibuat, objek mungkin berada dalam keadaan yang disebut
Menambahkan item penjualan baru, kemudian keadaan disebut Menunggu barang dikirim, dan
terakhir, ketika semua barang telah dikirim, keadaan disebut Selesai. Jika Anda mencoba
menggunakan kata benda untuk memberi nama suatu negara, Anda mungkin mempunyai
gagasan yang salah tentang negara bagian atau kelas objek. Nama suatu negara tidak boleh
berupa objek (atau kata benda); itu harus berupa sesuatu yang mendeskripsikan objek (atau
kata benda).
Keadaan digambarkan sebagai kondisi semipermanen karena peristiwa eksternal dapat
mengganggu suatu keadaan dan menyebabkan objek berpindah ke keadaan baru. Sebuah Objek
tetap berada dalam suatu keadaan sampai suatu peristiwa menyebabkannya berpindah, atau
transisi pergerakan suatu benda dari satu keadaan bertransisi, ke keadaan lain. Maka transisi adalah perpindahan suatu benda dari satu keadaan
ke keadaan lain
ke keadaan lain. Transisi adalah mekanisme yang menyebabkan suatu objek meninggalkan
suatu keadaan dan berubah ke keadaan baru. Negara bersifat semipermanen karena transisi
mengganggu dan mengakhirinya. Umumnya, transisi berdurasi singkat—dibandingkan dengan
negara bagian—dan tidak dapat diganggu. Kombinasi negara bagian dan transisi antar negara
bagian menyediakan mekanisme yang digunakan analis untuk menangkap aturan bisnis. Dalam
contoh RMO kami sebelumnya, kami akan mengatakan bahwa penjualan pelanggan harus
dalam keadaan Dibayar sebelum dapat bertransisi ke keadaan Dikirim. Informasi ini ditangkap
dan didokumentasikan dalam diagram UML yang disebut diagram mesin negara.
diagram mesin keadaan diagram yang
menunjukkan kehidupan suatu objek dalam Diagram mesin status dapat dikembangkan untuk setiap kelas domain masalah yang
keadaan dan transisi
memiliki perilaku kompleks atau kondisi status yang perlu dilacak.
Namun, tidak semua kelas memerlukan diagram mesin status. Jika suatu objek di kelas domain
masalah tidak memiliki kondisi status yang harus mengontrol pemrosesan objek tersebut,
diagram mesin keadaan mungkin tidak diperlukan.
Misalnya, dalam diagram kelas RMO, kelas seperti Sale mungkin memerlukan diagram mesin
keadaan. Namun, kelas seperti SaleTransaction mungkin tidak.
Transaksi penjualan terjadi ketika pembayaran dilakukan dan kemudian diam saja; tidak perlu
melacak kondisi lain.
Diagram mesin keadaan terdiri dari oval yang mewakili keadaan suatu objek dan panah
yang mewakili transisi. Gambar 5-11 mengilustrasikan diagram mesin keadaan sederhana untuk
sebuah printer. Karena mempelajari diagram mesin keadaan sedikit lebih mudah dengan
menggunakan benda nyata, kita mulai dengan beberapa contoh perangkat keras komputer.
Setelah dasar-dasarnya dijelaskan, kami akan mengilustrasikan pemodelan objek perangkat
lunak dalam domain masalah. Titik awal diagram mesin keadaan adalah titik hitam, yang disebut
pseudostate titik awal diagram mesin keadaan, keadaan semu. Bentuk pertama setelah titik hitam merupakan keadaan pertama printer. Dalam
ditandai dengan titik hitam hal ini, printer mulai dalam keadaan Mati. Suatu negara bagian diwakili oleh sebuah persegi
panjang dengan sudut membulat (hampir seperti oval tetapi lebih persegi), dengan nama negara
bagian ditempatkan di dalamnya.
Seperti ditunjukkan pada Gambar 5-11, panah yang meninggalkan keadaan Mati disebut
transisi. Pengaktifan transisi menyebabkan objek meninggalkan keadaan Mati dan melakukan
transisi ke keadaan Hidup. Setelah transisi dimulai, transisi berjalan hingga selesai dengan
keadaan tujuan untuk transisi tertentu, membawa objek ke keadaan baru, yang disebut keadaan tujuan. Transisi dimulai dengan tanda
keadaan ke mana suatu objek berpindah setelah panah dari keadaan asal— keadaan sebelum transisi—ke keadaan tujuan, dan diberi label
transisi selesai
dengan string untuk mendeskripsikan komponen transisi.
keadaan asal untuk transisi tertentu, keadaan awal
suatu objek dari mana transisi terjadi Label transisi terdiri dari sintaks berikut dengan tiga komponen:
nama transisi (parameter,…) [kondisi penjaga] / ekspresi tindakan
GAMBAR 5-11
Diagram mesin keadaan sederhana Negara menunjukkan keadaan Nama transisi memiliki nama pemicu, penjaga,
untuk printer keberadaan objek. dan ekspresi tindakan.
onButtonPushed [Penutup pengaman ditutup] / jalankan tes mandiri

Mati Pada
offButtonPushed
Pseudostate awal menunjukkan Transisi memindahkan objek dari keadaan asal

awal diagram mesin keadaan. ke keadaan tujuan.
Pada Gambar 5-11, nama transisinya adalah onButtonPushed. Transisi itu seperti pemicu
yang menyala atau suatu peristiwa yang terjadi. Nama harus mencerminkan tindakan peristiwa
pemicu. Pada Gambar 5-11, tidak ada parameter yang dikirim ke printer.
Kondisi pengamannya adalah [Penutup pengaman tertutup]. Untuk transisi ke api, penjagaannya
harus benar. Garis miring ke depan membagi mekanisme pengaktifan dari tindakan atau proses.
ekspresi tindakan deskripsi aktivitas yang dilakukan Ekspresi tindakan menunjukkan beberapa proses yang harus terjadi sebelum transisi selesai
sebagai bagian dari transisi dan objek tiba di keadaan tujuan. Dalam hal ini, printer akan menjalankan tes mandiri sebelum
masuk ke status Hidup.
Nama transisi adalah nama peristiwa pesan yang memicu transisi dan menyebabkan objek
meninggalkan keadaan asal. Perhatikan bahwa formatnya sangat mirip dengan pesan di SSD.
Faktanya, Anda akan menemukan bahwa nama peristiwa pesan dan nama transisi menggunakan
sintaksis yang hampir sama. Ada hubungan lain antara pesan dan transisi: Transisi disebabkan
oleh pesan yang sampai ke objek. Bagian parameter nama pesan berasal langsung dari
parameter pesan.
guard-condition pengujian benar/salah untuk melihat Kondisi penjagaan adalah kualifikasi atau pengujian pada transisi, dan ini hanyalah kondisi
apakah transisi dapat diaktifkan benar/salah yang harus dipenuhi sebelum transisi dapat diaktifkan. Untuk transisi ke api, pertama-
tama pemicunya harus muncul, lalu penjaganya harus mengevaluasi ke benar. Terkadang,
transisi hanya memiliki kondisi penjagaan dan tidak ada peristiwa pemicu. Dalam hal ini,
pemicunya terus-menerus menyala, dan setiap kali penjaga menjadi benar, transisi terjadi.
Ingat kembali pembahasan diagram urutan bahwa pesan mempunyai pengujian serupa,
yang disebut kondisi benar/salah. Kondisi benar/salah ini merupakan pengujian pada pihak
pengirim pesan, dan sebelum pesan dapat dikirim, kondisi benar/salah harus benar. Sebaliknya,
kondisi penjagaan ada di sisi penerima pesan. Pesan mungkin diterima, namun transisi hanya
terjadi jika kondisi penjagaan juga benar. Kombinasi pengujian, pesan, dan transisi ini
memberikan fleksibilitas luar biasa dalam mendefinisikan perilaku kompleks.
Ekspresi tindakan adalah ekspresi prosedural yang dijalankan ketika transisi diaktifkan. Dengan
kata lain, ini menggambarkan tindakan yang akan dilakukan. Salah satu dari tiga komponen—nama
transisi, kondisi penjaga, atau ekspresi tindakan—mungkin kosong. Jika nama transisi atau kondisi
penjaga kosong, maka secara otomatis bernilai benar. Salah satu dari keduanya mungkin juga rumit,
dengan penghubung AND dan OR.
Keadaan Gabungan dan Konkurensi Sebelum

mengajari Anda cara mengembangkan diagram mesin keadaan, kita perlu memperkenalkan
satu jenis keadaan lain: keadaan gabungan. Di dunia nyata, sangat umum jika suatu objek
berada dalam beberapa keadaan pada saat yang bersamaan. Misalnya, ketika printer pada
Gambar 5-11 dalam keadaan hidup, printer mungkin juga melakukan hal lain.
Terkadang, itu sedang mencetak; terkadang, ia hanya duduk diam; dan saat pertama kali
dinyalakan, ia melewati beberapa langkah pemeriksaan mandiri. Semua kondisi ini terjadi saat
printer hidup, dan dapat dianggap sebagai kondisi yang terjadi secara bersamaan. Kondisi
konkurensi atau keadaan bersamaan kondisi berada di berada di lebih dari satu keadaan pada satu waktu disebut konkurensi, atau keadaan serentak.
lebih dari satu keadaan pada satu waktu Salah satu cara untuk menunjukkan hal ini adalah dengan bilah sinkronisasi dan jalur bersamaan,
seperti dalam diagram aktivitas. Dengan demikian, kita dapat membagi transisi dengan bilah
sinkronisasi sehingga satu jalur menuju ke status Aktif dan jalur lainnya menuju ke status Idle,
jalur serangkaian keadaan dan transisi yang terhubung Printing, dan Selfcheck. Jalur adalah serangkaian keadaan dan transisi yang terhubung secara
secara berurutan berurutan .
Cara lain untuk menunjukkan keadaan serentak adalah dengan membuat keadaan bersarang di dalam keadaan lain,
keadaan komposit keadaan yang mengandung keadaan negara bagian yang tingkatnya lebih tinggi. Negara bagian yang tingkatnya lebih tinggi ini disebut negara bagian gabungan.
dan transisi lain (yaitu, suatu jalur) Keadaan gabungan mewakili tingkat abstraksi yang lebih tinggi dan dapat berisi keadaan
bersarang dan jalur transisi. Gambar 5-12, yang merupakan perpanjangan dari Gambar 5-11,
mengilustrasikan gagasan ini sehubungan dengan printer. Printer tidak hanya berada dalam
kondisi Hidup, namun secara bersamaan juga berada dalam kondisi Idle atau Working. Persegi
panjang bulat untuk keadaan Aktif dibagi menjadi dua kompartemen. Kompartemen paling atas
GAMBAR 5-12
Contoh status gabungan untuk
objek printer Pada
cetak (dokumen)
Menganggur Bekerja
Memuat dan mencetak lembaran
[selesai]
berisi nama, dan kompartemen bawah berisi status bersarang dan jalur transisi.
Ketika printer memasuki keadaan Hidup, maka secara otomatis dimulai dari titik hitam
bertumpuk dan berpindah ke keadaan Idle. Dengan demikian, printer dalam keadaan On dan
Idle. Ketika pesan pencetakan diterima, printer melakukan transisi ke status Bekerja namun juga
tetap dalam status Aktif. Beberapa notasi baru juga diperkenalkan untuk status Kerja. Dalam hal
ini, kompartemen bawah berisi ekspresi tindakan—yaitu, aktivitas yang terjadi saat printer
berada dalam status Bekerja.
Kita dapat memperluas gagasan tentang keadaan gabungan dan konkurensi satu langkah
lebih jauh dengan mengizinkan banyak jalur dalam keadaan gabungan. Mungkin suatu objek
mempunyai seluruh rangkaian keadaan dan transisi—beberapa jalur—yang aktif secara
bersamaan. Untuk mendokumentasikan beberapa jalur secara bersamaan untuk satu objek, kita
menggambar keadaan gabungan dengan bagian bawah dibagi menjadi beberapa kompartemen
— satu untuk setiap jalur perilaku secara bersamaan. Misalnya, bayangkan sebuah printer yang
memiliki tempat masukan untuk menampung kertas. Printer ini juga bergantian antara dua
keadaan dalam siklus kerjanya: Idle dan Working. Kita mungkin ingin menjelaskan dua jalur
terpisah: satu mewakili keadaan baki kertas masukan dan yang lainnya mewakili keadaan
mekanisme pencetakan. Jalur pertama akan memiliki status Kosong, Penuh, dan Rendah. Jalur
kedua akan memiliki status Idle dan Working.
Kedua jalur ini bersifat independen; pergerakan antar negara bagian dalam satu kompartemen
sepenuhnya tidak bergantung pada pergerakan antar negara bagian dalam kompartemen lainnya.
Seperti sebelumnya, ada dua cara untuk mendokumentasikan perilaku bersamaan ini.
Pertama, kita bisa menggunakan bilah sinkronisasi dengan satu jalur menjadi tiga jalur. Kedua,
kita bisa menggunakan keadaan gabungan. Gambar 5-13 memperluas contoh printer dari
Gambar 5-12. Dalam contoh ini, ada dua jalur bersamaan dalam keadaan gabungan. Jalur
bersamaan atas mewakili bagian baki kertas pada printer. Kedua jalur tersebut sepenuhnya
independen, dan printer bergerak melalui status dan transisi di setiap jalur secara independen.
Ketika tombol Off ditekan, printer akan meninggalkan kondisi On.
Tentu saja, ketika printer meninggalkan status Aktif, printer juga meninggalkan semua jalur
dalam status bersarang. Tidak masalah apakah printer sedang dalam keadaan atau sedang
transisi. Bila tombol Mati ditekan, semua aktivitas dihentikan, dan printer keluar dari status Hidup.
Sekarang setelah Anda mengetahui notasi dasar diagram mesin keadaan, kami akan menjelaskan
cara mengembangkan diagram mesin keadaan.
GAMBAR 5-13
Jalur bersamaan untuk printer di
Di negara bagian Pada
padaButtonPushed () mengisi () pesan rendah ()

Mati Kosong Penuh Rendah
mengisi ()
bakiKosong ()
offButtonDidorong () cetak (dokumen)

Menganggur
Bekerja
Memuat dan mencetak lembaran
[selesai]
Aturan untuk Mengembangkan Diagram Mesin Status

Pengembangan diagram mesin negara mengikuti serangkaian aturan. Aturan membantu
Anda mengembangkan diagram mesin status untuk kelas di domain masalah. Biasanya,
tantangan utama dalam membangun diagram mesin keadaan adalah mengidentifikasi
keadaan yang tepat untuk objek tersebut. Mungkin bermanfaat untuk berpura-pura bahwa Anda adalah
Sangat mudah untuk berpura-pura menjadi pelanggan tetapi sedikit lebih sulit untuk mengatakan “Saya
adalah pesanan” atau “Saya adalah kiriman. Bagaimana saya bisa ada? Di negara bagian mana saya
berada?” Namun, jika Anda bisa mulai berpikir seperti ini, ini akan membantu Anda mengembangkan
diagram mesin keadaan.
Area kesulitan utama lainnya bagi analis baru adalah mengidentifikasi dan menangani keadaan
gabungan dengan thread yang bersarang. Biasanya, penyebab utama kesulitan ini adalah kurangnya
pengalaman dalam memikirkan perilaku yang terjadi bersamaan. Solusi terbaiknya adalah dengan
mengingat bahwa mengembangkan diagram mesin keadaan merupakan perilaku berulang—lebih dari
mengembangkan jenis diagram lainnya. Analis jarang mendapatkan diagram mesin negara dengan
benar pada kali pertama. Mereka selalu menggambarnya lalu menyempurnakannya lagi dan lagi. Juga,
ingat bahwa ketika Anda mendefinisikan persyaratan, Anda hanya mendapatkan gambaran umum
tentang perilaku suatu objek. Selama desain, saat Anda membuat diagram urutan terperinci, Anda
akan memiliki kesempatan untuk menyempurnakan dan memperbaiki diagram mesin keadaan penting.
Terakhir, jangan lupa bertanya tentang kondisi pengecualian—terutama saat Anda melihat kata
verifikasi atau periksa. Biasanya, akan ada dua transisi keluar dari negara bagian yang memverifikasi
sesuatu: satu untuk penerimaan dan satu lagi untuk penolakan.
Berikut adalah daftar langkah-langkah yang akan membantu Anda memulai mengembangkan
diagram mesin status:
1. Tinjau diagram kelas dan pilih kelas yang mungkin memerlukan status
diagram mesin—Ingatlah untuk hanya menyertakan kelas-kelas yang memiliki beberapa kondisi
status yang penting untuk dilacak oleh sistem. Kemudian, mulailah dengan kelas-kelas
yang tampaknya memiliki diagram mesin keadaan paling sederhana, seperti kelas SaleItem
untuk RMO, yang akan dibahas nanti.
2. Untuk setiap kelas yang dipilih dalam kelompok, buatlah daftar semua kondisi status yang dapat
Anda identifikasi—Pada titik ini, cukup lakukan brainstorming. Jika Anda bekerja dalam tim,
adakan sesi brainstorming dengan seluruh tim. Ingatlah bahwa keadaan ini harus
mencerminkan keadaan objek dunia nyata yang akan direpresentasikan dalam perangkat
lunak. Terkadang, akan sangat membantu jika memikirkan objek fisik, mengidentifikasi
keadaan objek fisik, dan kemudian menerjemahkan keadaan yang sesuai ke dalam keadaan
sistem atau kondisi status yang sesuai. Dia
juga membantu untuk memikirkan kehidupan objek. Bagaimana hal itu bisa ada dalam sistem?
Kapan dan bagaimana cara menghapusnya dari sistem? Apakah ada status aktif? Apakah ada
status tidak aktif? Apakah ada negara bagian yang menunggunya? Pikirkan aktivitas yang dilakukan
terhadap objek atau oleh objek. Seringkali, objek akan berada dalam keadaan tertentu saat tindakan
ini terjadi.
3. Mulailah membuat fragmen diagram mesin status dengan mengidentifikasi transisi yang menyebabkan
objek meninggalkan status teridentifikasi—Misalnya, jika penjualan berada dalam status Siap
dikirim, transisi seperti startShipping akan menyebabkan penjualan menjadi tinggalkan keadaan itu.
4. Urutkan kombinasi transisi keadaan ini dalam urutan yang benar—Kemudian, gabungkan kombinasi
tersebut menjadi fragmen yang lebih besar. Saat fragmen dikumpulkan menjadi jalur yang lebih
besar, wajar jika kita mulai mencari siklus hidup alami objek tersebut. Lanjutkan membangun jalur
yang lebih panjang dalam diagram mesin negara dengan menggabungkan fragmen.
5. Tinjau kembali jalur-jalur tersebut dan carilah jalur-jalur yang independen dan bersamaan—Kapan an
item bisa berada di dua keadaan secara bersamaan, ada dua kemungkinan. Kedua keadaan tersebut
mungkin berada pada jalur yang independen, seperti pada contoh printer Bekerja dan Penuh. Hal
ini terjadi ketika keadaan dan jalur bersifat independen, dan jalur yang satu dapat berubah tanpa
memengaruhi jalur yang lain. Sebagai alternatif, satu negara bagian bisa menjadi negara bagian
gabungan, sehingga kedua negara bagian tersebut harus disarangkan. Salah satu cara untuk
mengidentifikasi calon negara bagian gabungan adalah dengan menentukan apakah negara bagian
tersebut berbarengan dengan beberapa negara bagian lain dan apakah negara bagian lain tersebut
bergantung pada negara bagian aslinya. Misalnya, keadaan Hidup mempunyai beberapa keadaan
dan jalur lain yang dapat terjadi ketika printer dalam keadaan Hidup, dan keadaan tersebut
bergantung pada printer dalam keadaan Hidup.
6. Carilah transisi tambahan—Seringkali, selama iterasi pertama, beberapa kemungkinan kombinasi
keadaan-transisi-keadaan terlewatkan. Salah satu metode untuk mengidentifikasinya adalah dengan
mengambil setiap kombinasi keadaan yang berpasangan dan menanyakan apakah terdapat
transisi yang valid antar keadaan. Uji transisi di kedua arah.
7. Perluas setiap transisi dengan peristiwa pesan yang sesuai, jaga-

kondisi, dan ekspresi tindakan—Sertakan ekspresi tindakan yang sesuai di setiap negara
bagian. Sebagian besar pekerjaan ini mungkin telah dilakukan saat fragmen diagram mesin
negara sedang dibuat.
8. Tinjau dan uji setiap diagram mesin status—Tinjau setiap status Anda
diagram mesin dengan melakukan hal berikut: a.
Pastikan status Anda benar-benar merupakan status objek di kelas. Pastikan bahwa nama negara
bagian benar-benar menggambarkan keadaan objek, bukan objek itu sendiri.
B. Ikuti siklus hidup suatu objek mulai dari keberadaannya hingga penghapusannya dari sistem.
Pastikan semua kemungkinan kombinasi tercakup dan jalur pada diagram mesin negara akurat.
C. Pastikan diagram Anda mencakup semua kondisi pengecualian serta
aliran perilaku normal yang diharapkan. D.

Cari lagi perilaku bersamaan (banyak jalur) dan kemungkinan jalur bersarang (status gabungan).
Mengembangkan Diagram Mesin Negara RMO Mari kita praktikkan

langkah-langkah ini dengan mengembangkan dua diagram mesin negara untuk RMO.
Langkah pertama adalah meninjau diagram kelas domain dan kemudian memilih kelas yang mungkin
memiliki kondisi status yang perlu dilacak. Dalam hal ini, kami memilih kelas Sale dan SaleItem. Kami
berasumsi bahwa pelanggan ingin mengetahui status penjualan mereka dan status masing-masing item
yang dijual. Kelas lain yang menjadi kandidat untuk diagram mesin negara adalah: InventoryItem, untuk
melacak stok barang yang ada atau habis; Pengiriman, untuk melacak kedatangan; dan mungkin
Pelanggan, untuk melacak pelanggan aktif dan tidak aktif.
Mengembangkan Diagram Mesin Status SaleItem Langkah

pertama dalam mengembangkan diagram mesin status SaleItem adalah mengidentifikasi
kemungkinan kondisi status yang mungkin menarik. Beberapa kondisi status yang
diperlukan adalah Siap dikirim, Dalam pesanan kembali, dan Dikirim. Sebuah pertanyaan
menarik muncul di benak saya saat ini: Bisakah barang penjualan dikirimkan sebagian?
Dengan kata lain, jika pelanggan membeli 10 item tetapi persediaannya hanya lima,
haruskah RMO mengirimkan lima item tersebut dan mengembalikan lima item lainnya ke pesanan se
Anda harus melihat konsekuensi dari keputusan ini. Sistem dan database perlu dirancang untuk
melacak dan memantau informasi rinci untuk mendukung kemampuan ini. Diagram kelas domain
untuk RMO menunjukkan bahwa SaleItem dapat dikaitkan dengan pengiriman nol (belum dikirimkan)
atau satu pengiriman (terkirim seluruhnya). Berdasarkan spesifikasi saat ini, definisi tersebut tidak
mengizinkan pengiriman sebagian SaleItem.
Ini hanyalah contoh lain dari manfaat membangun model. Jika kita tidak mengembangkan
model diagram mesin negara, pertanyaan ini mungkin tidak akan pernah ditanyakan. Pengembangan
model dan diagram rinci adalah salah satu aktivitas terpenting yang dapat dilakukan oleh
pengembang sistem. Hal ini memaksa analis untuk mengajukan pertanyaan mendasar. Terkadang,
pengembang sistem baru berpikir bahwa pengembangan model hanya membuang-buang waktu,
terutama untuk sistem kecil.
Namun, benar-benar memahami kebutuhan pengguna sebelum menulis program selalu menghemat
waktu dalam jangka panjang.
Langkah kedua adalah mengidentifikasi transisi keluar untuk setiap kondisi status. Gambar
5-14 adalah tabel yang menunjukkan negara bagian yang telah ditentukan dan transisi keluar untuk
masing-masing negara bagian tersebut. Satu negara bagian tambahan telah ditambahkan ke daftar
—Baru ditambahkan—yang mencakup kondisi yang terjadi ketika suatu barang telah ditambahkan
ke penjualan tetapi penjualannya belum selesai atau belum dibayar, sehingga barang tersebut
belum siap untuk dikirim.
Langkah ketiga adalah menggabungkan pasangan keadaan-transisi menjadi fragmen-fragmen
dan membangun diagram mesin keadaan dengan keadaan-keadaan dalam urutan yang benar.
Gambar 5-15 mengilustrasikan diagram mesin keadaan yang telah selesai sebagian. Alur dari awal
hingga akhir untuk objek SaleItem cukup jelas. Namun, setidaknya ada satu transisi yang tampaknya
hilang. Harus ada beberapa jalur untuk memungkinkan masuk ke status On back order sehingga
kami menyadari bahwa diagram mesin status potongan pertama ini memerlukan beberapa
penyempurnaan. Kami akan memperbaikinya sebentar lagi.
GAMBAR 5-14 Negara Transisi menyebabkan keluarnya negara

Negara bagian dan transisi keluar untuk
objek Barang Penjualan Baru ditambahkan selesaiMenambahkan
Siap di kirim kan item kapal
Di pesanan belakang barang Tiba
Dikirim Tidak ada transisi keluar yang ditentukan
GAMBAR 5-15
Diagram mesin keadaan parsial untuk
barang Tiba ()
objek Barang Penjualan Di pesanan belakang
selesaiMenambahkan () item kapal ()

Baru ditambahkan Siap di kirim kan Dikirim
Langkah keempat adalah mencari jalur yang bersamaan. Dalam kasus ini, tampaknya objek
SaleItem tidak dapat berada di dua status yang teridentifikasi secara bersamaan. Tentu saja,
karena kami memilih untuk memulai dengan diagram mesin keadaan sederhana, hal itu sudah
diharapkan.
Langkah kelima adalah mencari transisi tambahan. Langkah ini adalah saat kami
menyempurnakan transisi lain yang diperlukan. Penambahan yang pertama adalah adanya
transisi dari Newly Added ke On Back Order. Untuk melanjutkan, periksa setiap pasangan
negara bagian untuk melihat apakah ada kemungkinan kombinasi lainnya. Secara khusus,
carilah transisi mundur. Misalnya, apakah SaleItem dapat berubah dari Siap dikirim ke Dalam
pesanan kembali? Hal ini akan terjadi jika petugas pengiriman menemukan bahwa jumlah
barang di gudang tidak mencukupi, padahal sistem mengindikasikan seharusnya ada. Perulangan
mundur lainnya, seperti dari Dikirim ke Siap dikirim atau dari Dalam pesanan kembali ke Baru
ditambahkan, tidak masuk akal dan tidak disertakan.
Langkah keenam adalah menyelesaikan semua transisi dengan nama, kondisi penjagaan,
dan ekspresi tindakan yang benar. Dua nama transisi baru ditambahkan. Yang pertama adalah
transisi dari titik hitam awal ke keadaan baru ditambahkan.
Transisi tersebut menyebabkan pembuatan—atau, dalam istilah sistem, pembuatan instance—
objek SaleItem baru. Itu diberi nama yang sama dengan pesan ke dalam sistem yang
menambahkannya: addItem(). Transisi terakhir adalah transisi yang menyebabkan item pesanan
dihapus dari sistem. Transisi ini berpindah dari status Dikirim ke titik hitam terakhir yang dilingkari,
yang merupakan status semu terakhir. Dengan asumsi bahwa transisi tersebut diarsipkan ke
pita cadangan ketika dihapus dari sistem yang aktif, transisi tersebut diberi nama archive().
Ekspresi tindakan ditambahkan ke transisi untuk menunjukkan tindakan khusus apa pun
yang dimulai oleh objek atau pada objek. Dalam hal ini, hanya satu tindakan yang diperlukan.
Ketika barang yang Siap dikirim dipindahkan ke Dalam pemesanan kembali, sistem harus
memulai pesanan pembelian baru ke pemasok untuk membeli lebih banyak barang. Jadi, pada
transisi markBackOrdered(), ekspresi tindakan dicatat untuk menempatkan pesanan pembelian.
Gambar 5-16 mengilustrasikan diagram mesin keadaan akhir untuk SaleItem.
Langkah ketujuh—meninjau dan menguji diagram mesin negara—adalah langkah peninjauan

kualitas. Selalu tergoda untuk mengabaikan langkah ini; namun, manajer proyek yang baik
memastikan bahwa analis sistem mempunyai waktu sesuai jadwal untuk melakukan pemeriksaan
kualitas dengan cepat terhadap model mereka. Panduan (seperti dijelaskan dalam Bab 2) pada
tahap proyek ini sangat tepat.
Mengembangkan Diagram Mesin Status Penjualan

Objek Penjualan sedikit lebih kompleks daripada objek SaleItem. Dalam contoh ini, Anda akan
melihat beberapa fitur diagram mesin status yang mendukung objek yang lebih kompleks.
GAMBAR 5-16 Diagram mesin keadaan akhir untuk objek SaleItem
markBackOrdered () barang Tiba ()

Di pesanan belakang
markBackOrdered () /
tempatkan pesanan pembelian
Tambahkan Barang () selesaiMenambahkan () item kapal () arsip ()

Baru ditambahkan Siap di kirim kan Dikirim
GAMBAR 5-17 Negara Keluar dari transisi

Negara bagian dan transisi keluar untuk Dijual
Terbuka untuk penambahan item penjualan lengkap
Siap untuk pengiriman mulaiPengiriman
Dalam pengiriman pengiriman Selesai
Menunggu pesanan kembali kembaliPesanan Tiba
Dikirim pembayaran telah diselesaikan
Tertutup arsip
Gambar 5-17 menunjukkan keadaan yang ditentukan dan transisi keluar yang, pada iterasi
pertama, tampaknya diperlukan. Membaca dari atas ke bawah, negara bagian menggambarkan
siklus hidup penjualan—misalnya, kondisi status. Pertama, Penjualan muncul dan siap untuk
menambahkan item ke dalamnya—status Terbuka untuk penambahan item.
Pengguna di RMO mengindikasikan bahwa mereka ingin Penjualan tetap dalam keadaan ini
selama 24 jam jika pelanggan ingin menambahkan lebih banyak item. Setelah semua item
ditambahkan, Penjualan Siap dikirim. Kedua, masuk ke pengiriman dan berada dalam status
Dalam pengiriman. Pada titik ini, belum jelas bagaimana hubungan Dalam pengiriman dan
Menunggu pesanan kembali. Hubungan tersebut harus diselesaikan seiring dengan pembuatan
diagram mesin negara. Akhirnya, Penjualan Dikirim, dan setelah pembayaran selesai, Ditutup.
Pada langkah ketiga, fragmen dibuat dan digabungkan untuk menghasilkan diagram mesin
keadaan pertama (lihat Gambar 5-18). Diagram mesin negara yang dibuat dari fragmen
tampaknya benar—sebagian besar. Namun, kami mencatat beberapa masalah dengan status
Menunggu pesanan kembali.
Setelah beberapa analisis, kami memutuskan bahwa pesanan Dalam pengiriman dan
Menunggu kembali adalah status yang bersamaan. Dan diperlukan keadaan lain, yang disebut
Sedang Dikirim, ketika petugas pengiriman sedang aktif mengirimkan barang. Salah satu cara
untuk menunjukkan masa berlaku Penjualan adalah dengan memasukkannya ke dalam status
Dalam pengiriman saat pengiriman dimulai. Itu juga memasuki status Dikirim pada saat itu.
Penjualan dapat berputar antara Dikirim dan Menunggu pesanan kembali. Keluarnya keadaan
gabungan hanya terjadi dari keadaan Sedang Dikirim, yaitu di dalam keadaan Dalam Pengiriman.
Jelasnya, setelah meninggalkan keadaan dalam, pesanan juga meninggalkan keadaan pengiriman kompos
Saat kita melewati langkah keempat, kelima, dan keenam, kita melihat bahwa transisi baru
harus ditambahkan. Transisi pembuatan dari keadaan semu awal diperlukan. Selain itu, transisi
harus disertakan untuk menunjukkan kapan item ditambahkan dan kapan item tersebut dikirim.
Biasanya, kita menempatkan aktivitas perulangan ini pada transisi yang meninggalkan suatu
keadaan dan kembali ke keadaan yang sama. Dalam hal ini, transisi disebut addItem(). Perhatikan
bagaimana ia meninggalkan status Terbuka untuk penambahan item
GAMBAR 5-18
Diagram mesin status bagian pertama
Menunggu kembaliPesanan Tiba ()
untuk Pesanan
pesanan kembali
Terbuka untuk selesaiPenjualan () Siap untuk mulaiPengiriman ()

penambahan item Dalam pengiriman
pengiriman
pengiriman Selesai ()
pembayaranDibersihkan () arsip ()
Dikirim Tertutup
GAMBAR 5-19
Diagram mesin keadaan bagian kedua untuk Tambahkan Barang ()
Memesan
mulaiPenjualan () selesaiPenjualan () Siap untuk

Terbuka untuk penambahan item
pengiriman
mulaiPengiriman ()
Dalam pengiriman
pengirimanCurrent () [ada pesanan di awal] Menunggu

Sedang dikirim
perintah kembali
kembaliPesanan Tiba ()
pengiriman Selesai ()
pembayaranDibersihkan () arsip ()
Dikirim Tertutup
dan kembali ke keadaan yang sama. Gambar 5-19 membawa diagram mesin negara ke tingkat penyelesaian
ini.
Manfaat mengembangkan diagram mesin status untuk objek domain bermasalah adalah membantu
Anda menangkap dan memperjelas aturan bisnis. Dari diagram mesin status, kita dapat melihat bahwa
pengiriman tidak dapat dimulai saat penjualan berada dalam status Buka untuk penambahan item, item baru
tidak dapat ditambahkan ke penjualan setelah ditempatkan dalam status Siap untuk pengiriman, dan
penjualan tidak dianggap terkirim sampai semua barang dikirimkan. Jika penjualan berstatus Dalam
pengiriman, kami mengetahui bahwa penjualan tersebut sedang aktif dikerjakan atau menunggu pesanan
kembali.
Seperti biasa, manfaat pembuatan model yang cermat membantu kita mendapatkan pemahaman
yang benar tentang persyaratan sistem. Sekarang mari kita melihat gambaran besarnya dan melihat
bagaimana model-model yang berbeda cocok satu sama lain.
Mengintegrasikan Model Persyaratan Diagram yang dijelaskan dalam bab ini
memungkinkan analis untuk menentukan secara lengkap persyaratan fungsional sistem. Jika Anda
mengembangkan sistem menggunakan siklus hidup pengembangan sistem air terjun, Anda akan
mengembangkan rangkaian diagram lengkap untuk mewakili semua persyaratan sistem sebelum
melanjutkan dengan desain.
Namun, karena Anda menggunakan pendekatan berulang, Anda hanya akan membuat diagram yang
diperlukan untuk iterasi tertentu. Diagram kasus penggunaan yang lengkap penting untuk mendapatkan
gambaran keseluruhan cakupan sistem baru.
Namun detail pendukung yang disertakan dalam deskripsi use case, diagram aktivitas, dan diagram
sequence sistem hanya perlu dilakukan untuk use case pada iterasi tertentu.
Diagram kelas model domain adalah kasus khusus. Sama seperti diagram use case keseluruhan,
diagram kelas model domain harus selengkap mungkin untuk keseluruhan sistem, seperti yang ditunjukkan
untuk RMO di Bab 4. Jumlah
GAMBAR 5-20
Gunakan Model domain
Hubungan antara model persyaratan
diagram kasus diagram kelas
berorientasi objek
Gunakan Diagram Diagram urutan Diagram mesin

deskripsi kasus aktivitas sistem (SSD) negara
kelas domain masalah untuk sistem memberikan indikator tambahan tentang cakupan total
sistem. Penyempurnaan dan implementasi aktual dari banyak kelas akan menunggu iterasi
selanjutnya, namun model domainnya harus cukup lengkap. Model domain diperlukan untuk
mengidentifikasi semua kelas domain yang diperlukan dalam sistem baru. Model domain juga
digunakan untuk mendesain database.
Sepanjang bab ini, Anda telah melihat bagaimana pembuatan diagram bergantung pada
informasi yang diberikan oleh diagram lain. Anda juga telah melihat bahwa pengembangan
diagram baru sering kali membantu menyempurnakan dan memperbaiki diagram sebelumnya.
Anda juga harus mencatat bahwa pengembangan diagram rinci sangat penting untuk
mendapatkan pemahaman menyeluruh tentang kebutuhan pengguna. Gambar 5-20
mengilustrasikan hubungan utama antara model persyaratan untuk pengembangan berorientasi
objek. Diagram use case dan diagram lain di sebelah kiri digunakan untuk menangkap proses
sistem baru. Diagram kelas dan diagram dependennya menangkap informasi tentang kelas-
kelas untuk sistem baru. Panah padat menunjukkan ketergantungan besar, dan panah putus-
putus menunjukkan ketergantungan kecil. Ketergantungan umumnya mengalir dari atas ke
bawah, namun beberapa anak panah memiliki dua kepala untuk menggambarkan bahwa
pengaruh terjadi dalam dua arah.
Perhatikan bahwa diagram use case dan diagram kelas model domain adalah model utama
yang menjadi sumber informasi bagi orang lain. Anda harus mengembangkan kedua diagram
tersebut selengkap mungkin. Deskripsi rinci—baik dalam format naratif atau diagram aktivitas—
menyediakan dokumentasi internal yang penting tentang kasus penggunaan dan harus
sepenuhnya mendukung diagram kasus penggunaan. Deskripsi internal seperti prakondisi dan
pascakondisi menggunakan informasi dari diagram kelas. Deskripsi rinci ini juga penting untuk
pengembangan diagram urutan sistem. Dengan demikian, deskripsi rinci, diagram aktivitas, dan
diagram urutan sistem semuanya harus konsisten dengan langkah-langkah kasus penggunaan
tertentu. Seiring kemajuan Anda dalam mengembangkan sistem dan terutama saat Anda mulai
melakukan desain sistem secara mendetail, Anda akan menemukan bahwa memahami
hubungan di antara model-model ini merupakan elemen penting dalam kualitas model Anda.
Ringkasan Bab Pendekatan
berorientasi objek untuk pengembangan sistem informasi memiliki Aktivitas internal use case pertama kali dijelaskan
serangkaian diagram dan model tekstual lengkap yang bersama- oleh aliran aktivitas internal. Dimungkinkan untuk memiliki beberapa
sama mendokumentasikan kebutuhan pengguna dan menentukan aliran internal berbeda, yang mewakili skenario berbeda dari kasus
persyaratan sistem. Persyaratan ini ditentukan dengan menggunakan penggunaan yang sama. Dengan demikian, sebuah use case
diagram kelas model domain dan diagram mesin status untuk mungkin memiliki beberapa skenario. Detail ini didokumentasikan
memodelkan domain masalah dan diagram kasus penggunaan, dalam deskripsi use case atau diagram aktivitas.
deskripsi kasus penggunaan atau diagram aktivitas, dan diagram Diagram lain yang memberikan rincian persyaratan pemrosesan
urutan sistem (SSD) untuk memodelkan kasus penggunaan. use case adalah SSD. SSD mendokumentasikan input dan output
sistem. Ruang lingkup
setiap SSD biasanya merupakan use case atau skenario dalam use Diagram kelas model domain terus disempurnakan saat
case. Komponen SSD adalah aktor—aktor yang sama yang diidentifikasi menentukan persyaratan. Perilaku objek domain yang direpresentasikan
dalam kasus penggunaan—dan sistem. Sistem diperlakukan sebagai dalam diagram kelas merupakan aspek persyaratan yang juga dipelajari
kotak hitam di mana pemrosesan internal tidak ditangani. Pesan, yang dan dimodelkan. Diagram mesin keadaan digunakan untuk memodelkan
mewakili masukan, dikirim dari aktor ke sistem. keadaan objek dan transisi keadaan yang terjadi dalam suatu use case.
Pesan keluaran dikembalikan dari sistem ke aktor. Urutan pesan Semua model yang dibahas dalam bab ini saling terkait, dan informasi
ditunjukkan dari atas ke bawah. dalam satu model menjelaskan informasi dalam model lainnya.
Istilah-Istilah Utama
ekspresi tindakan 135 jalur 135

bingkai alternatif 129 postconditions 122 prakondisi
keadaan gabungan 135 122 pseudostate 134
konkurensi, atau keadaan bersamaan 135
negara tujuan 134 skenario atau contoh kasus penggunaan 121
kondisi penjaga 135 diagram negara bagian 132
interaksi 126 garis hidup, atau garis diagram mesin keadaan 134 diagram
hidup objek 127 bingkai lingkaran 129 urutan sistem (SSD) 126
bingkai opt 129 keadaan transisi 134
asal 134 kondisi benar/salah 129
deskripsi kasus penggunaan 121
Tinjau Pertanyaan
1. Model apa yang menggambarkan kasus penggunaan secara lebih rinci proses untuk memperbarui informasi tentang produk
detailnya? tertentu.
2. Dua diagram UML apa yang digunakan untuk memodelkan 12. Apa nama simbol sequence diagram yang digunakan untuk
kelas domain? mewakili perluasan suatu objek sepanjang durasi use
3. Bagian manakah dari deskripsi use case yang juga dapat case?
dimodelkan dengan menggunakan diagram aktivitas? 13. Apa dua cara untuk menampilkan nilai yang dikembalikan pada
4. Jelaskan perbedaan antara use case dan a diagram urutan?
skenario. Berikan contoh spesifik kasus penggunaan dengan 14. Apa dua cara untuk menunjukkan pengulangan pada
beberapa kemungkinan skenario. diagram urutan?
5. Buat daftar bagian atau kompartemen dari deskripsi kasus penggunaan 15. Apa tiga jenis frame yang digunakan pada diagram
yang dikembangkan sepenuhnya. sequence?
6. Bandingkan/kontraskan prakondisi dan pascakondisi. 16. Apa simbol kondisi benar/salah pada diagram barisan?
7. Bandingkan/kontraskan kondisi pasca dan kondisi
pengecualian. 17. Apa saja parameter sebuah pesan?
8. Bandingkan/kontraskan proses bisnis dan alur aktivitas untuk 18. Sebutkan langkah-langkah utama untuk mengembangkan SSD.
suatu use case. Jelaskan bagaimana diagram aktivitas dapat 19. Apa yang dimaksud dengan keadaan objek?
digunakan untuk memodelkan keduanya.
20. Apa yang dimaksud dengan transisi keadaan?
9. Apa tujuan dari SSD? Simbol apa yang digunakan dalam SSD?
21. Saat mempertimbangkan persyaratan, negara bagian dan negara bagian
transisi penting untuk memahami diagram lainnya?
10. Apa saja langkah-langkah yang diperlukan untuk mengembangkan SSD?
11. Tulis pesan SSD lengkap dari aktor ke sistem, dengan aktor 22. Diagram UML apa yang digunakan untuk menunjukkan keadaan
meminta sistem untuk memulai dan transisi suatu objek?
23. Sebutkan unsur-unsur yang membentuk deskripsi transisi. Elemen 26. Apa tujuan dari kondisi penjagaan?
mana yang opsional? 27. Identifikasi model-model yang dijelaskan dalam bab ini dan
24. Apa yang dimaksud dengan keadaan gabungan? Untuk apa ini digunakan? hubungannya satu sama lain.
25. Apa yang dimaksud dengan istilah jalan?
Soal dan Latihan

1. Setelah membaca narasi berikut, lakukan hal berikut: i. polis asuransi. Petugas kemudian memeriksa informasi untuk
Kembangkan memastikan premi terkini dan kebijakan berlaku.
diagram aktivitas untuk setiap skenario. ii. Lengkapi deskripsi

Pelanggan memberikan merek, model, tahun, dan nomor
kasus penggunaan yang dikembangkan sepenuhnya untuk setiap
identifikasi kendaraan (VIN) mobil yang akan ditambahkan. Petugas
skenario.
memasukkan informasi ini, dan sistem memastikan bahwa data
Pasokan Bangunan Berkualitas memiliki dua jenis pelanggan: yang diberikan valid. Selanjutnya, pelanggan memilih jenis
kontraktor dan masyarakat umum. Penjualan untuk masing- pertanggungan yang diinginkan dan besarannya masing-masing.
masingnya sedikit berbeda. Petugas memasukkan informasi, dan sistem mencatatnya
Seorang kontraktor membeli bahan dengan membawanya ke dan memvalidasi jumlah yang diminta terhadap batas polisnya.
meja kasir kontraktor. Petugas memasukkan nama kontraktor ke
Setelah semua cakupan dimasukkan, sistem memastikan cakupan
dalam sistem. Sistem menampilkan informasi kontraktor, termasuk total terhadap semua rentang lainnya, termasuk mobil lain dalam
status kredit saat ini. Petugas kemudian membukakan tiket baru polis. Terakhir, pelanggan harus mengidentifikasi semua pengemudi
(penjualan) untuk kontraktor. Selanjutnya petugas melakukan scan dan persentase waktu mereka mengemudikan mobil. Jika driver baru
pada setiap barang yang akan dibeli. Sistem menemukan harga akan ditambahkan, maka kasus penggunaan lain—Tambahkan
barang dan menambahkan barang tersebut ke tiket. Di akhir driver baru—dipanggil.
pembelian, petugas menunjukkan akhir penjualan. Sistem
membandingkan jumlah total dengan batas kredit kontraktor saat
ini dan, jika dapat diterima, akan menyelesaikan penjualan. Sistem Di akhir proses, sistem memperbarui polis, menghitung
membuat tiket elektronik untuk barang tersebut, dan batas kredit jumlah premi baru, dan mencetak pernyataan polis yang diperbarui
kontraktor dikurangi dengan jumlah penjualan. Beberapa kontraktor untuk dikirimkan ke pemilik polis.
suka menyimpan catatan pembelian mereka, sehingga mereka
meminta agar rincian tiket dicetak. Yang lain tidak tertarik dengan
3. Berdasarkan daftar kelas dan asosiasi berikut untuk sistem asuransi
cetakannya.
mobil sebelumnya, daftarkan prakondisi dan pascakondisi untuk
kasus penggunaan Tambahkan kendaraan baru ke polis yang ada.
Penjualan kepada masyarakat umum cukup dimasukkan ke Kelas dalam sistem: ÿ Polis
dalam mesin kasir, dan tiket kertas dicetak saat barang diidentifikasi. ÿ
Pembayaran bisa dengan uang tunai, cek, atau kartu kredit. Petugas Tertanggung ÿ
harus memasukkan jenis pembayaran untuk memastikan saldo mesin Kendaraan yang
kasir pada akhir shift. Untuk pembayaran kartu kredit, sistem Diasuransikan
mencetak voucher kartu kredit yang harus ditandatangani ÿ Cakupan ÿ Cakupan Standar (mencantumkan pertanggungan
pelanggan. asuransi standar dengan harga berdasarkan kategori
peringkat) ÿ Kendaraan Standar (mencantumkan semua jenis kendaraan yang p
2. Berdasarkan narasi berikut, kembangkan diagram aktivitas atau dibuat)
deskripsi yang dikembangkan sepenuhnya untuk kasus penggunaan Hubungan dalam sistem: ÿ Polis
Tambahkan kendaraan baru ke polis yang ada dalam sistem asuransi mempunyai Tertanggung (one-to-many) ÿ Polis mempunyai
mobil. Kendaraan Tertanggung (one-to-many) ÿ Kendaraan
Seorang pelanggan menelepon petugas di perusahaan
mempunyai Pertanggungan (one-to-many) ÿ
asuransi dan memberikan nomor polisnya. Petugas memasukkan Pertanggungan merupakan jenis Pertanggungan Standar
informasi ini, dan sistem menampilkan informasi dasar ÿ Kendaraan merupakan Kendaraan Standar
GAMBAR 5-21 Diagram mesin status telepon seluler
Dicolokkan
mematikan ()
plugin() cabut ()
Diam Panggilan Menghubungkan

menyalakan ()
Mati
menjawab () Aktif
Berdering
(Pembicaraan)
Tutup Telepon ()
Dibebankan Peringatan rendah Tidak dikenakan biaya
pluggedIn () [1/2 jam]
4. Kembangkan SSD berdasarkan narasi dan diagram aktivitas vii. Bisakah telepon mengubah status baterai ketika seseorang
Anda untuk soal 1. sedang berbicara? Jelaskan gerakan mana yang
diperbolehkan dan mana yang tidak diperbolehkan.
5. Kembangkan SSD berdasarkan narasi atau diagram aktivitas
Anda untuk soal 2. viii. Negara bagian mana yang serentak dengan negara bagian
6. Tinjau diagram mesin negara telepon seluler yang ditunjukkan lain? Buatlah tabel dua kolom yang menunjukkan
negara bagian secara bersamaan.
pada Gambar 5-21 dan kemudian jawablah pertanyaan berikut.
(Perhatikan bahwa telepon ini mempunyai karakteristik yang 7. Berdasarkan uraian pengiriman yang dilakukan oleh Union
tidak ditemukan pada telepon biasa. Dasarkan jawaban Parcel Shipments berikut ini, identifikasi semua negara
Anda hanya pada diagram mesin negara.) bagian dan transisi keluar dan kemudian kembangkan diagram
Saya. Apa yang terjadi dengan menghidupkan mesin negara.
Pengiriman pertama kali dikenali setelah diambil dari
telepon? ii. Di negara bagian mana telepon dihidupkan ketika
dihidupkan? pelanggan. Setelah berada di dalam sistem, ia dianggap aktif
dan dalam perjalanan. Setiap kali melewati pos pemeriksaan,
aku aku aku. Apa tiga cara mematikan telepon? seperti tiba di tujuan perantara, itu dipindai dan catatan dibuat
yang menunjukkan waktu dan tempat pemindaian pos
iv. Bisakah telepon mati di tengah keadaan Aktif (Berbicara)? pemeriksaan. Statusnya berubah ketika ditempatkan di
v. Bagaimana telepon bisa truk pengantar. Masih aktif, tapi sekarang dianggap
masuk ke keadaan Aktif (Berbicara)? vi. Bisakah telepon berstatus pending delivery. Setelah terkirim, statusnya
berubah lagi.
dicolokkan saat
seseorang sedang berbicara?
Dari waktu ke waktu, kiriman mempunyai tujuan di luar memulai prosedur paket yang hilang untuk memulihkan
wilayah yang dilayani oleh Union. Dalam kasus tersebut, Union kerusakan apa pun.
memiliki hubungan kerja dengan layanan kurir lainnya. Setelah 8. Temukan perusahaan di daerah Anda yang berkembang
suatu paket diserahkan kepada kurir lain, maka dicatat telah perangkat lunak. Perusahaan konsultan atau perusahaan dengan
diserahkan. Dalam hal ini, nomor pelacakan kurir baru dicatat (jika banyak staf profesional sistem informasi cenderung lebih teliti
tersedia). Union juga meminta kurir baru untuk memberikan dalam pendekatan mereka terhadap pengembangan sistem.
pemberitahuan perubahan status setelah paket terkirim. Siapkan wawancara. Tentukan pendekatan pengembangan
yang digunakan perusahaan.
Banyak perusahaan masih menggunakan teknik terstruktur
tradisional yang dikombinasikan dengan beberapa
Sayangnya, dari waktu ke waktu, sebuah paket hilang. pengembangan berorientasi objek. Di perusahaan lain, beberapa
Dalam hal ini, ia tetap dalam keadaan aktif selama dua minggu proyek terstruktur, sedangkan proyek lainnya berorientasi objek.
tetapi juga ditandai sebagai salah tempat. Apabila setelah dua Cari tahu jenis pemodelan apa yang dilakukan perusahaan untuk
minggu paket belum juga ditemukan maka dianggap hilang. Pada spesifikasi kebutuhan. Bandingkan temuan Anda dengan
saat itu, pelanggan bisa teknik yang diajarkan dalam bab ini.
Studi kasus
Pertukaran Buku TheEyesHaveIt.com memesan sampai menerima pemberitahuan bahwa buku telah dikirim.
Setelah penjual menerima pemberitahuan bahwa buku yang terdaftar telah
Pertukaran Buku TheEyesHaveIt.com adalah jenis pertukaran e-bisnis yang
terjual, penjual harus memberi tahu pembeli melalui email dalam waktu 48
melakukan bisnis sepenuhnya di Internet. Perusahaan bertindak sebagai
jam bahwa pembelian tersebut dicatat. Pengiriman pesanan harus dilakukan
clearinghouse bagi pembeli dan penjual buku bekas. dalam waktu 24 jam setelah penjual mengirimkan email pemberitahuan.
Penjual mengirimkan pemberitahuan kepada pembeli dan TheEyesHaveIt.com
Untuk menawarkan buku untuk dijual, seseorang harus mendaftar ke
saat pengiriman dilakukan.
TheEyesHaveIt.com. Orang tersebut harus memberikan alamat fisik dan
nomor telepon terkini serta alamat email sewaan saat ini. Sistem kemudian melihat
Setelah menerima kiriman, TheEyesHaveIt.com menyimpan pesanan
mempertahankan akun terbuka untuk orang ini. Akses ke sistem sebagai
dalam status terkirim. Pada akhir setiap bulan, cek dikirimkan ke setiap
penjual adalah melalui portal yang aman dan terautentikasi.
penjual untuk pesanan buku yang tetap dalam status terkirim selama 30
hari. Masa tunggu 30 hari berlaku agar pembeli dapat memberi tahu
Penjual dapat membuat daftar buku di sistem melalui formulir Internet
TheEyesHaveIt.com jika kiriman tidak sampai karena alasan tertentu atau
khusus. Formulir tersebut menanyakan semua informasi terkait tentang
jika kondisi buku tidak sama seperti yang diiklankan.
buku tersebut: kategorinya, kondisi umumnya, dan harga yang diminta.
Seorang penjual dapat mendaftarkan buku sebanyak yang diinginkan.
Sistem memelihara indeks semua buku di sistem sehingga pembeli dapat
Jika mau, pembeli bisa memasukkan kode layanan untuk penjual.
menggunakan mesin pencari untuk mencari buku. Mesin pencari Kode layanan merupakan indikasi seberapa baik penjual dalam melayani
memungkinkan pencarian berdasarkan judul, penulis, kategori, dan kata
pembelian buku. Beberapa penjual sangat aktif dan menggunakan
kunci.
TheEyesHaveIt.com sebagai outlet utama untuk menjual buku. Oleh karena
Orang yang ingin membeli buku datang ke situs tersebut dan mencari
itu, kode layanan merupakan indikator penting bagi calon pembeli.
buku yang diinginkannya. Ketika mereka memutuskan untuk membeli,
mereka harus membuka rekening dengan kartu kredit untuk membayar
Untuk kasus ini, kembangkan diagram berikut:
pembukuan. Sistem menjaga semua informasi ini tetap aman
server. 1. Diagram kelas model domain 2. Daftar
Saat pembelian dilakukan, TheEyesHaveIt.com mengirimkan kasus penggunaan dan diagram kasus penggunaan 3. Deskripsi
pemberitahuan email kepada penjual buku yang dipilih serta informasi yang dikembangkan sepenuhnya untuk dua kasus penggunaan: Tambahkan a
pembayaran. Itu juga menandai buku itu telah terjual. Sistem tetap terbuka penjual dan Catat pesanan buku 4.
Sebuah SSD untuk masing-masing dari dua kasus penggunaan dalam pertanyaan 3
MENJALANKAN STUDI KASUS
Dewan Komunitas Realtors
Sistem Multiple Listing Service memiliki sejumlah kasus penggunaan, ketahui di kantor real estate mana agen tersebut bekerja sebelum
yang Anda identifikasi di Bab 3, dan tiga kelas domain utama, yang meminta informasi agen.
Anda identifikasi di Bab 4: RealEstateOffice, Agen, dan Listing. 2. Untuk kasus penggunaan Buat daftar baru, tulis deskripsi kasus
penggunaan yang dikembangkan sepenuhnya dan gambarkan SSD.
Ingatlah bahwa sistem perlu mengetahui agen mana yang
1. Untuk kasus penggunaan Tambahkan agen ke kantor real estat,
membuat daftar sebelum sistem meminta informasi daftar.
tulis deskripsi kasus penggunaan yang dikembangkan
sepenuhnya dan gambarkan SSD. Tinjau materi kasus di bab
3. Gambarkan diagram mesin status yang menunjukkan status dan
sebelumnya dan ingat kembali bahwa sistem perlu melakukan hal tersebut
transisi untuk objek Listing.
Layanan Perjalanan Liburan Musim Semi 'R' Us
Sistem Layanan Perjalanan Spring Breaks 'R' Us memiliki banyak kasus 2. Untuk kasus penggunaan Tambahkan resor baru, tuliskan secara lengkap
penggunaan dan kelas domain, yang telah Anda identifikasi di Bab 3 mengembangkan deskripsi kasus penggunaan dan menggambar SSD.
dan 4. Tinjau diagram kelas model domain untuk merasakan Tinjau kelas yang terkait dengan resor dalam model domain untuk
kompleksitas beberapa kasus penggunaan. memahami alur aktivitas dan pengulangan yang terlibat.
1. Untuk kasus penggunaan Pesan reservasi, tulis deskripsi kasus

3. Gambarkan diagram aktivitas untuk menunjukkan alur aktivitas
penggunaan yang dikembangkan sepenuhnya, dan gambar SSD.
untuk use case Tambahkan resor baru.
Tinjau kelas yang terkait dengan reservasi dalam model domain
4. Gambarlah diagram mesin status yang menunjukkan status dan
untuk memahami aliran aktivitas dan pengulangan yang terlibat.
transisi untuk objek Reservasi.
Layanan Kurir Di Tempat
Seiring dengan berkembangnya Layanan Kurir On the Spot, Bill cukup jika perangkat digital melakukan sinkronisasi dengan kantor pusat
menyadari bahwa ia dapat memberikan layanan yang jauh lebih baik setiap kali pengambilan atau pengantaran dilakukan. Pada titik waktu
kepada pelanggannya jika ia memanfaatkan beberapa teknologi yang tersebut, jadwal rute dapat diperbarui dengan informasi yang sesuai.
tersedia saat ini. Misalnya, hal ini akan memungkinkan dia untuk terus
berkomunikasi dengan truk pengirimannya, sehingga dapat menghemat Sebelumnya, pelanggan dapat menelepon On the Spot dan
biaya transportasi dan tenaga kerja dengan membuat operasi meminta penjemputan paket atau mengunjungi situs Web perusahaan
penjemputan dan pengantaran menjadi lebih efisien. Ini akan untuk menjadwalkan penjemputan. Setelah pelanggan login, mereka
memungkinkan dia untuk melayani pelanggannya dengan lebih baik. dapat membuka halaman Web yang memungkinkan mereka
Tentu saja, sistem yang lebih canggih akan dibutuhkan, namun memasukkan informasi tentang setiap usia paket, termasuk alamat
konsultan pengembangan Bill telah meyakinkannya bahwa solusi yang “kirim ke”, informasi kategori ukuran dan berat, dan jenis layanan yang
mudah dan tidak terlalu rumit dapat dikembangkan. diminta.
On the Spot menyediakan layanan “tiga jam”, “hari yang sama”, dan
Beginilah cara Bill ingin bisnisnya beroperasi. “semalam”. Untuk memfasilitasi layanan mandiri pelanggan, On the
Setiap truk akan melakukan pengiriman dan penjemputan pagi dan sore Spot tidak memerlukan berat dan ukuran yang pasti, namun terdapat
hari. Setiap pengemudi akan memiliki perangkat digital portabel dengan kategori ukuran dan berat yang telah ditentukan sebelumnya yang
layar sentuh. Pengemudi akan dapat melihat jadwal pengambilan dan dapat dipilih oleh pelanggan.
pengirimannya untuk perjalanan tersebut. (Catatan: Proses ini Setelah pelanggan memasukkan informasi untuk semua paket,
memerlukan kasus penggunaan baru—sesuatu yang diprediksi oleh sistem akan menghitung biaya dan kemudian mencetak label surat dan
metodologi pengembangan Agile akan terjadi.) Namun, karena truk tanda terima. Tergantung pada jenis layanan yang diminta dan
akan sering melakukan kontak dengan kantor pusat melalui akses kedekatan truk pengantar, sistem akan menjadwalkan penjemputan
Internet telepon, jadwal penjemputan/pengiriman dapat diperbarui segera atau penjemputan di kemudian hari pada hari itu. Ini akan
secara nyata waktu—bahkan saat berlari. Daripada mempertahankan menampilkan informasi ini sehingga pelanggan akan segera mengetahui
kontak terus-menerus, Bill memutuskan untuk melakukannya kapan akan mengambil.
(lanjutan di halaman 149)

(lanjutan dari halaman 148)
Mengambil paket adalah proses yang cukup mudah. Namun ada beberapa "disampaikan" itu penting. Biasanya, sebuah paket akan mengikuti semua status,
variasi dalam apa yang akan terjadi tergantung pada informasi apa yang ada di namun karena kecanggihan penjadwalan dan algoritma pengiriman, paket
sistem dan apakah paket tersebut sudah diberi label. Setelah tiba di lokasi kadang-kadang akan diambil dan dikirimkan pada proses pengiriman yang
penjemputan yang dijadwalkan, sistem pengemudi akan menampilkan informasi sama. Bill pun memutuskan untuk menambahkan status “dibatalkan” untuk paket-
paket apa pun yang tersedia untuk pelanggan ini. Jika sistem telah memiliki paket yang dijadwalkan diambil tetapi akhirnya tidak terkirim.
informasi mengenai paket-paket tersebut, pengemudi hanya akan memverifikasi
bahwa informasi yang benar telah ada dalam sistem untuk paket-paket tersebut.
Pengemudi juga dapat melakukan perubahan seperti memperbaiki alamat,
1. Berdasarkan uraian tersebut, kembangkanlah yang berikut ini
menghapus paket, atau menambah paket baru. Jika ini adalah pelanggan tunai,
untuk kasus penggunaan Minta pengambilan paket dan untuk skenario
pengemudi akan mengumpulkan uang dan memasukkannya ke dalam sistem.
pelanggan Web:
Dengan menggunakan printer portabel dari van, pengemudi dapat mencetak
kwitansi untuk pelanggan sesuai kebutuhan. Jika ada paket baru yang tidak ada Saya. Deskripsi kasus penggunaan yang dikembangkan
dalam sistem, pengemudi akan memasukkan informasi yang diperlukan dan juga sepenuhnya ii. Diagram aktivitas
mencetak label surat dengan printer portabelnya.
aku aku aku. Sebuah SSD
Berdasarkan uraian yang sama, kembangkan hal berikut untuk kasus

penggunaan Pickup a package:
Saya. Deskripsi kasus penggunaan yang dikembangkan

Salah satu layanan lain yang dibutuhkan pelanggan adalah dapat melacak
status pengiriman paket mereka. Sistem perlu melacak status suatu paket sejak sepenuhnya ii. Diagram aktivitas
pertama kali “mengetahui” tentang paket tersebut hingga dikirimkan. Status iii. Diagram urutan sistem 2. Kembangkan
seperti “siap diambil”, “diambil”, “tiba di gudang”, “keluar untuk diantar”, dan
diagram mesin keadaan yang menjelaskan semua kemungkinan kondisi status
untuk objek Paket.
Pemantauan Glukosa Waktu Nyata Sistem Medis Sandia

Gambar 5-22 menunjukkan serangkaian kasus penggunaan untuk aktor pasien 1. Kasus penggunaan manakah yang mencakup kasus penggunaan lainnya?
dan dokter. Jawablah pertanyaan berikut dan/atau selesaikan latihan berikut: Ubah diagram untuk memasukkan hubungan yang disertakan.
GAMBAR 5-22 Kasus penggunaan sistem RTGM
Lihat/tanggapi Lihat/tanggapi
peringatan peringatan
Lihat sejarah
Sabar Dokter
Tetapkan
Beri anotasi pada sejarah
kondisi peringatan
Kirim pesan ke dokter Kirim pesan ke pasien
Lihat / dengar Melihat/

pesan dari dokter mendengar pesan
dari pasien
(lanjutan di halaman 150)

(lanjutan dari halaman 149)
2. Pertimbangkan kasus penggunaan Lihat/tanggapi peringatan dan 3. Kembangkan SSD untuk kasus penggunaan Lihat riwayat.
Lihat riwayat. Kedua aktor tersebut sama-sama menggunakan Asumsikan bahwa sistem akan secara otomatis menampilkan
versi terakhir, namun masing-masing memiliki versi berbeda kadar glukosa terkini, yang diperbarui setiap interval lima
mengenai versi pertama. Mengapa para aktor memiliki versi kasus menit secara default. Asumsikan lebih lanjut bahwa pengguna
penggunaan Lihat/tanggapi peringatan yang berbeda? Apakah dapat meminta sistem untuk melihat kadar glukosa selama
diagram akan salah jika setiap aktor memiliki versi kasus jangka waktu yang ditentukan pengguna dan kadar tersebut
penggunaan Lihat riwayatnya sendiri? Mengapa atau mengapa tidak? dapat ditampilkan dalam bentuk tabel atau grafik.
Sumber Daya Lebih Lanjut
Grady Booch, James Rumbaugh, dan Ivar Philippe Kruchten, Proses Terpadu Rasional: Sebuah Pengantar
Jacobson, Panduan Pengguna Bahasa Pemodelan Terpadu. (edisi ke-3). Addison-Wesley, 2005.
Addison-Wesley, 1999.
E. Reed Doke, JW Satzinger, dan SR Williams, Pengembangan Craig Larman, Menerapkan UML dan Pola: Pengantar Analisis
Aplikasi Berorientasi Objek Menggunakan Java. Teknologi Kursus, dan Desain Berorientasi Objek serta Proses Terpadu (edisi
2002. ke-3).
Hans-Erik Eriksson, Magnus Penker, Brian Lyons, dan David Fado, Dewan Prentice, 2005.
Perangkat UML 2. JohnWiley & Putra, 2004. Grup Manajemen Objek, Spesifikasi Superstruktur UML 2.0, 2004.
Martin Fowler, UML Distilled: Panduan Singkat Bahasa
Pemodelan Objek Standar (edisi ke-3). Addison-Wesley, 2004.

BOOK-Systems Analysis and Design in A Changin-147-178

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

BOOK-Systems Analysis and Design in A Changin-147-178

Diunggah oleh

Hak Cipta:

Format Tersedia

Machine Translated by Google

Garis besar bab

ÿ Diagram Aktivitas untuk Kasus Penggunaan

ÿ Diagram Urutan Sistem—Mengidentifikasi Input dan Output

ÿ Diagram Mesin Status—Mengidentifikasi Perilaku Objek

ÿ Mengintegrasikan Model Persyaratan

ÿ Tulis deskripsi kasus penggunaan yang dikembangkan sepenuhnya

ÿ Mengembangkan diagram aktivitas untuk memodelkan alur aktivitas

ÿ Mengembangkan diagram urutan sistem

ÿ Mengembangkan diagram mesin negara untuk memodelkan perilaku objek

120 BAGIAN 2 ÿ Kegiatan Analisis Sistem

Electronics Unlimited: Mengintegrasikan Rantai Pasokan

BAB 5 ÿ Memperluas Model Persyaratan 121

Deskripsi Kasus Penggunaan Daftar kasus

Deskripsi Singkat Use Case Tergantung pada

122 BAGIAN 2 ÿ Kegiatan Analisis Sistem

GAMBAR 5-1 Kasus penggunaan Deskripsi kasus penggunaan singkat

Cari pelanggan Pengguna/pelaku memasukkan nomor rekening pelanggan, dan sistem

Deskripsi Use Case yang Dikembangkan Sepenuhnya

BAB 5 ÿ Memperluas Model Persyaratan 123

Gunakan nama kasus: Buat akun pelanggan.

Skenario: Buat akun pelanggan online.

Peristiwa pemicu: Pelanggan baru ingin membuat akun secara online.

Pemangku kepentingan: Akuntansi, Pemasaran, Penjualan.

Prasyarat: Subsistem akun pelanggan harus tersedia.

Kondisi pasca: Pelanggan harus dibuat dan disimpan.

Alur kegiatan: Aktor Sistem

1. Pelanggan menunjukkan keinginan untuk 1.1 Sistem menciptakan pelanggan baru.

2. Pelanggan memasukkan satu atau lebih 2.1 Sistem membuat alamat.

3. Pelanggan memasukkan kartu kredit/debit 3.1 Sistem membuat akun.

Pengecualian 1.1 Data dasar pelanggan tidak lengkap.

124 BAGIAN 2 ÿ Kegiatan Analisis Sistem

Gunakan nama kasus: Kirimkan barang.

Skenario: Kirim item untuk penjualan baru.

Peristiwa pemicu: Pengiriman diberitahukan penjualan baru yang akan dikirimkan.

Aktor: Petugas Pengiriman.

Kasus penggunaan terkait Tidak ada.

Pemangku kepentingan: Penjualan, Pemasaran, Pengiriman, manajer gudang.

Prasyarat: Pelanggan dan alamat harus ada.

Kondisi pasca: Pengiriman dibuat dan dikaitkan dengan pengirim.

Alur kegiatan: Aktor Sistem

1. Pengiriman permintaan jual beli 1.1 Sistem mencari penjualan dan

2. Pengiriman menugaskan pengirim. 2.1 Sistem membuat pengiriman dan

5. Pengiriman meminta label pengiriman 5.1 Sistem menghasilkan label pengiriman

BAB 5 ÿ Memperluas Model Persyaratan 125

Diagram Aktivitas untuk Use Case Cara lain untuk

Masukkan alamat Buat alamat

Masukkan informasi kredit Buat Akun

Verifikasi informasi kredit

126 BAGIAN 2 ÿ Kegiatan Analisis Sistem

Diagram aktivitas untuk Isi keranjang belanja Pelanggan Sistem

Pilih opsi dan

Cari dan lihat aksesori

Pilih opsi dan

Diagram Urutan Sistem—Mengidentifikasi Input dan Output Dalam pendekatan berorientasi

objek, aliran informasi dicapai melalui

BAB 5 ÿ Memperluas Model Persyaratan 127

Notasi SSD Gambar

inquireOnItem (catalogID, prodID, ukuran) Garis hidup objek; menunjukkan

informasi barang informasi barang:

Nilai yang dikembalikan

Catatan opsional untuk

128 BAGIAN 2 ÿ Kegiatan Analisis Sistem