В связи с развитием информационных технологий и применением вычислительной техники в промышленной и финансовой сфере крайне важным становится обеспечение высокого уровня надежности, поскольку невыполнение данных требований может привести к существенным убыткам. Повышенные требования по надежности предъявляются и к программному обеспечению вычислительных машин и систем [1].
Одним из актуальных на сегодняшний день подходов к созданию надежного программного обеспечения является применение блоков восстановления [10]. Программное обеспечение, разрабатываемое согласно данному подходу, отличается применением избыточных программных компонент, предназначенных для решения одной и той же задачи. В контексте программного обеспечения схемы блоков восстановления данные программные компоненты называются альтернативами [6, 10].
Фактически блоки восстановления комбинируют основные идеи контрольных точек и рестарта для компонент программного обеспечения таким образом, что различные альтернативы используются только после того, как обнаруживается ошибка.
Контрольные точки определяются во время проектирования программного обеспечения и служат для того, чтобы восстановить состояние ПО, если в альтернативе произойдет сбой или она вернет неверный результат. Оценка результата производится посредством приемочного теста. В том случае, если результат работы альтернативы оказался неверным, происходит откат и выполнение другой альтернативы [8]. Следует отметить, что приемочный тест должен обладать некоторой априорной информацией о предполагаемых результатах, которая позволила бы оценить полученные результаты работы альтернатив.
Естественным развитием подхода с применением блоков восстановления стало его объединение с альтернативным подходом, где функционально эквивалентные программные компоненты исполняются параллельно и результаты их работы оцениваются посредством алгоритмов голосования [4]. Последний получил название мультиверсионного программирования, а программные компоненты – мультиверсии или просто версии [3]. Синтез этих двух подходов привел к появлению блоков восстановления с согласованием, где каждая альтернатива представлена набором версий, т. е. каждая альтернатива является мультиверсионной [6].
Концепция программной избыточности предполагает формирование структуры программного обеспечения, используя набор программных компонент. Это справедливо как для мультиверсионного программного обеспечения, как и программного обеспечения с блоком восстановления, в том числе, с блоком восстановления с согласованием. Возможность модульной декомпозиции каждого из этих классов программного обеспечения позволяет использовать программные компоненты не только собственной разработки, но и созданные сторонними разработчиками и соответствующие требуемой спецификации.
На международном рынке программных продуктов это программные компоненты получили название COTS-компонентов (от англ. commercial off-the-shelf – «коробочный программный продукт») [9].
Реализация в программных компонентах различных методов и алгоритмов, предназначенных для решения одной и той же задачи, позволяет избежать возникновения идентичных ошибок в этих компонентах и тем самым обеспечить отказоустойчивое исполнение всего программного обеспечения. Компоненты могут быть представлены в виде библиотек, часть из них может быть разработана самостоятельно, а часть – различными поставщиками. Однако в некоторых случаях программные компоненты могут быть несовместимы из-за проблем интерфейса, спецификации или реализации [5]. В связи с этим возникает необходимость учета совместимости различных программных компонент.
В данной статье предложена модель оптимизации, предназначенная для решения задачи формировании высоконадежного программного обеспечения с учетом совместимости входящих в его состав программных компонент, в первую очередь, COTS-компонентов. Предлагаемая модель является развитием модели оптимизации, предложенной авторами в [2].
Показатели надежности и стоимости программных компонент
Будем рассматривать программную систему, реализуемую согласно схеме блоков восстановления с согласованием. Положим, что данная программная система состоит из n модулей и выполняет L функций. При этом для выполнения функций используются различные (пересекающиеся) множества модулей системы. Обозначим частоту выполнения l-й функции как fl, а количество модулей, необходимых для ее выполнения, как sl, sl ∈ S, где 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-компонент. Однако при их интеграции в состав программной системы необходимо учитывать совместимость программных компонент.
В работе представлена модель оптимизации, предназначенная для решения обеих указанных проблем при формировании программной системы. Предложенный математический аппарат обладает большим потенциалом к использованию при создании высоконадежных программных систем.
Рецензенты:
Бронов С. А., д.т.н., профессор, руководитель научно-учебной лаборатории систем автоматизированного проектирования кафедры систем искусственного интеллекта Сибирского федерального университета, г. Красноярск.
Носков М. В., д.ф.-м.н., профессор, заместитель директора по научной работе Института космических и информационных технологий Сибирского федерального университета, г. Красноярск.
Библиографическая ссылка
Царев Р.Ю., Завьялова О.И., Черниговский А.С. УЧЕТ СОВМЕСТИМОСТИ COTS-КОМПОНЕНТОВ ПРИ ФОРМИРОВАНИИ ИЗБЫТОЧНЫХ ПРОГРАММНЫХ СИСТЕМ // Современные проблемы науки и образования. – 2015. – № 1-2. ;URL: https://science-education.ru/ru/article/view?id=19746 (дата обращения: 06.12.2024).