Основы объектно-ориентированного программирования

if "Необходимая информация доступна" then

"Получить запрошенный результат"

"Вывести его"

else

"Запросить подтверждение запроса"

if Да then

"Получить требуемую информацию"

"Вычислить запрошенный результат"

"Вывести результат"

end

end

end

(и т. д.)

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

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

Интерфейсы и проектирование ПО

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

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

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

Преждевременное упорядочение

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

Напомним две альтернативных структуры для первого уточнения компилятора.

[C1]

"Прочесть программу и породить последовательность лексем"

"Разобрать последовательность лексем и построить абстрактное синтаксическое дерево"

"Снабдить дерево семантической информацией"

"Сгенерировать по полученному дереву код"

[C'1]

from

"Инициализировать структуры данных"

until

"Определения всех функций обработаны"

loop

"Прочесть определение следующей функции"

"Сгенерировать частичный код"

end

"Заполнить перекрестные ссылки"

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