Sb96899

(INSTRUCTOR :name Panteleev :dept CS)))))" :language fipa-sl

:ontology student-ontology

)

Поле :content имеет следующую структуру:

:content (action1 (role1 :parameter1 value1 :parameter2 value2)

(role2 :parameter3 value3 :parameter4

(role3 :parameter5 value5)))

Значение value1 обычно представляется в строковом виде. Если оно содержит внутри себя пробелы, то заключается в кавычки. Пример:

:name “Ivan Petrov”

5.2. Порядок выполнения работы

В данной лабораторной работе предлагается расширить пользовательскую онтологию StudentOntology, содержащую следующие базовые роли:

концепции: Студент, Преподаватель, Курс (Student, Instructor, Course);

действия: Регистрировать (Register);

утверждения: Курс доступен (CourseAvailable);

предикаты: Зарегистрирован (Registered).

Каждая из этих ролей реализована одноименным классом.

На рис. 5.1 приведена модель иерархии классов StudentOntology в UML. Примечание: в языке Java строчные и прописные буквы различаются, в

том числе и в именах файлов классов. Поэтому всегда необходимо соблюдать регистр (верхний и нижний).

1. Изучить пример пользовательской онтологии StudentOntology, для чего проанализировать диаграмму классов StudentOntology и сравнить ее с программной реализацией соответствующих классов в приведенном листинге (прил. 1).

11

Рис. 5.1. Иерархия классов StudentOntology

2.Расширить онтологию StudentOntology в соответствии с выданным вариантом задания.

Варианты заданий:

2.1.Расширить класс Instructor представлением информации о должности преподавателя. Например, добавить поле «position».

2.2.Добавить действие «deregister», отменяющее регистрацию студента на данный курс, и предикат «deregistered», соответствующий факту отмены регистрации на данный курс.

2.3.Добавить в концепцию «курс» внутреннюю концепцию «расписа-

ние_курса» («CourseSchedule»). Пример формата (CourseSchedule :day Monday :time 13-15).

2.4.Расширить класс Student, добавив в него поле «age».

2.5.Вывести общие слоты для классов Student и Instructor в новый класс Person (name) и затем сделать классы Student и Instructor дочерними для Person.

3.Запрограммировать расширение онтологии, модифицируя приведенный программный код.

Для расширения онтологии путем добавления в нее новой роли необходимо сделать следующее:

12

3.1.Определить соответствующий данной роли java-класс, для чего можно воспользоваться примерами уже реализованных классов для других ролей онтологии.

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

Пусть, например, необходимо добавить роль «deregister», означающую отмену регистрации студента на определенный курс. Формат представления роли следующий:

(deregister :student student_name :course course_name).

Определение соответствующего java-класса deregister.java следующее: class deregister

{

private Student student; private Course course;

public void setStudent(Student s) { student=s;} public Student getStudent() { return student; } public void setCourse(Course c) { course=c; } public Course getCourse() { return course; }

}

Примечание: если поля значений у роли именованные, то в классе, описывающем данную роль, методы установки и считывания значения поля записываются в виде getName или setName. Если поля значений неименованные, то используются методы вида set_x и get_x, где х – порядковый номер поля. Несоблюдение этого правила приведет к ошибке декодирования ACLсообщения, например, при вызове метода extractContent(msg).

Для регистрации роли «deregister» в онтологии StudentOntology.java в

раздел «actions» надо добавить константу «DEREGISTER»:

// Actions

public static final String DEREGISTER = "DEREGISTER";

В конструктор StudentOntology() надо добавить следующий код:

private StudentOntology(Ontology base)

{

...

add(new AgentActionSchema(DEREGISTER), Deregister.class);

AgentActionSchema as = (AgentActionSchema)

13

getSchema(DEREGISTER); as.add("student", (ConceptSchema)

getSchema(STUDENT)); as.add("course", (ConceptSchema) getSchema(COURSE));

...

}

4. Реализовать отправку и получение ACL-сообщения c использованием данных из расширенной онтологии. Для этого написать код двух агентов, один из которых будет отправлять сообщение, а другой – получать.

5.3.Содержание отчета

1.Определение онтологии.

2.Диаграмма классов пользовательской онтологии StudentOntology.

3.Вариант задания на расширение пользовательской онтологии.

4.Диаграмма классов пользовательской онтологии StudentOntology, расширенная в соответствии с заданием.

5.Исходные тексты Java-файлов с классами получающего и принимающего сообщений агентов, а также с классами расширенной онтологии.

6.Текст bat-файла для запуска агентов.

7.Протокол общения агентов (из Sniffer).

8.Выводы.

5.4. Вопросы для самоконтроля

1.Что такое онтология?

2.Какими методами реализуется пользовательская онтология в JADE?

