Главная | Обратная связь | Поможем написать вашу работу!

Листинг 19.1. Статический анализ, выполненный анализатором LINT

⇐ ПредыдущаяСтр 137 из 202Следующая ⇒

138% more lint_ex.c

#include <stdio.h>

printarray (Anarray)

int Anarray;

{

printf("%d",Anarray);

}

main()

{

int Anarray[5]; int i; char c;

printarray(Anarray,i/c);

printarray(Anarray);

}

139% cc lint_ex.c

140% lint lint_ex.c

lint_ex.c(10): warning: с may be used before set

lint_ex.c(10): warning: i may be used before set

printarray: variable # of args.lint_ex.c(4)::lint_ex.с(10)

printarray, arg. 1 used inconsistently lint_ex.c(4)::lint_ex.с(10)

printarray, arg. 1 used inconsistently lint_ex.c(4)::lint_ex.с(11)

printf returns value which is always ignored

В строке 139 выполняется компиляция С-программы, в результате которой компилятор не обнаружил ни одной ошибки. В следующей за ней строке следует вызов анализатора LINT, который находит ошибки и предоставляет отчет.

Статический анализатор выявил, что используемые скалярные переменные С и i не инициализированы, функция printarray вызывается с другим количеством аргументов, чем указано при ее определении. Также обнаружено непоследовательное использование первого аргумента в функции printarray, кроме того, анализатор обнаружил, что значение функции нигде не используется.

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

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

19.4. Метод "чистая комната"

При разработке ПО методом "чистая комната" (cleanroom) для устранения дефектов используется процесс строгого инспектирования [239, 75, 219, 284]. Цель данного метода– создание ПО без дефектов. Название "чистая комната" взято по аналогии с производством кристаллов полупроводников, где выращивание кристаллов без дефектов происходит в сверхчистой атмосфере (чистых комнатах). Я описываю этот метод в данной главе, поскольку согласно ему в процессе разработки ПО при проверке соответствия системных компонентов спецификациям тестирование заменяется инспектированием.

На рис. 19.5 представлена модель процесса разработки ПО методом "чистая комната", построенная на основе описания, приведенного в работе [219].

Рис. 19.5. Процесс разработки ПО методом "чистая комната"

В разработке ПО методом "чистая комната" можно выделить пять ключевых моментов.

1. Формальная спецификация. Длясоздаваемой системы разрабатывается формальная спецификация. Для записи спецификации используется модель состояний, в которой отображены отклики системы на стимулы.

2. Пошаговая разработка. Разработка ПО разбивается на несколько этапов, которые выполняются и пррверяются методом "чистая комната" независимо друг от друга. Этапы определяются совместно с заказчиком на ранних стадиях процесса создания программного продукта.

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

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

5. Статистическое тестирование системы. На каждом шаге разработки проводится тестирование статистическими методами, позволяющими оценить надежность программной системы. Статистические методы рассматриваются в главе 21. Как показано на рис. 19.5, статистические тесты базируются на операционном профиле, который разрабатывается параллельно созданию спецификации системы.

Пошаговая разработка ПО, схема которой показана на рис. 19.6, описана в главе 3. Выполнение каждого этапа определяется пользователями. На каждом отдельном этапе получается вполне работоспособная система, но с ограниченными возможностями. Пользователи возвращают отчеты о функционировании системы вместе с предложениями необходимых изменений. Пошаговая разработка ПО позволяет уменьшить количество ошибок, возникающих из-за изменений требований заказчика.

Рис. 19.6. Процесс пошаговой разработки

Если спецификация определена как единое целое, изменения в требованиях заказчика (которые неизбежны) влекут за собой изменения в спецификации и в процессе разработки. В этом случае спецификация и системная архитектура должны постоянно пересматриваться. В методе пошаговой разработки спецификация на каждом шаге фиксирована, хотя требования по изменению других частей системы принимаются. Каждый шаг разработки завершается готовым программным продуктом.

На первых этапах пошаговой разработки ПО методом "чистая комната" реализуются наиболее критические для заказчика системные функции. Менее важные системные функции добавляются на последующих этапах. Таким образом, у заказчика есть возможность проверить и испытать систему (ее основные функции) до окончательного завершения разработки. Если возникают проблемы с требованиями, заказчик сообщает об этом группе разработчиков и запрашивает новую версию продукта.

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

