Презентація "Діаграми UML. Діаграми прецедентів"

Діаграми UML. Діаграми прецедентів

Що таке UML-діаграми?Unified Modeling Language (UML) — уніфікована мова моделювання. Розшифруємо: modeling передбачає створення моделі, що описує об'єкт. Unified (універсальний, єдиний) — підходить для широкого класу проектованих програмних систем, різних областей додатків, типів організацій, рівнів компетентності, розмірів проектів. UML описує об'єкт в єдиному заданому синтаксисі, тому де б ви не намалювали діаграму, її правила будуть зрозумілими для всіх, хто знайомий з цією графічною мовою

Для чого використовується UML?Одне із завдань UML — служити засобом комунікації всередині команди та при спілкуванні з замовником. Давайте розгляднемо можливі варіанти використання дігарам.  Проектування. UML-діаграми стануть у пригоді при моделюванні архітектури великих проектів, в якій можна зібрати як великі, так і дрібніші деталі і намалювати каркас (схему) програми. По ньому пізніше буде будуватись код.   Реверс-інжиніринг — створення UML-моделі з існуючого коду додатку, зворотна побудова. Может застосовуватися, наприклад, на проектах підтримки, де є написаний код, але документація неповна або відсутня.  З моделей можна витягувати текстову інформацію і генерувати відносто читабельні тексти — документувати. Текст і графіка будуть доповнювати один одного.

Нотація UML для опису логіки проекту. Як будь-яка інша мова, UML має власні правила оформлення моделей і синтаксис. За допомогою графічної нотації UML можна візуалізувати систему, об'єднати всі компоненти в єдину структуру, уточнювати і покращувати модель у процесі роботи. На загальному рівні графічна нотація UML містить 4 основні типи елементів:фігури; значки;лінії;написи. UML-нотація де-факто є галузевим стандартом у сфері розробки програмного забезпечення, ІТ-інфраструктури і бізнес-систем.

Популярні програми для створення діаграм. Diagrams.net — зручний сервіс для створення блок-схем, UML-діаграм, моделей бізнес-процесів онлайн. Сумісний з більшістю популярних інструментів, включаючи Google Docs, Git, Dropbox, One. Drive та інші. Dbdiagram.io — додаток для побудови діаграм зв'язків для баз даних. Хороший інструмент для розробників і аналітиків. Google Drawings — безкоштовний інструмент для створення блок-схем і діаграм в складі Google Drive (менш зручний порівняно з diagrams.net);

Види UML-діаграм 4 типи діаграм представляють статичну структуру додатку; 5 типів представляють поведінкові аспекти системи; 3 представляють фізичні аспекти функціонування системи (діаграми реалізацїі). В мові UML є 12 типів діаграм: Найбільш доступними з них є: Діаграма прецедентів (Use-case diagram); Діаграма класів (Class diagram); Діаграма активностей (Activity diagram); Діаграма послідовності (Sequence diagram); Діаграма розгортання (Deployment diagram);Діаграма співробітництва (Collaboration diagram)Діаграма об'єктів (Object diagram))Діаграма станів (Statechart diagram).

Діаграма прецедентів — Use-case diagram. Діаграма прецедентів — в UML, діаграма, на якій зображено відношення між акторами та прецедентами в системі. Також, перекладається як діаграма варіантів використання. Суть даної діаграми полягає в наступному: проектована система представляється у вигляді безлічі сутностей чи акторів, що взаємодіють із системою за допомогою так званих варіантів використання. Діаграми прецедентів відображають елементи моделі варіантів використання.

Діаграма прецедентів — Use-case diagram. Діаграма прецедентів використовує 2 основних елементи: 1) Actor (учасник) — множина логічно пов'язаних ролей, виконуваних при взаємодії з прецедентами або сутностями (система, підсистема або клас). Учасником може бути людина, роль людини в системі чи інша система, підсистема або клас, які представляють щось поза сутністю. 2) Use case (прецедент) — опис окремого аспекту поведінки системи з точки зору користувача. Прецедент не показує, "як" досягається певний результат, а тільки "що" саме виконується.

Актори (actors) діаграми прецедентів. Важливо зауважити два моменти: Поняття актора несе ролеву ознаку. (Актори, по суті, – це типи: актором є клієнт чи адміністратор, а не Петренко, Шевченко чи Буш). Акторами можуть виступати інші програмні системи. Актори позначаються у діаграмах прецедентів стилізованими людськими фігурками. Приклади акторів: Клієнт, адміністратор, білінгова система.

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

Прецеденти (Use case) . Як визначати прецеденти?Простий спосіб виявлення прецедентів полягає в тому, що треба розглянути кожного основного актора та визначити, які суттєві результати (суттєві цілі) він може переслідувати. Отже, прецеденти мають функціональне забарвлення, “прив'язуючись” до суттєвих цілей основних акторів. Прецеденти зображуються еліпсами. Як правило, для іменування прецедентів використовуються дієслова чи короткі дієслівні фрази (“Створення таблиці”, “Створити таблицю”)

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

Розглянемо класичний студентський приклад, в якому є 2 учасники: студент і бібліотекар. Прецеденти для студента: шукає в каталозі, замовляє, працює в читальному залі. Роль бібліотекаря: видача замовлення, консультації (рекомендації книг по темі, навчання використанню пошукової системи і заповнення бланків замовлення). Діаграма прецедентів — Use-case diagram

Діаграма прецедентів — Use-case diagram. Другий приклад дещо складніший. Бачимо, що одна і та сама особа може виступати в декількох ролях. Наприклад, product manager у нас працює над стратегією і більше нічим не займається, архітектор працює над стратегією і займається впровадженням, build master займається трьома речами одночасно, і так далі. За такою схемою ми можемо простежити, як  пов'язані між собою ролі і прецеденти.