Система Bee-gent

Инструментарий AgentBuilder, обсуждавшийся выше, базируется на концепции среды разработки, принятой в технологии программирования. Отличный от это­го подход применяется в системе Bee-gent [Bee-gent, 1999]. Здесь для проектиро­вания и реализации MAC используется специальная МАС-библиотека, реализо­ванная на языке Java, а собственно технология, на наш взгляд, представлена методологией спецификации поведения агентов распределенной системы. При этом в системе Bee-gent используется множество базовых агентов (generic agents), среди которых можно выделить упаковщики (agent wrappers) и медиато­ры (mediation agents).

Поведение всей системы, направленное на достижение определенных целей, ба­зируется на спецификации «бесед» (message exchanges) через протоколы взаимо­действия (interaction protocols).

Такие протоколы представляются специальными графами (рис. 9.3), основными понятиями которых являются состояния (states) и переходы (transitions). При этом переходы, по сути дела, лишь специфицируют смещение «фокуса» в следую­щее состояние с помощью специальных правил перехода, а ядро формализма со­ставляют состояния. Именно здесь проверяются предусловия перемещения в сле­дующее состояние и в случае их удовлетворения выполняются действия, в основе которых обмен XML/ACL сообщениями. Возможны правила, результатом вы­полнения которых является выбор следующего состояния из множества подходя­щих.

Как и обычно, в таких случаях, в качестве базиса сообщений декларируется ис­пользование теории речевых актов [Austin, 1965; Searle, 1985]. Однако в случае Bee-gent для этого используется специальный язык ACL, разработанный на осно­ве KQML [Labrou et al, 1997]. Интересно здесь то, что логическая структура ACL-выражений представляется в формализме XML [XML, 1998]. Поэтому язык опи­сания поведения агентов в Bee-gent называется XML/ACL. Основное отличие его от, например, языка RADL в том, что в XML/ACL введены перформативы пред­ставления намерений (intentions), а также средства спецификации потоков развертывания беседы (conversation flows). Вместе с тем в языке спецификации по­ведения агентов системы Bee-gent нет правил, определяющих, в каких случаях какие перформативы должны использоваться. И, следовательно, нет типовых сценариев диалогов. Пример перформатива в формализме XML/ACL приведен ниже:

<!DOCTYPE request SYSTEM "request.dtd">

<request>

<sender>Mediation Agent</sender>

<receiver>Agent Wrapper</receiver>

<content>

<action>act1/action>

<actor>Agent Wrapper</actor>

<args>null</args>

</content>

<protocol>Request-inform</protocol>

<reply-with>MSG-ID:K/reply-with>

<ontology>default</ontology>

</request>

Рис. 9.3. Общая структура протоколов взаимодействия в системе Bee-gent

Как следует из данного примера, для спецификации перформативов использует­ся система специальных тегов, что хорошо коррелирует с предложениями FIPA по созданию языка SKDL (Structured Knowledge Description Language) [SKDL, 1998]. Вместе с тем реализация поведения агентов лежит на специальной систе­ме Java-классов и практически никак не связана с внешним представлением пер­формативов в языке XML/ACL.

Для иллюстрации подхода Bee-gent к описанию поведения агентов рассмотрим модельную задачу брокера [Bee-gent, 1999], обслуживающего потенциального покупателя, который находит продавца определенного товара, обсуждает с ним цены и информирует покупателя о возможных вариантах покупки.

Контрактная сеть верхнего уровня для данной задачи представлена на рис. 9.4.

Рис. 9.4. Контрактная сеть верхнего уровня для задачи брокера

С точки зрения системы представления знаний AgentBuilder, она наиболее близ­ка к спецификации агентства (Agency). Однако в данном случае, по нашему мне­нию, в контрактной сети Bee-gent более детально специфицируются не только типы взаимодействий между агентами в агентстве, но и их реализация.

Собственно спецификацию поведения агентов в системе Bee-gent можно проил­люстрировать на примере протокола взаимодействия для продавца, показанного на рис. 9.5

Такая спецификация достаточно прозрачна и в дополнительных комментариях не нуждается. Поэтому, на наш взгляд, интереснее рассмотреть, как реализуется поведение агента в формализме системы Bee-gent.

