UML для начинающих: базовые диаграммы, которые реально используют

UML — это не про «уметь рисовать все 14 диаграмм наизусть». И не про то, чтобы вставлять в спецификацию красивую картинку, которую никто не откроет. UML — это про способ думать о системе до того, как написан первый метод. Про то, чтобы вы и разработчик одинаково понимали, кто кому что отправляет и в какой момент.

На практике из всего зоопарка UML нужны 4 типа диаграмм. Остальные — либо для архитекторов уровня enterprise, либо для сертификации, которую никто не спрашивает. Вот эти четыре.

Диаграмма последовательности (Sequence) — главный инструмент

Если вы освоите только одну диаграмму — пусть это будет Sequence. Она показывает, как компоненты системы общаются друг с другом во времени. Кто вызывает, кто отвечает, в каком порядке.

Вот классический сценарий оформления заказа в интернет-магазине:

sequenceDiagram
  participant C as Клиент
  participant UI as Веб-интерфейс
  participant S as Сервер заказов
  participant DB as База данных
  participant P as Платёжный шлюз

  C->>UI: Добавляет товар в корзину
  UI->>S: POST /cart/items
  S->>DB: INSERT cart_items
  DB-->>S: OK
  S-->>UI: 201 Created

  C->>UI: Оформляет заказ
  UI->>S: POST /orders
  S->>DB: BEGIN TRANSACTION
  S->>DB: INSERT orders
  DB-->>S: order_id=42
  S->>P: Запрос оплаты
  P-->>S: Оплата подтверждена
  S->>DB: UPDATE orders SET status=paid
  S->>DB: COMMIT
  DB-->>S: OK
  S-->>UI: 201 Created, id=42
  UI-->>C: Заказ оформлен

На диаграмме пять участников: Клиент, Веб-интерфейс, Сервер заказов, База данных и Платёжный шлюз. Сплошные стрелки — синхронные вызовы, пунктирные — ответы. Всё читается сверху вниз: сначала товар добавляется в корзину через POST /cart/items, сервер пишет строку в cart_items таблицу, возвращает 201 Created. Затем клиент оформляет заказ — сервер в транзакции создаёт запись в orders, дёргает платёжный шлюз, получает подтверждение, обновляет статус на paid, коммитит и отвечает клиенту.

Заметьте: тут нет кода — только взаимодействия. Но разработчик, глядя на эту диаграмму, уже понимает, какие эндпоинты нужны, где транзакция, что делать при отказе платежа. Я на проектах рисую Sequence до начала разработки — и экономлю часы на обсуждениях «а кто должен создать заказ — фронт или бэк».

Главное правило Sequence: одна диаграмма = один сценарий. Не пытайтесь запихнуть и оформление, и возврат, и отмену в одну схему — получится каша.

Когда Sequence не справляется

Sequence хорош для линейных взаимодействий. Но если у вас сценарий с ветвлениями («если товара нет на складе — уведомить менеджера, иначе — зарезервировать»), лучше взять Activity-диаграмму. Или если важно показать, как объект меняет состояния — State-диаграмму.

Диаграмма классов (Class) — модель данных

Class-диаграмма — это схема сущностей и их связей. Не путайте с ERD: в ERD вы показываете таблицы базы данных, а в Class-диаграмме — объекты предметной области, их атрибуты и методы.

Возьмём тот же интернет-магазин:

classDiagram
  class Заказчик {
      +String имя
      +String email
      +оформитьЗаказ()
      +отменитьЗаказ()
  }
  class Заказ {
      +int id
      +String статус
      +Date датаСоздания
      +float итогоСумма
      +рассчитатьИтого()
      +подтвердить()
  }
  class СтрокаЗаказа {
      +String товар
      +int количество
      +float цена
  }
  class Товар {
      +int id
      +String название
      +float цена
      +int остаток
  }
  class Платёж {
      +int id
      +String способ
      +String статус
      +float сумма
      +провести()
  }

  Заказчик "1" --> "*" Заказ : создаёт
  Заказ "1" *-- "*" СтрокаЗаказа : содержит
  СтрокаЗаказа "*" --> "1" Товар : ссылается
  Заказ "1" --> "1" Платёж : оплачивается

Здесь пять классов. У каждого — атрибуты (поля) в верхней секции и методы в нижней. Связи подписаны: Заказчик создаёт Заказ (один-ко-многим), Заказ содержит СтрокиЗаказа (композиция — ромбик на конце), СтрокаЗаказа ссылается на Товар, Заказ оплачивается одним Платежом.

