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

Министерство образования и науки Российской Федерации 
Сибирский федеральный университет 
 
 
 
 
 
 
 
 
А.С. Кузнецов, С.В. Ченцов, Р.Ю. Царев 
 
 
 
МНОГОЭТАПНЫЙ  АНАЛИЗ  
АРХИТЕКТУРНОЙ  НАДЕЖНОСТИ  
И  СИНТЕЗ  ОТКАЗОУСТОЙЧИВОГО  
ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ  
СЛОЖНЫХ  СИСТЕМ 
 
 
 
Монография 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Красноярск 
СФУ 
2013 

УДК 004.052.3 
ББК 32.973.2-18 
К891 
 
 
Рецензенты: 
А.А. Ступина, доктор технических наук, профессор кафедры  
«Системный анализ и исследование операций» СибГАУ  
им. М.Ф. Решетнева; 
А.К. Шлепкин, доктор физико-математических наук, профессор,  
зав. кафедрой прикладной математики и информационной безопасности 
КрасГАУ 
 
Кузнецов, А.С. 
К891  
Многоэтапный анализ архитектурной надежности и синтез отказоустойчивого программного обеспечения сложных систем: монография / А.С. Кузнецов, С.В. Ченцов, Р.Ю. Царев. – Красноярск: 
Сиб. федер. ун-т, 2013. – 143 c. 
 
 
ISBN 978-5-7638-2730-9 
 
В монографии предложен комплекс математических моделей и алгоритмов анализа надежности программного обеспечения сложных систем с учетом их многоуровневости и распределенности архитектуры. Представлена система построения трансляторов мультисинтаксических языков программирования мультиверсионного программного обеспечения сложных систем. 
Предназначена специалистам, работающим в области проектирования 
и разработки программного обеспечения, а также аспирантам и докторантам. Материалы монографии рекомендуются к использованию при проведении лекционных и практических занятий у магистрантов укрупненных 
групп 220000 «Автоматика и управление», 230000 «Информатика и вычислительная техника». 
 
 
 
УДК 004.052.3 
ББК 32.973.2-18 
 
 
 
 
ISBN 978-5-7638-2730-9 
© Сибирский федеральный университет, 2013 

ОГЛАВЛЕНИЕ 

ВВЕДЕНИЕ .......................................................................................................... 6 

1. ПРОБЛЕМЫ АНАЛИЗА АРХИТЕКТУРНОЙ НАДЕЖНОСТИ 
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СЛОЖНЫХ СИСТЕМ ....................... 8 

1.1. Повышение архитектурной надежности программного 
обеспечения ...................................................................................................... 9 
1.1.1. Терминологические проблемы анализа архитектурной 
надежности .................................................................................................. 10 
1.1.2. Адекватность программных архитектур условиям и 
требованиям работоспособности систем ................................................. 14 
1.1.3. Системные методы повышения архитектурной надежности ...... 17 

1.2. Архитектура программного обеспечения сложных систем 
управления и обработки информации ......................................................... 19 
1.2.1. Фазы разработки программного обеспечения сложных 
систем управления и обработки информации ......................................... 19 
1.2.2. Анализ фазы архитектурного дизайна ........................................... 20 
1.2.3. Архитектурная спецификация критических систем ..................... 26 

2. МОДЕЛЬНО-АЛГОРИТМИЧЕСКИЙ АППАРАТ АНАЛИЗА 
АРХИТЕКТУРНОЙ НАДЕЖНОСТИ ПРОГРАММНОГО 
ОБЕСПЕЧЕНИЯ СЛОЖНЫХ СИСТЕМ ........................................................ 33 

2.1. Аналитическое определение показателей архитектурной 
надежности программного обеспечения ..................................................... 33 

