Dalam suatu proses pengembangan software, analisa dan rancangan telah
merupakan terminologu yang sangat tua. Pada saat masalah ditelusuri dan
spesifikasi dinegosiasikan, dapat dikatakan bahwa kita berada pada tahap
rancangan. merancang adalah menemukan suatu cara untuk menyelesaikan
masalah, salah satu tool/model untuk merancang pengembangan software yang
berbasis object-oriented adalah UML. Alasan mengapa UML digunakan adalah,
pertama, scalability dimana objek lebih mudah dipakai untuk menggambarkan
sistem yang besar dan komplek. Kedua, dynamic modeling, dapat dipakai untuk
pemodelan sistem dinamis dan real time.
Sebagaimana dalam tulisan pertama, penulis menjelaskan konsep mengenai
obyek, OOA&D (Obyek Oriented Analyst/ Design) dan pengenalan UML, maka
dalam tulisan kedua ini lebih ditekankan pada cara bagaimana UML digunakan
dalam merancang sebuah pengembangan software yang disertai gambar atau
contoh dari sebuah aplikasi.
1. Use Case
Sebuah use case menggambarkan suatu urutan interaksi antara satu atau lebih
aktor dan sistem. Dalam fase requirements, model use case mengambarkan
sistem sebagai sebuah kotak hitam dan interaksi antara aktor dan sistem dalam
suatu bentuk naratif, yang terdiri dari input user dan respon-respon sistem.
Setiap use case menggambarkan perilaku sejumlah aspek sistem, tanpa
mengurangi struktur internalnya. Selama pembuatan model use case secara
pararel juga harus ditetapkan obyek-obyek yang terlibat dalam setiap use case.
Perhatikan satu contoh sederhana dari proses perbankan, yaitu mesin teller
otomatis (Automated Teller Machine-ATM) yang memberikan kemudahan pada
customernya untuk mengambil uang dari rekening bank secara langsung. Pada
proses ini terdapat satu aktor, yaitu ATM Customer dan satu use case, yaitu
Penarikan Dana. Proses ini dapat dilihat pada Gambar 1. Use case Penarikan
Dana menggambarkan urutan interaksi antara customer dengan sistem, diawali
ketika customer memasukan kartu ATM ke dalam mesin pembaca kartu dan
akhirnya menerima pengeluaran uang yang dilakukan oleh mesin ATM.
2. Aktor
Sebuah aktor mencirikan suatu bagian outside user atau susunan yang berkaitan
dengan user yang berinteraksi dengan sistem [Rumbaugh, Booch, dan Jacobson
1999]. Dalam model use case, aktor merupakan satu-satunya kesatuan eksternal
yang berinteraksi dengan sistem.
Terdapat beberapa variasi bagaimana aktor dibentuk [Fowler dan Scott 1999].
Sebuah aktor sering kali merupakan manusia (human user). Pada sejumlah
sistem informasi, manusia adalah satu-satunya aktor. Dan mungkin saja dalam
sistem informasi, seorang aktor bisa saja menjadi suatu sistem eksternal. Pada
aplikasi real-time dan distribusi, sebuah aktor bisa saja menjadi satu perangkat
eksternal I/O atau sebuah alat pengatur waktu. Perangkat eksternal I/O dan
pengatur waktu aktor secara khusus lazimnya berada dalam real-time yang
tersimpan dalam sistem (real-time embedded systems), sistem berinteraksi
dengan lingkungan eksternal melalui sensor dan aktuator.
Primary actor (aktor utama) memprakarsai sebuah use case. Jadi, suatu primary
aktor memegang peran sebagai proaktif dan yang memulai aksi dalam sistem.
Aktor lainnya yang berperan sebagai secondary aktor bisa saja terlibat dalam use
case dengan menerima output dan memberikan input. Setidaknya satu aktor
harus mendapatkan nilai dari use case. Biasanya adalah primary aktor (aktor
utama). Bagaimanapun, dalam real-time embedded systems, primary aktor dapat
berperan sebagai perangkat eksternal I/O atau pengatur waktu, penerima utama
dari use case bisa menjadi secondary human aktor yang menerima sejumlah
informasi dari sistem.
fisik dengan sistem. Aktor manusia dapat berinteraksi dengan sistem melalui
perangkat standar I/O, seperti keyboard, display, atau mouse. Aktor manusia
bisa juga berinteraksi dengan sistem melalui perangkat non-standar I/O seperti
bermacam-macam sensor. Dalam keseluruhan hal tersebut, manusia merupakan
aktor dan perangkat I/O adalah bukan aktor.
Perhatikan beberapa contoh human aktor (aktor manusia). Pada sistem
perbankan, satu contoh aktor adalah manusia yang berperan sebagai teller yang
berinteraksi dengan sistem melalui perangkat standar I/O, seperti keyboard,
display, atau mouse. Contoh lainnya adalah manusia yang berperan sebagai
customer yang berinteraksi dengan sistem melalui mesin teller otomatis (ATM).
Dalam hal ini, customer berinteraksi dengan sistem dengan menggunakan
beberapa perangkat I/O, termasuk perangkat pembaca kartu (card reader),
pengeluar uang (cash dispenser), dan pencetak tanda terima (receipt printer),
ditambah lagi keyboard dan display.
Pada beberapa kasus, bagaimana pun juga sebuah aktor bisa saja berupa
perangkat I/O. Hal ini bisa terjadi ketika sebuah use case tidak melibatkan
manusia, seperti yang sering terjadi pada aplikasi-aplikasi real-time. Dalam hal
ini, I/O aktor berinteraksi dengan sistem melalui sebuah sensor. Contoh aktor
yang merupakan perangkat input adalah Arrival Sensor pada Sistem Kontrol
Elevator. Sensor ini mengidentifikasi elevator tersebut pada saat hendak
mencapai lantai dan perlu dihentikan. Kemudian sensor tersebut menginisiasikan
Stop Elevator at Floor use case. Aktor lain dalam Elevator Control System adalah
orang yang berada dalam elevator (human passenger) yang berinteraksi dengan
sistem melalui tombol-tombol nomor pada tingkat lantai dan tombol-tombol
elevator. Input dari aktor secara aktual dideteksi melalui sensor-sensor tombol
lantai dan sensor-sensor tombol elevator berturut-turut.
Aktor dapat pula menjadi sebuah alat pengukur waktu yang secara periodik
mengirimkan pengukuran waktu kejadian (timer events) pada sistem. Use case
secara periodik diperlukan ketika beberapa informasi perlu di-output
oleh sistem pada suatu basis reguler. Hal ini sangat penting dalam sistem-sistem
real-time, dan juga sangat berguna dalam sistem informasi. Walaupun sejumlah
metodologi menganggap pengukur waktu merupakan hal internal bagi sistem,
dan akan lebih berguna dalam desain aplikasi real-time untuk memperhatikan
pengukur-pengukur waktu sebagai eksternal logis bagi sistem dan
menganggapnya sebagai primary aktor yang memulai aksi dalam sistem.
Contohnya, pada sistem monitoring mobil, beberapa use case di-inisialisasi
dengan suatu aktor pengukur waktu. Sebagai contoh dapat dilihat pada Gambar
2. Timer aktor mengawali Calculate Trip Speed use case, yang secara periodik
menghitung rata-rata kecepatan melalui suatu jalan/ jejak dan menampilkan nilai
ini ke driver. Dalam hal ini, pengukur waktu merupakan primary aktor (aktor
utama) dan driver merupakan secondary aktor (aktor kedua)
primary aktor) atau partisipan (sebagai secondary aktor) dalam use case. Satu
contoh aktor sistem eksternal adalah pabrik robot dalam Automation System.
Robot mengawali proses dengan use case Generate Alarm dan Notify, robot
menggerakkan alarm conditions yang dikirim ke operator pabrik yang
berkepentingan, yang telah terdaftar untuk menerima alarms. Dalam use case ini,
robot merupakan primary aktor yang mengawali inisiatif use case, dan operator
merupakan secondary aktor yang menerima alarms.
3. Identifikasi Use Case
Sebuah use case dimulai dengan masukan/input dari seorang aktor. Use case
merupakan suatu urutan lengkap kejadian-kejadian yang diajukan oleh seorang
aktor, dan spesifikasi interaksi antara aktor dengan sistem. Use case yang
sederhana hanya melibatkan satu interaksi/hubungan dengan sebuah aktor, dan
use case yang lebih kompleks melibatkan beberapa interaksi dengan aktor. Use
cases yang lebih kompleks juga melibatkan lebih dari satu aktor.
Untuk menjabarkan use case dalam sistem, sangat baik bila dimulai dengan
memperhatikan aktor dan actions/aksi yang mereka lakukan dalam sistem.
Setiap use case menggambarkan suatu urutan interaksi antara aktor dengan
sistem. Sebuah use case harus memberikan sejumlah nilai pada satu aktor.
Kemudian, kebutuhan fungsional sistem dijelaskan dalam use case yang
merupakan suatu spesifikasi eksternal dari sebuah sistem. Bagaimanapun juga,
ketika membuat use case, sangatlah penting menghindari suatu dekomposisi
fungsional yang dalam beberapa use case kecil lebih menjelaskan fungsi-fungsi
individual sistem daripada menjelaskan urutan kejadian yang memberikan hasil
yang berguna bagi aktor.
Perhatikan lagi contoh pada perbankan. Disamping penarikan melalui ATM, ATM
Customer, aktor juga bisa menanyakan jumlah rekening atau mentransfer dana
antar dua rekening. Karena terdapat fungsi-fungsi yang berbeda yang diajukan
oleh customer dengan hasil-hasil guna yang berbeda, fungsi-fungsi pertanyaan
dan pentransferan harus dibuat sebagai use case yang terpisah, daripada
menjadi bagian dari original use case. Oleh karena itu, customer dapat
mengajukan tiga use case seperti yang dapat dilihat di Gambar. 3; Withdraw
Funds (Penarikan dana), Query Account, dan Transfer Funds (Pentransferan
Dana).
aktor dan sistem. Dan mungkin saja terdapat cabang-cabang urutan use case
utama, yang mengarah pada berkurangnya frekuensi interaksi antara aktor
dengan sistem. Deviasi-deviasi dari urutan utama hanya dilaksanakan pada
beberapa situasi, contohnya jika aktor melakukan kesalahan input pada sistem.
Ketergantungan pada aplikasi kebutuhan, alternatif ini memecahkan use case dan
kadang-kadang bersatu kembali dengan urutan utama. Cabang-cabang alternatif
digambarkan juga dalam use case.
Dalam use case Withdraw Funds, urutan utama adalah urutan tahap-tahap
dalam keberhasilan pelaksanaan penarikan (withdrawal). Cabang-cabang
alternatif digunakan untuk mengarahkan berbagai error cases, seperti ketika
kartu ATM tidak dikenali atau dilaporkan telah hilang dan lain sebagainya.
4. Pendokumentasian Model Use Case
Use case didokumentasi dalam use case model sebagai berikut:
• Use Case Name. Setiap use case diberi nama.
• Summary. Deskripsi singkat use case, biasanya satu atau dua kalimat.
• Dependency. Bagian ini menggambarkan apakah use case yang satu
tergantung pada use case yang lain, dalam arti apakah use case tersebut
termasuk pada use case yang lain atau malah memperluas use case lain.
• Actors. Bagian ini memberikan nama pada actor dalam use case. Selalu
terdapat use case utama (primary use case) yang memulai use case.
Disamping itu terdapat juga secondary use case yang terlibat dalam use
case. Contohnya, dalam use case Withdraw Funds, ATM Customer adalah
actor-nya.
• Preconditions. Satu atau lebih kondisi harus berjalan dengan baik pada
permulaan use case; contohnya mesin ATM yang tidak jalan, menampilkan
pesan Selamat Datang.
• Deskripsi. Bagian terbesar dari use case merupakan deskripsi naratif dari
urutan utama use case yang merupakan urutan yang paling umum dari
interaksi antara aktor dan sistem. Deskripsi tersebut dalam bentuk input
dari aktor, diikuti oleh respon pada sistem. Sistem ditandai dengan sebuah
kotak hitam (black box) yang berkaitan dengan apa yang sistem lakukan
dalam merespon input aktor, bukan bagaimana internal melakukannya.
• Alternatif-alternatif. Deskripsi naratif dari alternatif merupakan cabang
dari urutan utama. Terdapat beberapa cabang alternatif dari urutan
utama. Contohnya, jika rekening customer terdapat dana yang tidak
sesuai, akan tampil permohonan maaf dan menolak kartu.
• Postcondition. Kondisi yang selalu terjadi di akhir use case, jika urutan
utama telah dilakukan; contohnya dana customer telah ditarik.
• Outstanding questions. Pertanyaan-pertanyaan tentang use case
didokumentasikan untuk didiskusikan dengan para user.
merupakan terminologu yang sangat tua. Pada saat masalah ditelusuri dan
spesifikasi dinegosiasikan, dapat dikatakan bahwa kita berada pada tahap
rancangan. merancang adalah menemukan suatu cara untuk menyelesaikan
masalah, salah satu tool/model untuk merancang pengembangan software yang
berbasis object-oriented adalah UML. Alasan mengapa UML digunakan adalah,
pertama, scalability dimana objek lebih mudah dipakai untuk menggambarkan
sistem yang besar dan komplek. Kedua, dynamic modeling, dapat dipakai untuk
pemodelan sistem dinamis dan real time.
Sebagaimana dalam tulisan pertama, penulis menjelaskan konsep mengenai
obyek, OOA&D (Obyek Oriented Analyst/ Design) dan pengenalan UML, maka
dalam tulisan kedua ini lebih ditekankan pada cara bagaimana UML digunakan
dalam merancang sebuah pengembangan software yang disertai gambar atau
contoh dari sebuah aplikasi.
1. Use Case
Sebuah use case menggambarkan suatu urutan interaksi antara satu atau lebih
aktor dan sistem. Dalam fase requirements, model use case mengambarkan
sistem sebagai sebuah kotak hitam dan interaksi antara aktor dan sistem dalam
suatu bentuk naratif, yang terdiri dari input user dan respon-respon sistem.
Setiap use case menggambarkan perilaku sejumlah aspek sistem, tanpa
mengurangi struktur internalnya. Selama pembuatan model use case secara
pararel juga harus ditetapkan obyek-obyek yang terlibat dalam setiap use case.
Perhatikan satu contoh sederhana dari proses perbankan, yaitu mesin teller
otomatis (Automated Teller Machine-ATM) yang memberikan kemudahan pada
customernya untuk mengambil uang dari rekening bank secara langsung. Pada
proses ini terdapat satu aktor, yaitu ATM Customer dan satu use case, yaitu
Penarikan Dana. Proses ini dapat dilihat pada Gambar 1. Use case Penarikan
Dana menggambarkan urutan interaksi antara customer dengan sistem, diawali
ketika customer memasukan kartu ATM ke dalam mesin pembaca kartu dan
akhirnya menerima pengeluaran uang yang dilakukan oleh mesin ATM.
2. Aktor
Sebuah aktor mencirikan suatu bagian outside user atau susunan yang berkaitan
dengan user yang berinteraksi dengan sistem [Rumbaugh, Booch, dan Jacobson
1999]. Dalam model use case, aktor merupakan satu-satunya kesatuan eksternal
yang berinteraksi dengan sistem.
Terdapat beberapa variasi bagaimana aktor dibentuk [Fowler dan Scott 1999].
Sebuah aktor sering kali merupakan manusia (human user). Pada sejumlah
sistem informasi, manusia adalah satu-satunya aktor. Dan mungkin saja dalam
sistem informasi, seorang aktor bisa saja menjadi suatu sistem eksternal. Pada
aplikasi real-time dan distribusi, sebuah aktor bisa saja menjadi satu perangkat
eksternal I/O atau sebuah alat pengatur waktu. Perangkat eksternal I/O dan
pengatur waktu aktor secara khusus lazimnya berada dalam real-time yang
tersimpan dalam sistem (real-time embedded systems), sistem berinteraksi
dengan lingkungan eksternal melalui sensor dan aktuator.
Primary actor (aktor utama) memprakarsai sebuah use case. Jadi, suatu primary
aktor memegang peran sebagai proaktif dan yang memulai aksi dalam sistem.
Aktor lainnya yang berperan sebagai secondary aktor bisa saja terlibat dalam use
case dengan menerima output dan memberikan input. Setidaknya satu aktor
harus mendapatkan nilai dari use case. Biasanya adalah primary aktor (aktor
utama). Bagaimanapun, dalam real-time embedded systems, primary aktor dapat
berperan sebagai perangkat eksternal I/O atau pengatur waktu, penerima utama
dari use case bisa menjadi secondary human aktor yang menerima sejumlah
informasi dari sistem.
Gambar 1. Contoh aktifitas Aktor dan Use Case
Aktor manusia bisa saja menggunakan berbagai perangkat I/O untuk berinteraksifisik dengan sistem. Aktor manusia dapat berinteraksi dengan sistem melalui
perangkat standar I/O, seperti keyboard, display, atau mouse. Aktor manusia
bisa juga berinteraksi dengan sistem melalui perangkat non-standar I/O seperti
bermacam-macam sensor. Dalam keseluruhan hal tersebut, manusia merupakan
aktor dan perangkat I/O adalah bukan aktor.
Perhatikan beberapa contoh human aktor (aktor manusia). Pada sistem
perbankan, satu contoh aktor adalah manusia yang berperan sebagai teller yang
berinteraksi dengan sistem melalui perangkat standar I/O, seperti keyboard,
display, atau mouse. Contoh lainnya adalah manusia yang berperan sebagai
customer yang berinteraksi dengan sistem melalui mesin teller otomatis (ATM).
Dalam hal ini, customer berinteraksi dengan sistem dengan menggunakan
beberapa perangkat I/O, termasuk perangkat pembaca kartu (card reader),
pengeluar uang (cash dispenser), dan pencetak tanda terima (receipt printer),
ditambah lagi keyboard dan display.
Pada beberapa kasus, bagaimana pun juga sebuah aktor bisa saja berupa
perangkat I/O. Hal ini bisa terjadi ketika sebuah use case tidak melibatkan
manusia, seperti yang sering terjadi pada aplikasi-aplikasi real-time. Dalam hal
ini, I/O aktor berinteraksi dengan sistem melalui sebuah sensor. Contoh aktor
yang merupakan perangkat input adalah Arrival Sensor pada Sistem Kontrol
Elevator. Sensor ini mengidentifikasi elevator tersebut pada saat hendak
mencapai lantai dan perlu dihentikan. Kemudian sensor tersebut menginisiasikan
Stop Elevator at Floor use case. Aktor lain dalam Elevator Control System adalah
orang yang berada dalam elevator (human passenger) yang berinteraksi dengan
sistem melalui tombol-tombol nomor pada tingkat lantai dan tombol-tombol
elevator. Input dari aktor secara aktual dideteksi melalui sensor-sensor tombol
lantai dan sensor-sensor tombol elevator berturut-turut.
Aktor dapat pula menjadi sebuah alat pengukur waktu yang secara periodik
mengirimkan pengukuran waktu kejadian (timer events) pada sistem. Use case
secara periodik diperlukan ketika beberapa informasi perlu di-output
oleh sistem pada suatu basis reguler. Hal ini sangat penting dalam sistem-sistem
real-time, dan juga sangat berguna dalam sistem informasi. Walaupun sejumlah
metodologi menganggap pengukur waktu merupakan hal internal bagi sistem,
dan akan lebih berguna dalam desain aplikasi real-time untuk memperhatikan
pengukur-pengukur waktu sebagai eksternal logis bagi sistem dan
menganggapnya sebagai primary aktor yang memulai aksi dalam sistem.
Contohnya, pada sistem monitoring mobil, beberapa use case di-inisialisasi
dengan suatu aktor pengukur waktu. Sebagai contoh dapat dilihat pada Gambar
2. Timer aktor mengawali Calculate Trip Speed use case, yang secara periodik
menghitung rata-rata kecepatan melalui suatu jalan/ jejak dan menampilkan nilai
ini ke driver. Dalam hal ini, pengukur waktu merupakan primary aktor (aktor
utama) dan driver merupakan secondary aktor (aktor kedua)
Gambar 2. Contoh aktor pengukur waktu
Suatu aktor bisa juga menjadi sistem eksternal yang melakukan inisiatif (sebagaiprimary aktor) atau partisipan (sebagai secondary aktor) dalam use case. Satu
contoh aktor sistem eksternal adalah pabrik robot dalam Automation System.
Robot mengawali proses dengan use case Generate Alarm dan Notify, robot
menggerakkan alarm conditions yang dikirim ke operator pabrik yang
berkepentingan, yang telah terdaftar untuk menerima alarms. Dalam use case ini,
robot merupakan primary aktor yang mengawali inisiatif use case, dan operator
merupakan secondary aktor yang menerima alarms.
3. Identifikasi Use Case
Sebuah use case dimulai dengan masukan/input dari seorang aktor. Use case
merupakan suatu urutan lengkap kejadian-kejadian yang diajukan oleh seorang
aktor, dan spesifikasi interaksi antara aktor dengan sistem. Use case yang
sederhana hanya melibatkan satu interaksi/hubungan dengan sebuah aktor, dan
use case yang lebih kompleks melibatkan beberapa interaksi dengan aktor. Use
cases yang lebih kompleks juga melibatkan lebih dari satu aktor.
Untuk menjabarkan use case dalam sistem, sangat baik bila dimulai dengan
memperhatikan aktor dan actions/aksi yang mereka lakukan dalam sistem.
Setiap use case menggambarkan suatu urutan interaksi antara aktor dengan
sistem. Sebuah use case harus memberikan sejumlah nilai pada satu aktor.
Kemudian, kebutuhan fungsional sistem dijelaskan dalam use case yang
merupakan suatu spesifikasi eksternal dari sebuah sistem. Bagaimanapun juga,
ketika membuat use case, sangatlah penting menghindari suatu dekomposisi
fungsional yang dalam beberapa use case kecil lebih menjelaskan fungsi-fungsi
individual sistem daripada menjelaskan urutan kejadian yang memberikan hasil
yang berguna bagi aktor.
Perhatikan lagi contoh pada perbankan. Disamping penarikan melalui ATM, ATM
Customer, aktor juga bisa menanyakan jumlah rekening atau mentransfer dana
antar dua rekening. Karena terdapat fungsi-fungsi yang berbeda yang diajukan
oleh customer dengan hasil-hasil guna yang berbeda, fungsi-fungsi pertanyaan
dan pentransferan harus dibuat sebagai use case yang terpisah, daripada
menjadi bagian dari original use case. Oleh karena itu, customer dapat
mengajukan tiga use case seperti yang dapat dilihat di Gambar. 3; Withdraw
Funds (Penarikan dana), Query Account, dan Transfer Funds (Pentransferan
Dana).
Gambar 3: Aktor dan use case dalam sistem Bank
Urutan utama use case menjelaskan urutan interaksi yang paling umum antaraaktor dan sistem. Dan mungkin saja terdapat cabang-cabang urutan use case
utama, yang mengarah pada berkurangnya frekuensi interaksi antara aktor
dengan sistem. Deviasi-deviasi dari urutan utama hanya dilaksanakan pada
beberapa situasi, contohnya jika aktor melakukan kesalahan input pada sistem.
Ketergantungan pada aplikasi kebutuhan, alternatif ini memecahkan use case dan
kadang-kadang bersatu kembali dengan urutan utama. Cabang-cabang alternatif
digambarkan juga dalam use case.
Dalam use case Withdraw Funds, urutan utama adalah urutan tahap-tahap
dalam keberhasilan pelaksanaan penarikan (withdrawal). Cabang-cabang
alternatif digunakan untuk mengarahkan berbagai error cases, seperti ketika
kartu ATM tidak dikenali atau dilaporkan telah hilang dan lain sebagainya.
4. Pendokumentasian Model Use Case
Use case didokumentasi dalam use case model sebagai berikut:
• Use Case Name. Setiap use case diberi nama.
• Summary. Deskripsi singkat use case, biasanya satu atau dua kalimat.
• Dependency. Bagian ini menggambarkan apakah use case yang satu
tergantung pada use case yang lain, dalam arti apakah use case tersebut
termasuk pada use case yang lain atau malah memperluas use case lain.
• Actors. Bagian ini memberikan nama pada actor dalam use case. Selalu
terdapat use case utama (primary use case) yang memulai use case.
Disamping itu terdapat juga secondary use case yang terlibat dalam use
case. Contohnya, dalam use case Withdraw Funds, ATM Customer adalah
actor-nya.
• Preconditions. Satu atau lebih kondisi harus berjalan dengan baik pada
permulaan use case; contohnya mesin ATM yang tidak jalan, menampilkan
pesan Selamat Datang.
• Deskripsi. Bagian terbesar dari use case merupakan deskripsi naratif dari
urutan utama use case yang merupakan urutan yang paling umum dari
interaksi antara aktor dan sistem. Deskripsi tersebut dalam bentuk input
dari aktor, diikuti oleh respon pada sistem. Sistem ditandai dengan sebuah
kotak hitam (black box) yang berkaitan dengan apa yang sistem lakukan
dalam merespon input aktor, bukan bagaimana internal melakukannya.
• Alternatif-alternatif. Deskripsi naratif dari alternatif merupakan cabang
dari urutan utama. Terdapat beberapa cabang alternatif dari urutan
utama. Contohnya, jika rekening customer terdapat dana yang tidak
sesuai, akan tampil permohonan maaf dan menolak kartu.
• Postcondition. Kondisi yang selalu terjadi di akhir use case, jika urutan
utama telah dilakukan; contohnya dana customer telah ditarik.
• Outstanding questions. Pertanyaan-pertanyaan tentang use case
didokumentasikan untuk didiskusikan dengan para user.
0 komentar:
Posting Komentar