This is my World

Me Just Being Me

UML Analisis Perancangan Berorientasi Objek

1. Pengertian UML adalah bahasa grafis yang dipergunakan untuk menangkap artefak dari pengembangan perangkat lunak. Bahasa ini memberikan model notasi grafis. UML merupakan satu satunya bahasa yang dipergunakan secara luas oleh industry. Bahasa ini sangat kaya dan memiliki banyak aspek dari praktek terbaik rekayasa perangkat lunak. Meskipun begitu, UML sendiri hanyalah sebuah sintaks, sebuah alat, sebuah bahasa yang dapat dipergunakan untuk membangun perangkat lunak. Akan tetapi untuk membangun sebuah sistem yang kokoh (robust) dan mudah dirawat bergantung pada prinsip prinsip perancangan (bukan UML) yang didapat dari pengalaman. UML menggunakan proses pembangunan perangkat lunak IIF (Iterative, Incremental Framework) dengan 4 tahapan : Inception, Elaboration, Construction, dan Transition. Tahapan construction terdiri dari 4 bagian, yaitu : analisis, perancangan, implementasi, pengujian.

2. Ciri ciri UML UML bersifat generik: UML tidak mengandung hal hal yang berhubungan dengan proses. Sebuah proses untuk perusahaan A mungkin sangat berbeda dengan proses pada perusahaan B.

3. Komponen UML

UML memiliki berbagai jenis diagram (model) yang berhubungan dengan stake holder pada sebuah pembangunan perangkat lunak. Stake holder tersebut adalah :

Analis Disainer Koder Tester QA Pelanggan Penulis teknis

Berbagai jenis diagram UML tersebut adalah :

Use case diagram

How will our system interact with the outside world?

Mendeskripsikan kelakuan sistem dari sudut pandang pengguna, berguna untuk membantu memahami kebutuhan. Use case adalah dasar dari diagram lain.

Class Diagram

What objects do we need? How will they be related?

Dapat dipergunakan pada tingkatan analisis maupun perancangan. Diagram kelas pada tingkatan analisis disebut model konseptual.

Collaboration Diagram

How will the objects interact?

Diagram kolaborasi (Collaboration Diagram) menggambarkan kolaborasi (kerja sama) yang dilakukan oleh kelas kelas pada sistem.

Sequence Diagram

How will the objects interact?

Sequence Diagram menggambarkan bagaimana objek objek di dalam sistem berinteraksi seiring dengan waktu. Ia menampilkan informasi yang sama dengan Diagram Kolaborasi (Collaboration Diagram), hanya dengan bentuk yang berbeda.

State Diagram What states should our objects be in? Menggambarkan keadaan objek pada suatu waktu di dalam sistem kita.

Package Diagram How are we going to modularize our development? Package Diagram membagi sistem ke dalam bagan yang lebih kecil dan lebih mudah dimengerti.

Component Diagram

How will our software components be related?

Component Diagram

mirip dengan Package Diagram, ia menotasikan pembagian sistem dan hubungan antar modul. Akan tetapi,Component Diagram lebih menekankan komponen perangkat lunak (file, header, link libraries, executeable, package) daripada pembagian logika seperti pada Package Diagram.

Deployment Diagram

How will the software be deployed?

Memberikan gambaran terhadap bagaimana rencana untuk melakukan deploy dari perangkat lunak yang telah dibangun.

1. Tahapan Inception

Pada tahapan inception, UML tidak digunakan. Aktivitas utama dari tahapan ini adalah :

Menentukan tujuan dari product Membuat business case Mendefinisikan jangkauan dari proyek Menentukan biaya keseluruhan dari proyek

Salah satu contoh hasil dari tahapan ini adalah business plan.

1. Tahapan Elaboration

Pada tahapan ini, permasalahan yang diutamakan adalah pendetilan masalah (bukan pendetilan implementasi), memahami kebutuhan pelanggan dan bisnisnya, serta mengembangkan rencana ke tingkatan yang lebih lanjut.

Aktivitas utama pada tahapan ini adalah menanggulangi resiko. Semakin cepat sebuah resiko diketahui dan ditanggulangi, semakin kecil akibat yang diakibatkannya terhadap proyek. Melakukan pemodelan terhadap area yang sulit atau bermasalah dari proyek memberikan bantuan yang besar terhadap penanggulangan resiko.

UML pada Tahap Elaboration

Ada 2 model UML yang dipergunakan pada tahapan ini untuk membantu memahami masalah secara keseluruhan, yaitu : Use Case Model dan Diagram Class(Conceptual Model).

Gambar 1 dua model UML pada tahap Elaboration 1. Short Use Case Diagram Use Case Model berfungsi untuk mendeskripsikan interaksi antara user dan sistem. Tujuan dari tahapan elaboration menemukan sebanyak mugkin use case yang ada tanpa perlu memberikan detil penuh terhadap setiap use case. Use case tersebut akan dikembangkan lebih lanjut pada tahapan construction.Untuk use case yang memiliki resiko, adalah hal yang baik untuk melakukan pendetilan terhadapnya dan melakukan penanggulangan resiko. Finding Use Case

Ada beberapa pendekatan yang dapat dilakukan untuk menemukan use case. Salah satunya adalah dengan melakukan wawancara terhadap pengguna potensial dari sistem. Ini adalah tugas yang sangat sulit. Dari 2 orang yang berbeda mungkin saja didapatkan pandangan yang benar benar berbeda dengan apa yang harus dilakukan oleh sistem (bahkan jika mereka bekerja di bawah organisasi yang sama). Pendekatan lain yang lebih popular adalah workshop. Pendekatan ini disebut Joint Requirements Plannin Workshops (JRP). Workshop ini mengumpulkan sekumpulan orang yang tertarik pada sistem yang sedang dikembangkan (disebut juga stakeholder) untuk mencari tahu pandangan mereka tentang apa yang perlu dilakukan oleh sistem. Kunci kesuksesan terletak pada fasilitator. Mereka memimpin kelompok tersebut untuk memastikan bahwa diskusi tetap berjalan sesuai dengan topiknya dan semua stakeholder memberikan tanggapannya.Seorang juru tulis juga diperlukan untuk mencatat dokumentasi tentang jalannya workshop. Use Case berperan penting disini, kesederhanaannya memberikan kemampuan kepada stakeholder yang sekalipun gagap teknologi, dapat menangkap konsep dari diagram dengan mudah. Suatu metode yang sederhana untuk menyukseskan workshop adalah :

Brainstorm semua actor yang memungkinkan terlebih dahulu. Brainstorm semua use case yang memungkinkan. Selesai brainstorming, lakukan justifikasi terhadap use case dengan menggunakan grup.Deskripsikan setiap use case dengan 1 baris / paragraf sederhana. Jika use case tidak dapat dideskripsikan, besar kemungkinan ia bukanlah use case. Tuangkan dalam bentuk model.

NB : Jangan memaksakan diri untuk menemukan semua use case dan actor. Adalah hal yang lumrah untuk menambahkan use case dan actor kemudian. NB : Setiap langkah tidak harus benar 100%! Sebuah formula untuk menentukan jumlah use case : Apa yang masuk ke dalam sistem adalah jumlah dari keseluruhan use case. Komponen Use Case Ada 2 komponen Use Case Model, yaitu : Use Case dan Actor.

1. Use Case

Gambar 2 Notasi Use Case Ciri ciri :

Use Case dideskripsikan menggunakan kombinasi kata kerja dan kata benda. Use Case tidak dapat di-inisiasi oleh dirinyya sendiri.

1. Actor

Gambar 3 Notasi Actor

Ciri ciri :

Actor dideskripsikan menggunakan kata benda. Dapat (bukan harus) melakukan inisiasi terhadap use case. Actor tidak harus orang, dapat saja sistem, atau entitas yang berhubungan dengan sistem tetapi berasal dari luar sistem. 1 Actor dapat berinteraksi dengan beberapa use case.

