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

Що таке UML?

Якщо подивитися картинки у пошукових системах, то стане зрозуміло, що UML– це щось про схеми, стрілочки та квадратики. Що важливо, що UML перекладається як Unified Modeling Language. Важливе слово Unified. Тобто наші картинки зрозуміємо не лише ми, а й інші, хто знає UML. Виходить це така міжнародна мова малювання схем.

Як говорить Вікіпедія

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

Найцікавіше, що не всі замислюються чи здогадуються, UML має специфікації. І навіть є специфікація UML2. Докладніше зі специфікацією можна ознайомитись на сайті Object Management Group. Власне, ця група займається розробкою специфікацій UML. Цікаво, що UML не обмежується описом структури класів. Існує багато типів UML діаграм. Короткий опис типів UML діаграм можна побачити в тій же Вікіпедії: UML - діаграми або відео Тимура Батиршинова Огляд UML діаграм. UML також широко застосовується при описі різних процесів, наприклад тут: Єдиний вхід з використанням JWT . Повертаючись до використання UML діаграм класів, варто відзначити книгу Head First: Паттерни проектування, в якій патерни ілюструються тими самими UML діаграмами. Виходить, що UML справді використовується. І виходить, що знання та розуміння його застосування досить корисна навичка.

Застосування

Розберемо, як із цим UML можна працювати з IDE. Як IDE візьмемо IntelliJ Idea. Якщо використовувати IntelliJ Idea Ultimate, то у нас "з коробки" буде встановлений плагін " UML SupportВін дозволяє автоматично генерувати красиві діаграми класів. Наприклад, через Ctrl+N або пункт меню "Navigate" -> "Class" перейдемо в клас ArrayList. Тепер, через контекстне меню на ім'я класу виберемо "Diagram" -> "Show diagram popup". В результаті ми отримаємо гарну діаграму:

Але що якщо хочеться самому намалювати, та ще й немає Ultimate версії Idea? Якщо ми використовуємо IntelliJ Idea Community Edition, то ми не маємо іншого вибору. Для цього потрібно зрозуміти, як така схема UML влаштована. Для початку нам знадобиться встановити Graphviz. Це набір утиліт для візуалізації графів. Його використовує плагін, який ми будемо застосовувати. Після встановлення необхідно додати каталог binз каталогу встановленого Graphvizу змінну середовища оточення PATH. Після цього IntelliJ Idea в меню вибрати File -> Settings. У вікні "Settings" вибрати категорію "Plugins", натиснути кнопку "Browse repositories" та встановити плагін PlantUML integration. Чим такий гарний цей PlantUML? Він використовує для опису UML мову опису графів під назвою " dotі це дозволяє йому бути більш універсальним, тому що ця мова використовується не тільки PlantUML. нас з'явиться можливість через "File" -> "New" створювати UML діаграми. Давайте виконаємо створення діаграми типу "UML class". від UML до коду А щоб зрозуміти, як це зобразити в тексті, візьмемо мануал по PlantUML: plantuml class-diagram У ньому на самому початку представлена ​​табличка з тим, як потрібно описувати зв'язки:

Про самі зв'язки можемо ще підглядати сюди: "Відносини між класами в UML. Приклади ". На основі цих матеріалів приступимо до створення нашої UML діаграми. Додамо наступний вміст, який описує два класи: @startuml class ArrayList ( ) class LinkedList ( ) @enduml Щоб побачити результат в Idea, виберемо "View" -> "Tool Windows" -> "PlantUML". Ми отримаємо просто два квадрати, що позначають класи. Як ми знаємо, обидва ці класи реалізують інтерфейс List. Це ставлення класів і називають - реалізація (realization). Для зображення такого зв'язку використовують стрілку з пунктирною лінією. Зобразимо її: interface List List< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о package privateмасив елементів: ~ Object elementData Тепер ми хочемо показати, що ArrayList містить якісь об'єкти. В даному випадку буде тип зв'язку - агрегація(Aggregation). Агрегатом у разі є ArrayList , т.к. він містить інші об'єкти. Агрегацію ми вибираємо тому, що об'єкти у списку можуть жити без списку: вони не є його невід'ємними частинами. Їхній час життя не прив'язаний до часу життя списку. Агрегат з латинського перекладається як "зібраний", тобто щось складене з чогось. Наприклад, у житті є насосний агрегат, який складається з насоса та двигуна. Сам агрегат можна розібрати, залишивши щось із його складових частин. Наприклад, щоб продати чи поставити в інший агрегат. Так і у списку. І це виражається у вигляді порожнього ромбика біля агрегату і безперервної лінії. Зобразимо це так: class Object ( ) ArrayList o- Object Тепер ми хочемо показати, що на відміну від ArrayList , клас LinkedList містить у собі Node - контейнери, що посилаються на дані, що зберігаються. В даному випадку Node є частиною самого LinkedList і не можуть жити окремо. Node не є безпосередньо збереженим вмістом, а лише містить посилання на нього. Наприклад, коли ми додаємо до LinkedList якийсь рядок, ми додаємо новий Node , який містить посилання на цей рядок, а також посилання на попередній і наступний Node . Такий тип зв'язку називається композицією(Composition). Для відображення у композита (того, хто складається з частин) малюється забарвлений робмик, до нього веде безперервна лінія. Запишемо тепер це у вигляді текстового відображення зв'язку: class Node ( ) LinkedList * -- Node І тепер необхідно навчитися відображати ще один важливий тип зв'язку - залежність(dependency relationship). Він використовується тоді, коли один клас використовує інший, при цьому клас не містить клас, що використовується, і не є його спадкоємцем. Наприклад, LinkedList і ArrayList вміють створювати ListIterator. Відобразимо це у вигляді стрілок з пунктирною лінією: ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:

