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

003063942

На правах рукописи

Чикизов Алексей Александрович

КОМПОНЕНТНАЯ РАСПРЕДЕЛЕННАЯ АРХИТЕКТУРА МУЛЬТИВЕРСИОННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ОТКАЗОУСТОЙЧИВЫХ СИСТЕМ УПРАВЛЕНИЯ

Специальность 05 13 01 — Системный анализ, управление и обработка

информации

Автореферат

диссертации на соискание ученой степени кандидата технических наук

Красноярск — 2007

1 4 ИЮН 2007

003063942

Работа выполнена в Сибирском государственном аэрокосмическом университете имени академика М Ф Решетнева

Научный руководитель

кандидат технических наук, доцент Царев Роман Юрьевич

Официальные оппоненты

доктор технических наук, профессор Петров Михаил Николаевич кандидат технических наук, доцент Зеленков Павел Викторович

Ведущая организация ГОУ ВПО «Томский государственный университет систем управления и радиоэлектроники»

Защита состоится 28 июня 2007 г в 14 00 на заседании диссертационного совета Д 212 249 02 при Сибирском государственном аэрокосмическом университете имени академика МФ Решетнева по адресу 660014, г Красноярск, пр им газ "Красноярский рабочий", 31

С диссертацией можно ознакомиться в библиотеке Сибирского государственного аэрокосмического университета имени академика М Ф Решетнева

Автореферат разослан "26" мая 2007 года

Ученый секретарь диссертационного совета

ИВ Ковалев

ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ

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

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

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

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

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

■ языки программирования модулей,

■ алгоритмы решения типовых задач,

■ средства программирования,

■ методы тестирования

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

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

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

Декомпозиция главной цели может выглядеть как набор подцелей

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

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

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

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

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

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

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

Научная новизна работы: 1 Методика формирования компонентного распределенного мультиверсионного программного обеспечения, позволяющая

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

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

3 Метод планирования транзакционного исполнения версий программных модулей систем управления, позволивший обосновать уровень избыточности программного обеспечения и повысить эффективность восстановления данных

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

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

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

На защиту выносятся:

1 Методика формирования компонентного распределенного мультиверсионного программного обеспечения

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

3 Метод планирования транзакционного исполнения версий компонентных программных модулей систем управления

Апробация работы Основные положения и результаты работы прошли апробацию на VIII Всероссийской научно-технической конференции (Улан-Удэ, 2007 г) Докладывались на научно-технических семинарах НИИ Систем управления, волновых процессов и технологий (2004-2006 гг) и Сибирского государственного аэрокосмического университета (2004-2007 гг )

Структура и объем работы. Диссертация состоит из введения, пяти глав, заключения и списка литературы

ОСНОВНОЕ СОДЕРЖАНИЕ РАБОТЫ Во введении дана общая характеристика проблемы, обоснована актуальность выбранной темы, определены цель и задачи исследования Сформулированы основные положения, выносимые на защиту, научная новизна и практическая значимость полученных результатов

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

Понятие программного компонента (software component) является одним из ключевых в современной инженерии программного обеспечения (ПО) Компоненты являются блоками, из которых строится компонентное программное обеспечение Эти же компоненты имеются в виду, когда говорят о компонентных технологиях, компонентной или компонентно-ориентированной (component based) разработке ПО, компонентах JavaBeans, EJB, CORBA, ActiveX, VBA, COM, DCOM, NET, Web-службы (web services), Такой компонент представляет собой структурную единицу программной системы, обладающую четко определенным интерфейсом, который полностью описывает ее зависимости от окружения Основное свойство такого компонента заключается в том, что он может быть независимо поставлен или не поставлен, добавлен в состав некоторой системы или удален из нее, в том числе, может включаться в состав систем других поставщиков

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

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

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

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

Компонент являться единицей развертывания, он может быть присоединен к остальной системе, когда она уже некоторое время работает, и должен после этого выполнять все свои функции, если в исходной системе уже были все компоненты, от которых он зависит Он может быть удален из нее Естественно, после этого могут перестать работать те компоненты, которые зависят от него

Создание компонентных распределенных систем высокого качества является одной из наиболее сложных задач по разработке ПО Технологии типа JavaBeans, CORBA, СОМ+ и NET создаются как раз для того, чтобы сделать разработку широко встречающихся видов распределенных систем — так называемых бизнес приложений, поддерживающих решение бизнес-задач некоторой организации, — достаточно простой и доступной практически любому программисту Основная задача, которую пытаются решить с помощью распределенных систем — обеспечение максимально простого доступа к большому количеству ресурсов, повышение надежности путем дублирования отдельных узлов системы Наиболее важными свойствами такой системы являются

• Прозрачность (transparency) Прозрачностью называется способность системы скрыть физическое распределение ресурсов, а также аспекты их перераспределения и перемещения между различными машинами в ходе работы, репликацию (те дублирование) ресурсов, трудности, возникающие при одновременной работе

• Открытость (openness) Открытость системы определяется как полнота и ясность описания интерфейсов работы с ней и служб, которые она предоставляет через эти интерфейсы Такое описание должно включать в себя все, что необходимо знать для того, чтобы пользоваться этими службами, независимо от реализации данной системы и платформы, на которой она развернута

• Масштабируемость (scalability) Масштабируемость системы — это зависимость изменения ее характеристик от числа ее пользователей, числа подключенных ресурсов, а также от степени географической распределенности системы В число значимых характеристик при этом попадают функциональность, производительность, стоимость, трудозатраты на разработку, на внесение изменений, на сопровождение, на администрирование, удобство работы с системой

