В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 9. Проблемы реализации. Часть I графическая система в случае ее широкого распространения будет использо- ваться на протяжении еще 30-50 лет. Надеемся, что к тому времени другие части системы достигнут гораздо более высокого уровня безопасности. 9.1 Создание правильных программ Источник всех проблем реализации кроется в том, что мы, IT-специали- сты, не знаем, как написать правильную программу или модуль. (“Правиль- ная” программа — это программа, которая ведет себя именно так, как описа- но в ее спецификациях.) Существует несколько причин того, почему нам так трудно написать правильную программу. 9.1.1 Спецификации Первая причина касается отсутствия спецификаций. Для большинства программ не существует четкого описания того, что именно они должны де- лать. Если у программы нет спецификаций, мы даже не можем проверить, правильная она или нет. Сама концепция правильности для таких программ теряет свою определенность. Многие программные проекты сопровождаются документом, называемым функциональной спецификацией. Теоретически это и есть спецификация про- граммы. На практике, однако, этот документ либо не существует, либо явля- ется неполным, либо описывает вещи, не относящиеся к поведению програм- мы. Не имея четкой спецификации, нечего и надеяться получить правильную программу. Процесс создания спецификаций можно разделить на три этапа. • Требования. Это неформальное описание того, для чего предназна- чена программа. Этот документ описывает скорее “ что я могу сде- лать с помощью этой программы”, нежели то, “ как я могу это сделать”. В большинстве случаев требования несколько расплывчаты и не содер- жат мелких деталей. Они сконцентрированы на программе в целом. • Функциональная спецификация. Это подробное и исчерпывающее описание поведения программы. В функциональной спецификации должны содержаться только те элементы программы, поведение кото- рых может быть оценено “из внешнего мира”. • Прежде чем помещать какой-либо элемент в функциональную специфи- кацию, подумайте, можно ли разработать тест для готовой программы, который будет определять, функционирует ли этот элемент должным образом. Тест должен использовать только внешнее поведение програм- мы, а не ее внутренние механизмы. Если такой тест создать нельзя, 9.1. Создание правильных программ 153 соответствующий элемент не должен быть указан в функциональной спецификации. • Функциональная спецификация должна быть полной. Другими слова- ми, она должна содержать описание абсолютно всех функциональных элементов программы. Все, что не было занесено в функциональную спецификацию, не должно быть реализовано. • Для большей наглядности функциональную спецификацию можно представить себе в виде основы для тестирования готовой програм- мы. Все элементы, указанные в функциональной спецификации, могут и должны быть протестированы. • План реализации. У этого документа много названий. План реализа- ции описывает внутреннее поведение программы. В нем указаны все те элементы, которые не могут быть протестированы извне. Хороший план реализации зачастую разбивает программу на несколько модулей и опи- сывает функциональность каждого из них. Описание модуля, в свою очередь, можно рассматривать как составление требований к модулю с последующим созданием функциональной спецификации и плана ре- ализации. Из всех перечисленных документов наиболее важной, несомненно, являет- ся функциональная спецификация. Именно она служит основой для тестиро- вания готовой программы. Иногда для разработки программы может вполне хватить неформальных требований или плана реализации, представляющего собой лишь несколько заметок на клочке бумаги. Но при отсутствии функ- циональной спецификации мы даже не сможем описать, чего мы достигли по окончании разработки программы. 9.1.2 Тестирование и исправление Вторая проблема написания правильных программ касается повсеместно распространенного метода разработки “протестировать и исправить”. Про- граммисты пишут программу и затем тестируют ее на предмет того, правиль- но ли она работает. Если она не работает или работает неправильно, програм- мисты исправляют найденные ошибки и снова тестируют программу. Всем известно, что такой подход отнюдь не приводит к появлению правильной про- граммы. Он позволяет лишь получить программу, которая будет работать (а точнее, возможно, будет работать) в наиболее стандартных ситуациях. В 1972 году Эдсгер Дейкстра (Edsger Dijkstra) в одной из своих речей отметил, что тестирование может показать только наличие ошибок, а не их отсутствие [22]. Подмечено как нельзя точно. В идеале мы хотели бы со- здавать такие программы, правильность которых могла бы быть доказана. |