2.2. Модели анализа архитектурной надежности программного 
обеспечения сложных систем ....................................................................... 41 
2.2.1. Универсальная модель анализа архитектурной надежности 
программного обеспечения сложных систем .......................................... 41 
2.2.2. Анализ надежности программного обеспечения сложных 
систем на фазе кодирования ...................................................................... 45 
2.2.3. Анализ надежности программного обеспечения сложных 
систем на фазе тестирования системы ..................................................... 46 
2.2.4. Операционные профили тестирования компонент ....................... 48 
2.2.5. Модель оценки надежности объектно-ориентированного 
программного обеспечения ....................................................................... 52 
2.2.6. Модель оценки транзакционной надежности ПО сложных 
систем .......................................................................................................... 56 
2.2.7. Модификация универсальной модели для анализа 
архитектурной надежности систем с программной архитектурой 
«клиент-сервер» .......................................................................................... 59 

3. ПРОБЛЕМЫ СОЗДАНИЯ МУЛЬТИВЕРСИОННОГО 
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ............................................................. 67 

3.1. Методология мультиверсионного программирования как 
средство повышения надежности программного обеспечения ................ 67 

3.2. Критические замечания относительно современного состояния 
методологии мультиверсионного программирования ............................... 72 

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

4.1. Неформальное определение мультисинтаксического языка 
(МСЯ) .............................................................................................................. 78 

4.2. Обзор современных мультисинтаксических средств .......................... 79 
4.2.1. Использование ассемблерных вставок при 
программировании на языках высокого уровня ..................................... 79 
4.2.2. Скриптовые языки для создания динамических Web-страниц ... 84 
4.2.3. Встраивание языков запросов данных в языки 
программирования ..................................................................................... 87 
4.2.4. Концепция Domain Specific Languages .......................................... 90 
4.2.5. Синтаксис включений в программы на одном языке кода на 
другом языке ............................................................................................... 92 

4.3. Формальное описание мультисинтаксического языка ....................... 94 

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

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

5.2. Формирование таблиц синтаксического анализа 
мультисинтаксических языков программирования ................................. 105 

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

5.4. Семантический анализ мультисинтаксических языков 
программирования и этап синтеза компилятора МСЯ ............................ 114 

6. АВТОМАТИЗАЦИЯ РАЗРАБОТКИ ТРАНСЛЯТОРОВ 
МУЛЬТИСИНТАКСИЧЕСКИХ ЯЗЫКОВ ПРОГРАММИРОВАНИЯ 
МУЛЬТИВЕРСИОННЫХ ПРОГРАММНЫХ СИСТЕМ ........................... 117 

6.1. Система построения трансляторов мультисинтаксических 
языков программирования мультиверсионных систем MuYacc ............ 117 

6.2. Входная спецификация системы MuYacc .......................................... 119 

6.3. Применение трансляторов МСЯ при разработке 
мультиверсионного ПО ............................................................................... 123 
6.3.1. Проект IntegrAsm – компилятор языка C, обеспечивающий 
вставки ассемблерного кода .................................................................... 123 
6.3.2. Проект MulQuery – компилятор языка C, обеспечивающий 
включение кода на языках запросов к СУБД ........................................ 125 
6.3.3. Использование трансляторов MulQuery и IntegrAsm для 
разработки мультиверсионного ПО ....................................................... 127 

ЗАКЛЮЧЕНИЕ ............................................................................................... 130 

БИБЛИОГРАФИЧЕСКИЙ  СПИСОК .......................................................... 132 

 

ВВЕДЕНИЕ 

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

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

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

Архитектура программного обеспечения, как правило, определяется концепцией архитектурного проектирования [25; 39]. На рис. 1.1 представлены этапы проектирования сложной программной системы. 

Архитектурное 
проектирование 
 

Обобщенные 
спецификации 
 

Проектирование 
интерфейсов 
 

Компонентное 
проектирование 
 

Проектирование 
структур данных
 

Проектирование 
алгоритмов 

 
Рис. 1.1. Этапы проектирования программной системы 

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

Архитектурное проектирование состоит из следующих этапов: 
структурирование системы – формирование совокупности относительно независимых систем; 
моделирование управления – управление взаимоотношениями 
между частями системы; 

