Як будувати UML-діаграми. Розбираємо три найпопулярніші варіанти

Привіт, мене звати Юлія Каграманова, я викладаю у Державному університеті телекомунікацій. У цій статті хочу поговорити про UML — стандартизовану мову нотації, яка дозволяє сформувати вимоги, краще зрозуміти та пояснити архітектуру програмного забезпечення, а також сприяє тому, що важливі деталі реалізації проєкту не забуваються, а вартість розробки — зменшується.

Стаття буде корисна для бізнес-аналітиків, продакт-менеджерів, розробників, тестувальників та й загалом усіх, хто хоче навчитись візуалізувати вимоги до проєкту.

Коротко про UML

UML (Unified Modeling Language) — уніфікована мова моделювання, що використовується розробниками програмного забезпечення для візуалізації процесів та роботи систем.

Це не мова програмування, скоріше набір правил та стандартів для створення діаграм. Вони дозволяють розробникам програмного забезпечення та інженерам «говорити однією мовою», не заглиблюючись у фактичний код свого продукту. Складання діаграм за допомогою UML — це чудовий спосіб допомогти іншим швидко зрозуміти складну ідею чи структуру.

UML-діаграми поділяються на 14 типів:

Ми розглянемо найпопулярніші з них:

• Діаграма прецедентів (Use-case diagram);
• Діаграма активностей (Activity diagram);
• Діаграма послідовності (Sequence diagram);

Діаграма варіантів використання

Діаграма варіантів використання — (діаграма прецедентів, сценарій використання, use case) — дозволяє уявити типи ролей та їх взаємодію із системою. Проте не показує порядок виконання кроків. Зображує функціональні вимоги (те, що система може зробити) з точки зору користувача. Може описуватись текстом або у вигляді діаграми.

Рис.2 Основні позначення діаграми варіантів використання

Діаграми використання розробляються на ранній стадії проєктування системи та призначені для:
Простого пояснення роботи системи, створення та погодження ТЗ.
Формування функціональних (що має робити) вимог до системи
Створення основи для документації та тестування.

Складові діаграми варіантів використання

Діаграми варіантів використання складаються з 4 об’єктів: актор, прецедент (варіант використання), система, зв’язок.

Актор. Поняття когось, або чогось, що взаємодіє з системою, але не належить до неї (знаходиться за межами системи). Зазвичай позначається у вигляді стилізованого чоловічка. Рідше у вигляді прямокутника класу з написом <<actor>>.

Усіх акторів умовно можна розділити на первинних (ті, що ініціюють взаємодію з системою) та вторинних (ті що реагують на взаємодію). Первинні зазвичай зображуються зліва, а вторинні — справа від системи.
Оскільки будь-яка система може взаємодіяти не лише з людьми, актор не завжди позначає користувача-людину. Він може позначати іншу систему або пристрій з яким взаємодіє.

Часто виникає плутанина між поняттями актор та користувач:

• актор — це поняття, що представляє клас користувачів (узагальнення групи користувачів), а не конкретного користувача, та може поєднувати в собі декілька ролей. Наприклад актор — працівник компанії може мати ролі інженер, менеджер, директор;
• користувач — це тип актора або його конкретна реалізація. Декілька користувачів можуть грати одну роль, тобто бути одним актором. Наприклад Іван та Роман — студенти. Також один користувач може належати до різних акторів, тобто виконувати різні ролі. Наприклад, в системі університету актор може бути викладачем в одному випадку, і науковим керівником в іншому.

Рис. 3 Приклад користувача, актора та ролі в UML

Випадок використання (прецедент). Прецеденти визначають очікувану поведінку та відповідають на питання, що робить система. Представляють набір можливих функцій, дій або завдань. Зображується у вигляді еліпса з назвою дії (дієсловом) у ньому. Прецедент вказує, що має трапитись, проте не відповідає на запитання, як це має статись.

До прикладу: в системі банківського додатка прецедентами можуть бути: перевірити баланс, переказати кошти, оплатити рахунок та ін. Б

Система. Те, що моделюється. Це може бути сайт, мобільний додаток або навіть модуль програмного забезпечення. Зображується у вигляді прямокутника з назвою системи у верхній частині.

Коментар розширює функціональність, надає підказки та умови.

Рис.4 Складові діаграми послідовності

Зв’язки (відношення). Усі актори мають бути пов’язані з прецедентом. Проте не усі прецеденти повинні бути пов’язані з акторами. Частіше всього для зображення зв’язку використовується суцільна лінія.

У діаграмі варіантів використання існує 4 типи зв’язків:

1. Асоціація (Association). Звичайний зв’язок актора та прецеденту. Позначається суцільною лінією без напису (стереотипу). Незалежно від типу зв’язку, будь-який актор повинен бути пов’язаний принаймні з одним (можна з декількома) варіантом використання. Кілька акторів можуть бути пов’язані з одним варіантом використання.

