1. Введение в диаграммы потоков данных
Диаграмма потоков данных (DFD) — это графическое представление того, как данные перемещаются через информационную систему. Она показывает:
- Откуда данные приходят и куда они направляются
- Как обрабатываются данные
- Где хранятся данные
- Кто или что взаимодействует с системой

2. Ключевые понятия
Основные элементы
| Элемент | Символ | Назначение |
|---|---|---|
| Внешняя сущность | Прямоугольник | Человек, организация или система, отправляющая/получающая данные |
| Процесс | Круг/Эллипс | Преобразует входящие данные в исходящие данные |
| Хранилище данных | Открытый прямоугольник | Хранилище для постоянного хранения данных |
| Поток данных | Стрелка | Показывает направление перемещения данных |
Уровни ДФП
- Схема контекста (уровень 0): Наивысший уровень, показывает границы системы и основные внешние сущности
- Уровень 1: Разбивает основной процесс на основные подпроцессы
- Уровень 2+: Дальнейшее разбиение, показывающее детальные процессы
3. Логические и физические ДФП
Логическая ДФП

А логическая ДФП (также называемая «основной моделью») фокусируется на:
- ЧТО что делает система
- Бизнес-деятельность и информационные потребности
- Независимо от технологии реализации
Характеристики:
- Показывает бизнес-операции и процессы
- Нет деталей, специфичных для технологии
- Более абстрактные и ориентированные на пользователя
- Помогает понять бизнес-требования
Физическая СДФ

А физическая СДФ (также называемая «модель реализации») фокусируется на:
- КАК система будет реализована
- Технические детали и ограничения
- Конкретные технологии и системы
Характеристики:
- Показывает реальное оборудование, программное обеспечение и людей
- Включает детали реализации
- Более конкретные и ориентированные на разработчика
- Помогает при проектировании и развертывании системы
Таблица сравнения
| Аспект | Логическая схема потока данных | Физическая схема потока данных |
|---|---|---|
| Фокус | Бизнес-потребности | Реализация |
| Кто | Бизнес-аналитики, пользователи | Проектировщики систем, разработчики |
| Уровень | Высокий уровень, абстрактный | Детализированный, конкретный |
| Компоненты | Бизнес-процессы | Технические процессы |
| Хранилища данных | Концептуальные сущности | Физические файлы/базы данных |
| Сущности | Бизнес-роли | Фактические системы/устройства |
4. Компоненты DFD

Внешние сущности
- Источники и пункты назначения данных
- За пределами границы системы
- Обозначаются существительными
Процессы
- Преобразуют данные с входа на выход
- Обозначаются глагол + существительное
- Нумеруются для идентификации
Хранилища данных
- Постоянные хранилища данных
- Обозначаются существительными
- Нумерация D1, D2, D3…
Потоки данных
- Показывают движение данных
- Обозначаются описательными метками
- Направление указывает на поток
5. Рабочие примеры с Graphviz
Пример 1: Система управления отелем (логическая DFD)

digraph HotelMIS_DFD_Logical {
// --- СТИЛЬ ГРАФА ---
graph [
rankdir = LR
splines = true
overlap = false
nodesep = 0.6
ranksep = 1.0
fontname = "Helvetica,Arial,sans-serif"
fontsize = 12
]
// --- СТИЛЬ УЗЛОВ ---
node [
fontname = "Helvetica,Arial,sans-serif"
fontsize = 11
penwidth = 1.5
]
// Внешние сущности
node [shape = box, style = "filled", fillcolor = "#E1F5FE", color = "#0288D1"]
Гость;
Персонал;
// --- ГРАНИЦА СИСТЕМЫ ---
subgraph cluster_SystemBoundary {
label = "Граница системы Hotel MIS";
fontname = "Helvetica,Arial,sans-serif";
fontcolor = "#757575";
fontsize = 14;
color = "#757575";
style = "dashed,rounded";
bgcolor = "#FAFAFA";
margin = 20;
// Процессы
node [shape = circle, style = "filled", fillcolor = "#E8F5E9", color = "#388E3C", fixedsize = true, width = 1.3]
P1 [label="1.0nУправлениеnБронированиями"];
P2 [label="2.0nРегистрация/nВыезд"];
P3 [label="3.0nУправлениеnИнвентарём"];
// Хранилища данных
node [shape = record, style = "filled", fillcolor = "#FFF9C4", color = "#FBC02D", fixedsize = false]
ReservationsDS [label="{ <id> D1 | База данныхnБронирований }"];
RoomsDS [label="{ <id> D2 | База данныхnСтатуса номеров }"];
InventoryDS [label="{ <id> D3 | База данныхnИнвентаря }"];
}
// --- СТИЛЬ РЕБЕР ---
edge [
fontname = "Helvetica,Arial,sans-serif"
fontsize = 9
color = "#555555"
arrowsize = 0.8
]
// --- ПОТОКИ ДАННЫХ ---
// Взаимодействия гостя
Гость -> P1 [label="Запрос бронирования"];
P1 -> Гость [label="Подтверждение"];
Гость -> P2 [label="Прибытие"];
P2 -> Гость [label="Ключ от номера/Квитанция"];
// Взаимодействия персонала
Персонал -> P3 [label="Обновление инвентаря"];
P3 -> Персонал [label="Оповещения/Отчёты"];
// Процесс к хранилищу данных
P1 -> ReservationsDS [label="Новое бронирование"];
ReservationsDS -> P1 [label="Проверка доступности"];
P1 -> RoomsDS [label="Запрос данных о номере"];
RoomsDS -> P1 [label="Доступные номера"];
P2 -> RoomsDS [label="Обновление статуса номера"];
RoomsDS -> P2 [label="Информация о номере"];
P2 -> P3 [label="Данные о пребывании"];
P3 -> InventoryDS [label="Обновление запасов"];
InventoryDS -> P3 [label="Уровень запасов"];
}
Пример 2: Логическая СХД – Система управления библиотекой

digraph LibrarySystem_Logical {
// --- СТИЛЬ ГРАФА ---
graph [
rankdir = TB
splines = true
nodesep = 0.5
ranksep = 0.8
fontname = "Helvetica,Arial,sans-serif"
fontsize = 12
]
// --- СТИЛЬ УЗЛОВ ---
node [
fontname = "Helvetica,Arial,sans-serif"
fontsize = 11
penwidth = 1.5
]
// Внешние сущности
node [shape = box, style = "filled", fillcolor = "#E1F5FE", color = "#0288D1"]
Член;
Библиотекарь;
// --- ГРАНИЦА СИСТЕМЫ ---
subgraph cluster_LibrarySystem {
label = "Система библиотеки (логическая)";
style = "dashed,rounded";
color = "#757575";
bgcolor = "#FAFAFA";
margin = 20;
// Процессы
node [shape = circle, style = "filled", fillcolor = "#E8F5E9", color = "#388E3C", width = 1.4]
P1 [label="1.0nУправлениеnКаталогом"];
P2 [label="2.0nОбработкаnЗайма"];
P3 [label="3.0nОбработкаnВозврата"];
// Хранилища данных
node [shape = record, style = "filled", fillcolor = "#FFF9C4", color = "#FBC02D"]
CatalogDS [label="{ <id> D1 | КаталогnКниг }"];
TransactionsDS [label="{ <id> D2 | ЗаписиnЗаймов }"];
MemberDS [label="{ <id> D3 | База данныхnЧленов }"];
}
// --- СТИЛЬ РЕБЕР ---
edge [
fontname = "Helvetica,Arial,sans-serif"
fontsize = 9
color = "#555555"
arrowsize = 0.8
]
// --- ПОТОКИ ДАННЫХ ---
// Взаимодействия члена
Член -> P1 [label="Поиск книг"];
P1 -> Член [label="Результаты поиска"];
Член -> P2 [label="Запрос займа"];
P2 -> Член [label="Подтверждение займа"];
Член -> P3 [label="Возврат книг"];
P3 -> Член [label="Квитанция о возврате"];
// Взаимодействия библиотекаря
Библиотекарь -> P1 [label="Добавить/обновить книги"];
P1 -> Библиотекарь [label="Подтверждение обновления каталога"];
Библиотекарь -> P3 [label="Обработка просроченных"];
P3 -> Библиотекарь [label="Отчёт о просроченных"];
// Потоки данных
P1 -> CatalogDS [label="Обновление книг"];
CatalogDS -> P1 [label="Данные каталога"];
P2 -> CatalogDS [label="Проверка доступности"];
CatalogDS -> P2 [label="Статус книги"];
P2 -> MemberDS [label="Проверка статуса члена"];
MemberDS -> P2 [label="Информация о члене"];
P2 -> TransactionsDS [label="Создать запись займа"];
TransactionsDS -> P2 [label="История займов"];
P3 -> TransactionsDS [label="Обновить возврат"];
TransactionsDS -> P3 [label="Записи о займах"];
P3 -> MemberDS [label="Обновить статус члена"];
MemberDS -> P3 [label="Информация о члене"];
}
Пример 3: Физическая СХД – Система управления библиотекой

