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

Устойчивость (Robustness)

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

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

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

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

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

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

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

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

Расширяемость (Extendibility)

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

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

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

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

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

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

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

[x]. Простота построения: простая архитектура легче адаптируется к изменениям, чем сложная.

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

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

Повторное использование (Reusability)

Определение: повторное использование

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

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

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