Ведущая роль в моделировании принадлежит DFD.

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

В качестве основных символов диаграмм потоков данных могут быть использованы следующие (см. табл. 4.1).

Как видно из обозначений DFD, эти диаграммы идентифицируют основные компоненты CASE-модели.

Графическое представление диаграммы потоков данных на экране дисплея обеспечивает наглядность моделирования и удобство корректировки основных компонентов модели в интерактивном режиме.

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

Таблица 4.1

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

!!!!!!!!!!!!!!!!!!!!

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

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

• текстовое описание;
• естественный структурированный язык;
• таблицы решений;
• деревья решений;
• визуальные языки;
• языки программирования.

Языки программирования (C, Cobol и др.) вызывают затруднения в описании алгоритмов применительно к DFD, поскольку требуют использования, помимо потоков данных, словарей данных, и требуют синхронной корректировки спецификаций процессов при корректировке DFD. Структурированный естественный язык легко понимается не только проектировщиками и программистами, но и конечными пользователями. В этом его достоинство. Однако он не обеспечивает автоматической кодогенерации из-за наличия неоднозначностей.

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

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

Содержимое каждого хранилища данных, представленного на диаграмме потока данных, описывается словарем данных и моделью данных ERD. В случае работы системы в реальном времени DFD дополняется STD. Иерархическая структура CASE-модели представлена на рис. 4.4.

Построение иерархической диаграммы потоков данных начинается с контекстных диаграмм.

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

Таким образом, контекстная диаграмма имеет форму звезды.

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

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

Рис. 4.4. Иерархическая структура диаграммы потоков данных

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

Такое описание процесса на нижнем уровне детализации называется мини-спецификацией.

Признаками завершения детализации обычно являются:

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

Рис. 4.5. Контекстная диаграмма потоков данных АРМ склада материалов

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

Рис. 4.6. Детализация диаграммы потоков данных

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

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

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

Рис. 4.7. Каскадная модель разработки информационных систем