Tujuan dari Use Case Model

Meski Use Case terlihat sederhana akan tetapi ia merupakan komponen yang penting di dalam UML. Berikut adalah kegunaan dari Use Case :

Mendefinisikan jangkauan dari sistem. Memberikan fokus yang lebih baik kepada kebutuhan (requirement) sistem (sebab biasanya kebutuhan sistem cenderung kabur, membingungkan, ambigu, dan ditulis dengan buruk). Gabungan dari seluruh Use Case adalah sistem secara keseluruhan. Memungkinkan komunikasi antara pelanggan dan pengembang. Menuntun tim pengembang melalui proses pengembangan. Use Case adalah Backbone. Memberikan sebuah metode untuk merencanakan kerja pengembangan dan memungkinkan estimasimengenai lama pengembangan. Memberikan basis untuk melakukan pengujian sistem. Membantu pembuatan user guide.

Use Case Granularity Granularity berbicara tentang sebesar apakah isi dari sebuah use case? Apakah setiap interaksi pengguna ke sistem harus dituangkan ke dalam sebuah use case atau seluruh interaksi tersebut dibungkus di dalam sebuah use case? Kesalahan utama di dalam use case adalah seringkali pengembang membuat sejumlah besar use case kecil dan tidak relevan. Pada sistem yang besar, mungkin saja berakhir dengan jumlah use case yang tidak logis dan menyebabkan kompleksitas meningkat pesat. Ada hal yang harus diingat mengenai pembuatan use case : Sebuah use case harus memenuhi tujuan akhir dari actor. Contoh : pada kasus mesin ATM, apakah tujuan akhir dari user adalah memasukkan kartu/pin, atau mengambil receipt? Tidak, sehingga tidak perlu membuat use case untuk hal tersebut. Hal yang diperlukan oleh user adalah mengambil uang. Sehingga cukup menggunakan sebuah use case itu saja, meski di dalamnya ada aktivitas seperti memasukkan kartu/pin, dsb. Use Case Description Setiap use case memiliki sekumpulan penuh penjelasan detil tertulis mengenai interaksi dan skenario di

dalamnya. Berikut adalah template yang digunakan untuk men-spesifikasikan struktur dan isi dari dokumenuse case description :

Gambar 4 Use Case Description Template Untuk Short use case, bagian yang harus diisi adalah : nama use case, deskripsi singkat, actor (dapat ditambahkan pada template di atas), dan requirement yang dipenuhinya (dapat ditambahkan pada template di atas). Ranking Use Case Pada saat melakukan tahapan construction, use case yang telah dibuat disini akan mengalami iterasi berulang kali. Untuk membagi use case ke dalam pekerjaan iterasi yang ada, use case dialokasikan menggunakan tingkatan (rank). Secara mudah, tingkatan adalah angka yang menunjukkan use case yang akan dikembangkan. Pengalaman yang akan menentukan use case manakah yang akan memiliki tingkatan lebih tinggi. Ada 6 jenis tingkatan secara umum :

Risky use cases Major Architechtural Use cases Use cases exercising large areas of system functionality Use Cases requiring extensive research, or new technologies. Quick wins Large Payoffs for the customer

Sebuah use case mungkin saja mengalami beberapa kali proses iterasi, pecah use case tersebut ke dalam beberapa versi. Pada akhir setiap iterasi, use case tersebut masih dapat melakukan sesuatu tetapihanya pada suatu batasan tertentu. 1. Diagram Class (Conceptual Model) Conceptual Modeling (disebut juga Domain Modeling) adalah aktivitas untuk menemukan konsepyang penting untuk sistem. Proses ini membantu

untuk memahami masalah lebih lanjut, dan mengembangkan pemahaman lebih mendalam tentang keperluan pelanggan. Untuk melakukan hal ini (menemukan konsep), dipergunakan sintaks UML yaitu class diagram. Catatan pada tahap ini adalah : jangan melakukan perancangan sistem, tahapan yang dilakukan masih analisis. Class Diagram yang telah dihasilkan pada tahapan ini tidak berhubungan dengan tahapan construction (Tidak melakukan perancangan sistem). Oleh karenanya,class diagram pada tahapan ini lebih sering disebut conceptual model untuk memberikan perbedaandengan class diagram sesungguhnya pada tahapan construction. Mulai saat ini class diagram pada tahapan ini akan disebut sebagai conceptual model. Conceptual model tidak boleh berhubungan dengan perancangan (design), seperti : database, daemon process, form, trigger, event, dsb. If the customer doesnt understand the concept, it probably isnt concept at all. Finding Concept Salah satu cara terbaik untuk menemukan konsep adalah dengan melakukan hal yang sama pada saat mencari use case, yaitu workshop dan brainstorming. Cara lain adalah dengan mencari konsep melalui dokumen kebutuhan (requirement). Beberapa kandidat konsep yang mungkin dapat diambil dari requirement adalah :

Objek fisik atau nyata. Tempat Transaksi Tugas (pelanggan, sales, dll) Container untuk konsep lain. Sistem lain (eksternal) Kata benda abstrak Organisasi Kejadian Aturan Catatan

Cara kedua untuk mencari konsep dari dokumen requirement adalah dengan mencari kata benda di dalam dokumen tersebut. Meskipun cara untuk mencari konsep dari dokumen requirement ini cukup sering dipakai, tetapi input dari pelanggan adalah penting!.

Conceptual Model

Ada 2 komponen di dalam conceptual Model, yaitu : Concept Box dan Association.

1. Concept Box

Gambar 5 Concept Box (Similar to Class) Concept ditampilkan pada sebuah kotak sederhana dengan judul dari konsep (dalam huruf besar secara konvensi) pada baris teratas kotak. Di dalam kotak yang besar terdapat 2 kotak yang lebih kecil. Kotak pertama (yang berada di tengah) digunakan untuk atribut dari konsep.Kotak kedua (yang berada di bawah) digunakan untuk kelakuan dari konsep.

NB : Pada conceptual model kelakuan tidak diisi (belum didefinisikan). Kelakuan baru didefinisikan pada tahapan construction saat membuat class diagram. Finding Attribute

Hal yang seringkali dipermasalahkan adalah apakah sebuah atribut seharusnya adalah konsep? Sebuah saran yang cukup baik untuk masalah ini adalah : jika ragu, jadikanlah atribut tersebut sebagai konsep, waktu akan menyelesaikannya nanti. Ada beberapa hal yang dapat membantu untuk menentukan atribut :

Nilai tunggal (string atau angka) biasanya adalah atribut Jika sebuah property dari konsep tidak dapat melakukan apapun, kemungkinan ia adalah atribut.

1. Association

Asosiasi berfungsi untuk mendeskripsikan bagaimana 2 buah konsep berhubungan. Di dalam setiap hubungan tersebut ada yang disebut sebagai kardinalitas. Kardinalitas memberitahu berapa banyak instans yang diijinkan untuk setiap konsep.

Gambar 6 Contoh Kardinalitas Notasi * berarti banyak. Ada sedikit perbedaan pada * dan 1..*. Yang pertamamengartikan banyak secara kabur, mungkin banyak konsep yang diijinkan ataupunbelum dibuat keputusan yang pantas. Yang terakhir mengartikan banyak yang lebihkonkret, satu atau lebih dari satu diijinkan. Untuk setiap asosiasi yang telah dibuat, diberikan nama di atas garis (yang menyatakan asosiasi tersebut). Nama tersebut sesuai dengan arti dari relasitersebut. Building the complete model

Setelah sesi brainstorming selesai, akan didapat sekumpulan concept dengan atribut. Untuk menemukan relasi antara 2 konsep hal terbaik adalah dengan menanyakan apakah kedua konsep tersebut salingberhubungan atau tidak. Kesalahan yang mungkin terjadi pada tahap ini biasanya adalah :

Pemutusan bahwa 2 konsep berhubungan

