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.
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.
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.
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
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.
2.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.
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.
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.
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.
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.
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 : “ 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 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++ tidak 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.
Sumber :
http://fandimin.blogspot.com/2011/12/komponen-uml-unified-modeling-language.html#ixzz1lC8XMrzD
- Follow Us on Twitter!
- "Join Us on Facebook!
- RSS
Contact