• Безопасность (safety) Так как распределенные системы вовлекают в свою работу множество пользователей, машин и географически разделенных элементов, вопросы их безопасности получают гораздо большее значение, чем при работе обычных приложений, сосредоточенных на одной физической машине

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

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

Во втором разделе произведен анализ современных технологий программирования распределенных систем управления - СОМ+ и NET

С самого начала технология СОМ разрабатывалась с учетом обеспечения поддержки распределенных сред, т е способности клиента создавать объекты на других машинах и вызывать их методы по сети Эти планы стали реальностью после выпуска распределенной COM (Distributed СОМ — DCOM) DCOM позволяет клиенту создавать и использовать объекты, как на удаленных системах, так и на локальной Более того, клиент может даже не осознавать различия между этими двумя случаями Подобно тому, как клиенты СОМ имеют прозрачный доступ к объектам в динамических библиотеках и локальных процессах, DCOM обеспечивает прозрачный доступ к объектам в удаленных процессах Расширением СОМ-технологии является технология Microsoft Transaction Server (MTS) благодаря которой появилась возможность совместного использования СОМ-объектов многими клиентами, авторизованный доступ к этим объектам, а также при необходимости обработку транзакций этими объектами Расширенная таким образом технология СОМ получила название СОМ+ Новая версия СОМ - это совокупность программных средств, обеспечивающих разработку, распространение и функционирование распределенных приложений для сетей Интернет и интранег

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

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

До появления технологии NET программирование СОМ+ сервисов занимало много времени и требовало привлечения высококвалифицированных программистов Разработчик должен был сам реализовать все тонкости внутренней логики технологии, написать большой объем исходных кодов, следить за контролем версий и унификацией интрфейсов, все это приводило к большим затратам и могло вызвать нарушение в жизненном цикле программной системы

Технология NET представляет собой совершенно новый способ создания распределенных приложений, NET не имеет ничего общего с СОМ, кроме мощных средств интеграции двух платформ Для типов NET не нужны ни фабрики классов, ни поддержка уникальных интерфейсов Специально для новой платформы был разработан новый язык программирования С#, который содержит в себе все лучшее от существующих на сегодняшний день объектно-ориентированных языков программирования Очень важно отметить, что платформа NET является полностью не зависимой от используемых языков программирования

Основными возможностями технологии NET являются

• Полные возможности взаимодействия с существующим кодом

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

• Общая среда выполнения для любых приложений NET, вне зависимости от того, на каких языках они созданы Один из важных моментов при этом - то, что для всех языков используется один и тот же набор встроенных типов данных

• Библиотека базовых классов, которая обеспечивает сокрытие всех сложностей связанных с непосредственным использованием вызовов API, и предлагает целостную объектную модель для всех языков программирования, поддерживающих NET

• Действительное упрощение развертывания приложения В NET нет необходимости регистрировать двойные типы в системном реестре Боле того, NET позволяет разным версиям одно и того же модуля DLL мирно сосуществовать на одном компьютере

Во время анонса платформы NET на конференции 2000 Professional Developers Conference докладчики называли организации, работающие над созданием NET версий своих компиляторов, где были представлены более 30 различных языков Такое разнообразие вызвано применением в NET промежуточного платформенно-независимого язьпса MSIL (Microsoft

Intermediate Language) или просто IL Таким образом, любой язык программирования сначала компилируется в набор инструкции IL, и далее исполняется в среде выполнения NET

С# можно считать новым членом сообщества объектно-ориентированного языков программирования, к самым распространенным из которых относят Java, С++, Object Pascal и Visual Basic В любом объектно-ориентированном языке обязательно реализованы три важнейших принципа объектно-ориентированного программирования

• инкапсуляция - как объекты прячут свое внутренне устройство,

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

• полиморфизм - как в этом языке реализована поддержка выполнения нужного действия в зависимости от типа передаваемого объекта,

В течении множества лет обработка ошибок превращалась разработчиками в сложную смесь различных приемов, множество программистов реализовывало свою собственную логику обработки ошибок в рамках одного единственного приложения Очевидная проблема таких приемов обработки ошибок заключается в том, что все они - разные Каждый прием привязан к конкретной технологии, конкретному языку и проекту Чтобы унифицировать такие подходы NET предлагает единую технику обнаружения ошибок времени выполнения и передачи сообщений о них -структурированная обработка исключений (Structured Exception Handling, SEH)

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

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

В мире NET существует понятие рефлексия типов — процесс обнаружения типов во время работы программы Используя рефлексию, появляется возможность загружать информацию о модулях и сами модули прямо во время выполнения программы Рефлексия позволяет в процессе работы программы получить перечень всех интерфейсов, методов, полей и свойств событий и прочую информацию, важную для объектно-ориентированного программирования Ключевой особенностью рефлексии является динамическое выполнение кода, основной модуль может отправить на удаленную рабочую станцию произвольный код на выполнение, что позволяет мгновенно, без перекомпиляции исправлять ошибки в модулях

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

В терминах NET сериализация (serialization) - это термин описывающий процесс преобразования объекта в линейную последовательность байтов Обратный процесс, когда из потока байтов, содержащего всю необходимую информацию, объект восстанавливается в исходном виде, называют десериализацией (deserialization) Таким образом появляется возможность сохранить объект в произвольном состоянии и далее вернуть его в это состояние

Очень часто компоненты разработанные в NET должны успешно работать в мире сложных приложений, где значительную часть кода составляют классические СОМ+ сервисы Сложность возникает в том, что код модулей СОМ - двоичный, платформенно-зависимый, в отличии от полностью независимого кода NET - IL СОМ+ серверы работают с уникальными наборами типов данных, содержание которых в разных языках программирования сильно отличаются Помимо того что в каждом программном модуле СОМ должны быть реализованы достаточно сложные элементы(фабрики классов, код IDL, итд), следует учитывать, что в мире СОМ необходимо отслеживать каждую ссылку на объект и если не позаботиться о механизме контроля ссылок, произойдет утечка памяти

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

