Aplicatie bazata pe un sistem multi agent folosind ZEUS pentru simularea tranzactiilor de pe o piata imobiliara

Studeni: Radu Alina Mirela Raican Mara Grupa:1063

Cuprins
1. Analiza domeniului .............................................................................................................................. 3 1.1 Enuntul problemei si premisele..................................................................................................... 3 1.2. Domeniul si modelul de roluri ...................................................................................................... 4 1.3. Mentionare agenti i roluri........................................................................................................... 4 2. Proiectarea aplicaiei ........................................................................................................................... 6 2.1 Proiectarea problemei ................................................................................................................... 6 2.2 Crearea Ontologiei ........................................................................................................................ 9 2.2.1 Identificarea conceptelor ....................................................................................................... 9 2.2.2 Constrngeri ........................................................................................................................... 9 3. Dezvoltarea Aplicatiei ........................................................................................................................ 10 3.2 Crearea Agentilor ........................................................................................................................ 10 3.2.1. Definirea Agentilor .............................................................................................................. 11 3.2.2 Descrierea task-ului .............................................................................................................. 12 3.2.3 Organizarea Agentilor........................................................................................................... 13 3.2.4 Coordonarea Agentilor ......................................................................................................... 13 3.3 Configurarea agentilor utilitari .................................................................................................... 16 3.4 Configurarea agentilor task ......................................................................................................... 18

1. Analiza domeniului
1.1 Enuntul problemei si premisele
Lucrarea de fata isi propune sa analizeze si sa simuleze tranzactionarea valorilor pe o piata imobiliara, cu ajutorul unei noi aplicatii, bazate pe un sistem multi agent. Scopul aplicaiei este: - de a simula funcionarea unei piee imobiliare printr-un sistem de comer electronic mediat de ageni inteligeni - s permit participanilor comercializarea n mod electronic prin intermediul agenilor. Premize: a) Se vor da spre inchiriere/vanzare garsoniere, apartamente de 2 si de 3 camere. b) Zona tintita este municipiul Bucuresti. c) Participantii sunt: a. Proprietarul imobilului, A, este cel care ofera spre vanzare/inchiriere garsoniera sau apartamentul. Acesta, initial, a avut la dispozitie urmatoarele: i. 4 garsoniere, confort 1 ii. 2 apartamente de 2 camere, confort 1, respectiv 2 iii. 1 apartamente de 3 camere, confort 1 iv. 1 vila v. 1 garaj In decursul afacerii, a reusit sa vanda 3 garsoniere, apartamentele de 2 camere, ramanand cu un buget de 30.000 euro, urmarind sa obtina, in continuare, un profit minim de 15% pentru urmatoarele: i. 1 garsoniera, confort 1 ii. 1 apartament de 3 camere, confort 1 b. Agentul imobiliar, participantul B, se ocupa de intermedierea tranzactiei dintre proprietar si client, si consultanta in domeniul vanzarii, punand in legatura cererea cu oferta. Acesta primeste, in schimb, un comision de 3%, la care se adauga TVA. c. Clientul, participantul C, reprezinta o persoana fizica ce doreste achizitionarea unui apartament, avand un buget de 150 000 euro. d) Toate tranzaciile vor fi realizate n euro. e) Preturile propuse de proprietar sunt urmatoarele: a. O garsoniera costa 35 000 euro; b. Apartamentul costa 80 000 euro. f) Clientul poate negocia pretul g) Proprietarul sau clientul se pot retrage daca nu exista colaborare optima intre acestia

1.2. Domeniul si modelul de roluri

1.3. Mentionare agenti i roluri

a) Lista responsabilitatilor agentilor

Tabel 1. Interaciunile aferente diagramei de colaborare Colaborare 1 Registration Explicaie Vnztorii nregistreaz sau produsele oferite spre vnzare. de-registreaz

2 3

Find Request Find Response

Solicit ageni care vnd produsele cutate. List cu agenii care se potrivesc criteriilor de cutare. Mesaj ce conine propunerea cumprtorului

Buyer Offer

