Диаграмма потоков данных (Data Flow Diagram, DFD) — нотация для моделирования движения информации в системе: какие данные поступают, как процессы их преобразуют, где хранятся и кому передаются. В отличие от BPMN, который описывает поток работ (роли, события, SLA), DFD фиксирует информационную и функциональную архитектуру — сеть процессов, соединённых потоками данных. Заметка живёт в ветке «Описание бизнес-процессов», но не заменяет описание исполняемого процесса: DFD здесь — инструмент SA для модели функций и данных в цепочке с моделированием данных и архитектурой ИС. Выбор нотации — по вопросу «какие данные и где преобразуются», а не «кто в каком порядке выполняет шаги».

DFD не показывает временную последовательность, условия ветвления и управляющие сигналы. Для этого — диаграмма деятельности или BPMN. DFD уместна на верхних уровнях абстракции при анализе функциональных требований, проектировании архитектуры ИС и интеграций.

1. Суть темы

DFD — часть структурного анализа (structured analysis): метод декомпозиции системы через иерархию диаграмм с обязательной балансировкой потоков между уровнями. В классическом SDLC DFD строят на этапе анализа требований и предпроектного обследования — см. Waterfall и V-model; в Agile — точечно для спорных интеграций и legacy-участков.

Аналитик строит DFD, когда нужно:

  • зафиксировать границу системы и обмен данными с внешним миром;
  • декомпозировать функции без привязки к экранам и API;
  • связать процессы с хранилищами и потоками для последующей спецификации (ERD, словарь данных, интерфейсы).

Контекстная DFD (уровень 0) пересекается с контекстной диаграммой системы, но не дублирует её: context diagram в SA — семейство видов (integration context, DFD level 0, C4 Context в C4-модели). Контекстная DFD — частный случай, где система — один процесс «чёрный ящик», а стрелки — только именованные потоки данных. C4 Context показывает системы и людей на границе, часто с технологиями связи; DFD L0 детализирует именно информационный обмен и служит стартом декомпозиции. На проекте достаточно одного контекстного вида: если команда ведёт C4 Context — DFD L0 не обязательна; если выбрана DFD — уровень 0 заменяет контекстный артефакт и становится родителем для L1, а не параллельным документом.

Логическая vs физическая DFD. Логическая DFD описывает, какие преобразования нужны, независимо от конкретных БД, файлов и протоколов — основной уровень работы SA на этапе требований. Физическая DFD добавляет реальные носители (таблицы, очереди, REST-эндпоинты, печатные формы) — чаще зона архитектора и разработки; связь с логической и физической моделью данных.

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

Четыре элемента DFD

ЭлементНазначениеYourdon/DeMarcoGane/Sarson
Внешняя сущность (External Entity)Источник или приёмник данных вне системыПрямоугольникПрямоугольник
Процесс (Process)Преобразование входных потоков в выходные; имя — глагол + объектКругСкруглённый прямоугольник с полями (номер, имя)
Хранилище данных (Data Store)Место накопления данных для последующего использованияДве параллельные линииПрямоугольник с открытой левой стороной
Поток данных (Data Flow)Перемещение информации; подпись — существительное, не действиеСтрелка с именемСтрелка с именем

Правила именования:

  • Процесс: «Рассчитать стоимость», «Проверить наличие».
  • Поток: «Данные заказа», «Подтверждение оплаты» — не «Передать заказ».
  • Хранилище: «Заказы», «Клиенты» — часто соответствует сущностям ER-диаграммы.
  • Внешняя сущность: роль, отдел или система («Клиент», «Платёжный шлюз»).

Составные пакеты данных детализируйте в словаре данных или шаблоне глоссария.

Нотации: Yourdon/DeMarco и Gane/Sarson

Исторически — две школы структурного анализа с одинаковой семантикой, разной графикой:

  • Yourdon/DeMarco — процессы кругами; лаконично, но тесно для длинных имён.
  • Gane/Sarson — процессы прямоугольниками с номером; удобнее для иерархии и трассировки.

На практике чаще Gane/Sarson. Диаграммы Mermaid в этой заметке — схематическая иллюстрация логики, а не канон нотации: формы узлов упрощены, хранилища не повторяют «открытый прямоугольник» Gane/Sarson. Рабочие артефакты стройте в специализированных редакторах с корпоративным стандартом; Mermaid и PlantUML удобны для черновиков и версионирования в Git.

