Systemy wieloagentowe (MAS) – struktura komunikacji między

(1)

Systemy wieloagentowe (MAS) – struktura komunikacji między

agentami

http://www.MultiAgent.com

Autor:

Zofia Kruczkiewicz

(2)

Agenda

1. Wprowadzenie do zagadnień komunikacji między agentami

2. Specyfikacje FIPA

3. Komunikacja między agentami – BUI 4. Wiadomości typu ACL

5. Semantyka wiadomości ACL 6. Protokoły interakcji

7. Przykład aplikacji realizujacej standardowy protokół Contact-Net Projekt MASE

8. Zastosowanie różnych mechanizmów JADE (2) – zastosowanie szablonów protokołów

(3)

1. Wprowadzenie do zagadnień

komunikacji między agentami

(4)

Wieloagentowy system informatyczny

(5)

Jakie są agenty ?

• Autonomous - autonomiczne

• Interactive - interaktywne

• Adaptive – przystosowujące się

• Sociable – zdolne do zachowań społecznych

• Mobile - mobilne

• Proxy – mogą wystąpić jako pełnomocnicy w różnych zadaniach

• Proactive – zorientowane na cel

• Rational – zdolne do racjonalnego działania

• Unpredictable - nieprzewidywalne

• Temporally continuous – zdolne do ciągłej realizacji procesu

• Transparent and accountable - zrozumiałe i odpowiedzialne

• Coordinative – skoordynowane planem, mechanizmami zarządzania

• Cooperative - współpracujące

• Competitive – rywalizujące bez wyrządzania szkody innym agentom

• Rugged – zdolne do zarządzania danymi obarczonymi błędami i danymi niepewnymi

• Trustworthy – godne zaufania

(6)

Klasyfikacja paradygmatów agentów

Autonomia

• dynamiczna (reaktywna,

proaktywna) – wynika z wewnętrznej

struktury agenta

• nieprzewidywalna, przewidywalna – wynika z

zewnętrznych warunków

Adaptacja

• Reakcja

• Wnioskowanie

• Uczenie

• Ewolucja Interakcja

• Komunikacja

• Koordynacja

• Kooperacja

• Współzawodnictwo

(7)

Interakcja - Dostępne, otwarte, niedeterministyczne, dynamiczne, ciągłe (wg J.Ferber)

(8)

2. SPECYFIKACJE FIPA Foundation for Intelligent

Physical Agents

– normy- specyfikują zewnętrzne zachowania agenta i jego współpracę z innymi

podsystemami ujętymi w specyfikacji FIPA – informacje o aplikacjach– określające

sposób użycia technologii FIPA

(9)

Specyfikacje FIPA 2005 (97)

(10)

Część 1 - Agent Management

Część 1 opisuje normy dotyczące:

• istnieniem agentów

• operacyjnością agentów

• zarządzaniem agentami

• Definicja platformy agenta, pojęcie białej i żółtej księgi, przysyłaniem wiadomości oraz

zarządzaniem cyklami życia agenta, akty komunikacyjne agenta wyrażające jego

inteligentne zachowanie oraz odpowiadająca

ontologia oraz język zawartości wiadomości

(11)

(12)

Część 2 - Język komunikacji agenta

The FIPA Agent Communication Language (ACL) jest oparty na teorii aktów mowy: wiadomości są aktami komunikacyjnymi.

Specyfikacja składa się :

• ze zbioru typów wiadomości, które zawierają opis pragmatyki tych wiadomości wyrażające stosunek typu BUI agenta do innego

agenta/agentów. Opis jest przedstawiony w

formie narracyjnej i formalnej opartej na logice modalnej.

• Ze zbioru opisów protokołów komunikacji

(13)

(14)

FIPA Agent Message Transport specifications deal with the transport and representation

Część 3 - Reprezentacja wiadomości i

transportu wiadomości

(15)

Część 4 - Integracja Agent/Software

Część 4 opisuje sposób integrowania oprogramowania nieagentowego z oprogramowaniem agentowym:

• Systemy baz danych

• Oprogramowanie sieciowe

• Oprogramowanie narzędziowe

(16)

(17)

Część 5 - Aplikacje

(Osobisty Asystent Podróży) Turystyka obejmuje następujące

komponenty:

• Zaopatrzeniowiec

• Pośrednik

• Usługi osobiste

• Role te pełni agent typu PTA - Personal

Travel Agent

(18)

Część 5 - Aplikacje (Osobisty Asystent)

Jest nim półautonomiczny agent typu PA (Personal Assistant) o następujących cechach:

• Realizuje usługi zaopatrzeniowe

• Informuje

• Zarządza podstawowymi danymi

• Organizuje rozrywkę

• Planuje czas przeznaczony na pracę i odpoczynek

• Organizuje spotkania

Część 5 - Aplikacje (Przedsięwzięcia Audio/Video i transmisje)

•Wybór właściwych programów uwzględniając preferencje użytkownika

•Negocjowanie zmiany w programach

(19)

Część 5 - Aplikacje (Zarządzanie i zabezpieczanie sieci)

• Dostarczanie usług końcowym użytkownikom zgodnie z zasadą jakości usług i kosztu usług

• Idea VPN (Virtual Private Network) – połączenia z wybranymi użytkownika na ich życzenie,

dostarczanie usług audiowizualnych

• Zapewniają te usługi trzy typy agentów:

– The Personal Communications Agent (PCA) – reprezentuje użytkownika

– The Service Provider Agent (SPA) - dostarcza usługi – The Network Provider Agent (NPA) – umożliwia

dostęp do sieci

(20)

(21)

3. Komunikacja między agentami - BUI

Cechy komunikacji :

Komunikacja między agentami wynika ze spełnianych przez nich misji. Oparta jest ona na następujących mentalnych

atrybutach agenta:

• Belief (wiara) oznacza zbiór propozycji, które agent akceptuje i zbiór propozycji, które agent nie akceptuje podczas

negocjacji

• Uncertainty (niepewność) oznacza zbiór propozycji, które agent akceptuje lub nie akceptuje z pewnym poziomem

niepewności, czy są prawdziwe lub fałszywe. Oznacza to, że agent przyjmuje model negocjacji, gdy przedmiotem jest

niepewna informacja

• Intention (intencja) oznacza intencję, zamiar lub cel lub zbiór celów, które agent uważa za prawdziwe i te, w ktore agent nie wierzy. Intencje są przedstawiane w postaci planu akcji (np.

za pomocą mapy stanów), prowadzących do zmiany stanów świata rzeczywistego, wybieranych przez agenta

(22)

Wnioski (1)

• Sprzeczności: dana jest propozycja p - wtedy stan wiary p, stan niewiary p, stan niepewności p i stan pewności p wykluczają się wzajemnie.

• W rozproszonych systemach agent jest jedynie zdolny do

spełnienia swoich intencji za pomocą wpływu wywieranego na innych agentów do wykonania akcji.

• Wpływ wywierany na innych agentów osiąga się za pomocą specjalnej klasy akcji zwanych aktami komunikacyjnymi

(communicative acts) – czyli wysyłaniu wiadomości zawierających zakodowany akt komunikacyjny przez nadawcę do odbiorcy.

• Ważną rolę odgrywa typ wiadomości oraz posiadanie tej samej wiedzy opartej na koncepcji BUI.

Np. Agent i wierzy, że “lepiej jest czytać książki niż oglądać TV” i uważa, że agent j będzie uważał podobnie. Agent i w ACL inform informuje j swojej o wierze. Agent j na podstawie semantyki inform wie, że agent i chce

wpłynąć na jego intencje dotyczące wiary w wartość czytania książek, ale dla agenta j przyjęcie wiary agenta i może stanowić pewien problem.

(23)

Wnioski (2)

• transport wiadomości między agentami

• struktura wiadomości

• syntaktyka transportu wiadomości ACL w postaci strumienia bajtów

