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

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

В работе [2] в качестве примера рассмотрена большая архитектура комплексной системы управления предприятием (КСУП), соответствующая классу программных систем, работающих в реальном масштабе времени и обладающих разветвленным телекоммуникационным комплексом, в том числе и программным. В данной ПС выделены следующие архитектурные уровни:

• -    процессы;

• -    функции;

• -    примитивы;

• -    данные;

• -    структуры;

• -    сообщения.

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

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

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

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

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

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

Анализ результатов при сравнении вариантов архитектур. С помощью диалоговой системы оценки архитектуры проведем сравнительный анализ двух вариантов архитектуры телекоммуникационного программного обеспечения: А (табл. 1) и В (табл. 2).

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

Что касается среднего времени появления сбоя, то оно возрастает с увеличением числа компонентов (рис. 2). Так, вариант архитектуры А содержит 829 компонентов и среднее время появления сбоя равно 52 926 463 с, а вариант В состоит из 646 компонентов и среднее время появления сбоя для него равно 19 315 479 с. Среднее время появления сбоя зависит от времени использования компонентов. Поэтому меньшее среднее появления сбоя не обязательно отражает более низкую надежность большой архитектуры передачи телекоммуникационных данных в реальном масштабе времени.

А                  В

Рис. 1. Диаграмма среднего времени простоя системы для двух вариантов архитектуры ПО

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

Значения параметров варианта архитектуры А

Таблица 1

Уровни архитектуры	ЧисХо компонентов	Вероятность сбоя компонента	Условная вероятность сбоя на разных уровнях	Время доступа, анаХиза, восстановления	Время использования компонента
Процессы	7	0,1	0,0	5	100
Функции	399	0,2	0,8	7	80
Примитивы	138	0,05	0,4	12	90
Данные	202	0,12	0,5	12	25
Структуры	49	0,05	0,2	11	40
Сообщения	34	0,05	0,1	14	60

Значения параметров варианта архитектуры В

Таблица 2

Уровни архитектуры	ЧисХо компонентов	Вероятность сбоя компонента	УсХовная вероятность сбоя на разных уровнях	Время доступа, анаХиза, восстановХения	Время испоХьзования компонента
Процессы	7	0,1	0,0	5	100
Функции	215	0,35	0,9	12	90
Примитивы	63	0,1	0,5	18	110
Данные	278	0,1	0,4	10	20
Структуры	49	0,05	0,2	11	40
Сообщения	34	0,05	0,1	14	60

нирования системы, вариант архитектуры А оказывается более надежным. Вероятность того, что в момент времени t (при t ^ ^ ) система А будет функционировать нормально, составляет 0,943, а для варианта В значение вероятности будет 0,876.

А                В

Рис. 2. Диаграмма среднего времени появления сбоя в системе для двух вариантов архитектуры ПО

А                  В

Рис. 3. Диаграмма коэффициента готовности системы для двух вариантов архитектуры ПО

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

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

Диалоговая система экспресс-анализа архитектурной надежности ПС [5] представляет возможности для более тонкого анализа архитектуры по графикам, показывающим изменение характеристик надежности архитектуры в зависимости от изменения числа компонентов на одном из уровней архитектуры (рис. 5-7).

А                  В

Рис. 4. Диаграмма средней стоимости разработки системы для двух вариантов архитектуры ПО

Рис. 5. График изменения времени простоя в зависимости от изменения количества функций и данных

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

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

Рис. 7. График изменения готовности системы в зависимости от изменения количества функций и данных

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

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