Cтраница 1
Внешние спецификации модуля физически могут принимать разнообразные формы, лишь бы они включали ответы на перечисленные выше шесть вопросов. На рис. 8.1 показаны спецификации одного из входов модуля ESTAB-MGR ( УПРТВИМ), спроектированного в гл. [1]
Внешние спецификации модуля и текст исходной программы составляют основу документации модуля. Они должны быть дополнены небольшой дозой информации о логике и комментариев к исходной программе. Вместе с информацией о логике может также присутствовать и список советов по модификации. [2]
Используя внешние спецификации модуля: - необходимо получить проверочные тесты для каждого условия и варианта данных, границ-всех зэданныхинтер - - валоВ: На входе и выходе и для неверных условий. [3]
Важно отделить внешние спецификации модуля от другой документации ( например, описания его логики), потому что изменение логики может никак не повлиять на вызывающие модули, а изменение внешних спецификаций обычно требует изменить вызывающие модули. [4]
Необходимо отличать внешнюю спецификацию модуля от другой документации, такой, как описание логики модуля, так как логика модуля может изменяться без воздействия вызывающих модулей, а изменение внешних спецификаций модуля обычно приводит к изменениям в вызывающих модулях. Внешняя спецификация модуля может принимать ряд физических форм в зависимости от включения шести перечисленных выше категорий. [5]
Необходимо отличать внешнюю спецификацию модуля от другой документации, такой, как описание логики модуля, так как логика модуля может изменяться без воздействия вызывающих модулей, а изменение внешних спецификаций модуля обычно приводит к изменениям в вызывающих модулях. Внешняя спецификация модуля может принимать ряд физических форм в зависимости от включения шести перечисленных выше категорий. [6]
Необходимо отличать внешнюю спецификацию модуля от другой документации, такой, как описание логики модуля, так как логика модуля может изменяться без воздействия вызывающих модулей, а изменение внешних спецификаций модуля обычно приводит к изменениям в вызывающих модулях. Внешняя спецификация модуля может принимать ряд физических форм в зависимости от включения шести перечисленных выше категорий. [7]
Начальным шагом в проектировании модуля является определение его внешних характеристик. Эта информация содержится во внешней спецификации модуля, которая включает все данные, необходимые для модулей, вызывающих данный модуль. В особенности необходимо отметить, что внешняя спецификация модуля не должна содержать указаний о внутреннем представлении данных или о логике модуля. Кроме того, недопустимо, чтобы спецификация содержала какие-либо ссылки на вызывающие модули или на контексты, в которых данный модуль используется. [8]
Первый шаг при проектировании модуля состоит в определении его внешних характеристик. Эта информация выражается в виде внешних спецификаций модуля, которые содержат все сведения, необходимые вызывающим его модулям, и ничего больше. В частности, внешние спецификации модуля не должны содержать никакой информации о логике модуля или о внутреннем представлении данных. Кроме того, спецификации не должны включать каких бы то ни было ссылок на вызывающие модули или на контексты, в которых этот модуль используется. [9]
Первый шаг при проектировании модуля состоит в определении его внешних характеристик. Эта информация выражается в виде внешних спецификаций модуля, которые содержат все сведения, необходимые вызывающим его модулям, и ничего больше. В частности, внешние спецификации модуля не должны содержать никакой информации о логике модуля или о внутреннем представлении данных. Кроме того, спецификации не должны включать каких бы то ни было ссылок на вызывающие модули или на контексты, в которых этот модуль используется. [10]
Внешнее проектирование сводится к решению такой задачи: Переведите множество целей системы во внешние спецификации, где цели - данные, а внешние спецификации - неизвестные. В задаче проектирования логики модуля даны внешние спецификации модуля, а неизвестное - текст его программы. [11]
Начальным шагом в проектировании модуля является определение его внешних характеристик. Эта информация содержится во внешней спецификации модуля, которая включает все данные, необходимые для модулей, вызывающих данный модуль. В особенности необходимо отметить, что внешняя спецификация модуля не должна содержать указаний о внутреннем представлении данных или о логике модуля. Кроме того, недопустимо, чтобы спецификация содержала какие-либо ссылки на вызывающие модули или на контексты, в которых данный модуль используется. [12]
Коль скоро он написан, почему бы ему и не служить документацией логики. Просмотрев заново рис. 8.7, можно убедиться в том, что текст программы MATCHES вместе с первоначальной его детализацией и внешними спецификациями модуля составляют достаточный и весьма желательный комплект документации для функции MATCHES. Дополнительная документация ( например, блок-схемы) нежелательна, так как она была бы избыточной при наличии такого текста программы. Избыточности в документации любого вида следует избегать, поскольку она увеличивает-возможность возникновения противоречий. Более того, если не заботиться об обновлении документации ( а это особенно трудно, если документация логики физически отделена от текста программы), избыточная документация часто становится совершенно бесполезной после того, как текст программы несколько раз изменен. [13]
Ответ, основанный на данном ранее определении ошибки в программном обеспечении - твердое нет, и не представляется вероятным, чтобы он изменился в будущем. Есть, однако, школа утверждающая, что правильность программы может быть доказана, если выразить намерения программиста в некоторой формальной логической системе, сформулировать математические теоремы о программе, используя это описание и исходный текст программы, и затем доказать теоремы. Если допустить, что это возможно ( а так оно и есть), тогда, очевидно, центральной здесь становится проблема определения смысла слова правильность. Если оно означает правильность по отношению к нуждам пользователей, тогда такой подход был бы исключительно ценным. Если оно означает правильность по отношению к внешним спецификациям, подход также был бы крайне полезным, хотя и не гарантировал бы отсутствие всех ошибок. Если правильность означает правильность по отношению к спецификациям низкого уровня, таким, как внешние спецификации модуля, подход по-прежнему заслуживает внимания, хотя и в меньшей степени. [14]