digraph LibrarySystem_Physical {
// --- СТИЛЬ ГРАФА ---
graph [
rankdir = TB
splines = true
nodesep = 0.5
ranksep = 0.8
fontname = "Helvetica,Arial,sans-serif"
fontsize = 12
]
// --- СТИЛЬ УЗЛОВ ---
node [
fontname = "Helvetica,Arial,sans-serif"
fontsize = 11
penwidth = 1.5
]
// Внешние сущности (физические)
node [shape = box, style = "filled", fillcolor = "#E1F5FE", color = "#0288D1"]
"Член библиотеки" [label="БиблиотекаnЧлен"];
"Библиотекарь" [label="ПерсоналnБиблиотеки"];
"Система электронной почты" [label="Система электроннойnпочты"];
"Платежный шлюз" [label="Платежныйnшлюз"];
// --- ГРАНИЦА СИСТЕМЫ ---
subgraph cluster_LibrarySystem_Physical {
label = "Система управления библиотекой (физическая реализация)";
style = "dashed,rounded";
color = "#757575";
bgcolor = "#FAFAFA";
margin = 20;
// Физические процессы (с деталями технологии)
node [shape = circle, style = "filled", fillcolor = "#E8F5E9", color = "#388E3C", width = 1.4]
P1 [label="1.0nВеб-каталогn(HTML, JS)"];
P2 [label="2.0nAPI займаn(Python/REST)"];
P3 [label="3.0nОбработчик возвратаn(Java)"];
// Физические хранилища данных (с деталями технологии)
node [shape = record, style = "filled", fillcolor = "#FFF9C4", color = "#FBC02D"]
CatalogDS [label="{ <id> D1 | PostgreSQLnКаталог книг }"];
TransactionsDS [label="{ <id> D2 | MongoDBnЗаписи займа }"];
MemberDS [label="{ <id> D3 | OraclenБаза данных членов }"];
// Дополнительные физические компоненты
node [shape = box, style = "filled", fillcolor = "#F3E5F5", color = "#8E24AA"]
"Сервер кэширования" [label="RedisnКэш"];
"Очередь сообщений" [label="RabbitMQnОчередь"];
}
// --- СТИЛЬ РЕБЕР ---
edge [
fontname = "Helvetica,Arial,sans-serif"
fontsize = 9
color = "#555555"
arrowsize = 0.8
]
// --- ПОТОКИ ДАННЫХ (физические) ---
// Физические взаимодействия члена
"Член библиотеки" -> P1 [label="HTTP GETnПоиск книг"];
P1 -> "Член библиотеки" [label="HTML/JSONnРезультаты"];
"Член библиотеки" -> P2 [label="REST APInЗапрос займа"];
P2 -> "Член библиотеки" [label="JSONnПодтверждение"];
"Член библиотеки" -> P3 [label="REST APInВозврат"];
P3 -> "Член библиотеки" [label="JSONnКвитанция"];
// Физические взаимодействия библиотекаря
"Библиотекарь" -> P1 [label="HTTPSnУправление каталогом"];
P1 -> "Библиотекарь" [label="HTMLnПодтверждение"];
"Библиотекарь" -> P3 [label="REST APInОбработка просроченных"];
P3 -> "Библиотекарь" [label="PDF-отчёт"];
// Взаимодействия с внешними системами
P2 -> "Система электронной почты" [label="SMTPnУведомление"];
P3 -> "Платежный шлюз" [label="HTTPSnОплата штрафа"];
// Потоки данных (физические)
P1 -> CatalogDS [label="SQL UPDATE"];
CatalogDS -> P1 [label="SQL SELECT"];
P1 -> "Сервер кэширования" [label="Обновление кэша"];
"Сервер кэширования" -> P1 [label="Соответствие кэша"];
P2 -> CatalogDS [label="SQL SELECT"];
CatalogDS -> P2 [label="SQL Результат"];
P2 -> MemberDS [label="SQL SELECT"];
MemberDS -> P2 [label="SQL Результат"];
P2 -> TransactionsDS [label="INSERT"];
TransactionsDS -> P2 [label="SELECT"];
P2 -> "Очередь сообщений" [label="Опубликовать событие займа"];
P3 -> TransactionsDS [label="UPDATE"];
TransactionsDS -> P3 [label="SELECT"];
P3 -> MemberDS [label="UPDATE"];
MemberDS -> P3 [label="SELECT"];
P3 -> "Очередь сообщений" [label="Опубликовать событие возврата"];
}
Пример 4: Обработка заказов в электронной коммерции (логическая СПД)

