Структура модуля

Остальные правила «хорошего стиля» программирования касаются структуры программы [1].

Избегайте кратных END.Хорошее правило при программировании на Delphi – предусматривать отдельный END для каждого оператора DO. Это позволяет компилятору обнаружить некоторые ошибки, а пользова­телю помогает понять подразумеваемую последовательность выполнения.

Предусматривайте ELSE для каждого THEN.В условных предло­жениях должно быть поровну THEN и ELSE. Даже если ненужно ничего делать в случае ELSE, следует предусмотреть пустой оператор. Это под­скажет пользователю, что случай ELSE также рассматривался, и поможет понять последовательность действий.

Отметим, что этому правилу не обязательно следовать, если будет принято предложение полностью отказаться от вложенных условных предложений и конструкции ELSE. Важно помнить о необходимости быть последовательным; если в модуле имеется хоть одно ELSE, значит, во всех условных предложениях должны быть ELSE.

Выполняйте исчерпывающие проверки.При анализе входного пара­метра, ожидаемое значение которого должно быть 1, 2 или 3, не следует предполагать, что его значение равно 3, если оно не равно ни 1, ни 2.

Не пишите изменяющих самих себя программ.Языки высокого уровня почти исключили эту практику. Однако такие конструкции, как пе­ременные типа метки в Pascal, позволяют изменять оператор GO TO, и в таком качестве их нужно избегать.

Будьте осторожны с внутренними процедурами.Если программист решает использовать внутренние процедуры в таком языке, какPascal, он должен быть внимательным в отношении правил определения областей доступности имен, которые позволяют ссылаться на внешние процедуры.

По возможности используйте рекурсию.Рекурсивные модули – простой путь решения многих сложных вычислительных задач. Чтобы научиться мыслить рекурсивно, требуются определенные усилия, но после более близкого знакомства с этой концепцией рекурсия становится удоб­ным средством реализации алгоритмов для сложных структур. Рекурсия желательна при обработке структур данных, определенных рекурсивно, например деревьев, представляющих перечень необходимых материалов, или сложных списковых структур, графов или решеток, для которых неиз­вестны или изменяются длина и глубина. Источник силы рекурсии состоит в том, что она снимает с программиста бремя забот об управлении памя­тью и превращает «перебор с возвратом» (т.е. возврат по дереву и затем проход вниз по другой ветви) в совсем простой процесс.

Рекурсию, однако, не следует применять там, где вполне достаточно простой итерации. Например, рекурсивно определенная математическая функция факториал (Х!=Х*(Х–1)!) часто используется для иллюстрации рекурсивных методов программирования. Поскольку, однако, при ее вы­числении не требуется перебора с возвратом, проще всего запрограмми­ро­вать эту функцию с помощью итерации (цикла DO), а не рекурсивной про­цедуры.

3.3. Тестирование и верификация программ

Тестирования и верификация программ, хотя и непосредственно не являются этапами разработки программы, однако являются неотъемлемой частью создания ПО и прямо влияют на надежность программы.

Тестирование – деятельность, выполняемая для оценки и улучше­ния качества программного обеспечения. Эта деятельность, в общем слу­чае, базируется на обнаружении дефектов и проблем в программных сис­темах. В соответствие с IEEE Std 829-1983, тестирование – это процесс анализа ПО, направленный на выявление отличий между его реально существующими и требуемыми свойствами (дефект) и на оценку свойств программного обеспечения.

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

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