• Вызовы из типов NET напрямую к модулям DLL, созданным на С

• Вызовы из типов NET к службам СОМ+

• Вызовы из служб СОМ+ к типам NET

Используя любой язык программирования из NET можно создавать распределенные приложения с поддержкой всех возможностей СОМ+, при этом все сложности разработки интерфейсов и взаимодействия NET берет на себя

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

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

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

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

Предложены модели восстановления версий после сбоя, которые позволяет реализовать выбранные технологии объектно-ориентированного компонентного программирования

Предлагается использовать временные состояния версий компонент для восстановления сбойных версий в контрольных точках Данная схема изображена на рисунке 1, где СР! - это контрольные точки Благодаря такому подходу гибкость построения мультиверсионного ПО значительно увеличивается в отличие от классических методов

Сохранение вектора состояний на жесткий диск

Рис 1 Схема восстановления сбойного компонента из временного состояния другой версии компонента

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

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

Введение состояния версий может использоваться для различных целей, отличных от целей восстановления версий, например отладка версий, что особенно удобно при первом методе, т к появляется возможность работать с полной информацией об объекте, измерение производительности, откат действий(транзакций), сбор различной статистической информации о моделируемом или управляемом объекте или процессе и т п

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

- Превентивное тестирование» версий, которые в текущий момент не используются для сравнения их временных состояний

- Сохранять временные состояния версий в хранилище данных и использовать для восстановления сбойных версий

- Перезапустить все версии (может быть полезно, при аппаратных сбоях или при множественных программных сбоях)

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

В четвертом разделе обсуждаются проблемы одновременного доступа нескольких мультиверсий к базе данных Основная идея управления параллельными транзакциями на основе многоверсионности (multiversion concurrency control, MVCC) заключается в том, что в базе данных допускается существование нескольких версий одного и того же элемента данных, что позволяет улучшить ряд характеристик СУБД, наиболее важных для следующих категорий приложений

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

Многоверсионные алгоритмы позволяют избежать подобных проблем благодаря тому, что транзакция, вносящая изменения в базу данных, не конфликтует с транзакциями чтения Но в то же время многоверсионные алгоритмы обычно сложны в реализации и запросы к версионным СУБД вызывают заметные накладные расходы

Одним из наиболее эффективных методов повышения производительности доступа к базе данных является метод MVSG-планировщиков Этот класс многоверсионных алгоритмов планирования обобщает широко известную моноверсионную технику Serialization Graph Testing (SGT)

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

Таким образом, планирование конфликтующих операций накладывает ограничение на порядок сериализации транзакций Эти ограничения и выражает граф конфликтов Рассмотрим, как происходит планирование очередной операции pi(x) с помощью SGT-планировщика Если это первая операция транзакции ft, поступившая планировщику, то создается новый узел в графе сериализации

В граф добавляются дуги вида (tj, ti) для каждой запланированной ранее операции qj(x) (i _j), конфликтующей с pi(x) Возможны два варианта а) результирующий граф содержит циклы — транзакция ft откатывается, Ь) полученный граф ацикличен — действие добавляется к списку запланированных

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

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

Рассмотрим следующий пример

51 = м>1[х1]м>1[у1]г2[у1]гЗ[х1]м>2[г2]гЗ[г2]™2[х2]

Граф (рис 2), составленный по правилам алгоритма 8СТ, будет содержать дуги (И, И), (11, tЗ), (1:2, гЗ)

Этот граф ацикличен Однако для Я не существует эквивалентного моноверсионного последовательного расписания Действительно, поскольку [3 читает версию х, записанную (гЗ[х1]), то t2, которая тоже пишет элемент х (м>2[х2]), должна следовать в моноверсионном последовательном расписании либо после ¿3, либо перед 11 Но первый вариант невозможен из-за шага гЗ[г2'], а второй — из-за г2[у1 ]

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

Опишем общую схему работы предлагаемого МУЗО-планировщика Когда очередной шаг рф) поступает планировщику, он предпринимает следующие действия

Если это первое действие транзакции и, поступившее планировщику, то соответствующий узел добавляется к графу конфликтов Если это шаг п(х), то выбирается подходящая версия х/, и в граф добавляется дуга (у, П) (поскольку, согласно нашим обозначениям, версию х/ записала транзакция /¡г) Для всех других к, таких что мк(хк) является шагом Не, в граф добавляется либо дуга у), либо дуга (и, гк) В этом и состоит выбор «позиции записи»

Если это шаг ми(хг), то для каждой транзакции 1к, которая прочитала, скажем, версию уд, нужно добавить либо дугу (и, ф, либо дугу (¡к й) То есть и должна следовать либо до I), либо после tk в соответствующем последовательном расписании

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

Следует обратить внимание на выборе подходящей версии для чтения Версия х/ не является подходящей в двух случаях во-первых, если существует путь из й в // (// следует после и по порядку сериализации), во-вторых, если

Т1

тз

Рис 2 Пример графа сериализации

