Ващенко Г.В., Добронец Б.С. Надежность информационных систем. Лабораторный практикум

Подождите немного. Документ загружается.

Другой подход к исправлению связан с попытками восстановить разру-

шения, вызванные ошибками, например искажения записей в базе данных

или управляющих таблицах системы. Польза от методов борьбы с искажени-

ями ограниченна, поскольку предполагается, что разработчик заранее преду-

гадает несколько возможных типов искажений и предусмотрит программно

реализуемые функции для их устранения. Это похоже на парадокс, посколь-

ку, если знать заранее, какие ошибки возникнут, можно было бы принять

дополнительные меры по их предупреждению. Если методы ликвидации по-

следствий сбоев не могут быть обобщены для работы со многими типами

искажений, лучше всего направлять силы и средства на предупреждение

ошибок. Вместо того чтобы, разрабатывая операционную систему, оснащать

ее средствами обнаружения и восстановления цепочки искаженных таблиц

или управляющих блоков, следовало бы лучше спроектировать систему так,

чтобы только один модуль имел доступ к этой цепочке, а затем настойчиво

пытаться убедиться в правильности этого модуля.

Устойчивость к ошибкам

Методы этой группы ставят своей целью обеспечить функционирование

программной системы при наличии в ней ошибок. Их разбивают на три под-

группы: динамическая избыточность, методы отступления и методы изоля-

ции ошибок.

1. Истоки концепции динамической избыточности лежат в проектирова-

нии аппаратного обеспечения. Один из подходов к динамической избыточно-

сти — метод голосования. Данные обрабатываются независимо несколькими

идентичными устройствами, и результаты сравниваются. Если большинство

устройств выработало одинаковый результат, этот результат и считается пра-

вильным. Вследствие особой природы ошибок в программном обеспечении

ошибка, имеющаяся в копии программного модуля, будет также присутство-

вать во всех других его копиях, поэтому идея голосования здесь, видимо,

неприемлема. Предлагаемый иногда подход к решению этой проблемы состо-

ит в том, чтобы иметь несколько неидентичных копий модуля. Это значит, что

все копии выполняют одну и ту же функцию, но либо реализуют различные

алгоритмы, либо созданы разными разработчиками. Этот подход бесперспек-

тивен по следующим причинам. Часто трудно получить существенно разные

версии модуля, выполняющие одинаковые функции. Кроме того, возникает

необходимость в дополнительном программном обеспечении для организации

выполнения этих версий параллельно или последовательно и сравнения ре-

зультатов. Это дополнительное программное обеспечение повышает уровень

сложности системы, что, конечно, противоречит основной идее предупрежде-

ния ошибок — стремиться в первую очередь минимизировать сложность.

Второй подход к динамической избыточности — выполнять эти запасные

копии только тогда, когда результаты, полученные с помощью основной ко-

пии, признаны неправильными. Если это происходит, система автоматически

вызывает запасную копию. Если и ее результаты неправильны, вызывается

другая запасная копия и т. д. Этот подход страдает большинством перечис-

ленных ранее недостатков. Кроме того, вполне вероятно, что если ресурсы

при работе над проектом фиксированы, то при реализации “запасных” вер-

сий проектированию и тестированию будет уделено меньше внимания, чем

можно было бы уделить, если бы реализовывалась лишь одна копия и дина-

мическая избыточность не использовалась.

2. Вторая подгруппа методов обеспечения устойчивости к ошибкам назы-

вается методами отступления или сокращенного обслуживания. Эти методы

приемлемы обычно лишь тогда, когда для системы программного обеспече-

ния существенно важно благопристойно закончить работу. Например, если

ошибка оказывается в системе, управляющей технологическими процессами,

и в результате эта система выходит из строя, то может быть загружен и

выполнен особый фрагмент программы, призванный подстраховать систему

и обеспечить безаварийное завершение всех управляемых системой процес-

сов. Аналогичные средства часто необходимы в операционных системах. Если

операционная система обнаруживает, что она вот-вот выйдет из строя, она

может загрузить аварийный фрагмент, ответственный за оповещение пользо-

вателей у терминалов о предстоящем сбое и за сохранение всех критических

для системы данных.

3. Последняя подгруппа — методы изоляции ошибок. Основная их цель

— не дать последствиям ошибки выйти за пределы как можно меньшей ча-

сти системы программного обеспечения, так чтобы если ошибка возникнет, то

не вся система оказалась неработоспособной; отключаются лишь отдельные

функции в системе либо некоторые ее пользователи. Например, во многих

операционных системах изолируются ошибки отдельных пользователей, так

