Нотации моделирования для новичка: UML vs BPMN vs ERD — что и когда

Первое, что слышит новичок на собеседовании: «А вы UML знаете? BPMN рисуете? ERD-диаграмму базы сделаете?» И глаза округляются. Потому что на курсах про каждую нотацию рассказывали отдельно. А как это всё собрать в голове и понять, когда какую брать — не рассказывали.

Я через это прошёл. Сидел перед пустым листом в draw.io и не понимал, с чего начать. Процесс рисовать? Данные? Классы? Сейчас это выглядит забавно, но тогда реально тормозило работу. Разложу всё на атомы — без академизма, только то, что реально нужно.

Зачем вообще нужны нотации

Нотация — это не «чтобы красиво». Это договорённость о том, как рисовать. Если вы нарисуете квадратик, а разработчик прочитает его как стрелочку — у вас баг на проде ещё до первой строчки кода.

Стандартные нотации решают ровно эту проблему. BPMN-шлюз выглядит как ромб у всех — и бизнес-аналитик из Москвы, и архитектор из Новосибирска поймут его одинаково. UML-стрелка с треугольником — всегда наследование, а не «ой, я просто красиво хотел». ERD-нотация «воронья лапка» означает «многие» — и это знает любой DBA.

Без общей грамматики диаграмма превращается в картинку «я художник, я так вижу». А с общей грамматикой — в инженерный документ, который можно обсуждать, ревьюить и передавать между командами.

Ключевых нотаций, с которыми вы столкнётесь в первые полгода работы, всего три: UML, BPMN и ERD. Их путают чаще всего. При этом задачи у них разные — и брать не ту нотацию под задачу примерно как забивать гвозди отвёрткой. Технически можно. Практически — больно.

UML: универсальный швейцарский нож

UML — это не одна диаграмма. Это семейство. Честно говоря, полторы дюжины типов, из которых на практике нужны штук пять.

Вот что из UML реально используется каждый день:

• Sequence Diagram — кто кому что отправляет и в каком порядке. Главная рабочая лошадка. Если вы пишете API-контракты или описываете интеграцию, Sequence — ваш инструмент. Сервер вызывает сервис, сервис дёргает БД, БД отвечает, гейтвей возвращает 201 — всё по шагам и с таймингом.
• Class Diagram — из чего состоит система на уровне объектов. Классы, атрибуты, методы, связи: наследование, композиция, агрегация. Нужна, когда проектируете доменную модель.
• Activity Diagram — поток действий. Похоже на блок-схему, но в стандарте UML. Если нет ролей и дорожек, а надо показать просто «шаг 1 → шаг 2 → если условие то шаг 3, иначе шаг 4» — берите Activity.
• State Machine Diagram — как объект меняет состояния. Заказ: pending → paid → shipped → delivered. Полезно, когда у сущности есть жизненный цикл, и надо не пропустить невозможные переходы (из delivered обратно в pending — это уже баг).
• Component Diagram — разбивка системы на модули и их интерфейсы. Высокоуровнево. «Микросервис Заказов общается с Платёжным шлюзом через REST, с Нотификатором через Kafka».

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

Здесь скажу главное: UML — про архитектуру и поведение системы. Он технический, его читают разработчики. Если ваша задача — описать, как работают микросервисы, кто кому шлёт HTTP-запросы и в каком формате приходит JSON — вы в UML.

BPMN: когда важен процесс и роли

BPMN стоит особняком. Это не про код и не про базу данных — это про людей, системы и то, как между ними течёт работа.

Главная фишка BPMN — дорожки (pools и lanes). Каждая дорожка — роль или система. И вы видите, как задача переходит от менеджера к бухгалтеру, от бухгалтера — к автоматической проверке, от проверки — обратно к менеджеру с комментарием. UML так не умеет. UML покажет, что сервер А дёрнул сервер Б — но кто нажал кнопку и почему, UML не скажет.

Ключевые элементы BPMN, без которых никуда:

• События (events) — старт процесса, завершение, таймеры, сообщения. Кружочки разной толщины.
• Действия (tasks) — «заполнить заявку», «проверить скоринг», «отправить уведомление». Прямоугольники со скруглёнными углами.
• Шлюзы (gateways) — развилки. Ромбы. Эксклюзивный шлюз: либо один путь, либо другой. Параллельный: оба пути одновременно. По моему опыту, 90% ошибок в BPMN — неправильный тип шлюза.
• Потоки (sequence flows) — стрелки между элементами. Показывают, куда движется процесс.

