Aplicatie bazata pe un sistem multi agent folosind ZEUS pentru simularea tranzactiilor tranzactiilor de pe o piata imobiliara
Studenţi: Radu Alina Mirela
Raican Mara Grupa:1063
Cuprins 1. Analiza domeniului .............................................................................................................................. .............................................................................................................................. 3 1.1 Enuntul problemei si premisele..................................................................................................... premisele..................................................................................................... 3 1.2. Domeniul si modelul de roluri ...................................................................................... ...................................................................................................... ................ 4 1.3. Mentionare agenti şi roluri ......................................................... ........................................................................................................... .................................................. 4 2. Proiectarea aplicaţiei .............................................................. ........................................................................................................................... ............................................................. 6
2.1 Proiectarea problemei.................................................................. ................................................................................................................... ................................................. 6 ........................................................................................................................ ............................................................. 9 2.2 Crearea Ontologiei ........................................................... 2.2.1 Identificarea Identific area conceptelor ....................................................................................................... ....................................................................................................... 9 2.2.2 Constrângeri ...................................................................................................................... ........................................................................................................................... ..... 9 3. Dezvoltarea Aplicatiei A plicatiei ............................................................. ........................................................................................................................ ........................................................... 10 3.2 Crearea Agentilor .......................................................................................................... ........................................................................................................................ .............. 10 3.2.1. Definirea D efinirea Agentilor .............................................................................................................. .............................................................................................................. 11 3.2.2 Descrierea task-ului .............................................................................................................. .............................................................................................................. 12 3.2.3 Organizarea O rganizarea Agentilor........................................................................................................... Agentilor........................................................................................................... 13 3.2.4 Coordonarea Agentilor A gentilor ......................................................... ......................................................................................................... ................................................ 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 aplicaţiei este: - de a simula funcţionarea unei pieţe imobiliare printr -un sistem de comerţ electronic mediat de agenţi inteligenţi - să permită participanţilor comercializarea în mod electronic prin intermediul agenţilor. 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 tranzacţiile 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. Interacţiunile aferente diagramei de colaborare Colaborare
Explicaţie
1
Registration
Vânzătorii înregistrează sau produsele oferite spre vânzare.
2
Find Request
Solicită agenţi care vând produsele căutate.
3
Find Response
Listă cu agenţii care se potrivesc criteriilor de căutare.
4
Buyer Offer
Mesaj ce conţine propunerea cumpărătorului
de-registrează
5
Seller Response
Răspunsul vânzătorului la o ofertă trimisă anterior.
In concluzie, după identificarea domenului şi a modelelor de roluri folosite ( Distributed Marketplace şi ZEUS Application) soluţia se va baza pe crearea următorilor agenţi care să îndeplinească rolurile din modele folosite:
Nume Agent
Rol jucat
Owner
Seller, Buyer ( Inquirer, Registrant)
Client
Buyer( Inquirer, Registrant)
EstateAgent
Seller (Inquirer, Registrant)
Visual
Visualiser
ANS
Agent Name Server
Odată identificate rolurile din cadrul aplicaţiei, trebuie identificat modul în care agenţii vor juca fiecare rol.
SELLER – Responsabilităţi sociale Origine
Responsabilitate
SellerRegistrant
Să înregistreze şi de-registreze prezenţa în piaţă (marketplace)
Seller
Să primească şi să raspundă la ofertele primite
Seller - Inquirer
Să solicite informații despre cererile de pe piață
SELLER – Responsabilităţi de domeniu Origine
Responsabilitate
Seller
Să faciliteze introducerea preferinţelor de vânzare ale utilizatorului
Seller
Să analizeze ofertele
BUYER – Responsabilităţi sociale Origine
Responsabilitate
Buyer - Registrant
Să înregistreze şi de-registreze prezenţa în piaţă (marketplace)
Buyer-Inquirer
Să solicite informaţii despre ofertele de pe piață
Buyer
Să comunice ofertele agentului imobiliar
BUYER – Responsabilităţi de domeniu Origine
Responsabilitate
Buyer
Să faciliteze introducerea preferinţelor de cumpărare ale utilizatorului
Buyer
Să analizeze ofertele
2. Proiectarea aplicaţiei Procesul de proiectare const ă în: - transpunerea fiecărei responsabilităţi identificate în etapa anterioară într -o problemă generalizată - găsirea celei mai bune soluţii la problema de la pasul anterior.
2.1 Proiectarea problemei După identificarea responsabilităţilor aferente fiecărui agent, se trec e la transpunerea fiecărei responsabilităţi într-o problemă ce trebuie rezolvată.
a) Rolul Buyer
BUYER Responsabilităţi sociale Responsabilitate:
Să înregistreze şi de-registreze prezenţa în piaţă
Origine:
Buyer – Registrant (Client si Proprietar)
Problemă:
Trimitere mesaj *către: EstateAgent(Seller), despre: Commodities-
Wanted] Soluţie:
Echiparea agentului cu protocolul de coordonare adecvat (COORD-1)
Responsabilitate:
Să solicite informaţii despre ofertele de pe piață
Origine:
Buyer – Inquirer (Client si Proprietar)
Problemă:
Să stocheze *Seller – Commodity, Price]
Soluţie:
Automatic – funcţionalitate oferită de agentul Facilitator din ZEUS
Responsabilitate:
Să comunice ofertele catre agentul imobiliar.
Origine:
Buyer (Client)
Problemă
Trimitere mesaj *către: Seller, despre: Commodities-Wanted]
Soluţie:
Automatic – funcţionalitate oferită de agentul Facilitator din ZEUS
Responsabilităţi de domeniu Responsabilitate:
Să faciliteze introducerea preferinţelor de cumpărare ale
utilizatorului Origine:
Buyer
Problemă:
Introducerea informaţiei *Commodity, Price, Number+
Soluţie:
Foloseşte interfaţa implicită UI (Automatic)
Responsabilitate:
Să analizeze ofertele
Origine:
Buyer (Client si Proprietar)
Problemă:
Evaluare [Commodity, Price]
Soluţie:
Echipare agent cu strategii de negociere ( COORD-2)
b) Rolul Seller
SELLER Responsabilităţi sociale Responsabilitate:
Să înregistreze şi de-registreze prezenţa în piaţă (marketplace)
Origine:
Seller-Registrant
Problemă:
Trimitere mesaj *către: Buyer, despre: Commodities-For-Sale]
Soluţie:
Echiparea agentului cu protocolul de coordonare adecvat (COORD-1)
Responsabilitate:
Să solicite informaţii despre cererile de pe piață
Origine:
Seller-Inquirer
Problemă:
Stocare [Buyer – Commodity, Price]
Soluţie:
Automatic – parte a funcţionalităţii implicite a Task Agent
Responsabilitate:
Să primească şi să raspundă la ofertele primite
Origine:
Seller
Problemă:
Angajare în dialog [cu: Buyer, despre: Commodity-For-Sale]
Soluţie:
Echiparea agentului cu protocolul de coordonare adecvat (COORD-1)
Responsabilităţi de domeniu Responsabilitate:
Să
faciliteze
introducerea
preferinţelor
de
vânzare
utilizatorului Origine:
Seller
Problemă:
Introducerea informaţiei *Commodity, Price, Number+
Soluţie:
Foloseşte interfaţa implicită UI (Automatic)
Responsabilitate:
Să interpreteze răspunsurile clientului
Origine:
Seller
Problemă:
Evaluare [Commodity, Price]
Soluţie:
Echipare agent cu strategii de negociere ( COORD-2)
ale
2.2 Crearea Ontologiei Următoarea fază este aceea de a modela cunoştinţele ce vor fi folosite de rolurile agenţilor.
Această etapă ar trebui să conducă la conceptele din cadrul aplicaţiei (în cadrul ZEUS numite Fapte), la atributele şi valorile lor posibile (de asemenea cunoscute şi sub numele de constrângeri).
2.2.1 Identificarea conceptelor
Conceptele cheie din aplicaţia EstateMarket sunt menţionate în cerinţe/specificaţii. Aceste sunt: - studio - two rooms apartment - three rooms apartment - villa - garage.
Pentru că aceste concepte fac referire la instanţe 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 deţin câte un atribut care descrie valoarea (unit_cost). In aplicaţia de faţă acesta poate fi folosit pentru stocarea preţului fiecărui bun. De asemenea el nu este potrivit pentru aplicaţii în care nu sunt folosite noţiuni care să descrie valoarea bunurilor iar preţurile sunt determinate doar de cerere şi ofertă. 2.2.2 Constrângeri
Constrângerile oferă un mijloc de verificare, li mitând valorile la un subset de valori posibile. In acest caz constrângerile (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 evaluării imobilelor va fi adăugată atunci când vor fi definiţi agenţii. Prin urmare, faptele rezultate cu atributele şi constrângerile arată ca în figura de mai jos. Aceasta reprezintă ontologia aplicaţiei.
Odată definită aceasta se poate trece la procesul de creare al agenţilor.
3. Dezvoltarea Aplicatiei 3.2 Crearea Agentilor Crearea agenţilor constă în mai multe s ubprocese care se vor repeta pentru fiecare agent task in parte în cadrul aplicaţiei.
Am creat un nou agent pe care l-am denumit Seller. Rezultatul acestei acţiuni este un nou agent ZEUS generic. In continuare acest agent va fi
configurat pentru a satisface r esponsabilităţile specifice aplicaţiei aferente rolurilor sale. In fereastra ”Agent Editor” am editat i nformaţiile despre acest agent.
3.2.1. Definirea Agentilor
Am mentionat resursele iniţiale 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 colecţii de reguli care sunt grupate în mod convenabil, de obicei datorită funcţionalităţilor lor. Fiecare regulă constă dintr -o expresie care cuprinde un pattern şi o acţiune; atunci când agentul deţine date care se potrivesc cu patternul atunci se declanşază regula asociată. Deoarece regulile sunt dependente de aplicaţie, ele pot solicita un efort mare pentru realizare. legalBuying – conţine 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 Având în vedere modul în care au fost proiectati a gentii se observă că nu sunt soluţii care să afecteze nivelul de organizare al unui agent. In specificaţiile problemei nu se menţionează faptul că un agent trebuie să deţină apriori cunoştinţe despre ceilalţi. Pri n urmare nu trebuie definite cunoştinţe. Se poate sări 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 soluţii ce vor afecta nivelul de coordonare al agentului. Acestea vor fi identificate prin COORD- x ( numărul fiecăruia reprezintă ordinea în care trebuie realizate, unele fiind dependente de existenţa 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 cumpăra
Conform secţiunii 3, un agent pentru a începe să cumpere bunuri trebuie să înceapă dialogul cu un potenţial vânzător. Atunci, acest proces implică echiparea agentului cu un protocol de iniţiere prin selectarea Fipa-Contract-Net-Manager din tabelul „Coordination Protocols‟. Tabelul de jos “Coordination Strategies‟ arata aplicabilitatea acelui protocol. Implicit câmpul Mode va fi bifat, lucru ce indică aspectul că această strategie va fi folosită împreună cu faptele descrise în câmpul Fact Type. Deoarece acest câmp conţine ZeusFact (Fapte Zeus) această strategie va fi folosită pentru a cumpăra fapte de orice tip. In specificaţii nu este menţionat faptul că agenţii vor folosi strategii specializate pentru interacţiuni particulare, de aceea câmpurile Agents şi Relations vor rămâne neschimbate. Am selectat functia GrowthFunction din lista cu strategiile disponibile si am definit parametrii care determina modul de lucru al strategiei GrowthFunction.
min.percent: fracţiunea (partea) valorii percepute din preţul unui bun de la care agentul va începe să liciteze
no.evasion: diferenţa de preţ considerată a fi neseminifcativă de către agent. Când preţul oferit este mai mare decât preţul de licitare dar în intervalul 'no quibble' atunci oferta va fi acceptată. Această soluţie evită derularea mai multor runde de negociere pentru nişte mărunţiş (utilă când se timpul este foarte scurt).
max.percent: fracţiunea (partea) valorii percepute din preţul unui bun până la care să mai negocieze. agentul este dispus
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 asemănător cu procesul care îl dotează cu abilitatea de a face oferte. Pentru început se specifică protocolul care descrie rolul vânzătorului(furnizorului) într-un dialog de negociere.
Atunci, acest proces implică echiparea agentului cu un protocol de iniţiere prin selectarea Fipa-Contract-Net-Contractor din tabelul „Coordination Protocols‟. Implicit câmpul Mode din tabelul „Coordination Strategies‟ va fi bifat, lucru ce indică aspectul că această strategie va fi folosită împreună cu faptele descrise în câmpul Fact Type. Deoarece acest câmp conţine ZeusFact (FapteZeus) această strategie va fi folosită pentru a vinde fapte de orice tip. In specificaţii nu este menţionat faptul că agenţii vor folosi strategii specializate pentru interacţiuni particulare, de aceea câmpurile Agents şi Relations vor rămâne neschimbate.
Am selectat functia DecayFunction din lista strategiilor disponibile si am setat parametrii care indică modul în care această strategie rulează:
min.percent: fracţiunea (partea) din valoarea unui bun care s e scade din preţul său. Valoarea obţinută reprezintă preţul minim pe care îl va accepta pentru un produs vânzătorul. Acest factor va dicta agentului marjaminimă de profit, iar dacă aceasta este peste sub 100% atunci agentul poate vinde produsul cu mai puţin decâtvaloarea percepută. no.quibble: diferenţa de preţ considerată de agent a fi nesemnificativă. Când o ofertă de preţ este mai micădecât un preţ solicitat dar în intervalul 'no quibble' atunci oferta va fi acceptată. Se evită astfel runde denegocieri pentru sume mici bani. max.percent: fracţiunea (partea) din valoarea unui bun care se adauga la preţul său. Valoarea obţinută reprezintă preţul 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 agenţi utilitari vor fi creaţi şî modul în care vor fi configuraţi. Din interfaţa principală deschideţi instrumentul Code Generator. Se va afişa planul de generare (Generation Plan) şi anume agenţii care vor fi creaţi când s e va executa generarea de cod. Se poate observa că pe lângă cei 3 agenţi creaţi până acum (Owner (Seller ),Client (Buyer ) and
EstateAgent) mai sunt şi Name Server, Facilitator şi Visualiser. Deoarece cei 3 din urmă îndeplinesc cerinţele iniţiale nu mai este nevoie să mai adăugăm încă unul de vreun tip.
Pentru configurarea parametrilor de rulare pentru aceşti agenţi, am deschis tab-ul 'Utility Agents' şi am completat astfel: Agent Name Server
Schimbat numele în ANS. Adresa IP în câmpul Host va fi implicit adresa calculatorului (presupunând că aici va rula şi serverul). Deoarece există un singur NaemServer acesta este marcat ca fiind “root” şi oferă valoarea pentru câmpul “time -grain”. Această valoare se pote schimba însă 0.5
este o valoarea potrivită pentru această aplicaţie. Se va presupune pentru simplitate că toţi agenţii vor fi rulaţi din acelaşi director, de aceea în câmpul Address File nu trebuie trecută o cale ci doar un nume de fişier. Valoarea introdusa a fost dns.db (acesta oferă numele fişierului în care Name Server îşi va scrie locaţia). Facilitatorul
Se presupune că Facilitatorul va rula pe aceeaşi maşina ca şi serverul, prin urmare c âmpul
Host nu trebuie schimbat. Câmpul DNS file conţine calea şi numele fişierului care conţine locaţia serverului. Câmpul trebuie să aibă acelaşi conţinut ca şi câmpul 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
Câmpul Host poate rămâne neschimbat iar câm pul DNS File trebuie să conţină aceeaşi valoare ca şi campul Address File de la Name Server.
Configurarea realizată pentru agenţii utilitari
3.4 Configurarea agentilor task Agentul 'Seller' /’Buyer’ / ‘EstateAgent’ : - se presupune că va rula pe acelaşi calcualtor ca şi agenţii utilitari (va avea acealşi Host) - câmpul DNS File trebuie să conţină aceeaşi valoare ca a câmpului Address File de la Name Server.
Conform proiectării noastre, resursele agenţilor por fi reprezentate în mod intern şi nu este nevoie să
fie obţinute din baze de date externe. De aceea câmpul Database External poate fi lăsat liber pentru toţi agenţii.
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/
