Диаграмма на проекте — не украшение презентации, а способ зафиксировать границы системы, процессы и интеграции так, чтобы стейкхолдеры и команда разработки поняли одно и то же. Статья отвечает на практический вопрос: какой из трёх инструментов выбрать, как устроить co-existence с RM и зафиксировать согласованную версию на релиз — не подменяя спецификации API, схемы БД и исполняемые контракты. Обзор не исчерпывает рынок: Visio, Miro/FigJam, PlantUML и Mermaid решают смежные задачи — здесь только EA, Lucidchart и draw.io как типичный корпоративный набор.

1. Суть темы

Инструменты моделирования (modeling tools) — среда, в которой системный аналитик фиксирует структуру системы, процессы, интеграции и границы решения в виде диаграмм и, при необходимости, формальной модели. Модель объясняет кто с кем и зачем взаимодействует; спецификации и контракты задают как именно передаются данные — см. 07.02 Работа с API (практика) и 07.03 Основы XML, JSON, YAML.

ИнструментРольТипичный контекст
Sparx Enterprise Architect (EA)Репозиторий моделей, UML/BPMN/SysML, трассировка к требованиямКорпоративная архитектура, отрасли с формальным audit (финансы, фарма, гос.), единый каталог артефактов
LucidchartОблачные совместные диаграммы, шаблоны BPMN/UML-like, интеграции с wiki/PMКросс-функциональные воркшопы, быстрая визуализация для стейкхолдеров
draw.io (diagrams.net)Универсальный редактор, open-source ядро, self-host / desktopЛёгкая документация, вложения в Confluence/Git, минимум лицензионных барьеров

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

Техническая грамотность выбора хранилища. Системному аналитику в разделе «07» важно понимать не только «где рисовать», но и переносимость артефакта: .drawio — открытый XML, удобный для Git, но diff/merge конфликтов ограничены — см. 07.05 Системы контроля версий (Git) для документации; модель EA живёт в проприетарном репозитории (.eap или БД) и не становится файлами в Git без явного export и процесса синхронизации; Lucid хранит данные в облаке vendor. «Модель в EA» и «диаграмма в репозитории документации» — разные источники правды, пока вы не зафиксировали baseline или export под релиз.

Граница темы в разделе «07. Технический фундамент»:

В зоне этой статьиВынесено в соседние заметки
Выбор и использование EA, Lucidchart, draw.ioСинтаксис UML, BPMN, C4 — 06.01.02 Поведенческие диаграммы (State, Activity, Use Case), 03.04.01 BPMN 2.0 - введение и основы, 06.03.05 C4-модель
В каком инструменте держать артефакт SAКак рисовать context, DFD, ER — 03.01.02 Моделирование контекста системы (Context Diagram), 03.04.02 Диаграмма потоков данных (DFD), 03.03.01 ER-диаграммы (сущность-связь)
Версионирование .drawio в GitПрактика Git для документации — 07.05 Системы контроля версий (Git) для документации
Deployment-sketch на диаграммеDocker/K8s — 07.08 Контейнеризация и оркестрация (Docker, Kubernetes)
flowchart TB
    W[Воркшоп / elicitation]
    W --> D[Черновик Lucid / draw.io]
    W --> S[OpenAPI / SRS — параллельно]
    D --> A{Нужна трассировка и baseline?}
    A -->|Да| EA[Модель в Sparx EA]
    A -->|Нет| K[Wiki / Git + PNG для review]
    EA --> R[Отчёт trace matrix / baseline]

Черновик на воркшопе и текстовые спецификации идут параллельно с elicitation: диаграмма не генерирует OpenAPI или SRS автоматически.

2. Ключевые понятия

Диаграмма vs модель

Диаграмма (diagram) — представление (view) набора элементов и связей для конкретной аудитории: контекст системы, sequence-сценарий, BPMN AS-IS. Модель (model repository) — связный набор элементов с уникальными ID, атрибутами и правилами нотации; одни и те же сущности могут отображаться на нескольких диаграммах.

