Inteligenta Aritficiala Zeus

7/28/2019 Inteligenta Aritficiala Zeus

1/30

ACADEMIA DE STUDII ECONOMICE FACULTATEA DE CIBERNETIC,STATISTIC, I INFORMATIC ECONOMIC 2012

DEZVOLTAREA UNUI SISTEM MULTIAGENTFOLOSIND ZEUS CARE SIMULEAZ IEIREA

UNEI MAINI DINTR-O PARCARE

Studeni: Potop Oana-MarinaRadu Alexandra Florentina

Grupa:1063


2/30


CUPRINS

Contents

Capitolul 1: Analiza aplicaiei ............................................................................................ 31.1 Enuntul problemei si premisele ............................................................................ 31.2 Domeniul si modelul de roluri .............................................................................. 3

a. Domeniul The Information Management ............................................................... 3Figura 1 - Diagrama modelului de roluri Shared Information Space...................... 4Diagrama de colaborare Shared Information Space Collaboration ............................ 4Descrierea rolurilor modelului Shared Information Space...................................... 51.3 Mentionarea agentilor i a rolurilor...................................................................... 71.4 Lista responsabilitatilor agentilor ........................................................................ 8

Capitolul 2: Proiectarea aplicaiei ..................................................................................... 102.1 Detalierea responsablitatilor pe agenti ................................................................ 102.2 Modelare de cunotinte i ontologie ................................................................... 13

Capitolul 3: Dezvoltarea aplicatiei .................................................................................... 153.1 Crearea ontologiei ............................................................................................... 153.2 Crearea agentilor ................................................................................................. 153.2.1 Definirea agentilor ........................................................................................... 153.3 Configurarea agentilor utilitari ........................................................................... 223.4 Configurarea agentior task .................................................................................. 23

Capitolul 4: Implementarea i rularea aplicaiei ............................................................... 244.1 Evidentierea rezultatelor aplicatiei: .................................................................... 264.2 View-ul societii de ageni, Statistici ................................................................ 27


3/30


Capitolul 1: Analiza aplicaiei

1.1 Enunul problemei i premisele

Proiectul realizat descrie modul de rezolvare i implementare a unei probleme clasicecare presupune ieirea dintr-o parcare a unei masini.

Prin aceast aplicaie sunt puse n eviden dou particulariti ale platformei ZEUS.

Modul n care se poate implementa un serviciu centralizat de informaii ce poatefi interogat folosind mesageria agenilor

Modul n care se poate controla comportamentul unui agent folosind reguli.Pentru nceput, n cadrul analizei aplicaiei se indentific domeniul i modelul de

roluri cele mai potrivite innd cont de cerinele aplicaiei.In situaia de fa, un agent deine informaii necesare celorlali ageni iar acetia

comunic prin intermediul mesajelor cu el. Cel mai potrivit domeniu este cel dindomeniul Managementului informaiei (Information Management Domain) iar modelulde roluri este Spaiul de punere n comun a informaiilor (The Shared InformationSpaces).

1.2 Domeniul i modelul de roluri

a. Domeniul The Information ManagementCaracteristici.Aplicaiile n acest domeniu sunt caracterizate de ctre modul asimetric ncare sunt deinute informaiile. De exemplu, anumite entitti dein informaii pe carealtele nu le dein iniial fie din cauza drepturilor de care dispun, fie modului n care aufost proiectate i construite. De aceea, entitile care nu dein informaiile trebuie scomunice cu entitatea care le deine pentru a le obine i pentru a putea s i continueactivitatea.

b.Modelul de roluri The Shared Information Space

Modelul The Shared Information Space implic dou tipuri de entitai:

1. Publisher-ul (Distribuitorul) - care deine informaii la care doar el are acces 2. Subscriber-ul (Abonatul)care solicit informaii pe care le deine Publisher-ul,

solicitarea fcut prin intermediul trimiterii de mesaje.


4/30


Premizele modelului: exist un singurPublisher unul sau mai muli Subscriber-i Subscriber-iifolosesc aceeai surs de informaii pentru a

realiza scopuri proprii.

Publisher-ul conine 3 sub-roluri: rolul modelului (Model role) responsabil pentru

pstrarea informaiilor stocate rolul Viewresponsabil pentru vizualizarea informaiilor rolul Controller este un intermediar ntre informaiile

stocate i Subscriber-i.

