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 estimasi mengenai 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 dokumen use 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 tetapi hanya pada suatu batasan tertentu.

1. Diagram Class (Conceptual Model)
   
   Conceptual Modeling (disebut juga Domain Modeling) adalah aktivitas untuk menemukan konsep yang 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 perbedaan dengan 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 doesn’t understand the concept, it probably isn’t 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 pertama mengartikan “banyak” secara kabur, mungkin banyak konsep yang diijinkan ataupun belum dibuat keputusan yang pantas. Yang terakhir mengartikan “banyak” yang lebih konkret, 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 relasi tersebut.

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 saling berhubungan 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 adalah memahami 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, user dianggap memberikan masukan (input) sesuai dengan harapan (kondisi ideal). Interaksi antara user dengan sistem dijelaskan secara mendetil disini. Kondisi akhir dari main flow adalah post condition.
  
• Alternate Flow(s)
  
  Alternate flow adalah aliran proses yang akan dijalankan (dibangkitkan) jika terjadi hal – hal di luar dugaan pada
  main flow. Pada alternate flow, mungkin terjadi perubahan post condition. Perubahan pada post condition, ditandai dengan :
  
  
  Post Conditions à(Post Condition baru).
  
• Exception Flow(s)
  
  Exception Flow adalah aliran proses yang akan dijalankan (dibangkitkan) jika terjadi hal – 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 pencampuran antara 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 akibat sulitnya 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 gambar actor.

• 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 atas 2 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 dengan menggunakan kolaborasi dari objek yang berbeda. Collaboration Diagram dipergunakan untuk menjelaskan
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. Pembuatan Sequence 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 pada conceptual 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 – langkah pembuatannya 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) disebut substate.
  
  
  

Gambar 29 Nesting State

Terkadang sebuah superstate dapat mengalami interupsi. Adalah memungkinkan untuk menggambarkan 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 sebuah state
  berubah (bertransisi) menjadi state yang memiliki keterangan entry. Keadaan akhir (disebut exit) 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 atau merancang
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 baik konsekuensinya!“

The Law of Demeter

Hukum ini, dikenal juga sebagai : “Don’t Talk to Strangers“, adalah sebuah metode yang efektif untuk memerangi coupling. Hukum ini menyatakan bahwa setiap objek hanya boleh memanggil method yang 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 constants dari 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 dan memiliki terlalu banyak pekerjaan. Biasanya berakhir dengan sistem yang memiliki sedikit “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 dari conceptual 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 konvensi sebagai 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 disebut derived 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 menggunakan inheritance“.

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 diaplikasikan secara 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 dimiliki valid. Aturan ini mengatakan bahwa sebuah frase dengan format : “<derived class> is a <base class>” 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 kelas turunan 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, visibility dari 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 ada diharapkan dapat “bekerja” pada sebuah kelas tertentu, ia dapat bekerja dengan baik pada kelas 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 terhadap method Accelerate!

Oleh karena alasan inilah sebuah kelas turunan tidak dapat menghapus method dari superclass-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-implementasikan dan 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 seringkali huruf 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 package tersebut.

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 setiap package
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 package tersebut 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 lain abstraksi kelas rendah). Berbeda dengan package, dengan perancangan yang baik sebuah package dapat menjadi solid dan menjadi sebuah komponen perangkat lunak yang dapat digunakan kembali (memiliki abstraksi 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 façade (façade pattern). Pola ini memberikan sebuah kelas diantara 2 buah package yang hendak berkomunikasi, sehingga kedua package yang akan berkomunikasi harus melalui kelas ini (yang disebut kelas façade).

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 sebagai kumpulan 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 (façade) di antara subsistem. Meskipun pada saat pengembangan proyek nanti diperlukan perubahan pada façade, 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 harus memahami 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 case yang 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 konsisten dengan 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 saat melakukan 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 façade), 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 logika terpisah, untuk menghindari tubrukan nama kelas di antara namespaces.

Meski ia memberikan beberapa dukungan dari packages, sayangnya ia tidak memberikan perlindungan 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 sama dengan 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

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.

Tool Yang Mendukung UML
Saat ini banyak sekali tool perancangan perangkat lunak yang mendukung UML, baik itu tool komersial maupun opensource.  Secara lengkap dari tools UML yang open source kunjungi URL http://java-source.net/open-source/uml-modeling.
Tools UML yang open source diantaranya:

1. StarUML, merupakan piranti lunak untuk mengembangkan UML. Cepat, fleksibel, kaya fitur. Dapat running di platform Linux/Windows.
2. ArgoUML, cukup powerfull, mudah digunakan, interaktif, support dalam mendisain  UML.
3. UniMod, fokus pada desain dan implementasi application behavior. Didistribusikan di bawah lisensi Open Software v.2.1.
4. Alma, piranti lunak yang bekerja untuk modelling dan analyzing. Alma support untuk mendisain lingkungan piranti lunak berbasis GIS dan mendokumentasikan piranti lunak berorientasi obyek.
5. UMLet, menggambarkan UML berbasis open source pada tool Java. Mampu mentransfer diagram dalam bentuk SVG, JPG, PDF dan LaTeX. UMLet juga mampu memandu dalam pembuatan diagram secara ceat.
6. TOPCASED-UML2 (TOPCASED Modeling Framework Open Source Project)
7. Papyrus UML (Payrus Open Source Project)

Untuk tools UML yang komersial diantaranya:

• Rational Rose (www.rational.com)
• Together (www.togethersoft.com)
• Object Domain (www.objectdomain.com)
• Jvision (www.object-insight.com)
• Objecteering (www.objecteering.com)
• MagicDraw (www.nomagic.com/magicdrawuml)
• Visual Object Modeller (www.visualobject.com)
• Enterprise Architect (Sparx Systems)
• UModel (Altova)
• Artisan Studio (Artisan Software)
• Rhapsody (IBM/Telelogic)
• TAU G2 (IBM/Telelogic)
• Visual Paradigm for UML (Visual Paradigm)
• Poseidon for UML (Gentleware)
• Together Architect / Designer /Developer (Borland)

Other UML tools
Data seluruh tool yang mendukung UML, bisa dipelajari di situs http://www.objectsbydesign.com/ tools/umltools_byCompany.html.
Disamping itu, daftar tool UML berikut fungsi dan perbandingan kemampuannya juga dapat dilihat di http://www.jeckle.de/umltools.htm.
Pointer Penting UML
Sebagai referensi dalam mempelajari dan menggunakan UML, situs-situs yang merupakan pointer penting adalah:

• http://www.cetus-links.org/oo_uml.html
• http://www.omg.org
• http://www.omg.org/technology/uml/
• http://www.rational.com/uml
• http://www.uml.org/