Machine Translated by Google
Fakultas Sains dan Teknologi
CBOP3103
Pendekatan Berorientasi Objek
dalam Pengembangan Perangkat Lunak
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
CBOP3103
BERORIENTASI PADA OBJEK
PENDEKATAN DALAM
PERANGKAT LUNAK
PERKEMBANGAN
Karin Kolbe
Dr Geoffrey Phipps
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
Direktur Proyek:
Pengembang:
Prof Dato' Dr Mansor Fadzil
Assoc Prof Dr Norlia T. Goolamally
Universitas Terbuka Malaysia
Karin Kolbe
Dr Geoffrey Phipps
Spirus Pty Ltd
Koordinator:
Dr SL Chung
OUHK
Produksi:
Tim Penerbitan ETPU
Diadaptasi untuk
Universitas Terbuka Malaysia oleh: Assoc Prof Dr Nantha Kumar Subramaniam
Universitas Terbuka Malaysia
Diperiksa oleh:
R Moganadas Ramalingam
Diedit oleh:
Aezi Hani Abd Rasyid
Dikembangkan oleh:
Pusat Desain dan Teknologi Instruksional
Universitas Terbuka Malaysia
Dicetak oleh:
Meteor Dok. Sdn. Bhd.
Lot 47-48, Jalan SR 1/9, Seksyen 9,
Jalan Serdang Raya, Taman Serdang Raya,
43300 Seri Kembangan, Selangor Darul Ehsan
Edisi Pertama, Mei 2008
Edisi Kedua, Desember 2015 (rs)
Hak Cipta © Universitas Terbuka Hong Kong dan Universitas Terbuka Malaysia, Desember 2015,
CBOP3103 Hak
cipta dilindungi undang-undang. Tidak ada bagian dari karya ini yang boleh direproduksi dalam bentuk apa
pun atau dengan cara apa pun tanpa izin tertulis dari Presiden, Universitas Terbuka Malaysia (OUM).
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
Daftar isi
ixxiv
Panduan Kursus
Topik 1 Pengantar Berorientasi Objek 1.1 Pendekatan
Pengembangan Sistem 1.1.1 Pendekatan Prediktif
1
3
1.1.2 Model dan Notasi dalam
3
Pendekatan Prediktif 1.1.3 SDLC Iteratif 1.2 Perancangan Sistem
Berorientasi Objek 1.2.1 Berpikir
4
dalam Objek 1.2.2 Membangun Sistem dari
Objek 1.2.3 Proses Terpadu 1.2.4
5
6
7
Notasi 1.2.5 Apakah Desain Sistem Berorientasi
Objek merupakan Pendekatan
11
Adaptif?
14
1.2.6 Analisis dan Desain
19
11
18
1.3 Pentingnya Desain 1.4 Memulai:
Tahap Awal 1.4.1 Tahap Awal Ringkasan Artefak
Istilah-istilah Utama Referensi
20
21
23
24
28
28
Topik 2 Persyaratan dan Kasus Penggunaan 2.1
Analisis Persyaratan 2.1.1 Tingkatan
dan Jenis Persyaratan 2.1.2 Tantangan Penulisan
Persyaratan 2.2 Pemangku Kepentingan, Pelaku dan
Peran 2.2.1 Jenis Peran 2.2.2 Perbedaan
Peran 2.2.3 Menemukan
Peran 2.3 Penulisan Use Cases
2.3.1 Tujuan dan Tingkatan Use
Case 2.3.2 Format Penulisan
Use Case 2.3.3 Use Case Diagram 2.3.4 Activity
29
30
31
33
36
37
37
39
41
46
Diagram 2.3.5 Potensi Masalah pada Use Case
48
2.3.6 Cara Menangani Ratusan
48
Use Case
49
51
52
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
iv ÿ DAFTAR ISI
2.4 Menangkap Persyaratan Secara Iteratif Ringkasan
53
Istilah-istilah
54
55
Utama Referensi
55
Topik 3 Pemodelan Berorientasi Objek 3.1 Dari Awal
57
hingga Elaborasi 3.2 Use Case Review System
58
Sequence Diagram 3.3 Model Domain 3.4 Kelas Konseptual 3.4.1
Identifikasi Kelas Konseptual
61
62
3.4.2 Masalah dalam Identifikasi
69
Kelas Konseptual 3.4.3 Spesifikasi Kelas Konseptual
70
73
73
3.5 Asosiasi 3.5.1
74
Mengidentifikasi Asosiasi 3.5.2 Multiplisitas
75
3.5.3 Permasalahan
Asosiasi Lainnya
78
79
3.6 Atribut 3.7 Notasi
81
UML, Model dan Metode: Ringkasan Berbagai Perspektif Istilah-istilah
83
Utama Referensi
84
85
85
86
Topik 4 Kasus Penggunaan Lainnya
87
4.1 Kasus Penggunaan yang
Berhubungan 4.1.1 Hubungan Sertakan
89
4.1.2 Hubungan Perluasan 4.1.3 Hubungan
92
Generalisasi 4.2 Menemukan Semua Kasus
94
Penggunaan 4.2.1 Diagram Status
95
4.2.2 Menampilkan Status
96
Super 4.2.3 Buat + Baca + Perbarui +
99
Hapus = CRUD 4.3 Aturan Bisnis 4.4 Pemodelan Lebih Lanjut 4.4.1
Ringkasan Diagram
100
101
Kekokohan Istilah-istilah
103
Utama Referensi
104
113
114
114
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
DAFTAR ISI ÿ v
116
Topik 5 Pemodelan Dinamis 5.1 Model
Perancangan 5.1.1 Kelas versus
Objek 5.1.2 Objek dan Pesan 5.2
Diagram Interaksi 5.2.1 Notasi Diagram
Kolaborasi 5.2.2 Notasi Diagram
Urutan 5.2.3 Perancangan Tanggung Jawab 5.3
117
119
121
123
123
Perancangan Diagram Kelas 5.3.1 Visibilitas
126
5.3 .2 Spesifikasi Atribut Lengkap 5.3.3 Asosiasi
128
5.3.4 Komposisi („Kegunaan a‰
132
134
Hubungan)
134
135
136
5.3.5 Agregasi („Memiliki‰ Hubungan)
5.4 Warisan 5.4.1
Polimorfisme 5.4.2 Kelas
Beton dan Abstrak 5.5 Prinsip Desain 5.5.1 Kopling
5.5.2 Ringkasan Kohesi Istilahistilah Kunci Referensi
137
138
142
142
144
144
146
148
149
149
Studi kasus
150
Jawaban
151
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
vi ÿ DAFTAR ISI
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
PANDUAN KURSUS
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
PANDUAN KURSUS ÿ ix
DESKRIPSI PANDUAN KURSUS
Anda harus membaca ini
Panduan
denganKursus
cermat dari awal hingga akhir. Ini memberi tahu Anda secara
singkat tentang kursus tersebut dan bagaimana Anda dapat mempelajari materi kursus. Ini juga
menunjukkan jumlah waktu yang mungkin Anda habiskan untuk menyelesaikan kursus dengan
Kursus
sukses. Silakan terus mengacu pada
Memandu saat Anda mempelajari materi kursus karena ini akan membantu Anda memperjelas
komponen atau poin pelajaran penting yang mungkin Anda lewatkan atau abaikan.
PERKENALAN
CBOP3103 Pendekatan Berorientasi Objek dalam Pengembangan Perangkat Lunak merupakan
salah satu mata kuliah yang ditawarkan oleh Fakultas Sains dan Teknologi Open University
Malaysia (OUM). Kursus ini bernilai 3 jam kredit dan harus dibahas selama 8 hingga 15 minggu.
KEPADA SIAPA KURSUS INI DITARGETKAN?
Mata kuliah ini ditujukan untuk seluruh mahasiswa IT khususnya yang mengambil spesialisasi
Sistem Komputer atau Sistem Informasi yang perlu memahami bagaimana perangkat lunak
dikembangkan dengan menggunakan pendekatan berorientasi objek. Siswa yang terdaftar di
spesialisasi terkait TI lainnya juga akan merasakan manfaat kursus ini karena kursus ini akan
menjawab banyak pertanyaan mereka mengenai pengembangan sistem berorientasi objek.
JADWAL BELAJAR
Ini adalah praktik standar OUM bahwa pelajar mengumpulkan 40 jam belajar untuk setiap jam
kredit. Dengan demikian, untuk kursus tiga jam kredit, Anda diharapkan menghabiskan 120 jam
belajar. Tabel 1 memberikan perkiraan bagaimana 120 jam belajar dapat diakumulasikan.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
x ÿ PANDUAN KURSUS
Tabel 1 Estimasi Akumulasi Waktu Jam Belajar
Kegiatan Belajar
Belajar
Jam
Pelajari secara singkat isi kursus dan berpartisipasi dalam diskusi awal
3
Pelajari modulnya
60
Hadiri 3 hingga 5 sesi tutorial
10
Partisipasi daring
12
Revisi
15
Tugas, Tes, dan Ujian
20
TOTAL JAM BELAJAR
120
HASIL KURSUS
Pada akhir kursus ini, Anda seharusnya mampu:
1. Menjelaskan prinsip dasar orientasi objek;
2. Menjelaskan bagaimana mengembangkan sistem berorientasi objek secara berulang;
3. Menerapkan analisis berorientasi objek, keterampilan desain, dan notasi pada suatu pernyataan
masalah;
4. Membahas penggunaan metodologi dan notasi berorientasi objek selama pengembangan sistem;
5. Menggunakan keterampilan dan teknik yang sesuai untuk menetapkan ruang lingkup dan
persyaratan dokumen;
6. Mengembangkan aktor dan model use case;
7. Buat model domain dengan kelas;
8. Menggambar diagram keadaan dan ketahanan untuk memvalidasi model domain;
9. Menggambar diagram dinamis untuk mengatasi aspek perilaku suatu sistem;
Dan
10. Memahami prinsip desain berorientasi objek yang baik.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
PANDUAN KURSUS ÿ xi
SINOPSIS KURSUS
Kursus ini dibagi menjadi 5 topik. Sinopsis masing-masing topik disajikan di bawah ini:
Topik 1 memperkenalkan dasar-dasar orientasi objek, menempatkannya dalam konteks perkembangan
komputasi selama 40 tahun terakhir.
Topik 2 mengkaji siapa yang akan menjadi pengguna sistem. Kami akan mempelajari pendekatan untuk
memastikan dan menangkap persyaratan sistem.
Topik 3 adalah yang pertama dari empat unit yang dikhususkan untuk berbagai aspek pemodelan objek.
Secara khusus, Topik
adalah3 tentang menentukan objek yang tepat untuk suatu sistem.
Topik 4 melihat lebih dekat persyaratan sistem dan menambahkan informasi ini ke model kami.
Topik 5 adalah tentang mendesain pesan yang dikirim antar objek. Selain itu, Anda juga akan
mempelajari secara detail tentang pewarisan dan konsep terkait lainnya. Prinsip-prinsip desain
berorientasi objek yang baik akan menjadi bagian terakhir dari topik ini.
Akan ada sejumlah bacaan „pendek‰ tambahan untuk topik-topik tertentu seperti yang ditunjukkan
pada tabel di bawah ini. Bacaan ini disediakan sebagai bagian dari paket kursus Anda di myVLE.
Tema
Membaca
Topik 1
Topik 2
• Membaca 2.1 Membaca 2.3 (dapat diunduh dari myVLE) • Satu
bacaan dari bab e-book (perpustakaan digital 24ÿ7)
-
Topik 3
Topik 4
• Satu bacaan dari bab e-book (perpustakaan digital 24ÿ7)
Topik 5
• Dua bacaan dari bab e-book (perpustakaan digital 24ÿ7)
Ada juga satu studi kasus yang disediakan di akhir modul
Siswa wajib membaca bacaan ini karena akan memberi mereka pemahaman yang kuat tentang konsepkonsep tertentu yang berkaitan dengan kursus. Bacaan ini adalah bagian dari silabus. Oleh karena itu,
dapat digunakan untuk ujian dan ujian akhir.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
xii ÿ PANDUAN KURSUS
PANDUAN PENYUSUNAN TEKS
Sebelum Anda mempelajari modul ini, penting bagi Anda untuk memperhatikan susunan
teksnya. Memahami susunan teks akan membantu Anda mengatur pembelajaran mata kuliah
ini secara lebih obyektif dan efektif. Secara umum susunan teks tiap topik adalah sebagai
berikut:
Hasil Pembelajaran: Bagian ini mengacu pada apa yang harus Anda capai setelah Anda
sepenuhnya membahas suatu topik. Saat Anda mempelajari setiap topik, Anda harus sering
mengacu pada hasil pembelajaran ini. Dengan melakukan ini, Anda dapat terus mengukur
pemahaman Anda tentang topik tersebut.
Self-Check: Komponen modul ini disisipkan pada lokasi-lokasi strategis di seluruh modul. Ini
dapat disisipkan setelah satu sub-bagian atau beberapa sub-bagian. Biasanya muncul dalam
bentuk pertanyaan. Ketika Anda menemukan komponen ini, cobalah merenungkan apa yang
telah Anda pelajari sejauh ini. Dengan mencoba menjawab pertanyaan tersebut, Anda
seharusnya dapat mengukur seberapa baik Anda memahami sub-bagiannya. Seringkali,
jawaban atas pertanyaan dapat ditemukan langsung dari modul itu sendiri.
Aktivitas: Seperti Pemeriksaan Mandiri, komponen Aktivitas juga ditempatkan di berbagai
lokasi atau titik di seluruh modul. Komponen ini mungkin mengharuskan Anda menyelesaikan
pertanyaan, mengeksplorasi studi kasus singkat, atau melakukan observasi atau penelitian.
Bahkan mungkin Anda perlu mengevaluasi skenario tertentu. Ketika Anda menemukan suatu
Kegiatan, Anda harus mencoba merefleksikan apa yang telah Anda kumpulkan dari modul
dan menerapkannya pada situasi nyata. Pada saat yang sama, Anda harus melibatkan diri
dalam pemikiran tingkat tinggi yang mengharuskan Anda menganalisis, mensintesis, dan
mengevaluasi, bukan hanya mengingat dan mendefinisikan.
Ringkasan: Anda akan menemukan komponen ini di akhir setiap topik. Komponen ini
membantu Anda merangkum keseluruhan topik. Dengan membaca ringkasannya, Anda
seharusnya dapat mengukur tingkat retensi pengetahuan Anda. Jika Anda menemukan poinpoin dalam ringkasan yang tidak Anda pahami sepenuhnya, ada baiknya Anda meninjau
kembali rincian dalam modul.
Istilah Kunci: Komponen ini dapat ditemukan di akhir setiap topik. Anda harus mempelajari
komponen ini untuk mengingatkan diri Anda tentang istilah atau jargon penting yang digunakan
di seluruh modul. Jika Anda menemukan istilah-istilah di sini yang tidak dapat Anda jelaskan,
Anda harus mencari istilah-istilah tersebut di modul.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
PANDUAN KURSUS ÿ xiii
Referensi: Bagian Referensi adalah tempat daftar buku teks, jurnal, artikel, konten atau sumber
elektronik yang relevan dan berguna dapat ditemukan. Daftar ini dapat muncul di beberapa lokasi
Kursus
seperti di (di bagian Referensi), di akhir setiap topik, atau Panduan
di belakang
modul. Anda dianjurkan
untuk membaca atau merujuk pada sumber yang disarankan untuk memperoleh informasi
tambahan yang diperlukan dan untuk meningkatkan pemahaman Anda secara keseluruhan
tentang kursus tersebut.
METODE PENILAIAN
Silakan merujuk ke myVLE.
PENGGUNAAN STUDI KASUS
Kursus ini menggunakan dua studi kasus yang akan Anda temukan di akhir Topik 1:
• Sistem POS NextGen
• Video Victoria
Studi kasus adalah bentuk pembelajaran dan penilaian yang berguna dan semakin populer di
Fakultas Teknologi Informasi dan Komunikasi Multimedia OUM.
KESIMPULAN
Desain itu sulit. Desain yang baik bahkan lebih sulit dan membutuhkan latihan serta waktu. Berbeda
dengan akuntansi, seringkali terdapat lebih dari satu jawaban yang benar. Jika Anda mengajukan
pertanyaan kepada tutor Anda, mereka mungkin sering menjawab dengan „tergantung‰. Hal ini bisa
sangat membuat frustrasi pada awalnya, namun dengan praktik berulang-ulang dalam studi kasus,
tes mandiri, dan tutorial, Anda akan mendapatkan kepercayaan diri, dan, kami berharap, menikmati
kursus ini. Semoga beruntung!
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
xiv ÿ PANDUAN KURSUS
CATATAN TENTANG PENGEMBANG DAN
PENINJAUAN MODUL INI
Karin Kolbe (BSc, MSc) memiliki pengalaman luas dalam konsultasi dan pelatihan
berorientasi objek. Dia telah menulis dan menyelenggarakan kursus tentang analisis dan
desain berorientasi objek, menulis kasus penggunaan dan kegunaan. Dalam berbagai
aplikasi, termasuk manajemen portofolio, pengendalian lalu lintas jalan raya, kepolisian
dan e-commerce, ia telah bekerja sebagai manajer proyek, analis bisnis, ahli metodologi,
dan manajer program.
Geoffrey Phipps (BSc, PhD) adalah konsultan berpengalaman dan arsitek perangkat
lunak, ahli dalam Java, J2EE, komputasi terdistribusi dan akuntansi investasi pada
Windows NT dan Unix. Tujuannya adalah untuk terus meningkatkan proses perangkat
lunak menggunakan teknologi berorientasi objek dan metrik perangkat lunak.
Nantha Kumar Subramaniam (PhD (CompSc)) telah mereview, memoderasi dan memberi
nilai tambah pada modul ini agar sesuai dengan kebutuhan mahasiswa Open University
Malaysia (OUM). Beliau memiliki pengalaman mengajar dan penelitian yang luas di bidang
analisis dan desain berorientasi objek serta pemrograman berorientasi objek. Dia ikut
menulis modul di bidang ini untuk siswa OUM.
TAN SRI DR ABDULLAH SANUSI (TSDAS) DIGITAL
PERPUSTAKAAN
Perpustakaan Digital TSDAS memiliki beragam sumber daya cetak dan online untuk
digunakan oleh pelajar. Perpustakaan digital lengkap yang dapat diakses melalui portal
OUM ini menyediakan akses ke lebih dari 30 database online yang terdiri dari e-journal, etesis, e-book, dan lainnya. Contoh database yang tersedia adalah EBSCOhost, ProQuest,
SpringerLink, Books24ÿ7, InfoSci Books, Emerald Management Plus dan Ebrary Electronic
Books. Sebagai pembelajar OUM, Anda didorong untuk memanfaatkan sepenuhnya
sumber daya yang tersedia melalui perpustakaan ini.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
Tema
ÿ Pengantar
Berorientasi Objek 1
Perangkat lunak
Perkembangan
HASIL BELAJAR
Pada akhir topik ini, Anda seharusnya mampu:
1. Mendeskripsikan prinsip dasar sistem berorientasi objek;
2. Definisikan istilah air terjun dan iteratif sebagaimana diterapkan pada sistem
perkembangan;
3.
Membedakan metodologi dan notasi;
4. Definisikan UML dan jelaskan cara penggunaannya;
5. Definisikan Unified Process (UP) dan jelaskan cara penggunaannya; Dan
6. Jelaskan keterkaitan fase, disiplin ilmu dan artefak di UP.
ÿ PENDAHULUAN
Selamat datang di Topik 1 kursus Pendekatan Berorientasi Objek CBOP3103 dalam
Pengembangan Perangkat Lunak. Topik ini merupakan pengantar keseluruhan kursus. Kita
akan mulai dengan konsep yang paling penting: apakah benda itu? Sangat penting bagi Anda
untuk memahami konsep suatu benda. Nanti kita akan melihat bagaimana suatu objek
berhubungan dengan suatu kelas.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
2 ÿ TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK
Pada tingkat dasar, objek adalah sekumpulan data beserta beberapa operasi yang dapat
dilakukan pada data tersebut. Contoh objeknya adalah rekening bank. Data tersebut terdiri
dari nomor rekening, nama rekening dan cabang tempat rekening tersebut berada. Operasi
yang dapat dilakukan pada rekening bank antara lain pembukaan rekening, penarikan uang,
penyetoran uang dan pemberian saldo rekening.
Gambar 1.1: Objek rekening bank
Sistem berorientasi objek dapat dipandang sebagai kumpulan objek yang mengirim dan
menerima pesan dari dan ke satu sama lain. Analoginya adalah orang-orang di sebuah kota.
Setiap orang merupakan objek yang mengirim dan menerima pesan ke dan dari orang lain.
Beberapa pesan merupakan permintaan informasi („Berapa nomor telepon Anda?‰),
beberapa pesan memberikan informasi („6685 1234‰) dan pesan lainnya merupakan
permintaan untuk melakukan suatu tugas („Silakan fotokopi halaman ini‰). Seseorang tidak
dapat mengubah data orang lain. Segala perubahan terhadap data dilakukan oleh individu
yang bersangkutan, baik sebagai respons terhadap pesan dari orang lain, maupun karena
keputusan pribadi. Saya tidak bisa mengubah nama Anda, tetapi Anda bisa. Oleh karena
itu, kita masing-masing memiliki data sendiri yang dapat dibagikan atau dirahasiakan. Dalam
kursus ini kami menggunakan studi kasus „Video Victoria‰ yang dapat Anda temukan
dalam topik ini. Silakan lihat studi kasus ini karena kami akan menggunakannya di seluruh modul.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 1
MEMPERKENALKAN
S. BERORIENTASI CT
PERANGKAT LUNAK PERANGKAT
PERKEMBANGAN
PERSYARATAN TERHADAP KEBERATAN
1.1
PERSETUJUAN
Pemburu (
OACHE
(2000) mempertimbangkanada
KE SISTEM
TEMS DE
beberapa diskelebihan o
(seperti
itu airnya
adaptif
pendekatan ini. AContoh dari
semua model) ke sistem des
f aplikasi adaptif
ÿ3
PERKEMBANGAN
MENDAPATKAN
dari hal sebelumnya
aplikasi prediktif pendekatan
menyarankan masuk
gunakan
menandatangani dan mencatat
berorientasi pada hal lain d
proach adalah obje
desain.
Prediksi
ek
saya menyetujui
1.1.1
Satu contohcukup dari
Mengembangkanment
e jenis p
aplikasi rediktif
Kehidupan Cy
siklus (SDLC) t
itu perkenalan
pendekatan adalah dia
th
air terjun
Sistem
dihasilkan menjadi lunak
mesin perangkat lunak
muncul pada
tahun 1970an
S.
Sebuah SDLC
C adalah manajeralat permata fo
kegiatan
atau merencanakan, melaksanakan suatudan mengendalikan
g berbagai
s terlibat dalam pengembangan sistem
t proses. Mo
bijih secara spesifikly, ini adalah
menjadi
serangkaian rekan
esses oleh Brea mengajak mereka d
. Ini menguraikan langkah
s
kegiatan
untuk
SDLC, peran
setiap fase o
demi langkah a
alat untuk proses
yang kompleks
pengelola
dan aktivitas
fase a
yang dipertaruhkan
masing-masing
aktivitas
n setiap aktivitasitas dan d
kiriman e
karakteristik
dari
e
air
terjun
SD
DLC itu e
dia karakter kunci
orang yang lebih tua bermain
diharapkan dari
setiap
ch. Th
dibiarkan sebelummelanjutkan
m
selanjutnya. Itue kelemahan
ch adalah
langkah selesai
untuk pendekatan ini
ke
kami tidak bisaatau memastikan kami
jika sedang
w
membangun
ng yang benar s sistem sampai th dia mengakhiri proses.
Juga, itu
hampir yakin bahwa
akan cha
persyaratan
t selama pengembangan yang panjang operasi
kemarahan.
Gambar 1.2 : Air terjun
Aku mendekati
Hak Cipta © Universitas Terbuka Malaysia (OUM)
cess, proses
Machine Translated by Google
4 ÿ TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK
Pada tahun 1980-an, berbagai pendekatan yang disebut pengembangan cepat, pembuatan
prototipe, atau pengembangan spiral mencoba mengubah pendekatan ini. Semua teknik ini
mempunyai kelebihan, namun juga mempunyai kelemahan sehingga sistem, terutama sistem
besar di organisasi besar (seperti sistem aplikasi perbankan) terus dibangun dengan
pendekatan air terjun.
1.1.2 Model dan Notasi dalam Pendekatan Prediktif
Model adalah analogi yang disederhanakan dari entitas nyata (sistem dalam mata kuliah ini).
Ini bisa berupa dokumen, diagram, atau bahkan model kayu yang memungkinkan kita melihat
detail atau aspek tertentu dari entitas nyata, sambil mengabaikan yang lain. Misalnya, model
kertas sebuah bangunan baru akan menunjukkan ukuran bangunan tersebut dibandingkan
dengan bangunan lainnya. Jika cahaya diberikan, kita bahkan dapat melihat bayangan yang
dihasilkan matahari. Namun, kita tidak akan memiliki banyak gambaran tentang tekstur
bangunan kaca, batu bata, baja, dll.
Pada tahun 1980an, pemodelan aplikasi sebelum mencoba membangunnya menjadi praktik
umum.
Modelnya biasanya dalam salah satu bentuk berikut:
(a) Diagram Hubungan Entitas (ER);
(b) Diagram Aliran Data (DFD); Dan
(c) Diagram alur.
Jangan khawatir jika Anda tidak yakin apa itu, karena saat ini Anda tidak perlu menghadapinya,
terutama dalam proyek pengembangan sistem atau perangkat lunak yang besar. Hal penting
yang perlu diperhatikan adalah model ini memisahkan data dan proses atau fungsi yang
dilakukan pada data selama seluruh proses analisis dan desain. Sistem yang dihasilkan
umumnya sulit dipertahankan seiring berjalannya waktu. Salah satu alasan mengapa
pemeliharaan sulit dilakukan adalah karena semua data dan pemrosesan yang berkaitan
dengan satu entitas dapat tersebar ke seluruh sistem, sehingga perubahan memerlukan
banyak pekerjaan. Misalnya, kita ingin mengubah kolom ID karyawan dari enam menjadi
delapan digit. Ini berarti melihat setiap layar atau laporan untuk melihat dampaknya.
Permasalahan Tahun 2000 adalah contoh lain dimana perhitungan berdasarkan tanggal
tersebar di seluruh sistem, masing-masing perlu diperiksa secara manual. Dari semua model
inilah program kemudian ditulis.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK ÿ 5
Nanti di topik ini dan nanti di kursus ini Anda akan melihat bahwa pemodelan berorientasi objek menyatukan data
dan proses.
Menurut Fowler (2000), keterbatasan utama pendekatan prediktif adalah bahwa pendekatan ini gagal
memperhitungkan perubahan-perubahan yang tidak bisa dihindari dalam jangka waktu proses pembangunan.
Pengembangan berulang merupakan proses
adaptif yang penting karena perubahan fitur yang
diperlukan
di dalam
proses yang dapat diprediksi
sebagai
baik, tapi itu
yang dapat mereka tangani harus dilakukan
.
Seperti yang akan Anda lihat, salah satu karakteristik utama dari desain sistem berorientasi objek adalah ia
menggunakan SDLC berulang.
1.1.3 SDLC Iteratif
Dengan SDLC berulang, kami membangun sebagian kecil sistem dan kemudian „mencobanya‰. Tergantung pada
apa yang telah dibangun, kata 'cobalah' mungkin memiliki arti yang berbeda. Mungkin kita memiliki sistem yang
cukup bagi pengguna untuk melakukan sebagian kecil pekerjaan mereka, atau untuk mengerjakan kasus-kasus
sederhana. Mungkin kami memiliki beberapa perangkat lunak yang dapat dimainkan oleh pengguna menggunakan
data pengujian. Di awal proyek, mungkin hanya ada beberapa rancangan tata letak layar yang meniru tindakan
tertentu.
Dari hasil tes mungkin kami perlu melakukan perubahan. Setelah kami yakin bahwa semuanya berfungsi dengan
baik, kami kemudian menambahkan beberapa fungsi lagi dan mengulangi seluruh proses. Setiap iterasi dapat
meningkatkan atau menambah beberapa fungsi.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
6 ÿ TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK
1.2
PERANCANGAN SISTEM BERORIENTASI OBJEK
Kita akan memulai bagian ini dengan bacaan singkat yang menyajikan argumen untuk desain
sistem berorientasi objek. Sebagaimana pendekatan terhadap Teknologi Informasi (TI) yang
telah berubah dalam tiga puluh tahun terakhir, demikian pula peran TI dalam organisasi.
TI digunakan dalam suatu organisasi dengan salah satu dari dua cara. Pertama, TI mendukung
dapat menyederhanakan bisnis dengan menyederhanakan dan mempercepat berbagai
tugas. Misalnya, penerbit buku dapat menggunakan TI untuk sisi faktur dan akuntansi bisnisnya.
memungkinkan
Kedua, penggunaan TI yang lebih canggih pada layanan
atau produk baru.
Contohnya di sini adalah penerbit yang menerbitkan buku di Web dan mengenakan biaya per
penayangan. Semakin banyak aplikasi yang mendukung dibandingkan mendukung bisnis.
Dalam lingkungan bisnis yang bergejolak saat ini, kebutuhan pelanggan baru dan cara-cara
baru dalam menjalankan bisnis bermunculan setiap hari. Oleh karena itu, kebutuhan akan
sistem yang fleksibel yang dapat dibangun dan diubah dengan cepat sangatlah penting. Di
sinilah teknologi berorientasi objek sangat penting.
Namun, tentu saja kita perlu menyadari bahwa tidak ada teknologi yang merupakan obat
mujarab untuk semua masalah pembangunan.
AKTIVITAS 1.1
Ambil contoh organisasi tempat Anda bekerja. Apa perannya
TI dalam organisasi? Aplikasi TI apa yang dapat dikategorikan
"mendukung‰? Aplikasi TI apa yang dapat dikategorikan sebagai „memungkinkan
bisnis‰? Bicaralah dengan personel TI di organisasi Anda untuk mencari tahu
tentang perbedaan penggunaan TI dalam dua kategori ini. Posting ringkasan
temuan Anda di papan diskusi myVLE. Bandingkan temuan Anda
dengan teman kursusmu.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK ÿ 7
1.2.1 Berpikir pada Objek
Seperti yang kami nyatakan di bagian pendahuluan, belajar „berpikir dalam objek‰ adalah hal yang
sulit. Jadi kami ingin Anda mulai memikirkan tentang objek sekarang, meskipun objek tersebut belum
dibahas
Topik 3 .
Ada beberapa istilah penting dalam orientasi objek yang dijelaskan di bagian ini:
(a) Kelas dan objek;
(b) Enkapsulasi data dan metode;
(c) Dukungan terhadap polimorfisme;
(d) Warisan dalam hierarki kelas; Dan
(e) Antarmuka objek.
Kelas adalah cetak biru yang mendefinisikan variabel (atau atribut) dan metode yang umum
untuk semua objek jenis tertentu. Di dunia nyata, kita sering kali mempunyai banyak benda
yang sejenis. Misalnya, mobil Anda hanyalah salah satu dari banyak mobil di dunia. Dalam
konteks berorientasi objek, kami mengatakan bahwa objek mobil Anda adalah turunan dari
kelas objek yang dikenal sebagai mobil. Mobil memiliki beberapa keadaan (gigi saat ini,
kecepatan saat ini, empat roda) dan perilaku (mengganti gigi, mengubah kecepatan) yang sama.
Namun, setiap kondisi mobil tidak bergantung pada dan dapat berbeda dari kondisi mobil
lainnya.
Saat membangunnya, pabrikan memanfaatkan fakta bahwa mobil memiliki karakteristik yang
sama dan mereka dapat memproduksi banyak mobil dari cetak biru yang sama. Akan sangat
tidak efisien untuk menghasilkan cetak biru baru untuk setiap mobil yang diproduksi.
Dalam perangkat lunak berorientasi objek, dimungkinkan juga untuk memiliki banyak objek
sejenis yang memiliki karakteristik yang sama: catatan karyawan, klip video, catatan siswa,
dan sebagainya. Seperti halnya produsen mobil, Anda dapat memanfaatkan fakta bahwa
benda-benda sejenis itu serupa dan Anda dapat membuat cetak biru untuk benda-benda tersebut.
Seperti dibahas di atas, objek adalah turunan dari suatu kelas. Objek merupakan hal terpenting
dalam paradigma berorientasi objek. Objek dalam perangkat lunak berorientasi objek
berkolaborasi dan bekerja sama dengan mengirimkan pesan untuk mengimplementasikan
perilaku perangkat lunak. Untuk lebih spesifiknya, kita dapat mendefinisikan objek sebagai
sesuatu yang memiliki keadaan, perilaku, dan identitas. Tabel 1.1 memberikan penjelasan dan
contoh ciri-ciri benda tersebut.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
8 ÿ TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK
Tabel 1.1: Karakteristik Objek
Karakteristik Objek
Penjelasan
Negara
Setiap objek memiliki properti yang secara kolektif mewakili keadaan.
Suatu negara dapat memiliki nilai dinamis atau nilai permanen.
Contoh keadaan yang bersifat dinamis adalah jumlah uang dalam mesin,
jumlah kaleng minuman yang belum terjual, umur, dan lain-lain.
Contoh status permanen yang tidak berubah adalah nama, tanggal lahir,
dll. Dalam pemrograman, status diwakili oleh atribut.
Perilaku
Perilaku objek merupakan respon objek ketika objek menerima pesan.
Mungkin ada dua jenis tindakan yang terjadi yaitu mengubah keadaan
objek yang menerima pesan atau keadaan objek yang mengirim pesan.
Contoh: Perhatikan objek mesin penjual otomatis. Salah satu pesan
yang mungkin diterimanya adalah: lepaskan kaleng minuman pilihan
pembeli. Pesan ini akan dikirim ke mesin penjual otomatis ketika pembeli
menekan tombol di mesin. Pesan yang diterima menyebabkan objek
menunjukkan suatu perilaku, yaitu minuman yang dipilih pembeli
dilepaskan. Selain menunjukkan perilaku, suatu objek juga dapat
mengirimkan pesan ke objek lain sebagai respons terhadap pesan yang
diterima.
Ada hubungan erat antara perilaku dan keadaan. Perilaku suatu objek
dipengaruhi oleh keadaan objek tersebut. Misalnya, asumsikan jumlah
kaleng dalam mesin adalah nol, yaitu semua kaleng dalam mesin
tersebut terjual habis. Jika mesin menerima pesan untuk mengeluarkan
minuman kaleng, maka objek tersebut tentu tidak dapat memenuhi
permintaan tersebut karena keadaannya yang jumlah kalengnya nol.
Dalam pemrograman, metode digunakan untuk mendefinisikan perilaku
yang dapat dilakukan suatu objek.
Identitas
Identitas adalah properti yang membedakan suatu objek dari semua
objek lainnya. Setiap objek mempunyai identitas uniknya masing-masing.
Misalnya, sekelompok objek siswa dapat diidentifikasi dengan identitas
uniknya seperti StudentA, StudentB, StudentC,
dll.
Silakan merujuk ke http://java.sun.com/docs/books/tutorial/java/concepts/ class.html yang
memiliki diagram bagus yang menjelaskan konsep kelas dan objek.
Dalam pemrograman berorientasi objek, istilah metode mengacu pada sepotong kode yang
secara eksklusif dikaitkan dengan suatu kelas (disebut metode kelas atau metode statis) atau
dengan suatu objek (disebut metode instan). Suatu metode biasanya terdiri dari serangkaian
pernyataan untuk melakukan suatu tindakan, sekumpulan parameter masukan untuk melakukan tindakan
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK ÿ 9
membuat parameter tindakan tersebut dan mungkin semacam nilai keluaran (disebut nilai
kembalian). Tujuan dari metode adalah untuk menyediakan mekanisme untuk mengakses
(untuk membaca dan menulis) data pribadi yang disimpan dalam suatu objek atau kelas.
Pertimbangkan skenario berikut:
Anda memasuki sebuah restoran. Setelah melihat menu, Anda memesan sepiring nasi goreng
dari server. Kemudian, server akan langsung menuju dapur untuk menyampaikan pesanan
Anda kepada juru masak. Setelah sepuluh menit, server akan kembali kepada Anda dengan
makanan yang telah Anda pesan.
Dalam skenario di atas, Anda tidak perlu mempermasalahkan cara memasak nasi goreng.
Anda hanya ingin nasi gorengnya disajikan. Ini adalah contoh enkapsulasi.
Enkapsulasi adalah istilah yang diberikan untuk proses menyembunyikan semua detail suatu
objek yang tidak berkontribusi terhadap karakteristik esensialnya. Enkapsulasi menyembunyikan
detail implementasi objek dan satu-satunya hal yang tetap terlihat secara eksternal adalah
antarmuka objek (yaitu, kumpulan semua pesan yang dapat ditanggapi oleh objek). Setelah
suatu objek dienkapsulasi, detail implementasinya tidak lagi dapat diakses dengan segera.
Sebaliknya mereka dikemas dan hanya dapat diakses secara tidak langsung melalui
antarmuka objek. Satu-satunya cara untuk mengakses objek yang dienkapsulasi tersebut
adalah melalui penyampaian pesan: seseorang mengirimkan pesan ke objek tersebut, dan
objek itu sendiri memilih metode yang akan digunakan untuk bereaksi terhadap pesan
tersebut, yang ditentukan oleh metode. Semua objek dikaitkan dengan daftar pesan yang
dipahami oleh mereka. Daftar pesan ini secara kolektif menjadi antarmuka objek. Misalnya,
antarmuka untuk objek mesin ATM adalah semua pesan valid yang dapat dikirim oleh
pengguna seperti untuk menarik uang, memeriksa saldo, transfer dana, dll. Pesan tidak valid
yang dikirim oleh pengguna yang bukan merupakan bagian dari objek mesin ATM antarmuka
tidak akan diterima oleh objek.
Warisan adalah kemampuan suatu kelas untuk menggunakan properti dan metode kelas lain
sambil menambahkan fungsionalitasnya sendiri. Contoh dimana hal ini dapat berguna adalah
dengan sistem pencatatan karyawan. Anda dapat membuat kelas karyawan dengan umum
status dan tindakan yang umum bagi semua karyawan. Kemudian kelas dapat ditentukan
lagi
spesifik untuk karyawan yang digaji, ditugaskan, dan dibayar per jam. Kelas generik
kelas super
dikenal sebagai kelas induk (atau kelas dasar) dan kelas khusus disebut
sebagai kelas
subkelas
turunan (atau kelas turunan). Konsep pewarisan
sangat meningkatkan kemampuan kode
serta membuat proses desain menjadi lebih sederhana dan bersih.
penggunaan kembali
metode
Polimorfisme adalah kemampuan suatu tindakan atau untuk
melakukan hal yang berbeda
berdasarkan objek yang ditindaklanjuti. Pengikatan metode kelebihan beban, penggantian,
dan dinamis adalah jenis polimorfisme.
Kami akan meninjau kembali beberapa konsep yang diperkenalkan pada bagian ini di Topik 5.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
10 ÿ ATAS
GAMBAR 1 PENDAHULUAN
DUKSI
KE O
PERANGKAT LUNAK TED
E
ORIEN OBJEK
tidak
PERKEMBANGAN
AKTIVVITA 1.2
Tambahkan
ikat pinggang ke dia
e mengikuti laboratorium
agram atau kalimat bel
kelasS
data
instansejak itu
kali
pesan m
rendah:
pesan
_____ satu sama lain.
komunitas objek
bersatu oleh senmenemukan _______
(a) Ob
(b) Dan
adalah perangkat lunak
t
dan
____________
_
adalah templat t yang mendefinisikan metode
variabel dalam kumpulan objek tertentu
S.
sebuah
(Bisa
kata lain f
S ____________
_.
untuk 'objek' adalah
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK ÿ 11
1.2.2 Membangun Sistem dari Objek
Dari bacaan di bagian sebelumnya Anda seharusnya mempunyai gambaran tentang bagaimana objek
dapat digunakan untuk mengimplementasikan objek dunia nyata seperti rekening bank dan kendaraan.
Namun, Anda mungkin masih bingung bagaimana aplikasi komersial yang kompleks dibangun
seluruhnya menggunakan objek.
Pada topik selanjutnya Anda akan melihat contoh objek lainnya, seperti transaksi, proses, dan
kalkulator. Dalam sistem berorientasi objek, setiap bagian atau blok penyusun adalah sebuah objek.
Selain itu, setiap objek harus memenuhi satu tujuan atau peran. Selama dekade terakhir, pakar
teknologi objek telah mempelajari bahwa sistem yang menerapkan aturan ini lebih mudah beradaptasi
terhadap perubahan dan memiliki lebih sedikit cacat.
Sekarang kita siap untuk melihat bagaimana teknologi berorientasi objek diterapkan dalam proyek
pengembangan aplikasi. Anda telah menemukan SDLC berulang. Sekarang kita akan melihat
metodologi dan notasi yang digunakan untuk mengembangkan sistem berorientasi objek. Jika Anda
perlu mengingat kembali apa yang dimaksud dengan istilah-istilah ini, tinjau bagian sebelumnya.
(Peringatan: tidak semua hal di bagian ini benar-benar berorientasi objek dan tidak setiap proyek yang
memanfaatkan beberapa aspek orientasi objek menggunakan semua pendekatan ini. Apa yang kita
diskusikan di sini adalah praktik terbaik saat ini dalam rekayasa perangkat lunak berorientasi objek.)
1.2.3 Proses Terpadu
Beberapa buku teks menggambarkan Unified Process (UP) sebagai metodologi berorientasi objek. Ini
kurang akurat, karena dapat digunakan untuk pendekatan lain dalam perancangan sistem, namun ini
adalah metodologi yang kami gunakan, jadi dalam konteks kami ini berorientasi objek. Ini memandu
hasil utama (dokumen, model, dll.), komposisi dan keterampilan tim serta tanggung jawab mereka,
serta durasi dan waktu tahapan proyek. Proses tersebut merupakan standar industri yang dipublikasikan
untuk proses pengembangan perangkat lunak khususnya untuk sistem berorientasi objek. Varian UP
yang dikenal dengan Rational Unified Process (RUP) yang merupakan penyempurnaan rinci dari UP
telah diadopsi secara luas. Kursus ini akan fokus pada UP normal. UP adalah pengembangan berulang
yang diselenggarakan dalam fase dan disiplin dua dimensi (awalnya dikenal sebagai alur kerja). Setiap
disiplin ilmu mempunyai artefaknya masing-masing.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
12 ÿ TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK
(a) UP mempunyai empat tahap permulaan, penjabaran, pembinaan dan peralihan.
Tujuan dari semua tahapan ini dijelaskan dalam tabel berikut:
Tabel 1.2: Tahapan UP
Fase
Lahirnya
Tujuan
Tujuan utama tahap awal adalah untuk menetapkan alasan kelayakan
sistem yang diusulkan.
Elaborasi Fase Elaborasi merupakan fase dimana proyek mulai terbentuk.
Pada fase ini analisis domain masalah dibuat dan arsitektur proyek
mendapatkan bentuk dasarnya.
Konstruksi Dalam konstruksi, fokus utama diberikan pada pengembangan komponen
dan fitur lain dari sistem yang sedang dirancang. Ini adalah fase di
mana sebagian besar pengkodean dilakukan.
Transisi
Pada fase transisi produk telah berpindah dari organisasi
pengembangan ke pengguna akhir. Kegiatan fase ini mencakup
pelatihan bagi pengguna akhir dan pengelola serta pengujian beta
sistem untuk memvalidasinya terhadap harapan pengguna akhir.
Penting bagi Anda untuk memperhatikan bahwa semua fase di atas dibagi menjadi
beberapa iterasi.
(b) UP memiliki disiplin ilmu yang mewakili area fokus proyek, pemodelan bisnis,
persyaratan, analisis dan desain, implementasi, pengujian, penerapan, manajemen
proyek, konfigurasi dan manajemen perubahan serta lingkungan. Setiap disiplin ilmu
mempunyai artefaknya masing-masing.
Gambar 1.5 mengilustrasikan perubahan upaya relatif disiplin ilmu sehubungan
dengan fase-fase di UP seperti yang disarankan oleh Larman (2002). Seperti yang
ditunjukkan pada diagram, satu iterasi pekerjaan fase dilakukan di sebagian besar
atau semua disiplin ilmu, namun upaya relatif di seluruh disiplin ilmu ini berubah seiring waktu.
Iterasi awal dalam suatu fase cenderung berfokus pada persyaratan dan desain, dan
yang berikutnya kurang fokus, karena persyaratan dan desain menjadi stabil melalui
proses umpan balik dan adaptasi (Larman (2002).
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK ÿ 13
Gambar 1.5: Perubahan upaya relatif UP Sumber:
Larman (2002), hal. 22
Anda telah diperingatkan di awal bagian ini bahwa setiap disiplin ilmu memiliki
artefaknya sendiri. Di UP, artefak adalah kata kunci yang digunakan untuk
produk kerja apa pun seperti kode, dokumen teks, diagram, dll. Artefak yang
dipilih untuk proyek pengembangan sistem dapat ditulis dalam dokumen singkat
yang disebut Kasus Pengembangan. Kasus Pembangunan sendiri merupakan
artefak dari disiplin ilmu Lingkungan Hidup. Diagram berikut menunjukkan
Kasus Pengembangan yang menjelaskan artefak untuk studi kasus „NextGen
POS‰ yang akan diperkenalkan di akhir topik ini.
Tabel 1.3: Kasus Perkembangan
Artefak
Disiplin
masuk.
I1
Konstan.
Trans.
C1..Cn
T1..T2
S
Model Domain Pemodelan Bisnis
Persyaratan
Elab.
E1..En
Model Kasus Penggunaan
S
R
Penglihatan
S
R
S
R
S
S
Tambahan
Spesifikasi
Glosarium
Desain
Penerapan
Model Desain
S
Dokumen Arsitektur SW
S
Model data
S
R
Model Implementasi
S
R
R
R
R
R
S
R
Rencana Pengembangan SW Manajemen Proyek
Pengujian
Model Uji
Lingkungan
Kasus Pembangunan
S
S
R
mulai, perbaiki
Sumber: Larman (2002), hal. 24
Hak Cipta © Universitas Terbuka Malaysia (OUM)
R
Machine Translated by Google
14 ÿ TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK
Dalam diagram Anda dapat melihat beberapa atrifakta umum yang digunakan untuk disiplin ilmu di
UP. Harap perhatikan bahwa proyek pengembangan perangkat lunak atau sistem yang berbeda
mungkin memerlukan artefak yang berbeda. Fokus kursus ini adalah pada disiplin ilmu pemodelan
bisnis, persyaratan dan desain. Jadi, cobalah mengingat artefak yang digunakan dalam disiplin ilmu
tersebut.
AKTIVITAS 1.3
1.
Sebutkan tiga keuntungan dari iteratif dibandingkan air terjun
mendekati.
2.
Sebutkan tiga tantangan yang terkait dengan pendekatan berulang.
Salah satu praktik UP yang paling penting adalah pengembangan berulang. Aspek lain yang sangat
penting dari UP adalah bahwa UP perlu disesuaikan atau dimodifikasi untuk setiap proyek. Sebagai
sebuah industri, kami kini menyadari bahwa tidak ada satu metode pun yang berhasil untuk setiap
proyek di setiap organisasi. Misalnya, perusahaan kecil yang membangun intranet memerlukan
pendekatan yang berbeda dibandingkan perusahaan besar yang mengerjakan kontrak pertahanan
bernilai jutaan dolar. Pendekatan yang disesuaikan ini merupakan kekuatan sekaligus kelemahan.
Hal ini merupakan kekuatan karena memberikan panduan, namun juga merupakan kelemahan
karena tim proyek masih perlu memutuskan bagaimana menggunakan metodologi tersebut.
UP banyak menggunakan Unified Modeling Language (UML). Inti dari UML adalah model, yang
dalam konteks proses pengembangan perangkat lunak merupakan penyederhanaan realitas yang
membantu tim proyek memahami aspek-aspek tertentu dari kompleksitas yang melekat pada
perangkat lunak. UML dirancang untuk membantu peserta dalam upaya pengembangan perangkat
lunak membangun model yang memungkinkan tim memvisualisasikan sistem, menentukan struktur
dan perilaku sistem, membangun sistem, dan mendokumentasikan keputusan yang dibuat sepanjang
proses.
Banyak tugas yang didefinisikan UP melibatkan penggunaan UML dan satu atau lebih model.
Sekarang mari kita lihat notasi yang digunakan dengan metodologi UP.
1.2.4 Notasi
Dalam kursus ini kita akan menggunakan notasi standar industri yang disebut Unified Modeling
Language (UML). Standar ini merupakan hasil kolaborasi antara tiga ahli metodologi: Jim Rumbaugh,
Grady Booch dan Ivar Jacobson.
Apa yang mereka terbitkan pada tahun 1994 merupakan penggabungan notasi mereka sendiri
ditambah notasi beberapa penulis lain.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 1
UML de
MEMPERKENALKAN
S. BERORIENTASI CT
PERANGKAT LUNAK PERANGKAT
PERKEMBANGAN
PERSYARATAN TERHADAP KEBERATAN
standar denda
HAI desain. Ve
model yang dirancang
s dan notasi
Grup nt
d itu sebagai versin 1.2. Versi: kapann 1.4 adalah arus tidak. Terdaftar
(a) UM
Rilis ML 2.0
5;
ed pada bulan Juli 2005
(b) UM
Rilis ML 2.11
t 2007;
sed pada bulan Agustus
(c)UM
Rilis ML 2.12
sed pada bulan November
mber
Sementara standarnya
th
tidak sempurna
ny bagian UM
hanya sebuah kaleng
Di n
Dan
2007 (akhir
versi terbaik).
sempurna untuk semua situasi,
s
itu berarti semua orang mampu
h dia yang lain agram. Paling
onals
Profesi TI
e untuk membaca masing-masing
ml. (Tolong kembali
lihat Gambar 1.6)
Aragambar 1.6: Overv
notasi
ns untuk ekspres bernyanyi berbedat aspek OO
versi 1.1 tadinya s disampaikan t kepada ManajemenObjek
th diterbitkan
(OMG) i pada tahun 1997 dan hei
adalah o versi lain
s dari UML:
menggunakan praktek
ÿ 15
pemandangan mai
dalam diagram UML pagi
kamu beberapa dari dia
th UML
bagian selanjutnyaAnda
y
akan diperkenalkan secara singkatdiberikan kepada Anda
s untuk digunakan isecara intensif dalam kursus ini.
e Kasus
(a) Penggunaan
deskripsi kasus penggunaan
acara
Sebuah kamu
cribe s
nar deskripsi yang bagus
pilihan hal
dasar
sed.
M. Ini adalah
urutan penggunaan seorang
sistem aktor bagimu
se kasusnya juga tidak
proses. Sebuah kita
biasanya
Seorang aktor akan memulai apsistem atau an
muhanya perlu ditanggapi
Hai.
aktor o atau acara-
acara akan ha aplikasikan itu
Hak Cipta © Universitas Terbuka Malaysia (OUM)
e proses
Machine Translated by Google
16 ÿ TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK
Contoh Kasus Penggunaan:
Pinjam Video
Pelanggan mengambil video yang telah dipilihnya dan pergi ke konter
pembayaran. Di sana petugas mengonfirmasi keanggotaannya dan memeriksa
video yang sudah lewat waktunya. Total biaya dihitung, pelanggan membayar
dan pulang dengan videonya.
(b) Model Domain
Model domain dihasilkan selama analisis dan bukan merupakan deskripsi
objek perangkat lunak. Ini adalah visualisasi konsep dalam domain dunia
nyata. Ini memiliki identifikasi konsep, atribut dan asosiasi seperti yang
ditunjukkan di bawah ini:
Gambar 1.7: Model
domain
Sumber: http://www.apl.jhu.edu/Classes/605404/stafford/oointro/
process_overview/sld004.htm
(c) Diagram Interaksi
Diagram interaksi diproduksi dalam desain dan berkaitan dengan pendefinisian
objek perangkat lunak dan kolaborasinya. Ini memiliki aliran pesan antara
objek perangkat lunak dan juga pemanggilan metode.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK ÿ 17
Gambar 1.8: Diagram interaksi
Sumber:
http://www.cs.gordon.edu/courses/cs211/ATMExample/Interactions.html
(d) Desain Diagram Kelas
Diagram kelas desain yang dihasilkan selama desain menunjukkan tampilan statis definisi
kelas. Ia memiliki metode dan atribut kelas. Berbeda dengan model domain, diagram ini tidak
menggambarkan konsep dunia nyata, melainkan menunjukkan kelas perangkat lunak.
Gambar 1.9: Diagram kelas desain
Sumber: http://www.comptechdoc.org/independent/uml/begin/umldcd.html
Saat Anda mempelajari kursus ini, Anda akan melihat bagaimana diagram yang ditunjukkan di
bagian ini cocok satu sama lain. Topik 2 hingga Topik 5 akan membahas notasi ini secara detail.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
18 ÿ TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK
1.2.5 Apakah Desain Sistem Berorientasi Objek merupakan
Pendekatan Adaptif?
Sekarang setelah Anda membaca tentang metodologi dan notasi, bagaimana menurut Anda? Apakah
desain sistem berorientasi objek merupakan pendekatan adaptif?
Anda mungkin pertama kali berpikir demikian, karena Fowler (2000) cukup meremehkan UML dan
berpendapat bahwa proses desain sistem yang menggunakannya tidak bisa adaptif.
Namun, UML hanyalah sebuah notasi; yang terpenting adalah cara penggunaannya. Fowler sedang
mendiskusikan UML seperti yang digunakan dalam metodologi formal. Anda dapat menguraikan UML
dengan menggambar model dua puluh halaman yang ditinjau secara formal. Anda juga dapat menggunakan
notasi UML yang sangat jarang di papan tulis untuk mengkomunikasikan beberapa ide dengan cepat.
Kemungkinan besar ini adalah cara yang digunakan di UP.
Perhatikan juga bahwa tidak ada yang secara intrinsik bersifat iteratif mengenai orientasi objek. Kedua
pendekatan ini bekerja sama dengan sangat baik, namun Anda dapat melakukan pengembangan nonorientasi objek secara iteratif, sebagaimana Anda juga dapat melakukan pengembangan berorientasi
objek secara non-iteratif.
Jadi, meskipun konsep metodologi berat dan ringan, proses prediktif dan adaptif berguna untuk memahami
proses, Anda harus berhati-hati agar tidak membahasnya terlalu jauh.
AKTIVITAS 1.4
Isilah kolom sebelah kanan tabel berikut.
Perbandingan pendekatan tradisional dan berorientasi objek untuk pengembangan sistem.
Tradisional
Pendekatan data dan
fungsi
Pertimbangkan secara terpisah
Siklus hidup pengembangan
sistem (SDLC)
Air terjun
Notasi
Diagram Hubungan Entitas
(ER).
Contoh bahasa
COBOL, berbagai 4GL
Basis data
Basis data relasional
Berorientasi pada objek
Diagram Aliran Data (DFD)
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK ÿ 19
1.2.6 Analisis dan Desain
Analisis dan desain adalah dua komponen utama yang terlibat ketika mengembangkan perangkat
lunak menggunakan pendekatan berorientasi objek. Apa arti istilah „analisis‰ dan „desain‰?
Sederhananya, analisis perlu disediakan danApa
desain akan disediakan.
Bagaimana
Selama analisis berorientasi objek, penekanannya adalah pada menemukan objek atau konsep dalam
domain masalah. Misalnya, dalam kasus Sistem Informasi Perpustakaan, beberapa konsepnya antara
Buku , Perpustakaan Dan Pelindung.
lain Analisis Berorientasi Objek (OOA), kemudian, adalah proses
mendefinisikan masalah dalam bentuk objek: objek dunia nyata yang harus berinteraksi dengan sistem
dan kandidat objek perangkat lunak yang digunakan untuk mengeksplorasi berbagai alternatif solusi.
Kesesuaian alami objek pemrograman dengan objek dunia nyata memiliki dampak besar di sini: Anda
dapat mendefinisikan semua objek dunia nyata berdasarkan kelas, atribut, dan operasinya.
Selama desain berorientasi objek, penekanannya adalah pada pendefinisian objek perangkat lunak
dan bagaimana objek tersebut berkolaborasi untuk memenuhi persyaratan. Misalnya, dalam kasus
judulmetode. Desain
Sistem Informasi Perpustakaan, objek Buku
perangkat lunak mungkin memiliki atribut dan
A dapatkanBab
Berorientasi Objek (OOD), kemudian, adalah proses mendefinisikan komponen,
antarmuka, objek, kelas, atribut, dan operasi yang akan memenuhi persyaratan. Anda biasanya
memulai dengan objek kandidat yang ditentukan selama analisis, namun menambahkan lebih banyak
ketelitian pada definisinya. Kemudian, Anda menambahkan atau mengubah objek sesuai kebutuhan
untuk menyempurnakan solusi. Dalam sistem besar, desain biasanya terjadi pada dua skala: desain
arsitektur, yang mendefinisikan komponen-komponen yang membentuk sistem, dan desain komponen,
yang mendefinisikan kelas dan antarmuka dalam suatu komponen.
Anda pasti ingat bahwa dalam model air terjun seharusnya terdapat perbedaan yang jelas antara
analisis dan desain. Dalam model berulang Anda mungkin bertanya-tanya di mana letak perbedaannya.
Ini adalah garis yang sangat bagus, dan selama sebuah proyek atau bahkan satu percakapan, Anda
mungkin menemukan bahwa Anda melakukan keduanya.
Meskipun berguna untuk memisahkan analisis dan desain ketika kita membagi masalah besar menjadi
bagian-bagian kecil, ada baiknya juga untuk mempertimbangkan ide-ide lain yang mungkin tidak terlalu
cocok untuk saat ini.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
20 ÿ TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK
1.3
PENTINGNYA DESAIN
Hidup kita dipenuhi dengan mainan, peralatan, dan teknologi. Beberapa di antaranya dirancang dengan baik dan
mudah digunakan. Pisau yang bagus memiliki keseimbangan yang baik, mudah dipegang di tangan Anda dan
memungkinkan Anda berkonsentrasi pada apa yang Anda potong. Situs web yang dirancang dengan baik memberi
Anda informasi yang Anda butuhkan dalam waktu dan kerumitan minimum.
Alat atau antarmuka pengguna yang dirancang dengan buruk memerlukan upaya untuk menggunakannya dan
akibatnya seseorang sering membuat kesalahan atau merasa frustrasi. Mesin cuci yang memiliki lima tombol dan
dial dengan 12 pengaturan terlalu rumit untuk sekadar mencuci pakaian!
Aplikasi yang mengharuskan saya memasukkan tanggal kedaluwarsa kartu kredit „02/06‰ dan bukannya „0206‰
dan tidak menjelaskan kesalahannya sungguh membuat frustrasi.
Ada desain yang terlihat, ada pula yang tersembunyi. Pertimbangkan sebuah mobil. Di dalam mobil kita dapat
melihat dan menyentuh kendali pengemudi. Apakah roda kemudi mudah digenggam? Bisakah Anda dengan cepat
menemukan klakson dalam keadaan darurat? Elemen desain lainnya terungkap melalui penggunaan.
Berapa lama waktu yang dibutuhkan AC untuk mendinginkan mobil pada hari yang panas? Seberapa baik rem
bekerja saat hujan? Beberapa elemen desain bersifat internal sehingga hanya seorang ahli yang dapat
mengapresiasi desain dan mampu memprediksi masa depan.
Bagaimana keausan mesin selama bertahun-tahun? Bagaimana performa mobil saat terjadi kecelakaan? Tidak
ada sesuatu pun di dalam mobil yang kebetulan; seseorang telah merancang segalanya. Begitu pula dengan
perangkat lunak. Aspek eksternal adalah antarmuka pengguna. Internal berkaitan dengan keandalan, kemampuan
untuk berubah dan ketahanan terhadap teknologi baru.
Donald Norman dalam bukunya menantangDesain
kita untuk
dari merancangHal
teko
Sehari-hari
kopi, gagang pintu, sistem telepon, dan
kontrol pendingin dengan mempertimbangkan manusia (1989, 36):
Jikaakan
memungkinkan,
terjadi kesalahan,
seseorang
semua
akan
kesalahan
melakukannya.
yang mungkin
sebuah terjadi Perancang harus berasumsi bahwa
dan dirancang sedemikian rupa sehingga efeknya begitu terjadi.
tersebut
hal meminimalkankemungkinan terjadinya
kesalahan pertama-tama,
jika
atau Kesalahan seharusnya mudah jika memungkinkan
dideteksi, dampaknya harus minimal, dan agar dampaknya dapat dibalik.
Ingatlah selalu bahwa pengguna suatu sistem adalah manusia. Desain yang baik memerlukan pemahaman
tentang prinsip-prinsip dasar dan timbal baliknya. Desain yang bagus membutuhkan pengalaman. Desain yang
baik bukan tentang benar atau salah, tapi tentang menjadi lebih baik dalam keadaan tertentu dibandingkan
keadaan lainnya. Karena semua alasan ini, belajar mendesain dengan baik bisa membuat frustasi. Namun
demikian, ketika Anda telah membuat desain yang bagus, itu sangat memuaskan.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK ÿ 21
1.4
MEMULAI: AWALNYA
FASE
Fase awal adalah saat proyek dimulai di UP. Tujuan utama dari fase Inception adalah untuk menetapkan
alasan kelayakan sistem yang diusulkan.
Ini dimulai dengan seseorang mempunyai ide. Orang lain kemudian perlu dilibatkan – orang yang memiliki
wewenang, keuangan, pengetahuan atau keterampilan yang sesuai. Mereka perlu bekerja sama untuk
membentuk visi bersama untuk proyek tersebut. (Istilah „pernyataan misi‰ juga bisa digunakan.) Visi
memberikan gambaran hasil akhir tanpa mengkhawatirkan komponen dan prosesnya. Seringkali orang
khawatir untuk berkomitmen pada kertas terlalu dini. Namun, ingat: ini adalah pengembangan berulang.
Jadi kami berharap untuk melihat banyak versi dari hal yang sama. Dokumen visi dapat dengan mudah
diperbarui setiap hari selama periode dua minggu seiring dengan semakin banyaknya hal yang dipelajari.
Dalam membentuk visi, Anda perlu meminta bantuan semua pemangku kepentingan yang terlibat dalam
proyek seperti CEO, direktur TI, dewan direksi, dll.
Bagian penting dari visi proyek adalah ruang lingkupnya. Apa sebenarnya yang akan dan apa yang tidak
akan ada dalam sistem? Jika cakupannya terlalu besar maka kemungkinan besar proyek tersebut akan
gagal. Cakupannya harus sekecil mungkin namun tetap memenuhi kebutuhan inti. Aturan 80/20, atau
prinsip ParetoÊs (dinamai berdasarkan nama ekonom Italia abad ke-19), menjelaskan mengapa setiap fitur
tidak perlu dibangun. Aturan ini menyatakan bahwa 80 persen nilai sekelompok barang umumnya
terkonsentrasi pada 20 persen barang tersebut. Contohnya termasuk tagihan telepon (80 persen panggilan
hanya ke 20 persen orang) dan makan di restoran (80 persen pesanan ditujukan untuk 20 persen hidangan
di menu) dan perangkat lunak 80 persen dari total biaya. pengguna pengolah kata hanya menggunakan 20
persen dari seluruh fitur.
Tentu saja, semakin banyak pemangku kepentingan yang Anda konsultasikan, semakin besar cakupannya.
Namun, sangat penting untuk mengartikulasikan dengan tegas dan tetap berpegang pada visi utama.
(Salah satu teknik yang berguna adalah dengan memiliki lampiran pada visi Anda tentang semua hal yang
bukan sedang dipertimbangkan, namun bisa jadi nanti. Ini berarti bahwa ide tidak hilang, begitu pula visi).
Ruang lingkup suatu sistem sebenarnya merupakan penjumlahan dari bagian-bagiannya. Beberapa bagian
menyediakan fungsionalitas, seperti menerima pesanan pelanggan dan lainnya disebut persyaratan nonfungsional. Ini adalah hal-hal seperti kecepatan sistem, kualitas dan kepatuhan terhadap standar (Topik 2
membahas lebih lanjut tentang topik ini).
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
22 ÿ TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK
Persyaratan fungsional paling baik dijelaskan dengan kasus penggunaan. Use case ditemukan oleh Ivar
Jacobsen, salah satu dari tiga penulis UML. Use case adalah deskripsi dari beberapa interaksi sistem. Itu
ditulis dalam bahasa sehari-hari yang sederhana, bahasa Inggris, atau bahasa apa pun yang paling
nyaman bagi pengguna. Ini bisa berupa narasi sederhana dan santai yang menggambarkan bagaimana
tujuan pengguna terpenuhi.
Berikut adalah contoh kasus penggunaan. Misalkan kita sedang menulis sistem untuk menyewakan video.
Meminjam A kasus penggunaan video cerita sederhana
Pelanggan mengambil video yang telah dipilihnyaatau
dandia
pergi ke konter pembayaran. Di
ke
sana petugas mengonfirmasi keanggotaannya dan memeriksa apakah
atau ada video yang sudah lewat
waktunya.Total biaya dihitung, pelanggan membayar, dan pergi bersamanya
atau videonya.
Ingatlah selalu bahwa use case menggambarkan interaksi antara pengguna dan sistem. Itu tidak memberi
tahu kita apa pun tentang cara kerja sistem. Itu dilakukan nanti.
Jangan khawatir jika Anda masih bingung dengan kasus penggunaan. Topik 2 membahas kasus penggunaan
secara lebih rinci dalam menentukan siapa penggunanya, mencapai tujuan mereka, menggunakan format kasus
penggunaan yang berbeda, dll.
Sejauh menyangkut tahap awal proyek, yang kami inginkan adalah daftar awal nama-nama kasus
penggunaan. Kami ingin tahu apakah ada 5 atau 50 kasus penggunaan. Hal ini, pada gilirannya, akan
memberi kita gambaran tentang berapa lama proyek tersebut akan memakan waktu dan juga biayanya.
AKTIVITAS 1.5
Tulis kasus penggunaan untuk masing-masing hal berikut:
(a) Seorang siswa mendaftar untuk kursus OUM.
(b) Pelanggan membeli barang dari toko online.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK ÿ 23
1.4.1 Artefak Fase Awal
Selama pengembangan suatu sistem, berbagai model, desain, dokumen, laporan, spreadsheet, manual,
dan kode pemrograman dihasilkan. Kami menyebutnya sebagai artefak. Metodologi biasanya
memberikan pedoman tentang artefak mana yang perlu diproduksi, kapan artefak tersebut diproduksi
dalam siklus hidup pengembangan, formatnya (gambar, dokumen, spreadsheet, dll.) dan mungkin siapa
di tim yang harus memproduksinya.
Berhati-hatilah saat mempertimbangkan artefak untuk proyek tertentu karena setiap artefak menambah
total biaya. Untuk setiap artefak:
(a) memastikan bahwa hal tersebut mempunyai tujuan yang nyata, baik saat ini maupun di masa depan; Dan
(b) menetapkan seberapa „baik‰ hal tersebut perlu dipikirkan kembali tentang aturan 80/20.
Tabel 1.4 berisi daftar artefak yang ditentukan UP untuk tahap awal.
Ingatlah bahwa semua artefak ini bisa dimulai sebagai sketsa atau dokumen yang sangat sederhana.
Tergantung pada ukuran dan sifat proyek, mereka mungkin berkembang menjadi lebih rinci dan/atau
lebih formal.
Tabel 1.4: Artefak Fase Awal
Komentar
Artefak
Visi dan kasus bisnis Ini bisa dimulai dari dokumen sederhana setebal 12 halaman, mungkin dengan beberapa
2 dapat dimasukkan.
diagram. membahas materi Topik
lain yang
Gunakan model kasus
Dibahas lebih lanjut di . Sebenarnya
Topik 2 apa yang diperlukan dalam Fase Awal
adalah daftar kasus penggunaan utama yang perlu dibahas, ditambah
mungkin beberapa detail untuk kasus penggunaan utama.
Spesifikasi tambahan
Glosarium
Ini adalah segala sesuatu yang dianggap perlu tetapi tidak termasuk di
tempat lain. Lebih detailnya di
Topik 2 .
Setiap proyek memiliki kata dan istilah khusus yang perlu dipahami semua
orang. Untuk menghindari pengulangan yang tidak perlu, sebaiknya
kumpulkan semua istilah di satu tempat.
Daftar risiko dan
rencana manajemen risiko
Setiap proyek mempunyai risiko. Risiko dapat dikategorikan sebagai risiko
teknis, manusia, atau politik. Ada yang bersifat umum pada setiap proyek,
seperti orang-orang penting yang keluar dan ada pula yang khusus untuk
proyek tersebut.
Daftar risiko dan rencana manajemen risiko dapat berupa dokumen
sederhana yang berisi daftar risiko dan cara menguranginya. Peninjauan
risiko secara rutin sangatlah penting.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
24 ÿ TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK
Prototipe dan pembuktian konsep
Prototipe dapat diproduksi karena sejumlah alasan. Hal ini dapat dilakukan untuk
mendemonstrasikan tampilan antarmuka pengguna, atau dapat juga untuk
mendemonstrasikan bahwa teknologi yang dipilih berfungsi dan 2.000 transaksi
dapat disimpan dalam database dalam waktu kurang dari dua menit.
Rencana iterasi
Menjelaskan apa yang harus dilakukan pada iterasi elaborasi pertama.
Dalam pengembangan berulang, di akhir setiap fase atau iterasi Anda perlu
merencanakan fase atau iterasi berikutnya.
Rencana tersebut harus mencakup berapa lama iterasi akan berlangsung, siapa
yang akan berpartisipasi dan apa yang akan mereka hasilkan.
Rencana fase dan rencana
Pada tahap proyek ini, Anda akan memiliki gambaran tentang orang, sumber daya,
pengembangan perangkat lunak
dan alat yang Anda perlukan untuk proyek tersebut. Ini perlu dicantumkan. Seperti
biasa, ingatlah bahwa rencana ini dapat diubah seiring dengan dipelajarinya
informasi baru.
Kasus pembangunan
Rencana ini menunjukkan proses seperti apa yang akan Anda ikuti untuk proyek
tersebut. Apakah ini akan menjadi proyek yang setiap dokumennya harus
ditandatangani oleh sponsor proyek, atau apakah Anda akan menggunakan
tinjauan informal?
Di sinilah Anda menyatakan artefak seperti apa yang akan Anda hasilkan dalam
proyek ini.
(Diadaptasi dari Larman (2002), hlm. 3738
• Topik ini menjadi latar untuk sisa kursus. Orientasi objek memungkinkan kita
menggabungkan data dan fungsi saat menganalisis entitas dunia nyata dan perangkat
lunak.
• Pendekatan pengembangan aplikasi berpindah dari air terjun ke iteratif
perkembangan.
• Kami memperkenalkan dua standar: Unified Process (UP) dan Unified Modeling Language
(UML). UP adalah metodologi untuk mengembangkan sistem berorientasi objek secara
berulang. UML adalah seperangkat notasi standar untuk memodelkan berbagai aspek
sistem berorientasi objek.
• Pengembangan sistem merupakan suatu usaha rekayasa dan kreatif
Ada banyak pendapat berbeda tentang cara terbaik untuk melanjutkan.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK ÿ 25
• Kami kemudian memulai tahap awal studi kasus dengan melihat
visi, pemangku kepentingan dan beberapa rencana awal.
• Sekarang kami akan memperkenalkan studi kasus yang digunakan dalam kursus ini.
Studi Kasus 1: Video Victoria
(Ini adalah pengantar Video Victoria, sebuah contoh yang akan Anda gunakan
banyak kegiatan dan diskusi dalam topik berikut.)
VictoriaÊs Video adalah toko video besar dengan ribuan anggota dan video. Ini adalah toko tunggal dan
Victoria tidak memiliki rencana untuk memperluas ke banyak cabang.
Victoria memiliki stok sekitar 50.000 video setiap tahunnya, sekitar sepertiga dari video tersebut dijual
atau dimusnahkan dan yang baru dibeli. Setiap video
memiliki klasifikasi (G umum, PG bimbingan orang tua, MA audiens dewasa, dan
dibatasi R). Anggota harus berusia di atas 18 tahun untuk meminjam video R. Setiap video juga memiliki
kategori: roman, umum, fiksi ilmiah, bahasa asing, dan anak-anak.
Anda harus menjadi anggota untuk meminjam video. Terdapat sekitar 10.000 anggota dan jumlah
tersebut meningkat sekitar 2.000 setiap tahunnya, namun beberapa
anggota belum meminjam selama bertahun-tahun. Ketika orang baru meminta untuk menjadi a
anggota, mereka harus menunjukkan SIM atau tanda pengenal lainnya yang berfoto. Minimal
umurnya 16 tahun. Seorang anggota dapat meminjam video dalam jumlah berapa pun, asalkan mereka dapat meminjamnya
tidak ada video yang lewat waktunya, dan dimungkinkan juga untuk memesan video. Ada denda
untuk video yang sudah lewat waktu.
Lamanya waktu peminjaman video tergantung pada videonya. Baru
rilis hanya dipinjamkan dalam semalam, rilis saat ini untuk sewa tiga hari dan sisanya untuk seminggu.
Ulang tahun anggota ditandai dengan surat khusus yang mengundang mereka untuk meminjam apa pun
video pilihan mereka selama seminggu secara gratis.
Setiap tiga bulan sekali toko tersebut melakukan stock opname. Setiap video yang hilang diperbarui
untuk menunjukkan mereka sebagai 'hilang'.
Sistem Victoria memiliki tiga terminal kasir cerdas yang sangat baik
menangani semua transaksi keuangan. Terminal ini menangani kartu kredit
fasilitas, rekonsiliasi kas, perbankan dan antarmuka dengan sistem akuntansi.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
2 6 ÿ ATAS
GAMBAR 1 PENDAHULUAN
DUKSI
KE O
ORIEN OBJEK
PERANGKAT LUNAK TED
E
tidak
PERKEMBANGAN
H
Namun, perang lama
e (Windows 9
95)
kompilasi saat inisistem puter berjalan sangat dan
sebuah
ditulis secara tidak jelas
kembali memprogram
menggunakan bahasa yang tidak dimengerti oleh siapa pun .
tr
topi membutuhkan sedikit
a
Ini sangat lambatw dan tidak bertemansistem dly th
sttaff. Jadi Victor ria telah memutuskaned untuk berinvestasisecara
i
lengkap sistem baru
adalah
em dan lunak
perangkat keras, opsistem pemerasan
D
keputusan
miliki kamu belum pernah, bu
ade.
h
gudang. Sulit
hujan untuk ne
baru
mereka dengan obat-obatan
masuk
gudang dan operasi
sistem operasi
em
W
Sementara dia d melakukan ini, dia dia ingin beriklandd perang data rehouse jadi th manajemen topi masuk
cadapatkan berbagai macam
laporan statistik AS. Misalnya,
ke untuk melihat siapaich
mereka ingin
pelanggan, ho aduh
os paling po
populer atau tidakpopuler, siapa yang terbaik c
kamu
jenis video
M
dan
video
di
sana
ya, dll.
banyak yang terlambat
n tambahan, di n saat ini s
dan anggota perlu pres
Di dalam
sebuah
masalah apa
pembaca kode adalah
videonya
s diperlukan untuk pindai
s
sistem barc
mengirimkan kartu identitasnya untuk diambile
en anggota lupa membawa
video o
ng kartu mereka ds, jadi Victoria
os,
keluar. Hal ini menyebabkan
se
a ingin hal
jelajahi o lainnya pilihan.
mantan
T
Pengikut
V
Vide
Victoria
posisi th
g adalah fungsinyadekomposisi nasional
dia menargetkan sistem
n
baruf
untuk
aku:
A
Karena ada a
selalu baru st
B Ini mudah dipelajarin dan gunakan.
anggota taff
yang baru w sistem memiliki
s bergabung dengan toko,
s
Hak Cipta © Universitas Terbuka Malaysia (OUM)
ke
Machine Translated by Google
TOPIK 1 PENGENALAN PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK ÿ 27
Studi Kasus 2: Sistem POS NextGen (Ini
adalah pengenalan Sistem POS NextGen, contoh yang akan Anda gunakan dalam beberapa aktivitas
dan diskusi pada topik berikut. Kasus ini
Penelitian diadaptasi dari Larman (2002), halaman 2931.
Studi kasusnya adalah sistem point-of-sale (POS) NextGen. Dalam studi kasus ini, kita akan melihat
bahwa ada banyak masalah persyaratan dan desain yang menarik untuk dipecahkan.
Ini adalah masalah yang realistis karena organisasi benar-benar menggunakan sistem POS
teknologi objek. Sistem POS adalah aplikasi terkomputerisasi yang digunakan (sebagian) untuk
mencatat penjualan dan menangani pembayaran dan biasanya digunakan di toko ritel. Dia
termasuk komponen perangkat keras seperti komputer dan pemindai kode batang dan
perangkat lunak untuk menjalankan sistem. Itu dihubungkan ke berbagai aplikasi layanan seperti
kalkulator pajak pihak ketiga dan kontrol inventaris. Sistem harus relatif toleran terhadap kesalahan.
Sebuah sistem POS harus semakin mendukung banyak dan beragam
terminal dan antarmuka sisi klien. Ini termasuk browser Web, PC biasa
yang mendukung Graphical User Interface (GUI), input layar sentuh, PDA nirkabel dan lain sebagainya.
Selanjutnya, kami menciptakan sistem POS komersial yang akan kami jual
klien yang berbeda dengan kebutuhan yang berbeda dalam hal pemrosesan aturan bisnis. Setiap
klien akan menginginkan serangkaian logika unik untuk dieksekusi pada titik-titik tertentu yang dapat diprediksi
dalam skenario penggunaan sistem, seperti ketika penjualan baru dimulai atau ketika penjualan baru dimulai.
item baris ditambahkan. Oleh karena itu, diperlukan suatu mekanisme untuk menyediakan hal tersebut
fleksibilitas dan penyesuaian. Dengan menggunakan strategi pengembangan berulang, kami berhasil
akan melanjutkan melalui persyaratan, analisis berorientasi objek, desain dan implementasi.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
2 8 ÿ ATAS
GAMBAR 1 PENDAHULUAN
DUKSI
KE O
PERANGKAT LUNAK TED
E
ORIEN OBJEK
A
Atribut
Obyek
C
Kelas
Polimor rphisme
Konstruksi
C
tiang pancanglebih tua
E
Elaborasi
Subkelas S
Lahirnya
pantat
kelas super
Warisan
Transisi
Contoh
Bersatu
SAYA
SAYA
SAYA
Pengembangan berulang
kawin
SAYA
tidak
PERKEMBANGAN
pada
Pemodelan La bahasa (UM
ml)
Variabel e
lari
air terjun II
M
Pesan
M
metode
C
Bertahan
Cockburn, A. (1998).
benda hidup
Boston, MMA: Addison n-Wesley.
proyek berorientasi
Sebuah prt:
C
Konstantin,
L.(1995).
Yourdon n Tekan.
Hai
Konstantinus
C
adalah
pada orang-orang
. Inggris
F burung hantu, M. (20
000) Atur pola makan Anda. proses pada a
D
Desember. Ulangdiambil dari
m <http://ww
sdm0012 2a/0012a.htm m>.
perangkat lunak
ulang
ww.sdmagazi
K
D proses:
Krutchen,
P. (1 1999). Tikus kesatuan nasional
Tambahan
n-Wesley.
L
Larman, C. (20 002). Melamar
Aula
N
Norman, D.(1
1989). Des
UML dan pola hal
ide .
manajer
Tebing bagus, NNJ:
pengembangan
majalah ent
ine.com/docu
Sebuah
N
bu panduan
perkenalan
jumlah/s=73
N.
,
37/
Membaca, MMA:
. Uppper Sadel Riv
ver, NJ: Persetanwaktu
NNew York, N
Y: DoubleDa ay/ .
ditanda setiap
tanganihari hal-hal
Mata uang
kamu.
HAI
Kelola Objek
Grup Manajemen . Diperoleh fr
T
Taylor, DA (1998).
ct
Keberatan
MA: Tambahkan
dison-Wesley
teknologi
dari http://w
www.omg.org
G
Panduan rÊs y: manajer (2ndedisi d.). Baca ng,
kamu.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
Tema ÿ Persyaratan
dan Kasus Penggunaan
2
HASIL BELAJAR
Pada akhir topik ini, Anda seharusnya mampu:
1.
Membedakan berbagai jenis dan tingkat persyaratan;
2.
Buat daftar persyaratan non-fungsional standar;
3. Menyadari bahwa perubahan persyaratan tidak bisa dihindari dan digariskan
strategi untuk menghadapi perubahan tersebut;
4.
Identifikasi aktor untuk suatu sistem;
5. Tentukan use case, tingkat use case dan jelaskan bagaimana use case cocok
dengan tujuan;
6.
Identifikasi kasus penggunaan suatu sistem;
7. Menggambar diagram use case UML untuk menunjukkan ruang lingkup suatu sistem; dan 8.
Menggambar diagram aktivitas UML yang benar untuk sekumpulan kasus penggunaan.
ÿ PENDAHULUAN
Topik ini adalah tentang menemukan dan kemudian mencatat dan menganalisis persyaratan untuk suatu
sistem. Persyaratan yang didefinisikan dengan buruk adalah penyebab utama kegagalan sistem.
Persyaratan suatu sistem mencakup spektrum yang luas, mulai dari kebutuhan bisnis hingga teknologi spesifik
serta apa yang „harus dilakukan‰ oleh sistem, seperti menghitung pajak.
Topik ini dimulai dengan diskusi tentang berbagai tingkat dan jenis persyaratan. Kami kemudian fokus pada
apa yang „harus dilakukan‰ oleh sistem, atau persyaratan fungsionalnya.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
30 ÿ TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN
Persyaratan fungsional dijelaskan oleh kasus penggunaan. Kasus penggunaan adalah inti dari
analisis dan desain berorientasi objek. Akibatnya sebagian besar topik ini adalah tentang penulisan
kasus penggunaan, yang telah Anda perkenalkan secara singkat di Topik 1. Kasus penggunaan
terlihat sederhana dan sangat sederhana sampai Anda mencoba menulisnya. Kegiatan untuk topik
ini akan membantu Anda melatih keterampilan ini.
Selain use case, Anda akan mempelajari tiga diagram UML yang digunakan bersama dengan use
case. Diagram use case memberikan gambaran gambaran aktor dan use case. Diagram aktivitas
menunjukkan bagaimana beberapa kasus penggunaan berinteraksi untuk mencapai tugas atau
proses bisnis. Gunakan diagram paket kasus untuk mengelompokkan kasus penggunaan secara
logis agar lebih mudah memahami gambaran besarnya.
Sepanjang keseluruhan proses pengembangan sistem, kami menerima bahwa persyaratan akan
berubah sebagai respons terhadap berbagai kebutuhan. UP mengatasi hal ini dengan menggunakan
metodologi pengembangan berulang. Topik ini diakhiri dengan melihat dokumen dan artefak
persyaratan UP.
2.1
ANALISA KEBUTUHAN
Seperti yang Anda pelajari di Topik 1, ada beberapa disiplin ilmu (atau alur kerja) dalam masingmasing empat fase (UP). Salah satu disiplin ilmu paling awal dan salah satu yang paling penting
adalah analisis kebutuhan. Jelasnya, sebelum kita melakukan apa pun, kita harus bertanya pada diri
sendiri apa yang kita ingin sistem lakukan.
Untuk menjawab pertanyaan ini, perlu dipertimbangkan:
(a) kebutuhan bisnis;
(b) sumber daya yang tersedia;
(c) kemungkinan teknologi; Dan
(d) implikasi sosial dan hukum.
Masalah yang harus dipecahkan didiskusikan di antara anggota tim, pelanggan, dan biasanya
pengguna. Asumsi diungkapkan tetapi dapat diverifikasi atau ditolak menggunakan teknik pembuatan
prototipe „bukti konsep‰.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN ÿ 31
Persyaratan sistem adalah hasil dari proses ini dan mewakili kesepakatan antara
anggota tim pengembangan sistem, pelanggan, dan pengguna. Perhatikan bahwa
Apa
persyaratan akan memberitahu sistem akan melakukan,
bukan
Bagaimana
itu akan berhasil. Penulisan persyaratan meliputi:
(a) Mendefinisikan tujuan sistem, memprioritaskan fungsionalitasnya dan menentukan
konteksnya (yaitu, siapa penggunanya dan sistem apa yang berinteraksi
dengannya?);
(b) Mengidentifikasi antarmuka eksternal, baik manusia maupun sistem-ke-sistem.
Teknologi dari sistem yang ada yang harus dihubungkan dengan sistem dapat
membatasi persyaratan dan desain;
(c) Mengidentifikasi fungsionalitas utama yang harus disediakan oleh sistem dan
menggambarkannya;
(d) Mendokumentasikan asumsi-asumsi yang menjadi dasar persyaratan. Jika
asumsinya berubah, maka persyaratannya juga akan berubah; Dan
(e) Berkomunikasi dengan pengguna, klien, analis bisnis dan pengembang sehingga
sistem yang dikembangkan memenuhi harapan klien.
Persyaratan tersebut mungkin juga melibatkan prototipe „bukti konsep‰, yang pada
awal siklus hidup proses pengembangan mengkonfirmasi atau membentuk arah
solusi. Prototipe dapat berupa tiruan yang diimplementasikan dari beberapa fungsi
dalam sistem, atau dapat berupa sketsa GUI yang melaluinya skenario dapat
dinavigasi dan dikonfirmasi.
2.1.1 Tingkatan dan Jenis Persyaratan
Suatu organisasi mungkin memulai proyek pengembangan sistem baru karena
sejumlah alasan: kebutuhan bisnis baru, penggantian sistem lama, penggabungan
dua sistem yang ada karena akuisisi dan merger, dll. Dalam kebanyakan kasus,
aktivitas pengembangan sistem didorong oleh kebutuhan bisnis . Oleh karena itu,
Anda perlu memahami berbagai tingkat persyaratan untuk sistem yang akan Anda
kembangkan. Ini adalah:
(a) Persyaratan bisnis ini menentukan proses tingkat tinggi yang terjadi dalam suatu
organisasi. Misalnya dalam sistem perbankan, apa tujuan pengembangan
sistem perbankan baru? Apakah akan menggantikan sistem lama atau akan
digunakan pada bidang usaha baru, dan sebagainya?
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
32 ÿ TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN
(b) Persyaratan sistem yang harus dilakukan sistem komputer bagi penggunanya.
Ini adalah persyaratan fungsional sistem.
(c) Persyaratan internal yang berkaitan dengan teknologi, personel, persyaratan platform
perangkat keras, dll. Ini adalah persyaratan non-fungsional.
Untuk menjelaskan perbedaan kebutuhan fungsional dan non-fungsional, perhatikan contoh
membangun rumah. Bayangkan Anda mewarisi sebidang tanah dan ingin membangun
rumah di atasnya. Jadi Anda menghubungi seorang arsitek dan duduk untuk mendiskusikan
kebutuhan Anda. Berapa banyak kamar yang Anda butuhkan?
Apakah Anda ingin ruang makan di sebelah dapur? Seberapa besar seharusnya taman itu?
Kita dapat menganggap ini sebagai persyaratan fungsional rumah. Ada juga persyaratan lain
seperti kualitas keran kamar mandi, jumlah cahaya alami dan total anggaran untuk proyek
tersebut. Ini tidak berfungsi
persyaratan. Dari perspektif pengembangan sistem, kebutuhan non-fungsional dapat dibagi
lagi menjadi beberapa kategori. Dalam konteks UP, persyaratan dikategorikan menurut
model FURPS+ yang mengacu pada: fungsi, kemampuan, kinerja, dukungan dan „+‰ untuk
Fhal lainnya (seperti implementasi,
Rkelayakan,
P
pengoperasian,
paket, legal, dll.) seperti yang digambarkan
pada Gambar 2.1 .
kamu
Gambar 2.1: Model persyaratan FURPS+
Cockburn (2002) menyatakan bahwa hanya sepertiga dari persyaratan yang fungsional.
Beberapa persyaratan dapat dianggap fungsional dan non-fungsional.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN ÿ 33
KEGIATAN 2.1
Cirikan persyaratan berikut sebagai fungsional, non-fungsional
atau keduanya.
(a) Pelanggan menerima diskon khusus pada hari ulang tahunnya.
(b) Gunakan arsitektur Java J2EE.
(c) Setiap terminal POS mampu memproses 100 item penjualan per menit.
(d) Menghasilkan laporan permintaan seluruh transaksi yang lebih besar dari
$100.000.
(e) Setiap pengguna dapat melihat opsi menu yang dipersonalisasi.
KEGIATAN 2.2
Sistem Video Victoria Dalam
topik ini, kami akan menggunakan sistem Video Victoria, yaitu Anda
diperkenalkan pada Topik 1 sebagai dasar untuk beberapa kegiatan.
Lihat lagi studi kasus, yang termasuk dalam dan daftar dua persyaratan
fungsional dan dua non-fungsional
persyaratan untuk sistem.
Topik 1 ,
2.1.2 Tantangan Persyaratan Penulisan
Pengembang sistem yang berpengalaman akan memberi tahu Anda bahwa salah satu penyebab
utama kegagalan proyek adalah analisis persyaratan yang dilakukan dengan buruk. Penulis
persyaratan menghadapi sejumlah tantangan, tidak semuanya bersifat teknis. Masalah
komunikasi, manusia dan bisnis juga harus diperhitungkan. Berikut ini adalah tantangan yang
mungkin terjadi:
(a) Kompleksitas Domain Masalah
Tantangan terbesar adalah mencari tahu tentang domain masalah (lingkungan di mana
sistem akan beroperasi, misalnya toko video kita).
Hal ini terutama berlaku jika domain tersebut adalah domain baru. Tantangan terkait
domain lainnya mencakup: memastikan peran sistem dalam domain, mencapai pemahaman
dalam domain masalah, menerjemahkan apa yang Anda pelajari
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
3 4 ÿ ATAS
REMENT
GAMBAR 2 DIPERLUKAN
DAN U KASUS PENGGUNAAN
tentang thdia permintaan domain
pertanyaan s
yaitu.
Jelas sekalily, yang besar
bijih
spesifikasi dan tanggung jawab sistem
r dan lebih kompleks uired, mo
kebutuhan sistem
tantangan melakukan tugas Anda..
(B
b) Orang-ke
o-orang Com
Anda perlu
ed efektif c
komunikasi
komunikasi
dalam urutan t
untuk mengekstrak info
formasi kesana kemari
om
klien sebuahdan pengguna di atas
om
keluar masalahnyalem domain, untuk mendapatkan inf formasi kesana kemari
klien a
dan pengguna atentang s
kebutuhan sistem kemarahan, untuk
mengerti penyerahan sistem kembali ke klien dan
untuk berkumpul
persyaratannya
informasi nts
dan terakhirsangat ingin disampaikan
kamu perlunya
sampaikan padamu
d pengguna untuk penegasan
th
ahli waris
kami
pada,
ion untuk dikembangkan
operasi,
manajer ger dan teste
r berubah menjadi persyaratannya
t
eh,
entitas yang m
mungkin saja
sudah didirikan kandang. Misalnya
perlengkapan an analisis, kelompokup
permintaan yang berhasil
terlibat
(C
c) Konstan
aku perlu konv
sangat informatif ion ke satu ano
efektif lainnya
ely.
t Berubah
Seperti yangtelah
kita h disebutkan, mengubah kembali
pertanyaan i
f perangkat
lunakkembali mengembangkan saya
aspek yang baik
dari
siklus hidup.
. Meski begitu
mungkin f dibekukan pada patitik tertentu
itu akan c terus berkembang. Ini
dia domain masalah oleh analis an
ditingkatkanaku mengerti
ding dari s
solusi sistem
ion di pa
akan selalu ch
tidak
g dari
e untuk berimprovisasi
dan berkembang eh,
seni pengguna, atau
es atau politik
pemberi
regulator, teknologi
w
persetujuan, nyanyikan
Mengakuipermintaan pertanyaan
itu
T.
konsep inti
persyaratan gh
dan orang-orang tidak
t, sebuah sistem an
pemahaman
evolusi ini mungkin disebabkan
sudah mengerti
dan akhir th
sekadar kompetisi,
adalah sebuah keniscayaan
ics.
hange adalah ac pengembangan
berulang
(D
d) Penulisan R
Persyaratan
s di UP
yang
Seperti yang Anda tahu, pergibenar-benar diperlukan
analisis komentar ysis adalah ke desjuru tulis apa t
dandan kebiasaannyamer
sistem s harus dilakukan (th persyaratan
nts) dan dapatkanpengembang
d
pada deskripsi iturobekan. Ke ac
untuk
menyetujui sekeliling
bantingan dan e berperilaku itu
potensi
l pengguna adalah saya
sumber
penting
mencapai ini, w kami mendefinisikan
sistem e dan
itu
itu seharusnya d untuk melakukan. Pelanggan a
dan
informasi
asi.
Di UP berkembang
bingkai pment mework, persyaratan analisis nts
ted
dalam dua ke ey artefak, t
Kasus Penggunaan
e Model untuk t
kemajuannya
hadir secara aktif
fungsia semua persyaratan
nts dan s
aktif untuk no
tambahan
spesifikasi
fungsia
nts (lihat F
semua persyaratan
gambar 2.2).
Ara
gambar 2.2: Ke persyaratannyaartefak nts
Hak Cipta © Universitas Terbuka Malaysia (OUM)
pada-
Machine Translated by Google
DAN
D KASUS PENGGUNAAN
KE
PERSYARATAN OPICUIREMENT
2
ÿ 35
Seperti disebutkan
mer, siapa
d dalam Topik 1, tModel Kasus Penggunaan adalah pentingpenting bagi bo lainnya yang adatnya
yang butuh
diath
menjadi model untuk va
Alidate itu th
akan
menjadi
wh
d dan untuk
di yang diharapkan
dia sistem akan
pengembang
elopers, siapa
untuk
persyaratan
o butuh m
model ke ge
sistem. Kasus Penggunaan M
dan kamu yang lebih baik
memahami
Model tertulis
g dari
sepuluh sehingga kedua
b
pelanggan r dan pengembang
veloper di bawah memahaminya.
Model Kasus Penggunaan cterdiri dari ac
eksternal ke sistem
fungsi
aktor dan kasus penggunaan. Aktor mewakili
e entitas
esent kasusm, baik gunakan ers atau sistem lainnya. Menggunakan kasus ini mewakili
semua perilaku sistem
gambar wh
punya p yang lebih jelas
M. Aktor membantu
p tentukan sy
sistem dan berikan
apakah kamu
dilakukan.Kita
W akan melihat apada aktor lebih jauh
dia terlibat
dalam hal itu adalah harus
suppo
bagian selanjutnya.
tahu dari T
Topik 1, penggunaan
perwakilan
acara nts kasus
tri
dipicu oleh ac aktor dan
menjelaskan
e
kasus
adalah
de
merespons. Sebagai penggunaan
mengembangkan acco
begitulah sy
membendung harus diselesaikan
perintah untuk
aktor
e relevan dengan para
t pengguna.
rsÊ kebutuhan, sistemnya mo
bijih mungkin
Seperti yang Anda k
th langkah utamaps dari itu
proses yang eratifes dari membanguning dan
Gambar 2 2.3 menunjukkan dia
menyampaikan
e
kasus
hidup
th
ng beberapa fungsi
fungsionalitas. Menggunakan
melalui en
sistem ban l
siklus hidup
dan bertindak sebagai pemersatu
dia sama Gunakan
e Mode Kasus el digunakan du semua
benang ng. Th
selanjutnyaalur kerja
4 adalah teluk
nanti
adalah. Topik ini mencakup pohon cemaratiga langkah pertama s
lebih lanjut
optik.
Angkae 2.3: Yang utaman langkah
Hak Cipta © Universitas Terbuka Malaysia (OUM)
ekor. Langkah
Machine Translated by Google
36 ÿ TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN
2.2
PEMANGKU KEPENTINGAN, AKTOR DAN PERAN
Dalam Topik 1 kami mencatat bahwa pemangku kepentingan adalah semua orang atau kelompok, baik internal
maupun eksternal organisasi Anda yang akan mempengaruhi atau terkena dampak proposal Anda.
Tentu saja ini termasuk orang-orang yang akan menggunakan sistem tersebut. Dalam UML, istilah untuk
pengguna adalah aktor namun kata ini dapat menimbulkan kebingungan. Kami tidak mengatakan seseorang
adalah aktor Hamlet; kami mengatakan bahwa seorang aktor memainkan peran Hamlet.
Cara berpikir lain tentang peran adalah memakai topi yang berbeda. Satu orang dapat memakai jabatan yang
berbeda, atau memainkan banyak peran berbeda seiring mereka menjalani hari atau suatu proses. Salah satu
contohnya adalah membuat dokumen atau laporan berukuran besar. Awalnya seseorang, sebut saja dia Alice,
otaknya membuang ide ke halaman secepat mungkin. Dia ingin membuat struktur kasar. Dia tidak tertarik pada
ejaan, tata bahasa, atau font. Setelah beberapa jam, dia berpindah ke peran lain, yaitu peran menulis. Di sini
dia mengetik seluruh kalimat. Dia menyertakan grafik dan judul. Dia prihatin tentang ejaan, tata bahasa, dan
font yang benar. Untuk melengkapi dokumen tersebut, ia meminta rekannya Ahmad dan Bernard untuk
mengkajinya. Mereka perlu menambahkan komentar ke dokumen tanpa mempengaruhi teks aslinya. Di atas
kertas, ini adalah coretan di pinggir salinan cetak. Terakhir, Alice mengambil komentar dari semua orang yang
berbeda untuk menghasilkan satu dokumen akhir (lihat Gambar 2.4).
Gambar 2.4: Orang dan peran „memakai topi‰
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN ÿ 37
2.2.1 Jenis Peran
Ada tiga macam peran atau aktor:
(a) Primer
Seseorang dalam peran ini secara langsung menggunakan sistem untuk memasukkan, melihat
proses atau mengekstrak informasi. Tergantung pada antarmuka pengguna, orang-orang ini
akan menggunakan keyboard, mouse, tombol pada mesin atau berbicara dengan sistem yang
diaktifkan dengan suara. Contoh dalam studi kasus ini adalah petugas check out dan petugas
stok di ruang belakang.
(b) Sekunder
Seseorang dalam peran ini tidak secara langsung menggunakan sistem, namun menggunakan
atau menghasilkan data untuk sistem. Contoh klasiknya adalah seseorang yang menerima
laporan dari suatu sistem, khususnya di departemen lain dalam organisasi. Orang ini mungkin
atau mungkin tidak mengakses sistem untuk mendapatkan laporan, namun merupakan
pengguna informasi. (Biasanya, peran ini diabaikan dalam analisis kebutuhan.) Contoh dalam
studi kasus ini adalah para manajer.
(c) Eksternal
Sistem apa pun yang menerima atau menghasilkan data untuk sistem tersebut adalah sistem
eksternal, misalnya sistem kantor pajak, bank, sistem rekening, dll.
Perhatikan bahwa taksonomi ini sedikit berbeda dari UML dan Larman (2002). Secara khusus, dalam
UML, pengguna dan sistem eksternal diperlakukan sama. Memang benar bahwa keduanya berada di
luar sistem, namun memperlakukan manusia dan komputer dengan cara yang sama tidak kondusif
untuk membangun sistem yang dapat digunakan. Lebih jauh lagi, pengalaman kami menunjukkan
bahwa kebutuhan aktor sekunder seringkali diabaikan. Seringkali kebutuhan akan pelaporan sudah
diketahui, namun alih-alih kebutuhan tersebut diperiksa dengan cermat, respons standarnya adalah
dengan menambahkan alat pelaporan pengguna akhir. Sangat jarang pendekatan sederhana ini dapat
memuaskan. Jika manajemen senior tidak menerima manfaat apa pun dari sistem, maka proyek
tersebut dapat dihentikan.
2.2.2 Perbedaan Peran
Pertanyaan yang perlu Anda tanyakan kepada seseorang yang memegang peran adalah:
(a) Apakah mereka tahu cara menggunakan komputer? Apakah mereka nyaman dengan a
antarmuka pengguna grafis?
(b) Apakah mereka memahami domainnya? (Untuk domain toko video, apakah orang tersebut
mengetahui cara peminjaman video, apakah mereka mengetahui cara kerja sistem penagihan
kartu kredit, atau apakah mereka anggota masyarakat?)
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
38 ÿ TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN
(c) Apakah mereka akan menerima pelatihan dalam menggunakan sistem baru?
(d) Bagaimana lingkungan kerja mereka? Apakah ada kebisingan atau cahaya yang cukup? Apakah banyak interupsi
dari orang lain? Apakah mereka harus dapat beralih di antara banyak aplikasi? Seberapa andalkah jaringan
tersebut?
(e) Frekuensi penggunaan. Apakah mereka akan menggunakan aplikasi tersebut setahun sekali, atau sebulan sekali
tujuh puluh kali sehari?
(f) Dalam melakukan pekerjaannya, apakah mereka mengacu pada formulir kertas atau sumber data lainnya?
(g) Mintalah mereka untuk mengurutkan satu atau lebih hal berikut: keandalan, kebenaran,
kepuasan, kemudahan penggunaan.
KEGIATAN 2.3
Berikut adalah dua peran yang sangat berbeda untuk dua sistem yang sangat berbeda.
Petugas untuk perusahaan investasi kecil. Perusahaan ini hanya memiliki 30 klien dan hanya ada
beberapa transaksi per hari, namun jumlah uang dalam setiap transaksi bisa besar.
Remaja di situs klub penggemar Kylie Minogue. Situs web ini memiliki foto, lirik, dan contoh lagu Kylie.
Terdapat fasilitas diskusi dan chatting online.
Untuk masing-masing peran, pertimbangkan apa yang penting bagi seseorang dalam peran tersebut dan tetapkan
prioritas (1, 2, 3, atau 4) untuk masing-masing peran tersebut. Anda tidak dapat menjadikan semuanya sebagai prioritas 1!
Petugas untuk
Investasi
Objektif
Perusahaan
Remaja di Kylie
Klub Penggemar Minogue
Situs web
Keandalan sistem, misalnya hasil
pencarian atau perhitungan sudah benar
Efisiensi, misalnya jumlah langkah
yang diperlukan minimal, sehingga
mengurangi human error
Kepuasan, misalnya pengalaman
menggunakan sistem yang
menyenangkan
Kecepatan, misalnya kecepatan menampilkan
informasi
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN ÿ 39
2.2.3 Menemukan Peran
Ada dua cara sederhana untuk mulai menemukan peran suatu sistem. Ini adalah melakukan
brainstorming daftar awal dan melihat jabatan yang ada.
(a) Lakukan Brainstorming untuk
Membuat Daftar Awal Baik Anda sendiri atau bersama anggota tim lainnya, cukup tuliskan namanama yang dapat Anda pikirkan. (Saat melakukan brainstorming, jangan khawatir untuk
mendapatkan nama terbaik untuk peran yang akan datang nanti.)
(b) Lihatlah Judul Pekerjaan yang Ada
Ini adalah awal yang baik, namun nama peran tersebut mungkin akan sangat berbeda dengan
jabatan yang ada karena:
(i) Uraian pekerjaan biasanya memerlukan beberapa peran. Misalnya, jabatan "penulis teknis"
dapat dibagi menjadi beberapa peran:
• pencari dokumen;
• pembaca dokumen;
• penulis dokumen; dan/atau
• peninjau dokumen.
Masing-masing peran ini akan memiliki sejumlah kasus penggunaan.
(ii) Judul pekerjaan yang ada biasanya bukan nama peran yang baik karena sudah mempunyai
banyak arti bagi penggunanya ÿ entah ada riwayat mengenai apa yang terkandung dalam
pekerjaan tersebut atau pekerjaan tersebut mempunyai komponen lain yang tidak terkait
dengan sistem baru.
(iii) Terdapat hubungan banyak-ke-banyak antara jabatan dan kasus penggunaan atau tugas.
Oleh karena itu, jabatan bisa menyesatkan.
Peringatan: Jika Anda melakukan analisis peran terlalu jauh, Anda akan mendapatkan peran yang
berbeda untuk setiap kasus penggunaan. Hal ini merupakan kebalikan dari memiliki satu peran, yang
disebut „pengguna‰ yang melakukan segalanya. Di antara kedua ekstrem ini terdapat serangkaian
peran yang berguna dan bisa diterapkan. Terkadang perlu waktu agak lama untuk menyatukannya. Jadi
mulailah dengan daftar awal peran dan berusaha mengidentifikasi kasus penggunaannya. Kemudian
kembalilah dan tinjau teladannya.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
40 ÿ TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN
Tabel 2.1 mungkin berguna untuk menyusun para aktor.
Tabel 2.1: Tabel Contoh untuk Penyusunan Aktor
Aktor
Nama Aktor
Jenis
Nama ini
harus bermakna
mungkin.
Judul
Primer
sekunder
Satu atau dua kalimat untuk
Hal ini berguna
menggambarkan aktor secara
atau
rinci
dalam berkomunikasi
dengan staf.
luar
Pentingnya
Aktor
Pekerjaan saat ini
Keterangan
Rendah,
sedang atau tinggi
Mungkin ada beberapa
jabatan untuk
setiap aktor, atau
mungkin ada satu jabatan
banyak aktor.
Terakhir, tetapkan tingkat kepentingan (tinggi, sedang, rendah) untuk masing-masing aktor. Ini
akan menentukan urutan Anda mulai mencari kasus penggunaan. (Tentu saja, seperti halnya
semua hal, setelah Anda melihatnya lebih dekat, kepentingannya mungkin berubah).
Untuk studi kasus POS NextGen yang diperkenalkan pada Topik 1, daftar awal pelakunya dapat
dilihat pada Tabel 2.2.
Tabel 2.2: Daftar Awal Aktor NextGen POS
Nama Aktor
Aktor
Jenis
Kasir
Utama
Keterangan
Menjual barang ke
pelanggan dan
Pekerjaan saat ini
Judul
Asisten toko
Pentingnya
Aktor
Tinggi
Pengawas tugas
mengumpulkan pembayaran
kode batang
Luar
pemindai
** Tidak yakin apakah ini
bagian dari sistem, atau
aktor eksternal
Tak dapat diterapkan
Sedang
Administrator Utama Belum banyak informasi?
Kontrol
inventaris
Luar
Sedang
Tidak berlaku,
tetapi
Sedang
bicaralah dengan gudang
Pengelola
Analis
Sekunder ** Diperlukan penyelidikan
lebih lanjut
Manajer toko
Sedang
Akuntan
Utama
** Diperlukan penyelidikan
lebih lanjut
Akuntan
Sedang
Hitung pajak yang terutang
Tak dapat diterapkan
Rendah
Kalkulator pajak Eksternal
ÿ
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN ÿ 41
Anda akan melihat bahwa daftar ini memiliki pertanyaan dan menunjukkan di mana lebih banyak pekerjaan yang
diperlukan. Ini normal.
Pekerjaan analisis selanjutnya pasti akan mengubah beberapa informasi ini, namun ini merupakan titik awal
yang baik. Perhatikan bahwa pemindai kode batang telah disertakan, tetapi uraiannya adalah pertanyaan yang
harus diselesaikan. Ini baik-baik saja. Ingatlah bahwa pengembangan berulang adalah tentang memulai dan
terus menyempurnakan serta mengembangkan pekerjaan sebelumnya.
KEGIATAN 2.4
Identifikasi kemungkinan aktor untuk sistem Video Victoria dan kategorikan
mereka sebagai primer, sekunder atau eksternal.
2.3
MENULIS KASUS PENGGUNAAN
Kami telah memiliki pemahaman yang baik tentang aktor (serta peran yang akan dimainkan aktor) dalam Use
Case Model. Aktor adalah entitas di luar sistem yang akan berinteraksi dengan sistem. Apa yang ada di dalam
sistem diwakili oleh use case dalam Use Case Model. Kasus penggunaan adalah cara untuk menemukan dan
mendokumentasikan persyaratan fungsional. Mereka menggambarkan perilaku sistem dari sudut pandang
pengguna. Kasus penggunaan ditulis dalam bahasa yang sederhana sehingga pengguna dan staf TI dapat
memahaminya. Setiap use case harus mencapai sesuatu yang berguna bagi pengguna. Bacaan selanjutnya
memberikan contoh use case singkat.
Kasus penggunaan mendefinisikan janji atau kontrak tentang bagaimana suatu sistem akan berperilaku (Larman,
2002).
Ada tiga jenis format untuk menulis kasus penggunaan. Format yang perlu diperhatikan tergantung pada
kebutuhan. Penjelasan ketiga jenis format use case tersebut diberikan sebagai berikut:
(a) Kasus penggunaan singkat memiliki ringkasan satu paragraf dan biasanya digunakan untuk skenario
keberhasilan utama. Berikut adalah contoh kasus penggunaan format singkat (Dimodifikasi Proses
Penjualan
dari Larman, 2002):
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
42 ÿ TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN
Proses Penjualan:
1. Pelanggan tiba di kasir POS dengan membawa barang dan/atau jasa ke
pembelian.
2. Kasir memulai penjualan baru.
3. Kasir memasukkan pengenal barang.
4. Sistem mencatat item baris penjualan dan menyajikan deskripsi item, harga, dan total
berjalan.
5. Harga dihitung dari seperangkat aturan harga.
6. Sistem menyajikan total pajak yang dihitung.
7. Kasir memberitahukan jumlah totalnya kepada Pelanggan dan meminta pembayaran.
8. Pelanggan membayar dan Sistem menangani pembayaran.
9. Sistem mencatat penjualan yang telah selesai dan mengirimkan informasi penjualan
dan pembayaran ke sistem akuntansi eksternal (untuk akuntansi dan komisi) dan
sistem inventaris (untuk memperbarui inventaris).
10. Sistem menyajikan tanda terima. Pelanggan pergi dengan membawa tanda terima dan barang (jika
setiap).
(b) Kasus penggunaan kasual merupakan paragraf informal yang memiliki banyak paragraf yang
mencakup berbagai skenario. Pengembalian Pegangan yang ditunjukkan pada Bacaan 2.2
adalah contohnya.
(c) Pakaian lengkap terlengkap yang memperlihatkan semua langkah dan variasinya. Ini memiliki
bagian pendukung, seperti prasyarat dan jaminan keberhasilan. Contoh kasus penggunaan
lengkap untuk studi kasus NextGen dapat ditemukan di http://www3.itu.edu.tr/~buzluca/ymt/
ornek_uc.pdf.
Namun, pembahasan detail tentang use case lengkap berada di luar silabus.
Menulis use case, sampai batas tertentu, seperti menulis laporan, dan seperti yang Anda ketahui
jika Anda pernah menulis laporan, akan lebih mudah jika Anda bisa mengikuti beberapa jenis
format. Sebagian besar perusahaan dan organisasi memiliki templat laporan untuk dijadikan acuan
oleh orang-orang. Demikian pula, untuk kasus penggunaan, terdapat templat yang dapat dirujuk
oleh analis sistem. Salah satu templat kasus penggunaan paling populer dikembangkan oleh
Alistair Cockburn. Versi lengkap dan penjelasan rinci tentang templat tersedia di http://
members.aol.com/acockburn/papers/uctempla.doc. Templat kasus penggunaan tidak tercakup
dalam kursus ini.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN ÿ 43
KEGIATAN 2.5
1. Tulis kasus penggunaan "pinjam video".
2. Menurut Anda mengapa ini merupakan kasus penggunaan yang baik?
Dalam Latihan 2.5 kami memberi Anda nama sebuah use case, tapi tentu saja, biasanya Anda harus
mengerjakan sendiri use case tersebut. Memutuskan di mana satu kasus penggunaan berakhir dan kasus
penggunaan lainnya dimulai memerlukan sedikit latihan. Saat Anda pertama kali mulai menuliskan kemungkinan
kasus penggunaan, jangan terlalu khawatir untuk memperbaikinya. Setelah Anda menulis kasus penggunaan
lebih jauh, Anda akan dapat menentukan batasannya.
KEGIATAN 2.6
Di Aktivitas 2.4, Anda membuat daftar aktor untuk Video Victoria. Kamu sekarang
perlu menyusun daftar aktor, dari yang paling penting hingga yang paling tidak penting
penting, dan buat daftar kasus penggunaannya. Jangan terlalu khawatir
menyempurnakan nama kasus penggunaan. Tulis saja. Nanti
Anda dapat mengubah nama, menghapus kasus penggunaan, atau menambahkan kasus penggunaan.
KEGIATAN 2.7
Dengan menggunakan daftar Anda dari Aktivitas 2.6, pilih penggunaan terpenting berikutnya
kasus aktor yang paling penting dan tulis format singkat kasus penggunaan tersebut.
Sekarang pilih use case lain dan tulis juga dalam format singkat.
Jika semua aktivitas pengembangan sistem didorong oleh bisnis, maka pembuat persyaratan harus bertujuan
untuk mencapai tujuan yang akan memberikan nilai bagi organisasi. Ini berarti bahwa kasus penggunaan:
(a) harus memberikan sesuatu yang bernilai kepada seorang aktor;
(b) biasanya mewakili bagian utama dari fungsionalitas yang lengkap
mulai sampai akhir;
(c) mewakili tujuan interaksi antara aktor dan sistem; tujuan mewakili tujuan yang bermakna dan terukur bagi
aktor; Dan
(d) mencatat sekumpulan jalur (skenario) yang mengambil aktor dari peristiwa pemicu
(awal kasus penggunaan) ke tujuan (skenario keberhasilan).
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
44 ÿ TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN
(e) Mencatat serangkaian skenario yang melintasi aktor dari peristiwa pemicu menuju suatu tujuan
namun gagal mencapai tujuan (skenario alternatif). Format untuk menulis skenario alternatif
adalah sebagai berikut:
kondisi: penanganan
Contoh skenario alternatif tahun 2002)
berdasarkan format di atas:
Proses Penjualan diberikan di bawah ini (Larman,
3a: Pengidentifikasi item tidak valid ditemukan:
kondisi
1. Sistem memberi sinyal kesalahan dan menolak entri
penanganan
3b: Ada beberapa item yang sama: 1. Kasir
dapat memasukkan pengenal kategori item dan jumlahnya
Tuliskan kondisi sebagai sesuatu yang dapat dideteksi oleh sistem atau aktor. Contoh di atas
kondisi
hanya memiliki satu untuk . Pasti ada lebih dari satu kondisi
penanganan
penanganan .
Ingatlah bahwa sebuah use case mungkin memiliki skenario keberhasilan utama dan beberapa
skenario alternatif. Terkadang, ketika kita memiliki sistem yang besar dan rumit untuk
dikembangkan, terdapat banyak skenario yang berbeda. Mustahil untuk menemukan semua
skenario yang mungkin terjadi sejak awal.
Ingat, di UP, semuanya dilakukan secara berulang. Oleh karena itu, ketika Anda pertama kali
mulai menulis kasus penggunaan untuk suatu sistem, yang terbaik adalah mengabaikan semua
skenario alternatif dan hanya memikirkan segala sesuatunya berjalan dengan baik ÿ „skenario
hari cerah‰. Skenario alternatif dapat ditambahkan pada iterasi mendatang. Tentu saja, skenario
yang berhasil juga dapat direvisi dan diubah pada tahap selanjutnya.
AKTIVITAS 2.8
Kami telah menulis skenario keberhasilan utama untuk „meminjam video‰
kasus penggunaan di Aktivitas 2.5. Cobalah untuk memikirkan beberapa skenario alternatif dan
menyajikannya dalam format singkat yang mirip dengan skenario keberhasilan utama.
Bandingkan jawaban Anda dengan teman kursus Anda di myVLE.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN ÿ 45
Tujuan utama UP adalah membantu pengembang sistem untuk membangun sistemnya secara sistematis.
Pengembangan sistem yang buruk cenderung dilakukan oleh pengembang yang tidak dapat menilai apa
yang harus mereka lakukan pada setiap tahap dari keseluruhan siklus pengembangan. Kesalahan umum
adalah terjun ke desain sistem sebelum analisis kebutuhan yang baik tersedia. Oleh karena itu, dalam
kerangka UP, pendekatan kasus penggunaan kotak hitam biasanya diadopsi untuk membantu pengembang
sistem menghindari kesalahan yang sama dua kali. Sekarang mari kita bahas istilah tersebut. Sesuatu
disebut kotak hitam jika kita tidak bisa melihat cara kerjanya. Misalnya, dari sudut pandang pengemudi
mobil, mobil adalah kotak hitam. Mobil itu bergerak dengan benar atau tidak. Jika ada masalah, maka
montir mobil datang dan dengan tampilan kotak putih, mengangkat kap mobil dan melihat mesin serta
bagian dalamnya. Oleh karena itu, dalam pendekatan black-box dalam penulisan kasus penggunaan, kita
tidak peduli tentang bagaimana sistem akan melakukan tugasnya tetapi hanya fokus pada apa yang
diharapkan dari sistem.
Dengan kata lain, kami hanya fokus pada tanggung jawab sistem. Contoh kasus penggunaan kotak hitam
ditunjukkan di bawah ini:
Gaya Kotak Hitam
Sistem memperbarui nilai siswa
Bukan Gaya Kotak Hitam
Sistem menulis tanda baru ke database
Sistem menghasilkan pernyataan SQL UPDATE
untuk tugas tersebut
Terkadang kebingungan masih muncul meskipun kita mengadopsi pendekatan kotak hitam, karena orang
yang berbeda mempunyai pemahaman yang berbeda tentang „apa yang dilakukan sistem‰. Misalnya,
seorang kasir mungkin menganggap tujuannya sebagai „login‰, namun sebenarnya ini hanyalah
mekanisme yang mencapai tujuan tingkat yang lebih tinggi yaitu mengidentifikasi dan mengautentikasi
dirinya.
Saat menulis kasus penggunaan, jauhkan antarmuka pengguna dan fokus hanya pada aktor
maksud.
AKTIVITAS 2.9
Sekarang ambil tiga kasus penggunaan dari Aktivitas 2.5 dan 2.7 dan tulis ulang
dalam format dua kolom yang penting. (Ya, menulis kasus penggunaan itu sulit
berhasil, tetapi semakin banyak Anda menulis, semakin mudah jadinya. Hal ini tidak cukup baik untuk dilakukan
lihat saja jawabannya. Anda harus berlatih). Pokoknya jawabannya bisa
diperoleh pada akhir modul.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
46 ÿ TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN
2.3.1 Tujuan dan Tingkat Kasus Penggunaan
Sekarang Anda sudah mempunyai gambaran tentang apa itu use case dan, secara umum, tahu cara penulisannya. Sekarang,
mari kita mundur sejenak dan mengajukan pertanyaan mendasar: Apa yang seharusnya menjadi tujuan dari use case?
Seperti yang kami sebutkan sebelumnya, pengguna yang berbeda memiliki tujuan yang berbeda. Misalnya, manajer umum
sebuah toko ritel mengharapkan sistem ritel di perusahaannya untuk menyederhanakan seluruh proses ritel. Sebaliknya,
kasir mungkin mengharapkan sistem yang sama untuk membaca barcode barang dengan benar dan efisien. Nah, manakah
dari dua persyaratan berikut yang harus diubah menjadi kasus penggunaan? Faktanya, tidak satu pun dari keduanya yang
bisa menjadi kasus penggunaan yang baik.
Sasaran manajer umum berada pada tingkat yang terlalu tinggi sedangkan sasaran kasir terlalu rendah. Jadi, tingkat sasaran
pengguna apa yang dapat diubah menjadi kasus penggunaan? Pedoman umumnya adalah dengan melihat Proses Bisnis
Dasar (EBP). Bacaan 2.1 akan menjelaskan kepada Anda konsep EBP. Ini juga memberikan contoh yang sangat jelas
tentang bagaimana seorang analis sistem menyelidiki tujuan pengguna kasir melalui serangkaian pertanyaan dan
mengidentifikasi tingkat tujuan yang sesuai untuk menulis kasus penggunaan.
Sekarang unduh Reading 2.1 dari myVLE untuk mempelajari tentang tujuan dan cakupan penggunaan
kasus.
Sistem informasi adalah entitas abstrak yang terdiri dari perangkat lunak, perangkat keras, dan aplikasi. Namun, meskipun
kita tidak dapat memvisualisasikan keseluruhan sistem informasi, untuk keperluan kasus penggunaan, kita perlu menentukan
batasannya. Ibarat membangun rumah, kita perlu melakukan survey tanah untuk menentukan batas tapak rumah yang akan
dibangun. Batasan sistem yang jelas membantu dalam mengidentifikasi aktor yang tepat untuk menggunakan kasus, yang
pada gilirannya, membantu analis sistem untuk mencapai tujuan.
Prosedur empat langkah yang diusulkan untuk mendefinisikan kasus penggunaan tercantum di bawah ini:
(a) menentukan batas sistem yang tepat;
(b) mengidentifikasi aktor-aktor utama;
(c) mengidentifikasi tujuan para aktor; Dan
(d) mendefinisikan dan memberi nama kasus penggunaan.
Sekarang unduh Reading 2.2 dari myVLE untuk mempelajari prosedur empat langkah untuk mendefinisikan kasus
penggunaan seperti yang tercantum di atas.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN ÿ 47
KEGIATAN 2.10
Untuk Video Victoria, hingga saat ini kami telah mencoba mengidentifikasi aktor dan
beberapa kasus penggunaan singkat. Namun, semua ini diproduksi oleh kami
imajinasi. Dalam sistem nyata, cara yang tepat untuk melakukan persyaratan
analisis adalah melakukan kombinasi dari banyak kegiatan seperti:
(a) Membaca dokumentasi apa pun yang telah dikumpulkan;
(b) Lihatlah sistem apa pun yang ada saat ini. Lihatlah layar dan
laporan. Lihat apakah Anda dapat melacak beberapa contoh nyata sepenuhnya
melalui. Misalnya, untuk sistem asuransi, Anda bisa melihat caranya
kebijakan dibuat, dan kemudian bagaimana klaim dapat diproses;
Dan
(c) Berbicara dengan pihak-pihak yang berkepentingan. Biasanya Anda memulai dengan
mengadakan beberapa lokakarya persyaratan pengguna. Gunakan inisial
analisis aktor berfungsi sebagai panduan tentang siapa yang harus hadir
bengkel. Untuk lokakarya pertama, yang terbaik adalah melibatkan lebih banyak orang
daripada menguranginya karena Anda memerlukan jangkauan pandangan seluas mungkin.
Nantinya, Anda dapat mengadakan lokakarya yang jauh lebih kecil untuk dikonsentrasikan
daerah tertentu.
Siapkan daftar pertanyaan yang ingin Anda tanyakan kepada berbagai orang
dari Video Victoria.
Penting bagi Anda untuk memahami Model Kasus Penggunaan karena ini adalah elemen penting dalam
Analisis & Desain Sistem Berorientasi Objek (OOSAD) dan merupakan salah satu tugas paling awal
dalam keseluruhan proyek pengembangan sistem. Keberhasilan proyek di masa depan bergantung pada
penggunaan kasus yang tepat. Karena terkadang bermanfaat untuk mendekati suatu topik dari sudut
pandang yang berbeda, kami ingin Anda memperkuat pemahaman Anda tentang Model Kasus
Penggunaan dengan membaca bacaan berikutnya dari Cockburn:
http://alistair.cockburn.us/structuring+use+cases+with+goals
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
48 ÿ TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN
2.3.2 Format Penulisan Use Case
Ada tiga jenis format untuk menulis kasus penggunaan. Format yang perlu diperhatikan tergantung
pada kebutuhan. Penjelasan untuk ketiga jenis format kasus penggunaan ini diberikan di bawah
ini:
(a) Kasus penggunaan singkat memiliki ringkasan satu paragraf dan biasanya merupakan contoh
Proses Penjualan yang ditunjukkan pada
untuk skenario keberhasilan utama seperti
Reading 2.1.
(b) Kasus penggunaan kasual merupakan paragraf informal yang memiliki banyak paragraf yang
mencakup berbagai skenario. Pengembalian Pegangan yang ditunjukkan pada Bacaan
2.2 adalah contohnya.
(c) Pakaian lengkap format terlengkap yang menunjukkan semua langkah dan variasi. Ini memiliki
bagian pendukung, seperti prasyarat dan jaminan keberhasilan.
Menulis use case, sampai batas tertentu, seperti menulis laporan dan seperti yang Anda ketahui
jika Anda pernah menulis laporan, akan jauh lebih mudah jika Anda bisa mengikuti beberapa
jenis format. Sebagian besar perusahaan dan organisasi memiliki templat laporan untuk dijadikan
acuan oleh orang-orang. Demikian pula, untuk kasus penggunaan, terdapat templat yang dapat
dirujuk oleh analis sistem. Salah satu templat kasus penggunaan paling populer dikembangkan
oleh Alistair Cockburn. Versi lengkap dan penjelasan rinci tentang templat tersedia di http://
alistair.cockburn.us/Basic+use+case+template. Templat kasus penggunaan tidak dibahas dalam
kursus ini.
Bab e-book berikut dari perpustakaan digital OUM (Books24x7) berisi penjelasan lebih lanjut dan
studi kasus „Mesin Soda‰ tentang kasus penggunaan. Anda wajib membaca bab ini.
Schmuller, Joseph. "Jam 6 - Memperkenalkan Kasus Penggunaan". Sams Ajarkan Diri Anda
UML dalam 24 Jam. Sam. © 1999. Buku24x7. http://common.books24x7.com/toc.aspx? buku
buku=414
Kami akan meninjau kembali studi kasus „Mesin Soda‰ di Topik 4 dan Topik 5
2.3.3 Diagram Kasus Penggunaan
„Sebuah gambar melukiskan ribuan kata‰: terkadang ilustrasi visual dapat mewakili ide-ide rumit
dengan cara yang sederhana dan mudah. Diagram use case dapat memberikan pandangan
statis dari suatu sistem sehingga memungkinkan kita memiliki gambaran umum tentang sistem
dan hubungan antara use case serta aktor-aktor sistem.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN ÿ 49
Gambar 2.5 merupakan notasi UML sederhana untuk menggambarkan suatu use case.
Gambar 2.5: Notasi use case diagram
Kumpulan diagram use case akan membentuk konteks diagram use case yang menunjukkan ruang
lingkup sistem dan hubungan antara aktor dan use case. Ini berfungsi sebagai ringkasan diagram perilaku
sistem.
Menurut Larman (2002), diagram use case hanya bersifat sekunder dalam penulisan use case.
Pengembang sistem tidak boleh menghabiskan terlalu banyak waktu untuk menggambar diagram use
case. Menulis teks use case harus menjadi fokus utama.
Sekarang unduh Reading 2.3 dari myVLE untuk mempelajari diagram kasus penggunaan secara detail.
KEGIATAN 2.11
Dengan menggunakan contoh diagram use case yang ditunjukkan pada Gambar 2.5
Membaca 2.3 sebagai panduan, gambarkan diagram use case untuk Video Victoria.
2.3.4 Diagram Aktivitas
Untuk banyak aplikasi, sangatlah penting untuk melihat bagaimana semua kasus penggunaan cocok
untuk mencapai sesuatu secara keseluruhan. Hal ini terutama berlaku ketika ada banyak orang berbeda
yang terlibat dalam keseluruhan aktivitas. Misalnya, salah satu tantangan utama bagi bisnis yang menjual
produk melalui Internet adalah menyelesaikan seluruh sisi pemenuhannya. Mengambil pesanan dan
uangnya adalah hal yang mudah! UML memiliki notasi yang disebut diagram aktivitas. Diagram ini, dalam
banyak aspek, sangat mirip dengan diagram alir. Mereka dapat digunakan pada berbagai tahap
pengembangan, mulai dari persyaratan hingga pemrograman terperinci.
Diagram berikut menunjukkan bagaimana berbagai aktor menggunakan use case mereka sendiri untuk
mencapai keseluruhan tugas. Diagram tersebut memiliki „jalur berenang‰ untuk masing-masing aktor
yang berbeda.
Setiap sistem berbeda sehingga Anda harus memutuskan apakah diagram aktivitas berguna atau tidak.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
50 ÿ ATAS
REMENT
GAMBAR 2 DIPERLUKAN
DAN U
KASUS PENGGUNAAN
Gambar 22.6: Sebuah contoh le suatu kegiatan kamu diagram
AKTIVVITA 2.12
Apakah
pikirkan suatu tindakan
p jelaskan caranya wa
diagram aktivitas saya akan membantu
Anda kasus penggunaan untuk Vic
Video toria
Jika demikian, thdan
s sistem cocok t
Catatan:
Kami tidak mencoba menggambar
menggambarnya.
N
e dari mereka itu
sistem ole, bu
tapi hanya beberapa
membuat smasuk akal bagi kita
berfungsi sebagai siapa
ole.
WHO
bagian
dari
keseluruhan?
bersama-sama untuk atau
fo
semua
kasus penggunaan
di membuat proses itu
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN ÿ 51
2.3.5 Potensi Masalah pada Kasus Penggunaan
Menulis kasus penggunaan yang efektif bukanlah perkara sederhana dan ada sejumlah kendala yang
harus dihindari. Berikut sepuluh hal yang diidentifikasi oleh Lilly (1999):
(a) Batas sistem tidak terdefinisi atau tidak tetap;
(b) Kasus penggunaan ditulis dari sudut pandang sistem;
(c) Nama aktor tidak konsisten;
(d) Ada terlalu banyak kasus penggunaan;
(e) Hubungan aktor-ke-use case menyerupai jaring laba-laba;
(f) Spesifikasi kasus penggunaan terlalu panjang;
(g) Spesifikasi kasus penggunaan membingungkan;
(h) Kasus penggunaan tidak menjelaskan hak fungsional dengan benar;
(i) Pelanggan tidak memahami kasus penggunaan; Dan
(j) Kasus penggunaan tidak pernah selesai.
Dalam menulis daftar ini, Lilly (1999) tidak menentang use case, namun mencoba mengingatkan
pendatang baru terhadap potensi masalah dan menyarankan cara untuk menghindarinya. Dia
menyarankan:
(a) Definisikan batas sistem secara eksplisit. Ini memperjelas apa yang ada di dalamnya
sistem dan apa yang ada di luar sistem;
(b) Manfaatkan templat standar untuk mendokumentasikan spesifikasi kasus penggunaan Anda. Jika
tim menggunakan templat, ini akan membantu komunikasi antar anggota tim serta membantu
pendatang baru untuk memulai;
(c) Saat menulis use case, fokuslah pada tujuan para aktor. Hal ini akan membantu Anda menemukan
kasus penggunaan dari sudut pandang pengguna dan tetap fokus pada fungsi utama sistem;
Dan
(d) Jangan menjadikan spesifikasi kasus penggunaan sama dengan desain antarmuka pengguna.
Anda dapat menggunakan representasi antarmuka pengguna dengan fidelitas rendah, namun
karena desain antarmuka pengguna sangat bergantung pada perubahan khusus desain,
sebaiknya jangan menyertakannya sebagai bagian dari persyaratan jika Anda ingin membuatnya
ditandatangani lebih awal daripada nanti.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
52 ÿ TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN
Untuk membantu menangkap potensi masalah, Lilly menyarankan agar Anda meninjau Model Kasus Penggunaan
Anda, diagram dan spesifikasinya secara bertahap dengan tim pengembangan, klien, dan pengguna. Mulailah
dengan meninjau diagram use-case Anda sebelum Anda menentukan detail use case, periksa apakah batasan
sistem telah didefinisikan dengan jelas, tidak ada aktor yang terlewatkan, dan use case fokus pada tujuan
pengguna.
KEGIATAN 2.13
Bedakan antara kasus penggunaan dan pernyataan persyaratan. Memeriksa
jawaban Anda di <http://ootips.org/use-cases-vs-requirements.html>
2.3.6 Cara Menangani Ratusan Kasus Penggunaan
Studi kasus yang sedang Anda kerjakan sengaja dipilih menjadi aplikasi kecil. Jadi, Anda mungkin bertanya-tanya
bagaimana proses ini 'ditingkatkan' untuk memenuhi sistem yang lebih besar yang mungkin memiliki 200+ kasus
penggunaan. Kuncinya adalah mengatur kasus penggunaan sehingga tim dapat memahaminya. Salah satu teknik
spesifiknya adalah dengan mengatur use case ke dalam kelompok atau paket.
Paket UML adalah mekanisme untuk mengelompokkan apa pun menjadi satu. Jadi use case package merupakan
kumpulan use case, aktor bahkan paket use case lainnya untuk menyusun model use case dengan membaginya
menjadi bagian-bagian yang lebih kecil. Jadi, daripada mencoba memahami 200+ kasus penggunaan, tim mungkin
hanya perlu memahami 20 paket kasus penggunaan. Oleh karena itu, masing-masing anggota tim perlu memahami
detail beberapa paket kasus penggunaan.
Memutuskan paket untuk suatu sistem memerlukan sedikit pengalaman dan umumnya terdapat beberapa
pendekatan yang valid untuk satu sistem. Beberapa kemungkinan untuk mengemas kasus penggunaan tercantum
di bawah ini:
(a) Berdasarkan area fungsional. Misalnya, letakkan segala sesuatu yang berkaitan dengan uang dalam satu
paket, dan inventaris di paket lain.
(b) Oleh aktor. Misalnya, letakkan semua kasus penggunaan kasir dalam satu paket.
(c) Berdasarkan "gaya" kasus penggunaan. Misalnya, letakkan semua kasus penggunaan gaya pengaturan atau
pemeliharaan sederhana dalam satu paket.
(d) Berdasarkan kepentingan atau pengulangannya. Misalnya, semua kasus penggunaan yang akan dilakukan
dibangun dulu bisa dalam satu paket.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
DAN
D KASUS PENGGUNAAN
KE
PERSYARATAN OPICUIREMENT
2
ÿ 53
N. Untuk ujian Sederhananya, semua
kasus penggunaan
implementasi
itu del
(e) Secara fisik im
ases
diakses d melalui
dijalani melalui th
dia Web ada di n satu paket
ge, dan gunakan c
heakantor iklan com puter berada di paket
a
lain
usia.
Umum
kasus penggunaan
tolong mendekat itu yang terbaik. Desember
hanya kombinasition multip
menyebutkan
sebuah
kolaboratif
sudah ada usaha di antara keduanya
antara
penggunaan
analis
eh, persyaratannya
paketnya s biasanya a
desain basis datapengacau dan itue manajer
, teknisnya
al arsitek, hal mungkin d
kemarahan,
proyek
R.
UML
Notasi L untuk paket ra adalah di folder. Ho
Namun,, seperti mereka
ditekankan
lebih penting dari diagram
t
dia menggunakan kasuslebih
i
ea
. Seringkali a
rlier, teks t
kasus penggunaan
penting
kasusnya, ikutimenikah dengan daftar ojika
hanya sebagai deskripsi singkation kegunaannya
paket
termasuk
kegunaannya
kasus tha di terdiri dari t menggunakan paket.
Secara opsional, saya
diagram kasus m dari
kasus penggunaan
s (lihat Gambargambar 2.7).
Gambar 2.7: Kasus penggunaan hal
kemasan
2.4
CAPTU
URING R PERALATAN
MENS I ITERATIV
VELY
Tt
Topik
Seperti yang Anda pelajari di semua
kegiatan dalam kesatuan
1 ,
proses ed masuktermasuk
s, akan selesai tidak secara berulang
persyaratan
analisis
kamu. Seluruh proses hal
memperbaiki
era. Itu
kasus
menulis ting ini digunakan untuk
penggunaan
beberapa
ini mungkin
hal
ta
pekerjaan dan
kasus memiliki
tion
s membentang bo
lainnya awal mulanya
saja
dan elab
fase borasi
ch konstanta
diselesaikan un sampai kita bereaksi
kamu tidak menjadi rekan
pekerjaan f
se dari UP
P. Mungkin
fase truk
as. Distribusi
untuk kebutuhan saya
analisis entitas dan kasus penggunaanes
menulis thr
pada
kondisi
ch tergantung o
ini
sepanjang
ion dan
ransum dan halfase di UP sangat banyak
kebutuhanf sistem d
pengembangan itu sendiri serta pekerjaan
ng gaya
e
tim manajemen.
H
Namun,
karena pekerjaan
pedoman,
kemarahan
sebagian
akan
besar
dilakukan
selama ini
pengembangan
sistem
t dari persyaratan
seorang analisis
gu umum
iterasi
s di elabo
fase ransum.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
54 ÿ TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN
Khususnya pada sistem yang besar, kuncinya adalah mengidentifikasi semua
secara arsitektural
kasus penggunaan yang signifikan kasus sedini mungkin dan membiarkan kasus penggunaan yang kurang
penting untuk dibahas nanti. Signifikan secara arsitektural di sini berarti semua fungsi penting dari
sistem. Kasus penggunaan sangat penting dan penting dalam Proses Terpadu (Larman, 2002).
Selama analisis persyaratan, kasus penggunaan adalah produk utama. Namun, seperti yang kami
catat sebelumnya, kasus penggunaan memenuhi persyaratan fungsional sistem. Seperti yang Anda
ingat, ada juga persyaratan non-fungsional yang perlu diidentifikasi. Di samping kasus penggunaan,
ada tiga artefak lagi dalam alur kerja persyaratan – visi, spesifikasi tambahan, dan glosarium.
Ketiga artefak ini menangkap persyaratan sistem lain yang tidak dapat ditangkap dalam kasus
penggunaan. Spesifikasi tambahan mencakup persyaratan non-fungsional lainnya dalam kategori
URPS+ seperti dokumentasi, pengemasan, dukungan, persyaratan perizinan, dll. Visi tersebut
mungkin merupakan dokumen tingkat tertinggi proyek, yang memberikan gambaran luas tentang
tujuan dan kebutuhan bisnis proyek. proyek dan bagaimana sistem yang diusulkan akan terlihat. Ini
menetapkan tujuan akhir proyek dari perspektif bisnis organisasi. Glosarium ini terutama berfungsi
sebagai kamus data untuk keseluruhan proyek pengembangan sistem. Ini dengan jelas mendefinisikan
semua istilah teknis dalam konteks pengembangan sistem untuk menghindari masalah komunikasi
dan ambiguitas yang mungkin timbul selama keseluruhan proses pengembangan.
Pembahasan rinci tentang visi, spesifikasi tambahan, dan glosarium tidak termasuk dalam cakupan
kursus ini.
• Setiap proyek pengembangan sistem dimulai dengan analisis kebutuhan. Mendapatkan persyaratan
yang tepat sangat penting untuk keberhasilan pengembangan sistem terutama untuk sistem
yang besar dan kompleks serta dalam lingkungan bisnis yang berubah dengan cepat.
Berbeda dengan siklus hidup pengembangan sistem air terjun tradisional (di mana analisis
persyaratan dilakukan dan diselesaikan sebelum tahap desain dan implementasi), model UP
memiliki alur kerja (disiplin) persyaratan yang diperluas ke seluruh proses pengembangan
sistem. Dengan kata lain, analisis kebutuhan dilakukan secara iteratif.
• Berbagai jenis persyaratan dikategorikan sebagai fungsional atau non-fungsional menurut model
FURPS+. Dalam konteks UP, penulisan persyaratan didasarkan pada model use case.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
DAN
D KASUS PENGGUNAAN
KE
PERSYARATAN OPICUIREMENT
2
• kamu
ÿ 55
mod kasus penggunaan
del
termasuk t identitasnya
asi aktor
s, tujuan mereka dan
ases.
Kesenangan
kemarahan
persyaratan nasional
ditangkap dalam use case dia
ca
kasus S. Kadang-kadang,,
membantu ke bawahtand
agram bisa b terbiasa dengan dia
lebih dari itu
aliran
ev
ventilasi
dan
hubungan antara
semua gambar rs sistem, t
menulispenggunaan
aktor dan menggunakan cas
se.
• Lainnya eh tidak berfungsipersyaratan pribadi
dikirim ke tempat lain
eh artefak seperti itu
ch karena
persyaratannya sudah ditentukan
visio aktif, supel
spesifikasi masukikasi dan g
s membentuk arti fakta di re
kasus penggunaan
Glosarium. Itu
artefak ini bersama dengan
alur kerja peralatan.
Aktor
Kita
se kasus
ment
Fungsi persyaratan pribadi
Kita
se kasus aktivitaskamu diagram
Non-fu
saya
Kita
lihat diagram kasus
perlengkapan
persyaratan nasional
Peran
Konstan
Kita
se paket kasus
ya
untuk
Siap ing, MA:
LAD (1999
9). Perangkat lunak untuk
perawatan
rinci
ddison-Wesley kamu. (Memberikan iklan
ment penggunaankasus penggunaan untuk
o merancang
itu antarmuka pengguna
ce. Lihat juga th situs web pewaris <www.foruse.
<
.com>)
Lockwood, L
tine, LL, & Ad
W menulis
Efek
ayam jantan
rn, A. (2002).
menggunakan.
kasus penggunaan aktif
S.
Boston, MA J: Addison W
Eriksson n, DIA, & Pe
S pemodelan
enkus, M. (20 000). Bisnis
rk.
pola di tempat kerja
New York k, NY: Wiley
. (Sampul ini
menepuk
e model kasus seperti saat ini tidak ada di bagian atas foto.)
ini
Wesley.
w
dengan UML ÿ
B
Bisnis
sampai batas tertentu
nsions
menggunakan
Larman,
C.(2002).
Hasemua.
Lilly, S.(
L dan pola
menerapkan UML
Aplikasi
(1999). Ambil
Bagaimana
Hindari
ToA UseCas
diambil dari: htt tp://www.ap
S. Sadd Atas
sungai kecil, NJ:
pi.adm.br/GR
RS/referensi
sePitfalls.pdf
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Pembantu tukang
sebagai/
Machine Translated by Google
56 ÿ TOPIK 2 PERSYARATAN DAN KASUS PENGGUNAAN
Robertson, S., & Robertson, J. (1999). Mengelola persyaratan. Menguasai
proses persyaratan.
Addison-Wesley. (Lihat juga situs web mereka
untuk templat persyaratan, <http://www.atlsysguild.com/GuildSite/Robs/
Template.html>
Zachman, J. Kerangka Zachman. Diperoleh dari: http://www.zachman
international.com (Pilih „Framework‰ dari menu sebelah kiri. Zachman
Framework memberikan gambaran lengkap tentang persyaratan dari
perspektif perusahaan.)
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
Tema
3
ÿ Berorientasi Objek
Pemodelan
HASIL BELAJAR
Pada akhir topik ini, Anda seharusnya mampu:
1. Menentukan langkah-langkah elaborasi; 2.
Menerapkan diagram urutan sistem; 3. Menjelaskan
tujuan pemodelan domain; 4. Menjelaskan apa itu kelas
konseptual; Daftar teknik untuk menemukan kelas
5.
konseptual;
6. Mendefinisikan istilah asosiasi dan atribut;
7. Gambarlah diagram kelas domain untuk domain tertentu, menggunakan metode yang benar
Notasi diagram kelas UML; Dan
8. Mendiskusikan permasalahan penerapan UML pada berbagai perspektif dan
model dan menjelaskan apa yang dimaksud dengan kesenjangan representasi.
ÿ PENDAHULUAN
Dari Topik 2 kami telah mendefinisikan persyaratan sistem kami sampai tingkat tertentu.
Mudah-mudahan kita memahami dengan jelas ruang lingkupnya (yakni, apa yang disertakan) dan mempunyai
beberapa kasus penggunaan dan mungkin diagram kasus penggunaan yang telah ditulis untuk bagian-bagian
sistem.
Sampai saat ini belum ada yang berorientasi objek dalam materi. Kita bisa menulis kasus penggunaan dan
kemudian melanjutkan dengan cara yang tidak berorientasi objek. Pada topik ini, kita memulai pemodelan
berorientasi objek yang akan berlanjut untuk beberapa topik. Meskipun materi disajikan kepada Anda secara
berurutan, pada kenyataannya pemodelan berorientasi objek terjadi secara paralel dengan penulisan use
case.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
58 ÿ TOPIK 3 PEMODELAN BERORIENTASI OBJEK
Topik ini membahas tentang pemodelan domain. Mengapa kita melakukan ini? Hal ini karena
kita perlu mengkonfirmasi pemahaman kita tentang domain dan ruang lingkup masalahnya.
Dalam beberapa kasus, pengembang perangkat lunak atau analis sistem telah memahami
domain tersebut, namun dalam banyak kasus masih ada beberapa pembelajaran yang harus
dilakukan. Di bidang spesialis tertentu, seperti keuangan, desainer TI diharapkan mengetahui
banyak tentang domain keuangan. Meskipun teorinya mungkin terlihat cukup mudah, Anda
perlu berlatih melalui aktivitas dan tutorial. Pada akhir topik ini Anda akan memiliki model
domain untuk Video Victoria.
3.1
DARI AWAL SAMPAI ELABORASI
Topik ini, yang berfokus pada pemodelan domain, memberikan pertemuan pertama Anda
dengan pemodelan berorientasi objek. Sebelum membahasnya secara detail, mari kita
periksa di mana posisi kita sekarang di UP. Ingatlah bahwa UP memiliki dua aspek: fase dan
disiplin (atau alur kerja). Pada tahun ,Topik
Anda 2mengerjakan satu persyaratan disiplin yang
penting. Dengan menggunakan model use case, Anda melihat bagaimana menghasilkan
sejumlah artefak dalam alur kerja persyaratan, termasuk use case (yang mungkin
menggabungkan beberapa diagram use case), visi, spesifikasi tambahan, dan glosarium.
Sekali lagi, kami ingin menekankan bahwa artefak ini tidak diproduksi sekaligus: UP didirikan
atas dasar pemikiran bahwa semua tugas dilakukan secara bertahap dan berulang. Sebagian
besar tugas dalam alur kerja persyaratan diselesaikan selama fase awal dan elaborasi.
(Tentu saja, dalam dua fase ini, tugas-tugas lain juga dilaksanakan.) Jadi setelah fase awal,
penting untuk memeriksa apa yang telah dilakukan dan apa yang akan kita lakukan pada
fase elaborasi.
Selama fase awal, kita harus menetapkan kasus bisnis untuk sistem dan menentukan ruang
lingkup proyek. Untuk mencapai hal ini kita harus mengidentifikasi seluruh entitas eksternal
yang akan berinteraksi dengan sistem (aktor dan peran mereka) dan mendefinisikan sifat
interaksi ini pada tingkat tinggi. Hal ini melibatkan identifikasi semua kasus penggunaan dan
penjelasan (secara singkat) beberapa kasus penggunaan yang signifikan. Kasus bisnis
mencakup kriteria keberhasilan, penilaian risiko dan perkiraan sumber daya yang dibutuhkan
serta rencana fase yang menunjukkan tanggal pencapaian utama.
Hasil dari fase awal harus mencakup:
(a) Dokumen visi: visi umum tentang persyaratan proyek, fitur utama, dan kendala utama;
(b) Model kasus penggunaan awal (selesai 1020 persen);
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 3 PEMODELAN BERORIENTASI OBJEK ÿ 59
(c) Glosarium proyek awal;
(d) Kasus bisnis awal, yang mencakup konteks bisnis, kriteria keberhasilan (proyeksi pendapatan,
pengakuan pasar, dan sebagainya), dan perkiraan keuangan;
(e) Penilaian risiko awal;
(f) Rencana proyek yang menunjukkan tahapan dan iterasi;
(g) Model bisnis, jika diperlukan; Dan
(h) Satu atau beberapa prototipe sederhana.
Fase permulaan tidak boleh berlangsung lama, umumnya satu sampai dua minggu, sehingga
banyak hal dalam daftar di atas yang dimulai tetapi tidak selesai.
Misalnya, prototipe arsitektur yang serius dapat memerlukan waktu satu bulan untuk memilih dan
menginstal teknologi yang relevan (perangkat keras dan perangkat lunak) dan kemudian
membangunnya. Artefak yang dihasilkan harus singkat dan tidak lengkap. Tonggak sejarah proyek
besar pertama adalah pada akhir fase awal. Kriteria evaluasi untuk tahap awal adalah:
(a) Para pemangku kepentingan menyepakati definisi ruang lingkup dan perkiraan biaya atau jadwal;
(b) Pemahaman persyaratan seperti yang disajikan dalam kasus penggunaan utama;
(c) Kredibilitas perkiraan biaya atau jadwal, prioritas, risiko dan proses pembangunan;
(d) Kedalaman dan keluasan setiap prototipe arsitektur yang dikembangkan; Dan
(e) Pengeluaran aktual versus pengeluaran yang direncanakan.
Jika tonggak sejarah tahap awal tidak terpenuhi, ruang lingkup proyek dapat didefinisikan ulang,
atau bahkan mungkin dibatalkan. Jika melewati tonggak sejarah tersebut, tim proyek memasuki
fase elaborasi di mana penyelidikan persyaratan yang lebih mendalam dilakukan dan implementasi
arsitektur inti dimulai. Tujuan dari tahap elaborasi adalah untuk menganalisis domain masalah,
membangun landasan arsitektur yang kuat, mengembangkan rencana proyek dan menghilangkan
elemen risiko tertinggi dari proyek. Keputusan arsitektur harus dibuat dengan pemahaman tentang
keseluruhan sistem: ruang lingkupnya, fungsionalitas utama dan persyaratan non-fungsional
seperti persyaratan kinerja, dll.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
60 ÿ TOPIK 3 PEMODELAN BERORIENTASI OBJEK
Dalam hal manajemen proyek, fase elaborasi adalah fase paling kritis dari empat fase.
Pada akhir fase ini, 'rekayasa' yang sulit dianggap selesai dan tim proyek harus membuat
keputusan yang sangat penting apakah akan berkomitmen atau tidak pada fase
konstruksi dan transisi. Bagi sebagian besar proyek, hal ini juga berkaitan dengan
transisi dari operasi berbiaya rendah dan berisiko rendah ke operasi berbiaya tinggi dan
berisiko tinggi dengan investasi besar. Meskipun prosesnya harus selalu mengakomodasi
perubahan, aktivitas fase elaborasi memastikan bahwa arsitektur, persyaratan, dan
rencana cukup stabil dan risiko cukup dimitigasi, sehingga Anda dapat menentukan
biaya dan jadwal penyelesaian pengembangan.
Pada tahap elaborasi, prototipe arsitektur yang dapat dieksekusi dibangun dalam satu
atau lebih iterasi, bergantung pada cakupan, ukuran, risiko, dan kebaruan proyek.
Upaya ini setidaknya harus mengatasi kasus penggunaan utama yang diidentifikasi
pada tahap awal, yang biasanya mengungkap risiko teknis utama proyek. Meskipun
prototipe evolusioner dari komponen berkualitas produksi selalu menjadi tujuannya, hal
ini tidak mengecualikan pengembangan satu atau lebih prototipe eksploratif dan sekali
pakai untuk memitigasi risiko tertentu seperti pengorbanan desain atau persyaratan,
studi kelayakan komponen, atau demonstrasi kepada investor, pelanggan. dan
pengguna akhir. Hasil dari tahap elaborasi adalah:
(a) Model use case (setidaknya 80 persen selesai): semua use case dan aktor telah
diidentifikasi, dan sebagian besar deskripsi use case telah dikembangkan;
(b) Persyaratan tambahan: persyaratan ini mencakup persyaratan non-fungsional dan
persyaratan apa pun yang tidak terkait dengan kasus penggunaan tertentu;
(c) Diagram urutan sistem yang menggambarkan kejadian dan urutannya: diagram ini
dihasilkan oleh aktor dan kejadian sistem atau antar sistem;
(d) Model domain: visualisasi hal-hal dalam domain yang diminati;
(e) Model desain (lengkap sebagian): sekumpulan diagram yang menggambarkan
desain logis sistem;
(f) Dokumen arsitektur perangkat lunak: ini merangkum arsitektur utama
permasalahan dan penyelesaiannya dalam desain;
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 3 PEMODELAN BERORIENTASI OBJEK ÿ 61
(g) Model data (lengkap sebagian): mencakup skema database dan strategi pemetaan antara
representasi objek dan non-objek;
(h) Model pengujian (lengkap sebagian): ini menggambarkan apa yang akan diuji;
(i) Prototipe arsitektur yang dapat dieksekusi;
(j) Revisi daftar risiko dan revisi kasus bisnis;
(k) Rencana pengembangan untuk keseluruhan proyek, termasuk rencana proyek secara kasar, yang
menunjukkan iterasi dan kriteria evaluasi untuk setiap iterasi;
(l) Perkembangan kasus yang diperbarui yang merinci proses yang akan digunakan; Dan
(m) Panduan pengguna awal (opsional).
Sistem yang ditargetkan akan dirancang dan dibangun oleh tim pengembangan sistem organisasi.
Namun, mungkin saja terdapat paket perangkat lunak yang tersedia secara komersial yang sesuai
dengan persyaratan sistem yang ditargetkan (atau hanya memerlukan sedikit adaptasi). Dalam hal
ini, organisasi dapat memilih untuk tidak membangun sistemnya sendiri namun membeli paket
komersial yang tersedia, yang dalam banyak kasus lebih ekonomis. Keputusan apakah akan membeli
atau membangun sistem harus dibuat pada tahap elaborasi sebelum kita melanjutkan ke tahap
berikutnya, yang sangat mahal dan berisiko.
3.2
TINJAUAN KASUS PENGGUNAAN – URUTAN SISTEM
DIAGRAM
Seperti yang Anda ingat, kasus penggunaan terutama mendeskripsikan „apa‰ yang akan dilakukan
sistem, bukan „bagaimana‰ sistem akan melakukannya. Akibatnya, seperti yang akan Anda lihat
ketika Anda membaca bagian ini, sistem diperlakukan sebagai kotak hitam tempat para aktor
berinteraksi. Sebelum melanjutkan ke desain logis sistem, ada baiknya untuk memperjelas lebih lanjut
perilakunya menggunakan diagram urutan sistem (SSD), sebuah teknik yang memungkinkan Anda
meninjau kasus penggunaan Anda. SSD mengilustrasikan peristiwa dan operasi secara berurutan,
dimulai dengan masukan aktor eksternal ke sistem.
Diagram tersebut dapat dilihat sebagai gambar garis waktu dari kasus penggunaan yang diperluas,
peristiwa paling awal ditempatkan di bagian atas diagram. Gambar 3.1 adalah contoh SSD sederhana
untuk satu use case. Menurut Larman (2002), SSD adalah bagian dari Use-Case Model.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
6 62 ÿ ATAS
MO BERORIENTASIODEL
T
GAMBAR 3 OBYEK
Gambar 3.1: Diagram
diagram urutan sistem m
AKTIVITAS 3.1
Lihat daftarpenggunaan untuk Video
Victo ria
„meminjam
viddi Topik 2: ses yang Anda tulis untuk Latihan 2.5 Anda menulis
deos‰ kasus
penggunaan, dan untuk yang lain kami ingin SSD untuk masing-masing e 2.7kamu salah dalam
Latihan
ini. Menggambar
Dari sebenarnya melakukan hal tersebut pada
SSD, Anda mungkin kasus
mendapati
bahwa kasuses.
penggunaan
Anda kurang tepat. Kesalahan umum adalah tidak jelasnya teks kasus penggunaan tentang apa
yang sedang
kasus ar terjadi. Misalnya, Anda mungkin memiliki
frasa seperti „perbarui
detail‰. Ya, siapa yang memperbarui
detail sistem? Jadi, kalau kamumenemukan ada yang salah dengan dirimu, perbaikilah.
pengguna atau t
3.3
OMAIN
MELAKUKAN
kasus penggunaan kami,
MODEL
Jika Anda merujuk kembali ke fase UP P
dan rencana disiplin ilmu di Topik 1, Anda akan menemukan bahwa ada disiplinmelihat
ilmu „pemodelan bisnis‰ dengan tindakan artifa „model domain m‰ ha. atau selebihnya dari topik ini, kita akan fokus pada
pembahasan bagaimana melakukan pemodelan bisnis F dan produksi n model
domain (atau a sebagaimana dirujuk di rm
beberapa o dari melek
huruf). Model domain adalah masa depan, suatu hal yangada di dunia nyata d.
kesimpulan
mode konseptual del
ulang
presentasi
Hak Cipta © Universitas Terbuka Malaysia (OUM)
sa
Machine Translated by Google
TOPIK 3 PEMODELAN BERORIENTASI OBJEK ÿ 63
Faktanya, pemodelan domain adalah versi pemodelan bisnis yang disederhanakan. Seperti
digambarkan pada Gambar 3.2, pemodelan bisnis yang lebih detail dapat dilakukan dengan
cara alternatif dengan proses yang lebih detail.
Gambar 3.2: Pemodelan bisnis
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
64 ÿ TOPIK 3 PEMODELAN BERORIENTASI OBJEK
Sebelum melangkah lebih jauh, mari kita bahas berbagai jenis model yang Anda temui di UP, karena
model tersebut mungkin membingungkan kecuali Anda memahami dengan jelas bagaimana model
tersebut cocok satu sama lain.
Di UP, kami mengadopsi metodologi pemodelan untuk melakukan sebagian besar tugas di seluruh
proses pengembangan sistem. Ada sejumlah model berbeda yang perlu kita bangun pada fase dan
iterasi berbeda. Kita dapat mengkategorikan semua model yang berbeda ini ke dalam tiga tingkatan,
konseptual, logis, dan fisik.
Tabel 3.1: Hierarki Model di UP
Model Konseptual Model ini merupakan representasi dunia nyata (dalam konteks pengembangan sistem,
domain bisnis dimana sistem yang dihasilkan akan dioperasikan) dari konsepsi
pengguna. Misalnya, dalam kasus Video Victoria, model konseptual adalah
model yang menggambarkan entitas serta hubungannya dalam sistem
pemeriksaan video seperti yang dirasakan oleh, misalnya, anggota toko video.
Entitas dalam domain check-out video mungkin mencakup: (a) anggota (b)
CD video (c)
judul video (d)
kategori video, dll.
Model konsepsi memiliki tingkat abstraksi tertinggi dalam hierarki pemodelan
karena model tersebut mencerminkan cara pengguna memandang operasi
mereka sendiri.
Model logis
Model fisik
atau memiliki,
Model ini menunjukkan apa yang harus dilakukan suatu
sistem tanpa
memperhatikan bagaimana hal itu dilakukan, dibangun, dan direpresentasikan.
implementasi model
Hal ini termasuk yang dibahas dalam Topik 2. Model
persyaratan-independen
logisnya adalah sistem akhir dapat
diimplementasikan pada platform pemrograman apa pun, baik itu C++ atau
Java dan bahkan sistem manual.
Mengerjakan
Ini adalah model desain akhir yang menunjukkan bagaimana sesuatu akan dilakukan
atau dibangun dan menggambarkan semua detail platform, penyimpanan data, dan
detail implementasi lainnya.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 3 PEMODELAN BERORIENTASI OBJEK ÿ 65
Disiplin pemodelan bisnis datang sebelum disiplin persyaratan.
Namun seperti yang Anda lihat, dalam praktiknya, kami tidak mengikuti
urutan ini. Misalnya, kita telah membahas cukup detail tentang disiplin
persyaratan tanpa menyebutkan satu kata pun tentang pemodelan bisnis.
Faktanya, disarankan agar pemodelan bisnis dimulai pada iterasi pertama
tahap elaborasi setelah beberapa artefak persyaratan awal telah dihasilkan
seperti yang ditunjukkan pada Tabel 3.2.
Tabel 3.2: Pemodelan Bisnis
Artefak
Disiplin
masuk.
I1
Konstan.
Trans.
C1..Cn
T1..T2
S
Model Domain Pemodelan Bisnis
Persyaratan
Elab.
E1..En
Model Kasus Penggunaan
S
R
Penglihatan
S
R
S
R
S
S
Tambahan
Spesifikasi
Glosarium
Desain
S
Model Desain
R
Arsitektur SW
S
Dokumen
Penerapan
Proyek
Pengelolaan
Model data
S
R
Model Implementasi
S
R
R
R
R
R
S
R
Rencana Pengembangan SW
Pengujian
Model Uji
Lingkungan
Kasus Pembangunan
S
S
R
mulai, perbaiki
Sumber: Larman (2002), hal. 24
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
66 ÿ TOPIK 3 PEMODELAN BERORIENTASI OBJEK
Hal ini karena dalam praktik UP, kami mengerjakan disiplin ilmu secara berulang. Mereka
tidak dimulai dan diselesaikan secara berurutan. Dalam setiap iterasi, mungkin ada beberapa
disiplin ilmu yang sedang berjalan (tentu saja dengan tingkat penyelesaian yang berbedabeda) pada waktu yang bersamaan. Untuk memfasilitasi pengembangan model domain
(terutama dalam identifikasi objek domain, yang akan kita bahas di bagian selanjutnya),
kasus penggunaan (setidaknya yang pendahuluan) dikembangkan sebelum model domain.
Seperti yang akan Anda lihat nanti dalam diskusi, model domain dan model use case saling
terkait.
Sekarang setelah Anda memiliki pemahaman yang jelas tentang keseluruhan hierarki
pemodelan UP, Anda akan melihat mengapa penting untuk memiliki proses pemodelan
bisnis di atas model UP lainnya. Seperti kita ketahui, sistem informasi tidak lagi sekedar
mendukung bisnis. Semakin lama, mereka menjadi bagian integral dari sebuah bisnis, oleh
karena itu bisnis itu sendiri yang menentukan persyaratan sistem yang akan kita kembangkan.
Model bisnis (model domain) adalah abstraksi tentang bagaimana suatu bisnis berfungsi. Ini
adalah pandangan yang agak disederhanakan mengenai realitas bisnis yang kompleks.
Model bisnis memungkinkan pengembang sistem menghilangkan detail yang tidak relevan
dan fokus pada aspek bisnis yang lebih penting.
Seperti yang kami katakan di atas, model use case dan model domain saling terkait. Model
use case (seperti sebagian besar artefaknya) pada dasarnya bersifat tekstual: model ini
menggambarkan rincian persyaratan fungsional (dan non-fungsional) sistem dalam katakata. Namun, seperti yang sering dinyatakan, ide-ide yang disajikan dalam bentuk visual
dibandingkan tekstual sering kali lebih mudah dipahami (sebuah gambar menggambarkan ribuan kata).
Jadi model bisnis visual (domain) dapat meningkatkan pemahaman operasi bisnis dan
membantu menyempurnakan pengembangan model persyaratan dan model desain pada
tahap UP selanjutnya.
Terkadang, proyek pengembangan sistem berskala besar berjalan seiring dengan perubahan
besar dalam proses bisnis (yang kami sebut Rekayasa Ulang Proses Bisnis (BPR). Dalam
hal ini, model bisnis tidak hanya melayani tujuan analisis dan desain sistem tetapi juga dapat
diperlakukan sebagai cetak biru bagi mereka yang melakukan rekayasa ulang (dalam hal
ini, kita mungkin perlu melalui proses pemodelan bisnis secara rinci seperti yang digambarkan
pada Gambar. 3.2). Panduan ini menyediakan bahasa dan platform yang sama bagi kedua
komunitas, serta menunjukkan cara membuat dan memelihara ketertelusuran langsung
antara model bisnis dan perangkat lunak.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 3 PEMODELAN BERORIENTASI OBJEK ÿ 67
Ada banyak cara berbeda untuk melakukan pemodelan bisnis. Dalam konteks UP,
kita biasanya menggunakan notasi diagram kelas UML (yang menghasilkan apa yang
disebut model domain atau model konseptual dalam beberapa literatur berorientasi
objek lainnya). Ingatlah bahwa UML hanyalah sebuah alat untuk analisis dan desain
berorientasi objek. Diagram kelas di UML dapat digunakan untuk tujuan lain di UP
seperti 'diagram kelas desain' dalam model desain yang akan kita bahas nanti. Di
sini, dalam konteks pemodelan bisnis, model domain adalah diagram kelas yang
diambil dari perspektif konseptual (yang berbeda dengan perspektif spesifikasi dalam
diagram kelas desain pada tahap pemodelan desain).
Dalam model domain, kami memiliki tiga jenis informasi:
(a) Objek domain (atau kelas konseptual) yang mengidentifikasi entitas bisnis atau
konsep, misalnya toko, video CD, member, dan sebagainya;
(b) Asosiasi antara objek domain yang menentukan hubungan yang relevan, objek
yang menangkap informasi bisnis yang perlu dilestarikan dan keragamannya,
misalnya, sebuah toko memiliki banyak CD video, seorang anggota meminjam
banyak CD video; Dan
(c) Atribut objek domain yang merupakan nilai data logika suatu objek, misalnya
setiap anggota boleh mempunyai „nomor anggota‰ yang merupakan atribut
dari objek „anggota‰.
Penting untuk dicatat bahwa diagram kelas analisis adalah visualisasi hal-hal dalam
domain dunia nyata yang diminati dan bukan komponen perangkat lunak seperti
kelas Java.
Ingat...
Diagram kelas analisis yang dihasilkan selama tahap analisis adalah visualisasi halhal di domain dunia nyata yang diinginkan dan BUKAN komponen perangkat lunak
seperti kelas Java. Di sisi lain, hubungan antar kelas perangkat lunak, yang
menggambarkan detail kelas dilakukan melalui diagram kelas desain yang
berlangsung selama tahap desain.
Desain diagram kelas berada di luar silabus.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
68 ÿ TOPIK 3 PEMODELAN BERORIENTASI OBJEK
KEGIATAN 3.2
Sebelum kita masuk ke detail model domain, mari kita pastikan
sudah jelas fungsinya. Lihat diagram di bawah ini:
Sumber: Larman (2002)
Jangan khawatir dengan arti sebenarnya dari notasi baris,
kata-kata, panah, dll. karena semuanya akan dijelaskan nanti di topik ini. Untuk
sejenak, coba saja baca diagram dengan kata-kata berikut ini, mulai
A Toko .
Barang adalah Ditebar
di pojok kanan atas: Toko memiliki
alamat (misalnya Jalan Buntong 15, Ipoh) dan Kedai Perabot nama (Misalnya,
toko
Ali). Masing-masing atau memiliki,Rumah
beberapa
atau ,direkam pada,
Register . Setiap
Penjualan
, adalah
ditangkap
Daftar .
Lanjutkan dengan deskripsi ini untuk mencakup semua objek domain dan
hubungan seperti yang digambarkan pada gambar di atas. Lihat apakah itu memberi Anda yang lebih baik
pemahaman tentang proses „penjualan pembayaran‰ kasus NextGen POS.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
KE
OBJEK OPIC 3
M. BERORIENTASI CT
PEMODELAN
ÿ 69
3.4 KONSESIEPTUAL SKELAS
model adalah untuk mengidentifikasi
hal yang harus kita lakukan dalam membangun domain m
r domain kelas sses, sebagai istilahed oleh beberapa dari
kelas aktual (atau
o konsep berorientasi objek
Yang pertama Itu
literatur
membenci sesuatu
e). Sebuah konsep
perwakilan kelas sebenarnya
hal fisik
cal atau konsepsi
ptual dalam
, seperti yang akan Anda
konsepsi kelas nyata,
C
kelas
lihat di a. Namun,pertama,
fi
kita perlu merevisi apa yang kami maksud dengan
y kata-kata dan momen
Y
1
.
Anda
akan
ingat
akan
dari
itu
kelas
C
makan
untuk
satu
set
o
Tema
ss adalah sebuah templat
obyek
objek
yang
al
akan terlihat samaSaya. Jadi seorang pria
lant
untuk
mobil
itu
seperti
sebuah
kelas
s, dan
manufaktur hal
semua mobil yang dibuatnyaes adalah objeknyaproyek. Tentu sajarse, setiap mobilr punya sendiri n lisensi
bisnis
ess. Ada
e saudara yang berbeda
temuan
aliran yang berbeda
wner (lihat Gambar 3.3).
piring dan d milik a
Angkae 3.3: Kelas dand objek
Sebagai rekegembiraan b antara kelas
malas dengan
h bahasa kami
melukis mobil n
prosesnyacess yang pergi
perangkat lunak
e pemodelan
telinga, kita sering merasa sedikit
ss dan objeknya jects sangat bagus
usia. Jika dia
kepala mesin
mencari ac
perlu dilakukan satu lebih baik‰,dia
h adalah pr
itu ada di pabrik
eh dari spe
kata pabrik
mungkin banyak bicara
ng
tentang
mobil yang spesifik. Jadi, juga, dalam
kelas ds dan ob
ada di antara kita menyanyikan kata itu
w tempat kita berenang
Entitas itu ity 'objek' jatuh ke dalam
jumlah kucing
penting.
Di
sini
ar
ada tiga jenis
objek th yang mereka wakili
ys: „G pada
objek.
kategori, dasar
ed di sana
topi dunia
s konseptua
al kelas itu
t kita akan
pertemuan melakukan bisniss pemodelan:
(a) Bersamaobjek beton
Bersama
ini tangib
s adalah mo
benda-benda beton
Dalam
e toko video e
berwujud dan
undmemahami. Untuk
r contoh, sch
sekolah nyata
bukan hanya b
di sebuah
gempa bumi
st dengan mudah dan
dipahami
lihat
deo
CD
misalnya, adalah
penipu
(b) Bersamaob konseptual objek masuk
sebuah sc
ble, yaitu, mereka memiliki
kehadiran.
fisik hal
oleh a analis dan kamu pengguna.
benda beton;
dan seringkali jauh
r lebih banyak perbedaan
sulit untuk
hool adalah sebuah kesimpulan
objek konseptual bahwa t. Anda mungkin
berpendapat
.
Namun,
th
Konsep sekolahnyaadalah n
hanya ada itu h memiliki bangunan.
s di sekolah runtuh karena
bangunan. Saya agine bahwa semua bangunan
ke. Kita tidak bisa jangan katakan itu
sekolahnya tidak ada
lihat
judul
deo
o konseptual
Demikian pula, juga
aku keberatan; dan
Itu tidak akan dibangun kembali. S
dapat
Hak Cipta © Universitas Terbuka Malaysia (OUM)
bertahun-tahun lagi.
Machine Translated by Google
70 ÿ TOPIK 3 PEMODELAN BERORIENTASI OBJEK
(c) Objek peristiwa dan keadaan bersifat sangat abstrak. Mereka saling terkait karena biasanya ketika
suatu peristiwa penting terjadi, beberapa atau lebih objek akan beralih ke keadaan yang
berbeda. Contoh objek peristiwa dan keadaan di toko video adalah . Kita dapat melihat bahwa
pinjambiasanya
video akan mengubah status (misalnya, peminjaman daftar
peristiwa peminjaman video
video) objek.
Kelas konseptual merupakan konsep penting dalam paradigma berorientasi objek. Dalam proses
pengembangan perangkat lunak tradisional, program perangkat lunak yang rumit dipecah menjadi
beberapa proses atau fungsi (dalam istilah pemrograman komputer). Misalnya, lihat gambar
dekomposisi fungsional untuk sistem toko video di
Topik 1 .
Dalam pendekatan pengembangan perangkat lunak berorientasi objek, program perangkat lunak
yang rumit dipecah menjadi objek (yang, dalam banyak kasus, menyerupai objek dunia nyata). Oleh
karena itu, pembagian domain bisnis atau masalah ke dalam kelas konseptual adalah langkah
pertama dalam analisis dan desain berorientasi objek.
Namun, harap dicatat bahwa kelas konseptual atau objek yang kita bicarakan dalam pemodelan
domain berbeda dari kelas objek perangkat lunak yang akan kita bicarakan pada tahap UP selanjutnya.
Menurut Larman (2002), kelas konseptual dapat dipertimbangkan dalam istilah berikut:
(a) Simbol kata atau gambar yang mewakili kelas konseptual
(b) Intensi definisi kelas konseptual
(c) Memperluas kumpulan contoh yang diterapkan pada kelas konseptual
Misalnya, dalam transaksi kredit, kelas konseptual dapat mempunyai simbol . Maksudnya bisa saja
Meminjam„mewakili peristiwa transaksi
Meminjam
peminjaman yang mempunyai tanggal dan ID transaksi‰.
Perpanjangan dari adalah semua contoh pinjaman.
Meminjam
3.4.1 Identifikasi Kelas Konseptual
Kelas konseptual dalam model domain dapat menjadi inspirasi desain kelas perangkat lunak dalam
model desain. Dalam hal ini, identifikasi kelas konseptual dalam model domain sangat penting bagi
keberhasilan pengembangan sistem. Dalam domain bisnis yang rumit, mungkin terdapat ratusan
entitas yang berpotensi diperlakukan sebagai kelas konseptual.
INGAT: Apakah mereka termasuk dalam model domain sangat banyak
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 3 PEMODELAN BERORIENTASI OBJEK ÿ 71
bergantung pada pengguna dan cara mereka memandang lingkungan bisnisnya. Kita
harus memilih kelas konseptual yang tepat sehingga model domain yang bermakna
dapat tercipta.
Ada sejumlah cara agar kita dapat mengidentifikasi kelas konseptual secara sistematis.
Salah satu caranya adalah dengan membuat daftar kategori kelas konseptual.
Kita telah mengategorikan kelas konseptual ke dalam tiga kategori besar, yaitu objek
konkrit, objek konseptual, dan objek peristiwa dan keadaan. Ketiga kategori ini
selanjutnya diperluas ke kategori yang lebih halus sesuai Tabel 3.3.
Tabel 3.3: Daftar Kategori Kelas Konseptual
Contoh
Kategori Kelas Konseptual
Benda fisik atau nyata
Daftar
Spesifikasi
Tempat
Spesifikasi produk
Toko
Transaksi
Penjualan, Pembayaran
Item baris transaksi
Item Garis Penjualan
Peran orang
Kasir
Wadah barang lainnya
Simpan, Bin
Hal-hal di dalam wadah
Barang
Sistem komputer lain di luar sistem
Sistem Otorisasi Pembayaran Kredit
Konsep Kata Benda Abstrak
Kelaparan
Organisasi
Acara
Departemen penjualan
Proses
MenjualProduk
Aturan atau Kebijakan
Kebijakan pengembalian
Katalog
Katalog Produk
Catatan keuangan, pekerjaan, kontrak, hukum
Kwitansi, Buku Besar, Kontrak Kerja
Penjualan, Pembayaran, Rapat
penting
Instrumen dan layanan keuangan
JalurKredit
Manual, dokumen, kertas referensi, buku
Daftar Perubahan Harga Harian
Sumber: Diadaptasi dari Larman (2002)
Meskipun daftar kategori yang disajikan diambil dari beberapa domain tertentu (dalam
kasus Tabel 3.3, domain toko), daftar tersebut kurang lebih mencakup banyak kategori
umum di domain bisnis lainnya.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
72 ÿ TOPIK 3 PEMODELAN BERORIENTASI OBJEK
AKTIVITAS 3.3
Dengan menggunakan Tabel 3.3 sebagai panduan, buatlah kategorisasi kelas konseptual untuk
Video Victoria.
Teknik lain untuk mengidentifikasi kelas konseptual adalah penggunaan identifikasi frase kata benda.
Setelah Anda mempelajari Bacaan 3.5, Anda akan melihat bahwa salah satu argumen untuk mengembangkan
kasus penggunaan sebelum pemodelan domain adalah bahwa kasus tersebut merupakan sumber frasa
kata benda yang sangat baik untuk identifikasi kelas konseptual. Namun, perhatikan bahaya ambiguitas
dalam bahasa alami kasus penggunaan yang diterjemahkan ke dalam kelas konseptual jika transformasi
dari satu ke yang lain dilakukan terlalu mekanis.
Sekarang mari kita lihat satu contoh di mana kita akan menggunakan identifikasi frase kata benda untuk
mengidentifikasi kelas konseptual.
Contoh Di
bawah ini adalah gambaran sistem reservasi tiket berbasis web. Semua frasa kata benda yang merupakan
kandidat untuk kelas konseptual ditandai dengan huruf tebal.
Perusahaan reservasi tiket berbasis internet mengkhususkan diri dalam menjual tiket acara hiburan
kepada pelanggan yang mengunjungi situs web perusahaan. Perusahaan memperoleh tiket untuk acara
dari agen tiket biasa secara teratur atau berdasarkan permintaan ketika stok menipis.
Sebelum mereka dapat menggunakan situs ini, pelanggan harus mendaftarkan rincian kontak mereka
atau memasukkan informasi yang cukup untuk mengidentifikasi diri mereka jika mereka telah mendaftar
sebelumnya. Mereka kemudian dapat melihat materi publisitas dan informasi ketersediaan tiket untuk
sejumlah acara berbeda dan menambahkan tiket untuk acara yang dipilih ke dalam pesanan mereka.
Setelah selesai, mereka memasukkan rincian kartu kredit mereka dan, jika semuanya baik-baik saja, tiket
mereka akan dikirim melalui pos. Perusahaan menyimpan alamat kontak dan alamat penagihan (kartu
kredit) (yang mungkin sama) untuk setiap pelanggan terdaftar.
Berkonsentrasi hanya pada sisi pelanggan, jangan memodelkan pasokan tiket dari „agen tiket biasa‰.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 3 PEMODELAN BERORIENTASI OBJEK ÿ 73
3.4.2 Permasalahan dalam Mengidentifikasi Kelas Konseptual
Tidak ada daftar kelas konseptual unik untuk domain bisnis tertentu.
Pengguna yang berbeda dan analis sistem berorientasi objek mungkin menghasilkan daftar yang berbeda.
Dimasukkannya objek entitas tertentu ke dalam daftar kelas konseptual atau tidak bergantung
pada konteks kasus penggunaan dan terkadang pada tahapan dan iterasi dalam UP.
Misalnya, apakah objek "daftar video pinjam" harus disertakan dalam model domain toko
video? Ini adalah pertanyaan yang bisa diperdebatkan karena „daftar video yang dipinjam‰
dari seorang anggota dibuat berdasarkan permintaan (mungkin untuk beberapa anggota
yang lupa berapa banyak video yang telah mereka pinjam). Ini bukan bagian dari proses
peminjaman video biasa; hal ini hanya diperlukan, katakanlah, dalam kasus penggunaan
„permintaan peminjaman daftar video‰.
Ada juga masalah penamaan kelas konseptual yang tepat sehingga penggunaan model
domain sebagai alat komunikasi yang efektif dalam proyek pengembangan sistem dapat
disorot. Ada dua prinsip dasar yang perlu kita ikuti dalam memberi nama kelas konseptual:
(a) Keduanya harus berbeda; Dan
(b) Harus ada cara untuk membedakannya.
Kita akan membahas „atribut‰ kelas konseptual di bagian selanjutnya.
Terkadang, mungkin terjadi kebingungan antara kelas konseptual itu sendiri dan atributnya.
Misalnya, haruskah „Popularitas‰ menjadi kelas konseptual yang terpisah dari „Video‰
atau hanya atributnya saja? Gunakan petunjuk berikut untuk mengatasi kebingungan ini:
A nomor
atau teks tapi sesuatu
„Kelas konseptual tidak dianggap sebagai sesuatu
yang mempunyai badan hukum, organisasi dan menempati ruang‰
3.4.3 Spesifikasi Kelas Konseptual
Terdapat kategori kelas konseptual yang disebut „spesifikasi‰ atau „deskripsi‰ dalam
daftar kategori kelas konseptual yang diperluas pada Tabel 5.1. Kategori kelas konseptual
ini memerlukan sedikit elaborasi. Contoh berikut akan membantu Anda memahami gagasan
tersebut.
Perjalananada
Bintang
Dalam contoh toko video, misalkan kita mempunyai video yang pernah
dalam stok.
Video tersebut memiliki judul video, klasifikasi video dan kategori video, dll., yang
menyertainya. Setelah video dipinjam oleh anggota dan hilang, maka video tersebut akan
dihapus dari sistem. Jika manajemen perlu memperoleh informasi tentang video tersebut
(misalnya, klasifikasi apa), maka mereka tidak mungkin dapat memperoleh informasi
tersebut. Untuk mengatasi ini
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
74 ÿ TOPIK 3 PEMODELAN BERORIENTASI OBJEK
masalahnya, kita memerlukan kelas konseptual „VideoSpecification‰ yang mencatat informasi tentang
video sehingga kapan pun informasi tentang video tertentu diperlukan (tidak peduli apakah masih
tersedia atau tidak), informasi tersebut dapat diambil dari spesifikasi. Berikut ini saran kapan waktu
yang tepat untuk menggunakan kelas konseptual spesifikasi:
(a) Terdapat kebutuhan untuk mendeskripsikan suatu barang atau jasa, terlepas dari keberadaan
barang atau jasa tersebut saat ini.
(b) Menghapus contoh hal-hal yang dijelaskannya (misalnya: Item) mengakibatkan hilangnya informasi
yang perlu dipertahankan.
(C)
Ini mengurangi duplikasi informasi.
AKTIVITAS 3.4
Perbarui model domain yang ditampilkan di Aktivitas 3.2 untuk menyertakan deskripsi
kelas konseptual.
3.5
ASOSIASI
Sekarang kami telah berhasil mengidentifikasi kelas konseptual dalam domain bisnis. Katakanlah,
dalam sistem toko video, kami telah mengidentifikasi „Member‰, „Video‰, „FrontDesk‰,
„MemberRecord‰ sebagai kelas konseptual (harap dicatat bahwa ini adalah model domain yang
sangat disederhanakan dan mungkin bukan model domain sebenarnya untuk kasus toko video). Apa
yang akan kita lakukan dengan semua objek (atau kelas konseptual) ini? Jawaban yang jelas adalah
mencari tahu bagaimana keterkaitannya. Asosiasi adalah istilah berorientasi objek untuk hubungan.
Orang-orang di dunia nyata mempunyai hubungan dengan orang lain, dengan benda, dan dengan
tempat. Jadi kita dapat mengatakan seseorang mempunyai ibu, menikah dengan pasangannya, suka
mengendarai Porsche, tinggal di rumah, dll. Ini adalah asosiasi objek 'orang' dengan objek lain di dunia
nyata. Kita melihat bahwa sebagian besar hubungan antara objek „orang‰ dan objek lainnya
dideskripsikan dengan kata kerja seperti „has‰, „married to‰, „likes to‰, „lives in‰, dan sebagainya.
Dalam UML, asosiasi adalah hubungan yang mengungkapkan interaksi antara contoh dua kelas
konseptual, diwakili oleh kata kerja yang menggambarkan apa yang mereka lakukan satu sama lain,
dan/atau dengan kata benda untuk peran yang masing-masing mainkan dalam kehidupan yang lain.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
KE
OBJEK OPIC 3
Gambar 3 .4 menunjukkan hubungan b
„Video‰ .
M. BERORIENTASI CT
PEMODELAN
antara dua konseptual cl
gadis „Memb
ÿ 75
ber‰ dan
Notasi ML untukatau asosiasi
Gambar 3.4: UM
Garis
e antara
mber‰ dan „V Video‰ ditayangkan
mengirimkan
e kelas konseptual „Mem
asosiasi ion antara dua kelas
ses dengan label „Pinjam
w‰ indikasi itu
asosiasi menyebutkan nama
ion (rela Th dia „1‰ dan „*
hubungan).
akan disk uss secara rinci Nanti.
l
3.5.1
Mengenali
ying
domain
lurus
antara konseptualc
kelas, kami n perlu mengidentifikasi
ntify semua ion penting
kelas yang w akan menghasilkan yang
a
bermakna aku asosiasi
gunakan videonya
o sistem toko tolong. m sebagai contoh
Mulai w dengan daftar a semua kelas
kelas d ditarik (dengan asosiasi ut
s di sebelah kiri dan UM
n) di sebelah
masuk ke dalam daftar
st,
asosiasi ion ke UM
Diagram ML o
Pilih pada
3.5.
Anggota‰ dan d „Video‰ an dan periksa
m penggunaan cas
se atau diskusi ion dengan
„
„Anggota Bor
baris Video‰), ,
Pada
saatwaktu,
yang sama
diagram
ML.
sebuah
tambahkan
„Anggota er‰ dan „Vide item eo‰ di t
dari semua ht,
seperti yang ditunjukkanGambar
i
kanan
yaitu, 'M
apakah mereka memiliki sebuah hubungan
p (baik dari
jika ada ulang kegembiraan (i dalam hal ini
pengguna). Jika
dua kelas ses telah c
multiplisitas, w yang kami
ini
mple dan
boleh melakukan iniadalah. Berikut sayap
adalah sim
jumlah w
cara maju di mana kita u
pertama dan
d kelas kedua
wakili m
asosiasi
Asso
Sama seperti kita mengidentifikasi konseptual c
model. T Ada sebuah
‰
garis ditarik lin
memasukkan
daftarnya, indikasi
e hubungan ini
makan itu
diperiksa.
F
identitas pergaulanlangkah
Gambar
3.5: Bokong
ifikasi 11
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
76 ÿ ATAS
MO BERORIENTASIODEL
T
GAMBAR 3 OBYEK
T
Lalu
kita pindah sudah turun ke l daftar untuk memeriksa hubungannyapinggul antara 'Anggota' a
'FMeja Depan‰ adan asosiasi
ist juga lin
diikat dengan lin
kutipan „Go T
Ke‰ ditambahkan. Sekali lagi, yang kedua
dua item di t
dan
li
tidak.
T
R‰dia daftar, yaitu, 'Membe
Proses ini diulangi dengan cerdas dan yang lainnya ituturun th
"M
AnggotaReco pasangan ord‰. Jika suatu hubunganshi p ada, asosiasi i
ditambahkan dalam t
kamu
em di dalam lis st, bahkan kamuugh tidak ada hubungan
pinggul
diagram UML M. Untuk itu
juga antara dua item, seperti „Anggota
r‰ dan „Mem mberRekam‰, , tautan adalah al
d
een dua jam
memiliki
hubungan ion antara kita
tertarik untuk menggabungkan kedua item tersebut
ms menunjukkan t itu relati
b
B sudah pertimbangkan
merah. Ketika „MAnggota‰ dan d semua yang lain
eh item dow
B een terhubung, iitu menunjukkan ttopi hubungannyahubungan antaraween „Anggota
Hai
kelas-kelas di sana
telah
h ditipu
sebagai
asosiasi di
tidak dipertimbangkan (reg
tanpa
penjaga wapa pun terjadi
wn daftarnya ha
atau mereka
dan langkah berikutnya
di kelas „V
Video‰ dan th dia kelas lain
ep, hubungannya nship antara
d
turunkan
daftar i dianggap
ems
adalah
tautan
ed
setelah r mereka
hubungan h
. Demikian pula, itu
een diperiksa dan assoc
d
diagram jika re
sebuah
P.
memiliki diagramgram).
UML Kami kira-kiradan lanjutkan ke o langkah berikutnya
Di dalam
b
jalan
er‰ dan semuanya t
ded antara dua kelas mana pun
ciation adalah menambahkan
xists (lihat F
kegembiraan mantan
ses di UM
Gambar 3.6).
Angkae 3.6: Asosiasi pada identifikasi
pada langkah 2
Hak Cipta © Universitas Terbuka Malaysia (OUM)
ses
memiliki
ML
Machine Translated by Google
KE
PEMODELAN
OBJEK OPIC 3 M. BERORIENTASI CT
ÿ 77
mengudara di bawah
e daftar sampai semua pasangan kelas hatelah
Langkah ini
p diulangi dengan kelas pa
dipertimbangkan
merah. Model terakhirnya akan lo oke seperti Figur ulang 3.7.
Figambar 3.7: Asso identifikasi kutipanpekerjaan akhir hal
Sim
mencari
kelas. T
besar
nomor
pada identifikasi haustive adalah,intinya,
di es seorang mantantion
hubungan yang mungkin
10 pasangan
nkapal antar
metode sederhana untuk asosiasi
g metode th
topi akan memeriksa
k semua pos
metodenya adalah itu
di kemungkinan kemampuan mis melemparkan
dia keuntungan ge dari m ini
ion ke dalam mo odel sangat rendah. Namun
eh, untuk model besar dengan ha asosiasi
konseptua
akan menjadibesar
v
(n*
c
al kelas, pasangan jumlah
kelas itu
*[n-1] untuk n kelas
keledai). Ef
kapan begitu
beberapa dari sebagai
asosiasi ar
tidak signifikan
di perlu diperiksa sangat
upaya yang terlibat
d mungkin tidak dibenarkan
tidak bisa atau jahat
modelnya.
tidak menyenangkan bagi
teksb
Oleh karena itu,dalam
alternatifnya
bertemu
buku, sebuah alte
„umum
pada asosiasi
yang disebut
pembuatannya g penggunaan sebagai
„perlu
n daftar‰ disarankan
disarankan. Ini m metodenya ba ased pada „
diketahui‰asosiasi
a
hal
prinsip ke a
akan le bisa membingungkanion di bulan
„Biasa
biasa saja
kelas. T
hindari juga bu
apapun yang dihasilkan
g asosiasi
s, yang
odel.
pada asosiasi
arman (2002) berisi com
n daftar‰ oleh La
kategori mmon ories yang
n
penentu
sekutu bernilai c mempertimbangkan masuk
ng hubungannya onships antara antara itu
Asosiasi umum li
s mengikuti untuk maskapai
t
penerbangan res
pelayanan
ist diberikan sebagai
sistem (T Tabel 3.4).
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
78 ÿ TOPIK 3 PEMODELAN BERORIENTASI OBJEK
Tabel 3.4: Daftar Asosiasi Umum (Seperti yang Diusulkan oleh Larman (2002))
Contoh
Kategori
A adalah bagian fisik dari B
Pesawat Sayap
A adalah bagian logis dari B
FlightLeg-FlightRute
A secara fisik terkandung dalam/pada B
Pesawat Penumpang
A secara logis terkandung dalam/pada B
Jadwal Penerbangan-Penerbangan
A adalah deskripsi untuk B
FlightDescription-Penerbangan
A adalah item baris transaksi atau laporan B
Log PemeliharaanPekerjaan-Pemeliharaan
A diketahui/dicatat/dicatat/dilaporkan/ditangkap
B
Reservasi-FlightManifest
A adalah anggota B
Pilot-Pesawat
A adalah subunit organisasi dari B
Pemeliharaan-Pesawat
A menggunakan atau mengelola B
Pilot-Pesawat
A berkomunikasi dengan B
Agen Reservasi-Penumpang
A terkait dengan transaksi B
Tiket penumpang
A adalah transaksi yang berkaitan dengan transaksi lain B
Reservasi-Pembatalan
A berada di sebelah B
Kota-Kota
A dimiliki oleh B
Pesawat-Pesawat
A adalah peristiwa yang berkaitan dengan B
Keberangkatan penerbangan
3.5.2 Multiplisitas
Saat Anda mengidentifikasi dan menggambar setiap asosiasi, awalnya Anda akan
menggambarnya sebagai garis sederhana yang menghubungkan dua kotak di diagram
UML. Setelah Anda membentuk asosiasi, misalnya, „Video Pinjam Anggota‰, ada
pertanyaan lain yang perlu ditanyakan: Berapa banyak video yang akan dipinjam anggota?
Pertanyaan ini berkaitan dengan banyaknya asosiasi.
Multiplisitas suatu asosiasi adalah jumlah instance dari setiap kelas yang dapat berpartisipasi
dalam suatu kejadian asosiasi. Tabel berikut mencantumkan beberapa kemungkinan nilai
multiplisitas untuk asosiasi (lihat Tabel 3.5). Multiplisitas adalah informasi penting untuk
tahap desain sistem selanjutnya. Ini mengkomunikasikan batasan domain penting yang
akan mempengaruhi desain perangkat lunak, terutama dalam desain database pada tahap
implementasi.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
KE
OBJEK OPIC 3
M. BERORIENTASI CT
PEMODELAN
ÿ 79
Tabel 3. .5: Multiplisitas y Nilai
Banyak
tiplicities
Arti
11
satu lawan satu
1*
satu-ke-banyak
1 1..*
satu lawan satu atau lebih
1 0,1
satu-ke-nol atau satu-ke-satu
e domain mo
Gambar 3 .8 menggambarkan
del dari video tersebut
sistem
toko deo mereka dengan mu
multiplisitas
ditambahkan.
asosiasi
Gambar 3.8 : Sebagai
3.5.3
Ada
dengan h multiplisitas
masalah AAsosiasi
Saya yang lain
ada masalah lainya prihatin
asosiasi ng
pada
dan itu dia
membantu dalam mak
raja model
domain lebih memahami
dapat dan melayani
sudah tujuannya se dari komunitas
menyatukan
domain k pengetahuan mlebih efektif
ly. Ini termasuk lude:
(a) Tidak Konferensi Aming saran untuk Asso asosiasi itu
asosiasi e harus dimulai w
dengan modal
adalah konvensi umum untuk
Ini saya
aku menulis seperti itusebagai
a
Kirim-oleh atau Kirim-oleh.
o membaca keledai
pergaulan dari m dari kiri ke kanant atau from
p ke bawah. atas
(b)Mu
se
beberapa Asosiasihubungan antaraid Dua Kelas
Itu kamu bisa menjadi mu
beberapa hubungan
di kapal antara kitaeen objek dalam domain m
shosendiri di bawah ini.sini.
H Di sini F
Terbang-ke dan F
Lalat-Dari ar
jelas sekali di
terpisah
hubungan.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
model sebagai
hubungan
Machine Translated by Google
80 ÿ ATAS
MO BERORIENTASIODEL
T
GAMBAR 3 OBYEK
(C
c) Asosiasi
Asosiasi
ion dan Imp
ion dalam an
implementasi
kelas analisis d diagramnya tidakatau tentang aliran data, atau keberatan dll
dalam perangkat lunak
solusi perangkat n tapi itu terlihat begitulah hubungannya
kapal dalam keadaan murni
koneksi yang aktif
bagus
t
nyata
konsepnyaarti sebenarnya dari dunia
diagram kelas analisis
(yaitu cod ding). Kamu M
masuk tapi kita
saya dari asso
ld. Juga, beberapa
lima Asosiasi
Komprehensif
Kapan identitas
perkumpulan di t analisisc
mengidentifikasi pantat
(D
d) „Perlu
di fo
o-tahu‰ vs C
berikut ini (Lar
(i) Fokus cus di pantat
ke bdilestarikan f
(ii) Av
ion
pelaksana
tidak perlu dilaksanakan
m mungkin tidak dilaksanakan
d selama i
w asosiasi
mungkin juga d temukan yang baru
ketinggalan di th dia analisis cl
asosiasi di t
diagram gadis.
ns
diagram kelas m, perhatikan
rman, 2002):
perkumpulan untukpengetahuan
w
yang mana
tepi kembali
untuk beberapa dura
asi („
oid menunjukkan berlebihan atau
A
Penggunaan yang ketat dari pendekatan
'perlu-untuk-tahu'
perlu-t
kegembiraan ne
‰
untuk mengetahui
juga asosiasi yang diperlukan).
r dapat diturunkan sebagai
asosiasi
sorot oh
hted di atas t
untuk mempertahankan t
asosiasi di
analisis na c
diagram kelas m akan menyediakanea informasi minimal th
m mungkin tidak menyatu
dia analisis kelas diagram pantat. yaArtinya
kedudukan t
penuh itu
di bawah
sebagai
P
masalah
ke
ion
pada
pengguna. sesuaiding ke Larm man (2002), dalam istilah asosiasi
A pada, model analisis yang baik cl diagram gadis dapat dikonstruk suatu saat
M
kebutuhan minimald-untuk-tahu m model dan o
salah satu yang ilu
malam hari
di mana antara
tidak
ry bayangkanb bisa
dan dengan kata lain
s, gunakan yang berikut ini
kegembiraan. Di dalam
rendah:
ulang
Penekananize perlu-untuk-knsekarang asosiasiion, tapi tambahkan
d pilihan kompilasipemahaman-on
asosiasi hanya untuk memperkaya bagian kritis
modelnya (La
arman, 2002).
kedudukan t
n kepala sekolah, gunakan fo
asosiasi menjadi antar kelas
Di dalam
sebagai
mengikuti pantat sosialisasi gu
es (Larman, 20
o-tahu‰ juga
(A
a) Fokus pada n 'kebutuhan untuk'
(B
b) Ini bulan
bijih penting
asosiasi aktif;
pedoman wh
ing
kutipan;
t untuk mengidentifikasi konsep
kelas biasa th
(C
c) Terlalu laki-lakiasosiasi apa pun ns akan mengarah ke kebingungan dan
dan marginal b
(D
d) Hindari sh
hen identifikasi
002):
han ke identitas tify
keuntungan; Dan
asosiasi variabel tions.
bagaimana redunndant atau turunan
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 3 PEMODELAN BERORIENTASI OBJEK ÿ 81
AKTIVITAS 3.5
Gambar ulang Gambar 3.8 untuk menambahkan kelas konseptual „VideoSpecification‰ ke dalamnya
model domain toko video.
3.6
ATRIBUT
Atribut adalah bagian data yang kami gunakan untuk mengidentifikasi atau mendeskripsikan
sesuatu. Misalnya seseorang mempunyai nama, tanggal lahir dan warna mata. Atribut
biasanya berhubungan dengan kata benda yang diikuti dengan frasa posesif, misalnya
„warna mobil itu‰. Dalam hal ini, warna merupakan atribut dari mobil. Atribut biasanya
berupa tipe data sederhana atau tipe data primitif seperti integer, float, string, date, time, dll.
Nanti di Topik 5 Anda akan melihat bahwa atribut juga dapat menunjuk suatu kelas.
Untuk sistem toko video, berikut adalah atribut yang mungkin ada pada kelas konseptual
yang diidentifikasi:
(a) nomor anggota;
(b) ID video video, klasifikasi;
(c) nomor registrasi meja depan FrontDesk; Dan
(d) AnggotaMencatat jumlah item video yang dipinjam, tanggal jatuh tempo item
dipinjam.
Dalam UML, atribut ditampilkan di bagian bawah kotak persegi panjang yang mewakili kelas
konseptual. Oleh karena itu model domain yang telah selesai, sebagaimana direpresentasikan
dalam UML untuk sistem toko video, adalah seperti yang ditunjukkan pada Gambar 3.9.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
82 ÿ ATAS
MO BERORIENTASIODEL
T
GAMBAR 3 OBYEK
Gambar 3.9: Konseptual m model video s
S terkadang,
w
apakah kita sh
sulit untuk dilakukan
o menilai apa
ada atribut
harus memperlakukannya sebagai kelas lainpantat.
itu sebuah atribute dari kelas su
sebagai
sistem toko
atau
bute benar-benar sebuah atribut sederhana,
Untuk ujian
sebuah tanggal adalah
ted
biasanya mengobati
seperti Hutang tanggal e. Namunvernya, sekarang kontra
sider cuaca
foperkiraan sy
sistem di observatorium yang menyimpan d
catatan harian atmosfer
kondisi eric dan d menghasilkan aanalisis untuk d berbeda sekali eks, bulan a
dan tahun. Ya
d
variabelnya
s, misalnya
ya, maksimal
tanggal dapat dijelaskan b
oleh banyak orang lain
bersama
ach
um,
jam matahari
bersinar, total ra jatuh, rata-rata
d suhu rata-rata suhu, h
w
tc. Anal
kecepatan angin usia,
et ini
atribut terpisah utes untuk d
lisis mungkin a juga membutuhkan se
hari
M
minimal dan
Hai
f dalam seminggu,
m dan kamu telinga. Dalam ca iniya, mungkin sajat kemudian memilih untuk memperlakukan „Dat
bulan
terpisah c
sebagai
W
Ketika
ada
pantat dengan o variabel lain
te‰ kelas konseptual
memasukkan
menilai apakah r untuk
untuk menghilangkan
tidak
y dan
perlu
incorre
di mana letaknyasulit
d untuk ju
atribut situasi, gunakan yang berikuti
kriteria ng t
atribut: di
pada
(A
a) Jika ind
s sebagai atributnya
utes.
keberadaan
ketergantungan mantan
sebuah
rath
n entitas adalah penting,
im
sebuah
dll
dia dari sekedar
kelas arate;
nilainya, thmaka itu adalah sepa
(B
b) Suatu entitas ty yang memiliki fefitur-fiturnya
miliknya sendiri di dalam
n yang
diberikan aaplikasi adalah
sa
memisahkankelas;
(C
c) Jika va
nilai attr
menyatakan kembali
g atributnya
ribut tergantung ds di pesta
R;
e sebagai kualifikasi
konteks khusus t, lalu pertimbangkan
der
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 3 PEMODELAN BERORIENTASI OBJEK ÿ 83
(d) Nama adalah atribut kelas jika tidak bergantung pada konteks, khususnya jika tidak harus unik;
(e) Jangan mencantumkan pengidentifikasi objek yang digunakan semata-mata untuk merujuk suatu
objek secara jelas;
(F)
Jika suatu atribut menggambarkan keadaan internal suatu kelas yang tidak terlihat di luar kelas,
maka hilangkan atribut tersebut dari analisis; Dan
(g) Hilangkan atribut-atribut kecil yang kecil kemungkinannya mempengaruhi sebagian besar operasi.
Tips Larman (2002) berikut ini sangat berguna saat membuat diagram kelas analisis:
(a) Gunakan Kategori Kelas Konseptual (dari Tabel 3.3) atau identifikasi frasa kata benda untuk
mengidentifikasi kelas konseptual.
(b) Gambarkan mereka dalam diagram kelas analisis.
(c) Tambahkan asosiasi yang diperlukan untuk menunjukkan hubungan antara
kelas.
(d) Tambahkan atribut yang diperlukan untuk memenuhi persyaratan informasi.
AKTIVITAS 3.6
Mirip dengan Aktivitas 3.5, tambahkan kelas konseptual „VideoSpecification‰
dan atributnya yang sesuai dengan Gambar 3.9.
Selamat! Anda sekarang telah membuat model domain. Mungkin belum sempurna, namun cukup baik
untuk digunakan.
3.7
NOTASI UML, MODEL DAN
METODE: PERSPEKTIF GANDA
Kami telah membuat model domain kami. Model domain adalah model pertama di UP yang kami gunakan
dengan serius notasi UML (tentu saja kami telah menggunakan beberapa notasi UML dalam kasus
penggunaan kami tetapi tidak terlalu ekstensif). Kami juga pertama kali bertemu dengan objek dan kelas
dalam pengembangan model domain. Seperti yang telah dijelaskan pada bagian sebelumnya, dalam UP
terdapat beberapa level pemodelan dengan level abstraksi yang berbeda-beda. Namun, apapun levelnya
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
84 ÿ TOPIK 3 PEMODELAN BERORIENTASI OBJEK
Abstraksi dari tahap pemodelan yang kita jalani, pada dasarnya kita mengandalkan kumpulan
notasi UML yang sama untuk memvisualisasikan dan mengkomunikasikan model. Oleh karena
itu, sangat penting untuk memperjelas bahwa kami tidak mencampuradukkan model dengan notasi UML.
Misalnya, kotak persegi panjang yang sama di UML dapat digunakan untuk mewakili kelas-kelas
dalam model yang berbeda, baik itu kelas konseptual dalam model domain atau kelas perangkat
lunak dalam model desain.
Salah satu keuntungan menggunakan kumpulan notasi yang sama di seluruh proses
pengembangan adalah mengurangi apa yang disebut kesenjangan semantik (atau „kesenjangan
representasi‰). Kesenjangan semantik berarti kesenjangan antara model mental kita tentang
domain dan representasinya dalam perangkat lunak. Dalam pengertian yang lebih luas, hal ini
mengacu pada kurangnya pemahaman konseptual bersama mengenai aspek bisnis dan sistem
yang perlu dimodelkan sedemikian rupa sehingga memungkinkan manusia dan teknologi untuk
bekerja sama secara harmonis dan beradaptasi terhadap perubahan. Dengan pendekatan
berorientasi objek dan penggunaan UML, kami menggunakan representasi, notasi, dan yang
terpenting gaya berpikir yang sama, mulai dari analisis hingga implementasi akhir dan pemeliharaan
sistem. Hal ini tidak hanya membuatnya lebih mudah dan murah untuk menyelesaikan semua
tugas pengembangan sistem, namun juga memungkinkan kami mengedukasi pengguna dengan
lebih baik. Dengan mengurangi kompleksitas semuanya melalui pengurangan jumlah konsep yang
sulit, kita dapat membawa pengetahuan ke dalam jangkauan kelompok orang yang lebih besar
dalam organisasi dan pada akhirnya mendapatkan lebih banyak kerja sama dan antusiasme serta
kepemilikan pengguna terhadap proyek tersebut.
• Dalam topik ini, Anda pertama kali bertemu dengan objek dan kelas. Anda memodelkan domain
bisnis dengan kelas konseptual yang sangat abstrak. Anda mempelajari bagaimana kasus
penggunaan yang digunakan untuk membantu identifikasi kelas konseptual.
Anda juga mengidentifikasi hubungan antara kelas konseptual dan menemukan sifat
intrinsiknya dengan mengidentifikasi atributnya.
• Ide untuk menggunakan kumpulan notasi standar yang sama, UML, dalam model yang berbeda
dan pada tahapan yang berbeda dalam UP ditekankan. Menggunakan kerangka kerja ini akan
mengurangi kesenjangan representasi antara model mental domain dan representasi
perangkat lunak dan menghasilkan lingkungan pengembangan sistem yang jauh lebih baik.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
KE
PEMODELAN
OBJEK OPIC 3M. BERORIENTASI CT
Asosiasiasi
Melakukan
Atribut utes
Lihatlah
Konsepkelas sebenarnya
Musifat serba bisa
Konsepmodel sebenarnya
Phmodel historis
Larman, C.(2002).
Hasemua.
ÿ 85
model utama
model logis
L dan pola
menerapkan UML
Aplikasi
Eriksson n, DIA, & Pe
enkus, M. (20 000). Bisnis
k. New York,
pola di
bekerja
menepuk
NY: Wiley.
S.
Sadd Atas
pemodelan s
sungai kecil, NJ:
engan UML
Hak Cipta © Universitas Terbuka Malaysia (OUM)
w
Pembantu tukang
B
Bisnis
Machine Translated by Google
Tema
ÿ Lebih Banyak Kasus Penggunaan
4
HASIL BELAJAR
Pada akhir topik ini, Anda seharusnya mampu:
1. Mengembangkan sub-use case dengan menyertakan dan memperluas hubungan; 2. Jelaskan
tujuan diagram keadaan UML secara konseptual
tingkat pemodelan; 3.
Menggambar diagram keadaan sederhana untuk kelas konseptual; 4.
Definisikan CRUD dan terapkan; 5.
Menjelaskan dan menerapkan aturan bisnis dalam analisis kebutuhan; 6. Mendeskripsikan
tujuan analisis ketahanan; dan 7. Menggambar sekumpulan diagram
analisis ketahanan suatu sistem.
ÿ PENDAHULUAN
Topik ini menggabungkan pekerjaan yang dilakukan pada kasus penggunaan dan membantu Anda mempelajari
lebih lanjut tentang model. Meskipun hal ini mungkin tampak sedikit membingungkan, dalam praktiknya terdapat
orang-orang berbeda yang mengerjakan berbagai aspek proyek, atau, dalam kasus proyek skala kecil, orangorang yang sama mengerjakan kasus penggunaan dan model lainnya secara bersamaan.
Kasus penggunaan adalah inti dari keseluruhan proses, jadi ada baiknya meluangkan waktu yang diperlukan
untuk 'melakukannya dengan benar'. Namun, mengetahui apa yang “benar” sering kali merupakan bagian yang sulit.
Seperti yang akan Anda lihat dalam topik ini, tidak semua penulis dan praktisi sepakat mengenai apa yang benar.
Anda perlu menyelesaikan ini untuk setiap proyek.
Pada bagian kasus penggunaan, kita melihat bagaimana kita dapat membagi kasus penggunaan menjadi sub-kasus
penggunaan. Seberapa jauh Anda mengambil tindakan ini agak kontroversial seperti yang akan Anda lihat.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 4 KASUS PENGGUNAAN LAINNYA ÿ 87
Pertanyaan besar ketika bekerja dengan use case adalah kapan Anda selesai? Dengan kata lain,
kapan Anda menemukan semua kasus penggunaan? Salah satu teknik yang sangat berguna untuk
membantu menjawab pertanyaan ini adalah dengan menggambar beberapa diagram keadaan.
Singkatnya, kami mengambil entitas utama dari model kelas domain dan melihat siklus hidup
masing-masing entitas saat dibuat, diperbarui, dan mungkin dihapus.
Selama pengembangan kasus penggunaan, dengan satu atau lain cara, kita perlu mengetahui
bagaimana operasi dan bisnis perusahaan atau organisasi berjalan.
Setiap perusahaan atau organisasi memiliki kebijakan dan aturannya sendiri dalam melakukan
sesuatu, yang dapat dirangkum dalam seperangkat aturan bisnis. Kami mungkin menemukan
sedikit demi sedikit aturan bisnis selama proses penulisan kasus penggunaan. Tidak ada cara
formal untuk menyajikan aturan bisnis (dalam hal UML atau alat pengembangan lainnya). Namun,
seperti yang mungkin Anda sadari nanti, seperangkat aturan bisnis yang baik penting untuk setiap
tahap proyek pengembangan sistem secara keseluruhan, jadi sekali lagi ada baiknya
mendedikasikan beberapa upaya untuk hal tersebut.
Terakhir, kita melihat teknik yang disebut diagram ketahanan. Diagram ini membantu kita beralih
dari analisis ke desain.
4.1
KASUS PENGGUNAAN YANG TERKAIT
Seperti yang Anda ingat, kita pertama kali membahas use case di Topik 2. Use case
menggambarkan interaksi seorang aktor (baik orang atau sistem eksternal) dengan sistem yang
sedang dibahas. Kasus penggunaan ditulis dalam bahasa sederhana sehingga pengguna dan staf
teknis dapat membacanya. Kasus penggunaan dapat ditulis secara informal atau menggunakan
template yang lebih formal. Versi awal dari sebuah use case menggambarkan alur utama kejadian
bagaimana sesuatu seharusnya terjadi dalam situasi normal, dengan asumsi tidak ada masalah.
Kemudian, seiring dengan kemajuan pekerjaan pada sistem, kasus penggunaan akan
disempurnakan untuk memuat aliran alternatif dan penanganan pengecualian.
Ada banyak pendekatan dan gaya berbeda dalam menulis kasus penggunaan. Alasan perbedaan
ini mencakup preferensi pribadi, gaya penerapan yang berbeda (misalnya, situs web yang menjual
buku berbeda dengan sistem perdagangan pasar saham), dan skala atau gaya pengembangan
yang berbeda (misalnya, dua orang dalam proyek tiga bulan bekerja sangat berbeda dari 50 orang
dalam proyek dua tahun).
Bacaan selanjutnya adalah review kasus penggunaan yang ditulis oleh penemunya, Ivar Jacobsen.
Dia memulai dengan sejarah singkat perkembangan mereka.
http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/ma
r03/usecases_TheRationalEdge_mar2003.pdf
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
88 ÿ TOPIK 4 KASUS PENGGUNAAN LAINNYA
Seperti yang dapat Anda lihat dari bacaan ini, salah satu aspek use case yang telah berkembang sejak tahun
1986 adalah bagaimana kita dapat menghubungkan satu use case dengan use case lainnya. Mengaitkan
kasus penggunaan satu sama lain memungkinkan kita melihat persamaan dan perbedaan di antara keduanya.
Ada tiga macam hubungan antar use case, yaitu:
(a) Termasuk biasanya ketika satu set kasus penggunaan masing-masing mencakup beberapa fungsi
umum yang dinyatakan dalam satu sub-kasus penggunaan bersama;
(b) Perluas dimana fungsionalitas suatu use case diperluas dengan mereferensikan use case lainnya; Dan
(c) Menggeneralisasi ketika beberapa kasus penggunaan berbagi sesuatu yang serupa.
Sebelum kita membahas hubungan ini secara lebih rinci, ingatlah bahwa kami terutama menulis kasus
penggunaan untuk dibaca orang. Kasus penggunaan tidak dibaca oleh compiler (program perangkat lunak
yang mengubah program komputer menjadi kode komputer yang dapat dieksekusi) atau oleh alat jenis
apa pun. Jadi sebelum kita menambahkan hubungan ke kasus penggunaan kita, kita harus yakin bahwa
menambahkan kompleksitas akan membantu pembaca (manusia) untuk lebih memahaminya.
Satu lagi peringatan. Seperti yang Anda lihat dalam bacaan, Jacobsen telah mengubah pandangannya
tentang cara terbaik untuk menghubungkan kasus penggunaan. Kasus penggunaan tidak didefinisikan
secara matematis, sehingga hubungan di antara kasus-kasus tersebut juga tidak didefinisikan secara ketat.
Anda mungkin akan menemukan bahwa ketika Anda membaca rincian tentang berbagai jenis hubungan,
semuanya akan tampak cukup sederhana, namun ketika Anda mencoba menerapkan pengetahuan ini, itu
bisa jadi sangat sulit. Setiap orang, baik pemula maupun praktisi terampil, menghadapi masalah yang
sama. Solusinya adalah dengan mengingat bahwa use case adalah untuk manusia
menggunakan.
http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/ma
r03/usecases_TheRationalEdge_mar2003.pdf
„
Baca halaman 45, yaitu bagian ‰ dan „
bahasa
Kasus penggunaan dan pemodelan terpadu
Berhati-hatilah saat memformalkan kasus penggunaan‰.
Catatan: Bacaan selanjutnya, mulai dari judul „‰, lebih maju dan teoretis.
Besok: potensi
langkah selanjutnya
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 4 KASUS PENGGUNAAN LAINNYA ÿ 89
4.1.1 Hubungan Sertakan
Pada bagian bacaan yang baru saja Anda pelajari, Jacobsen menjelaskan tentang „hubungan inklusif‰.
Saat Anda menulis kasus penggunaan, Anda mungkin menemukan bahwa bagian dari beberapa kasus
penggunaan terjadi di beberapa kasus penggunaan. Untuk menangkap kesamaan ini dan untuk
menyederhanakan kompleksitas kasus penggunaan yang panjang, Anda dapat menempatkan bagian
umum dalam sub-kasus penggunaan dan kemudian mereferensikan sub-kasus penggunaan ini dari kasus
penggunaan lain yang relevan. Jika Anda memiliki pengalaman dalam bidang tradisional, Anda pasti
bahasa prosedural pemrograman
sudah familiar dengan konsepnya
menggunakan subrutin untuk mengurangi kompleksitas pemrograman.
Sebagai contoh, mari kita perhatikan Video Victoria. Dalam Topik 2 kami mengidentifikasi kasus
penggunaan Pertahankan Anggota (Aktivitas 2.6). Tabel berikutnya adalah draf pertama untuk penggunaan tersebut
kasus.
Tabel 4.1: Kasus Penggunaan Pertahankan Anggota
Pertahankan Anggota
Niat Aktor
Tanggung Jawab Sistem
Identifikasi peminjam
Menampilkan detail pribadi (nama, alamat, tanggal lahir,
tanggal, bergabung, dll.) peminjam, ditambah ringkasan
pinjaman saat ini Simpan perubahannya
Secara opsional, pengguna dapat mengubah
rincian pribadi anggota
Secara opsional, pengguna dapat menghapus
anggota
Periksa apakah peminjam tidak meminjam apa pun
Hapus anggota tersebut
Sekarang bandingkan kasus penggunaan ini dengan Pinjam Video (dari jawaban Latihan 2.9). Apakah
ada kesamaan? Ya. Baris pertama untuk masing-masingnya sama: „Identifikasi peminjam‰. Saat kita
melihat kasus penggunaan dalam format penting, hal ini mungkin tampak tidak terlalu berarti. Namun,
sebelum kita dapat membangun sistem ini, kita harus memutuskan bagaimana peminjam akan diidentifikasi.
Akankah pengguna memiliki kartu untuk dipindai, atau akankah dia memberi kami nama atau nomor
identifikasinya?
Apakah dia perlu mengutip kata sandi? Jadi, untuk mengatasi semua kekhawatiran ini, kita dapat membuat
sub-use case yang kita sebut „Dapatkan Peminjam‰. Kini kasus penggunaan Video Pinjam dan Identifikasi
Anggota akan ÿmencakupŸ sub-kasus penggunaan Dapatkan Peminjam. (Perhatikan notasi UML yang
menempatkan karakter khusus ÿ Ÿ di sekitar kata „include‰.)
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
90 ÿ TOPIK 4 KASUS PENGGUNAAN LAINNYA
Jadi sekarang bagaimana tampilan kasus penggunaan kita? Di sisi lain kita bisa (lihat Tabel
4.2).
Tabel 4.2: Penyertaan Sub-Kasus Penggunaan
Pertahankan Anggota
Niat Aktor
Tanggung Jawab Sistem
Sertakan kasus penggunaan Dapatkan Peminjam
ÿ
Saat ini penggunaan teks yang digarisbawahi dalam sebuah situs web berarti hyperlink ke
sesuatu yang lain. Konvensi ini digunakan untuk use case untuk menunjukkan sub-use case.
Jadi cara penulisan singkatnya cukup dengan menggarisbawahi nama use case, seperti
berikut (silahkan lihat Tabel 4.3).
Tabel 4.3: Cara Singkat Penulisan Penyertaan Sub-use Case
Pertahankan Anggota
Niat Aktor
Tanggung Jawab Sistem
Dapatkan Peminjam
ÿ
Kasus penggunaan Dapatkan Peminjam adalah sebagai berikut (lihat Tabel 4.4).
Tabel 4.4: Kasus Sub-Penggunaan
Dapatkan Peminjam
Subfungsi
Tingkat:
Niat Aktor
Identifikasi peminjam
Tanggung Jawab Sistem
Menampilkan detail pribadi (nama, alamat, tanggal
lahir, tanggal bergabung, dll.) peminjam ÿ
Anda akan melihat judul di awal use case yang memiliki klausa level. Ini memberitahu kita
bahwa ini adalah sub-use case, karena hanya memberi kita sebuah subfungsi. Artinya, use
case ini tidak masuk akal dengan sendirinya. Itu perlu dipanggil oleh use case lain.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
KE
sertakan Notasi
Kasus Penggunaan
e Diagram Inc
ÿ 91
GAMBAR 4 LEBIH BANYAK KASUS PENGGUNAAN
pada
Memperlihatkan
w hubungan
penyertaan pada penggunaan c
kasus, UML sp
dengan ing kepanah
luded menggunakan cas
se (mohon rujuk
incl menunjuk
F
Gambar
4.1: Depi icting termasuk hubunganmu
baris tted,
menentukan sebuah titik
1).
eh ke Gambar 4.
P
AKTIVITAS4.1
4
Leet kami lagi t
al siap punya a
pikirkan kembali t ke situasi tersebut ion Victor
Video ria.
kasus penggunaan untuk
pinjam
eos. Tapi
video
sekarang
itu di dia juga ingin se
Anda
Victoria menceritakan
itu kamu
semua video lama itu yang dia lakukan itu tidak perlu.
ble, inkorpora
perbarui kami Andase kasus ke ulangmencerminkan cha initidak. Jika memungkinkan
incsertakan relasi
kasus.
nkirim ke simp
tingkatkan penggunaan Anda
makan sebuah
Ke atas
perbarui kamu
ca se.
Ke atas
Termasuk hubungan baik
ram
diagram kasus penggunaan
kapal adalah mo
A
pertama
st
aturan dari
kegiatan 2.11) w
dengan yang baru kami menggunakan
OST berguna relhubungan menjadi tween menggunakan
ases,
ca dan
d model yang digunakan
ng hanya hubungan ini. rn (2002, hal.
kamu bisa
membangun sangat rumit
s
ayam jantan20
07), menulis:
Sebagai
(dari Ac
mb, selalu
kamu
menggunakan
w
thmiliknya
yang mengikuti
Orang-orang siapa
termasuk
des
hubunganshipinggul antara
Memang,
kamu
T bahwa mereka menemukan
pembaca mereka
rs memiliki lebih sedikit co
dan
dengan mereka
campuran termasuk
yaitu dan memperluas
ds
yang
tulisan mereka itu aturan melaporkan orangho
dan [generasi
ayam jantanrn menganut pandangan ini karena
kasus penggunaan. onfusi sadar].
jika kasusnya,
e penekanannya kakak ada di dan teks kamu
peran mereka di com
rast, orang w
yang memberi
berkomunikasi antar orang
ople. Dengan kontras
lebih banyak em
d
penekanan pada th dia menggunakan kasusdiagram,
bagian
khususnya kapan n dilakukan dengan alat CASE,
mereka
seperti
e co yang ditambahkan
kompleksitas h
Selanjutnyat bagian disk
menjalin hubungan lain
cuss ekstensinya nd dan genera
hubungan baik
S.
kapal.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
92 ÿ TOPIK 4 KASUS PENGGUNAAN LAINNYA
4.1.2 Memperluas Hubungan
Hubungan perluasan adalah jenis hubungan lain antar kasus penggunaan. Di bagian sebelumnya kita melihat
hubungan include, yang dapat Anda anggap sebagai "melakukan sesuatu yang umum pada beberapa kasus
penggunaan". Definisi informal dari perluasan hubungan adalah 'melakukan sesuatu yang ekstra'.
Mari kita lihat contoh salah satu cara penggunaan hubungan perluasan. Di Video Victoria, kami memiliki
persyaratan ini (dari deskripsi Studi Kasus Video Victoria di Topik 1):
Ulang tahun anggota ditandai dengan video pilihan A surat khusus yang mengundang mereka ke pinjam apa saja
A minggu secara gratis.
mereka
Jadi kita jelas membutuhkan sebuah use case untuk menghasilkan surat ulang tahun, yaitu use case yang
sederhana. Namun, bagaimana kita menangani situasi ketika seseorang datang ke toko dengan membawa surat
ulang tahun dan ingin meminjam video secara gratis? Jelas ini merupakan perpanjangan dari kasus penggunaan
Pinjam Video.
Jadi, bagaimana tampilan kasus penggunaan ini?
Tabel 4.5: Hubungan yang Perluasan
Tangani Surat Ulang Tahun
Tingkat:
Subfungsi
Pemicu:
Pelanggan memiliki surat ulang tahun
Titik perpanjangan: Hitung total biaya yang harus dibayar dalam Pinjam Video
Niat Aktor
Tunjukkan bahwa peminjam memiliki surat
Tanggung Jawab Sistem
Pastikan pinjaman ulang tahun belum digunakan tahun ini
ulang tahun
Rekam penggunaan surat ulang tahun
Sesuaikan total jatuh tempo
Sekali lagi Anda dapat melihat kita berada pada level subfungsi. Klausa pemicu memberitahu kita kapan hal itu
dimulai, yaitu ketika pelanggan memiliki surat ulang tahun. Titik ekstensi memberitahu kita bahwa kasus
penggunaan Menangani Surat Ulang Tahun dimulai dari kasus penggunaan Pinjam Video ketika mencapai
bagian „hitung total biaya yang harus dibayar‰. Ini disebut titik ekstensi.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
KE
o pertahankan kitaJika kasusnya rapi, kami dapat mendokumentasikannyaingat Bor
Terakhir, untuk
menunjukkanbahwa ada ekstensi
N. Di tempat lain
ÿ 93
GAMBAR 4 LEBIH BANYAK KASUS PENGGUNAAN
baris Video untuk
kasus penggunaan
ke jelas untuk s
pesanan, kami mak
seseorang
e‰, ada begitu
ada sesuatu
membaca kasus penggunaan ini, sebagai bagian dari „menghitung total biaya yang harus dibayar
yang lebih terjadi
pening.
Tabel 4
.6: Dokumentasi
ng Kasus Penggunaan untuk Menampilkan Mantanxtension
Pinjam V Video
Ekstensi tepat: Kal
Hitung total biaya
Aktor Int
e jatuh tempo
ketegangan
Sistem Kembali
tanggung jawab
Dapatkan bor
pendayung
Kalkulasiketerlambatan total biaya yang harus dibayar untuk a denda di
Mengenali
kamu videonya
masa lalu
dana bo baru
Lulus t total cinta
atau tulisan tangan
jumlah karena th
dia Tunai
Daftar di Terminal
Perhatikan itu
di selain menambahkan mantan
kasus penggunaan,
,
exte
poin xtensi
tidak pada awal Peminjaman
kami miliki tidak tidak mengubah e teks itu sama sekali. Ini adalah sebuahn penting a
dan hubungan
pinggul. Pinjam Video adalah u yang lengkap dan utuh
sebelum wkami menambahkansurat
b
ulang tahun ers, jadi tidak perlu c
mengubah.
e Diagram Contohxtend Notasi
yaitu li bertitik
padan kasus penggunaan, spesifik UML
kasus penggunaan dasar (tolong r mengacu pada Gambar
ulang 4.2).
Memperlihatkan
w perpanjangan kembali
kegembiraan
aku menunjuk ke
F
Gambar
4.2: Dep
Sangat c penggunaan umum
diambil kapan saja. Sebuah
layar
id kapan saja
dari ekstensi
ujian umum
aspek
kasus penggunaan
pada
Kasus Penggunaan
panah
w Video yang
dan
menggambarkan ekstensinya
hubungan
ine, dengan
P
dan hubungan
aku
ip untuk beberapa orang
cukup adalah a
kemampuan untuk mencetak
bertindak itu di tidak bisa
menginformasikan
kawin aktif
e.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
94 ÿ TOPIK 4 KASUS PENGGUNAAN LAINNYA
Jadi, misalnya, jika kita mempunyai kasus penggunaan Pertahankan Anggota, maka setiap saat
petugas meja depan dapat mencetak ringkasan anggota tersebut.
KEGIATAN 4.2
Seperti yang dibahas di bagian sebelumnya, fungsi cetak adalah contohnya
hubungan yang diperluas. Tulis kasus penggunaan Pertahankan Anggota termasuk
segala sesuatu yang diperlukan untuk memungkinkan pengguna mencetak. Gambarkan juga use case-nya
diagram.
Perbedaan antara hubungan perluasan dan penyertaan diberikan di bawah ini:
Termasuk
Memperpanjang
Use case dengan perluasan (sub) use
Use case dengan use case umum
kasus
Use case utama memerlukan sub use case
Use case utama masih lengkap tanpa sub
use case
ini untuk menyelesaikan proses atau aktivitas
Hanya aktivitas tambahan
4.1.3 Hubungan Generalisasi
Hubungan ini jarang digunakan, bahkan lebih jarang digunakan dengan baik. Kami menyertakannya di
sini hanya sebagai peringatan bagi Anda yang mungkin menemukannya di materi lain. Inilah yang
dikatakan Cockburn (2002, p. 241) tentang hal itu. Notasi generalisasi kasus penggunaan:
Secara umum, masalah dengan hubungangeneralisasi adalah bahwa komunitas profesional
belum mencapai pemahaman tentang apa yang tersirat dalam perilaku subtipe dan cara
ke
spesialisasi, apa yang dimaksud dengan properti dan pilihan. Karena use case adalah deskripsi
perilaku, maka tidak ada pemahaman standar tentang apa itu perilaku
berarti
mengkhususkan mereka.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 4 KASUS PENGGUNAAN LAINNYA ÿ 95
Studi Kasus
Bab e-book berikut dari perpustakaan digital OUM (Books24x7) berisi studi kasus pembuatan diagram use
case. Anda wajib membaca bab ini.
7
Schmuller, Joseph. „Jam - Bekerja dengan
Use Case Diagram‰. Sams Ajari Diri Sendiri UML 1999. Buku
24x7. dalam 24 Jam.
toc.aspx?bookid=414>
Sam. © <http://common.books24x7. com/
4.2
MENEMUKAN SEMUA KASUS PENGGUNAAN
Jadi, bagaimana Anda tahu jika Anda telah menemukan semua kasus penggunaan?
Dalam pembacaan online sebelumnya, Jacobsen memberikan aturan praktis untuk jumlah kasus penggunaan.
Dia mengatakan, „sistem besar yang mendukung satu proses bisnis mungkin memiliki tidak lebih dari 20
kasus penggunaan‰. Jumlah ini tidak termasuk sub-kasus penggunaan, maupun kasus penggunaan tipe
generik, seperti logon atau logoff. Coba pikirkan tentang VictoriaÊs Video, yang hanya memiliki satu fungsi
bisnis kecil, yaitu menyewakan video.
Kami memiliki kurang dari 20 kasus penggunaan, jadi aturan ini tampaknya berlaku. Namun, dalam
praktiknya, dengan sistem yang besar, terkadang sulit untuk mengatakan apa yang dimaksud dengan satu
proses bisnis.
Cara lain untuk melihat berapa banyak kasus penggunaan yang harus ada adalah dengan mencatat tingkat
penemuan kasus penggunaan. Biasanya, seorang praktisi berpengalaman akan mengidentifikasi sekitar 70
persen kasus penggunaan dengan cukup cepat. Bagian selanjutnya mencakup beberapa teknik yang
digunakan saat bekerja dengan pengguna untuk membantu membuat proses tersebut selancar mungkin.
Namun, bagaimana dengan 30 persen kasus penggunaan lainnya? Beberapa di antaranya akan menjadi
jelas setelah Anda mulai menguraikan 70 persen awal. Ada juga dua teknik yang sangat berguna. Keduanya
mengharuskan kita bekerja dengan model kelas konseptual. (Inilah sebabnya kami mengajari Anda
menggunakan penulisan kasus dan pemodelan domain secara paralel.)
Teknik pertama adalah menggambar diagram keadaan untuk kelas konseptual utama. Pada diagram ini kami
kemudian menulis nama use case. Saat melakukan hal tersebut, kami sering menemukan kasus penggunaan
yang hilang.
Teknik kedua adalah memeriksa apakah Anda memiliki kasus penggunaan untuk membuat, membaca,
memperbarui, dan menghapus informasi untuk setiap kelas konseptual.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
96 ÿ TOPIK 4 KASUS PENGGUNAAN LAINNYA
4.2.1 Diagram Keadaan
Diagram keadaan menunjukkan siklus hidup suatu objek: peristiwa apa yang dialaminya, transisinya,
dan keadaan di antara peristiwa-peristiwa tersebut. Seperti kebanyakan diagram UML, diagram
keadaan menyediakan notasi dasar yang dapat digunakan untuk berbagai tujuan. Tujuan kita pada
tahap ini adalah untuk menggambar gambaran siklus hidup kelas konseptual yang menjadi inti sistem.
Biasanya dalam suatu sistem, hanya ada beberapa kelas konseptual yang benar-benar memerlukan
diagram keadaan. Tidak salah menggambar diagram keadaan untuk semua kelas konseptual, tapi
mungkin hanya membuang-buang waktu, karena menggambar semua ini tidak akan menunjukkan
sesuatu yang baru kepada kita. Jadi kuncinya adalah dengan cepat menentukan mana yang perlu
Anda lakukan.
Tabel berikut memberikan beberapa contoh sistem dan daftar kelas konseptualnya. Kolom ketiga
menyarankan kelas konseptual yang mungkin memerlukan diagram keadaan. Seperti yang Anda
lihat, kata-kata di kolom ketiga sebenarnya adalah inti dari setiap sistem.
Tabel 4.7: Contoh Sistem dan Kasus Konseptual yang Memerlukan State Diagram
Pesanan masuk
Kelas Konseptual itu
Kelas Konseptual
Sistem
Membutuhkan Diagram Negara
Pesanan, pelanggan, produk, kwitansi, toko,
Pesanan, pelanggan, produk
dll.
Manajemen aset Aset, pembelian, penjualan, lokasi, dll. Aset
Manajemen
Tahanan, tempat tidur, hukuman, laporan
tahanan
medis, perintah pengadilan, dll.
Pendaftaran mahasiswa Mahasiswa, mata kuliah,
Universitas,
Tawanan
Mahasiswa, tentu saja
dosen, dll.
AKTIVITAS 4.3
Untuk Video Victoria, tentukan kelas konseptual mana yang memerlukan status
diagram.
Sebagai contoh, mari kita perhatikan sistem penjara.
Misalkan kita baru saja mulai bekerja dan kita telah mengidentifikasi tiga kasus penggunaan:
(a) Penerimaan Menangani tahanan yang dipindahkan dari polisi atau
pengadilan ke penjara, dan diterima.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
KE
(b) Lalu
jawab Tangan
transfernya
(c) Rel
sewa Tangan
Dles cara di mana ap
GAMBAR 4 LEBIH BANYAK KASUS PENGGUNAAN
r sampai setengah wa
menjadi seorang tahanan
ya
ÿ 97
rumah.
tahanan kembali dilepaskan kembali ke
com
komunitas.
lel dengan iden ntifying dan w
Secara paralel
konsep
kelas ual
jadi kami berhenti
seni
Apa yang harus dilakukan
oes
el. Cepat w
kita
penggunaan tulisan kasus,
c
juga bekerja
kami menyadari hal itu
t Tahanan adalah a konsep kunci
g pada mod
kelas ual,
menggambarnya
s diagram keadaanM.
suatu negara bagiantampilan
d
e adalah ujian
diagram kamu suka? Di Sini
sederhana (tolong
mengacu pada
Gambar 4. .3).
Aragambar 4.3: Sebutkandiagram
d
untuk Pri versi isoner
pada 1
Catatan: HalJika rumah jalan adalah
adalah tempat untuk menyimpan
op di tengah jalan aperjalanan.
Kita punya e kotak dengan cor bulat
diberikan am
bermakna n
ini av
sangat umum
Apa ini
ners ke deno
nama. Perhatikan bahwa nam
menunjukkandia
th
t negara bagian berakhirndi„ed‰
n berakhir untuk Enegara bagian Inggrisnama.
n
bagaimana itu th ini tiga
adalah diagram sh
kita
Selanjutnya kita
e. Setiap negara bagian harus
perhatikan setiap negara bagian
aku yang terakhir
lihat caranyaw kasus penggunaan kamipasokan model
menggunakan kasus pada diagram keadaan (pl
e menyatakan bahwa tahanan bisa masuk
tolong staf ini
sewa lihat
makan. Jadi yang kami lakukan adalah
o Gambar 4.4)
diagram aku
kita sekarang ini:
Aragambar 4.4: Sebutkandiagram
d
untuk Pri versi isoner
pada 2
Hak Cipta © Universitas Terbuka Malaysia (OUM)
. Jadi
Machine Translated by Google
98 ÿ KE
9
E KASUS PENGGUNAAN
OPIC 4 LEBIH BANYAK
N
Perhatikan juga, th dia memulai
stYang terakhir, hormat
secara efektif.
dan simbol keadaan akhir. Itu
S o sekarang kita bisa
diagram s ke t
Hai
aku akan menunjukkan ini
pengguna ke c
ini menunjukkan thdia pertama dan l
tegaskan bahwa wkami benar
tidak
dalam pemahamanmu
dan siapa yang mengerti
berdiri sistem penjara uld wou
menemukan. Sangat mirip
mungkin seseorang
saay:
„Yah, itu
semuanya baik-baik saja, tapi bagaimana jika ya
A
Setelah beberapa di
miliknya
(F
Gambar
diskusi dengan kecerdasan
th
A tahanan esca
pengguna, kita bisa kembali
kera?‰
menggambar dia agram seperti th
4.5):
m untuk Tahanan
Gambar 4.55: Diagram keadaan
T
Versi baru ini
versi 3
ion memiliki yang baru
w negara bagian disebut Escaped (bukansepertinya itu sudah berakhir
ds dalam „ed‰), a dan
w
kami punya identitastified dua baru
w kasus penggunaan,yaitu
n
Escap
krrusial o
caases.
makan diagram mereka membantu kamu kita untuk segera f menemukanmu yang hilang
menggambar sta
e dan tutup ulanggambar. Ini adalah t titik
menggunakan
N
Perhatikan
pada diagram terakhir ini m bahwa kita sekarang
kami mengenali t
N
gambar. tidak
pernah mendapatkan rekap
bahwa beberapa esc
tahanan berjubah
AKTIVVITA 4.4
Untuk Vic Video toriaÊs
Pita,
s, gambar dua s
negara bagian yang terpisah
e diagram,
aktif
tidak untuk Video
dan temukan satu untukku
bara.
sebuah
Apakah kamu
kamu mengidentifikasi apa pun kasus penggunaan yang hilang?
Hak Cipta © Universitas Terbuka Malaysia (OUM)
ers
Machine Translated by Google
KE GAMBAR 4 LEBIH BANYAK
4.2.2
Menunjukkan
ng
KASUS PENGGUNAAN
ÿ 99
Super S Amerika
Setelah menggambar
Staf super ates adalah seorang teknisi
teknik untuk sim menyederhanakan sta
makan diagram.
ng „Diagram
m
untuk
Tahanan
versi
3‰
kita
bisa
sh
bagaimana
dengan
ano
pengguna
lain
ap
,
keadaan
ho mungkin
berkata:
Ini baik saja,
B tahanan
tapi
“Kamu
rumah. Dari tentu saja
Jadi di
S juga bisa scape
yaitu
dari menjadi
berada di h
setengah jalan
N merekapergi
kembali ke dalam tahanan
y.‰
jikakami
kamumenangkap
yakin, kalau begitu
terlihat seperti ini
S:
iagram bisa
Ara
gambar 4.6: Sebutkandiagram
d
untuk Priversi isoner
Kamu akanaku perhatikan itu ada
t dua
sejak th
ini merujuk pada
memperkenalkan
cing
Di n
o transisi,
sama kamu
ept dari super
conce
pada 4
atau kasus penggunaan,
disebut melarikan diri
pe.
Sekarang
kasus penggunaan, wkita bisa menyederhanakannyamenyempurnakan diagramnya
gram dengan
negara bagian (lihat Gambar
ulang 4.6).
ada sebuahnegara bagian yang super
Aku menelepon Laksamana
disetujui. Jadi
Anda dapat melihat bahwa
t
versi ext y
apa yang kita
tahanan wa Dalam Penahanan o
e sekarang katakan
ying adalah jika atauada
Di setengah
e di negara bagian Lolos.
E
Sekali
dan mereka
y Kalau begitu, kaburlah
dan mereka akan menjadi seperti itu
, jika mereka r
bagian Lolos,
y rumah,
e mereka berada di negara
ditangkap kembali, mereka
t
pergi ke e negara bagian Di Cus
tenang (tolong e lihat .7).
Gambar 4.
Ara
gambar 4.7: Sebutkandiagram
d
untuk Priversi isoner
pada tanggal 5
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
100 ÿ TOPIK 4 KASUS PENGGUNAAN LAINNYA
4.2.3 Buat + Baca + Perbarui + Hapus = CRUD
Sekarang kita melihat teknik kedua yang membantu kita menemukan kasus penggunaan yang hilang.
Akronim „CRUD‰ adalah singkatan dari Buat, Baca, Perbarui, dan Hapus. Kita perlu memeriksa setiap
kelas dalam diagram kelas konseptual untuk memastikan bahwa kita memiliki semua operasi ini, atau kita
dapat memutuskan untuk tidak memasukkannya. Misalnya, operasi penghapusan sering kali dihilangkan.
Di Video Victoria, ada Anggota kelas konseptual. Dalam tinjauan informal model kelas konseptual dan kasus
penggunaan, percakapan ini dapat dengan mudah terjadi:
Sarojini (
pengulas
Tiveesha ():
Apakah kita memiliki kasus penggunaan untuk membuat anggota?
):
Ya, ini disebut „Buat Anggota‰.
perancang
Sarojini: Apakah kami memiliki kasus penggunaan yang dapat membaca anggota?
Tiveesha: Ya, kami punya beberapa. Yang utama adalah Mempertahankan Anggota dan
Pinjam Video.
Sarojini: Apakah sistem mendukung pembaruan anggota?
Tiveesha: Ya, sekali lagi itulah kasus penggunaan Keep Members.
Sarojini: Dan yang terakhir, bagaimana dengan penghapusan?
Tiveesha: Jawaban yang sama lagi karena dalam sistem ini memperbarui dan menghapus cukup
mudah, kami telah menggabungkannya ke dalam satu kasus penggunaan.
Sarojini: Ide bagus. Sekarang, beralih ke kelas konseptual lainnya ÿ
Dalam percakapan ini, Sarojini telah mengkonfirmasi bahwa Tiveesha telah mempertimbangkan semua
operasi CRUD untuk Anggota kelas konseptual. Rangkaian pertanyaan berikutnya adalah tentang kelas
konseptual lain, seperti Video.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 4 KASUS PENGGUNAAN LAINNYA ÿ 101
AKTIVITAS 4.5
Lanjutkan review Sarojini dan lihat kelas Spesifikasi Video.
Apa yang kamu temukan?
4.3
PERATURAN BISNIS
Kami sekarang mendekati akhir analisis kebutuhan. (Ingatlah bahwa „mendekati akhir‰ di sini berarti akhir
dari pembahasan analisis persyaratan. Dalam praktiknya, karena kita melakukan berbagai hal secara
berulang di UP, semua tugas dalam analisis persyaratan akan mencakup berbagai fase di UP .)
Sebelum kita beralih ke pembahasan desain, ada topik sangat penting yang tidak boleh kita lewatkan:
aturan bisnis.
Aturan bisnis mungkin merupakan bagian paling dasar dari analisis persyaratan dan harus dilakukan
bersamaan dengan pemodelan kasus penggunaan. Bacaan berikut mengeksplorasi hubungan antara
aturan bisnis dan kasus penggunaan secara lebih lengkap:
Gottesdiener, E. (1999). „Menangkap aturan bisnis‰, Majalah Pengembangan Perangkat Lunak,
7(12), di <http://
www.ebgconsulting.com/pubs/articles/businessrulesrule_gottesdiener
.pdf>
Faktanya, selain perannya dalam kasus penggunaan, aturan bisnis juga terkait dengan artefak lain dalam
proses pengembangan perangkat lunak. Bacaan berikut membahas tautan tersebut, khususnya pada
desain antarmuka pengguna, pembersihan data, dan validasi.
Ambler, S (2000) „Aturan bisnis berorientasi objek‰ di: <http://
www.sdmagazine.com/documents/s=826/sdm0006j/>
Di bagian terakhir bacaannya, Ambler menyebutkan Object Constraint Language (OCL) sebagai sarana
untuk mengekspresikan aturan bisnis. Para ahli lain tidak setuju.
Misalnya, Gottesdiener mengatakan bahwa peraturan bisnis harus ditulis dalam bahasa yang dimengerti
pengguna. Kami juga ingin mengadopsi pendekatan ini dalam menulis aturan bisnis. Berikut adalah
beberapa opsi yang kami sarankan untuk mengungkapkan aturan bisnis dengan cara terbaik:
(a) mencantumkan semua aturan dalam satu daftar, dan kemudian merujuk ke daftar tersebut dari kasus
penggunaan lainnya, maket layar, diagram kelas, dll.;
(b) cukup temukan aturan dalam kasus penggunaan, seperti yang telah kita lakukan dalam kursus ini; Dan
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
102 ÿ TOPIK 4 KASUS PENGGUNAAN LAINNYA
(c) membuat kasus penggunaan tetap sederhana, namun menambahkan bagian ke template kasus penggunaan
Anda untuk secara eksplisit merujuk pada aturan bisnis yang diterapkan setiap kasus penggunaan.
Jadi, seperti yang Anda lihat, ada berbagai kemungkinan. Faktor tambahan yang perlu dipertimbangkan
adalah gaya sistem (misalnya, apakah sistem tersebut melibatkan banyak perhitungan), ukuran aplikasi, alat
yang digunakan, dll.
Jadi apa aturan bisnis di VictoriaÊs Video? Berikut beberapa contohnya:
(a) Hanya anggota yang dapat meminjam video;
(b) Apabila ada orang baru yang mengajukan permohonan untuk menjadi anggota, ia harus menunjukkan
SIM atau tanda pengenal lainnya yang berfoto;
(c) Usia minimal 16 tahun;
(d) Seorang anggota dapat meminjam video dalam jumlah berapa pun, selama tidak ada video yang sudah
lewat batas waktunya;
(e) Ada denda untuk video yang sudah lewat waktunya;
(f) Lamanya waktu peminjaman video bergantung pada video tersebut.
Rilisan baru hanya dipinjamkan dalam semalam, rilisan saat ini untuk sewa tiga hari dan sisanya untuk
seminggu;
(g) Anggota dapat memesan video;
(h) Setiap video memiliki klasifikasi, (G umum, PG bimbingan orang tua, MA penonton dewasa, dan R
terbatas). Anggota harus berusia di atas 18 tahun untuk meminjam video R. Setiap video juga memiliki
kategori: roman, umum, fiksi ilmiah, bahasa asing, dan anak-anak;
(i) Saat seorang anggota berulang tahun, mereka akan dikirimi surat khusus yang mengundang mereka untuk
meminjam video apa pun pilihan mereka selama seminggu secara gratis;
(j) Setiap tiga bulan sekali toko melakukan stock opname; Dan
(k) Setiap video yang hilang diperbarui untuk ditampilkan sebagai hilang.
Anda harus mengenali sebagian besar teks ini karena cukup dekat dengan deskripsi awal yang Anda lihat
dari Studi Kasus Video Victoria di Topik 1. Saat mendeskripsikan suatu sistem, salah satu metode yang
sangat umum adalah membuat daftar dan mendeskripsikan aturan bisnis. Keahlian seorang analis persyaratan
adalah menangkap aturan-aturan ini dan menjadikannya sesuatu yang dapat dikerjakan oleh tim desain dan
pemrograman lainnya. Kasus penggunaan adalah cara utama untuk menyatukan aturan bisnis untuk
menciptakan sebuah sistem.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 4 KASUS PENGGUNAAN LAINNYA ÿ 103
KEGIATAN 4.6
Untuk masing-masing contoh aturan bisnis yang baru saja kami berikan untuk Victoria
Video, putuskan apakah aturan telah diterapkan dalam kasus penggunaan apa pun. Jika begitu,
sebutkan nama mereka; atau, Anda mungkin memperhatikan bahwa aturan bisnis belum ada
ditangkap dalam kasus penggunaan apa pun.
Latihan sebelumnya seharusnya membantu Anda memahami fakta bahwa terdapat hubungan yang cukup
kuat antara kasus penggunaan dan aturan bisnis, namun setiap bentuknya sangat berbeda.
4.4
LEBIH BANYAK PEMODELAN
Jadi, di mana kita akan pergi? Kita hampir selesai dengan diskusi kita tentang analisis kebutuhan. Namun
pada tahap UP ini, persyaratan kami belum lengkap, sehingga kemungkinan ada beberapa bagian sistem
yang lebih lengkap dibandingkan yang lain. Kami memiliki diagram kelas konseptual, dan serangkaian kasus
penggunaan dengan aturan bisnis. Beberapa pekerjaan lain yang dijelaskan dalam Topik 3 juga dapat
dilakukan, seperti SSD. Kami juga memiliki beberapa diagram keadaan untuk kelas konseptual yang penting.
Oleh karena itu, sudah waktunya bagi kita untuk memulai beberapa pekerjaan „desain‰.
Terkait Video Victoria, apa yang kami punya?
Dari Topik 2 dan topik ini, model use case kami sedang dikembangkan. Kami memiliki daftar aktor dan
kasus penggunaan. Kami memiliki diagram kasus penggunaan secara keseluruhan. Beberapa kasus
penggunaan telah ditulis secara rinci, sementara yang lain hanya memiliki nama. Kami memiliki diagram
aktivitas untuk menunjukkan bagaimana beberapa kasus penggunaan utama cocok satu sama lain.
Dari Topik 3 kita mempunyai model kelas konseptual dan dari topik ini juga kita telah menggambar beberapa
diagram keadaan untuk kelas konseptual Member dan Video Tape.
Jadi sekarang kami ingin beralih ke model desain. Namun, ada kesenjangan yang sangat besar antara kelas
domain konseptual dan kelas desain. Untuk membantu kita menjembatani kesenjangan ini, ada teknik yang
disebut analisis ketahanan (terkadang juga disebut „analisis kasus penggunaan‰). Teknik ini dapat
membantu kita untuk menghasilkan desain awal. Teknik ini sangat berguna bagi pemula, namun bahkan
desainer berpengalaman pun sering menggunakan teknik ini ketika menghadapi masalah yang sulit.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
1 04 ÿ KE
E KASUS PENGGUNAAN
OPIC 4 LEBIH BANYAK
R
Kekokohan di
bantuan iagramtolong kita cepat mudah mengidentifikasikelas
d
desain
R
Kekokohan
di
iagram adalah mjauh lebih cepat r harus dilakukan daripada urutan diaagram karena
thhei kurang detail
D. Kekokohan
diagram dia
sebuah
e 4.8).
analisis ke des tanda tangan (tolong ulang
mengacu pada Gambar
s dan metode
ds.
menggunakan
kesenjangan itu om
bantu kami menyeberang t
F
Gambar 4.8: Robu diagram kegunaanms bantu jembatan
e kesenjangan antara
antara analisis dan dan fase desain
se
R
Kekokohan
di
UML normal sehingga sebagian besar CASAlat SE melakukantidak
n
iagram adalah n bukan bagian dari fo
su
mendukung mereka.. Namun, th
dia semangat t jenis d
diagram adalah th
tapi itu benar
ya
tidak
r
lebih
dari
t
‰,
yaitu
tindakan
dra
buang‰
menakjubkan itu membantu Anda jauh
en
Faktanya, sebagai semantik dari f kekokohan d diagramnya cukup longgar
produk ke-nd. SAYA
Sangat mungkin untuk memiliki banyak
Q
kamu berbeda versi dari hal yang sama.
4
4.4.1 Ro
T
Bagian ini ta
MS
sifat keras kepala
s Diagram
membuat kamu senang
ya
menggambar ga kokoh
R
Kekokohan sebuah
keterlibatan analisisaku menganalisisnya
ng narasinya
mengidentifikasi af
set tebakan pertama
t objek th
obobjek dapat diklasifikasikan menjadio tiga jenis,
(A
a) Batas
ss diagram fo
teks aktif id
atau satu penggunaan ca
as.
kasus penggunaan a
Dan
topi akan berpartisipasiipate di setiap kasus penggunaan. Ituini
, yaitu
coba;
(B
b) Entitas; sebuahdan
(C
c) Pengendalian eh.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 4 KASUS PENGGUNAAN LAINNYA ÿ 105
Masing-masing mempunyai simbol tersendiri (lihat Gambar 4.9).
Gambar 4.9: Simbol batas, entitas, dan pengontrol
Objek batas mewakili semua hubungan antara objek internal sistem dan dunia luar. Jenis objek batas
yang paling umum adalah bagian dari antarmuka pengguna, seperti jendela atau kotak dialog. Pembaca
kode batang juga diwakili oleh objek batas.
Misalnya, di Video Victoria kita memiliki objek untuk mengontrol pembaca kode batang.
Objek entitas adalah objek yang mewakili data yang harus diingat oleh sistem, baik secara permanen di
luar eksekusi use case (data tersebut mungkin disimpan dalam tabel database) atau untuk eksekusi use
case. Model domain konseptual harus menjadi sumber dari banyak objek entitas Anda. Biasanya, Anda
akan menemukan entitas baru yang tidak ada dalam diagram kelas domain Anda. Ini bukan cacat pada
model konseptual Anda, namun merupakan tanda bahwa analisis ketahanan membantu Anda.
Dalam Video Victoria, objek yang telah kita identifikasi sebagai kelas konseptual mungkin semuanya akan
direpresentasikan sebagai objek entitas.
Objek pengontrol mewakili hal lain yang Anda perlukan agar keseluruhan diagram masuk akal. Hal-hal
seperti aturan bisnis atau proses yang ditangkap oleh use case akan ditampilkan sebagai objek pengontrol.
Di Video Victoria, semua logika yang membentuk kasus penggunaan akan berada dalam objek pengontrol.
Selain itu, kita bisa meletakkan beberapa perhitungan di objek pengontrolnya sendiri.
Kita akan mempelajari sebuah contoh, tapi pertama-tama kita perlu memperhatikan aturan-aturan berikut,
yang harus dipatuhi oleh diagram ketahanan:
(a) Aktor hanya berbicara pada objek pembatas;
(b) Objek batas hanya berkomunikasi dengan objek pengontrol;
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
1 06 ÿ KE
E KASUS PENGGUNAAN
OPIC 4 LEBIH BANYAK
ajak untuk boun
(C
c) Pengendalian
eh benda ta
kendalinya ers; Dan
(D
d) Entitas ob
objek hanya bicara
objek yang tidak penting
ts,
entitas ob
objek atau lainnya
ers.
kamu untuk mengendalikan
Jika
jika kamu menemukantopi
th kamu tidak bisa atau memodelkan diagram dengan cara ini, itu
dan mungkin kamuAnda
N
perlu menambahkan objek baru. T
Himpunan ob
potongan pertama di t
yang harus dilakukan adalah a
objek yang Anda akhiri
sekumpulan desain c gadis.
H ujiannya
Ini
contoh sebuah val ketahanan identitas
diagram s (ple
Gambar 4.10:
fa valid kuat
Contoh dari
kemudahan lihat FGambar 4.10).
diagram ketuhanan
HAI
Tentu
saja ini
eds beberapa wo perintah untuk memberi label pada semua entitas ya, jadi kami tahu
s diagram ne
w
aduh,
tentang apa itukeluar. Langsung tions dari ar
orang bodoh adalahIni tidak khusus sebagian besar penting
o kamu bisa Dra aw mereka yang mana
cara chever m
Jadi
F atau mereka yango sudah khawatir
akrab dengan
dengan kecerdasandetail m
pesan antara
w
kami melakukan selanjutnya
diagram pengaruh ms sendiri
semut, membuat lebih
se
masuk akal bagi Anda.
h urutan dia
bersama
bahwadikita
adalah
n
agram, perhatikan bukan
antara
objeknya
dll. com
aku nanti ap
induk ayam
yaitu.
S o bagaimana kabarmukamu mulai? Dengan baikaku, kamu kembali k untuk Anda gunakan
e kasus. Ambil teksnya, dan
Anda melakukannya, SSD-nya. Sta
kondisi di wo lain
kamu
bersama
melalui kasus penggunaan. Aku g
baiklah, ambillah „hari yang cerah‰
mayor atau sejenisnya
hanya kesalahan bisaakan ditangani
pertimbangkan bagaimana m
bersama
membaca seni t
‰ mendekati.
D.
,
jika
kesalahan
tidak ada kesalahan
Bisa
Nanti kamu c
L
Mari
kita sekarang sp
tunggu sedikit waktu untuk bekerja ng melalui sebuah n diperpanjang e contoh ho
roketegaran dia
pemrograman ca sebuah karya di pr latihan.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
aduh
Machine Translated by Google
KE GAMBAR 4 LEBIH BANYAK
e
Contoh
Lihat gambar b
di bawah ini yang menunjukkan SSSD untuk P
KASUS PENGGUNAAN
Proses Penjualan
ÿ 107
kasus penggunaan
(Larman n (2002)):
N
Catatan:
*[...]
] adalah
itu
tanda terasi
er dan
klausa indikasi ng c
B
kotak
untuk iterasition.
Sumber: LLarman (2002), halaman 119
Jadi marilah kita
Mari menggambar robu
diagram
dari
e kasir ke th
kegunaan saya untuk ini. T Baris pertama adalah „Make Ne
dia sistem. Th
dia adalah perwakilan
dimasuki oleh bo objek dasar
aturan kamis di atas, kita tahu bahwa batas ob
menggambar satu. Dia
ke
pengontrol,ojadi
mungkin terlihat seperti itu
objek hanya bisa
4.11: Versio
ct. Dari
objek
kamu berbicara dengan rekan
yang berikut iniing.
ure
Gambar
ew Sale‰,
pada 1
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
1 08 ÿ KE
E KASUS PENGGUNAAN
OPIC 4 LEBIH BANYAK
T
Baris berikutnya o dari SSD adalah "Masukkan Item"‰. Jelas sekali, inis membutuhkan ano
batas lainnya
ary
obobjek disebut E Masukkan Barang.
2: Versi 2
Gambar 4.12
T
Baris berikutnya odari SSD adalah dmenampilkan
en
entitas Butir a
dan Spesifikasi Produk
sebelum kita membutuhkan t
e deskripsi dan harga. H
. Aturan s
mengatakan bahwa hanya pengontrol cBisa
taberbicara dengan entitas
w baris dari Penjualan Baru
s, jadi kita menggambar
P
Spesifik Produk
objek fiksi
e Pengendali t
ke butir a
ts.
3: Versi 3
Gambar 4.13
Hak Cipta © Universitas Terbuka Malaysia (OUM)
dan
Machine Translated by Google
KE GAMBAR 4 LEBIH BANYAK
Untuk menampilkan
ya
harga dan deskripsinya
ion, tambahkan nebatas baru
ure
Gambar
Kee ini
tapi kami melakukantidak
n
eps yang sedang berjalan,
4.14: Versio
perlu sh
KASUS PENGGUNAAN
ÿ 109
:
pada 4
karena kita sebenarnya
kamu hanya tertarikditempatkan di findin
ng tahu apa th
atau berulangG. Ini adalah
dia entitas ar
re, bukan di
th
gambaran bagaimanamereka digunakand itu terjadi
masuk nanti
dia merincinya
bagaimana pengulangan
aktif
optik.
Selanjutnyakami tidak menarik acara
adalah kapan
n pengguna ind
e
menyatakan bahwa dia
e sudah 'selesai'. T
Kalau begitu,
pergi dan c hitung kita mungkin Di
n sini w
Spesifikasi produk
n (misalnya
butuh beberapa mlebih jelasnyaf
entri telah di
e, banyak hitungan
pajak di di item yang berbedaS). Juga, kami m mungkin memerlukan beberapa
saya informasi
dari pajak.
tingkat yang berbeda
s penjualan
biarkan saja tarif pajaknya
yaitu. Jadi
info kapak dengan catatan
t
„inve
dia‰. Anda
kami masukkan
n suatu entitas ob objek yang disebut Ta
memperkirakan lebih jauh
c
3
itu
tidak
su
semua
kelas
ada
nfo mungkin
ed, tapi Pajak Masuk
semuanya dari Topi
konsep seperti itu
bisa mengingatnya
menjadi kaleng
ndidate untuk menjadi
eing
diagram m, dalam hal ini a
di kelas
diagram pantat.
diagram ketahanan, ind
Sekali lagi, ulah dr
menunjukkan di mana ada lubang
desain kami.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
menggambar
es dalam
Machine Translated by Google
1 10 ÿ KE
E KASUS PENGGUNAAN
OPIC 4 LEBIH BANYAK
Gambar 4.15 : Versi 5
N
d untuk menyimpan semua informasi dikumpulkan
Selanjutnya, kita perlu
gadis, , kita melihat ada dua
M.
Sdan Item Baris ales
sel
diagram
. Melihat semua konsep kami
o panggilan kelas tinggal di sini, npenjualan yang baik a
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
KE
ure
Gambar
4.16: Versio
GAMBAR 4 LEBIH BANYAK
KASUS PENGGUNAAN ÿ 111
n6
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
1 12 ÿ KE
GAMBAR 4 LEBIH BANYAK KASUS PENGGUNAAN
L
Terakhir kita berurusan dengan bayarannyament.
Gambar 4.17: Versi 7
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 4 KASUS PENGGUNAAN LAINNYA ÿ 113
Bacaan berikut akan memperkuat pemahaman Anda tentang analisis ketahanan dan cara menggambar
diagram ketahanan untuk kasus penggunaan Anda. Pembacaan ini juga menunjukkan beberapa
kesalahan umum dalam analisis ketahanan yang harus Anda hindari.
„Analisis ketahanan yang berhasil‰ di <http://www.sdmagazine.com/documents/ s=733/sdm0103c/
0103c.htm>
AKTIVITAS 4.7
Dengan asumsi Anda memiliki kasus penggunaan berikut untuk Pinjam Video, gambarlah a
diagram ketahanan untuk menangani kondisi berikut:
(a) Video Peminjaman Toko Video Kasus Penggunaan
(b) petugas memindai kartu peminjam
(c) sistem menampilkan kata sandi peminjam
(d) peminjam secara lisan memberikan kata sandi
(e) petugas memindai video
(f) sistem menampilkan biaya
(g) peminjam membayar
(h) sistem mencatat informasi.
• Kasus penggunaan adalah inti dari analisis persyaratan yang menjadi landasan seluruh proyek
pengembangan dengan memandu kita untuk „melakukan hal yang benar‰. Pembahasan use
case kita mulai pada Topik 2. Pada topik ini, kita menguraikannya dengan membahas bagaimana
menghubungkan use case menggunakan sub-use case, termasuk „extend‰ dan „include‰.
• Satu pertanyaan yang selalu membingungkan pengembang sistem yang tidak berpengalaman adalah
„berapa banyak kasus penggunaan yang cukup untuk sistem ini?‰ Dalam kebanyakan kasus,
tidak ada jawaban pasti. Namun, ada beberapa teknik yang dapat membantu kami mengidentifikasi
kasus penggunaan yang terlewat. Salah satunya adalah menggambar „diagram keadaan‰ dari
kelas konseptual penting dalam model domain. Cara lainnya adalah dengan melihat operasi CRUD
dari kelas konseptual. Metode-metode ini, dalam satu atau lain cara, dapat membantu
mengidentifikasi serangkaian kasus penggunaan proyek yang lebih lengkap.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
1 14 ÿ KE
•
OPIC 4 LEBIH BANYAK
E KASUS PENGGUNAAN
Sebelum kita menyelesaikannya
diskusimu
Kak, kita harus
n sesuai kebutuhan
analisis manajemen
Temukan
bisnisnya
memahami d aturan o
logika behi
bukan targetnyasistem yang didapat
mereka tidak bisa
Kalau
sedang melayani.
HAI tidak, kita e akan menentukan
Anda pasti akan berakhir dengan sebuah sistem
aturan
bisnis
nisasi
miliki
e ke
bukan fungsi dengan
pr
es dari komputer pany atau organ
sangat baik. b
dipelajari
d secara rinci.
Aturan bisnis
kami bertaruh
tidak hanya itu kamu bisa membantumu
persyaratan yang lebih
baiknts, mereka juga akan melakukannyao dirujuk
analisis
d oleh model lain di kemudian hari
dalam desain,, implementasi asi dan testi
•
lihatlah
ta alat yang dapat membantu untuk bmenjembatani gaap antara t
Kami juga akan melakukannya
nts dan de
persyaratannya
diagram c
tahapan.
desain robu
dapat membantu kita untuk melakukannya
o mengidentifikasi
anal kehausan lisis. Menggambarkuat
pohon cemara
kasus.
tebakan pertamaobjek
set o
di th
<<memperluas>>
Nyatakan dia
agram
<<sertakan>>
Kasus penggunaan
yaitu
R
Kekokohan d diagram
Kasus penggunaan
A
Ambler,
S. (20
000). Objek-o
sdmagaz zine.com/doc
diagramnya
bisnis yang berorientasi
aturan ness. Ulang
diambil
jumlah/s=82
26/sdm0006j/
C
se kasus.
Ayam Bakar, A. ( (2002). Menulis
ng efektif bagi kita
acobson, I., C
Ya
R
Diperoleh dari sana
om: http://
hristerson, M M., Jonsson, P.
perangkat lunak
misalnya,
rekayasa,
penggunaan
kasus
a
m: http://ww
ww.
/
ding, MA: Iklan ddison-Wesley
/www.ebgcon
ttesdiener.pd
aturanaturan_dapat
dari
Membaca
G
aturan ness.
Gottesdiener, E E.(1999). Topi mengambil bisnis
M
Majalah.
bisnis
ess
dia menggunakan
kamu.
lembut
perangkat lunak Develo
pilihan
nsulting.com/
/pub/artikel
es/
F
ted
., & Overgaar rd, G. (1992).
Berorientasi objek
D
sakit.
MA:
Addiso
padapendekatan yang didorong
Membaca, ,
Wesley.
L
Larman,
C. (20
Aula.
002). Terapkan
UML dan pola hal
. Uppper Sadel Riv
ver, NJ: Persetanwaktu
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 4 KASUS PENGGUNAAN LAINNYA ÿ 115
Rosenberg, D. dan Scott, K. (1999). Gunakan pemodelan objek berdasarkan kasus dengan UML:
Pendekatan praktis. Membaca, MA: Addison-Wesley.
Von Halle, B. (2002).
Penerapan aturan bisnis: Membangun sistem yang lebih baik dengan
menggunakan pendekatan aturanNew
bisnis.York
NY: Wiley.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
Tema ÿ Dinamis
5
Pemodelan
HASIL BELAJAR
Pada akhir topik ini, Anda seharusnya mampu:
1. Menjelaskan peran pemodelan desain; 2.
Menjelaskan tujuan diagram kolaborasi UML; 3. Menggambar
diagram kolaborasi UML yang benar untuk suatu sistem; 4.
Menjelaskan tujuan diagram urutan UML; 5. Menggambar
diagram urutan UML yang benar untuk suatu sistem; 6.
Menggambar diagram kelas desain; 7.
Mendefinisikan dan menggunakan pewarisan pada
diagram kelas; 8. Definisikan istilah
polimorfisme; 9. Menjelaskan kelas abstrak dan
konkrit; 10. Menjelaskan prinsip desain kopling dan kohesi; Dan
11. Sebutkan prinsip desain lainnya.
ÿ PENDAHULUAN
Pada topik ini kita melanjutkan dari Topik 4 dan masuk ke tahap desain. Anda akan benarbenar "melihat" bagaimana sistem berorientasi objek menyatu dalam kelas perangkat
lunak. Secara khusus, Anda akan melihat bagaimana objek meneruskan pesan ke objek
lain, dan dengan melakukan itu, Anda akan mendapatkan gambaran umum tentang cara
kerja sistem.
Ada dua diagram interaksi di UML. Keduanya menunjukkan bagaimana pesan dikirimkan
antar objek. Topik ini menjelaskan keduanya secara rinci.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 5 PEMODELAN DINAMIS ÿ 117
Dengan mempelajari diagram ketahanan di Topik 4 dan diagram interaksi di Topik 5,
Anda akan mempelajari lebih lanjut tentang cara kerja kelas perangkat lunak sebenarnya.
Dengan demikian, hasil dari diagram interaksi adalah mengambil apa yang telah dipelajari
dan mulai mengerjakan diagram kelas desain.
Topik ini juga akan membahas konsep pewarisan dan polimorfisme berorientasi objek
yang sangat penting.
Topik diakhiri dengan diskusi tentang prinsip-prinsip desain berorientasi objek yang baik.
5.1
MODEL DESAIN
Pada titik ini dalam kursus ini kita hampir selesai dengan analisis sistem kita.
Kita harus memiliki model domain yang lengkap dan sebagian besar kasus penggunaan
seharusnya sudah selesai. Dengan kata lain, kita harus mempunyai gambaran lengkap
tentang „apa yang akan dilakukan sistem‰. Sekarang, saatnya untuk memulai
perancangan sistem yang, seperti yang mungkin Anda ingat, memerlukan penjelasan dan
dokumentasi bagaimana sistem akan bekerja dan memastikan sistem berfungsi dengan
baik. Dalam hal ini, kita perlu menghasilkan desain yang baik berdasarkan artefak yang
kita identifikasi pada tahap analisis. Di akhir Topik 4, kami memperkenalkan diagram
ketahanan, sebuah alat penting yang akan membawa kita dari tahap analisis ke tahap
desain. Dalam topik ini, kita melihat proses ini secara lebih rinci. Pertama-tama, mari kita
lihat apa yang akan kita lakukan dan artefak yang akan dihasilkan dalam desain berorientasi objek.
Gambar 5.1 menggambarkan artefak dan hubungan antar artefak dalam model desain.
Seperti yang Anda lihat, diagram ketahanan bertindak sebagai antarmuka antara analisis
dan desain.
Gambar 5.1: Diagram desain utama
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
118 ÿ TOPIK 5 PEMODELAN DINAMIS
Dalam model desain, kami akan menghasilkan dua set diagram:
(a) Rancang diagram kelas yang mendefinisikan kelas-kelas dan hubungan di antara mereka. Ini
mewakili aspek statis dari model desain; Dan
(b) Diagram interaksi yang mendefinisikan interaksi kelas atau objek. Mereka mewakili aspek
dinamis dari model desain. Ada dua jenis diagram interaksi, yaitu diagram sequence dan
diagram kolaborasi.
Perhatikan bahwa pada Gambar 5.1, meskipun terdapat satu diagram kelas konseptual dan satu
diagram kelas desain, terdapat beberapa diagram ketahanan, urutan, dan kolaborasi. Kenapa ini?
Ingat kembali Topik 4 bahwa kita menggambar satu diagram ketahanan untuk satu kasus
penggunaan. Demikian pula, kita mengambil setiap diagram ketahanan dan kemudian menggambar
diagram urutan dan/atau diagram kolaborasi untuk masing-masing diagram.
Di lingkungan UP, kami selalu menekankan bahwa pengembangan persyaratan dan artefak desain
merupakan proses yang berulang. Pendekatan ini juga diterapkan dalam identifikasi kelas perangkat
lunak dalam model desain. Pengembangan dua rangkaian diagram dalam model desain juga
berlangsung dengan cara ini. Mereka akan didefinisikan secara paralel dan berulang. Oleh karena
itu, jangan khawatir jika Anda mempunyai "firasat" bahwa sesi pertama kelas perangkat lunak Anda
belum selesai. Saat Anda melakukan langkah lebih jauh dalam desain dan memperjelas detail
desain, kelas-kelas yang hilang ini akan terlihat.
Langkah-langkah berikut menguraikan bagaimana Anda akan mengidentifikasi bagian pertama dari
kelas perangkat lunak untuk model desain:
(a) Gunakan model persyaratan, kasus penggunaan, atau model domain dan temukan
kata benda. Kemungkinan besar ini adalah kelas;
(b) Gunakan teknik analisis ketahanan untuk mengidentifikasi kelas tambahan;
(c) Menyarankan tanggung jawab;
(d) Identifikasi atribut; Dan
(e) Identifikasi operasi.
Kami akan membahas detail tentang cara melanjutkan langkah-langkah ini di bagian selanjutnya.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 5 PEMODELAN DINAMIS ÿ 119
5.1.1 Kelas versus Objek
Mari kita revisi dulu konsep kunci objek dan pesan yang telah diperkenalkan di Topik 1. Hal ini
akan memberi kita gambaran yang lebih jelas tentang bagaimana kelas desain dapat
diekspresikan dalam model kelas desain. Mari kita lihat kembali perbedaan antara kelas dan
objek. Kelas adalah kumpulan objek dengan struktur, perilaku, hubungan, dan semantik yang
sama.
Tabel 5.1: Perbedaan Kelas dan Objek
Definisi
Contoh Dunia Nyata
Berapa banyak?
Kelas adalah definisi atau
Denah pembangunan rumah
Satu
spesifikasi atau templat.
Template unit belajar CBOP3103
Rumah
Objek adalah contoh fisik yang
dibuat sesuai dengan definisi
kelas.
dibangun sesuai denah bangunan. Sebanyak yang dibutuhkan
Sebanyak yang dibutuhkan
Topik pembelajaran diproduksi
dengan format sesuai template.
Dalam UML, sebuah kelas digambar sebagai persegi panjang dengan tiga kompartemen: satu
untuk nama kelas dan pengubahnya, satu untuk atribut dan satu lagi untuk operasi.
(a) Nama kelas adalah string tekstual yang digunakan untuk mengidentifikasi kelas (misalnya,
„Pelanggan‰). Setiap nama memiliki arti unik dalam konteksnya.
Kelas harus diberi nama menggunakan kosakata domain.
Standar penamaan harus dibuat (misalnya, semua kelas adalah kata benda tunggal
yang dimulai dengan huruf kapital).
(b) Struktur suatu kelas diwakili oleh atribut-atributnya.
Atribut mempunyai nama dan tipe yang dipisahkan dengan tanda titik dua „:‰.
Atribut dapat ditemukan dengan memeriksa definisi kelas, persyaratan masalah dan
dengan menerapkan pengetahuan domain. Kita telah mempelajari secara detail tentang
atribut di Topik 3.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
1 20 ÿ KE
OPIC 5 DINA
MODEL MIC
tidak
(C
c) Operasi
atribut
ons adalah b
perilaku
kelas fa atau objek yang ditindaklanjuti t
s di kelas atau objek. Op
operasi dapat memiliki input(), output() dan input
Saya
di
dalam
tahu ().
argumen ut/keluaran
Uments
Semua berdebat
memiliki nama dan
diawali dengan istilah d
keluar
tidak.
saya tidak
tipe d (sepa
diberi tanda titik dua) dan a
menggambarkan wh
jenis topi arg
gumam mereka
n direkomendasikan
memperbaiki kita
Catatan thtopi yang kita lakukantidak
e masukan/
adalah
adalah.
/keluaran (
di dalam
keluar)
tidak. argumen
Sedang dalam program
serudukan, ap
metode da.
n umum, itu
Di dalam
ada tiga t
prosedur th
di pelaksana
jenis operasi
bukan operasinya tion disebut
ransum yang co bisa ada di diagram kelas
saya
N
yaitu kontra
operasi truk
ransum, quer
n dan pembaruanoperasi tanggal pada.
operasi ry
C
digunakan
untuk
membuat
untuk kelas b dengan memberikan init
Operasi konstruktoroperasi awal adalah kamu
e objek baru
ay nilai untuk atribut. Th
dia nama th
dia membangun engan atau operasinya
sama saja
thdia nama th
n
digunakan
untuk
a
dia kelas. Ya
operasi apa pun
akses hanya th dia keberatan sta makan
dan opera ini
RetrieveID, ch
R
sebuah
asi tidak
heckPassword
keadaan ao
atau ubah
d, dll). Akhirnya
objek (misalnya getNama, dapatkanPa
ay,
ed untuk memperbarui atau
y, perbarui operasierasi adalah penggunaan
perbarui operasi ion akan chan nge
obyek. Ini
bab
nilai atribut
ute(s) dari o
gantung va
thdia menyatakan e objek (misalnya setName,
perbarui
s
tanggalUmur, dll).
kelas
Gambar 5.2 : Notasi
C
F gambar 5.3 sho itulah desainnya n notasi kelas
di kelas
ss Anggota masuk
dan video sh
contoh hop.
mantan
Gambar 5 .3: Notasi kelas ion untuk mem kelas anggota
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 5 PEMODELAN DINAMIS ÿ 121
Rincian lain dalam notasi kelas akan dibahas di bagian selanjutnya.
Untuk menentukan suatu objek, kita juga menggunakan persegi panjang, tetapi namanya
digarisbawahi. Pada gambar berikut, kotak pertama mewakili Anggota kelas. Kotak kedua
jill . Biasanya objek tidak diberi nama
untuk suatu objek. Dalam hal ini, objek yang
diberi nama hanyalah objek anonim. Kotak ketiga mewakili objek anonim dari Anggota kelas.
Gambar 5.4: Contoh kelas, objek, dan objek anonim
5.1.2 Objek dan Pesan
Objek berkomunikasi satu sama lain dengan mengirim dan menerima pesan.
Terkadang sebuah pesan berisi data, namun di lain waktu tidak.
Pertama-tama kita dapat memikirkan tentang bagaimana orang berkomunikasi. Berikut beberapa contohnya:
(a) Pembawa acara pesta makan malam mengumumkan, „Makan malam sudah siap.‰
(b) Seorang pekerja kantoran kembali ke mejanya setelah istirahat makan siang dan rekan
kerjanya berkata kepadanya, „Saat kamu keluar, saya menjawab teleponmu. Silakan
hubungi Jason Yip di 6343 3472.‰
(c) Dua orang bertemu di sebuah bar, dan di penghujung malam, salah satu orang berkata,
„Berapa nomor telepon Anda?‰ dan yang lainnya menjawab, „3472 3424.‰
(d) Seorang ibu memberikan sebuah catatan kepada anaknya, „Inilah sebuah catatan yang saya ingin kamu berikan kepada anakmu
guru.‰
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
122 ÿ TOPIK 5 PEMODELAN DINAMIS
Tabel 5.2 menunjukkan bagaimana masing-masing pesan dapat dinyatakan dalam UML.
Tabel 5.2: Contoh Pesan yang Dinyatakan dalam UML
Kata-kata
Gaya
Setara dengan UML
"Makan malam sudah siap.‰
Perintah tunggal
Makan malam sudah siap()
„Tolong hubungi Jason Yip di
6343 3472.‰
Pesan dengan data
RingPerson(„Jason Yip‰, „6343 3472‰)
"Berapa nomor telepon anda?‰
Pertanyaan dengan jawaban
DapatkanNomor Telepon():Nomor Telepon
yang diharapkan
„3472 3424.‰
„Ini catatan yang saya ingin kamu
Berikan objek pada suatu
berikan kepada gurumu.‰
objek.
GiveToTeacher (Alasan: Catatan)
Tabel di atas merangkum contoh yang baru saja diberikan, dan di kolom terakhir memberikan
contoh bagaimana pesan UML dapat ditulis.
Lihatlah baris kedua. Detail „Jason Yip‰ dan „6343 3472‰ di dalam tanda kurung disebut
parameter.
Sekarang lihat baris ketiga „:nomor telepon‰. Tanda titik dua memberi tahu kita bahwa suatu
jawaban diharapkan, dan kata PhoneNumber memberi tahu kita jawaban seperti apa yang
diharapkan.
Terakhir, baris keempat adalah contoh suatu objek, dalam hal ini catatan untuk guru, yang
disampaikan sebagai bagian dari pesan.
Notasi dasar untuk menunjukkan penyampaian pesan cukup mudah.
Namun, seperti kebanyakan UML, ada banyak kerumitan kecil yang hanya muncul sesekali. Kursus
ini berpegang pada dasar-dasarnya.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 5 PEMODELAN DINAMIS ÿ 123
5.2
DIAGRAM INTERAKSI
Ingatlah bahwa dua set artefak (diagram kelas dan diagram interaksi) akan dihasilkan
berdasarkan artefak dalam tahap analisis dan diagram ketahanan. Kedua rangkaian diagram
ini akan diproduksi secara paralel dan berulang. Kita akan melihat diagram interaksi terlebih
dahulu.
Diagram interaksi digunakan untuk mendefinisikan interaksi kelas atau objek dalam sistem.
Mereka menunjukkan aspek dinamis dari sistem, misalnya aliran pesan. Ada dua jenis diagram
interaksi: urutan dan kolaborasi. Kedua tipe tersebut digunakan untuk mendeskripsikan perilaku
objek untuk memenuhi satu kasus penggunaan.
Kedua jenis diagram interaksi ini masing-masing memiliki kekuatan dan kelemahannya masingmasing, sehingga penggunaannya sedikit berbeda. Diagram kolaborasi (beberapa buku teks
menggunakan istilah diagram komunikasi) sedikit lebih intuitif dan berguna untuk mempelajari
UML. Namun, penggunaannya dalam industri lebih sedikit. Diagram urutan lebih kompleks dan
menampilkan lebih banyak detail.
Diagram interaksi adalah cara untuk menunjukkan bagaimana satu use case akan direalisasikan
dalam bentuk objek perangkat lunak. Anda akan melihat bahwa, seperti halnya diagram
ketahanan, beberapa nama kelas sama atau sangat mirip dengan nama kelas konseptual. Hal
ini diharapkan. Namun, kali ini namanya merujuk pada representasi perangkat lunak dari
benda tersebut. Selain itu, Anda akan menemukan bahwa ada kelas lain yang hanya ada di
perangkat lunak dan tidak di kehidupan nyata.
5.2.1 Notasi Diagram Kolaborasi
Diagram kolaborasi menggambarkan interaksi antar elemen suatu sistem dan hubungannya
yang diatur dalam ruang dan waktu. Diagram ini berisi elemen-elemen berikut:
(a) Kelas, dinotasikan sebagai kelas persegi panjang, untuk mewakili objek yang terlibat dalam
interaksi;
(b) Peran asosiasi, yang mewakili peran yang mungkin dimainkan oleh tautan dalam interaksi;
Dan
(c) Pesan, dilambangkan dengan panah berlabel, untuk mewakili pesan yang dikirim antar
objek. Panah menunjuk dari objek pengirim pesan ke objek penerima. Secara opsional,
parameter diteruskan sebagai bagian dari pesan; dan juga secara opsional, beberapa
informasi, atau objek lain diteruskan kembali.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
124 ÿ TOPIK 5 PEMODELAN DINAMIS
Gambar 5.5: Contoh diagram kolaborasi
Kolaborasi adalah spesifikasi bagaimana pengklasifikasi, seperti kasus penggunaan atau
operasi, diwujudkan oleh sekumpulan kelas dan asosiasi yang memainkan peran tertentu
dan digunakan dengan cara tertentu. Kolaborasi mendefinisikan interaksi.
Diagram kolaborasi menunjukkan pesan yang dikirimkan objek satu sama lain. Sebuah
pesan direpresentasikan sebagai panah di dekat garis asosiasi antara dua objek.
Panah menunjuk ke objek penerima. Label di dekat panah menunjukkan isi pesannya.
Pesan tersebut memberitahu objek penerima untuk menjalankan salah satu operasinya.
Sepasang tanda kurung mengakhiri pesan. Di dalam tanda kurung terdapat parameter
(jika ada) tempat operasi dijalankan.
Tabel 5.3 merangkum rincian diagram kolaborasi.
Tabel 5.3: Detail Diagram Kolaborasi
Tautan
Jalur koneksi antara dua objek yang memungkinkan komunikasi di antara
keduanya.
Ini adalah link asosiasi pada diagram kelas. (Catatan: dalam Paradigma
Visual Anda perlu meletakkan tautan antar objek sebelum Anda dapat
mengirim pesan di sepanjang tautan tersebut.)
Pesan
Pesan sebenarnya dari satu objek ke objek lainnya. Perhatikan bahwa
mungkin ada beberapa pesan antara pasangan objek yang sama.
Pesan untuk 'diri sendiri'
Objek sering kali mengirimkan pesan kepada dirinya sendiri.
Pembuatan instance
Objek terus-menerus diciptakan. Misalnya, penjualan baru menghasilkan
catatan transaksi baru.
Urutan penomoran
pesan
Nomor urut diperlukan untuk menunjukkan urutan pengiriman pesan.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 5 PEMODELAN DINAMIS ÿ 125
Pesan bersyarat Jarang digunakan. Kirimkan pesan tertentu hanya jika syaratnya terpenuhi.
Jalur bersyarat yang
saling eksklusif
Sebuah metode penomoran yang memungkinkan dua urutan pesan
terpisah diikuti, bergantung pada hasil pengujian bersyarat.
Iterasi atau perulangan
Untuk menentukan bahwa pesan tertentu dikirim beberapa kali.
Iterasi atas koleksi
Sangat umum digunakan. Kirim pesan yang sama ke kumpulan objek,
seperti daftar.
Pesan ke objek kelas
Ini adalah sesuatu yang belum kami sebutkan secara eksplisit, dan
merupakan hal yang halus. Selain metode pada objek, terkadang ada
kebutuhan untuk menentukan metode yang beroperasi pada tingkat
kelas. Alasan utamanya adalah pesan „buat‰. Jika suatu objek belum
ada, lalu bagaimana cara membuatnya? Jawabannya adalah setiap
membuat.
kelas mempunyai metode kelas yang disebut Metode kelas
disebut juga metode statis.
Bab e-book berikut dari perpustakaan digital OUM (Books24ÿ7) berisi penjelasan
dan contoh lebih lanjut tentang diagram kolaborasi. Anda wajib membaca bab
ini.
Schmuller, Joseph. „Jam 10 Bekerja dengan Diagram Kolaborasi‰. Sams
Ajarkan Diri Anda UML dalam 24 Jam. Sam. © 1999.
Buku24ÿ7. <http://common.books24ÿ7.com/toc.aspx?bookid=414>
Selain notasi dalam bacaannya juga terdapat konsep multi benda. Ini juga
dikenal sebagai objek koleksi (seperti daftar). Jadi pesan yang ditampilkan
dikirim ke multi objek, sebenarnya adalah pesan yang dikirim ke kolektor objek
tersebut. Kolektor kemudian menemukan objek yang benar.
Gambar 5.6: Multi objek untuk diagram kolaborasi
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
126 ÿ TOPIK 5 PEMODELAN DINAMIS
KEGIATAN 5.1
Perhatikan diagram kolaborasi berikut. Ini menunjukkan kasus penggunaan a
peminum haus datang ke restoran dan meminta minuman dari a
Bot. Bayangkan Bot sebagai robot yang berinteraksi dengan bagian lain dari
restoran.
Tugas Anda adalah menerjemahkan diagram ini ke dalam dialog antar
berbagai komponen.
Gambar 5.7: Seorang peminum yang haus masuk ke sebuah restoran
5.2.2 Notasi Diagram Urutan
Diagram urutan menggambarkan interaksi antar elemen suatu sistem yang diatur dalam urutan
waktu. Diagram ini berisi elemen-elemen berikut:
(a) Peran kelas, dilambangkan dengan persegi panjang kelas, mewakili peran yang mungkin
dimainkan oleh objek dalam interaksi;
(b) Garis hidup, yang dilambangkan dengan garis putus-putus, melambangkan keberadaan suatu benda dalam
jangka waktu tertentu;
(c) Aktivasi, dilambangkan dengan persegi panjang tipis, menyatakan waktu selama suatu
objek sedang melakukan suatu operasi; Dan
(d) Pesan, dilambangkan dengan tanda panah horizontal di antara garis hidup,
mewakili komunikasi antar objek.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 5 PEMODELAN DINAMIS ÿ 127
Gambar 5.8: Notasi diagram barisan
Biasanya diagram urutan menunjukkan satu kasus penggunaan. Namun, untuk menunjukkan secara
memadai bagaimana kesalahan ditangani, sering kali diperlukan diagram tambahan.
Tabel 5.3 merangkum rincian diagram sequence.
Tabel 5.3: Detail Sequence Diagram
Tautan
Tidak ditampilkan
Pesan
Pesan adalah garis sederhana dari satu objek ke objek lainnya.
Fokus kotak kontrol dan
aktivasi
Ini sangat berguna ketika Anda baru mengenal diagram urutan. Hal ini
memungkinkan Anda dengan sangat mudah melihat objek mana yang aktif
atau menunggu untuk mendapatkan jawaban atas pesan yang telah mereka kirimkan.
Mengilustrasikan pengembalian
Sekali lagi, sangat berguna untuk pemula. Tampilkan secara eksplisit
kapan pesan dibalas.
Pesan untuk „diri sendiri‰
atau „ini‰
Garis sederhana dari suatu objek ke dirinya sendiri. Kotak aktivasi bersarang,
seperti yang ditunjukkan dalam teks, sebenarnya tidak diperlukan.
Pembuatan instance Sangat penting
Jalur hidup objek dan
penghancuran objek
Terkadang berguna
Pesan bersyarat
Adapun diagram kolaborasi
Pesan bersyarat yang
saling eksklusif
Iterasi untuk satu pesan
Adapun diagram kolaborasi
Iterasi untuk serangkaian
pesan
Iterasi pada
koleksi (multi objek)
Pesan ke objek kelas
Adapun diagram kolaborasi
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
128 ÿ TOPIK 5 PEMODELAN DINAMIS
Bab e-book berikut dari perpustakaan digital OUM (Books24x7) berisi lebih banyak penjelasan dan
contoh diagram sequence. Anda wajib membaca bab ini.
Schmuller, Joseph. „Jam 9 - Bekerja dengan Diagram Urutan‰. Sams Ajarkan Diri Anda UML dalam
24 Jam. Sam. © 1999. Buku24ÿ7. <http://common.books24ÿ7.com/
toc.aspx?bookid=414>
KEGIATAN 5.2
Ambil diagram kolaborasi pada Latihan 5.1 dan terjemahkan ke dalam a
diagram urutan.
5.2.3 Merancang Tanggung Jawab
Anda telah melihat seperti apa diagram interaksi (diagram kolaboratif atau diagram urutan). Sekarang
pertanyaannya adalah, bagaimana kita menemukan hal-hal tersebut?
Jelasnya, model desain harus didasarkan pada artefak yang kita miliki dalam analisis kebutuhan. Kami
memiliki serangkaian kasus penggunaan dan diagram ketahanan untuk semua, atau setidaknya kasus
penggunaan yang penting. Kami akan mulai membuat diagram interaksi berdasarkan artefak ini.
Saat kami mengerjakan kasus penggunaan atau diagram ketahanan, dan kami mencoba memutuskan
objek mana yang harus memenuhi fungsi tertentu, kata tersebut digunakan.
tanggung jawab
Booch, Jacobson dan Rumbaugh (1999) mendefinisikan tanggung jawab sebagai „kontrak atau
kewajiban dari suatu jenis atau kelas‰. Kelas bertanggung jawab untuk mengetahui sesuatu dan
melakukan sesuatu.
Dalam hal tindakannya, sebuah instance dari suatu kelas dapat melakukan sesuatu sendiri, dapat
menyebabkan kelas lain melakukan sesuatu dengan memulai suatu tindakan atau mengendalikan atau
mengoordinasikan tindakannya. Ini adalah jenis tanggung jawab 'melakukan' yang harus didefinisikan
dengan tepat untuk kelas-kelas dalam suatu sistem.
Tanggung jawab suatu kelas mungkin: mengetahui datanya sendiri, mengetahui objek terkait, atau
mengetahui hal-hal yang dapat diketahuinya.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 5 PEMODELAN DINAMIS ÿ 129
Desain adalah tentang menugaskan tanggung jawab ke kelas yang sesuai.
Sedang mengerjakan
tanggung jawab suatu objek antara lain:
(a) Melakukan sesuatu sendiri, seperti membuat suatu benda atau melakukan perhitungan;
(b) Memulai tindakan pada objek lain; Dan
(c) Mengendalikan dan mengkoordinasikan kegiatan pada objek lain.
Penuh arti
tanggung jawab suatu objek antara lain:
(a) Mengetahui tentang data pribadi yang dienkapsulasi (misalnya, kaca di
Latihan 5.1 mengetahui ukurannya);
(b) Mengetahui tentang objek yang berkaitan; Dan
(c) Mengetahui tentang hal-hal yang dapat diperoleh atau dihitung.
Contoh: Proses Penjualan
Sekarang kita siap untuk mulai bekerja membuat diagram kolaborasi untuk use case Proses Penjualan. Pada
Topik 4 kita menggambar diagram ketahanan untuk kasus penggunaan ini (lihat lagi Gambar 4.17). Ada
beberapa perbedaan penting antara diagram ketahanan dan diagram kolaborasi.
Perbedaan penting pertama antara diagram ketahanan dan diagram kolaborasi adalah bahwa diagram
ketahanan tidak berkaitan dengan urutan kejadian sebenarnya. Jadi, urutan pengiriman pesan akan sering
berubah antara diagram ketahanan dan diagram kolaborasi.
Perbedaan penting kedua antara diagram ketahanan dan kolaborasi adalah diagram ketahanan menunjukkan
banyak objek antarmuka pengguna. Namun, kami tidak ingin mempersulit diagram kolaborasi dengan
menampilkan semua ini. Memang sering kali mereka belum ditentukan, jadi kita tidak tahu apakah akan ada
kotak daftar, teks biasa, atau input yang diaktifkan suara. Objek antarmuka diagram ketahanan membantu kita
melihat dengan tepat informasi apa yang masuk dan keluar dari sistem. Diagram interaksi melangkah lebih
jauh dan menunjukkan bagaimana informasi diproses dalam sistem. Jadi, dengan kata lain, kita dapat
menerjemahkan semua objek antarmuka diagram ketahanan dengan satu objek yang kita sebut GUI
(„antarmuka pengguna grafis‰) yang umumnya menghubungkan perangkat antara pengguna manusia dan
perangkat lunak dalam sistem nyata).
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
130 ÿ TOPIK 5 PEMODELAN DINAMIS
Selanjutnya, kami ingin merangkum semua kecerdasan use case ke dalam satu objek yang
akan kami sebut Register. Alternatifnya, Anda dapat menyebutnya Pengontrol Kasus
Penggunaan Proses Penjualan. Pada proyek nyata, setelah beberapa use case diselesaikan,
pengontrol use case ini dapat diperiksa ulang dan mungkin digabungkan atau ditangani
dengan cara lain.
Di mana memulainya? Kita mulai dengan GUI yang memberitahukan Daftar bahwa ia siap
untuk membuat penjualan baru. Ini adalah operasi pembuatan sederhana di kelas Sale.
Selanjutnya GUI mengirimkan Daftarkan id atau barcode item dan jumlahnya. Kemudian,
kita perlu mencari tahu itemnya, sesuai dengan diagram ketahanan kita. Mari kita periksa
apakah ini benar. Jadi lihatlah model kelas konseptual pada halaman di bawah ini:
Sumber: Larman (2002)
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 5 PEMODELAN DINAMIS ÿ 131
Apa yang Anda perhatikan tentang itemId? Apakah atribut ini ada di kelas Item?
Tidak, ini bukan pada ProductSpecification. Namun, bagaimana kita mendapatkan
ProductSpecification? Dari model domainnya kita tahu itu dari ProductCatalogue. Kami mencoba
untuk mendapatkan kembali seluruh objek ProductSpecification, jadi perhatikan sintaks pesan 5
dari Gambar 5.9. Selanjutnya objek ProductCatalogue mengirimkan pesan ke objek koleksi
ProductSpecification, yang ditandai dengan notasi khusus. Objek koleksi ini menemukan
ProductSpecification yang benar dan mengirimkannya kembali.
Gambar 5.9: Diagram kolaborasi untuk proses penjualan
(Catatan: Pada titik ini kita berasumsi bahwa semua objek ini hanya diam menunggu kita berbicara
dengannya. Pada kenyataannya, tentu saja, objek-objek tersebut berada dalam database dan kita
harus melakukan beberapa upaya untuk mengeluarkannya. Memasukkan dan mengeluarkan data
dari database tidak tercakup dalam modul ini.)
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
132 ÿ TOPIK 5 PEMODELAN DINAMIS
Jadi sekarang kita memiliki objek ProductSpecification. Haruskah objek Register membuat
SalesLineItem? Tidak, karena itu adalah detail yang sebaiknya didelegasikan ke objek lain.
Jadi, seperti yang kita identifikasi dengan benar dalam diagram ketahanan, meskipun dalam urutan
yang berbeda, ProductSpecification diteruskan ke objek Sale, yang kemudian digunakan untuk
membuat SalesLineItem di pesan 7. Pesan 8 kemudian menambahkan SalesLineItem ke objek
koleksi SalesLineItem. Pesan 9 adalah GUI yang memberi tahu kita bahwa tidak ada item lagi, jadi
kita perlu menghitung totalnya. Sekali lagi Register mendelegasikan tugas ini ke objek Sale yang
kemudian, pada gilirannya, menanyakan total masing-masing SalesLineItem. Setiap SalesLineItem
menanyakan ProductSpecification-nya untuk harganya.
Terakhir, pembayaran dilakukan (anggap hanya uang tunai dan uang yang diberikan benar) dan
objek Pembayaran dibuat.
Jadi sekarang kita memiliki satu diagram kolaborasi untuk kasus penggunaan Proses Penjualan.
Tentu saja, kita juga dapat menampilkannya sebagai diagram urutan.
KEGIATAN 5.3
Gambarlah diagram urutan untuk Proses Penjualan, berdasarkan
pemahaman tentang diagram kolaborasi yang telah diberikan
Gambar 5.9.
KEGIATAN 5.4
Gambarkan diagram kolaborasi dan diagram urutan untuk use case
Pinjam Video dalam kasus Video Victoria.
5.3
DIAGRAM KELAS DESAIN
Kita telah melalui langkah-langkah pembuatan diagram interaksi (diagram kolaborasi atau diagram
urutan), yang menunjukkan tampilan dinamis model desain. Di dalam diagram interaksi ini, pada
dasarnya kami telah mengidentifikasi kelas perangkat lunak berdasarkan artefak dari tahap analisis
seperti kasus penggunaan dan diagram ketahanan. Namun, diagram interaksi menunjukkan
bagaimana kelas-kelas perangkat lunak ini berinteraksi dalam kaitannya dengan urutan pesan
yang diteruskan bolak-balik di antara kelas-kelas ini. Sejalan dengan diagram interaksi ini, kita juga
memiliki gambaran statis tentang hubungan antara kelas-kelas ini, yang menggambarkan detail
kelas-kelas tersebut dalam diagram kelas desain.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 5 PEMODELAN DINAMIS ÿ 133
Diagram kelas desain menggambarkan kelas-kelas yang akan ada dalam perangkat lunak. Saat kami
mengerjakan setiap kasus penggunaan dan menggambar diagram interaksi, kami mencari tahu apa
saja kelas-kelas ini. Ada berbagai cara untuk membuat diagram kelas desain. Salah satu caranya
adalah dengan mendasarkannya pada diagram interaksi yang kita miliki. Sebagai contoh, kita dapat
membuat diagram kelas desain penjualan video versi pertama hanya dengan:
(a) Menggambar kelas-kelas dari diagram interaksi;
(b) Jika suatu pesan diteruskan dari kelas A ke kelas B, maka buatlah garis di antaranya
mereka; Dan
(c) Menambahkan pesan yang diterima oleh suatu kelas sebagai salah satu operasinya.
Gambar 5.10: Upaya pertama pada diagram kelas desain
Perhatikan bagaimana dalam diagram ini, nama kelas tidak digarisbawahi, artinya ini adalah kelas,
bukan objek.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
134 ÿ TOPIK 5 PEMODELAN DINAMIS
Seperti yang telah Anda pelajari di bagian sebelumnya, ada lebih banyak detail kelas yang dibutuhkan
yang belum kami kerjakan. Sekarang kita akan membahasnya satu per satu.
5.3.1 Visibilitas
Visibilitas suatu atribut atau metode dalam suatu kelas menentukan objek lain yang dapat mengaksesnya.
Pilihannya adalah:
(A)
Visibilitas publik
dilambangkan dengan „+‰ dalam UML (atau dengan ikon di alat) artinya
bahwa objek dari kelas mana pun dapat menggunakan atribut atau operasi.
(B)
Visibilitas terlindungi
dilambangkan dengan „#‰: dalam UML (atau dengan ikon pada alat)
berarti hanya objek dari kelas tersebut atau subkelasnya yang dapat menggunakan atribut atau
operasi tersebut. Subkelas dibahas nanti dalam topik ini.
(C)
Visibilitas pribadi
dilambangkan dengan „‰ dalam UML (atau dengan ikon pada alat) berarti
hanya objek dari kelas tersebut yang dapat menggunakan atribut atau operasi tersebut.
Praktik desain yang diinginkan adalah menjaga atribut kelas Anda tetap pribadi, memberikan akses ke
atribut tersebut melalui metode „aksesor‰. Selain itu, hanya metode yang harus diakses oleh objek lain
yang boleh dipublikasikan atau dilindungi.
5.3.2 Spesifikasi Atribut Lengkap
Format spesifikasi atribut adalah:
[visibilitas] nama [:tipe] [= nilai awal]
(a) Setiap bagian bersifat opsional, kecuali nama;
(b) Visibilitas telah dibahas di atas;
(c) Tipe bisa berupa tipe dasar, seperti integer atau string, atau bisa juga kelas lain. Contoh klasiknya
adalah jenis „uang‰; Dan
(d) Nilai awal adalah nilai yang akan ditetapkan untuk setiap objek baru kelas ini.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
DINAMIS M PEMODELAN
TOPIK 5
5.3.3
ÿ 135
Asosiasi
asi
Seorang rekan
ciation adalah rekan
koneksi
hubungannya kelas
ted. Jika
antara di antara kelas dan ditampilkan n sebagai garis comenghubungkan
jika ada n
tidak ada panah yang menyala garis, diasumsikan t
dua arah akhir. Seorang asosiasiperwakilan inisiasi
ent yang satu m metode atau m etos Kla
menjadi
pantat B dapat
v
pantat
pergaulan
ion Cla pantat A ke Kelass B dan sebaliknyasebaliknya.
dua arah atau satu arah
nasional. Sebuah arr
kepala baris di t akhir th
garisnya
tentang hubungan itustatus
melaporkan ab
bisa b
digunakan untuk
r
-arah n5.11, tentang
mewakili
uni-n Gambar
kemampuan navigasi. Di dalam
kelas Gunakaneh tahu
kelas e Passwo pesanan, tapi bukan dia
th sebaliknya.
Di d
modus domain el, saat kita menggambar pantatnya pergaulan pada konsep tersebut diagram kelas
tidak khawatir d dengan bagaimanabenda
t
diakses
D. Itu sudah
m, kami n
yang sebenarnya
w
cukup t
di sini adalah a asosiasi. W
untuk mengatakan bahwa th
kita adalah rekan
kecerdasan yang bersangkutan
th
arah
Saat mendesain ng kelas d
bagaimana obobjek dapat berupa diakses.
Kam kami dapat sp
a
ecify kami,
n akses, sebagaiditunjukkan pada Gambar
gambar 5.11.
re 5.11: Sebuah asso
hubungan dengan navigasi
o
Gambar
Seperti halnya model domain, multiplisitas o
menunjukkan
Itu nomornya
terjadi
diagram,
asso
eh misalnya
dari sebuah asosiasi
asi
ces dari setiap kelas yang ca
asosiasi. Untuk emisalnya, vi
jumlah vid
atau apa pun
satu arahasi
antara
te di bagian
seorang partisipan
baris satu
ideo belanjakan akubisa membosankan
eos, yang ditunjukkan sebagai berikut.
Angkae 5.12: Perkalian kota asosiasi
n kelas
hubungan antara ckelas
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
1 36 ÿ KE
OPIC 5 DINA
MODEL MIC
F gambar 5.13 demenggambarkan final
versi al dari t
tidak
desain kelas
diagram pantat odari Proses
pada desain
n diagram kelasM
sa
Skasus penggunaan bir.
kedua
Gambar 5.13: Versi
A
5.3.4 Bersama
5
ompositio
n (“Kegunaana” Hubungankapal ion)
A
pada hubungan pinggul, juga tahudimiliki sebagai rekan gabungan agg gregasi, adalah sa
Sebuah komposisi
"Slebih kuat‰ untukm dari agregat asi dimana th
makan dan des dicoba dengan t
dia bagiannya adalah cre
w
keseluruhan.
Ini menunjukkan
menyatakan hal itukelas e belon ngs ke yang lain dia. Contoh komposit
hubungan ion: A Sebuah persegi panjang dibuat p dari beberapa poin. Jika th
ulang
hancur, jadi a
dia persegi panjang adalah d
adalah poinnya S.
A
Komposisi
n hubungan
lisebagai berikut S:
p ditunjukkan dalam UML dengan berlian terisi dan
Hak Cipta © Universitas Terbuka Malaysia (OUM)
ya
Machine Translated by Google
TOPIK 5
5.3.5
DINAMIS M PEMODELAN
ÿ 137
kegembiraanP)
Agregatgerbang (“HMemiliki” Re
t dari keseluruhan
e tapi
bagian mungkin mandiri
keseluruhannya
kembali
membutuhkan
parrt. Di tempat lainperintah, agregatserupa
Dalam sebuah aghubungan
hubungan, itu
gregasi
ke komposisi
aktif, tetapi
nship: cara
mengerikanpengelompokan
o
hal-hal.
t
Contoh contoh agregat hubungan gerbang
pesanan terdiri dari s
produk berlanjutkamu harus ada ev
bahkan jika
beberapa produk
bagus, tapi profesional
rignya lebih sedikit
yang
pesanannya dihancurkan. Sebuah
A
agregasi n hubungan
tidak terisi berlian dan garis sebagai berikut kita:
p ditunjukkan dalam UML dengan d yang
Gambar bdi bawah ini menunjukkan kelas desaindiagram ss w yang memiliki jugaasosiasi, com komposisi
asi antara
n kelas
dan aggr hubungan relasi hubungan. Itu e multiplisitas y dari sebuah asosiasi
juga s
w:
ditunjukkan pada gambar di bawah ini
Jadi
sumber:
Modifikasi
diedit dari www.apemodelan tangkas..com/style/cla
Perhatikan topi
th dengan keduanya
h jenis ag
berlian
d terletak o
agregatasi dan dan komposit
n sisi titik garis
tidak ke cl
"siapa".
ole‰ di sana kegembiraan. AAgregasi adalah khusus untuk
r
aktif berarti itu
lebih ketat dari norma asosiasi yang buruk
lubang n. Agregasi
hubunganmengirimkan. Lebih jauhlebih lanjut, pa seni biasanya tidak bisa ada
assDiagram.htm M
hubungan ion
pinggul,
gadis yang mana
mewakili
perusahaan asosiasition
yang
tidak ada apa-apa
bagian
tanpa
penyebab asi m banyak kebingunganpada. Sebagai Martin
n Fowler menulisini
Agrega
dalam edisiion,
ke-2
halaman 85:
dan utuh.
UML
D
sulingan
,
f terbesar
"Satu dari
saya
b
R ketakutan]di
bêtes noires [a A sesuatu, entahlah
rly tidak suka atau
Itu
Dia
ng jelaskan
agregat asi.
sy ke
regeasi adalah itu
w
A
Itu
mobil
punya
e
roda
sebagai
itu
kapal.
pa
mudah mengatakan itu
satu dengan jelas: mesin Aggre dan
e
G
sepertinya
bagus,itu
tapi
adalah pertimbangan
deringapa
hubungan modellin terdengar
agregat
bedanya ng
bagian dari seni. Ini antara
tion dan asosiasi
hubungan tipis yang sulit.‰
Anda akanaku mungkin n perhatikan itu th e kelas desain diagram ss adalah
ar ke
sangat mirip
model
apa
pun.
H
Namun,
konsep diagram kelas ualgram itu w
kami produksi di doma
ada
dan ada yang berbeda
ences. orang-orang itutabel berikut merangkum t
kesimpulan.
perbedaan utama ini
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
138 ÿ TOPIK 5 PEMODELAN DINAMIS
Tabel 5.3: Perbedaan Utama antara Diagram Kelas Konseptual dan Desain
Konsep
Konseptual
Kelas
Desain
Ya mewakili entitas
dunia nyata
Hubungan
Ya mewakili kelas perangkat lunak.
Beberapa di antaranya akan memetakan 1:1 ke
kelas dunia nyata.
"Mempunyai sebuah‰
Tambahkan arah ke hubungan „has-a‰ Kirimkan
Navigasi tidak relevan
pesan ke kelas.
hubungan "Is-a".
Mewarisi kode
Kardinalitas
Ya
Ya
Atribut
Tampilkan yang utama, tipe
Tambahkan lebih banyak atribut. Tambahkan jenis.
Warisan
(dibahas nanti)
bersifat opsional
Metode
Biasanya sangat sedikit
Tambahkan lebih banyak lagi, dengan parameter lengkap.
KEGIATAN 5.5
Gambarlah diagram kelas desain untuk kasus penggunaan Pinjam Video di
Video Victoria.
5.4
WARISAN
Warisan adalah aspek penting dari orientasi objek dan kita telah membahas konsep
ini secara singkat di Topik 1. Warisan adalah hubungan antar objek. Hal ini dikenal
sebagai hubungan 'is-a'. Hal ini berbeda dengan hubungan asosiasi, yaitu hubungan
“memiliki”. Hubungan pewarisan dapat ditunjukkan pada diagram kelas konseptual
dan diagram kelas desain.
Mari kita lihat sebuah contoh. Bayangkan Anda sedang menulis sistem untuk
menangani registrasi kendaraan untuk Departemen Transportasi. Sistem ini harus
menangani berbagai jenis kendaraan, baik mobil, sepeda motor, dan bus. Semua ini
mempunyai beberapa kesamaan dan beberapa hal yang berbeda. Jika kita
menggambar kelas-kelasnya, kita mungkin memiliki yang berikut ini (lihat Gambar 5.14):
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
DINAMIS M PEMODELAN
TOPIK 5
tiga kelas wi
Gambar 5.14 : Th
ÿ 139
dengan persamaan
Jadi apa yang Anda perhatikance? Mereka semua hmemiliki atributnya
lisensi butePl
inspeksi.
permintaanMasuk
dipanggilVe
Kendaraan
dan kr ,
makan dan o operasi
jika ini keluar masuk
bukan su baru kelas atas
bstraksi dari
Jadi o kita membuat ab
makan tiga sub bclasses (permohonan
as lihat Gambar gambar 5.15).
Gambar 5.15:: Warisanc
Perhatikan itu
di panah
w digambar p
hierarki ini
dariM
subkelas
ss ke sup
dan panah ini berlawanan dengan intuisiitif). arr
baris bisa d
(Awalnyakamu mungkin baik-baik saja
dalam berbagai
w
choi
cara, seperti yang ditunjukkan
wn pada gambar 5.16
5
es adalah milikmu.
menunjuk
perkelas.
ditarik
Gambar 5.16: Dua gaya panah berbeda untuk atau ahli waris setelah hierarki
Jadi kita ha
ave gen
adalah ayMobil, Bus
kendaraan
konsep ral
fa kendaraan dand spesialisasinya
situasi. Kami sa ay itu
e.
S adalah kendaraan dan
a Sepeda Motor
ke kendaraan
adalah
erclass memegang
itu atributnya
es dan metode peluang yang semuanya umum untuk a
Sup
subkelas yaitu. Masing-masing dia
th subkelas kemudian dapat memilih secara nasional memiliki
e tambahan a atribut dan
operasi
jatah.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
140 ÿ TOPIK 5 PEMODELAN DINAMIS
Seperti yang ditulis Larman (2002), mengidentifikasi superkelas dan subkelas mempunyai nilai dalam model kelas
konseptual karena kehadirannya memungkinkan kita untuk memahami konsep dalam istilah yang lebih umum, halus,
dan abstrak. Hal ini mengarah pada penghematan ekspresi, peningkatan pemahaman dan pengurangan informasi
berulang. Selanjutnya, ketika menentukan kelas desain, pewarisan adalah alat yang ampuh untuk menyederhanakan
desain dengan mengekspresikan kesamaan secara ringkas.
Ketika sebuah subkelas mewarisi dari superkelas, ia mewarisi apa yang dimiliki superkelas
tersebut. Subkelas
semuanya
mewarisi semua atribut, operasi, dan hubungan superkelas. Berikut ini contohnya:
Pelajari diagram berikut (lihat Gambar 5.17).
Gambar 5.17: Warisan artinya mewariskan segala sesuatu
Bisakah kita mengatakan
Bus juga diwariskan.
mempunyai sebuah
Pemilik? Jawabannya adalah ya, karena semua hubungan memang demikian
Bisakah seorang pemilik memiliki dua Mobil dan sebuah Bus? Ya.
Apakah setiap Bus mempunyai pemilik? Ya.
Bisakah objek mengubah kelas? Ini adalah pertanyaan penting dan ilustrasi yang sangat bagus tentang perbedaan
antara diagram kelas konseptual dan desain. Mari kita bertanya, apakah bus bisa menjadi sepeda motor? Jelas di
dunia nyata hal ini tidak masuk akal. Namun, pada contoh lain, hal ini tidak begitu jelas.
Gambar 5.18: Penggunaan pewarisan yang baik untuk diagram kelas konseptual
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 5 PEMODELAN DINAMIS ÿ 141
Katakanlah di Video Victoria kita menggambar kelas konseptual dengan superkelas Peminjam,
dan dua subkelas Anak dan Dewasa (lihat Gambar 5.18). Ada aturan berbeda yang berlaku
untuk masing-masingnya, jadi ini masuk akal. Namun, ketika kita bertanya „Apakah seorang
anak menjadi dewasa?‰ Tentu saja jawabannya adalah ya. Jika ini adalah diagram kelas
desain, kita akan mendapat masalah, seperti. Ya, kita selalu bisa
benda tidak bisa berubah
kelas menulis beberapa kode untuk menghapus objek Anak, dan membuat objek Dewasa, tapi
itu adalah pendekatan yang sangat berantakan. Untuk desain diagram kelas, jauh lebih baik
tidak menggunakan pewarisan, namun menggunakan asosiasi biasa (lihat Gambar 5.19).
Gambar 5.19: Penggunaan pewarisan yang baik untuk diagram kelas desain
KEGIATAN 5.6
Pada sistem NextGen POS, pembayaran dapat dilakukan secara tunai, kredit
kartu atau cek. Untuk pembayaran kartu kredit lebih dari $200, sistem harus
mencatat nomor otorisasi. Untuk menerima cek beberapa bentuk
identifikasi (seperti SIM atau paspor) harus dicatat.
Perbarui diagram kelas pada Gambar 5.13 untuk mencerminkan persyaratan ini.
KEGIATAN 5.7
Di Video VictoriaÊs ada berbagai kategori video, yaitu
romansa, umum, fiksi ilmiah, bahasa asing, dan anak-anak. Tunjukkan bagaimana ini
informasi dapat tercermin pada kelas konseptual dan desain
diagram.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
142 ÿ TOPIK 5 PEMODELAN DINAMIS
5.4.1 Polimorfisme
Polimorfisme sangat terkait dengan pewarisan. Perhatikan contoh berikut (lihat Gambar 5.20):
Gambar 5.20: Pohon pewarisan dokumen
Pohon pewarisan sejumlah tipe dokumen ditunjukkan pada Gambar 6.3.
Perhatikan bahwa setiap tipe dokumen di pohon memiliki metode pencetakan. Jadi ketika
objek pemilik ingin mencetak dokumen, ia cukup mengirimkan pesan „print‰ ke dokumen
tersebut. Poin pentingnya adalah objek pemilik tidak perlu mengetahui jenis dokumennya
sebelum dapat mengeluarkan perintah print. Konsep ini dikenal sebagai polimorfisme yang
mempunyai banyak bentuk. Perhatikan bahwa polimorfisme menyiratkan bahwa objek
mengubah kelas. Artinyabukan
kode pasti dari metode tersebut akan berubah sesuai dengan kelas
objek yang menerima pesan.
5.4.2 Kelas Konkrit dan Abstrak
Ketika membahas pewarisan, kita tidak bisa menghindari pembahasan kelas abstrak dan
konkret. Kelas abstrak adalah kelas yang tidak pernah memiliki objek apa pun. Pertimbangkan
ini: apakah masuk akal untuk memiliki objek Buah? Jelas tidak, karena kelas Fruit adalah
abstraksi dari sebuah buah, dan bukan buah itu sendiri. Dalam hal ini, Fruit adalah kelas
abstrak dan kita tidak dapat membuat objek untuk kelas ini.
Kelas konkrit adalah kelas yang mempunyai objek. Sampai pada topik ini, semua kelas yang
kita bahas adalah kelas konkrit.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 5 PEMODELAN DINAMIS ÿ 143
Kembali ke kelas abstrak, jika kita tidak dapat membuat objek dari kelas abstrak, lalu mengapa kita
memiliki kelas abstrak dalam diagram kelas? Sebenarnya, setiap kelas abstrak mewakili beberapa ide,
meskipun tidak akan sepenuhnya lengkap karena beberapa detail dan definisi akan diserahkan kepada
kelas konkret yang mewarisi kelas abstrak. Nama kelas abstrak harus mencerminkan bahwa itu adalah
sebuah konsep dan bukan sesuatu yang spesifik. Jadi „Rekening‰ versus „Rekening Giro‰, atau
„Kendaraan‰ versus „Truk‰.
Dua hal yang perlu diperhatikan:
(a) Kelas konkrit harus selalu berupa daun; Dan
(b) Kelas abstrak tidak boleh mewarisi kelas konkrit, karena tidak masuk akal untuk beralih dari umum ke
khusus dan kembali ke umum seperti yang ditunjukkan pada Gambar 5.21:
Gambar 5.21: Kelas Abstrak dan Konkrit diperbolehkan dan tidak diperbolehkan
Ada dua cara untuk menentukan kelas abstrak dan konkret di UML. Salah satu caranya adalah dengan
mengetikkan nama kelas dalam huruf miring; cara lainnya adalah dengan meletakkan kata abstrak dalam
tanda kurung kurawal seperti terlihat pada gambar di bawah ini.
Gambar 5.22: Notasi untuk kelas abstrak
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
144 ÿ TOPIK 5 PEMODELAN DINAMIS
5.5
PRINSIP DESAIN
Sampai di sini kita telah membahas bagaimana mengubah model analisis kita menjadi model
desain. Berdasarkan kasus penggunaan, diagram kelas konseptual, dan diagram ketahanan, kami
menghasilkan tampilan dinamis dan tampilan statis dari model desain. Untuk tampilan dinamis,
representasi UML adalah diagram urutan atau diagram kolaborasi. Untuk tampilan statis model
desain, representasi UML adalah diagram kelas desain. Agar model desain berfungsi lebih baik,
ada beberapa prinsip kelas desain yang perlu kita ikuti.
Bagian ini membahas beberapa prinsip yang harus diwujudkan oleh desain berorientasi objek yang
baik, yaitu kohesi dan penggandengan. Bagian ini membahas tentang bagaimana Anda dapat
mengevaluasi sebuah desain. Dalam pekerjaan Anda sampai saat ini, terkadang Anda mungkin
telah melihat bahwa ada pilihan dalam cara Anda mendekati sesuatu. Misalnya, apakah Anda
harus membagi kelas menjadi dua kelas terpisah, atau kelas mana yang harus mengimplementasikan
metode tertentu? Pada bagian ini, kami memberikan beberapa terminologi bagi Anda untuk
mendiskusikan suatu desain dari segi berbagai kelebihan dan kekurangannya. Seperti halnya
semua upaya desain baik itu desain interior, pakaian, perencanaan kota, dan sebagainya, trade-off perlu dilakukan.
Seperti yang Anda lihat di topik sebelumnya, kelas desain awalnya berasal langsung dari model
konseptual, dan kemudian ditambahkan, diubah, atau digabungkan seiring berkembangnya solusi.
Seiring berkembangnya desain, desain harus terus dievaluasi berdasarkan prinsip desain
berorientasi objek berikut.
5.5.1 Kopling
Kopling berasal dari metode terstruktur Edward Yourdon, seorang pengembang model desain
berorientasi objek. Kopling mewakili kekuatan hubungan antara dua kelas. Dua kelas digabungkan
jika salah satu dari mereka menggunakan, mengacu pada yang lain, atau dalam beberapa hal
memiliki pengetahuan tentang yang lain.
Melihat kembali Gambar 5.12, kita dapat mengatakan bahwa Peminjaman dan Video digabungkan,
sedangkan Anggota dan Video tidak. Untuk mengonfirmasi hal ini, kita dapat membaca kode
metode kelas Anggota dan Video untuk mengonfirmasi bahwa tidak ada yang mengirimkan pesan
apa pun ke yang lain.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 5 PEMODELAN DINAMIS ÿ 145
Jika suatu kelas berubah, maka semua kelas yang digabungkan (mungkin) akan berubah. Penggabungan
yang begitu kuat akan memperumit suatu sistem sehingga lebih sulit untuk mengubah dan memahami
satu kelas jika kelas tersebut sangat terkait dengan kelas lainnya. Lebih jauh lagi, kelas-kelas yang
digabungkan secara ketat sulit untuk digunakan kembali dalam sistem yang lebih baru. Kopling longgar
berupaya membuat sistem lebih mudah dipahami, dipelihara, dan diubah. Anda dapat mengklasifikasikan
kopling ke dalam berbagai jenis, empat bentuk paling dasar (lihat Richter (1999), hal. 133)
(a) Penggabungan identitas;
(b) Penggabungan representasional;
(c) Kopling subkelas; Dan
(d) Kopling warisan.
Kopling identitas mengukur tingkat konektivitas suatu desain. Ini ditampilkan sebagai asosiasi pada
diagram kelas. Secara efektif suatu objek „tahu‰ tentang objek lain. Asosiasi satu arah kurang
berpasangan dibandingkan asosiasi dua arah.
Kopling representasional adalah ukuran bagaimana satu objek mengakses data objek lain.
Mengakses metode publik foo di kelas X, seperti pada Gambar 5.23, merupakan pendekatan tingkat
rendah sehingga memiliki tingkat penggabungan representasional yang tinggi.
Gambar 5.23: Metode getFoo adalah contoh 'pengambil' yang mendapatkan nilai atribut
Di sisi lain, menggunakan metode getFoo, yang hanya akan memberi kita nilai atribut foo, adalah
penggandengan representasional tingkat rendah. Versi terakhir lebih disukai karena rincian implantasi
tingkat rendah kelas X disembunyikan.
Ini adalah enkapsulasi.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
146 ÿ TOPIK 5 PEMODELAN DINAMIS
Penggabungan subkelas terjadi ketika kelas klien secara langsung mereferensikan subkelas,
bukan superkelasnya. Hal ini harus dihindari sedapat mungkin (lihat Gambar 5.24).
Gambar 5.24: Pendekatan penggandengan subkelas yang lebih disukai dan kurang disukai
Kopling pewarisan: suatu subkelas dihubungkan dengan superkelasnya melalui penggabungan
warisan. Ingatlah bahwa subkelas mewarisi segala sesuatu dari superkelasnya dan hal ini tidak
dapat diubah pada saat run-time. Pada bagian 5.4, kami memperingatkan terhadap kemungkinan
penggunaan warisan yang berlebihan dan merekomendasikan agar asosiasi dipertimbangkan.
Lihat Gambar 5.19 sebagai contoh.
5.5.2 Kohesi
Kohesi juga berasal dari metode terstruktur Edward Yourdon dan merupakan ukuran seberapa
fokus fungsionalitas suatu kelas. Suatu kelas memiliki kohesi yang tinggi jika hanya mewakili satu
ide.
Kelas VideoSpecification mendefinisikan judul film tertentu. Ini memberi tahu kita sesuatu tentang
film itu (namanya, aktornya, tahun pembuatannya, ratingnya, dan sebagainya). Kelas Video adalah
tentang satu rekaman tertentu dari spesifikasi video.
Jadi Video dan VideoSpecification adalah kelas yang terpisah. Jika digabung menjadi satu maka
kelas yang dihasilkan tidak akan memiliki kohesi yang tinggi.
Jika perilaku suatu kelas bersifat multi-fungsi, atau hanya sebagian dari suatu fungsi, maka ia
memiliki kohesi yang rendah dan hal ini tidak diinginkan. Kelas yang sangat kohesif lebih mudah
untuk dipahami tidak hanya dalam dirinya sendiri tetapi juga dalam hubungannya dengan kelaskelas lain. Jika Anda tahu persis apa yang akan dilakukan suatu kelas (fungsi tunggalnya), maka
Anda memahami dengan tepat bagaimana kelas lain akan menggunakannya. Faktanya, ini
memfasilitasi desain kelas baru yang akan menggunakan kelas yang kohesif secara fungsional.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 5 PEMODELAN DINAMIS ÿ 147
AKTIVITAS 5.8
Manakah dari dua kutipan diagram kelas berikut yang menunjukkan baik
kohesi?
2. Manakah dari dua diagram berikut yang menunjukkan kopling yang lebih baik?
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
148 ÿ TOPIK 5 PEMODELAN DINAMIS
3. Diagram manakah di bawah ini yang menunjukkan penggandengan yang lebih baik?
• Dalam topik ini, kita memasuki tahap desain sistem. Dengan selesainya semua (atau sebagian
besar) artefak dan dokumen dalam tahap analisis, kita mulai melihat bagaimana sistem
dapat dibangun dan bagaimana kelas dan objek perangkat lunak dapat bekerja sama untuk
mencapai tugas yang kita identifikasi dalam analisis.
• Model desain terdiri dari dua jenis artefak, yaitu diagram interaksi dan diagram kelas desain.
Diagram interaksi akan memberi kita tampilan dinamis sistem yang menunjukkan urutan
pertukaran pesan antar kelas. Diagram kelas desain akan menggambarkan hubungan antar
kelas dan memberikan lebih banyak rincian tentang struktur kelas dan operasi yang dapat
dilakukannya.
• Kita juga telah mempelajari properti yang sangat penting dari desain berorientasi objek
pewarisan kelas selain polimorfisme, kelas abstrak dan konkret.
• Pada saat yang sama, prinsip-prinsip desain berorientasi objek yang baik telah diterapkan
diperkenalkan.
• Dalam kursus ini, kita telah mempelajari pendekatan berorientasi objek dalam perangkat lunak
perkembangan.
• Kami juga fokus pada Proses Terpadu dan UML.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
TOPIK 5
DINAMIS MPEMODELAN
Kelas mmetode
Int diagram interaksigram
Kohesio
Paarameter
pada
Kolaborasi
diagram orasi
ÿ 149
Poolimorfisme
pagi
kopling ng
Urutan
diagram
Enkapsu ulasi
Stametode atik
urutan
d desain denganjam aplikasi
Booch, G G.(1991).
Keberatan
berorientasi objek
Bententu saja Cummmings.
pagi
, , kayu
merah cKota, California:
Booch, G G., Rumbaugh h, J., & Jacobs anak, J. (1999). . Yang bersatud pemodelan la bahasa.
Reatambahan, MA: Addison-We
referensi untukatau UML,
esley. (Ini adalah penjelasan
proyang bagus
e detail dari y kamu akan pernahperlu.)
n
Fowler, M M., & Scott, K K.(2000). UM ML Sulingan (
Kami
esley. (Ini saya sa pendek dan d praktis o
(edisi ke-2). Rea tambahan, MA :AddisonA
ikhtisar aktual untuk
Anda
menggunakan
UMLdalam
i
pratindakan.)
Larman, C.(2002).
Hasemua.
L dan pola
Aplikasi
S. Sadd Atas
F
Richter, C. (1999).
menerapkan Perancangan UML
objek fleksibel berorientasi dll
IndDianapolis, IN N: Pub Teknis Macmillan
berkilauan.
UM
Scott, K K. (2001).
ML menjelaskan D . Boston, M
sics dari UML.)
pramenunjukkan bas
Dangkal ay, A., & Trot
dan aktif
berorientasi
tt, JR (2002)
objek
desain ted
MA: Addison
. Pola desain jelaskan
. Booston, MA: Iklan ddison Wesle
sungai kecil, NJ:
Pembantu tukang
S
sistem
dengan UML ke-.
n-Wesley. (Th
edisi: Per
bukunya
prospektif baru
mata.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
150 ÿ JAWABAN
Studi kasus
Sekarang kita telah sampai pada bagian akhir buku ini. Untuk memastikan bahwa
Anda telah memahami semua konsep penting dan diagram UML yang dibahas
dalam buku ini, mari kita bahas studi kasus. Studi kasus diambil dari bab e-book
yang tersedia di perpustakaan digital OUM (Buku24ÿ7) seperti yang ditunjukkan
pada tabel di bawah. Dalam menjalani studi kasus ini, ikuti urutan tugas yang
ditunjukkan pada tabel di bawah.
Tugas
Pengantar studi
kasus
Referensi
Schmuller, Joseph. „Jam 16 Memperkenalkan Studi Kasus‰. Sams Ajarkan
Diri Anda UML dalam 24 Jam. Sam. © 1999. Buku24ÿ7. <http://
common.books24ÿ7.com/toc.aspx?bookid=414>
Melakukan
analisis domain
Schmuller, Joseph. „Jam 17 Melakukan Analisis Domain‰.
Sams Ajarkan Diri Anda UML dalam 24 Jam. Sam. © 1999. Buku24ÿ7.
<http://common.books24ÿ7.com/toc.aspx?bookid=414>
Mengembangkan penggunaan
kasus
Schmuller, Joseph. „Jam 19 Mengembangkan Kasus Penggunaan‰. Sams
Ajarkan Diri Anda UML dalam 24 Jam. Sam. © 1999. Buku24ÿ7.
<http://common.books24ÿ7.com/toc.aspx?bookid=414>
Mengembangkan
diagram
interaksi
Schmuller, Joseph. „Jam 20 Melakukan Interaksi dan Perubahan Keadaan‰.
Sams Ajarkan Diri Anda UML dalam 24 Jam. Sam. © 1999.
Buku24ÿ7. <http://common.books24ÿ7.com
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
JAWABAN
ÿ 151
Jawab
swer S
TEMAC 1: INT
RODUKTI KE O
RIENTED
OBYEK-ATAU
PERANGKATPERKEMBANGAN
D
MENDAPATKAN
LEMBUT
Kegiatan 1.1
Contoh
es TI untuk su
laporan:
ponseltelepon ile (
WAP ikasi), pergi
sudah mengaturku
sistem masuk.
PDAA (Pribadi Da
di Asisten)
Contoh
untuk telepon c
esai, telepon
semuanya, kirim pesan padaku
tidak ada buku dand aplikasi
) seperti Palm P Pilot.
es untuk IT sebagai
kegunaan‰:
n „mengaktifkan bu
Data
Aplikasi Penambangan ikatan
Sistem ert, e
pengalaman
tc.
Kegiatan 1.2
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
152 ÿ JAWABAN
(a) pesan
(b) kelas
(c) contoh
Kegiatan 1.3
(a) Ada beberapa kemungkinan jawaban, antara lain:
• Mitigasi risiko dengan mengerjakan aspek-aspek paling berisiko dari suatu proyek, kita
dapat mengatasi masalah apa pun atau menghentikan proyek lebih awal daripada
menunggu hingga proyek selesai.
• Memberikan hasil awal dan nyata kepada pengguna, sehingga semakin besar
kerja sama.
• Menanamkan kebiasaan mengantarkan artefak secara rutin. Artinya, proyek ini
tetap menjaga momentumnya dan tidak terperosok dalam detail-detail rumit atau
fitur-fitur yang tidak mutlak diperlukan.
(b) Berikut tiga tantangannya:
• Proyek yang berulang akan lebih sulit diprediksi, dikendalikan, dan dikelola.
• Kontrol versi sangat mendasar pada setiap dokumen dan bagian
kode dapat diubah beberapa kali.
• Setelah suatu sistem diimplementasikan, Anda berdua harus mendukung sistem yang ada
sistem serta melanjutkan pengembangan.
Kegiatan 1.4
Tradisional
Pendekatan data dan fungsi Pertimbangkan secara terpisah
Berorientasi pada objek
Pertimbangkan bersama
Siklus hidup pengembangan sistem
(SDLC)
Air terjun
Iteratif
Notasi
Diagram hubungan entitas
(ER).
diagram UML
Diagram Aliran Data (DFD)
Contoh bahasa
COBOL, berbagai 4GL
Basis data
Basis data relasional
Jawa, C++
Biasanya masih pakai
database relasional
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
JAWABAN ÿ 153
Kegiatan 1.5
• Seorang Siswa Mendaftar untuk Kursus OUM
Siswa menerima paket pendaftaran dari Register melalui surat. Ia mencari daftar mata
kuliah yang tersedia di Prospektus atau Suplemen Mata Kuliah. Ia memutuskan mata
kuliah mana yang ingin ia ikuti pada semester mendatang. Dia mengisi formulir pendaftaran
dan mengirimkannya kembali ke Registry. Dia menerima slip pembayaran dari Registry.
Dia pergi ke bank yang ditunjuk untuk membayar biaya sekolah untuk kursus yang dia
daftarkan. Ia menerima instruksi dari Panitera untuk mengumpulkan materi kursus dan
jadwal belajar kursus.
• Pelanggan Membeli Barang dari Toko Online Pelanggan
menyalakan PC-nya dan terhubung ke Internet. Pelanggan membuka browser Internet
dan memasukkan URL toko online. Pelanggan mencari katalog online untuk barang yang
ingin dia beli. Pelanggan mengklik ikon pembelian item tersebut. Item ditambahkan ke
keranjang belanja online. Pelanggan mengklik keranjang belanja online dan memeriksa
apakah item telah ditambahkan. Pelanggan mengklik ikon checkout. Pada halaman
pembayaran, pelanggan memasukkan informasi pembeliannya (nomor kartu kredit,
tanggal kedaluwarsa, email, alamat) dan mengklik ikon konfirmasi.
TOPIK 2: PERSYARATAN DAN KASUS PENGGUNAAN
Kegiatan 2.1
(a) fungsional
(b) tidak berfungsi
(c) fungsional
(d) tidak berfungsi
(e) dapat dianggap sebagai keduanya
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
154 ÿ JAWABAN
Kegiatan 2.2
Persyaratan fungsional:
• mendaftarkan anggota;
• melacak video yang sudah lewat waktunya;
• menghasilkan file unggahan harian untuk buku besar; Dan
• mencetak surat untuk anggota pada hari ulang tahunnya
Persyaratan non-fungsional:
• kecepatan sistem harus memungkinkan transaksi peminjaman video diselesaikan dalam waktu
satu menit;
• pembaca kode batang harus memiliki keakuratan minimal 99,5 persen; Dan
• petugas meja depan harus dapat memahami semua fungsi
sistem dalam waktu satu minggu.
Kegiatan 2.3
Objektif
Staf
Keandalan
1
4
Efisiensi
2
3
Kepuasan
4
1
Kecepatan
3
2
Remaja
Kegiatan 2.4
Pelanggan (atau anggota)
primer atau sekunder, tergantung pada apakah
pelanggan berinteraksi langsung dengan sistem. Menyarankan
kepada klien, Victoria, bahwa untuk versi pertama
sistem, anggotanya adalah orang sekunder dan meja depan
petugas berinteraksi dengan sistem. Versi yang lebih baru bisa
memungkinkan pelanggan untuk meminjam video mereka sendiri.
Petugas meja depan
utama Aktor ini berurusan dengan anggota yang bergabung,
meminjam video, mengajukan pertanyaan.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
JAWABAN ÿ 155
Petugas kantor belakang
primer Aktor ini menangani semua fungsi back office, seperti
pengiriman data ke sistem buku besar. (Mungkin nanti akan
diketahui bahwa 'aktor' ini sebenarnya adalah beberapa aktor.)
Pengambil saham
primer atau sekunder, tergantung pada implementasinya.
Membutuhkan lebih banyak informasi tentang apa saja yang diperlukan dalam
pengambilan stok.
Pengelolaan
sekunder, karena kebutuhan pelaporan mereka dipenuhi dari
gudang data. Butuh informasi yang cukup untuk menjalankan
bisnis.
Manajer keamanan
primer mempertahankan nama pengguna untuk mengontrol
akses ke sistem.
Gudang data
eksternal membutuhkan pembaruan data harian.
Terminal mesin kasir
eksternal menangani semua transaksi keuangan.
Selain itu, setiap pengguna utama harus dapat masuk, keluar, dan mengubah kata sandinya.
Aktivitas 2.5
Meminjam format video singkat untuk versi awal kasus penggunaan
Kasus penggunaan ini dimulai ketika anggota selesai memilih videonya dan membawanya ke meja
depan. Petugas meja depan meminta untuk melihat kartu anggota mereka.
Petugas kemudian memasukkan nomor anggota ke dalam sistem. Petugas front desk kemudian
memindai barcode video anggota. Sistem menghitung harga berdasarkan apakah video tersebut rilis
baru, rilis saat ini, atau lainnya, dan harga ditampilkan di terminal kasir. Pelanggan membayar dengan
kartu kredit atau uang tunai, lalu meninggalkan toko dengan videonya.
Aktor yang paling penting adalah petugas front desk karena aktor ini melayani para member. Lagi
pula, jika tidak ada anggota, toko video itu akan gulung tikar. Demikian pula, jika tidak ada yang
meminjam video apa pun, maka sudah waktunya berkemas dan pulang.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
156 ÿ JAWABAN
Aktivitas 2.6
Daftar berikut berisi kasus penggunaan utama yang mungkin telah Anda identifikasi. Perhatikan bahwa ada kasus
penggunaan lain, yang akan kita temukan pada analisis selanjutnya. Anda mungkin sudah memikirkan beberapa di antaranya
sendiri. Tentunya semakin banyak kasus penggunaan yang Anda temukan sebelumnya, semakin mudah keseluruhan
prosesnya.
Aktor
Catatan atau Masalah
Kasus Penggunaan
Petugas meja depan Pinjam video
Kasus penggunaan ini berinteraksi dengan
mesin kasir
Kembalikan video
Buat anggota
Perlu diputuskan apakah masih
menggunakan kartu anggota
Masukkan reservasi
Anggota
Ini termasuk mengubah dan menghapus
Cari judul
Petugas kantor belakang Menghasilkan surat ulang tahun
Pengambil saham
Lakukan stock opname
Intern
Menghasilkan data untuk
Tidak terlalu dipahami pada tahap ini
gudang data
Manajer keamanan Mempertahankan pengguna yang valid
Setiap orang
Masuk
Keluar
Ganti kata sandi
Dapatkan bantuan daring
Kegiatan 2.7
1. Return Video Use case ini
digunakan ketika ada anggota yang mengembalikan video. Petugas meja depan memindai video dan sistem
diperbarui untuk menampilkan video yang dikembalikan.
(Seperti yang Anda lihat, beberapa kasus penggunaan sangat sederhana.)
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
JAWABAN ÿ 157
2. Menghasilkan Surat Ulang Tahun
Petugas back office melakukan use case ini kira-kira sekali seminggu.
Sistem menampilkan rentang tanggal ulang tahun yang terakhir dibuat.
Petugas kemudian memilih rentang tanggal lain, biasanya satu minggu lagi. Sistem menghasilkan
surat-surat. Petugas memasukkan surat-surat itu ke dalam amplop dan mengeposkannya.
Kegiatan 2.8
Alur alternatif dalam video pinjaman
• Nomor anggota mungkin tidak valid. Minta petugas untuk memasukkan kembali nomor tersebut.
• Anggota mungkin memiliki video yang sudah lewat waktunya. Mereka tidak diperbolehkan meminjam video
lagi, jadi akhiri kasus penggunaan tersebut.
• Anggota mungkin dikenakan denda untuk membayar video yang terlambat dikembalikan. Mereka harus
membayar denda serta biaya untuk video baru tersebut.
Kegiatan 2.9
Meminjam video
Niat Aktor
Tanggung Jawab Sistem
Identifikasi peminjam Konfirmasikan peminjam ada
Identifikasi videonya
Hitung total biaya yang harus dibayar untuk denda masa lalu dan
pinjaman baru
Berikan jumlah total yang harus dibayarkan ke terminal kasir
Identifikasi videonya
Rekam video seperti yang dikembalikan
Kegiatan 2.10
Berikut adalah beberapa contohnya. Masih banyak lagi:
• Apakah benar anggota tidak akan menggunakan sistem komputer? Artinya, apakah semuanya akan
dilakukan melalui petugas?
• Bagaimana para anggota akan mengidentifikasi diri mereka sendiri?
• Ceritakan tentang stock opname. Apa masalahnya? Apa yang kamu coba
meraih?
• Siapa yang akan mendukung dan memelihara sistem?
• Pernahkah Anda berpikir untuk mentransfer data dari sistem lama ke sistem baru
sistem?
• Apakah diperlukan audit?
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
158 ÿ JAWABAN
Kegiatan 2.11
Hal-hal yang perlu diperhatikan tentang diagram ini:
• Lihat bagaimana anggota ditampilkan di sisi kiri. Meskipun mereka tidak berinteraksi langsung dengan
sistem, ada baiknya kita melihat di mana mereka cocok.
• Meskipun terminal mesin kasir merupakan sistem eksternal dalam hal pelacakan video, terkadang
berguna untuk melihat ke dalamnya dan melihat kasus penggunaannya.
Jadi, dalam contoh ini, kita dapat melihat ada use case yang disebut „ambil uang‰.
Harap diingat bahwa ini bukan diagram aliran data jadi kami tidak mengatakan apa pun tentang
aliran data antara kedua sistem.
• Perhatikan bagaimana diagram ini dengan cepat menjadi sangat sibuk dengan banyak garis. Inilah
sebabnya mengapa use case yang digunakan semua orang, yaitu logon, logoff, dll, tidak ditampilkan.
Nanti di unit ini kami akan menunjukkan kepada Anda cara menangani sistem besar dengan
ratusan kasus penggunaan.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
JAWABAN
ÿ 159
Kegiatan 2.12
TEMAC 3: OBJ
ECT-ORIEDIMASUKKAN MO
ODEL
Kegiatan 3.1
Ada ar
berapa banyak cara
s Anda bisa dr
mentah ini. Di hal
khususnya, itu
G
n adalah,
sebuah pertanyaan besar
adalah dua ujian
adalah 'sy sistem‰. Ini contohnya.
Versi 1 Lihat barulah sistemnya
m‰ secara keseluruhan
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
WERS
1 60 ÿ JAWABAN
V
Tampilan
Versi 2
‰
dengan 'sistem'
hanya sebagai videonya
pelacakan
deo pa
seni
n Versi 1 w
utuh. Dalam versi ion 2 kita melihat 'sistem'
kita melihat 'sy sistem‰ sebagai aw
dan trek video bagian cking. W Yang mana kor benar? Keduanya. Bagaimanapun itu
juhanya menjadi
aku
kebenaran. Jika ada
penting itu
kamu tidak mengertitahan perbedaannya
re adalah conf apa pun
fusi, lalu y
kamu
Di dalam
sebagai
adalah
SH
harus dilampirkan
harus mencatat diagrammu
tugas bu
sebagai
n Versi 2 t
ke
jumlah total.
V
Versi 2 jelas
m sehingga hal orang (seperti dan tutor a
arkers) tidak bisa mengerti apa
topi kamu sh
bagaimana.
Masalahnya adalah bagaimana caranya
dengan CashRe egisterTermin nal diberitahu t
dia penting
Apakah itu datang
e dari V
Pelacakan Video g Sistem, atau dari penggunaan
di Video T
terminal.
itu benar-benar menunjukkan hal itu
Sistem Pelacakan em memberitahu te
T
Sebelumnya
g diagram w
P
Paradigma. Bukan te itu en
ditarik kita
di
eh?
nyanyikan Sequ Diagram pengaruhm alat di Visu
terVideo dan
d menampilkanJudul
pesannya ha
jalan a
biasa „*‰ pref
T
Tanda „*‰ mengirimkan
iterasi
mewakili
N. Anda mungkintelah
h memperhatikan sayadi kotak teks Andamemperbaiki. oke, persegigle
panjang
menunjukkan
bahwa
alat
t
s ditempatkan di thdia diagram untuk mengurung sekelompok m
pesan ke dalam
M
biasa
eter.
Namun
m
di
Visu
ver, Sekuelnya
diulangi bersama
pesan adalah P
Diagram ence
adalah
Aku tidak mengizinkannya
Paradigma memang demikian
dia
menempatkan persegi
r
panjang pada diagram.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
JAWABAN ÿ 161
Kegiatan 3.3
Kategori Kelas Konseptual
Contoh
Benda fisik atau nyata
CD Video
Spesifikasi, desain, atau
deskripsi suatu benda
Judul video
Tempat
Toko video Meja depan
Transaksi
Pinjam a
A video
video Kembali
Item baris transaksi
CD Video
Peran orang
Petugas meja depan anggota,
Petugas ruang belakang, Akuntan
semua peran yang Anda identifikasi akan hilang
Konsep kata benda abstrak
Membosankan Menyenangkan
Organisasi
Perusahaan yang membuat kaset video
Bank
Acara
Sebuah video baru dirilis
Proses
Meminjam A
A video
video Kembali
Lakukan a
stock mengambil banyak kasus penggunaan
cocok di sini
Aturan dan kebijakan
Kebijakan peminjaman Kebijakan bergabung Kebijakan yang sudah lewat waktu
Katalog
Katalog video
Manual, dokumen, referensi,
kertas, buku
Catatan anggota Rilis baru Pelatihan karyawan baru
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
1 62 ÿ JAWABAN
WERS
A
Kegiatan 3.4
A
Kegiatan 3.5
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
JAWABAN
ÿ 163
Kegiatan 3.6
TEMAdari 4: MO
KASUS
PENGGUNAAN KEMBALI-C
Kegiatan 4.1
Ini jawabannya, tapi mari kita bicara
Mungkin kamu sudah bisa
ady membayangkan
berhasil melewatinyatidak perlahan.
o jual video lama eos. Jadi ini dia
Ini versi pertama kami
sion.
Kita butuh da gunakan kasus untuk
Aktor Niat
S
Respon
Sistem
pada
Mengenali
kamu video lama S
kepekaan
G
Dapatkan harganya
Pamenghitung jumlah total yang harus dibayarkan ke Kas
Daftar
Teterminal
tentang la
yang Anda
perhatikan Pinjam
Video menggunakan
V
ca
as.
Apa yang harus dilakukan
garis ast? Dia
sama dengan
itu baris terakhir salah satu dari
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
164 ÿ JAWABAN
Jadi kita bisa membuat sub-use case baru yang disebut Proses Pembayaran.
Subfungsi
Tingkat:
Niat Aktor
Dapatkan pembayaran
Tanggung Jawab Sistem
Berikan jumlah total yang harus dibayarkan ke Terminal Mesin Kasir
Kemudian, memperbarui dua kasus penggunaan lainnya memberi kita hal berikut:
Pinjam Video
Niat Aktor
Tanggung Jawab Sistem
Dapatkan Peminjam (catatan yang digarisbawahi) Menampilkan rincian pinjaman saat ini
Identifikasi videonya
Hitung total biaya yang harus dibayar untuk denda masa lalu dan
pinjaman baru
Proses Pembayaran (catatan digarisbawahi)
Jual Video Lama
Niat Aktor
Identifikasi video lama
Tanggung Jawab Sistem
Dapatkan harganya
Proses Pembayaran (catatan digarisbawahi)
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
JAWABAN ÿ 165
Diagram use case dari Aktivitas 2.11 sekarang adalah sebagai berikut.
Kegiatan 4.2
Pertahankan Anggota
Titik Ekstensi:
Kapan saja rincian anggota ditampilkan
Niat Aktor
Tanggung Jawab Sistem
Dapatkan Peminjam
Menampilkan detail pribadi (nama, alamat, tanggal lahir,
tanggal bergabung, dll.), ditambah ringkasan pinjaman saat
ini (misalnya, jumlah pinjaman, jumlah tunggakan, jumlah
pinjaman saat ini, jumlah tunggakan saat ini)
Secara opsional, pengguna dapat
mengubah rincian pribadi anggota
Simpan perubahannya
Secara opsional, pengguna dapat menghapus
Periksa apakah peminjam tidak meminjam apa pun
anggota
Hapus anggota tersebut
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
166 ÿ JAWABAN
Cetak Detail Peminjam
Tingkat:
Subfungsi
Pemicu:
Pengguna ingin mencetak rincian anggota
Poin Perpanjangan: Kapan saja dalam Mempertahankan Anggota
Niat Aktor
Tanggung Jawab Sistem
Tunjukkan bahwa cetakan diperlukan. Cetak detailnya
Kegiatan 4.3
Entitas paling jelas yang ingin kita lacak adalah setiap Video Tape.
Entitas lain yang diagram keadaannya berguna adalah anggota kelas.
Pembahasan masalah tidak menyebutkan bahwa jika seorang anggota memiliki terlalu banyak
tunggakan, maka dia tidak diperbolehkan meminjam, namun fakta inilah yang harus diverifikasi dengan
pengguna individu jika diagram keadaan digunakan.
Seperti yang telah kami nyatakan, tidak salah menggambar diagram keadaan untuk kelas lain, hanya
saja diagram tersebut akan sangat sederhana dan Anda tidak akan belajar darinya. Namun, tentu saja
cara terbaik untuk mengetahuinya adalah dengan menggambarnya.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
JAWABAN ÿ 167
Aktivitas 4.4
Versi pertama diagram keadaan untuk Video Tape mungkin terlihat seperti ini:
Kemudian, Anda dapat memikirkan tentang bagaimana rekaman video muncul. Jelas kita kehilangan
kasus penggunaan di sini, sebut saja Dapatkan Kaset Video Baru.
Dan bagaimana dengan keadaan akhirnya? Jawaban awalnya adalah dengan membuat kasus
penggunaan baru lainnya, kali ini disebut Retire Video Tapes. Jelas kami telah menemukan fungsi baru
dan perlu kembali ke pengguna untuk mendiskusikan hal ini. Misalnya, mungkin mereka mencoba
menjual beberapa kaset video lama.
Jadi sekarang diagramnya terlihat seperti ini:
Terakhir, mari kita pikirkan tentang kaset video yang hilang atau hilang. Sekali lagi, kami perlu
mendiskusikan hal ini dengan Victoria, dan jawabannya mungkin sebagai berikut.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
168 ÿ JAWABAN
Sekarang ke diagram keadaan untuk anggota:
Aktivitas 4.5
Jika Anda memikirkan semua use case yang telah kita diskusikan sejauh ini, Anda harus
menyadari bahwa satu-satunya use case yang mungkin ada hubungannya dengan kelas
Video Spesifikasi adalah use case yang kami identifikasi dalam jawaban Aktivitas 4.4, yaitu
Dapatkan Kaset Video Baru.
Jadi langkah selanjutnya adalah menulis use case tersebut, lalu melanjutkan dengan review.
Pengoperasian pada Spesifikasi Video
Bagaimana Ditangani
Membuat
kasus penggunaan baru: Buat Judul Video
Membaca
kasus penggunaan baru: Pertahankan Judul Video
kasus penggunaan: Dapatkan Kaset Video Baru
Memperbarui
kasus penggunaan baru: Pertahankan Judul Video
Menghapus
kasus penggunaan baru: Pertahankan Judul Video
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
JAWABAN ÿ 169
Kegiatan 4.6
Aturan Bisnis
Kasus Penggunaan
Hanya anggota yang dapat meminjam video.
Pinjam Video
Ketika ada orang baru yang meminta menjadi anggota, mereka
Ditangani oleh Panitera, bukan sistem
harus menunjukkan ID.
Usia minimal adalah 16 tahun.
Ditangani oleh Panitera, bukan sistem
Seorang anggota dapat meminjam video dalam jumlah berapa
Seharusnya ada di Video Pinjam
pun, asalkan tidak ada video yang sudah lewat waktunya.
Ada denda untuk video yang sudah lewat waktunya.
Pinjam Video
Lihat juga Video Pengembalian
Lamanya waktu peminjaman video bergantung pada video
Kasus penggunaan Pinjam Video perlu
tersebut. Rilisan baru hanya dipinjamkan dalam semalam,
menangani hal ini
rilisan saat ini untuk sewa tiga hari, dan sisanya untuk
seminggu.
Anggota dapat memesan video.
Cadangan Video
Setiap video memiliki klasifikasi, (G umum, PG bimbingan
Klasifikasi dan Kategori adalah atribut Spesifikasi
orang tua, MA pemirsa dewasa, dan R terbatas). Anggota
harus berusia di atas 18 tahun untuk meminjam video R.
Setiap video juga memiliki kategori: romansa, umum, fiksi
Video, sehingga dikelola oleh kasus penggunaan
Pertahankan Judul Video, yang diidentifikasi
dalam Aktivitas 4.5.
ilmiah, bahasa asing, dan anak-anak.
Ketika seorang anggota berulang tahun, mereka akan dikirimi surat
Hasilkan Surat Ulang Tahun
khusus yang mengundang mereka untuk meminjam video apa pun
pilihan mereka selama seminggu secara gratis.
Setiap tiga bulan sekali toko tersebut melakukan stock opname. Lakukan stock opname. Pengguna harus melakukannya
ingatlah untuk melakukannya.
Setiap video yang hilang diperbarui untuk ditampilkan sebagai
hilang.
Rekam Kaset Video Hilang. Ini adalah kasus
penggunaan yang kami identifikasi di Aktivitas
4.4
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
170 ÿ JAWABAN
Kegiatan 4.7
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
JAWABAN ÿ 171
TOPIK 5: PEMODELAN DINAMIS
Kegiatan 5.1
Peminum yang haus: (kepada BarBot) Bolehkah saya minta segelas bir?
BarBot:
(ke GlassTray) Ambilkan aku Gelas (bersih)?
Baki Kaca:
(mengambil kaca dari GlassTray dan mengembalikannya ke BarBot)
BartBot:
(memberikan Gelas kosong ke BeerTap) Isilah.
Keran Bir:
(ke Kaca) Seberapa besar kamu?
Kaca:
(ke BarBot) 285ml.
Keran Bir:
(mengeluarkan 285ml bir ke dalam gelas, dan mengembalikan Gelas yang
sudah diisi ke BarBot)
BarBot:
(memberikan segelas penuh kepada peminumnya)
Kegiatan 5.2
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
172 ÿ JAWABAN
Kegiatan 5.3
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
JAWABAN ÿ 173
Kegiatan 5.4
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
174 ÿ JAWABAN
Kegiatan 5.5
Kegiatan 5.6
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
JAWABAN ÿ 175
Kegiatan 5.7
Ini merupakan pertanyaan jebakan, karena sejauh ini kita tidak mempunyai informasi atau persyaratan
pemrosesan yang berbeda untuk kategori yang berbeda. Jadi, meskipun secara konseptual hal ini mungkin
cukup penting bagi pemilik bisnis, dari sisi persyaratan pemrosesan, tidak ada tambahan yang diperlukan.
Mungkin diagram kelas desain kedua pada awalnya merupakan versi yang lebih baik, tetapi setelah
desain selesai, dan tidak ada persyaratan lebih lanjut yang ditemukan, maka gunakan diagram kelas
desain pertama.
Kegiatan 5.8
1. Diagram kedua; memiliki fungsionalitas untuk Catur dan Catur di kelas yang sama (BoardGame) tidak
kohesif secara fungsional.
2. Diagram kedua; Diagram pertama menampilkan kelas Player yang membuat kelas CheckersMove
untuk kelas CheckersBoard. Diagram kedua memungkinkan kelas CheckersBoard menangani
kelas CheckersMove itu sendiri.
3. Gambar B memiliki kopling yang lebih sedikit karena setiap kelas mempunyai paling banyak satu
asosiasi dengan kelas lainnya.
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
UMPAN BALIK MODUL
MODUL MAKLUM BALAS
Jika Anda memiliki komentar atau masukan, Anda dipersilakan untuk:
1. Kirimkan komentar atau tanggapan Anda melalui email ke modulefeedback@oum.edu.my
ATAU
2.
Isi formulir evaluasi online Modul Cetak yang tersedia di myVLE.
Terima kasih.
Pusat Desain dan Teknologi Instruksional ()
Pusat Reka Bentuk Pengajaran dan Teknologi
No Telp : 03-27732578
Nomor Faks : 03-26978702
Hak Cipta © Universitas Terbuka Malaysia (OUM)
Machine Translated by Google
Hak Cipta © Universitas Terbuka Malaysia (OUM)