Деталізувати можна настільки, наскільки це потрібно. Всі позначення вказані тут: "PlantUML - діаграма класів". Крім того, у малюванні такої схеми немає нічого надприродного, і під час роботи над своїми завданнями її можна швидко малювати від руки. Це дозволить розвинути навички продумування архітектури програми та допоможе виявити недоліки структури класів на ранньому етапі, а не коли ви вже витратите день на реалізацію неправильної моделі. Мені здається, це непогана причина для того, щоб спробувати?

Автоматизація

Існують різні способи автоматичної генерації PlantUML діаграм. Наприклад, в Ideaє плагін SketchIT, але малює він їх не зовсім правильно. Скажімо, неправильно малюється імплементація інтерфейсів (відображається як спадкування). Також в інтернеті є приклади того, як це вбудувати у життєвий цикл складання вашого проекту. Допустимо, для Mavenє приклад використання uml-java-docklet. Для того, щоб показати як це, скористаємося Maven Archetype для швидкого створення Maven проекту. Виконаємо команду: mvn archetype:generate На питанні вибору фільтра ( Choose a number or apply filter) залишаємо default, просто натиснувши Enter. Це завжди буде maven-archetype-quickstartДалі відповідаємо на запитання і завершуємо створення проекту:

Оскільки Maven не є метою цієї статті, відповіді на свої запитання щодо Maven можна знайти в Maven Users Centre . У створеному проекті відкриємо на редагування файл опису проекту, pom.xml. У нього скопіюємо вміст із опису uml-java-docklet installing. Артефакт, що використовується в описі, не вдалося знайти в репозиторії Maven Central. Але у мене запрацювало з цим: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0. Тобто треба в тому описі просто замінити groupIdз " info.leadinglight"на" com.chfourie" і поставити версію " 1.0.0 Після цього можемо виконати в каталозі, де знаходиться файл pom.xmlці команди: mvn clean install та mvn javadoc:javadoc . Тепер, якщо відкрити згенеровану документацію (explorer targetsiteapidocsindex.html), ми побачимо UML схеми. До речі, імплементація тут вже відображається правильно)

Висновок

Як видно, UML дозволяє візуалізувати структуру вашої програми. Крім того, UML не обмежується лише цим. За допомогою UML можна описувати різні процеси всередині вашої компанії або описувати бізнес-процес, в рамках якого працює функція, яку ви пишете. Наскільки UML корисний особисто для вас - вирішувати вам, але знайти час і ознайомитися докладніше буде в будь-якому випадку корисно. #Viacheslav English version of this post: UML diagram Java на CodeGym

В даний час мова UML – це стандартна нотація візуального моделювання програмних систем, ухвалена консорціумом Object Managing Group (OMG) восени 1997 р., яка підтримується багатьма об'єктно-орієнтованими CASE-продуктами.

Стандарт UML пропонує наступний набір діаграм для моделювання:

· діаграма варіантів використання (use case diagram) – для моделювання бізнес-процесів організації чи підприємства та визначення вимог до створюваної інформаційної системи;

· діаграма класів (class diagram) – для моделювання статичної структури класів системи та зв'язків між ними;

· Діаграма поведінки системи (behavior diagrams);