digraph ECommerce_Logical {
// --- СТИЛЬ ГРАФА ---
graph [
rankdir = LR
splines = true
nodesep = 0.5
ranksep = 0.8
fontname = "Helvetica,Arial,sans-serif"
fontsize = 12
]
// --- СТИЛЬ УЗЛОВ ---
node [
fontname = "Helvetica,Arial,sans-serif"
fontsize = 11
penwidth = 1.5
]
// Внешние сущности
node [shape = box, style = "filled", fillcolor = "#E1F5FE", color = "#0288D1"]
Customer;
Supplier;
"Payment Processor" [label="PaymentnProcessor"];
// --- ГРАНИЦА СИСТЕМЫ ---
subgraph cluster_ECommerce {
label = "Система электронной коммерции (логическая)";
style = "dashed,rounded";
color = "#757575";
bgcolor = "#FAFAFA";
margin = 20;
// Процессы
node [shape = circle, style = "filled", fillcolor = "#E8F5E9", color = "#388E3C", width = 1.4]
P1 [label="1.0nОбработкаnзаказа"];
P2 [label="2.0nУправлениеnинвентарём"];
P3 [label="3.0nОбработкаnотправки"];
// Хранилища данных
node [shape = record, style = "filled", fillcolor = "#FFF9C4", color = "#FBC02D"]
OrderDS [label="{ <id> D1 | Заказы }"];
InventoryDS [label="{ <id> D2 | Инвентарь }"];
ShipmentDS [label="{ <id> D3 | Отправки }"];
}
// --- СТИЛЬ РЕБЕР ---
edge [
fontname = "Helvetica,Arial,sans-serif"
fontsize = 9
color = "#555555"
arrowsize = 0.8
]
// --- ПОТОКИ ДАННЫХ ---
// Взаимодействия с клиентом
Customer -> P1 [label="Детали заказа"];
P1 -> Customer [label="Подтверждение заказа"];
Customer -> P3 [label="Отслеживание заказа"];
P3 -> Customer [label="Информация о трекинге"];
// Платежный процессор
"Payment Processor" -> P1 [label="Ответ платежа"];
P1 -> "Payment Processor" [label="Запрос платежа"];
// Поставщик
Supplier -> P2 [label="Обновление запасов"];
P2 -> Supplier [label="Запрос на повторный заказ"];
// Потоки данных процессов
P1 -> OrderDS [label="Сохранить заказ"];
OrderDS -> P1 [label="История заказов"];
P1 -> InventoryDS [label="Проверить наличие"];
InventoryDS -> P1 [label="Доступность"];
P1 -> P3 [label="Детали отправки"];
P2 -> InventoryDS [label="Обновить запасы"];
InventoryDS -> P2 [label="Текущие запасы"];
P3 -> OrderDS [label="Обновить статус"];
OrderDS -> P3 [label="Информация о заказе"];
P3 -> ShipmentDS [label="Создать отправку"];
ShipmentDS -> P3 [label="Детали отправки"];
}
6. Лучшие практики
Для логических СПД
- Сосредоточьтесь на бизнес-процессах, а не на технологии
- Используйте бизнес-терминологиюкоторую понимают заинтересованные стороны
- Сохраняйте процессы на одном уровне абстракции
- Проверяйте с бизнес-пользователямина точность
- Покажите все основные потоки данныхмежду компонентами
Для физических DFD
- Включите детали, специфичные для технологии
- Учитывайте производительность и масштабируемость
- Документируйте системные интерфейсычетко
- Включите обработку ошибоки процессы восстановления
- Согласуйте с фактической архитектурой системы
Общие лучшие практики
- Начните с диаграммы контекста
- Нумеруйте процессы иерархически
- Используйте значимые именадля всех компонентов
- Избегайте пересечения потоков данных
- Регулярно проверяйте с заинтересованными сторонами
7. Распространенные ошибки

