книги / Надежность программного обеспечения систем обработки данных
..pdfбедные от ошибок, лишь, тогда, когда станут реальностью системы автоматического синтеза программ.
Несмотря на то что накопленный опыт указывает на надежность больших программ, настоятельная потреб ность 1вынуждает пользоваться ими для управления процессами реального времени, хотя и ясно, что это сопряжено с большим риском. Стоимость необнаруженной ошибки может быть очень высокой. Поэтому необходимо создавать столь надежное ПО, насколько это возможно Структурное программирование может быть использовано для разработки систем, сопровождаться жестким тести рованием программ, включая проверку правильности ал горитмов. Такая процедура позволяет конструировать достаточно надежные системы. Однако для получения сверхиадежных систем необходимы дополнительные уси лия. Этого можно достичь введя в программу некоторую избыточность для проверки правильности действий сит стемы. Такой кусок программного обеспечения, который проверяет автоматически собственное динамическое пове дение во время выполнения^ называется самоконтролярующнмся программным обеспечением.
Самоконтролирующееся ПО впервые было разрабо тано для тех систем, где требуется сверхнадежиость. Такие системы обычно включаются в систему управле ния в реальном времени с большой стоимостью. Нельзя ожидать, чтобы в большой программе не было ошибок. Независимо от того, насколько внимательно она кон струировалась, современные средства программирования не могут гарантировать правильность больших про грамм.
Для больших систем обширное тестирование всех возможных случаев невозможно. Всегда имеются особые случаи, которые никогда не рассматривались. Даже если ПО можно проверить на правильность действий, то нельзя достичь правильности действий системы до тех пор, пока не будет гарантирована ее целостность.
Целостность системы ПО может быть разрушена необнаруженными ошибками в аппаратуре, такими, как сбои при переходных процессах, вызывающие искажение данных, нарушение зашиты; ошибки людей при выпол нении; остаточные программные ошибки в системеЗа шита целостности системы от таких нежелательных из менений может быть обеспечена путем преобразования программы в кусок самоконтролирующегося ПО. Такой прием, хотя н не может гарантировать целостности сн-
261
«темы ПОИ .любых возможных.ошибках, однако поыюяет сконструировать *е так, что она будет эффективно отражать наиболее часто . встпечаюшиеся ошнпки До
того как в действительности можно будет гарантировать целостность системы, необходимо доказать ее правиль ность, чего нельзя достичь для больших шюгоамм в на стоящее время.
Самоконтролирующееся п и в первую очередь исполь зуется для проверки правильности действий системы во время работы. Это достигается путем введения ирбыточг ности в программу. Самоконтролирующееся ПО конструи руется для реализации следующих функций: определения программных ошибок, их локализации, проверки целост ности системы, помощи системе избавиться от ошибки.
Средства определения ошибок на момент выполнения очень важны во многих системах ПО. В ряде случаев мы скорее, прекратим процесс, чем допустим выполнение неверных операций, так как многие результаты будут некорректными. В отличие от аппаратных сбоев нет надежной статистики о поведении и распределении раз личных программных ошибок. Распознавание програм мных ошибок может проводиться лишь путем выявления ненормального поведения системы. Это требует со сто роны разработчика формулировки набора стандартов на нормальное поведение системы, и средства самоконтроля могут использоваться для проверки на существование отличий, от нормального поведения. Проверяя обосно ванность поведения программы на различных стадиях вычислений, можно увеличить надежность на выходе и ограничить распространение ошибок^
Ограничение распространения ошибок помогает огра ничить опасность, вызванную обнаруженной ошибкой, и предотвращает темсамым катастрофу для всей си стемы. Это также изолирует ошибку и помогает про граммисту локализовать ее. Способность самоконтролирующихся программ определять и локализовать ошибки зависит от имеющихся средств проверки и частоты выпол нения этих проверок.
После обнаружения ошибки необходимо применить процедуру исправления для устранения ненормального поведения системы. Быстрое исправление очень важно для систем, требующих продолжительного пропуска, та ких, как системы переключения телефонов. Эти системы могут быть сконструированы таким образом, чтобы вос становление производилось бы при возможном зати хании выполнения.
2 6 2
Процедура исправления предусматривает избавление от пбеледствк'й ошибки и собственно исправление ошибки, если это возможно. Некоторые временные ошибки могут быть устранены путем повторения операции. Например, ошибка э Чтении при вводе данных может быть устра нена Путём повтора операции чтения, если несоответ ствие вызвано временной ошибкой. Другие постоянные ошибки могут быть исправлены путем восстановления искаженных элементов из избыточной информации, хра нимой в программе, или из сохраненной в предшествую щем состоянии копии. Однако если это программная ошибка. ' то требуется вмешательство человека. Тем не менее процесс исправления может оказаться бес полезным, так как программная ошибка приведет к тому же самому эффекту.
Изоппфуя ошибку и ограничивая распространение, ее вредного воздействия, самоконтролнрующееся ПО предо ставляет ценную информацию для исправления. Даже при условии широкого внедрения средств самоконтроля в систему все еще могут оставаться ошибки, которые нельзя обнаружить. Поэтому желательно проверять целостность системы периодически илн непосредственно перед выполнением критических процессов. Проверки це лостности обычно реализуются путем контроля опреде ленных свойств программы, которые необходимы для нормального - выполнения.
Самоконтролирующаяся система может быть постро ена с использованием различных средств самоконтроля на разных уровнях: системном, модульном, операцни- (инструкций), данных. Программная избыточность на различных уровнях предназначена для проверки системы на данном уровне. Низшим является уровень, наиболее узкий, по масштабам определения ошибок, но оконча-' тельный по . принятию решения об ошибке.
На системном уровне целостность системы можно проверить при избыточности процесса в мультипрограм мной или мультипроцессорной среде. Целостность дей ствующей системы можно проверить, создавая фиктив ней процесс путем задания искусственного запроса.
В мультипроцессорной среде различные комбинации процессов создают различную среду для системы. Зтн средства проверки очень эффективны, если правильные действия системы чувствительны в определенной степени к среде. При таких условиях стойкие» программные
263
ошибки* всплывут на поверш ит* шнцк прмгнжаичщщрравмльной комбинации процессов в системе
Перегрузка системы является часто результатом не; надежных действий В системах реального времени за поздалый результат столь же страшен, сколь и неверный. Ухудшение выполнения может быть вызвано програм мной ошибкой или перегрузкой в распределительном процессе. В каждом случае необходимо выполнить процедуру корректировки Необычная частота аппарат ных прерываний может также указывать либо на ма шинный сбой, либо на программную ошибку. Тогда должна быть проведена дополнительная проверка.
На низших уровнях, включая модульный уровень, уро
вень операций и уровень |
данных, могут применяться |
«ее средства, обсужденные |
ранее. Надежность действий |
каждого функционального модуля может быть проверена так же, как н последовательность выполнения
На уровне операций могут быть использованы сред ств» защиты. Вместо вычисления адреса для передачи управления должны использоваться ветви условия Крн* сервативный стиль программирования также должен использоваться для кодирования каждого модуля, не делая по возможности серьезных предположений о дей ствиях других модулей.
Избыточность на уровне данных очень полезна для защиты целостности данных и для обеспечения средств исправления. Информационная избыточность позволяет составлять обоснованные тесты обнаружения ошибок для систем, использующих независимые данные. Она также позволяет восстановить данные, испорченные изза программных ошибок или аппаратных сбоев.
Данные из различных источников, содержащие одну н ту же информацию, могут храниться и периодически сравниваться для обнаружения ошибок и восстановления утерянных данных. Периодическое сохранение состояния программы позволяет вернуться в ближайшую контроль ную точку в случае отказа в системе
Информирование о выполняющейся последователь ности может быть эффективно достигнуто посредством ассоциативной памяти Наличие ассоциативной памяти также ускоряет многие операции сравнения, которые встречаются при проверке соответствия. «Следы» важных событий в системе также могут собираться и контролиро ваться в отдельном аппаратном модуле на предмет их обоснованности. Кроме этого с помощью специализиро-
264
ванной аппаратуры, ё особенности той; которая отно* снтся к таймеру и состоянию ресурсов, можно произво дил-ь дополнительный контроль. Должен быть определен максимальный момент времени для каждого процесса и должен Иметься аппаратный модуль, ответственный за время протеканий процесса. Та же проверка должна быть применена и в отношении ресурсов процесса .
Максимальный ресурс времени удерживания может быть определен для каждого ресурса, который исполь зует процесс По исчерпании лимита времени для со ответствующего ресурса генерируется аппаратное пре рывание длё прекращения управления ресурсом
Аппаратный таймер также может использоваться для проверки времени ответа системы на критическое событие. ТаймСр включается по критическому событию й Выключается системой, когда соответствующие дей ствия уже сделаны В случае неожиданной задержки в системе при выполнении критического события таймер выдает прерывание по исчерпанию определенного лимита Времени Таймер также можно использовать для про верки последовательности событий, которые всегда сле дуют одно за другим Таймер включается одним со бытием, а выключается другим. Неверная последова тельность сохранит состояние таймера на длительный период времени, что вызовет прерывание, указывающее на ложное условие
Самоконтролирующееся ПО полезно для доказатель ства надежности программ на различных стадиях разработки На стадии конструирования и реализации утверждения о соотношении между переменными сделают логические ошибки более очевидными. Это позволяет также повысить уверенность в надежности программы неформальным образом. На стадии тестирования для определения всевозможных аппаратных и программных Погрешностей необходимо внедрять разнообразные сред ства самоконтроля, обеспечивающие локализацию ошиб ки в системе История обнаружения ошибки должна сохраняться для оценки эффективности средств само контроля В системе также должна быть осуществлена
в широких масштабах оценка |
стоимостных |
расходов |
||
по различным средствам |
|
|
|
к |
Поведение системы ПО является чувствительным |
||||
данным и зависимым от среды |
Поэтому |
стоимость |
и |
|
эффективность самоконтролирующегося |
кода |
может |
||
существенно варьировать в различных средах Эффектив-
26S
кость по стоимости различных средств, должна быть оценена в различных средах. Лишь самые существен ные и эффективные средства следует сохранять в целях снижения расходов. Стоимость контроля может быть снижена путем реализации некоторых проверок на спе циализированной аппаратуре.
Таким образом, самоконтроль позволяет определить аппаратурные и программные ошибки через очень малый промежуток времени после того, как они произошли Ограничение распространения ошибок помогает легче из бавиться от них посредством ограничения вреда, при носимого ошибкой. Избыточность данных помогает произвести быстрое восстановление, что приводит к улуч шению показателей функционирования системы.
В настоящее время появилась необходимость разра ботать формальную методологию конструирования самоконтролирующегося ПО. Можно производить функцио нальную проверку, проверку управления последователь ностью н проверку данных системы. За исключением проверки управления последовательностью, не существует систематических процедур для других форм проверки. Формальный подход необходим для проведения ав томатизации и оценки стоимостной эффективности.
В настоящий момент большинство средств самоконт роля требует от программиста перемены стиля про граммирования. Необходимо отметить, что средства структурного программирования обладают некоторыми формами избыточности, что приводит к увеличению надежности программ. Автоматизаций размещения и удаления средств проверки в программе будет чрезвы чайно полезной. Не все средства самоконтроля можно автоматизировать, хотя некоторые из них, например информирование о последовательности выполнения, легко поддаются автоматизации. Оценка стоимостной эффектив ности этих средств поможет выбрать наиболее приемле мые из них для аппаратной реализации.
Введение программной избыточности в систему уве личивает ее стоимость. Для реализации специализиро ванных проверок необходима дополнительная аппара тура, а для избыточных данных — дополнительная память. Выполнение избыточных операций также является источ ником неэффективного использования аппаратуры. Одна ко по мере уменьшения стоимости аппаратуры и повы шения ее быстродействия эти стоимости будут скомпен сированы посредством улучшения показателей функцио нирования и надежности системы.
ЛИТЕРАТУРА
I |
Гласс Р |
Руководство по надежному программированию,— М |
Фн |
|
|
нансы н статистика, 1982,— 256 с |
Справочник |
||
2. Дофроневский О В., Борохович Я П., Самчемко К В |
||||
3 |
но ЭВМ.— Киев: Внша школа, 1976,— 191 с. |
М. |
Мир, |
|
Майерс |
Г Надежность программного обеспечения. |
|||
|
1980 — 360 с. |
|
|
|
4Надежность в технике. Термины и определения. ГОСТ 27.002—83.
М. Изд-во стандартов, Г983.— 30 с
5. Система документации единой системы ЭВМ/Под общ. ред
А. М. Ларионова.— М.. Статистика, 1976.— Зф8 с.
6.Тейнер~Г, Липов М., Нельсон Э Надежность программного обес
печения,— М . Мир, 1981 — 325 с
7 |
Шуроков В. В., Алферова 3. В., Лихачева Г Н. Программное обеспе |
|||
8. |
ченне ЭВМ.— М . Статистика, |
1979 — 376 с. |
||
Boehm В |
W The |
High Cost |
of Software — Practical Strategies for |
|
|
Developing |
Large |
Software Systems.— Addison Wesley Publishing |
|
|
Company — 1978. |
|
|
|
9. Guidelines for Documentation of Computer Programs and Automated
Data |
Sustem s//Federal |
information |
Processing Standards Publica |
||||
tion |
38.— 1976. |
|
|
|
|
|
|
10 Hansen S |
D and Mchard Q. D. Readability and Quality Control of |
||||||
Production |
Engineering |
Computer Program s//Journal |
of Aircraft, |
||||
1974.— Vol. |
11 - |
№ 4. |
Modular Programming T Hoskyns and |
Co.. |
|||
14. Implications of |
Using |
||||||
Ltd., |
Guide |
No |
1 Hoskyns System |
Research.— New |
York; |
1973. |
|
12. Morin L. Estimation of Resources for Computer Programming Pro jects.— University of North Carolina.— Charel Hill, M. C., 1973
13.Richards H and Wright C. Introduction to the SYMBOL 2R Program ming Language//ACM -IEEE Sumposium on High — Level — Lan guage Computer Architecture.— New York, IEEE, 1973
14.Shooman M Probabilistic Models for Software Reliability prodiction,
l972//lnternational |
Symposium |
on |
F au lt— Tolerant |
Computing. ~ |
Newton, M ass, 1972, Jme 21, |
IEEE Computer Society |
|
||
15. Schick G.'J and |
Wolverton R |
W |
Assessment of Software Reliability |
|
I I Annual Meeting — German Operations Research Society,— Hamburg;
1972
267
П Р Е Д М Е Т Н Ы Й У К А З А Т Е Л Ь
Адаптируемость 109 Адаптация документации 46, 110,
192 Активное обнаружение ошибок
12, 66
Анализ требований 102 Архитектура системы 33, 126
Безопасность ПО, 112, 180 Библиотекарь 45
Вероятность сбоя 18 Верификация программ 154 Внешние действия 141 Внешние спецификации 114, 115
График работ 110 Группа
—главного программиста 43 интеграции 177 специалистов 44 программирования 42
Декомпозиция задач 137 Документация системы 52 Допуск ошибок 69
Заданный |
уровень надежности |
||
22 |
обеспечения надежности |
||
Задачи |
|||
22, |
123, |
138, |
153 |
Затраты |
|
|
|
производства 79 |
|||
технического |
обеспечения 77 |
||
программного обеспечения 79, 80 документации 91
сопровождения 87
Защита от ошибок 53. 144 Защищенность информации 46,
145
Избежание ошибок 66 Избыточность 69, 262
—аппаратная 69, 70 временная 69, 70 динамическая 69, 70 программная 69, 70, 263
Изоляция ошибок 70, 263 Интерфейс
внешний 12, 116 межмодульный 12, 116 модуля 12, 116
Информация теста 232 Исправление ошибок 68, 263
Испытание
—безопасности 180
—бессбойностн 180
—восстанавливаемости 180
—надежности н готовности 180
—оборудования 179
—памяти 17Й
—переносимости 181
—предельных нагрузок 179
—производительности 180
—средств взаимодействия с пользователем 181
Источники ошибок 48
Качество программного обес лечения 27 Квалификаций персонала 31, 32 Классификация?
—задач проектирования с за данным уровнем надежности 22
—модулей 130, 131. 132
—ошибок 55, 56
—показателей надежности 16, 17
проектов программного обес печения 101
—средств анализа требований 101, 102
— средств самоконтроля 266
— факторов, определяющих на дежность 25
Кодирование модуля 141, 142 Количественная оценка надеж ности 17 Компиляция модуля 144
Контролируемость программ 168 Контроль
—групповой 120
—интегрированный 155
—опытно эксплуатационный 155
—программ 42, 154, 159
системный 155 Концептуальная целостность 115 Корректность программ 4, 12
Методы
—допуска ошибок 69 контроля 159, 163» 165 оценки стоимости 91 '
26 8
Методы планирования
—прямые 208
—косвенные 218
—графические 219 Модель
—имитационная 246
—надежности 234
—оценки надежности 228, 244
—ошибок 228, 233
—Переходных вероятностей 237
—сеющая ошибки 243
—сложности 253, 255, 256 Модуль
—информационно-связанный 132
—классово-связанный 131
—коммунинационно связанный 132
— |
процедурно-связанный |
132 |
— |
функционально-связанный |
132 |
Модульная структура 35, 36 |
|
|
Надежность'
—оборудования 10
—программного обеспечения 8, 10, 11. 34
—функциональная 12 Независимость модуля 130, 135
Обнаружение ошибок 66 Обновление документации 205 Обоснование требований 22 Обслуживаемость 133 Описание
—программы 29, 202
—структуры 128
—целей 107, 108 Определение
—пользователя 112, 191
—программного средства 84 Организация контроля 42, 154 Отказы оборудования 8, 9 Отладка 154 Оценка*
—стоимости 91
—сходств и различий 92
—соотношений 92
—снизу вверх 93
Ошибка
—документации 65
—коммуникационная 65
—концептуализации 64
—механическая 64
—описания целей 107
—персонала 57, 65
постановки 64 программная 6, 8. 59
проектирования тестов 173
— производства 9
—разработки 9
—реализации 64
—синхронизации 60
—умственная 64
Пассивное обнаружение ошибок 66
Поддержка 54 Показатели-
—качественные 16
—количественные 17
—надежности 16
—порядковые 17
—стоимости программного обес печения 95
Принцип:
— автоматизации 159
— выборочного контроля 157
—логической редакции 158
—моделирования 157
—модульности 130, 155
— организации контроля 154
—проектирования контроля 152
—сегментации 155
—стандартизации 158 Проверка.
—внешних спецификаций 120 —- логики модуля 144, 147
—программ 147, 152
—требований 106, 147
—функциональная 260 Программирование:
—защитное 145
—модульное 125, 152
—структурное 151. 260 Проектирование
—внешнее 98, 124
—модуля 141
—с программной избыточно стью 263
—сверху вниз 152
—системных тестов 178
—тестирования 172, 178, 184
Производительность 111, 180 Производство программного обеспечения 73, 74
Разработка требований 101, 102 Руководитель проекта 191 Руководство.
—операционное 202 - пользователя 201
—по обслуживанию 203 Ресурсы проекта 91
Самоконтролнрующееся про граммное обеспечение 260 Связность
2 6 9
—внешняя 131 134
—контрольная 114 логическая 131
—общая 133
—относительная 134
—сильная 133
— условная 131 Связь с пользователем 101 Сложность 39 ‘Совместимость 112 Сопровождаемость 109
Специфика торговле арограм иным обеспечением 77 Спецификация
базы данных 200
—модуля 13 оборудования 53. 198
общего программного обес печения 53, 198 программная 198 системы 197
«- языков программирования 53 Средства анализа требования 102
Стиль программирования 148 Стоимость программного обеспе йения 95. 110 Структура
программного обеспечения 12, 131 документации 193
Тенденции разянтия систем программирования 32
языков программирования 32 Тестирование
модуля 172 при установке 187
приемо сдаточное 186 системное 178 функциональное 170
Тестовый анализ 204 Тестовый план 204 Требования.
информационные 195 к конструкции и взаимосвязи модулей 36 системные 101 функциональные 193
Универсальность 108
Уммфсальмшль разработка 451 Управление
—измененняма 122
—надежность» 40
—последовательностью 264
—разработкой 27. 89. 139 Устойчивость программы 4
Фаза
—планирования 79, 80
—проектирования 85
—реализации плана 79. 80
Факторы.
— архитектура ЭВМ я надеж
ноеть 33
—конструктивные 38
—определяющие цену нрог раммяого обеспеченна 77, 78
—организационные 40
—определяющие затраты на программное обеспечение 88 определяющие надежность программного обеспечения 26 определяемые окружающей средой 90 подготовка и повышенне ква
лнфикацни персонала 31
связяпные с организацией разработки 68 технологические 39 управление разработкой 27
—человеческие 109
—эксплуатационные 46
языки программирования н надежность 35
Формулировка требований
Характеристики
—логические 201
—надежности 16
Цели
—анализа 79
—документирования 189
—продукта 112 проекта 113 проектирования 133
структурного программирова ния 151
Цикл жизни 81