Pembuatan garis diagram dan tidak ada nama yang diberikan

Saat membangun model adalah penting untuk mengingat bahwa asosiasi tidak lebih penting daripada atribut. Setiap asosiasi yang kurang dapat dengan mudah ditambahkan kemudian, tetapi adalah jauh lebih susah untuk mencari atribut yang hilang. Pada akhirnya, sebuah diagram harus masuk akal ketika pelanggan membaca kembali diagram tersebut dalam kalimat biasa.

1. Tahapan Construction Pada tahapan construction, produk dibangun, sistem dibawa pada keadaan dimana ia siap diantarkan kepada komunitas pengguna. Strategi pada tahapan ini adalah sekumpulan proses waterfall pendek, dengan sekumpulan kecil use case yang dikembangkan pada setiap iterasi. Secara ideal, pada akhir iterasi diharapkan sebuah sistem yang dapat berjalan meski terbatas. Setiap tahapan iterasi waterfall akan memiliki sekumpulan dokumen UML :

Pada analisis, akan dihasilkan beberapa use case (yang penuh ataupun diperluas) Pada perancangan, akan dihasilkan class diagram, interaction models, dan state diagrams. Pada pengkodean, akan dihasilkan kode yang telah diuji dan dijalankan.

Fase Analisis Pada tahapan ini, meski telah berada tahapan construction, akan tetapi kita masih berada pada tahapan analisis. Yang harus kita perhatikan bukanlah solusi, melainkan masalah. Tujuan utama dari fase ini adalahmemahami masalah dengan lebih mendalam. Short use case yang telah dibuat pada tahapan elaboration akan dikembangkan kembali di tahapan ini untuk diberikan detil secara penuh.

Gambar 7 Use Case Description Template Pada bagian ini, short use case telah memberikan detil terhadap bagian use case dan short description (serta dengan tambahan actor dan requirement jika diperlukan). 5 bagian lain belum diisi. Berikut adalah keterangan untuk kelima bagian tersebut.

Pre-Conditions Bagian ini menjelaskan kondisi yang harus dipenuhi sebelum use case dapat berjalan. Bagian pre conditions harus bukan sebuah proses yang termasuk di dalam use case. Contoh : jika ada sebuah pre condition : user telah berhasil login, artinya proses validasi user tidak termasuk di dalam use case tersebut.

Post-Conditions Bagian ini menjelaskan kondisi sistem pada akhir use case. Harus ada proses di dalam use case yang memberikan hasil ini. Kondisi akhir ini dapat menggunakan syarat perbandingan if-then (jika maka).

The Use Case Flow Ada 3 Flow utama dari use case, Flow dimulai dari main flow dan berpindah ke flow lain jika diperlukan. Perpindahan ke alternate flow ditandai dengan [An] dengan n adalah nomor urut Alternate Flow. Perpindahan ke exception flow ditandai dengan [En] dengan n adalah nomor urut Exception Flow.

Gambar 8 Full Use Case Description

Berikut adalah penjelasan aliran proses pada sebuah Use Case :

Main Flow Aliran ini menjelaskan proses use case jika tidak terjadi hal hal di luar dugaan. Pada aliran proses ini, userdianggap memberikan masukan (input) sesuai dengan harapan (kondisi ideal). Interaksiantara user dengan sistem dijelaskan secara mendetil disini. Kondisi akhir darimain flow adalah post condition.

Alternate Flow(s) Alternate flow adalah aliran proses yang akan dijalankan (dibangkitkan) jika terjadihal hal di luar dugaan pada main flow. Pada alternate flow, mungkin terjadi perubahan post condition. Perubahan padapost condition, ditandai dengan :

Post Conditions (Post Condition baru).

Exception Flow(s) Exception Flow adalah aliran proses yang akan dijalankan (dibangkitkan) jika terjadihal hal yang tidak diinginkan ataupun hal hal yang tidak diduga sebelumnya. Pada kode program, bagian ini dipetakan ke bagian penanganan exception (seperti pada C++, Java, Ada, Delphi, dan bahasa pemrograman lainnya). Biasanya akan mengakhiri proses use case seketika.

Pada saat menulis proses dari aliran proses sebuah use case, seringkali terjadi pencampuranantara analisis dan perancangan (disain). Contohnya : di dalam aliran proses seringkali disebutkan bagaimana sistem mengakses dan memodifikasi database, pemindahan data data di dalam sebuah array, dsb (yang seharusnya tidak boleh). Hal ini mungkin terjadi akibatsulitnya menemukan kata kata yang tepat untuk menggambarkan keadaan yang diinginkan oleh pengembang saat menuliskan aliran proses. Untuk menanggulangi masalah ini dapat digunakan sequence diagram untuk membantu (bukan menggantikan) menjelaskan aliran proses dari use case..

Sequence diagram dapat dipergunakan pada tahapan analisis maupun perancangan (disain). Untuk tahap analisis,sistem dianggap sebagai sebuah kotak hitam (black box). Sequence Diagram dapat dipergunakan hanya untuk main flow, tidak perlu menggambarkan sequence diagram untuk alternate flow dan exception flow kecuali jika benar benar kompleks atau menarik. Ada 4 komponen dari sequence diagram yang akan dipergunakan pada tahapan analisis :

Actor

Gambar 9 Actor

Actor berada pada sisi kiri dari diagram. Nama dari actor berada di bagian bawah dari gambaractor.

System Box

Gambar 10 System Box System box berada pada sisi kanan dari diagram. Keseluruhan sistem direpresentasikan sebagai sebuah kotak dan diberi nama sistem (ataupun nama dari sistem).

Timelines

Gambar 11 Timeline

Sebuah garis lurus vertikal ditambahkan di bawah actor dan system box untuk menggambarkan aliran waktu.

Interactions

Gambar 12 Interaction

Interaksi antara user dengan sistem digambarkan dengan garis dan panah antara user dengan sistem. Kotak yang tergambar di garis timeline menyatakan waktu yang dihabiskan oleh satu sekuen dari proses. Nama dari interaksi yang terjadi di tulis diatas garis dan mendeskripsikan jenis interaksi yang terjadi.

Berikut adalah contoh dari sequence diagram :

Gambar 13 Contoh Sequence Diagram

Fase Perancangan Pada fase ini seharusnya permasalahan telah dapat dimengerti sepenuhnya (untuk iterasi ini). Perancangan akan memulai pembuatan solusi untuk masalah. Pada tahapan ini ada 3 hal yang harus diperhatikan :

Objek apa saja yang diperlukan oleh sistem Objek yang mana yang bertanggung jawab untuk memenuhi kebutuhan Waktu untuk objek berinteraksi

Untuk menggambarkan interaksi antar objek, digunakan Interaksi diagram. Interaksi diagram terdiri atas2 jenis diagram yang saling berelasi, yaitu : sequence diagram dan collaboration diagram. Setelah objek objek yang diperlukan telah dimiliki, sebuah class diagram dipergunakan untuk menangkap informasi bagaimana kelas kelas saling berelasi. Akhirnya, sebuah model lain dipergunakan untuk memberikan penjelasan tentang state dari setiap objek yang disebut dengan state diagram atau state model. Karena pada tahapan ini telah memulai pembuatan solusi maka pada tahapan ini akan mulai dibicarakan tentang pemrograman (pseudo-code, code), basisdata, struktur data, dan berbagai hal lain yang berhubungan dengan perangkat lunak. Pada fase perancangan ini, ada 3 tipe model yang akan dihasilkan : interaction diagram, class diagram, dan state diagram. Interaction Diagram Collaboration Diagram Use case yang telah didapatkan pada tahapan sebelumnya, tugasnya akan dijelaskan denganmenggunakan kolaborasi dari objek yang berbeda. Collaboration Diagram dipergunakan untukmenjelaskan kolaborasi dari objek objek yang ada untuk memenuhi sebuah use case. Collaboration Diagram memiliki sintaks berikut :

