Разработка сложных программных изделий

Структурное проектирование, управляемое потоками данных


Структурное проектирование

состоит в детализации метода нисходящего проектирования. Сохраняя все принципы предыдуще­го метода, структурное проектирование добавляет ряд руководящих указаний для систематизации процесса проектирования и для оцен­ки качества проекта.

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

Процесс проектирования может быть представлен в виде после­довательности следующих четырех шагов.

Шаг 1. Представление схемы потоков данных.

Основой для определения состава программных компонент слу­жит СПД, которая показывает перемещение данных в системе и их преобразование в процедурных блоках. СПД дает первое представ­ление о проектируемой системе.

Шаг 2. Изображение структурной схемы проекта.

Путем преобразования СПД проектировщик создает проект сис­темы в виде иерархии программных компонент. В качестве руко­водства по преобразованию СПД используются две стратегии:

• анализ преобразований;

• анализ транзакций.

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

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


Это первый уровень дета­лизации.

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

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

Процесс проектирования здесь состоит из четырех шагов:

• идентификация источников транзакций;

• установление центра транзакций в СПД;

• идентификация модулей обработки транзакций в СПД и со­здание высокоуровневой структурной схемы программы;

• детализация модулей обработки транзакций и построение де­тальной схемы проекта.

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

При проектировании сложных программных систем может ока­заться целесообразным использовать комбинацию обеих стратегий.

Шаг 3. Оценка проекта.

В связи с тем, что в результате проектирования может быть по­лучено несколько вариантов проекта, возникает необходимость их сравнения. Для оценки качества проекта на практике широко ис­пользуются два показателя: сцепление между модулями и связность каждого модуля. Эти оценки подробно рассмотрены в гл. 4, а здесь следует лишь отметить, что высокое качество проекта означает сла­бое сцепление между модулями и сильную связность каждого из них.

Шаг 4. Подготовка проекта для реализации.

Последний шаг структурного проектирования называют пакети­рованием проекта. Он представляет собой процесс преобразования логического проекта программы в физически реализуемые блоки. Его цель — определить компоненты физической системы, каждая из которых выполняется под управлением операционной системы как отдельный загрузочный модуль.

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


Содержание раздела