что сбой влияет лишь на некоторое подмножество пользователей, а система в

целом продолжает функционировать. В телефонных переключательных си-

стемах для восстановления после ошибки, чтобы не рисковать выходом из

строя всей системы, просто разрывают телефонную связь. Другие методы

изоляции ошибок связаны с защитой каждой из программ в системе от оши-

бок других программ. Ошибка в прикладной программе, выполняемой под

управлением операционной системы, должна оказывать влияние только на

эту программу. Она не должна сказываться на операционной системе или

других программах, функционирующих в этой системе.

Из этих трех подгрупп методов обеспечения устойчивости к ошибкам

только третья, изоляция ошибок, применима для большинства систем про-

граммного обеспечения.

Важное обстоятельство, касающееся всех четырех подходов, состоит в

том, что обнаружение, исправление ошибок и устойчивость к ошибкам в

некотором отношении противоположны методам предупреждения ошибок.

В частности, обнаружение, исправление и устойчивость требуют дополни-

тельных функций от самого программного обеспечения. Тем самым не толь-

ко увеличивается сложность готовой системы, но и появляется возможность

внести новые ошибки при реализации этих функций. Как правило, все рас-

сматриваемые методы предупреждения и многие методы обнаружения оши-

бок применимы к любому программному проекту. Методы исправления оши-

бок и обеспечения устойчивости применяются не очень широко. Это, однако,

зависит от области приложения. Если рассматривается, скажем, система ре-

ального времени, то ясно, что она должна сохранить работоспособность и

при наличии ошибок, а тогда могут оказаться желательными и методы ис-

правления и обеспечения устойчивости. К системам такого типа относятся

телефонные переключательные системы, системы управления технологиче-

скими процессами, аэрокосмические и авиационные диспетчерские системы

и операционные системы широкого назначения.

Принципы — это независимые от области приложения стратегии обеспе-

чения надежности программных систем. Рассматриваются принципы проек-

тирования системы, программы, модуля, направленные на предупреждение

ошибок. Для остальных трех категорий принципы неизвестны. Методы — это

более мелкие, обычно зависящие от области приложения тактические сред-

ства.

Процессы проектирования

Проектирование любого программного продукта включает несколько раз-

личных процессов. При хорошо поставленном руководстве проектом эти про-

цессы явно выражены, так что могут быть установлены контрольные сро-

ки, выбрана методология и по завершении каждого процесса можно прове-

рить “доброкачественность” его результатов. При плохом руководстве неко-

торые из этих процессов или все они не выделяются явно: каждый процесс

по-прежнему присутствует в каком-то виде, но некоторые из них проходят

неявно, вследствие чего контрольные сроки, методология и оценки никогда

не устанавливаются.

Рассмотрим модель процессов проектирования типичной крупной про-

граммной системы.

Требования → цели → предварительный внешний проект →

детальный внешний проект → проект архитектуры программы →

внешние проекты модулей → проекты логики модулей

Отметим, что модель не зависит от методологии. Все указанные в ней

действия должны выполняться в той или иной форме во всякой разработ-

ке, независимо от того, какой язык программирования был принят, писал

ли пользователь исходные требования, использовалось ли “структурное про-

граммирование” и т. д.

На первом шаге составляется перечень требований, т. е. четкое опреде-

ление того, что пользователь ожидает от готового продукта. Следующий шаг

касается постановки целей — задач, которые ставятся перед окончательным

результатом и самим проектом. Затем выполняется внешний проект высоко-

го уровня. На этом шаге определяется взаимодействие с пользователем, но

не рассматриваются многие его детали, такие, как форматы ввода-вывода.

Исходный внешний проект приводит к двум параллельным процессам.

В процессе детального внешнего проектирования завершается определение

взаимодействия с пользователем, описываются его мельчайшие подробности.

В процессе разработки архитектуры системы выполняется разложение ее на

множество программ, подсистем или компонент и определяются сопряже-

ния между ними. Эти два шага ведут к процессу проектирования структуры

программы, в котором проектируются модули, их сопряжения и взаимосвязи

для каждой программы, компоненты или подсистемы. Следующий процесс

— внешнее проектирование модуля — это точное определение всех сопряже-

нии модуля. Последний шаг — проектирование логики модуля — состоит в

разработке внутренней логики каждого модуля системы, он включает также

выражение этой логики текстом конкретной программы.

Следует также помнить, что в работе над любым проектом последова-

тельность процессов проектирования отнюдь не так проста. Есть существен-

ная обратная связь между процессами. Например, во время одного из шагов

внешнего проектирования могут быть обнаружены погрешности в формули-

ровке целей, тогда нужно немедленно вернуться и исправить их. При про-

ектировании структуры программы можно внезапно обнаружить, что ука-

занная во внешних спецификациях функция неосуществима или обойдется

слишком дорого, тогда может понадобиться принять компромиссное реше-

ние и изменить внешние спецификации.

Сложность

Сложность — это основная причина ошибок перевода и, следовательно,

одна из главных причин ненадежности программного обеспечения. Слож-

ность почти не поддается ни точному определению, ни измерению. Однако

можно сказать, что мерой сложности объекта является количество интеллек-

туальных усилий, необходимых для понимания этого объекта.

В общем случае сложность объекта является функцией взаимодействия

между его компонентами. Например, сложность внешнего проекта программ-

ной системы в некоторой степени определяется связями между всеми ее внеш-

ними сопряжениями, например между командами пользователя и соотно-

шениями между входной и выходной информацией системы. Сложность ар-

хитектуры системы определяется связями между подсистемами. Сложность

проекта программы — функция связей между модулями. Сложность отдель-

ного модуля — функция связей между его командами.

В борьбе со сложностью программного обеспечения можно привлечь две

концепции из общей теории систем. Первая — независимость. В соответствии

с этой концепцией для минимизации сложности необходимо максимально уси-

лить независимость компонент системы. По существу это означает такое раз-

биение системы, чтобы высокочастотная динамика ее была заключена в еди-

ных компонентах, а межкомпонентные взаимодействия представляли лишь

низкочастотную динамику системы.

Вторая концепция — иерархическая структура. Иерархия позволяет стра-

тифицировать систему по уровням понимания. Каждый уровень представля-

ет собой совокупность структурных отношений между элементами нижних

уровней. Концепция уровня позволяет понять систему, скрывая несуществен-

ные уровни детализации. Например, система, которую мы называем “чело-

век”, представляется иерархией. Социолог может интересоваться взаимоотно-

шениями людей, не заботясь об их внутреннем устройстве. Психолог работает

на более низком уровне иерархии. Он может исследовать различные логиче-

ские и физические процессы в мозге, не рассматривая внутреннего строения

областей мозга. Еще ниже в этой иерархии находится нейролог — он имеет де-

ло со структурой основных компонент мозга. Однако он может изучать мозг

на этом уровне, не заботясь о молекулярной структуре отдельных белков в

нейроне. Химик-органик интересуется построением сложных аминокислот из

таких компонент, как атомы углерода, водорода, кислорода и хлора. Наконец,

физик-ядерщик изучает систему на уровне элементарных частиц в атоме и

взаимодействия между ними.

Иерархия позволяет проектировать, описывать и понимать сложные си-

стемы. Если бы нельзя было принять описанный подход к изучению человека,

социологу пришлось бы рассматривать его как необъятное и сложное множе-

ство субатомных частиц. Очевидно, что такое количество деталей подавило

бы его, так что невозможны были бы даже те ограниченные знания о чело-

веке, которыми мы располагаем.

К этим двум концепциям сокращения сложности (независимость и иерар-

хическая структура) можно добавить третью: проявление связей всюду, где

они возникают. Основная проблема многих больших программных систем —

огромное количество независимых побочных эффектов, создаваемых компо-

нентами системы. Из-за этих побочных эффектов систему невозможно по-

нять. И можно быть уверенным, что систему, в которой нельзя разобраться,

было очень трудно спроектировать хотя бы с минимальной гарантией надеж-

ности.

Проектное решение любого уровня имеет некоторую внутреннюю орга-

низацию, или форму. Для минимизации сложности нам нужен метод прояв-

ления этой внутренней формы, с тем чтобы в соответствии с нею разбить

проект на части. При внешнем проектировании, например, разбиение систе-

мы в соответствии с ее внутренней формой называется концептуальной це-

лостностью. В разделах, посвященных разработке архитектуры системы и

проектированию структуры программы, рассматриваются методы определе-

ния этой внутренней формы для дальнейшего разбиения системы на мно-

жество компонент с высокой степенью независимости. При проектировании

логики программы дисциплина, называемая структурным программирова-

нием, имеет целью, помимо всего прочего, привести эту логику в соответствие

с несколькими базовыми стандартными формами.

Задания

Разработать предварительный проект ПО для ИС по учету успеваемости

в ВУЗе.

Разработать предварительный проект ПО для ИС по продаже билетов в

театре.

Лабораторная работа № 3.

Устойчивость к ошибкам

Цель работы: Закрепление знаний по теме “Надёжное программное обес-

печение. Основные показатели. Проектирование” и приобретение практиче-

