UML для системного аналитика: диаграммы прецедентов, последовательности и состояний в ТЗ

Распространённое заблуждение новичка — считать, что UML надо выучить целиком, а диаграмму вставлять в ТЗ ради солидности. На практике аналитик рисует схему, когда текст становится неоднозначным. Фраза «пользователь может отменить бронь» не говорит, можно ли отменить бронь, когда замок уже открылся. Диаграмма состояний задаёт этот вопрос сама: если стрелки «отмена» из состояния «замок открыт» нет, значит, команда либо запрещает переход, либо о нём забыла, и это надо выяснить до разработки.

Какие диаграммы реально нужны

Диаграмма прецедентов (use case) отвечает на вопрос «кто и что делает с системой»: актёры — люди или внешние системы — и овалы с целями вроде «Оплатить поездку». Это карта границ системы, а шаги пишут текстом в спецификации прецедента: основной сценарий, альтернативы, исключения.

Диаграмма деятельности (activity) показывает поток действий с развилками и параллельными ветками. Её берут для алгоритма внутри одной функции, например расчёта цены с промокодом и бонусами; процесс с участием нескольких отделов удобнее рисовать в BPMN.

Диаграмма последовательности (sequence) раскладывает один сценарий во времени: вертикальные линии жизни участников и стрелки сообщений между ними. Разработчик видит по ней, кто кого вызывает, что приходит в ответ и что происходит при ошибке.

Диаграмма состояний (state machine) фиксирует жизненный цикл объекта: состояния, события и разрешённые переходы. Диаграмма классов в работе аналитика чаще служит моделью предметной области: сущности, атрибуты, связи и кратности. ER-диаграмма таблиц к UML не относится, но решает близкую задачу, поэтому в ТЗ обычно оставляют одну из двух моделей.

Какую версию стандарта указывать

Текущая спецификация языка — OMG UML 2.5.1, принятая в декабре 2017 года: это один нормативный документ formal/17-12-05 и машиночитаемые файлы метамодели. Международный стандарт устроен иначе. На странице UML 2.4.1 консорциум OMG указывает, что международным стандартом стала предыдущая версия, 2.4.1 от июля 2011 года, причём двумя частями: ISO/IEC 19505-1 Infrastructure и ISO/IEC 19505-2 Superstructure. По карточке ISO/IEC 19505-2:2012 стандарт вышел в апреле 2012 года, а в 2025 году пересмотрен и подтверждён как действующий.

Отсюда практическое следствие для ТЗ: фраза «модели выполняются по ISO/IEC 19505» формально отсылает к UML 2.4.1, а не к актуальной версии. На эскизе разница почти незаметна, но, если модель будут проверять на соответствие или генерировать по ней код, в разделе о нотациях лучше прямо написать «UML 2.5.1 (OMG, formal/17-12-05)».

Учебный пример: аренда самоката

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

Сначала он добавляет на диаграмму прецедентов цель «Забронировать самокат». Уже здесь всплывает вопрос, который текстом легко пропустить: можно ли держать две брони одновременно.

Затем идёт диаграмма последовательности: приложение запрашивает бронь, сервер проверяет самокат, сохраняет бронь, отправляет команду на замок и возвращает таймер. Фрагментом alt показана ветка, где замок не ответил: бронь отменяется. Каждое сообщение становится методом API в спецификации, каждая ветка alt — тест-кейсом.

Последней строится диаграмма состояний самоката с переходами, подписанными событиями. На ней выясняется, что разряд во время брони никак не обработан, и в требования добавляется правило: бронь снимается, пользователь получает уведомление. Фрагмент в PlantUML:

@startuml
[*] --> Свободен
Свободен --> Забронирован : бронь создана
Забронирован --> Свободен : истекло 10 минут
Забронирован --> Разряжен : заряд ниже порога
state "В поездке" as Ride
Забронирован --> Ride : замок открыт
@enduml

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

UML, BPMN или C4

Нотацию выбирают под вопрос, на который отвечает схема. BPMN описывает бизнес-процесс: кто из людей и отделов что делает, где ждёт, куда передаёт работу. UML описывает саму программную систему: её пользователей, данные, поведение объектов и обмен сообщениями. C4 показывает архитектуру уровнями приближения — контекст, контейнеры, компоненты — и не задаёт строгой нотации поведения.

В одном ТЗ они уживаются: передачу самоката в ремонт рисуют в BPMN, окружение приложения — в C4, логику брони — в UML. Ошибка начинается, когда нотацией отвечают на чужой вопрос, например рисуют BPMN-процесс, где дорожками служат микросервисы.

Ошибки в нотации, которые видно сразу

Ошибки новичка обычно не в кривых линиях, а в неверном смысле элементов. Вот что чаще всего замечают на ревью:

