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.