Вместе они действительно составляют пару отточенных инструментов.
Глава 13. Целое и части
Я духов вызывать могу из бездны.
И я могу, и каждый может,
Вопрос лишь, явятся ль на зов они?
ШЕКСПИР, КОРОЛЬ ГЕНРИХ IV
Среди современных кудесников, как и встарь, встречаются хвастуны: "Я могу писать программы, которые управляют воздушным движением, перехватывают баллистические ракеты, делают переводы по банковским счетам, управляют производственными линиями". На что есть ответ: "И я могу, и каждый может, но будет ли работать то, что ты напишешь?"
Как написать программу, которая будет работать? Как протестировать программу? И как объединить набор протестированных программ-компонентов в протестированную и надежную систему? Несколько раз мы уже касались соответствующих приемов, давайте теперь рассмотрим их более систематически.
Проектирование без ошибок
Защита определений от ошибок. Самые пагубные и неуловимые системные ошибки возникают из-за несоответствия допущений, сделанных авторами различных компонентов. Подход к концептуальной целостности, изложенных выше в главах 4, 5 и 6, непосредственно обращается к этим проблемам. Кратко говоря, концептуальная целостность продукта не только упрощает его использование, но также облегчает разработку и делает менее подверженным ошибкам.
Такую же роль выполняет детализированная трудоемкая работа по разработке архитектуры, подразумеваемая этим подходом. В. А. Высоцкий из проекта Safeguard, выполнявшегося в Bell Telephone Laboratories, говорит так: "Решающая задача - дать определение для продукта. Очень многие неудачи связаны именно с теми аспектами, которые не были вполне специфицированы".1 Тщательное определение функций, тщательная спецификация и старательное избегание всех украшательств функций и полетов технической мысли - все это снижает количество системных ошибок, которые будут обнаружены.
Проверка спецификации. Задолго до написания всякого кода спецификация должна быть передана сторонней группе тестирования для тщательного рассмотрения полноты и ясности. Как считает Высоцкий, сами разработчики сделать это не могут: "Они не могут признаться, что не понимают ее, они будут счастливо прокладывать свой путь через пропущенные и темные места".
Нисходящее проектирование. В очень четкой статье 1971 года Никлаус Вирт формализовал процедуру разработки, годами использовавшуюся лучшими программистами.2 Более того, его замечания, сделанные в отношении разработки программ, полностью применимы к разработке сложных программных систем. Воплощением этих замечаний является разделение создания систем на проектирование архитектуры, разработку и реализацию. Более того, каждая из задач проектирования архитектуры, разработки и реализации лучше всего может быть решена нисходящими методами.
Вкратце, метод Вирта определяет разработку как последовательность уточняющих шагов. Набрасывается примерное описание задачи и грубый метод решения, позволяющий получить основной результат.