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

• Автор: Чикизов, Алексей Александрович
• Шифр специальности: 05.13.01
• Научная степень: Кандидатская
• Год защиты: 2007
• Место защиты: Красноярск
• Количество страниц: 138 с. : ил.

Содержание
Содержание
Введение.,

1 Проблемы проектирования компонентных распределенных систем управления

1.1 Основные понятия компонентных технологий

1.2 Общие принципы построения распределенных систем

1.3 Синхронное и асинхронное взаимодействие

1.4 Транзакции.

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

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

2.1 Технология программирования СОМ.

2.1.1 Не жестко связанные события.
2.1.2 Компоненты с поддержкой очередей
2.1.3 СОМ безопасность.
2.2 Технология программирования ..
2.2.1 Структура .
2.2.2 Библиотека базовых классов
2.2.3 . и СОМобъекты
2.2.4 Среда исполнения .программ
3 Структуры мультиверсионных моделей.
3.1 Блоки восстановления.
3.2 версионное программирование.
3.3 версионное программирование с самоконтролем.
3.4 Блоки восстановления с согласованием
3.5 Проблемы мультиверсионного программного обеспечения.
3.5.1 Разработка мультиверсионного программного обеспечения
3.5.2 Алгоритмы выбора вывода.
3.6 Отказоустойчивость в операционных системах
3.7 Выводы
4 Многоверсионность данных и управление параллельными транзакциями
4.1 Транзакции и параллелизм
4.2 Временные метки.
4.3 Многоверсионный вариант двухфазного протокола синхронизации
4.4 Многоверсионный протокол для транзакций, не изменяющих данные
4.5 Vпланировщики.
4.6 Проблемы реализации версионных алгоритмов
4.7 Выводы.
5 Модели и алгоритмы анализа надежности программных средств
5.1 Модель анализа на этапе дизайна архитектуры ПО.
5.2 Анализ надежности программного обеспечения на фазе кодирования
5.3 Анализ надежности программного обеспечения на фазе тестирования системы
5.4 Операционные профили тестирования компонент
5.4.1 Оценивание вероятностей сбоя
5.4.2 Ведение таблиц параметров профилей
5.4.2 Пример применения операционных профилей.
5.5 Модели надежности объектноориентированного программного обеспечения
5.5.1 Фаза построения архитектуры объектноориентированного программного обеспечения
5.5.2 Фаза кодирования
5.5.3 Фаза тестирования.
5.5.4 Оценка параметров надежности
5.5.6 Модель оценки транзакционной надежности объектноориентированного программного обеспечения.
Заключение.
Список использованных источников


Он может быть встроен в программные продукты третьих партий и распространяться вместе с ними. В то же время никакая его часть не обладает этими свойствами. В идеале такой компонент может быть добавлен или полностью замещен другой реализацией тех же интерфейсов прямо в ходе работы системы, без ее остановки. Хотя и не все разновидности компонентов обладают этим свойством, его наличие признается крайне желательным. Это требует наличия определенной инфраструктуры, которая позволяет компонентам находить друг друга и взаимодействовать по определенным правилам. Набор правил определения интерфейсов компонентов и их реализаций, а также правил, по которым компоненты работают в системе и взаимодействуют друг с другом, принято объединять под именем компонентной модели (component model) [2]. В компонентную модель входят правила, регламентирующие жизненный цикл компонента, т. Существуют несколько компонентных моделей. Правильно взаимодействовать друг с другом могут только компоненты, построенные в рамках одной модели, поскольку компонентная модель определяет «язык», на котором компоненты могут общаться друг с другом. Помимо компонентной модели для работы компонентов необходим некоторый набор базовых служб (basic services). Например, компоненты должны уметь находить друг друга в среде, которая, возможно, распределена на несколько машин. Компоненты должны уметь передавать друг другу данные, опять же, может быть при помощи сетевых взаимодействий, но реализации отдельных компонентов сами по себе не должны зависеть от вида используемой связи и от расположения их партнеров по взаимодействию. Набор таких базовых, необходимых для функционирования большинства компонентов сервисов, вместе с поддерживаемой с их помощью компонентной моделью называется компонентной средой (или компонентным каркасом, component framework). Примеры известных компонентных сред — различные реализации J2EE, . NET, CORBA. Сами по себе J2EE, . NET и CORBA являются спецификациями компонентных моделей и набора базовых служб, которые должны поддерживаться их реализациями. На практике этого, к сожалению, не всегда удается достичь, но всякое препятствие к такому взаимодействию рассматривается как серьезная, подлежащая скорейшему разрешению проблема. Соотношение между компонентами, их интерфейсами, компонентной моделью и компонентной средой можно изобразить в виде блоков на Рис. Компоненты Предоставляю: ятг треб’. Компонентная модель Определяет требования *. Рисунок 1. Основные элементы компонентного программного обеспечения. Компоненты отличаются от классов объектно-ориентированных языков. Класс определяет не только набор реализуемых интерфейсов, но и саму их реализацию — он содержит код определяемых операций. Контракт компонента, чаще всего, не фиксирует реализацию его интерфейсов. Класс написан на определенном языке программирования. Компонент же не привязан к определенному языку, если, конечно, его компонентная модель этого не требует - компонентная модель является для компонентов тем же, чем для классов является язык программирования. Обычно компонент является более крупной структурной единицей, чем класс. Реализация компонента часто состоит из нескольких тесно связанных друг с другом классов. Понятие компонента является более узким, чем понятие программного модуля. Основное содержание понятия модуля — наличие четко описанного интерфейса между ним и окружением. Понятие компонента добавляет атомарность развертывания, а также возможность поставки или удаления компонента отдельно от всей остальной системы. Возможность включения и исключения компонента из системы делает его отдельным элементом продаваемого ПО. Компоненты, хотя и не являются законченными продуктами, могут разрабатываться и продаваться отдельно, если они следуют правилам определенной компонентной модели и реализуют достаточно важные для покупателей функции, которые те хотели бы иметь в рамках своей программной системы. В дальнейшем мы будем рассматривать компонентные технологии в связи с разработкой распределенных программных систем.