Class Kelas di dalam collaboration diagram memiliki notasi seperti berikut :

Gambar 14 Notasi Kelas

Objek Ada 2 jenis objek yang dimodelkan di collaboration diagram, yaitu : objek biasa (instan dari sebuah kelas) dan objek dengan penamaan (nama dari objek) atau objek bernama.

Gambar 15 Notasi Objek Biasa

Gambar 16 Notasi Objek Bernama Di dalam collaboration diagram kumpulan (stack) objek dimodelkan dengan notasi berikut :

Gambar 17 Notasi Kumpulan (Stack) Objek

Objek Communication Untuk menggambarkan komunikasi antar 2 objek, dinotasikan sebagai berikut :

Gambar 18 Notasi Komunikasi Objek

Message Passing and Numbering Antara 2 objek yang berkomunikasi, komunikasi tersebut terjadi dengan melakukan pertukaran pesan (message passing). Ada 3 jenis pesan yang dapat dikirimkan ketika 2 objek berkomunikasi, yaitu : pesan biasa, pesan dengan parameter, pesan dengan nilai kembalian.

Gambar 19 Notasi Pesan Biasa

Gambar 20 Notasi Pesan dengan Parameter

Gambar 21 Notasi Pesan dengan nilai kembalian Angka yang berada di samping pesan yang dikirimkan menyatakan urutan pesan tersebut dieksekusi untuk memenuhi use case. Setiap penambahan pesan, nilai di samping pesan akan dinaikkan 1 (increment).

Looping Untuk menggambarkan terjadinya loop, dipergunakan notasi berikut :

Gambar 22 Notasi Looping (Perulangan) Tanda asterisk (*) pada pesan (message) menandakan bahwa pesan tersebut diulang.

Creating new object Untuk membuat objek baru, dipergunakan notasi berikut :

Gambar 23 Notasi Create Objek

Meskipun notasi ini memiliki sedikit keanehan, pesan dikirimkan kepada objek yang bahkan belum ada (belum di-create). Berikut adalah contoh dari sebuah collaboration diagram :

Gambar 24 Contoh Collaboration Diagram Darimanakah objek objek yang dipergunakan di dalam collaboration diagram di atas berasal?

Beberapa objek di atas adalah objek baru yang belum pernah dilihat, akan tetapi kebanyakan objek yang berada di dalam collaboration diagram adalah objek yang berasal dari conceptual model yang telah dibuat pada tahap elaboration.

Terkadang pada saat membuat collaboration diagram akan disadari bahwa ada association yang belum ditemukan (dibuat) pada tahap pembuatan conceptual model. Hal ini terkadang dapat mengganggu kebutuhan (requirement) dari pelanggan. Jika hal ini terjadi, tanyakan pada pelanggan terlebih dahulu.

Dengan membuat collaboration diagram, code yang akan diimplementasikan menjadi sistem tidak terpetakan dengan baik. Ada beberapa masalah yang belum terselesaikan melalui collaboration diagram, yaitu :

Input dan output (interface) antara user dengan sistem belum terdefinisi

Basis data dan jaringan belum terdefinisi disini Keputusan yang dibuat mengenai sebuah kelas belum terdefinisi dengan jelas.

Di dalam membuat collaboration diagram ada 4 hal yang harus dicatat :

Buat diagram sesederhana mungkin. Jika sebuah diagram menjadi sangat kompleks, cobalah untuk membuat diagram terpisah untuk setiap interaksi dengan user. Jangan berusaha untuk menjelaskan setiap scenario yang mungkin ada. Alternative flow adalah sesuatu yang jarang terjadi, tidak perlu disertakan di dalam diagram. Jangan membuat kelas dengan nama controller, handler, manager, atau driver. Hal ini membuat desain menjadi tidak berorientasi objek melainkan berorientasi aksi (action oriented). Hindari kelas dewa. Kelas dewa adalah sebuah kelas yang mengerjakan berbagai hal dan tidak banyak berkolaborasi dengan objek lain. Sebuah solusi OO yang baik adalah kelas kelas kecil yang saling bekerja sama untuk mencapai tujuannya.

Sequence Diagram Sequence Diagram memberikan informasi yang sama dengan Collaboration Diagram. PembuatanSequence Diagram pada tahapan ini sama dengan sequence diagram pada tahapan analisis yang dipergunakan saat menjelaskan aliran proses use case. Perbedaannya adalah pada bagian ini, sistem diperluas dengan objek objek yang sama seperti pada collaboration diagram. (NB : Hanya berbeda susunan bukan urutan, ditambah dengan penambahan timeline untuk mempermudah pembacaan diagram).

Class Diagram

Class Diagram yang dipergunakan disini memiliki notasi yang sama dengan conceptual model pada tahapan elaboration. Perbedaan class diagram pada tahapan ini dengan conceptual model (class diagram pada tahapan elaboration) adalah padaconceptual model tidak ada deskripsi kelakuan (fungsi dan prosedur) di dalamnya, semuanya hanya berpusat pada masalah pelanggan. Conceptual Model yang telah dibuat sebelumnya akan dikembangkan lebih lanjut pada tahapan ini untuk menjadi design class diagram yang sebenarnya. Dengan kata lain, sebuah diagram dimana dapat di-kode-kan. Pembuatan class diagram didasarkan pada conceptual model dan collaboration diagram. Perubahan ini cukup terstruktur dan mekanis, perubahan ini harusnya tidak terlalu susah. langkah langkahpembuatannya adalah sebagai berikut :

Penambahan operasi (kelakuan) Penambahan navigasi pesan (navigability) Perbaikan atribut Pemutusan Visibilitas Pembuatan agregasi NB : Jika agregasi sudah ditemukan pada tahapan conceptual model, boleh ditambahkan.

Pembuatan komposisi NB : Jika komposisi sudah ditemukan pada tahapan conceptual model, boleh ditambahkan.

NB : praktisi berpedapat bahwa agregasi dan komposisi bukanlah suatu hal yang baik. Relasi ini bersifat redundan (berulang ulang) dan harus dihilangkan. Meskipun begitu, agregasi tetaplah sebuah konsep OO. Ia tetap legal untuk dipergunakan. Agregasi dan komposisi dapat dimodelkan sebagai sebuah asosiasi dengan nama is composed from.

State Diagram

State Diagram berfungsi untuk memodelkan keadaan keadaan yang mungkin dimiliki oleh sebuah objek. Model ini memungkinkan untuk menangkap kejadian kejadian (event) yang penting dan efeknya setelah kejadian (event) tersebut. Sintaks dari diagram ini adalah sebagai berikut :

Start state Start State ini menggambarkan keadaan objek di awal pembuatannya.

Gambar 25 Notasi Start

End state End State ini menggambarkan keadaan objek dihancurkan.

Gambar 26 Notasi End

State Describer State describer dipergunakan untuk menuliskan keadaan dari objek.

Gambar 27 State Describer

State Transition Sebuah event dapat menyebabkan sebuah objek berubah state atau tetap pada statenya.Perubahan (transition) dari sebuah state ke state lainnya diakibatkan oleh sebuah event digambarkan oleh state transition. Event yang menyebabkan perubahan tersebut dituliskan di atas garis panah. State yang dihasilkan digambarkan di kotak event describer.

Gambar 28 State Transition

Sub/Superstate (Nesting States) Terkadang diperlukan penggambaran state di dalam sebuah state. Sebuah state yang lebih umum dipergunakan untuk menggambarkan komponen komponen state yang lebih kecil. State yang lebih umum disebut superstate. State yang lebih khusus (bagian dari superstate) disebutsubstate.

Gambar 29 Nesting State

Terkadang sebuah superstate dapat mengalami interupsi. Adalah memungkinkan untukmenggambarkan keadaan dimana saat sebuah superstate melanjutkan state-nya akan dimulai dari saat state terakhir sebelum diinterupsi. Superstate yang seperti itu disebut history state. Notasinya adalah huruf H di dalam lingkaran.