In continuare n Figura 1 este prezentat Modelul Rolurilor

Figura 1 - Diagrama modelului de roluri Shared Information Space

Diagrama de colaborare Shared Information Space Collaboration

Modelul conine 3 seturi de interaciuni:

- ntre rolul de Controller i Subscriber care implic nregistrarea, problema irspunsul la interogri.

Rspunsurile la interogri sunt formulate dup consultarea modelului.- rolul Viewpoate de asemenea accesa modelul i, dup cum se poate vedea n Figura2, realizeaz n raport cu acesta aceleai interaciuni ca i Controller-ul (4,5,7).

Controller

Publisher

ViewModel

Subscriber


5/30


Figura 2:Interaciunile dintr rolurile modelului Shared Information Space

Interaciunile:

Colaborare Explicaie1 Inregistrare Subscriber-ii se aboneaz la Publisher

2 Rspuns la nregistare Publisher-ul notific Subscriber3 Solicitare informaie Este trimis o cerere de obinere a unei

informaii4 Interogarea modelului Modelul este interogat pentru a se obine un

rspuns la cererea primit.5 Rspunsul modelului Informaia solicitat este returnat

Controller-ului6 Rspuns ce conine

informaiaController-ul prezint informaia Subscriber-ului

7 Actualizarea modelului Este fcut o modificare (actualizare) pentruinformaia trimis deinut de model.

Descrierea rolurilor modelului Shared Information Space

CONTROLLER

Modelul de roluri: Shared Information Space

Relaiile cu alte roluri: Aparine rolului Publisher

Descriere:

Sub-rolul reprezint un furnizor de informaii i acoper cel mai important aspect

al Publisher-ului.Are sarcina de a gestiona cererile de abonare i colicitrile de informaii de laSubscriber-i.

Responsabiliti: Colaboratori:

[1, 2] S primeasc i s raspund cererilor deabonare

Subscriber-i


6/30


[3, 6] S primeasc i s rspund solicitrilorde informaii

Subscriber-i

Interfee externe:

S interogheze modelul pentru obinerea de rspunsuri/informaii la solicitareaabonailor

Cerine preliminare:

-

MODEL


Relaiile cu alte roluri:Aparine rolului Publisher

Descriere:Rolul stocheaz informaiile deinute de Publisher i ofer rolurilor Controller iViewposibilitatea de a accesa i actualiza modelul.


[4, 5] S ofere informaii la cerere Controller, View

[7] S permit modificri asupra informaiilorstocate

Controller, View

Interfee externe:

S includ un depozit de informaii

Cerine preliminare:-

VIEW


Relaiile cu alte roluri: Aparine rolului Publisher

Descriere:

Acest sub-rol este opional pentru Publisher. Se folosete de obicei atunci cnd enevoie s fie oferit o descriere a informaiilor stocate de model. Pot exista maimulte instane ale acestui sub-rol n funcie de modurile n care pot fi afiate

informaiile.


[4, 5] S interogheze i s reprezinte modelul. Model

[7] S realizeze modificri n model Model

Interfee externe:


7/30


S vizualizeze coninutul modelului

Cerine preliminare:

-

SUBSCRIBER


Descriere:

Acest rol stocheaz informaiile deinute de Publisher i ofer Controller-uluiposibilitatea de a accesa i de a modifica modelul.


[1, 2] S realizeze i s primeasc cereri deabonare

Controller

[3, 6] S realizeze i s primeasc cereripentru informaii.

Controller

Interfee externe:

S realizeze propriile activiti specifice aplicaiei

Cerine preliminare:

-

1.3 Menionarea agentilor i a rolurilor

Acest proiect nu implic task-uri primitive, fiind implementat un comportamentreactiv care este inclus n ageni folosind task-uri bazate pe reguli.

Participanii i capacitile lor sunt:

Agentul Environment este rspunztor pentru:- stocarea unei pacari- reinerea locaiilor agenilor n cadrul parcarii- va rspunde agenilor la interogrile despre parcare-

va afia grafic parcarea i locaia agenilor n ea la fiecare moment de timp pn laieirea din parcare.

Agentul tip Navigatoragenii de acest tipau urmtoarele caracteristici:- ncearc s iasa din parcare- nu dein informaii despre cum arat parcarea-trebuie s trimit mesaje agentului Environment pentru a obine informaii despre

parcare, informaii pe baza crora s ia deciziile pentru urmtoarea mutare