Рис. 9.5. Граф протокола взаимодействия для поведения продавца

Собственно инициация агента здесь осуществляется стандартным для Java-при­ложений образом:

………………………

import com.toshiba.beegent. *;

import com.toshiba.beegent.xml.*;

import com.toshiba.beegent.util.*;

public class AW2 extends Agent Wrapper {

public static void main (String[] argv) throws Exception {

AW2 aw = new AW2();

aw.setName ("bidder");

aw.printLog (true);

aw setPassword ("kawamura");

aw.addPublicIPStates ();

aw.startIP ();

}

}

Каждое состояние в протоколе взаимодействия является экземпляром класса AwrIPState, фрагмент описания которого приведен ниже.

class AwrIPState1 extends AwrIPState

{ AwrIPStateS1 () { super ("INIT"); }

public void action () {

XmlAcl xa = null;

………….

while (waitXML (0)){

xa = getXML ();

perf = xa.getTag2Value ("performative");

sender = xa.getTag2Value ("sender");

action = xa.getTag2Value ("action");

if (perf.equals ("cfp")) break;

}

// Send XML/ACL

int rand = new Random (System.currentTimeMillis()).nextInt ();

int dice = Math. abs (rand) % 3;

switch (dice) {

case 0: // generate Refuse performative

setPostcond ("INIT");

break;

……………………

default:

setPostcond ("INIT");

return;

}

if (IsendXML (xa))

Debug.printLog (getMyname (), "Failed to send XML/ACL");

}

}

Наиболее интересны и важны здесь «петля» ожидания сообщений и оператор switch, в теле которого собственно и специфицируется поведение как последова­тельность действий, направленных в данном случае на формирование соответ­ствующего перформатива.

Анализ этого фрагмента и других примеров реализации поведения агентов в си­стеме Bee-gent позволяет сделать следующие выводы. Агентная библиотека фир­мы Toshiba является достаточно развитой и отвечает основным требованиям к компонентам программного обеспечения данного класса. Перформативы XML/ ACL более высокого, по сравнению с KQML, уровня. Для спецификации прото­колов взаимодействия предлагается использовать язык программирования, а не представления знаний. На уровне технологии имеется достаточно четкая струк­тура представления поведения агентов. Учитывая то, что языком реализации поведения в данном случае является Java, система Bee-gent ориентирована на компиляцию программ, а не интерпретацию спецификаций, как это происходит в случае системы Agent Builder.

Выше мы обсудили два подхода к разработке и реализации MAC, которые отра­жают разные концы спектра инструментов, используемых в этой области.

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

При этом задача построения технологий нового поколения для создания MAC может быть решена на основе совместного использования опыта разработчиков MAC и методологий обработки знаний, заимствованных из ИИ [Guarino et al., 1995b]. Для этого, прежде всего, необходимо адаптировать методы и средства проектирования и реализации прикладных интеллектуальных систем в новую проблемную область: разработку мультиагентных систем нового поколения. Очевидно, что спецификация процесса разработки MAC на основе методов про­ектирования баз знаний в такой технологии предполагает:

• эксплицитное представление в БЗ архитектуры проектируемой MAC;

• явную спецификацию архитектуры отдельных типов агентов, «задействован­ных» в рамках проектируемой MAC;

• описание в виде специальных баз знаний модели (схемы) всех знаний, необхо­димых каждому агенту для реализации поставленных перед ним целей;

• анализ используемых в настоящее время при реализации MAC систем классов и соответствующих программных библиотек с целью явной спецификации со­ответствия между элементами архитектуры проектируемой MAC и ее компо­нентами и программными единицами, реализующими их;

• формальную спецификацию (на уровне соответствующей системы представ­ления и манипулирования знаниями) специальной машины вывода (решате­ля), целью которой является переход от спецификации MAC к ее реализации.

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

По существу, при таком подходе мы получаем специализированную экспертную систему, предметной областью которой является автоматизация проектирования и реализации определенного класса мультиагентных систем. Создание такой ме­тодологии разработки MAC обсуждается, например, в работе [Iglesias et. all, 1996], где приводится, в частности, спецификация процесса разработки MAC на базе CommonKADS.

Дата добавления: 2015-07-02