 |
Инструментарий AgentBuilder
|
|
|
|
Инструментарий для построения MAC компании Reticular Systems, Inc. состоит из двух компонентов: средств разработки (development tools) и окружения периода исполнения (run-time execution environment). Первый компонент ориентирован на поддержку процессов анализа предметной области создаваемой MAC и проектирование агентов с заданным поведением. Второй — обеспечивает эффективную среду для выполнения агентно-ориентированных программ. И тот и другой компоненты реализованы на языке Java, что позволяет им работать на всех платформах, где установлена Java-среда. Агентные программы, проектируемые в рамках AgentBuilder, тоже являются Java-программами и могут исполняться на любом компьютере, где установлена виртуальная Java-машина JVM (Java virtual machine).
Общая схема процесса проектирования и реализации агентно-ориентированных приложений на основе AgentBuilder ToolKit представлена на рис. 9.1. Этот инструментарий имеет средства для организации и предметной области создаваемой MAC, средства спецификации архитектуры агенства и поведения агентов, а также средства отладки агентных приложений и наблюдения за поведением созданных агентов.
Модель «жизненного цикла» агентов, разрабатываемых в рамках AgentBuilder, представлена на рис. 9.2. Как следует из данной схемы, стандартный «жизненный цикл» агента включает следующие основные шаги:
• обработка новых сообщений;
• определение, какие правила поведения применимы в текущей ситуации;
• выполнение действий, специфицированных этими правилами;
• обновление ментальной модели в соответствии с заданными правилами;
• планирование.
Собственно ментальные модели (начальная и текущая) включают описания исходных (текущих) намерений, полаганий, обязательств и возможностей, а также спецификации правил поведения.
|
|
|
Рис. 9.1.Технологическая схема процесса разработки
агентно-ориентированных приложений на базе AgentBuilder ToolKit
Данная модель получила название Reticular Agent Mental Model (RAMM) и является развитием модели Шохама (Shoham) [Shoham, 1993], где все действия выполняются только как результат определенных обязательств. В рамках RAMM эта идея расширена до уровня общих правил поведения, которые определяют причину действия агента в каждой точке его функционирования. При этом правила поведения фиксируют множество возможных «откликов» агента на текущее состояние среды так, как это предписывается полаганиями.
Для спецификации поведения агентов в системе AgentBuilder используется специальный объектно-ориентированный язык RADL (Reticular Agent Definition Language). Правила поведения в этом языке могут рассматриваться как конструкции вида WHEN-IF-THEN.
Рис. 9.2.Модель «жизненного цикла» агента в системе AgentBuilder
WHEN-часть правила адресована новым событиям, возникающим в окружении агента и включает новые сообщения, полученные от других агентов.
IF-часть сравнивает текущую ментальную модель с условиями применимости правила. Образцы в IF-части работают на намерениях, полаганиях, обязательствах и возможностях, определенных в ментальной модели.
THEN-часть определяет действия в ответ на текущие события и состояния ментальной модели и внешнего окружения. Они могут включать обновление ментальной модели, коммуникативные и внутренние действия.
Общий формат правил поведения следующий:
NAME имя правила
WHENMessage Condition(s)
IF Mental Condition(s)
THENPrivate Action(s); Mental Change(s); Message Action(s)
Для иллюстрации возможностей этого языка рассмотрим пример правила «Движение-Вперед-На-Зеленый-Свет» из предметной области «Управление автомобилем», взятый из руководства пользователя [AgentBuilder, 1999].
NAME "Greenlight Move Forward Rule"
|
|
|
WHEN
?KQMLMessage.Performative EQUALS TELL
?KQMLMessage.Sender EQUALS "stoplight-agent"
?KQMLMessage.Content EQUALS String
?KQMLMessage.Ontology EQUALS "Stoplight"
IF
?KQMLMessage.Content EQUALS "stoplight-green"
?KQMLMessage.Status EQUALS "stoppedAtRedLight"
currentMotion.Content EQUALS "stoplight-green"
currentLocation EQUALS nextlntersection
NOT(currentLocation EQUALS destination)
FOR_ALL (?BlockedIntersection,
NOT(?BlockedIntersection. Location EQUALS currentLocation))
THEN
DO (Go(trafficSpeed))
DO ($nextlntersection =
getNextIntersection (currentLocation,
currentMotion.Direction))
ASSERT (SET_VALUE_OF currentMotion.Status TO moving)
ASSERT (SET_VALUE_OF nextlntersection TO Snextlntersection)
SEND (performative = REPLY, receiver = "stoplight-agent",
content = "acknowledged",
in-reply-to =?KQMLMessage.Reply-with)
Как следует из данного примера, в языке RADL активно используются образцы, имеются достаточно развитые средства работы с переменными и представительный набор действий, включающий формирование перформативов языка KQML [Labrou et al., 1997]. Структуры данных, на которых «работает» данный язык, являются, по существу, фреймами, а сами правила — суть продукции специального вида. Язык поддержан на инструментальном уровне системой специальных язы-ково-ориентированных редакторов.
Спецификация поведения агентов и их ментальных моделей составляет специальный файл (agent definition file), который используется совместно с классами и методами из библиотеки действий агентов и библиотеки интерфейсов. Этот файл интерпретируется в рамках компонента Reticular's Run-Time Agent Engine, являющегося частью окружения периода исполнения AgentBuilder.
Оценивая подход к спецификации моделей поведения агентов, используемый в AgentBuilder, можно констатировать, что в целом это серьезная система представления и манипулирования знаниями, ориентированная на описание моделей типа RAMM. Вместе с тем в данной модели отсутствуют средства эксплицитного управления выводом, которые могли бы существенно увеличить функциональную мощность языка. Нет в модели и средств явной фиксации состояния агента, отличных от флагов и/или значений переменных. Не вполне ясно и то, как в спецификации моделей поведения могут быть учтены разные, но одновременно сосуществующие «линии поведения», что характерно для действительно интеллектуальных агентов. Не вполне обоснованным представляется и использование режима интерпретации для реализации поведения агентов.
Но в целом можно еще раз отметить, что инструментарий AgentBuilder является современным и мощным средством проектирования и реализации MAC.
|
|
|
Система 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.
|
|
|
