И. Соммервилл - Инженерия программного обеспечения (1133538), страница 103
Текст из файла (страница 103)
Например, анализаторы мокнут обнаружить необъявленные переменные, однако они не в состоянии определить неправильные присвоения, В языках со слабым контролем типов, например С, статические анализаторы могут определить функции с неверным количеством и типом аргументов, однако не способны распознать ситуации, когда в функции пропущен неверный аргумент правильного типа. Конечно, для таких языков, как С, статический анализ является эффективным методом обнаружения ошибок. Но в современных языках программирования, например )ата, из языка удалены конструкции, способствующие появлению многих ошибок. Все переменные должны быть объявлены, отсутствуют операторы безусловного перехода, вследствие чего маловероятно случайное создание неиспользуемого кода, и осуществляется автоматическое управление памятью.
Такой подход к устранению ошибок более эффективен для повышения надежности программ, чем любые методы обнаружения о~вибок Поэтому для )ага-программ использовать автоматический статический анализ нерентабельно. 19.4. Метод "чистая комната" При разработке ПО методом "чистая комната" (с1еапгоош) для устранения дефектов используется процесс строгого инспектирования [259, 75, 219, 284). 1\ель ллшюго метода— создание ПО без дефектов. Название "чисгая комната' взято по аналогии с производством кристаллов полупроводников, где выращивание кристаллов без дефектов происходит в сверхчистой атмосфере (чистых комнатах). Я описываю этот метод в данной главе, поскаль; ку согласно ему в процессе разработки ПО при проверке соответствия систелшых компонентов спецификациям тестирование заменяется инспектированием.
На рис. 19.5 представлена модель процесса разработки ПО методом "чистая комната", построенная на основе описания, приведенного в работе (219]. Рш; 1 9 5. Процесс)тзула бом хи ПО лияыдаи "чилтпа хамка тп " В разработке ПО методом "чистая комната" можно выделить пять ключевых моментов. 1.
Фоуилпльнпа еяеци(оикпция. Лля создаваемой системы разрабатывается формальная спецификация. Для записи спецификации используется модель состояниИ, в которой отображены отклики системы на стимулы. 400 хуасть У. Верификация и атгвстация 2. Пошаговая ргмрабгника. Разработка ПО разбивается на несколько этапов, которые выполняются и проверяются методом "чистая комната" независимо друг от друга. Этапы определяются совместно с заказчиком на ранних стадиях процесса создания программного продукта, 3. Струкнгууним п)гогунм)эгироввииг. Используется только ограниченное количество управляющих конструкций'и абстракций данных. Процесс разработки программы — зто процедура поэтапной детализации спецификации. 4.
Статическая вфификацил. Разрабатываемое ПО проверяется статическим методом строгого инспектирования ПО. Для модулей или отдельных элементов тестирование кода не проводится. 5. Статианическав тгсти~юваиие аиимим. На каждом шаге разработки проводится тестирование статистическими методами, позволяющими оценить надежность про. граммной системы, Статистические методы рассматринаются в главе 21. Как показано на риш 19.5, статистические тесты базируются на операционном профиле, который разрабатывается параллельно созданию спецификации системы. Пошаговая разработка ПО, схема которой показана нз рис. 19.6, описана в главе 3.
Выполнение каждого этапа определяется пользователями. На каждом отдельном этапе получается вполне работоспособная система, ио с ограничениымн возможностями. Пользователи возвращают отчеты о функционировании системы вместе с предложениями необходимых изменений. Пошаговая разработка ПО позволяет уменьшить количество ошибок, возникающих нз-за изменений требований заказчика. нснроезнне шцнн Запрос на изменение трабоееннй Рис. 19.6. Провггс пошаговой раг)габотки Если спецификация определена как единое целое, изменения в требованиях заказчика (которые неизбежны) влекут за собой изменения в спецификации и в процессе разработки.
В этом случае спецификация и системная архитектура должны постоянно пересматриваться. В методе пошаговой разработки спецификация на каждом шаге фиксирована, хотя требования по изменению других частей системы принимаются. Каждый шаг разработки завершается готовым программным продуктом. На первых этапах пошаговой разработки ПО методом "чистзл комната" реализуются наиболее критические для заказчика системные функции.
Менее важныс системные функции добавляются на последующих этапах. Таким образом, у заказчика есть возможность проверить и испытать систему (ее основные функции) до окончательного завершения разработки. Если возникают проблемы с требованиями, заказчик сообщает об этом группе разработчиков и запрашивает новую версию продукта. Таким образом, наиболее важные для заказчика системные функции проверяются наибольшее количество раз. По мере добавления в систему новые функции комбинируются с уже имеющимися.
и интегрированнан система тестируется. Поэтому те части системы, 19. Верификация и аттестация ПО 401 которые созданы на первых этапах разработки, на каждом иэ последующих этапов проверяются еще раз с помощью других контрольных тестов. Процесс разработки ПО методом "чистая комка Ы' планируется таким образом, чтобы обеспечить строгое инспектирование программ. Спецификация системы представлена моделью состояний, которая через ряд последовательных моделей постепенно преобра. зуется в исполняемую программу. Этот подход к разработке ПО описан в главе 3. Инспектирование программ дополняются строгими математическими доказательствами согласо. ванносги и корректности преобразований.
Обычно разработкой больших систем методом "чистая комната" занимаются три группы разработчиков. 1. Группа стмнифпкпнки. Отвечает эа разработку и подаержку системной спецификации. Этой группой создаются спецификации пользовательских требований и формальные спецификации для верификации системы. В некоторых случаях, например после окончания разработки спецификации, эта группа может присоединиться к группе разработки.
2. Группа рпгрпйомпи. Занимается разработкой и проверкой ПО. При проверке используется структурированный формальный подход, основанный на инспектиро. ванин кода, подкрепленный доказательством правильности работы системы. 3. Группп ирмпутккпики. Занимается разработкой статистических тестов, применяемых после окончания разработки ПО. Все тесты основаны на использовании формальной спецификации. Контрольные тесты разрабатываются параллельно с созданием системы и используются для сертификации надежности ПО. В результате использования метода "чистая комната" готовый программный продукт содержит крайне мало ошибок и его стоимость меньше, чем у разработанного традиционными методами. В работе [751 описано несколько успешных проектов, разработанных методом "чистая комната", с неизменно низким процентом ошибок в разработанных системах.
Расходы на эти проекты сравнимы с расходами на проекты, которые разрабатывались с использованием традиционных методов. В процессе разработки методом "чистая комната" оказывается рентабельной статическая проверка. Огромное количество дефектов обнаруживается еще до исполнения программы и исправляется в процессе разработки ПО. В статье (219] утверждается, что во время тестирования проектов, которые разрабатывались с использованием метода "чистая комната", в среднем обнаруживается только 2,3 дефекта на тысячу строк исходного кода. В целом расходы на разработку не увеличиваются, так как сокращаются расходы на тестирование и исправление ошибок в разрабатываемой программной системе. з ,В$ЮЧЕВЫЕ ЙОЙЯТЙЯ'„':„'~~, ~;-,',;ц~р,Э",",,::.',ь..:~;„".,йт,', '.„','„,:,, йп Кацйа ГпцйтВШаГВМ.ПрбГрЭММНМКСйСтЕМ вЂ” раЗНЫЕ ПрОцвССМ. ЦЕЛЬ ВЕрнфнхацИИ вЂ” Шжаб!;;,''В!зать'; что!прогрмма'соответствует свовй'специфиации.
Цель'аттестации-' показать, что про' ' г25ЪФГрамма работает„именно тав;-'-так нужно пользозатеяо ~г!!ос ~."Я! ..;. г е,'б' '1уяан пгетнррвания 'ПО да~жеи содерззпь описание тестируемьп злеменав, график проведения ' ' ' ванна';:описания'йдоцедур управления оГюцессом тестирования, требования к аппаратному йгпрограмцноьгу абеспеиеникуи описание проблем, мпорме могут возникнуть в процессе твсти- Часть Ч. Верификация и аттестация 492 " ',"'":, ° тли айг ий ггртйрфя'~| д~ чвцйчя ° Стациешйе методы 'обнаружчюйия шлйбакйрйму~р'й,анййтзи(тую тестации. ' Цепль'ийспектиромния-," 'определить местоийажеййвчуашибак в "про равания'далвюн проводйпчся"'в'соотввтстийт"сытй(б(блбйййшюй мрто дефбкто, „, 1(1(узчя'че ' ° стютемная промрм кода йрограммы провЩФтсяЪеболйой гр$ййбй."члейамг(т(зуййы'ййй(йа(гш(.
к румищитель группы (ипи юхзрдинатор], автор (сй$атбйь] кодв,трецеизент, прщщавлйх((ййй,:~бдя, ' Ва ВРЕМЯ ИИСПВКШРОВВНИЯ,'И ИНСПЕКтаР ПРОИЕРИаашй фД С ПШВШЦйа Раюйч(НЬИ,'твйтайх, '"-:>-'' ° Статические внаииаторы- это программные ииструментальныв срерств(ц; кбуар((й ,, исжтдный программный кать с их помощью можнй„вывить таюш ошибчки,'"как„нейспольфефые';.: 'ч ' 'РаэрабатКа ПО'МвтОдПМ, ч(йетая Кайиата"'ЙЮВаНаийа СтатИ~ЕСКйХ';Мета((В('ПРГШййхй(ййзупййМ И' статистеВСВм твстироеайии 'для' сеРтификации'надежнастй'"'ьистййы' 'МЙ4''успюшна йапалвзу- ' ется в процессе'разработки систем с высоким уровйем нвдвжностИ~Ф'".':",'-" "'.! эчк Упражнения 19,1.
19.2, 19,3. 19нй 19.6, 19.6. 19.7. 19.В. Обсудите различия между верификацией и аттестацией и объясните, почему апестзция является более сложным процессом. Обыюните, почему не нужно устрвшпь все дефекты в программе перед ее поставкой заказчику. До каких пор следует тестировать программу, чтобы удостовериться, что она соответствует своему назначению? Объясните, почему инспектирование программы является эффекпшным методом обнаружения в ней ошибок. Какие типы ошибок нельзя обнаружить методом инспектирования? Разработайте технологическую карту наиболее распространенных ошибок (не синтаксических), ко.
торые не обнаруживаются компилятором, но которые можно выявшь при инспектировании про. граммы. При составлении таблицы используйте свои знания дача, С++, С или других языков про- граммирования. Составьте список вопрсоов, ответы на которые позволяют во время проведения статического ана- лиза обнаружить ошибки в программах, написанных на языках чача, Ааа и С++. Сравните свой спи- сок со списком, представленным в табл.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
