Apa itu UML?
Jika Anda melihat gambar di mesin pencari, menjadi jelas bahwa UML- ini adalah sesuatu tentang skema, panah, dan kotak. Yang penting UML diterjemahkan sebagai Bahasa Pemodelan Terpadu. Kata Unified penting di sini. Artinya, gambar kita akan dipahami tidak hanya oleh kita, tetapi juga oleh orang lain yang mengenal UML. Ternyata ini adalah bahasa internasional untuk menggambar diagram.
Seperti yang dikatakan Wikipedia
UML adalah bahasa deskripsi grafis untuk pemodelan objek di bidang pengembangan perangkat lunak, pemodelan proses bisnis, rekayasa sistem, dan pemetaan struktur organisasi.Hal paling menarik yang tidak semua orang pikirkan atau tebak adalah bahwa UML memiliki spesifikasi. Apalagi ada spesifikasi UML2. Informasi lebih lanjut tentang spesifikasi dapat ditemukan di situs web Grup Manajemen Objek. Sebenarnya grup ini bergerak di bidang pengembangan spesifikasi UML. Menarik juga bahwa UML tidak terbatas pada penggambaran struktur kelas. Ada banyak jenis diagram UML. Deskripsi singkat tentang jenis-jenis diagram UML dapat dilihat di Wikipedia yang sama: diagram UML atau di video Timur Batyrshinov Gambaran Umum Diagram UML. UML juga banyak digunakan dalam menggambarkan berbagai proses, misalnya di sini: Single sign-on menggunakan JWT. Kembali ke penggunaan diagram kelas UML, perlu dicatat buku Head First: Design Patterns, di mana pola diilustrasikan oleh diagram UML yang sama. Ternyata UML memang sedang digunakan. Dan ternyata mengetahui dan memahami penerapannya merupakan keterampilan yang cukup berguna.
Aplikasi
Mari kita lihat bagaimana Anda dapat bekerja dengan UML ini dari IDE. Sebagai IDE, ambil Ide IntelliJ. Jika digunakan IntelliJ Ide Ultimate, maka kita akan menginstal plugin "di luar kotak" Dukungan UML". Ini memungkinkan Anda untuk secara otomatis menghasilkan diagram kelas yang indah. Misalnya, melalui Ctrl + N atau item menu "Navigasi" -> "Kelas" buka kelas Daftar Array. Sekarang, melalui menu konteks dengan nama kelas, pilih "Diagram" -> "Show diagram popup". Hasilnya, kami mendapatkan bagan yang indah:
Tetapi bagaimana jika Anda ingin menggambar sendiri, dan bahkan tidak ada Ide versi Ultimate? Jika kita menggunakan IntelliJ Idea Community Edition, maka kita tidak punya pilihan lain. Untuk melakukan ini, Anda perlu memahami cara kerja skema UML seperti itu. Pertama kita perlu menginstal Graphviz . Ini adalah satu set utilitas visualisasi grafik. Itu digunakan oleh plugin yang akan kita gunakan. Setelah instalasi, Anda perlu menambahkan direktori tempat sampah dari direktori yang diinstal grafikviz ke variabel lingkungan JALUR. Setelah itu, di IntelliJ Idea, pilih File -> Settings dari menu. Di jendela "Pengaturan", pilih kategori "Plugin", klik tombol "Jelajahi repositori" dan instal plugin integrasi PlantUML. Kenapa yang ini bagus banget TanamanUML? Ini menggunakan bahasa deskripsi grafik yang disebut " dot dan ini memungkinkan untuk lebih universal, karena bahasa ini digunakan tidak hanya oleh PlantUML. Apalagi semua yang akan kita lakukan di bawah ini tidak hanya dapat dilakukan di IDE, tetapi juga di layanan online planttext.com. Setelah menginstal Plugin PlantUML, kita akan dapat membuat diagram UML melalui "File" -> "New". Mari kita buat diagram tipe "UML class". Selama ini, template dengan contoh dibuat secara otomatis. Mari hapus kontennya dan buat sendiri, dipersenjatai dengan artikel dari Habr: Hubungan Kelas - dari UML ke kode... Dan untuk memahami bagaimana menggambarkan ini dalam teks, mari kita ambil manual PlantUML: plantuml class-diagram... Di dalamnya, di sangat awal, ada tanda dengan cara menggambarkan hubungan:
Soal koneksinya sendiri, kita masih bisa mengintip di sini: “Hubungan antar kelas di UML. Contohnya”. Berdasarkan materi ini, mari kita mulai membuat diagram UML kita. Tambahkan konten berikut yang menjelaskan dua kelas: @startuml class ArrayList ( ) class LinkedList ( ) @enduml Untuk melihat hasil di Idea, pilih "View" -> "Tool Windows" -> "PlantUML". Kami hanya akan mendapatkan dua kotak yang menunjukkan kelas. Seperti yang kita ketahui, kedua kelas ini mengimplementasikan antarmuka Daftar. Hubungan kelas ini disebut - implementasi (realisasi). Panah dengan garis putus-putus digunakan untuk menggambarkan hubungan semacam itu. Mari kita menggambarnya: Antarmuka Daftar Daftar< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о paket pribadi elemen array: ~ Object elementData Sekarang kita ingin menunjukkan bahwa ArrayList berisi beberapa objek. Dalam hal ini, jenis koneksi adalah - pengumpulan(pengumpulan). Agregat dalam hal ini adalah ArrayList , karena itu berisi objek lain. Kami memilih agregasi karena objek dalam daftar dapat hidup tanpa daftar: mereka bukan bagian integral darinya. Seumur hidup mereka tidak terikat dengan umur daftar. Satuan dari bahasa Latin diterjemahkan sebagai "dikumpulkan", yaitu sesuatu yang terdiri dari sesuatu. Misalnya, dalam kehidupan, ada unit pemompaan, yang terdiri dari pompa dan mesin. Unit itu sendiri dapat dibongkar, meninggalkan beberapa komponennya. Misalnya, untuk dijual atau dimasukkan ke dalam unit lain. Jadi ada di daftar. Dan ini dinyatakan dalam bentuk belah ketupat kosong pada satuan dan garis kontinu. Mari kita begini: class Object ( ) ArrayList o- Object Sekarang kita ingin menunjukkan bahwa, tidak seperti ArrayList , class LinkedList berisi kontainer Node yang merujuk ke data yang disimpan. Dalam hal ini, Node adalah bagian dari LinkedList itu sendiri dan tidak dapat hidup secara terpisah. Node tidak secara langsung menyimpan konten, tetapi hanya berisi referensi untuk itu. Misalnya, ketika kita menambahkan baris ke LinkedList, kita menambahkan Node baru yang berisi link ke baris itu, serta link ke Node sebelumnya dan berikutnya. Jenis koneksi ini disebut komposisi(komposisi). Untuk menampilkan komposit (yang terdiri dari bagian-bagian), robic yang diisi digambar, garis kontinu mengarah ke sana. Sekarang mari kita tulis ini sebagai tampilan teks dari tautan: class Node ( ) LinkedList * -- Node Dan sekarang kita perlu mempelajari cara menampilkan jenis tautan penting lainnya - kecanduan(hubungan ketergantungan). Ini digunakan ketika satu kelas menggunakan yang lain, sedangkan kelas tidak berisi kelas yang digunakan dan bukan penggantinya. Misalnya, LinkedList dan ArrayList dapat membuat ListIterator . Mari kita tampilkan ini sebagai panah putus-putus: class ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:
Anda dapat merinci sebanyak yang Anda butuhkan. Semua sebutan tercantum di sini: "PlantUML - Diagram Kelas". Selain itu, tidak ada yang supernatural dalam menggambar skema seperti itu, dan saat mengerjakan tugas Anda, Anda dapat dengan cepat menggambarnya dengan tangan. Ini akan mengembangkan keterampilan berpikir arsitektur aplikasi Anda dan membantu Anda menemukan kelemahan struktur kelas sejak dini, bukan setelah Anda menghabiskan waktu seharian menerapkan model yang salah. Saya pikir itu alasan yang bagus untuk mencobanya?)
Otomatisasi
Ada berbagai cara untuk menghasilkan diagram PlantUML secara otomatis. Misalnya, di ide ide Ada plugin SketchIT, tetapi tidak menggambarnya dengan benar. Misalnya, implementasi antarmuka digambar secara tidak benar (ditampilkan sebagai pewarisan). Ada juga contoh online tentang bagaimana memasukkan ini ke dalam siklus hidup pembangunan proyek Anda. Katakanlah untuk Maven ada contoh menggunakan uml-Java-docklet . Untuk menunjukkan bagaimana ini dilakukan, mari gunakan Pola Dasar Maven untuk membuat proyek Maven dengan cepat. Mari kita jalankan perintah: mvn archetype:generate Pada pertanyaan memilih filter ( Pilih nomor atau terapkan filter) biarkan default hanya dengan menekan Enter. Itu akan selalu" maven-arketipe-quickstart". Kami memilih versi terbaru. Selanjutnya, jawab pertanyaan dan selesaikan pembuatan proyek:
Karena Maven bukan fokus artikel ini, jawaban atas pertanyaan Anda tentang Maven dapat ditemukan di Pusat Pengguna Maven . Dalam proyek yang dihasilkan, buka file deskripsi proyek untuk diedit, pom.xml. Kami akan menyalin konten dari deskripsi pemasangan uml-java-docklet ke dalamnya. Artefak yang digunakan dalam deskripsi tidak dapat ditemukan di repositori Maven Central. Tapi itu berhasil bagi saya dengan ini: https://mvnrepository.com/artifact/com.chfourie/uml-Java-doclet/1.0.0 . Artinya, dalam deskripsi itu Anda hanya perlu mengganti ID grup dari " info.leadinglight" pada " com.chfourie" dan masukkan versi " 1.0.0 ". Setelah itu, kita bisa mengeksekusi di direktori tempat file tersebut berada pom.xml perintah ini adalah: mvn clean install dan mvn javadoc:javadoc . Sekarang, jika kita membuka dokumentasi yang dihasilkan (explorer target\site\apidocs\index.html), kita akan melihat diagram UML. Omong-omong, implementasinya sudah ditampilkan dengan benar di sini)
Kesimpulan
Seperti yang Anda lihat, UML memungkinkan Anda untuk memvisualisasikan struktur aplikasi Anda. Juga, UML tidak terbatas hanya itu. Dengan bantuan UML, Anda dapat menggambarkan berbagai proses dalam perusahaan Anda atau menggambarkan proses bisnis di mana fungsi yang Anda tulis bekerja. Terserah Anda untuk memutuskan seberapa banyak UML berguna bagi Anda secara pribadi, tetapi akan berguna untuk menemukan waktu dan mengenalnya lebih detail pula. #Viacheslav versi Rusia dari posting ini: Diagram UML Java di CodeGymAnotasi: Mata kuliah ini adalah UML - Unified Modeling Language. Pada kuliah sebelumnya, kita telah membahas tentang apa itu UML, sejarahnya, tujuan, cara penggunaan bahasanya, struktur definisinya, terminologi dan notasinya. Telah dicatat bahwa model UML adalah satu set diagram. Dalam kuliah ini, kita akan mempertimbangkan pertanyaan-pertanyaan seperti: mengapa kita membutuhkan beberapa jenis diagram; jenis diagram; OOP dan diagram urutan
Sebelum beralih ke pembahasan materi utama kuliah ini, mari kita bahas dulu kenapa membangun diagram sama sekali. Pengembangan model sistem apa pun (tidak hanya perangkat lunak) selalu mendahului pembuatan atau pembaruannya. Ini diperlukan setidaknya untuk lebih jelas membayangkan masalah yang sedang dipecahkan. Model bijaksana sangat penting baik untuk interaksi dalam tim pengembangan dan untuk saling pengertian dengan pelanggan. Bagaimanapun, ini memungkinkan Anda untuk memastikan bahwa proyek "konsisten secara arsitektur" sebelum diimplementasikan dalam kode.
Kami membangun model sistem yang kompleks karena kami tidak dapat menggambarkannya sepenuhnya, "lihat sekilas". Oleh karena itu, kami hanya memilih properti sistem yang penting untuk tugas tertentu dan membangun modelnya yang mencerminkan properti ini. Metode analisis berorientasi objek memungkinkan untuk menggambarkan sistem kompleks nyata dengan cara yang paling memadai. Tetapi ketika sistem menjadi lebih kompleks, ada kebutuhan untuk teknologi simulasi yang baik. Seperti yang kami katakan di kuliah sebelumnya, sistem terpadu digunakan sebagai teknologi "standar". bahasa pemodelan(Unified Modeling Language, UML), yang merupakan bahasa grafis untuk spesifikasi, visualisasi, desain, dan dokumentasi sistem. Dengan menggunakan UML, Anda dapat mengembangkan model terperinci dari sistem yang sedang dibuat, yang tidak hanya mencerminkan konsepnya, tetapi juga fitur implementasi yang spesifik. Dalam kerangka model UML, semua representasi tentang sistem ditetapkan dalam bentuk konstruksi grafik khusus yang disebut diagram.
Catatan. Kami tidak akan mempertimbangkan semua, tetapi hanya beberapa jenis grafik. Misalnya, diagram komponen tidak tercakup dalam kuliah ini, yang hanya merupakan gambaran singkat tentang jenis diagram. Jumlah jenis bagan untuk model aplikasi tertentu tidak dibatasi dengan cara apa pun. Untuk aplikasi sederhana, tidak perlu membangun semua jenis diagram tanpa kecuali. Beberapa dari mereka mungkin hilang begitu saja, dan fakta ini tidak akan dianggap sebagai kesalahan. Penting untuk dipahami bahwa ketersediaan diagram jenis tertentu tergantung pada spesifikasi proyek tertentu. Informasi tentang jenis diagram lainnya (tidak dibahas di sini) dapat ditemukan dalam standar UML.
Mengapa Anda Membutuhkan Beberapa Jenis Grafik
Pertama, mari kita definisikan terminologi. Dalam pengantar kuliah ini, kami berulang kali menggunakan konsep sistem, model, dan diagram. Penulis yakin bahwa kita masing-masing secara intuitif memahami arti dari konsep-konsep ini, tetapi untuk membuatnya lebih jelas, mari kita lihat lagi glosarium dan baca yang berikut ini:
Sistem- satu set subsistem terkontrol yang saling berhubungan yang disatukan oleh tujuan fungsi yang sama.
Ya, tidak terlalu informatif. Lalu apa itu subsistem? Untuk memperjelas situasinya, mari kita beralih ke klasik:
sistem panggilan satu set subsistem terorganisir untuk mencapai tujuan tertentu dan dijelaskan menggunakan satu set model, mungkin dari sudut pandang yang berbeda.
Nah, tidak ada yang dapat Anda lakukan, Anda harus mencari definisi subsistem. Di sana juga dikatakan bahwa subsistem adalah satu set elemen, beberapa di antaranya menentukan perilaku elemen lainnya. Ian Sommerville menjelaskan konsepnya seperti ini:
Subsistem adalah sistem yang fungsinya tidak bergantung pada layanan subsistem lain. Sistem perangkat lunak disusun sebagai satu set subsistem yang relatif independen. Interaksi antar subsistem juga didefinisikan.
Juga tidak terlalu jelas, tetapi lebih baik. Berbicara dalam bahasa "manusia", sistem direpresentasikan sebagai seperangkat entitas sederhana yang relatif mandiri. Ini dapat dibandingkan dengan bagaimana, dalam proses pengembangan program, kami membangun antarmuka grafis dari "kubus" standar - komponen visual, atau bagaimana teks program itu sendiri juga dibagi menjadi modul yang berisi subrutin yang digabungkan sesuai dengan fungsi fitur, dan mereka dapat digunakan kembali, dalam program berikut.
Memahami konsep sistem. Selama proses desain, sistem dipertimbangkan dari sudut pandang yang berbeda dengan bantuan model, berbagai representasi yang muncul dalam bentuk diagram. Sekali lagi, pembaca mungkin memiliki pertanyaan tentang arti dari konsep-konsep tersebut model Dan diagram. Kami pikir definisi yang indah, tetapi tidak terlalu jelas model sebagai abstraksi sistem yang tertutup secara semantik tidak mungkin untuk memperjelas situasi, jadi mari kita coba jelaskan "dengan kata-kata kita sendiri."
Model- ini adalah objek tertentu (materi atau tidak) yang hanya menampilkan karakteristik paling signifikan dari sistem untuk tugas ini. Modelnya berbeda - berwujud dan tidak berwujud, buatan dan alami, dekoratif dan matematis ...
Mari kita berikan beberapa contoh. Mobil mainan plastik yang akrab bagi kita semua, yang kita mainkan dengan penuh semangat di masa kecil, tidak lebih dari bahan dekoratif buatan model mobil nyata. Tentu saja, di "mobil" seperti itu tidak ada mesin, kami tidak mengisi tangkinya dengan bensin, gearbox tidak berfungsi di dalamnya (apalagi, tidak ada sama sekali), tetapi sebagai model, mainan ini sepenuhnya memenuhi fungsinya fungsi: memberikan gambaran kepada anak tentang mobil, karena menampilkan ciri khasnya adalah adanya roda empat, bodi, pintu, jendela, kemampuan mengemudi, dll.
Dalam penelitian medis, pengujian hewan sering mendahului uji klinis obat pada manusia. Dalam hal ini, hewan bertindak sebagai bahan alami model manusia.
Persamaan yang ditunjukkan di atas juga merupakan model, tetapi ini adalah model matematika, dan ini menggambarkan pergerakan titik material di bawah aksi gravitasi.
Tetap hanya untuk mengatakan apa itu diagram. Diagram adalah representasi grafis dari satu set elemen. Biasanya digambarkan sebagai graf dengan simpul (entitas) dan sisi (hubungan). Ada banyak contoh diagram. Ini adalah diagram blok yang akrab bagi kita semua dari tahun-tahun sekolah, dan diagram instalasi untuk berbagai peralatan yang dapat kita lihat di manual pengguna, dan pohon file dan direktori pada disk, yang dapat kita lihat dengan menjalankan perintah pohon di Konsol Windows, dan banyak lagi lainnya. Dalam kehidupan sehari-hari, diagram mengelilingi kita dari semua sisi, karena gambar lebih mudah kita pahami daripada teks...
Tetapi kembali ke desain perangkat lunak (dan tidak hanya). Dalam industri ini sejak menggunakan diagram, Anda dapat memvisualisasikan sistem dari berbagai sudut pandang. Salah satu diagram, misalnya, dapat menggambarkan interaksi pengguna dengan sistem, yang lain - perubahan status sistem selama operasinya, yang ketiga - interaksi antara elemen sistem, dll. Kompleks sistem dapat dan harus direpresentasikan sebagai satu set model kecil dan hampir independen - diagram, dan tidak satupun dari mereka cukup untuk menggambarkan sistem dan mendapatkan gambaran yang lengkap, karena masing-masing berfokus pada beberapa aspek tertentu dari fungsi sistem. sistem dan menyatakan yang berbeda tingkat abstraksi. Dengan kata lain, setiap model sesuai dengan beberapa sudut pandang tertentu pada sistem yang dirancang.
Terlepas dari kenyataan bahwa pada paragraf sebelumnya kita sangat longgar dengan konsep model, perlu dipahami bahwa dalam konteks definisi di atas tidak ada diagram tunggal yang menjadi model. Diagram hanyalah sarana untuk memvisualisasikan model, dan keduanya harus dibedakan. Hanya satu set diagram merupakan model sistem dan menggambarkannya secara lengkap, tetapi tidak ada satu diagram pun yang keluar dari konteks.
Jenis grafik
UML 1.5 didefinisikan dua belas jenis grafik dibagi menjadi tiga kelompok:
- empat jenis diagram mewakili struktur statis aplikasi;
- lima mewakili aspek perilaku sistem;
- tiga mewakili aspek fisik operasi sistem (diagram implementasi).
Versi UML 2.1 saat ini tidak membuat terlalu banyak perubahan. Tampilan diagram sedikit berubah (bingkai dan peningkatan visual lainnya telah muncul), notasi sedikit meningkat, beberapa diagram telah menerima nama baru.
Namun, jumlah pastinya diagram kanonik itu sama sekali tidak penting bagi kami, karena kami tidak akan mempertimbangkan semuanya, tetapi hanya beberapa - karena jumlah jenis diagram untuk model tertentu dari aplikasi tertentu tidak tetap. Untuk aplikasi sederhana, tidak perlu membangun semua diagram tanpa kecuali. Misalnya, untuk aplikasi lokal, tidak perlu membuat diagram penerapan. Penting untuk dipahami bahwa daftar diagram bergantung pada spesifikasi proyek yang sedang dikembangkan dan ditentukan oleh pengembang itu sendiri. Jika pembaca yang penasaran masih ingin tahu tentang semua diagram UML, kami akan merujuknya ke standar UML (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Ingatlah bahwa tujuan kursus ini bukan untuk menggambarkan secara mutlak semua kemungkinan UML, tetapi hanya untuk memperkenalkan bahasa ini, untuk memberikan ide awal tentang teknologi ini.
Jadi, kita akan melihat secara singkat jenis grafik seperti:
- Gunakan diagram kasus;
- diagram kelas;
- diagram objek;
- diagram urutan;
- diagram interaksi;
- diagram negara;
- diagram aktivitas;
- diagram penyebaran.
Kami akan berbicara tentang beberapa diagram ini secara lebih rinci dalam kuliah berikutnya. Untuk saat ini, kami tidak akan fokus pada detailnya, tetapi menetapkan tujuan mengajar pembaca untuk setidaknya membedakan secara visual antara jenis diagram, untuk memberikan ide awal tentang tujuan jenis utama diagram. Jadi, mari kita mulai.
Gunakan diagram kasus
Setiap sistem (termasuk perangkat lunak) dirancang dengan mempertimbangkan fakta bahwa selama bekerja, sistem tersebut akan digunakan oleh orang dan/atau berinteraksi dengan sistem lain. Entitas yang berinteraksi dengan sistem selama kerjanya disebut aktor, dan setiap aktor mengharapkan sistem untuk berperilaku dengan cara yang ditentukan secara ketat dan dapat diprediksi. Mari kita coba memberikan definisi yang lebih ketat tentang sebuah ector. Untuk melakukan ini, kami menggunakan kosakata visual yang luar biasa untuk UML Mentor Zicom:
Hector (aktor)- ini adalah seperangkat peran yang terkait secara logis yang dilakukan saat berinteraksi dengan preseden atau entitas (sistem, subsistem, atau kelas). Seorang aktor dapat menjadi orang atau sistem lain, subsistem atau kelas yang mewakili sesuatu di luar entitas.
Secara grafis, vektor digambarkan baik " orang kecil", mirip dengan yang kami gambar di masa kecil, menggambarkan anggota keluarga kami, atau simbol kelas dengan stereotip yang sesuai, seperti yang ditunjukkan pada gambar. Kedua bentuk penyajian tersebut memiliki arti yang sama dan dapat digunakan dalam diagram. Bentuk "stereotip" lebih sering digunakan untuk mewakili aktor sistem atau dalam kasus di mana aktor memiliki properti yang perlu ditampilkan (Gbr. 2.1).
Pembaca yang penuh perhatian dapat langsung mengajukan pertanyaan: Mengapa hector dan bukan aktor?? Kami setuju, kata "ektor" sedikit memotong telinga orang Rusia. Alasan mengapa kami mengatakan ini sederhana - ector dibentuk dari kata tindakan, yang artinya dalam terjemahan tindakan. Terjemahan harfiah dari kata "ektor" - aktor- terlalu lama dan tidak nyaman digunakan. Karena itu, kami akan terus mengatakannya.
Beras. 2.1.
Pembaca penuh perhatian yang sama dapat melihat kata "preseden" muncul dalam definisi ector. Apa itu? Pertanyaan ini akan lebih menarik bagi kita jika kita ingat bahwa kita sedang membicarakannya Gunakan diagram kasus. Jadi,
Preseden (kasus penggunaan)- deskripsi aspek tertentu dari perilaku sistem dari sudut pandang pengguna (Butch).
Definisinya cukup dapat dimengerti dan lengkap, tetapi dapat disempurnakan lebih lanjut dengan menggunakan yang sama Mentor Zicom"om:
kasus penggunaan- deskripsi rangkaian kejadian yang berurutan (termasuk varian) yang dilakukan oleh sistem yang mengarah pada hasil yang diamati oleh aktor. Sebuah use case mewakili perilaku suatu entitas dengan menggambarkan interaksi antara aktor dan sistem. Sebuah preseden tidak menunjukkan "bagaimana" hasil tertentu dicapai, tetapi hanya "apa" itu.
Preseden ditunjukkan dengan cara yang sangat sederhana - dalam bentuk elips, di mana namanya ditunjukkan. Use case dan aktor terhubung dengan garis. Seringkali di salah satu ujung garis menggambarkan nasi. 2.3
UML sekarang menjadi notasi standar untuk pemodelan visual sistem perangkat lunak, diadopsi oleh Object Managing Group (OMG) pada musim gugur 1997 dan didukung oleh banyak produk CASE berorientasi objek.
Standar UML menawarkan rangkaian diagram berikut untuk pemodelan:
Use case diagram (use case diagram) - untuk memodelkan proses bisnis suatu organisasi atau perusahaan dan menentukan persyaratan untuk sistem informasi yang sedang dibuat;
diagram kelas (diagram kelas) - untuk memodelkan struktur statis kelas sistem dan hubungan di antara mereka;
diagram perilaku sistem (behavior diagram);
diagram interaksi;
Diagram urutan - untuk memodelkan proses pengiriman pesan antar objek dalam satu kasus penggunaan;
diagram kolaborasi (diagram kolaborasi) - untuk memodelkan proses pengiriman pesan antar objek dalam kasus penggunaan yang sama;
diagram statechart - untuk memodelkan perilaku objek sistem selama transisi dari satu keadaan ke keadaan lain;
diagram aktivitas - untuk memodelkan perilaku sistem dalam kerangka berbagai kasus penggunaan, atau aktivitas pemodelan;
diagram implementasi (diagram implementasi):
Diagram komponen (component diagram) - untuk memodelkan hierarki komponen (subsistem) dari sistem informasi;
diagram penyebaran (diagram penyebaran) - untuk memodelkan arsitektur fisik dari sistem informasi yang dirancang.
pada gambar. 1.1 menyajikan model terintegrasi dari sistem informasi, termasuk diagram utama yang akan dikembangkan dalam proyek kursus ini.
Beras. 1. Model terintegrasi dari sistem informasi dalam notasi bahasa UML
4.2. Gunakan diagram kasus
Use case adalah urutan tindakan yang dilakukan oleh sistem dalam menanggapi suatu peristiwa yang dipicu oleh beberapa objek eksternal (aktor). Sebuah use case menggambarkan interaksi khas antara pengguna dan sistem. Dalam kasus yang paling sederhana, use case ditentukan dalam proses diskusi dengan pengguna tentang fungsi-fungsi yang ingin dia implementasikan dalam sistem informasi ini. Dalam UML, use case digambarkan sebagai berikut:
Gbr.2. Gunakan kasus
Aktor adalah peran yang dimainkan pengguna dalam kaitannya dengan sistem. Aktor mewakili peran, bukan orang atau jabatan tertentu. Meskipun digambarkan sebagai figur manusia dalam use case diagram, aktor juga dapat menjadi sistem informasi eksternal yang membutuhkan beberapa informasi dari sistem. Anda hanya boleh menunjukkan aktor dalam diagram ketika mereka benar-benar membutuhkan beberapa kasus penggunaan. Dalam UML, aktor direpresentasikan sebagai bentuk:
Gbr.3. Karakter (aktor)
Aktor dibagi menjadi tiga jenis utama:
Pengguna
sistem;
Sistem lain yang berinteraksi dengan yang satu ini;
Waktu menjadi aktor jika pemicu setiap peristiwa dalam sistem bergantung padanya.
4.2.1. Hubungan Antara Use Case dan Aktor
Dalam UML, use case diagram mendukung beberapa jenis hubungan antar elemen diagram:
Komunikasi (komunikasi),
Penyertaan (termasuk),
ekstensi (memperpanjang),
generalisasi.
komunikasi komunikasi adalah hubungan antara use case dan aktor. Di UML, tautan komunikasi ditampilkan menggunakan asosiasi satu arah (garis padat).
Gbr.4. Contoh tautan komunikasi
Koneksi inklusi digunakan dalam situasi di mana ada beberapa bagian dari perilaku sistem yang diulang di lebih dari satu kasus penggunaan. Dengan bantuan tautan semacam itu, fungsi yang dapat digunakan kembali biasanya dimodelkan.
Koneksi ekstensi digunakan untuk menggambarkan perubahan perilaku normal suatu sistem. Ini memungkinkan satu use case untuk menggunakan fungsionalitas use case lain saat dibutuhkan.
Gbr.5. Contoh hubungan inklusi dan ekstensi
Generalisasi komunikasi menunjukkan bahwa beberapa aktor atau kelas memiliki sifat yang sama.
Gbr.6. Contoh hubungan generalisasi
4.3.
diagram interaksi menggambarkan perilaku kelompok objek yang berinteraksi. Biasanya, diagram interaksi hanya mencakup perilaku objek dalam satu kasus penggunaan. Diagram seperti itu menampilkan sejumlah objek dan pesan yang mereka tukarkan satu sama lain.
pesan adalah sarana dimana objek pengirim meminta objek penerima untuk melakukan salah satu operasinya.
Pesan informasi (informatif) adalah pesan yang menyediakan objek penerima dengan beberapa informasi untuk memperbarui statusnya.
Pesan permintaan (interogatif) adalah pesan yang meminta keluaran dari beberapa informasi tentang objek penerima.
Pesan penting adalah pesan yang meminta penerima untuk melakukan beberapa tindakan.
Ada dua jenis diagram interaksi: diagram urutan dan diagram kolaborasi.
4.3.1. Diagram urutan
diagram urutan mencerminkan aliran peristiwa yang terjadi dalam kasus penggunaan tunggal.
Semua aktor (aktor, kelas, atau objek) yang terlibat dalam skenario tertentu (use case) ditampilkan di bagian atas diagram. Panah sesuai dengan pesan yang dikirimkan antara aktor dan objek, atau antara objek untuk melakukan fungsi yang diperlukan.
Dalam diagram urutan, objek digambarkan sebagai persegi panjang, dari mana garis vertikal putus-putus ditarik ke bawah. Garis ini disebut garis hidup suatu objek . Ini adalah fragmen dari siklus hidup suatu objek dalam proses interaksi.
Setiap pesan direpresentasikan sebagai panah di antara garis hidup dua objek. Pesan muncul dalam urutan kemunculannya di halaman dari atas ke bawah. Setiap pesan ditandai dengan setidaknya nama pesan. Secara opsional, Anda juga dapat menambahkan argumen dan beberapa informasi kontrol. Anda dapat menunjukkan delegasi diri, pesan yang dikirim oleh objek ke dirinya sendiri, dengan panah pesan menunjuk ke garis hidup yang sama.
Beras. 7. Contoh Diagram Urutan
4.3.2. Diagram kolaborasi
Diagram Kerjasama menampilkan aliran peristiwa dalam skenario tertentu (use case). Pesan diurutkan berdasarkan waktu, meskipun diagram kolaborasi lebih fokus pada hubungan antar objek. Diagram kolaborasi menunjukkan semua informasi yang dimiliki diagram urutan, tetapi diagram kolaborasi menggambarkan aliran peristiwa dengan cara yang berbeda. Dari situ lebih mudah untuk memahami hubungan yang ada antar objek.
Dalam diagram kolaborasi, seperti dalam diagram urutan, panah mewakili pesan yang dipertukarkan dalam kasus penggunaan yang diberikan. Urutan waktu mereka ditunjukkan dengan penomoran pesan.
Beras. 8. Contoh diagram kerjasama
4.4. diagram kelas
4.4.1. Informasi Umum
diagram kelas mendefinisikan jenis kelas sistem dan berbagai jenis tautan statis yang ada di antara mereka. Diagram kelas juga menunjukkan atribut kelas, operasi kelas, dan batasan yang ditempatkan pada hubungan antar kelas.
Diagram kelas dalam UML adalah grafik yang simpulnya adalah elemen dari struktur statis proyek (kelas, antarmuka), dan busur adalah hubungan antara simpul (asosiasi, pewarisan, dependensi).
Diagram kelas menunjukkan elemen-elemen berikut:
· Paket (paket) - satu set elemen model, secara logis terkait satu sama lain;
· Kelas (kelas) - deskripsi properti umum dari sekelompok objek serupa;
· Antarmuka (antarmuka) - kelas abstrak yang menentukan serangkaian operasi yang disediakan oleh objek dari kelas arbitrer yang terkait dengan antarmuka yang diberikan ke objek lain.
4.4.2. Kelas
Kelas adalah sekelompok entitas (objek) yang memiliki kesamaan sifat, yaitu data dan perilaku. Anggota individu dari kelas disebut objek kelas, atau hanya objek.
Perilaku objek dalam UML mengacu pada aturan apa pun untuk interaksi objek dengan dunia luar dan dengan data objek itu sendiri.
Dalam diagram, kelas digambarkan sebagai persegi panjang dengan batas padat, dibagi dengan garis horizontal menjadi 3 bagian:
Bagian atas (bagian nama) berisi nama kelas dan properti umum lainnya (khususnya, stereotip).
Bagian tengah berisi daftar atribut
Di bagian bawah adalah daftar operasi kelas yang mencerminkan perilakunya (tindakan yang dilakukan oleh kelas).
Atribut dan bagian operasi mana pun mungkin tidak ditampilkan (atau keduanya). Untuk bagian yang hilang, Anda tidak perlu menggambar garis pemisah dan entah bagaimana menunjukkan ada atau tidaknya elemen di dalamnya.
Bagian tambahan, seperti Pengecualian, dapat diperkenalkan pada kebijaksanaan implementasi tertentu.
Beras. 9. Contoh Diagram Kelas
4.4.2.1.Stereotip kelas
Stereotyping kelas adalah mekanisme untuk mengklasifikasikan kelas ke dalam kategori.
UML mendefinisikan tiga stereotip kelas utama:
Batas (border);
Entitas (entitas);
Pengendalian (manajemen).
4.4.2.2.Kelas batas
Kelas batas adalah kelas-kelas yang terletak pada batas sistem dan seluruh lingkungan. Ini adalah tampilan, laporan, antarmuka dengan perangkat keras (seperti printer atau pemindai), dan antarmuka dengan sistem lain.
Untuk menemukan kelas batas, Anda perlu menjelajahi diagram use case. Setiap interaksi antara aktor dan use case harus memiliki setidaknya satu kelas batas. Kelas inilah yang memungkinkan aktor untuk berinteraksi dengan sistem.
4.4.2.3.Kelas entitas
Kelas entitas berisi informasi yang disimpan. Mereka memiliki arti terbesar bagi pengguna, dan karena itu nama mereka sering menggunakan istilah dari area subjek. Biasanya, untuk setiap kelas entitas, sebuah tabel dibuat dalam database.
4.4.2.4.Kelas kontrol
Kelas kontrol bertanggung jawab untuk mengoordinasikan tindakan kelas lain. Biasanya, setiap use case memiliki satu kelas kontrol yang mengontrol urutan kejadian untuk use case tersebut. Kelas kontrol bertanggung jawab untuk koordinasi, tetapi tidak membawa fungsionalitas apa pun dalam dirinya sendiri, karena kelas lain tidak mengirimkannya dalam jumlah besar pesan. Sebaliknya, dia sendiri mengirim banyak pesan. Kelas manajer hanya mendelegasikan tanggung jawab ke kelas lain, itulah sebabnya sering disebut sebagai kelas manajer.
Mungkin ada kelas kontrol lain dalam sistem yang umum untuk beberapa kasus penggunaan. Misalnya, mungkin ada kelas SecurityManager yang bertanggung jawab untuk memantau kejadian terkait keamanan. Kelas TransactionManager menangani koordinasi pesan yang terkait dengan transaksi database. Mungkin ada manajer lain yang menangani elemen lain dari operasi sistem, seperti berbagi sumber daya, pemrosesan data terdistribusi, atau penanganan kesalahan.
Selain stereotip yang disebutkan di atas, Anda dapat membuatnya sendiri.
4.4.2.5.Atribut
Atribut adalah sepotong informasi yang terkait dengan kelas. Atribut menyimpan data kelas yang dienkapsulasi.
Karena atribut terkandung di dalam kelas, atribut tersebut disembunyikan dari kelas lain. Karena itu, mungkin perlu untuk menentukan kelas mana yang memiliki hak untuk membaca dan memodifikasi atribut. Properti ini disebut visibilitas atribut.
Atribut dapat memiliki empat kemungkinan nilai untuk parameter ini:
Umum (umum, terbuka). Nilai visibilitas ini mengasumsikan bahwa atribut akan terlihat oleh semua kelas lainnya. Setiap kelas dapat melihat atau mengubah nilai atribut. Sesuai dengan notasi UML, atribut umum didahului dengan tanda "+".
Pribadi (tertutup, rahasia). Atribut yang sesuai tidak terlihat oleh kelas lain. Atribut pribadi dilambangkan dengan tanda "-" sesuai dengan notasi UML.
Dilindungi (dilindungi). Atribut seperti itu hanya tersedia untuk kelas itu sendiri dan turunannya. Notasi UML untuk atribut yang dilindungi adalah tanda "#".
Paket atau Implementasi (batch). Asumsikan bahwa atribut yang diberikan dibagikan, tetapi hanya di dalam paketnya. Jenis visibilitas ini tidak ditunjukkan oleh ikon khusus apa pun.
Dengan bantuan ketertutupan atau keamanan, dimungkinkan untuk menghindari situasi ketika nilai atribut diubah oleh semua kelas sistem. Sebagai gantinya, logika modifikasi atribut akan dibungkus dalam kelas yang sama dengan atribut itu sendiri. Opsi visibilitas yang Anda atur akan memengaruhi kode yang dihasilkan.
4.4.2.6.Operasi
Operasi mengimplementasikan perilaku yang berhubungan dengan kelas. Operasi memiliki tiga bagian - nama, parameter, dan tipe pengembalian.
Parameter adalah argumen yang diterima operasi sebagai input. Jenis kembali mengacu pada hasil dari tindakan operasi.
Diagram kelas dapat menunjukkan nama operasi dan nama operasi bersama dengan parameter dan tipe pengembaliannya. Untuk mengurangi beban pada diagram, akan berguna untuk menunjukkan hanya nama operasi pada beberapa dari mereka, dan tanda tangan lengkap mereka pada yang lain.
Dalam UML, operasi memiliki notasi berikut:
Nama Operasi (argumen: tipe data argumen, argumen2: tipe data argumen2,...): tipe pengembalian
Ada empat jenis operasi yang perlu dipertimbangkan:
Operasi implementasi;
Operasi manajemen;
Operasi akses;
Operasi bantu.
Operasi implementasi
Operasi pelaksana mengimplementasikan beberapa fungsi bisnis. Operasi tersebut dapat ditemukan dengan memeriksa diagram interaksi. Diagram jenis ini fokus pada fungsi bisnis, dan setiap pesan dalam diagram kemungkinan besar dapat dikaitkan dengan operasi implementasi.
Setiap operasi implementasi harus mudah dilacak ke persyaratan yang sesuai. Hal ini dicapai pada berbagai tahap simulasi. Operasi diturunkan dari pesan dalam diagram interaksi, pesan diturunkan dari deskripsi rinci aliran peristiwa, yang dihasilkan berdasarkan use case, dan yang terakhir berdasarkan persyaratan. Mampu melacak seluruh rantai ini membantu memastikan bahwa setiap persyaratan diimplementasikan dalam kode, dan setiap bagian kode mengimplementasikan beberapa persyaratan.
Operasi manajemen
Operasi manajer mengelola pembuatan dan penghancuran objek. Konstruktor dan destruktor kelas termasuk dalam kategori ini.
Operasi akses
Atribut biasanya bersifat pribadi atau dilindungi. Namun, kelas lain terkadang perlu melihat atau mengubah nilainya. Ada operasi akses untuk ini. Pendekatan ini memungkinkan untuk mengenkapsulasi atribut dengan aman di dalam kelas, melindunginya dari kelas lain, tetapi masih memungkinkan akses terkontrol ke atribut tersebut. Membuat operasi Get and Set (mendapatkan dan mengubah nilai) untuk setiap atribut kelas adalah standar.
Operasi bantu
Auxiliary (operasi pembantu) adalah operasi-operasi kelas yang diperlukan untuk memenuhi tanggung jawabnya, tetapi tentang kelas lain yang seharusnya tidak tahu apa-apa. Ini adalah operasi kelas pribadi dan dilindungi.
Untuk mengidentifikasi transaksi, lakukan hal berikut:
1. Mempelajari diagram urutan dan diagram kooperatif. Sebagian besar pesan dalam diagram ini adalah operasi implementasi. Pesan reflektif akan menjadi operasi tambahan.
2. Pertimbangkan operasi kontrol. Anda mungkin perlu menambahkan konstruktor dan destruktor.
3. Pertimbangkan operasi akses. Untuk setiap atribut kelas yang perlu dikerjakan oleh kelas lain, Anda perlu membuat operasi Get and Set.
4.4.2.7.koneksi
Sebuah hubungan adalah hubungan semantik antara kelas. Ini memberi kelas kemampuan untuk belajar tentang atribut, operasi, dan hubungan kelas lain. Dengan kata lain, agar satu kelas dapat mengirim pesan ke yang lain secara berurutan atau diagram kooperatif, harus ada hubungan di antara mereka.
Ada empat jenis hubungan yang dapat dibangun antar kelas: asosiasi, dependensi, agregasi, dan generalisasi.
Asosiasi komunikasi
Sebuah asosiasi adalah hubungan semantik antara kelas. Mereka digambar pada diagram kelas sebagai garis biasa.
Beras. 10. Asosiasi komunikasi
Asosiasi bisa dua arah, seperti pada contoh, atau searah. Dalam UML, asosiasi dua arah digambarkan sebagai garis sederhana tanpa panah, atau dengan panah di kedua sisi garis. Asosiasi searah hanya memiliki satu panah yang menunjukkan arahnya.
Arah asosiasi dapat ditentukan dengan memeriksa diagram urutan dan diagram kooperatif. Jika semua pesan di dalamnya dikirim hanya oleh satu kelas dan hanya diterima oleh kelas lain, tetapi tidak sebaliknya, maka terjadi komunikasi searah antara kelas-kelas tersebut. Jika setidaknya satu pesan dikirim ke arah yang berlawanan, asosiasi harus dua arah.
Asosiasi dapat bersifat refleksif. Asosiasi refleksif berarti bahwa satu instance dari kelas berinteraksi dengan instance lain dari kelas yang sama.
kecanduan komunikasi
Hubungan ketergantungan juga mencerminkan hubungan antar kelas, tetapi selalu searah dan menunjukkan bahwa satu kelas bergantung pada definisi yang dibuat di kelas lain. Misalnya, kelas A menggunakan metode kelas B. Kemudian, ketika kelas B berubah, perlu dilakukan perubahan yang sesuai di kelas A.
Ketergantungan diwakili oleh garis putus-putus yang ditarik di antara dua elemen diagram, dan elemen yang ditambatkan di ujung panah dikatakan bergantung pada elemen yang ditambatkan di awal panah itu.
Beras. 11. Kecanduan komunikasi
Saat membuat kode untuk kelas-kelas ini, tidak ada atribut baru yang akan ditambahkan ke dalamnya. Namun, operator khusus bahasa yang diperlukan untuk mendukung komunikasi akan dibuat.
Agregasi komunikasi
Agregasi adalah bentuk asosiasi yang lebih ketat. Agregasi adalah hubungan antara keseluruhan dan bagiannya. Misalnya, Anda mungkin memiliki kelas Mobil, serta kelas Mesin, Ban, dan kelas untuk suku cadang mobil lainnya. Akibatnya, objek kelas Mobil akan terdiri dari objek kelas Mesin, empat objek Ban, dll. Agregasi divisualisasikan sebagai garis dengan belah ketupat untuk kelas yang merupakan bilangan bulat:
Beras. 11. Agregasi komunikasi
Selain agregasi sederhana, UML memperkenalkan bentuk agregasi yang lebih kuat yang disebut komposisi. Menurut komposisi, bagian objek hanya dapat dimiliki oleh satu keseluruhan, dan, terlebih lagi, sebagai aturan, siklus hidup bagian-bagian bertepatan dengan siklus keseluruhan: mereka hidup dan mati bersamanya. Setiap penghapusan keseluruhan meluas ke bagian-bagiannya.
Penghapusan berjenjang ini sering dianggap sebagai bagian dari definisi agregasi, tetapi selalu tersirat ketika multiplisitas peran adalah 1,1; misalnya, jika Pelanggan perlu dihapus, maka penghapusan itu harus disebarkan ke Pesanan (dan, pada gilirannya, Jalur Pesanan).
UML adalah bahasa pemodelan grafis terpadu untuk menggambarkan, memvisualisasikan, merancang dan mendokumentasikan sistem OO. UML dirancang untuk mendukung proses pemodelan PS berdasarkan pendekatan OO, untuk mengatur hubungan antara konsep konseptual dan program, dan untuk mencerminkan masalah penskalaan sistem yang kompleks. Model UML digunakan di semua tahap siklus hidup perangkat lunak, mulai dari analisis bisnis hingga pemeliharaan sistem. Organisasi yang berbeda dapat menggunakan UML dengan caranya sendiri, tergantung pada area masalah mereka dan teknologi yang digunakan.
Sejarah Singkat UML
Pada pertengahan 1990-an, beberapa lusin metode pemodelan OO diusulkan oleh berbagai penulis, yang masing-masing menggunakan notasi grafisnya sendiri. Pada saat yang sama, salah satu dari metode ini memiliki kekuatannya sendiri, tetapi tidak memungkinkan untuk membangun model PS yang cukup lengkap, untuk menunjukkannya "dari semua sisi", yaitu, semua proyeksi yang diperlukan (Lihat artikel 1). Selain itu, kurangnya standar pemodelan OO menyulitkan pengembang untuk memilih metode yang paling tepat, yang mencegah meluasnya penggunaan pendekatan OO untuk pengembangan perangkat lunak.
Atas permintaan Object Management Group (OMG) - sebuah organisasi yang bertanggung jawab untuk mengadopsi standar di bidang teknologi objek dan database, masalah mendesak penyatuan dan standardisasi diselesaikan oleh penulis dari tiga metode OO paling populer - G. Booch , D. Rambo dan A. Jacobson, yang menggabungkan Upaya menciptakan UML versi 1.1, disetujui oleh OMG pada tahun 1997 sebagai standar.
UML adalah bahasa
Setiap bahasa terdiri dari kamus dan aturan untuk menggabungkan kata-kata untuk membuat konstruksi yang bermakna. Jadi, bahasa pemrograman itu diatur secara khusus, seperti UML. Ciri khasnya adalah bahwa kosakata bahasa dibentuk oleh elemen grafis. Setiap simbol grafis memiliki semantik tertentu, sehingga model yang dibuat oleh satu pengembang dapat dipahami dengan jelas oleh yang lain, serta oleh alat yang menafsirkan UML. Dari sini, khususnya, dapat disimpulkan bahwa model PS yang disajikan dalam UML dapat secara otomatis diterjemahkan ke dalam bahasa pemrograman OO (seperti Java, C ++, VisualBasic), yaitu, dengan alat pemodelan visual yang baik yang mendukung UML, dengan membangun model , kita juga akan mendapatkan kode program kosong yang sesuai dengan model ini.
Perlu ditekankan bahwa UML adalah bahasa, bukan metode. Ini menjelaskan elemen apa untuk membuat model dan cara membacanya, tetapi tidak mengatakan apa pun tentang model mana dan dalam kasus apa yang harus dikembangkan. Untuk membuat metode berbasis UML, perlu dilengkapi dengan deskripsi proses pengembangan PS. Contoh dari proses tersebut adalah Rational Unified Process, yang akan dibahas pada artikel selanjutnya.
kosakata UML
Model direpresentasikan dalam bentuk entitas dan hubungan di antara mereka, yang ditunjukkan pada diagram.
Esensi adalah abstraksi yang merupakan elemen utama dari model. Ada empat jenis entitas - struktural (kelas, antarmuka, komponen, kasus penggunaan, kerjasama, simpul), perilaku (interaksi, status), pengelompokan (paket), dan annotatif (komentar). Setiap tipe entitas memiliki representasi grafisnya sendiri. Entitas akan dibahas secara rinci saat mempelajari diagram.
Hubungan menunjukkan hubungan yang berbeda antar entitas. Jenis hubungan berikut ini didefinisikan dalam UML:
- Kecanduan menunjukkan hubungan seperti itu antara dua entitas, ketika perubahan di salah satunya - independen - dapat mempengaruhi semantik yang lain - dependen. Dependensi diwakili oleh panah putus-putus yang menunjuk dari entitas dependen ke entitas independen.
- Asosiasi adalah hubungan struktural yang menunjukkan bahwa objek dari satu entitas terkait dengan objek lain. Secara grafis, sebuah asosiasi ditampilkan sebagai garis yang menghubungkan entitas terkait. Asosiasi digunakan untuk menavigasi antar objek. Misalnya, asosiasi antara kelas "Pesanan" dan "Produk" dapat digunakan untuk menemukan semua produk yang ditentukan dalam pesanan tertentu - di satu sisi, atau untuk menemukan semua pesanan yang berisi produk ini - di sisi lain. Jelas bahwa program terkait harus menerapkan mekanisme yang menyediakan navigasi tersebut. Jika navigasi diperlukan hanya dalam satu arah, itu ditunjukkan oleh panah di akhir asosiasi. Kasus asosiasi khusus adalah agregasi - hubungan dengan bentuk "keseluruhan" - "bagian". Secara grafis, ini disorot dengan belah ketupat di ujung dekat entitas-keseluruhan.
- Generalisasi adalah hubungan antara entitas induk dan entitas anak. Pada dasarnya, hubungan ini mencerminkan properti pewarisan untuk kelas dan objek. Generalisasi ditampilkan sebagai garis yang diakhiri dengan segitiga menunjuk ke arah entitas induk. Anak mewarisi struktur (atribut) dan perilaku (metode) dari orang tua, tetapi pada saat yang sama dapat memiliki elemen struktur baru dan metode baru. UML memungkinkan pewarisan berganda ketika suatu entitas terkait dengan lebih dari satu entitas induk.
- Penerapan- hubungan antara entitas yang mendefinisikan spesifikasi perilaku (antarmuka) dengan entitas yang mendefinisikan implementasi perilaku ini (kelas, komponen). Hubungan ini umum digunakan dalam pemodelan komponen dan akan dijelaskan lebih rinci dalam artikel berikutnya.
Diagram. UML menyediakan diagram berikut:
- Diagram yang menggambarkan perilaku sistem:
- Diagram keadaan (State diagram),
- diagram aktivitas,
- diagram objek,
- diagram urutan,
- diagram kolaborasi;
- Diagram yang menggambarkan implementasi fisik sistem:
- diagram komponen;
- Diagram penyebaran.
Tampilan kontrol model. Paket.
Kami telah mengatakan bahwa agar model dapat dipahami dengan baik oleh seseorang, perlu untuk mengaturnya secara hierarkis, meninggalkan sejumlah kecil entitas di setiap tingkat hierarki. UML mencakup sarana pengorganisasian representasi hierarkis dari model - paket. Setiap model terdiri dari satu set paket yang mungkin berisi kelas, kasus penggunaan, dan entitas dan diagram lainnya. Sebuah paket dapat menyertakan paket lain, yang memungkinkan Anda membuat hierarki. UML tidak menyediakan diagram paket terpisah, tetapi mereka mungkin muncul di diagram lain. Paket ditampilkan sebagai persegi panjang dengan tab.
Apa yang disediakan UML.
- deskripsi hierarkis dari sistem yang kompleks dengan menyorot paket;
- formalisasi persyaratan fungsional untuk sistem menggunakan peralatan kasus penggunaan;
- merinci persyaratan sistem dengan membuat diagram aktivitas dan skenario;
- pemilihan kelas data dan konstruksi model data konseptual dalam bentuk diagram kelas;
- pemilihan kelas yang menggambarkan antarmuka pengguna, dan pembuatan skema navigasi layar;
- deskripsi proses interaksi objek dalam kinerja fungsi sistem;
- deskripsi perilaku objek dalam bentuk diagram aktivitas dan keadaan;
- deskripsi komponen perangkat lunak dan interaksinya melalui antarmuka;
- deskripsi arsitektur fisik sistem.
Dan yang terakhir…
Terlepas dari semua daya tarik UML, akan sulit untuk menggunakannya dalam pemodelan PS nyata tanpa alat pemodelan visual. Alat tersebut memungkinkan Anda untuk menampilkan diagram dengan cepat di layar tampilan, mendokumentasikannya, menghasilkan kode program yang kosong dalam berbagai bahasa pemrograman OO, dan membuat skema database. Sebagian besar dari mereka termasuk kemungkinan rekayasa ulang kode program - memulihkan proyeksi tertentu dari model PS dengan secara otomatis menganalisis kode sumber program, yang sangat penting untuk memastikan bahwa model dan kode cocok dan ketika merancang sistem yang mewarisi fungsionalitas sistem pendahulu. .
UML (Unified Modeling Language - unified modelling language) - bahasa deskripsi grafis untuk pemodelan objek di bidang pengembangan perangkat lunak. UML adalah bahasa umum, ini adalah standar terbuka yang menggunakan notasi grafis untuk membuat model abstrak dari suatu sistem, yang disebut model UML. UML dibuat untuk mendefinisikan, memvisualisasikan, mendesain, dan mendokumentasikan sebagian besar sistem perangkat lunak. UML bukan bahasa pemrograman, tetapi pembuatan kode dimungkinkan dalam alat untuk mengeksekusi model UML sebagai kode yang ditafsirkan. Wikipedia
Produk Komersial
Microsoft Visio
Jenis: perangkat lunak komersial
Produk perangkat lunak populer dari Microsoft yang memungkinkan Anda menggambar diagram kaya, termasuk UML:
Mulai dari versi 2010, dimungkinkan untuk menerbitkan diagram di web (Layanan SharePoint + Visio):
Penampil Visio- program gratis yang memungkinkan Anda melihat diagram Visio yang dibuat sebelumnya. Anda dapat mengunduh di %D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5%20.
%0A
Microsoft%20Visual%20Studio%202010
%0A%D0%A2%D0%B8%D0%BF:%20%D0%BA%D0%BE%D0%BC%D0%BC%D0%B5%D1%80%D1%87%D0%B5%D1% 81%D0%BA%D0%BE%D0%B5%20%D0%9F%D0%9E%20(%D0%B5%D1%81%D1%82%D1%8C%20%D0%B1%D0 %B5%D1%81%D0%BF%D0%BB%D0%B0%D1%82%D0%BD%D0%B0%D1%8F%20Express%20%D0%B2%D0%B5%D1%80 %D1%81%D0%B8%D1%8F).
%0A
%D0%92%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B9%20%D0%B2%D0 %B5%D1%80%D1%81%D0%B8%D0%B8%20Microsoft%20Visual%20Studio%202010%20%D0%BF%D0%BE%D1%8F%D0%B2%D0%B8%D0 %BB%D1%81%D1%8F%20%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9%20%D1%82%D0%B8%D0%BF%20%D0 %BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%20-%20Modelling,%20%D0%BA%D0%BE%D1%82%D0%BE %D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82 %20%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%80%D0%B0%D0%B7%D0 %BB%D0%B8%D1%87%D0%BD%D1%8B%D0%B5%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0 %D0%BC%D0%BC%D0%B0%20%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1 %82%D1%8C%20%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5%20 %D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%BD%D0%B0%20%D1%81%D0%BE%D0 %BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B8%D0%B5%20%D1%81%20%D0%BD %D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%20%D0%B0%D1%80%D1%85 %D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%BE%D0%B9.
%0A
%D0%9F%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82%20%D0%B3%D0%B5%D0%BD %D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20Sequence%20Diagram%20%D0%BD%D0%B0 %20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8%20%D0%BA%D0%BE%D0 %B4%D0%B0,%20%D0%B2%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B8%D1%80% D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%81%D0%B2%D1%8F%D0%B7%D0%B8%20%D0%B2%20% D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5%20%D0%BC%D0%B5%D0%B6%D0%B4%D1%83% 20%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8, %20%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%81%D1%81 %D1%8B%D0%BB%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%82.%D0%B4.
%0A%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80%20Use%20case%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80 %D0%B0%D0%BC%D0%BC%D1%8B,%20%D0%BD%D0%B0%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0% B0%D0%BD%D0%BD%D0%BE%D0%B9%20%D0%B2%20Visual%20Studio%202010:
%0A%0A%D0%9A%D1%80%D0%BE%D0%BC%D0%B5%20%D1%82%D0%BE%D0%B3%D0%BE,%20%D0%B4%D0%BE% D1%81%D1%82%D1%83%D0%BF%D0%B5%D0%BD%20Visualization%20and%20Modeling%20Feature%20Pack%20(%D0%B4%D0%BB%D1%8F%20 %D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%87%D0%B8%D0%BA%D0%BE%D0%B2%20MSDN),%20 %D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE %D0%BB%D1%8F%D0%B5%D1%82:
%0A- %D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20 %D0%BA%D0%BE%D0%B4%20%D0%BD%D0%B0%20%D0%B1%D0%B0%D0%B7%D0%B5%20UML%20%D0%B4%D0 %B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0 %BE%D0%B2 %0A
- %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20UML%20%D0%B4%D0%B8%D0 %B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B8%D0%B7%20%D0%BA%D0%BE%D0%B4 %D0%B0 %0A
- %D0%B8%D0%BC%D0%BF%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1 %8C%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%BA%D0 %BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2,%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0% D0%BC%D0%BC%D1%8B%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0% D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9,%20%D0%B4%D0%B8 %D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B2%D0%B0%D1%80%D0%B8%D0%B0 %D0%BD%D1%82%D0%BE%D0%B2%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE %D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D1%81%20XMI%202.1 %0A
- %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B4%D0%B8%D0%B0 %D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8 %D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9%20%D0%B4%D0%BB%D1%8F%20ASP.NET,%20C%20%D0% B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2 %0A
- %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B8%20%D0%BF%D1 %80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1%82%D1%8C%20layer%20diagrams%20%D0%B4%D0%BB%D1%8F%20C %20%D0%B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2 %0A
- %D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C%20%D1%81%D0%BE%D0%B1%D1%81%D1%82%D0%B2 %D0%B5%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA %D0%B8%20%D0%B4%D0%BB%D1%8F%20layer%20diagram %0A
%D0%A1%D0%BA%D0%B0%D1%87%D0%B0%D1%82%D1%8C%20Visualisasi%20and%20Modeling%20Feature%20Pack%20%D0%BC%D0%BE%D0 %B6%D0%BD%D0%BE%20%D0%BF%D0%BE%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5:%20
IBM Rasional Rose
Peluang:
- Use case diagram (diagram preseden);
- Deployment diagram (diagram topologi);
- Statechart diagram (diagram keadaan);
- Diagram aktivitas (diagram aktivitas);
- Diagram interaksi (diagram interaksi);
- Diagram urutan (diagram urutan tindakan);
- Diagram kolaborasi (diagram kolaborasi);
- Diagram kelas (class diagram);
- Diagram komponen (component diagram).
Tangkapan layar:
program sumber terbuka
BintangUML
Peluang:
- Dukungan UML 2.0
- MDA (Arsitektur Berbasis Model)
- Arsitektur Plug-in (Anda dapat menulis dalam bahasa yang kompatibel dengan COM: C++, Delphi, C#, VB, ...)
StarUML ditulis terutama dalam Delphi, tetapi komponen juga dapat ditambahkan dalam bahasa lain, seperti C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C#, VB.NET. Di bawah ini adalah beberapa tangkapan layar.
Diagram Kelas:
Gunakan diagram kasus:
ArgoUML
Grafik yang didukung:
- kelas
- Negara
- kasus penggunaan
- Aktivitas
- Kolaborasi
- Penyebaran
- Urutan
Peluang:
- Dukungan untuk sembilan diagram UML 1.4
- Platform independen (Java 5+)
- Metamodel Standar UML 1.4
- Dukungan XMI
- Ekspor ke GIF, PNG, PS, EPS, PGML, dan SVG
- Bahasa: EN, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
- dukungan OCL
- Maju, Rekayasa Mundur
Tangkapan layar:
