Моделирование потоковых данных ресурсов

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

    На  приведенной DFD (рисунок 2.43) накопитель данных "библиотека" является глобальным или абстрактным представлением хранилища данных.

    Анализ  функционального аспекта поведения  системы дает представление об обмене и преобразовании данных в системе. Взаимосвязь между "абстрактными" потоками данных и "конкретными" потоками данных на диаграмме нулевого уровня выражается в диаграммах структур данных (рисунок 2.44).

    На  фазе анализа строится глобальная модель данных, представляемая в виде диаграммы "сущность-связь" (рисунок 2.45).

    Между различными типами диаграмм существуют следующие взаимосвязи:

• ELM-DFD: события - входные потоки, реакции - выходные потоки
• DFD-DSD: потоки данных - структуры данных верхнего уровня
• DFD-ERD: накопители данных - ER-диаграммы
• DSD-ERD: структуры данных нижнего уровня - атрибуты сущностей

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

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

Рис. 2.43. Контекстная диаграмма 

Рис. 2.44. Диаграмма структур данных  

    Результатами  проектирования архитектуры являются:

• модель процессов (диаграммы архитектуры системы (SAD) и миниспецификации на структурированном языке);
• модель данных (ERD и подсхемы ERD);
• модель пользовательского интерфейса (классификация процессов на интерактивные и неинтерактивные функции, диаграмма последовательности форм (FSD - Form Sequence Diagram), показывающая, какие формы появляются в приложении и в каком порядке. На FSD фиксируется набор и структура вызовов экранных форм. Диаграммы FSD образуют иерархию, на вершине которой находится главная форма приложения, реализующего подсистему. На втором уровне находятся формы, реализующие процессы нижнего уровня функциональной структуры, зафиксированной на диаграммах SAD.

Рис. 2.45. Диаграмма "сущность-связь"  

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

• уточнение модели базы данных для последующей генерации SQL-предложений;
• уточнение структуры пользовательского интерфейса;
• построение структурных схем, отражающих логику работы пользовательского интерфейса и модель бизнес-логики (Structure Charts Diagram - SCD) и привязка их к формам.
• Результатами детального проектирования являются:
• модель процессов (структурные схемы интерактивных и неинтерактивных функций);
• модель данных (определение в ERD всех необходимых параметров для приложений);
• модель пользовательского интерфейса (диаграмма последовательности форм (FSD), показывающая, какие формы появляются в приложении и в каком порядке, взаимосвязь между каждой формой и определенной структурной схемой, взаимосвязь между каждой формой и одной или более сущностями в ERD).

    На  фазе реализации строится реализационная модель. Процесс ее построения включает в себя:

• генерацию SQL-предложений, определяющих структуру целевой БД (таблицы, индексы, ограничения целостности);
• уточнение структурных схем (SCD) и диаграмм последовательности форм (FSD) с последующей генерацией кода приложений.

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