Требования к построению модели в нотации DFD совпадают с рассмотренными требованиями нотаций IDEF0 и IDEF3. Модель должна строиться с единой точки зрения, иметь четко определенные цель и границы моделирования.
Сначала строится контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс — вся проектируемая система, соединенная "абстрактными" потоками данных с внешними сущностями (приемниками и источниками информации). Контекстная диаграмма устанавливает границы моделируемой системы.
Пример варианта контекстной диаграммы для системы "Графический редактор (Paint)" представлен на рис. 10.4.
Рис. 10.4. Вариант контекстной диаграммы
Далее строится диаграмма первого уровня. Она содержит набор подсистем, соединенных потоками данных.
Пример варианта диаграммы первого уровня для системы "Графический редактор (Paint)" представлен на рис. 10.5. Выделены подсистемы: "Подсистема работы с файлами", "Подсистема редактирования изображения", "Подсистема настройки изображения" и "Подсистема настройки интерфейса".
Для каждой подсистемы выполняется детализация ее структуры. На диаграммах последующих уровней уже изображают процессы (функции, выполняемые подсистемой).
Каждый процесс, в свою очередь, может быть детализирован при помощи диаграммы потоков данных, на которых уже изображается совокупность взаимосвязанных действий (работ). Пример детализирующих диаграмм приведен на рис. 10.6, 10.7.
Естественно, если моделируется довольно простая система, которая не может быть представлена в виде совокупности подсистем, то на диаграмме первого уровня сразу изображают совокупность процессов или даже действий, т.е. набор и наполнение диаграмм зависит от масштаба моделируемой системы. Так в модели системы "Графический редактор (Paint)" на диаграмме первого уровня показаны два действия: "Печатать изображение" и "Преобразовать изображение в рисунок рабочего стола".
При декомпозиции должно выполняться правило балансировки.
Правило балансировки означает, что при детализации подсистемы, процесса, действия детализирующая диаграмма в качестве внешних источ-ников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь детализируемая подсистема, процесс, действие на родительской диаграмме.
При наличии функционально идентичных процессов, действий рекомендуется определять один функциональный блок, соответствующий такому процессу, действию, на самом верхнем уровне, где он необходим, и затем ссылаться к нему на нижних уровнях.
Декомпозицию заканчивают, когда процесс, действие могут быть эффективно описаны с помощью короткой (до одной страницы) миниспецификации обработки (описание логики процесса).
В дальнейшем по этим миниспецификациям специалист, выполняющий реализацию проекта, должен разработать соответствующую программу.
При построении иерархии диаграмм потоков данных переходить к какой бы то ни было детализации процессов следует только после определения содержания всех потоков и накопителей данных. Содержание описывается в словаре данных. Декомпозиция потоков данных должна осуществляться параллельно с декомпозицией процессов. Эти две работы должны выполняться одновременно, а не одна за другой.
Причем на начальном этапе анализа и при переходе от контекстной диаграммы к диаграмме 1-го уровня для лучшего понимания содержание потоков данных удобно сначала описывать при помощи диаграмм структур данных.
Пример варианта фрагмента диаграммы структуры данных для системы "Графический редактор (Paint)" (см. рис. 10.4) представлен на рис. 10.8.
Рис. 10.5. Диаграмма декомпозиции контекстной диаграммы функциональной модели в нотации DFD
Рис. 10.6. Диаграмма декомпозиции подсистемы А2 "Подсистема редактирования изображения" в нотации DFD
Рис. 10.7. Диаграмма декомпозиции процесса подсистемы А3 "Подсистема настройки изображения" в нотации DFD
Рис. 10.8. Фрагмент диаграммы структуры данных
После построения законченной модели системы ее необходимо верифицировать (проверить на полноту и согласованность).
В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы. Выявленные недетализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки.
В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации: все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны.