книги / Надежность программного обеспечения систем обработки данных
..pdfкакие-то Грумы 'ИяаПбёШ Леёчё^'о конкретно» Я**пе. ЭТОТ топ' аиалиЗаМоМ|ет^быТОЖ
зовам прй Доставлении тесТОвых'првИёдур, !кotopыe, бу дут выйвяЯть ошибки более эффекгйИйо. Другим приме*-1 ром зЫЯМсймоёти ошибок я влЯётсй'Мх зависимость dt Уле- ! м«нтой среды программирования, от языка npdif^aMtitipid^1 аайия. Эго может быть использовано Аля о^еяйя Л^агностйческих возможностей рааличнылЯзыков'''npot*pkkl^0
мированйя. |
- -‘"ь |
:V '' |
Двумя ’основными" 1ШТОгх>рнямНп}>йзнакаКАК явля |
||
ются1" даншке и процедуры. Категория |
данные включает |
|
разделы входные и внутренние, каждый из которых’ ИЬдразделяется на значение, атрйбут.нмя, номер, структура и порядок. Категория процедуры включает разделы вы-'
числение (операнд, оператор, операция); контроль (<$ух* чай. итерация, порядок.налйчйе) и интерфейс (персонал, оборудование, программное1Обеспечение).
Ошибочные значения содержат константы и литера лы. В разделе входные подобные ошибки Встречаются во входных потока* Информации-Пользователя и вфЛАлах1 данных. Эти ошибки являются результатом hecoorBefcr-' вия входных' данных*' программным спецификациям.
Вразделе внутренние такйе ошибки могутпроявляться
ввиде констант или ЛятерасЛов; входящих в; состав иьДа,
инициализирующего некЪторые вЫчисленяяГ |
: |
Ошибочные а т р и б у т ы 1м о г у т п о я в л я т ь с я ' в |
о б о и х *раН*Г' |
д е л а л и в к л ю ч а т ь в с е б я к о й с т а н ^ ТЯТга строк, к О т о р ы г 1' п о я в л я ю т с я в 1 т е х м е с т а х ; г д е п р е д п Ь л а г Я л Ь с ь и с п б л ь э о - г' в а Н Я е ц е л ы х ч и с е л и л и с т р о к б и т о в . Ё с л й л о д о б и ы ё о ш и б к и н е п р о в е р я ю т с я п р и к о н т р о л е , т о о н и М о г у т п о в л е ч ь з а с о б о й с н я т о е з а д а н и я и Л Н п о л у ч е н и е н е Я р я в и л ь н ы х р е
з у л ь т а т о в . Т а к к а к з н а ч е н и я а т р и б у т о в 1ю м н о г о м з а в и с я т о т с р е д ы ' п р о г р а м м и р о в а н и я ; то с о д е р ж и м о е * э т о г о
р а з д е л а о т э к с п е р и м е и т а к э к с п е р и м е н Т у м о Ж е т з н а ч н ^ т е л ь н о в а р ь и р о в а т ь . П р и м е р а м и а т р и б у т о в д а н н ы х в я з ы к е П Л / 1 я в л я ю т с я д л я ч и с л о в ы х д а н н ы х - ^ р а з м е р н о с т ь н
т о ч н о с т ь , д л я с т р о к — д л и н а , ДЛЯ ф а й л о в — д л и н а з а п и с и .
Ошибки в именах обычно ограничены разделом вну тренние, но могут быть имена переменных, файлов и по-' лей записей. Вероятность ошибки в имени увеличивается, если одно и то же имя используется в нескольких контек стах, или а случае частичного совпадения имен. Заметим, что этот тип ошибок будет часто совпадать с ошибками раздела область (признак ЧТО).
Ошибки в структуре и порядке будут найдены в раз-
611 .
B fiJtn xctpffK t^ ^ i»pkdoK j В расойatpfcBHiOtieH оннймес-
..TO «ютому.чтожх Вчеиьтрудяо рязграяуНиггь. В принципе структура рассматривается как особый вид упорядоченяосто.’ отобдокяющмй <■присущие данным взаимосвязи. Порядокотобршжает ■произвольно выбранную последо вательность данных, которая, будучи установлена.должна
Д О Х М Н Ц Т ЬС Я , •■-.■■■ |
■■■ |
• |
, Раздел вычисления охватывает |
вое типы |
операций |
над данными. Подраздел операнд включает, ошибки, обусловленные неправильным использованием данных. Подраздел оператор включает процессы, .которые соот ветствуют данным, но выполнение которых не соответ ствует целям вычислений, например неправильный поря док выполнения, явившийся результатом; непонимания
правил, по 1юторыр| . tipwtpKfef операторой.' Подраздел операция nueef отношение к ошибкам,
связанным с пропуском операций. Типичными примера ми являются такие, как отсутствие инициализации пере менной Перед ее первым использованием, сохранение первоначального Значений переменной; которая не будет яопбльзойатНся * процедуре и Т\ д; ; >
j Раздел-контроль включает ошибки логического управ ления порядком-и частотой: выМмнеиия кода. Подраздел случай содержит информацию ошибки при попытке опре делить все варианты, которые должны уникально обра батываться в процедуре; Типичным примером такого ва рианта мбжет быть отсутствие данных (нулевые данные), первичный вариант (инициализация), терминальный ва риант (последняя передача данных) и ошибочный "варнвит(йеправильноеопределеяие).
г Подраздел итерация включил* ошибки, связанные с повторением кр»а. Типичным Примером такой ошибки явиеиатоя бвеиЕМечяый. Цикл! р -
Подраздел' порядок* (упорядоченность)‘ определяет ошибки' контроля,’ веэиикающне йз-за неправильной по следовательности выполнения* вычислений или тестов, т.- о самипо себе процессыявляются корректными, но выполняются в непредусмотренной последоввТОльяости. Примером может служить использование переменной до вшчисления ее значения, выполнение Одной подпрограммы -перед другой, причем первой из подпрограмм требуются данные, получаемые во второй.
' Подраздел наличие отводится для ошибок; обуслов ленных наличием таких4 ситуаций, когда, 'например, в программе есть оператор ДО, но нет соответствующего
ему оператора END. |
- |
-в!г |
|
, |
.ст<1!9Л1¥^^ |
rff»»- |
нвобразяой |
^достаточно устойчивой |
груипыощцбед, |
включающей все ярице щ деэднмв оцшбкивэаимедеветвия процедуры со средой,лв которой она-функционпрует. Сюда включаются подразделы персонал* ’ оборудование и ДО.- Первый из подразделов <включаетошибки непралильного толкования требований. Типичным примером итого является генератор отчетов, ИачиИйющийиеЯНть с нового листа нри каждой сиене наименования отдела и печзтающнйспнеок сотрудников отдела в алфавитном порядке, тогда как необходимо быловыдать синеок сот рудников в алфавитном порядке с указанием соответст вующих номеров отделов. '
Подраздел бборудоёШшё ЪклюЪйег ошибки ТИпа по пытки вложить в процедуру тадне требования К офорудрванию.которЫе недопустимы по конегруктиВвЦм сооб ражениям. ЭТт>т тйпошиббк часто, встречается 'при paQoте с внешними устройствами. Например, процедура была написана для работы с одним типом дисковод устройст ва, а использована для обращения и другому типу. Родраздел программное, обеспечение >•в основном включает а себя ошибки интерфейса, Например, процедура обраба тывает матрицу'Раэтрносхью 7Х& втоврем я, как ата матрица имеет размерность 8X7. , . <
Признай КОГДД. Ошибки могут быть классифициро ваны по признаку КОГДА, т. е. в соответствии со стадией разработки программы, на которой встретилась ошибка. Три стадии имеют отношение к признаку. КОГДА; началь ное проектирование, внедрение и функционирований.
На стадии начального проектирования функциональ ные требования преобразуются в программные специфи кации. Ошибки этой стадии будут классифицироваться я категории уметвенные. При внедрении имеют место ошибкн, которые описываются также в категории умственное и механические. На стадии функционирования ошибки фиксируются не разработчиком, а пользователем. Источ ником ошибок является обработка редких, комбинаций данных.
Признак ПОЧЕМУ. Ошибки, могут быть классифици рованы по признаку ПОЧЕМУ, т. е. на основании чего программист Выдал код или данные, которые классифи цированы как. ошибочные по признаку КАК. Ошибки, одинаково классифицированные по признакам ЧТО и КАК, могут быть иначе классифицированы по признаку ПОЧЕМУ. Наирнмер, механическая ошибка может иметь
те же посдаавШИ1Я„<ч1ю " толкование сие* цифдкаций, Примените*1шо»ф||Ишатривае¥<н|у признаку
выделяются следующие‘|у |я $ ^ |
механический, умст |
венный и коммуншущувщшА, |
' », |
Информация цвв категории |
механический включает |
ошнбди^првебрвмжани» й9 одной формы в другую и моДО?, быт* классифицирована по разделом: подстановка, путаница и пропуск. Типичными примерами механических ошибок являются,IMUIM/SKII перфорации ,с бланков, ввод результатов вычислений лручную-ю терминала и т. д. Эго объясняется тем, что, несмотря* ив уверенность програм миста в правильности данных, ОАк каким-то образом бы ли испорчены в процессе преобразования. Для человека, написавшего программу, обнаружить механические ошиб ки достаточно трудно, & посторонний человек {лучше программист) увидит их почти сразу. Причина здесь кроется В том, что писавший,программу ослеплен собст венной убежденностью в безошибочном выполнении ра боты, тогда как посторонний человек таких иллюзий лишен.
Ошибки подстановки состоит е замене одних элемен тов.! (значений, имен) другими. Этот тип ошибки очень трудно определить, так как перепутанные элементы могут использоваться аналогичным образом. Ошибки, обуслов ленные путаниц0йцтрвД£тавлтт1Со6рн перестановку сим волов в элементе, что приводит к неправильной трактов ке элемента. Этотчхип ошибки легко выявляется для имен вр время трансляции, но.для нкоел и текста часто такие ошибки остаются не обнаруженными. Ошибки-пропуска определяются тек, нто-какие-твиданные* или части алго
ритма были ошибочно опушены.,, < Под умственными ошибками ^понимаются ошибки в
трактовке каких-то положений -вне зависимости от стадии ,разрвботки ПО. Эти ошибки являются следствием не правильного понимания программистом информации или результатом неправильных-логических выводов, получен ных на базе корректной информации. Характерным при мером подобной ошибки является проектирование воз можностей, которые не удовлетворяют ограничениям, накладываемым оборудованием.
Ошибки концептуализации и реализации соверша ются и проявляются на всех стадиях разработки. Нача лом процесса разработки является набор спецификаций, на основании которых программист вырабатывает концеп ции относительно реализации процесса обработки данных.
При этом во внимание принимаются компоненты, процес сы и интерфейсы Как правило, в результате проекти рования получается набор программных спецификаций, которые затем используются в качестве входных относи тельно процесса реализации На любом этапе разработки концепция разработки может изменяться, все больше от личаясь от первоначальной В этой ситуации ошибками концептуализации являются неправильно сделанные вы воды из спецификаций, а ошибками реализации являются разработки, не соответствующие концепции
Коммуникационные ошибки имеют отношение к интер фейсу между программами и их источниками информа ции Типичной ошибкой здесь является случай, когда программа и блок-схема не соответствуют друг другу К ошибкам персонала относят ошибки, допускаемые раз работчиками в процессе общения друг с другом. К ошиб кам документации относятся неточности в документации.
Сложность и многосторонность процесса разработки ПО отражаются и в структуре метода классификации ошибок Несмотря на то что в рассмотренном методе классификации представлено в общей сложности около 100 атрибутов данных об ошибках, вероятность того, что их потребуется еще больше, остается достаточно высо кой С другой стороны, ни от одного эксперимента не ожидается использования Bceto метода классификации. Список приведенных категорий, разделов и подразделов может служить основанием для выбора такого подмно жества, которое соответствовало бы целям конкретного эксперимента.
3.3 ПОДХОДЫ к ОБЕСПЕЧЕНИЮ НАДЕЖНОСТИ
Для достижения заданного уровня надежности необп ходимо выполнять основные принципы разработки, ко торые можно условно объединить в четыре группы, избе* жание, обнаружение, исправление и допуск ошибок.
Избежание ошибок включает описание принципов, выполнение которых обеспечивает минимизацию ошибок, вносимых в процессе создания ПО Обнаружение ошибок базируется на средствах и методологии, обеспечивающих определение ошибок в разработанном ПО В группу прин ципов, обеспечивающих исправление ошибок, включают ся конструирование и методология использования функ ций, корректирующих обнаруженные ошибки или устра няющих результаты их воздействия. Допуск ошибок
3 Зак 1922 |
6 5 |
предусматривает средства и приемы, обеспечивающие возможность выполнения заданной работы при наличии ошибок
Избежание ошибок. К средствам избежания ошибок в процессе проектирования относятся такие, целью кото рых являются предупреждение появления ошибок в про грамме Большая часть этих средств и приемов имеет от ношение к отдельным процессам трансляции, рассмотрен ным ранее Можно выделить следующие возможные группы средств:
средства н приемы минимизации сложности как основ ной причины ошибок трансляции,
средства и методы достижения точности реализации процессов трансляции,
средства и методы совершенствования информацион ных связей разработчиков,
средства и приемы немедленного обнаружения и устра нения ошибок трансляции после каждого шага, а не после завершения написания программы.
Естественно, что избежание ошибок является опти мальным подходом к достижению надежности разрабаты ваемой системы ПО. Несмотря на очевидность этого утверждения и усилия, затрачиваемые на решение про блемы избежания ошибок при разработке, практика по казывает, что ошибки имеют место Отсюда и возникает необходимость в наличии трех оставшихся категорий.
Обнаружение ошибок. Если предполагаем, что ПО имеет ошибки, то первым мероприятием должно быть ИХ обнаружение Если необходимы дополнительные меро приятия, такие, как средства для корректировки или об хода ошибок, то в первую очередь необходимо иметь способ обнаружения ошибок
Можно выделить две различные группы мер по обна ружению ошибок: пассивные попытки обнаружения оши бок и их симптомов во время выполнения запланированных программных функций и активные попытки периодическо го самопросмотра ПО с целью выявления ошибок.
Меры обнаружения ошибок могут рассматриваться как для случая проверки в процессе разработки, так и во время работы ПО Учитывая то, что в процессе разработ ки обнаружение ошибок в основном реализуется систе мой простых организационных мероприятий, остановимся на приемах и методах обнаружения на уровне програм мных модулей в процессе функционирования.
Разработка мер обнаружения ошибок основывается на следующей системе утверждений
1) принцип взаимного подозрения Каждый модуль должен быть ориентирован на то, что все остальные мо дули, связанные с ним в процессе работы, содержат ошиб ки Тогда при приеме входной информации от других мо дулей или из некоторого внешнего источника по отноше нию к системе предполагается, что данные могут быть оши бочными, и их необходимо проверить,
2)принцип немедленного обнаружения. Ошибки долж ны быть обнаружены до момента реализации функций модуля. Это не только ограничит распространение их влияния, исключит возможный ущерб, но также упроща ет проведение отладки;
3)принцип избыточности. Все меры обнаружения ошибок основываются на некоторой форме явной или не явной избыточности.
Перечень мер по обнаружению ошибок достаточно раз нообразен, и его конкретное представление в значитель ной мере определяется конструкцией и назначением мо дуля Однако можно привести некоторый обобщенный пе речень мер по обнаружению ошибок:
1)организация проверки признаков каждого входною Элемента данных. Если входное данное должно быть циф ровым (текстовым), то в этом необходимо убедиться
Если это число должно быть положительным, надо про верить его. Если число должно иметь определенный раз мер — надо проверить н это;
2)организация проверки значений входных данных на известные ограничения. Так, если элемент данных яв ляется адресом основной памяти, то необходимо прове рить его действенность;
3)организация полноты проверки. Если для числа заданы (известны) пределы его значения нижней и верх
ней границами, то, проверив соблюдение нижней грани цы, нельзя не проверить и соблюдение верхней границы,
4)при наличии явной избыточности входных данных необходимо проверить их на совместимость;
5)прн отсутствии явной избыточности входных данных целесообразно предусмотреть ее. Например, добавление
контрольных сумм по строкам н столбцам передаваемой матрицы. После приема таких данных можно провести проверку соблюдения принятого условия;
6) организация сравнения входных данных с некото рым набором внутренних данных, если это может выте кать из физической сущности процессов
3* |
67 |
Применение функций обнаружения ошибок должно производиться^ в соответствии с последовательной стра тегией на протяжении проектирования системы. Это отно сится и к действиям, выполняемым после обнаружения ошибки. Такие действия должны быть однообразными независимо от функций, реализуемых модулем.
Пассивное обнаружение ошибок не позволяет выявить все ошибки, так как ошибка обнаруживается только тогда, когда осуществляется контрольная функция. Проверка симптомов ошибок может быть проведена за счет проектирования программных функций, активно ис пользующих систему с целью поиска ошибок. Такие меры называются активными мерами по обнаружению ошибок.
Активные меры обнаружения ошибок обычно встроены в монитор обнаружения, реализующий параллельный процесс периодического сканирования системных данных. Необходимость такого подхода вызывается тем, что систе мы ПО, управляющие ресурсами, обладают классом программных ошибок, характеризующихся потерей ре сурсов при длительном процессе работы. Например, мо нитор может сканировать основную память для обнару жения блоков, которые не назначены никакой текущей программе, но и не присутствуют в списке нераспределен ной памяти.
Монитор обнаружения может быть реализован как периодическая задача или как задача с низким приори тетом, решаемая, когда система находится в состоянии ожидания. В экстремальных ситуациях может оказаться желательным иметь монитор, выполняющий диагности ческие тесты системы.
Рассмотрение перечня пассивных и активных мер об наружения ошибок ПО еще раз подчеркивает необхо димость четкого выполнения организационных мер по обнаружению ошибок на стадии проектирования.
Исправление о ш и б о к . Имея средства и приемы обнару жения ошибок, необходимо обеспечить корректировку обнаруженных ошибок нли устранение последствий йх действия. Исправление ошибок представляет собой мощ ное средство обеспечения надежности работы примени тельно к оборудованию. Современные процессоры наде лены способностью обнаружения неисправных компонент и замены их идентичными исправными компонентами при реализации резервирования. Аналогичных средств дляПО не существует в силу коренных различий между
вв
программной ошибкой и сбоем оборудования. Действи тельно, если конкретный программный модуль содержит ошибку, то и его резервный вариант также будет оши бочным.
Известные идеи корректировки сводятся к попыткам исправления последствий ошибок, таких, как разрушение записей базы данных или системных контрольных таблиц. Средства исправления последствий ошибок имеют доволь но ограниченные преимущества, потому что они требуют от разработчика предвидения возможных типов разру шения и разработки специальных программных функций, исправляющйх эти разрушения. Это выглядит парадок сально, потому что, если программист заранее знает, ка кие ошибки будут иметь место, то он наверняка постара ется их избежать.
До тех пор пока функции корректировки ошибок не станут достаточно мощными, чтобы исправлять большую часть типов разрушений, средства избежания ошибок бу дут предпочтительнее. Будет лучше, если вместо созда ния функций операционной системы, обнаруживающих и исправляющих разрушенную цепочку таблиц или кон трольных блоков, разработчик спроектирует системы та ким образом, что к таблицам будет иметь доступ только один модуль, который подвергнется тщательной проверке.
Допуск ошибок. Средства допуска ошибок должны обеспечивать возможность функциоиироваиия системы ПО в случае, когда в ней присутствуют ошибки. В соста ве этих средств можно выделить такие группы, как дина мическая избыточность, вспомогательные методы и изоля ция ошибок.
Концепция динамической избыточности широко ис пользуется при разработке оборудования. Сущность ее состоит в том, что одни и те же данные параллельно обра батываются несколькими идентичными устройствами с последующим сопоставлением полученных результатов. При совпадении результатов большинства (или всех) устройств последние будут считаться правильными. Применительно к ПО эта концепция может быть реали зована в случае, если имеется возможность реализации алгоритмически не идентичных модулей, выполняющих одну и ту же функцию. Возможно применение вариантов одного и того же модуля, написанного и отлаженного различными программистами.
Однако оба подхода нельзя признать удовлетвори тельными, так как достаточно трудно создать различные
версии модуля, выполняющие одну и ту же функцию Кроме того, должна быть написана дополнительная про грамма, управляющая работой версий модуля и обеспе чивающая сравнение полученных результатов Все это противоречит идее избежания ошибок, заключающейся прежде всего в минимизации сложности
Второй подход обеспечения динамической избыточно сти заключается в использовании дополнительных вари антов модулей, когда результаты работы основного мо дуля признаны некорректными Если результаты работы модуля некорректны, то система автоматически вызыва ет запасной модуль Если и вновь полученный результат неверен, то вызывается следующий модуль-дублер и т д. Данный подход обладает всеми перечисленными выше недостатками Кроме того, при наличии ограниченных ресурсов на разработку каждого последующего «запас ного» варианта будет обращаться меньше внимания, чем на один вариант, разрабатываемый без применения концепции динамической избыточности.
Набор вспомогательных методов допуска ошибок при меним только в том случае, когда работа системы долж на быть закончена каким-либо разумным образом На пример, если в системе контроля процесса обнаружена ошибка, то может быть загружен и выполнен вспомога тельный модуль, гарантирующий разумное завершение проверки всех контролируемых системой процессов Ана логичные функции необходимы в операционных систе мах для предупреждения пользователей о неминуемом сбое и возможной порче данных
В наборе средств допуска ошибок можно выделить категорию изоляции ошибок. Здесь суть заключается в попытке изолировать ошибки минимальной частью про граммной системы с тем, чтобы в случае возникновения ошибки система не потеряла своей работоспособности. Например, множество операционных систем изолирует ошибки конкретными пользователями, т. е. после возник новения ошибки она отразится только на подмножестве системных пользователей, а система в целом останется работоспособной. Другие средства изоляции ошибок за щищают каждую программу системы от ошибок других программ Ошибка прикладной программы, обрабатывае мой операционной системой, скажется на работе только самой программы, т е не будет влиять на операционную систему или на другие прикладные программы.
Из рассмотренных групп средств допуска ошибок
.70