Автор: Мейер Бертран
Название: Основы объектно-ориентированного программирования
Содержание
Лекция 1. Качество ПО
Лекция 2. Критерии объектной ориентации
Лекция 3. Модульность
Лекция 4. Подходы к повторному использованию
Лекция 5. К объектной технологии
Лекция 6. Абстрактные типы данных (АТД)
Лекция 7. Статические структуры: классы
Лекция 8. Динамические структуры: объекты
Лекция 9. Управление памятью
Лекция 10. Универсализация
Лекция 11. Проектирование по контракту: построение надежного ПО
Лекция 12. Когда контракт нарушается: обработка исключений
Лекция 13. Поддерживающие механизмы
Лекция 14. Введение в наследование
Лекция 15. Множественное наследование
Лекция 16. Техника наследования
Лекция 17. Типизация
Лекция 18. Глобальные объекты и константы
Качество - это цель инженерной деятельности; построение качественного ПО (software) - цель программной инженерии (software engineering). В данной книге рассматриваются средства и технические приемы, позволяющие значительно улучшить качество ПО. Прежде чем приступить к изучению этих средств и приемов, следует хорошо представлять нашу цель. Качество ПО лучше всего описывается комбинацией ряда факторов. В этой лекции мы постараемся проанализировать некоторые из них, покажем, где необходимы улучшения, и укажем дорогу в дальнейшем путешествии по лекциям этого курса.
Внешние и внутренние факторы
Все мы хотим, чтобы наше ПО было быстродействующим, надежным, легким в использовании, читаемым, модульным, структурным и т.д. Но эти определения описывают два разных типа качества. Наличие или отсутствие таких качеств, как скорость и простота использования ПО, может быть обнаружено его пользователями. Эти качества можно назвать внешними факторами качества.
Под словом "пользователи" нужно понимать не только людей, взаимодействующих с конечным продуктом, но и тех, кто их закупает, занимается администрированием. Такое свойство, например, как легкость адаптации продуктов к изменениям спецификаций - далее определенная в нашей дискуссии как расширяемость - попадает в категорию внешних факторов, поскольку она может представлять интерес для администраторов, закупающих продукт, хотя и не важна для "конечных пользователей", непосредственно работающих с продуктом.
Такие характеристики ПО, как модульность или читаемость, являются внутренними факторами, понятными только для профессионалов, имеющих доступ к тексту ПО.
В конечном счете, только внешние факторы имеют значение. Но ключ к достижению внешних факторов спрятан во внутренних факторах: для того, чтобы достичь видимого качества, проектировщики и конструкторы должны иметь внутренние приемы, позволяющие улучшать скрытые от пользователя качества.
Последующие лекции представляют описание набора современных технических средств достижения внутреннего качества. Однако за частностями не следует терять из вида общую картину; внутренние технические приемы не являются самоцелью - они лишь средство достижения внешних качеств нашего продукта.
Рассмотрим самые важные внешние факторы качества, стремление к которым есть центральная задача ОО-построения ПО.
Корректность (Correctness)
Определение: корректность
Корректность - это способность ПО выполнять точные задачи так, как они определены их спецификацией.
Корректность является важнейшим качеством. Если система не делает того, что она должна делать, то все остальное - ее быстродействие, хороший пользовательский интерфейс - не имеет особого значения.
Но легче сказать, чем сделать. Даже первый шаг к корректности уже труден: необходимо в точной форме специфицировать технические требования к системе, что само по себе является тяжелой задачей.
Методы обеспечения корректности обычно условны. Серьезная система ПО, даже небольшая по нынешним меркам, использует столь многое, что невозможно гарантировать ее корректность, работая со всеми компонентами на одном уровне. Необходим многоуровневый подход:
Рис. 1.1. Слои в разработке ПО
В условном подходе к корректности мы заботимся только о том, чтобы обеспечить корректность каждого уровня, основываясь на предположении, что нижележащие уровни корректны. Это единственно реалистичный подход, поскольку он позволяет разделить проблему и на каждой ступени сконцентрироваться на ограниченном круге задач. Нельзя проверить, что программа на языке высокого уровня корректна, если не предположить, что используемый компилятор корректно реализует язык. Это не слепое доверие компилятору, а разделение проблемы на две: проверка корректности компилятора и проверка корректности программы относительно семантики языка.
В методе, описанном в нашей книге, слоев даже больше: разработка ПО будет основываться на библиотеках компонентов повторного использования, используемых во многих приложениях.
Рис. 1.2. Уровни в процессе разработки, включающем повторное использование
Здесь также применим условный подход: следует обеспечить корректность библиотек и корректность приложения при условии, что библиотеки корректны.
Многие практики полагают, что достижение корректности ПО связано с тестированием и исправлением ошибок. Мы же более амбициозны: в дальнейших лекциях исследуется ряд технических приемов, в частности типизация и метод утверждений, направленных на построение ПО, корректного с самого начала. Исправление ошибок и тестирование, конечно, остаются необходимыми как средства дополнительной проверки результата. Можно было бы пойти дальше и принять совсем формальный подход к построению ПО. Это не является целью наших лекций, как ясно из несколько "робких" терминов - "проверять", "гарантировать", "обеспечивать", используемых выше вместо слова "доказывать". Все же многие из описанных ниже технических приемов происходят непосредственно от математических методов формальной спецификации и верификации программ, проходя длинный путь к обеспечению идеала корректности.
Устойчивость (Robustness)
Определение: устойчивость
Устойчивость - это способность ПО соответствующим образом реагировать на аварийные ситуации.
Устойчивость дополняет корректность. Корректность относится к поведению системы в случаях, определенных спецификацией; устойчивость характеризует то, что происходит за пределами этой спецификации.
Рис. 1.3. Устойчивость против корректности
Как видно из определения, устойчивость по своей природе более нечеткое понятие, чем корректность. Невозможно сказать, как в случае с корректностью, что в аварийных ситуациях система должна "выполнять свои задачи", поскольку ситуации выходят за пределы спецификации. Если бы эти задачи были известны, аварийный случай стал бы частью спецификации, и мы бы снова вернулись в область корректности.
Это определение "аварийной ситуации" нам еще понадобится при изучении обработки исключений (Об исключительных ситуациях см. лекция 12). Оно подразумевает, что понятия нормальной и аварийной ситуации всегда относительны по отношению к заданной спецификации; ситуация аварийна, если она выходит за рамки спецификации. Если расширить спецификацию, аварийные случаи становятся нормальными - даже если они соответствуют таким нежелательным событиям, как, например, ошибочный ввод пользователя.
Термин "нормальный" в этом смысле не означает "желательный", а просто "запланированный в проекте ПО". Хотя на первый взгляд может показаться парадоксальным, что ошибочный ввод может называться нормальным случаем, любой другой подход опирается на субъективные критерии и, таким образом, бесполезен.
Всегда будут существовать случаи, на которые спецификация явно не распространяется. Роль требования устойчивости - удостовериться, что и в таких случаях система не приводит к непоправимой ситуации; она должна выдать соответствующее сообщение об ошибке, гладко завершить работу или войти в так называемый режим "постепенного вывода из работы".
Расширяемость (Extendibility)
Определение: расширяемость
Расширяемость - это легкость адаптации ПО к изменениям спецификации.