• katalog standardowych aktów komunikacyjnych

• zbiór i definicja podstawowych protokołów komunikacji zawierających zbiór wiadomości

• definicja modelu semantyki komunikacji.

(24)

4. Wiadomości typu ACL

(25)

Cechy wiadomości - FIPA ACL

Typ wiadomości jest zgodny z typem zawartości wiadomości, którą powinna charakteryzować:

• kompletność

• prostota

• zwięzłość.

Wiadomość reprezentuje akt komunikacyjny, jest jego synonimem

Semantyka języka komunikacji jest oparta na precyzyjnym formalizmie, pozbawionym

sprzeczności.

(26)

Wymagania transportu wiadomości ACL

Usługę transportu wiadomości spełnia system zarządzania agentami Wymagania usług transportu wiadomości (niezbędne):

• przesyłanie zakodowanej wiadomości w postaci sekwencji bajtów

• usługi transportu powinny być niezawodne, dokładne, uporządkowane (kolejność)

• nie spełnienie tych własności powinno być sygnalizowane

• agent ma opcję wyboru sposobu odebrania wiadomości:

uśpienie lub oczekiwania na wiadomość (tryb synchroniczny) lub wykonywanie innych czynności podczas oczekiwania na odpowiedź

• czas przeterminowania nie jest parametrem aktu

komunikacyjnego, tylko systemu usług transportu wiadomości

• po wykryciu błędów, system może wysłać informację o tym fakcie do nadawcy w postaci wiadomości o błędzie

• system zapewnia wybór poprawnego mechanizmu transportu (TCP/IP, SMTP, HTTP, etc)

(27)

Wymagania dotyczące wiadomości ACL

• Wymaganie 1:

Agenty mogą wysłać wiadomość not-understood, jeśli otrzymają wiadomość, której nie rozpoznają lub nie są w stanie odczytać zawartości wiadomości. Agenty muszą odebrać i obsłużyć taką wiadomość

• Wymaganie 2:

Agent powinien posiadać predefiniowany zbiór typów

wiadomości i protokołów, zgodnych z definicją semantyki aktów komunikacyjnych

• Wymaganie 3:

Agent nie może zmieniać znaczenia istniejących predefiniowanych aktów komunikacyjnych

• Wymaganie 4:

Agenty mogą wprowadzać nowe akty komunikacyjne

zrozumiałe przez odbiorcę, jednak nie wolno im nadawać znaczenia istniejących aktów komunikacyjnych.

(28)

• Wymaganie 5:

Agent powinien poprawnie syntaktycznie formułować zawartość generowanej wiadomości oraz z taką samą poprawnością

odczytywać wiadomości.

Zawartość wiadomości

Zawartość wiadomości odpowiada przeznaczeniu aktu

komunikacyjnego. Wiadomość czyli akt komunikacyjny jest zdaniem, natomiast zawartość jest gramatycznym obiektem zdania. Zawartość jest zapisana w języku podanym w

parametrze :language.

• Wymaganie 6:

Ogólnie, język zawartości wiadomości musi wyrażać propozycje, obiekty i akcje. Język ten służy jedynie do

wyrażania typów akcji: propozycji, informowania, żądania itp.

Stany propozycji - true lub false

Obiekty – rzeczy abstrakcyjne lub konkretne

Akcje – agent staje sie aktywny (iota <variable> <term>) np. iota x(P x) oznacza, że x taki, że P [jest prawdziwe] dla x. Słowo iota jest konstruktorem dla termów.

(29)

Definicja 1:

Język zawartości wiadomości FIPA jest oparty na gramatyce s-wyrażeń lub jej podgramatyce i umożliwia wyrażanie propozycji, obiektów i akcji odpowiadających cyklowi życia agenta.

• Wymaganie 7:

Agent jest zobowiązany do wyrażania swoich możliwości wymieniając wiadomości napisane za pomocą języka zawartości wiadomości i

stosując określoną ontologię.

(30)

Budowa wiadomości ACL