Иерархия уровней

УровеньСодержание
0 (контекст)Один процесс — вся система; потоки к внешним сущностям
1Декомпозиция контекстного процесса на основные функции (1, 2, 3…)
2, 3, …Детализация выбранного процесса (2.1, 2.2; 2.2.1…)

Декомпозиция следует принципу декомпозиции системы: каждый уровень добавляет детализацию внутри границы родительского процесса. На уровне 2 и ниже к каждому «листовому» процессу классически добавляют спецификацию процесса (process specification): входы, выходы, логика преобразования текстом — без новой графики, но с трассировкой к FR.

Explosion и implosion потоков. Один контекстный поток может расщепиться (explosion) на несколько дочерних — если родительский пакет данных на L1 раскладывается на составные потоки между процессами. Несколько внутренних потоков могут слиться (implosion) в один исходящий поток родителя — если процессы формируют единый информационный пакет. Имена при explosion/implosion должны быть согласованы: либо сохраняется имя родителя, либо в словаре данных явно указано «Данные заказа = {позиции, адрес, сумма}». Без этой связи балансировка формально нарушена.

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

Когда строить DFD, а когда нет

СитуацияDFD уместна
Новая ИС с множеством интеграций и неочевидными потоками данныхДа
Рефакторинг legacy: нужно понять, где данные «застревают»Да
Согласование границ с заказчиком до детализацииДа — контекст (L0)
Малый scope, команда уже ведёт OpenAPI + ERDСкорее нет — дублирование
Agile-итерация на один микросервис с готовым контрактомТочечно — только спорные потоки
Нужны роли, SLA, таймеры, исполняемый процессНет — [[03.04.01 BPMN 2.0 - введение и основы

Поток на DFD часто становится черновиком контракта интеграции: логический «Результат оплаты» → физический payload в OpenAPI/AsyncAPI. Для событийных и real-time сценариев классическая DFD ограничена: асинхронные очереди и event streams лучше дополнять моделями асинхронного взаимодействия.

Пример: контекст (уровень 0)

flowchart LR
    subgraph "Внешние сущности"
        Клиент(Клиент)
        ПС(Платёжный шлюз)
        Склад(Складская система)
    end
    subgraph "Интернет-магазин (система)"
        P0["0 Обработать заказ"]
    end
    Клиент -->|"Заказ"| P0
    P0 -->|"Счёт на оплату"| Клиент
    P0 -->|"Запрос на оплату"| ПС
    ПС -->|"Результат оплаты"| P0
    P0 -->|"Заказ на доставку"| Склад
    Склад -->|"Подтверждение отгрузки"| P0
    P0 -->|"Уведомление о статусе"| Клиент

Mermaid — схема логики; на рабочей диаграмме — Gane/Sarson: процесс 0 в поле «номер | имя», внешние сущности — прямоугольники.

Контекстная диаграмма задаёт границы решения: 3 внешних сущности, 7 потоков через границу системы.

Пример: уровень 1 с балансировкой

Процесс 0 «Обработать заказ» раскрывается на процессы 1–4. Имена потоков на границе системы совпадают с контекстом; все внутренние потоки — между процессами и при обращении к хранилищам — тоже подписаны. P3 «Провести оплату» фиксирует «Статус оплаты» в D2: без записи в хранилище оплата остаётся «чёрным ящиком», а P2 не может опираться на согласованное состояние заказа.

flowchart TD
    Клиент(Клиент)
    ПС(Платёжный шлюз)
    Склад(Складская система)

    subgraph "Система"
        P1["1 Проверить наличие"]
        P2["2 Оформить заказ"]
        P3["3 Провести оплату"]
        P4["4 Передать в доставку"]
        D1[("D1 База товаров")]
        D2[("D2 База заказов")]
    end

    Клиент -->|"Заказ"| P1
    D1 -->|"Данные товаров"| P1
    P1 -->|"Резерв товара"| D1
    P1 -->|"Проверенный заказ"| P2
    P2 -->|"Запись заказа"| D2
    P2 -->|"Счёт на оплату"| Клиент
    P2 -->|"Запрос на оплату"| P3
    P3 -->|"Запрос на оплату"| ПС
    ПС -->|"Результат оплаты"| P3
    P3 -->|"Статус оплаты"| D2
    P3 -->|"Результат оплаты"| P2
    D2 -->|"Данные заказа"| P2
    P2 -->|"Заказ на доставку"| P4
    D2 -->|"Данные заказа"| P4
    P4 -->|"Заказ на доставку"| Склад
    Склад -->|"Подтверждение отгрузки"| P4
    P4 -->|"Статус отгрузки"| D2
    P2 -->|"Уведомление о статусе"| Клиент

Матрица балансировки контекст → уровень 1:

Поток (контекст)НаправлениеГде появляется на L1
ЗаказКлиент → системаP1 (вход)
Счёт на оплатусистема → КлиентP2 → Клиент
Запрос на оплатусистема → ПСP2 → P3 → ПС
Результат оплатыПС → системаПС → P3 → P2
Заказ на доставкусистема → СкладP2 → P4 → Склад
Подтверждение отгрузкиСклад → системаСклад → P4
Уведомление о статусесистема → КлиентP2 → Клиент

Внутренний путь P2 → P3 → ПС сохраняет то же имя «Запрос на оплату» на границе с ПС — допустимый explosion: один контекстный поток проходит через цепочку процессов. Запись «Статус оплаты» в D2 — внутренняя детализация; на границе системы по-прежнему только «Результат оплаты» от ПС.

Пример: уровень 2 и спецификация процесса

Процесс 2 «Оформить заказ» на L2 раскрывается, например, на 2.1 «Сформировать счёт» и 2.2 «Зафиксировать заказ». Вход родителя «Проверенный заказ» на L2 становится входом 2.2; «Счёт на оплату» — выход 2.1.

flowchart TD
    subgraph "Процесс 2 — Оформить заказ"
        P21["2.1 Сформировать счёт"]
        P22["2.2 Зафиксировать заказ"]
        D2[("D2 База заказов")]
    end
    P21 -->|"Счёт на оплату"| OUT1((к P3 / Клиент))
    IN1(("Проверенный заказ")) --> P22
    P22 -->|"Запись заказа"| D2
    IN1 --> P21
    P21 -->|"Данные для счёта"| P22

Мини-спецификация процесса 2.2 (фрагмент):

ПолеСодержание
ВходыПроверенный заказ, Данные для счёта
ВыходыЗапись заказа → D2
ЛогикаСоздать запись заказа со статусом «Ожидает оплаты»; присвоить номер; связать с резервом из D1
Связь с FRFR-012 «Оформление заказа»

Так декомпозиция не обрывается на L1: номер процесса ведёт в матрицу трассировки, спецификация — в текст SRS.

Логический → физический поток (фрагмент)

На одном участке e-commerce-модели:

УровеньУчастникПоток
ЛогическийP3 → ПСЗапрос на оплату
ФизическийСервис payment-adapter → gateway.example.comPOST /v1/charges (OpenAPI, JSON)
Физический (событийный вариант)order-service → брокерСообщение PaymentRequested (AsyncAPI)

Физическая DFD не заменяет контракт — она показывает, какой логический поток где реализован; детали полей — в спецификации и физической модели данных.

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

  1. Выписать все входящие и исходящие потоки родительского процесса.
  2. Для каждого потока найти на дочерней диаграмме процесс-источник и процесс/сущность-приёмник с тем же именем (или зафиксировать соответствие в словаре данных).
  3. Убедиться, что на границе системы не появилось новых потоков и не исчезло старых.
  4. Проверить, что каждый внутренний поток между процессами не «пробивает» границу родителя без необходимости.
  5. Сверить explosion/implosion: сумма составных потоков = родительский пакет.
  6. Подписать каждый поток, включая чтение и запись в хранилища; безымянное ребро к D — типичная ошибка новичков.
  7. При расхождении имён — либо переименовать, либо добавить примечание «= поток X контекста».

Правила построения

  1. Две внешние сущности не соединяются напрямую — только через систему.
  2. Два хранилища не соединяются напрямую — нужен процесс-посредник.
  3. Процесс преобразует данные: минимум один вход и один выход. Вход может идти от сущности, процесса или хранилища (чтение); выход — к сущности, процессу или хранилищу (запись). Процесс «только читает из D1 и никуда не пишет» — чёрная дыра; «только пишет в D2 без входа» — мираж.
  4. Ветвление потока допустимо, если одни и те же данные идут в несколько приёмников. Если ветви несут разную информацию или разные правила — добавьте процесс «Маршрутизировать / Распределить данные» или продублируйте подписи с уточнением в словаре данных.
  5. Имена уникальны на диаграмме (внешние сущности могут дублироваться для компоновки — помечайте *).
  6. Балансировка уровней — см. чеклист выше.
  7. Нумерация: процессы — иерархически (0, 1, 2, 2.1…); хранилища — префикс D и порядковый номер (D1, D2) или имя без иерархического номера процесса. Не смешивайте схемы.

Нумерация и трассировка

  • Контекст: процесс 0.
  • Уровень 1: 1, 2, 3…
  • Детализация процесса 2: 2.1, 2.2…

Номер процесса связывайте с функциональным требованием в матрице трассировки (шаблон — 10.01.15 Шаблон матрицы трассировки). Пример строки: FR-012 «Оформление заказа» → процесс 2 на DFD L1 → спецификация 2.2.

Сравнение с соседними нотациями

АспектDFDBPMNIDEF0Use CaseActivity Diagram
ФокусПотоки данных, преобразование информацииПоток работ, роли, событияФункции, ICOMАкторы и цели, сценарии взаимодействияПоток управления, параллелизм
ВремяНе показываетПоказываетНе показываетНе показываетПоказывает
Граница / акторыВнешние сущности, потоки через границуПулы, дорожки, сообщенияВходы/выходы на границе блокаАктор ↔ система, без внутренних потоковДорожки исполнителей
Типичное применение SAИнформационная архитектура, интеграцииБизнес-процессы as-is/to-beФункциональная декомпозицияScope и инициация сценариевРеализация use case

DFD часто — первый шаг после границ системы; BPMN — детализация потока работ; IDEF0 — см. 03.04.03 IDEF0 и его применение; Use Case — диаграмма прецедентов («кто инициирует»), DFD — «какие данные куда текут» внутри выбранного сценария.

Инструменты

Для DFD используйте draw.io, Lucidchart, Sparx EA, Visio или текстовые PlantUML/Mermaid — сравнение возможностей, Git и корпоративные стандарты: 07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io).

ИИ как вспомогательный инструмент

LLM могут ускорить черновик DFD из текста требований или проверку очевидных «чёрных дыр», но модель нужно верифицировать вручную — техниками V&V. Практики промптов и кейсы — 11.03 Промпт-инжиниринг для аналитика и 11.07 Практические кейсы применения LLM в анализе.

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

  • Смешение потоков управления и данных — «сигнал», «запуск»; для управления — BPMN или диаграмма состояний.
  • Чёрная дыра и мираж — процесс без выхода или без входа (см. правило 3).
  • Безымянные потоки — особенно при чтении/записи в хранилище; каждое ребро подписывается существительным.
  • Хранилище ↔ хранилище без процесса.
  • Потеря балансировки при декомпозиции — новые потоки «ниоткуда».
  • Имена потоков как глаголы — «Передать заказ» вместо «Заказ».
  • Неверное направление к хранилищу: чтение — из store в процесс, запись — из процесса в store.
  • Дублирование одной внешней сущности на листе без пометки * — читатель не поймёт, что это один и тот же актор.
  • Избыточная детализация на L0 — один процесс; эвристика 3–7 внешних сущностей — не норма BABOK, а правило читаемости (дубликаты с * считаются как одна).
  • Ветвление без логики — скрытые бизнес-правила (см. правило 4).
  • Оплата или статус «в памяти процесса» без записи в хранилище — при рестарте или параллельных сценариях модель расходится с реальностью.
  • Попытка показать real-time event stream классической DFD без перехода к физической модели и AsyncAPI.

Готовую DFD вкладывают в BRD/SRS как иллюстрацию информационной архитектуры раздела.

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

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

Первоисточники по DFD преимущественно на английском; ниже — классика, стандарты и русскоязычные обзоры.

Книги и стандарты

Статьи и справочники