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

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

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

□□3458000

I

Штенцель Артем Владимирович

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

Специальность 05.13.11 - Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей

Автореферат

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

Научный руководитель: к.т.н., доцент Тынченко С.В.

1 5 ДЕК 2008

Красноярск 2008

003458000

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

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

доцент Тынченко Сергей Васильевич

Официальные оппоненты: доктор технических наук,

профессор Петров Михаил Николаевич

кандидат технических наук,

доцент Ежеманская Светлана Николаевна

Ведущая организация: НИИ Автоматики и электромеханики, г. Томск

Защита состоится «29» декабря 2008 года в 14.00 часов на заседании диссертационного Совета ДС 212.023.04 при Сибирском государственном аэрокосмическом университете им. академика М.Ф. Решетнева по адресу: г. Красноярск, пр. им. газ. «Красноярский рабочий», 31.

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

Автореферат разослан 28 ноября 2008 года.

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

И.В. Ковалев

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

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

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

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

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

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

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

• методы разработки ПО;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

к=1 (65,

при ограничениях

Щ . : .....

,1 =%...,п;

м

п от, .

< 5;

где Я-, задаётся следующим выражением:

Я, = 1 -]~У(1 - > / =

Здесь введены следующие условные обозначения: К- число функции, реализуемых модулем мультиверсионной ПС; п - число процедур, используемых в модулях ПС; ^ - частота (весовой коэффициент) использования к-й функции ПСД= 1,2,...Д;

от, - число мультиверсий 1-й процедуры, г = 1,..., и; Щ— оценка надежностиу'-й мультиверсии г'-й процедуры модуля ПС; Ху- булева переменная, равная 1, если /-я мультиверсия выбрана для г-й процедуры модуля ПС, иначе - 0;

- оценка надежности г-й процедуры модуля ПС; Я - оценка надежности мультиверсионного модуля ПС; Су - стоимость разработки и сопровождения у'-й мультверсии г'-й процедуры программного модуля ПС;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

: Компонуй Г " * ' '..: ■ ..... , Описание/назначение ...... ' ■•

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

IMvsControl Управление процессом работы комплекса, (остановка/запуск процесса обработки данных).

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

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

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

IMvsProgEvent Уведомление среды исполнения об изменениях, происходящих в программных компонентах.

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

2 о >я о IMvsInput Получение данных ввода из внешней среды

Р. и Ё К IMvsOutput Передача данных вывода во внешнюю среду.

MvsProg[l,2,...,N] Множество программных модулей, инкапсулирующих функции обработки данных.

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

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

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

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

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

МувЕуеп! Интерфейс событий уведомляет пользовательский

о « интерфейс об изменениях, происходящих в среде

к исполнения.

О, н 1Му8и$ег1п1ег£асе Используется клиентской программой для

Я N1 настройки и управления отображением данных

комплекса.

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

Условные обозначения:

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

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

Рисунок 1. Модель мультиверсионного программного обеспечения построенного на основе технологии СОМ объектов.

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

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

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

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

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

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

Ниже приведены исходные данные и результаты тестов.

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

Номер Вероятность компонента ошибки Тин ошибки : 1 ШШЫтШ. Последствия ошибки

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

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

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

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

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

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

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

щшшт ние параметра Количество итераций среды исполнения

..... V; 100000

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

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

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

Количество сбоев/отказов компонентам 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 - Зависимость вероятности сбоя/отказа среды исполнения от количества программных модулей

Наименование параметра Кол-во программных ко.мпопеш

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

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

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

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

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

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

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

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

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

4. Предложена 2-х этапная процедура формирования отказоустойчивого модульного ПО на основе мультиверсионной программной архитектуры.

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

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

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

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

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

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

1. Штенцель, A.B. Принципы формирования мультиверсионного программного комплекса [Текст] / A.B. Штенцель, И.А. Капчинский, A.C. Кузнецов // Вестник СибГАУ,- 2008,- № 1(18).- С. 18-23.

2. Штенцель, A.B. Оценка надежности мультиверсионной программной архитектуры систем управления и обработки информации [Текст] / A.B. Штенцель, A.B. Новой // Вестник СибГАУ,- 2008,- № 3(20).- С. 73-79.

3. Синтез оптимальных мультиверсионных программных комплексов с модульной архитектурой (Программная система "Designer Multiversion Software ver. 1.0") [Текст] / В.П. Петрулевич, О.И. Завьялова, Р.Ю. Царев, A.B. Штенцель, С.Н. Гриценко // Инновации в науке и образовании (Телеграф отраслевого фонда алгоритмов и программ).-2008. № 7(42).- С. 3-4.

4. Штенцель, A.B. Архитектурное проектирование мультиверсионного программного обеспечения отказоустойчивых систем управления [Текст] / A.B. Штенцель // Вестник НИИ СУВПТ.- 2007.- Вып. 25,- С. 57-71.

5. Штенцель, A.B. Минимизация межмодульного интерфейса в задаче синтеза мультиверсионных модульных систем обработки информации [Текст] / A.B. Штенцель, C.B. Тынченко, А.Н. Лайков // Вестник НИИ СУВПТ.- 2007,- Вып. 25.- С. 72-76.

6. Штенцель, A.B. Применение методологии мультиверсий для обеспечения отказоустойчивости программных средств [Текст] / A.B. Штенцель, И.А. Капчинский // Вестник НИИ СУВПТ.- 2006.- Вып. 24,-С. 138-141.

7. Штенцель, A.B. Автоматизированная система расчетов за услуги передачи данных [Текст] / A.B. Штенцель // Материалы YII-й Всероссийской НПК «Решетневские чтения» (11-12 ноября 2004 г.).-Красноярск: СибГАУ, 2004. - С. 155-157.

8. Штенцель, A.B. Повышение качества работы баз данных под управлением СУБД «ORACLE» [Текст] / A.B. Штенцель, Е.В. Гражданцев // Актуальные проблемы экономики, права и информационных технологий. Сборник научных статей. Красноярск: КФ МЭСИ, 2005,- Часть 3. - С. 107-112.

9. Штенцель, A.B. Создание распределенной системы статистического учета и обработки информации для отказоустойчивого узла передачи данных [Текст] / A.B. Штенцель // Актуальные проблемы экономики, права и информационных технологий. Сборник научных статей. Красноярск: КФ МЭСИ, 2006,- Часть 3. - С. 71-79.

10. Штенцель, A.B. Отказоустойчивость СУБД CACHE для биллинговых систем [Текст] /A.B. Штенцель // Актуальные проблемы экономики, права и информационных технологий. Сборник научных статей. Красноярск: КФ МЭСИ, 2006.- Часть 3. - С. 80-84.

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

11. Петрулевич В.П., Завьялова О.И., Царев Р.Ю., Штенцель A.B., Гриценко С.Н. Синтез оптимальных мультиверсионных программных комплексов с модульной архитектурой (Программная система "DesignerMultiversionSoftware ver. 1.0"). - М.: ВНТИЦ, 2008. № 50200801438.

Заказ № щн Тираж 400 экз.

Отпечатано ООО «Новые компьютерные технологии» 660049 г. Красноярск, ул. К. Маркса, 62; офис 120; тел.: (391)226-31-31,226-31-11.

Введение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.4.1 Фазы разработки программного обеспечения.

1.4.1.1. Фаза дизайна архитектуры программного обеспечения.

1.4.1.2 Компоненты архитектуры.

1.4.2 Надежность архитектуры программного обеспечения.

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

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

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

2.1. Постановка задач синтеза.

2.2 Процедура решения задачи синтеза.

2.3. Программная реализация системыформирования структур мультиверсионных программных систем.

2.3.1 Общие сведения.

2.3.2 Описание системы формирования структур мультиверсионных программных систем.

2.3.3 Концептуальная архитектура системы формирования структур мультиверсионных программных систем.

2.3.4 Описание работы с системой.

2.3.5 Примеры решения задач и анализ результатов.

2.3.5.1 Исходные данные.

2.3.5.2 Результаты работы.

2.3.5.3 Полученная структурная схема программной системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

4 Инструментальные средства построения мультиверсионного ПО с использованием технологии компонентного проектирования (СОМ).

4.1 Инструментальный MVS комплекс.

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

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

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

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

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

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

4.2 Инструментальный MVS комплекс в работе.

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

4.4 Выводы.

Программное обеспечение (ПО), являясь неотъемлемой составляющей как коммерческих, так и специальных систем управления и обработки информации, проникает во многие области современной жизни, но, несмотря на столь широкое распространение, ПО едва когда-либо было «совершенно». Из-за огромного количества причин чрезвычайно трудно создать безупречный программный продукт. Только наиболее тривиальные программные решения могут быть выполнены без ошибок. Так как ЭВМ применяются для решения все более сложных задач в информационно-управляющих системах, то растет вероятность логических ошибок, присутствующих в ПО [1, 2, 5-11].

На сегодняшний день известны различные методы проектирования отказоустойчивого ПО [95-99]. Одним из наиболее перспективных является метод мультиверсионного проектирования, впервые предложенный А. Авижиенисом в 70-х годах двадцатого столетия и получивший развитие в работах Г. Гласса, Дж. Лапри, М. Луи, Дж. Муса, И. Соммервилла, В.В. Липаева, И.В. Ковалева, Р.Ю. Царева и др. При реализации мультиверсионности в программную систему (ПС) включается несколько программных компонент, дублирующих друг друга по своему целевому назначению. Мультиверсионность исполнения программных компонент обеспечивает функционирование системы независимо от скрытых ошибок отдельных версий программных модулей. Ключевое преимущество мультиверсионного ПО состоит в том, что сбой системы может произойти только в единственном случае - в случае сбоя существенного числа версий модулей. Мультиверсионные модули подтверждают работу друг друга, следовательно, мы можем быть уверены в точности результатов, которые они выбирают вместе.

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

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

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

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

• методы разработки ПО;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

4. Предложена 2-х этапная процедура формирования отказоустойчивого модульного ПО на основе мультиверсионной программной архитектуры.

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

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

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

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

1. Александров, А.В. Обеспечение устойчивости функционирования корпоративных сетей Текст. / А.В. Александров // Компьютерра. 2006. — № 14.- С.6-11.

2. Аниконов, А.В. Формирование мультиверсионных программных средств информационно-управляющих систем Текст. // Автореферат диссертации на соискание ученой степени кандидата технических наук. — Красноярск: СФУ, 2008.- 16 с.

3. Антонов, А.В. Системный анализ Текст. / А.В. Антонов.- М.: Высш. шк., 2004,- 454 с.

4. Анфилатов, B.C. Системный анализ в управлении Текст. / В.С Анфилатов,-М.: Финансы и статистика, 2003.- 368 с.

5. Басс, JI Архитектура программного обеспечения на практике Текст. / Л.Басс, П. Клементе, Р. Кацман .- Спб.: Питер, 2006.- 575 с.

6. Бондаренко В. Устойчивость на все сто Электронный ресурс. Режим доступа: http://www.muk.com.ua/lcentre/MUK - Classics of distribution.htm. -Загл. с экрана.

7. Богатырев, В.А. К повышению надежности вычислительных систем на основе динамического распределения функций Текст. / Изв. вузов. Приборостроение. 1981

8. Богатырев, В.А. Отказоустойчивые многомашинные вычислительные системы динамического распределения запросов при дублировании функциональных ресурсов : Учебник для студентов вузов Текст. / В.А. Богатырев.- Приборостроение, 1996. — № 4.

9. Боэм, Б. У. Характеристики качества программного обеспечения Текст. / Б. Боэм, Дж. Браун, X. Каспар, М. Липов, Г. Мак-Леод, М. Мерит. М.: Мир, 1981.-208 с.

10. Ю.Боэм, Б.У. Инженерное проектирование программного обеспечения Текст. : Пер. с англ. / Б.У. Боэм. М.: Радио и связь, 1985. - 512 с.

11. П.Брауде, Э. Технология разработки программного обеспечения Текст. / Э. Брауде.- Спб.: Питер, 2004.- 655 с.

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

13. И.Вахромеев К. Защита данных от катастроф Текст. / К. Вахромеев // Открытые системы. 2000. - №3. - С. 8-14.

14. Галатенко В.А. Информационная безопасность Текст. / В.А. Галатенко // Открытые системы. 1995. - №4. - С.3-10.

15. Герасимов, Ю. Улётный интерфейс Электронный ресурс. Режим доступа : http://www.usability.ru/toader/articles /flyoffui.htm. - Загл. с экрана.

16. Гласс Р. Руководство по надежному программированию Текст. : Пер. с англ. / Р. Гласс. М.: Финансы и статистика, 1982. - 256 с.

17. Дилон, Б. Инженерные методы обеспечения надежности систем Текст. / Б. Дилон, И. Сингх.-М.: Мир, 1984.-318 с.

18. Дубова, Н.А. Управление распределённой средой корпорации Текст. / Н.А. Дубова // Открытые системы. 1999. - № 11-12. - С. 53-57.

19. Елагин, В. Кластеры против катастроф Текст. / В. Елагин // Открытые системы. 2002. - № 6. - С. 29-36.23.3адорожный, В. Надёжная система из ненадёжных элементов Текст. / В. Задорожный, И. Малиновская // Открытые системы. 2000. - № 12. - С. 1518.

20. Иванов, П. Управление информационными системами: базовые концепции и тенденции развития Текст. / П. Иванов // Открытые системы. 1999. - № 4. -С. 37-42.

21. Климов А.А. Проектное управление Текст. / А.А. Климов // Экономист. -1998.-С. 32-35.

22. Ковалев, И.В. Система поддержки принятия решений по выбору состава отказоустойчивых систем управления Текст. / И.В. Ковалев, В.В. Смолин, Р.Ю. Царев // Программные продукты и системы, 2007, № 3 (79). С. 71-72.

23. Ковалев, И.В. Программная поддержка анализа кластерных структур отказоустойчивых систем управления Текст. / И.В. Ковалев, Е.А. Энгель, Р.Ю. Царев // Системы управления и информационные технологии, 2007, № 2. С.101-104.

24. Ковалев, И.В. Программно-алгоритмическое обеспечение методов оценки надежности распределенных компьютерных систем Текст. / И.В. Ковалев, В.А. Морозов, Р.Ю. Царев // Системы управления и информационные технологии, 2006, № 4. С.26-30.

25. Ковалев, И.В. Модель многокритериального принятия решений при выборе проектов информационно-управляющих систем Текст. / И.В. Ковалев, Т.И. Семенько, Р.Ю. Царев // Системы управления и информационные технологии, 2006, № 4. С.62-66.

26. Ковалев, И.В. Программная поддержка анализа кластерных структур отказоустойчивых информационных систем / И.В. Ковалев, Р.Ю.Царев, Е.А. Энгель // Научно-техническая информация, 2007, Серия 2, № 5, С. 15-17.

27. Ковалев, И.В. Мультиверсионный метод повышения программной надежности информационно-телекоммуникационных технологий в корпоративных структурах Текст. / И.В.Ковалев, Р.В. Юнусов // Телекоммуникации и информатизация образования. 2003. - №2. - С. 50-55.

28. Ковалев И.В., Царев Р.Ю., Слободин М.Ю., Усольцев А.А. Программная система «MultiForm vl.0» (Система многоатрибутивного формирования мультиверсионных программных средств). М.: ВНТИЦ, 2004. - № 50200400275.

29. Ковалев И.В., Царев Р.Ю., Золотарев К.В., Слободин М.Ю. Программная система «Cluster Analyzer vl.0» (Система поддержки принятия решений при проектировании кластерной инфраструктуры). М.: ВНТИЦ, 2004. - № 50200400611.

30. Князькин, Ю.М. Построение на встроенной ЦВМ интерпретатора алгоритмов логического управления сложным объектом Текст. / Ю.М Князькин, В.В. Хартов. — Проблемы управления движением и навигацией. 1987. - № 22.

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

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

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

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

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

36. Коганов А.В., Романюк С.Г. Экономический подход к понятию надежности программы Текст. / А.В. Коганов // Открытые системы. 2005. - №3. - С. 311.

37. Кочетов, Ю.А. Задачи оптимального выбора состава систем технических средств при многоэтапном процессе выполнения работ Текст. / Ю.А. Кочетов // Препринт 12. Новосибирск, Ин-т математики СО АН СССР, 1987. - 47 с.

38. Липаев В.В. Надёжность программных средств Текст. / В.В. Липаев // СИНТЕГ. -М., 1998. 232 с.

39. Липаев, В.В. О проблемах оценивания качества программных средств Текст. / В.В. Липаев // Информационные технологии. 2002. - С. 19-23.

40. Липаев, В.В. Проектирование математического обеспечения АСУ Текст. / В.В. Липаев. -М.: Советское радио, 1977. 400 с.

41. Липаев, В.В. Технология проектирования комплексов программ АСУ Текст. / В.В. Липаев, Л.А. Серебровский. М.: Радио и связь, 1983. - 264 с.

42. Липаев, В.В. Тестирование программ Текст. / В.В. Липаев. М.: Радио и связь, 1986.-234 с.

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

44. Мамиконов, А.Г. Типизация разработки модульных систем обработки данных Текст. / А.Г. Мамиконов, В.В. Кульба, С.А. Косяченко. М.: Наука, 1989. -165 с.

45. Мамиконов, А.Г. Синтез оптимальных модульных систем обработки данных Текст. / А.Г. Мамиконов, В.В. Кульба. М.: Наука, 1986.

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

47. Месорович, М. Теория иерархических многоуровневых систем Текст. / М. Месорович, Д. Мако, А. Такахара. М.: Мир. 1973. - С. 344.

48. Михалевич, B.C. Вычислительные методы исследования и проектирования сложных систем Текст. / B.C. Михалевич, B.JI. Волкович. Наука, 1982. -286 с.

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

50. Половко, A.M. Основы теории надежности Текст. / A.M. Половко, С.В. Гуров.- СПб.: БХВ-Петербург, 2006.- 704 с.

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

52. Раинкшкс, К. Оценка надежности систем с использованием графов Текст. / К. Раинкшкс, И.А. Ушаков. М.: Радио и связь, 1988.

53. Рябинин, И.А. Надежность и безопасность структурно-сложных систем Текст. / И.А. Рябинин. СПб.: Политехника, 2000.- 247 с.

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

55. Синтез оптимальных мультиверсионных программных комплексов с модульной архитектурой (Программная система "Designer Multiversion

56. Software ver. 1.0") Текст. / В.П. Петрулевич, О.И. Завьялова, Р.Ю. Царев, А.В. Штенцель, С.Н. Гриценко // Инновации в науке и образовании (Телеграф отраслевого фонда алгоритмов и программ).- 2008. № 7(42).- С. 3-4.

57. Системный анализ: Проектирование, оптимизация и приложения Текст. // В 2 т., под общ. Ред. Антамошкина А.Н. Красноярск: САА, 1996. - 206 с.

58. Соммервилл, Я. Инженерия программного обеспечения Текст. / Я.Соммервилл.- М.: «Вильяме», 2002.- 624 с.

59. Сугак, Е.В. Надежность технических систем Текст. / Под общ. Ред. Е.В. Сугака.- Красноярск: НИИ СУВПТ, 2000.- 607 с.

60. Таненбаум, Э. Распределенные системы. Принципы и парадигмы Текст. / Э. Таненбаум.- СПб.: Питер, 2003.- 877 с.

61. Толковый словарь по вычислительным системам / Под ред. В. Иллигуорта и др. Текст. : Пер с англ. -М.: Машиностроение, 1991. 560 с.

62. Черкесов, Г.Н. Надежность аппратано-программных комплексов Текст. /Г.Н. Черкесов.- СПб.: Питер, 2005.- 479 с.

63. Чжу, У.У. Копирование и размещение программных модулей в системе распределенной обработки в реальном времени Текст. / У.У. Чжу, Ц.К. Лян. ТИИЭР, 1997.-Т. 75.-N 5.-С. 23-44.

64. Штенцель, А.В. Принципы формирования мультиверсионного программного комплекса Текст. / А.В. Штенцель, И.А. Капчинский, А.С. Кузнецов // Вестник СибГАУ.- 2008.- № 1(18).- С. 18-23.

65. Штенцель, А.В. Оценка надежности мультиверсионной программной архитектуры систем управления и обработки информации Текст. / А.В. Штенцель, А.В. Новой // Вестник СибГАУ.- 2008.- № 3(20).- С. 73-79.

66. Штенцель, А.В. Архитектурное проектирование мультиверсионного программного обеспечения отказоустойчивых систем управления Текст. / А.В. Штенцель //Вестник НИИ СУВПТ.- 2007.- Вып. 25,- С. 57-71.

67. Штенцель, А.В. Минимизация межмодульного интерфейса в задаче синтеза мультиверсионных модульных систем обработки информации Текст. / А.В. Штенцель, С.В. Тынченко, А.Н. Лайков // Вестник НИИ СУВПТ.- 2007.- Вып. 25,- С. 72-76.

68. Штенцель, А.В. Применение методологии мультиверсий для обеспечения отказоустойчивости программных средств Текст. / А.В. Штенцель, И.А. Капчинский // Вестник НИИ СУВПТ.- 2006.- Вып. 24.- С. 138-141.

69. Штенцель, А.В. Автоматизированная система расчетов за услуги передачи данных Текст. / А.В. Штенцель // Материалы VII-й Всероссийской НПК «Решетневские чтения» (11-12 ноября 2004 г.).- Красноярск: СибГАУ, 2004. -С. 155-157.

70. Штенцель, А.В. Отказоустойчивость СУБД CACHE для биллинговых систем Текст. / А.В. Штенцель // Актуальные проблемы экономики, права и информационных технологий. Сборник научных статей. Красноярск: КФ МЭСИ, 2006.- Часть 3. С. 80-84.

71. Юдин, Д.Б. Математические методы оптимизации устройств и алгоритмов АСУ Текст. / Д.Б. Юдин, А.П. Горяшко, А.С. Немировский. М.: Радио и связь, 1982.-288 с.

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

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

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

75. Antamoshkin, A. System Analysis, Design and Optimization Text. / A. Antamoshkin, and others. Ofset Press, Krasnoyarsk, 1993. - 312 p.

76. Ashrafi, N. Optimization Models for Selection of Programs, Considering Cost & Reliability Text. / N. Ashrafi, O. Berman;IEEE Transaction on reliability. — Vol. 41, No 2, June 1992. Pp. 281-287.

77. Avizienis, A. The N-Version approach to fault-tolerant software Text. / A. Avizienis // IEEE Trans, on Software Engineering. — Vol. SE11. № 12. — December, 1985.-Pp. 1491-1501.

78. Berman, O. Choosing an Optimal Set of Libraries Text. / O. Berman, M. Cutler // IEEE Transaction on reliability. Vol. 45. - No 2, June 1996. - Pp.303-307.

79. Bogomolov, S. Fault Tolerance Software Library Support of Real-Time Embedded Systems Text. / S. Bogomolov, A. Bondarenko, A. Fyodarov // Third European Dependable Computing Conference, EDCC-3. Prague, Czech Republic, September 15-17, 2001.

80. Cherif, A. Improving the Efficiency of Replication for Highly Reliable Systems Text. / A. Cherif, M. Toyoshima, T. Katayama // FastAbstract ISSRE. 2003.

81. David, Ph. Development of a fault tolerant computer system for the Hermes Space Shuttle Text. / Ph. David, C. Guidal // IEEE Trans. 2003. - Pp. 641-648.

82. David W. System reliability confidence intervals for complex systems Text. / W. David // IEEE Trans, on reliability. 1997. - Pp. 487 - 492.

83. Hamlet, D. Foundational Theory of Software Component Reliability Text. / D. Hamlet, D. Mason, D. Wiot // FastAbstract ISSRE. 2000.

84. Hecht, H. Fault tolerant software Text. / H. Hecht // IEEE Trans. Reliability. -Vol. R-28. 1979. - Pp. 227-232.

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

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

87. Karunanithi, N. Prediction of Software Reliability Using Connectionist Text. / N. Karunanithi, D.Whitley, Y.K.Malaiya // IEEE transactions on reliability. Models July 2002.-Vol. 18.-No. 7.

88. Keene, S. Progressive Software Reliability Modeling Text. / S. Keene // FastAbstract ISSRE. 2007.

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

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

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

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

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

94. Lyu, M.R. Handbook of Software Reliability Engineering Text. / M.R. Lyu. -IEEE Computer Society Press and McGraw-Hill Book Company, 1996. 819 p.

95. Lyu, M.R. Software Fault Tolerance Text. / Michael R. Lyu. John Wiley & Sons Ltd, 1996.

96. McFarlan, F.W. Portfolio approach to information systems Text. / Harvard Business Rev. 59. Pp. 142-150.

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

98. Zahedi, F. Software reliability allocation based on structure, utility, price, and cost was / F. Zahedi, N. Ashrafi // IEEE Trans, on Software Engineering. April 1991. - Vol. 17, No. 4. - Pp. 345-356.