ЛАБОРАТОРНАЯ РАБОТА № 6 Использование стандартизированных протоколов

взаимодействия агентов

Цель работы: научиться пользоваться стандартизированными организацией FIPA протоколами взаимодействия агентов.

6.1. Теоретические сведения

6.1.1. Протоколы взаимодействия агентов

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

14

(агент, начинающий беседу) и Респондент (агент, участвующий в беседе как получатель запроса Инициатора). JADE предоставляет готовые классы поведения для двух указанных ролей в разговорах для большинства стандартизованных протоколов взаимодействия. Эти классы находятся в пакете jade.proto и реализуют набор методов работы с поведением агента на разных стадиях разговора.

Поведение Инициатора заканчивается при достижении любого заключительного состояния протокола взаимодействия. Все типы поведения Инициатора, кроме FipaRequestInitiatorBehaviour, позволяют одновременно общаться с несколькими респондентами, т. е. поддерживают режим 1:N.

6.1.2. Протоколы AchieveRE

Сообщение в языке FIPA-ACL представляет собой речевой акт и рассматривается как одно из действий, которое может выполнить агент. Для каждого речевого акта стандарты FIPA определяют предусловия их выполнимости и ожидаемый эффект действия, названный рациональным эффектом. Предусловия выполнимости – это условия, которые должны быть выполнены прежде чем агент сможет совершить речевой акт, т. е. отправить ACLсообщение.

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

Стандарты FIPA определяют множество протоколов взаимодействия, позволяющих инициатору проверить, был ли достигнут ожидаемый рациональный эффект речевого акта (Achieve Rational Effect). Наиболее важными из этих протоколов являются: FIPA-Request, FIPA-query, FIPA-Request-When, FIPA-recruiting, FIPA-brokering. Базовая структура этих протоколов одинакова, она представлена на рис. 6.1.

Респондент может в ответ на запрос Инициатора сообщить, что он не понял запроса (речевой акт not-understood) или отказывается от достижения рационального эффекта речевого акта (речевой акт refuse).

15

Рис. 6.1. Структура протоколов взаимодействия

В случае согласия выполнить (возможно, в будущем) запрос Инициатора, обеспечив тем самым рациональный эффект, Респондент отвечает речевым актом agree.

После выполнения действия Респондент должен сообщить о результате с помощью речевого акта inform (информирование), если рациональный эффект достигнут, а в противном случае – с помощью речевого акта failure (неудача).

Среда JADE содержит несколько программных классов AchieveREInitiator/Responder, поддерживающих реализацию данных протоколов взаимодействия агентов. Рассмотрим эти классы более подробно.

6.1.3. Класс AchieveREInitiator

Класс AchieveREInitiator соответствует агентам, инициирующим взаимодействие. Экземпляр этого класса может быть создан следующим вызовом конструктора:

new AchieveREInitiator(this, msg),

где this – объект, представляющий агента; msg – экземпляр класса

ACLMessage.

В момент вызова конструктора объект ACLMessage может быть определен не полностью. Метод prepareRequests() может быть переопределeн таким образом, чтобы возвращать полный список ACL-сообщений (вектор объектов ACLMessage), которые будут посланы.

Все методы можно переопределить в дочернем классе.

Для обработки полученных сообщений могут использоваться следующие 3 метода:

16

handleOutOfSequence обрабатывает все неожиданно полученные сообщения, имеющие корректные значения полей conversation-id или in-reply-to;

handleAllResponses обрабатывает все полученные первые ответы (notunderstood, refuse, agree) и для каждого полученного ответа вызывает соответствующий его типу сообщения метод handleNotUnderstood/Refuse/Agree. Переопределение этого метода наиболее эффективно в случае разговора 1:N; handleAllResultNotifications обрабатывает все полученные вторые ответы (failure, inform) и для каждого полученного ответа вызывает соответствующий его типу сообщения метод handleFailure/Inform. Переопределение

этого метода наиболее эффективно в случае разговора 1:N.

Информация об ACL-сообщениях, с которыми работает агент, может быть получена вызовом метода getDataStore(). Для указания конкретных требуемых результатов используются различные ключи:

getDataStore().get(ALL_RESPONSES_KEY) возвращает вектор объектов

ACLMessage со всеми первыми ответами (not-understood, refuse, agree);

getDataStore().get(ALL_RESULT_NOTIFICATIONS_KEY) возвращает вектор объектов ACLMessage со всеми вторыми ответами (failure, inform);

getDataStore().get(REQUEST_KEY) возвращает объект ACLMessage,

являющийся параметром конструктора класса;

getDataStore().get (ALL_REQUESTS_KEY) возвращает вектор объектов

ACLMessage, возвращаемых методом prepareRequests.