8/30


- fiecare agent de acest tip va conine o baz de reguli ce descrie compo rtamentulnecesar soluionrii problemei i care le va gestiona mutrile

- fiecare agent va deine o interfat grafic prin care se va raporta utilizatoruluistatusul su curent

- n cadrul aplicaiei sunt creai 3 ageni navigatori(car1,car2,car3).

Modelul de roluri Shared Information Space const ntr-o surs centralizat deinformaii iar responsabilitile sale corespund n mare msur agentului Environment.Rolurile pentru Subscriber-i sunt adecvate pentru agenii Navigator.

In continuare se poate face asocierea rol-participant, ncepnd cu modelul deroluri standard de aplicaia ZEUS. Este nevoie de un agent care s aib rolul de NameServer pentru asigurarea independeei de locaie.

Aisgnarea rolurilor pentru ageni este urmtoarea:

Nume agent Rol

Environment Publisher (Model, View, Controller)

Navigator Subscriber

1.4 Lista responsabilitilor agenilor

Responsabilitile rolului Publisher:

PUBLISHERResponsabiliti sociale

Origine Responsabilitate

Controller (1) S accepte solicitrile de nregistrare

Controller (2) S rspund nregistrrilor

Controller (3) S primeasc cererile de informaii de la Subscriber-i(abonai)

Controller (4) S rspund cererilor de informaii de la Subscriber-i

PUBLISHERResponsabiliti de domeniu

Origine Responsabilitate

Controller (5) S interogheze modelul pentru a putea rspunde cererilorSubscriber-ilor

Model (6) S includ un depozit de informaii

View (7) S vizualizeze coninutul modelului


9/30


Responsabilitile rolului Subscriber:

SUBSCRIBERResponsabiliti socialeOrigine Responsabilitate

Subscriber (1) S se nregistreze la Publisher

Subscriber (2) S solicite informaii de la Publisher cnd este nevoie

SUBSCRIBERResponsabiliti de domeniuSubscriber (3) S realizeze propriile activiti specifice

Subscriber (4) S informeze utilizatorul despre starea curent


10/30


Capitolul 2: Proiectarea aplicaiei

Dup identificarea responsabilitilor specifice fiecrui agent, se poate mapafiecare pe o problem ce trebuie soluionat.

2.1 Detalierea responsabliilor pe ageni

Realizarea rolului de Publisher

Rolurile Publisher-ului refer n primul rnd tratarea cererilor de abonat, dup cum sepoate observa arat n tabelul de mai jos. Aceste intrri vor ilustra faptul ca potrivind oproblema la o soluie existentnecesit o anumitexperien n construirea de sisteme deagent.

PUBLISHER

RESPONSABILITI SOCIALE

Responsibilitate: (1) S accepte solicitrile de nregistrare

Origine: Controller

Problem: Recepionarea i nregistrarea unui nou Subscriber

Soluie: Adugare Fact Monitor la Programul extern (IMPL-4)

Explicaie: Toate mesajele primite sunt adugate n baza de date cu resurse a agentului.Inregistrarea poate fi implementat prin interfaa Fact Monitor. Aceasta are ometod care este declanat atunci cnd sunt recepionate noi fapte dup care potfi luate msurilecorespunztoare (a se vedea urmtoarea intrare).

Responsibilitate: (2) S rspund nregistrrilor

Origine: ControllerProblem: S trimit un mesaj napoi la Subscriber.

Soluie: Creaz o resurs iniial pentru agent (DEF-3) iSpecific prezena unei reguli (DEF-2) iImplementeaz o regul de trimitere a mesajului (RULE-1)

Explicaie: Atunci cnd regula este declanat (a se vedea intrarea precedent), agentul vatrimite un mesaj napoi la Subscriber ntiinndu-l de nregistrare. Fapta trimisSubscriber-ilor nregistrai cu succes va fi furnizat Publisher-ului ca fiind oresursiniial.

Responsibilitate: (3) S primeasc cererile de informaii de la Subscriber-i (abonai)

Origine: Controller

Problem: S monitorizeze sosirea de noi cereri de informaii (pentru schimbare a locaiei).Soluie: Adaug cerere Fact Monitor la Programul extern (IMPL-4)

Explicaie: Folosind o abordare asemntoare gestionrii nregistrrilor, Fact Monitorpoate detecta interogrile primite i reaciona n consecin. In acest caz seinterogheaz Modelul i se declanaz regulile care trimit un rspuns (a se vedeintrarea urmtoarea).

