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

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