(31)

Wyrażenie użyteczne dla systemu usług transportowych i zawiera czas wysłania, czas odbioru, trasę itp. Struktura koperty jest listą par słów kluczowych, które oznaczają pewne aspekty usług wiadomości

:envelope

Wiadomość wysłana jako odpowiedź zawiera w tym atrybucie wyrażenie, które jest również zawarte w parametrze reply-with w odebranej wiadomości,

:in-reply-to

Atrybut zawiera wyrażenie, które identyfikuje oryginalną wiadomość. Może być używane w wątku konwersacji, jeśli jednocześnie prowadzi się kilka dialogów jednocześnie. Np. Agent i wysyła wiadomość do agenta j wiadomość, która zawiera

:reply-with query1,

agent j powinien odpowiedzieć :in-reply-to query1.

:reply-with

Nazwa agenta, do którego wysłana jest wiadomość. Może to być pojedyncza nazwa lub zbiór nazw agentów - multicasting (opcjonalna)

:receiver

Nazwa agenta nadającego akt komunikacyjny (opcjonalna) :sender

typ wiadomości :performative

Znaczenie wiadomości Parametry

(32)

Wyrażenie jest używane do identyfikacji sekwencji wychodzących wiadomości, które tworzą konwersację. Konwersacja może być użyta do zarządzania strategią komunikacji i aktywności agenta oraz do dodatkowej interpretacji znaczenia wiadomości

:conversation- id

Identyfikator oznacza protokół, który zastosował wysyłający agent.

Protokół dodatkowo podaje kontekst wiadomości (opcjonalny). W domyślnej sytuacji każda wiadomość może być traktowana indywidualnie, bez stosowania protokołu.

Nadaje się wtedy niezerowy conversation-id. Odpowiedzi mogą być identyfikowane za pomocą tego samego conversation-id. Czas przeterminowania w reply-by oznacza maksymalny czas oczekiwania na kolejną wiadomość wyznaczoną przez protokół

:protocol

Oznacza czas i/lub datę wyrażenia, która oznacza najdłuższy czas, po którym wysyłający agent oczekuje na odpowiedź

:reply-by

Oznacza ontologię, która jest używana do podania znaczenia symboli używanych w wyrażeniu zawartości wiadomości (często domyślna)

:ontology

Opis kodowania wyrażeń zawartych w wiadomości :encoding

Atrybut zawiera schemat kodowania zawartości wiadomości.

:language

Atrybut zawiera dane wiadomości, czyli treść akcji :content

(33)

Wykaz standardowych wiadomości ACL

(34)

Nadawca przesyła wiadomość do odbiorcy, zawierającą odwołanie do propozycję,

inform ref (macro act)

Nadawca przesyła propozycję do odbiorcy, podając, czy jest prawdziwa inform if

(macro act)

Nadawca przesyła propozycję do odbiorcy inform

Nadawca wykonuje zadanie, ale powiadamia odbiorcę, że nie może go skończyć

failure

Nadawca potwierdza odbiorcy, że nie ufa wysłanej wcześniej przez niego informacji (nadawca zazwyczaj ufa)

disconfirm

Nadawca potwierdza odbiorcy, że ufa wysłanej wcześniej przez niego informacji (nadawca zazwyczaj nie ufa)

confirm

Nadawca podaje propozycję wykonania zadania przez odbiorcę, podając definicję tego zadania

cfp

Nadawca anuluje wykonania zadania przez odbiorcę cancel

Nadawca zgadza się na wykonanie zleconego zadania przez odbiorcę w przyszłości po spełnieniu pewnych warunków

agree

Nadawca akceptuje wykonanie zadania przez odbiorcę, które zostało wcześniej zaproponowane przez odbiorcę

accept proposal

Interpretacja znaczenia wiadomości Typ

wiadomości

(35)

Nadawca żąda, aby był przez odbiorcę powiadamiany o wskazanej informacji oraz o zmianach tej informacji

subscribe