ских навыков, необходимых при разработке программного обеспечения, функ-

ционирующее при наличии в нем ошибок.

Самостоятельная работа студента под контролем преподавателя:

При выполнении лабораторной работы студент пишет программу, ис-

пользуя три подгруппы способов повышения надёжности ПО: динамическая

избыточность, методы отступления и методы изоляции ошибок.

Форма отчетности: программа, содержащая средства обнаружения, пре-

дупреждения и устранения ошибок.

Обнаружение ошибок

Из четырех основных групп методов обеспечения надежности наилучшие

результаты дают методы предупреждения ошибок. В большинстве случаев,

однако, при разработке программного обеспечения никак нельзя предпола-

гать, что готовая программа не будет содержать ошибок. В этом и состоит

исходная предпосылка методов обнаружения ошибок, исправления ошибок

и обеспечения устойчивости к ошибкам: готовая программа (система) будет

содержать ошибки и поэтому должна быть спроектирована так, чтобы ее

поведение .было предсказуемо и в случае ошибки. При этом имеются в ви-

ду как ошибки в программном обеспечении, так и ошибки пользователя или

сбои аппаратуры.

Пассивное обнаружение ошибок

Если мы исходим из предположения, что в программном обеспечении

будут ошибки, то, очевидно, в первую очередь следует принять меры для их

обнаружения. Более того, если необходимо принимать дополнительные меры

(например, исправлять ошибки или их последствия), то все равно сначала

нужно уметь обнаруживать ошибки.

Меры по обнаружению ошибок можно разбить на две подгруппы:

пассивные попытки обнаружить симптомы ошибки в процессе “обычной”

работы программного обеспечения и активные попытки программной систе-

мы периодически обследовать свое состояние в поисках признаков ошибок.

Пассивное обнаружение рассматривается в этом разделе, активное — в сле-

дующем.

Меры по обнаружению ошибок могут быть приняты на нескольких струк-

турных уровнях программной системы. В этой главе мы будем заниматься

уровнем подсистем, или компонент, т. е. нас будут интересовать меры по

обнаружению симптомов ошибок, предпринимаемые при переходе от одной

компоненты к другой, а также внутри компоненты. Все это, конечно, приме-

нимо также к отдельным модулям внутри компоненты.

Разрабатывая эти меры, мы будем опираться на следующие положения:

1. Взаимное недоверие. Каждая из компонент должна предполагать, что

все другие содержат ошибки. Когда она получает какие-нибудь данные от

другой компоненты или из источника вне системы, она должна предполагать,

что данные могут быть неправильными, и пытаться найти в них ошибки.

2. Немедленное обнаружение. Ошибки необходимо обнаружить как мож-

но раньше. Это не только ограничивает наносимый ими ущерб, но и значи-

тельно упрощает задачу отладки.

3. Избыточность. Все средства обнаружения ошибок основаны на неко-

торой форме избыточности (явной или неявной).

Конкретные меры обнаружения сильно зависят от специфики приклад-

ной области. Однако некоторые идеи можно почерпнуть из следующего спис-

ка:

1. Проверяйте атрибуты любого элемента входных данных. Если вход-

ные данные должны быть числовыми или буквенными, проверьте это. Если

число на входе должно быть положительным, проверьте его значение. Если

известно, какой должна быть длина входных данных, проверьте ее.

2. Применяйте “тэги” в таблицах, записях и управляющих блоках и про-

веряйте с их помощью допустимость входных данных. Тэг — это поле записи,

явно указывающее на ее назначение.

3. Проверяйте, находится ли входное значение в установленных преде-

лах. Например, если входной элемент — адрес в основной памяти, проверяйте

его допустимость. Всегда проверяйте поле адреса или указателя на нуль и

считайте, что оно неверно, если равно нулю. Если входные данные — таблица

вероятностей, проверьте, находятся ли все значения между нулем и единицей.

4. Проверяйте допустимость всех вариантов значений. Если входное по-

ле — код, обозначающий один из десяти районов, никогда не предполагайте,

что если это не код ни одного из районов 1, 2, ..., 9, то это обязательно код

района 10.

5. Если во входных данных есть какая-либо явная избыточность, вос-

пользуйтесь ею для проверки данных.

6. Там, где во входных данных нет явной избыточности, введите ее. Если

ваша система использует крайне важную таблицу, подумайте о включении

в нее контрольной суммы. Всякий раз, когда таблица обновляется, следует

просуммировать (по некоторому модулю) ее поля и результат поместить в

специальное поле контрольной суммы. Подсистема, использующая таблицу,

сможет теперь проверить, не была ли таблица случайно испорчена, — для

