Apa Itu UML?

UML, atau singkatan dari Unified Modeling Language, adalah bahasa pemodelan standar yang terdiri dari serangkaian diagram terintegrasi yang dikembangkan untuk membantu pengembang sistem dan software untuk menentukan, memvisualisasikan, membangun, dan mendokumentasikan artifact dari software system, serta untuk pemodelan bisnis dan sistem non-software lainnya.

UML mewakili kumpulan praktik engineering terbaik yang telah terbukti berhasil dalam pemodelan sistem yang besar dan kompleks. UML adalah bagian yang sangat penting dalam pengembangan software berorientasi objek dan proses pengembangan software. Sebagian besar UML menggunakan notasi grafis untuk mengekspresikan desain proyek software. Menggunakan UML mampu membantu tim untuk dapat berkomunikasi, mengeksplorasi desain potensial, dan memvalidasi desain arsitektur software. Pada artikel ini, kita akan membahas secara terperinci tentang apa itu UML, sejarah UML dan deskripsi setiap jenis diagram UML.

Baca Juga: Apa Itu SaaS?

Asal Usul UML

Tujuan dari UML adalah untuk menyediakan notasi standar yang dapat digunakan oleh semua metode berorientasi objek dan untuk memilih dan mengintegrasikan elemen terbaik dari notasi prekursor. UML telah dirancang untuk dapat berjalan di berbagai aplikasi. Oleh karena itu, UML menyediakan konstruksi untuk berbagai sistem dan kegiatan (misalnya, sistem terdistribusi, analisis, desain sistem dan penyebaran).

UML adalah notasi yang dihasilkan dari penyatuan OMT dari:

1. Object Modeling Technique OMT [James Rumbaugh 1991] - Ini merupakan alat terbaik untuk analisis dan sistem informasi intensif data.

2. Booch [Grady Booch 1994] - Ini sangat baik untuk desain dan implementasi. Grady Booch telah bekerja secara ekstensif dengan bahasa Ada, dan telah menjadi pemain utama dalam pengembangan teknik berorientasi objek untuk bahasa tersebut. Meskipun metode Booch itu kuat, notasinya kurang diterima dengan baik (banyak bentuk cloud mendominasi modelnya, sehingga tidak terlalu rapi)

3. OOSE (Object-Oriented Software Engineering [Ivar Jacobson 1992]) - menampilkan model yang dikenal sebagai Use Cases. Use Cases adalah teknik yang kuat untuk memahami perilaku seluruh sistem (area di mana Object Oriented secara tradisional lemah).

Pada tahun 1994, Jim Rumbaugh, pencipta OMT, mengejutkan dunia software ketika ia meninggalkan General Electric dan bergabung dengan Grady Booch di Rational Corp. Tujuan dari kemitraan ini adalah untuk menggabungkan ide-ide mereka menjadi satu metode terpadu (judul kerja untuk metode itu memang "Unified Method").

Pada tahun 1995, pencipta OOSE, Ivar Jacobson, juga bergabung dengan Rational, dan ide-idenya (khususnya konsep "Use Cases") dimasukkan ke dalam Unified Method yang baru, dan sekarang disebut Unified Modelling Language. Tim Rumbaugh, Booch dan Jacobson dikenal sebagai "Three Amigos".

Mengapa Harus UML?

Karena nilai strategis software akan meningkat bagi banyak perusahaan, maka semakin banyak industri yang mencari teknik untuk mengotomatisasi produksi software dan untuk meningkatkan kualitasnya, serta mengurangi biaya dan waktu ke pasar. Teknik-teknik ini meliputi teknologi komponen, pemrograman visual, pola dan framework. Bisnis juga mencari teknik untuk mengelola kompleksitas sistem saat mereka meningkatkan cakupan dan skala. Secara khusus, mereka menyadari kebutuhan untuk memecahkan masalah arsitektur yang berulang, seperti distribusi fisik, konkurensi, replikasi, keamanan, penyeimbangan beban, dan toleransi kesalahan. Selain itu, pengembangan untuk World Wide Web yang membuat beberapa hal menjadi lebih sederhana, telah memperburuk masalah arsitektur ini. Unified Modeling Language (UML) dirancang untuk menjawab kebutuhan ini. Tujuan utama dalam desain UML dirangkum oleh Page-Jones dalam Fundamental Object-Oriented Design di UML sebagai berikut:

• Menyediakan pengguna dengan bahasa pemodelan visual ekspresif yang siap pakai sehingga mereka dapat mengembangkan dan bertukar model yang bermakna.
• Menyediakan mekanisme ekstensibilitas dan spesialisasi untuk memperluas konsep inti.
• Menjadi independen dari bahasa pemrograman dan proses pengembangan tertentu.
• Memberikan dasar formal untuk memahami bahasa pemodelan.
• Mendorong pertumbuhan pasar alat bantu Object Oriented.
• Mendukung konsep pengembangan tingkat yang lebih tinggi seperti kolaborasi, kerangka kerja, pola, dan komponen.
• Mengintegrasikan praktik terbaik.

Ada Dua Diagram Dalam UML

UML memanfaatkan elemen dan membentuk asosiasi di antara mereka untuk membentuk diagram. Diagram dalam UML secara garis besar dapat diklasifikasikan sebagai:

- Diagram Structural – Menangkap aspek atau struktur statis dari suatu sistem. Diagram Struktural meliputi: Component Diagram, Object Diagram, Class Diagram, dan Deployment Diagram.

- Diagram Behavior – Menangkap aspek dinamis atau perilaku sistem. Diagram perilaku meliputi: Use Case Diagram, State Diagram, Activity Diagram dan Interaction Diagram.

1. Diagram UML Structural 

