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

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

[x].Сомнительной является сама идея охарактеризовать всю систему посредством только одной функции.

[x].Используя в качестве основы декомпозиции системы на модули свойства, которые склонны подвергаться наибольшим изменениям, этот метод не способен учесть эволюционную природу программных систем.

При эволюции системы то, что вначале воспринималось как ее главная функция, с течением времени может стать менее важным.

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

Рис. 5.3. Структура простой системы расчета зарплаты

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

Предположим, однако, что разработка нашей платежной системы благополучно завершена и программа выполняет всю необходимую работу. Скорее всего, на этом разработка не прекратится. Хорошие системы имеют противную привычку возбуждать в своих пользователях множество идей о других вещах, которые они могут делать. Как разработчику системы вам было сказано вначале, что все, что вы должны сделать - это сгенерировать чеки и пару вспомогательных выходных данных. Но затем просьбы о расширениях начинают попадать на ваш стол одна за другой: "Может ли программа собирать некоторую дополнительную статистику?" "Я говорил вам, что в следующем квартале мы собираемся начать платить некоторым служащим ежемесячно, а некоторым - дважды в месяц, не так ли?" "И, между прочим, мне нужен ежемесячный суммарный отчет для администрации и еще один ежеквартальный для акционеров". "Бухгалтерам требуется отдельный отчет для начисления налогов". "Кстати, правильно ли вы храните информацию о зарплате? Очень хотелось бы предоставить персоналу интерактивный доступ к ней. Не понимаю, почему трудно добавить такую функцию?"

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

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

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

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

Рассмотрим какую-либо операционную систему. Наиболее разумно представлять ее как систему, предоставляющую такие услуги, как распределение времени процессора, управление памятью, обращение с устройствами ввода-вывода, декодирование и исполнение команд пользователя. Модули хорошо структурированной ОС стремятся сгруппироваться вокруг этих групп функций. Но это не та структура, которую можно получить при нисходящей функциональной декомпозиции. Этот метод заставляет проектировщика отвечать на искусственный вопрос: "что является "верхней" функцией?", а затем использовать последовательные уточнения полученного ответа в качестве основы для структуры системы. При определенных усилиях можно придти к следующему ответу на исходный вопрос

"Обработать все запросы пользователя",

который далее можно уточнять примерно так:

from

начальная загрузка системы

until

остановка или аварийный отказ

loop

"Прочесть запрос пользователя и поместить во входную очередь"

"Взять запрос r из входной очереди"

"Обработать r"

"Поместить результат в выходную очередь"

"Взять результат q из выходной очереди"

"Выдать результат q получателю"

end

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

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