· Діаграма взаємодії (interaction diagrams);

· діаграма послідовності (sequence diagrams) – для моделювання процесу обміну повідомленнями між об'єктами у межах одного варіанта використання;

· діаграма кооперації (collaboration diagram) – для моделювання процесу обміну повідомленнями між об'єктами у межах одного варіанта використання;

· Діаграма станів (statechart diagram) - для моделювання поведінки об'єктів системи при переході з одного стану в інший;

· Діаграма видів діяльності (activity diagram) - для моделювання поведінки системи в рамках різних варіантів використання, або моделювання діяльностей;

· Діаграма реалізації (implementation diagrams):

· Діаграма компонентів (component diagrams) - для моделювання ієрархії компонентів (підсистем) інформаційної системи;

· Діаграма розгортання (deployment diagram) – для моделювання фізичної архітектури спроектованої інформаційної системи.

На рис. 1.1 представлена ​​інтегрована модель інформаційної системи, що включає основні діаграми, які мають бути розроблені у цьому курсовому проекті.

Мал. 1. Інтегрована модель інформаційної системи у нотації мови UML

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

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

Рис.2. Варіант використання

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

Рис.3. Діюча особа (актор)

Актори поділяються на три основні типи:

· Користувачі;

· Системи;

· Інші системи, що взаємодіють з даною;

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

4.2.1. Зв'язки між варіантами використання та акторами

У мові UML на діаграмах варіантів використання підтримується кілька типів зв'язків між елементами діаграми:

· Комунікація (communication),

· Включення (include),

· Розширення (extend),

· Узагальнення (generalization).

Зв'язок комунікації– це зв'язок між варіантом використання та актором. Мовою UML зв'язку комунікації показують за допомогою односпрямованої асоціації (суцільної лінії).

Рис.4. Приклад зв'язку комунікації

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

Зв'язок розширеннязастосовується при описі змін у нормальній поведінці системи. Вона дозволяє одному варіанту використання за необхідності використовувати функціональні можливості іншого варіанта використання.

Рис.5. Приклад зв'язку включення та розширення

Зв'язок узагальненняпоказує, що в кількох акторів чи класів є спільні властивості.

Рис.6. Приклад зв'язку узагальнення

4.3.

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

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

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

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

Імперативне (imperative) повідомлення- Це повідомлення, що запитує у об'єкта-отримувача виконання деяких дій.

Існує два види діаграм взаємодії: діаграми послідовності (sequence diagrams) та діаграми кооперації (collaboration diagrams).

4.3.1. Діаграма послідовності (sequence diagrams)

Діаграма послідовностівідображає потік подій, що відбуваються в рамках одного варіанта використання.

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

На діаграмі послідовності об'єкт зображується у вигляді прямокутника, від якого вниз проведено пунктирну вертикальну лінію. Ця лінія називається лінією життя (lifeline) об'єкта . Вона є фрагментом життєвого циклу об'єкта у процесі взаємодії.

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

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

4.3.2. Діаграма кооперації (collaboration diagram)

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

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

Мал. 8. Приклад діаграми кооперації

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

4.4.1. Загальні відомості

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

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

На діаграмі класів відображаються такі елементи:

· Пакет (package) – набір елементів моделі, логічно пов'язаних між собою;

· Клас (class) – опис загальних властивостей групи подібних об'єктів;

· Інтерфейс (interface) - абстрактний клас, що задає набір операцій, які об'єкт довільного класу, пов'язаного з цим інтерфейсом, надає іншим об'єктам.

4.4.2. Клас