Nadawca żąda wykonania zadania przez odbiorcę, w dowolnym momencie, kiedy zostaną spełnione podane propozycje w wiadomości request

whenever

Nadawca żąda wykonania zadania przez odbiorcę, kiedy zostaną spełnione podane propozycje

request when

Nadawca żąda wykonania zadania przez odbiorcę request

Nadawca nie przyjmuje propozycji od odbiorcy reject

proposal

Nadawca odmawia odbiorcy wykonania zadania refuse

Nadawca pyta odbiorcę, czy wskazana propozycja w wiadomości jest prawdziwa

query ref

Nadawca pyta odbiorcę, czy wysyłana propozycja jest prawdziwa query if

Nadawca informuje odbiorcę, że przyjmuje jego propozycje wykonania zadania, podanego w wiadomości cfp

propose

Nadawca nie rozumie wiadomości otrzymanej wcześniej od odbiorcy i informuje go o tym

not

understood

(36)

Zależności między wiadomościami ACL

(37)

+ subscribe

+ request-whenever

+ request-when

+ request

+ reject-proposal

+ refuse

+ query-ref

+ query-if

+ propose

+ not-understood

+ inform-ref (macro act)

+ inform-if (macro act)

+ inform

+ failure

+ disconfirm

+ confirm

+ cfp

+ cancel

+ agree

+ accept-proposal

Osługa błędu Wykonanie

akcji Negocjacje

Żądanie informacji Przesyłanie

informacji

Kategorie wiadomości Typ wiadomości

(38)

5. Semantyka wiadomości ACL

(39)

Semantyka języka ACL

Język semantyki typu Semantic Language

(SL) jest formalnym językiem używanych do

definicji semantyki języka typu FIPA Agent

Communication Language (FIPA ACL).

(40)

(I John (B Bob(temperature 10)))

(41)

Przykłady

Definicja aktu komunikacyjnego

• <i, act (j, C)>

Równoważna definicja aktu komunikacyjnego (act

:sender i :receiver j :content C)

• FP: φ1

• RE: φ2

gdzie i jest inicjatorem akcji, j jest uczestnikiem , act jest nazwą aktu,

C reprezentuje semantyczny kontekst φ1 and φ2 są propozycjami,

FP jest możliwym skutkiem działania act, RE jest racjonalnym efektem działania act.

(42)

Przykład (1) – ogólny model request

Model aktu komunikacyjnego typu request (FIPA00037, 2000):

<i, request (j, a)>

FP: φ1 RE: φ2

Równoważny zapis (request

:sender i :receiver j :content

a)

FP: FP(a) [i\j] ∧ Bi Agent (j, a) ∧￢ Bi Ij Done (a) RE: Done (a)

(43)

Przykład (1) – zastosowanie request

Agent x żąda od agenta y, aby ten zarezerwował mu bilet.

(request

:sender (agent-identifier :name x)

:receiver (set (agent-identifier :name y)) :content

"((action (agent-identifier :name y)

(reserve-ticket LHR MUC 27-sept-97) ))"

:protocol fipa-request :language fipa-sl

:reply-with order567)

(44)

Przykład (1) – ogólny model agree

Jeśli agent i może wykonać polecenie, wysyła wiadomość typu agree do agenta j

<i, agree (j, <i, request>, φ))>

≡ <i, inform (j, Ii Done (<i, act>, φ))>

FP: Bi α ∧ ￢ Bi (Bifj α ∨ Uifj α) RE: Bj α

gdzie: α = Ii Done(<i, act>, φ)

(45)

Przykład (1) - zastosowanie agree

Agent y odpowiada agentowi x, że zgadza się, ale pod warunkiem, że na koncie agenta x znajduje się

wystarczająca ilość pieniędzy.

(agree

:sender (agent-identifier :name y)

:receiver (set (agent-identifier :name x)) :content

"( (action (agent-identifier :name y)

(reserve-ticket LHR MUC 27-sept-97)) (sufficient- funds ac12345))"

:in-reply-to order567 :protocol fipa-request :language fipa-sl)

