Классификация языковых средств описания агентов на различных уровнях абстракции, назначение отдельных групп языков

Кроме агентных платформ для программирования агентов(JADE, Jason, Jack, Aglobe, Coguaar и т.д.) могут применяться:

1) универсальные языки (Java, C++ , Visual Basic, C# );

2) языки представления знаний (SL, KIF);

**KIF – Knowledge Interchange Format – это формат обмена знаниями.

KIF представляет собой формат для описания содержательной части сообщения, которое «упаковывается» в «KQML-конверт». Он также может быть использован и как основной язык представления знаний внутри агента.

3) языки переговоров и обмена знаниями (KQML, AgentSpeak, April);

**KQML - Knowledge Query and Manipulation Language – это язык запросов и манипулирования знаниями. KQML обычно позиционируется как, так называемый, «внешний» язык для обмена сообщениями между агентами. Посредством него, как в конверт, «заворачивается» основное содержание сообщения, которое обычно написано на другом языке. Иначе говоря, он определяет «формат конверта» и ни в коей мере не определяет формат, на котором должно быть написано содержание сообщения, хотя содержание сообщения также может быть написано на KQML.

4) языки сценариев (Tcl/Tk, Python, Perl 5);

5) специализированные языки (TeleScript, COOL, Agent0, AgentK);

6) символьные языки и языки логического программирования (Oz, ConGolog, IMPACT, Dylog, Concurrent METATEM);

7) а также другие языки и средства разработки агентов.

В качестве критериев выбора средств разработки МАС можно использовать, следующий набор критериев:

· a-критерий: возможность создания систем агентов, способных интегрировать в Windows-приложения;

· b- критерий: наличие операторов для временных выражений, поскольку агенты должны своевременно реагировать на действия;

· c-критерий: поддержка архитектуры стиля BDI, так как предполагается наличие у агента знаний о желаниях, убеждениях, намерениях пользователя;

· d-критерий: наличие операторов для реализации коммуникаций;

· e-критерий: Специализация. Проблемно/предметно специализированные средства обеспечивают сокращение сроков разработки приложений, увеличивают эффективность использования инструментария, упрощают и ускоряют работу программиста, позволяют повторно использовать информационное и программное обеспечение (объекты, классы, правила, процедуры);

· f-критерий: наличие конструкций для реализации модульностей из-за сложности программ агентов;

· g- критерий: обеспечение четкой семантики.

Для реализации агентов наиболее важными являются критерии a),b),e),f),g). Этим критериям удовлетворяют многие средства реализации агентов.

26.Мобильные агенты: определение, назначение, обобщенная структурная схема, основные понятия теории мобильных агентов. Пример решения задачи.

Многоагентные системы подразделяются на статические (позволяют передавать только данные приложений) и динамические (обеспечивают возможность передачи исполняемого кода).

При динамическом подходе многоагентные системы используют понятие мобильных агентов. Мобильные агенты— это программы, которые могут перемещаться по сети, например по WWW, могут переместить своё выполнение на другой процессор. Они покидают клиентский компьютер и перемещаются на удаленный сервер для выполнения своих действий, после чего возвращаются обратно.

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

· уменьшают время и стоимость передачи данных (например, при больших объемах данных вместо передачи всей необработанной информации по сети на хост-источник посылается агент, который выбирает только необходимую информацию и передает ее пользователю);

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

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

· позволяют выполнять асинхронные вычисления (например, запустив агента, можно переключится на другое приложение и даже отсоединиться от сети, а результат будет доставлен агентом адресату после выполнения задания).

Классификация языковых средств описания агентов на различных уровнях абстракции, назначение отдельных групп языков - student2.ru

27.Стандартные языки взаимодействия агентов: KQML, KIF – назначение, структура сообщений, примеры сообщений.

Язык KIF - Knowledge Interchange Format – это формат обмена знаниями.

Этот язык очень похож на язык логики первого порядка в LISP-нотации. Также он имеет много общего с языком разработки экспертных систем среды CLIPS.

