Ada apa dengan UML?

Kebanyakan orang salah, UML bukanlah Universal Modelling Language, dimana UML tidak diperuntukkan agar bisa membuat model bagi apa saja (contoh, UML tidak terlalu baik untuk memodelkan persediaan pasar).UML juga bukanlah Unified Marxist-Leninists, suatu partai politik di Nepal. UML adalah Unified Modelling Language.
lebih penting adalah, UML merupakan standardized modelling language yang terdiri dari kumpulan-kumpulan diagram, dikembangkan untuk membantu para pengembang sistem dan software agar bisa menyelesaikan tugas-tugas seperti:
• Spesifikasi
• Visualisasi
• Desain Arsitektur
• Konstruksi
• Simulasi dan testing
• Dokumentasi
UML dikembangkan sebagai ide dasar untuk mempromosikan hubungan dan produktifitas antara para pengembang dari object-oriented system.
UML memuaskan kebutuhan yang penting dalam pengembangan software dan sistem. Pemodelan (modeling) memungkinkan para pengembang bisa berkonsentrasi pada gambaran yang luas. UML membantu kita melihat dan menyelesaikan masalah-masalah yang sering terjadi. Ketika kita membuat model, kita membuat suatu abstraksi dari sistem nyata yang sudah ada, yang memungkinkan kita bisa bertanya tentang model tersebut dan akan kita dapatkan jawaban yang memuaskan.
Setelah kita puas dengan hasil kerja kita, kita bisa menggunakan model kita bersama dengan orang lain. Kita bisa menggunakan model kita untuk meminta bantuan dari orang lain yang akan meningkatkan kerja kita, dan juga dapat saling membantu dengan mengajari orang lain.
Abstracting
Teknik dalam membuat model dari ide kita atau dunia nyata adalah dengan menggunakan abstraction. Sebagai contoh, map merupakan model dunia – bukanlah miniatur dunia.
Setiap diagram UML yang kita gambar memiliki keterkaitan dengan dunia nyata. Abstraction dikembangkan sebagai ketentuan untuk dipelajari dan sering digunakan.
Jika kita berpikir UML sebagai map dari dunia yang kita lihat, hampir mendekati. Analogi yang lebih mendekati adalah merupakan kumpulan dari blueprint yang menampilkan detail yang cukup dari suatu bangunan untuk memastikan tentang apa sebenarnya bangunan tersebut. Abstraction model dan diagram juga berguna karena akan menjelaskan lebih rinci detail-detail yang dibutuhkan (kita tidak perlu mengambar pohon dan mobil dan orang dalam map kita, karena map kita akan menjadi susah alias tidak praktis untuk dipakai).
Kategori diagram UML
• Structural Diagram: kita menggunakan structural diagram untuk menampilkan blok bangunanan dari sistem kita – merupakan fitur yang tidak berubah bersama waktu. Diagram ini menjawab pertanyaan, ada apa disana?
• Behavioral Diagram: kita menggunakan behavioral diagram untuk menampilkan bagaimana sistem kita merespon permintaan atau apa saja seiring waktu.
• Interaction diagram: merupakan tipe dari behavioral diagram. Kita menggunakan interaction diagram untuk melukiskan perubahan dari pesan-pesan dalam suatu kolaborasi (kumpulan dari object-object yang sama) sehingga tujuan bisa tercapai.
• Structural diagram (Class diagram) : Digunakan untuk menampilkan entiti dunia nyata, elemen dari analisa dan desain, atau implementasi class dan relasinya.
• Structural diagram (Object diagram) : Digunakan untuk menampilkan suatu contoh spesifik atau ilustrasi dari suatu object serta link nya. Sering digunakan untuk mengindikasikan kondisi dari suatu even, seperti percobaan atau operasi pemanggilan.
• Structural diagram (Composite structure diagram) : Digunakan untuk menampilkan bagaimana sesuatu itu dibuat.
• Structural diagram (Deployment diagram) : Digunakan untuk menampilkan arsitektur run-time dari suatu sistem, kerangka hardware, ruang lingkup software, dan sebagainya.
• Structural diagram (Component diagram) : Digunakan untuk menampilkan organisasi dan hubungan antar sistem.
• Structural diagram (Package diagram) : Digunakan untuk mengorganisir elemen model dan menampilkan ketergantungan antara mereka.
• Behavioral diagram (Activity diagram) : Digunakan untuk menampilkan arus data dari kebiasaan antar object.
• Behavioral diagram (Use case diagram) : Digunakan untuk menampilkan layanan yang bisa diminta oleh actor dari sistem kita.
• Behavioral diagram (State machine diagram / Protocol state machine diagram) : Digunakan untuk menampilkan urutan proses dari suatu object dan kondisinya saat ini.
• Interaction diagram (Overview diagram) : Digunakan untuk menampilkan banyak skenario interaksi (urutan dari kebiasaan) bagi suatu kolaborasi (kumpulan elemen yang sama dan saling bekerja agar tercapai tujuan yang diinginkan).
• Interaction diagram (Sequence diagram) : Digunakan untuk fokus pada perubahan pesan antara grup dari suatu object dan urutan pesan tersebut.
• Interaction diagram (Communication diagram) : Digunakan untuk fokus pada perubahan pesan antara grup dari suatu object dan relasi dari object-object tersebut.
• Interaction diagram (Timing diagram) : Digunakan untuk menampilkan perubahan dan hubungan terhadap waktu nyata atau terhadap proses sistem.
Karena UML sangatlah fleksibel, kita akan menjumpai berbagai cara dalam meng-kategorikan diagram kita. Pohon kategori di bawah ini cukup terkenal:
• Static diagram: Menampilkan fitur statis dari sistem. Kategori ini hampir sama dengan structural diagram.
• Dynamic diagram: Menampilkan bagaimana proses perubahan yang terjadi dalam sistem sepanjang waktu. Kategori ini mencakup UML state-machine diagram dan timing diagram.
• Functional diagram: Menampilkan detail dari proses dan algoritma. Kategori ini mencakup use case, interaction, dan activity diagram.
Kita bisa mengembangkan diagram UML untuk menampilkan informasi yang berbeda pada waktu yang berbeda atau untuk tujuan yang berbeda. Ada banyak kerangka modelling, seperti Zachman atau DODAF. Berikut pertanyaan standar tentang sistem :
• Siapa yang menggunakan sistem? Menampilkan actor (pengguna sistem) dalam diagram use case(menampilkan tujuan sistem)
• Dari mana sistem dibuat? Menggambarkan diagram Class untuk menampilkan struktur logis dan component diagram agar bisa menampilkan struktur fisik.
• Dimana lokasi komponen dalam suatu sistem? Mengindikasikan rencana kita untuk menentukan lokasi suatu komponen.
• Kapan kejadian penting terjadi? Menampilkan apa yang menyebabkan object kita bisa bereaksi dan mulai melakukan kerjanya dengan state diagram dan interaction diagram.
• Bagaimana sistem ini bekerja? Menampilkan bagian struktur diagram dan menggunakan communication diagram untuk menampilkkan interaksi.
Siapa yang memerlukan UML?
Para pengguna UML dibagi dalam kategori:
• Modeler: Modeler mencoba menjelaskan dunia nyata seperti bagaimana mereka melihatnya.
• Designer: Designer mencoba mencari solusi yang memungkinkan, untuk dibandingkan atau menentukan proses pada aspek yang berbeda.
• Implementer: Implementer membangun solusi menggunakan UML sebagai bagian dari tujuan implementasi. Kebanyakan program UML sekarang sudah bisa membuat sendiri definisi dari suatu Class atau Database, seperti kode aplikasi atau user interface. (**)
UML itu cuma Gambar ? Benarkah ?
Well, pertanyaan yang saya pakai mungkin terlalu extreme. Bukan. Maksud saya bukannya UML itu tidak penting. Tapi ada hal yang lebih penting yaitu OOAD itu sendiri. UML “hanyalah” gambar yang digunakan sebagai “alat komunikasi” untuk menggambarkan suatu ide yang abstrak untuk dapat diimplementasikan.
Selain sebagai alat komunikasi, UML juga dapat berfungsi sebagai dokumentsasi dari suatu design. Jika architect, designer atau developer datang dan pergi dalam suatu project, UML diagrams dapat dipakai sebagai learning aid untuk memahami suatu system software yang kompleks.
UML dipilih karena kita butuh standard. Komunikasi bisa lancar kalau semua orang bicara dalam bahasa yang sama. Demikian halnya UML yang merupakan bahasa dalam bentuk gambar. Misal, jika kita menggunakan UML class diagram, semua orang yang memahami UML class diagram dapat mengerti mana attribute, mana responsibility, mana yang public, mana yang protected, class yang mana implement interface, class mana merupakan generalisasi class lainnya, dan sebagainya.
Celakanya, orang banyak yang tersesat dalam menggunakan UML ini. Banyak yang membuat UML menjadi “the real thing”. Padahal, UML itu cuma model dari system yang sebenarnya. Dan definisi model adalah: “Cheaper imitations of the real thing!”. Jadi, jangan menghabiskan terlalu banyak waktu “menggambar” UML. Fokuslah pada OOAD. Pada domain objects anda, kolaborasi antar object, responsibility tiap object, grouping object dan semacamnya. UML itu Cuma “cheaper model” dari hal-hal tadi.
Dari sini, bagaimana menggunakan UML dapat dibedakan menjadi 3:
1. UML as sketch
2. UML as Blueprint
3. UML as Programming Language
UML as sketch
Dari seluruh hal yang ada pada UML, hanya 20% saja yang akan terpakai dalam 80% effort analysis, design dan development. Kuncinya adalah selektivitas. Pilih notasi / diagram UML yang anda butuhkan saja. Gambarkan juga UML untuk hal yang menjadi fokus perhatian pada suatu saat tertentu. Tidak perlu semuanya.
Dengan demikian, UML dapat anda gambar dengan pensil diatas kertas. Dengan spidol pada whiteboard. Gambarkan diagram UML di whiteboard, diskusikan bersama team development, begitu ide development di dapat, langsung coding. Intinya, UML digunakan sebagai media komunikasi pada saat brainstorming ide design.
UML tadi bisa disimpan, tapi bisa juga dibuang. Terserah anda. Jika anda memakai drawing tools seperti Visio, anda dapat menyimpan UML tadi sebagai dokumen. Yang lebih menarik, Visio Enterprise Architect bisa melakukan Reverse Engineer dari code anda. Jadi, anda dapat menggunakan the code as the documentation of the system.
Saya adalah penganut aliran UML as sketch ini. UML tool favorit saya adalah spidol dan whiteboards. Yeah, kadang-kadang pakai Visio juga. Sekarang ini saya pakai Visio Enterprise Architect 2003.
UML as Blueprint
Jika anda membangun gedung pencakar langit atau jembatan, pasti ada arsitek dan insinyur sipil yang akan menggambar dan mengkalkulasikan semua design. Setelah design jadi, design dilempar ke kuli bangunan yang akan diawasi para mandor.
UMLdapat digunakan sebagai blueprint seperti halnya design bangunan atau jembatan. Architect/senior devs membuat UML-nya, lalu developer menulis code berdasarkan design tersebut. Konsekuensinya, UML yang digunakan harus sedetail-detailnya, selengkap-lengkapnya.
Problemnya, pada banyak kasus, selama masa development, design bisa berubah mengikuti kebutuhan bisnis. Nah, jika code harus berubah, logikanya, blueprint juga harus berubah. Me-maintain blueprint ini bukanlah pekerjaan ringan. Bikin capek! Syukur kalau ada waktu untuk melakukannya.
Tapi, pada skala project yang besar, dengan development team yang terpisah, UML as blueprint is the way to go. Tentu saja, pada project skala besar anda pasti menggunakan CASE tool (Computer Aided Software Engineering). Dengan CASE tool, maintenance blueprint ini akan lebih ringan. Jika anda tidak punya CASE tool, tetapi memilih menggunakan UML as blueprint… you just dig your own grave!!!
UML as Programming Language
Yang satu ini menggunakan UML lebih jauh lagi. Design dilakukan dengan UML (tentu saja dengan CASE tool), lalu dengan UML tadi di-generate skeleton code secara automatis. Nah, pada skeleton code inilah developer menambah baris-baris code untuk melengkapi skeleton code tadi. Disini, UML berfungsi sebagai suatu programming language. Untuk melakukan ini, anda perlu CASE tool yang canggih. CASE tool yang harus men-support Round-trip Engineering.
Microsoft support untuk UML
Sebagai permulaan, saya akan bicara tool Microsoft untuk UML yaitu Visio.
Visio men-support forward engineering. Kita bisa membuat skeleton code dari UML design kita. Sebaliknya, kita bisa mendapatkan UML (class diagram) dari code kita dengan fasilitas reverse engineering. Sayangnya, Visio tidak mensupport round-trip engineering. Code hasil generate dari Visio, jika kita update, lalu kita reverse engineer, anda mendapatkan model UML baru (bukan yang pertama anda pakai tadi). Lalu dari model yang baru anda dapat ini, anda tidak dapat melakukan update terhadap UML design ini dan mengharapkan code anda tadi juga terupdate. Intinya, Visio tidak bisa Round-trip engineering. Dari kenyataan ini, Visio masih termasuk kategori Drawing tool untuk menggambar UML. Dia belum layak disebut sebagai CASE tool.
Ada banyak CASE tool di pasaran. Tapi… harganya tidak ada yang murah. Yang paling terkenal adalah dari Rational (sekarang IBM Rational). Saya pernah punya sedikit pengalaman dengan Rational XDE for Microsoft .NET. Interesting. Tetapi, jika anda tidak punya barang-barang mewah seperti CASE tool ini, jangan sekali-sekali menggunakan UML sebagai blueprint apalagi programming language. O ya, CASE tool juga tampaknya tidak terlalu sukses di pasar.
O ya, Visio yang ada sekarang menggunakan UML versi 1.4. Baru-baru ini, OMG (yang bertugas memaintain UML) merilis UML versi 2.0. Jika anda ingin menggunakan UML versi 2.0 ini, ada stencil untuk Visio yang bisa anda download di :http://www.phruby.com/stencildownload.html
Tentang UML sendiri, Microsoft melihatnya bahwa UML bukan satu-satunya modeling language. Microsoft sedang memulai inisiatif DSL (Domain Specific Language). Lalu ada lagi inisiatif Software Factories, dsb. Sangat menarik untuk kita ikuti perkembangannya. Tetapi sebelum semua ini jadi kenyataan (he..he.. maksudnya, bisa kita pakai di production), kita stick dulu di UML. Kita juga lihat apakah DSL ini akan bisa “menggantikan” UML. Apakah DSL bisa diterima komunitas development. Dan sebagainya..dan sebagainya…
Kembali ke alinea pertama… ada yang lebih penting dari UML atau apapun juga modeling language lainnya… OOAD! UML itu Cuma gambar.

sumber