модульная декомпозиция – подсистемы разделяются на модули. 
Результатом архитектурного проектирования является документ, отображающий архитектуру программной системы (ПС) [64]. 
Существуют следующие архитектурные модели: 
статическая структурная модель ПС – подсистемы разрабатываются независимо; 
динамическая модель процессов – организация процессов во 
время работы системы; 
интерфейсная модель – определяются сервисы, предоставляемые каждой подсистемой через общий интерфейс; 
модели отношений – рассматриваются взаимоотношения между 
частями системы. 
В зависимости от требований выбираются различные атрибуты 
модели: 
1. Производительность – за все критические ситуации отвечает минимальное количество подсистем с минимальным взаимодействием между собой. Лучше использовать крупномодульные компоненты ПС. 
2. Защищенность – многоуровневая структура, в которой критические системные элементы защищены на внутренних уровнях. 
3. Безопасность – максимально снижается количество подсистем, влияющих на безопасность. 
4. Надежность – включение избыточных компонентов, которые 
можно заменять и обновлять без прерывания работы ПС. 
5. Удобство сопровождения – применяются мелкие структурные 
компоненты, которые можно легко изменять. Программы, создающие 
данные, отделены от тех компонент, которые эти данные используют. 

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

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

вость и коэффициент готовности не менее 99,999 % (т. е. не более 5 
минут простоев в год).  
Надежность программного обеспечения сложных систем управления и обработки информации обходится очень недешево, и существующие сегодня высоконадежные архитектурные решения базируются либо на операционных системах собственной разработки, либо на 
одном из клонов Unix [50]. Поставщики аппаратных платформ обеспечивают высокую надежность, заставляя платить за избыточность 
аппаратных и программных средств. Еще больше возрастает эта плата, когда необходимо решать программными средствами не нашедшие своего аппаратурного решения проблемы, возникающие в ходе 
неизбежных упущений в процессе разработки. Проанализируем проблему повышения архитектурной надежности программного обеспечения и рассматриваются современные архитектурные решения, 
обеспечивающие требуемую отказоустойчивость и доступность ресурсов программного обеспечения сложных систем управления и обработки информации.  
В работах [1; 62; 76] отмечается, что до недавнего времени надёжными системами считались только сложные закрытые и дорогие корпоративные системы, предполагающие частое дублирование узлов. 
С появлением открытых компьютерных сетей появилась возможность 
строить надежные системы из универсальных архитектурных компонентов, которые можно заменить в случае аварии без нарушения работоспособности конфигурации в рамках корпоративной структуры.  

1.1.1. Терминологические проблемы анализа  
архитектурной надежности  
В результате анализа многих работ из области исследования надежности программных систем был выявлен широкий ряд проблем, 
основной причиной которого является отсутствие единого стандарта в 
области обеспечения надежности и отказоустойчивого ПО. Данной 
проблеме посвящены труды многих зарубежных и отечественных исследователей, таких как Авиженис [88], Майерс, Боэм, Ашфари, Луи, 
Соммервилл [65], Дилон, Берман, Липаев [50], Черкесов, Орлов [56], 
Ковалев [33–42] и др. 
Среди множества различных институтов и организаций (ISREE, 
IEEE, NASA), независимых исследователей проблем надежности ПО 
не существует единой терминологии, единых параметров и показателей надежности, методологии разработки отказоустойчивого ПО. 

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

Проблемы терминологии 
Ошибка, сбой и дефект в программном обеспечении. Подразумевается, что программное обеспечение содержит ошибку, если [63]:  
1. Поведение ПО не соответствует спецификациям. 
Недостатки: неявно предполагается, что спецификации корректны. Подготовка спецификаций – один из основных источников ошибок. Если поведение программного продукта не соответствует его 
спецификациям, ошибка, вероятно, имеется. Однако, если система ведёт себя в соответствии со спецификациями, мы не можем утверждать, что она не содержит ошибок. 
2. Поведение ПО не соответствует спецификациям при использовании в установленных при разработке пределах. 
Недостатки: если система случайно используется в непредусмотренной ситуации, её поведение должно оставаться разумным. Если это не так, она содержит ошибку. 
3. Программное обеспечение ведёт себя не в соответствии с 
официальной документацией и поставленными пользователем спецификациями. 
Недостатки: ошибки могут содержаться и в программе, и в спецификациях, или в руководстве описана только ожидаемая и планируемая работа с программной системой. 
4. Система не способна действовать в соответствии с исходной 
спецификацией и перечнем требований пользователя. 
Это утверждение тоже не лишено недостатков, поскольку письменные требования пользователя редко детализированы настолько, 
чтобы описывать желаемое поведение программного обеспечения при 
всех мыслимых обстоятельствах. 
Таким образом, в качестве окончательного определения можно 
принять следующее: в программном обеспечении имеется ошибка, 
если оно не выполняет того, что пользователю разумно от него ожидать. Отказ программного обеспечения – это проявление ошибки в 
нём. 
Термины «ошибка», «сбой» и «дефект» часто используются без 
разделения по смыслу. Ошибка в ПО – это действия программиста, 

