UML: основы

1.

UML: основы
Диаграммы • синтаксис нотации • графические объекты и отношения
Структура
Поведение
Взаимодействия
Подходит для: анализ требований, проектирование, документация, общение в команде
Class
+id: int
+name: string
+save()
1/12

2.

1. Что такое UML
UML (Unified Modeling Language) —
стандартная графическая нотация для
моделирования систем.
• Помогает визуализировать структуру и поведение.
• Упрощает обсуждение требований с заказчиком и
командой.
• Дает единый «язык» документации (архитектура,
дизайн, процессы).
Где чаще всего используют
• Требования: use case, activity.
• Проектирование: class, component,
deployment.
• Интеграции: sequence, communication.
• Сложная логика: state machine.
Идея в одном рисунке
Мысль
Модель
Код
Важно: UML — это язык, а не методология (Scrum/UP и
т.п.).
2/12

3.

2. Из чего состоит UML
Модель = элементы + отношения + представления (диаграммы)
Элементы модели
Отношения
Диаграммы
• Классификаторы: классы,
компоненты, узлы.
• Экземпляры: объекты, сообщения.
• Поведение: действия, состояния.
• Группировка: пакеты.
• Ограничения: заметки, «{constraint}».
• Ассоциация (с кратностями).
• Агрегация / композиция.
• Обобщение (наследование).
• Зависимость (dependency).
• Реализация интерфейса.
• Структурные — «что
есть».
• Поведенческие — «что
происходит».
• Взаимодействия — «кто с
кем говорит».
Нотация =
графика +
правила
Use case
3/12

4.

3. Виды диаграмм UML (обзор)
У UML 2.x обычно выделяют 14 типов диаграмм
Структурные
• Class (классов)
• Object (объектов)
• Package (пакетов)
• Component (компонентов)
• Composite Structure (составной структуры)
• Deployment (развертывания)
• Profile (профилей)
Поведенческие
• Use Case (вариантов использования)
• Activity (деятельности)
• State Machine (состояний)
Взаимодействия
• Sequence (последовательности)
• Communication (коммуникации)
• Timing (времени)
• Interaction Overview (обзор взаимодействий)
На практике чаще всего начинают с 3–5 диаграмм под задачу.
4/12

5.

4. Диаграмма вариантов использования (Use Case)
Показывает функциональность глазами пользователей
Когда полезна
Мини‑пример
• Собрать/проверить требования.
• Согласовать границы системы.
• Зафиксировать роли и цели.
Система
Войти
Основные элементы
• Актор (роль) — «палочник».
• Use case — овал с названием.
• Граница системы — прямоугольник.
• Связи: association, include, extend, generalization.
<<include>>
Создать заказ
Покупатель
Оплатить
5/12

6.

5. Диаграмма классов (Class)
Структура данных и отношений между сущностями
Что показывает
Связи (быстрый пример)
• Классы/интерфейсы: атрибуты и операции.
• Связи между сущностями и кратности.
• Агрегация/композиция (владение).
• Наследование и реализации.
Синтаксис класса
Имя
—
атрибуты
—
операции
Order
+id: UUID
+total: Money
+status: OrderStatus
10..*
Customer
Order
размещает
1
Order
1..*
OrderItem
+addItem(p: Product, qty: int)
+pay()
+cancel()
композиция: item живёт внутри order
6/12

7.

6. Диаграмма последовательности (Sequence)
Показывает обмен сообщениями во времени
Ключевые элементы
• Участники (lifelines) — прямоугольник + пунктир
вниз.
• Сообщения — стрелки между lifelines.
• Активность — прямоугольник (activation bar).
• Фрагменты: alt/opt/loop (условия).
Мини‑пример: оплата заказа
UI
OrderSvc
PayGW
DB
pay(orderId)
alt [approved]
authorize(amount)
approved
updateStatus(PAID)
ok
Подсказка: на одной диаграмме — один сценарий (happy
path + 1–2 альтернативы).
receipt
7/12

8.

7. Диаграмма деятельности (Activity)
Поток работ: действия, ветвления, параллельность
Основные графические объекты
Мини‑пример: оформление заказа
• Start/End — черный кружок и «мишень».
• Action — скруглённый прямоугольник.
• Decision/Merge — ромб с условиями.
• Fork/Join — толстая линия для параллельности.
• Swimlanes — разделение по ролям/системам.
Выбрать товары
Заполнить адрес
Оплата
успешна?
[нет]
Показать
ошибку
[да]
Показать чек
Подходит для бизнес‑процессов и алгоритмов (и как
документация, и как «вход» для обсуждений).
8/12

9.

8. Диаграмма состояний (State Machine)
Поведение объекта как набор состояний и переходов
Когда использовать
• Есть «жизненный цикл» сущности: заказ, счет, заявка.
• Много событий и правил переходов.
• Нужно явно описать допустимые состояния.
Синтаксис перехода
event [guard] / action
пример: pay [amount>0] / setStatus(PAID)
Мини‑пример: статус заказа
create
NEW
can
cel
CANCELLED
pay
PAIDref
un
d
shi
p
SHIPPED
complete
Также бывают entry/exit/do‑actions внутри состояния.
9/12

10.

9. Нотация отношений (шпаргалка)
Линии, стрелки и «ромбики» — это синтаксис. Смысл задаётся семантикой UML.
1
0..*
Ассоциация
Наследование (Generalization)
Связь между сущностями; указывается роль и
кратность (1, 0..*, 1..n).
«is‑a»: потомок наследует атрибуты/операции
предка.
Зависимость (Dependency)
Агрегация
«использует»: пунктирная стрелка. Часто для связей
модулей/слоёв.
«has‑a» (слабое владение): пустой ромб у «целого».
Композиция
Реализация (Realization)
Сильное владение: часть не живёт без целого
(заполненный ромб).
Класс реализует интерфейс: пунктир + пустой
треугольник.
10/12

11.

10. Практика: как делать диаграммы полезными
Рекомендации
Типичные ошибки
• Начните с вопроса: «что нужно понять/решить?»
• Ограничьте масштаб: одна диаграмма = одна мысль.
• Подбирайте уровень детализации под аудиторию.
• Давайте понятные имена (глаголы для действий,
существительные для сущностей).
• Фиксируйте версии/дату и владельца диаграммы.
• Диаграмма «всё обо всём» (не читается).
• Слишком много украшательств вместо смысла.
• Смешивание уровней: бизнес‑термины + детали
реализации в одном месте.
• Нет легенды/оговорок (что включено, что
исключено).
• Не обновляется → теряет доверие команды.
11/12

12.

11. Итоги и быстрый выбор диаграммы
Какую диаграмму выбрать?
Что делает система для пользователя?
Use Case
Какой поток работ/процесс?
Activity
Какие сущности и связи?
Как проходит сценарий во времени?
Class
Какие состояния и правила переходов?
State Machine
Sequence
Как устроено
развертывание/компоненты?
Component/Deployment
Если хотите — добавлю примеры «на вашем проекте» (заказ/доставка/CRM и т.п.) и задания для практики.
12/12