Используя KIF, агент может описывать свойства объектов предметной области и отношения между объектами, а также может использовать в этом описании обобщения, относящиеся ко всем объектам. Для этого в словаре KIF определены базовые логические связки и кванторы, а также цифры, символы и зарезервированные слова. Лиспообразная нотация KIF также позволяет обрабатывать списки объектов.

Приведем примеры.

(= (temperature ml) (scalar 83 Celsius))

В данном выражении утверждается, что температура некоего объекта ml составляет 83 градуса Цельсия. Знак равенства – это отношение между двумя понятиями предметной области: свойством и значением свойства. При этом в KIF temperature рассматривается как функция с одним аргументом - ml, а scalar – как функция с двумя аргументами - 83 Celsius. Знак равенства – это стандартный символ KIF, а имена функций temperature и scalar – это уже пользовательское расширение языка, которое должно быть описано специальным образом.

Следующий пример показывает, как может быть введено новое понятие предметной области в терминах уже определенных понятий. В нем утверждается, что объект является холостяком (bachelor), если этот объект мужчина и он не женат.

(defrelation bachelor (?x) :=

(and (man ?x)

(not (married ?x)

)

Как можно заметить, данный язык обладает довольно сложным синтаксисом благодаря большому количеству скобок. Здесь «?x» – это имя переменной, обозначающей некий объект. Символ «: =» - символ определения. Man и married – соответственно классификация и свойство объекта «?x», записанные в предикатной форме.

Следующий пример показывает, как в KIF может быть описано отношение «подкласс-класс».

(defrelation person (?x) :=> (mammal ?x))

В примере говорится, что всякий объект, который является человеком, является и млекопитающим.

Язык KQML -Knowledge Query and Manipulation Language – это язык запросов и манипулирования знаниями. KQML обычно позиционируется как, так называемый, «внешний» язык для обмена сообщениями между агентами. Посредством него, как в конверт, «заворачивается» основное содержание сообщения, которое обычно написано на другом языке. Иначе говоря, он определяет «формат конверта» и ни в коей мере не определяет формат, на котором должно быть написано содержание сообщения, хотя содержание сообщения также может быть написано на KQML.

Сообщение на языке KQML можно понимать как программный объект, в котором определен императив (т.е. глагол, описывающий совершаемую посредством данного сообщения операцию) и ряд его параметров (пар вида атрибут/значение) [3].

Вот пример KQML-сообщения:

(ask-one

:content (PRICE IBM ?price)

:receiver stock-server

:language KIF

:ontology NYSE-TICKS

)

Смысл этого сообщения следующий: некий агент-отправитель спрашивает агента-получателя (stock-server) о цене на какой-то товар от IBM. HРодолдлодлодододододло

Разберем структуру данного сообщения.

«ask-one» - это императив (зарезервированное слово), который используется агентом, чтобы задать вопрос другому агенту, на который требуется только один из возможных ответов.

Другие поля сообщения, начинающиеся через «:» - это атрибуты сообщения.

Поле «:content» - описывает содержание сообщение, представленное в данном случае в формате KIF.

«:receiver» - имя получателя сообщения.

«:language» - название языка, на котором написано сообщение (получатель должен его понимать и вообще-то это необязательно должен быть KIF).

«:ontology» - определяет имя словаря терминов, используемых в сообщении (например, онтологическое расширение языка KIF).

Также в сообщении могут содержаться и другие атрибуты:«:force», «:reply-with», «:in-reply-to», «:sender»,

28.Структура МАС как программной системы в среде Jason: структура программы агента, структура программы среды функционирования, структура файла проекта.

Jason – это перспективное инструментальное средство для создания МАС на основе комбинации двух языков – расширенного AgentSpeak и Java.

AgentSpeak – это язык описания логики работы агентов и взаимодействий между ними, ориентированный на программирование BDI-модели.

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

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

Проект МАС в Jason состоит из файла проекта, имеющего расширение «.mas2j», файлов с программами агентов (минимальное количество агентов – один), которые должны иметь расширение «.asl», файлов модели среды и пользовательского интерфейса (не обязательно), написанных на Java.

Программа каждого агента пишется на языке AgentSpeak и структурно состоит из трех частей, относительное расположение которых фиксировано:

- изначальные убеждения и правила;

- изначальные цели;

- планы достижения целей.

Планы

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

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

- метки плана (необязательна);

- события активации плана;

- контекстных ограничений (могут отсутствовать);

- содержания плана (может отсутствовать).

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

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

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

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

@p1 – правильная метка.

@P1 – неправильная метка.

@mm12CV – правильная метка.

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

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

- происходит добавление или удаление убеждений;

- происходит возникновение новых или отказ от прежних целей;

- запрашивается несуществующая в базе убеждений информация;

- нарушается процесс выполнения плана.

Имена событий начинаются со знаков «+» и «-» и образуются от имен убеждений и целей как показано в табл. 2.

Таблица 2

Обозначение события	Пояснение
+k	Событие добавления убеждения k
-k	Событие удаления убеждения k
+!k	Событие возникновения цели !k
-!k	Событие отказа от достижения цели !k (по причине ошибки в плане или штатным образом)
+?k	Событие возникновения цели-проверки
-?k	Событие отказа от проверки ?k (по причине ошибки в плане или штатным образом)

Рассмотрим подробнее три последних события, указанных в таблице. Допустим, у нас имеется план, обслуживающий достигаемую цель «!p», в теле которого присутствует цель-проверка «?f(X)». Когда интерпретатор Jason переходит к обработке цели-проверки, то вначале он пытается достичь ее путем считывания заданных термов из базы убеждений.

Если в базе убеждений в явном виде нет необходимого для этого убеждения, то он пытается вывести его из имеющихся правил.

Если подходящие правила не будут найдены, то генерируется событие «+?f(X)» в надежде на то, что найдется план, вычисляющий значение терма X.

Если такой план будет найден, но должным образом не завершит свою работу, например, по причине ошибки, то генерируется событие отказа от цели-проверки «-?f(X)».

Если плана для обработки «+?f(X)» не найдено, то происходит отказ от достижения цели «!p» и генерируется событие «-!p».

События «-?f(X)» и «-!p» также могут быть перехвачены и обработаны соответствующими планами. Посредством подобных планов обычно реализуется обработка исключительных ситуаций.

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

Термы-переменные, конкретизированные в контекстных ограничениях, сохраняют свое значение и в теле плана.

Приведем примеры контекстных ограничений в отрыве от остальных частей плана:

«p(X)&q(Y)&X>Y» – ограничения вычисляются слева направо, поэтому сначала будет конкретизирована переменная X, потом Y, и, наконец, они будут сравнены.

Тело плана – это последовательность операций, реализующих предназначение плана:

- математических операций;

- вызовов внутренних функций Jason;

- действий, направленных на объекты среды функционирования МАС;

- коммуникационных актов.

Отдельные выражения в теле плана отделяются точкой с запятой, а в конце плана ставится точка.

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

«Метка

Имя события : Контекстные ограничения <- Тело плана.»

Возможны также следующие варианты структуры плана.

1. Без контекстных ограничений.

«Имя события <- Тело плана.»

2. Без контекстных ограничений и телa плана.

«Имя события.» или «Имя события<-true.»

3. Без тела плана, но с контекстными ограничениями.

Имя события : Контекстные ограничения

В первом случае план может быть принят к исполнению как только зафиксировано отслеживаемое событие, без всяких дополнительных условий.

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

Файл проекта:

MAS name{ - имя

infrastructure: Centralised – тип инфраструктуры (может быть еще Saci – исп. для работы агентов на разных машинах в сети)

environment: nameEnv – указание среды

agents: ag1; ag2; - агенты присутствующие изначально

}

Программа среды:

import jason.asSyntax.Literal; - три библиотеки необходимые для работы jason

import jason.asSyntax.Structure;

import jason.environment.Environment;

public class NameEnv extends Environment { - класс среды, унаследован от jason.environment.Environment

@Override