Seller Response

Rspunsul vnztorului la o ofert trimis anterior.

In concluzie, dup identificarea domenului i a modelelor de roluri folosite (Distributed Marketplace i ZEUS Application) soluia se va baza pe crearea urmtorilor ageni care s ndeplineasc rolurile din modele folosite:

Nume Agent Owner Client EstateAgent Visual ANS

Rol jucat Seller, Buyer ( Inquirer, Registrant) Buyer( Inquirer, Registrant) Seller (Inquirer, Registrant) Visualiser Agent Name Server

Odat identificate rolurile din cadrul aplicaiei, trebuie identificat modul n care agenii vor juca fiecare rol.

SELLER Responsabiliti sociale Origine SellerRegistrant Seller Seller - Inquirer Responsabilitate S nregistreze i de-registreze prezena n pia (marketplace) S primeasc i s raspund la ofertele primite S solicite informaii despre cererile de pe pia

SELLER Responsabiliti de domeniu Origine Seller Seller Responsabilitate S faciliteze introducerea preferinelor de vnzare ale utilizatorului S analizeze ofertele

BUYER Responsabiliti sociale Origine Buyer - Registrant Buyer-Inquirer Buyer Responsabilitate S nregistreze i de-registreze prezena n pia (marketplace) S solicite informaii despre ofertele de pe pia S comunice ofertele agentului imobiliar

BUYER Responsabiliti de domeniu Origine Buyer Buyer Responsabilitate S faciliteze introducerea preferinelor de cumprare ale utilizatorului S analizeze ofertele

2. Proiectarea aplicaiei
Procesul de proiectare const n: - transpunerea fiecrei responsabiliti identificate n etapa anterioar ntr-o problem generalizat - gsirea celei mai bune soluii la problema de la pasul anterior.

2.1 Proiectarea problemei

Dup identificarea responsabilitilor aferente fiecrui agent, se trece la transpunerea fiecrei responsabiliti ntr-o problem ce trebuie rezolvat. a) Rolul Buyer

BUYER
Responsabiliti sociale Responsabilitate: Origine: Problem: Soluie: S nregistreze i de-registreze prezena n pia Buyer Registrant (Client si Proprietar) Trimitere mesaj *ctre: EstateAgent(Seller), despre: CommoditiesWanted]
Echiparea agentului cu protocolul de coordonare adecvat (COORD-1)

Responsabilitate: Origine: Problem: Soluie: Responsabilitate: Origine: Problem Soluie:

S solicite informaii despre ofertele de pe pia Buyer Inquirer (Client si Proprietar) S stocheze *Seller Commodity, Price] Automatic funcionalitate oferit de agentul Facilitator din ZEUS S comunice ofertele catre agentul imobiliar. Buyer (Client) Trimitere mesaj *ctre: Seller, despre: Commodities-Wanted] Automatic funcionalitate oferit de agentul Facilitator din ZEUS

Responsabiliti de domeniu Responsabilitate: Origine: Problem: Soluie: Responsabilitate: Origine: Problem: Soluie: S faciliteze introducerea preferinelor de cumprare ale utilizatorului Buyer Introducerea informaiei *Commodity, Price, Number+ Folosete interfaa implicit UI (Automatic) S analizeze ofertele Buyer (Client si Proprietar) Evaluare [Commodity, Price]
Echipare agent cu strategii de negociere (COORD-2)

b) Rolul Seller

SELLER
Responsabiliti sociale Responsabilitate: Origine: Problem: Soluie: S nregistreze i de-registreze prezena n pia (marketplace) Seller-Registrant Trimitere mesaj *ctre: Buyer, despre: Commodities-For-Sale]
Echiparea agentului cu protocolul de coordonare adecvat (COORD-1)

Responsabilitate: Origine: Problem: Soluie: Responsabilitate: Origine: Problem: Soluie:

S solicite informaii despre cererile de pe pia Seller-Inquirer Stocare [Buyer Commodity, Price] Automatic parte a funcionalitii implicite a Task Agent S primeasc i s raspund la ofertele primite Seller Angajare n dialog [cu: Buyer, despre: Commodity-For-Sale]
Echiparea agentului cu protocolul de coordonare adecvat (COORD-1)