Gambar 30 History State

Entry/Exit Event Di dalam sebuah state dapat ditambahkan keterangan mengenai keadaan awal dan akhir dari state. Keadaan awal (disebut entry) menggambarkan keadaan yang diperlukan ketika sebuahstate berubah (bertransisi) menjadi state yang memiliki keterangan entry. Keadaan akhir (disebutexit) menggambarkan keadaan yang dimiliki oleh state ketika state berakhir.

Gambar 31 Entry/Exit Event

Untuk menggambarkan keadaan dimana sebuah state harus mengirimkan pesan ke objek lain, dipergunakan notasi seperti berikut : ^object.method (parameters)

Gambar 32 Entry berparameter

Guard untuk menggambarkan bahwa sebuah kondisi harus dipenuhi supaya terjadi state transition (bukan supaya state transition berhasil seperti pada entry event).

Gambar 33 Guard

Contoh dari state diagram :

Gambar 34 Contoh State Diagram Bagian ini dipergunakan pada tahapan construction (desain) untuk dapat melakukan sebuah perancangan yang BAIK. Konsep OO

Pattern

Sebuah pattern adalah sebuah solusi yang dipergunakan dengan baik dan sangat umum untuk masalah masalah yang cukup sering terjadi. Ada banyak pattern yang dapat dikenal oleh seorang perancang.Pattern yang akan dibahas pada bagian ini disebut GRASP (General Responsibility Assignment Software Patterns). GRASP membantu untuk menentukan kelakuan dari setiap kelas dengan cara yang paling elegan yang dimungkinkan. Pola (Pattern) tersebut dinamakan : Expert, Creator, High Cohersion, Low Coupling, dan Controller. Penggunaan dari kelima pola GRASP akan membuat perancangan OO menjadi lebih dapat dimengerti, mudah diubah, dan kokoh (robust).

Expert

Ini adalah sebuah pola yang sangat sederhana namun juga seringkali dilanggar. Pola ini harus yang paling utama ada di dalam pikiran seorang perancang saat membangun diagram kolaborasi ataumerancang class diagram.

Pola ini membantu alokasi kelakuan (behavior) ke dalam kelas. Alokasi yang baik dari sebuah kelakuan memiliki nilai :

Mudah dimengerti Dapat di-extend secara mudah Dapat dipergunakan kembali (reusable) Lebih kokoh (robust)

Pola ini memiliki aturan : Hanya kelas yang expert terhadap suatu behavior saja baru boleh memiliki behavior tersebut.

Creator

Pola ini adalah penggunaan spesifik dari Expert Pattern. Pola ini menjawab pertanyaan : Kelas manakah yang harus bertanggung jawab untuk pembuatan instans dari suatu kelas tertentu.. Kelas A harus bertanggung jawab untuk pembuatan kelas B, jika :

A mengandung objek B A menggunakan objek B secara dekat A memiliki inisialisasi data yang akan digunakan oleh B

High Cohesion

Sebuah perancangan OO yang baik memiliki tanda setiap kelas hanya memiliki sejumlah kecil method. Merupakan hal yang sangat penting untuk memastikan bahwa setiap kelas memiliki tanggung jawab yang terfokus.

Aturan utama dari pembangunan sebuah kelas adalah setiap kelas harus memiliki hanya satu kunci abstraksi (menggambarkan sebuah benda dari dunia nyata)

Low Coupling

Coupling adalah sebuah ukuran untuk menentukan seberapa tergantungnya sebuah kelas terhadap kelas lain. Coupling yang tinggi dapat menyebabkan code yang sulit diubah atau dirawat sebuah perubahan kecil dapat menyebabkan ombak perubahan terhadap sistem.

Untuk mengurangi coupling salah satu cara terbaik adalah dengan mengikuti model conceptual. Pesan yang dikirimkan hanya jika ada asosiasi yang telah didefinisikan pada tahapan conceptual modeling.

Aturan utama disini adalah : Jaga coupling seminimum mungkin conceptual model adalah sumber yang sempurna sebagai ukuran mengenai jumlah coupling minimum. Menaikkan level dari coupling bukanlah sebuah masalah jika telah dipikirkan dengan baikkonsekuensinya!

The Law of Demeter

Hukum ini, dikenal juga sebagai : Dont Talk to Strangers, adalah sebuah metode yang efektif untuk memerangi coupling. Hukum ini menyatakan bahwa setiap objek hanya boleh memanggil methodyang dimiliki oleh :

Dirinya sendiri Parameter yang dikirimkan kepada method Setiap objek yang dibentuk Setiap yang memegang objek secara langsung.

Beberapa hal yang harus dipertimbangkan mengenai coupling :

Jangan pernah membuat atribut dari kelas bersifat public. SEbuah atribut public membuka kesempatan penyalahgunaan sebuah kelas (pengecualian hanya diberikan kepada constantsdari kelas). Berikan get dan set hanya pada saat diperlukan. Berikan antarmuka public yang paling minimum. Jangan biarkan data mengalir di dalam sistem (minimalisasi pemindahan data). Jangan hanya mempertimbangkan coupling Ingat mengenai High cohesion dan expert! Sebuah kelas yang tidak memiliki coupling sama sekali akan memiliki kelas yang mengambang danmemiliki terlalu banyak pekerjaan. Biasanya berakhir dengan sistem yang memilikisedikit objek aktif yang tidak berkomunikasi.

Controller Secara umum penambahan informasi mengenai GUI (Graphical User Interface), basis data, atau objek fisik lainnya ke dalam kelas merupakan sebuah perancangan yang buruk. Kelas kelas dariconceptual model adalah kelas bisnis yang harus dibiarkan tetap murni (tanpa

GUI, database,dll). Untuk menghubungkan kelas bisnis dan actor diperkenalkan sebuah kelas baru yang dinamakan controller. Nama dari controller memiliki konvensisebagai berikut : <UseCaseName>Handler. Inheritance

Seringkali di dalam perancangan, beberapa kelas memiliki karakteristik yang sama. Karakteristik yang sama ini dapat digabungkan ke dalam sebuah kelas (untuk mengurangi pengulangan/redundan kode). Kelas ini kemudian dapat di-waris-kan (inherit) ke kelas lain yang lebih khusus dan menambahkan atribut serta method kepada kelas yang lebih khusus tersebut.

Gambar 35 dua kelas dengan karakteristik mirip

Gambar 36 Penggunaan Inheritance Proses pengelompokan karakteristik sebuah kelas yang sama dari beberapa kelas ke dalam sebuah kelas yang lebih umum disebut proses generalisasi. Kelas yang lebih umum disebut base class (atau superclass). Kelas yang lebih khusus disebutderived class (atau subclass). Sebuah base class dapat diturunkan (inherit) ke base class lain yang lebih khusus.

Permasalahan yang seringkali muncul berhubungan dengan inheritance adalah penggunaan inheritance secara berlebihan. Hal ini dapat menimbulkan permasalahan pada perawatan. Hal ini disebabkan kelas turunan (derived class) memiliki coupling yang sangat erat terhadap kelas basis (base class). Perubahan pada kelas basis akan menyebabkan perubahan pada kelas turunan. Penggunaan kelas turunan mewajibkan perancang untuk mengetahui kemampuan dari kelas basis. Hal ini berarti harus diadakan eksplorasi terhadap hierarki kelas yang besar. Masalah ini dikenal juga dengan nama proliferation of classes. Hal ini disebabkan karena inheritance dipergunakan ketika ia tidak seharusnya dipergunakan. Aturan utama di dalam penggunaan inheritance adalah : Gunakan inheritance hanya sebagai alat (mekanisme) generalisasi tidak selalu harus menggunakaninheritance.

Dalam melakukan inheritance ada 2 aturan yang harus diikuti, yaitu : aturan is a kind dan aturan 100 %.

Aturan 100 %

