Apa antara ide dan kode? Gambaran umum dari 14 diagram UML





Ave Coder!



Anda mendapat ide produk yang keren, tetapi Anda tidak ingin terjebak dalam kode dan kehilangan seluruh gambar karena detail kecil? Apakah Anda akan duduk untuk mendengus server perusahaan dan Anda perlu mengisi sesuatu yang keren dan IT?



Seri artikel ini akan ditujukan untuk pengetahuan yang berguna, tetapi terkadang sulit dipahami tentang pertumbuhan muda - diagram UML. Dan saya akan memulainya dengan ulasan diagram yang ada, mari kita bicara sedikit tentang sejarah dan mengapa harus ada begitu banyak diagram.



UML adalah kependekan dari Unified Modeling Language, dan seperti yang kita tahu, itu adalah bahasa pemodelan standar yang terdiri dari serangkaian diagram terintegrasi yang dirancang untuk membantu pengembang sistem dan perangkat lunak dalam mengidentifikasi, memvisualisasikan, membangun, dan mendokumentasikan artefak sistem perangkat lunak, serta , misalnya, untuk pemodelan bisnis.



UML adalah seperangkat praktik rekayasa terbaik yang telah terbukti efektif dalam memodelkan sistem yang besar dan kompleks dan merupakan bagian yang sangat penting dalam pengembangan perangkat lunak berorientasi objek.



UML terutama menggunakan notasi grafis untuk mengekspresikan desain proyek perangkat lunak. Menggunakan UML membantu tim proyek berkomunikasi, mengeksplorasi proyek potensial, dan memvalidasi desain arsitektur perangkat lunak.



Asal usul UML



Tujuan dari UML adalah untuk memberikan notasi standar yang dapat digunakan oleh semua metode berorientasi objek, dan untuk memilih dan mengintegrasikan elemen terbaik dari notasi pendahulu. UML telah dikembangkan untuk berbagai aplikasi. Akibatnya, ia menyediakan desain untuk berbagai sistem dan kegiatan (misalnya, sistem terdistribusi, analisis, desain, dan penyebaran sistem).



UML tidak muncul dari awal, itu didahului oleh beberapa peristiwa penting, kepribadian dan metodologi. Sebagai contoh:



  • OMT [James Rumbaugh 1991], .
  • Booch [Grady Booch 1994] — . - . , , , , .
  • OOSE (- [Ivar Jacobson 1992]) — , — , , .


Pada tahun 1994 Jim Rambeau, tidak menjadi bingung dengan John Rambo, meskipun Jim juga keren karena dia, untuk sesaat, pencipta teknik pemodelan objek yang disebutkan di atas, mengejutkan dunia perangkat lunak ketika dia meninggalkan General Electric dan bergabung dengan Grady Booch di Rational Corp. Tujuan dari kemitraan ini adalah untuk menggabungkan ide-ide mereka menjadi satu metode tunggal (nama kerja untuk metode itu memang "Metode Terpadu").



Pada 1995, pencipta OOSE, Ivar Jacobson, juga bergabung dengan Rational, dan gagasannya (khususnya konsep "kasus penggunaan") dimasukkan dalam metode terpadu yang baru, yang sekarang disebut Unified Modeling Language.



Berbeda dengan Gang Empat yang terkenal, Tim Rumbo, Buch dan Jacobson dikenal sebagai Tiga Amigos.



UML juga telah dipengaruhi oleh notasi berorientasi objek lainnya:



  • Mellor and Schlaer [1998]
  • Coad dan Yourdon [1995]
  • Wirfs Brock [1990]
  • Martin dan Odell [1992]


UML juga mencakup konsep-konsep baru yang tidak ditemukan dalam metode arus utama lainnya pada saat itu, seperti mekanisme ekstensi dan bahasa kendala.



Mengapa UML?



Ketika nilai strategis perangkat lunak tumbuh bagi banyak perusahaan, industri mencari metode untuk mengotomatisasi produksi perangkat lunak, serta untuk meningkatkan kualitas dan mengurangi biaya dan waktu ke pasar.



Teknik-teknik ini termasuk teknologi komponen, pemrograman visual, template, dan struktur.



Perusahaan juga mencari metode untuk mengelola kompleksitas sistem saat mereka ditingkatkan.



Secara khusus, mereka mengenali kebutuhan untuk mengatasi masalah arsitektur berulang seperti distribusi fisik, konkurensi, replikasi, keamanan, keseimbangan beban, dan toleransi kesalahan.



Selain itu, pengembangan web, sementara menyederhanakan hal-hal, umumnya memperburuk masalah arsitektur ini.



Unified Modeling Language (UML) dikembangkan untuk memenuhi kebutuhan ini.