Responsabiliti de domeniu Responsabilitate: Origine: Problem: Soluie: S faciliteze utilizatorului Seller Introducerea informaiei *Commodity, Price, Number+ Folosete interfaa implicit UI (Automatic) introducerea preferinelor de vnzare ale

Responsabilitate: Origine: Problem: Soluie:

S interpreteze rspunsurile clientului Seller Evaluare [Commodity, Price]

Echipare agent cu strategii de negociere (COORD-2)

2.2 Crearea Ontologiei Urmtoarea faz este aceea de a modela cunotinele ce vor fi folosite de rolurile agenilor. Aceast etap ar trebui s conduc la conceptele din cadrul aplicaiei (n cadrul ZEUS numite Fapte), la atributele i valorile lor posibile (de asemenea cunoscute i sub numele de constrngeri).

2.2.1 Identificarea conceptelor

Conceptele cheie din aplicaia EstateMarket sunt menionate n cerine/specificaii. Aceste sunt: - studio - two rooms apartment - three rooms apartment - villa - garage. Pentru c aceste concepte fac referire la instane fizice (i nu abstracte), ele vor face parte din fapte de tip entitate (Entity). Un fapt de tip abstract (Abstract), pe langa bani, il vor constitui serviciile. Toate faptele de tip entitate dein cte un atribut care descrie valoarea (unit_cost). In aplicaia de fa acesta poate fi folosit pentru stocarea preului fiecrui bun. De asemenea el nu este potrivit pentru aplicaii n care nu sunt folosite noiuni care s descrie valoarea bunurilor iar preurile sunt determinate doar de cerere i ofert.
2.2.2 Constrngeri

Constrngerile ofer un mijloc de verificare, limitnd valorile la un subset de valori posibile. In acest caz constrngerile (pentru stoc) exist (valorile trebuie s fie pozitive) i de aceea nu mai este nevoie de altele n plus (atributul number are valoarea implicit 1). Deoarece valorile fiecarui atribut pot s nu fie general acceptate, nu este nevoie s fie setat o valoare implicit pentru costul/unitate (unit_cost) pentru fiecare imobil. Valoarea evalurii imobilelor va fi adugat atunci cnd vor fi definii agenii. Prin urmare, faptele rezultate cu atributele i constrngerile arat ca n figura de mai jos. Aceasta reprezint ontologia aplicaiei.

Odat definit aceasta se poate trece la procesul de creare al agenilor.

3. Dezvoltarea Aplicatiei
3.2 Crearea Agentilor
Crearea agenilor const n mai multe subprocese care se vor repeta pentru fiecare agent task in parte n cadrul aplicaiei. Am creat un nou agent pe care l-am denumit Seller. Rezultatul acestei aciuni este un nou agent ZEUS generic. In continuare acest agent va fi configurat pentru a satisface responsabilitile specifice aplicaiei aferente rolurilor sale. In fereastra Agent Editor am editat informaiile despre acest agent.

3.2.1. Definirea Agentilor

Am mentionat resursele iniiale ale agentului Seller (Owner). In panel-ul Initial Agent Resources am ales faptele din ierarhia de fapte. Pentru fiecare fapt am redenumit campul Instance si am setat numarul si valoarea. Chiar daca au existat agenti care nu detineau nici un imobil, am setat numarul acestora la 0 , pentru a putea permite agentilor sa cumpere si sa vanda.

Definirea Agentului Buyer

3.2.2 Descrierea task-ului

In cadrul definirii agentului Buyer(Client) a fost creat baza de reguli legalBuying. Bazele de reguli sunt colecii de reguli care sunt grupate n mod convenabil, de obicei datorit funcionalitilor lor. Fiecare regul const dintr-o expresie care cuprinde un pattern i o aciune; atunci cnd agentul deine date care se potrivesc cu patternul atunci se declanaz regula asociat. Deoarece regulile sunt dependente de aplicaie, ele pot solicita un efort mare pentru realizare. legalBuying conine o regul pentru ai permite cumparatorului sa cumpere atunci cand are money > 0.