Aturan ini berisi : Semua definisi yang dimiliki oleh kelas basis harus diaplikasikansecara penuh oleh kelas turunan. Pengabaian terhadap aturan ini dapat menyebabkan masalah terhadap perawatan.

Substitutability Sebuah method tidak dapat dihapus di dalam hierarki inheritance.

Aturan is a kind

Aturan ini berfungsi untuk melakukan pengujian apakah hierarki inheritance yang dimilikivalid. Aturan ini mengatakan bahwa sebuah frase dengan format : <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-akind diterapkan dengan baik.

Sebagai tambahan, Inheritance adalah white-box-reuse. Enkapsulasi antara kelas basis dan kelasturunan cukup lemah secara umum, perubahan terhadap kelas basis dapat menyebabkan perubahan kelas turunan manapun. Hal ini menyebabkan pengguna kelas harus mengetahui hubungan antara parent class (superclass, kelas basis) dengan kelas yang sedang dikerjakan (child class, subclass, kelas turunan).

Protected Visibility

Atribut dalam setiap kelas memiliki karakteristik visibility. Secara default, visibilitydari sebuah atribut pada kelas adalah private. Hal ini berarti apapun (kelas manapun) selain dari kelas yang memiliki atribut tersebut tidak dapat melihat nilai dari atribut tersebut. Visibility dengan nilai public artinya apapun (kelas manapun) dapat melihat nilai dari atribut tersebut. OO menyediakan suatu Visibility atribut dengan nilai protected, yang artinya kelas turunan dari kelas tersebut dapat melihat nilai dari atribut-nya tetapi kelas lain tidak.

Penggambaran protected visibility digambarkan dengan tanda pagar (#) di samping atribut yang bersifat protected.

Gambar 37 Protected Visibility

Polymorphism

Kelas turunan dapat mendefinisikan kembali implementasi dari method. Hal ini biasanya disebabkan karena dua buah kelas turunan yang memiliki method turunan dari sebuah kelas basis melakukan implementasi yang berbeda terhadap method tersebut.

Gambar 38 Polymorphism

The principle of substitutability berhubungan erat dengan polymorphism. Prinsip ini mengatakan bahwa jika method yang adadiharapkan dapat bekerja pada sebuah kelas tertentu, ia dapat bekerja dengan baik padakelas turunannya yang manapun. Prinsip ini tidak mengijinkan kelas turunan untuk menghapus method dari superclass-nya. Hal ini supaya tidak terjadi kesalahan akibat keteledoran di dalam penggunaan kelas.

Contoh kasus :

Method accelerate di atas bekerja dengan menggunakan parameter dengan tipe Transport, dan melakukan percepatan dengan menggunakan method move(). Method ini dapat dipanggil dengan aman dan memberikan sebuah objek Car kepadanya (karena Car adalah subclass dari Transport) ataupun sebuah objek Boat. Jika suatu saat nanti, ada sebuah kelas turunan baru dari Transport dengan nama Aeroplane, kelas Aeroplane ini dapat diterima dengan baik tanpa modifikasi terhadapmethod Accelerate! Oleh karena alasan inilah sebuah kelas turunan tidak dapat menghapus method darisuperclassnya. 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 diimplementasikandan 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 <<abstract>> di bawah nama kelas. Notasi ini diperkenalkan karena seringkalihuruf miring (italic) sulit untuk dikenali pada sebuah diagram kelas. Pemberian atribut tambahan <<abstract>> disebut stereotyping (<<abstract>> adalah stereotype).

Gambar 39 Abstract Class

Gambar 40 Abstract Class (Stereotype)

System Architechture

Ada beberapa masalah yang dihadapi oleh pengembang perangkat lunak ketika menghadapi pengembangan sistem yang bersifat besar dan lebih kompleks. Untuk menjawab permasalahan itu, UML memberikan beberapa tools yang dapat berguna di dalam pengembangan. Package Diagram Semua artefak UML dapat disusun ke dalam UML Packages. Package secara mendasar adalah sebuah kontainer logika untuk elemen elemen yang saling berhubungan. Sebuah package dapat berisi package lain sehingga pada akhirnya akan membentuk hierarki. Di dalam UML, dapat juga digambarkan sekumpulan packages dimana ada hubungan

beberapa packagetersebut. Gambar 41 Relasi antar package Contoh di atas adalah model klasik dari three tier model di dalam pengembangan perangkat lunak. Benda yang berada di dalam package Presentation bergantung pada benda yang berada di dalam package Business. Meskipun semua artefak UML dapat ditaruh di dalam package, penggunaan package yang paling umum adalah untuk menaruh sekelompok kelas yang saling berhubungan. Penamaan kelas dari setiappackage harus unik. Namun penamaan kelas dari package yang berbeda tidak bermasalah meskipun memiliki nama kelas yang sama. Keuntungan dari melakukan packaging adalah :

Pengelompokan sistem yang besar ke dalam subsistem yang lebih mudah dikelola. Memungkinkan iterative pengembangan secara parallel.

Keuntungan lain dari packaging adalah jika desain dari sebuah package dilakukan dengan baik dan packagetersebut memiliki antarmuka yang jelas untuk digunakan antar package, konsep code reuse dapat dimaksimalkan. Class reuse (penggunaan ulang kelas) adalah sesuatu yang sulit untuk dilakukan dikarenakan kelas memiliki jangkauan yang sempit dan sulit untuk digunakan kembali (dengan kata lainabstraksi kelas rendah). Berbeda dengan package, dengan perancangan yang baik sebuah package dapat menjadi solid dan menjadi sebuah komponen perangkat lunak yang dapat digunakan kembali (memilikiabstraksi yang tinggi). Ada 3 hal heuristik dari GRASP yang dapat diaplikasikan kepada packaging :

Expert : package manakah sebuah kelas harus ditaruh? High Cohesion : sebuah package tidak boleh melakukan terlalu banyak hal Loose Coupling : ketergantungan antar package harus seminimal mungkin.

Package Communication Komunikasi antara 2 package dapat dilakukan sesuai dengan pola faade (faade pattern). Pola ini memberikan sebuah kelas diantara 2 buah package yang hendak berkomunikasi, sehingga kedua packageyang akan berkomunikasi harus melalui kelas ini (yang disebut kelas faade).

Gambar 42 Komunikasi tanpa kelas facade

Gambar 43 Komunikasi dengan kelas facade Architechture Centric Development Proses pembangunan perangkat lunak RUP (Rational Unified Process) menyarankan konsep pengembangan dengan arsitektur terpusat. Dengan kata lain, sistem dirancang sebagaikumpulan dari subsistem mulai dari tahapan yang sangat awal dari pengembangan. Dengan membuat sekumpulan kecil subsistem yang mudah dikelola, sebuah tim pengembang yang terdiri dari 3 4 orang dapat dialokasikan terhadap setiap subsistem. Subsistem tersebut dapat dikerjakan parallel tanpa bergantung satu sama lain. Tim architecture akan melakukan pengelolaan terhadap antarmuka (faade) di antara subsistem. Meskipun pada saat pengembangan proyek nanti diperlukan perubahan pada faade, yang akan melakukan modifikasi adalah tim architectural bukan tim pengembang yang bekerja pada subsistem individual. Dikarenakan tim architecture mengelola pandangan tingkat tinggi dari sistem, mereka harusmemahami akibat dari modifikasi antar interface yang dimiliki oleh subsistem. Menangani Use Case Besar Salah satu permasalahan yang muncul dari pengembangan dengan skala besar adalah use caseyang pertama sekali dibuat biasanya terlampau besar untuk dikembangkan dalam satu kali iterasi. Solusi yang diberikan bukanlah membuat masa iterasi lebih panjang, melainkan memecah use case menjadi sekumpulan versi yang lebih kecil dan mudah di-kelola.

Untuk setiap iterasi, tim terpisah dapat mengerjakan subsistem terpisah secara paralel. Pada akhir dari iterasi, tahapan integrasi akan dilakukan, dan pengujian terhadap antarmuka subsistem akan dilakukan.

Kesimpulan : Rational Corp memberikan sebuah pendekatan terbaik untuk pendekatan secara arsitektur terpusat (architecture centric approach), yaitu :

Definisikan subsistem dari tahap awal Jaga kompleksitas supaya tetap dapat diatur Iterasi secara parallel tetapi jangan hack interface Tunjuk sebuah tim arsitektural

Fase Pengkodean Salah satu masalah kunci dari perancangan dan koding adalah untuk menjaga model tetap konsistendengan kode. Untuk melakukan hal ini, salah satu pendekatan yang dapat dilakukan adalah dengan menambahkan sebuah tahapan tambahan pada iterasi, yaitu tahapan sinkronisasi. Tahapan ini berfungsi untuk melakukan sinkronisasi artefak. Disini model diubah untuk menggambarkan keputusan perancangan yang telah dibuat saatmelakukan koding di iterasi sebelumnya.

Gambar 44 Tahapan perancangan Pemetaan perancangan ke kode

[Class Diagram] Class to Code

Definisi kelas yang dikodekan akan diturunkan dari kelas diagram perancangan. Definisi method akan berasal dari collaboration diagram, bantuan lainnya berasal dari use case description (detil tambahan, khususnya pada exception/alternate flows)dan state chart (menangkap kondisi error). Pemetaan 1 : Class Model Class

Gambar 45 Class Model

Gambar 46 Class Code Langkah Pemetaan :

Tambahkan constructor untuk setiap kelas yang dibuat Petakan atribut dan method yang ada di dalam class diagram Pemetaan 2 : Contain Relationship

Gambar 47 Contain Relationship

Gambar 48 Code

Pemetaan 3 : Pendefinisian Method

Gambar 49 Method (Message Passing)

Gambar 50 Code Method

Gambar 51 Code Method

[Package] Package to Code

Java

Java memiliki dukungan langsung terhadap package. Baris pertama dari deklarasi kelas pada java harus mengatakan pada Java di package manakah kelas tersebut berada. (Jika tidak ada, Java akan menganggap kelas berada pada package default). Java juga memiliki fitur package protection. Kelas (bersama dengan method dan atributnya) hanya dapat dilihat oleh kelas yang berada pada package yang sama. Ini memberikan dukungan yang sempurna untuk enkapsulasi di dalam package. Dengan membuat semua kelas hanya dapat dilihat oleh kelas di dalam satu package (kecuali kelas faade), subsistem (atau package) dapat dikembangkan secara bebas (independent). Meskipun sintaks yang dimiliki java untuk fitur ini tidak terlalu baik, yaitu hanya melakukan deklarasi kelas tanpa kata kunci public, protected, atau private di depan kata kunci kelas.

C++ C++ ti dak memiliki dukungan langsung terhadap package, tetapi C++ memiliki konsep yang disebut sebagai namespace. Ini memungkinkan kelas untuk ditaruh pada partisi logikaterpisah, untuk menghindari tubrukan nama kelas di antara namespaces. Meski ia memberikan beberapa dukungan dari packages, sayangnya ia tidak memberikanperlindungan dari visibilities. Kelas yang berasal dari sebuah namespaces dapat mengakses seluruh kelas publik yang terdapat di namespaces lain. Component Model

UML menyediakan sebuah notasi yang dapat dipergunakan untuk memodelkan komponen perangkat lunak yang bersifat fisik dan keras (bukan kode, cth : file). Notasi ini menggunakan notasi yang samadengan package diagram. Ia memodelkan ketergantungan antara entitas fisik perangkat lunak seperti :executeable file, dynamic link library, object file, source file, dll).

