И. Соммервилл - Инженерия программного обеспечения (1133538), страница 113
Текст из файла (страница 113)
Для этого необходимо пройти в обратном порядке все ветви, идущие от данного опасного состояния, и рассмотреть послелнее присвоение у всех переменных состояния на каждой ветви. Предыдущие вычис- 4о8 Яасть У, Верификация и аттестация ления (например, 1.й оператор й на рис. 21.6) можно не рассматривать. В атом примере нам необходимо рассмотреть набор возможных значений переменной снггап10ова (текущыг доза) непосредственно перед выполнением метода вбгпгп(в(ег(пвнйп (регулирование инсулина).
Рис. 21.б. Локогптельеомо бегоппаоппш лгпподом оог п)готиопого В представленном на рис, 21.6 доказательстве вызов метода абпйп)в1аг(пвнйп возможен в трех ветвях программы. 21. Аттестация критических систем 439 1. Ни одно из ответвлений 2.го оператора й нс выполняется. Данная снтлщня имеет место, если значение переменной сигептооэе больше или равно ш!пвпцгпОове (минимальная доза) н меньше или равно <пахОове (максимальная лоза). 2. Выполняется ветвь й>еп 2.го оператора а В этом случае сцггеп10оэе присваивается значение нуль.
Здесь иостусловием будет сцггеп)Ооэе = О. 3. Выполняется ветвь е)ве 2-го оператора 14 В этом случае соггеп)0оэе присваиваетсл значение техОоэе. Постусловнем этой ветви будет сцггеп10ове = шлхОове. Во всех трех случаях постусловис противоречит предусловик> опасного состояния, поэтому система безопасна. 21.3.3. Обеспечение безопасности в процессе разработкиПО В начале главы уже поднимался вопрос о важности обеспечения качества процесса разработки системы.
Данный вопрос важен для любых критических систем, а особенно для систем, критических по обеспечению безопасности, па что сеть >гвс причины. 1. Аварийные ситуации — редкие события в критических системах, поэтому практически невозможно смоделировать их во время тестирования системы. 2. Трсбовю<ия безопасности, как указывалось в главе 16, иногда не исключают ненадежно. го повеления системы. Посредством тестирования и других процессов аттестации ис. возможно полностью доказать соответствие системы требованиям безо наг ности.
Из модели жизненного цикза разработки систем с критическими трсбовщшями безопасности следует, что безопасности необходимо уделять внимание иа протлжснпи всех этапов процесса разработки ПО. Поэтому в процссс разработки критической системы необходимо включить мероприятия по обеспечению безопасности разрабатываслюй системы и среди них перечисленные ниже. 1.
Создание системы регистрации и иаблюлеиия, которал озтлсжшюст опасности в системс, начинал с этапа предварительного анализа рисков и закапчивю< тестированием и аттестацией систел<ы. 2. Назначение ишкенсров, которые будут отвечать ж> все аспекты бсзопасп<к.-гп системы. 3. Всесторонний анализ безопасности на протяжении всего процесса разработки. 4. Создание системы сертификации безопасности, посредством которой атгссгуются компоненты с критическими требованиями безопасности.
5. Использование четко рззработаниой системы управления коифштрзписй (см. главу 29), которая необхолима лля отслеживания всех связанных с системной безопасностью документов и их согласования с соответствующей технической лолумситацисй. Чтобы показать, что представллст собой процесс аттестации систем, критических по обеспечению безопасности. рассмотрим процесс анализа рисков, который лвлястгл важной частью разработки таких систем. Напомним, что в процессе анализа рисков, рзссмотрснно. го в главе 17, определлются и анализируются системные риски.
Анализ рисков выполняется на протяжении всего процесса разработки системы, поэтому необходимо быть уверенным, что на всех этапах процесса разработки риски расс>ютрсиы должным оГ>разом. 440 'Часть тг. Верификация и аттестация Если в процессе разработки четко определены внутренние риски системы. то далее доказывается, что эти риски не могут привести к аварийным ситуациям.
Это дока. зательство может быть подкреплено доказательством безопасности, рассмотренным в разделе 21.3.2. Основным документом безопасности является документ, в котором проанализированы и отслежены все риски, определенные в процессе специфицирования системы. Этот документ затем используется на всех этапах процесса разработки ПО для оценки того, как на каждом этапе разработки учитываются риски. Упрощенный пример анализа рисков, выполненный для системы инъекции инсулина, показан во врсзкс 21.1.
~ Днализ рисков' б"'..4ктззк,'тй':".~мнкйнВ":.",. зг,.'" '.:;;.гу -.*.Ър'. 4 Пенать20Я299;~,""!чхйзз1 1- ~ Опасное собыпю "- '.дцФб- "' з' зб". ': ' 'Передозироака шюулйнач" та ж: чз..'а.'.'«,'~гзжЬ1 ьь ! а' ~ дерэео опшзов шйидшийа::: °, -:-:, -:,,дд. Алга 240!.99.
докумэгйт Анализ сбоее, стр. б ; Дерезе отказов лостдоено -:-;„.,„-,„.,':, -" Джейн Вильнмс и Билл Смит,;., ' ':3,.„:-;У,':-,гг 1 дерево ожазое проверено; ',,эньгг41$ь;*:;:,„=цдд: дага 20 01.99, прщерил джеймс Вра1м'' ',.'.".~уз~',,ж-',! :, Требоааниябезопасностисистемы.,:,';,,;... ':,„,„,:,';,,',," ' '„;. ',„'„'::.', „"".,.' .'.-,„,.~",„'„'„ ~! ~ ~ ~ ~ ~ ~ ~ ы ! ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ !~ ~ ~ ~ ~1 ! ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ! ~ ~ ~ г ~ ~ ~~ ~ ~ ! ~ « ~ ~ ~ ~ ~ ~ ~ | ~ ~ ~ т ~ ~ ~ ~ 1 ~ ~ !~~~ ~ ~~ ~ ~ ~ ~ ~~ ~ ~ ~ ~ ~~ ~ ~ ! ~ ~ ~~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~~ 1 ~ ~ ~ ~ ~ ~ ~ ~ т ~ ~~ ~ ~ ! ~ ~ | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ с ~ г ~ ~ ~ ~~ ~ ~ ~ |~ ~ ~ 1. В системе должны быть средства дпя семотестироаання Йстемы датчиков, часоа и'средств инъ- ' , 2: Самопроверка ПО должна выпеваться оййнттаз в мьйнучу.,'г '- „„„ 3. Если при проверке ПО обшкруживаютсл ошибки з каац-лнбео 'компонентах системы, то выдаетсэ звуковое предупреждение, а на мониторе отображается название компонента, е котором обнаружены ошибки.
Инъекция'йнсулина при этом првютайаэлиэается:- "" ' '. 4. В системе должйа,бить воэможность ручной корректировки дозы, которая-щюзоаяет юльзозэсте-' . , ' лю аменять рассчитанную ранее дозу инсулина. б. Ноеое значение дозы даано быть не больвю устанавленнов предельного значений.
Таэа пршия ньи значений макет быль нескопыо, если система вонфштрнруатся медицинским пе1юонзлюм. " ° Как следует из приведенного примера анализа рисков, желательно назначить ответственное лицо (специалиста), который отвечал бы за безопасность будущей системы, но не участвовал в ее разработке. Задача такого специалиста — следить, чтобы все необходимые мероприятия для обеспечения безопасности были выполнены и описаны в соответствующих документах. Заказчик системы может также потребовать независимого проверяющего по обеспечению безопасности из сторонней органиэации, который будет отчитываться нспосрсдствеино перед заказчиком.
В болыиинствс случаев отвечать за обеспечение безопасности должны дипломированные специалисты. В Великобритании такими специалистами, как правило, являютсл со- 21. Аттестации критических систем 441 трудники проектных институтов и квалифицированные инженеры. За обеспечение безопасности не должны отвечать малоопытные некомпетентные инженеры. Не следует привлекать для этого и специалистов по программноиу обеспечению.
Возможно, в будущем, в соответствии с более развитыми стандартами процесса разработки критического ПО, потребуется, чтобы инженеры, отвечающие за обеспечение безопасности, были дипломированными специалистами соответствующего профиля. 21.3.4. Контроль безопасности исполнения В главе 18 вы познакомились с понятием "безопасное программирование". В отличие от обычного программирования, при безопасном в програчму добавляются лополпитель. ные операторы для проверки наличия ошибок в системе. Подобная текнологня может использоваться и в системах, критических по обеспечению безопасности.
В программу добавляется контроль«ь<й код, который проверяет ограничения безопасности, и в случае нх нарушения включается обработка исключительной ситуации. Ограничения безопасности можно представить в виде формальных условий. Эти условил являются предикатами, описывающими ограничения, которые должны выполняться перед следующим исполняемым оператором. В системах с критическими требованиями безопасности, формальные уело.
вия должны создаваться иа основе спецификации требований безопасности. Такие ограничения безопасности более полно обеспечивают надежное поведение системы. Особое значение имеют условия для обеспечения безопасности взаимодействий кол<- попентов системы, Например, в системе ипъсдции инсулина при регулировании дозы в блок инъекции может поступить сигнал па увеличеннук< дозу инсулина (листинг 21.2). Максимально допустимое увеличение дозы инсулина можно определить заранее и вклю. ч ить в систему в виде формального условия. Листинг 21.2. Управление инъекцией инсулина вгаг1с код<) асЪРп1вгег1пвп11п ( ) с)<гомэ яагесуехсергдоп ( Рпс жах1псгетепгв = 1пви11пршар.квхрове / 8< Рпс 1псгемепгв = 1пви11прпжр.спггепсрове / 8; // проверка условия сиггепгрове с= 1пви11пРожр.а<ахрове 11 (1пвп11пРшар.спггеперове > Хпвц1(пРшар.жахрове) С)<гом пем яа1есуЕхсергдоп (Ршар.с)овецдд)<)< е1ве Йог (зпс 1 = 1; 1 <= Рпсгемепсв< з++) ( депегагеЯТдпа1 ( ); 11 (з > иах1псгежепсв) Г)згом пЕм Яагегуехсергдоп (Рцжр.
1псоггесг1псгшаепгв) ) ) // адлпп1вгег1пвп11п Если при вычислении значения перел<виной сцггеп!Розе (текущая доза) возникает ошибка, то происходит прерывание программы. Сигнал на чрезмерную дозу инс)лина не выдается, так как контрольное условие гарантирует, что система выласт дозу, не большую, чем <пвхРовв (максимальная доза). В принципе большая часть кода с условиями безопасности может быть создана автоматически с помощью препроцессора обработки условий. Однако такой способ не всегда приемлем, часто код контрольных условий создается вручную.
442 'Часть лг. Верификация и аттестация 21.4. Оценивание защищенности ПО В иастоящсс время оцсниванис защищснности системы приобретает большое значснис. поскольку всс чаще системы объединяются посредством 1нгсгпек Как ужо отмечалось в главс 16, требования защищенности в некоторых отношениях подобны требованиям безопасности.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