Responsibilitate: (4) S rspund cererilor de informaii de la Subscriber-i


11/30


Origine: Controller

Problem: S trimit un mesaj Message [to: Subscriber, about: ]

Soluie: Implementeaz regulile de trimitere mesaj (RULE-1)

Explicaie: Atunci cnd o regul este declanat (n acest caz pe baza informaiei extras de

la Model) Controller-ul poate trimite un mesaj napoi ctre Subscriber oferindinformaia solicitat.

Deoarece toate aceste soluii nu sunt oferite automat de ctre clasa de agen ZUEStrebuie realizate de ctre dezvoltator prin configurarea agenilor folosind intrumentulZEUS de generare a agenilor i scriind programele externe necesare.

PUBLISHER RESPONSABILITI DE DOMENIU

Responsibilitate: (5) S interogheze modelul pentru a putea rspunde cererilor Subscriber-ilor

Origine: Controller

Problem: S extrag informaii de la Model pentru a rspunde interogrilor Subscriber-ilor

Soluie: Implementez metoda Adapter (IMPL-4)

Explicaie: Metoda Adapter va oferi aplicaiei codul specific care translateaz cererileSubscriber-ilor n interogri ctre Model. Metoda Adapter va avea legtur cuagenii prin intermediul interfeei proprii Zeus External.

Responsibilitate: (6) S includ un depozit de informaii

Origine: Model

Problem: S stocheze informaii

Soluie: Aloc o resurs iniial a agentului (DEF-3) sauConecteaz agentul la o resurs extern (IMPL-3) sauImplementeaz Modelul prin program extern (IMPL-4)

Explicaie: Ageni pot stoca informaii ntr-o varietate de moduri; se pot constata ca fapte inbaza de date de resurse, ntr-o baz de date extern sau n codul Java, care esteaccesibil interfaei agentului ZeusExternal.Alegerea va depinde de tipul deinformaii care sunt stocate. n acest caz, vompstra pracarea exterior, ntr-o matrice2-dimensional Booleana.

Responsibilitate: (7) S vizualizeze coninutul modelului

Origine: View

Problem: Sa ofere o reprezentare grafic a modelului

Soluie: Sa implementeze Model GUI

Explicaie: Reprezentarea parcarii este specifica aplicaiei pentru a fi interpretata de Visualiser,astfel incat o interfapersonalizatva trebui s fiescrisa cse afieaz. Acest lucru

poate fi instantiat din programul agentului ZeusExternal.


12/30


Realizarea rolului de Subscriber

Acest lucru implic adoptarea aceleiai abordare ca i nainte, lund n considerarefiecare responsabilitate, la rndul su:

SUBSCRIBER RESPONSABILITI SOCIALE

Responsabilitate: (1) S se nregistreze la Publisher

Problem: Trimite mesaj ctre Publisher [about: registration]

Soluie: Exist o relaie ntre el i Publisher (de peer) (ORG-1) sau se folosete Facilitatorul iImplementare de reguli pentru trimitere de mesaje(RULE-1)

Explicaie: Identitatea Publisher-ului poate fi setat static atunci cnd agenii sunt generai, saudescoperit la rulare prin intermediul unui Facilitator. Subscriber-ul poate trimite un mesajc Publisher pentru a se nregistra.

Responsabilitate: (2) S solicite informaii de la Publisher cnd este nevoie

Problem: S trimit ctre mutarea urmtoare a Navigatorului ctre agentul Environment.

Soluie: Se creeaz o resurs iniial pentru agent (DEF-3) iSe specific prezena unei baze de date de reguli (DEF-2) iSe implementeaz reguli de trimitere a mesajului (RULE-1)

Explicaie: Resursa iniial va stoca un ablon de micare care va fi folosit pentru informarea mediului(Environment) de micarea pe care Nvigatorul dorete s o realizeze. Micarea reprezint ocerere implicit de informaie. De exemplu pentru mesajul trimis "I'm moving North"rspunsul va conine i specificarea "there are obstacles north and east". Precondiiile acestor reguli include comportamentul de rezolvare a ieirii din labirint.

SUBSCRIBER

RESPONSABILITI DE DOMENIUResponsabilitate: (3) S realizeze propriile activiti specifice