Ошибки 1: Смешивание логического и физического
❌ Неправильно:Добавление названий технологий баз данных в логическую схему потоков данных
✅ Верно: Сохраняйте логическую схему потоков данных независимой от технологии
Опасность 2: Отсутствующие потоки данных
❌ Неверно: Показ только одного направления между сущностями
✅ Верно: Включайте двунаправленные потоки, где это уместно
Опасность 3: Избыточная сложность
❌ Неверно: Размещение более чем 20 процессов на одной схеме
✅ Верно: Разбивайте на несколько узконаправленных схем
Опасность 4: Неправильная маркировка потоков данных
❌ Неправильно: «Данные» как метка
✅ Правильно: Описательные метки, такие как «Сведения о заказе клиента»
Опасность 5: Неправильные границы процессов
❌ Неправильно: Один процесс, выполняющий несколько нерелевантных функций
✅ Правильно: Отдельные процессы для различных функций
Заключение
Диаграммы потоков данных являются необходимыми инструментами для анализа и проектирования систем. Понимание различий между логическими и физическими диаграммами потоков данных помогает вам эффективно взаимодействовать с различными заинтересованными сторонами на разных этапах жизненного цикла разработки программного обеспечения.
- Логические диаграммы потоков данных связывают бизнес-требования и технические решения
- Физические диаграммы потоков данных направляют решения по реализации и развертыванию
Используйте приведенные примеры в качестве шаблонов для своих диаграмм потоков данных, адаптируя их под конкретные требования вашей системы, при этом соблюдая лучшие практики, изложенные выше.
Дополнительные ресурсы
- Генератор диаграмм потоков данных Гейна и Сарсона с помощью ИИ от Visual Paradigm: Объясняет, как инструменты ИИ Visual Paradigm могут генерировать диаграммы потоков данных Гейна и Сарсона на основе текстовых описаний.
- Пошаговое руководство по созданию диаграмм потоков данных с помощью Visual Paradigm: Предоставляет руководство по созданию диаграмм потоков данных с помощью онлайн-инструмента Visual Paradigm, от регистрации до обмена.
- Как создать диаграмму потоков данных (DFD)?: Руководство, охватывающее, что такое DFD, его цель и основные типы (физический и логический).
- Руководство для начинающих по созданию диаграмм потоков данных по методологии SSADM с помощью Visual Paradigm Online: Вводное руководство по созданию диаграмм потоков данных по стилю SSADM с использованием Visual Paradigm Online.
- Полное руководство по диаграммам потоков данных (DFD): раскрытие принципов потока информации: Обзор диаграмм потоков данных, с детализацией их элементов и объяснением, почему Visual Paradigm — подходящий инструмент для их создания.
- Освоение диаграмм потоков данных с помощью Visual Paradigm: пошаговое руководство: Практическое руководство, использующее примеры и шаблоны для обучения созданию DFD, включая кейсы, такие как системы онлайн-покупок.
- Понимание логических DFD и физических DFD: когда и зачем нам их нужно: Объясняет различия, цели и подходящие случаи использования логических и физических диаграмм потоков данных.
- Руководство для начинающих по созданию диаграмм потоков данных (DFD) с помощью Visual Paradigm Online: Удобное для новичков руководство, которое проходит по шагам создания DFD с помощью Visual Paradigm Online.
- Архив DFD — руководства Visual Paradigm: Сборник статей по темам DFD, включая генераторы на основе ИИ, валидацию, балансировку и уровни.
- Руководство по началу работы с диаграммами потоков данных (DFD) с помощью Visual Paradigm Online: Подробно описывает пошаговый процесс создания DFD, включая ключевые компоненты и способы использования шаблонов.
- Нарисуйте DFD с лучшим инструментом DFD: Обсуждает графическое представление потоков данных, детально описывает логические и физические DFD, а также исследует преимущества каждого типа.
-
Руководство для начинающих по диаграммам потоков данных (DFD) с помощью Visual Paradigm Online: Руководство для начинающих на индонезийском языке по DFD, описывающее компоненты и пошаговый процесс создания в Visual Paradigm Online.
Это руководство предоставляет основу для создания эффективных DFD. Помните, что хорошие диаграммы развиваются за счет итераций и обратной связи заинтересованных сторон.
Эта статья также доступна на Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Việt Nam, 简体中文 and 繁體中文












