2.2.Нисходящее проектирование

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

Нисходящее проектирование применимо к проектированию сис­тем, программ, отдельного модуля, а также к проектированию структур данных. Как и другие структурные методы, нисходящее проектирование имеет целью:

• систематизировать процесс проектирования;

• создать модульный проект программы;

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

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

• при принятии решения обязательно рассматривать альтерна­тивные проекты;

• на каждом шаге принимать как можно меньше решений;

• в первую очередь пытаться выполнять простейшие решения. Для успешного применения метода каждый проектировщик дол­жен следовать следующим основополагающим принципам:

1. Для каждого модуля (на любом уровне иерархии) должны быть определены: функция, его входы и выходы.

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

3. Для описания интерфейсов между модулями данным необхо­димо уделять такое же внимание, как и процедурам обработки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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