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

Рис. 5.1. Схема применения структурного подхода

Таблица 5.1. Методологии структурного анализа и проектирования

Методологии структурного анализа и проектирования информационных систем появились позже фактического использования этих принципов на практике (структурного программирования). В конце 60-х гг. ХХ в. стали появляться и применяться первые методологии, ориентированные на структурный подход.

Сущность структурного анализа и проектирования

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

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

Большинство методологий структурного анализа и проектирования основано на представлении моделей разрабатываемых систем в виде диаграмм. Наиболее популярные из них представлены в табл. 5.1.

Методология Тип разрабатываемой модели
SADT (Structured Analysis and Design Technique, методология структурного анализа и проектирования) Функциональная
DFD (Data Flow Diagrams, диаграммы потоков данных) Смешанная (функциональная, информационная, компонентная)
ERD (Entity-Relationship Diagrams, диаграммы «сущность-связь») Информационная
STD (State Transition Diagrams, диаграммы изменения состояний) Поведенческая
Flowcharts (блок-схемы) Смешанная (поведенческая, информационная, компонентная)

Схематично применение структурного подхода изображено на рис. 5.1.

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

Показанная на рис.5.1 схема не означает, что построение моделей должно строго соответствовать указанному порядку – одна за другой. Как правило, разработка каждой последующей модели начинается еще до полного завершения разработки предыдущей, а иногда – параллельно.