Когда брать BPMN? Когда заказчик говорит: «У нас тут сложный процесс согласования заявок, три отдела участвуют, и ещё автоматическая проверка по базе». Вот тут вам BPMN. Нарисуете дорожки, разложите шаги по ролям, заказчик ткнёт пальцем и скажет: «О, теперь понял, где мы теряем время». Это и есть цель.

BPMN читают не только разработчики. Его читают бизнес-заказчики, менеджеры, владельцы продукта. Поэтому он менее технический, чем UML, и более «про людей». Условно: UML — для команды разработки, BPMN — для всех.

ERD: когда главное — данные

ERD — это про сущности и связи. Если UML объясняет поведение системы, а BPMN — процессы, то ERD отвечает на вопрос «какие данные мы храним и как они связаны».

Базовая ERD — это:

• Сущности (entity) — таблицы или объекты: Customer, Order, Product. Прямоугольники.
• Атрибуты (attributes) — поля сущности: customer_id, full_name, email.
• Связи (relationships) — линии между сущностями. Один-к-одному, один-ко-многим, многие-ко-многим. «Один клиент делает много заказов» — это связь один-ко-многим.

Классический пример — интернет-магазин:

erDiagram
  CUSTOMER ||--o{ ORDER : "размещает"
  ORDER ||--|{ ORDER_ITEM : "содержит"
  ORDER_ITEM } |--|| PRODUCT : "ссылается на"
  CUSTOMER {
      int customer_id PK
      string full_name
      string email
      string phone
      datetime registration_date
  }
  ORDER {
      int order_id PK
      int customer_id FK
      string status
      decimal total_amount
      datetime created_at
  }
  ORDER_ITEM {
      int item_id PK
      int order_id FK
      int product_id FK
      int quantity
      decimal price
  }
  PRODUCT {
      int product_id PK
      string name
      decimal base_price
      int stock_quantity
      string category
  }

На диаграмме видно: один Customer размещает много Order (связь один-ко-многим, обозначена палочкой и «вороньей лапкой»). Order содержит несколько OrderItem, каждый из которых ссылается на один Product. Эта схема — скелет базы данных. Разработчик смотрит на неё и сразу понимает, какие таблицы создавать, где внешние ключи, и как джойнить.

ERD — самая узкая из трёх нотаций. Она делает ровно одно: показывает структуру данных. Зато делает это без компромиссов. Там, где в UML Class Diagram можно уйти в дебри методов и интерфейсов, ERD держит фокус на одном: «что храним и как оно связано».

Самый частый вопрос новичков: ERD или UML Class Diagram? Отвечаю: если ваша цель — спроектировать БД, берите ERD. Если описываете доменную модель с поведением, методами и наследованием — UML Class Diagram. На практике я часто рисую и то, и другое. Сначала ERD — утвердить схему данных с DBA. Потом Class Diagram — для разработчиков, с методами и бизнес-логикой.

Сравнительная таблица: три нотации в одной плоскости

Эта таблица — ответ на вопрос «что выбрать». Если надо показать, как заказ проходит путь от корзины до доставки, с участием клиента, менеджера и платёжки — BPMN. Если надо показать, как микросервис Заказов дёргает Склад через REST и ждёт ответ — UML Sequence. Если надо спроектировать таблицы orders, order_items, products и их связи — ERD.

Навигатор: какую нотацию брать под задачу

Если вы всё ещё сомневаетесь — вот карта принятия решений. Идёте от вопроса «что мне нужно показать?» и спускаетесь к конкретной нотации:

graph TD
  Q["Что нужно смоделировать?"]

  Q --> P["Бизнес-процесс<br/>кто что делает, в каком порядке"]
  Q --> D["Структура данных<br/>сущности и их связи"]
  Q --> B["Поведение системы<br/>кто кому что отправляет"]
  Q --> S["Состояния объекта<br/>как сущность меняется во времени"]

  P --> P1{"Процесс с ролями<br/>и ветвлениями?"}
  P1 -->|"да"| BPMN["BPMN<br/>дорожки, шлюзы, события"]
  P1 -->|"нет"| ACT["UML Activity Diagram<br/>поток управления"]

  D --> D1{"Проектируем БД<br/>или логическую модель?"}
  D1 -->|"БД"| ERD["ERD<br/>таблицы, ключи, связи"]
  D1 -->|"логика"| CLS["UML Class Diagram<br/>классы, атрибуты, методы"]

  B --> B1{"Описываем сценарий<br/>или архитектуру?"}
  B1 -->|"сценарий"| SEQ["UML Sequence Diagram<br/>обмен сообщениями во времени"]
  B1 -->|"архитектура"| COMM["UML Component Diagram<br/>разбивка на модули и интерфейсы"]

  S --> STM["UML State Machine<br/>состояния, переходы, триггеры"]

  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 B fill:#f0a500,stroke:#c88400,color:#fff
  style S fill:#f0a500,stroke:#c88400,color:#fff
  style P1 fill:#e0e0e0,stroke:#999,color:#333
  style D1 fill:#e0e0e0,stroke:#999,color:#333
  style B1 fill:#e0e0e0,stroke:#999,color:#333
  style BPMN fill:#50c878,stroke:#3a9a5c,color:#fff
  style ACT fill:#7b68ee,stroke:#5a4db2,color:#fff
  style ERD fill:#50c878,stroke:#3a9a5c,color:#fff
  style CLS fill:#7b68ee,stroke:#5a4db2,color:#fff
  style SEQ fill:#50c878,stroke:#3a9a5c,color:#fff
  style COMM fill:#7b68ee,stroke:#5a4db2,color:#fff
  style STM fill:#50c878,stroke:#3a9a5c,color:#fff

Логика простая. Начинаете с вопроса «что моделирую?» — жёлтые узлы наверху. Отвечаете — попадаете в серый ромб с уточняющим вопросом. В зависимости от ответа выходите на зелёную или фиолетовую нотацию.

Зелёные — это нотации-финалисты: берёте и рисуете, без дополнительных вилок. Фиолетовые — UML-нотации, которые закрывают задачу, но требуют понимания контекста (какой именно тип UML-диаграммы нужен).

Один нюанс: эта карта работает для типичных задач новичка. В реальном проекте вы можете комбинировать нотации — например, сначала BPMN для согласования процесса, затем ERD для схемы данных, затем UML Sequence для API-контракта. Это норма. Нотации не конкурируют, они дополняют друг друга.

Что выбрать новичку: минимальный набор

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

1. UML Sequence Diagram. Потому что API-контракты и интеграции — это хлеб аналитика. Без Sequence вы не опишете, как сервисы общаются. Освойте первым делом.
2. ERD. Потому что данные — фундамент. Даже если вы не проектируете БД с нуля, вам нужно читать схему и понимать, где какие ключи. Освойте вторым.
3. BPMN на уровне «дорожки, задачи, шлюзы». Потому что на встрече с заказчиком вы должны быстро набросать процесс так, чтобы его поняли. Не надо зубрить все 100+ элементов BPMN — хватит базового набора из 6–7 фигур.

Что учить потом: UML Activity Diagram (если часто описываете алгоритмы), UML State Machine (если работаете с документооборотом или заказами со сложным жизненным циклом), UML Class Diagram (когда перейдёте к проектированию доменной модели).

Кстати, о требованиях. Нотация — это форма, а содержание — это что именно вы описываете. User Story и Use Case: как системному аналитику писать требования по шаблону — пост про то, как превратить «хотелки» заказчика во внятные спецификации. Нотации и требования идут рука об руку: требования говорят «что», нотация показывает «как».

Когда не надо рисовать вообще

Есть ситуации, где диаграммы вредят.

Первая: процесс на три шага. «Клиент нажал кнопку — система отправила email». Не надо ради этого запускать draw.io и полчаса подбирать иконки. Напишите текстом. Текст в трёх предложениях читается быстрее, чем диаграмма рендерится в голове.

Вторая: диаграмма ради диаграммы. Знаете это чувство, когда в спецификации UML-диаграмма на полстраницы, но никто на неё не смотрит? Не тратьте время. Диаграмма нужна только если она что-то объясняет такого, что текстом объяснить дольше и хуже.

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

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

Главный вывод

Три нотации — три задачи. UML — архитектура и поведение ПО. BPMN — бизнес-процессы и роли. ERD — структура данных.

Не пытайтесь выучить все. Начните с UML Sequence — вы будете рисовать его каждый день. Добавьте ERD для понимания схем данных. И держите BPMN в кармане для встреч с бизнесом. Остальное доберёте, когда понадобится.

И да — не верьте тем, кто говорит «надо знать все 14 диаграмм UML». Они, скорее всего, сами их не рисовали.