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

Своевременность - до сих пор необычное явление для больших проектов. Когда корпорация Microsoft объявила, что его операционная система, находящаяся в разработке несколько лет, будет выпущена на месяц раньше, это была новость, достойная заголовка первой полосы Computer World 1.2) (в статье упоминались значительные задержки в предыдущих проектах).

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

[x].Верифицируемость (Verifiability) - это легкость подготовки процедур приемки, особенно тестовых данных, процедур обнаружения неполадок и трассировки ошибок на этапах заключительной проверки и введения проекта в действие.

[x].Целостность (Integrity) - это способность ПО защищать свои различные компоненты (программы, данные) от несанкционированного доступа и модификации.

[x].Восстанавливаемость (Repairability) - это способность облегчать устранение дефектов.

[x].Экономичность (Economy) сочетается c своевременностью - это способность системы завершиться, не превысив выделенного бюджета или даже не истратив его.

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

[x].Внешнюю, дающую пользователям возможность понять сильные стороны системы и удобство их использования. Необходимость в ней является следствием простоты использования системы.

[x].Внутреннюю, дающую разработчикам ПО возможность понять структуру и реализацию системы, - следствие требования расширяемости.

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

Документацию не следует считать независимой частью проекта. Предпочтительнее в максимально возможной степени создавать самодокументируемое ПО. Это справедливо для всех трех видов документации:

[x].Включение возможности получения справки проясняет соглашения пользовательского интерфейса. Тем самым облегчается задача авторов руководств пользователей и других форм внешней документации.

[x].Хороший язык реализации устраняет необходимость большой части внешней документации. Это будет одним из главных требований ОО-нотации, разработанной в этой книге.

[x].Нотация будет поддерживать сокрытие информации и другие технические приемы (такие как утверждения), позволяющие отделить интерфейс модуля от его реализации. При этом становится возможным из текстов автоматически извлекать документацию интерфейса модулей. Эта тема подробно изучается в лекциях книги. Все эти приемы уменьшают роль традиционной документации, хотя, конечно, не следует ожидать, что они полностью ее заменят.

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

Как можно достичь целостности, если не вводить защиты различного рода, что неизбежно затруднит простоту использования? Экономичность часто конфликтует с функциональностью.

Оптимальная эффективностьтребует полной адаптации к определенному оборудованию и программной среде, что является противоположностью переносимости. Повторное использованиетребует решения общих задач, что расширяет границы, заданные спецификацией. Давление своевременностиможет склонить нас к технике RAD - быстрой разработки приложения (Rapid Application Development), что может повредить расширяемости. Хотя во многих случаях удается найти решение, примиряющее явно конфликтующие факторы, иногда приходится идти на компромисс.

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