Диаграмма потоков данных (DFD) — схема, которая показывает, где информация застревает, дублируется или исчезает в никуда. Со стороны такая схема может казаться архаикой — зачем рисовать стрелочки, если можно сразу писать код? Ответ прост: исправлять проблемы в уже написанном коде дороже, чем на этапе проектирования.

В статье собрали основу про DFD для тех, кто с ней не сталкивался: зачем ее используют и как изображают.

Что такое диаграмма потоков данных

Диаграмма потоков данных (Data Flow Diagram, DFD) — это схема работы системы, которая наглядно показывает, откуда поступает информация, как она обрабатывается, где хранится и кому передается. Правильно построенная диаграмма улучшает понимание логики системы и снижает риск ошибок при разработке.

При построении диаграммы используют несколько элементов:

Внешние источники и приемники данных. Объекты или системы за пределами процесса, которые либо поставляют информацию, либо получают результаты. Например, клиент, поставщик, сторонний сервис, госорган.

Процессы. Блоки, в которых происходит преобразование или анализ данных. Например, блоки «Проверить платеж» или «Сформировать отчет». Также в них могут указывать название систем, которые выполняют процесс.

Хранилища. Базы данных, таблицы, файлы, реестры и другие сущности, где временно или навсегда сохраняют информацию.

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

Рассмотрим на упрощенном примере бронирования книги в библиотеке: читатель оставляет заявку на бронь, после чего система сверяет данные о наличии книги и передает уведомление о заказе библиотекарю. Как это будет выглядеть на схеме:

В этом примере:

• Внешние сущности — читатель, который отправляет запрос, и библиотекарь.

• Потоки данных — запрос на бронирование, результат запроса, уведомление о заказе, статус брони, название книги и данные о ее наличии.

• Хранилище данных — каталог книг.

• Процессы — обработка бронирования.

Схема показывает ключевые компоненты и их взаимосвязи. Это помогает понять, кто участвует в процессе, какие данные передаются и где они хранятся.

Для чего строят диаграмму

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

• Разработка ПО — позволяет проектировать взаимодействие модулей системы, упрощая понимание логики передачи данных.

• Оптимизация документооборота — показывает движение документов в организации, выявляя задержки и дублирование процессов.

• Анализ бизнес-процессов — визуализирует  потоки информации между отделами, выявляя узкие места и избыточные операции.

• Автоматизация процессов — выявляет точки интеграции IT-систем, помогая спланировать передачу информации между ними.

Нотации Data Flow Diagram

Нотация — набор графических элементов, из которых строят диаграмму. У DFD есть две распространенные нотации: первая — Йордана и Де Марко, вторая — Гейна и Сарсона. Обе нотации решают одинаковые задачи, а их принцип ничем не отличается друг от друга. Различие лишь в визуальных обозначениях. Рассмотрим подробнее:

Требования использовать определенную нотацию нет. Главное, чтобы все участники с доступом к диаграмме понимали указанные обозначения.

Какие есть уровни DFD

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

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

Уровень 1. Происходит декомпозиция главного процесса из Уровня 0. Появляются основные подпроцессы, которые нумеруют в иерархическом порядке: 1.1, 1.2, 1.3 и т.д.

Уровень 2. На этом этапе детализируют конкретный процесс с Уровня 1. Принцип нумерации сохраняется и связан с подпроцессом, который детализируют. То есть если детализируют процесс 1.1, то на диаграмме второго уровня будут процессы 1.1.1.,1.1.2., 1.1.3. и т.д.

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

Принципы построения диаграммы

Чтобы схема правильно отражала процесс, нужно учесть некоторые особенности:

1. У всех процессов процесс должно быть не меньше одного входа и одного выхода. Если у процесса нет входа, значит, он  передает данные из ниоткуда, что маловероятно. А если нет выхода, то получается, что данные исчезают, чего тоже не должно быть.

2. Каждое хранилище должно быть связано с процессом, который либо записывает, либо обрабатывает данные. Данные не должны просто лежать — они должны быть кем-то использованы, иначе неизвестно, зачем их хранить.

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

Где построить DFD

Несколько сервисов, которые доступны в России и в которых можно изобразить схему:

• PlantUML — бесплатное open-code-решение для создания диаграмм через редактор кода.

• Mermaid — еще один бесплатный сервис с открытым исходным кодом и онлайн-редактором кода.

• Diagram — бесплатный сервис для создания mind map.

Почему DFD не всегда подходит для управления бизнес-процессами

DFD напоминает схему бизнес-процесса, но диаграмма фокусируется именно на движении данных, а не на логике выполнения задач. Из-за этого для полноты картины на схеме не хватает:

• Ответственных и ролей — DFD не показывает, кто, человек или система, выполняет процесс. Управление требует назначения ответственности.

• Состояний процесса — DFD не фиксирует состояние объекта по типу «заказ в обработке», «заказ отправлен» или «сообщение отправлено». При управлении процессами отслеживает именно смену состояний.

Для управления бизнес-процессами нужны системы нотации, которые показывают последовательность, логику, время, ответственных и состояния — например, стандарт BPMN (Business Process Model and Notation). DFD же остается подходящим инструментом для анализа информационных потоков в системе.

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

Data Flow Diagram: кратко

• DFD — схема, которая показывает движение данных в системе: их источники, обработку, хранение и передачу. Диаграмму строят из внешних сущностей, процессов, хранилищ и связей между ними.

• DFD помогает проектировать ПО, оптимизировать документооборот, анализировать процессы и планировать автоматизацию. С помощью схемы в доступном виде визуализируют потоки данных, чтобы выявить узкие места и избыточные операции.

• Существуют две основные нотации: Йордана–Де Марко (прямоугольники, круги, открытые хранилища) и Гейна–Сарсона (тени, круги, двойные линии для хранилищ). Разница только в обозначениях, суть элементов одинакова.

• DFD не показывает ответственных, состояния объектов или логику выполнения задач, поэтому для визуализации и управления процессами лучше подходят BPM-системы, а для гибкого контроля выполнения задач системы вроде Kaiten.