Система модельно-алгоритмической поддержки многоэтапного анализа надежности программных средств
Анализ методов оценки надежности программных средств на всех этапах жизненного цикла, их классификация и типы, предъявляемые требования. Мультиверсионное программное обеспечение. Современные модели и алгоритмы анализа надежности программных средств.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 03.11.2013 |
| Размер файла | 280,5 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Их отношение можно записать[93]:
(1.4)
Пусть количество ошибок за время t - N(t). Предположим, что ошибки устраняются по мере обнаружения. За основу возьмем экспоненциальную модель. Предполагается, что количество найденных и исправленных ошибок пропорционально количеству существующих ошибок.
Можно показать, что ?1 определяется как:
, (1.5)
где S - количество инструкций в коде, Q - количество объектных инструкций в каждой инструкции кода и r - уровень выполнения инструкции компьютером k - называется коэффициентом подверженности ошибкам и меняется от 1x10-7 до 10x10-7, t измеряется в секундах выполнения процессорного времени.
, (1.6)
где N(0) начальное количество ошибок, общее количество ошибок за время t:
, (1.7)
в общем случае получаем:
, (1.8)
где bo, общее количество ошибок, которые могут быть обнаружены равно N(0). Это предполагает, что во время отладки не делаются новые ошибки.
Выражение для интенсивности сбоев используя равенство:
(1.9)
Экспоненциальная модель легка для понимания и применения. Преимущество этой модели в том, что параметры ?0 и ?1 четко определены еще до начала тестирования.
SGRM может применяться при двух различных ситуациях.
1. До начала теста. Часто надо иметь предварительный план тестирования. Для экcпонентациональной или логарифмической модели можно оценить время для достижения требуемого значения интенсивности сбоев, MTTF или плотности ошибок.
Во многих случаях t должно измеряться в человеко-часах и должно быть умножено на соответствующий коэффициент, который определяется с использованием опыта предыдущих проектов.
2. Во время теста. Используя SGRM, можно оценить дополнительное время тестирования, необходимое для достижения желаемого уровня надежности.
Основные шаги использования SGRM:
1. Сбор данных. Данные об интенсивности сбоев включают множество погрешностей и «шума». Данные часто нуждаются в сглаживании. Наиболее общая форма сглаживания - это использование группировки данных. Группировка включает разделение теста на интервалы, затем рассчитывается средняя величина интенсивности сбоев на каждом интервале.
2. Выбор модели и определение параметров. Лучший способ выбора модели - это положиться на прошлый опыт проектов, использующих такую методику. Экспоненциальная и логарифмическая модели для экстраполяции параметров, используются чаще всего. Данные первых тестов содержат большое количество шума. На самых ранних стадиях тестирования параметры могут очень сильно отклоняться от реальных, и они не могут использоваться пока не будут стабилизированы.
3. Выполнение анализа о количестве дополнительных тестов. Используя подходящую модель, мы можем оценить количество необходимых дополнительных тестов для достижения определенного уровня интенсивности сбоев. Из этого рассчитывается минимальное время, которое необходимо затратить на тестирование.
В модели SGRM предполагается, что во время тестирования используется единая методика поиска ошибок. Каждая новая стратегия изначально эффективна для поиска определенных классов ошибок, но дает «всплески» в интенсивности сбоев. Для этого надо использовать процедуру сглаживания. Большей проблемой является то, что ПО продолжает модифицироваться во время тестов. Если изменения были значительны, то приходится выбрасывать из выборки значения, полученные ранее.
Одним из важных параметров эффективности SGRM является коэффициент покрытия ошибок. Коэффициент покрытия ошибок Cd линейно зависит от Св - коэффициента покрытия ветвлений. Коэффициент покрытия ветвления показывает, насколько эффективно были «захвачены» все возможные пути ветвления программы.
Cd= - a+bCв, Cв>0 (1.10)
Значения параметров a и b зависит от размера ПО и начальной плотности ошибок. Преимущество использования коэффициентов покрытия в том, что они напрямую зависят от того, насколько тщательно программа исследуется. Для достижения высокой надежности ПО должна использоваться более строгая мера, такая как коэффициент покрытия предикатов. Предикаты - условные операторы, которые влияют на внутренне поведение программы.
Операционные профили тестирования
Вполне очевидно, что абсолютно полный тест некоторых компонентов ПО практически невозможно выполнить[76]. Это легко представить на примере модуля, находящего корни квадратного уравнения. Входом в модуль является вектор коэффициентов уравнения, а выходом - вектор решений. Каждый входящий элемент может принимать значения от -? до +?. Сразу сталкиваемся с тем ограничением, что компьютерные программы не «умеют» работать с бесконечными числами, т.е. при очень больших или очень малых значениях входных коэффициентов мы даже не можем вычислить решение. Другое ограничение на время тестирования - если, например, перебирать значения коэффициентов от -5000 до 5000 с шагом 0.0001, то получим, что необходимо выполнить 1030 запусков модуля, что может занять несколько лет, при условии, что не будет обнаружено ошибок.
Некоторыми исследователями предлагается составлять так называемые операционные профили. Профили представляют собой таблицы, включающие информацию о диапазонах входных данных модуля и вероятности сбоя на данном диапазоне данных. Субъективные и методологические оценки процесса разработки ПО не должны отображаться в операционных таблицах данных. Конечно, класс и технологии разработчика должны учитываться при выборе компонента, но их роль должна подкрепляться точными техническими данными.
Есть два способа оценки качества ПО:
1. Компонент был признан корректным.
2. Он был действительно (случайным образом) протестирован.
Оба способа требуют формальную спецификацию того, что компонент должен делать. Утверждение того, что компонент был признан корректным - это гарантия его выполнения согласно его спецификации. Заявление, говорящее, что надежность компонента выше за одно выполнение с доверительной вероятностью 99%, означает, что не более, чем в одном из ста случаев ошибка может произойти в одном из 10 000 испытаний.
Отображения профиля. Рабочие операционные профили должны рассматриваться при занесении результатов измерений в таблицу. Так как разработчик компонента не может знать, как его продукт будет использован и, следовательно, с каким профилем он встретится, будучи частью системы, таблица данных должна рассматривать профиль как параметр. Это значит, что в ней определяется отображение профиля в параметры надежности.
Подобласти компонентов. Компонент имеет естественное разделение его входного пространства на функциональные подобласти, и практическое описание его профиля как вектора весов над этими подобластями. Такая форма профиля позволяет разработчику тестировать компонент, не зная заранее, с каким разрезом данных он может позднее встретиться.
Процесс разработки компонента и системы
В общих чертах, процесс создания и использования компонентов можно представить так:
- Разработчик компонента определяет множество входных подобластей для выполнения компонента.
- Разработчик компонента измеряет свойства компонента для каждой подобласти.
- Разработчик компонента размещает в таблице данных список подобластей компонента и надежность.
- Системный проектировщик определяет структуру системы, использующей компоненты.
- Используя таблицы предполагаемых компонентов и испытательных профилей для системы, системный проектировщик вычисляет надежность системы.
- Если нельзя достигнуть требуемой надежности системы, необходимо найти лучшие компоненты, или изменить структуру системы, а после этого повторить вычисления.
Такая идеализированная модель не применима на практике. В настоящее время не существует принципиальной теории надежности программной системы, состоящей из компонентов. Успешное теоретическое обоснование должно использовать сравнительно простую модель, но в то же время пользоваться сложившейся теорией тестирования и теорией надежности.
Рабочие профили компонент программного обеспечения
Если информация о качестве компонента в его таблице данных статистического характера, то она должна быть получена путем случайного тестирования. Профиль, предназначенный для компонента, зависит не только от входного профиля системы, но также от позиции компонента в системе и действий других компонентов. Операционный профиль можно записывать с помощью двух таблиц, содержащих отображения профиля (одна для надежности, другая для изменения профиля). Эти таблицы определяются через разделение на части входной области. Системный проектировщик может использовать эти части для вычисления надежности системы до начала ее работы.
Размер компонентов
Размер компонентов может качественно повлиять на концепцию разработки ПО, основанного на компонентах. Размер компонента во внимание не берется, кроме неявного допущения о том, что разработчик компонента протестировал компонент для подготовки его операционного профиля. ПО размером операционной системы (или даже компилятора) практически не может быть протестировано в целом, так же как не могут быть определены подходящие подобласти. Из этого следует, что такие системы должны быть построены из компонентов меньшего размера, подходящего для прямых оценок. До того, как рассматривать операционную систему в качестве компонента, нужно проанализировать ее собственные компоненты.
1.9 Выводы
Можно сделать следующие выводы:
Оценка и анализ надежности должны осуществляться на каждом шаге создания отказоустойчивого ПО.
В связи с тем, что нет единого подхода, методики и параметров для оценки надежности ПО, в настоящее время существует множество моделей и алгоритмов проверенных практически, но имеющих ряд недостатков. Основной недостаток всех моделей - «узкая специализация». Модели всегда привязаны к какой-либо одной фазе разработки ПО, а иногда имеют чисто теоретическую ценность из-за того, что в них должны быть использованы данные с других стадий разработки ПО, и авторы таких моделей отводят этому факту второстепенное значение.
Наиболее перспективным является подход, направленный на создание некоторой гибридной модели, включающей в себя все достоинства хорошо проверенных моделей и алгоритмов. Существующие модели и алгоритмы необходимо модифицировать таким образом, чтобы выходные данные одной модели стали входными для других; предусмотреть единство понимания параметров, пересчет единиц измерения, нормализацию данных и удовлетворение современным требованиям и тенденциям, например, объектно-ориентированный анализ и программирование. Необходимо использовать как можно больше априорной информации перед началом каждой фазы создания ПО, что обеспечит наиболее приемлемые и точные результаты.
2. Мультиверсионное программное обеспечение
Можно выделить три формы избыточности: аппаратную, программную, временную. Аппаратная избыточность должна предупредить отказы аппаратных средств, а программная и временная - случайные сбои. Программная избыточность включает применение специальных контрольных программ и контрольных кодов. Временная избыточность подразумевает многократное исполнение программ для отдельных функций, надежность которых должна быть особенно высокой. Как известно, концепция избыточного программирования была введена A. Авиженисом [1,63].
Мультиверсионность исполнения программных модулей подразумевает независимую генерацию N і 2 функционально эквивалентных программ (мультиверсий) в соответствии с идентичными исходными спецификациями. Для этих N версий программ предоставляются средства конкурентного исполнения, в ходе которого в назначенных точках контроля (сс-points) программами генерируются вектора сравнения (с-vectors). Составляющие векторов сравнения и контрольные точки предварительно определены еще на этапе исходных спецификаций.
2.1 Базовые элементы мультиверсионного программного обеспечения
программный мультиверсионный алгоритм
Анализируя результаты исследований последних лет в области рассматриваемой методологии, можно выявить три составляющих элемента мультиверсионного программирования, которые являются базовыми при синтезе отказоустойчивого программного обеспечения [6,7,32,42,68,77,108].
1. Процесс исходной спецификации и мультиверсионного программирования (N-version programming - NVP), который предполагает гарантию независимости и функциональной эквивалентности N индивидуальных процессов программирования.
2. Результат (мультиверсионное программное обеспечение - N-version software или NVS) NVP - процесса, для которого имеются в наличии средства конкурентного исполнения со специфицированными точками контроля и с-векторами.
3. Внешние средства поддержки исполнения мультиверсий ПО (N-version executive или NVX), которые обеспечивают исполнение NVS и предусматривают алгоритмы принятия решений в контрольных точках.
Все три элемента NVP объединены целью независимой и конкурентной генерации N і 2 функционально эквивалентных программных компонент, которые затем будут исполнены и будет принято решение о правильности функционирования ПО. В этих элементах совершенно нет необходимости в случае использования одной версии программы, таким образом, концепция NVP (как подход к созданию отказоустойчивого ПО) вводит такие новые направления исследований в области инжиниринга программного обеспечения, как NVP, NVS, NVX, определения которых мы рассмотрели.
Рисунок 2.1. Структура мультиверсионного ПО (NVS)
При анализе структуры мультиверсионного ПО необходимо отметить, что существенное отличие между многоканальными аппаратными средствами и отказоустойчивым ПО заключается в том, что простое дублирование одних и тех же элементов при проектировании является эффективным против случайных ошибок, имеющих физическую природу, в технических системах, но не эффективно при отказах ПО. Простое копирование - это также и копирование необнаруженных на данный момент («спящих») ошибок в программах, поэтому N программных компонент должны разрабатываться отдельно и независимо друг от друга, что и соответствует концепции избыточного проектирования ПО.
Можно выделить два основных направления отказоустойчивого программирования: мультиверсионное программирование - NVP и программирование с восстановительным блоком - RB. Общим является наличие двух или более избыточных компонент (в NVS они названы версиями, а в RB-подходе - альтернативами, объединенными с приемным тестом). Основное же отличие заключается в методе, с помощью которого принимается решение о результатах работы программ. Очевидно, возможны комбинации базовых схем, а также расширение функций ЕЕ-среды как для NVP-процесса (например, многоуровневый решающий алгоритм, общий или индивидуальный RB-блок для мультиверсионной программы), так и для RB - метода (например, кэш-память для восстановления программных компонент, многоуровневый иерархический приемный тест и т.д.).
Реализация восстановительного элемента в обоих методах имеет ограничение: в RB ошибки, которые не будут обнаружены приемным тестом (а такое возможно), не приведут к переключению на восстановление при функционировании ПО; в NVS переключение на восстановление будет неверным, если большинство версий предоставят ошибочный результат в точке восстановления.
Однако, наличие N > 2 версий избыточных компонент ПО еще не подразумевает устойчивость этого ПО к отказам, так как необходимо наличие среды исполнения («execution environment» - EE) для NVS. Как отдельные версии ПО, так и ЕЕ-среда должны отвечать следующим требованиям:
ЕЕ-среда должна предусматривать функции поддержки исполнения N>2 версий программных компонент в режиме контроля ошибок;
Индивидуальные спецификации версий ПО должны определять способы достижения отказоустойчивого исполнения, которые поддерживаются в ЕЕ-среде;
Наилучший исход NVP должен минимизировать вероятность необнаружения (или невозврата для RB) ошибочного исполнения мультиверсионного программного компонента в отличие от обычной программной системы.
Определив основные элементы мультиверсионного программирования, отметим не менее важные проектные этапы, которые относятся, во-первых, к спецификации версий NVS-систем ПО (с учетом требований к их дальнейшему конкурентному исполнению в EE-среде с использованием внешних средств поддержки исполнения NVX); во-вторых, к непосредственному этапу программирования, учитывая, что основное требование NVP - максимальная независимость исходов процесса и, соответственно, версий ПО; в-третьих, к созданию NVX-систем EE-среды исполнения программных компонент мультиверсионного ПО как с высокой надежностью, так и с эффективными показателями по времени исполнения, что особенно важно для использования блоков NVS-систем в ПО автономных комплексов управления, работающих в реальном времени.
Решение первой из указанных проблем основывается на применении системы спецификаций мультиверсионного ПО, названной «V-Spec», которая определяет:
- функцию, которая должна быть выполнена с учетом ограничений по времени исполнения, исходных данных и начального состояния версии ПО;
- требования по внутреннему контролю ошибок и тестированию версий модуля;
- требования по разнообразию программирования;
- контрольные точки (сс-точки), в которых решающий алгоритм NVX-среды будет применен для контроля всех версий;
- точки восстановления (r-точки), в которых осуществляется применение RB-блока для восстановления ошибочно выполненных версий ПО;
- параметры решающего алгоритма NVX-среды, используемые в каждой сс- и r-точке;
- возможные исходы исполнения в NVX-среде, включая случай, когда решающий алгоритм не способен принять решение.
Относительно NVX-систем поддержки исполнения версий можно отметить, что их основные функции должны обеспечивать следующее:
- решающий алгоритм или множество алгоритмов;
- входные последовательности данных для всех версий;
- внутриверсионную коммуникацию;
- синхронизацию исполнения версий (если позволяет аппаратно - программный комплекс) при жестких временных ограничениях;
- «локальное» управление исполнением каждой версии;
- «глобальное» исполнение мультиверсионного ПО в совокупности с решающими функциями восстановления ошибочных версий по r-точкам (локальный RB-блок в составе NVX);
- диалоговый интерфейс пользователя NVX-системы.
2.2 Жизненный цикл мультиверсионного программного обеспечения
Рассмотрим последовательно процедуры методологии мультиверсионного программирования в сравнении со стандартным ЖЦПО.
Фаза системных спецификаций - формирование NVX (NVS - супервизор)
На этой фазе внешняя среда поддержки исполнения (NVX) мультиверсионного ПО должна быть определена с учетом эволюции всей системы и обеспечения требований к пользовательскому интерфейсу. Существует три аспекта этого этапа.
1. Выбор способа реализации NVX-среды и распределение ресурсов.
Очевидно, что вся архитектура системы формируется на фазе системных спецификаций и, тем самым, выбирается конфигурация ПО, количество версий и способ их взаимодействия.
2. Средства поддержки сопровождения и инструментарий.
Существующие NVX-среды могут быть адаптированы и приспособлены к новым приложениям, при этом следует отметить, что NVX-среда может быть организована в виде как программных, так и аппаратных средств (возможны комбинации). Базовые функции NVX в качестве супервизора NVS включают: решающий алгоритм (или множество алгоритмов); средства обеспечения соответствия исходных состояний всех версий; межверсионное взаимодействие; синхронизацию версий и выполнение ограничений по времени; «локальный супервизор» для каждой версии; общее конкурентное исполнение и решающие функции для восстановления ошибочных версий; интерфейс пользователя для контроля, ввода команд управления, сбора информации при мультиверсионном исполнении программ.
3. Выбор структуры аппаратных средств.
Относительно этого аспекта лишь отметим, что в некоторых случаях для исполнения NVS-системы ПО, может потребоваться специально предназначенный для этих целей процессор (или несколько процессоров). Особенно это важно, если NVS применяется в системах реального времени с жесткими ограничениями. Возможна гибридная структура, включающая отказоустойчивые аппаратные средства.
Фаза выработки требований к ПО - выбор способов достижения и степени разнообразия версий ПО
На этой фазе жизненного цикла ПО главная задача - избежать совпадения способов программирования, потенциально влияя на независимость ошибок мультиверсий. Выделим три этапа выбора.
1. Распределение между случайным разнообразием и разнообразием за счет предъявления установленных требований.
Если первое соответствует персональным качествам программиста (способ мышления, программистский индивидуализм), то второе, наоборот, является формальным способом, позволяющим установить требования к языку программирования, способам обеспечения надежности и т.д.
2. Оценка требуемого разнообразия процесса проектирования ПО (по большинству фаз ЖЦПО)
Фактически имеется четыре фазы, которые способствуют разнообразию: спецификация, проектирование, кодирование и тестирование (различные языки программирования, инструментальные средства, алгоритмы, методологии).
3. Разнообразие как проектные ограничения.
Устанавливается через последний из возможных способов, который специфичен для каждой программной разработки, а типичным проектным ограничением является стоимость, строгая последовательность работ, независимость этапов и т.д.
Фаза спецификации ПО - установка определителей ошибок и алгоритмов восстановления
Спецификация версий NVS-ПО осуществляется с помощью «V-spec» [77], которые полностью устанавливают функциональные требования к модулю ПО и на этой фазе должен быть выбран и специфицирован детектор ошибок и алгоритм восстановления (с-точки, с-вектор, RB-блок). При соответствии этих параметров в каждой версии ПО необходимо стремиться избегать факторы, ограничивающие разнообразие, например, использовать различные типы «V-spec», устанавливающие одинаковые требования.
Фаза проектирования и кодирования - ведение C\D-протокола развития NVS
На этой фазе стартует мультипрограммирование конкурентных версий ПО в соответствии со спецификациями «V-spec». Определяется строгий протокол взаимодействия и документирования (C\D-протокол). Одним из положительных последствий протокола является то, что он дает достаточную совокупность деталей при поиске причин ошибочного исполнения NVS-компонента на более поздней стадии эксплуатации ПО.
Фаза тестирования - фаза предварительной эксплуатации NVS
На этом этапе при последовательном тестировании N > 2 версий может осуществляться дополнение состава ПО, если велика вероятность ошибочного исполнения за счет выдачи одинаково неверного результата большинством мультиверсионных компонентов. Здесь же возможно привлечение экспертов для определения по результатам тестового прогона «образцовой» версии ПО.
Фаза оценки и принятия - оценка отказоустойчивости NVS
Оценка атрибутов, характеризующих отказоустойчивость ПО, подразумевает аналитическое моделирование, имитационное, эксперименты (или комбинации этих методов). Необходимо: определить критерии оценки отказоустойчивости; оценить признаки многообразия; сделать предварительные заключения, для чего рассматриваются два аспекта, касающиеся выбора подходящей модели оценки надежности ПО и определения количественных показателей метода оценки соответственно.
Фаза сопровождения и развития - выбор и осуществление способа сопровождения NVS
Сущность фазы сопровождения NVS характеризуется следующей спецификой. Во-первых, функционально NVX-среда должна быть соответствующим образом гарантирована от сбоев и ошибок на протяжении этой операционной фазы. Критичные по надежностным требованиям части NVS-супервизора могут быть защищены путем применения мультиверсионной методологии. Аномальные ситуации, регистрируемые в процессе сопровождения, являются объектом дальнейших исследований. Во-вторых, модификация NVS-системы ПО должна следовать проектной парадигме мультиверсионного программирования. При добавлении функций ПО это может касаться как непосредственно мультиверсий, так и составных частей NVX-среды (решающие алгоритмы, приемные тесты и т.д.).
Анализ содержания указанных процедур методологии позволяет сделать заключение о том, что в настоящее время только рассматриваемый нами подход мультиверсионного отказоустойчивого программирования является возможной альтернативой методам тестирования и доказательства правильности программ, обеспечивая высокий уровень надежности исполнения критичных по сбоям и ошибкам программных компонент. Именно данная методология обеспечивает гарантию того, что ошибки одной из версий не приведут к нарушению процесса управления сложными объектами, для которых характерны жесткие требования по надежности и автономности функционирования.
Наконец, на этапе сопровождения отказоустойчивого ПО, при его развитии и модификации основное внимание направлено на разработку спецификаций «V-Spec» с использованием языков высокого уровня, что позволяет привлекать к разработке мультиверсионных компонент непосредственно специалистов по управлению и основное внимание уделять качеству требований на разработку надежного программного обеспечения. Существенным является и то, что при модификации программной системы следование парадигме мультиверсионности обязательно, причем при развитии и добавлении функций ПО это касается как мультиверсий, так и составных частей NVX-среды.
2.3 Восстановление сбойных компонент при мультиверсионном объектно-ориентированном программировании
Объектно-ориентированный подход позволяет создать схему избыточности, реализующую обнаружение ошибок, позволяющую не только контролировать, но и делать восстановление сбойных версий компонент, а также предотвращать распространение ошибок. Для того чтобы реализовать такие механизмы, должен быть создан специальный класс, методы которого будут отображать внутреннее состояние объектов на более абстрактный уровень[4].
Функционирование N-версионного ПО зависит от среды выполнения, которая ответственна за то, чтобы версии компонент выполнялись параллельно, синхронизировались, передавали свои результаты выполнения в решающий блок и т.д. Используя концепции объектно-ориентированного подхода, мы можем встроить некую мультиверсионную среду непосредственно в систему, которая будет прозрачна для пользователя, и может быть легко использована для любого компонента.
Подход к построению избыточности программного обеспечения
Фундаментальные принципы разработки современного избыточного ПО:
1) Избыточные компоненты должны быть разработаны методом структурного программирования.
2) Должна быть обеспечена возможность применения схем избыточности рекурсивно. Это позволяет любой суб-компонент системы, который является рекурсивным для любого компонента, разрабатывать избыточно.
3) Другой важный момент - инкапсуляция избыточности. Сложные системы должны строиться таким образом, чтобы избыточность компонент была скрыта от внешних компонент. Это означает то, что контроль за избыточностью, как и сама избыточность, контролируемая в ПО, должны быть скрыты внутри компонент, которые предоставляют приложению только обычный интерфейс.
4) Независимость разработки версий компонент. Сама схема должна поддерживать независимую разработку компонент.
5) Контроль и поддержка избыточности должны быть разделены настолько, насколько это возможно от кода приложения и компонент.
Избыточность программного обеспечения и объектно-ориентированный подход
Применение N-версионного программирования при разработке классов и объектов, являющихся элементами архитектуры объектно-ориентированного ПО, может позволить достаточно просто реализовать все особенности перечисленные выше. Такой подход позволяет применять все преимущества ООП при разработке ПО без разбиения структуры системы на сложные интерфейсы взаимодействия элементов системы.
При разработке N-версионного ПО, в контексте ООП, должны быть реализованы все элементы схемы в терминах ООП: избыточные компоненты, версии, решающие блоки, механизм контроля (менеджер или супервизор), входные / выходные параметры, внутреннее представление данных. Основная идея заключается в использовании избыточности классов при разработке их по одной и той же спецификации. Такие классы называют DI-классы (Diversity-Implemented).
Разработчики версий объектов используют одинаковые спецификации. Версии являются скрытыми внутри DI-классов. Кроме того, DI-классы имеют внутри скрытые объекты - решающий модуль и менеджер (механизм контроля).
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
Рисунок 2.2. Представление DI-класса
Все DI-классы должны быть наследованы от мета-класса, в котором реализованы все механизмы построения и контроля избыточности в виде скрытых методов класса.
Когда вызывается метод DI объекта, метод-менеджер вызывает этот метод во всех N-версиях для параллельного выполнения, ожидает результатов и отсылает их в решающий модуль - метод для сравнения. Решающий модуль возвращает уже правильный результат, если есть большинство среди решений. Если все результаты отличаются, то метод-менеджер сигнализирует об ошибке.
Общие принципы реализации мультиверсионной избыточности
Первая схема восстановления компонент после сбоя появилась достаточно давно - CER (Сommunity Еrror Recovery), предложена еще Авиженисом[63]. Основная идея заключалась в том, что состояние корректных версий может быть использовано для восстановления сбойных версий. Эта идея использовалась и развивалась достаточно долго. Основной недостаток этой идеи заключается в том, что невозможно сделать откат всех версий компонента или хотя бы одного из них (сбойного).
Другой подход - это использование управления исключениями внутри каждой сбойной версии. Но это не дает гарантии того, что состояния всех версий одинаково без знания состояния корректной версии.
В CER состояние корректной версии используется для восстановления сбойной версии в состояние, в котором она не могла бы дать сбой. Это частный случай «восстановления вперед» после сбоя (forward error recovery). Единственное важное сходство с «восстановлением назад» то, что состояние версии компонента устанавливается в уже известное состояние. Фактически это восстановление «откатывает» состояние версии компонента вперед, в первое корректное состояние, полученное из корректного компонента. Главная проблема такого восстановления заключается в сложности создания функций отображения для передачи внутренних состояний версий компонента.
В CER единицы избыточности четко не определены, они не являются структурными единицами системы - это N независимо разработанных программ, которые состоят из модулей одинаковой функциональности выполняемых в одинаковом порядке. Построены программы по одинаковым спецификациям. Такой подход не является рекурсивным, он имеет ограничения в версиях. В таком подходе избыточность версий не инкапсулирована. Количество контрольных точек должно быть одинаковым для всех версий, и они должны включать одинаковый набор типов данных. Разработка N программ имеет свои ограничения, например, они должны содержать те же модули, выполнение которых заканчивается в точках восстановления.
В CER используется двухуровневое обнаружение ошибок, но с некоторыми особенностями. В точках восстановления (r-points) делается то же самое, что и в точках сравнения (cc-points). В точках сравнения происходит сравнение массивов данных - векторов сравнения (cc-vectors), которые должны быть одинаковыми для всех версий компонента. Не всегда известно как выбрать эти вектора. Тем не менее, эти данные очень важны, т.к. именно они используются для восстановления. Восстановление заключается в установке корректных данных в вектор сравнения для сбойной версии. Выбор наборов данных, которые служили бы как для обнаружения, так и для восстановления версий, является достаточно сложной задачей.
Современные подходы реализации мультиверсионной избыточности
CER был первый из подходов использующих два типа точек: сс-points (точки контроля) и r-points (точки восстановления), в которых происходила синхронизация версий - это двух уровневое восстановление. Точки сравнения используются не только для сравнения векторов сравнения (cc-vectors), но и для частичного восстановления версий: каждая версия посылает решающему модулю результат, включающий и вектор сравнения. Вектор сравнения используется для частичного восстановления, т.к. данные в этом векторе представляют подмножество состояний версий. Каждая версия состоит из нескольких модулей, выполняемых последовательно, каждый модуль имеет несколько контрольных точек внутри.
Точки восстановления устанавливаются между модулями и используются для полного восстановления версии модуля или компонента. В этих точках конечное состояние каждой версии отображается в промежуточном формате, общего для всех версий, таким образом, чтобы результаты могли быть сравнены и переданы сбойной версии для восстановления.
Недавно была разработана концепция абстрактного состояния версии, представленная в объектно-ориентированных терминах.
2.3.5 Объектно-ориентированное восстановление версий компонент программного обеспечения
Объектно-ориентированная схема использует двухуровневое отслеживание сбоев: как выходных переменных, так и состояний версий. Первое дает гарантию того, что никакая ошибочная информация не распространится за пределы класса. Второе используется для предотвращения распространения сбоя внутри класса, здесь сравниваются внутренние состояния версий через специальное унифицированное представление, называемое абстрактным состоянием версии. Разработчик версии должен перекрыть метод DI мета-класса, который выполняет вычисление текущего абстрактного состояния версии и возвращающий результат методу-менеджеру.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
Рисунок 2.3. Схема восстановления сбойного компонента из абстрактного состояния другой версии компонента
Метод-менеджер передает абстрактные состояния всех версий в решающий модуль (метод DI мета-класса). Это предполагает, что состояние сбойной версии инкапсулировано внутри версии объекта, таким образом, этого достаточно для восстановления этого объекта. Внешние спецификации одинаковые для всех версий и предполагается, что они корректны и сбои происходят из-за ошибок, допущенных при программировании версий. Предполагается, что метод абстрактного отображения состояния версии корректен. Абстрактное состояние версии может быть представлено как множество различных данных, представляющих различные аспекты конкретного состояния объекта. Данные такого типа используются методом-менеджером для контроля восстановления версий. Данные скрыты внутри DI объекта. Их тип зависит от конкретного приложения и может быть выполнен как класс, включающий в себя только методы доступа. Поэтому достаточно только одного экземпляра класса для каждого DI объекта. Решающий метод является достаточно простым, т.к. он не должен содержать сложных вычислений - он сравнивает только выходы версий, которые должны быть одного типа.
В некоторых приложениях методы-менеджеры можно сделать более гибкими для реализации более гибких политик управления версиями и уменьшения стоимости разработки.
Одна из таких политик заключается в сравнении входных состояний версий, например, в очень сложных функциях, где вполне вероятно, что ошибка произойдет во время вычислений такой функции.
Другая интересная политика в разнесении вычислений во времени, когда выходы одинаковые, а состояния версий разные - использование реплик при выполнении, когда метод-менеджер уже получил подтверждение от решающего метода о большинстве и прерывает не выполнившиеся до конца версии. Применяется чаще для однопроцессорного аппаратного обеспечения и для экономии процессорного времени.
Еще одна интересная комбинация двух видов сравнения результатов заключается в анализе входных и выходных значений параметров. Например, некоторые методы могут не содержать выходов, и в таком случае не происходит вызов решающего метода, поэтому здесь мы можем сравнивать входные и выходные значения состояний версий.
2.4 Выводы
Существуют две главные идеи, на которых строится концепция абстрактного состояния версии компонент мультиверсионного ПО. Во-первых, все версии объектов имеют общие состояния данных, т.к. они являются экземплярами одного и того же класса. Абстрактное состояние версии заключается в абстрагировании всех экземпляров. Во-вторых, абстрактные состояния версий могут использоваться для различных целей помимо восстановления версий: измерение производительности, откат действий (транзакций), совершенных в системе, сбор различной статистической информации о моделируемом объекте или процессе и т.п.
При разработке функций отображения и абстрактных состояний версий могут быть получены некоторые вспомогательные результаты:
1) Выполнение «фонового тестирования» версий, которые в текущий момент не используются для сравнения их абстрактных состояний.
2) Сохранять абстрактные состояния версий в хранилище данных и использовать для восстановления сбойный версий.
3) «Откат» всех версии назад и их перезапуск (может быть полезно, когда решающий метод не выявил большинство).
4) Реализация схемы «отката вперед».
3. Модели и алгоритмы анализа надежности программных средств
В данной главе приводятся модели и алгоритмы, позволяющие оценивать параметры надежности ПО на всех основных стадиях разработки. Приводится универсальная модель оценки параметров надежности, позволяющая легко адаптировать ее как к мультиверсионному, так и к ПО с распределенной архитектурой. Модель адаптирована к современным методам анализа и разработки ПО, в частности рассмотрена возможность применения модели для объектно-ориентированного подхода построения ПО.
3.1 Модель анализа на этапе дизайна архитектуры программного обеспечения
Оценку параметров надежности архитектуры можно оценить с помощью предлагаемой базовой модели, основные параметры которой следующие:
M - число уровней архитектуры ПО;
F - общее число компонент в архитектуре ПО;
Ni - число компонент на уровне i, i=1., M;
Dij - непересекающиеся множества компонент j на уровне i, i=1., F, j=1., M;
G - граф задающий компоненты и связи между компонентами архитектуры
Gij - матрица инцидентности графа G, размером (FxF)
Ri - коэффициент надежности компонента i, i=1., F;
Ci - стоимость разработки компонента i, i=1., F;
Zi - множество версий компонента i, i=1., F;
PUi - вероятность использования компонента i, i=1., F;
PFi - вероятность сбоя в компоненте i, i=1., F;
PLij - условная вероятность сбоя в компоненте i при сбое в компоненте j, i=1., F, j=1., F;
TAi - относительное время доступа к компоненту i, i=1., F;
TCi - относительное время анализа сбоя в компоненте i, i=1., F;
TEi - относительное время устранения сбоя в компоненте i, i=1., F;
TUi - относительное время использования компонента i, i=1., F;
TR - среднее время простоя системы;
MTTF - среднее время появления сбоя;
S - коэффициент готовности системы;
Rs - коэффициент надежности системы;
Cs - стоимость разработки системы.
Для данной модели обязательно выполнение условия:
(3.1)
Матрица инцидентности графа G задается следующим образом:
- элемент матрицы Gij равен 0, если между i-м и j-м компонентом нет взаимосвязи;
- элемент матрицы Gij равен 1, если i-й компонент использует j-й компонент;
- элемент матрицы Gij равен -1, если i-ый компонент используется j-ым компонентом.
Cреднее время простоя системы вычисляется как:
(3.2)
Среднее время появления сбоя вычисляется как:
(3.3)
Коэффициент готовности системы вычисляется по формуле:
S= MTTF / (MTTF+TR) (3.4)
Коэффициент надежности системы вычисляется как:
, (3.5)
где (3.6)
Стоимость разработки системы вычисляется как:
(3.7)
Данная модель может представлять только теоретический интерес, так, например, с точки зрения объектно-ориентированного подхода процесс - последовательная совокупность вызовов методов классов. Для такого варианта количество уровней архитектуры равно одному. Такие параметры, как времена доступа, анализа и восстановления, характерны для распределенной мультиверсионной архитектуры.
Для трансформации модели необходимо воспользоваться следующим алгоритмом:
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
Недостатки и преимущества моделей оценки надежности архитектуры ПО:
Основной недостаток модели - на фазе дизайна архитектуры не всегда известны некоторые параметры. Если надежность каждого компонента заранее не известна, то ее можно оценить только на стадии кодирования, а более точно только на стадии тестирования компонентов. Вероятность использования компонента и вероятность сбоя в компоненте можно получить только после завершения фазы тестирования системы. Для распределенных мультиверсионных архитектур ПО параметры времен доступа, анализа и восстановления компонент можно оценить также только после стадии тестирования системы.
Достоинство модели в том, что еще на концептуальной фазе мы имеем структуру архитектуры будущего ПО. Для объектно-ориентированного ПО можно построить дерево иерархии классов и методов классов. В общем случае на этой стадии мы задаем параметры, которые необходимо оценить на последующих фазах.
3.2 Анализ надежности программного обеспечения на фазе кодирования
Надежность напрямую зависит от количества ошибок в коде. Ошибки в коде в большой степени зависит от качества создания кода.
На стадии кодирования оценивается количество ошибок в коде.
Определим начальную плотность ошибок в коде
, (3.8)
где Fph - коэффициент фазы тестирования;
Fpr - коэффициент командного программирования;
Fm - коэффициент опытности и «зрелости» процесса разработки ПО;
Fs - коэффициент структурирования;
С - константа определяющая кол-во ошибок/KLOC.
Коэффициент фазы тестирования (Fph) может принимать следующие значения:
Тестирование модуля 4
Тестирование подсистемы 2.5
Тестирование системы 1 (по умолчанию)
Тестирование на приемлемость 0.35
Для коэффициента командного программирования (Fpr) плотность ошибок зависит от конкретных людей, их опыта написания программ и отладки.
Можно принять следующие значения параметра:
Высокий 0.4
Средний 1 (по умолчанию)
Низкий 2.5
Коэффициент опытности и «зрелости» процесса разработки ПО (Fm).
Можно принять следующие значения параметра:
уровень 1 1.5
уровень 2 1
уровень 3 0.4
уровень 4 0.1
уровень 5 0.05
Коэффициент структурирования (Fs): Этот параметр принимает во внимание зависимость плотности ошибок от языка программирования.
Fs=1, для объектно-ориентированного программирования.
Коэффициент С обычно лежит в диапазоне от 6 до 20 ошибок/KLOC. Можно брать как средние значения, так и MAX MIN значения для оценки диапазона плотности ошибок.
N(0)=DL, где L - количество тысяч строк исходного кода.
N(0) - начальное количество ошибок в исходном коде.
Данная модель используется для определения начального значения ошибок в коде.
3.3 Анализ надежности программного обеспечения на фазе тестирования системы
Доля достижения требуемого уровня надежности ПО может достигать 60% ресурсов проекта. Следовательно, тестирование должно быть тщательным образом спланировано для реализации проекта к заданной дате. Даже после длительного периода тестирования, дополнительное тестирование может выявить новые ошибки. ПО выходит из проекта с должным уровнем надежности, но все равно содержит ошибки. Для планирования и принятия решений используется SGRM - модель роста надежности ПО. SGRM предполагает, что надежность растет пропорционально времени тестирования, которое может быть измерено во времени использования процессора. Рост надежности определяют в терминах интенсивности сбоев л(t) или количества ожидаемых ошибок за время t м(t).
Известно, что интенсивность сбоев равна:
(3.9)
Пусть количество ошибок за время t - N(t). Предположим, что ошибки устраняются по мере обнаружения. За основу модели возьмем экспоненциальную модель. Она предполагает, что количество найденных и исправленных ошибок пропорционально количеству существующих ошибок.
Используя b1, как константу пропорциональности получаем:
(3.10)
b1 определяется как:
, (3.11)
где S - количество инструкций в коде, Q - количество объектных инструкций в каждой инструкции кода и r - уровень выполнения инструкции компьютером, k - называется коэффициентом подверженности ошибкам и меняется от 1x10-7 до 1x10-6, когда t измеряется в секундах выполнения процессорного времени.
(3.12)
Где N(0) начальное количество ошибок, тогда общее количество ожидаемых ошибок за время t:
(3.13)
в общем случае получаем:
, (3.14)
где bo, общее количество ошибок, которые могут быть обнаружены равно N(0). Это предполагает, что во время отладки не делаются новые ошибки.
Выражение для интенсивности сбоев:
(3.15)
Экспоненциальная модель легка для понимания и применения. Преимущество этой модели в том, что параметры b0 и b1 четко определены еще до начала тестирования.
Надежность компонента определяется как:
, (3.16)
где e - общее количество вызовов компонента за время t;
d - время выполнения компонента / общее время тестирования;
- интенсивность сбоя компонента.
Можно вычислить время Tf, необходимое для достижения желаемого уровня интенсивности сбоя
(3.17)
Или время Tr для достижения желаемого уровня надежности Rm:
(3.18)
Во многих случаях Tr и Tf используются в человеко-часах и должны быть умножены на соответствующий коэффициент - он определяется с использованием предыдущего опыта проектов.
3.4 Операционные профили тестирования компонент
В процессе тестирования каждого модуля составляется операционный профиль. В операционный профиль входит множество подобластей входных диапазонов параметров, с указанием надежности для каждого диапазона. Для каждого компонента обязательно составляется хотя бы один диапазон.
Выход компонента может являться входным профилем для другого компонента, таким образом, можно говорить о входных и выходных профилях. Для построения модели достаточно использовать только входные профили.
Тщательное тестирование позволяет получить более точные оценки надежности R каждого компонента.
, (3.19)
где Ns - количество сбоев в заданном диапазоне входных значений,
N - количество тестов в заданном диапазоне.
Таким образом, получаем операционный профиль в виде:
D1 R1
D2 R2
….
Dn Ri
Где Di - диапазон значений, i=1,…, n, а Ri - вероятность попадания в данный диапазон значений, i=1,…, n.
Для описания профиля используется плотность вероятности, где D дискретная область. На практике очень трудно достигнуть точных данных о профиле от пользователей ПО. Лучшее, что можно сделать, это описать его как гистограмму вероятностей над обширными классами входов.
Пусть у компонента C есть входная областьD, разделенная на n областей, не имеющих общих элементов,
Пусть каждая подобласть имеет свой профиль Рi, и свою вероятность сбоя :
(3.20)
где Df это подмножество D, на котором C сбоев, а Pi - профиль внутри подобласти Si. Полностью профиль P для компонента можно выразить, как нормализованный вектор вероятностей того, что каждая подобласть будет использована.
На практике профиль дословно определяется экспертом: человеком, который предполагает вероятность появления различных входных данных. Такой эксперт обычно испытывает затруднения уже в том, чтобы предположить веса hi, и обычно ничего не может сказать о распределениях Pi. Таким образом, внутри подобластей обычно берется равномерное распределение. Следовательно,
(3.21)
Благодаря этому профиль всегда будет нормализованным вектором весов, приложенным к множеству подобластей.
Оценивание вероятностей сбоя
На практике вероятность сбоя fi в подобласти Si может быть оценена путем случайного тестирования. Обычно сбоев не наблюдается, и это обеспечивает верхнюю границу fi. Если N тестов были проведены без ошибок, то есть твердая уверенность в том, что fi ниже 1/N. Таким образом, этот основной параметр может быть измерен разработчиком компонента.
Ведение таблиц параметров профилей
Два отображения таблиц компонента дают системному проектировщику возможность вычислить надежность компонента, где бы он не находился в системе, и вычислить путь, которым входной профиль переходит в выходной. Таким образом, эти схемы могут быть определены в терминах профиля: P=<h1, h2,…, hn>. Системный проектировщик использует их для того, чтобы передавать профили через структуры системы во время тестирования.
Ведение таблиц надежности
Надежность отображает вектор профилей с элементами, находящимися в диапазоне (вероятность того, что компонент не даст сбой согласно профилю). Для того чтобы занести это отображение в таблицу данных, разработчик компонента определяет вероятности сбоя fi внутри каждой подобласти, используя равномерное распределение.
Тогда
(3.22)
Пользуясь данной схемой (где fi была измерена разработчиком) и профилем (hi для проектируемой системы), системный проектировщик может вычислить R - надежность компонента при заданном профиле.
Ведение таблиц изменений профиля
Изменение профиля отображает изменение входного вектора профиля в выходной. За параметры берутся выходные подобласти. Отображение должно учитывать возможность произвольного набора выходных подобластей U1, U2., Um, несвязанных с подобластями в таблице компонента. Именно такой набор будет описывать некоторый следующий компонент в системном проекте. Пусть весами, вычисляемыми для выходного профиля, будут Q=<k1, k1., km> на подобластях Ui. Каждое kj это вес каждой входной подобласти,
Подобные документы
Программное обеспечение как продукт. Основные характеристик качества программного средства. Основные понятия и показатели надежности программных средств. Дестабилизирующие факторы и методы обеспечения надежности функционирования программных средств.
лекция [370,1 K], добавлен 22.03.2014Порядок и принципы документирования работ, выполняемых на этапе анализа и проектирования в жизненном цикле программных средств, нормативная основа. Описание пользовательского интерфейса прототипа разработанной информационной системы, его структура.
курсовая работа [472,9 K], добавлен 11.11.2014Анализ методологии и стандартизации оценки характеристик качества готовых программных средств: по функциональной пригодности, по корректности, по способности к взаимодействию, по защищенности. Процессы и продукты жизненного цикла программных средств.
контрольная работа [26,6 K], добавлен 23.01.2011Ошибки, которые воздействуют на программное обеспечение и методы прогнозирования программных отказов. Анализ моделей надежности программного обеспечения и методика оценки ее надежности. Экспоненциальное распределение. Методика оценки безотказности.
курсовая работа [71,5 K], добавлен 15.12.2013Особенности аналитической и эмпирической моделей надежности программных средств. Проектирование алгоритма тестирования и разработка программы для определения надежности ПО моделями Шумана, Миллса, Липова, с использованием языка C# и VisualStudio 2013.
курсовая работа [811,5 K], добавлен 29.06.2014Модель надежности программного средства как математическая модель для оценки зависимости надежности программного обеспечения от некоторых определенных параметров, анализ видов. Общая характеристика простой интуитивной модели, анализ сфер использования.
презентация [151,1 K], добавлен 22.03.2014Критерии оценки эффективности и качества создания программных средств. Роль трудоемкости и длительности создания программных средств в определении эффективности их создания. Требования к качеству, суммарные затраты на разработку программного средства.
реферат [26,7 K], добавлен 10.10.2014Этапы тестирования при испытаниях надежности программных средств. Комплексирование модулей и отладка автономных групп программ в статике без взаимодействия с другими компонентами. Испытания главного конструктора. Жизненный цикл программного средства.
презентация [339,6 K], добавлен 22.03.2014Сущность понятия "программное обеспечение". Типы прикладных программ. Современные системы программирования для персональных компьютеров. Уровни программного обеспечения: базовый, системный, служебный. Классификация служебных программных средств.
реферат [20,2 K], добавлен 01.04.2010Определение задач и классов программных средств для организации научных конференций. Особенности использования программных средств поддержки организации и проведения конференций. Сравнение программных средств для организации и проведения конференций.
реферат [1,8 M], добавлен 05.12.2017
