UML-діаграма - це спеціалізований мова графічного опису, призначений для об`єктного моделювання в сфері розробки різного програмного забезпечення. Дана мова має широкий профіль і являє собою відкритий стандарт, в якому використовуються різні графічні позначення, щоб створити абстрактну модель системи. UML створювався для того, щоб забезпечити визначення, візуалізацію, документування, а також проектування всіляких програмних систем. Варто зазначити, що сама по собі UML-діаграма не представляє собою мову програмування, але при цьому передбачається можливість генерації на її основі окремого коду.
Навіщо вона потрібна?
Застосування UML не закінчується на моделюванні всілякого ПО. Також дана мова активно сьогодні використовується для моделювання різних бізнес-процесів, ведення системного проектування, а також відображення організаційних структур.
За допомогою UML розробники програмного забезпечення можуть забезпечити повне угоду в використовуваних графічних позначеннях, щоб представити загальні поняття, такі як: компонент, узагальнення, клас, поведінку і агрегація. За рахунок цього досягається велика ступінь концентрації на архітектурі і проектуванні.
Також варто відзначити, що є кілька видів таких діаграм.
діаграма класів
Діаграма класів UML є статичну структурну діаграму, призначену для опису структури системи, а також демонстрації атрибутів, методів і залежностей між кількома різними класами.
Варто відзначити той факт, що є кілька точок зору на побудову таких діаграм в залежності від того, яким чином вони будуть використовуватися:
- Концептуальна. В даному випадку діаграма класів UML здійснює опис моделі певної предметної області, і в ній передбачаються тільки класи прикладних об`єктів.
- Специфічна. Діаграма використовується в процесі проектування різних інформаційних систем.
- Реалізаційна. Діаграма класів включає в себе всілякі класи, які безпосередньо використовуються в програмному коді.
діаграма компонентів
Діаграма компонентів UML є повністю статичну структурну діаграму. Призначається вона для того, щоб продемонструвати розбиття певної програмної системи на різноманітні структурні компоненти, а також зв`язку між ними. Діаграма компонентів UML в таких то використовувати всілякі моделі, бібліотеки, файли, пакети, виконувані файли і ще безліч інших елементів.
Діаграма композитної / складовою структури
UML діаграма композитної / складовою структури також є статичною структурної діаграмою, але використовується вона для того, щоб показати внутрішню структуру класів. По можливості дана діаграма може продемонструвати також взаємодія елементів, що знаходяться у внутрішній структурі класу.
Підвидом їх є UML-діаграма кооперації, яка використовується для демонстрації ролей, а також взаємодії різних класів в межах кооперації. Вони є досить зручними в тому випадку, якщо потрібно моделювати шаблони проектування.
Варто зазначити, що одночасно можуть використовуватися види діаграм UML класів і композитної структури.
діаграма розгортання
Дана діаграма використовується для того, щоб моделювати працюють вузли, а також всілякі артефакти, які на них були розгорнуті. В UML 2 на різних вузлах здійснюється розгортання артефактів, в той час як в першій версії розгорталися виключно компоненти. Таким чином, діаграма розгортання UML використовується переважно до другої версії.
Між артефактом і тим компонентом, який він реалізує, формується залежність маніфестації.
діаграма об`єктів
Даний вид дозволяє побачити повноцінний або ж частковий знімок створюваної системи в певний момент часу. На ній буде відображатися всі екземпляри класів конкретної системи із зазначенням поточних значень їх параметрів, а також зв`язків між ними.
діаграма пакетів
Ця діаграма носить структурний характер, і основним її змістом є всілякі пакети, а також відносини між ними. В даному випадку немає ніякого жорсткого поділу між декількома структурними діаграмами, внаслідок чого їх використання найчастіше зустрічається виключно для зручності, і ніякого семантичного значення в собі не несе. Варто відзначити, що різні елементи можуть надавати інші UML діаграми (приклади: пакети і самі діаграми пакетів).
Їх використання здійснюється для того, щоб забезпечити організацію кількох елементів в групи за певною ознакою, щоб спростити структуру, а також організувати роботу з моделлю даної системи.
діаграма діяльності
Діаграма діяльності UML відображає розкладання певної діяльності на кілька складових частин. В даному випадку поняттям «діяльність» називається специфікація певного виконуваного поведінки у вигляді паралельного, а також координованого послідовного виконання різних підлеглих елементів - вкладених типів діяльності і різних дій, об`єднаних потоками, що йдуть від виходів певного вузла до входів іншого.
Діаграма діяльності UML досить часто використовуються для того, щоб моделювати різні бізнес-процеси, паралельні і послідовні обчислення. Крім усього іншого ними моделюються всілякі технологічні процедури.
діаграма автомата
Цей вид називається і трохи інакше - діаграма станів UML. Має представлений кінцевий автомат з простими і композитними станами, а також переходами.
Кінцевий автомат являє собою специфікацію послідовності різних станів, через які проходить певний об`єкт, або ж взаємодія у відповідь на деякі події свого життя, а також відповідні дії об`єкта на такі події. Кінцевий автомат, який використовує діаграма станів UML, закріплюється за вихідним елементом і використовується для того, щоб визначити поведінку його примірників.
Як аналогів таких діаграм можуть використовуватися так звані дракон-схеми.
Діаграми сценаріїв використання
Діаграма варіантів використання UML відображає на собі всі відносини, які виникають між акторами, а також різними варіантами використання. Головне її завдання - здійснювати собою повноцінний засіб, за допомогою якого клієнт, кінцевий користувач або ж який-небудь розробник зможе спільно обговорювати поведінку і функціональність певної системи.
Якщо діаграма варіантів використання UML використовується в процесі моделювання системи, то аналітик збирається:
- Чітко відокремити моделируемую систему від її оточення.
- Виявити дійових осіб, шляхи їх взаємодії з даною системою, а також очікуваний її функціонал.
- Встановити в глосарії в якості предметної області різні поняття, які відносяться до докладного опису функціоналу даної системи.
Якщо розробляється в UML діаграма використання, процедура починається з текстового опису, яке виходить при роботі із замовником. При цьому варто відзначити той факт, що різні нефункціональні вимоги в процесі складання моделі прецедентів повністю опускаються, і для них вже буде формуватися окремий документ.
комунікації
Діаграма комунікації точно так же, як і діаграма послідовності UML, є транзитивною, тобто висловлює в собі взаємодію, але при цьому демонструє його різними способами, і при необхідності з потрібним ступенем точності можна перетворити одну в іншу.
Діаграма комунікації відображає в собі взаємодії, які відбуваються між різними елементами композитної структури, а також ролями кооперації. Головною відмінністю її від діаграми послідовності є те, що на ній досить явно вказуються відносини між декількома елементами, а час не використовується в якості окремого виміру.
Даний тип відрізняється абсолютно вільним форматом упорядкування кількох об`єктів і зв`язків точно так же, як це здійснюється в діаграмі об`єктів. Якщо є необхідність в тому, щоб підтримувати порядок повідомлень при цьому вільному форматі, здійснюється їх хронологічна нумерація. Читання даної діаграми починається з початкового повідомлення 1.0, і згодом продовжується по тому напрямку, по якому здійснюється передача повідомлень від одного об`єкта до іншого.
Здебільшого такі діаграми демонструють точно таку ж інформацію, яку надає нам діаграма послідовності, однак через те, що тут використовується інший спосіб представлення інформації, певні речі на одній діаграмі стає набагато простіше визначити, чим на інший. Також варто відзначити, що діаграма комунікацій більш наочно показує, з якими елементами вступає у взаємодію кожен окремий елемент, в той час як діаграма послідовності більш ясно показує, в якому порядку здійснюються взаємодії.
діаграма послідовності
Діаграма послідовності UML демонструє взаємодії між декількома об`єктами, які упорядковуються відповідно до пори їх прояви. На такий діаграмі відображається впорядковане в часі взаємодія між декількома об`єктами. Зокрема, на ній відображаються всі об`єкти, які беруть участь у взаємодії, а також повна послідовність обмінюваних ними повідомлень.
Головними елементами в даному випадку виступають позначення різних об`єктів, а також вертикальні лінії, що відображають плин часу і прямокутники, що надають діяльність певного об`єкта або ж виконання ним будь-якої функції.
діаграма співпраці
Даний тип діаграм дозволяє продемонструвати взаємодії між декількома об`єктами, абстрагуючись від послідовності трансляції повідомлень. Даний тип діаграм в компактному вигляді відображає в собі абсолютно всі передані і прийняті повідомлення певного об`єкта, а також формати цих повідомлень.
У зв`язку з тим, що діаграми послідовності і комунікації являють собою просто-напросто різний погляд на одні й ті ж процедури, Rational Rose надає можливість створювати з діаграми послідовності комунікаційну або ж навпаки, а також здійснює повністю автоматичну їх синхронізацію.
Діаграми огляду взаємодії
Це діаграми мови UML, які відносяться до різновиду діаграм діяльності та включають в себе одночасно елементи Sequence і конструкції потоку управління.
Варто відзначити той факт, що даний формат об`єднує в собі Collaboration і Sequence diagram, які надають можливість з різних точок зору розглядати взаємодію між декількома об`єктами в формованої системі.
діаграма синхронізації
Являє собою альтернативний варіант діаграми послідовності, який явно демонструє зміну стану на лінії життя з певною шкалою часу. Може бути досить корисною в різних додатках реального часу.
У чому переваги?
Варто відзначити кілька переваг, якими відрізняється UML діаграма користування та інші:
- Мова є об`єктно-орієнтованим, внаслідок чого технології опису результатів проведеного аналізу та проектування є семантично близькими до методів програмування на всіляких об`єктно-орієнтованих мовах сучасного типу.
- За допомогою цієї мови система може бути описана практично з будь-яких можливих точок зору, і точно так само описуються різні аспекти її поведінки.
- Всі діаграми є порівняно простими для читання навіть після відносно швидкого ознайомлення з його синтаксисом.
- UML дозволяє розширити, а також вводити власні графічні і текстові стереотипи, що сприяє його використанню не тільки в програмної інженерії.
- Мова отримав досить широке поширення, а також досить активно розвивається.
недоліки
Незважаючи на те що побудова UML-діаграм відрізняється масою своїх плюсів, досить часто їх і критикують за такі недоліки:
- Надмірність. У переважній більшості випадків критики говорять про те, що UML є занадто великим і складним, і часто це невиправдано. У нього входить досить багато надлишкових або ж практично непотрібних конструкцій і діаграм, причому найбільш часто подібна критика йде на адресу другої версії, а не першої, тому що в більш нових ревізіях присутня більша кількість компромісів «розроблених комітетом».
- Різні неточності в семантиці. З тієї причини, що UML визначається комбінацією себе, англійської та OCL, у нього відсутня скутість, яка є властивою для мов, точно визначених технікою формального опису. У певних ситуаціях абстрактний синтаксис OCL, UML і англійський починають один одному суперечити, в той час як в інших випадках вони є неповними. Неточність опису самого мови однаково відбивається як на користувачів, так і на постачальників інструментів, що в кінцевому підсумку призводить до несумісності інструментів через унікального способу трактування різних специфікацій.
- Проблеми в процесі впровадження та вивчення. Всі зазначені вище проблеми створюють певні складності в процесі впровадження та вивчення UML, і особливо це стосується тих випадків, коли керівництво змушує інженерів насильно його використовувати, в той час як у них відсутні попередні навички.
- Код відображає код. Ще одним думкою є те, що важливість мають не красиві і привабливі моделі, а безпосередньо робочі системи, тобто код і є проект. Відповідно до цього думкою є потреба в тому, щоб розробити більш ефективний спосіб написання програмного забезпечення. UML прийнято цінувати при підходах, компілює моделі для регенерації здійсненного або ж вихідного коду. Але насправді цього може бути недостатньо, тому що в даній мові відсутні властивості повноти по Тьюрингу, і кожен згенерований код в кінцевому підсумку буде обмежуватися тим, що може припустити або ж визначити інтерпретує UML інструмент.
- Неузгодженість навантаження. Даний термін походить з теорії системного аналізу для визначення нездатності входу певної системи сприйняти вихід іншої. Як в будь-яких стандартних системах позначень, UML може представляти одні системи в більш ефективному і стислому вигляді в порівнянні з іншими. Таким чином, розробник більше схиляється до тих рішень, які є більш комфортними для переплетення всіх сильних сторін UML, а також інших мов програмування. Дана проблема є більш очевидною в тому випадку, якщо мова розробки не відповідає основним принципам об`єктно-орієнтованої ортодоксальної доктрини, тобто не намагається працювати відповідно до принципів ООП.
- Намагається бути універсальним. UML є мова моделювання загального призначення, який намагається забезпечити сумісність з будь-яким існуючим на сьогоднішній день мовою обробки. У контексті певного проекту, для того, щоб команда проектувальників змогла домогтися кінцевої мети, потрібно вибирати застосовні можливості цієї мови. Крім цього можливі шляхи обмеження сфери використання UML в якійсь певній області проходять через формалізм, який є не повністю сформульованим, а який сам є об`єктом критики.
Таким чином, використання даного мови є актуальним далеко не у всіх ситуаціях.