Tujuan utama desain UML adalah:



  • Memberi pengguna bahasa pemodelan visual ekspresif yang siap pakai sehingga mereka dapat mengembangkan dan berbagi model yang bermakna.
  • Menyediakan mekanisme ekstensibilitas dan spesialisasi untuk memperluas konsep inti.
  • Tidak bergantung pada bahasa pemrograman tertentu dan proses pengembangan.
  • Berikan kerangka kerja formal untuk memahami bahasa pemodelan.
  • Dorong pertumbuhan pasar untuk alat yang berorientasi objek.
  • Dukungan untuk konsep desain tingkat tinggi seperti kolaborasi, struktur, template, dan komponen.
  • Integrasikan praktik terbaik.


Diagram UML dibagi menjadi dua jenis - ini adalah diagram struktural dan diagram perilaku.







Diagram struktural menunjukkan struktur statis sistem dan bagian-bagiannya pada berbagai tingkat abstraksi dan implementasi, serta hubungan mereka. Elemen-elemen dalam diagram struktural mewakili konsep yang bermakna dari sistem dan dapat mencakup abstrak, konsep nyata dan konsep implementasi. Ada tujuh jenis diagram struktur:



  • Diagram struktur komposit
  • Grafik Penempatan
  • Diagram paket
  • Bagan Profil
  • Diagram kelas
  • Diagram objek
  • Diagram komponen


Behavioral diagram menunjukkan perilaku dinamis dari objek dalam sistem, yang dapat digambarkan sebagai serangkaian perubahan dalam sistem dari waktu ke waktu. Dan diagram perilaku meliputi:



  • Bagan aktivitas
  • Gunakan diagram kasus
  • Diagram keadaan
  • Diagram urutan
  • Diagram komunikasi
  • Bagan Ikhtisar Interaksi
  • Bagan waktu


Sekarang beberapa kata tentang masing-masing



Diagram kelas



Diagram kelas adalah teknik pemodelan sentral yang digunakan di hampir semua metode berorientasi objek. Diagram ini menjelaskan jenis-jenis objek dalam sistem dan berbagai jenis hubungan statis yang ada di antara mereka.



Tiga jenis hubungan yang paling penting dalam diagram kelas (sebenarnya ada lebih banyak) adalah:



Asosiasi yang mewakili hubungan antara jenis contoh, misalnya, seseorang bekerja untuk perusahaan, perusahaan memiliki beberapa kantor.



Warisan yang terkait langsung dengan warisan dalam desain Berorientasi Objek.



Agregasi, yang merupakan bentuk komposisi objek dalam desain berorientasi objek.







Diagram komponen



Dalam bahasa pemodelan terpadu, diagram komponen menunjukkan bagaimana komponen berkumpul untuk membentuk komponen yang lebih besar atau sistem perangkat lunak.



Ini menggambarkan arsitektur komponen perangkat lunak dan dependensi di antara mereka.



Komponen perangkat lunak ini termasuk komponen runtime, komponen yang dapat dieksekusi, dan komponen kode sumber.







Grafik Penempatan



Diagram penempatan membantu Anda memodelkan aspek fisik dari sistem perangkat lunak berorientasi objek. Ini adalah diagram blok yang menunjukkan arsitektur sistem sebagai penyebaran (distribusi) artefak perangkat lunak.



Artefak mewakili elemen spesifik dalam dunia fisik yang merupakan hasil dari proses pengembangan.



Diagram memodelkan konfigurasi run-time dalam tampilan statis dan memvisualisasikan distribusi artefak dalam aplikasi.



Dalam kebanyakan kasus, ini melibatkan simulasi konfigurasi perangkat keras bersama dengan komponen perangkat lunak yang menjadi tuan rumah mereka.







Diagram objek



Diagram objek statis adalah turunan dari diagram kelas; ini menunjukkan snapshot status terperinci sistem pada titik waktu tertentu. Perbedaannya adalah bahwa diagram kelas adalah model abstrak yang terdiri dari kelas dan hubungannya.



Namun, diagram objek adalah turunan pada momen tertentu, yang bersifat spesifik.Penggunaan diagram objek agak terbatas, yaitu, untuk menunjukkan contoh struktur data.







Diagram paket



Diagram paket adalah diagram struktural UML yang menunjukkan paket dan dependensi di antara mereka.



Ini memungkinkan Anda untuk menampilkan berbagai tampilan sistem, misalnya, mudah untuk memodelkan aplikasi multi-tier.







Diagram struktur komposit



Diagram struktur komposit mirip dengan diagram kelas dan merupakan semacam diagram komponen yang digunakan terutama dalam pemodelan sistem di tingkat mikro, tetapi diagram itu menggambarkan bagian-bagian individual dan bukan seluruh kelas. Ini adalah jenis diagram struktural statis yang menunjukkan struktur internal kelas dan interaksi yang dimungkinkan oleh struktur ini.



Diagram ini dapat mencakup internal, port tempat bagian-bagian berkomunikasi satu sama lain atau melalui mana instance kelas berinteraksi dengan bagian-bagian dan dengan dunia luar, dan konektor antara bagian-bagian atau port. Struktur komposit adalah kumpulan elemen yang saling terkait yang berinteraksi saat runtime untuk mencapai tujuan. Setiap elemen memiliki peran spesifik dalam kolaborasi.







Bagan Profil



Diagram profil memungkinkan kami untuk membuat stereotip khusus-platform dan spesifik-platform serta menentukan hubungan di antara mereka. Kita dapat membuat stereotip dengan menggambar bentuk stereotip dan menghubungkannya dengan komposisi atau generalisasi melalui antarmuka berorientasi sumber daya. Kami juga dapat mendefinisikan dan memvisualisasikan nilai stereotip.







Gunakan diagram kasus



Diagram use case menggambarkan persyaratan fungsional suatu sistem dalam hal use case. Pada dasarnya, ini adalah model fungsi yang seharusnya dari sistem (preseden) dan lingkungannya (aktor).



Menggunakan case memungkinkan kita untuk menghubungkan apa yang kita butuhkan dari sistem dengan bagaimana sistem memenuhi kebutuhan itu.







Bagan aktivitas



Activity diagram adalah representasi grafis dari alur kerja selangkah demi selangkah dan selangkah demi selangkah dengan dukungan untuk seleksi, iterasi, dan konkurensi.

Mereka menggambarkan aliran kontrol dari sistem target, seperti menjelajahi aturan bisnis yang kompleks dan operasi, dan menggambarkan kasus penggunaan dan proses bisnis.

Dalam UML, diagram aktivitas dirancang untuk mensimulasikan proses komputasi dan organisasi.







Diagram keadaan



State diagram adalah jenis diagram yang digunakan dalam UML untuk menggambarkan perilaku sistem, yang didasarkan pada konsep diagram keadaan David Harel. State diagram menunjukkan status dan transisi yang diaktifkan, dan peristiwa yang memengaruhi transisi tersebut. Ini membantu untuk memvisualisasikan seluruh siklus hidup objek dan, dengan demikian, membantu untuk lebih memahami sistem berbasis negara.







Diagram urutan



Diagram urutan memodelkan interaksi objek berdasarkan urutan waktu. Ini menunjukkan bagaimana beberapa objek berinteraksi dengan yang lain dalam kasus penggunaan tertentu.







Diagram Komunikasi



Seperti diagram urutan, diagram komunikasi juga digunakan untuk memodelkan perilaku dinamis dari use case. Dibandingkan dengan diagram urutan, diagram komunikasi lebih fokus untuk menunjukkan interaksi objek, daripada urutan waktu. Bahkan, diagram komunikasi dan diagram urutan secara semantik setara dan dapat mengalir satu sama lain.







Bagan Ikhtisar Interaksi



Diagram ikhtisar interaksi berfokus pada ikhtisar aliran manajemen interaksi. Ini adalah varian dari Diagram Aktivitas di mana node adalah interaksi atau peristiwa interaksi. Diagram ikhtisar interaksi menggambarkan interaksi di mana pesan dan jalur kehidupan disembunyikan. Kita dapat menautkan diagram "nyata" dan mencapai navigasi tingkat tinggi antara diagram dalam diagram ikhtisar interaksi.







Bagan waktu



Diagram waktu menunjukkan perilaku objek pada periode waktu tertentu. Sebenarnya, ini adalah bentuk khusus dari diagram urutan dan perbedaan di antara mereka adalah bahwa sumbu ditukar sehingga waktu meningkat dari kiri ke kanan, dan garis kehidupan ditampilkan dalam kompartemen terpisah yang terletak secara vertikal.











Mengapa ada begitu banyak diagram di UML?



Alasan untuk ini adalah bahwa Anda dapat melihat sistem dari sudut pandang yang berbeda, karena banyak pemangku kepentingan akan terlibat dalam pengembangan perangkat lunak, seperti: analis, desainer, pembuat kode, penguji, kontrol kualitas, pelanggan, penulis teknis.







Semua orang ini tertarik pada berbagai aspek sistem, dan masing-masing memerlukan tingkat detail yang berbeda.



Misalnya, pembuat kode harus memahami desain sistem dan dapat mengubah desain menjadi kode tingkat rendah.



Sebaliknya, seorang penulis teknis tertarik pada perilaku sistem secara keseluruhan dan harus memahami bagaimana fungsi produk.



UML mencoba menyediakan bahasa dengan cara yang sedemikian ekspresif sehingga semua pemangku kepentingan dapat memperoleh manfaat dari setidaknya satu diagram UML.



Bagi mereka yang terlalu malas untuk membaca:





Ave!



All Articles