Шпаргалка по "Надежности информационных систем"

1) методы, позволяющие справиться со сложностью, свести ее к минимуму, так как это- главная причина ошибок перевода;

2) методы достижения большей точности при переводе;

3) методы улучшения обмена информацией;

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

Должно быть очевидно, что  предупреждение ошибок - оптимальный путь к достижению надежности программного обеспечения. Лучший способ обеспечить надежность - прежде всего не допустить возникновения ошибок. Гарантировать отсутствие ошибок, однако, невозможно никогда. Другие три группы методов опираются на предположение, что ошибки все-таки будут.

2. Если предполагать, что в программном обеспечении какие-то ошибки все же будут, то лучшая (после предупреждения ошибок) стратегия - включить средства обнаружения ошибок в само программное обеспечение(этап тестирования). Немедленное обнаружение имеет два преимущества: можно минимизировать влияние ошибки и последующие затруднения для человека, которому придется извлекать информацию о ней, находить ее и исправлять.

Меры по обнаружению  ошибок можно разбить на две подгруппы: пассивные попытки обнаружить симптомы ошибки в процессе «обычной» работы программного обеспечения и активные попытки программной системы периодически обследовать свое состояние в поисках признаков ошибок.

Пассивное обнаружение. Меры по обнаружению ошибок могут быть приняты на нескольких структурных уровнях программной системы. Здесь мы будем рассматривать уровень подсистем, или компонентов, т.е. нас будут интересовать меры по обнаружению симптомов ошибок, предпринимаемые при переходе от одного компонента к другому, а также внутри компонента. Все это, конечно, применимо также к отдельным модулям внутри компонента. Наилучшее решение - немедленно завершить выполнение программы или (в случае операционной системы) перевести центральный процессор в состояние ожидания. Конечно, во многих системах подобная стратегия бывает нецелесообразной (например, может оказаться, что приостанавливать работу системы нельзя). В таком случае используется метод регистрации ошибок. Описание симптомов ошибки и «моментальный снимок» состояния системы сохраняются во внешнем файле, после чего система может продолжать работу. Этот файл позднее будет изучен обслуживающим персоналом.

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

Активное обнаружение  ошибок. Не все ошибки можно выявить  пассивными методами, поскольку эти методы обнаруживают ошибку лишь тогда, когда ее симптомы подвергаются соответствующей проверке. Можно делать и дополнительные проверки, если спроектировать специальные программные средства для активного поиска признаков ошибок в системе. Такие средства называются средствами активного обнаружения ошибок.

Активные средства обнаружения ошибок обычно объединяются в диагностический монитор: параллельный процесс, который периодически анализирует состояние системы с целью обнаружить ошибку.

3. Следующий шаг - методы исправления ошибок; после того как ошибка обнаружена, либо она сама, либо ее последствия должны быть исправлены программным обеспечением (этап отладки). Исправление ошибок самой системой - плодотворный метод проектирования надежных систем. Некоторые устройства способны обнаружить неисправные компоненты и перейти к использованию идентичных запасных. Аналогичные методы неприменимы к программному обеспечению вследствие глубоких внутренних различий между сбоями аппаратуры и ошибками в программах. Если некоторый программный модуль содержит ошибку, идентичные «запасные» модули также будут содержать ту же ошибку.

Другой подход к исправлению связан с попытками  восстановить разрушения, вызванные ошибками, например искажения записей в базе данных или управляющих таблицах системы. Польза от методов борьбы с искажениями ограничена, поскольку предполагается, что разработчик заранее предугадает несколько возможных типов искажений и предусмотрит программно реализуемые функции для их устранения. Это похоже на парадокс, поскольку, если знать заранее, какие ошибки возникнут, можно было бы принять дополнительные меры по их предупреждению. Если методы ликвидации последствий сбоев не могут быть обобщены для работы со многими типами искажений, лучше всего направлять силы и средства на предупреждение ошибок.

 

25. Устойчивость ПС к ошибкам и обработка сбоев аппаратуры.

В большой вычислительной системе изоляция программ является ключевым фактором, гарантирующим, что  отказы в программе одного пользователя не приведут к отказам в программах других пользователей или к полному выводу системы из строя. Основные правила изоляции ошибок перечислены ниже:

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

2. Связь между двумя программами (или программой и операционной системой) может быть разрешена только при условии использования четко определенных сопряжении.

3. Прикладные программы и их данные должны быть защищены от операционной системы до такой степени, чтобы ошибки в операционной системе не могли привести к случайному изменению прикладных программ или их данных.

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

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

6. Никакие системные данные, непосредственно доступные прикладным программам, не должны влиять на функционирование операционной системы.

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

Реализация многих из этих принципов влияет на архитектуру  лежащего в основе системы аппаратного обеспечения. Улучшая общую надежность системы, следует заботиться не только об ошибках в программном обеспечении, но и об ошибках во входных данных системы (ошибки пользователя).

Еще один интересующий нас класс ошибок - сбои аппаратуры. Во многих случаях они обрабатываются самой аппаратурой за счет использования кодов, исправляющих ошибки, исправления последствий сбоев (например, переключением на запасные компоненты) и средств, обеспечивающих устойчивость к ошибкам (например, голосование). Некоторые сбои, однако, нельзя обработать только аппаратными средствами, они требуют помощи со стороны программного обеспечения. Ниже приводится список возможностей, которые часто бывают необходимы в программных системах для борьбы со сбоями аппаратуры.

1. Повторное выполнение операций. Многие сбои аппаратуры не постоянны (например, скачки напряжения, шум в телекоммуникационных линиях, колебания при механическом движении).