Процесс разработки ПО методом "чистая комната" планируется таким образом, чтобы обеспечить строгое инспектирование программ. Спецификация системы представлена моделью состояний, которая через ряд последовательных моделей постепенно преобразуется в исполняемую программу. Этот подход к разработке ПО описан в главе 3. Инспектирование программ дополняются строгими математическими доказательствами согласованности и корректности преобразований.

Обычно разработкой больших систем методом "чистая комната" занимаются три группы разработчиков.

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

2. Группа разработки. Занимается разработкой и проверкой ПО. При проверке используется структурированный формальный подход, основанный на инспектировании кода, подкрепленный доказательством правильности работы системы.

3. Группа сертификации. Занимается разработкой статистических тестов, применяемых после окончания разработки ПО. Все тесты основаны на использовании формальной спецификации. Контрольные тесты разрабатываются параллельно с созданием системы и используются для сертификации надежности ПО.

В результате использования метода "чистая комната" готовый программный продукт содержит крайне мало ошибок и его стоимость меньше, чем у разработанного традиционными методами. В работе [75] описано несколько успешных проектов, разработанных методом "чистая комната", с неизменно низким процентом ошибок в разработанных системах. Расходы на эти проекты сравнимы с расходами на проекты, которые разрабатывались с использованием традиционных методов.

В процессе разработки методом "чистая комната" оказывается рентабельной статическая проверка. Огромное количество дефектов обнаруживается еще до исполнения программы и исправляется в процессе разработки ПО. В статье [219] утверждается, что во время тестирования проектов, которые разрабатывались с использованием метода "чистая комната", в среднем обнаруживается только 2,3 дефекта на тысячу строк исходного кода. В целом расходы на разработку не увеличиваются, так как сокращаются расходы на тестирование и исправление ошибок в разрабатываемой программной системе.

КЛЮЧЕВЫЕ ПОНЯТИЯ

• Верификация и аттестация программных систем – разные процессы. Цель верификации – показать, что программа соответствует своей спецификации. Цель аттестации – показать, что программа работает именно так, как нужно пользователю.

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

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

• Инспектирование программ является эффективным методом обнаружения ошибок в программе. Цель инспектирования – определить местоположение ошибок в программах. Процесс инспектирования должен проводиться в соответствии с технологической картой дефектов.

• Системная проверка кода программы проводится небольшой группой. Членами группы являются: руководитель группы (или координатор), автор (создатель) кода, рецензент, представляющий код во время инспектирования, и инспектор, проверяющий код с помощью различных тестов.

• Статические анализаторы – это программные инструментальные средства, которые анализируют исходный программный код. С их помощью можно выявить такие ошибки, как неиспользуемые разделы кода и необъявленные переменные.

• Разработка ПО методом "чистая комната" основана на статических методах проверки программ и статистическом тестировании для сертификации надежности системы. Метод успешно используется в процессе разработки систем с высоким уровнем надежности.

Упражнения

19.1. Обсудите различия между верификацией и аттестацией и объясните, почему аттестация является более сложным процессом.

19.2. Объясните, почему не нужно устранять все дефекты в программе перед ее поставкой заказчику. До каких пор следует тестировать программу, чтобы удостовериться, что она соответствует своему назначению?

19.3. Объясните, почему инспектирование программы является эффективным методом обнаружения в ней ошибок. Какие типы ошибок нельзя обнаружить методом инспектирования?

19.4. Разработайте технологическую карту наиболее распространенных ошибок (не синтаксических), которые не обнаруживаются компилятором, но которые можно выявить при инспектировании программы. При составлении таблицы используйте свои знания Java, C++, С или других языков программирования.

19.5. Составьте список вопросов, ответы на которые позволяют во время проведения статического анализа обнаружить ошибки в программах, написанных на языках Java, Ada и C++. Сравните свой список со списком, представленным в табл. 19.2.

19.6. Составьте отчет, в котором бы приводились преимущества метода "чистая комната", а также связанные с ним расходы и риски.

19.7. Менеджер решил для оценки специалистов в качестве исходных данных воспользоваться отчетами о результатах инспектирования программ. В отчетах содержится информация о том, кто совершил и кто обнаружил ошибки в программе. Этичны ли действия менеджера? Этично ли заранее проинформировать персонал об этом? Как это решение может повлиять на процесс инспектирования?

19.8. Один из подходов, широко используемых при тестировании ПО, состоит в тестировании системы до тех пор, пока не будут израсходованы все средства, выделенные на тестирование. Затем система передается заказчикам. Обсудите этичность такого подхода.

⇐ Предыдущая 132 133 134 135 136137138 139 140 141 Следующая ⇒