- •2 3 1 Общие сведения 12
- •2. Структурный подход к проектированию программного обеспечения
- •2.1. Сущность структурного подхода
- •2.1.1. Проблема сложности больших систем
- •2.1.2. Структурный подход к разработке по
- •2.2. Метод функционального моделирования sadt
- •2.2.1. Общие сведения
- •2.2.2. Состав функциональной модели
- •2.2.3. Построение иерархии диаграмм
- •2.2.4. Типы связей между функциями
- •2.3. Моделирование потоков данных (процессов)
- •2 3 1 Общие сведения
- •2.3.2. Состав диаграмм потоков данных
- •2.3.3. Построение иерархии диаграмм потоков данных
- •2.4. Сравнительный анализ sadt-моделей и диаграмм потоков данных
- •2.5. Функциональные модели, используемые на стадии проектирования
- •2.6. Моделирование данных
- •2.6.1. Основные понятия
- •2.6.2. Метод баркера
- •2.6.3. Метод idef1
- •2.6.4. Подход, используемый в case-средстве silverrun
- •2.7. Пример использования структурного подхода
- •2.7.1. Описание предметной области (организации)
- •2.7.2. Построение моделей деятельности организации
2.7.2. Построение моделей деятельности организации
На стадии формирования требований к ПО строятся начальная контекстная DFD, контекстные диаграммы, определяется состав потоков данных и конструируется концептуальная модель данных в виде ERD.
Из описания предметной области следует, что в процессе работы данной подсистемы ГНИ участвуют налогоплательщики и другие подсистемы. Эти объекты являются внешними сущностями. Они не только взаимодействуют с системой, но также определяют ее границы и изображаются на начальной контекстной DFD как терминаторы.
Начальная контекстная диаграмма в нотации Гейна-Сэрсона изображена на рис. 2.40.
Для завершения анализа функционального аспекта системы строится полная контекстная диаграмма, включающая диаграмму нулевого уровня (рис. 2.41). При этом подсистема учета и регистрации декомпозируется на четыре процесса. Существующие "абстрактные" потоки данных между терминаторами и процессами трансформируются в потоки, представляющие обмен данными на более конкретном уровне.
Концептуальная модель данных в виде ERD (рис. 2.42) строится исходя из следующих соображений:
-
сущности могут быть распознаны как структуры данных в DFD. Чтобы рассматривать объект в качестве сущности, он должен обладать более чем одним атрибутом;
-
связи должны отражать наличие взаимодействия между сущностями, причем в системе должна сохраняться информация об этом взаимодействии.
С использованием построенных структур данных определяются атрибуты каждой сущности и изображаются на диаграмме. Внешние ключи можно не показывать, поскольку они определяются связями между сущностями. Выделяются (при необходимости) зависимые от идентификатора сущности и связи "супертип-подтип".
Проверяется соответствие между описанием структур данных и концептуальной моделью (все элементы данных должны быть использованы в качестве атрибутов).
На стадии проектирования выполняются детальное описание функционирования системы, дальнейший анализ используемых данных и построение реляционной модели для последующего проектирования базы данных. Определяется структура пользовательского интерфейса. Результатами проектирования являются:
-
модель системных процессов;
-
архитектура ЭИС;
-
модели данных приложений;
-
модель пользовательского интерфейса.
На стадии реализации выполняются генерация SQL-предложений, определяющих структуру целевой БД (таблицы, индексы, ограничения целостности), и генерация кода приложений.
На основе анализа потоков данных и взаимодействия процессов с хранилищами данных осуществляется окончательное выделение подсистем (предварительное должно быть сделано и зафиксировано на этапе формулирования требований в техническом задании). При выделении подсистем необходимо руководствоваться принципами функциональной связанности и минимизации информационной зависимости. Необходимо учитывать, что на основании таких элементов подсистемы, как процессы и данные, на этапе разработки должно быть создано приложение, способное функционировать самостоятельно. С другой стороны, при группировке процессов и данных в подсистемы необходимо учитывать требования к конфигурированию продукта, если они были сформулированы на этапе анализа.
Следует запомнить:
Сущность структурного подхода к разработке ПО ЭИС заключается в его декомпозиции (разбиении) на автоматизируемые функции. В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой, и отношения между данными.
Основные понятия:
Диаграммы потоков данных, диаграммы "сущность-связь", функциональная модель, внешняя сущность, процесс, накопитель данных, поток данных, сущность, связь, атрибут.
Вопросы для самоконтроля:
-
В чем заключаются основные принципы структурного подхода?
-
Что общего и в чем различия между методом SADT и моделированием потоков данных?
-
В чем заключаются достоинства и недостатки структурного подхода?