§ 3.2. Диаграммы потоков данных dfd (Data Flow Diagrams)

Несколько позднее, чем нотация SADT, если говорить точнее, то в 1977 году, появилась книга К. Гейна и Т. Сарсона, в которой обсуждалось применение диаграмм потоков данных (DFD), а в 1978 вышли книги Т. Де Марко и В. Вейнбурга (они привели последовательность шагов от моделирования существующей системы до моделирования разрабатываемой системы с использованием DFD) [4].

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

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

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

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

Налогоплательщик

Рис. 3.9. Изображение внешней сущности

При построении модели сложной ЭИС она может быть представ­лена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого либо может быть деком­позирована на ряд подсистем. Подсистема изображается в виде квадрата со сглаженными углами разделенного на 3 сектора: поле номера, поле имени, поле физической реализации. Номер подсистемы служит для ее идентификации. В поле име­ни вводится наименование подсистемы в виде предложения с под­лежащим и соответствующими определениями и дополнениями.

Рис. 3.10. Изображение подсистемы

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

Рис. 3.11. Изображение процесса

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

D1 Реестр налогоплательщиков

Рис. 3.12 Изображение накопителя данных

Если процесс сохраняет данные, то стрелка потока данных направлена от процесса к накопителю, а если считывает данные, то из накопителя к процессу (см. рис. 3.13).

Рис. 3.13. Накопители данных и процессы

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

Рис. 3.14. Изображение потока данных

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

Цель построения иерархии DFD – сделать требования к системе ясными и понятными на каждом уровне детализации, а также разбить эти требования на части с точ­но определенными отношениями между ними. Для достижения это­го целесообразно пользоваться следующими рекомендациями:

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

• не загромождать диаграммы не существенными на данном уров­не деталями;

• декомпозицию потоков данных осуществлять параллельно с де­композицией процессов;

• выбирать ясные, отражающие суть дела имена процессов и пото­ков.

Для сложных систем строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня де­тализируют контекст и структуру подсистем.

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

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

При детализации должны выполняться следующие правила:

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

• правило нумерации – при детализации процессов должна поддерживаться их иерархическая нумерация.

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

• наличия у процесса относительно небольшого количества вход­ных и выходных потоков данных (2-3 потока);

• возможности описания преобразования данных процессом в виде последовательного алгоритма;

• выполнения процессом единственной логической функции пре­образования входной информации в выходную;

• возможности описания логики процесса при помощи специфи­кации небольшого объема (не более 20 - 30 строк).

Спецификации должны удовлетворять следующим требованиям:

• для каждого процесса нижнего уровня должна существовать одна и только одна спецификация;

• спецификация должна определять способ преобразования вход­ных потоков в выходные;

• нет необходимости (по крайней мере на стадии формирования требований) определять метод реализации этого преобра­зования;

• спецификация должна стремиться к ограничению избыточности - не следует переопределять то, что уже было определено на диаг­рамме;

• набор конструкций для построения спецификации должен быть простым и понятным.

Спецификации содер­жат номер и/или имя процесса, списки входных и выходных дан­ных и тело (описание) процесса, являющееся спецификацией ал­горитма или операции, трансформирующей входные потоки дан­ных в выходные.

Структурированный естественный язык применяется для описания спецификаций процессов. В состав языка входят следующие основные символы:

• глаголы, ориентированные на действие и применяемые к объ­ектам;

• термины, определенные на любой стадии проекта ПО (напри­мер, задачи, процедуры, символы данных и т. п.);

• предлоги и союзы, используемые в логических отношениях;

• общеупотребительные математические, физические и техничес­кие термины;

• арифметические уравнения;

• таблицы, диаграммы, графы и т. п.;

• комментарии.

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

• логика процесса выражается в виде комбинации последователь­ных конструкций, конструкций выбора и итераций;

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

• логика процесса должна быть выражена четко и недвусмысленно.

При построении иерархии DFD переходить к детализации про­цессов следует только после определения содержания всех потоков и накопителей данных, которое описывается с помощью структур дан­ных. Для каждого потока данных формируется список всех его эле­ментов данных, затем элементы данных объединяются в структуры данных, соответствующие более крупным объектам данных. Каж­дый объект должен состоять из элементов, являющихся его атрибу­тами. Структуры данных могут содержать альтернативы, условные вхождения и итерации. Условное вхождение показывает, что данный компонент может отсутствовать в структуре. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация предусматривает вхождение любого числа эле­ментов в указанном диапазоне. Для каждого элемента данных может ука­зываться его тип (непрерывные или дискретные данные). Для непре­рывных данных могут указываться: единица измерения (например, кг. см. и т. п.), диапазон значений, точность представления и форма физического кодирования. Для дискретных данных может указываться таблица допустимых значений.

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

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

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

, ; ; ; ;

На рисунке 3.15б представлена матрица смежности графа.

Рис. 3.15. Графовое и матричное представление последовательности расчетов

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

Дуги могут нести также и дополнительную нагрузку. Если на них указать число, то тем самым можно количественно характеризовать связь. Например, количество документов, передаваемых в период, количество объектов, перемещающихся в пространстве и т. д.

Одним из вариантов информационной модели, наглядно отображающей взаимосвязь между входной и результирующей информацией, служит схема, приведенная на рисунке 3.16.

Рис.3.16. Информационная модель связи входных и результирующих

Документов

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

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

Тем не менее, весьма эффективны DFD-диаграммы как простейшее средство формализации взаимодействия между объектами бизнеса, в двух случаях: или, когда необходимо наиболее простыми средствами отразить уже идеально отлаженный механизм бизнеса (например, для целей построения компьютерной системы) или же, наоборот, если бизнес представляет совершенный "черный ящик", и нужно сделать первые наброски, пытаясь найти "луч света в темном царстве".