166 Глава 8

ния задачи является наиболее важным результатом данной ра-_ боты.

Цель состоит в написании спецификаций, которые являются одновременно достаточно полными и достаточно ограниченными. Таким образом, мы удаляем должное внимание поставленным тре­бованиям, исключительным ситуациям и граничным условиям. Этот процесс предполагает постановку ряда вопросов относи­тельно поведения абстракций, подобных тому, как поступать с индексами, если строка пуста. Смысл состоит в том, что поста­новка и ответ на такие вопросы заставляет нас более тщательно анализировать абстракцию и ее предполагаемое назначение.

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

Как это будет показано в гл. 12 и 13, спецификации можно начать составлять сразу же после того, как будут приняты опи­сываемые в них решения. Поскольку спецификации теряют зна­чимость только в том случае, если становятся устаревшими со­ответствующие абстракции, то они эволюционируют до тех пор, пока эволюционирует сама программа. Серьезная ошибка счи­тать, что процесс написания спецификаций является отдельной фазой создания программного обеспечения.

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

Смцификации

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

Наконец, спецификация весьма полезна в процессе сопровож­дения программного обеспечения. Существование ясной и акку­ратной документации является необходимым условием для успеш­ного и эффективного сопровождения. Нам необходимо знать, что делает каждый модуль, а если он достаточно сложен, знать также то, как он это делает. Зачастую эти два аспекта документации сильно взаимосвязаны. Использование спецификации в качестве документации позволяет нам разделить эти две стороны, что облегчает анализ и возможные модификации. Например, модифи­кация, при которой требуется только заново реализовать един­ственную абстракцию без изменения ее спецификации, гораздо легче реализуема, чем модификация, предполагающая изменение спецификации.

8.4. Заключение

В данной главе были рассмотрены спецификации и предложены критерии, используемые при их создании. Мы определяем смысл спецификации через набор программных модулей, ей удовлетво­ряющий. Такое определение учитывает интуитивное назначение спецификации, а именно: утверждает, что общего имеют между собой все допустимые реализации абстракции. Такая специфика­ция сообщает пользователям то, из чего они могут исходить, а проектировщикам — то, что они должны реализовать.

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

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