этого только нужно выполнить контрольное суммирование.

7. Сравнивайте, согласуются ли входные данные с какими-либо внутрен-

ними данными. Если на входе операционной системы возникает требование

освободить некоторый блок памяти, она должна убедиться, что этот блок в

данный момент действительно занят.

Когда разрабатываются меры по обнаружению ошибок, важно принять

согласованную стратегию для всей системы (т. е. применить идею концеп-

туальной целостности к обнаружению ошибок). Действия, предпринимаемые

после обнаружения ошибки в программном обеспечении (например, возврат

кода ошибки), должны быть единообразными для всех компонент системы.

Активное обнаружение ошибок

Не все ошибки можно выявить пассивными методами, поскольку эти

методы обнаруживают ошибку лишь тогда, когда ее симптомы подвергают-

ся соответствующей проверке. Можно делать и дополнительные проверки,

если спроектировать специальные программные средства для активного по-

иска признаков ошибок в системе. Такие средства называются средствами

активного обнаружения ошибок.

Активные средства обнаружения ошибок обычно объединяются в диа-

гностический монитор: параллельный процесс, который периодически ана-

лизирует состояние системы с целью обнаружения ошибки.

Диагностический монитор можно реализовать как периодически выпол-

няемую задачу (например, она планируется на каждый час) либо как задачу

с низким приоритетом, которая планируется для выполнения в то время, ко-

гда система переходит в состояние ожидания. Как и прежде, выполняемые

монитором конкретные проверки зависят от специфики системы, но некото-

рые идеи будут понятны из примеров. Монитор может обследовать основную

память, чтобы обнаружить блоки памяти, не выделенные ни одной из выпол-

няемых задач и не включенные в системный список свободной памяти. Он

может проверять также необычные ситуации: например, процесс не планиро-

вался для выполнения в течение некоторого разумного интервала времени.

Монитор может осуществлять поиск “затерявшихся” внутри системы сообще-

ний или операций ввода-вывода, которые необычно долгое время остаются

незавершенными, участков памяти на диске, которые не помечены как выде-

ленные и не включены в список свободной памяти, а также различного рода

странностей в файлах данных.

Исправление ошибок и устойчивость к ошибкам

Имея средства обнаружения ошибок в программном обеспечении, есте-

ственно предпринять следующий шаг, попробовать создать средства, наце-

ленные на исправление обнаруженных ошибок. По существу, термин “исправ-

ление ошибок” в применении к программному обеспечению означает ликвида-

цию ущерба, нанесенного ошибкой, а не исправление самой ошибки. Как мы

уже видели, исправление ошибки в аппаратуре (например, автоматическим

переключением на запасное устройство) — вполне жизнеспособный прием,

но пытаться исправить настоящую ошибку в программном обеспечении без

участия человека бесполезно. Самое большее, что можно сделать в этом слу-

чае, — свести на нет ущерб, нанесенный ошибкой. Самое большее, что можно

сделать по части устойчивости к ошибкам, — либо сделать нанесенный ущерб

незаметным, либо изолировать его лишь в рамках части системы.

Однако самым сильным доводом против исправления ошибок и обеспече-

ния устойчивости остается следующий аргумент. Поскольку все равно необ-

ходимо заранее предвидеть несколько возможных ошибок, обычно лучше при

проектировании и тестировании направлять все усилия на их устранение.

Изоляция ошибок

В большой вычислительной системе изоляция программ является ключе-

вым фактором, гарантирующим, что отказы в программе одного пользовате-

ля не приведут к отказам в программах других пользователей или к полному

выводу системы из строя. Основные правила изоляции ошибок перечислены

ниже.

1. Прикладная программа не должна иметь возможности непосредствен-

но ссылаться на другую прикладную программу или данные в другой про-

грамме и изменять их.

2. Прикладная программа не должна иметь возможности непосредствен-

но ссылаться на программы или данные операционной системы и изменять

их. Связь между двумя программами (или программой и операционной систе-

мой) может быть разрешена только при условии использования четко опре-

деленных сопряжений и только в случае, когда обе программы дают согласие

на эту связь.

3. Прикладные программы и их данные должны быть защищены от опе-

рационной системы до такой степени, чтобы ошибки в операционной системе

не могли привести к случайному изменению прикладных программ или их

данных.

4. Операционная система должна защищать все прикладные программы

и данные от случайного их изменения операторами системы или обслужива-

ющим персоналом.

5. Прикладные программы не должны иметь возможности ни остановить

систему, ни вынудить ее изменить другую прикладную программу или ее

данные.

6. Когда прикладная программа обращается к операционной системе,