UML-діаграма. Види діаграм UML

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 в якійсь певній області проходять через формалізм, який є не повністю сформульованим, а який сам являє собою об 'єкт критики.

Таким чином, використання даної мови є актуальним далеко не у всіх ситуаціях.