CC BY
226
Информационные технологии
УДК 519.72
НЕКОТОРЫЕ АСПЕКТЫ ПРОЕКТИРОВАНИЯ МУЛЬТИАГЕНТНЫХ СИСТЕМ
С ИСПОЛЬЗОВАНИЕМ ЯЗЫКА иМЬ
С.Е. Ландсберг, А.А. Хованских
В статье рассматриваются понятия агента, мультиагентной системы, даны общие указания по реализации реактивной и BDI-архитектур агентов с использованием языка объектно-ориентированного программирования, проведен обзор основных диаграмм языка иМЬ и проанализирована возможность их применимости при проектировании мультиагентных систем
Ключевые слова: агент, мультиагентная система, архитектура, класс, метод
Технология программных агентов представляет собой одну из самых важных и впечатляющих концепций, начиная с 90-х годов в области искусственного интеллекта (Artificial Intelligence) и информационных технологий, которая кардинально меняет способ концептуализации и построения сложных компьютерных систем.
Обоснованное применение мультиагент-ных систем выражается в проектировании различных информационных систем поддержки принятия решений и, в том числе, информационных систем управления, являющихся сложной функциональной средой, способной предоставить специалистам актуальную и достоверную информацию о всех бизнес-процессах организации. В настоящее время становится актуальной задача проектирования таких социально-экономических систем при помощи мультиагентных технологий, поскольку сложность многих современных систем и организаций достигает такого уровня, что централизованное управление в них становится неэффективным из-за наличия огромных потоков информации.
Рассмотрим понятие агента. Агентом является вычислительная система, которая внедрена в некоторую среду и способна к автономному поведению в ней согласно своим целям. Здесь под автономией обычно понимают способность агента действовать без прямого вмешательства людей (или других агентов) и контролировать свои собственные действия и внутреннее состояние. Существует определенная аналогия между понятиями автономии в программировании с использованием агентов и инкапсуляции в объектно-ориентированном
Ландсберг Сергей Евгеньевич - ВГТУ, д-р техн. наук, профессор, e-mail: [email protected] Хованских Александр Анатольевич - ВГТУ, аспирант, e-mail: [email protected]
программировании (ООП) [1]. Объект инкапсулирует (заключает в виртуальную оболочку) некое состояние и контролирует его так, что доступ к нему возможен только через методы, предоставляемые объектом. В отличие от этого, агент инкапсулирует не только состояние, но и поведение. Агент - это объект с гибким поведением. Это означает, что агент должен быть [2]:
- автономным в указанном выше смысле;
- чувствительным, т.е. воспринимать через свои сенсоры свою среду и своевременно реагировать на изменения в ней;
- активным, т.е. не просто реагировать на воздействия своей среды, а уметь предвидеть ситуации, действовать с упреждением и целеустремленно, брать на себя инициативу там, где это целесообразно;
- социальным, т.е. общаться с другими агентами и людьми, чтобы решать свою задачу и помогать партнерам решать их задачи.
Мультиагентные системы (МАС) - это системы, состоящие из множества агентов, которые потенциально могут взаимодействовать друг с другом.
К построению агентно-ориентированных систем (АОС) можно указать два подхода: реализация единственного автономного агента или разработка МАС. Автономный агент взаимодействует только с пользователем и реализует весь спектр функциональных возможностей, необходимых в рамках агентноориентированной программы. В противовес этому МАС строится как объединение отдельных подсистем (агентов), основанных на знаниях, и способных функционировать в некоторых средах, а так же находящихся в определенных отношениях и взаимодействующих друг с другом, формируя некоторую организацию, и обладающих набором индивидуальных и совместных действий.
Процесс разработки МАС является сложным и трудоемким процессом, который
должен быть четко формализованным для разработчиков и опираться на некоторые определенные стандарты.
Методологии проектирования АОС все еще находятся в начальной стадии развития [3-7]. Известные подходы можно разделить на четыре основных класса:
- базирующиеся на методах ООП и технологиях с использованием соответствующих расширений;
- использующие традиционные методы инженерии знаний;
- основанные на организационноориентированных представлениях;
- комбинирующие в различной степени методы трех первых классов.
В данной статье мы рассмотрим некоторые аспекты процесса проектирования агентов на основе объектно-ориентированного анализа и проектирования с использованием унифицированного языка моделирования UML.
При сравнении особенностей ООП с набором требований, предъявляемых к программным агентам, становится, очевидно, что технология ООП наиболее подходит для программной реализации МАС. Такой подход использует обмен сообщениями для взаимодействия агентов, а также принципы наследования и агрегирования.
Перед тем, как описать агента в терминах классов и методов UML, сначала рассмотрим архитектуру простого агента (рис. 1), взаимодействующего с информационной окружающей средой, в качестве которой может выступать Интернет, корпоративная сеть (интранет) или виртуальная частная сеть (VPN).
Входные данные
Выходные данные
Рис. 1. Архитектура простого агента
На рисунке видно, что агент воспринимает окружающую среду через свои сенсоры, а затем на основе восприятия выбирает и выполняет действие через свои эффекторы. Сен-
сорный ввод, помимо прочего, может представлять собой также прием сообщений из сети, а действие - передачу сообщений в сеть.
Для программирования агентов можно использовать различные языки объектноориентированного программирования, но чаще всего используется язык Java. Здесь агент является объектом и благодаря этому наследует свою уникальную индивидуальность. Чтобы быть активным, агент должен быть объектом с внутренним событийным циклом, как любой объект класса thread языка Java.
Программный код типичного событийного цикла агента на языке Java, где события возникают в результате восприятия среды, представлен ниже.
Environment e; //состояние среды
RuleSet r; //набор правил
while (true) {
state = senseEnvironment(e); //оценить
среду
a = chooseAction(state, r); //выбрать действие
e.applyAction(a); //выполнить действие
}
Этот цикл является бесконечным, что обеспечивает живучесть агента.
Для агента, реализованного в виде объекта, автономия может осуществляться путем объявления всех методов объекта закрытыми. Тогда агент только сам может вызывать свои методы, и ни один другой агент не может заставить его сделать что-либо, не входящее в его намерения. Другие агенты могут общаться с таким агентом косвенно путем генерирования событий или сообщений в среде, которую данный агент воспринимает и на которую реагирует.
Предоставление агенту возможности “разговаривать” с другими агентами реализует общительность. Разговоры, осуществляемые путем передачи и приема сообщений, позволяют агентам координировать свою деятельность и сотрудничать, если они к этому склонны.
Далее мы рассмотрим пример проектирования типичных агентных архитектур (реактивная и BDI-архитектура) с помощью диаграмм классов UML, облегчающих понимание и создание агентов. Данные примеры не отражают каждый функциональный аспект архитектуры агента, а лишь дают общую схему реализации типичных архитектур агентов [8].
Реактивные агенты - это агенты, которые
не хранят информацию о состоянии среды, а так же не способны к целеполаганию, и просто реагируют на текущее восприятие в соответствии с набором правил типа «ситуация-действие». Диаграмма классов реактивной архитектуры агента показана на рис. 2.
Рис. 2. Архитектура реактивного агента в виде диаграммы классов UML
Здесь класс Agent представляет агента, класс BehaviorCollection - коллекцию методов поведения агента, класс Behavior - метод поведения агента, класс Action - действие агента и, наконец, классы Environment и State - окружающую среду агента и ее состояние соответственно. Метод run( ) класса агента выполняет действие, определяемое текущим методом поведения агента и состоянием окружающей среды. Коллекция объектов в ООП позволяет добавлять и удалять методы поведения без изменения программного кода функции выбора действия getAction( ), т.к. для просмотра списка методов поведения можно использовать итератор. Каждый метод поведения возбуждается, когда он соответствует среде, и каждый из них может блокировать другие методы поведения. Здесь функция getAction( ) не очень эффективна так как имеет время выполнения, измеряемое как O(n), где n - число методов поведения. Время выполнения этой функции можно сократить до O (log n), используя деревья решений, или до 0(1), используя аппаратные средства или параллель-
ную обработку. Разработчик должен гарантировать, что каждому состоянию окружающей среды соответствует, по крайней мере, один метод поведения. Для этого можно определить метод поведения по умолчанию, который соответствует всем входным сигналам, но блокируется всеми другими подходящими для состояния среды методами поведения.
Архитектура BDI-агента основана на модели “намерение-желание-вера” (belief-desire-intention, BDI). Заметим, что веры, желания и намерения агента можно толковать также и как его состояние, цели и планы соответственно. Веры включают в себя самомнение (“я верю, что я могу выполнить задание A”), веры в возможности других агентов (“я верю, что агент B может выполнить задание С”) и мнения об окружающей среде (“на основе данных моих сенсоров я полагаю, что нахожусь в трех метрах от стены”). Намерения сохраняются до тех пор, пока они не выполнены или пока не установлена их недостижимость.
Архитектура BDI-агентов в терминах классов UML показана на рис. 3.
Рис. 3. BDI-архитектура агента в виде диаграммы классов UML
Здесь классы BeliefSet, DesireSet и IntentionSet представляют наборы вер, желаний и намерений, а классы Belief, Desire и Intention - веру желание и намерение соответственно. Эта архитектура намеренно использу-
б
ет вместо прежнего метода многозадачный метод, согласно которому выполняемый thread непрерывно циклически проверяет, применимо ли текущее намерение. Если оно уже неприменимо, то агент выполняет метод stopCurrentIntention( ), который вызывает метод stopExecuting( ) класса намерения. Таким образом, намерение отвечает за прекращение своей работы и очистку памяти. Придавая каждому намерению эту способность, мы устраняем возможность тупиковой ситуации (deadlock), возникающей вследствие того, что намерение имеет некоторые зарезервированные ресурсы в момент прекращения своей работы.
Следующий программный код поясняет два главных цикла программы BDI-агента - по одному циклу для каждого thread в архитектуре BDI. Переменные a, B, D и I представляют соответственно агента, его веры, желания и намерения.
Agent::run() {
Environment e; e.run(); //запуск объекта окружающей среды в его собственном треде while(true) {
I = a.getBestIntention(); if (I.execute(a)) //если намерение выполнено
a.D.remove(I.goal); //удалить желание }
}
Метод run( ) агента выбирает наилучшее применимое намерение и выполняет его. Если функция выполнения намерения возвращает значение true, то желание достигнуто и поэтому оно удаляется из набора желаний. Если thread окружающей среды обнаруживает, что намерение больше не применимо, то намерение сразу выходит из вызова своего метода execute( ) с возвращаемым значением false. Заметим, что thread окружающей среды изменяет набор вер агента. Эти изменения набора вер должны синхронизироваться с любыми изменениями, которые производят намерения в наборах вер.
Выше были даны общие указания по реализации архитектур агентов с использованием языка ООП. По мере усложнения агентов эта технология будет расширяться. Однако, скорее всего, приведенные указания являются достаточно общими, так что при добавлении в состав агента новых функций переписывать весь его программный код не потребуется.
Данные виды диаграмм классов опреде-
ляют архитектурные решения в терминах классов и методов. Использование языка UML обосновывается лучшим пониманием популярных архитектур агентов и удобством их проектирования и реализации.
В общем случае, построение диаграмм классов агентов в UML подразумевает возможность показать функциональные назначения (роли), которые играют агенты, возможности для их взаимодействия и межагентные зависимости.
Межагентные взаимодействия и зависимости возможны только в случае построения полной МАС, которая содержит инфраструктуру, обеспечивающую транспортировку сообщений, а так же службу каталогов и извещение о событиях.
Взаимодействие агентов в МАС происходит посредством приема и передачи сообщений “агентами-клиентами” и обработки этих сообщений “агентами-серверами”. При этом в разных ситуациях одни и те же агенты могут выступать и в качестве клиентов, и в качестве серверов. Описание протокола взаимодействий агентов можно осуществлять путем построения диаграммы последовательностей (sequence diagram). Данный тип диаграмм позволяет отразить последовательность передачи сообщений между агентами.
Для описания спецификации поведения агентов в терминах языка UML удобно использовать диаграммы состояний и диаграммы деятельности.
Каждый агент МАС, обладающий определенным поведением, может находиться в определенных состояниях, переходить из состояния в состояние, совершая определенные действия в процессе реализации сценария своего поведения. Поведение большинства агентов реальных систем можно представить с точки зрения теории конечных автоматов, то есть поведение агента отражается в его состояниях (режимах функционирования), и диаграмма состояний (statechart diagram) позволяет отразить это графически.
Диаграмма деятельности представляет собой дальнейшее развитие диаграммы состояний. Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначение данной диаграммы в том, чтобы отражать процессы деятельности объекта. Этот тип диаграмм позволяет показать не только последовательность процессов, но и ветвление и даже синхронизацию процессов.
В данном подходе к проектированию
МАС, использование универсального языка моделирования UML позволяет разработчику использовать существующие стандарты везде, где это возможно, что обосновывается более гибким процессом понимания и проектирования МАС.
В общем случае, при разработке и реализации МАС с помощью языка UML можно выделить общие характеристики системы, структуру агентов и целей, а так же специфицировать протоколы взаимодействий и поведения агентов. Для этого можно использовать следующие диаграммы языка UML:
- функциональное описание процессов использования системы в виде диаграмм вариантов использования;
- идентификация агентов в виде пакетов в UML и определение зон ответственности;
- описание архитектур агентов с помощью диаграмм классов;
- спецификация задач каждого агента с использованием диаграмм деятельности;
- описание протоколов: используется
диаграмма последовательностей для того, чтобы описать грамматику каждого применяемого протокола в терминах речевых актов.
Таким образом, проанализировав основные виды диаграмм языка UML и возможность их применимости при описании различных аспектов разработки МАС, можно сделать вывод, что проектирование МАС удобно осуществлять, опираясь на объектно-ориентированную методологию проектирования, которая в свою очередь позволяет формализовать процесс разработки МАС и сохранить время, а так же помогает объединить различные процессы, необходимые для реализации МАС, в единую цепочку.
Поскольку в настоящее время нет общепринятой методологии проектирования МАС, то на основании вышесказанного можно сделать выводы об актуальности использования данного подхода при разработке программных
агентов на основе объектно-ориентированной методологии проектирования и реализации с использованием языка UML и ее дополнением некоторыми элементами теории агентов, что обеспечит удобный и оптимальный процесс разработки и специфицирование шагов, которые необходимо пройти разработчику МАС на каждой стадии цикла разработки.
Литература
1. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ /Пер. с англ. - М.: Изд-во “Бином”, 1999.
2. Люгер Д.Ф. Искусственный интеллект: стратегии и методы решения сложных проблем. - М: Издательский дом “Вильямс”, 2003.
3. Виттих В.А. Мультиагентные модели взаимодействий для построения сетей потребностей и возможностей в открытых системах / В. А. Виттих, П. О. Скобелев // Автоматика и телемеханика. - 2003. - №1. - С. 177185.
4. Андреев В. Методы и средства создания открытых мультиагентных систем для поддержки процессов принятия решений / В. Андреев, В. А. Виттих, С. В. Батищев // Известия РАН. Теория и системы управления. -2003. - №1. - С. 126-137.
5. Городецкий, В.И. MAS DK: инструментарий для разработки многоагентных систем и примеры приложений / В. И. Городецкий, О.В. Карсаев, И.В. Хотенко, А. В. Хабалов // Труды Международного конгресса «Искусственный интеллект в XXI веке» (ICAI 2001), 3 - 8 сентября 2001 г. - М. : Физматлит, 2001. - С. 249-262.
6. Котенко И.В. , Уланов А.В. Многоагентное моделирование защиты информационных ресурсов в сети Интернет // Известия РАН. Теория и системы управления. - 2007. - №5. - С. 74-88.
7. Ferber, J.A meta-model for the analysis and design of organisations in multi-agent systems / J. Ferber, O. Gutk-necht // In Proceeding of the 3rd International Conference on Multiagent Systems (ICMAS 98). - IEEE CS Press, 1998.
8. Шахмаметов Р.Г. Распределенные системы искусственного интеллекта: Учеб. пособие. - Новосибирск: Изд-во НГТУ, 2007.
9. J. Mylopoulos, M. Kolp, and J. Castro. UML for agent-oriented software development: The Tropos proposal. In Proc. of the 4th Int. Conf. on the Unified Modeling Language UML'01, Toronto, Canada, 2001.
Воронежский государственный технический университет
SOME ASPECTS OF THE DESIGN OF MULTIAGENT SYSTEMS USING THE LANGUAGE UML
S.E. Landsberg, A.A. Khovanskikh
In the article it considers the concept of an agent, a multiagent system, provides general guidance on the implementation of the administrative and BDI-architectures agents using the language of object-oriented programming, an overview of the basic diagrams of language UML and analyzed the possibility of their applicability in the design of multi-agent systems
Key words: agent, multiagent system, architecture, class, method