(46)

Przykład (1) - ogólny model refuse

Jeśli agent i odmawia agentowi j wykonania polecenia wysłanego w wiadomości typu request, wysyła do niego wiadomość typu

refuse

<i, refuse (j,<i, act>,φ)>≡ <i, disconfirm (j, Feasible(<i, act>))>;

<i, inform (j, φ ∧ ￢ Done (<i, act>) ∧ ￢ Ii Done (<i, act>))>

FP: Bi ￢ Feasible (<i, act>) ∧ Bi (Bj Feasible (<i, act>) ∨ Uj Feasible (<i, act>)) ∧ Bi α ∧￢ Bi (Bifj α ∨ Uifj α) RE: Bj ￢ Feasible (<i, act>) ∧ Bj α

gdzie: α = φ ∧￢ Done (<i, act>) ∧ ￢ Ii Done (<i, act>)

(47)

Przykład (1) – zastosowanie refuse

Agent y odpowiada, że odmawia rezerwacji biletu agentowi y, ponieważ brakuje pieniędzy na koncie

(refuse

:sender (agent-identifier :name y)

:receiver (set (agent-identifier :name x)) :content

"((action (agent-identifier :name y)

(reserve-ticket LHR MUC 27-sept-97)) (insufficient- funds ac12345))"

:in-reply-to order567 :protocol fipa-request :language fipa-sl)

(48)

Agent j składa propozycję agentowi i sprzedania mu 50 skrzynek śliwek (cfp :sender (agent-identifier :name j)

:receiver (set (agent-identifier :name i)) :content

"((action (agent-identifier :name i) (sell plum 50)))"

:ontology fruit-market :reply-with proposal2 )

Przykład (2) – call for proposal

(49)

Agent i odmawia agentowi j zakupu śliwek, gdy j nie ma wystarczającej kwoty na koncie:

(refuse

:sender (agent-identifier :name i)

:receiver (set (agent-identifier :name j)) :content

"((action (agent-identifier :name i) (sell plum 50))

(insufficient-funds ac12345))"

:language fipa-sl)

Przykład (2) – refuse

(50)

Przykład (2) - propose

Agent i informuje j, że sprzeda 50 skrzynek ze śliwkami w cenie $200:

( propose

:sender (agent-identifier :name i)

:receiver (set (agent-identifier :name j)) :content

"((action i (sell plum 50))(cost 200))"

:ontology fruit-market :language fipa-sl

:in-reply-to proposal3)

(51)

Przykład (2) – reject-proposal

Agent i informuje j, że odrzuca ofertę kupna śliwek od j, ponieważ cena jest za wysoka

(reject-proposal

"((action (agent-identifier :name j) (sell plum 50))

(cost 200)

(price-too-high 50))"

:in-reply-to proposal3)

(52)

Przykład (2) - inform

• (inform

(cost 200))"

:language sl)

(53)

Przykład (2) - failure

(failure

(error-message "No plum"))”

:language sl)

(54)

(55)

(56)

6. Protokoły interakcji

Używane wiadomości w różnych konwersacjach mogą

tworzyć pewien szablon, co prowadzi do definicji nowego typu protokołu interakcji

• Wymaganie 8:

Agent nie musi implementować standardowych

protokołów, jednak jeśli przyjęto nazwę standardowego protokołu, musi ona odpowiadać podanej w specyfikacji FIPA.

• Agent może brać udział w kilku konwersacjach

jednocześnie prowadząc dialog z wieloma agentami.

Konwersacje te mogą należeć do różnych protokołów.

Należy zapewnić rozróżnialność poszczególnych wiadomości należących do różnych protokołów i konwersacji.

(57)

Specyfikacja protokołu, jeśli jest operacją

Przykład (request

:sender i :receiver j

:content some-act

:protocol fipa-request

)

(58)

Notacja standardowego opisu protokołu

• prostokaty z podwójnymi krawędziami reprezentują akt komunikacyjny

