Три самых ходовых нотации решают три разные задачи. BPMN описывает бизнес-процесс: кто что делает, в каком порядке, где развилки и кто за что отвечает. UML описывает систему изнутри: как компоненты взаимодействуют во времени (sequence), как устроена структура (class/component), что система умеет для пользователя (use case). C4 описывает архитектуру на четырёх уровнях масштаба — от «коробочки в окружении» до кода. Выбирайте нотацию по вопросу, на который отвечаете, а не по привычке.
Однажды я отдал разработчику текстовое описание процесса на полторы страницы: «сначала клиент оформляет заявку, потом если сумма больше лимита — идёт на ручную проверку, иначе сразу в обработку, а если проверка не прошла — возврат на доработку…». Он прочитал дважды и спросил: «А что происходит, если заявка зависла на проверке и клиент отменил её?» В тексте этого не было видно — а на схеме дырка вылезла бы сразу. С тех пор сложные развилки я рисую, а не описываю.
Схема — это не украшение ТЗ. Это инструмент, который заставляет вас додумать то, что в прозе легко проскочить. Но у схемы есть цена: её надо уметь читать. Поэтому есть железное правило — рядом со схемой всегда идёт текст, который её пересказывает. Картинку не прочитает поисковик, не прочитает коллега в спешке, и, честно говоря, не всегда прочитаете вы сами через полгода.
Зачем вообще схемы
Одна хорошая схема экономит страницу текста — но не потому, что «картинка нагляднее». А потому, что нотация навязывает структуру. Когда вы рисуете развилку в BPMN, вы обязаны указать оба исхода. Когда рисуете sequence, вы обязаны показать, кто кому отправляет сообщение и что приходит в ответ. Текст таких обязательств не накладывает — в нём легко написать «система обрабатывает заявку» и не заметить, что вы не сказали, что будет при ошибке.
Схема не отменяет текст
Диаграмма показывает структуру, но плохо передаёт детали и условия. «Стрелка из A в B» не говорит, какие данные передаются, что в заголовках, какие лимиты. Поэтому схема и спецификация ходят парой: схема — про «как связано», текст — про «что именно». Подробнее про это — в записи как написать ТЗ.
BPMN — про бизнес-процессы
BPMN (Business Process Model and Notation) отвечает на вопрос «кто что делает и в каком порядке». Это нотация про людей и шаги, а не про систему. Если вы описываете, как заявка проходит через отделы, где менеджер принимает решение, где подключается автоматика, а где процесс ждёт оплаты — это BPMN.
Ключевые элементы простыми словами: задача (прямоугольник — кто-то что-то делает), шлюз (ромб — развилка, где процесс ветвится по условию), событие (кружок — старт, конец, таймер, входящее сообщение) и дорожки (lanes — горизонтальные полосы, каждая полоса это роль или система, и сразу видно, кто за какой шаг отвечает). Именно дорожки делают BPMN незаменимым там, где в процессе участвуют несколько ролей.
Это настоящая BPMN-диаграмма, а не схема «в общем виде». Прочитаем её по символам — заодно увидим, чем нотация отличается от произвольных квадратиков. Кружок слева — стартовое событие «Заявка подана»: процесс с него начинается. Ромбы — эксклюзивные шлюзы (развилки «или-или»): первый, «Сумма больше лимита?», ведёт либо к прямоугольнику-задаче «Ручная проверка менеджером», либо сразу к «Автоматической обработке». После ручной проверки второй шлюз «Проверка пройдена?» отправляет заявку либо в ту же автообработку, либо в кружок-конечное событие «Отказ, доработка». Успешный путь завершается событием «Заявка обработана». Обратите внимание на дисциплину, которую навязывает нотация: у каждого шлюза подписаны оба исхода (да/нет), и у каждой ветки есть конец, — в произвольной блок-схеме их легко забыть, и именно там прячутся дыры в требованиях. Подробнее про элементы BPMN и как их читать — в записи BPMN на практике.
UML — про систему
UML (Unified Modeling Language) — это не одна диаграмма, а целый набор. Аналитику из них реально нужны три-четыре.
Sequence (диаграмма последовательности) — про взаимодействие во времени. Кто кому отправляет запрос, в каком порядке, что приходит в ответ. Это рабочая лошадка аналитика: на ней видно, как клиент дёргает сервис, сервис идёт в базу, возвращает ответ. Если вы проектируете API или интеграцию — рисуете sequence.
Component / class (компонентная и классовая) — про структуру. Component показывает, из каких частей состоит система и как они соединены. Class — про структуру данных и объектов в коде, аналитику нужна реже.
Use case (диаграмма вариантов использования) — про то, что система умеет с точки зрения пользователя. Человечки (актёры) и овалы (что они могут делать). Хороша на старте, чтобы очертить границы: что вообще входит в систему, а что нет.
Если выучить одну UML-диаграмму
Учите sequence. Она закрывает 80% задач системного аналитика: любое взаимодействие во времени — запрос-ответ, цепочка вызовов между сервисами, обработка ошибки — ложится на неё естественно. С неё же проще всего перейти к описанию контракта API.
C4 — про архитектуру, простыми словами
C4 — это способ рисовать архитектуру так, чтобы её понял и бизнес, и разработчик. Идея — четыре уровня масштаба, как зум на карте. Вы не пытаетесь уместить всё в одну схему, а делаете несколько, от общего к частному.
- Context (контекст) — самый верхний уровень. Ваша система — одна коробочка, вокруг — пользователи и внешние системы, с которыми она общается. Понятно даже директору.
- Container (контейнеры) — заглядываем внутрь коробочки: из чего система состоит. Веб-приложение, бэкенд, база данных, очередь. «Контейнер» здесь — это не Docker, а крупная разворачиваемая часть.
- Component (компоненты) — заглядываем внутрь одного контейнера: из каких модулей он состоит.
- Code (код) — самый нижний уровень, классы и интерфейсы. На практике почти не рисуют — устаревает быстрее, чем дорисуешь.
В жизни аналитик чаще всего рисует первые два уровня: Context, чтобы договориться о границах, и Container, чтобы показать архитектуру. Уровни Component и Code оставляют разработке или не рисуют вовсе.
Что хочу показать → какая нотация
| Хочу показать | Нотация |
|---|---|
| Бизнес-процесс с ролями и развилками (кто что делает) | BPMN |
| Взаимодействие во времени (запрос-ответ, вызовы между сервисами) | UML sequence |
| Из каких частей состоит система | UML component / C4 Container |
| Что система умеет для пользователя, границы системы | UML use case |
| Архитектуру для бизнеса и инженеров на разных уровнях | C4 (Context + Container) |
| Структуру данных, сущности и связи | ER-диаграмма |
Откуда это взялось
UML родился в середине 1990-х, когда «три амиго» — Гради Буч, Джеймс Рамбо и Айвар Якобсон — в компании Rational Software свели свои конкурирующие подходы в один язык; в 1997-м он стал стандартом консорциума OMG. BPMN появился около 2004 года (его сделала организация BPMI), позже тоже перешёл под крыло OMG — актуальная версия BPMN 2.0 вышла в 2011-м. C4 придумал Саймон Браун около 2011 года — прямо как ответ на то, что «UML слишком тяжёлый»: меньше формализма, четыре уровня масштаба и упор на то, чтобы схему понимали живые люди.
Частые вопросы
BPMN или UML — что выбрать?
Зависит от того, что вы описываете. BPMN — для бизнес-процесса: кто что делает, в каком порядке, где развилки и кто за что отвечает (есть дорожки под роли). UML — для системы изнутри: sequence для взаимодействия во времени, component для структуры, use case для границ. Грубо: процесс с людьми — BPMN, поведение системы — UML.
Что такое C4 model простыми словами?
Это способ рисовать архитектуру на четырёх уровнях масштаба, как зум на карте. Context — система целиком одной коробочкой среди пользователей и внешних систем. Container — из чего она состоит (приложение, бэкенд, база). Component — модули внутри одной части. Code — классы (рисуют редко). Аналитику обычно хватает первых двух уровней.
Чем рисовать схемы?
Удобнее всего «диаграммы как код»: PlantUML закрывает UML, sequence и C4, mermaid встроен в Markdown. Для BPMN есть отдельные редакторы (Storm BPMN, bpmn.io). Для быстрых набросков на созвоне — Excalidraw. Подробный разбор инструментов по задачам — в записи инструменты системного аналитика.