UML для аналитика

UML (Unified Modeling Language) — это универсальный язык для описания систем и процессов в виде схем, без длинного текста.

📌 Это как чертёж: помогает всем участникам проекта понимать одно и то же одинаково.

Бизнес-аналитик использует UML, чтобы зафиксировать требования, описать бизнес-процессы и передать их команде разработки.

👉 UML нужен, чтобы объяснять сложное просто и без двусмысленности.

Какую диаграмму когда строить?

Вопрос	Диаграмма	Когда
Что умеет система? Для кого?	Use Case	Начало проекта, сбор и согласование требований
Как идёт бизнес-процесс?	Activity	Описание бизнес-процессов и пользовательских сценариев
Какие статусы у объекта?	State Machine	Описание жизненного цикла, статусов и переходов
Кто кому что отправляет?	Sequence	Описание взаимодействия участников (кто с кем и в какой последовательности), включая интеграции и API
Из каких сущностей состоит система?	Class Diagram	Доменная модель, структура данных и связи между сущностями

Use Case Diagram

Диаграмма вариантов использования · «Кто что делает в системе?»

Показывает, какие действия могут выполнять пользователи и внешние системы в вашем продукте. Это карта функциональности от лица пользователя.

📋 Строится в самом начале проекта — чтобы согласовать границы системы с заказчиком и командой.

Основные элементы

Элемент	Описание
Актор (Actor)	Человечек — пользователь или внешняя система, взаимодействующая снаружи
Вариант использования	Эллипс — одна конкретная цель или функция системы
Граница системы	Прямоугольник: всё внутри делает система, снаружи — акторы
«include»	Пунктирная стрелка: один Use Case обязательно вызывает другой
«extend»	Пунктирная стрелка: расширение — опциональное дополнительное поведение

Совет: Каждый эллипс — это ЦЕЛЬ пользователя, а не шаг. Не «Нажать кнопку Купить», а «Оформить заказ».

Пример — интернет-магазин

Частые ошибки

Слишком мелкая детализация: «Нажать кнопку», «Ввести логин» — это шаги, а не цели
Забыть про внешние системы как акторов (платёжный шлюз, SMS-сервис)
Описывать внутренние процессы внутри Use Case — это задача Activity Diagram

Activity Diagram

Диаграмма активностей · «Шаг за шагом»

Описывает последовательность действий для достижения цели — как блок-схема бизнес-процесса. Показывает ветвления, параллельные действия и точки принятия решений.

📋 Строится, когда нужно описать бизнес-процесс, сценарий работы или алгоритм с ветвлениями.

Основные элементы

● Старт

Заполненный чёрный круг — точка входа в процесс

◉ Конец

Круг с точкой внутри — завершение процесса

Скруглённый прямоугольник

Действие — конкретная операция или задача

◆ Ромб

Точка принятия решения, стрелки подписаны «да» / «нет»

Дорожки (Swimlanes)

Вертикальные полосы — на чьей стороне выполнение действия

Чёрная полоса (Fork/Join)

Начало и конец параллельных действий

Совет: Дорожки — ключевой инструмент для разграничения ответственности. Сразу видно, кто что делает и где происходит передача задачи.

Пример — обработка заявки на кредит (с параллельными проверками)

State Machine Diagram

Диаграмма состояний · «Жизненный цикл объекта»

Показывает все возможные состояния объекта (заказа, договора, задачи) и условия перехода между ними. Незаменима при описании workflow и бизнес-правил.

📋 Строится, когда объект может находиться в разных статусах и важно описать правила смены этих статусов.

Основные элементы

Элемент	Описание
Начальное состояние	Заполненный чёрный круг — откуда объект начинает существование
Состояние (State)	Прямоугольник с именем — текущий статус объекта
Конечное состояние	Круг с точкой внутри — объект больше не изменяется
Переход (Transition)	Стрелка между состояниями с подписью события

Совет: Ищите в интервью с заказчиком фразы «статус меняется когда…», «если заявка одобрена, то…» — это сигнал, что нужна диаграмма состояний.

Пример — жизненный цикл заказа

Sequence Diagram

Диаграмма последовательности · «Кто кому что говорит?»

Показывает порядок обмена сообщениями между участниками системы во времени. Подходит не только для технических интеграций и API, но и для описания бизнес-процессов — чтобы наглядно показать, кто с кем и в какой последовательности взаимодействует.

📋 Строится, когда важно показать точную последовательность взаимодействий — между людьми, отделами или компонентами системы.

Основные элементы

Участник (Lifeline)

Прямоугольник + пунктирная вертикаль — «линия жизни» участника

Активация

Прямоугольник на линии жизни — участник занят в этот момент

Стрелка → (сплошная)

Запрос / вызов. Время идёт строго сверху вниз

Пунктир ----→

Ответ на запрос — возвращается обратно

Совет: Читайте диаграмму строго сверху вниз. Стрелки вправо — запросы, стрелки влево и пунктир — ответы.

Пример 1 (бизнесовый)

Пример — согласование договора между отделами

Пример 2 (технический)

Пример — авторизация пользователя

Class Diagram

Диаграмма классов · «Структура данных системы»

Показывает сущности системы, их атрибуты и связи между ними. Для бизнес-аналитика — инструмент для описания доменной модели и согласования терминологии.

📋 Строится при описании структуры данных, согласовании терминологии или подготовке технического задания.

Структура класса и типы связей

Элемент / Тип связи	Значение и пример
Класс (сущность)	Прямоугольник из трёх частей: имя, атрибуты, методы. Для БА методы часто не нужны
Атрибуты	Свойства сущности — имя, дата, сумма, статус
Множественность (1, *, 0..1)	1 = один, * = много, 0..1 = ноль или один, 1..* = один или больше
Ассоциация ——→	«Связан с». Например, Клиент размещает Заказ
Композиция ◆——	Закрашенный ромб: часть не существует без целого. Сотрудник принадлежит Отделу — без отдела его нет в системе
Агрегация ◇——	Пустой ромб: объекты связаны, но существуют независимо. Сотрудник участвует в Проекте, но проект живёт и без конкретного человека
Наследование ——▷	«Является». Например, Физлицо и Юрлицо — оба Клиенты

Пример — сотрудники, отделы и проекты