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

• Автор: Штенцель, Артем Владимирович
• Шифр специальности: 05.13.11
• Научная степень: Кандидатская
• Год защиты: 2008
• Место защиты: Красноярск
• Количество страниц: 183 с. : ил.

Введение.

1 Проектирование высоконадежных программных систем.

1.1 Проблемы проектирования высоконадежных программных систем

1.2 Методы обеспечения отказоустойчивости программного обеспечения

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

1.2.3 Обработка исключений.

1.2.4 Контрольные точки и рестарт

1.2.5 Парные процессы

1.2.6 Разнообразие данных

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

Выводы по разделу.

1.3 Применение методологии мультиверсий для обеспечения отказоустойчивости программных систем
1.3.2 Иверсионное программирование.
1.3.3 Иверсионное программирование с самоконтролем.
1.3.4 Блоки восстановления с согласованием
1.3.5 Проблемы мультиверсионного программного обеспечения.
1.3.5.1 Разработка мультиверсионного программного обеспечения
1.3.5.2 Алгоритмы выбора вывода
1.3.6 Отказоустойчивость в операционных системах
Выводы по разделу.
1.4 Оптимизация модульного ПО на этапе дизайна мультиверсионной ,
архитектуры.
1.4.1 Фазы разработки программного обеспечения
1.4.1.1. Фаза дизайна архитектуры программного обеспечения.
1.4.1.2 Компоненты архитектуры.
1.4.2 Надежность архитектуры программного обеспечения.
1.4.3 Оптимизационные модели формирования модульного ПО на этане
дизайна мультиверсионной архитектуры
Выводы по разделу.
2 Модели синтеза оптимальных модульных систем на основе мультиверсионной программной архитектуры.
2.1. Постановка задач синтеза.
2.2 Процедура решения задачи синтеза
2.3. Программная реализация системыформирования структур мультиверсионных программных систем.
2.3.1 Общие сведения
2.3.2 Описание системы формирования структур мультиверсионных программных систем.
2.3.3 Концептуальная архитектура системы формирования структур мультиверсионных программных систем
2.3.4 Описание работы с системой
2.3.5 Примеры решения задач и анализ результатов.
2.3.5.1 Исходные данные.
2.3.5.2 Результаты работы.
2.3.5.3 Полученная структурная схема программной системы
2.3.5.4 Соотношение расходов на разработку архитектуры системы с учетом сокращенного цикла проектирования
Выводы по разделу
3 Модульные принципы формирования архитектур программного обеспечения .
3.1 Требования, предъявляемые к модулям программного обеспечения
3.2 Объектноориентированные методы проектирования модулей программного обеспечения
3.3 Проблемы разработки модулей программного обеспечения с использованием объектноориентированных методов проектирования
3.3.1 Проблемы распространения программного обеспечения.
3.3.2 Проблемы стандартизации на двоичном уровне
3.3.3 Проблемы инкапсуляции.
3.4 Технологии компонентного проектирования
3.4.1 Компонентная объектная модель , .
3.4.2 Общая архитектура брокеров объектных запросов
i,
3.5 Выводы по разделу
4 Инструментальные средства построения мультиверсионного ПО с использованием технологии компонентного проектирования СОМ
4.1 Инструментальный V комплекс
4.1.1 Клиентский ЕХЕмодуль.
4.1.2 Компонент vv.
4.1.3 Компонент vI.
4.1.4 Компоненты v, 2, .,
4.1.5 Компонент vv.
4.1.6 Компонент v
4.2 Инструментальный V комплекс в работе.
4.3 Результаты тестирования V комплекса
4.4 Выводы
Заключение.
Список использованных источников


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