Рис.5 Асоціація між актором та варіантом використання

2. Розширення (Extend). Показує додаткову функціональність або можливий не обов’язковий варіант поведінки системи. Базовий прецедент має сенс сам по собі, не залежить від розширюючого і може існувати без нього. Відношення розширення позначається пунктирною лінією зі звичайним вказівником, що вказує на базовий прецедент та стереотипом (написом) <<extend>>. Розширюючий прецедент активується лише за виконання умови.

Наприклад: прецедент «хибний пароль» можливий лише при введенні невірного паролю. Відповідає extensions в текстовому варіанті.

Рис.6 Приклад зв’язку розширення з умовою

Точки розширення (extension points). При використанні відношення розширення базовий варіант надає точки розширення (те саме, що extensions в текстовому описі) для розширюючого прецеденту. За бажанням вони можуть бути описані в окремому розділі базового прецеденту.

Рис.7 Приклад зв’язку розширення з точками розширення

Якщо існує умова розширення (condition, те саме, що preconditions в текстовому варіанті) її можна описати в коментарі. Коментар з’єднується з пунктирною лінією з умовою розширення.

Рис.8 Приклад використання коментаря

3. Включення (Include). Показує, що поведінка одного прецеденту включається як складовий компонент у послідовність поведінки іншого прецеденту. Ілюструє, що саме використовує базовий варіант для виконання операції. На відміну від зв’язку розширення, дочірній варіант у зв’язку include має бути обов’язковим для базового. Відношення включення використовується для уникнення дублювання однакових прецедентів та додає функціональність, не вказану в базовому. Відношення позначається пунктирною лінією зі стрілкою та стереотипом <<include>>, що вказує на включений варіант.

Включення добре ілюструє сценарій відновлення працездатності комп’ютера (припустимо, що інших варіантів немає):

• ремонт або заміна апаратних компонентів;
• виявлення та видалення вірусу;
• перевстановлення системи.

Рис.9 Включення між варіантами використання

Рис.10 Включення дочірнього прецеденту «оновити баланс» до декількох прецедентів-предків

4.Генералізація (Generalization). Генералізація (успадкування, узагальнення) це батьківсько-дочірні відношення. Генералізація позначається суцільною лінією з трикутним не зафарбованим вказівником, що вказує на прецедент-предок.

Властивості відносин узагальнення:

• дочірні прецеденти мають всі властивості предків;
• для одного предка може існувати декілька дочірніх прецедентів;
• може бути кілька батьків (множинне успадкування).

Узагальнення актора. В узагальнені актора один актор може успадкувати роль іншого. Нащадок успадковує всі варіанти використання предка, проте може мати і власні унікальні варіанти.

Рис.11 Узагальнення актора

Узагальнення варіанту використання. Схоже на узагальнення актора. В цьому випадку поведінка предка успадковується нащадком.

Використовується, коли існує спільна поведінка між двома варіантами використання. Наприклад, варіанти «Оплата банківською карткою» та «Оплата через Google Pay» можна узагальнити до «Оплата рахунку»

Рис.12 Узагальнення варіанту використання

Рекомендації зі створення діаграми варіантів використання

• Зручним способом моделювання є використання сервісу Draw.io. Також можливо створювати діаграму з телефону, через додаток Lucidchart. Після створення діаграми в мобільному додатку її можна виділити (ctrl +A) та вставити (ctrl +C) в Draw. io через комп’ютер.
• Якщо можливо, розміщуйте прецеденти в логічному послідовному порядку (наприклад, зверху донизу).
• За бажання, використовуйте кольори для розфарбування елементів діаграми.
• Лінії відношень не обов’язково мають бути прямими. Вони можуть утворювати гострі, або закруглені кути та повороти. Див. 1 2.
• Починайте моделювання з узагальненого варіанту і лише після цього додавайте нові деталі.

Поширені помилки

• Кожен актор очікує, що система поводитиметься строго певним, передбачуваним чином. Якщо очікується один результат, а отримується інший, таке моделювання є неправильним.
• Діаграма використання має розроблятись з точки зору користувача, а не програміста. У сценаріях повинні використовуватися назви елементів управління видимі користувачеві. Небажано зображати деталі реалізації, незрозумілі замовнику;

Приклади діаграм варіантів використання

Рис.13 Приклади діаграм використання

Діаграма послідовності

Діаграма послідовності (Sequence Diagram) — показує часові особливості передачі і прийому повідомлень об’єктами. Впорядкованість за часом слід розуміти як послідовність дій і не плутати з часовими діаграмами.

Позначення діаграми послідовності

