Функции и эволюция

We use cookies. Read the Privacy and Cookie Policy

Функции и эволюция

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

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

Уточнение сверху вниз пакетной версии могло начаться следующим образом.

[B0] - Абстракция верхнего уровня

"Решить полный экземпляр проблемы"

[B1] - Первое уточнение

"Прочесть входные данные"

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

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

и т. д. Проектирование интерактивной версии сверху вниз может происходить в следующем стиле.

[I1]

"Обработать одну транзакцию"

[I2]

if "Пользователь предоставил новую информацию" then

"Ввести информацию"

"Запомнить ее"

elseif "Запрошена ранее данная информация" then

"Извлечь запрошенную информацию"

"Вывести ее"

elseif "Запрошен результат" then

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

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

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

else

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

if Да then

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

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

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

end

end

end

(и т. д.)

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

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