• прецеденты нарезаны по кнопкам: «Нажать „Оплатить“», «Ввести промокод», — хотя прецедент должен давать актёру законченный результат;
• перепутаны include и extend: включаемый прецедент выполняется всегда, расширяющий — только при условии, и стрелка extend идёт от расширяющего прецедента к базовому;
• на диаграмме последовательности не различают синхронный вызов (закрашенная стрелка), асинхронное сообщение (открытая) и ответ (пунктир), и непонятно, ждёт ли отправитель результата;
• в состояния записаны действия: «Проверяем оплату» — это активность, а состояние звучит как «Ожидает оплаты»;
• из тупикового состояния нет выхода, и объект застревает в нём навсегда.

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

В чём рисовать

PlantUML превращает текст в диаграмму, поэтому схемы удобно хранить в Git и видеть изменения построчно. По документации PlantUML, диаграммам прецедентов, классов, компонентов, состояний и старого синтаксиса деятельности нужен Graphviz, а диаграммам последовательности — нет. Если ставить программы на рабочий ноутбук нельзя, попробуйте экспериментальный встроенный движок: строка !pragma layout smetana.

Похожий текстовый синтаксис у Mermaid, встроенного во многие вики. Графический draw.io удобнее, когда схему рисуют вместе на встрече; ему на сайте посвящена отдельная статья.

С чего начать и в каком порядке осваивать

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

1. Возьмите приложение, которым пользуетесь каждый день, и нарисуйте для него диаграмму прецедентов на пять-семь целей.
2. Для одного прецедента напишите текстовый сценарий с альтернативами и исключениями.
3. Разложите этот сценарий в диаграмму последовательности с веткой ошибки внешней системы.
4. Выберите главный объект — заказ, заявку, самокат — и нарисуйте его состояния с событиями на переходах.
5. Соберите модель предметной области: сущности, атрибуты, кратности связей.
6. Пронумеруйте требования и проставьте ссылки между ними и схемами, затем отдайте пакет на проверку коллеге.

Если у коллеги не осталось вопросов «а что будет, если…», навык уже работает; если их много, нужна регулярная обратная связь.

Чему учат на курсах

В программах онлайн-курсов UML обычно не выделен в отдельную тему: его изучают внутри работы с требованиями. Это удобно, потому что схема без задачи учит только расставлять фигуры.

На трёхмесячном курсе «Системный аналитик с нуля» Karpov Courses UML, Use Case, User Story и ER-диаграммы перечислены среди инструментов рядом с BPMN, SQL, Swagger и Postman, а в практике упомянуты диаграммы в BPMN и UML. Какие виды UML-диаграмм разбирают, на странице не сказано — уточните у школы.

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

Девятимесячный курс «Системный аналитик расширенный» Яндекс Практикума включает моделирование вариантов использования и трассировку требований, а в основных спринтах — ER-диаграммы, BPMN, диаграммы деятельности и состояний. В расширенном модуле добавлены нотация C4, событийная архитектура и AsyncAPI; всего в программе пять проектов.

Как навык влияет на доход

Отдельной надбавки «за UML» в вакансиях нет: нотация входит в базовые требования к аналитику вместе с SQL, BPMN и описанием API. Платят за ТЗ, по которому команда делает функцию без бесконечных уточнений, поэтому навык влияет на доход через задачи: кто уверенно описывает интеграции и жизненный цикл объектов, получает более сложные проекты и быстрее растёт по уровню.

Ориентир по верхней ступени даёт калькулятор зарплат Хабр Карьеры: для системного аналитика уровня Senior он показывает 300 000 ₽ в месяц по 557 анкетам (Россия без фильтра по городу, данные на октябрь 2026 года). Это зарплаты из анкет, а не предложения работодателей, и цифра описывает профессию целиком, а не вклад одной нотации. Для своего города и уровня включайте фильтры и смотрите медиану.

Как выбрать обучение

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

Если вам ближе бизнес-сторона — процессы, заинтересованные стороны, интервью, — посмотрите на курс «Бизнес-аналитик: тариф Мастер» Eduson Academy. В программе есть блоки о работе с требованиями и об описании процессов, где названы BPMN, UML и модели текущего и будущего состояния; на тарифе предусмотрены девять консультаций с экспертом. Срок обучения на странице указан по-разному, поэтому уточните его у школы до оплаты.

При сравнении программ смотрите, какие диаграммы вы нарисуете сами, кто их проверит и попадут ли они в портфолио вместе с текстом требований.

Сравнить онлайн-школы по цене, длительности и формату поможет рейтинг онлайн-школ по системной аналитике. Начать можно и без оплаты: за выходные нарисуйте три схемы для знакомого приложения в PlantUML и попросите коллегу составить по ним тест-кейсы. Его вопросы покажут, хватит ли самостоятельной практики.