Нотации моделирования

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

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

Проблема без нотаций

РАЗРАБОТЧИК рисует:                АРХИТЕКТОР рисует:
┌─────────┐    ┌─────────┐        ┌─────────┐    ┌─────────┐
│ Service │───▶│Database │        │ Module  │───▶│ Store   │
└─────────┘    └─────────┘        └─────────┘    └─────────┘

Это одно и то же? Разные вещи?
Стрелка -- это HTTP? SQL? Зависимость? Поток данных?

С НОТАЦИЕЙ: все понимают одинаково.

Ценность нотаций

Проблема	Решение через нотацию
"Каждый рисует как хочет"	Стандартный визуальный язык
"Непонятно что означает стрелка"	Типизированные связи
"Слишком много деталей на одной диаграмме"	Уровни абстракции
"Диаграмма устарела через неделю"	Diagrams as Code
"Техлид и менеджер видят разное"	Разные виды для разных аудиторий

Обзор нотаций

Карта нотаций

Уровень абстракции
▲
│  ArchiMate          ← Enterprise Architecture
│  ┌─────────────┐
│  │             │
│  └─────────────┘
│
│  BPMN               ← Business Processes
│  ┌─────────────┐
│  │             │
│  └─────────────┘
│
│  C4 Model           ← Software Architecture
│  ┌─────────────┐
│  │             │
│  └─────────────┘
│
│  UML                ← Software Design & Code
│  ┌─────────────┐
│  │             │
│  └─────────────┘
▼

UML (Unified Modeling Language)

UML -- стандарт ISO для моделирования программных систем. Включает 14 типов диаграмм.

Категории UML-диаграмм

Категория	Диаграммы	Для чего
Структурные	Class, Component, Package, Deployment, Object	Статическая структура
Поведенческие	Activity, State Machine, Use Case	Поведение системы
Взаимодействия	Sequence, Communication, Timing, Interaction Overview	Обмен сообщениями

Самые полезные UML-диаграммы

Для System Design:

1. Sequence Diagram    → Как компоненты общаются
   Client ──▶ API ──▶ DB

2. Class Diagram       → Структура кода (Domain Model)
   ┌───────┐
   │ Order │
   ├───────┤
   │-items │──▶ OrderItem
   └───────┘

3. Activity Diagram    → Бизнес-процесс / алгоритм
   [Start] → [Action] → {Decision} → [End]

4. Component Diagram   → Компоненты и зависимости
   [API] ──▶ [Service] ──▶ [Repository]

Плюсы UML	Минусы UML
Стандарт ISO, все знают	14 типов -- избыточно
Полнота покрытия	Сложные диаграммы плохо читаются
Поддержка в инструментах	Часто используется формально
Подходит для документации	Высокий порог входа

C4 Model

C4 Model -- простая иерархическая модель из 4 уровней для визуализации архитектуры.

4 уровня C4

Level 1: System Context   → Как система вписывается в мир
Level 2: Container         → Из каких частей состоит система
Level 3: Component         → Из чего состоит каждый контейнер
Level 4: Code              → Как устроен компонент внутри (UML)

Zoom in:
┌─────────────────────────────────────────┐
│  L1: System Context                     │
│  ┌──────────────────────────────────┐   │
│  │  L2: Containers                  │   │
│  │  ┌───────────────────────────┐   │   │
│  │  │  L3: Components           │   │   │
│  │  │  ┌────────────────────┐   │   │   │
│  │  │  │  L4: Code (UML)   │   │   │   │
│  │  │  └────────────────────┘   │   │   │
│  │  └───────────────────────────┘   │   │
│  └──────────────────────────────────┘   │
└─────────────────────────────────────────┘

Плюсы C4	Минусы C4
Простота (4 уровня)	Не описывает поведение (нет sequence)
Понятен нетехническим	Ограниченная выразительность
Diagrams as Code (Structurizr)	Не заменяет UML полностью
Чёткая аудитория каждого уровня	Нет стандарта ISO