Для реализации временно го контроля за выполнением протокола в поле reply-by конструктора ACLMessage указывается значение тайм-аута.

6.1.4. Класс SimpleAchieveREInitiator

Данный класс соответствует упрощенному варианту реализации роли инициатора. Главное отличие SimpleAcheveREInitiator от AchieveREInitiator

состоит в том, что данная версия протокола не позволяет программисту регистрировать прикладные поведения как методы состояний протокола. В данном варианте поддерживается только режим взаимодействия 1:1. Если программист задает в ACLMessage больше одного получателя, сообщение будет отослано только первому получателю.

17

6.1.5. Класс AchieveREResponder

Данный класс соответствует роли респондента. Конструктору должен быть передан в качестве аргумента шаблон, определяющий тип получаемого

ACL-сообщения (объекта ACLMessage).

Шаблон сообщения может быть создан с использованием метода createMessageTemplate. Кроме того, при необходимости могут использоваться более частные шаблоны, в таких случаях для каждого возможного агентаотправителя необходимо создать отдельные экземпляры класса.

Класс может быть легко расширен. Метод prepareResponse вызывается, когда получено сообщение инициатора, и необходимо послать ответ (напри-

мер, agree).

Метод prepareResultNotification вызывается, когда должен быть достигнут рациональный эффект (например, выполнено действие по протоколу FIPA-Request), нужно отправить инициатору заключительное сообщение (на-

пример, inform(done)).

Получение информации об обрабатываемых агентом ACL-сообщениях с использованием метода getDataStore() и ключей аналогично описанному выше. Возможны следующие варианты:

getDataStore().get(REQUEST_KEY) возвращает объект ACLMessage,

полученный от инициатора;

getDataStore().get(RESPONSE_KEY) возвращает объект ACLMessage,

посланный инициатору первым;

getDataStore().get(RESULT_NOTIFICATION_KEY) возвращает объект

ACLMessage, посланный инициатору вторым.

6.1.6. Класс SimpleAchiveREResponder

Данный класс соответствует упрощенному варианту реализации роли респондента. Главное отличие SimpleAchiveREResponder от AchiveREResponder состоит в том, что данная версия протокола не позволяет программисту регистрировать прикладные Поведения как методы состояний протокола.

6.1.7. Пример реализации протокола

Протоколы взаимодействия агентов в соответствии со стандартами FIPA могут быть достаточно просто реализованы в среде JADE с использованием описанных выше классов.

18

Следующий пример показывает, как добавить агенту поведение инициатора в протоколе FIPA-Request:

ACLMessage request =

new ACLMessage(ACLMessage.REQUEST); request.setProtocol(FIPAProtocolNames.FIPA_REQUEST); request.addReceiver(new AID(“receiver”,

AID.ISLOCALNAME)); myAgent.addBehaviour(new AchieveREInitiator(myAgent,

request)

{protected void handleInform(ACLMessage inform)

{

System.out.println(“Protocol finished. Rational

Effect achieved. Received the following message: ”+inform);

}

});

Следующий пример показывает, как добавить агенту поведение респондента в протоколе FIPA-Request:

MessageTemplate mt = AchieveREResponder.createMessageTemplate

(FIPAProtocolNames.FIPAREQUEST); myAgent.addBehaviour(new AchieveREResponder

(myAgent, mt)

{

protected ACLMessage prepareResultNotification (ACLMessage request, ACLMessage response)

{

System.out.println(“Responder has received the following message: ” +request);

ACLMessage informDone = request.createReply(); informDone.setPerformative(ACLMessage.INFORM); informDone.setContent(“inform done”);

return informDone;

}

});

19

6.1.8. Протокол FIPA-Contract-Net

Протокол контрактной сети (FIPA-Contract-Net) позволяет инициатору посылать предложение о выполнении некоторого действия нескольким респондентам, оценивать поступившие от них предложения и выбирать наиболее предпочтительный вариант (или отклонять все).

Базовая структура протокола представлена на рис. 6.2. Детальное описание протокола контрактной сети содержится в спецификациях FIPA [4].

Рис. 6.2. Структура протокола FIPA-Contract-Net

Инициатор посылает запрос предложений, используя сообщение типа cfp (call for proposals). В этом сообщении указывается действие, которое требуется выполнить, и, если необходимо, условия его выполнения.

Респонденты могут ответить сообщением типа propose («Предложение»), содержащим предварительные условия (например, цену или время выполнения). Если респондент не может корректно интерпретировать полученный запрос, он посылает сообщение not-understood («Не понял»). В случае отклонения предложения респондент посылает сообщение refuse («Отказ»).

Получив от респондентов сообщения с предложениями, инициатор оценивает их, выбирает лучшее и отправляет соответствующему респонденту сообщение accept-proposal («Предложение принято»).

20