UML: use case, sequence, диаграмма классов

Какие диаграммы UML вы рисуете и зачем — вопрос, где выигрывает не тот, кто перечислит все четырнадцать, а тот, кто объяснит выбор.

UML — набор нотаций для описания системы с разных сторон. Аналитику в реальной работе нужны в основном три: use case (границы и роли), sequence (взаимодействие во времени), class (структура понятий предметной области).

Вопрос 1. Какие диаграммы UML вы используете и в каких ситуациях?

Что проверяют. Осмысленность выбора. Заученный список из четырнадцати типов диаграмм — плохой знак: это признак теоретика. Хороший ответ строится по схеме «задача → диаграмма».

Задача	Диаграмма	Что показывает
Договориться о границах системы и ролях	Use case	кто (актор) какие цели закрывает через систему
Описать обмен сообщениями между сервисами	Sequence	кто кого вызывает, в каком порядке, что возвращает
Зафиксировать понятия и их связи	Class (концептуальная модель)	сущности, атрибуты, кардинальности
Описать жизненный цикл объекта	State machine	статусы заказа и допустимые переходы
Описать алгоритм или процесс с ветвлениями	Activity	шаги, условия, параллельные ветки

Остальные типы (компонентов, развёртывания, объектов, коммуникации) аналитик рисует редко — обычно это зона архитектора.

Use case: границы, а не интерфейс

Диаграмма вариантов использования отвечает на два вопроса: кто пользуется системой и какие цели закрывает. Не «какие кнопки нажимает» — именно цели. Хорошее имя use case — глагол плюс объект, отражающий завершённую пользу: «Оформить заказ», а не «Нажать кнопку "Далее"».

           Система «Интернет-магазин»
   ┌──────────────────────────────────────────┐
   │   (Оформить заказ)                        │
Покупатель ──┤   (Отменить заказ)                        │
   │   (Отследить доставку)                    │
   │                                           │
   │   (Собрать заказ)         ── Кладовщик    │
   │   (Провести платёж)  ─────────────────────┼── Платёжный шлюз
   └──────────────────────────────────────────┘

Актор — не обязательно человек: внешняя система тоже актор.

Частая ошибка — include и extend на каждом шагу. include означает «этот кусок обязательно выполняется в составе другого» (проверка авторизации), extend — «может выполниться при условии» (применить промокод). Если их больше трёх на диаграмме, вы, скорее всего, рисуете алгоритм, а не границы.

Вопрос 2. Когда вы рисуете sequence-диаграмму и что на ней обязательно?

Что проверяют. Умеете ли вы описывать интеграции. Sequence — самая полезная диаграмма аналитика в мире микросервисов: она наглядно показывает, кто кого зовёт, что происходит при ошибке и где нужен таймаут.

Обязательные элементы: участники (lifelines), сообщения со стрелками, различие синхронного вызова и ответа, альтернативные ветки (alt), циклы (loop), и — самое ценное — сценарий отказа.

Клиент      API-заказов    Платёжный      Очередь      Склад
   │             │           шлюз            │           │
   │ POST /orders│              │            │           │
   ├────────────>│              │            │           │
   │             │ authorize()  │            │           │
   │             ├─────────────>│            │           │
   │             │   approved   │            │           │
   │             │<─────────────┤            │           │
   │             │ publish(OrderCreated)     │           │
   │             ├──────────────────────────>│           │
   │  201 Created│              │            │ consume   │
   │<────────────┤              │            ├──────────>│
   │             │              │            │           │

alt: платёж отклонён
   │             │   declined   │            │           │
   │             │<─────────────┤            │           │
   │ 402 Payment Required       │            │           │
   │<────────────┤              │            │           │
   заказ сохраняется в статусе «Ожидает оплаты»,
   событие в очередь НЕ публикуется

Именно ветка alt с отказом отличает диаграмму аналитика от картинки для презентации. На собеседовании обязательно скажите, что рисуете не только успешный путь.

Вопрос 3. Зачем аналитику диаграмма классов, если он не пишет код?

Что проверяют. Понимаете ли вы разницу между концептуальной моделью предметной области и реализационной моделью классов.

Аналитик рисует концептуальный уровень: сущности предметной области, их атрибуты и связи с кардинальностями. Здесь нет методов, приватных полей и паттернов — есть язык бизнеса. Это фундамент для будущей ER-модели и для единого словаря терминов.

┌────────────────┐            ┌──────────────────┐
│ Клиент         │ 1        * │ Заказ            │
│ ─────────────  ├────────────┤ ──────────────── │
│ id             │  размещает │ номер            │
│ ФИО            │            │ дата создания    │
│ email          │            │ статус           │
└────────────────┘            └────────┬─────────┘
                                       │ 1
                                       │ содержит
                                       │ 1..*
                              ┌────────┴─────────┐
                              │ Позиция заказа   │
                              │ ──────────────── │
                              │ количество       │
                              │ цена на момент   │
                              └────────┬─────────┘
                                       │ *
                                       │ ссылается на
                                       │ 1
                              ┌────────┴─────────┐
                              │ Товар            │
                              └──────────────────┘

Обратите внимание на атрибут «цена на момент» у позиции заказа: цена товара меняется, а в оформленном заказе она обязана остаться прежней. Такие детали и есть настоящая ценность модели — они всплывают именно при рисовании, а не при чтении текста требований.

Про кардинальности говорите точно: 1..* («хотя бы одна позиция») — это уже бизнес-правило «пустой заказ создать нельзя», и его нужно проверить с заказчиком.

Типичные ошибки кандидатов

Перечисляют все типы диаграмм UML, но не могут объяснить, какую задачу решает каждая.
Рисуют на use case-диаграмме шаги интерфейса — получается блок-схема с овалами.
На sequence показывают только успешный сценарий, забывая ошибки, таймауты и повторы.
Смешивают концептуальную модель и модель классов кода: добавляют геттеры, DTO и слои.
Рисуют диаграмму «для документа» и не показывают её команде. Ценность диаграммы — в обсуждении, а не в наличии.

Как ответить кратко

Диаграмму выбираю под задачу, а не по списку. Use case — когда нужно договориться о границах системы и ролях: акторы и их цели, без шагов интерфейса. Sequence — для интеграций: кто кого вызывает, синхронно или асинхронно, и обязательно ветка с отказом, таймаутом и повтором. Диаграмма классов на концептуальном уровне — сущности, атрибуты и кардинальности, это язык бизнеса и основа будущей ER-модели. Дополнительно state machine для жизненного цикла заказа и activity для процессов с ветвлением. Главный критерий: диаграмма нужна, если она снимает спор в команде, иначе это лишняя работа.