BPMN (Business Process Model and Notation)

BPMN -- стандарт для моделирования бизнес-процессов.

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

Элемент	Символ	Описание
Start Event	(O)	Начало процесса
End Event	(O) с толстой границей	Конец процесса
Task	[прямоугольник]	Действие в процессе
Gateway	<ромб>	Точка ветвления
Sequence Flow	→	Порядок выполнения
Pool/Lane	Горизонтальные полосы	Участники процесса

Пример: оформление заказа

Customer          │  System           │  Warehouse
──────────────────┼───────────────────┼──────────────
                  │                   │
(O) Start         │                   │
  │               │                   │
  ▼               │                   │
[Выбор товаров]   │                   │
  │               │                   │
  ▼               │                   │
[Оформить заказ]──▶[Проверка оплаты] │
                  │  │                │
                  │  ◇ Оплачен?       │
                  │ /   \             │
                  │Да    Нет          │
                  │▼      ▼           │
                  │     [Уведомить    │
                  │      об ошибке]   │
                  │      │            │
                  │      ▼            │
                  │     (O) End       │
                  │                   │
                  │[Создать заказ]────▶[Собрать заказ]
                  │                   │  │
                  │                   │  ▼
                  │                   │[Отправить]
                  │                   │  │
                  │                   │  ▼
                  │                   │(O) End

Плюсы BPMN	Минусы BPMN
Понятен бизнесу	Не для технической архитектуры
Стандарт ISO	Сложные процессы перегружены
Executable (BPEL)	Разрыв между моделью и кодом
Инструменты (Camunda)	Высокий порог входа для деталей

ArchiMate

ArchiMate -- стандарт для моделирования enterprise-архитектуры на трёх уровнях.

Три слоя ArchiMate

┌─────────────────────────────────────┐
│          Business Layer             │  Бизнес-процессы
│  Actor, Role, Process, Service      │  и участники
├─────────────────────────────────────┤
│         Application Layer           │  Приложения
│  Component, Interface, Function     │  и данные
├─────────────────────────────────────┤
│         Technology Layer            │  Инфраструктура
│  Node, Device, Network, Artifact    │  и технологии
└─────────────────────────────────────┘

Плюсы ArchiMate	Минусы ArchiMate
Enterprise-уровень	Избыточен для одного приложения
Связь бизнеса и IT	Сложный, много элементов
Стандарт Open Group	Требует обучения
Impact analysis	Тяжёлые инструменты

Выбор нотации

Матрица выбора

Задача	Нотация	Аудитория
Общая архитектура	C4 (Level 1-2)	Все: от менеджеров до разработчиков
API-взаимодействие	UML Sequence	Разработчики
Domain Model	UML Class	Разработчики, DDD
Бизнес-процесс	BPMN	Бизнес + разработчики
Enterprise landscape	ArchiMate	Архитекторы, CTO
Компоненты системы	C4 (Level 3)	Техлиды, разработчики
Алгоритм/flow	UML Activity	Разработчики

Diagrams as Code

Инструмент	Язык	Для чего
Structurizr	DSL	C4 Model
PlantUML	Text	UML всех типов
Mermaid	Markdown	Sequence, Class, Flowchart
D2	Text	Общие диаграммы
DBML	Text	ER-диаграммы баз данных

Преимущества Diagrams as Code:
1. Версионирование в Git
2. Code review диаграмм
3. Автоматическая генерация
4. Не устаревают (CI/CD)
5. Текстовый формат -- diff-friendly

Итоги

Нотация	Для чего	Сложность
UML	Детальный дизайн кода	Высокая
C4	Архитектура приложения	Низкая
BPMN	Бизнес-процессы	Средняя
ArchiMate	Enterprise-архитектура	Высокая

Главное правило: Используй минимально достаточную нотацию. C4 для архитектуры + UML Sequence для взаимодействий покрывают 80% потребностей. Не усложняй без причины.