Scientific journal
Modern problems of science and education
ISSN 2070-7428
"Перечень" ВАК
ИФ РИНЦ = 1,006

AN ACCOUNT OF COTS COMPONENTS COMPATIBILITY WHEN DESIGN A REDUNDANT SOFTWARE SYSTEM

Tsarev R.Yu. 1 Zavyalova O.I. 1 Chernigovskiy A.S. 1
1 Siberian Federal University
Construction of large software systems is forcing to use software components both of home design and provided by third-party developers and suppliers at the market of software products. The use of the latter is especially important for the software systems with high reliability requirements where the introduction of software redundancy is chosen as a tool for reliability improving. The application of so-called commercial off-the-shelf or COTS components as part of a software system requires consideration of components compatibility. The article presents an optimization model for synthesis a highly reliable software system based on consensus recovery block scheme. The optimization model takes into account of COTS components compatibility.
reliability
redundancy
optimization
COTS

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

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

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

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

Естественным развитием подхода с применением блоков восстановления стало его объединение с альтернативным подходом, где функционально эквивалентные программные компоненты исполняются параллельно и результаты их работы оцениваются посредством алгоритмов голосования [4]. Последний получил название мультиверсионного программирования, а программные компоненты – мультиверсии или просто версии [3]. Синтез этих двух подходов привел к появлению блоков восстановления с согласованием, где каждая альтернатива представлена набором версий, т. е. каждая альтернатива является мультиверсионной [6].

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

На международном рынке программных продуктов это программные компоненты получили название COTS-компонентов (от англ. commercial off-the-shelf – «коробочный программный продукт») [9].

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

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

Показатели надежности и стоимости программных компонент

Будем рассматривать программную систему, реализуемую согласно схеме блоков восстановления с согласованием. Положим, что данная программная система состоит из n модулей и выполняет L функций. При этом для выполнения функций используются различные (пересекающиеся) множества модулей системы. Обозначим частоту выполнения l-й функции как fl, а количество модулей, необходимых для ее выполнения, как sl, slS, где S представляет собой архитектуру программной системы. Поскольку программная система создается согласно схеме блоков восстановления с согласованием, то для i-го модуля, i ∈ 1, ..., n, доступны mi альтернатив, тогда для j-й альтернативы i-го модуля, i ∈ 1, ..., n, j ∈ 1, ..., mi, доступны Vij версий.

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

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

Отдельная альтернатива может быть, либо приобретена (COTS-компонент), либо разработана самостоятельно. Обозначим эту взаимосвязь следующим образом:

где xijk – булева переменная, равная 1, если выбранная k-я версия j-й альтернативы i-го модуля, создана сторонними разработчиками, 0 – если данная версия разработана самостоятельно; yij – булева переменная, равная 1, если j-я альтернатива i-го модуля разрабатывается собственными силами, 0 – в противном случае.

При этом обеспечивается избыточность компонент программной системы на основе COTS-компонентов и компонентов собственной разработки:

где zij – булева переменная, равная 1, если j-я альтернатива присутствует в i-м модуле, 0 – в противном случае.

Определение вероятности отказа j-й альтернативы i-го модуля, разработанной собственными силами, может быть выполнено на основе числа успешных тестов [7]:

где Nij+ – количество успешно пройденных тестов; Nij – общее количество тестовых испытаний; qij – вероятность того, что единичное тестирование j-й альтернативы i-го модуля будет неуспешным.

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

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

Надежность j-й альтернативы i-го модуля программной системы можно представить в виде:

где Rijk - вероятность безотказной работы k-й версии j-й альтернативы i-го модуля (вероятность безотказной работы COTS-компонента).

Стоимость разработки j-й альтернативы i-го модуля равна величине cij(tij + τijNij), где cij - стоимость единичной разработки j-й альтернативы i-го модуля, tij - расчетное время разработки j-й альтернативы i-го модуля, τij - среднее время, требуемое на выполнение тестового сценария для j-й альтернативы i-го модуля.

При выборе покупке готовых COTS-компонентов срок поставки k-й версии j-й альтернативы i-го модуля, обозначаемый как dijk, указывается поставщиком. Время же собственной разработки компонентов рассчитывается разработчиками программной системы по формуле tij + τijNij.

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

где T – максимальный срок разработки программной системы.

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

Модель формирования оптимальной программной системы по схеме блока восстановления с согласованием, предложенная авторами в [2], предполагала, что альтернативы, представленные COTS-компонентами, одного модуля совместимы с альтернативами, также являющиеся COTS-компонентами, других модулей. Однако в некоторых случаях альтернативы модулей могут быть несовместимы с альтернативами других модулей [5].

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

которое означает, что если для модуля a выбрана альтернатива b, тогда для модуля v должна быть выбрана альтернатива ut, t = 1, …, z. При этом считается, что, если две альтернативы совместимы, то их версии тоже совместимы.

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

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

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

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

при условиях:

и

и

и

где R - надежность (вероятность безотказной работы) программной системы; Ri - надежность i-го модуля; Rij - надежность j-й альтернативы i-го модуля i; C - общие расходы на разработку и закупку компонент программной системы; cijk - стоимость k-й версии j-й альтернативы i-го модуля; Aij - событие, соответствующее отклонению результата j-й альтернативы i-го модуля; Bij - событие, соответствующее принятию корректного результата j-й альтернативы i-го модуля; p1 - вероятность того, что следующая альтернатива не будет вызвана, несмотря на отказ текущей альтернативы; p2 - вероятность неверной оценки корректного результата; p3 - вероятность принятия неверного результата за корректный.

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

Заключение

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

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

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

Рецензенты:

Бронов С. А., д.т.н., профессор, руководитель научно-учебной лаборатории систем автоматизированного проектирования кафедры систем искусственного интеллекта Сибирского федерального университета, г. Красноярск.

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