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

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

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

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

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

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

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

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

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

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

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

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

[I1]

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

[I2]

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

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

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

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

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

"Вывести ее"

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

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

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

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

else

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

if Да then

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

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

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

end

end

end

(и т. д.)

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

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

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг:

Эволюция Windows

Из книги автора

Эволюция Windows Windows API поддерживается несколькими версиями Windows. Существование ряда различных версий Windows может вносить некоторую неразбериху, однако с точки зрения программиста все они аналогичны друг другу. В частности, все версии поддерживают подмножества идентичных


Эволюция HTML

Из книги автора

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


5.4. Эволюция

Из книги автора

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


Эволюция PowerPC

Из книги автора

Эволюция PowerPC Концепция RISC была разработана Джоном Коком (John Cocke) из IBM Research. Кок установил, что прогресс в области компиляторов достиг той точки, когда можно упростить набор команд процессора, и возложить на компилятор значительную часть работы, ранее выполнявшейся


Эволюция PR и блогосфера

Из книги автора

Эволюция PR и блогосфера Метки: внимание, СМИ, PRСМИ – это, по Гладуэллу, коннекторы (см. книгу «Tipping point»). Они объединяют людей и дают производителям возможность рассказывать истории (показывать рекламу) большой аудитории. Что происходит, когда историй становится слишком


11.6 Эволюция BOOTP

Из книги автора

11.6 Эволюция BOOTP Протокол BOOTP обеспечивает в работе достаточную гибкость:? Перед запуском клиент может не иметь никакой информации или быть частично сконфигурированным.? Клиент может получить информацию на сервере загрузки или выбрать для этого специально указанный


8.3. Эволюция

Из книги автора

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


9.3. Эволюция

Из книги автора

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


10.3. Эволюция

Из книги автора

10.3. Эволюция Управление релизами Теперь, полностью определив архитектурный каркас системы складского учета, мы можем приступить к последовательному развитию. Выберем сначала наиболее важные транзакции в нашей системе (ее вертикальный срез) и выпустим продукт, который


11.3. Эволюция

Из книги автора

11.3. Эволюция Интеграция Теперь, когда ключевые абстракции предметной области выявлены, можно приступить к их соединению в действующее приложение. Мы будем реализовывать и проверять вертикальные срезы системы, а затем последовательно отрабатывать механизмы. Интеграция


12.3. Эволюция

Из книги автора

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


17.1. Эволюция С

Из книги автора

17.1. Эволюция С Главным фактом практики Unix-программирования всегда была стабильность языка С и небольшого количества служебных интерфейсов, которые всегда ему сопутствовали (особенно стандартная 1/О-библиотека и подобные ей). Тот факт, что i язык, созданный в 1973 году, в


17.1. Эволюция С

Из книги автора

17.1. Эволюция С Главным фактом практики Unix-программирования всегда была стабильность языка С и небольшого количества служебных интерфейсов, которые всегда ему сопутствовали (особенно стандартная I/O-библиотека и подобные ей). Тот факт, что язык, созданный в 1973 году, в


Эволюция доверия

Из книги автора

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