Gambar 52 Notasi UML untuk Component Model

1. Tahapan Transition Setelah melewati tahapan construction, maka berakhirlah tugas UML. Setelah mencapai tahapan ini, sebuah sistem yang berjalan sesuai dengan spesifikasi telah didapatkan. Tahap transition berkaitan dengan prosedur prosedur yang diperlukan untuk melakukan deliverable dari sistem yang telah dihasilkan.

http://eraindrop.wordpress.com/2009/09/23/uml--analisis-perancangan-berorientasiobjek/

Related
Analisis dan Perancangan Berorientasi ObjekIn "OOP" Analis sistem RPLIn "Kuliah" Makan, Parfum, dan UangRupiah Posted on 29/03/2013 by Dhienzz This entry was posted in OOP. Bookmark the permalink. Hujan jangan kau reda 1 Batang korek cukup menghagatkan, tapi akan lebih hangat jika semakin banyak yg menyalakan.

Analisa dan Perancangan Berbasis Objek

Object Oriented analaysis adalah metode analisis yang memeriksa requirements (syarat/keperluan yang harus dipenuhi suatu sistem) dari sudut pandang kelas-kelas dan objek-objek yang ditemui dalam ruang lingkup permasalahan. Object Oriented Design adalah metode untuk mengarahkan arsitektur software yang didasarkan pada manipulasi objek-objek sistem atau subsistem.

Konsep Dasar OOAD (Object Oriented Analysis and Design) OOAD mencakup analisis dan desain sebuah sistem dengan pendekatan objek, yaiut analisis berorientasi objek (OOA) dan desain berorientasi objek (OOD). OOA adalah metode analisis yang memerika requirement (syarat/keperluan) yang harus dipenuhi sebuah sistem) dari sudut pandang kelas-kelas dan objek-objek yang ditemui dalam ruang lingkup perusahaan. Sedangkan OOD adalah metode untuk mengarahkan arsitektur software yang didasarkan pada manipulasi objek-objek sistem atau subsistem. Terdapat beberapa konsep dalam OOAD, yaitu : - Objek (object)

Objek adalah benda secara fisik dan konseptual yang ada di sekitar kita. Sebuah objek memiliki keadaan sesaat yang disebut state. State dari sebuah objek adalah kondisi dari objek atau himpunan keadaan yang menggambarkan objek tersebut. State dinyatakan dengan nilai dari atribut objeknya. Atribut adalah nilai internal suatu objek yang mencerminkan karakteristik objek, kondisi sesaat, koneksi dengan objek lain dan identitas. Behaviour (perilaku objek) mendefinisikan bagaimana sebuah objek bertindak dan memberi reaksi. Behaviour ditentukan oleh himpunan semua atau beberapa operasi yang dapat dilakukan oleh objek tersebut, yang dicerminkan oleh interface, service, dan method dari objek tersebut. Interface adalah pintu untuk mengakses service dari objek Service adalah fungsi yang dapat dikerjakan oleh sebuah objek Method adalah mekanisme internal objek yang mencerminkan perilaku objek tersebut

- Kelas (class) Class adalah himpunan objek yang sejenis yaitu mempunyai sifat (atribut), perilaku umum (operasi), relasi umum dengan objek lain dan semantik umum. Class adalah abstraksi dari objek dalam dunia nyata. Class menetapkan spesifikasi perilaku dan atribut dari objek tersebut. - Kotak Hitam (black boxes) Sebuah objek adalah kotak hitam. Konsep ini menjadi dasar implementasi objek. Dalam operasi OO hanya developer yang dapat memahami detail proses yang ada didalam kotak tersebut, sedangkan user tidak perlu mengetahui apa yang dilakukan yang penting mereka dapat menggunakan objek untuk memproses kebutuhan mereka. Kotak hitam berisi kode dan data.

Encapsulation, yaitu proses menyembunyikan detail implementasi sebuah objek. Untuk mengakses data objek tersebut adalah melalui interface. Untuk berkomunikasi dengan objek digunakan message. Message adalah permintaan agar objek menerima untuk membawa metode yang ditunjukkan oleh perilaku dan mengembalikan result dari aksi tersebut kepada objek pengirim (sender)

- Asosiasi dan Agregasi

