Контекстная диаграмма — первый архитектурный шаг системного аналитика: она фиксирует границы проектируемой системы как «чёрного ящика» и показывает, с кем и какими данными система обменивается снаружи. Без согласованного контекста невозможно корректно выявить все интерфейсы и перейти к декомпозиции. Диаграмма отвечает на три вопроса: что внутри системы, кто снаружи, какие потоки данных связывают их.
1. Суть темы
Контекстная диаграмма (Context Diagram) — верхний уровень в иерархии диаграмм потоков данных (DFD, Data Flow Diagram): один процесс (система в целом), окружённый внешними сущностями (external entities / terminators), связанными с ним именованными потоками данных. Внутреннее устройство системы на этом уровне не показывается.
В BABOK® v3 контекстная диаграмма относится к техникам моделирования scope (Scope Modelling) и иллюстрирует понятие контекста (Context) в BACCM. В SEBoK тот же смысл выражается через system context и system boundary — описание системы в её окружении и границы, за которыми начинается внешний мир. Нормативная база — в 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148). Контекст — не детальное поведение во времени: sequence diagram и activity diagram описывают сценарии и порядок шагов, а не границы обмена данными.
Нумерация уровней DFD. В этой базе принята схема Гейна/Сарсона (G&S): контекст — процесс с номером 0, первая декомпозиция — уровень 1, далее 2, 3… В школе Йордана/Де Марко контекст иногда обозначают как «уровень −1», а процесс «0» — уже первой декомпозицией; это та же семантика «один чёрный ящик», но другая нумерация. При стыковке с 03.04.02 Диаграмма потоков данных (DFD) ориентируйтесь на G&S: контекст = 0.
Ключевые задачи контекста с системной точки зрения:
- Чёрный ящик и внешние интерфейсы — перечень точек обмена данными с людьми, организациями, смежными ИС и устройствами. Детализация контрактов — в 03.01.04 Интерфейсы и интеграционные взаимодействия.
- Граница по данным и каналам — что проходит через периметр системы; критерии «в scope / вне scope» и согласование с заказчиком — в 02.01.04 Определение границ решения (Scope Modelling).
- Основа для трассировки — поток на диаграмме связывается с требованием, интерфейсом или пунктом SRS (02.03.04 Трассировка требований (концепция), 10.01.15 Шаблон матрицы трассировки).
- Контракт о границах — артефакт для согласования с архитектором и командой разработки; входит в gate перед декомпозицией (10.04 Чеклист аналитика перед стартом разработки).
Контекст связан с понятием системы в среде (01.01 Понятие системы и системного подхода) и с видами архитектуры (03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая)): на одном проекте может понадобиться контекст бизнес-решения (организация и партнёры), системного (прикладная система и внешние ИС) или компонента (модуль внутри ERP). Это разные границы «чёрного ящика» — не смешивайте их на одной диаграмме без явной подписи уровня.
Типичная цепочка артефактов: 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая) → контекст (уровень 0) → DFD уровней 1+ (03.04.02 Диаграмма потоков данных (DFD)) → декомпозиция на подсистемы (03.01.03 Декомпозиция системы на подсистемы и модули) → use case / интерфейсы (03.02.01 Диаграмма прецедентов (Use Case Diagram), 03.01.04 Интерфейсы и интеграционные взаимодействия) → sequence для конкретного сценария (03.02.03 Диаграмма последовательности (Sequence Diagram)). Sequence — не «следующий шаг» после контекста, а детализация уже согласованного взаимодействия.
2. Ключевые понятия
Элементы контекстной DFD
На контекстном уровне допустимы только три типа элементов: процесс (система), внешняя сущность, поток данных. Хранилища, subprocesses и полный синтаксис нотаций — только в 03.04.02 Диаграмма потоков данных (DFD).
| Элемент | Гейн/Сарсон | Де Марко / Йордан | Описание |
|---|---|---|---|
| Процесс (система) | Скруглённый прямоугольник, номер «0» | Круг, номер «0» | Моделируемая система целиком; не декомпозируется на этом уровне |
| Внешняя сущность | Прямоугольник | Прямоугольник | Лицо, организация, подразделение, смежная ИС или устройство вне зоны ответственности проекта |
| Поток данных | Стрелка с подписью | Стрелка с подписью | Именованный канал передачи информации между процессом и сущностью |
Правила контекстного уровня (кратко): один процесс «0»; нет хранилищ; нет прямых потоков «сущность — сущность»; потоки — имена-существительные («Заказ», не «Оформить заказ»); у каждого потока есть отправитель и получатель.
Соглашения по потокам
- Один поток на диаграмме — один логический тип данных; состав атрибутов фиксируйте в 03.03.03 Словарь данных (описание).
- Двунаправленный обмен — две стрелки с разными именами, а не одна безымянная «туда-обратно».
- В event-driven и асинхронных интеграциях на контексте показывают именованный обмен информацией (событие, сообщение, webhook); протокол и топология — в 03.05.04 Асинхронное взаимодействие (очереди, Kafka, Events) и 03.05.01 Виды интеграции (точка-точка, ESB, API-led).
Устройства и каналы доступа
Категория «устройства» на контексте — не дублирование пользователя, а точка входа данных в систему:
| Ситуация | Типичное решение |
|---|---|
| Веб, мобильное приложение, POS-терминал как клиент одной системы | Одна сущность «Пользователь» (или роль: Покупатель, Кассир); канал (web/mobile/POS) — в интерфейсной спецификации или подпись потока |
| Устройство как автономный инициатор (датчик IoT, весы, сканер штрих-кода без UI) | Отдельная внешняя сущность: «Датчик температуры», «POS-терминал сети X» |
| Мобильное приложение — отдельный продукт с собственным API | Снаружи как смежная ИС; потоки «Запрос заказа / Ответ API» |
Периметр: безопасность, НФТ и регуляторика
На контексте фиксируют не только функциональные потоки, но и внешние ограничения периметра: IdP, API-шлюз, WAF, регулятор, система аудита. Их показывают как terminators или помечают на потоках ограничения (шифрование, маскирование, retention). Классификация НФТ — в 08.02 Нефункциональные требования (НФТ) — классификация и стандарты; практика периметра — в 08.07 Основы кибербезопасности для системного аналитика. Если поток несёт платёжные или персональные данные, отметьте связь с регуляторными рамками (08.06 Юридические и регуляторные требования РФ (PCI-DSS)) — без детализации PCI на диаграмме, только «граница доверенной зоны».
Логическая и физическая внешняя сущность
На контексте допустимы оба уровня абстракции: «Банк» (логически) или «API банка X v2» (физически). Выбор зависит от аудитории: для Vision & Scope с заказчиком — логические роли; для интеграционной спецификации — конкретные системы и контракты. Не смешивайте уровни на одной диаграмме без пояснения.
Альтернативные представления контекста
Одна и та же граница системы может быть показана разными нотациями. Это виды (views), а не взаимозаменяемые копии одного артефакта.
| Нотация | Что показывает | Чего не показывает | Когда выбирать |
|---|---|---|---|
| Context DFD (уровень 0) | Именованные потоки данных между системой и внешними сущностями | Функции, порядок шагов, хранилища | Scope по данным, структурный анализ, основа для DFD 1+ |
| IDEF0 A-0 (03.04.03 IDEF0 и его применение) | Входы, выходы, управление, механизмы одной функции | Детальные потоки DFD, декомпозиция по данным | Процессно-ориентированные проекты, гос/пром стандарты |
| C4 Context (06.03.05 C4-модель) | ПО-система, пользователи и смежные системы | Состав потоков данных, атрибуты | Software architecture, согласование с разработчиками |
| Use Case (boundary) (03.02.01 Диаграмма прецедентов (Use Case Diagram)) | Акторы и функциональные цели | Структура данных и каналы обмена | Переход к сценариям и приёмке по функциям |
| ArchiMate (бизнес/прикладной слой) (06.03.02 Бизнес-слой, 06.03.03 Прикладной и технологический слои) | Сервисы, роли, интерфейсы в EA-ландшафте | Детальные потоки DFD | Корпоративный контекст, согласование с EA |
| Карта экосистемы | Косвенные зависимости без прямого обмена | Точные контракты интеграции | Стратегический обзор; см. 02.01.03 Анализ заинтересованных сторон (Stakeholder Map) |
Экосистемная карта — отдельный артефакт, не «расширенная» context DFD: на классическом контексте не рисуют сущности без прямого обмена данными с системой.
3. Как применяется в работе аналитика
Пошаговая методика
- Назовите систему — однозначное имя по бизнес-назначению («Интернет-магазин "Ромашка"», «Модуль расчёта зарплаты»). Для компонента внутри большой системы явно укажите, что граница — модуля, а не всего ERP.
- Выявите внешние сущности — по 02.01.03 Анализ заинтересованных сторон (Stakeholder Map), интервью (02.02.01 Интервьюирование и анкетирование) и воркшопам (02.02.02 Воркшопы, фасилитация и совместные сессии). Категории: пользователи, подразделения, внешние организации, смежные ИС, устройства (см. таблицу выше).
- Определите потоки данных — для каждой сущности: что передаёт системе и что получает. Имена — существительные, согласованные с глоссарием.
- Проверьте полноту — чеклист ниже; валидация с заказчиком по 02.04.01 Верификация и валидация (V&V): «это действительно все внешние акторы и потоки для приёмки на границе?»
- Согласуйте — контекст как контракт о границах; включите в Vision & Scope или BRD (04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)). Триггеры пересмотра: новая интеграция → оценка влияния на границу и при необходимости change request через 02.05.02 Управление изменениями (Change Control Board); сдвиг приоритетов без изменения границы — 02.05.02 Управление приоритетами в условиях изменчивости.
Критерии проведения границы (системный угол)
Спорные случаи решаются вопросом «кто владеет изменениями и контрактом», а не технологией как таковой. Полная методика scope — в 02.01.04 Определение границ решения (Scope Modelling); здесь — типичные SA-решения:
| Ситуация | Типичное решение | Уточнить |
|---|---|---|
| Платёжный шлюз, IdP, CDN | Снаружи (terminator), если не разрабатываете и не сопровождаете | Потоки «запрос оплаты / результат» — между системой и шлюзом, не между покупателем и ядром |
| Корпоративный планировщик (Control-M, cron в другой системе) | Снаружи, если расписание и изменения — у другой команды | Встроенный job scheduler продукта — внутри |
| Микросервис «соседнего» продукта той же компании | Снаружи, если контракт и релизы — другая команда/продукт | Внутри, если входит в ваш solution scope |
| «Наш» API в облаке провайдера | Сущность «Облачный провайдер X» снаружи; управляемый вами runtime — внутри границы «системы» | Кто владеет SLA, секретами, сетевыми правилами; детали — в 03.01.04 Интерфейсы и интеграционные взаимодействия |
Трассировка: поток → требование
Каждый именованный поток на контексте — кандидат на строку матрицы трассировки:
Поток «Подтверждение платежа» → FR-042 (приём оплаты) → IF-PAY-01 (интерфейс шлюза) → пункт SRS §4.2Заполнение на уровне контекста — в 10.01.15 Шаблон матрицы трассировки; концепция — в 02.03.04 Трассировка требований (концепция).
Пример: интернет-магазин
Внешние сущности: Покупатель, Менеджер магазина, Платёжный шлюз, Служба доставки, Складская система. Оплата идёт через шлюз — прямого потока «Оплата» от покупателя к системе нет. На схеме — отдельная стрелка на каждый логический поток (правило «один поток — один тип данных»):
flowchart LR
Customer["Покупатель"]
Manager["Менеджер магазина"]
PaymentGW["Платёжный шлюз"]
Delivery["Служба доставки"]
Warehouse["Складская система"]
System["0<br/>Интернет-магазин"]
Customer -->|"Запрос каталога"| System
Customer -->|"Оформление заказа"| System
System -->|"Каталог товаров"| Customer
System -->|"Статус заказа"| Customer
System -->|"Уведомления"| Customer
Manager -->|"Данные о товарах"| System
Manager -->|"Правила ценообразования"| System
System -->|"Отчёт по продажам"| Manager
System -->|"Заявки на возврат"| Manager
System -->|"Запрос на списание"| PaymentGW
System -->|"Отмена платежа"| PaymentGW
PaymentGW -->|"Подтверждение платежа"| System
PaymentGW -->|"Ошибка транзакции"| System
System -->|"Заявка на доставку"| Delivery
System -->|"Возврат заказа"| Delivery
Delivery -->|"Трек-номер"| System
Delivery -->|"Статус доставки"| System
System -->|"Заказ на резервирование"| Warehouse
System -->|"Уведомление о сборке"| Warehouse
Warehouse -->|"Остатки товаров"| System
Warehouse -->|"Подтверждение отгрузки"| System
Примечание: в G&S процесс «0» — скруглённый прямоугольник, в DeMarco — круг; внешние сущности — прямоугольники. Mermaid выше передаёт семантику G&S; форму узла «0» в draw.io/Lucidchart берите по выбранной нотации.
Внутренние части (каталог, корзина, личный кабинет) появятся при декомпозиции на DFD уровня 1 (03.04.02 Диаграмма потоков данных (DFD)).
Рекомендуемое дополнение: реестр внешних сущностей
К диаграмме приложите таблицу с полями: наименование, тип (человек / ИС / устройство), зона ответственности, контакт заказчика, связанные потоки. Пример одной строки:
| Наименование | Тип | Зона ответственности | Контакт заказчика | Потоки |
|---|---|---|---|---|
| Платёжный шлюз «PayGate» | ИС | Обработка платежей по контракту; SLA — провайдер | Иван Петров, отдел закупок | Запрос на списание, Подтверждение платежа, Отмена платежа |
Чеклист валидации контекста
- Каждый значимый stakeholder представлен сущностью или явно исключён с обоснованием.
- У каждого потока есть producer и consumer; одна стрелка — один логический тип данных.
- Нет хранилищ, subprocesses и потоков «сущность — сущность».
- IdP, шлюзы и регуляторные точки периметра отражены, если влияют на приёмку.
- Имена согласованы со 03.03.03 Словарь данных (описание).
- Новое требование наносится на диаграмму или маркируется кандидатом на change (не «автоматически вне scope»).
- Заказчик подтвердил полноту внешних акторов и потоков (02.04.01 Верификация и валидация (V&V)).
Место в процессе анализа
Контекст создаётся после фиксации бизнес-потребности (02.01.01 Определение бизнес-проблем и возможностей) и задаёт рамки для классификации требований (02.03.01 Классификация требований (БТ, ФТ, НФТ)), проектирования интеграций (03.05.01 Виды интеграции (точка-точка, ESB, API-led)) и приёмочных сценариев на уровне обмена (02.04.02 Критерии приёмки (Acceptance Criteria)). Черновик можно ускорить средствами из 07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io) или LLM (11.05 Интеграция LLM с инструментами аналитика), но границы, состав сущностей и потоков проверяет аналитик.
4. Типовые ошибки и ограничения
| Ошибка | Почему мешает | Как избежать |
|---|---|---|
| Несколько процессов или хранилищ на «контексте» | Смешение с DFD 1+ | Один процесс «0»; декомпозиция — в 03.04.02 Диаграмма потоков данных (DFD) |
| Несколько потоков на одной стрелке | Нарушает правило трассировки | Отдельная стрелка на каждый логический тип данных |
| Потоки-глаголы («Оформить заказ») | Путают данные и действия | Имена-существительные; сценарии — в use case |
| Прямая оплата от пользователя в ядро при внешнем шлюзе | Неверная граница интеграции | Потоки через terminator шлюза |
| POS/IoT как «ещё один пользователь» без потоков | Дыры в scope устройств | Отдельная сущность или явная роль + поток телеметрии |
| Пропуск IdP / WAF на периметре | НФТ и security вне документации | Terminator или пометка на потоках; см. 08.07 Основы кибербезопасности для системного аналитика |
| Смешение контекста решения и модуля | Несогласованный scope | Отдельные диаграммы или явная подпись уровня |
| Подмена context DFD картой экосистемы | Размытые контракты | Косвенные влияния — отдельный артефакт |
| Категоричное «вне scope без обсуждения» | Конфликт с change management | Оценка влияния + CCB при выходе за границу |
Ограничения нотации: контекстная DFD не показывает порядок, параллельность и тайминг (в отличие от flowchart и sequence). Не заменяет спецификацию протоколов (03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf)) и не описывает внутреннюю архитектуру (03.01.03 Декомпозиция системы на подсистемы и модули).
Связи с другими разделами базы
Цепочка системной архитектуры (03.01):
- 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая) — уровни контекста: бизнес / система / компонент.
- 03.01.03 Декомпозиция системы на подсистемы и модули — следующий шаг после согласованного контекста.
- 03.01.04 Интерфейсы и интеграционные взаимодействия — детализация потоков с диаграммы.
Моделирование и альтернативные нотации (03.04, 06):
- 03.04.02 Диаграмма потоков данных (DFD) — декомпозиция контекста на уровни 1, 2, …
- 03.04.03 IDEF0 и его применение — контекстная диаграмма A-0 как родственный артефакт.
- 03.02.01 Диаграмма прецедентов (Use Case Diagram) — границы через акторов и функции.
- 06.03.05 C4-модель — контекст для software architecture.
Границы, требования и качество (02.x, 08.x, 10.x):
- 02.01.04 Определение границ решения (Scope Modelling) — критерии in/out of scope; контекст — системное представление границы.
- 02.03.04 Трассировка требований (концепция) и 10.01.15 Шаблон матрицы трассировки — связь потоков с требованиями.
- 02.04.01 Верификация и валидация (V&V) — валидация полноты контекста с заказчиком.
- 08.02 Нефункциональные требования (НФТ) — классификация и стандарты и 08.07 Основы кибербезопасности для системного аналитика — периметр и ограничения на потоках.
- 10.04 Чеклист аналитика перед стартом разработки — контекст как gate перед декомпозицией.
Документирование и стандарты:
- 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD) — место контекста в аналитической документации.
- 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148) — BABOK (scope), SEBoK (system context/boundary), ISO 29148.
Источники и дополнительные материалы
Книги и стандарты
- Tom DeMarco. Structured Analysis and System Specification. Yourdon Press, 1978. — классика DFD и контекстной диаграммы.
- Edward Yourdon. Modern Structured Analysis. Prentice-Hall, 1989. — развитие методологии контекстных диаграмм.
- Karl Wiegers, Joy Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. — глава о scope и контекстных диаграммах.
- BABOK Guide v3 (IIBA). Разделы Scope Modelling, Specify and Model Requirements. — iiba.org — BABOK
- ISO/IEC/IEEE 29148:2018 — требования к определению границ и контекста системы. — ISO.org; альтернативная справка: IEEE 29148-2018
- SEBoK — System Definition (system context, system boundary). — sebokwiki.org
Статьи и спецификации
- Simon Brown. C4 Model — иерархия context → containers → components → code. — c4model.com
- Morgan Masters. Introduction to Context Diagrams. Modern Analyst, 2019. — modernanalyst.com
- Morgan Masters. Putting Systems Analysis "Into Context" using the Context Diagram. Modern Analyst. — modernanalyst.com
Дополнительно
- Gane & Sarson — нотация DFD со скруглённым процессом и прямоугольными terminators (подробнее в 03.04.02 Диаграмма потоков данных (DFD)).
- Видео: DFD Context Diagram Explained with Examples — BA-EXPERTS (YouTube); поиск по названию.