Структурное проектирование, управляемое потоками данных
Структурное проектирование
состоит в детализации метода нисходящего проектирования. Сохраняя все принципы предыдущего метода, структурное проектирование добавляет ряд руководящих указаний для систематизации процесса проектирования и для оценки качества проекта.
Процесс декомпозиции в структурном проектировании основан на потоках данных в системе. Результатом проектирования также является структурная схема, содержащая иерархически расположенные процедурные компоненты программы (системы) и данные, соединяющие эти компоненты.
Процесс проектирования может быть представлен в виде последовательности следующих четырех шагов.
Шаг 1. Представление схемы потоков данных.
Основой для определения состава программных компонент служит СПД, которая показывает перемещение данных в системе и их преобразование в процедурных блоках. СПД дает первое представление о проектируемой системе.
Шаг 2. Изображение структурной схемы проекта.
Путем преобразования СПД проектировщик создает проект системы в виде иерархии программных компонент. В качестве руководства по преобразованию СПД используются две стратегии:
• анализ преобразований;
• анализ транзакций.
На первом этапе анализа преобразований происходит разделение СПД на три типа составных частей: вход, логическая обработка, выход. Входная часть, включающая процессы преобразования данных из физической (внешней) формы представления в логическую, называется ветвью ввода. Выходная часть, преобразующая данные из логической (внутренней) формы в физическое представление — в строку документа или экрана — называется ветвью вывода. В СПД в общем случае может быть несколько ветвей ввода и вывода. Логическая обработка, наиболее удаленная от входов и выходов, называется центром преобразования. СПД может содержать несколько центров преобразования.
Второй этап — построение схемы программы, в которой для каждой ветви потока и для каждого центра преобразования создается одна функциональная компонента.
Это первый уровень детализации.
На следующих этапах структурная схема еще более детализируется путем добавления подфункций для каждой функциональной компоненты.
Альтернативной стратегией построения схемы структурного проекта выступает анализ транзакций, который оказывается полезным при проектировании систем обработки транзакций. Транзакция — элемент или совокупность входных данных, вызывающая определенную реакцию системы, каждая транзакция содержит признак типа транзакции.
Процесс проектирования здесь состоит из четырех шагов:
• идентификация источников транзакций;
• установление центра транзакций в СПД;
• идентификация модулей обработки транзакций в СПД и создание высокоуровневой структурной схемы программы;
• детализация модулей обработки транзакций и построение детальной схемы проекта.
В результате в схеме на верхнем уровне находится блок "центр транзакций", а на следующем уровне — блоки, соответствующие обработке транзакции каждого типа.
При проектировании сложных программных систем может оказаться целесообразным использовать комбинацию обеих стратегий.
Шаг 3. Оценка проекта.
В связи с тем, что в результате проектирования может быть получено несколько вариантов проекта, возникает необходимость их сравнения. Для оценки качества проекта на практике широко используются два показателя: сцепление между модулями и связность каждого модуля. Эти оценки подробно рассмотрены в гл. 4, а здесь следует лишь отметить, что высокое качество проекта означает слабое сцепление между модулями и сильную связность каждого из них.
Шаг 4. Подготовка проекта для реализации.
Последний шаг структурного проектирования называют пакетированием проекта. Он представляет собой процесс преобразования логического проекта программы в физически реализуемые блоки. Его цель — определить компоненты физической системы, каждая из которых выполняется под управлением операционной системы как отдельный загрузочный модуль.
Несмотря на то, что структурное проектирование вводит ряд дополнительных формальных процедур в построение схемы проекта и использует критерии для оценки качества проекта, оно, как и нисходящее проектирование, не дает строгих правил для проведения функциональной декомпозиции. Серьезный пробел этого метода — отсутствие проектирования данных, и особенно заметным он становится, когда используется технология баз данных, что ограничивает применение метода разработкой простых программ с файловой средой.
