Программная реализация в среде Jason

Переход от концептуальной модели предметной области данной задачи и представлению ее в виде мультиагентной системы (в виде BDZ-модели) требует дополнительной доработки моделей агентов, у которых должны быть свои:

• • знания (knowledge) — постоянная часть знаний агента о себе, среде и других агентах, т. е. та часть, которая не изменяется в процессе его функционирования;
• • убеждения (beliefs, вера) — знания агента о среде, в частности о других агентах; это те знания, которые могут изменяться во времени и становиться неверными, однако агент может не иметь об этом информации и продолжать оставаться в убеждении, что на них можно основывать свои выводы;
• • желания (desires) — состояния, ситуации, достижение которых по разным причинам является для агента желательным;
• • намерения (intentions) — то, что агент обязан сделать в силу своих обязательств по отношению к другим агентам (ему «это» поручено и он взял эту задачу на себя) или что следует из его желаний (т.е. непротиворечивое подмножество желаний, выбранное по тем или иным причинам, которое совместимо с принятыми на себя обязательствами);
• • цели (goals) — конкретное множество конечных и промежуточных состояний, достижение которых агент принял в качестве текущей стратегии поведения;
• • обязательства по отношению к другим агентам (commitments) — задачи, которые агент берет на себя по просьбе (поручению) других агентов в рамках кооперативных целей или целей отдельных агентов в рамках сотрудничества.

Программная реализация в свою очередь существенно зависит от выбранной среды реализации и языка программирования BDZ-моделей. В данном случае реализация задачи о фастфуде была осуществлена в средеJason^] и на языке AgentSpeak.

Аббревиатура «Jason» расшифровывается как «Java-based AgentSpeak interpreter used with SACI for multi-agent distribution over the net». Сам Jason написан на Java и распространяется бесплатно под лицензией LGPL. (Скачать Jason можно с сайта разработчиков по адресу http//jason.sourceforge, net.) Для своей работы Jason требует JDK не ниже версии 5.

AgentSpeak представляет собой агентно-ориентированную версию языков логического программирования и похож на Prolog. Для обеспечения коммуникации между агентами в AgentSpeak встроена поддержка KQML.

Java в Jason используется для программирования моделей специфических сред функционирования агентов, разработки пользовательских интерфейсов MAC и модификации стандартной работы самого Jason.

Фактически Jason — интерпретатор AgentSpeak, обладающий возможностью расширять функциональности за счет открытости и использования Java.

Система Jason поставляется как надстройка над текстовым редактором Jedit или расширение для среды разработки Eclipse. В комплект поставки, ориентированный ш, Jedit, входят:

• • собственно редактор Jedit с уже подключенным к нему Jason в качестве надстройки;
• • исходные программные коды Jason;^[1]
• • библиотека примеров;
• • документация разработчика.
• (JDK в поставку не входит, но свободно может быть скачан с сайта производителя http://java.sun.com).

Java в Jason используется для программирования моделей специфических сред функционирования агентов, разработки пользовательских интерфейсов MAC и модификации стандартной работы самого Jason.

Программа MAC на языке AgentSpeak в среде Jason состоит из проектного файла и файлов с программами агентов. Запущенная на выполнение MAC работает циклично до тех пор, пока не будет остановлена пользователем вручную, самими агентами или интерпретатором по причине ошибки.

К сожалению, Jason пока не умеет работать с русским языком и не позволяет писать по-русски даже комментариев.

Структурная схема MAC «Фастфуд» показана на рис. 8.10.

База знаний агента содержит следующие информационные модули:

• • базу убеждений;
• • множество событий;
• • базу планов;
• • множество стеков-намерений.

Рассмотрим основные из них.

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

Цели. Цели подразделяются на достигаемые и цели-проверки.

Достигаемые цели — желаемые убеждения, для формирования которых в обязательном порядке должен существовать план.

Цели проверки — цели, заключающиеся в определении значений термов заданных убеждений для дальнейших операций над ними в теле плана.

Планы. Планы описывают процедурную составляющую знаний агента.

План состоит из четырех частей:

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

Эти части разделяются специальными символами-маркерами. Метка плана позволяет задать плану уникальный идентификатор. При помощи метки можно выполнять над планом различные операции.

Событие активации обычно располагается на следующей строке после метки или отделяется от нее пробелом.

Имя метки начинается с символа «@», после которого должна следовать маленькая буква, а далее — любые латинские буквы и цифры. Приведем примеры меток.

@р — правильная метка;

@mm2CV — правильная метка;

@12рт — неправильная метка.

Рис. 8.10. Структурная схема архитектуры многоагентной системы «Фастфуд».

КСЕР и планы. Очевидно, что в задаче о фастфуде результат можно получить только тогда, когда все участники процесса обслуживания покупателей действуют как единое целое, т. е. кооперируются для достижения общей цели. Это означает, что взаимодействие агентов будет осуществляться по модели кооперативного типа. Для нее характерно описание поведения агентов в виде планов, которые выделяются на основе полученных концептуальных структур.

При этом следует иметь в виду, что полученные результаты концептуального анализа, хотя и являются главным ориентиром, но по ним трудно сказать, какое точно количество планов получится в итоге. Это объясняется тем, что некоторые концептуальные структуры могут распадаться на несколько планов, а некоторые могут объединяться в один в зависимости от того, в каком режиме должны выполняться действия — последовательном или параллельном, альтернативны они или нет.

Например, действия повара ПрО (С2.1) и Пр1 последовательны, безальтернативны и ПрО (С2.1) зависит только от результатов Пр1. Поэтому они могут быть объединены в один общий план.

Условия действия Г1р1 формируются альтернативными действиями Пр 1.1 и Пр1.2, поэтому Пр1.1 и Пр1.2 порождают отдельные планы.

Кроме того, мы проводили анализ, предполагая, что все агенты действуют во времени последовательно. Однако это в большинстве случаев не так, и агенты действуют параллельно. Поэтому среди них возможны конфликты за ресурсы. Подобные конфликты очень трудно предсказать на этапе концептуального анализа, поэтому планы для обработки подобных случаев приходится разрабатывать в процессе тестирования и отладки программы.

В табл. 8.1 показана взаимосвязь концептуальных структур единичных решений с полученными в результате реализации планами. Каждый план снабжен меткой, образованной от имени агента и порядкового номера плана. Это сделано не только для присвоения планам аннотаций, но и для возможности ссылаться на них в тексте.

Из-за того, что программа оказалась громоздкой, агентов и комментариев к ним: «Генератор клиентов»; «Клиент»; «Продавец»; «Хранилище»; «Повар»; файл проекта MAC здесь не приводится.

Таблица 8.1

Взаимосвязь концептуальных структур единичных решений с полученными в результате реализации планами.

За дополнительной информацией о работе отдельных функций можно обращаться также в справочник, расположенный в конце указанного пособия¹, а также к первоисточникам^1[2][3].

• [1] Смирнов С. С., Смольянинова В. Л. Указ. соч.
• [2] Смирнов С. С., Смольянинова В. А. Указ. соч.
• [3] URL: http://jason.sourceforge.net; http://java.sun.com.