EA ориентирован на модель: элемент «Система X» существует один раз и ссылается из use case, компонента и требования. Lucidchart и draw.io чаще работают с набором связанных, но слабо нормализованных диаграмм — переиспользование через копирование или embed, а не через единый каталог элементов.

Нотации: где какой инструмент уместнее

Синтаксис нотаций — в 06.01.01 Структурные диаграммы (Class, Object, Package), 03.02.01 Диаграмма прецедентов (Use Case Diagram) и соседних заметках разделов 03 и 06. Здесь — только строгость среды и удобство инструмента:

НотацияEALucidchart / draw.ioЗамечание
UML (Use Case, Activity, Sequence, Class/Component)Профили, валидация, переиспользование элементовШаблоны фигур; строгость — дисциплина командыДетали поведения — 03.02.02 Диаграмма деятельности (Activity Diagram), 03.02.03 Диаграмма последовательности (Sequence Diagram)
BPMN 2.0Валидация профиля, связь с элементами моделиВизуальная близость к BPMN; исполняемость не гарантируетсяСогласование процесса ≠ готовность к engine; исполнение — 06.02.04 Работа с Camunda
C4Возможна через профили/стереотипыШаблоны «из коробки»; draw.io часто в Git рядом с ADRМетод — 06.03.05 C4-модель
ArchiMateНативные слои и viewpointsТолько шаблоны; без enterprise-репозитория ArchiMateСлои — 06.03.02 Бизнес-слой, 06.03.03 Прикладной и технологический слои

Что считать «достаточно строгим» BPMN/UML на review — часть внутреннего регламента / чеклиста команды; ориентир перед стартом — 10.04 Чеклист аналитика перед стартом разработки.

Возможности трёх инструментов

Sparx Enterprise Architect

  • Режим репозитория: файл .eap/.feap (один «архитектор за файлом») vs DB-backed (команда, блокировки элементов). Pro Cloud Server нужен, когда удалённая команда работает с одной DB-backed моделью без VPN к серверу EA; если вам выдали локальный .eap на ноутбук — это ваша зона ответственности SA только в части содержания модели, а не инфраструктуры доступа.
  • Централизованный каталог: версии, baselines, разграничение доступа — стыкуется с 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая) и ожиданиями архкомитета.
  • Requirements management в EA: элементы требований, связи «implements / verifies / traces» — см. 02.03.04 Трассировка требований (концепция), 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148). Отчёт trace matrix под релиз оформляют по 10.01.15 Шаблон матрицы трассировки или внутреннему шаблону EA. Это не замена Jama/DOORS: EA держит модель и trace к элементам диаграмм; RM-hub (Jama, DOORS) — источник правды по тексту требований, статусам и workflow согласования — 02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence). На одном проекте часто co-existence: ID требования в Jama, ссылка и реализация в EA.
  • Генерация документации, reverse engineering кода — для SA не обязанность, но опция синхронизации модели с реализацией после релиза; обновление контекстной диаграммы при смене интеграции — ответственность SA или владельца landscape по регламенту, не «разовая задача архитектора».
  • Профили UML, BPMN, SysML, ArchiMate, пользовательские стереотипы и tagged values.

Lucidchart

draw.io / diagrams.net

  • Редактор: web, desktop, embed; данные как .drawio (XML) — стыкуется с 07.05 Системы контроля версий (Git) для документации (diff/merge ограничены, но артефакт версионируем). PlantUML / Mermaid в markdown — text-friendly альтернатива для sequence и простых схем в том же репозитории, что 10.01.13 Шаблон архитектурного решения (ADR).
  • Self-hosted vs облако diagrams.net; нет встроенного RM как в EA.
  • Экспорт PNG/SVG/PDF; embed в Confluence через макрос draw.io (Atlassian Marketplace); read-only для стейкхолдеров — через wiki-страницу или PNG в MR.
  • BPMN — та же оговорка, что в таблице нотаций.

Viewpoint и уровень абстракции

Viewpoint (точка зрения) — одна система, разные диаграммы для бизнеса, разработки и эксплуатации; декомпозиция — 03.01.03 Декомпозиция системы на подсистемы и модули, views — 06.03.04 Взаимосвязи и точки зрения (Viewpoints). На контекстной диаграмме — акторы и каналы интеграции (REST/SOAP — 03.05.02 Синхронные протоколы (REST, gRPC, GraphQL)); детали контрактов — в OpenAPI/WSDL и 07.02 Работа с API (практика), не на том же листе.

