И. Соммервилл - Инженерия программного обеспечения (1133538), страница 98
Текст из файла (страница 98)
Эти версии выполняются параллельно на отдельных компьютерах. Результаты их работы сравниваются с помощью системы согласования, результаты какой-либо версии, не совпадающие с двумя другими или не полученные вовремя, отвергаются. Это наиболее часто используемый подход к созданию отказоустойчивого программного обеспечения. Он используется в системах сигна.
18. Разработка критических систем 379 лизации на железных дорогах, в авиационных системах и в системах защиты реакторов [14, 15, 29в]. 2. Бввкк ввгаиаявамнкя. В этом методе каждый программный компонент содержит тест„проверяющий его работу. Компонент также имеет подпрограмму, которая повторяет вычисления, если тест обнаружил неправильное выполнение.
Но повторные вычисления выполняются др)тим модулем компонента, который намеренно построен на другой интерпретации требований, предъявляемых к компоненту. Таким образом, компонент имеет несколько модулей (блоков восстановления), выполняющих одинаковые функции, но реализующих разные алгоритмы. Поскольку модули выполняются последовательно, в рамках данного подхода пет необходимо.
сти дублировать аппаратные средства. Метод блоков восстановления описан в работах [288, 289, 8*). Оба описанных подхода используют несколько разных архитект)р и программных реализаций. Когда для реализации одной и той жс спецификации используется несколько различных подходов, естественно считать маловероятной ситуацию. когда различные версии ПО будут иметь одни и те же ошибки. Достичь различия между разными версиями ПО можно также следующими способал1и. 1. Вкзючение в системную спецификацию требований использовать при проектировании различные подходы.
Например, можно потребовать, чтобы одна команда разработчиков использовала объектно.ориентированное проектирование, а другая -функциональноориеитированное. 2. Включение в спецификацию требований, чтобы для реализации били нспользова. ны различные языки программирования. Например, в системе с тремя версилми ПО для написания разных версий можно использовать языки программирования Аг)а, С++ и )ата. 5. Использовать при разработке системы различимо инструментальные средства и среды разработки. 4.
Можно потребовать использования конкретных алгоритмов для реализации определенных системных компонентов. Это, конечно, ограничивает свободу разработчиков и может стать причиной др)тих проблем. Каждал команда разработчиков должна работать со своей спецификацией (так называемой Ч спецификацией), которую получают из общей спецификации системных требований [15). Команды разработчиков каждой версии ПО должны работать изолированно, чтобы уменьшить вероятность появления в версиях одинаковых ошибок, Многообразие версий, конечно, увеличит общую безотказность системы.
Однако ряд экспериментов показывает: предположение о том, что различные команды разработчиков не сделают одинаковых ошибок, не всегда справедливо [200, 58, 214). Различные коллективы разработчиков мокнут сделать одни и те жс ошибки из.за одинаковых интерпретаций требований или вследствие того, что они независимо друг от др)та используют один и те же алгоритмы. Метод блоков восстановления уменьшает вероятность общих ошибок, поскольку блоки восстановления реализуют разные алгоритмы. Слабость обоих методов отказоустойчивости состоит в том, что опи основаны на предположении правильности системной спецификации. Однако во многих случаях 380 Часть?У. Критические системы спецификации неполны или содержат ошибки.
Один из путей уменьшения возможных ошибок в общей спецификации состоит в независимой разработке У-спецификаций и реализации их с помощью различных нотаций. Тогда один коллектив разработчиков может работать с формальной спецификацией, другой — с моделью системы, описывающей ее состояния, а третий — с требованиями на естественном языке. Это поможет избежать ошибок интерпретации требований, ио нс освободит от ошибок в самой спецификации.
18.4. Проектирование безопасных систем Общее правило проектирования ПО, критического по обеспечению безопасности, основывается на сокрытии информации и простоте программного обеспечения. Те части системы, которые являются критическими, должны быть изолированы от других частей системы. Этого можно достигнуть с помощью абстракций данных и управления физическим разделением системы. Критическая часть программного обеспечения может выполняться на отдельном компьютере с минимальными связями с другими частями системы.
Программное обеспечение, критическое по обеспечению безопасности, должно быть простым настолько, насколько возможно. Потенциально подверженных ошибкам конструкций языков программирования, рассмотренных выше в главе, нужно избегать везде, где возможно. Они даже могут быть запрещены стандартом разработки критических систем. В некоторых случаях можно разработать требование, чтобы программы писались на подмножестве языка, в котором исключены ненадежные конструкции.
Такие подмножества были разработаны для языков Моди1а-2, Аг1а и Рааса!, и, вероятно, будет разработано безопасное подмножество языка 1ага. Отказоустойчивое программное обеспечение должно исполыоваться только в системах. критических по обеспечению безопасности, когда состояния не защищены и безопасность системы зависит от работоспособности. Методы, повышающие устойчивость к отказам, усложняют создание и проверку программного обеспечения. Как упоминалось в предыдущем разделе, исследования показали, что использование Х-вариантного программирования не всегда обеспечивает безотказность систем, поскольку при разработке ПО на основе одной спецификации, различные команды разработчиков могут делать одни и те же ошибки. Избыточность программного обеспечения пе дает теоретически предсказанного увеличения системной безотказности.
Кроме того, если спецификация некорректна, все версии ПО будут иметь одинаковые ошибки. Это не означает, что Х-вариантное программирование бесполезно. Опо может уменьшать абсолютное число отказов системы. Если предположить, что общие ошибки будут обнаружены в различных версиях системы, то число отказов будет уменьшено. Кроме того, считается, что Х.вариантное программирование увеличивает доверие к безотказности системы [401. Альтернативой использованию Х-вариантного программирования, которое усложняег систему, является создание максимально простых (насколько зто возможно) систем и выделение дополнительных ресурсов для проверки правильности системы.
Простота программного обеспечения снижает вероятносгь ошибок Это также сокращает обычно высокие затраты на проверку безопасности системы, поскольку только сравнительно небольшая часть ПО бгдет связана с обеспечением безопасности. 18. Разработка критических систем 381 ':.'„" КЛЮЧЕВЫЕ ПОНЯТИЯ. л: ..л ';ч':.:...-г ':: . " '. -": .:;:,'.г; „'!:~„' „",:йк?кбгф .". эгзатгя':9~м'-А";~",-'1л3: пй'-" цг,'-"~1шфю~гэап ':-.,~!гс"т «й,еччцгпгщчФ ~э ЬД";;.флеааюййльнаЯ'надшюсшотьггпРогРайм мшквт-быта4ктигйУта пУтеэггискаккюййк!тоб1ибйк и вклю'-'; "чйншь,сйейсш,'опшзоуртойчйиэсти,ъкоуорые', обеспечивши;лродшйюниб.чйунщзу~нйроцащш сис-х , ',э- лемы дчшкцдошш уого, д~срйЪ|и в,системе йриведуг к;сбою,;-' ';;:" .-:,'-„';-:у-;:,„уъ-"4~; 3;-,.
6Ъ4';""Йешпщгпш-пршраммшяыюнструиции й'методы ''нвщтимер операторы 'беэуйовзйшяо':;:~тсерехода, ': ~:;::-'11УГУЧШИРЕЛй, РЕКУГтСИЯ, НаСаззшаНИЕ И,ШГСЛЦ.СзШШВВЮПШйаиитай, 8О,Савей-;ПРИРОДа ЫЩУт,ГЮСЛУ-т житьпричййой ошибок: Онитгедожкньыйисгюльъзоваися йри ратрабоицнагшжных'систем.,'. г фь;;9:::Пурйэыйсв, :ОбЕСПЕЧЕ~ци';?уСШйЧИВав;К-'Сбсяы',::МОжет ПрОцаивать 'фужцИОНйрОВацнв, НВСМОтря ' -я'."",,'-'.'~вайбкщкоторыв вызйвиот сбоксистемыгй<'-'„-',, -!':*;;:,, г к ь-; й::, .- '-л; ' ., ъ,:,'"':,Кйрсьтзвует четыре::аспекта 'отазоустойчивасти ПО, а.именйо'' рбнеружние ошибок и сбоее, по;.-.рвшлиащия сбоев .восстановление системы и усцэанение причин'сбоев.
1;е".мазо~еснеехпРРгРаммиРование- зФ'метод ппийаммиРованив, котоРый объединпет пРовеРкУ байт? й.,прарамм на'найичие ошибок,и'их локализацию. Ошйбмьопредешгются ранее, чем они приведут к ;;- '- сбою системы. ' , шшод безопасного ярогрвммирования использует средства обработе исклочительных ситуаций, . существующие в тшзи языкак программирования, как жатв и С++. ° "";., Рквариантное программирование и блоки воссуанавления являются методами построения отказа- ,, -.," устойчивых архитектур,' где устойчивость к сбоям обеспечивается дублированием программных и „Г, аппаратных средств. Упражнения 18.1. Объясните, почему наследование является конструкцией, потенциально приводящей к ошибкам, и почему использование механизма наследования необходимо минимизировать прн разработке крн. тнческих объектно-ориентированных систем. 18.2.
Если рекурсия- конструкция, приводящая к ошибкам, спроектируйте класс объектов, реализую- щий дтюичные деревья и работу с ними беэ использования рекурсии. 18.3. Опишите три метода безопасного программирования, которые уменьшают вероятность того, что ошибки ПО приведут к сбоям системы.
16.4. Кратко опишите стратегии прямого и обратного восстановления систем. Почему обратное восста- новление используется чице, чем прямое? Приведите два класса систем, где может использовать. ся обратное восстановление. 18.5. Какие предварительные условия должны соблюдаться, прежде чем может быть выполнено прямое восстановление отказоустойчивой системы? 8оэможно ли прямое восстановление в интерактивных системах' 18.8. Спроектируйте абстрактный тип данных илн объектный класс йоЬпвцэаг (устойчивый список), который реализует прямое восстановление в связанном списке.
Для этого используйте прямые и об. ратные ссылки между соседними элементами списка. 18.7. Опишите обстоятельства, когда при построении программных систем управления необходимо ис- пользовать отказоустойчивую архитектуру, и обьясните почему. 382 Честь Ж. Критяческие системы 18.8. Предложим, что управливцее программное обеспечение для лучевой терапии (используется в лечении больных раком пациентов) реализуется с помощью М-вариантного программироеания.
Прокомментируйте, правильное ли зто решение или нет. 18.9. Укажите дзе причины, почему различные версии системы а М-вариантных системах могут дать одинаковый сбой. 18.10. Обсудите проблемы разработки и сопровождения 'безостановочных" систем типа программного обеспечения телефонной станции. Как можно использоаать при радзаботке таких систем исключительные ситуации? 18,11. Использование метадое разработки безопасного программного обеспечения, обсуждавшихся в этой главе, очевидно, требует значительных дополнительньж затрат. Какие дополнительные затраты можно оправдать, если за 18-летний срок службы системы будут сохранены 100 жизней? Были бы оправданы те же самые затраты, если будут сохранены 10 жизней? Какова цена жизни? Правомочно и этично ли в таких ситуациях проводить оценку затратч Верификация и аттестация ПО Цель настоящей главы — дать общее представление о верификации и аттестации программного обеспече ния и познакоиить с методами статической верифи.
кации. Прочитав эту главу, вы должны: Я знать отличие между верификацией и аттестацией ПО; П познакомиться с инспектированием программ- эффективным методом выявления ошибок в про граммах; 0 понять, почему статический анализ программ яв. ляется одним из основных методов верификации; 0 познакомиться с разработкой программ методом "чистая комната" и знать, почему этот метод ока.
зывается эффективным. 19.1. Планирование верификации и аттестации 19.2. Инспектирование программных систем 19.3. Автоматический статический анализ программ 19.4. Метод "чистая комната" 386 Яасть У. Верификация и аттестация Верификацией и аттестацией называют процессы проверки и анализа, в ходе которых проверяется соответствие программного обеспечения своей спецификации и требованиям заказчиков. Верификация и аттестация охватывают полный жизненный цикл ПО -они начинаются на этапе анализа требований и завершаются проверкой программного кода на этапе тсстирования готовой программной системы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