• Class Diagram – Diagram UML yang paling banyak digunakan adalah Class Diagram . Diagram ini berbentuk blok bangunan dari semua sistem software berorientasi objek. Kita dapat menggunakan diagram kelas untuk menggambarkan struktur statis suatu sistem dengan menunjukkan kelas sistem, metode dan atributnya. Class Diagram juga membantu kita mengidentifikasi hubungan antara kelas atau objek yang berbeda.
• Composite Structure Diagramt – Kita bisa menggunakan diagram struktur komposit untuk mewakili struktur internal kelas dan titik interaksinya dengan bagian lain dari sistem. Composite Structure Diagram mewakili hubungan antara bagian dan konfigurasinya yang menentukan bagaimana classifier (kelas, komponen, atau node penyebaran) dapat berperilaku. Ini mewakili struktur internal dari pengklasifikasi terstruktur yang menggunakan bagian, port, dan konektor. Kita juga dapat memodelkan kolaborasi menggunakan diagram struktur komposit. Composite Structure Diagram mirip dengan Class Diagram kecuali pada bagian-bagian yang mewakili individu secara rinci dibandingkan dengan seluruh kelas.
• Object Diagram – Object Diagram dapat disebut sebagai tangkapan layar dari instance dalam suatu sistem dan hubungan yang ada di antara mereka. Karena diagram objek menggambarkan perilaku ketika objek telah dipakai, kita dapat mempelajari perilaku sistem pada saat tertentu. Object Diagram mirip dengan diagram kelas kecuali menunjukkan contoh kelas dalam sistem. Kita dapat menggambarkan pengklasifikasi aktual dan hubungan mereka menggunakan diagram kelas. Di sisi lain, Object Diagram mewakili contoh spesifik dari kelas dan hubungan di antara mereka pada suatu titik waktu.
• Component Diagram – Component Diagram digunakan untuk mewakili bagaimana komponen fisik dalam suatu sistem telah diatur. Kita dapat menggunakannya untuk memodelkan detail implementasi. Component diagram menggambarkan hubungan struktural antara elemen sistem software dan membantu kita dalam memahami jika persyaratan fungsional telah dicakup oleh pengembangan yang direncanakan. Component Diagram menjadi penting untuk digunakan ketika kita merancang dan membangun sistem yang kompleks. Interface digunakan oleh komponen sistem untuk berkomunikasi satu sama lain.
• Deployment Diagram – Deployment Diagram digunakan untuk mewakili haradware sistem beserta software-nya. Diagram ini memberi tahu kita komponen hardware apa yang ada dan komponen software apa yang berjalan di dalamnya. Kit daapt menggambarkan arsitektur sistem sebagai distribusi artifact software di atas target terdistribusi. Artifact adalah informasi yang dihasilkan oleh system software. Mereka akan digunakan ketika software sedang digunakan, didistribusikan atau digunakan di beberapa mesin dengan konfigurasi yang berbeda.
• Package Diagram – Kita dapat menggunakan Pacakge Diagram untuk menggambarkan bagaimana paket dan elemennya telah diatur. Package Diagram  hanya menunjukkan kepada kita ketergantungan antara paket yang berbeda dan komposisi internal paket. Paket membantu kita untuk mengatur diagram UML ke dalam kelompok yang bermakna dan membuat diagram dapat mudah dimengerti. Ini biasa digunakan untuk mengatur kelas dan menggunakan case diagram.

2. Diagram Behavior 

• State Machine Diagram – State Diagram digunakan untuk mewakili kondisi sistem atau bagian dari sistem dalam waktu yang terbatas. Ini merupakan diagram behavior dan mewakili perilaku menggunakan transisi keadaan terbatas. State Diagram juga disebut sebagai State Machine dan State-chart Diagram. Istilah-istilah ini sering digunakan secara bergantian. Jadi sederhananya, state diagram digunakan untuk memodelkan perilaku dinamis suatu kelas dalam menanggapi waktu dan mengubah rangsangan eksternal.
• Activity Diagram – Kita dapat menggunakan Activity Diagram untuk menggambarkan aliran kontrol dalam suatu sistem. Kita juga dapat menggunakan activity diagram untuk merujuk pada langkah-langkah yang terlibat dalam eksekusi use case. Kita dapat memodelkan aktivitas secara berurutan dan bersamaan menggunakan diagram ini. Jadi, pada dasarnya kita akan menggambarkan alur kerja secara visual menggunakan activity diagram. Activity Diagram berfokus pada kondisi aliran dan urutan terjadinya. Diagram ini membantu utnuk menggambarkan apa yang menyebabkan peristiwa tertentu.
• Use Case Diagram – Use Case Diagram digunakan untuk menggambarkan fungsionalitas sistem atau bagian dari sistem. Mereka banyak digunakan untuk menggambarkan persyaratan fungsional sistem dan interaksinya dengan agen eksternal (aktor). Use case pada dasarnya adalah diagram yang mewakili skenario yang berbeda di mana sistem dapat digunakan. Use case diagram memberi kita pandangan tingkat tinggi tentang apa yang dilakukan sistem atau bagian dari sistem tanpa masuk ke detail implementasi.
• Sequence Diagram – Sequence Diagram hanya menggambarkan interaksi antara objek secara berurutan, yaitu saat urutan interaksi ini berlangsung. Kita juga dapat menggunakan istilah diagram peristiwa atau skenario peristiwa untuk merujuk ke Sequence Diagram. Sequence diagram juga menggambarkan bagaimana dan bagaimana urutan objek-objek dalam suatu fungsi sistem. Diagram ini banyak digunakan oleh pengusaha dan pengembang software untuk mendokumentasikan dan memahami persyaratan untuk sistem baru dan yang sudah ada.