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

В методе, описанном в нашей книге, слоев даже больше: разработка ПО будет основываться на библиотеках компонентов повторного использования, используемых во многих приложениях.

Рис. 1.2. Уровни в процессе разработки, включающем повторное использование

Здесь также применим условный подход: следует обеспечить корректность библиотек и корректность приложения при условии, что библиотеки корректны.

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

Определение: устойчивость

Устойчивость - это способность ПО соответствующим образом реагировать на аварийные ситуации.

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

Рис. 1.3. Устойчивость против корректности

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

Термин "нормальный" в этом смысле не означает "желательный", а просто "запланированный в проекте ПО". Хотя на первый взгляд может показаться парадоксальным, что ошибочный ввод может называться нормальным случаем, любой другой подход опирается на субъективные критерии и, таким образом, бесполезен.

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

Определение: расширяемость

Расширяемость - это легкость адаптации ПО к изменениям спецификации.

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

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

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

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