Problem: Implementarea funcionalitilor aplicaiei n acest caz identificarea ieirii din labirint iinformarea utilizatorului de progresul fcut

Soluie: Implementarea bazei de reguli pentru comportament (RULE-1)

Explicaie: Expertiza necesar navigrii prin labirint este stocat sub form de reguli. In acest exemplu sepresupune c rspunsurile de la agentul mediu (Environment agent) vor fi suficiente pentru ainforma Navigatorul de obstacolele care ies n cale. Prin urmare aceste reguli vor folosiinformaia ctigat de la agentul Environment s determine urmtoarea mutarea ce va fifcut.

Responsabilitate: (4) S informeze utilizatorul despre starea curent

Problem: S ofere o descriere grafic a strii modelului. Soluie: Implementarea program extern pentru GUI (IMPL-4)

Explicaie: O interfaa pentru utilizator va fi creat pentru a afia care este starea agentului la fiecaremoment de timp. Pentru aceasta va fi nevoie de implementarea interfeei Fact Monitorpentru a detecta ce informaie este trimis i primit


13/30


2.2 Modelare de cunotine i ontologie

Identificarea conceptelor

1. concepte care reprezint parcarea2. concepte care descriu micarea n parcare.Deoarece nu este nevoie ca faptele s moteneasc atribute de la alte fapte, toate

faptele din ontologie vor fi sub-fapte Zeus (vor fi copii ai lui ZeusFacts).Faptele nu au nevoie de anumite constrngeri. De aceea informaia care trebuie

introdus este redat n tabelul urmtor. Dup crearea ontologiei, aceasta trebuie s arateca n Figura 1. Dup crearea ontologiei aceasta va fi salvat cu denumireamazedemo.def.

Fapt Atribute Default Explicaie

obstacle north: south, east, west :Boolean;

id : String

false Dac exist un perete naceste direcii.

mazeExited id : Stringsq: String

Identitatea agentului carea prsitparcarea

thisMove north, south, east, west :Boolean;id : String

false Atributul setat pe trueeste direcia pe care s-amicat agentul.

moveMade moved :Boolean;id : String

false Flag-ul intern indicfaptul c afost realizat omicare valid.

agentsName name : String Numele agentului carencearc s senregistreze.

agentRegister

ed

name : String Numele agentului demediu (Environmentagent) la care se facenregistrarea.

inMaze isInMaze :Boolean;name : String

false Un flag pentru fiecareagent nregistrat. Estesetat pe true dac agentuleste nc n parcare.


14/30


Figura 3:Ontologia aplicaiei


15/30


Capitolul 3: Dezvoltarea aplicatiei

3.1 Crearea ontologiei

Ontologia este definit conform punctului 2.2.

3.2 Crearea agenilor

Se creeaz urmtorii ageni(Fig. 2) : Car Red,Car Blue,Car Green, Environment

Figura 4 Agenii din aplicaie

3.2.1 Definirea agentilor

Creare agent Environment

Definirea agentului

Se va ine cont de responsabilitile sociale i de domeniu identificate n etapa deproiectare pentru a se vedea dac exist soluii care solicit modificri n definireaaegntului (identificate prin DEF-x). Astfel, exist menionate activitile DEF-2 i DEF-3(Figura 3)

Se d Click pe butonul 'Create New Task' din Task Identification i se selecteazopiunea 'New Rulebase' (proces descris n activitatea DEF-2).

Se redenumete noua intrare cu respondMove.Se specific apoi resursele iniiale ale agentului Environment (process descris nactivitatea DEF-3):

Se d Click pe butonul New Initial Resource i se selecteazagentRegisteredca itip de fapt.


16/30


Aceasta va fi folosit pentru a stoca o referin ctre agentul Environment care va fitrimis ctre toi agenii care s-au nregistrat cu succes. Editai numele atributului cuname valoarea cu Environment.

Nu sunt necsare modificri la organizarea i coordonarea agentului. Se salveazi se

prsete meniul de creare a agentului Environment.

Figura 3 Definirea agentului Environment

Definirea bazei de reguli pentru agentul Environment

In cadrul definirii agentului Environment a fost creat baza de regulirespondMove. Prin urmare aceastea trebuie i ea definit

Bazele de reguli sunt colecii de reguli care sunt grupate n mod convenabil, deobicei datorit funcionalitilor lor. Fiecare regulconst dintr-o expresie care cuprinde

