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

Диаграммы потоков данных (ДПД, англоязычная аббревиатура – DFD) – это графическая составляющая методологий структурного анализа и проектирования. С их помощью строится модель процессов преобразования информации в информационной системе. Основное назначение этой модели – определить процессы и данные, над которыми они происходят. Модели процессов используются для описания сложных систем, для оценки требований к системе, как механизм взаимодействия участников проекта на этапе проектирования, служат основой физического проектирования или реализации системы. В ряде случаев [Калашян-3] они используются на этапе анализа вместо SADT-диаграмм.

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

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

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

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

Диаграммы потоков данных в методологии Гейна-Сарсона

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

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

• потоки данных (arrow);

• процессы (activity);

• хранилища данных (data store);

• внешние сущности (external reference).

П оток данных – механизм передачи информации. Поток изображаются стрелкой, направление которой показывает направление потока. Стрелка имеет имя, заданное существительным. Если имя очевидно, оно может быть опущено.

П роцесс преобразует входные потоки, генерируя выходные в соответствии с действием, которое обозначено в его имени. Имя задаётся глаголом с дополнением, например, «Напечатать экзаменационную ведомость». Процесс имеет уникальный номер внутри диаграммы.

Х ранилище данных позволяет сохранять данные, передаваемые потоком. Структура хранилища может быть задана. Хранилище может служить как источником данных для процесса, так и приёмником. Имя хранилища идентифицирует его содержимое и задаётся существительным. Если поток, связанный с хранилищем, имеет ту же структуру, имя его может быть опущено.

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

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

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

Для построения диаграммы следующего уровня процесс контекстной диаграммы детализируется с помощью нескольких процессов, соединенных потоками. Как правило, поток не соединяет два процесса непосредственно, обычно процесс направляет его в одно из хранилищ, которое и служит исходным узлом потока, направленного в следующий процесс. Таким образом задаётся возможность асинхронной (параллельной) обработки данных.

Поток, в свою очередь, тоже может быть детализирован. На внешней диаграмме он может иметь более общий характер, на внутренней – более конкретный. Для разделения потока используют специальный групповой узел. Этот же узел используется и для слияния потоков.

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

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

Для того, чтобы диаграммы потоков данных отвечали своей цели, то есть были бы понятны программисту, при их написании полезно руководствоваться некоторыми правилами, которые, в частности, представлены в [Калянов-15]. Главные из них следующие:

• размещать на каждом уровне декомпозиции 3-6 процессов;

• выбирать ясные и однозначные имена процессов, хранилищ и потоков;

• однократно определять функционально идентичные процессы;

• контролировать связность диаграмм: следить за непрерывностью дуг при детализации;

• следить, чтобы процессы не соединялись потоками непосредственно (с учётом уровней детализации), поток, кроме контекстного, должен либо начинаться, либо заканчиваться в хранилище.