1. Лінія життя починається з об’єкта-прямокутника (голова) та зображується вертикальною пунктирною лінією (стеблом). Вона служить для позначення періоду часу, протягом якого об’єкт існує в системі. Якщо об’єкт існує в системі постійно, то його лінія життя повинна продовжуватися по всій площині діаграми зверху донизу. Зазвичай об’єкти перераховуються зліва направо. Шаблони лінії життя в Draw.io знаходяться в наборі фігур UML 2.5.

Рис.14 Загальні елементи діаграми послідовності

Рис.15 Позначення на лінії життя

Об’єкт (учасник) — позначення лінії життя та екземпляр класу у горизонтального прямокутника.
Актор — використовується, коли конкретна діаграма послідовності належить варіанту використання.
Сутність (entity) — представляє системні дані. Наприклад, у програмі обслуговування клієнтів суб’єкт — клієнт керує даними (сутність), пов’язаними з клієнтом.
Межа/кордон (boundary) — вказує на межу системи/ граничний елемент у системі; наприклад, екрани інтерфейсу користувача, шлюзи баз даних або меню, з якими взаємодіють користувачі
Управління (control) вказує на керівну сутність або менеджера. Він організовує та планує взаємодії між кордонами та сутностями та служить посередником між ними.

2. Смуга активації (фокус управління) — тонкий прямокутник на лінії життя, протягом якого елемент виконує операцію. Довжина прямокутника вказує на тривалість перебування об’єктів в активному режимі.

3. Повідомлення (виклики) з’являються в послідовному порядку на лінії життя. Повідомлення зображується за допомогою стрілок. Початок стрілки завжди торкається лінії життя відправника та лінії життя об’єкта, що приймає повідомлення. Підпис може знаходитись над або всередині стрілки повідомлення. Для зручності перед повідомленням можна проставляти нумерацію дій. Повідомлення можна розділити на такі категорії:

Рис.16 Позначення типів повідомлень

Повідомлення поділяються на синхронні, що очікують відповіді (зафарбований вказівник), та асинхронні — не очікують відповіді (пунктирна лінія, звичайний вказівник).

Рис.17 Приклад синхронного та асинхронного повідомлення

Рекурсивне повідомлення — направлене до себе (починається та закінчується на одній лінії життя). Прикладом може служити отримання доступу до камери смартфоном.

Повідомлення повернення (пунктирна лінія із зафарбованим вказівником) — зворотне повідомлення викликаючій стороні. Можна уникнути захаращення діаграм, вказуючи значення в самій стрілці початкового повідомлення.

Створення учасника — повідомлення, що створює нову лінію життя. Позначається пунктирною лінією, направленою до прямокутника учасника. Якщо створений учасник робить щось після його створення, слід додати вікно активації під його полем.

Видалення учасника позначається хрестом в кінці лінії життя учасника. При цьому, якщо стрілка повідомлення направлена від одного учасника до іншого, значить, один учасник видаляє іншого. Якщо стрілка відсутня, учасник самознищується.

Знайдене повідомлення — повідомлення від невідомого джерела.

4. Інші позначення:

• Коментар — прямокутник із загнутим кутом. Може бути з’єднаний з об’єктом пунктирною лінією.
• Фрагмент використовується, якщо процеси утворюють цикл або вимагають виконання умов для його закінчення. Він складається з вікна (рамки) та оператора фрагмента (напису) в п’ятикутнику зверху зліва.

Фрагмент діаграми послідовності (sd) використовується для оточення усієї діаграми. Після напису sd вказується назва діаграми.

Альтернативний фрагмент (alt) — показує один або декілька альтернативних сценаріїв, де виконується лише один, той, чия умова істинна.

Для опису двох або більше альтернативних сценаріїв використовуються пунктирні лінії — операнд взаємодії (interaction operands). Кожен операнд має умову захисту в квадратних дужках (guard condition).

Опціональний (не обов’язковий) фрагмент (opt) — виконується, лише якщо вказана умова, істинна. Він має лише одну умову і не поділяється на операнди. Використовується для опису не обов’язкового кроку робочого процесу.

Прикладом може слугувати послідовність покупок в інтернет-магазині: opt, щоб описати, як користувач може додати подарункове пакування. Та alt для опису двох варіантів оплати: за допомогою кредитної картки або грошового переказу.

Рис.18 Приклад фрагментів alt та opt

Фрагмент циклу (loop) — використовується для послідовності, що повторюється. Може мати межі ітерації, що пишуться біля назви loop

Рис.19 Приклад фрагмента циклу

Фрагмент посилання (ref) — для повторного використання частини послідовності в іншому місці діаграми.

Рис.20 Приклад фрагмента посилання

Рекомендації зі створення діаграми послідовності