• Biały prostokąt reprezentuje akcje podejmowane przez nadawcę

• Szare prostokaty reprezentują akcje podejmowane przez pozostałych uczestników protokołu

• Tekst napisany italikiem reprezentuje komnetarz

(59)

Protokół FIPA-request

(60)

(61)

Protokół FIPA-request-when

(62)

(63)

FIPA-query Protocol

(64)

(65)

Protokół FIPA-contract-net

(66)

(67)

FIPA-Iterated-Contract-Net Protocol

(68)

(69)

(70)

7. Przykład aplikacji realizujacej standardowy protokół Contact-

Net Projekt MASE

(71)

(72)

(73)

(74)

(75)

(76)

(77)

(78)

send(cfp)

Deadline for proposals

send(accept -proposal) receive(propose)

send(reject-proposal)

receive(inform) receive(failure)

(79)

receive(cfp)

send(propose)

receive (accept- proposal) receive(reject

-proposal) send(failure)

send(inform)

refuse

(80)

(81)

(82)

8. Zastosowanie różnych mechanizmów JADE (2) –

zastosowanie szablonów

protokołów

(83)

(84)

(85)

(86)

(87)

Zachowania Jade

(88)

Inicjator protokołu

• import jade.core.*;

• import jade.lang.acl.ACLMessage;

• import jade.proto.ContractNetInitiator;

• import jade.domain.FIPANames;

• import java.awt.event.*;

• import java.util.*;

• import javax.swing.*;

• // deficja agenta typu inicjator protokołu typu FIPA-Contract-Net

• public class ContractNetInitiatorAgent1 extends Agent {

• int inicjowanieRandom; //dane do realizacji losowych zadań

• int liczbaodbiorcow; //liczba agentów usługodawców

• String odbiorcy = ""; //łańcuch zawierający nazwy agentów usługodawców //wiadomość typu cfp protokolu ContarctNet

• ACLMessage wiadomosc = new ACLMessage(ACLMessage.CFP);

•

• //definicja komponentów interfejsu graficznego agenta typu inicjator

• //metoda Ramka tworząca interfejs graficzny użytkownika i przygotowująca wiadomość typu cfp

• void Ramka(Agent a) {

• final Agent ag = a;

• ramka = new JFrame("Agent inicjator");

• ramka.setSize(300, 420);

• ramka.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);

•

(89)

• //obsługa zdarzeń GUI agenta usługobiorcy

• zatwierdz.addActionListener(new ActionListener() {

• @Override

• public void actionPerformed(ActionEvent evt) {

• // kod źródłowy metody, która przygotowuje wiadomość typu cfp

• // i wstawia zachowanie typu NowyContractNetInitiator

• //które po uruchomieniu wysyła wiadomość typu cfp

• }

• });

• //wstawianie komponentów GUI do obiektu ramka typu JFrame

• @Override // wywołanie metody setup agenta inicjujące działania agenta

• protected void setup() {

• Ramka(this);

• }}

• //definicja klasy typu Behaviour do obsługi protokołu typu FIPA-Contract-Net po stronie agenta inicjatora

• class NowyContractNetInitiator extends ContractNetInitiator {

• int liczbaodbiorcow;

• int inicjowanieRandom;

• JTextArea komentarz; //kontakt z GUI agenta inicjatora

• NowyContractNetInitiator(Agent agent, ACLMessage wiadomosc, int liczbaodbiorcow_ ,

• int inicjowanieRandom_, JTextArea kom)

• {

• // kod źródłowy konstruktora

• }

(90)

• @Override //obsługa odbioru wiadomości typu refuse

• protected void handleRefuse(ACLMessage refuse) {

• // kod źródłowy metody

• }

• @Override // obsługa odbioru wiadomości typu propose

• protected void handlePropose(ACLMessage propozycja, Vector v) {

• }

•

• //obsługa odbioru wiadomości typu propose oraz przygotowanie się do wysłania wiadomości typu

• //reject-proposal lub accept-proposal

• @Override

• protected void handleAllResponses(Vector odbiorcy, Vector wybrani) {

• //reakcja na przekroczenie czasu oczekiwania na propozycje

• }

• @Override // obsługa odbioru wiadomości typu failure

• protected void handleFailure(ACLMessage failure) {

• }

• @Override //obsługa wiadomości typu inform

• protected void handleInform(ACLMessage inform) {

• }

• //pomocnicza metoda do obsługi zlecania zadań

• public byte[] wypelnij(int n, int m, int offset, int zakres) {

• return tablica1; }

• }

