logo
Базы знаний интелл

9.2.3. Система 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>actK/action>

<actor>Agent Wrapper</actor>

<args>null</args>

</content> ;

<protocol>Request-inform</protocol>

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

<ontology>default</ontology>

</request>

Рис. 9.З. Общая структура протоколов взаимодействия

в системе 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 AgentWrapper {

public static void main (StringC] argv) throws Exception {

AW2 aw = new AW2();

aw.setName ("bidder");

aw.printLog (true);

aw.setPassword ("kawamura");

aw.addPublicIPStates ,();

aw.startIP ();

}

}

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

class AwrlPStatel extends AwrlPState {

AwrlPStateSI () { 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()). nextlnt ();

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 ориентирована на компиляцию программ, а не интерпретацию спецификаций, как это происходит в случае системы AgentBuilder.

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

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

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

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

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

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

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

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

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

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