un pattern i o aciune; atunci cnd agentul deine date care se potrivesc cu patternulatunci se declanaz regula asociat.

Deoarece regulile sunt dependente de aplicaie, ele pot solicita un efort marepentru realizare.

Regulile pentru agentul Environment trebuie scrise de dezvoltator pentru amodela comportamentul dorit. Regulile sunt (responseMove.clp):


17/30


Nume regul Trigger Aciune

firstLegalMove Micare valid primit de laNavigator

Mesaj trimis pentru informareaNavigatorului de obstacolele de lanoua locaie

illegalMove Micare invalid ncercat deNavigator

Mesaj trimis care reitereazobstacolele de la locaia curent

respondReg Inregistrare Navigator primit Navigator nregistrat ca fiind nlabirint

sendInMaze Navigator nregistrat ca fiind nlabirint

Mesaj trimis pentru informareaNavigatorului c se afl n labirint

sendExited Navigatorul ajunge la ieirea dinlabirint

Mesaj trimis pentru informareaNavigatorului c nu mai exist nlabirint

Codul regulilor.

Nume regul Condiii Aciune

firstLegalMove ?moveFlag


18/30


Editorul de reguli arat ca n Figura 4.

Figura 4 Editorul de reguli

Crearea agenilor de tip Navigato r Agents

Pentru tipul de agentNavigator vor fi creai 3 ageni: Car Red,Car Green si Car Blue.

Pentru aceti ageni sunt create dou task-uri de tip baze de reguli (Figura 5.):

Registerconine o regul pentru nregistrarea agentului i una pentru de-registrarealui atunci cnd iese din labirint.

Navigate conine regulile care construiesc comportamentul de ieire din labirint.Const ntr-o regula de start i un set de reguli care urmesc pereii i prin care se

aleg direciile la intersecii i decid ce aciune s intreprind dac o anumit direcieeste blocat.


19/30


Fig. 5. Task-urile de tip baze de reguli

Pentru baza de reguli Register, regulile sunt urmtoarele:

Nume regul Condiii Aciune

registerWithEnvironment ?aN


20/30


?var15))

(retract ?obst)

followWall_north ?obst


21/30


?inMaze


22/30


?inMaze


23/30


3.4 Configurarea agentior task

Configurare ageni taskAgentul Environment. Conform proiectrii informaiile folosite de agent sunt

stocate ntr-un program extern (i nu ntr-o baz de date extern). De aceea n cmpulExternal Program va folosi un program numit mazeControl.

Agenii de tip Navigator au o clas numit navGUI menionat n cmpul ExternalProgram, clas care implementeaz interfaa utilizatorului.

Se va meniona pentru agenii Environment i Red crearea unei interfee prinZEUS.

Figura. 7 Agenii task


24/30


Capitolul 4: Implementarea i rularea aplicaiei

- Se alege directorul in care se va genera codul agenilor. - Se alege platforma Windows

- Se genereaza codul.

Prile care trebuie implementate sunt identificate cu prefixul IMPL n etapa deproiectare. Acestea sunt:

Adugare Fact Monitor la Programul extern (IMPL-4)Adaug cerere Fact Monitor la Programul extern (IMPL-4)Implementez metoda Adapter (IMPL-4)Implementeaz Modelul prin program extern (IMPL-4)

Implementarea program extern pentru GUI(IMPL-4)Codul pentru implementarea acestor aspecte va fi legat de agentul agentul

Environment prin programul extern mazeControl.java.

Implementarea programelor externe pentru agentul Environment

Prima problem de luat n calcul este modul n care agentul Environmet varspunde la nregistrare i la mesajele solicitate. Aceasta poate fi realizat prinimplementarea metodei factAddedEvent a interfeei FactMonitor (aceasta se vadesclana def iecare dat cnd un fapt este adugat n baza de date cu resurse a agentulu iEnvironment). Codul este redat n Fig. 8.

Codul solicitat invoc metoda Adapter, care este numit move (). Aceastmetod testeaz dac micarea fcut de agentul Navigator este corect i dac da,

micarea este fcut. Aceasta are ca rezultat faptul c locaia agentului este actualizat inoile obstacole din jur sunt identificate i trecute n baza de date. Aceasta n cele dinurm va declana un nou rspuns de la agentul Navigator iar cilul poate continua pn laieirea dinparcare.