2. Восстановление памяти. Если обнаруженный случайный сбой аппаратуры вызывает искажение области основной памяти и эта область содержит статические данные (например, команды объектной программы), то последствия сбоя можно повторно загрузить область памяти.

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

4. Восстановление файлов. Системы управления базами данных обычно обеспечивают избыточность данных, сохраняя копию текущего состояния базы данных на выделенных устройствах ввода-вывода, регистрируя все изменения базы данных или периодически автономно копируя всю базу данных.

5. Контрольная точка/рестарт. Контрольная точка - это периодически обновляемая копия состояния прикладной программы или всей системы

6. Предупреждение отказов питания. Некоторые вычислительные системы, особенно те, в которых используется энергозависимая память, предусматривают прерывание, предупреждающее программу о предстоящем отказе питания.

7. Регистрация ошибок. Все сбои аппаратуры должны регистрироваться во внешнем файле.

 

26. Модели надежности программных обеспечения и их классификация.

Термин модель надежности программного обеспечения, как правило, относится к математической модели, построенной для оценки зависимости надежности программного обеспечения от некоторых определенных параметров. Значения таких параметров либо предполагаются известными, либо могут быть измерены в ходе наблюдений или экспериментального исследования процесса функционирования программного обеспечения. Например, поведение некоторой ветви программы на подмножестве наборов входных данных, с помощью которых эта ветвь контролируется, существенным образом связано с надежностью программы, однако характеристики этого поведения могут быть оценены независимо от оценки самой надежности. Другим таким параметром является частота ошибок, которая позволяет оценить именно качество систем реального времени, функционирующих в непрерывном режиме, и в то же время получать только косвенную информацию относительно надежности программного обеспечения (например, в предположении экспоненциального распределения времени между отказами).

Одним из видов  модели надежности программного обеспечения, которая заслуживает особого  внимания, является так называемая феноменологическая, или эмпирическая, модель. При разработке моделей такого типа предполагается, что связь между надежностью и другими параметрами является статической. С помощью подобного подхода пытаются количественно оценить те характеристики программного обеспечения, которые свидетельствуют либо о высокой, либо о низкой его надежности.

Рассмотрим классификацию  моделей надежности ПС, приведенную на рисунке. Модели надежности программных средств (МНПС) подразделяются на аналитические и эмпирические. Аналитические модели дают возможность рассчитать количественные показатели надежности, основываясь на данных о поведении программы в процессе тестирования (измеряющие и оценивающие модели). Эмпирические модели базируются на анализе структурных особенностей программ. Они рассматривают зависимость показателей надежности от числа межмодульных связей, количества циклов в модулях, отношения количества прямолинейных участков программы к количеству точек ветвления и т.д. Часто эмпирические модели не дают конечных результатов показателей надежности, однако они включены в классификационную схему, так как развитие этих моделей позволяет выявлять взаимосвязь между сложностью ПС и его надежностью. Эти модели можно использовать на этапе проектирования ПС, когда осуществлена разбивка на модули и известна его структура.

Аналитические модели представлены двумя группами: динамические модели и статические. В динамических МНПС поведение ПС (появление отказов) рассматривается во времени. В статических моделях появление отказов не связывают со временем, а учитывают только зависимость количества ошибок от числа тестовых прогонов (по области ошибок) или зависимость количества ошибок от характеристики входных данных (по области данных).

Для использования  динамических моделей необходимо иметь  данные о появлении отказов во времени. Если фиксируются интервалы каждого отказа, то получается непрерывная картина появления отказов во времени (группа динамических моделей с непрерывным временем). Может фиксироваться только число отказов за произвольный интервал времени. В этом случае поведение ПС может быть представлено только в дискретных точках (группа динамических моделей с дискретным временем).

 

27. Аналитические, эмпирические и интуитивные модели надежности ПО.

Аналитическое моделирование надежности ПС включает четыре шага:

1) определение предположений, связанных с процедурой тестирования ПС;

2) разработка или выбор аналитической модели, базирующейся на предположениях о процедуре тестирования;

3) выбор параметров моделей с использованием полученных данных;

4) применение модели - расчет количественных показателей надежности по модели.

 

Эмпирические модели в основном базируются на анализе структурных  особенностей программного средства (или  программы). Эмпирические модели часто не дают конечных результатов показателей надежности, однако их использование на этапе проектирования ПС полезно для прогнозирования требующихся ресурсов тестирования, уточнения плановых сроков завершения проекта и т.д. Примерами эмпирических моделей служат:

• Модель сложности При проведении тестирования известна структура программы, имитирующей действия основной, но не известен конкретный путь, который будет выполняться при вводе определенного тестового входа. Кроме того, выбор очередного тестового набора из множества тест-входов случаен, т.е. в процессе тестирования не обосновывается выбор очередного тестового входа. Эти условия вполне соответствуют реальным условиям тестирования больших программ. Полученные данные анализируются, проводится расчет показателей надежности по модели Миллса, и считается, что реальное ПС, выполняющее аналогичные функции, с подобными характеристиками и в реальных условиях должно вести себя аналогичным или похожим образом;
• Модель, определяющая время доводки программы. Эта модель используется для ПС, которые имеют иерархическую структуру, т.е. ПС как система может содержать подсистемы, которые состоят из компонентов, а те, в свою очередь, состоят из V модулей. На любом уровне иерархии возможна взаимная зависимость между любыми парами объектов системы. Все взаимозависимости рассматриваются в терминах зависимости между парами модулей. Анализ модульных связей строится на том, что каждая пара модулей имеет конечную (возможно, нулевую) вероятность, изменения в одном модуле вызовут изменения в другом модуле;