Жизненный цикл артефакта: черновик на воркшопе (Lucid/draw.io) → согласованная модель в EA, если governance это требует; при миграции — один источник правды (baseline в EA или named version / Git tag в wiki), не два расходящихся каталога.

3. Как применяется в работе аналитика

Когда какой инструмент уместен

СитуацияИнструментПочему
Трассировка требование → use case → компонент → тест; baselines под релиз; единый каталог для архкомитетаEAФормальный репозиторий и отчёты compliance
Быстрые сессии с бизнесом, BPMN AS-IS/TO-BE, согласование в Confluence, remote workshopsLucidchartНизкий порог входа, совместное редактирование
Внутренняя KB, C4 в репозитории документации, air-gapped / self-host, файлы в Gitdraw.ioОткрытый формат, минимум vendor lock-in

Минимальный workflow на релиз

Компактная цепочка «действие × инструмент» — без пошагового мануала, но с проверяемым результатом:

Действие на релизEALucidchartdraw.io + Git
Зафиксировать согласованное состояниеBaseline модели + отчёт trace matrix (10.01.15 Шаблон матрицы трассировки)Named version + export PDF/PNGCommit .drawio, Git tag на релиз
Доказательство для audit / архкомаBaseline + матрица по 02.03.04 Трассировка требований (концепция)Named version + export в wiki/ConfluenceTag + PNG в MR (08.04 Рецензирование и инспекции (техники Фейгана))
Показать стейкхолдерам без лицензииHTML/PDF-отчёт из EAShare read-only или embed в ConfluencePNG/PDF на wiki-странице

Артефакты SA: где держать и ограничения инструмента

АртефактТипичный инструментОграничение / практика
Context / landscapeLucid или draw.io на старте; EA при governanceИмена из 10.01.14 Шаблон глоссария и словаря данных; метод — 03.01.02 Моделирование контекста системы (Context Diagram)
Use case + sequenceEA (связанные элементы); Lucid/draw.io для MVP-черновикаВ Lucid/draw.io trace к требованиям — вручную или через wiki
BPMN AS-IS/TO-BELucid на воркшопе; EA для baseline под релизАртефакт процесса — 10.01.08 Шаблон сквозной фичи (BPMN-процесс); исполняемость — см. таблицу нотаций
Integration / data flow, DFDdraw.io в Confluence/Git; EA при trace к компонентамDFD — 03.04.02 Диаграмма потоков данных (DFD); контракты — 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf)
ER / logical dataEA или draw.io; реже LucidФизическая схема — 07.01 Базы данных и SQL на уровне аналитика
Deployment sketchdraw.io / Lucid; EA для enterprise landscapeДетали K8s — 07.08 Контейнеризация и оркестрация (Docker, Kubernetes)

Миграция и co-existence: черновики из Lucid/draw.io импортируют в EA или архивируют как PNG + ссылка. Импорт в EA часто lossy: фигуры не становятся единым каталогом элементов с trace автоматически — нужна ручная нормализация или повторное моделирование ключевых связей. После baseline в EA wiki-страница ссылается на отчёт EA, а не дублирует «живую» схему. Confluence + draw.io macro — RM-light для диаграмм рядом с текстом требований — 02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence).

Рабочие практики

  • Единая легенда и словарь — те же имена систем, что в глоссарии и API-спецификации.
  • Версионирование смысла — номер релиза, дата, статус (draft/approved) на диаграмме; см. таблицу «минимальный workflow на релиз» выше.
  • Не дублировать текст требований на диаграмме — ссылки на ID (в EA нативно; в Lucid/draw.io — гиперссылки или макросы wiki).
  • Один вопрос — одна диаграмма; декомпозиция через ссылки «см. D-002».
  • Согласование с CI/CD — deployment-диаграммы отражают среды (dev/test/prod), не подменяя pipeline-as-code — 07.06 CICD и конвейеры — влияние на требования.