Asosiasi adalah hubungan yang mempunyai makna antara sejumlah objek. Asosiasi digambarkan dengan sebuah garis penghubung diantara objeknya. Contohnya : Asosiasi karyawan dengan unit kerja. Setiap karyawan bekerja di satu unit kerja, sedangkan unit kerja dapat memiliki beberapa karyawan. Agregasi adalah bentuk khusus sebuah asosiasi yang menggambarkan seluruh bagian pada suatu objek merupakan bagian dari objek yang lain. Contohnya : Kopling dan piston adalah bagian dari mesin, sedangkan mesin, roda, body merupakan bagian dari sebuah mobil.

Kelebihan

Dibandingkan dengan metode SSAD, OOAD lebih mudah digunakan dalam pembangunan sistem Dibandingkan dengan SSAD, waktu pengembangan, level organisasi, ketangguhan,dan penggunaan kembali (reuse) kode program lebih tinggi dibandingkan dengan metode OOAD (Sommerville, 2000). Tidak ada pemisahan antara fase desain dan analisis, sehingga meningkatkan komunikasi antara user dan developer dari awal hingga akhir pembangunan sistem. Analis dan programmer tidak dibatasi dengan batasan implementasi sistem, jadi desain dapat diformliasikan yang dapat dikonfirmasi dengan berbagai lingkungan eksekusi. Relasi obyek dengan entitas (thing) umumnya dapat di mapping dengan baik seperti kondisi pada dunia nyata dan keterkaitan dalam sistem. Hal ini memudahkan dalam mehami desain (Sommerville, 2000). Memungkinkan adanya perubahan dan kepercayaan diri yang tinggi terhadap kebernaran software yang membantu untuk mengurangi resiko pada pembangunan sistem yang kompleks (Booch, 2007). Encapsliation data dan method, memungkinkan penggunaan kembali pada proyek lain, hal ini akan memperingan proses desain, pemrograman dan reduksi harga. OOAD memungkinkan adanya standarisasi obyek yang akan memudahkan memahami desain dan mengurangi resiko pelaksanaan proyek. Dekomposisi obyek, memungkinkan seorang analis untuk memcah masalah menjadi pecahan-pecahan masalah dan bagian-bagian yang dimanage secara terpisah. Kode program dapat dikerjakan bersama-sama. Metode ini memungkinkan pembangunan software dengan cepat, sehingga dapat segera masuk ke pasaran dan kompetitif. Sistem yang dihasilkan sangat fleksibel dan mudah dalam memelihara.

Kekurangan

Pada awal desain OOAD, sistem mungkin akan sangat simple. Pada OOAD lebih fockus pada coding dibandingkan dengan SSAD. Pada OOAD tidak menekankan pada kinerja team seperti pada SSAD. Pada OOAD tidak mudah untuk mendefinisikan class dan obyek yang dibutuhkan sistem. Sering kali pemrogramam berorientasi obyek digunakan untuk melakukan anlisisis terhadap fungsional siste, sementara metode OOAD tidak berbasis pada fungsional sistem. OOAD merupakan jenis manajemen proyek yang tergolong baru, yang berbeda dengan metode analisis dengan metode terstruktur. Konsekuensinya adalah, team developer butuh waktu yang lebih lama untuk berpindah ke OOAD, karena mereka sudah menggunakan SSAD dalam waktu yang lama ( Hantos, 2005). Metodologi pengembangan sistem dengan OOAD menggunakan konsep reuse. Reuse merupakan salah satu keuntungan utama yang menjadi alasan digunakannya OOAD. Namun demikian, tanpa prosedur yang emplisit terhadap reuse, akan sangat sliit untuk menerapkan konsep ini pada skala besar (Hantos, 2005).

Perancangan Terstruktur (Structured Analisys and Design / SSAD)

Metode ini diperkenalkan pada tahun 1970, yang merupakan hasil turunan dari pemrograman terstruktur. Metode pengembangan dengan metode terstruktur ini terus diperbaiki sampai akhirnya dapat digunakan dalam dunia nyata. Perancangan ini bertujuan untuk membuat model SOLUSI terhadap PROBLEM yang sudah dimodelkan secara lengkap pada tahap analisis terstruktur. Ada empat kegiatan perancangan yang harus dilakukan, yaitu: 1. Perancangan arsitektural; kita merancang struktur modul P/L dengam mengacu pada model analisis yang sesuai (DFD). Langkahnya adalah: mengidentifikasi jenis aliran (transform flowatau transaction flow), menemukan batas-batas aliran (incoming flow dan outgoing flow), kemudian memetakannya menjadi striktur hirarki modul. Selanjutnya, kita alokasikan fungsi-fungsi yang harus ada pada modul-modul yang tepat. 2. Perancangan data; kita merancang struktur data yang dibutuhkan, serta merancang skema basisdata dengan mengacu pada model analisis yang sesuai (ERD). 3. Perancangan antarmuka; kita merancang antarmuka P/L dengan pengguna, antarmuka dengan sistem lain, dan antarmuka antar-modul. 4. Perancangan prosedural; kita merancang detil dari setiap fungsi pada modul. Notasi yang digunakan bisa berupa flow chart, algoritma, dan lain-lain Pastikan bahwa model perancangan yang dibuat sudah mengakomodasi kebutuhan non fungsional. Berikut ini merupakan kelebihan dan kekurangan metode perancangan terstruktur : Kelebihan

Milestone diperlihatkan dengan jelas yang memudahkan dalam manajemen proyek SSAD merupakan pendekatan visual, ini membuat metode ini mudah dimengerti oleh pengguna atau programmer. Penggunaan analisis grafis dan tool seperti DFD menjadikan SSAD menjadikan bagus untuk digunakan. SSAD merupakan metode yang diketahui secara umum pada berbagai industry. SSAD sudah diterapkan begitu lama sehingga metode ini sudah matang dan layak untuk digunakan. SSAD memungkinkan untuk melakukan validasi antara berbagai kebutuhan SSAD relatif simpel dan mudah dimengerti.

Kekurangan

SSAD berorientasi utama pada proses, sehingga mengabaikan kebutuhan non-fungsional. Sedikit sekali manajemen langsung terkait dengan SSAD Prinsip dasar SSAD merupakan pengembangan non-iterative (waterfall), akan tetapi kebutuhan akan berubah pada setiap proses.

Interaksi antara analisis atau pengguna tidak komprehensif, karena sistem telah didefinisikan dari awal, sehingga tidak adaptif terhadap perubahan (kebutuhan-kebutuhan baru). Selain dengan menggunakan desain logic dan DFD, tidak cukup tool yang digunakan untuk mengkomunikasikan dengan pengguna, sehingga sangat sulit bagi pengguna untuk melakukan evaluasi. Pada SAAD sulit sekali untuk memutuskan ketika ingin menghentikan dekomposisi dan mliai membuat sistem. SSAD tidak selalu memenuhi kebutuhan pengguna. SSAD tidak dapat memenuhi kebutuhan terkait bahasa pemrograman berorientasi obyek, karena metode ini memang didesain untuk mendukung bahasa pemrograman terstruktur, tidak berorientasi pada obyek (Jadalowen, 2002).

Perbedaan Analisa Berbasis Objek dan Yang Terstruktur

Perancangan Terstruktur : Modul merupakan unit dari kode software yang menjalankan fungsi. Perancangan Berorientasi Objek : Modul objek yang mengenkapsulasi atribut dan kode program untuk berjalan.

Inspired By Source : http://aribimoprihartanto.blogspot.com/2011/11/perbedaan-perancangan-terstruktur-dan.html http://saiiamilla.wordpress.com/2010/06/04/ooad-object-oriented-analysis-dan-design/ http://eziekim.wordpress.com/2011/11/08/perbedaan-antara-perancangan-terstruktur-danberorientasi-objek/ http://andri503.blogspot.com/2012/06/analisa-dan-perancangan-berbasis-objek.html