CC BY
26
УДК 004.4'22
МЕТОД СИНТЕЗА СТРУКТУРЫ МНОГОКОМПОНЕНТНЫХ ПРОГРАММНЫХ СИСТЕМ НА БАЗЕ МНОГОАГЕНТНОГО И ОНТОЛОГИЧЕСКОГО ПОДХОДОВ
И.И. Семенова
В статье предлагается метод синтеза структуры многокомпонентной программной системы на базе много-агентного и онтологического подходов. Приведен пример работы метода для поиска вариантов структур систем управления моделями
Ключевые слова: многокомпонентные программные системы, синтез структуры системы, поиск решения, задача комплектации
Введение
В процессе синтеза структур современных многокомпонентных программных систем разработчики сталкиваются с рядом проблем: наличие большое количества программных решений, которые могут быть использованы в качестве компонентов проектируемой системы; проблемы согласования их в новом программном решении, наличие у заказчика некоторых решений и т.п. По сути, данный процесс схож с задачами комплектации для различных видов систем, где сталкиваются с теми же проблемами: выбор одного компонента из нескольких, отсутствие компонента под предъявляемые требования, проблемы интеграции и организации готовых компонент в новой системе и т.д.
Для синтеза структур многокомпонентных программных систем и автоматизации проектирования используются различные подходы, описанные в [1, 4, 6, 7] и пр.
В данной статье предлагается для решения задачи синтеза использовать комбинацию мно-гоагентного и онтологического подходов. Преимущество видится в открытости как библиотеки онтологии, которая сможет пополняться и модифицироваться под развивающийся рынок программных решений, так и в возможности оперативного создания новых агентов на базе концептов сформированной онтологии, которые сразу будут включаться в процесс поиска структур вновь разрабатываемой многокомпонентной программной системы под требования заказчика, при сохранении уже ранее созданных агентов.
Постановка задачи
Используем в качестве основы общую постановку задачи комплектования из [3], модифицируя ее применительно к описываемому методу.
Пусть множество X = {Х1, X2,..., Хп}
представляет собой набор программных решений, существующих на рынке. Каждый элемент множества принадлежит одному или нескольким классам множества С = {С1,С2,...,Ск} , которое представляет собой типы (виды по назначению) программных решений, где к << п . В состав синтезируемой структуры многокомпонентного комплекса должно входить программное решение из каждого класса множества С, т.е. {С1,С2,...,Ст}, т < к, таким образом
{Х1,х^2,...,х^е С1,...,{хт,хт,...,хт}е Ст.
Каждому элементу множества С ставится в соответствие совокупность атрибутов Сс ®< -1с,-2с,...—рс > , причем количество атрибутов р для каждого элемента Сс может быть различным, но при этом р > 2. Соответственно для каждого элемента из множества X определяются значения атрибутов по С. Обязательно наличие у всех элементов множества С атрибутов -1с -
цена, -2с - наличие у заказчика описываемого программного решения.
Существует множество программных решений У = {^,У2,...,Ур} , используемых на
предприятии - заказчике многокомпонентной программной системы, так что У является подмножеством X.
Таким образом, нужно найти такую комбинацию элементов из множества X, которые совместимы в работе по указанным им атрибу-
Семенова Ирина Ивановна - СибАДИ, канд. техн. наук, доцент, e-mail: osobaii@gmail.com
там проектируемой многокомпонентной системе, при этом
m m
Е F1q ® min; S F2q ® max.
11
Описание метода на примере синтеза структуры системы управления моделями
Для описания работы метода на примере рассмотрим структурно-функциональную схему, представленную на рисунке 1, экспертного моделирующего комплекса, разрабатываемого для решения задач планирования многокомпонентных смесей в условиях неопределенности. Как видно из схемы в состав комплекса входят несколько систем, в частности, система управления моделями (СУМ), которая в свою очередь может включать готовые программные решения в качестве своих компонентов. Структура СУМ согласно [15] представлена на рисунке 2.
При проектировании СУМ может оказаться, что у заказчика есть готовые программные решения, которые могут выполнять отдельные задачи в СУМ, например, у него есть среда/ система исполнения моделей (в качестве примера можно рассмотреть AnyLogic, MatLab, MathCad и пр.), Solver - решающие системы или Решатели, реализующие отдельные решения или методы оптимизации (примерами могут служить BendX Stochastic Solver, LINDO API, OML, Risk Solver Platform и др.). Тогда возникает необходимость интегрировать готовые решения с проектируемой СУМ.
В качестве конструктора онтологий было выбрано инструментальное средство Magenta Ontology Constructor. В конструкторе онтологий возможно создание онтологий двух типов: описательная онтология (Descriptive ontology) и онтология мира заказов и ресурсов (Virtual World ontology). Descriptive ontology предназначена для описания предметной области и оперирует такими понятиями, как объект, атрибут, скрипт и т.п. Virtual World ontology описывает мир в терминах заказов, ресурсов и отношений матчинга (соответствия, сопоставления) между ними [2, 14].
Для демонстрации работы метода были созданы концепты «объект» в разрабатываемой онтологии проекта СУМ, а именно: компонента Система исполнения моделей (СИМ); компонента Решатель (Solver); компонента СУБД (DataBase) и собственно компонента СУМ (Proj ect_MBMS).
Для каждого концепта «объект» был определен список атрибутов, который соответствует разработанным требованиям в проекте управ-
ления требованиями, который был выполнен на базе продукта Система управления требованиями Requirements 0.9.
Для большинства атрибутов можно задать значение по умолчанию, которое будет устанавливаться при создании атрибутов в сцене в процессе синтеза структуры проекта.
Фрагмент созданных концептов «атрибуты» представлены средствами конструктора онтологий на рисунке 3 в виде онтологической сети. Для удобства организации взаимодействия между агентами, атрибуты упорядочены по группам, отражающим функциональную принадлежность требований (требования к экспорту, импорту, реализуемым функциям и т.д.).
На рисунке 4 отражен фрагмент реализованных связей между концептами «объекты» и «атрибуты». Видно, что даже во фрагменте представлен большой объем связей и ограничений, которые необходимо учитывать при принятии решения о выборе варианта структуры, что говорит о сложности задачи проверки совместимости компонент при «ручном» выборе структуры многокомпонентной программной системы.
Следующим этапом формирования библиотеки онтологии является создание онтологии мира заказов и ресурсов, а также концепта «агент заказа» и концептов «агент ресурса».
В рассматриваемом примере были созданы концепт «агент заказа» для объекта Project_MBMS и концепты «агент ресурса» для каждого из объектов: СИМ, Solver, DataBase.
Следующим этапом разработки онтологии является создание виртуальных отношений (матчинг). В онтологии допускаются отношения двух типов: симметричные отношения (symmetric); отношения типа субъект-объект (subject-object relations). Отличие их друг от друга состоит в том, что в симметричном отношении все участники имеют равные права, а в отношении «субъект-объект» участники выступают в разных ролях. Отношение матчинга является служебным классом отношений в виртуальном мире и связывает между собой концепты заказов/ресурсов. Отношение матчинга показывает возможность матчинга между агентами, концепты которых в онтологии связаны данным отношением. Иными словами, матчинг возможен, но он не обязательно состоится: агенты могут не договориться по разным причинам (есть более выгодное предложение, данное предложение не устраивает партнера/агента и т.д.) [5, 8, 9, 10].
Были установлены отношения матчинга между концептами агента заказа Project_MBMS
Demand и агентами ресурсов СИМ Resource, Solver Resource, DataBase Resource согласно предложенной сети «потребности-
возможности» (ПВ-сеть), представленной на рисунке 5.
После создания отношений между агентами ресурсов и заказов, необходимо для каждого из агентов задать правила, по которым будет осуществляться их взаимодействие, которые были определены на этапе постановки задачи. Данные правила задаются при помощи знаковых условий между соответствующими концептами «атрибуты», определенными для концептов «объекты».
Кроме условий (правил) взаимодействия агентов, возможно также, создание условий принятия решений. Условия принятия решений предназначены для работы машины принятия решений и позволяют агенту выбрать одно из множества возможных предложений (матчин-гов) от других партнеров. Для условия принятия решения необходимо определить атрибут условия, направление оптимизации (максимум/минимум) и весовой коэффициент, определяющий «значимость» данного условия. В разрабатываемой онтологии такими атрибутами являются стоимость программного обеспечения, выступающего в качестве компонента разрабатываемой структуры, который необходимо минимизировать, а также наличие уже купленного компонента у заказчика.
Следующим этапом является создание онтологической сцены сети «потребности-возможности» (ПВ-сети) на базе комплекса Magenta. Основой работы онтологической сцены является описанная ранее онтология для компонентов структуры СУМ.
В онтологической сцене концепты «объекты» выступают в качестве агентов, один и тот же концепт может быть представлен в онтологической сцене любым количеством агентов, имеющих необходимые атрибуты (требования). Для того чтобы агенты могли отражать разные программные реализации одних и тех же компонентов структуры СУМ, атрибуты концептов «объекты», а, следовательно, и концепты «агенты» имеют целочисленный тип атрибутов с нулевым значением по умолчанию, за исключением атрибутов описательного характера (название ПО, стоимость ПО и т.д.) со строковым типом. Таким образом, для того чтобы отразить поддержку (наличие) того или иного требования конкретной программной реализацией компонента структуры, достаточно у атрибута, соответствующего данному требованию, изме-
нить нулевое значение на значение равное единице.
Для проекта готового решения, который также представлен в виде концепта «агент» в онтологической сцене, значащим атрибутам, соответствующим предъявляемым разработчиком требованиям к проектируемой многокомпонентной системе, необходимо присвоить значение равное единице.
Результат многоагентного моделирования, представленный на рисунке 6, в котором выбор осуществлялся среди 8 систем исполнения моделей, 8 решателей и 6 СУБД, на основе разработанной онтологии подтвердил ожидаемое проектное решение по заданным требованиям. Естественно, данный метод целесообразно использовать при большом количестве альтернатив. Так в результате анализа рынка предложений по программным системам было найдено для систем исполнения моделей 54 решения, для решателей - 55 описанных решений [11, 12, 13], для СУБД порядок описанных решений аналогичный.
Заключение
Таким образом, разработчику системы для получения готового проектного решения, необходимо лишь задать значения атрибутов в соответствии с предъявляемыми требованиями к проектируемой системе. Разработанный инструмент, отличается гибкостью к расширению требований к проектируемой системе, позволяет избавить разработчика от поиска оптимальной структуры для заказчика «вручную», а также позволяет автоматически проверять возможность совместного функционирования компонентов в единой структуре системы. По мере появления новых программных решений на рынке, которые могут выступать в качестве одного из компонентов проектируемого класса систем, достаточно в сцене добавить агент на базе соответствующего концепта «объект» и указать его значения атрибутов. При следующем запуске процесса моделирования вновь добавленный агент автоматически включится в работу.
Метод синтеза структуры программного комплекса под поставленную задачу на основе многоагентного подхода, использующего в качестве базы знаний онтологию, позволит получать обоснованную оценку вариантов модульной сборки разрабатываемого программного комплекса и может использоваться на практике организациями-разработчиками ПО в качестве средства поддержки принятия решений.
Подобный подход и метод синтеза структуры применим для различных классов много-
компонентных программных систем при создании соответствующей онтологии по описанному выше сценарию.
Работа выполнена при поддержке гранта РФФИ № 11-08-90707.
Литература
1. Гурьянов В.И. Методы адаптивной сборки программного продукта: автореферат дис. ... кандидата технических наук: 05.13.17. Чебоксары, 2008.
2. Конструктор онтологий для разработки мультиа-гентных систем/ В.В. Андреев, К.В. Ивкушкин, И.А. Ми-наков, Г.А. Ржевский, П.О. Скобелев // Труды 3-ей Международной конференции по проблемам управления и моделирования сложных систем. Самара: СНЦ РАН. 2001. С. 480 - 488.
3. Кучер П., Снитюк В. Формализация задачи комплектования и эволюционные аспекты ее решения// Искусственный интеллект. 2009. №4. С. 268-273.
4. Лаврищева Е.М. , Петрухин В.А. Методы и средства инженерии программного обеспечения. М.: МФТИ, 2006. 304 с.
5. Мультиагентная среда для поддержки процессов принятия решений/ М.А. Кораблин, Г.А. Ржевский, П.О. Скобелев // ГССЯ 2001. СПб. 2001. С. 256-270.
6. Норенков И.П. Основы автоматизированного проектирования: учеб. для вузов. М.: Изд-во МГТУ им. Н.Э. Баумана, 2009. 430 с.
7. Рощин М.А. Проектирование многокомпонентных программных систем на основе гибридных логических
моделей: автореферат дис. ... кандидата технических наук: 05.13.01, 05.13.12. Волгоград, 2007.
8. Скобелев П.О. Виртуальные миры и интеллектуальные агенты для моделирования деятельности компаний// Труды 6-ой Национальной конференции ИИ-1998. Пущи-но. Т.2. С. 714-719.
9. Скобелев П.О. Открытые мультиагентные системы для поддержки процессов принятия решений при управлении предприятиями. // Труды Самарского научного центра РАН. Самара. 2001. С.215-227.
10. Скобелев П.О. Самоорганизация и эволюция в открытых мультиагентных системах для холонических предприятий // Труды международного конгресса «Искусственный интеллект в 21 веке». М.: Физматлит, 2001. Т.1. С. 314-338.
11. OR/MS Today Software Surveys [Электронный ресурс] / Forecasting Software Survey. URL: http://www.lionhrtpub.com/orms/surveys/FSS/ (дата обращения: 25.06.2011).
12. OR/MS Today Software Surveys [Электронный ресурс] / Simulation Software Survey. URL: http://www.lionhrtpub.com/orms/surveys/Simulation/ (дата обращения: 25.06.2011).
13. OR/MS Today Software Surveys [Электронный ресурс] / Statistical Software survey. URL: http://www.lionhrtpub.com/orms/surveys/ (дата обращения: 25.06.2011).
14. Skobelev P.O. Holonic Systems Simulation// Proc. of the 2nd International Conference "Complex Systems: Control and Modelling Problems". Samara. 2000. P. 73-79.
15. Turban E. Decision Support and Business Intelligent System / E. Turban, J.E. Aronson, T.P. Liang, R. Sharda. NJ: Prentice Hall, 2007. 850 p.
Рис. 1. Структурно-функциональная схема работы экспертного моделирующего комплекса
Рис. 3. Фрагмент онтологической сети концептов «атрибуты»
хкэуп хк)мтрог(
Рис. 4. Фрагмент онтологической сети для концептов «объект» и соответствующих им «атрибутов»
где
о-
заказчик»;
(^ресурс»; <—з» - «отношение матчинга»;
—- «отношение создание субагента». Рис. 5. Пример фрагмента ПВ-сети для предметной области «Синтез структуры СУМ»
Рис. 6. Пример результата работы многоагентной системы на основе разработанной онтологии
Сибирская государственная автомобильно-дорожная академия (СибАДИ)
THE METHOD FOR SYNTHESIS OF MULTICOMPONENT STRUCTURE OF SOFTWARE SYSTEMS BASED ON MULTIAGENT AND ONTOLOGICAL APPROACHES
I.I. Semenova
The paper proposes a method of synthesizing a multicomponent structure of a software system based on multiagent based and ontological approaches. In the article show an example of a method to search for variants of structures of control systems models
Key words: multicomponent program systems, synthesis of system structure, search of solutions, task of complete set