существует путь (//, ¡к, и), где гк пишет х — м>к(хк) В этих случаях отсутствует способ выбора места для м/к(хк) в эквивалентном моноверсионном последовательном расписании

Как уже отмечалось, выбор для добавления в граф дуга — «(й, либо ((к, й)у>, по сути, является выбором «позиции записи» Выбирается порядок следования других транзакций, которые пишут х В некоторых случаях будет иметься несколько альтернативных путей, а в некоторых уже существующие дуги не оставят возможности выбора

В рассмотренном примере в графе образуется цикл на последнем шаге — \v2fx2] Выполняя этот шаг, мы должны будем, согласно правилу Э алгоритма, добавить одну из дуг — (12, г1) или (¡3,12) Обе ведут к образованию цикла

Используя метод МУБО, появляется возможность одновременного доступа отдельных версий к СУБД, при этом существует возможность подсчитать уровень надежности транзакционного доступа к системе

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

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

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

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

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

Для вычисления общей транзакционной надежности Я,г необходимо составить полный перечень всех транзакций и вычислить надежность каждой транзакции с использованием операционных профилей Определим

т - общее количество классов, п - общее количество транзакций,

К, - класс, г= 1, ,т,

О, - операционный профиль (множество входных диапазонов) /-го класса, /=1, ,/и,

Р, - вектор, отображающий вероятности сбоя 1-го класса для каждого входного диапазона, /=1, ,т,

/,1 - /-ый элемент вектора Р,, 1— размерность вектора У7,, Т3 - транзакция,7=1, ,и,

В, - множество классов принадлежащиху-ой транзакции, /=1, ,п, Ну - вектор вероятностей использования диапазона значений /-ш класса ву-ой транзакции,

Ицк -к- й элемент вектора Ну

IVу - вес (надежность) /-го класса /-й транзакции,

Риз — вероятность использования /-Й транзакции,

Яв- надежностьтранзакции,

Я». - транзакционная надежность всей системы,

Вес (надежность) /-го классау-й транзакции определятся по формуле

к=1

Надежность транзакции можно вычислить как

¡■=1

После вычисления надежностей всех транзакций вычисляется общая транзакционная надежность системы т

I ри хЛ. гг у=1 7 «г

На основании выявленных операционных профилей классов, векторов вероятностей использования диапазонов и векторов весов произведен расчет итоговой транзакционной надежности 1^=0,999649

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

Это позволило уделить больше внимания тестированию и выявлению ошибок в коде и в «узких местах» тестируемой системы Уменьшив вероятность сбоя на входных диапазонах в этих классах в два раза, было получено новое значение транзакционной надежности 1^ = 0,999750

Затем был произведен расчет коэффициента готовности системы Б, информирующий

о том, когда отказавшая система будет восстановлена Для этого были получены значения ТП (среднее время простоя системы) и МТТР (среднее время появления сбоя) Время появления сбоя (МТТР) и среднее время простоя системы (Т11) характеризуют возможность архитектуры

программного обеспечения по обеспечению потенциальной производительности и для достижения этой производительности после отказа Определим

Р - общее число компонент(классов) в архитектуре ПО, Ри, - вероятность использования компонента 1,1=1, РР, - вероятность сбоя в компоненте г, /=1, ,Р,

РЬу - условная вероятность сбоя в компоненте г при сбое в компоненте у, 1=1, Д/=1, Л

ТА, - относительное время доступа к компоненту 1,1=1, .р, ТС, - относительное время анализа сбоя в компоненте /, г=1, ,Р, ТЕ, - относительное время устранения сбоя в компоненте 1,1= 1, р~, Ти, - относительное время использования компонента 1,1=1, р'

Среднее время простоя системы рассчитывается по формуле

Р Р

ТЯ= 2 [Ри хРРхЩ +ТС +ТЕ)+ £ [РЬ х[(Ц +ТС +ТЕ)]]]

Среднее время появления сбоя рассчитывается по формуле р р

МТТР= Е [РС/гх(1-Р^)х[Ш + 2 [{\-РЬ )хШ_ 111 '= 1 7=1,7*'

Коэффициент готовности системы рассчитывается по формуле

5= МГТР/(МТТР+ТЯ) Были получены следующие показатели Т11 = 0,000018 с, МТТЕ = 2045 с , 8= 0,999998

В результате уменьшения вероятности сбоя в соответствующих входных диапазонах удалось получить новые улучшенные показатели коэффициента готовности системы, среднего времени простоя системы и среднего времени появления сбоя ТЯ = 0,000015 с, МТТР= 2045,1 с, Б= 0,999999

В результате применения системы в реальном проекте удалось выявить «узкие места» в системе и повысить показатели надежности

Расчетные показатели, полученные с использованием разработанных моделей, отличались от реальных не более чем на 5%, что говорит о достаточной адекватности модели

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

ОСНОВНЫЕ РЕЗУЛЬТАТЫ И ВЫВОДЫ

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

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

• Исследованы современные объектно-ориентированные технологии проектирования программного обеспечения и выявление их основных преимуществ при создании мультиверсионных программного обеспечения,

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

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

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

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

Основные результаты диссертационной работы опубликованы в следующих работах

1 Чикизов, А А Компонентные технологии при разработке распределенного программного обеспечения / Чикизов А А Вестник НИИСУВПТ - Вып 9 - Красноярск НИИ СУВПТ, 2006 - С 60-64

2 Чикизов, А А Современные технологии программирования распределенных систем управления / Чикизов А А Вестник НИИ СУВПТ -Вып 9 -Красноярск НИИ СУВПТ, 2006 - С 71-73

Чикизов А А Повышение защищенности пользовательского рабочего места системы дистанционного банковского обслуживания / Чикизов А А Вестник НИИ СУВПТ - Вып 9 - Красноярск НИИ СУВПТ,

2006 - С 80-83

Чикизов, А А «Черные» методы оптимизации компонентов / Чикизов А А, Зиберт, А Ю, Вестник НИИ СУВПТ - Вып 6(20) -Красноярск НИИ СУВПТ, 2005 - С 51-55

Чикизов, А А Универсальная информационная система для отслеживания жизненного цикла программного обеспечения / Чикизов, А А НА Алексеев, Е С Гаврилов, Вестник университетского комплекса - Вып 6(20) - Красноярск НИИ СУВПТ, ВСФРГУИТП, 2005 - С 88-91

Чикизов, А А Модель нечеткой классификации объект в алгоритме фрактального сжатия изображений / А А Чикизов, Грудина Т Н, Вестник университетского комплекса - Вып 6(20) - Красноярск НИИ СУВПТ, ВСФРГУИТП, 2005 - С 162-165

Чикизов, А А Технология СОМ+ для реализации мультиверсионного программного обеспечения информационно управляющих систем / А А Чикизов, Ю Д Цветков, И А Капчинский // Вестник СибГАУ -2007,№1 -С 75-77

Чикизов, А А Оптимальное формирование модульного программного обеспечения информационно-управляющих систем / Р Ю Царев, В А Волков, А А Чикизов // Теоретические и прикладные вопросы современных информационных технологий Материалы VIII Всероссийской научно-технической конференции - Улан-Удэ Изд-во ВСГТУ, 2007 - С 383-385

Разработки, зарегистрированные в Отраслевом фонде алгоритмов и программ:

9 Волков В А, Чикизов А А, Ковалев И В , Царев Р Ю Компонентный мультиверсионный программный комплекс (Программная система «NVP Simulator ver 1 0») М ВНТИЦ, 2007 № 50200700702

10 А А Чикизов Программная система прогнозирования и восстановления неизвестных зависимостей при малом числе наблюдений «RegresIT 1 0» М ВНТИЦ, 2007 № 50200700723

11 А А Чикизов Тест структуры интеллекта AI Test 1 0 М ВНТИЦ,

2007 №50200700730

Подписано в печать_2007 г

Формат 60x84/24 Бумага писчая Уч изд л 1 Тираж 100 экз Заказ № Отпечатано в отделе множительной техники СибГАУ

4

5

6

7

8

Содержание.

Введение.

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 Технология программирования .NET.

2.2.1 Структура .NET Framework.

2.2.2 Библиотека базовых классов.

2.2.3 .NET и СОМ-объекты.

2.2.4 Среда исполнения .NET-программ.

3 Структуры мультиверсионных моделей.

3.1 Блоки восстановления.

3.2 N-версионное программирование.

3.3 N-версионное программирование с самоконтролем.

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 MVSG-планировщики.

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 Модель оценки транзакционной надежности объектно-ориентированного программного обеспечения.

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

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

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

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

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

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

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

ОСНОВНЫЕ РЕЗУЛЬТАТЫ И ВЫВОДЫ

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

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

• Исследованы современные объектно-ориентированные технологии проектирования программного обеспечения, выявлены их основные преимущества при создании мультиверсионного программного обеспечения; технологии СОМ+ и .NET включают в себя все требования мультиверсионных методов.

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

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

• Решена задача планирования транзакции при работе мультиверсий с СУБД, использование разработанного метода MVSG планировщика позволило сократить время доступа версий к базе данных.

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

Заключение

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

1. С. Szyperski. Component Software Beyond Object-Oriented Programming. Boston, MA: Addison-Wesley and ACM Press, 1998.

2. F. Bachmann, L. Bass, C. Buhman, S. Comella-Dorda, F. Long, J. Robert, R. Seacord, K. Wallnau. Volume II: Technical Concepts of Component-Based Software Engineering, 2nd Edition/ Technical Report CMU/SEI-2000-TR-008.

3. Э. Таненбаум, M. ван Стеен. Распределенные системы. Принципы и парадигмы. СПб.: Питер, 2003.

4. G. Alonso, F. Casati, Н. Kuno, V. Machiraju. Web Services. Concepts, Architectures and Applications. Springer-Verlag, 2004.

5. Michael R. Lyu, editor, Software Fault Tolerance, John Wiley & Sons, 1995.

6. Russell J. Abbott, Resourceful Systems for Fault Tolerance, Reliability, and Safety, ACM Computing Surveys, Vol. 22, No. I, March 1990, pp. 35 68.

7. Гантер, P. Методы управления проектированием программного обеспечения: Пер. с англ./ Р. Гантер, Е. К. Масловский. М.: Мир, 1981. -392 с.

8. Липаев, В. В. Качество программного обеспечения. / В. В. Липаев. М.: Финансы и статистика, 1983. - 263 с.

9. Мамиконов, А. Г. Проектирование АСУ. / А. Г. Мамиконов. М.: Высшая школа, 1987. - 304 с.

10. Липаев, В. В. Проектирование программных средств: Учеб. пособие для вузов по спец. "Автом. сист. обр. информ. и упр.". / В. В. Липаев. М.: Высшая школа, 1990. - 303 с.

11. П.Соммервилл И. Инженерия программного обеспечения / И. Соммервилл. Вильяме, 2002. 624 с.

12. Software Considerations in Airborne Systems and Equipment Certification, RTCA/DO-178B, RTCA, Inc, 1992.

13. Roger S. Pressman, Software Engineering: A Practitioner's Approach, The McGraw-Hill Companies, Inc., 1997.

14. Peter J. Denning, Fault Tolerant Operating Systems, ACM Computing Surveys, Vol. 8, No. 4, December 1976, pp. 359 389.

15. T. Anderson and P.A. Lee, Fault Tolerance: Principles and Practice, Prentice/Hall, 1981.

16. DavidJ. Taylor, Redundancy in Data Structures: Improving Software Fault Tolerance, IEEE Transactions on Software Engineering, Vol. SE-6, No. 6, November 1980, pp. 585 594.

17. David J. Taylor, Redundancy in Data Structures: Some Theoretical Results, IEEE Transactions on Software Engineering, Vol. SE-6, No. 6, November 1980, pp. 595-602.

18. J. P. Black, Introduction to Robust Data Structures, Digest of Papers FTCS-10: The Eleventh Annual International Symposium on Fault-Tolerant Computing, October 1 3,1980, pp. 110 -112.

19. J. P. Black, A Compendium of Robust Data Structures, Digest of Papers FTCS-11: The Eleventh Annual International Symposium on Fault-Tolerant Computing, June 24 26,1981, pp. 129 -131.

20. Dhiraj K. Pradhan, Fault-Tolerant Computer System Design, Prentice-Hall, Inc., 1996.

21. Herbert Hecht and Myron Hecht, Fault-Tolerance in Software, in Fault-Tolerant Computer System Design, Dhiraj K. Pradhan, Prentice Hall, 1996.

22. Brian Randell and Jie Xu, The Evolution of the Recovery Block Concept, in Software Fault Tolerance, Michael R. Lyu, editor, Wiley, 1995, pp. 1-21.

23. Brian Randell, Predictably Dependable Computing Systems, Springer, 1995.24Jim Gray, Why Do Computers Stop and What Can Be Done About It?,

24. Proceedings of the Fifth Symposium On Reliability in Distributed Software and Database Systems, January 13-15,1986, pp. 3-12.

25. Paul E. Ammann and John C. Knight, Data Diversity: An Approach to Software Fault Toleran ce, IEEE Transactions on Computers, Vol. 37, No. 4, April 1988, pp. 418-425.

26. Algirdas Avizienis, The Methodology of N-Version Programming, in R. Lyu, ed itor, Software Fault Tolerance, John Wiley & Sons, 1995.

27. R. Keith Scott, James W. Gau It, and David F. McAllister, Fault-Tolerant Software Reliability Modeling, IEEE Transactions on Software Engineering, Vol. SE-13, No. 5, May 1987, pp. 582 592.

28. Peter Bishop, Software Fault Tolerance by Design Diversity, in R. Lyu, editor, Software Fault Tolerance, John Wiley & Sons, 1995.

29. A. Avizienis, The UCLA DEDIX System: A Distributed Testbed for Multiple-Version Software, Digest of Papers: The Fifteenth Annual International Symposium on Fault-Tolerant Computing (FTCS 15), Ann Arbor, Michigan, June 19-21,1985, pp. 126 134.

30. A. Avizienis, The N-Version Approach to Fault-Tolerant Software, IEEE Transactions on Software Engineering, Vol. SE-11, No. 12, December 1985, pp. 290 300.

31. A. Avizienis and Jean-Claude Laprie, Dependable Computing: From Concepts to Design Diversity, Proceedings of the IEEE, Vol. 74, No. 5, May 1986, pp. 629-638.

32. A. Avizienis, In Search of Effective Diversity: A Six-Language Study of Fault-Tolerant Flight Control Software, Digest of Papers FTCS-18: The Eighteenth International Symposium on Fault-Tolerant Computing, June 27 -30,1988, pp. 15-22.

33. A. Avizienis, Software Fault Tolerance, Information Processing 89, Proceedings of the IFIP lit h World Computer Congress, 1989, pp. 491 -498.

34. А. Avizienis, Dependable Computing Depends on Structured Fault Tolerance, Proceedings of the 1995 6t h International Symposium on Software Reliability Engineering, Toulouse, France, 1995, pp. 158-168.

35. A. Avizienis, Toward Systematic Design of Fault-Tolerant Systems, Computer, April 1997, pp. 51 58.

36. Thomas C. Bressoud, TFT: A Software System for Application-Transparent Fault Tolerance, Digest of Papers: Twenty-Eight Annual International Symposium on Fault-Tolerant Computing, Munich, Germany, June 23 25, 1998, pp. 128-137.

37. F. Saglietti, Strategies for the Achievement and Assessment of Software Fault-Tolerance, IF AC 1990 World Congress, Automatic Control. Vol. IV, IF AC Symposia Series, Number 4,1991, pp. 303 308.

38. J. C. Knight, et al, A Large Scale Experiment in N- Version Programming, Digest of Papers FTCS-15: The 15th Annual International Conference on Fault Tolerant Computing, June 1985, pp. 135 139.

39. J. C. Knight and Nancy G. Leveson, An Experimental Evaluation of the Assumption of Independence in Multiversion Programming, IEEE Transactions on Software Engineering, Vol. SE-12, No. 1, January 1986, pp. 96 109.

40. Dave E. Eckhardt, An Experimental Evaluation of Software Redundancy as a Strategy for Imp roving Reliability, IEEE Transactions on Software Engineering, Vol. 17, No. 7, July 1991, pp. 692 702.

41. Tom Anderson, A Structured Mechanism for Diverse Software, Proceedings of the Fifth Symposium on Reliability in Distributed Software and Database Systems, January 1986, pp. 125 129.

42. Paul R. Lorczack, A Theoretical Investigation of Generalized Voters for Redundant Systems, Digest of Papers FTCS-19: The Nineteenth International Symposium on Fault-Tolerant Computing, 1989, pp. 444 451.

43. R. В. Broen, New Voters for Redundant Systems, Transactions of the ASME, Journal of Dynamic Systems, Measurement, and Control, March 1975, pp. 41-45.

44. Judith Gersting, A Comparison of Voting Algorithms for N-Version Programming, Proceedings of the 24t h Annual Hawaii International Conference on System Sciences, Volume II, January 1991, pp. 253 262.

45. P. R. Croll, Dependable, Intelligent Voting for Real-Time Control Software, Engineering Applications of Artificial Intelligence, vol. 8, no. 6, December 1995, pp. 615-623.

46. J. M. Bass, Voting in Real-Time Distributed Computer Control Systems, PhD Thesis, University of Sheffield, October 1995.

47. John P. J. Kelly, Multi-Version Software Development, Proceeding of the Fifth IFAC Workshop, Safety of Computer Control Systems, October 1986, pp. 43 49.

48. Kam Sing Tso and Algirdas Avizienis, Community Error Recovery in Inversion Software: A Design Study with Experimentation, Digest of Papers FTCS-17: The Seven teenth International Symposium on Fault-Tolerant Computing, July 6-8,1987, pp. 127- 133.

49. Frederic Salles, MetaKernels and Fault Containment Wrappers, Digest of Papers: Twenty-Ninth Annual International Symposium on Fault-Tolerant Computing, Madison, Wisconsin, June 15-18,1999, pp. 22 29.

50. Philip Koopman, Comparing Operating Systems Using Robustness Benchmarks, Proceedings of the 1997 16th IEEE Symposium on Reliable Distributed Systems, October 1997, pp. 72 79.

51. Mark Russinovich, Application Transparent Fault Management in Fault Tolerant Mach, Digest of Papers: The Twenty-Third International Symposium on Fault-Tolerant Computing (FTCS-23), Toulouse, France, June 22 24,1993, pp. 10-19.

52. Mark Russinovich, Application Transparent Fault Managemet in Fault Tolerant Mach, in Foundations of Dependable Computing System Implementation, Gary M. Koob and Clifford G. Lau, editors, Kluwer Academic Publishers, 1994, pp. 215 -241.

53. Mark Russinovich and Zaiy Segall, Fault-Tolerance for Off-The-Shelf Applications and Hardware, Digest of Papers: The Twenty-Fifth International Symposium on Fault-Tolerant Computing, Pasadena, CA, June 27 30, 1995, pp. 67-71.58.

54. Буч Г. Объектно-ориентированный анализ и проектирование с примерами на С++. / Г. Буч. М.: БИНОМ, 1998. - 560 с.60.

55. Бокс Д. Сущность технологии СОМ. Библиотека программиста. / Д. Бокс. СПб.: Питер, 2001. - 400 с.

56. Роджерсон Д. Основы СОМ. / Д. Роджерсон Русская Редакция, 2000 г. -400 с.

57. Гамма Э. Приемы объектно-ориентированного проектирования. Паттерны проектирования. / Э. Гамма, Р. Хелм, Р. Джонсон СПб.: Питер, 2001 -368 с.

58. Коберниченко A. Visual Studio 6. Искусство программирования / А. Коберниченко М.:Нолидж, 1999 - 255 с.

59. Рихтер Дж. Windows для профессионалов: создание эффективных Win32 приложений с учетом специфики 64-разрядной версии Windows / Дж. Рихтер. М.: Издательско-торговый дом "Русская Редакция", 2001. -752 с.

60. Bogomolov, S. Fault Tolerance Software Libraiy Support of Real-Time Embedded Systems / S. Bogomolov, A. Bondarenko, A. Fyodarov; Third European Dependable Computing Conference,EDCC-3, Prague, Czech Republic, September 15-17,1999

61. Cherif, A. Improving the Efficiency of Replication for Highly Reliable Systems/ A. Cherif, M. Toyoshima, T. Katayama; FastAbstract ISSRE Copyright 1999

62. Choi, J.G. Reliability Estimation of nuclear digital I&C systems using Software Functional Block Diagram and control flow / J.G. Choi, H.G.Kang; FastAbstract ISSRE Copyright 2000

63. Clasen, U. Eine Moeglichkeit der numerischen Behandlung von zeitlich-stochastischen Netzplaenen / In: "Operations Research Proceedings", Springer Verlag Berlin-Heidelberg, 1994. P. 46-51

64. Costa, D. On the Extention of Exception to Support Software Faults Models / D. Costa, T. Mendez; FastAbstract ISSRE Copyright 2000

65. David, Ph. Development of a fault tolerant computer system for the Hermes Space Shuttle / Ph. David, C. Guidal. IEEE Trans., 1993. - P. 641-648

66. Dunham, J.R. Eds. Production of reliable flight crucial software: Validation method research for fault-tolerant avionics and control systems sub-working-group meeting / J.R. Dunham, C.J. Knight.- NASA Conf. Pub. 2222, NASA, 1985

67. Grams T. The Poverty of Reliabiliy Growth Models/ FastAbstract ISSRE Copyright 1999

68. Goseva-Popova К. How Different Architecture Based Software Reliability Models are Reealated / K. Goseva-Popova, K.S. Trivedi, A.P.Mathur; FastAbstract ISSRE Copyright 2000

69. Hamlet, D. Foundational Theory of Software Component Reliability / D. Hamlet, D. Mason, D. Wiot; FastAbstract ISSRE Copyright 2000

70. Hecht, H. Fault tolerant software / IEEE Trans. Reliability, Vol. R-28, 1979. -P. 227-232

71. Hui-Qun, Z. A New Method for Estimating the Reliability of Software System Based on Components / Z. Hui-Qun, S. Jing, G. Yuan; FastAbstract ISSRE and Chillarege Corp. Copyright 2001

72. Hudak, J. Evaluation & comparition of fault-tolerant software techniques / J. Hudak, B.-H. Suh, D. Sieweorek, Z. Segall

73. Karunanithi, N. Prediction of Software Reliability Using Connectionist / N. Karunanithi, D.Whitley, Y.K.Malaiya; IEEE transactions on reliability. Models July 1992, Vol. 18, No. 7

74. Kaszycki,. G. Using Process Metrics to Enhance Software Fault Prediction Models/ FastAbstract ISSRE Copyright 1999

75. Keene, S. Progressive Software Reliability Modeling/ FastAbstract ISSRE Copyright 1999

76. Knight, C.J. An experimental evaluation of the assumption of independence in Multiversion programming / C.J. Knight, N.G. Levenson. IEEE Trans. Software Engineering, Vol. SE-12,1986. - P. 96-109

77. Kovalev, I.V. An Approach for the Reliability Optimization of N-Version Software under Resource and Cost/Timing Constraints /16th International Computer Measurement Group Conference, Nashville, TN, USA, December 9-13,1991

78. Kovalev, I. Computer-Aided Modelling of Production Cycles Optimal Sequence in: Letunovsky V.V.(Editor-in-chief): Problems of products qualityassurance in machine-building: Proceedings of Int. Conf. KSTU / Krasnoyarsk, 1994. P. 43-48

79. Kovalev, I. Optimization Reliability Model for Telecommunications Software Systems /1. Kovalev , A. Privalov, Ju. Shipovalov. In: Modelling, Measurement and Control. - AMSE Periodicals, Vol.4-5, 2000. - P. 47-52

80. Kovalev, I. Software engineering of spacecraft control technological cycles / In: "Modelling, Measurement and Control, B". Vol.56, №3. -AMSE PRESS, 1994.-P. 45-49

81. Kovalev, I.V. Fault-tolerant software architecture creation model based on reliability evaluation / I.V. Kovalev, R.V.Younoussov; Advanced in Modeling & Analysis, vol. 48, № 3-4. Journal of AMSE Periodicals,2002, P.31-43

82. Levendel, Y. Reliability analysis of large software systems: Defect data modeling / IEEE Trans. Software Engineering, 1990. Vol. 16. - P. 141-152

83. Liestman, A. Fault-Tolerant Scheduling Problem / A. Liestman, R.-H. Campbell. IEEE Trans, on Software Engineering, 1986. - Vol. SE-12. - P. 1089-1095

84. Lyu, M.R. Handbook of Software Reliability Engineering / Edited by Michael R. Lyu Published by IEEE Computer Society Press and McGraw-Hill Book Company, 1996,819 p

85. Lyu, M.R. Software Fault Tolerance / Edited by Michael R. Lyu Published by John Wiley & Sons Ltd, 1996

86. McFarlan, F.W. Portfolio approach to information systems / Harvard Business Rev. 59. P. 142-150

87. Microsoft Business Solution Axapta. Axapta developers best practice handbook/Microsoft Business Solution, 2003. http://www.msbs.ru

88. Microsoft Business Solution Axapta. Axapta developers guide /Microsoft Business Solution, 2003. http://www.msbs.ru

89. Microsoft Business Solution Axapta. MorphX Integration master /Microsoft Business Solution, 2003. http://www.msbs.ru

90. Microsoft Business Solution Axapta. X++ Advanced master/Microsoft Business Solution, 2003. http://www.msbs.ru

91. Microsoft Business Solution Axapta. Administration users guide /Microsoft Business Solution, 2003. http://www.msbs.ru

92. Muralidhar, K. Using the analytic hierarchy process for information system project selection / K. Muralidhar, R. Santhanam, R. Wilson. -Information Mgmt 18,1990. P. 87-95

93. Oracle Education. Introduction to Oracle: SQL & PL/SQL , Volume 1: Students Guide, Production 1.1.2000

94. Oracle Education. Introduction to Oracle: SQL & PL/SQL , Volume 2: Students Guide, Production 1.1. 2000

95. Oracle University. Enterprize DBA Part 1: Perfomance and tunning . Volume 1: Students Guide, Production 1.0. 2000

96. Oracle University. Enterprize DBA Part 2: Perfomance and tunning . Volume 2: Students Guide, Production 1.0. 2000

97. Pai, G.J. Enhancing Software Reliability Estimation Using Bayaesan Network and Fault Trees / G.J. Pai, J.B. Dugan; FastAbstract ISSRE and Chillarege Corp. Copyright 2001

98. Rosenberg, L. Software Metrics and Reliability / L. Rosenberg, T. Hammer, J. Shaw; Software reliability engineering was presented at the 9-th International Symposium, "Best Paper" Award, November, 1998

99. Shooman, M.L. Software Reliability for Use During Proposal and Early Design Stages / FastAbstract ISSRE Copyright 1999

100. Silayeva, Т. K.-E. An Innovative Method for Program Reliability Evaluation / T. Silayeva, K.-E. Grosspietsch. Euromicro '95. Como (Italy), September 1995

101. Tai, A. Performability Enhancement of Fault-Tolerant Software / A. Tai, J. Meyer, A. Avizienis. IEEE Trans, on Reliability, 1993. - Vol. 42, No. 2 . - P. 227-237

102. Wattanapongsakorn, N. Reliability Optimization for Software Systems with Multiple Applications./ FastAbstract ISSRE and Chillarege Corp. Copyright 2001

103. Whitehouse, G. E. Applied operations research: a survey, Wiley, Inc. / G. E. Whitehouse, B. L. Wechsler. New York, 1976. - 424 p

104. Xie, M. Regression Goodness-Of-fit Test for Software Reliability Model Validation / M. Xie, B.Yang; FastAbstract ISSRE Copyright 2000