UML All Resume
description
Transcript of UML All Resume
-
UML Analisis Perancangan Berorientasi Objek
UML
1. Pengertian
UML adalah bahasa grafis yang dipergunakan untuk menangkap artefak dari pengembangan perangkat lunak.
Bahasa ini memberikan model notasi grafis.
UML merupakan satu satunya bahasa yang dipergunakan secara luas oleh industry.
Bahasa ini sangat kaya dan memiliki banyak aspek dari praktek terbaik rekayasa perangkat lunak.
Meskipun begitu, UML sendiri hanyalah sebuah sintaks, sebuah alat, sebuah bahasa yang dapat dipergunakan untuk membangun perangkat lunak. Akan tetapi untuk membangun sebuah sistem yang kokoh (robust) dan mudah dirawat bergantung pada prinsip prinsip perancangan (bukan UML) yang didapat dari pengalaman.
UML menggunakan proses pembangunan perangkat lunak IIF (Iterative, Incremental Framework) dengan 4 tahapan : Inception, Elaboration, Construction, dan Transition. Tahapan construction terdiri dari 4 bagian, yaitu : analisis, perancangan, implementasi, pengujian.
2. Ciri ciri UML
UML bersifat generik: UML tidak mengandung hal hal yang berhubungan dengan proses. Sebuah proses untuk perusahaan A mungkin sangat berbeda dengan proses pada perusahaan B.
3. Komponen UML
UML memiliki berbagai jenis diagram (model) yang berhubungan dengan stake holder pada sebuah pembangunan perangkat lunak. Stake holder tersebut adalah :
-
Analis
Disainer
Koder
Tester
QA
Pelanggan
Penulis teknis
Berbagai
jenis diagram UML tersebut adalah :
Use case diagram
How will our system interact with the outside world?
Mendeskripsikan kelakuan sistem dari sudut pandang pengguna, berguna untuk membantu memahami kebutuhan. Use case adalah dasar dari diagram lain.
Class Diagram
What objects do we need? How will they be related?
Dapat dipergunakan pada tingkatan analisis maupun perancangan. Diagram kelas pada tingkatan analisis disebut model konseptual.
Collaboration Diagram
How will the objects interact?
Diagram kolaborasi (Collaboration Diagram) menggambarkan kolaborasi (kerja sama) yang dilakukan oleh kelas kelas pada sistem.
Sequence Diagram
How will the objects interact?
Sequence Diagram menggambarkan bagaimana objek objek di dalam sistem berinteraksi seiring dengan waktu. Ia menampilkan informasi yang sama dengan Diagram Kolaborasi (Collaboration
-
Diagram), hanya dengan bentuk yang berbeda.
State Diagram
What states should our objects be in?
Menggambarkan keadaan objek pada suatu waktu di dalam sistem kita.
Package Diagram
How are we going to modularize our development?
Package Diagram membagi sistem ke dalam bagan yang lebih kecil dan lebih mudah dimengerti.
Component Diagram
How will our software components be related?
Component Diagram mirip dengan Package Diagram, ia menotasikan pembagian sistem dan hubungan antar modul. Akan tetapi,Component Diagram lebih menekankan komponen perangkat lunak (file, header, link libraries, executeable, package) daripada pembagian logika seperti pada Package Diagram.
Deployment Diagram
How will the software be deployed?
Memberikan gambaran terhadap bagaimana rencana untuk melakukan deploy dari perangkat lunak yang telah dibangun.
1. Tahapan Inception
Pada tahapan inception, UML tidak digunakan. Aktivitas utama dari tahapan ini adalah :
Menentukan tujuan dari product
Membuat business case
Mendefinisikan jangkauan dari proyek
-
Menentukan biaya keseluruhan dari proyek
Salah satu contoh hasil dari tahapan ini adalah business plan.
1. Tahapan Elaboration
Pada tahapan ini, permasalahan yang diutamakan adalah pendetilan masalah (bukan pendetilan implementasi), memahami kebutuhan pelanggan dan bisnisnya, serta mengembangkan rencana ke tingkatan yang lebih lanjut.
Aktivitas utama pada tahapan ini adalah menanggulangi resiko. Semakin cepat sebuah resiko diketahui dan ditanggulangi, semakin kecil akibat yang diakibatkannya terhadap proyek.
Melakukan pemodelan terhadap area yang sulit atau bermasalah dari proyek memberikan bantuan yang besar terhadap penanggulangan resiko.
UML pada Tahap Elaboration
Ada 2 model UML yang dipergunakan pada tahapan ini untuk membantu memahami masalah secara keseluruhan, yaitu : Use Case Model dan Diagram Class(Conceptual Model).
Gambar 1 dua model UML pada tahap Elaboration
-
1. Short Use Case
Diagram Use Case Model berfungsi untuk mendeskripsikan interaksi antara user
dan sistem. Tujuan dari tahapan elaboration menemukan sebanyak mugkin use
case yang ada tanpa perlu memberikan detil penuh terhadap setiap use case.
Use case tersebut akan dikembangkan lebih lanjut pada
tahapan construction.Untuk use case yang memiliki resiko, adalah hal yang baik untuk
melakukan pendetilan terhadapnya dan melakukan penanggulangan resiko.
Finding Use Case
Ada beberapa
pendekatan yang dapat dilakukan untuk menemukan
use case. Salah satunya adalah dengan melakukan wawancara terhadap
pengguna potensial dari sistem. Ini adalah tugas yang sangat
sulit. Dari 2 orang yang berbeda mungkin saja didapatkan pandangan
yang benar benar berbeda dengan apa yang harus dilakukan oleh
sistem (bahkan jika mereka bekerja di bawah organisasi yang sama).
Pendekatan lain yang lebih popular adalah workshop. Pendekatan ini
disebut Joint Requirements Plannin Workshops (JRP). Workshop ini mengumpulkan
sekumpulan orang yang tertarik pada sistem yang sedang dikembangkan
(disebut juga stakeholder) untuk mencari tahu pandangan mereka tentang
apa yang perlu dilakukan oleh sistem.
Kunci kesuksesan terletak pada fasilitator. Mereka memimpin kelompok
tersebut untuk memastikan bahwa diskusi tetap berjalan sesuai dengan
topiknya dan semua stakeholder memberikan tanggapannya.Seorang
juru tulis juga diperlukan untuk mencatat dokumentasi tentang
jalannya workshop.
Use Case berperan penting disini, kesederhanaannya memberikan kemampuan
kepada stakeholder yang sekalipun gagap teknologi, dapat menangkap
konsep dari diagram dengan mudah.
-
Suatu metode yang sederhana untuk menyukseskan workshop adalah :
Brainstorm semua actor yang memungkinkan terlebih dahulu.
Brainstorm semua use case yang memungkinkan.
Selesai brainstorming, lakukan justifikasi terhadap use case dengan menggunakan grup.Deskripsikan setiap use case dengan 1 baris / paragraf sederhana. Jika use case tidak dapat dideskripsikan, besar kemungkinan ia bukanlah use case.
Tuangkan dalam bentuk model.
NB : Jangan memaksakan diri untuk menemukan semua use case dan actor.
Adalah hal yang lumrah untuk menambahkan use case dan actor kemudian.
NB : Setiap langkah tidak harus benar 100%!
Sebuah formula untuk menentukan jumlah
use case : Apa yang masuk ke dalam
sistem adalah jumlah dari keseluruhan
use case.
Komponen Use Case
Ada 2 komponen
Use Case Model, yaitu : Use Case dan Actor.
1. Use Case
Gambar 2 Notasi Use Case
-
Ciri ciri :
Use Case dideskripsikan menggunakan kombinasi kata kerja dan kata benda.
Use Case tidak dapat di-inisiasi oleh dirinyya sendiri.
1. Actor
Gambar 3 Notasi Actor
Ciri ciri :
Actor dideskripsikan menggunakan kata benda.
Dapat (bukan harus) melakukan inisiasi terhadap use case.
Actor tidak harus orang, dapat saja sistem, atau entitas yang berhubungan dengan sistem tetapi berasal dari luar sistem.
1 Actor dapat berinteraksi dengan beberapa use case.
Tujuan dari Use Case Model
Meski Use
Case terlihat sederhana akan tetapi ia
merupakan komponen yang penting di dalam UML. Berikut
adalah kegunaan dari Use Case :
Mendefinisikan jangkauan dari sistem.
-
Memberikan fokus yang lebih baik kepada kebutuhan (requirement) sistem (sebab biasanya kebutuhan sistem cenderung kabur, membingungkan, ambigu, dan ditulis dengan buruk).
Gabungan dari seluruh Use Case adalah sistem secara keseluruhan.
Memungkinkan komunikasi antara pelanggan dan pengembang.
Menuntun tim pengembang melalui proses pengembangan. Use Case adalah Backbone.
Memberikan sebuah metode untuk merencanakan kerja pengembangan dan memungkinkan estimasimengenai lama pengembangan.
Memberikan basis untuk melakukan pengujian sistem.
Membantu pembuatan user guide.
Use Case Granularity
Granularity berbicara tentang sebesar apakah isi dari sebuah use case?
Apakah setiap
interaksi pengguna ke sistem harus dituangkan ke dalam sebuah use
case atau
seluruh
interaksi tersebut dibungkus di dalam sebuah use case?
Kesalahan
utama di dalam use case adalah seringkali pengembang membuat sejumlah
besar use case kecil dan tidak relevan. Pada sistem yang besar,
mungkin saja berakhir dengan jumlah use case yang tidak
logis dan menyebabkan kompleksitas
meningkat pesat.
Ada hal yang harus diingat mengenai pembuatan use case : Sebuah use
case harus memenuhi tujuan akhir dari actor.
Contoh : pada kasus mesin ATM, apakah tujuan akhir dari user
adalah memasukkan kartu/pin, atau mengambil receipt? Tidak,
-
sehingga tidak perlu membuat use case untuk hal tersebut. Hal
yang diperlukan oleh user adalah mengambil uang. Sehingga cukup
menggunakan sebuah use case itu saja, meski di dalamnya ada
aktivitas seperti memasukkan kartu/pin, dsb.
Use Case Description
Setiap
use case
memiliki sekumpulan penuh penjelasan detil tertulis
mengenai interaksi dan skenario di dalamnya. Berikut adalah template yang
digunakan untuk men-spesifikasi-kan struktur dan isi dari dokumenuse case
description :
Gambar 4 Use Case Description Template
Untuk Short use case, bagian yang harus
diisi adalah : nama use case, deskripsi singkat, actor (dapat
ditambahkan pada template di atas), dan requirement yang dipenuhinya
(dapat ditambahkan pada template di atas).
Ranking Use Case
Pada saat melakukan tahapan construction, use case yang telah dibuat
disini akan mengalami
iterasi berulang kali. Untuk membagi
use case ke dalam pekerjaan
-
iterasi yang ada, use case dialokasikan menggunakan tingkatan (rank).
Secara mudah, tingkatan adalah angka yang menunjukkan
use case yang akan dikembangkan. Pengalaman yang akan menentukan
use case manakah yang akan memiliki tingkatan lebih tinggi. Ada 6 jenis
tingkatan secara umum :
Risky use cases
Major Architechtural Use cases
Use cases exercising large areas of system functionality
Use Cases requiring extensive research, or new technologies.
Quick wins
Large Payoffs for the customer
Sebuah use case mungkin saja mengalami beberapa kali proses iterasi, pecah
use case tersebut ke dalam beberapa versi. Pada akhir setiap iterasi, use case
tersebut masih dapat melakukan sesuatu tetapihanya pada suatu batasan
tertentu.
1. Diagram Class (Conceptual Model)
Conceptual Modeling (disebut juga Domain Modeling) adalah aktivitas untuk menemukan konsepyang penting untuk sistem. Proses ini membantu untuk memahami masalah lebih lanjut, dan mengembangkan pemahaman lebih mendalam tentang keperluan pelanggan. Untuk melakukan hal ini (menemukan konsep), dipergunakan sintaks UML yaitu class diagram.
Catatan pada tahap ini adalah : jangan melakukan perancangan sistem, tahapan yang
dilakukan masih analisis.
Class Diagram yang telah dihasilkan pada tahapan ini tidak berhubungan dengan tahapan construction (Tidak melakukan perancangan sistem). Oleh karenanya,class diagram pada tahapan ini lebih sering disebut conceptual model untuk memberikan perbedaandengan class diagram sesungguhnya pada tahapan construction. Mulai saat ini class diagram pada tahapan ini akan disebut sebagai conceptual model.
-
Conceptual model tidak boleh berhubungan dengan perancangan (design), seperti : database, daemon process, form, trigger, event, dsb.
If the customer doesnt understand the concept, it probably isnt concept at all.
Finding Concept
Salah satu cara terbaik untuk menemukan konsep adalah dengan melakukan hal yang sama pada saat mencari use case, yaitu workshop dan brainstorming.
Cara lain adalah dengan mencari konsep melalui dokumen kebutuhan (requirement). Beberapa kandidat konsep yang mungkin dapat diambil dari requirement adalah :
Objek fisik atau nyata.
Tempat
Transaksi
Tugas (pelanggan, sales, dll)
Container untuk konsep lain.
Sistem lain (eksternal)
Kata benda abstrak
Organisasi
Kejadian
Aturan
Catatan
Cara kedua untuk mencari konsep dari dokumen requirement adalah dengan mencari
kata benda di dalam dokumen tersebut. Meskipun cara untuk mencari konsep
dari dokumen requirement ini cukup sering dipakai, tetapi input dari
pelanggan adalah penting!.
Conceptual Model
-
Ada 2 komponen di dalam conceptual Model, yaitu : Concept Box dan Association.
1. Concept Box
Gambar 5 Concept Box (Similar to Class)
Concept ditampilkan pada sebuah kotak sederhana
dengan judul dari konsep (dalam huruf besar secara konvensi)
pada baris teratas kotak. Di dalam kotak yang besar terdapat 2
kotak yang lebih kecil. Kotak pertama (yang berada di tengah)
digunakan untuk atribut dari konsep.Kotak kedua (yang berada di
bawah) digunakan untuk kelakuan dari konsep.
NB : Pada conceptual model
kelakuan tidak diisi (belum didefinisikan). Kelakuan baru
didefinisikan pada tahapan construction saat membuat class diagram.
Finding Attribute
Hal yang seringkali dipermasalahkan adalah apakah
sebuah atribut seharusnya adalah konsep? Sebuah saran yang cukup
baik untuk masalah ini adalah : jika ragu, jadikanlah atribut
tersebut sebagai konsep, waktu akan menyelesaikannya nanti.
Ada beberapa hal yang dapat membantu untuk menentukan atribut
:
Nilai tunggal (string atau angka) biasanya adalah atribut
-
Jika sebuah property dari konsep tidak dapat melakukan apapun, kemungkinan ia adalah atribut.
1. Association
Asosiasi berfungsi untuk mendeskripsikan bagaimana 2 buah konsep berhubungan. Di dalam setiap hubungan tersebut ada yang disebut sebagai kardinalitas. Kardinalitas memberitahu berapa banyak instans yang diijinkan untuk setiap konsep.
Gambar 6 Contoh Kardinalitas
Notasi * berarti banyak. Ada sedikit perbedaan pada * dan
1..*. Yang pertamamengartikan banyak
secara kabur, mungkin banyak konsep yang diijinkan ataupunbelum d
ibuat keputusan yang pantas. Yang terakhir mengartikan banyak
yang lebihkonkret, satu atau lebih dari satu diijinkan.
Untuk setiap asosiasi yang telah dibuat, diberikan nama di atas garis (yang
menyatakan asosiasi tersebut). Nama tersebut sesuai dengan arti dari relasitersebut.
Building the complete model
Setelah sesi brainstorming selesai, akan didapat sekumpulan
concept dengan atribut. Untuk menemukan
relasi antara 2 konsep hal terbaik adalah dengan menanyakan apakah
-
kedua konsep tersebut salingberhubungan atau tidak. Kesalahan yang
mungkin terjadi pada tahap ini biasanya adalah :
Pemutusan bahwa 2 konsep berhubungan
Pembuatan garis diagram dan tidak ada nama yang diberikan
Saat membangun model adalah penting untuk mengingat bahwa asosiasi tidak lebih
penting daripada atribut. Setiap asosiasi yang kurang dapat dengan
mudah ditambahkan kemudian, tetapi adalah jauh
lebih
susah untuk mencari
atribut yang hilang.
Pada akhirnya, sebuah diagram harus masuk akal ketika pelanggan membaca
kembali diagram tersebut dalam kalimat biasa.
1. Tahapan Construction
Pada tahapan construction, produk dibangun, sistem dibawa pada keadaan dimana ia siap diantarkan kepada komunitas pengguna.
Strategi pada tahapan ini adalah sekumpulan proses waterfall pendek, dengan sekumpulan kecil use case yang dikembangkan pada setiap iterasi. Secara ideal, pada akhir iterasi diharapkan sebuah sistem yang dapat berjalan meski terbatas.
Setiap tahapan iterasi waterfall akan memiliki sekumpulan dokumen UML :
Pada analisis, akan dihasilkan beberapa use case (yang penuh ataupun diperluas)
Pada perancangan, akan dihasilkan class diagram, interaction models, dan state diagrams.
Pada pengkodean, akan dihasilkan kode yang telah diuji dan dijalankan.
Fase Analisis
-
Pada tahapan
ini, meski telah berada tahapan construction, akan tetapi
kita masih berada pada tahapan analisis. Yang harus kita
perhatikan bukanlah solusi, melainkan masalah. Tujuan utama dari fase
ini adalahmemahami masalah dengan lebih mendalam. Short use case yang
telah dibuat pada tahapan
elaboration akan dikembangkan kembali di tahapan ini untuk
diberikan detil secara penuh.
Gambar 7 Use Case Description Template
Pada bagian ini, short use case
telah memberikan detil terhadap bagian use case dan short description
(serta dengan tambahan actor dan requirement jika diperlukan). 5
bagian lain belum diisi. Berikut adalah keterangan untuk kelima bagian
tersebut.
Pre-Conditions
Bagian ini menjelaskan kondisi yang harus dipenuhi sebelum use case dapat berjalan. Bagian pre conditions harus bukan sebuah proses yang termasuk di dalam use case. Contoh : jika ada sebuah pre condition : user telah berhasil login, artinya proses validasi user tidak termasuk di dalam use case tersebut.
Post-Conditions
Bagian ini menjelaskan kondisi sistem pada akhir use case. Harus ada proses di dalam use case yang memberikan hasil ini. Kondisi akhir
-
ini dapat menggunakan syarat perbandingan if-then (jika maka).
The Use Case Flow
Ada 3 Flow utama dari use case, Flow dimulai dari main flow dan berpindah ke flow lain jika diperlukan. Perpindahan ke alternate flow ditandai dengan [An] dengan n adalah nomor urut Alternate Flow. Perpindahan ke exception flow ditandai dengan [En] dengan n adalah nomor urut Exception Flow.
Gambar 8 Full Use Case Description
Berikut adalah penjelasan aliran
proses pada sebuah Use Case :
Main Flow
Aliran ini menjelaskan proses use case jika tidak terjadi hal hal di luar dugaan. Pada aliran proses ini, userdianggap
-
memberikan masukan (input) sesuai dengan harapan (kondisi ideal). Interaksiantara user dengan sistem dijelaskan secara mendetil disini. Kondisi akhir darimain flow adalah post condition.
Alternate Flow(s)
Alternate flow adalah aliran proses yang akan dijalankan (dibangkitkan) jika terjadihal hal di luar dugaan pada main flow. Pada alternate flow, mungkin terjadi perubahan post condition. Perubahan padapost condition, ditandai dengan :
Post Conditions (Post Condition baru).
Exception Flow(s)
Exception Flow adalah aliran proses yang akan dijalankan (dibangkitkan) jika terjadihal hal yang tidak diinginkan ataupun hal hal yang tidak diduga sebelumnya. Pada kode program, bagian ini dipetakan ke bagian penanganan exception (seperti pada C++, Java, Ada, Delphi, dan bahasa pemrograman lainnya). Biasanya akan mengakhiri proses use case seketika.
Pada saat menulis proses dari aliran proses sebuah use
case, seringkali terjadi pencampuranantara analisis dan perancangan
(disain). Contohnya : di dalam aliran proses seringkali
disebutkan bagaimana sistem mengakses dan memodifikasi database,
pemindahan data data di dalam sebuah array, dsb
(yang seharusnya tidak boleh). Hal ini mungkin terjadi
akibatsulitnya menemukan kata kata yang tepat untuk menggambarkan
keadaan yang diinginkan oleh pengembang saat menuliskan aliran
proses. Untuk menanggulangi masalah ini dapat digunakan sequence
diagram untuk membantu (bukan
menggantikan) menjelaskan aliran proses dari use case..
Sequence diagram
dapat dipergunakan pada tahapan analisis maupun perancangan
(disain). Untuk tahap analisis,sistem
-
dianggap
sebagai sebuah kotak hitam (black box). Sequence Diagram dapat
dipergunakan hanya untuk main flow, tidak perlu menggambarkan sequence
diagram untuk alternate flow dan exception flow kecuali jika benar benar
kompleks atau menarik. Ada 4 komponen dari sequence diagram yang
akan dipergunakan pada tahapan analisis :
Actor
Gambar 9 Actor
Actor berada pada sisi kiri dari diagram. Nama dari actor berada
di bagian bawah dari gambaractor.
System Box
Gambar 10 System Box
System box berada pada sisi kanan dari diagram. Keseluruhan
sistem direpresentasikan sebagai sebuah kotak dan diberi nama
sistem (ataupun nama dari sistem).
Timelines
-
Gambar 11 Timeline
Sebuah garis lurus vertikal ditambahkan di bawah
actor dan system
box untuk menggambarkan aliran waktu.
Interactions
Gambar 12 Interaction
Interaksi antara user dengan sistem digambarkan dengan garis dan
panah antara
user dengan sistem. Kotak yang tergambar di garis
timeline menyatakan waktu yang dihabiskan oleh satu sekuen dari
proses. Nama dari interaksi yang terjadi di tulis diatas garis
dan mendeskripsikan jenis interaksi yang terjadi.
Berikut adalah contoh dari sequence diagram :
-
Gambar 13 Contoh Sequence Diagram
Fase Perancangan
Pada fase ini seharusnya permasalahan telah dapat dimengerti
sepenuhnya (untuk iterasi ini). Perancangan akan memulai pembuatan
solusi untuk masalah. Pada tahapan ini ada 3 hal yang harus
diperhatikan :
Objek apa saja yang diperlukan oleh sistem
Objek yang mana yang bertanggung jawab untuk memenuhi kebutuhan
Waktu untuk objek berinteraksi
Untuk menggambarkan interaksi antar objek, digunakan Interaksi diagram.
Interaksi diagram terdiri atas2 jenis diagram yang saling berelasi, yaitu
-
: sequence
diagram dan collaboration
diagram. Setelah objek objek yang diperlukan telah dimiliki, sebuah class
diagram dipergunakan untuk menangkap informasi bagaimana kelas kelas saling
berelasi. Akhirnya, sebuah model lain dipergunakan untuk
memberikan penjelasan tentang state dari setiap objek yang disebut dengan state
diagram atau state model.
Karena pada tahapan ini telah memulai pembuatan solusi maka pada
tahapan ini akan mulai dibicarakan tentang pemrograman (pseudo-code, code),
basisdata, struktur data, dan berbagai hal lain
yang berhubungan dengan perangkat lunak.
Pada fase perancangan ini, ada 3 tipe model yang akan dihasilkan
: interaction diagram, class diagram, dan state diagram.
Interaction Diagram
Collaboration Diagram
Use case yang telah didapatkan pada tahapan
sebelumnya, tugasnya akan dijelaskan denganmenggunakan kolaborasi
dari objek yang berbeda. Collaboration Diagram dipergunakan
untukmenjelaskan
kolaborasi dari objek objek yang ada untuk memenuhi sebuah use
case. Collaboration Diagram memiliki sintaks berikut :
Class
Kelas di dalam collaboration diagram memiliki notasi seperti berikut :
-
Gambar 14 Notasi Kelas
Objek
Ada 2 jenis objek yang dimodelkan di collaboration diagram, yaitu : objek biasa (instan dari sebuah kelas) dan objek dengan penamaan (nama dari objek) atau objek bernama.
Gambar 15 Notasi Objek Biasa
Gambar 16 Notasi Objek Bernama
Di dalam collaboration diagram kumpulan (stack) objek dimodelkan
dengan notasi berikut :
Gambar 17 Notasi Kumpulan (Stack) Objek
Objek Communication
-
Untuk menggambarkan komunikasi antar 2 objek, dinotasikan sebagai berikut :
Gambar 18 Notasi Komunikasi Objek
Message Passing and Numbering
Antara 2 objek yang berkomunikasi, komunikasi tersebut terjadi dengan melakukan pertukaran pesan (message passing). Ada 3 jenis pesan yang dapat dikirimkan ketika 2 objek berkomunikasi, yaitu : pesan biasa, pesan dengan parameter, pesan dengan nilai kembalian.
Gambar 19 Notasi Pesan Biasa
Gambar 20 Notasi Pesan dengan Parameter
-
Gambar 21 Notasi Pesan dengan nilai kembalian
Angka yang berada di
samping
pesan yang dikirimkan menyatakan
urutan pesan tersebut dieksekusi untuk memenuhi
use case. Setiap penambahan pesan, nilai di samping pesan
akan dinaikkan 1 (increment).
Looping
Untuk menggambarkan terjadinya loop, dipergunakan notasi berikut :
Gambar 22 Notasi Looping (Perulangan)
Tanda asterisk (*) pada pesan
(message) menandakan bahwa pesan tersebut diulang.
Creating new object
-
Untuk membuat objek baru, dipergunakan notasi berikut :
Gambar 23 Notasi Create Objek
Meskipun notasi ini memiliki sedikit keanehan, pesan dikirimkan
kepada objek yang bahkan belum ada (belum di-create).
Berikut adalah contoh dari sebuah collaboration diagram :
Gambar 24 Contoh Collaboration Diagram
Darimanakah objek objek yang dipergunakan di dalam collaboration diagram di atas
berasal?
Beberapa objek di atas adalah objek baru yang belum pernah
dilihat, akan tetapi kebanyakan objek yang berada di
-
dalam collaboration diagram adalah objek yang berasal
dari conceptual model yang telah dibuat pada tahap elaboration.
Terkadang pada saat membuat collaboration diagram akan disadari
bahwa ada association yang belum ditemukan (dibuat) pada tahap
pembuatan conceptual model. Hal ini terkadang dapat mengganggu
kebutuhan (requirement) dari pelanggan. Jika hal ini
terjadi, tanyakan pada pelanggan terlebih dahulu.
Dengan membuat collaboration diagram, code yang akan diimplementasikan
menjadi sistem tidak terpetakan dengan baik. Ada beberapa
masalah yang belum terselesaikan melalui collaboration diagram,
yaitu :
Input dan output (interface) antara user dengan sistem belum terdefinisi
Basis data dan jaringan belum terdefinisi disini
Keputusan yang dibuat mengenai sebuah kelas belum terdefinisi dengan jelas.
Di dalam membuat collaboration diagram ada 4 hal yang harus dicatat :
Buat diagram sesederhana mungkin. Jika sebuah diagram menjadi sangat kompleks, cobalah untuk membuat diagram terpisah untuk setiap interaksi dengan user.
Jangan berusaha untuk menjelaskan setiap scenario yang mungkin ada. Alternative flow adalah sesuatu yang jarang terjadi, tidak perlu disertakan di dalam diagram.
Jangan membuat kelas dengan nama controller, handler, manager, atau driver. Hal ini membuat desain menjadi tidak berorientasi objek melainkan berorientasi aksi (action oriented).
Hindari kelas dewa. Kelas dewa adalah sebuah kelas yang mengerjakan berbagai hal dan tidak banyak berkolaborasi dengan objek lain. Sebuah solusi OO yang baik adalah kelas kelas kecil yang saling bekerja sama untuk mencapai
-
tujuannya.
Sequence Diagram
Sequence Diagram memberikan informasi yang sama dengan Collaboration
Diagram. PembuatanSequence Diagram pada tahapan ini sama
dengan sequence diagram
pada tahapan analisis yang dipergunakan saat menjelaskan aliran
proses use case. Perbedaannya adalah pada bagian ini, sistem
diperluas dengan objek objek yang sama seperti
pada collaboration diagram. (NB : Hanya berbeda susunan
bukan urutan, ditambah dengan penambahan timeline untuk
mempermudah pembacaan diagram).
Class Diagram
Class Diagram yang dipergunakan disini memiliki notasi yang sama
dengan conceptual model
pada tahapan elaboration. Perbedaan class diagram
pada tahapan ini dengan conceptual model (class diagram pada tahapan
elaboration) adalah padaconceptual model
tidak ada deskripsi kelakuan (fungsi dan prosedur) di dalamnya, semuanya hanya
berpusat pada masalah pelanggan.
Conceptual Model yang telah dibuat sebelumnya akan dikembangkan lebih
lanjut pada tahapan ini untuk menjadi design class diagram
yang sebenarnya. Dengan kata lain, sebuah diagram dimana dapat di-kode-
kan.
Pembuatan class diagram didasarkan
pada conceptual model dan collaboration diagram. Perubahan ini cukup
terstruktur dan mekanis, perubahan ini harusnya tidak terlalu
susah. langkah langkahpembuatannya adalah sebagai berikut :
Penambahan operasi (kelakuan)
-
Penambahan navigasi pesan (navigability)
Perbaikan atribut
Pemutusan Visibilitas
Pembuatan agregasi
NB : Jika agregasi sudah ditemukan pada tahapan conceptual model, boleh ditambahkan.
Pembuatan komposisi
NB : Jika komposisi sudah ditemukan pada tahapan conceptual model, boleh ditambahkan.
NB : praktisi berpedapat bahwa agregasi dan komposisi bukanlah suatu hal
yang baik. Relasi ini bersifat redundan (berulang ulang) dan harus
dihilangkan. Meskipun begitu, agregasi tetaplah sebuah konsep OO. Ia
tetap legal untuk dipergunakan. Agregasi dan komposisi dapat
dimodelkan sebagai sebuah asosiasi dengan nama is composed from.
State Diagram
State Diagram berfungsi untuk memodelkan keadaan keadaan yang mungkin
dimiliki oleh sebuah objek. Model ini memungkinkan untuk menangkap
kejadian kejadian (event) yang penting dan efeknya setelah kejadian
(event) tersebut.
Sintaks dari diagram ini adalah sebagai berikut :
Start state
Start State ini menggambarkan keadaan objek di awal pembuatannya.
-
Gambar 25 Notasi Start
End state
End State ini menggambarkan keadaan objek dihancurkan.
Gambar 26 Notasi End
State Describer
State describer dipergunakan untuk menuliskan keadaan dari objek.
Gambar 27 State Describer
State Transition
Sebuah event dapat menyebabkan sebuah objek berubah state atau tetap pada state-nya.Perubahan (transition) dari sebuah state ke state lainnya diakibatkan oleh sebuah event digambarkan oleh state transition. Event yang menyebabkan perubahan tersebut dituliskan di atas garis panah. State yang dihasilkan digambarkan di kotak event describer.
Gambar 28 State Transition
Sub/Superstate (Nesting States)
Terkadang diperlukan penggambaran state di dalam sebuah state. Sebuah state yang lebih umum dipergunakan untuk menggambarkan komponen komponen state yang lebih kecil. State yang lebih umum disebut superstate. State yang lebih khusus (bagian
-
dari superstate) disebutsubstate.
Gambar 29 Nesting State
Terkadang sebuah superstate dapat mengalami interupsi. Adalah
memungkinkan untukmenggambarkan keadaan dimana saat sebuah superstate
melanjutkan
state-nya akan dimulai dari saat state
terakhir sebelum diinterupsi. Superstate yang seperti itu disebut
history state. Notasinya adalah huruf H di dalam lingkaran.
-
Gambar 30 History State
Entry/Exit Event
Di dalam sebuah state dapat ditambahkan keterangan mengenai keadaan awal dan akhir dari state. Keadaan awal (disebut entry) menggambarkan keadaan yang diperlukan ketika sebuahstate berubah (bertransisi) menjadi state yang memiliki keterangan entry. Keadaan akhir (disebutexit) menggambarkan keadaan yang dimiliki oleh state ketika state berakhir.
Gambar 31 Entry/Exit Event
Untuk menggambarkan keadaan dimana sebuah state harus mengirimkan
pesan ke objek lain, dipergunakan notasi seperti berikut :
^object.method (parameters)
-
Gambar 32 Entry berparameter
Guard
untuk menggambarkan bahwa sebuah kondisi harus dipenuhi supaya terjadi state transition (bukan supaya state transition berhasil seperti pada entry event).
Gambar 33 Guard
Contoh dari state diagram :
Gambar 34 Contoh State Diagram
Bagian ini dipergunakan pada tahapan construction (desain) untuk dapat melakukan sebuah
perancangan yang BAIK.
-
Konsep OO
Pattern
Sebuah pattern adalah sebuah solusi yang dipergunakan dengan baik dan
sangat umum untuk masalah masalah yang cukup sering terjadi. Ada
banyak pattern yang dapat dikenal oleh seorang perancang.Pattern yang akan
dibahas pada bagian ini disebut GRASP (General Responsibility Assignment Software
Patterns). GRASP membantu untuk menentukan kelakuan
dari setiap kelas dengan cara yang
paling elegan yang dimungkinkan. Pola (Pattern) tersebut dinamakan : Expert,
Creator, High Cohersion, Low Coupling, dan Controller. Penggunaan dari kelima
pola GRASP akan membuat perancangan
OO menjadi lebih dapat dimengerti, mudah diubah, dan kokoh (robust).
Expert
Ini adalah sebuah pola yang sangat sederhana namun juga
seringkali dilanggar. Pola ini harus yang paling utama ada di
dalam pikiran seorang perancang saat membangun diagram kolaborasi
ataumerancang
class diagram.
Pola ini membantu alokasi kelakuan (behavior) ke dalam kelas. Alokasi
yang baik dari sebuah kelakuan memiliki nilai :
Mudah dimengerti
Dapat di-extend secara mudah
Dapat dipergunakan kembali (reusable)
Lebih kokoh (robust)
Pola ini memiliki aturan : Hanya kelas yang expert terhadap
suatu behavior
saja baru boleh memiliki
-
behavior tersebut.
Creator
Pola ini adalah penggunaan spesifik dari Expert Pattern. Pola ini menjawab
pertanyaan : Kelas manakah yang harus bertanggung
jawab untuk pembuatan instans dari suatu kelas tertentu..
Kelas A harus bertanggung jawab untuk pembuatan kelas B, jika :
A mengandung objek B
A menggunakan objek B secara dekat
A memiliki inisialisasi data yang akan digunakan oleh B
High Cohesion
Sebuah perancangan
OO yang baik memiliki tanda setiap kelas hanya memiliki sejumlah kecil
method. Merupakan hal yang sangat penting untuk memastikan bahwa setiap
kelas memiliki tanggung jawab yang terfokus.
Aturan utama dari pembangunan sebuah kelas adalah setiap kelas harus
memiliki hanya satu kunci
abstraksi (menggambarkan sebuah benda dari dunia nyata)
Low Coupling
Coupling adalah sebuah ukuran untuk menentukan
seberapa tergantungnya sebuah kelas terhadap kelas lain. Coupling
yang tinggi dapat menyebabkan code yang sulit diubah atau dirawat
sebuah perubahan kecil dapat menyebabkan ombak perubahan terhadap
sistem.
Untuk mengurangi coupling salah satu cara terbaik adalah
dengan mengikuti model conceptual. Pesan yang dikirimkan hanya jika ada
-
asosiasi yang telah didefinisikan pada tahapan conceptual modeling.
Aturan utama disini adalah : Jaga coupling seminimum mungkin conceptual
model adalah sumber yang sempurna sebagai ukuran mengenai
jumlah coupling
minimum. Menaikkan level dari coupling bukanlah sebuah masalah jika telah
dipikirkan dengan baikkonsekuensinya!
The Law of Demeter
Hukum ini, dikenal juga sebagai : Dont Talk to Strangers, adalah
sebuah metode yang efektif untuk memerangi coupling. Hukum ini
menyatakan bahwa setiap objek hanya boleh memanggil methodyang
dimiliki oleh :
Dirinya sendiri
Parameter yang dikirimkan kepada method
Setiap objek yang dibentuk
Setiap yang memegang objek secara langsung.
Beberapa hal yang harus dipertimbangkan mengenai coupling :
Jangan pernah membuat atribut dari kelas bersifat public. SEbuah atribut public membuka kesempatan penyalahgunaan sebuah kelas (pengecualian hanya diberikan kepada constantsdari kelas).
Berikan get dan set hanya pada saat diperlukan.
Berikan antarmuka public yang paling minimum.
Jangan biarkan data mengalir di dalam sistem (minimalisasi pemindahan data).
Jangan hanya mempertimbangkan coupling Ingat mengenai High cohesion dan expert! Sebuah kelas yang tidak memiliki coupling sama sekali akan memiliki kelas yang mengambang danmemiliki terlalu banyak pekerjaan. Biasanya berakhir dengan sistem
-
yang memilikisedikit objek aktif yang tidak berkomunikasi.
Controller
Secara umum penambahan informasi mengenai GUI (Graphical User Interface),
basis data, atau objek fisik lainnya ke dalam kelas
merupakan sebuah perancangan yang buruk. Kelas kelas dariconceptual
model adalah kelas bisnis yang harus dibiarkan tetap murni (tanpa
GUI, database,dll). Untuk menghubungkan kelas bisnis dan actor
diperkenalkan sebuah kelas baru yang dinamakan controller. Nama
dari controller memiliki konvensisebagai berikut : Handler.
Inheritance
Seringkali di dalam perancangan, beberapa kelas memiliki
karakteristik yang sama. Karakteristik yang sama ini dapat digabungkan ke
dalam sebuah kelas (untuk mengurangi
pengulangan/redundan kode). Kelas ini kemudian dapat di-waris-kan
(inherit) ke kelas lain yang lebih khusus dan menambahkan
atribut serta method
kepada kelas yang lebih khusus tersebut.
Gambar 35 dua kelas dengan karakteristik mirip
-
Gambar 36 Penggunaan Inheritance
Proses pengelompokan
karakteristik sebuah kelas yang sama dari beberapa
kelas ke dalam sebuah kelas yang lebih umum disebut proses generalisasi.
Kelas yang lebih umum disebut base class (atau superclass). Kelas yang
lebih khusus disebutderived class (atau subclass). Sebuah base class dapat
diturunkan (inherit) ke base class lain yang lebih khusus.
Permasalahan yang seringkali muncul berhubungan
dengan inheritance adalah penggunaan
inheritance secara berlebihan. Hal ini dapat menimbulkan permasalahan
pada perawatan. Hal ini disebabkan kelas turunan (derived class) memiliki
coupling yang sangat erat terhadap kelas basis (base
class). Perubahan pada kelas basis akan menyebabkan perubahan pada
kelas turunan.
Penggunaan kelas turunan mewajibkan perancang untuk mengetahui
kemampuan dari kelas basis. Hal ini berarti harus diadakan eksplorasi
terhadap hierarki kelas yang besar. Masalah ini dikenal juga dengan
-
nama proliferation of classes. Hal ini disebabkan
karena inheritance dipergunakan ketika ia tidak seharusnya
dipergunakan.
Aturan utama di dalam penggunaan inheritance adalah : Gunakan
inheritance hanya sebagai alat (mekanisme) generalisasi tidak selalu
harus menggunakaninheritance.
Dalam melakukan inheritance ada 2 aturan yang harus diikuti, yaitu :
aturan is a kind dan aturan 100 %.
Aturan 100 %
Aturan ini berisi : Semua definisi yang dimiliki oleh
kelas basis harus diaplikasikansecara penuh oleh kelas turunan.
Pengabaian terhadap aturan ini dapat menyebabkan
masalah terhadap perawatan.
Substitutability
Sebuah method tidak dapat dihapus di dalam hierarki inheritance.
Aturan is a kind
Aturan ini berfungsi untuk melakukan pengujian apakah
hierarki inheritance yang dimilikivalid. Aturan ini mengatakan
bahwa sebuah frase dengan format : is a harus masuk akal.
-
Aggregation vs Inheritance
Jika sebuah kelas sepertinya dapat diturunkan dari sebuah kelas lain
(base class) tetapi tidak memenuhi aturan 100% dan aturan is-a-kind maka
cobalah mempertimbangkan agregasi untuk
menggantikan inheritance yang hendak dilakukan.
Permasalahan dengan Inheritance
Meskipun inheritance terlihat seperti sebuah alat yang powerful untuk
memaksimalkan konsep
reuse, Ia harus dipergunakan dengan hati hati. Inheritance dapat
menyebabkan hierarki kelas yang kompleks dan sulit dimengerti
(profileration of classes). Karenanya pergunakanlah inheritance dengan hati
hati dan yakinkan aturan 100% dan is-a-kind diterapkan dengan baik.
Sebagai tambahan, Inheritance adalah white-box-reuse. Enkapsulasi antara
kelas basis dan kelasturunan cukup lemah secara umum, perubahan
terhadap kelas basis dapat menyebabkan perubahan
kelas turunan manapun. Hal ini menyebabkan pengguna kelas
harus mengetahui hubungan antara parent class (superclass, kelas basis)
dengan kelas yang sedang dikerjakan (child class, subclass, kelas turunan).
Protected Visibility
Atribut dalam setiap kelas memiliki karakteristik visibility.
Secara default, visibilitydari sebuah atribut pada kelas
adalah private. Hal ini berarti apapun (kelas manapun) selain
dari kelas yang memiliki atribut tersebut tidak dapat melihat
nilai dari atribut tersebut. Visibility
dengan nilai public artinya apapun (kelas manapun) dapat melihat
nilai dari atribut tersebut. OO menyediakan
suatu Visibility atribut dengan nilai protected, yang artinya kelas
turunan dari kelas tersebut dapat melihat nilai dari atribut-
-
nya tetapi kelas lain tidak.
Penggambaran protected visibility digambarkan dengan tanda
pagar (#) di samping atribut yang bersifat protected.
Gambar 37 Protected Visibility
Polymorphism
Kelas turunan dapat mendefinisikan kembali implementasi
dari method. Hal ini biasanya disebabkan karena dua buah kelas
turunan yang memiliki method turunan dari sebuah kelas basis
melakukan implementasi yang berbeda terhadap method tersebut.
-
Gambar 38 Polymorphism
The principle of substitutability
berhubungan erat dengan polymorphism. Prinsip ini mengatakan
bahwa jika method yang adadiharapkan dapat bekerja pada
sebuah kelas tertentu, ia dapat bekerja dengan baik padakelas
turunannya yang manapun.
Prinsip ini tidak mengijinkan kelas turunan untuk
menghapus method dari superclass-nya. Hal ini supaya tidak
terjadi kesalahan akibat keteledoran di dalam penggunaan
kelas.
Contoh kasus :
Method accelerate di atas bekerja dengan menggunakan parameter
dengan tipe Transport, dan melakukan percepatan dengan
menggunakan method move().
-
Method ini dapat dipanggil dengan aman dan memberikan sebuah
objek Car kepadanya (karena Car adalah subclass dari
Transport) ataupun sebuah objek Boat.
Jika suatu saat nanti, ada sebuah kelas turunan baru dari
Transport dengan nama Aeroplane, kelas Aeroplane ini
dapat diterima dengan baik tanpa modifikasi
terhadapmethod Accelerate!
Oleh karena alasan inilah sebuah kelas turunan tidak
dapat menghapus method darisuperclass-nya. Jika diijinkan, mungkin
saja kelas turunan Aeroplane dapat menghapus
method move() dan semua kelebihan yang didapat diatas
menjadi hilang.
Abstract Classes
Seringkali di dalam perancangan, diperlukan untuk meninggalkan sebuah method tanpa di-
implementasikandan membiarkan implementasi dilakukan oleh kelas yang berada di
bagian bawah pohon hierarki inheritance.
Notasi penulisan method dengan sifat seperti itu dilakukan
dengan memiringkan (italic) nama dari method dan kelas. Kelas
yang memiliki method seperti itu disebut
abstract class. Notasi lain yang dipergunakan untuk
menggambarkan abstract class adalah dengan menambahkan
di bawah nama kelas. Notasi ini diperkenalkan
karena seringkalihuruf miring (italic) sulit untuk dikenali pada
sebuah diagram kelas. Pemberian atribut tambahan
disebut stereotyping (
adalah stereotype).
-
Gambar 39 Abstract Class
Gambar 40 Abstract Class (Stereotype)
System Architechture
Ada beberapa masalah yang dihadapi oleh pengembang perangkat lunak
ketika menghadapi pengembangan sistem yang bersifat besar dan lebih kompleks.
Untuk menjawab permasalahan itu, UML memberikan beberapa tools yang
-
dapat berguna di dalam pengembangan.
Package Diagram
Semua
artefak
UML dapat disusun ke dalam UML Packages. Package secara mendasar
adalah sebuah kontainer
logika untuk elemen elemen yang saling berhubungan.
Sebuah package dapat berisi package lain sehingga pada akhirnya akan
membentuk hierarki.
Di dalam UML, dapat juga digambarkan sekumpulan packages dimana ada
hubungan
beberapa packagetersebut.
Gambar 41 Relasi antar package
Contoh di atas adalah model klasik dari three tier model di dalam
pengembangan perangkat lunak. Benda yang berada di
dalam package Presentation bergantung pada benda yang berada di
dalam package Business.
Meskipun semua artefak UML dapat ditaruh di dalam package,
penggunaan package yang paling umum adalah untuk
menaruh sekelompok kelas yang saling berhubungan. Penamaan kelas dari
setiappackage
harus unik. Namun penamaan kelas dari package yang berbeda
tidak bermasalah meskipun memiliki nama kelas yang sama.
Keuntungan dari melakukan packaging adalah :
-
Pengelompokan sistem yang besar ke dalam subsistem yang lebih mudah dikelola.
Memungkinkan iterative pengembangan secara parallel.
Keuntungan lain dari packaging adalah jika desain dari
sebuah package dilakukan dengan baik dan packagetersebut memiliki antarmuka yang
jelas untuk digunakan antar package, konsep code reuse dapat
dimaksimalkan. Class reuse (penggunaan ulang kelas) adalah sesuatu yang sulit
untuk dilakukan dikarenakan kelas memiliki jangkauan yang sempit dan sulit
untuk digunakan kembali (dengan kata lainabstraksi kelas rendah). Berbeda
dengan package, dengan perancangan yang baik sebuah package dapat
menjadi solid dan menjadi sebuah komponen perangkat lunak yang dapat
digunakan kembali (memilikiabstraksi yang tinggi).
Ada 3 hal heuristik
dari GRASP yang dapat diaplikasikan kepada packaging :
Expert : package manakah sebuah kelas harus ditaruh?
High Cohesion : sebuah package tidak boleh melakukan terlalu banyak hal
Loose Coupling : ketergantungan antar package harus seminimal mungkin.
Package Communication
Komunikasi antara 2 package dapat dilakukan sesuai dengan
pola faade (faade pattern). Pola ini memberikan sebuah kelas diantara 2
buah package yang hendak berkomunikasi, sehingga kedua packageyang akan
berkomunikasi harus melalui kelas ini (yang disebut kelas faade).
-
Gambar 42 Komunikasi tanpa kelas facade
Gambar 43 Komunikasi dengan kelas facade
Architechture Centric Development
Proses pembangunan perangkat lunak RUP (Rational Unified
Process) menyarankan konsep pengembangan dengan arsitektur terpusat.
Dengan kata lain,
sistem dirancang sebagaikumpulan dari subsistem mulai dari
tahapan yang sangat awal dari pengembangan.
Dengan membuat sekumpulan kecil subsistem yang mudah dikelola,
sebuah tim pengembang yang terdiri dari 3 4 orang dapat
dialokasikan terhadap setiap subsistem. Subsistem tersebut
-
dapat dikerjakan parallel tanpa bergantung satu sama lain.
Tim architecture akan melakukan pengelolaan terhadap antarmuka
(faade) di antara subsistem. Meskipun pada saat pengembangan
proyek nanti diperlukan perubahan pada faade, yang akan
melakukan modifikasi adalah tim architectural bukan tim pengembang
yang bekerja pada subsistem individual.
Dikarenakan tim architecture mengelola pandangan tingkat tinggi
dari sistem, mereka harusmemahami akibat
dari modifikasi antar interface yang dimiliki oleh subsistem.
Menangani Use Case Besar
Salah satu permasalahan yang muncul dari pengembangan dengan
skala besar adalah use caseyang pertama
sekali dibuat biasanya terlampau besar untuk dikembangkan dalam
satu kali iterasi. Solusi yang
diberikan bukanlah membuat masa iterasi lebih panjang, melainkan
memecah use case menjadi sekumpulan versi yang lebih kecil dan
mudah di-kelola.
Untuk setiap iterasi, tim terpisah dapat mengerjakan subsistem terpisah secara paralel.
Pada akhir dari iterasi, tahapan integrasi akan dilakukan, dan pengujian terhadap
antarmuka subsistem akan dilakukan.
Kesimpulan :
Rational Corp memberikan sebuah pendekatan terbaik untuk
pendekatan secara arsitektur terpusat (architecture centric approach),
yaitu :
Definisikan subsistem dari tahap awal
Jaga kompleksitas supaya tetap dapat diatur
-
Iterasi secara parallel tetapi jangan hack interface
Tunjuk sebuah tim arsitektural
Fase Pengkodean
Salah satu masalah kunci dari perancangan dan koding adalah
untuk menjaga model tetap konsistendengan kode. Untuk melakukan hal
ini, salah satu pendekatan yang dapat dilakukan adalah dengan
menambahkan sebuah tahapan tambahan
pada iterasi, yaitu tahapan sinkronisasi. Tahapan ini berfungsi
untuk melakukan sinkronisasi artefak. Disini
model diubah untuk menggambarkan keputusan perancangan yang telah
dibuat saatmelakukan koding di iterasi sebelumnya.
Gambar 44 Tahapan perancangan
-
Pemetaan
perancangan ke kode
[Class Diagram] Class to Code
Definisi kelas yang dikodekan akan diturunkan dari kelas diagram
perancangan. Definisi
method akan berasal dari collaboration diagram, bantuan lainnya
berasal dari use case description (detil tambahan, khususnya
pada exception/alternate flows)dan state chart (menangkap
kondisi error).
Pemetaan 1 : Class Model Class
Gambar 45 Class Model
Gambar 46 Class Code
Langkah Pemetaan :
Tambahkan constructor untuk setiap kelas yang dibuat
-
Petakan atribut dan method yang ada di dalam class diagram
Pemetaan 2 : Contain Relationship
Gambar 47 Contain Relationship
Gambar 48 Code
Pemetaan 3 : Pendefinisian Method
Gambar 49 Method (Message Passing)
-
Gambar 50 Code Method
Gambar 51 Code Method
[Package] Package to Code
Java
Java memiliki
dukungan langsung terhadap package. Baris pertama dari deklarasi
kelas pada java harus mengatakan pada Java di package manakah kelas
tersebut berada. (Jika tidak ada, Java akan menganggap kelas
berada pada package default).
Java juga memiliki fitur package protection. Kelas (bersama
dengan method dan atributnya) hanya dapat dilihat oleh kelas yang
berada pada package yang sama. Ini memberikan dukungan yang
sempurna untuk enkapsulasi di dalam package. Dengan membuat semua
kelas hanya dapat dilihat oleh kelas di dalam
satu package (kecuali kelas faade), subsistem (atau package) dapat
dikembangkan secara bebas (independent). Meskipun sintaks yang
dimiliki java untuk fitur ini tidak terlalu baik, yaitu hanya
melakukan deklarasi kelas tanpa kata kunci public,
protected, atau private di depan kata kunci kelas.
-
C++
C++ ti dak memiliki dukungan langsung terhadap package, tetapi
C++ memiliki konsep yang disebut sebagai namespace. Ini
memungkinkan kelas untuk ditaruh pada partisi logikaterpisah,
untuk menghindari tubrukan nama kelas di antara namespaces.
Meski ia memberikan beberapa dukungan dari packages, sayangnya ia
tidak memberikanperlindungan dari visibilities. Kelas yang berasal
dari sebuah namespaces dapat mengakses seluruh
kelas publik yang terdapat
di namespaces lain.
Component Model
UML menyediakan sebuah notasi yang dapat dipergunakan untuk memodelkan
komponen perangkat lunak yang bersifat fisik dan keras (bukan kode, cth
: file). Notasi ini menggunakan notasi yang samadengan package diagram. Ia
memodelkan ketergantungan antara entitas fisik perangkat lunak seperti
:executeable file, dynamic link library, object file, source file, dll).
Gambar 52 Notasi UML untuk Component Model
-
1. Tahapan Transition
Setelah melewati tahapan construction, maka berakhirlah tugas UML. Setelah mencapai tahapan ini, sebuah sistem yang berjalan sesuai dengan spesifikasi telah didapatkan. Tahap transition berkaitan dengan prosedur prosedur yang diperlukan untuk melakukan deliverable dari sistem yang telah dihasilkan.