3.2.3 Organizarea Agentilor

Procesul deorganizare al agentului (Agent Organisation) Am lasat necompletat Avnd n vedere modul n care au fost proiectati agentii se observ c nu sunt soluii care s afecteze nivelul de organizare al unui agent. In specificaiile problemei nu se menioneaz faptul c un agent trebuie s dein apriori cunotine despre ceilali. Prin urmare nu trebuie definite cunotine. Se poate sri peste aceast etap.
3.2.4 Coordonarea Agentilor

Agentii vor fi echipati cu capacitatea de a vinde sau a cumpara. Din proiectarea agentului Seller rezult mai multe soluii ce vor afecta nivelul de coordonare al agentului. Acestea vor fi identificate prin COORD-x ( numrul fiecruia reprezint ordinea n care trebuie realizate, unele fiind dependente de existena altora). Equip agent with co-ordination protocol [Initiator] (COORD-1) Equip agent with co-ordination protocol [Respondent] (COORD-1) Equip agent with negotiation strategies [GrowthFunction] (COORD-2) Equip agent with negotiation strategies [DecayFunction] (COORD-2) Agentul Owner a fost echipat si cu capacitatea de a vinde si de a cumpara.

Echipare agent cu capacitatea de a cumpra Conform seciunii 3, un agent pentru a ncepe s cumpere bunuri trebuie s nceap dialogul cu un potenial vnztor. Atunci, acest proces implic echiparea agentului cu un protocol de iniiere prin selectarea Fipa-Contract-Net-Manager din tabelul Coordination Protocols. Tabelul de jos Coordination Strategies arata aplicabilitatea acelui protocol. Implicit cmpul Mode va fi bifat, lucru ce indic aspectul c aceast strategie va fi folosit mpreun cu faptele descrise n cmpul Fact Type. Deoarece acest cmp conine ZeusFact (Fapte Zeus) aceast strategie va fi folosit pentru a cumpra fapte de orice tip. In specificaii nu este menionat faptul c agenii vor folosi strategii specializate pentru interaciuni particulare, de aceea cmpurile Agents i Relations vor rmne neschimbate. Am selectat functia GrowthFunction din lista cu strategiile disponibile si am definit parametrii care determina modul de lucru al strategiei GrowthFunction. min.percent: fraciunea (partea) valorii percepute din preul unui bun de la care agentul va ncepe s liciteze

no.evasion: diferena de pre considerat a fi neseminifcativ de ctre agent. Cnd preul oferit este mai mare dect preul de licitare dar n intervalul 'no quibble' atunci oferta va fi acceptat. Aceast soluie evit derularea mai multor runde de negociere pentru nite mruni (util cnd se timpul este foarte scurt). max.percent: fraciunea (partea) valorii percepute din preul unui bun pn la care agentul este dispus s mai negocieze.

Parametrii strategiei GrowthFunction

Agent Coordination capacitatea de a cumpara pentru Buyer

Echipare agent cu capacitatea de a vinde Procesul prin care agentul este dotat cu capacitatea de manevra ofertele primite este asemntor cu procesul care l doteaz cu abilitatea de a face oferte. Pentru nceput se specific protocolul care descrie rolul vnztorului(furnizorului) ntr-un dialog de negociere. Atunci, acest proces implic echiparea agentului cu un protocol de iniiere prin selectarea Fipa-Contract-Net-Contractor din tabelul Coordination Protocols.Implicit cmpul Mode din tabelul Coordination Strategies va fi bifat, lucru ce indic aspectul c aceast strategie va fi folosit mpreun cu faptele descrise n cmpul Fact Type. Deoarece acest cmp conine ZeusFact (FapteZeus) aceast strategie va fi folosit pentru a vinde fapte de orice tip. In specificaii nu este menionat faptul c agenii vor folosi strategii specializate pentru interaciuni particulare, de aceea cmpurile Agents i Relations vor rmne neschimbate.

