Нисходящее проектирование программы основано на идее уровней абстракции.

Абстрагирование – это процесс обобщения, при котором внимание концентрируется на сходстве явлений и предметов и они объединяются в группы на основе этого сходства.

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

Разработка схемы иерархии.

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

Пример. Диалоговая информационная система, в которой обрабатываются запросы пользователя, приведена на рисунке 1.

Рис. 1

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

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

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

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

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

Преимущества вертикального управления:

- логика программы становится понятней;

- программу проще изменять и дополнять, в ней нет перекрестных связей;

- программирование и проверка вначале модулей высшего уровня, а затем низшего позволяет быстрее обнаруживать логические ошибки.

Модули низшего уровня детализируются только после написания всех модулей высших уровней. Рекомендации:

- при разбиении на модули лучше чуть перестараться, чем недостаточно продвинуться, так как объединять модули легче;

- нельзя рассредоточивать реализацию одной функции в разных модулях;

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

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

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

Внешние спецификации должны содержать следующие сведения:

- имя модуля;

- функция, выполняемая модулем;

- список параметров – число и порядок передачи модулю параметров;

- входные параметры – точное описание всех входных параметров (формат, размер, единицы измерений, диапазоны значений);

- выходные параметры – точное описание данных, которые возвращает модуль, здесь же указывается функциональная связь между входными и выходными параметрами, а также выходные данные, которые получаются при неверных входных данных;

- внешние эффекты – дается описание всех внешних событий, происходящих при работе модуля;

- использование внешних областей памяти и глобальных объектов.

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

Конец этапа проектирования характеризуется следующими условиями:

- известно необходимое число модулей и их спецификации;

- связи между модулями отображены схемой иерархии;

- вся работа проверена пользователями на точность и полноту.

Планирование.

Планирование включает в себя две задачи: планирование порядка разработки модуля и планирование тестов. На этом этапе выбирается последовательность программирования и тестирования модулей.

Планирование порядка разработки модулей.