• Оберіть тему діаграми послідовності.
• Визначте об’єкти або акторів, які будуть залучені до створення діаграми.
• Створіть короткий список взаємодій об’єктів, що відображатимуться на діаграмі послідовності.
• Визначте, якими типами повідомлень будуть обмінюватись об’єкти.
• Ви можете розфарбувати діаграму.

Поширені помилки

• Не додавайте багато деталей. Це захаращує діаграму та ускладнює її читання.
• Початок стрілки повідомлення має завжди торкатись лінії життя відправника, а вказівник — лінії життя об’єкта-одержувача.
• Повідомлення мають будуватись зліва направо.
• Не використовуйте діаграму послідовності, якщо необхідна реалізація простої логіки.

Приклади діаграм послідовності

Рис.21 Діаграма послідовності онлайн-системи іспитів

Рис.22 Діаграма послідовності системи управління школою

Рис.23 Діаграма послідовності музичного програвача но основі емоцій

Діаграма діяльності

Діаграма діяльності (Activity Diagram) візуалізує процес використання та ілюструє потік повідомлень від однієї дії до іншої. Показує цілісну роботу системи.

Діаграма діяльності вважається розширеним варіантом блок-схем. Проте блок-схема не має стандартизованої нотації та не містить паралелізмів (паралельне виконання дій) та синхронізації.

Також часто виникає питання, у чому різниця між діаграмою діяльності та послідовності. Головна мета діаграми послідовності — показати порядок виконання, або послідовність дій. Водночас діаграма діяльності потрібна для опису роботи всієї системи, вона показує перехід від однієї дії до іншої.

Ці дії можуть виконуватися людьми, програмними компонентами або комп’ютерами. Потік керування (порядок виконання) на діаграмі діяльності переходить від однієї операції до іншої. Цей потік може бути послідовним, розгалуженим або одночасним.

Рис. 24 Різниця між діаграмою послідовності та діаграмою діяльності (музичний плеєр на основі емоцій)

Позначення діаграми діяльності

Потік керування — з’єднує два вузли на діаграмі активності. Вузол розгалуження (вилка) — це вузол керування, який розділяє потік на кілька одночасних. Потрібен для створення декількох одночасних завдань. Вузол злиття об’єднує ці потоки.

Вузол прийняття рішень — це вузол керування, який вибирає між декількома потоками один істинний. Він схожий на оператор if в Java або C#. Умови (охоронні умови) записуються в квадратних дужках поруч з потоком.

Рис. 25 Приклад діаграми діяльності

Доріжки (swimlanes) — це спосіб групування дій, які виконуються одним актором, або декількома акторами в одному потоці. Не додавайте більш як 5 доріжок одночасно. Розташовуйте доріжки у логічному порядку.

Рис. 26 Приклад діаграми діяльності з доріжками

Як намалювати діаграму діяльності

1. Уявіть процес, який ви хочете змоделювати, та розбийте його на дії.
2. Подумайте, чи матиме ваш процес учасників, чи буде він мати доріжки.

3. Визначте порядок виконання дій. Чи мають виконуватись якісь умови для виконання певної дії (вузол прийняття рішень). Чи будуть у вас паралельні дії (вузол розгалужень).

Поради для створення діаграми діяльності

• В Draw io увімкніть бібліотеку форм UML. Клацніть «Більше обрисів» внизу панелі ліворуч, потім увімкніть бібліотеки форм UML, UML 2.5 та SysML. Натисніть кнопку «Застосувати». Погляньте на фігури, що знадобляться при створенні діаграми діяльності.

Рис. 27 Додавання наборів фігур в Draw io

• Діаграма діяльності не має суворих вимог щодо форми, кольору вказівника, лінії, фігур. Тому ви можете поекспериментувати з ними. Зверніть увагу на стилі кольорів та на тип лінії, вони доволі гарні.

Рис. 28 Панель вибору стилю

• Щоб створити діаграму з доріжками, зручно використовувати форми, які можна знайти в пошуку за назвою pool. Для зручності ви також можете зберігати до блокнота фігури з полотна або власні.

Рис.29 Пошук фігур

• За бажання, можна створювати діаграму в застосунках Lucidchart (Online, Android, IOS) та Microsoft Visio (платна програма для PC). Після завершення діаграми ви можете просто виділити, скопіювати та вставити її на полотно Draw io.

5. Draw io підтримує переходи над лініями. Якщо дві лінії перетинаються, ви можете зробити маленький горбочок-перехід для полегшення розуміння діаграми. Для цього натисніть на лінію та у меню стилів справа.

Рис. 30 Створення переходу над лініями

Приклади діаграм діяльності

Рис. 31 Діаграма виплати заробітної плати

Рис. 32 Діаграма приготування напою

Рис. 33 Діаграма входу в систему

Рис. 34 Діаграма роботи з документом