Если audit = named versions в Confluence с export — Lucid может пройти; риск — когда единственная копия в SaaS без export и без привязки к релизу.

Чеклист выбора инструмента

  • Нужна ли формальная трассировка и отчёты compliance (00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148))?
  • Обязателен ли единый репозиторий vs распределённые страницы wiki?
  • Collaboration vs offline/air-gapped и data residency (Lucid SaaS vs self-hosted draw.io)?
  • Нужен ли read-only / PDF / embed для стейкхолдеров без лицензий?
  • Режим EA: файл vs DB, сколько параллельных редакторов; нужен ли Pro Cloud Server?
  • Интеграция с Jira/Confluence/Azure DevOps?
  • Co-existence с Jama/DOORS — кто источник правды по тексту требований?
  • Навыки команды и стоимость лицензий (EA — per seat; Lucid — subscription; draw.io — часто бесплатно при self-host)?

Если EA внедряют «на будущее» без baselines и trace matrix — overhead без отдачи. Если governance требует неизменяемый снимок на релиз, а артефакты живут только в облаке без export и без named version — риск для compliance; конкретный критерий задаёт ваш регламент, не инструмент сам по себе.

4. Типовые ошибки и ограничения

Сводка ограничений (для решения)

Таблица ниже — не дублирование §2, а компактный чеклист при выборе. Детали по нотациям и хранилищу — выше.

КритерийEALucidchartdraw.io
Vendor lock-in / переносимостьПроприетарный репозиторий; миграция трудоёмкаОблако Lucid; export без named version не спасает auditОткрытый XML; переносимее
Параллельная работаDB + locking; .eap — узкое местоReal-time; named version для снимкаGit merge XML — болезненно
Трассировка RMСильная в модели; текст требований — часто в JamaСлабая / через интеграцииОбычно внешняя
Доступ стейкхолдеров без лицензииОтчёты/HTML/PDF из EAShare read-only, embedWiki + PNG/PDF

Типичные ошибки аналитика

  1. «Картинка ради картинки» — диаграмма без аудитории и вопроса; дублирование текста ТЗ вместо ссылки на 02.03.03 Спецификация требований (SRS, Use Case, User Story).
  2. Смешение уровней — бизнес-правила, UI и SQL на одном листе.
  3. Несогласованная нотация — «UML на глаз» без легенды; BPMN с неверными шлюзами → ложное ощущение согласования и готовности к автоматизации (см. таблицу нотаций в §2).
  4. Расхождение модели и реализации — после релиза API/БД артефакты не обновляют; в EA помогает baseline + опционально reverse engineering; без Git для draw.io — та же проблема. Зафиксируйте в регламенте, кто обновляет контекстную диаграмму при смене интеграции.
  5. Неверный масштаб инструмента — EA для малой команды без governance; enterprise без репозитория, когда audit требует trace matrix.
  6. Два источника правды — живая схема в Lucid и «официальная» в EA без процесса синхронизации.
  7. Lossy import = «мигрировали в EA» — импорт Lucid/draw.io не создаёт trace и единый каталог без доработки; ложное ощущение единого источника правды.
  8. Единственная копия в SaaS без export — риск потери истории (актуально для Lucid).
  9. .drawio в Git без договорённости — кто мержит конфликты XML, есть ли PNG для review в MR — см. 07.05 Системы контроля версий (Git) для документации, 08.04 Рецензирование и инспекции (техники Фейгана).

Что моделирование не заменяет

Моделирование не заменяет исполняемые спецификации (OpenAPI, JSON Schema, DDL), не доказывает корректность протоколов и не заменяет сетевые расчёты. Оно снижает неоднозначность на человеческом уровне — между elicitation и разработкой.

EA и RM-инструменты: EA не делает Jama/DOORS избыточными в программах с формальным RM — модель+trace в EA дополняет requirements hub. Lucid и draw.io в эту нишу не претендуют. Подсказки по LLM в редакторах диаграмм — 11.05 Интеграция LLM с инструментами аналитика.

Связи с другими разделами базы

Источники и дополнительные материалы

Продукты и документация

Стандарты и нотации