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

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

История и развитие

Методология построения диаграмм потоков данных возникла в конце 1960-х — начале 1970-х годов как часть подхода к структурному анализу. Основоположниками считаются Ларри Константин, Эдвард Йордон и Том ДеМарко, которые в 1970-х годах формализовали нотацию DFD. Параллельно развивались другие нотации, в частности, метод Гейна — Сарсона (Chris Gane и Trish Sarson), который получил широкое распространение в 1980-х годах. В 1990-е годы DFD активно использовались в рамках методологий структурного анализа (например, в методологии Йордона/ДеМарко) и в некоторых CASE-средствах (Computer-Aided Software Engineering). С развитием объектно-ориентированного подхода и UML (Unified Modeling Language) популярность DFD несколько снизилась, однако они остаются востребованными для документирования бизнес-процессов, анализа требований к системам и в некоторых областях, таких как проектирование баз данных и разработка встроенных систем.

Основные элементы и нотации

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

1. Внешние сущности (External Entities)

Внешние сущности представляют собой источники или получатели данных, находящиеся за пределами рассматриваемой системы. Они не являются частью системы, но взаимодействуют с ней. Примерами могут служить пользователи, другие информационные системы, внешние организации или датчики. В нотации Йордона/ДеМарко внешние сущности обозначаются прямоугольником, в нотации Гейна — Сарсона — квадратом с закруглёнными углами.

2. Процессы (Processes)

Процессы — это преобразователи данных. Они принимают входные данные, выполняют определённые операции и выдают выходные данные. Каждый процесс должен иметь уникальное имя (обычно глагол или глагольная фраза, например «Проверить заказ», «Рассчитать налог») и номер для идентификации. В нотации Йордона/ДеМарко процесс изображается в виде круга или овала, в нотации Гейна — Сарсона — в виде прямоугольника с закруглёнными углами.

3. Хранилища данных (Data Stores)

Хранилища данных — это места, где данные сохраняются для последующего использования. Они могут представлять собой базы данных, файлы, таблицы или любые другие формы хранения. Хранилища данных обычно обозначаются двумя параллельными линиями (в нотации Йордона/ДеМарко) или прямоугольником с открытым правым краем (в нотации Гейна — Сарсона). Имя хранилища должно быть существительным, например «Заказы клиентов», «Складские запасы».

4. Потоки данных (Data Flows)

Потоки данных — это стрелки, показывающие перемещение данных между элементами диаграммы. Они указывают направление передачи информации. Каждый поток данных должен быть подписан именем, описывающим передаваемые данные (например, «Данные заказа», «Подтверждение оплаты»). Потоки данных могут быть однонаправленными или двунаправленными, но в классических нотациях двунаправленные потоки обычно не используются — вместо них применяются два отдельных потока.

Основные нотации

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

• Нотация Йордона/ДеМарко (Yourdon/DeMarco): Процессы — круги; внешние сущности — прямоугольники; хранилища данных — две параллельные линии; потоки данных — стрелки.
• Нотация Гейна — Сарсона (Gane/Sarson): Процессы — прямоугольники с закруглёнными углами; внешние сущности — квадраты с закруглёнными углами; хранилища данных — прямоугольники с открытым правым краем; потоки данных — стрелки.
• Нотация SSADM (Structured Systems Analysis and Design Method): Используется в британской методологии, близка к нотации Гейна — Сарсона, но имеет свои особенности в обозначении хранилищ и процессов.

Уровни детализации (контекстные диаграммы)

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

• Контекстная диаграмма (уровень 0): Представляет систему как единый процесс, показывая только внешние сущности и потоки данных между ними и системой. Это самый общий взгляд на систему.
• Диаграмма уровня 1: Детализирует контекстную диаграмму, разбивая единственный процесс на несколько подпроцессов. Показываются также хранилища данных и потоки между ними.
• Диаграмма уровня 2 и ниже: Каждый подпроцесс с уровня 1 может быть далее детализирован на отдельной диаграмме. Глубина детализации определяется сложностью системы и целями моделирования. Обычно рекомендуется не углубляться более чем на 3-4 уровня, чтобы не потерять наглядность.

Применение

Диаграммы потоков данных находят применение в различных областях:

• Разработка программного обеспечения: Для анализа требований, проектирования архитектуры, документирования функциональных спецификаций.
• Бизнес-моделирование: Для описания бизнес-процессов, выявления узких мест, оптимизации потоков информации.
• Проектирование баз данных: Для определения логической структуры данных и их взаимосвязей.
• Анализ информационных систем: Для понимания существующей системы, выявления избыточных или недостающих потоков данных.
• Обучение и документация: Для наглядного представления работы системы заказчикам, разработчикам и другим заинтересованным сторонам.

Преимущества и недостатки

Преимущества

• Наглядность: DFD позволяют легко понять общую структуру системы и движение данных.
• Абстракция: Позволяют моделировать систему на логическом уровне, не углубляясь в технические детали.
• Иерархичность: Возможность детализации от общего к частному.
• Простота: Относительно небольшое количество элементов и правил делает DFD доступными для понимания.

Недостатки

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

Интересные факты

• В некоторых методологиях, таких как IDEF0, используется похожий, но не идентичный подход — диаграммы IDEF0 фокусируются на функциях и управляющих воздействиях, а не на потоках данных.
• DFD часто используются в сочетании с другими диаграммами, например, с диаграммами «сущность-связь» (ERD) для моделирования данных и с диаграммами состояний для моделирования поведения.
• В России и странах СНГ DFD активно применялись в 1990-х — начале 2000-х годов в рамках внедрения CASE-средств, таких как BPwin и ERwin, которые поддерживали нотации Гейна — Сарсона и Йордона/ДеМарко.

Источники

1. Йордон Э., ДеМарко Т. «Структурный анализ и проектирование систем». — М.: Мир, 1980.
2. Гейн К., Сарсон Т. «Структурный анализ систем: методология и инструментарий». — М.: Финансы и статистика, 1987.
3. Кендалл К., Кендалл Дж. «Системный анализ и проектирование информационных систем». — М.: Вильямс, 2005.
4. Pressman R. S. «Software Engineering: A Practitioner's Approach». — 8th ed. — McGraw-Hill, 2014.