O alt problem este stocarea reprezentrii parcarii, acesta fiind i principalulmotiv al existenei agentului Environment ( Daca agentul Navigator ar avea oreprezentare a parcarii, nu ar mai trebui s comunice cu agentul Environment). Modeluleste implementat n 2 dimensiuni (vector boolean) i poate fi identificat n fiierulmazeModel.java. Variabila care reine modelul stocat este instaniat cnd programul

extern mazeControl este creat prin agentul Environment.Ultimul aspect de implementat este interfaa GUI este implementat n fiierul

mazeView.java care, ca i modelul, este instaniat i stocat de programul externmazeControl. View-ul permite o serie de faciliti (schimbarea poziiei pereilor iprsirea grid-ului).


25/30


Figure 8: Implementarea metodei factAddedEvent pentru agentul Environment

public void factAddedEvent (FactEvent fe)

{

Fact currentFact = fe.getFact();

String agentName = context.whoami();

String factType = currentFact.getType();

System.out.println("Fact = " + factType);if (factType.equals("thisMove"))

{

String north = currentFact.getValue ("north");

String south = currentFact.getValue ("south");

String east = currentFact.getValue ("east");

String west = currentFact.getValue ("west");

String id = currentFact.getValue ("id");

boolean nBool = north.equals("true");

boolean sBool = south.equals("true");

boolean eBool = east.equals("true");

boolean wBool = west.equals("true");

try

{

Thread.sleep(500); // pause for a second

}

catch (Exception e) {;}

// now invoke a function that tests whether it is a legal move

// side effect the obstacles around the agent are asserted in fact database

move (id, nBool, eBool, sBool, wBool);

// a message should now have been sent to the originating agent

// telling it what new obstacles lie in it's path!

}

else if (factType.equals ("agentsName"))

{

String id = currentFact.getValue("name");

int c = (int)(mazeInUse.mazeWidth*Math.random());

int r = (int)(mazeInUse.mazeHeight*Math.random());

mazeInUse.registerAgent(id, c, r);

mazeGui.repaint();

OntologyDb ont = context.OntologyDb();

Fact obst = ont.getFact(Fact.FACT, "obstacle");

obst.setValue("north",mazeInUse.northVal(id));

obst.setValue("east",mazeInUse.eastVal(id));

obst.setValue("south",mazeInUse.southVal(id));

obst.setValue("west",mazeInUse.westVal(id));

obst.setValue("id", id);

ResourceDb rdb = context.ResourceDb();

rdb.add(obst); // add it to the fact db

}}

Request handling code -invokes the adapter method

that queries the Model

Registration code - places

Navigator in the maze andinforms it of obstacles at its

starting location


26/30


4.1 Evidentierea rezultatelor aplicatiei:

Odat lansat aplicaia, agenii se nregistreaz cu NameServer-ul i vor apreainterfeele (Fig. 9)

1. Agenii vor atepta utilizatorul s instruiasc agentul Navigator s se inregistrezela agentul Environment.

2. Se apasbutonul Start se va trimite un mesaj ctre agentul Environmentprincare se nregistreaz prezena sa n mediu. O maina va aprea n interfaaNavigatorului.

Interfaaagentului Environment (stnga) i cea a agentului Navigator (dreapta)


27/30


1. Dup nregistrarea Navigatorului, butonul Start de la fereastra parcrii va deveniactiv

2. Dup apsarea sa, agentul Environment va trimite un mesaj ctre Navigatorinformndu-l de obstacolele(alte masini parcate) din vecintatea sa. Cum acesteasunt precondiii pentru a face o micare, Navigatorul va rspunde cu o cerere demicare.

3. Dup ce i se confirm c face o micare valid, agentul Environment va actualizanoua poziie n parcare iar utilizatorul va vedea cum se realizeaz micrileagentului Navigator pe ecran.

4. Ciclul se continu pn cnd agentul Navigator iese din pacare.5. Agentul Navigator este apoi de-registrat de ctre agentul Environment care va

dezactiva butonul Start pn la o nou nregistrare.

4.2 View-ul societii de ageni, Statistici

Figura 8: View ul societii de ageni


28/30


Figura 9: Statistic 1 Traffic Volume: Distribution by Type

Figura 10: Statistic 2 Traffic Volume: Distribution by Agent


29/30


Figura11: Statistic 3 Traffic Volume: Inter-Agent Traffic Volume


30/30


Inteligenta Aritficiala Zeus

Documents

Transcript of Inteligenta Aritficiala Zeus