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

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

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

Основными компонентами диаграмм потоков данных являются: внешние сущности; системы и подсистемы; процессы; накопители данных; потоки данных.

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

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

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

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

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

• Размещать на каждой диаграмме от 3 до 6-7 процессов (аналогично SADT). Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса.

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

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

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

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

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

На практике полезными при составлении DFD-моделей могут быть приведенные ниже принципы.

А. Методика построения DFD-диаграмм

1. DFD-диаграмма должна быть полезной.

2. Цель построения DFD-диаграмм — общение с заказчиком и пользователями, уточнение требований к системе, передача знаний о предметной области от системных аналитиков к разработчикам автоматизированной системы.

3. Каждая DFD-диаграмма должна быть проверена на соответствие реальному положению дел («как есть»).

4. Правило от 2 до 6. На DFD-диаграмме должно быть не меньше двух и не больше шести процессов/подсистем.

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

6. Материальные процессы, потоки и хранилища на диаграммах DFD не отображаются (только процессы обработки информации, потоки данных и хранилища данных).

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

8. Не должно быть связей между внешними сущностями. Во внешних сущностях не должно быть обработки информации.

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

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

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

12. Элементарные процессы на диаграммах DFD не детализируются.

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

Имитационное моделирование.

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