которые приводят к дефектам в ПО. Дефект в ПО влечет за собой 
сбои во время исполнения кода [81]. Сбой – отклонение выхода системы от желаемого при выполнении кода. 
Дефект влечет за собой сбой только тогда, когда выполняется 
код, содержащий ошибку, и распространяется до выхода системы. 
Уровень тестируемости дефекта определяется как вероятность обнаружения сбоя на случайно выбранном выходе.  
Вводится понятие уровня сбоя: катастрофичный, высокий, средний, низкий, незначительный. Определения этих уровней меняются от 
системы к системе. 
Простой, или «зависание» – особый вид сбоя, зависящий как от 
сбоя в аппаратной части, так и в программной части системы, или же 
от некорректных действий пользователя. 
Надежность программного обеспечения. Организация IEEE определяет надежность как «способность системы или компонента выполнять требуемые функции при определенных условиях за определенный период времени». Это определение дал Авиженис, и оно считается классическим [76]. 
Основной недостаток такого определения – это то, что в нем не 
учтено различие между ошибками разных типов. 
Фактически надежность ПО определяется как вероятность 
функционирования ПО без ошибок за определенный период времени 
в определенной операционной системе.  
Для большинства разработчиков надежность определяется как 
корректность ПО, т. е. количество ошибок, которое надо исправить во 
время теста. 
Существует и другое определение надежности – операционная 
(транзакционная) надежность [10]. Операционная надежность – это 
способность системы или компонента выполнять требуемые функции 
при определенных условиях в рамках транзакции. Широко используется в системах обработки и хранения информации в базах данных. 
Будем использовать понятие классической и транзакционной 
надежности, в зависимости от места применения и используемой модели надежности. 
В определениях параметров из области надежности ПО существуют и другие определения, имеющие немаловажное значение. Одним из таких параметров является время. 
Время можно разделить на два типа: календарное время и процессорное время. Процессорное время преобразуется в календарное 

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

Проблемы выбора параметров 
Среди множества работ из области оценки параметров надежности ПО можно выявить несколько десятков подходов к измерению 
или методам оценки тех или иных количественных показателей, характеризующих надежность [21]. Показатель надежности – это количественная характеристика одного или нескольких свойств, определяющих надежность системы. В основе большинства показателей надежности лежат оценки наработки системы, т. е. продолжительности 
или объема работы, выполненной системой. Показатель надежности, 
относящийся к одному из свойств надежности, называется единичным. Комплексный показатель надежности характеризует несколько 
свойств, определяющих надежность системы. Наименования основных показателей надежности систем и их определения можно найти в 
ГОСТ 27.002–80 «Надежность в технике. Термины и определения». 
Надежность – имеет обозначение R (reliability) измеряется как 
вероятность невозникновения сбоя. Надежность используется практически во всех моделях как основной показатель. 
Среднее время появления сбоя имеет аббревиатуру MTTF (Mean 
Time To Failure); измеряет время между двумя последовательными 
сбоями. 
Интенсивность сбоев – величина, обратная MTTF, определяет 
количество сбоев в единицу времени. 
Среднее время простоя (TR) – величина, определяющая время, 
затрачиваемое на выявление, устранение и восстановление системы 
или компонента системы после сбоя. 
Коэффициент готовности системы – S – определяется как отношение разности среднего времени появления сбоя и среднего времени 
простоя системы к среднему времени появления сбоя. 
Количество оставшихся ошибок в коде ПО используется при 
разработке ПО. Показывает количество ошибок в коде на каждую тысячу строк исходного кода.