Клас- це група сутностей (об'єктів), що володіють подібними властивостями, а саме даними та поведінкою. Окремий представник деякого класу називається об'єктом класу чи просто об'єктом.

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

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

Верхня секція містить ім'я класу та інші загальні властивості (зокрема, стереотип).

У середній секції міститься список атрибутів

У нижній - список операцій класу, що відбивають його поведінку (дії класу).

Будь-яка з секцій атрибутів та операцій може не зображуватись (а також обидві відразу). Для відсутньої секції не потрібно малювати розділову лінію і будь-яким чином вказувати на наявність або відсутність елементів у ній.

На розсуд конкретної реалізації можуть бути введені додаткові секції, наприклад винятки (Exceptions).

Мал. 9. Приклад діаграми класів

4.4.2.1.Стереотипи класів

Стереотипи класів – це механізм, що дозволяє розділяти класи на категорії.

У мові UML визначено три основні стереотипи класів:

Boundary (кордон);

Entity (сутність);

Control (Управління).

4.4.2.2.Граничні класи

Межовими класами (boundary classes) називаються такі класи, які розташовані на межі системи та всього навколишнього середовища. Це екранні форми, звіти, інтерфейси з апаратурою (такі як принтери або сканери) та інтерфейси з іншими системами.

Щоб знайти граничні класи, слід досліджувати діаграми варіантів використання. Кожній взаємодії між дійовою особою та варіантом використання повинен відповідати принаймні один граничний клас. Саме такий клас дозволяє дійовій особі взаємодіяти із системою.

4.4.2.3.Класи-сутності

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

4.4.2.4.Керівні класи

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

У системі можуть бути й інші класи, що управляють, загальні для декількох варіантів використання. Наприклад, може бути клас SecurityManager (менеджер безпеки), який відповідає за контроль подій, пов'язаних з безпекою. Клас TransactionManager (менеджер транзакцій) займається координацією повідомлень, які стосуються транзакцій з базою даних. Можуть бути інші менеджери для роботи з іншими елементами функціонування системи, такими як поділ ресурсів, розподілена обробка даних або обробка помилок.

Крім згаданих вище стереотипів, можна створювати і свої власні.

4.4.2.5.Атрибути

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

Оскільки атрибути містяться всередині класу, вони приховані з інших класів. У зв'язку з цим може знадобитися вказати, які класи мають право читати та змінювати атрибути. Ця властивість називається видимістю атрибуту (attribute visibility).

У атрибута можна визначити чотири можливі значення цього параметра:

Public (загальний, відкритий). Це значення видимості передбачає, що атрибут буде видно усіма іншими класами. Будь-який клас може переглянути чи змінити значення атрибута. Відповідно до нотації UML загальному атрибуту передує знак "+".

Private (закритий, таємний). Відповідний атрибут не видно жодним іншим класом. Закритий атрибут позначається знаком « – » відповідно до нотації UML.

Protected (захищений). Такий атрибут доступний лише самому класу та його нащадкам. Нотація UML для захищеного атрибута – це знак «#».

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

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

4.4.2.6.Операції

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

Параметри – це аргументи, які отримують операція «на вході». Тип значення, що повертається відноситься до результату дії операції.

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

У мові UML операції мають таку нотацію:

Ім'я Операції (аргумент: тип даних аргументу, аргумент2: тип даних аргументу2,...): тип значення, що повертається

Слід розглянути чотири різні типи операцій:

операції реалізації;

Операції керування;

Операції доступу;

Допоміжні операції.

Операції реалізації

Операції реалізації (implementor operations) реалізують деякі бізнес-функції. Такі операції можна визначити, досліджуючи діаграми взаємодії. Діаграми цього фокусуються на бізнес-функціях, і кожне повідомлення діаграми, швидше за все, можна співвіднести з операцією реалізації.

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

Операції управління

Операції управління (manager operations) управляють створенням та знищенням об'єктів. У цю категорію потрапляють конструктори та деструктори класів.

Операції доступу

Атрибути зазвичай бувають закритими чи захищеними. Тим не менш, інші класи іноді повинні переглядати чи змінювати їх значення. І тому існують операції доступу (access operations). Такий підхід дає можливість безпечно інкапсулювати атрибути всередині класу, захистивши їх від інших класів, але все ж таки дозволяє здійснити до них контрольований доступ. Створення операцій Get та Set (отримання та зміни значення) для кожного атрибуту класу є стандартом.

Допоміжні операції

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

Щоб ідентифікувати операції, виконайте такі дії:

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

2. Розгляньте керуючі операції. Може знадобитися додати конструктори та деструктори.

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

4.4.2.7.Зв'язки

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

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

Зв'язок асоціація

Асоціація – це семантичний зв'язок між класами. Їх малюють на діаграмі класів як звичайної лінії.

Мал. 10. Зв'язок асоціація

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

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

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

Зв'язок залежність

Зв'язки залежності (dependency) також відбивають зв'язок між класами, але вони завжди односпрямовані і показують, що клас залежить від визначень, зроблених іншому. Наприклад, клас A використовує методи класу B. Тоді при зміні класу B необхідно зробити відповідні зміни у класі A.

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

Мал. 11. Зв'язок залежність

При генерації коду для цих класів до них не додаватимуться нові атрибути. Проте, буде створено специфічні для мови оператори, необхідні підтримки зв'язку.

Зв'язок агрегація

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

Мал. 11. Зв'язок агрегація

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

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

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

Коротка історія UML

До середини 90-х років різними авторами було запропоновано кілька десятків методів ГО моделювання, кожен із яких використовував свою графічну нотацію. При цьому будь-який з цих методів мав свої сильні сторони, але не дозволяв побудувати досить повну модель ПС, показати її «з усіх боків», тобто всі необхідні проекції (див. статтю 1). До того ж відсутність стандарту ГО моделювання ускладнювало для розробників вибір найбільш відповідного методу, що перешкоджало поширенню ГО підходу до розробки ПС.

За запитом Object Management Group (OMG) – організації, відповідальної за прийняття стандартів у галузі об'єктних технологій та баз даних, назрілу проблему уніфікації та стандартизації було вирішено авторами трьох найбільш популярних ГО методів – Г.Бучем, Д.Рамбо та А.Джекобсоном, які об'єднані зусиллями створили версію UML 1.1, затверджену OMG у 1997 році як стандарт.

UML – це мова

Будь-яка мова складається зі словника та правил комбінування слів для отримання осмислених конструкцій. Так, зокрема, влаштовані мови програмування, такою є UML. Відмінною його особливістю є те, що словник утворюють графічні елементи. Кожному графічному символу відповідає конкретна семантика, тому модель, створена одним розробником, може бути однозначно зрозуміла іншим, а також програмним засобом, що інтерпретує UML. Звідси, зокрема, випливає, що модель ПС, представлена ​​на UML, може автоматично бути переведена на ГО мову програмування (такі як Java, C++, VisualBasic), тобто, за наявності гарного інструментального засобу візуального моделювання, що підтримує UML, побудувавши модель , ми отримаємо і заготівлю програмного коду, що відповідає цій моделі.

Слід наголосити, що UML – це саме мова, а не метод. Він пояснює, з яких елементів створювати моделі та як їх читати, але нічого не говорить про те, які моделі та в яких випадках слід розробляти. Щоб створити метод з урахуванням UML, треба доповнити його описом процесу розробки ПС. Прикладом такого процесу є Rational Unified Process, який розглядатиметься у наступних статтях.

Словник UML

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

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

Відносинипоказують різні зв'язки між сутностями. У UML визначено такі типи відносин:

• Залежністьпоказує такий зв'язок між двома сутностями, коли зміна однієї з них – незалежної – може вплинути на семантику іншою – залежною. Залежність зображується пунктирною стрілкою, спрямованої від залежної сутності незалежної.
• Асоціація- Це структурне відношення, що показує, що об'єкти однієї сутності пов'язані з об'єктами іншої. Графічно асоціація показується у вигляді лінії, що з'єднує сутності, що зв'язуються. Асоціації служать для навігації між об'єктами. Наприклад, асоціація між класами «Замовлення» та «Товар» може бути використана для знаходження всіх товарів, зазначених у конкретному замовленні – з одного боку, або для знаходження всіх замовлень, у яких є даний товар, – з іншого. Зрозуміло, що у відповідних програмах має бути реалізований механізм, що забезпечує таку навігацію. Якщо потрібна навігація лише в одному напрямку, воно показується стрілкою наприкінці асоціації. Приватним випадком асоціації є агрегування – ставлення до виду «ціле» – «частина». Графічно воно виділяється за допомогою ромбіка на кінці біля сутності цілого.
• Узагальнення- Це відношення між сутністю-батьком і сутністю-нащадком. Фактично, це ставлення відбиває властивість успадкування для класів, і об'єктів. Узагальнення показується у вигляді лінії, що закінчується трикутником, спрямованим до батьківської сутності. Нащадок успадковує структуру (атрибути) і поведінку (методи) батька, але водночас може мати нові елементи структури і нові методи. UML допускає множинне успадкування, коли сутність пов'язана з більш ніж однією батьківською сутністю.
• Реалізація- Відношення між сутністю, що визначає специфікацію поведінки (інтерфейс) з сутністю, що визначає реалізацію цієї поведінки (клас, компонент). Це ставлення зазвичай використовується при моделюванні компонентів і буде докладніше описано в наступних статтях.

діаграми.У UML передбачені такі діаграми:

• Діаграми, що описують поведінку системи:
• Діаграми станів (State diagrams),
• Діаграми діяльності (Activity diagrams),
• Діаграми об'єктів (Object diagrams),
• Діаграми послідовностей (Sequence diagrams),
• Діаграми взаємодії (Collaboration diagrams);
• Діаграми, що описують фізичну реалізацію системи:
• Діаграми компонентів (Component diagrams);
• Діаграми розгортання (Deployment diagrams).

Подання керування моделлю. Пакети.

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

Що забезпечує UML.

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

І останнє…

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

Показати поведінку одного об'єкта протягом його життя, починаючи від створення об'єкта та закінчуючи його знищенням. Кожна діаграма станів є деяким автоматом.

План дій

У розділі «Опис» вивчіть основний набір символів діаграми станів, необхідний для вміння читати діаграми.

Після ознайомлення з іншими розділами («Приклад», «Застосування»), ви можете спробувати свої сили в самостійному складанні діаграм станів.

Зауваження (опис)

Тут представлений основний набір символів діаграми станів, необхідний для того, щоб прочитати діаграму. Після ознайомлення з іншими розділами («Приклад», «Застосування») ви зможете складати діаграми станівсамостійно!

Термін	Зображення	Опис
Початковий псевдостан (initial pseudostate)		Початковий стан системи
Перехід		Перехід (transition) означає переміщення з одного стану до іншого.
Стан		Позначає виконувані системою дії (можуть включати можливі варіанти), що призводять до результатів, що спостерігаються акторами.
Стан активності (activity state)		Складний крок у прецеденті можна уявити іншим прецедентом. У термінах мови UML ми говоримо, перший прецедент включає (includes) другий.
Кінцевий стан		Дозволяє визначити межі систем або підсистем.
Внутрішні активності (Internal activities)		Випадок коли стану можуть реагувати на події без здійснення переходу, і в цьому випадку подія, захист та активність розміщуються усередині прямокутника стану.
Вхідна активність		Вхідна активність виконується щоразу, коли ви входите у стан
Вихідна активність		Вихідна активність – виконується щоразу, коли ви залишаєте стан.
Суперстан		Часто буває, що кілька станів мають загальні переходи та внутрішні активності. У таких випадках можна їх перетворити на підстани (substates), а загальну поведінку перенести на суперстан (superstate).
Паралельні стани		Стани можуть бути розбиті на кілька паралельних станів, що запускаються одночасно.

Як застосовувати техніку креативності

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

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

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

Багато фахівців вважають, що редактор UI та об'єкти, що управляють, мають функціональні засоби, корисні при відображенні за допомогою діаграми станів .

Як навчитися

Тут ми спробували надати якомога простіший спосіб вивчення діаграми станів мови UML.

Як і багато інших мов він використовує для опису набір символів. Зміст цих знаків ви знайдете в таблиці у розділі «Зауваження (опис)». Кожен знак має своє найменування (термін) та написання. Також кожен термін має коротке пояснення, щоб швидко усвідомити його основну суть.

Далі ми б рекомендували перейти до розділу «Приклади» діаграм станівспробувати свої сили в читанні різних діаграм. Потім варто вивчити розділ «Застосування», оскільки, хоч і кількість типів діаграм в UML невелика, максимум переваг від їх використання ви зможете отримати лише якщо застосовувати відповідні діаграми за призначенням.

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

Діаграма станів (state machine diagrams)- Це відома технологія опису поведінки системи. У тому чи іншому вигляді діаграма станів існує з 1960 року, і на зорі об'єктно-орієнтованого програмування вони застосовувалися для подання поведінки системи. В об'єктно орієнтованих підходах ви малюєте діаграму станів єдиного класу, щоб показати поведінку одного об'єкта протягом його життя.

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

На рис. 10.1 показано діаграма станівкласу контролера, який керує моєю незвичайною системою безпеки. Діаграма стану починається зі стану створюваного об'єкта контролера: стану Wait (Чекання). На діаграмі це позначено за допомогою початкового псевдостатку (initial pseudostate)що не є станом, але має стрілку, що вказує на початковий стан.
На діаграмі показано, що контролер може бути в одному з трьох станів: Wait (Очікування), Lock (Замок) та Open (Відкритий). На діаграмі також представлені правила, згідно з якими контролер переходить із одного стану в інший. Ці правила представлені у вигляді переходів – ліній, які пов'язують стани.

Перехід (transition) означає переміщення з одного стану до іншого. Кожен перехід має свою мітку, яка складається із трьох частин:
тригер-ідентифікатор [захист]/активність (trigger-signature /activity). Усі вони не є обов'язковими. Як правило, тригер-ідентифікатор– це єдина подія, яка може спричинити зміну стану.

Захист, якщо він зазначений, є логічною умовою, яка має бути виконана, щоб перехід мав місце. Активність – це деяка поведінка системи під час переходу. Це може бути будь-який поведінковий вираз. Повна форма тригера-ідентифікатора може містити кілька подій та параметрів. Перехід зі стану Wait (рис. 10.1) в інший стан можна прочитати як «У стані Wait, якщо свічка видалена, ви бачите замок і переходите у стан Lock».

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

Коли в певному стані відбувається подія, то з цього стану можна зробити лише один перехід, наприклад, у стані Lock (рис. 10.1) захисту повинні бути взаємно виключають. Якщо подія відбувається, а дозволених переходів немає - наприклад, закриття сейфа в стані Wait або видалення свічки при відкритих дверях, - подія ігнорується.

Кінцевий стан ( final state) означає, що кінцевий автомат закінчив роботу, що викликає видалення об'єкта контролера. Тому для тих, хто мав необережність потрапити в пастку, повідомляємо, що оскільки об'єкт контролера припиняє своє існування, ми змушені посадити кролика назад у клітку, вимити підлогу та перевантажити систему.

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

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

Внутрішні активності у діаграмі станів

Стани можуть реагувати на події без здійснення переходу, використовуючи внутрішні активності (internal activities), і в цьому випадку подія, захист та активність розміщуються всередині прямокутника стану.

На рис. 10.2 представлений стан із внутрішніми активностями символів та подіями системи допомоги, які ви можете спостерігати у текстових полях редактора UI. Внутрішня активність подібна до самопереходу (self-transition) – переходу, який повертає в той самий стан. Синтаксис внутрішніх активностей побудований за тією ж логічною схемою події, захисту та процедури.

На рис. 10.2 показані також спеціальні активності: вхідна та вихідна активності. Вхідна активністьвиконується щоразу, коли ви входите у стан; вихідна активність- Щоразу, коли ви залишаєте стан. Однак внутрішні активності не ініціюють вхідну та вихідну активності; у цьому полягає різниця між внутрішніми активностями тасамопереходами .

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

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

Стан Searching (Пошук)на рис. 10.3 є таким станом активності (activity state): активність, що ведеться, позначається символом do/; звідси термін do-activity (виявляти активність). Після пошуку завершено переходи без активності, наприклад показ нового обладнання (Display New Hardware). Якщо в процесі активності відбувається подія скасування ( cancel), то do-активністьпросто переривається і ми повертаємось у стан Update Hardware Window (Оновлення вікна обладнання).

І do-активності, і звичайні активності є проявом деякої поведінки. Вирішальна різниця між ними полягає в тому, що звичайні активності відбуваються «миттєво» і не можуть бути перервані звичайними подіями, тоді як do-активності можуть виконуватися протягом деякого обмеженого часу і можуть перериватись, як показано на рис. 10.3. Миттєвість для різних систем трактується по-різному; для систем реального часу це може займати кілька машинних інструкцій, а для настільного програмного забезпечення може становити кілька секунд.

У UML 1звичайні активності позначалися терміном action(дія), а термін Діяльність(активність) застосовувався тільки для do-активностей.

Суперстану

Часто буває, що кілька станів мають загальні переходи та внутрішні активності. У таких випадках можна їх перетворити на підстани (substates), а загальну поведінку перенести на суперстан (superstate), як показано на рис. 10.4. Без суперстану довелося б малювати перехід cancel(скасування) для всіх трьох станів усередині стану Enter Connection Details (Введення подробиць з'єднання).

Паралельні стани

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

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

Мал. 10.5 включає також стан передісторії(History pseudostate). Це означає, що коли включений годинник, опція радіо/CD переходить у стан, в якому знаходився годинник, коли він був вимкнений. Стрілка, що виходить із передісторії, показує, який стан існував спочатку, коли відсутня передісторія.

Реалізація діаграм станів

Діаграму станів можна реалізувати трьома основними способами: за допомогою вкладеного оператора switch, патерну State та таблиці станів. Найпряміший підхід у роботі з діаграмами станів – це вкладений оператор switch, такий як на рис. 10.6.

Хоча цей спосіб і прямий, але дуже довгий, навіть для цього простого випадку. Крім того, при цьому підході дуже легко втратити контроль, тому не рекомендуємо застосовувати його навіть в елементарних ситуаціях.
Паттерн "Стан" (State pattern) представляє ієрархію класів станів для обробки поведінки станів. Кожен стан на діаграмі станів має власний підклас стану. Контролер має методи кожної події, які просто перенаправляють до класу стану. Діаграма станів показана на рис. 10.1 могла б бути реалізована за допомогою класів, представлених на рис. 10.7.

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

Так, діаграма на рис. 10.1 може бути подана у вигляді табл. 10.1.
Потім ми будуємо інтерпретатор, який використовує таблицю станів під час виконання програми або генератор коду, який породжує класи на основі цієї таблиці.

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

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

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

Якщо ви бажаєте навчитися працювати на фрілансі професійно, запрошуємо на курс «».

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

Переваги UML

• У UML використовуються графічні позначення для елементів системи, що моделюється, при цьому схеми UML досить прості для розуміння;
• UML дозволяє описувати системи практично з усіх можливих точок зору, враховуючи різні аспекти;
• UML об'єктно-орієнтований: його методи аналізу та побудови семанітично близькі до методів програмування, що використовуються у сучасних мовах ОВП;
• UML – відкритий стандарт. Стандарт розвивається та еволюціонує від версії до версії, відповідаючи найсучаснішим вимогам до опису систем;
• містить механізм розширення, що дозволяє вводити додаткові текстові та графічні типи, що уможливлює застосування UML не тільки у сфері IT.

Типи діаграм UML

У UML 14 типів діаграм. Їх можна розділити на 2 категорії:

• структурні, Що представляють інформаційну структуру;
• поведінкові, що представляють поведінку системи та різні аспекти взаємодій. Окремим підвидом діаграм поведінки вважаються діаграми взаємодії.

Ієрархія типів діаграм UML,
представлена ​​діаграмою класів

Структурні діаграми

1. Діаграма класівє ключовим елементом об'єктно-орієнтованому моделюванні. За допомогою цієї діаграми (власне, через класи, їх атрибути, методиі залежності між класами) описується модель предметної області та структура моделі, що моделюється.
2. Діаграма компонентіввідображає розбиття програмного коду на великі блоки (структурні компоненти) та показує залежностіміж ними. Компонентами може бути пакети, модулі, бібліотеки, файли тощо.
3. Об'єктна діаграмапоказує повний або частковий зріз моделі, що моделюється в заданий момент часу. Вона представляє екземплери класів (об'єкти), їх стан (поточні значення атрибутів) та відносини між ними.
4. Діаграма композитної структуридемонструє внутрішню структуру класів та, по можливості, взаємодії між елементами цієї структури.
5. Діаграма пакетівпоказує пакети та відносини між ними. Цей вид діаграм служить для спрощення структури моделі (і, відповідно, роботи з нею) через об'єднання елементів моделі групи за деякими критеріями.
6. Діаграма розгортаннямоделює розгортання програмних компонентів ( артефактів) на обчислювальних ресурсах/апаратних компонентах ( вузлах).
7. Діаграма профілівописує механізм розширення, що дозволяє пристосувати UML до різноманітних предметних областей та сфер діяльності.

Приклад UML-діаграм класів

Діаграми поведінки

1. Діаграма діяльностіпоказує дії ( actions) з яких складається деяка діяльність ( Діяльність). Діаграми діяльності використовуються для моделювання бізнес-процесів, технологічних процесів, послідовних та паралельних обчислень.
2. Діаграма варіантів використання(або діаграма прецедентів) описує відносини між акторами (діючими особами) і варіантами використання системи, що моделюється (її можливостями). Основне призначення діаграми – бути універсальним засобом для замовників, розробників та кінцевих користувачів, за допомогою якого можна було б спільно обговорювати систему – її можливості та поведінку.
3. Діаграма станівзображує динамічне поведінка сутності, показуючи як це сутність залежно від свого поточного стану реагує різні події. Насправді це діаграма станів з теорії атоматів.
4. Діаграма комунікації(у ранніх версіях діаграма кооперації) показує взаємодії між частинами композитної структури та ролями кооперації. На діаграмі очевидно вказуються відносини між елементами (об'єктами).
5. Діаграма послідовностівикористовується візуалізації послідовності взаємодій об'єктів. Показує життєвий цикл заданого об'єкта та взаємодію акторів (діючих осіб) у межах деякого варіанту використання, послідовність повідомлень якими вони обмінюються.
6. Діаграма огляду взаємодіївключає частину діаграми послідовності та конструкції потоку управління. Допомагає розглянути взаємодію об'єктів із різних точок зору.
7. Діаграма синхронізації- окремий підвид діаграм взаємодії, що спеціалізується на таймінгу. Діаграми цього виду використовуються для вивчення поведінки об'єктів протягом певного періоду часу.