Am selectat functia DecayFunction din lista strategiilor disponibile si am setat parametrii care indic modul n care aceast strategie ruleaz: min.percent: fraciunea (partea) din valoarea unui bun care se scade din preul su. Valoarea obinut reprezint preul minim pe care l va accepta pentru un produs vnztorul. Acest factor va dicta agentului marjaminim de profit, iar dac aceasta este peste sub 100% atunci agentul poate vinde produsul cu mai puin dectvaloarea perceput. no.quibble: diferena de pre considerat de agent a fi nesemnificativ. Cnd o ofert de pre este mai micdect un pre solicitat dar n intervalul 'no quibble' atunci oferta va fi acceptat. Se evit astfel runde denegocieri pentru sume mici bani. max.percent: fraciunea (partea) din valoarea unui bun care se adauga la preul su. Valoarea obinut reprezint preul maxim pe care l poate cere pentru un produs comerciantul.

Agent Coordination - Capacitatea de a cumpara si a vinde pentru Seller(Owner)

3.3 Configurarea agentilor utilitari

In cadrul acestei etape se va stabili ce ageni utilitari vor fi creai modul n care vor fi configurai. Din interfaa principal deschidei instrumentul Code Generator. Se va afia planul de generare (Generation Plan) i anume agenii care vor fi creai cnd se va executa generarea de cod. Se poate observa c pe lng cei 3 ageni creai pn acum (Owner (Seller),Client (Buyer) and EstateAgent) mai sunt i Name Server, Facilitator i Visualiser. Deoarece cei 3 din urm ndeplinesc cerinele iniiale nu mai este nevoie s mai adugm nc unul de vreun tip.

Pentru configurarea parametrilor de rulare pentru aceti ageni, am deschis tab-ul 'Utility Agents' i am completat astfel: Agent Name Server Schimbat numele n ANS. Adresa IP n cmpul Host va fi implicit adresa calculatorului (presupunnd c aici va rula i serverul). Deoarece exist un singur NaemServer acesta este marcat ca fiind root i ofer valoarea pentru cmpul time-grain. Aceast valoare se pote schimba ns 0.5 este o valoarea potrivit pentru aceast aplicaie. Se va presupune pentru simplitate c toi agenii vor fi rulai din acelai director, de aceea n cmpul Address File nu trebuie trecut o cale ci doar un nume de fiier. Valoarea introdusa a fost dns.db (acesta ofer numele fiierului n care Name Server i va scrie locaia). Facilitatorul Se presupune c Facilitatorul va rula pe aceeai maina ca i serverul, prin urmare cmpul Host nu trebuie schimbat. Cmpul DNS file conine calea i numele fiierului care conine locaia serverului. Cmpul trebuie s aib acelai coninut ca i cmpul Address File de la Name Server. In

proiectarea agentului Broker se specific faptul c acesta trebuie s fie reactiv (i nu pro-activ cum este setat implicit). De aceea modificarea care se impune este aceea de a seta Recycle Period la 0.

Visualiser Cmpul Host poate rmne neschimbat iar cmpul DNS File trebuie s conin aceeai valoare ca i campul Address File de la Name Server.

Configurarea realizat pentru agenii utilitari

3.4 Configurarea agentilor task

Agentul 'Seller' /Buyer / EstateAgent : - se presupune c va rula pe acelai calcualtor ca i agenii utilitari (va avea aceali Host) - cmpul DNS File trebuie s conin aceeai valoare ca a cmpului Address File de la Name Server.

Conform proiectrii noastre, resursele agenilor por fi reprezentate n mod intern i nu este nevoie s fie obinute din baze de date externe. De aceea cmpul Database External poate fi lsat liber pentru toi agenii.

Configurarea agentului task

4. Bibliografie
[1] Michael Wooldridge - An introduction to multiagent systems; [2] Jaron Collis - The Role Modelling Guide; [3] Jaron Collis ZEUS Technical Manual; [4] http://agent-imobiliar.blogspot.com/