(91)

Odbiorca

• import jade.core.Agent;

• import jade.lang.acl.*;

• import jade.domain.*;

• import jade.domain.FIPAAgentManagement.*;

• import jade.proto.ContractNetResponder;

• import javax.swing.*;

• // klasa agenta typu odbiorca

• public class ContractNetResponderAgent1 extends Agent {

• // definicja komponentów GUI agenta odbiorcy

• //metoda Ramka służy do budowy GUI agenta odbiorcy

• void Ramka() {

• // kod źródłowy metody tworzacej GUI

• }

•

• // metoda inicjująca agenta typu odbiorca - tworzy GUI użytkownika

• // i wstawia zachowanie agenta typu NowyContractNetResponder

• // do obsługi nadawania i odbioru wiadomości po stronie odbiorczej protokołu

• @Override

• protected void setup() {

• }

(92)

•

• // definicja klasy NowyContractNetResponder do obsługi

• // nadawania i odbioru wiadomości po stronie odbiorczej

• // protokołu FIPA-Contract-Net

• class NowyContractNetResponder extends ContractNetResponder {

• JTextArea komentarz; // elementy łączące z GUI agenta

• //odbiorcy

• JFrame ramka;

• //definicja konstruktora klasy NowyContractNetResponder

• NowyContractNetResponder(Agent agent, MessageTemplate szablon,

• JTextArea komentarz_, JFrame ramka_)

• {

• //kod źródłowy konstruktora

• }

(93)

• // metoda do obsługi wysłania wiadomości propose lub wysłania wiadomości refuse

• @Override

• protected ACLMessage prepareResponse(

• ACLMessage wezwanie_do_propozycji)

• throws NotUnderstoodException, RefuseException{

• }

• // metody do obsługi odbioru wiadomości typu reject-proposal

• @Override

• protected void handleRejectProposal(ACLMessage wezwanie_do_propozycji,

• ACLMessage propozycja, ACLMessage akceptacja) {

• }

•

• // metoda do obsługi wysłania wiadomości propose lub wysłania wiadomości refuse oraz

• // wysłania wiadomości typu inform w przypadku zaakceptowania propozycji zawartej

• // w wiadomości propose wykonania zadania lub failure w przypadku niepowodzenia

• // podczas realizacji zadania

• @Override

• protected ACLMessage prepareResultNotification(

• ACLMessage wezwanie_do_propozycji,

• ACLMessage propozycja, ACLMessage akceptacja)

• throws FailureException {

• } //koniec metody

• } //koniec definicji klasy NowyContractNetResponder

(94)

Start systemu – agenta inicjator przygotowuje dane zlecanego zadania, agenci odbiorcy r1 i r2 oczekują na wiadomość typu cfp

(95)

Przygotowanie danych do wysłania wiadomości typu propose przez agentów typu odbiorcy

(96)

Reakcje agenta inicjatora na spóźnione nadesłanie

wiadomości typu propose ze strony agentów usługodawców wysłanie wiadomości reject-proposal

(97)

Przypadek odebrania propozycji wysłanych przez agentów usługodawców agentowi – wysłanie accept-proposal oraz

reject-proposal

(98)

Przypadek akceptacji przez agenta usługobiorcę propozycji w wiadomości propose wysłanej przez agenta usługodawcę

r1 i następnie wysłanie przez agenta r1 informacji o wykonanym zadaniu – wysłanie inform

(99)

(100)

(101)

(102)

(103)