Вибір інструменту проектування (UML). Діаграми класів UML

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

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

UML дозволяє також розробникам програмного забезпечення досягти угоди в графічних позначенняхдля подання загальних понять (таких як клас, компонент, узагальнення (generalization), об'єднання (aggregation) та поведінка), і більше сконцентруватися на проектуванні та архітектурі.

Мова UML є загальноцільовою мовою візуального моделювання, яка розроблена для специфікації, візуалізації, проектування та документування компонентів програмного забезпечення, бізнес-процесів та інших систем. Мова UML одночасно є простим і потужним засобом моделювання, який може бути ефективно використаний для побудови концептуальних, логічних та графічних моделей складних системрізного цільового призначення. Ця мова увібрала в себе найкращі якостіметодів програмної інженерії, які з успіхом використовувалися протягом останніх роківпри моделюванні великих та складних систем.

Мова UML заснована на деякій базових поняттях, які можуть бути вивчені та застосовані більшістю програмістів та розробників, знайомих з методами об'єктно-орієнтованого аналізу та проектування. При цьому базові поняттяможуть комбінуватися і розширюватися таким чином, що фахівці об'єктного моделювання отримують можливість самостійно розробляти моделі великих і складних систем у різних областях додатків.

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

Розробка діаграми варіантів використання має на меті:

Визначити загальні межі та контекст моделюваної предметної областіна початкових етапахпроектування системи;

Сформулювати Загальні вимогидо функціональної поведінки проектованої системи;

Розробити вихідну концептуальну модельсистеми для її подальшої деталізації у формі логічних та фізичних моделей;

Підготувати вихідну документацію для взаємодії розробників системи з її замовниками та користувачами.

Суть даної діаграми полягає в наступному: проектована система представляється у вигляді безлічі сутностей або акторів, що взаємодіють із системою за допомогою так званих варіантів використання. При цьому актором (actor) або дійовою особою називається будь-яка сутність, що взаємодіє із системою ззовні. Це може бути людина, технічний пристрій, програма або будь-яка інша система, яка може бути джерелом впливу на систему, що моделюється так, як визначить сам розробник. У свою чергу варіант використання (use case) служить для опису сервісів, які система надає актору. Іншими словами, кожен варіант використання визначає деякий набір дій, який здійснюється системою при діалозі з актором. При цьому нічого не йдеться про те, яким чином буде реалізовано взаємодію акторів із системою.

Діаграмою послідовностей (Sequence diagram) називається діаграма взаємодій, яка акцентує увагу на тимчасовій упорядкованості повідомлень. Графічно така діаграма є таблицею, об'єкти в якій розташовуються вздовж осі X, а повідомлення в порядку зростання часу - вздовж осі Y. Діаграмою кооперації (Collaboration diagram) називається діаграма взаємодій, основна увага приділяється структурної організаціїоб'єктів, які приймають та надсилають повідомлення. Графічно така діаграма є графом з вершин і ребер.

Діаграми послідовностей характеризуються двома особливостями, які відрізняють їхню відмінність від діаграм кооперації.

По-перше, ними показано лінія життя об'єкта. Це вертикальна пунктирна лінія, що відбиває існування об'єкта у часі. Більшість об'єктів, представлених на діаграмі взаємодій, існує протягом усього взаємодії, тому їх зображують у верхній частині діаграми, які лінії життя промальовані зверху до низу. Об'єкти можуть створюватися під час взаємодій. Лінії життя таких об'єктів починаються з отримання повідомлення із стереотипом create. Об'єкти можуть також знищуватись під час взаємодій; в такому випадку їх лінії життя закінчуються отриманням повідомлення зі стереотипом destroy, а як візуальний спосіб використовується велика літера X, що означає кінець життя об'єкта.

Друга особливість цих діаграм – фокус управління. Він зображується у вигляді витягнутого прямокутника, що показує проміжок часу, протягом якого об'єкт виконує будь-яку дію, безпосередньо або за допомогою підпорядкованої процедури. Верхня грань прямокутника вирівнюється по часовій осі з моментом початку дії, нижня - з моментом його завершення (і може бути позначено повідомленням про повернення). Вкладеність фокусу управління, викликану рекурсією (тобто зверненням до власної операції) або зворотним викликом з боку іншого об'єкта, можна показати, розташувавши інший фокус управління трохи правіше свого батька (допускається вкладеність довільно! Глибини). Якщо місце розташування фокусу керування потрібно вказати з максимальною точністю, можна заштрихувати область прямокутника, відповідну часу, протягом якого метод дійсно працює і не передає керування іншому об'єкту.

Діаграмою класів (Class diagram) називають діаграму, де показано безліч класів, інтерфейсів, кооперацій і відносин з-поміж них. Її зображують як безліч вершин і дуг.

Діаграми класів при моделюванні об'єктно-орієнтованих систем зустрічаються найчастіше. На таких діаграмах показується безліч класів, інтерфейсів, кооперацій та відносин між ними.

p align="justify"> Діаграми класів використовуються для моделювання статичного виду системи з точки зору проектування. Сюди переважно відноситься моделювання словника системи, кооперацій і схем. Крім того, діаграми класів складають основу ще двох діаграм - компонентів та розгортання.

Діаграми класів важливі не тільки для візуалізації, специфікації та документування структурних моделей, але також для прямого та зворотного проектування виконуваних систем.

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

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

Діаграма компонентів (Component diagram) показує набір компонентів та відносини між ними. Графічно діаграма компонентів представляється як графа з ребрами і вершинами.

На діаграмі розгортання або застосування (Deployment diagram) показана конфігурація обробних вузлів, на яких виконується система, та компонентів, розміщених у цих вузлах. Діаграма розгортання представлена у вигляді графа з ребрами та вершинами.

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

Visual Studio 2010 Ultimate надає достатньо зручні можливостідля реверс-інжинірингу. За допомогою засобів Visual Studio ми можемо на основі існуючого коду побудувати UML-модель та зрозуміти як у нас, власне, все працює, але при цьому не докладати гігантських зусиль щодо створення діаграм вручну та підтримки їх у актуальному стані.

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

Нещодавно Microsoft випустила додаток під назвою Microsoft Visual Studio 2010 Feature Pack 2 Цей інструментдає нам чудову можливість синхронізувати зміни моделі в код. Коротко розповім, як це можна використати.

Для прикладу припустимо, що ми маємо примітивний блог. Предметна область представлена двома класами: Author та Article. Додаємо в солюшн новий Modeling Project. У ньому створюємо UML Class Diagram.

Скористайтеся можливостями Reverse Engineering. Перетягуємо класи з Architecture Explorer на діаграму. У цьому діаграмі сутність з'являються разом із атрибутами. Періодично між сутностями утворюються зв'язки, які мають бути (і навіть періодично правильно показується тип зв'язку), але у яких випадках – визначити поки що не вийшло.

Як нам усім відомо, стандарт UML 2.0 визначає чотири стандартного типуДані: Boolean, Integer, String і UnlimitedNatural. Інші типи автоматично створюються у пакетах відповідно до розташування у просторах імен.NET.

Отже, спробуємо «полагодити» модель до адекватного стану, а заразом, трохи розширимо її. Для цього, створюємо на діаграмі новий клас, в UML Model Explorer перетягуємо його в потрібний Package і вибираємо стереотип C# Class (Microsoft додала кілька специфічних для .NET стереотипів, які використовуються при кодогенерації).

Зауважте, даний класще не присутній у збірці Domain. Для того щоб прописати його туди, а заразом застосувати всі наші зміни, потрібно зробити наступне.

У Model Explorer вибираємо складання Domain, йдемо в Properties і в пункті Text Template Binding тикаємо кнопку «…». Додаємо новий елемент, у полі Project Path вказуємо ім'я проекту, в який буде генеруватися код, у полі Target Directory вказуємо папочку щодо проекту (ми генеруємо в корінь) та вказуємо адресу шаблону. За замовчуванням вони знаходяться в папці "C: Program Files (x86) Microsoft Visual Studio 10.0 Common7 IDE Extensions Microsoft Visualization and Modeling Feature Pack 2.0 Templates Text". Можна встановити кілька шаблонів на всі випадки життя. У нашому випадку вибираємо ClassTemplate.t4.

Після цього, натискаємо правою кнопочкою миші вільне місцедіаграми та вибираємо пункт Generate Code.

І – вуаля! Новий класдодано до збирання, всі зміни застосовані відповідно до моделі.

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

Отже, M$ пропонує нам чудовий інструмент, що серйозно полегшує життя архітекторам та розробникам. На жаль, це дуже необхідний пакетдоступний лише передплатникам MSDN, і компанія чомусь не дає змоги використовувати його всім бажаючим легальним користувачам. І це за вартості VS Ultimate близько 300 тис. рублів. Сподіватимемося, що в найближчому майбутньому такий стан речей зміниться.

Усі діаграми UML можна умовно розбити на дві групи, перша з яких – спільні діаграми. Загальні діаграми практично не залежать від предмета моделювання та можуть застосовуватись у будь-якому програмному проекті без огляду на предметну область, область рішень тощо.

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

Діаграма використання(use case diagram) ‒ це найбільш загальне уявлення функціонального призначеннясистеми.

Діаграма використання покликана відповісти на головне питаннямоделювання: що робить система у зовнішньому світі?

На діаграмі використання застосовуються два типи основних сутностей: варіанти використання 1 та дійові особи 2 , між якими встановлюються такі основні типи відносин:

асоціація між дійовою особою та варіантом використання 3 ;
узагальнення між дійовими особами 4;
узагальнення між варіантами використання 5;
залежності ( різних типів) між варіантами використання 6 .

На діаграмі використання, як і на будь-якій іншій, можуть бути коментарі 7 . Більш того, це настійно рекомендується робити для покращення читання діаграм.

Основні елементи нотації, які застосовуються на діаграмі використання, показані нижче. Детальний описнаведено у розділі 2.2.

1.5.2. Діаграма класів

Діаграма класів(class diagram) – основний спосіб опису структури системи.

Це не дивно, оскільки UML насамперед об'єктно-орієнтована мова, і класи є основним (якщо не єдиним) "будівельним матеріалом".

На діаграмі класів застосовується один основний тип сутностей: класи 1 (включаючи численні окремі випадки класів: інтерфейси, примітивні типи, класи-асоціації та багато інших), між якими встановлюються такі основні типи відносин:

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

Деякі елементи нотації, які застосовуються на діаграмі класів, показано нижче. Детальний опис наведено у розділі 3 .

1.5.3. Діаграма автомата

Діаграма автомата(state machine diagram) ‒ це один із способів детального опису поведінки в UML на основі явного виділення станів та опису переходів між станами.

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

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

Детальний опис всіх варіацій діаграм автомата наведено у розділі 4.2, а на наступному малюнку показані лише основні елементи нотації, що застосовуються на діаграмі автомата.

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

Діаграма діяльності (activity diagram) ‒ спосіб опису поведінки на основі вказівки потоків управління та потоків даних.

Діаграма діяльності – ще один спосіб опису поведінки, що візуально нагадує стару добру блок-схему алгоритму. Однак за рахунок модернізованих позначень, узгоджених з об'єктно-орієнтованим підходом, а головне за рахунок нової семантичної складової (вільна інтерпретація мереж Петрі), діаграма діяльності UML є потужним засобом для опису поведінки системи.

На діаграмі діяльності застосовують один основний тип сутностей - дію 1, і один тип відносин - переходи 2 (передачі управління та даних). Також використовуються такі конструкції як розвилки, злиття, з'єднання, розгалуження 3 , які схожі на сутності, але такими насправді не є, а є графічний спосібзображення деяких окремих випадків багатомісних відносин. Семантика елементів діаграм діяльності докладно розібрано у розділі 4 . Основні елементи нотації, які застосовуються на діаграмі діяльності, показані нижче.

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

Діаграма послідовності(sequence diagram) ‒ це спосіб опису поведінки системи на основі вказівки послідовності повідомлень, що передаються.

Фактично діаграма послідовності – це запис протоколу конкретного сеансу роботи системи (або фрагмента такого протоколу). В об'єктно-орієнтованому програмуванні найістотнішим під час виконання є пересилання повідомлень між об'єктами, що взаємодіють. Саме послідовність посилок повідомлень відображається на даній діаграмі, звідси назва.

На діаграмі послідовності застосовують один основний тип сутностей - екземпляри взаємодіючих класифікаторів 1 (в основному класів, компонентів та дійових осіб), і один тип відносин - зв'язку 2, за якими відбувається обмін повідомленнями 3 . Передбачено кілька способів посилки повідомлень, які у графічній нотації різняться видом стрілки, що відповідає відношенню.

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

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

На наступному малюнку показані основні елементи нотації, які застосовуються на діаграмі послідовності. Для позначення самих взаємодіючих об'єктів застосовується стандартна нотація прямокутник з ім'ям екземпляра класифікатора. Пунктирна лінія, що виходить із нього, називається лінією життя (lifeline) 4 . Це не позначення відношення в моделі, а графічний коментар, покликаний звернути увагу читача діаграми в правильному напрямку. Фігури у вигляді вузьких смужок, накладених на лінію життя, також не є зображеннями сутностей, що моделюються. Це графічний коментар, Який показує відрізки часу, протягом яких об'єкт володіє потоком управління (execution occurrence) 5 чи іншими словами має місце активація (activation) об'єкта. Складові кроки взаємодії (combined fragment) 6 дозволяють на діаграмі послідовності, відображати алгоритмічні аспекти протоколу взаємодії. Інші деталі нотації діаграми послідовностей див. у розділі 4 .

1.5.6. Діаграма комунікації

Діаграма комунікації(Communication diagram) ‒ спосіб опису поведінки, семантично еквівалентний діаграмі послідовності.

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

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

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

1.5.7. Діаграма компонентів

Діаграма компонентів(component diagram) ‒ показує взаємозв'язки між модулями (логічними або фізичними), з яких складається система, що моделюється.

Основний тип сутностей на діаграмі компонентів - це самі компоненти 1, а також інтерфейси 2, за допомогою яких вказується взаємозв'язок між компонентами. На діаграмі компонентів застосовуються такі відносини:

реалізації між компонентами та інтерфейсами (компонент реалізує інтерфейс);
залежності між компонентами та інтерфейсами (компонент використовує інтерфейс) 3 .

На малюнку показано основні елементи нотації, які застосовуються на діаграмі компонентів. Детальний опис наведено у розділі 3 .

1.5.8. Діаграма розміщення

Діаграма розміщення(Deployment diagram) поряд з відображенням складу та зв'язків елементів системи показує, як вони фізично розміщені на обчислювальних ресурсах під час виконання.

Таким чином, на діаграмі розміщення, порівняно з діаграмою компонентів, додається два типи сутностей: артефакт 1 , який є реалізацією компонента 2 і вузол 3 (можливо як класифікатор, що описує тип вузла, так і конкретний екземпляр), а також відношення асоціації між вузлами 4 показує, що вузли фізично пов'язані під час виконання.

На малюнку показані основні елементи нотації, які застосовуються на діаграмі розміщення. Для того щоб показати, що одна сутність є частиною іншої, застосовується або відношення залежності «deploy» 5 або фігура однієї сутності міститься всередину фігури іншої сутності 6 . Детальний опис діаграми наведено у розділі 3 .

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