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

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

Поздняков Дмитрий Александрович

КОМПОНЕНТНАЯ ПРОГРАММНАЯ АРХИТЕКТУРА МУЛЬТИВЕРСИОННЫХ СИСТЕМ ОБРАБОТКИ ИНФОРМАЦИИ И УПРАВЛЕНИЯ

Специальность 05.13.01 - Системный анализ, управление и обработка

информации

Автореферат

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

Красноярск 2006

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

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

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

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

доктор технических наук, профессор Петров Михаил Николаевич кандидат технических наук, доцент Тынченко Сергей Васильевич

Ведущая организация: Федеральное государственное учреждение "Государственный научно-исследовательский институт информационных технологий и телекоммуникаций" (г. Москва)

Защита состоится "12" мая 2006 года в 14 часов на заседании диссертационного Совета Д212.046.01 в ГНУ Научно-исследовательский институт систем управления, волновых процессов и технологий по адресу: 660028, г. Красноярск, ул. Баумана, 20в.

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

Автореферат разослан "11" апреля 2006 года.

Ученый секретарь

диссертационного совета

Смирнов

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

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

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

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

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

• образование, опыт и местоположение разработчиков;

• алгоритмы и структуры данных;

• языки программирования;

• методы разработки программного обеспечения;

• инструментальные средства программирования и среды (включая компиляторы);

• методы тестирования и инструментальные средства.

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

РОС. НАЦИОНАЛЬН БИБЛИОТЕКА 1

С.-Петербург

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

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

Поставленная цель достигается путем решения следующих задач:

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

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

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

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

Методы исследования: Методы прикладного системного анализа; объектно-ориентированного программирования; компонентного

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

Научная новизна работы:

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

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

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

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

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

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

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

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

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

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

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

Апробация работы. Основные положения и результаты работы прошли апробацию на 46 и 48-й научно-технических конференциях преподавателей, аспирантов и студентов Красноярского государственного технического университета (2003, 2006), на Пленарном заседании Второй Всероссийской конференции «Молодежь и наука: начало 21-го века», посвященной 50-летию КГТУ (2006), на международной AMSE-конференции «Modeling and Simulation - MS'05» (Rouen, Франция, 2005), на ежегодной заочной конференции РАЕН «Современные телекоммуникационные и информационные технологии» (2006). Докладывались на научно-технических

семинарах НИИ Систем управления, волновых процессов и технологий (20032006 гг.).

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

ОСНОВНОЕ СОДЕРЖАНИЕ РАБОТЫ

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

В первом разделе рассмотрены основные проблемы проектирования высоконадежных программно-информационных систем. Сформулированы основные понятия, применяемые в работе, такие как "программное средство", "комплекс программ" и "программа для ЭВМ". Описаны основные черты и особенности сложных программных средств, используемых в составе современных систем обработки информации и управления:

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

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

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

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

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

2. Открытость. Это возможность расширять систему путем добавления новых ресурсов.

3. Параллечьность В распределенных системах несколько процессов могут одновременно выполняться на разных компьютерах в сети. Эти процессы могут (но не обязательно) взаимодействовать друг с другом во время их выполнения.

4. Масштабируемость. В принципе все распределенные системы являются масштабируемыми: чтобы система соответствовала новым

требованиям, ее можно наращивать посредством добавления новых вычислительных ресурсов.

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

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

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

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

включают дублирование, временные проверки, реверсирование, кодирование, достоверность, и структурные проверки.

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

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

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

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

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

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

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

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

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

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

Память Контрольной

Точки

---

Контрольная Точка ▼

Ввод ■

Переключатель Выбора

I I 1 '-►

Приемочный тест

► Вывод

2.

Рисунок 1. Модель блока восстановления

М-версионное программирование - это мультиверсионная методика, в которой все версии разработаны в соответствии с идентичными основными требованиями, и решение о правильности вывода основано на сравнении всех выводов. Использование универсального алгоритма выбора решения (обычно, голосование) для выбора правильного вывода - фундаментальное различие этого подхода от подхода с блоком восстановления, который требует зависимого от приложения приемочного теста.

Версия 1

Ввод

Версия 2

Алгоритм Выбора

Версия N

Вывод

Рисунок 2. Модель Ы-версионного программирования

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

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

При реализации мультиверсионного голосования о правильности того или иного результата можно судить по количеству программных модулей, которые выдали подобный результат. Но возможен случай, когда трудно принять решение из-за неопределенности (два программных модуля вернули одни результат, два — другой). К тому же подобный способ реализации решающего алгоритма не учитывает предыдущий опыт отказов программных модулей. Различные программные модули могут иметь различную вероятность сбоев. Этот параметр нельзя выпускать из виду. Для решения задачи пересчета весовых коэффициентов использовался метод изменяющихся вероятностей (МИВЕР). Схема этого метода выглядит следующим образом:

1. Задаются начальные значения компонент вектора вероятностей Р°={р,0, ..., рп0}, где р,=Р{х^=1} - вероятность присвоения единичного значения ^й (]=1 ,п) компоненте вектора ХеО. При отсутствии априорных сведений о задаче вектор вероятностей задается в виде Р°={1/п,..., 1/п}.

2. Случайным образом (в соответствии с распределением вероятностей Рк, к=1Д-1), независимо выбираются г векторов Х'еБ, ¡=1,г.

3. Вычисляются соответствующие значения функционала ф (X1), ¡=1 ,г

4. Выбираются требуемые значения функционала из совокупности <р

5. По результатам п. 4 изменяются компоненты вектора вероятностей Рк по правилу:

где А+ = (л - т)1(птН ), й~ = 1/(Дп). 6. Пункты 2-5 повторяются Я раз.

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

(X1), ¡=1,т.

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

В четвертом разделе сформулированы и обоснованы требования, которым должны соответствовать разрабатываемые мультиверсионные модули.

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

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

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

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

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

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

1. Проблема распространения программного обеспечения.

2. Проблема стандартизации на двоичном уровне. Причина этой t проблемы кроется в отсутствии стандартизация на двоичном уровне.

3. Проблемы инкапсуляции. Хотя С++ и поддерживает синтаксическую инкапсуляцию через свои закрытые и защищенные ключевые слова, в • стандарте ничего не сказано о двоичной инкапсуляции.

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

1. СОМ - Component Object Model (компонентная объектная модель). Архитектура, разработанная корпорацией Microsoft и позволяющая создавать и поддерживать программные объекты и компоненты. Она обладает приблизительно теми же возможностями, что и архитектура CORBA, обеспечивающая взаимодействие распределенных объектов в сети.

2. CORBA - Common Object Request Broker Architecture (общая архитектура брокера объектных запросов). Стандарт, который был предложен консорциумом OMG для организации взаимодействия распределенных объектов. Архитектура CORBA позволяет выполнять * в сети программы, написанные на любом языке, независимо от того,

на какой платформе они запускаются. В архитектуре CORBA клиент ¿,

выполняет запрос к общему интерфейсу, который называется брокером объектных запросов. Брокер ORB пересылает запрос соответствующему объекту, а затем возвращает клиенту полученные результаты.

Для реализации среды и модулей мультиверсионного программного обеспечения, с учетом требований сформулированных в разделе 4, была выбрана технология компонентной объектной модели Microsoft (СОМ).

Философия СОМ заключается в следующем: программа-клиент использует при своей работе объект (объекты) некоторой другой программы

(сервера) так, словно эти объекты являются частью самого клиента. Основную роль при этом играет интерфейс объектов. Под интерфейсом объекта подразумевается поименованное множество функционально связанных методов (операций) объекта. Интерфейс может формироваться, как правило, при помощи IDL (Interface Definition Language), специального С++ -подобного языка описания интерфейсов. Клиент получает именно интерфейс затребованного объекта. Сервер же представляет собой программу, содержащую, кроме всего прочего, еще один или несколько объектов СОМ. Сервер СОМ может создавать реализации объектов из нескольких классов, каждый из которых представляет различные варианты поведения объекта. СОМ-клиент взаимодействует с СОМ-сервером через указатель на интерфейс и использует этот указатель для вызова методов сервера.

При этом клиент и сервер могут сосуществовать и взаимодействовать тремя различными способами:

1. Клиент и сервер исполняются на одном компьютере в рамках единого процесса;

2. Клиент и сервер запускаются на одной машине в рамках разных процессов;

3. Клиент и сервер - разные программы на различных компьютерах в составе сети.

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

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

В пятом разделе приводится описание реализованной среды и модулей мультиверсионного программного обеспечения (MVS комплекс) на основе компонентной (СОМ) архитектуры и с учетом требований, сформулированных в разделе 4. MVS комплекс состоит из нескольких компонентов и множества интерфейсов. Названия компонентов и интерфейсов, специфичных для MVS, имеют префиксы Mvs и IMvs соответственно. Основные составляющие MVS компоненты и интерфейсы приведены в таблице 1. Структура комплекса и взаимосвязь его компонент представлена на рисунке 3.

Таблица 1 - Основные компоненты и интерфейсы комплекса МУ5

ш Ияоне»*-^ '" ?>шдошие нятоачсни« ____ш и___ -А •

Му$Епуе1оре Среда исполнения. Обеспечение взаимодействия между программными компонентами, решающим алгоритмом и компонентом ввода/вывода.

ГМубСОПЙ-О! Управление процессом работы комплекса, (остановка/запуск процесса обработки данных).

2 и ШувМоёе! Подключение и настройка программных компонент, модуля ввода/вывода и решающего модуля. Настройка параметров функционирования среды.

о ■е- о. <и Н X X ШувЗгаШБ Предоставление данных о текущем состоянии системы и статистические данные о работе программных модулей.

ШувЮЕуеп! Уведомление среды исполнения о появлении на входе системы управления новых данных для обработки.

ШУБРГОЯЕУСЩ Уведомление среды исполнения об изменениях, происходящих в программных компонентах.

МувТО Инкапсулирует функции для взаимодействия с внешней средой (управляемым объектом). Обеспечивает ввод/вывод данных системы.

3 о >5 <и •Я« ГМу.^прШ: Получение данных ввода из внешней среды

О. о н X X ГМувОи1рШ Передача данных вывода во внешнюю среду.

МУ$Рго8[1,2,...Л] Множество программных модулей, инкапсулирующих функции обработки данных.

Интерфейсы ТМуБРгодСопгго! Универсальный интерфейс подключения к среде исполнения. Благодаря идентичности подключения программных модулей среда исполнения может одинаково работать с любыми программными модулем.

Му$5о1уег Инкапсуляция функции решающего алгоритма Принятие решения о работе программных модулей.

Л о >К ю •в" IMvsSolver Взаимодействие со средой исполнения, получение результатов работы программных модулей.

и £ К IMvsSolverControl Управление параметрами работы решающего алгоритма.

MvsUserlnterface Использует GDI для вывода изображения структуры комплекса на экран пользователя, а так же предоставляет элементы управления комплексом.

Интерфейсы IMvsEvent Интерфейс событий уведомляет пользовательский интерфейс об изменениях, происходящих в среде исполнения.

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

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

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

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

Клиентский ЕХЕ-Модуль

| | - компонент —- ссылка на интерфейс

—О - интерфейс компонента - границы процессов

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

параметрам: по

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

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

Таблица 2 - Характеристики программных компонент

,.,-,-Л ,!. ___I... «и Л ' ii4iiivulu.um.J-! 11

я у. --<»-» ЩЩЩРц 5

1 0.05 Арифметическая ошибка расчетов Сбой

2 0.025 Арифметическая ошибка расчетов Сбой

3 0.04 Арифметическая ошибка расчетов Сбой

4 0.1 Ошибка обращения к памяти Отказ

5 0.067 Логическая ошибка, зацикливание действий Отказ

6 0.02 Логическая ошибка, бесконечная рекурсия Отказ

Таблица 3 - Результаты тестирования комплекса МУБ

10000 50000 100000

Количество сбоев/отказов компонента #1 552 2527 5004

Количество сбоев/отказов компонента #2 145 1092 2371

Количество сбоев/отказов компонента #3 484 2203 4357

Количество сбоев/отказов компонента #4 1068 5022 10364

Количество сбоев/отказов компонента #5 685 3501 7040

Весовой коэффициент компонента #1 0.187 0.190 0.192

Весовой коэффициент компонента #2 0.250 0.264 0.270

Весовой коэффициент компонента #3 0.211 0.219 0.221

Весовой коэффициент компонента #4 0.145 0.128 0.119

Весовой коэффициент компонента #5 0.207 0.200 0.199

Количество сбоев среды исполнения 0 1 2

Количество отказов среды исполнения 0 0 0

Вероятность сбоя среды исполнения 0 0.00002 0.00002

Таблица 4 — Зависимость вероятности сбоя/отказа среды исполнения от количества программных модулей

Ы(М .....г .,

2 3 4 5

Вероятность сбоя КП 0.05 0.0019 0.0003 0.00002

Вероятность отказа КП 0 0 0 0

2 3 4 5

Количество программныхкомпонент

Рисунок 4. Зависимость вероятности сбоя среды исполнения от количества программных компонент На основе проведенного тестирования разработанного комплекса программ сделаны следующие выводы:

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

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

3. Увеличение количества программных компонент на единицу позволяет уменьшить вероятность сбоя комплекса программ на один порядок.

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

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

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

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

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

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

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

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

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

следующих работах:

1. Поздняков, Д.А. Разработка и исследование среды мультиверсионного исполнения программных модулей / Д.А. Поздняков, И.С. Титовский, Р.В. Юнусов; Вестник НИИ СУВПТ. - Вып 13. - Красноярск: НИИ СУВПТ, 2003.-С. 155-170.

2. Поздняков, Д.А. Архитектуры программных систем с применением мультиверсионной методологии / Д.А. Поздняков; Вестник университетского комплекса. - Вып. 6(20). - Красноярск: НИИ СУВПТ, ВСФ РГУИТП, 2005. - С. 111-118

О в- . 98 12 ss/Лг

3. Поздняков, Д.А. Обеспечение независимости модулей | мультиверсионного программного обеспечения на стадии исполнения | / Д.А. Поздняков, М.Ю. Слободан; Вестник университетского f комплекса. - Вып. 6(20). - Красноярск: НИИ СУВПТ, ВСФ РГУИТП, I 2005.-С. 185-196.

4. Поздняков, Д.А. Программная система "NVX vl.O" (Среда мультиверсионного исполнения программных модулей). / Д.А. Поздняков // Компьютерные учебные программы и инновации. - 2005,

№6.-С. 13-14. 1

5. Поздняков, Д.А. Краткий обзор методов повышения качества программных средств систем управления / Д.А. Поздняков, И.С. Титовский; Вестник НИИ СУВПТ. - Вып.12. - Красноярск: НИИ СУВПТ, 2003. - С. 57-60.

6. Ковалев И.В., Поздняков Д.А., Ступина A.A., Титовский И.С. Программная система «NVX vl.O» (Среда мультиверсионного 1 исполнения программных модулей) // Компьютерные учебные программы и инновации. - 2005, №6. 1 http://www.informika.ru/iext/magaz/innovat/n6_2005/n6_2005.html

7. Kovalev I., Pozdnjakov D., Stupina A., Titovskiy I. Program Systems «NVX vl 0» // The magazine Computing teaching programs and innovation. - 2005, №6.

http ://wwv. in formika.ru/text/rnagaz/innovat/cng/n6eng_2005/n6eng_2 005.htm

8. Поздняков, Д.А. Компонентная программная архитектура мультиверсионных систем обработки информации и управления / Д.А. Поздняков // Современные телекоммуникационные и I информационные технологии: материалы ежегодной заочной I конференции РАЕН.- М.: РАЕН, 2006.- С. 122-126. j

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

9. Ковалев И.В.. Поздняков Д.А., Ступина A.A., Титовский И.С. ¡¡« Программная система «NVX vl.O» (Среда мультиверсионного | исполнения программных модулей). - М: ВНТИЦ, 2004. - № 50200400994.

10. Ковалев И.В., Царев Р.Ю., Семенько Т.И., Поздняков Д.А. Система оценки и выбора корректного результата исполнения мультиверсий (Программная система «MVR-DM ver.1.0»), - М: ВНТИЦ, 2006. - № 50200600084.

Подписано в печать IV 0 Ч ■ 2006 г.

Формат 60x84/24. Бумага писчая. Уч. изд.л. 1.

Тираж 50 экз Заказ № Отпечатано в отделе множительной техники СибГАУ

Содержание.

Введение.

1 Проблемы проектирования высоконадежных программно-информационных систем.

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

1.2 Проблемы проектирования распределенных информационных систем

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

2.1 Структура и алгоритмы программного обеспечения.

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

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

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

2.5 Парные процессы.

2.6 Разнообразие Данных.

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

2.8 Выводы.

3 Применение методологии мультиверсий для обеспечения отказоустойчивости программного обеспечения.

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

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

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

3.4 Блоки восстановления с согласованием.

3.5 Проблемы мультиверсионного программного обеспечения.

3.5.1 Разработка мультиверсионного программного обеспечения.

3.5.2 Алгоритмы выбора вывода.

3.6 Отказоустойчивость в операционных системах.

3.7 Выводы.

4 Модульные принципы построения программного обеспечения.

4.1 Требования, предъявляемые к модулям программного обеспечения.

4.1.1 Динамическое подключение модулей.

4.1.2 Инкапсуляция.

4.1.3 Защита модуля.

4.1.4 Независимость от языка.

4.2 Объектно-ориентированные методы проектирования модулей программного обеспечения.

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

4.3.1 Проблемы распространения программного обеспечения.

4.3.2 Проблемы стандартизации на двоичном уровне.

4.3.3 Проблемы инкапсуляции.

4.4 Технологии компонентного проектирования.

4.4.1 Компонентная объектная модель (Component Object Model, COM).

4.4.2 Общая архитектура брокеров объектных запросов (Common Object Request Broker Architecture, CORBA).

4.5 Выводы.

5 Построение мультиверсионного программного обеспечения с использованием технологии компонентного проектирования (СОМ).

5.1 MVS комплекс. Детали и составные части.

5.1.1 Клиентский ЕХЕ-модуль.

5.1.2 Компонент MvsEnvelope.

5.1.3 Компонент MvsIO.

5.1.4 Компоненты MvsProg[l, 2,., N].

5.1.5 Компонент MvsSolver.

5.1.6 Компонент MvsUserlnterface.

5.2 MVS комплекс в работе.

5.3 Результаты тестирования MVS комплекса.

5.4 Выводы.

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

Несмотря на широкое распространение, программное обеспечение едва когда-либо было "совершенно". Из-за огромного количества причин, чрезвычайно трудно создать безупречное программное обеспечение. Согласно [1], "программное обеспечение - систематическое представление и обработка знаний человека". Для людей совершенное знание проблемы и ее решение редко достигается. В [2] заявлено, что "программы - это не больше, чем наилучшее представление программиста о том, что система должна делать". Даже если программист достаточно квалифицирован для решения проблемы, то знание должно быть преобразовано в систематическое представление, адекватное для автоматической обработки. Современные компьютеры беспощадны, когда работают с программным обеспечением: если есть ошибка в логике, рано или поздно эта ошибка обнаружится на выходе независимо от последствий. Только наиболее тривиальные программные решения могут быть выполнены без ошибок. Поскольку компьютеры применяются для решения все более сложных проблем, то растет вероятность логических ошибок присутствующих в программном обеспечении.

Использование программных систем во многих областях науки и производства, предъявляет высокие требования к надежности программных средств. Такими областями являются различные автоматические системы управления и обработки данных: банковская система, космос, подводные и подземные исследования, химическое производство, прогнозирование, медицина и другие. Сбой программных систем в подобных областях может повлечь за собой большие потери и иметь весьма серьезные последствия. Поскольку абсолютная уверенность в безупречности программных средств редко достигается, применяются методы повышения отказоустойчивости программного обеспечения для выполнения требований надежности проекта. Программная отказоустойчивость достигается благодаря использованию алгоритмов программирования и методов разработки программного обеспечения, которые повышают вероятности того, что конечная реализация проекта приведет к правильному и/или безопасному результату. Так как правильность и безопасность - концепции системного уровня, потребность и степень использования программной отказоустойчивости непосредственно зависит от предназначения приложения и полного проектирования систем.

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

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

• образование, опыт и местоположение разработчиков;

• алгоритмы и структуры данных;

• языки программирования;

• методы разработки программного обеспечения;

• инструментальные средства программирования и среды (включая компиляторы);

• методы тестирования и инструментальные средства.

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

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

Поставленная цель достигается путем решения следующих задач:

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

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

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

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

Методы исследования: Методы прикладного системного анализа; объектно-ориентированного программирования; компонентного проектирования сложных программных систем; мультиверсионного проектирования программного обеспечения отказоустойчивых систем управления и метод изменяющихся вероятностей.

Научная новизна работы:

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

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

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

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

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

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

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

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

3. Программная реализация среды исполнения на базе компонентной архитектуры для распределенной мультиверсионной системы. Апробация работы. Основные положения и результаты работы прошли апробацию на 46 и 48-й научно-технических конференциях преподавателей, аспирантов и студентов Красноярского государственного технического университета (2003, 2006), на Пленарном заседании Второй Всероссийской конференции «Молодежь и наука: начало 21-го века», посвященной 50-летию КГТУ (2006), на международной AMSE-конференции «Modeling and Simulation -MS'05» (Rouen, Франция, 2005), на ежегодной заочной конференции РАЕН «Современные телекоммуникационные и информационные технологии» (2006). Докладывались на научно-технических семинарах НИИ Систем управления, волновых процессов и технологий (2003-2006 гг.).

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

5.4 Выводы

Результатом практической реализации мультиверсионного метода создания отказоустойчивого программного обеспечение с использование компонентного проектирования стало создание среды мультиверсионного исполнения программных модулей и ряда программных модулей, которые вместе с ней составили целый комплекс программ. Тестирование данного КП позволило обозначить нам высокую эффективность мультиверсионного программирования как метода разработки отказоустойчивого программного обеспечения и целесообразность применения компонентной архитектуры. Но анализ функционирования разработанного КП позволил выявить некоторые недостатки. А именно, была установлена низкая эффективность работы среды исполнения при использовании двух программных модулей, из-за возникающей, в процессе принятия решения, неопределенности. Это позволяет нам заявить, что для обеспечения устойчивости КП мультиверсионной системы к сбоям, необходимо три или большее количество избыточных версий программных модулей.

Заключение

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

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

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

• Выработаны требования к модулям мультиверсионного программного обеспечения.

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

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

1. Lyu, М. R. Software Fault Tolerance / М. R. Lyu John Wiley & Sons, 1995.

2. Abbott, R. J. Resourceful Systems for Fault Tolerance, Reliability, and Safety / R. J. Abbott ACM Computing Surveys, Vol. 22, No. 1, March 1990. - pp. 35-68.

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

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

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

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

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

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

9. Pressman, R. S. Software Engineering: A Practitioner's Approach. / R. S. Pressman. The McGraw-Hill Companies, Inc., 1997.

10. Denning, P. J, Fault Tolerant Operating Systems. / P. J. Denning. ACM Computing Surveys, Vol. 8, No. 4, December 1976. - pp. 359-389.

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

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

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

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

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

16. Pradhan, D. K. Fault-Tolerant Computer System Design. / D. K. Pradhan -Prentice-Hall, Inc., 1996.

17. Hecht, H. Fault-Tolerance in Software, in Fault-Tolerant Computer System Design. / H. Hecht, M. Hecht Dhiraj K. Pradhan, Prentice Hall, 1996.

18. Randell, B. The Evolution of the Recovery Block Concept, in Software Fault Tolerance / B. Randell, J. Xu, M. R. Lyu- Wiley, 1995.-pp. 1-21.

19. Randell, B. Predictably Dependable Computing Systems / B. Randell Springer, 1995.

20. Gray, J. Why Do Computers Stop and What Can Be Done About It? / J. Gray -Proceedings of the Fifth Symposium On Reliability in Distributed Software and Database Systems, January 13-15, 1986. pp. 3-12.

21. Ammann, P. E. Data Diversity: An Approach to Software Fault Tolerance / P. E. Ammann, J. C. Knight IEEE Transactions on Computers, Vol. 37, No. 4, April 1988.-pp. 418-425.

22. Nicola, V. F. Checkpointing and the Modeling of Program Execution Time, in Software Fault Tolerance. / V. F. Nicola, M. R. Lyu Wiley, 1995. - pp. 167188.

23. Avizienis, A. On the Implementation of N-Version Programming for Software Fault Tolerance During Execution. / A. Avizienis, L. Chen Proceedings of the IEEE COMPSAC'77, November 1977.-pp. 149-155.

24. Avizienis, A. The Methodology of N-Version Programming Software Fault Tolerance / A. Avizienis, R. Lyu, John Wiley & Sons, 1995.

25. Scott, R. K. Fault-Tolerant Software Reliability Modeling / R. K. Scott, J. W. Gault, D. F. McAllister IEEE Transactions on Software Engineering, Vol. SE-13, No. 5, May 1987. - pp. 582-592.

26. Bishop, P. Software Fault Tolerance by Design Diversity. / P. Bishop, R. Lyu -John Wiley & Sons, 1995.

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

28. Avizienis, A. Dependable Computing: From Concepts to Design Diversity. / A. Avizienis, J.-C. Laprie Proceedings of the IEEE, Vol. 74, No. 5, May 1986. -pp. 629-638.

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

30. Avizienis, A. Software Fault Tolerance, Information Processing 89. / A. Avizienis Proceedings of the IFIP 11th World Computer Congress, 1989. -pp. 491-498.

31. Avizienis, A. Dependable Computing Depends on Structured Fault Tolerancc. / A. Avizienis Proceedings of the 1995 6t h International Symposium on Software Reliability Engineering, Toulouse, France, 1995. - pp. 158-168.

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

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

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

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

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

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

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

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

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

41. Gersting, J. A Comparison of Voting Algorithms for N-Version Programming. / J. Gersting Proceedings of the 24th Annual Hawaii International Conference on System Sciences, Volume II, January 1991. - pp. 253-262.

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

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

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

45. Tso, K. S. Community Error Recovery in N-Version Software: A Design Study with Experimentation. / K. S. Tso, A. Avizienis Digest of Papers FTCS-17: The Seven teenth International Symposium on Fault-Tolerant Computing, July 6-8, 1987.-pp. 127-133.

46. Saglietti, F. The Impact of Voter Granularity in Fault-Tolerant Software on System Reliability and Availability. / F. Saglietti, M. Kersken, Software Fault Tolerance: Achievement and Assessment Strategies, Springer-Verlag, 1991.

47. Voas, J. M. Certifying Off-the-Shelf Software Components. / J. M. Voas -IEEE Computer, Vol. 31, June 1998. pp. 53-59.

48. Salles, F. MetaKernels and Fault Containment Wrappers. / F. Salles Digest of

49. Papers: Twenty-Ninth Annual International Symposium on Fault-Tolerant Computing, Madison, Wisconsin, June 15- 18, 1999. pp. 22-29.

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

51. Russinovich, M. Application Transparent Fault Management in Fault Tolerant Mach. / M. Russinovich Digest of Papers: The Twenty-Third International

52. Symposium on Fault-Tolerant Computing (FTCS-23), Toulouse, France, June 22-24, 1993.-pp. 10-19.

53. Russinovich, M. Application Transparent Fault Managemet in Fault Tolerant Mach, in Foundations of Dependable Computing System Implementation. / M. Russinovich, G. M. Koob, C. G. Lau -Kluwer Academic Publishers, 1994. -pp. 215-241.

54. Russinovich, M. Fault-Tolerance for Off-The-Shelf Applications and Hardware. / M. Russinovich, Z. Segall Digest of Papers: The Twenty-Fifth International Symposium on Fault-Tolerant Computing, Pasadena, CA, June 27 -30, 1995.-pp. 67-71.

55. Ковалев, И.В. Автоматизация создания программных средств систем управления. / В кн.: Микроэлектронные устройства: проектирование и технология. Красноярск. КПИ, 1990. - С. 79-85.

56. Ковалев И.В. Многоатрибутивная модель формирования гарантоспособного набора проектов мультиверсионных программных систем. / И.В. Ковалев, Р.Ю. Царев; Вестник НИИ СУВПТ. Вып.7. -Красноярск: НИИ СУВПТ, 2001. - С. 129-137.

57. Ковалев, И.В. Оптимальное проектирование мультиверсионных систем управления. / И.В. Ковалев, А.А. Попов, А.С. Привалов. Доклады НТК смеждународным участием «Информационные технологии в инновационных проектах». Ижевск: ИжГТУ, 2000. - С. 24-29.

58. Ковалев, И.В. Параллельные процессы в информационно-управляющих системах. Формирование и оптимизация: Монография. / И.В. Ковалев, Р.Ю. Царев, Ю.Г. Шиповалов. Под ред. д.т.н., проф. A.B. Медведева. -Красноярск: НИИ СУВПТ, 2001. - 143 с

59. Ковалев, И.В. Система мультиверсионного формирования программного обеспечения управления космическими аппаратами: Диссертация на соискание ученой степени доктора технических наук. / Красноярск: КГТУ, 1997.-228 с.

60. Ковалев, И.В.Надежность архитектуры программного обеспечения телекоммуникационных технологий. / И.В. Ковалев, Н.В. Василенко, Р.В.Юнусов; Международная научная конференция Telematica'2001, Санкт-Петербург, 2001- С. 23-24

61. Ковалев, И.В.Оценка надежности аппаратно-программного информационно-управляющего комплекса. САКС-2002. / И.В.Ковалев, Р.В Юнусов; : Тезисы докладов международной научно-практической

62. Ш конференции (6-7 дек. 2002, г. Красноярск)/ СибГАУ. Красноярск, 2002.1. С. 352-353

63. Ковалев, И.В. Мультиверсионный метод повышения программной надежности информационно-телекоммуникационных технологий вкорпоративных структурах. / И.В.Ковалев, Р.В. Юнусов;

64. Телекоммуникации и информатизация образования. 2003. №2, С. 50-55

65. Попов, A.A. Бинарная модель отказоустойчивой системы программного обеспечения: Доклады НТК с международным участием «Информационные технологии в инновационных проектах». / A.A. Попов, A.C. Привалов. Ижевск: ИжГТУ, 2000. - С. 77-83

66. Саркисян, А. А. Повышение качества программ на основе автоматизированных методов. / А. А. Саркисян М.: Радио и связь, 1991.1. Ш -160 с.

67. Царев, Р.Ю. Многокритериальное принятие решений при создании отказоустойчивого программного обеспечения. / Вестник НИИ СУВПТ. -Вып.2. Красноярск: НИИ СУВПТ, 1999. - С. 190-194.

68. Царев, Р.Ю. Преобразование атрибутов при многоатрибутивном принятии решения. / Решетневские чтения. Тез. докл. V Всерос. Научн.-практ. конф. студентов, аспирантов молодых специалистов 12-15 ноября 2001г. -Красноярск: CAA, 2001. С. 119-120.

69. Юнусов, Р.В. Анализ надежности аппаратно-программного информационно-управляющего комплекса. / Вестник НИИ СУВПТ: Сб. научн. Трудов. / Под общей ред. профессора Н.В. Василенко; Красноярск: НИИ СУВПТ. 2003. Выпуск 11. С. 103-106.

70. Юнусов, Р.В. Оценка надежности программного обеспечения клиент-сервер на примере комплексной системы управления предприятием «Галактика». / Вестник НИИСУВПТ; Красноярск: НИИ СУВПТ.-2001. -Вып.7. С. 107-112.

71. Юнусов, Р.В. Оценка надежности и гарантоспособная модель архитектуры программного обеспечения. / Вестник НИИСУВПТ; Красноярск: НИИСУВПТ.2001. Вып.8. С. 194-208.

72. Юнусов, Р.В. Моделирование программных архитектур автоматизированных систем управления. / Управляющие и вычислительные системы. Новые технологии: Материалы всероссийской электронной научно-технической конференции. Вологда: ВоГТУ. 2001. С. 60-61.

73. Фокс, Д. Программное обеспечение и его разработка: Пер. с англ. / Д. Фокс М.: Мир, 1985. - 268 с.

74. Козленко Л. Проектирование информационных систем. / Л. Козленко -М.: КомпьютерПресс, № 9-11, 2001.

75. Орлов С.А. Технологии разработки программного обеспечения. / С.А. Орлов СПб.: Питер, 2002.

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

77. Майерс, Г. Надежность программного обеспечения: Пер. с англ. / Г. Майерс, В. Ш. Кауфман. М.: Мир, 1980. - 360 с.

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

79. Элджер, Д. С++: библиотека программиста. / Д. Элджер СПб.: Питер, 2000. - 320 с.

80. Страуструп, Б. Дизайн и эволюция С++. / Б. Страуструп СПб.: Питер, 2006.-448 с.

81. Липпман, С. Б. Основы программирования на С++. / С. Б. Липпман -Вильяме, 2002. 256 с.

82. Саттер, Г. Решение сложных задач на С++. / Г. Саттер Вильяме, 2002. 400 с.

83. Саттер, Г. Новые сложные задачи на С++. / Г. Саттер Вильяме, 2005. -270 с.

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

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

86. Rector, В. ATL Internals. / В. Rector, С. Sells Addison Wesley, 1999. - 635 с.

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

88. Шаллоуей, А. Шаблоны проектирования. / А. Шаллоуей, Д. Р. Трот -Вильяме, 2002. 288 с.

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

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

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

92. Аллен, Э. Типичные ошибки проектирования. / Э. Алей СПб.: Питер, 2003 - 224 с.

93. Antamoshkin, A. System Analysis, Design and Optimization / A. Antamoshkin, H.P. Schwefel, and others. Ofset Press, Krasnoyarsk, 1993. -312 p.

94. 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 913, 1991.

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

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

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

98. 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, pp. 31-43.