На собеседовании такую диаграмму часто просят нарисовать для задачи «спроектируйте API для интернет-магазина». И вот тут новички обычно сыплются: рисуют таблицы вместо классов или путают агрегацию с композицией. Разница простая: композиция (закрашенный ромб) — это когда часть не существует без целого. СтрокаЗаказа не живёт без Заказа. Агрегация (пустой ромб) — часть может существовать отдельно.

На практике Class-диаграмму я использую на этапе проектирования, до написания SQL-схемы. Она помогает договориться о модели с разработчиком и заказчиком быстрее, чем 10 страниц текста. Плюс из неё потом легко собрать User Story и Use Case — сущности с диаграммы становятся акторами и объектами в сценариях.

Activity и State: когда Sequence недостаточно

Activity-диаграмма (диаграмма деятельности) показывает поток управления: что происходит, если условие выполнилось, что — если нет. Это по сути блок-схема, но в стандарте UML. Ромбы — ветвления, прямоугольники — действия, толстые линии — распараллеливание.

Применяйте, когда описываете бизнес-процесс с вариативностью: «пользователь вводит промокод → если валиден — скидка применяется, если нет — показываем ошибку, если срок истёк — предлагаем другой». Sequence для такого сценария превратится в бесконечный alt-else, а Activity прочитает даже продакт.

State-диаграмма (диаграмма состояний) — про жизненный цикл объекта. Заказ может быть в состояниях: Новый → Оплачен → Собран → Отправлен → Доставлен. Или Новый → Отменён. Или Оплачен → Возврат. State-диаграмма показывает все легальные переходы и события, которые их вызывают.

Я видел проекты, где на состояния заказа было завязано полдюжины микросервисов, а документации по переходам не было — в итоге заказ мог уйти в доставку, не будучи оплаченным. Три состояния и пять стрелок на диаграмме предотвратили бы этот баг на этапе проектирования.

Какую диаграмму выбрать

Не надо рисовать все четыре для каждой задачи. Вот простой навигатор:

graph TD
  Q["Задача: что нужно показать?"] --> P["Процесс или сценарий"]
  Q --> D["Структуру данных"]
  Q --> S["Жизненный цикл объекта"]

  P --> SEQ["Sequence-диаграмма: кто, кому, в каком порядке"]
  P --> ACT["Activity-диаграмма: ветвления, параллельные потоки"]

  D --> CLS["Class-диаграмма: сущности, связи, атрибуты"]

  S --> ST["State-диаграмма: состояния и переходы"]

  style Q fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style P fill:#f0a500,stroke:#c88400,color:#fff
  style D fill:#f0a500,stroke:#c88400,color:#fff
  style S fill:#f0a500,stroke:#c88400,color:#fff
  style SEQ fill:#50c878,stroke:#3a9a5c,color:#fff
  style ACT fill:#50c878,stroke:#3a9a5c,color:#fff
  style CLS fill:#50c878,stroke:#3a9a5c,color:#fff
  style ST fill:#50c878,stroke:#3a9a5c,color:#fff

Синий блок — вопрос. Жёлтые — три типа задач. Зелёные — четыре диаграммы, каждая закрывает свой класс задач. Заметьте: для «процесс или сценарий» два варианта. Sequence — если взаимодействие линейное (клиент → сервер → БД). Activity — если есть ветвления, циклы, параллельные дорожки.

UML и живая спецификация

Главное правило: диаграмма должна жить рядом с кодом. В том же репозитории. Не в Confluence, где через месяц она устареет и превратится в артефакт, на который ссылаются со словами «ну на той схеме было по-другому». Mermaid-код в .md-файле, который лежит в docs/ рядом с сервисом, — вот что работает.

И не пытайтесь покрыть диаграммами весь проект. Три-четыре схемы для самых сложных сценариев — достаточно. Остальное описывается текстом в техническом задании. UML — это инструмент коммуникации, а не самоцель.

Чек-лист для начинающего аналитика

• Умеете нарисовать Sequence-диаграмму для сценария из 4–5 участников — база есть
• Понимаете разницу между композицией и агрегацией на Class-диаграмме
• Знаете, когда Sequence не подходит и нужно брать Activity
• Пробовали описать состояния заказа/заявки/пользователя через State-диаграмму
• Храните диаграммы в тексте (Mermaid), а не в PNG, который нельзя отревьюить в Pull Request

Если из этого списка у вас закрыто хотя бы три пункта — вы уже рисуете лучше, чем половина аналитиков, с которыми я работал. Если все пять — берите задачу посложнее и не бойтесь открывать PR с .md-файлом, в котором диаграмма объясняет архитектуру быстрее, чем thousand words.