Universita degli studi di Genova

Facolta di ScienzeMatematiche FisicheeNaturali

Corsodi Laurea in Inf ormatica

Anno Accademico2000/2001

Tesidi Laurea

D-CaseLP: un ambientedistrib uito perl’integrazione di Agenti Eterogenei.

CandidatoRiccardo Albertoni

RelatoriProf. Maurizio Martelli

Dott. Viviana Mascardi

CorrelatoreProf. Maura Cerioli

2

A Sandro, chemi ha insegnatol’ottimismo.A nonnaMariuccia,chemi insegno a saliresui ciliegi.

Ringraziamenti

Iniziamocon i ringraziamenti“Tecnici” a colorochemi hannoaiutatonella rea-lizzazionedi questolavoro.

Ringrazioil professorMaurizio Martelli per la disponibilita chemi hadimo-strato.

La dottoressaVivianaMascardi,perl’aiuto fornitomi eperaver fattol’impos-sibile peressercinonostantei suoi“improrogabili” impegni damamma...

A suomaritochesuomalgradosi e piu volte trovatonel ruolo di tramiteframeeViviana.

StefanoMiglia perle preziosediscussioni.

Veniamooraalle personechein questiannihannoallietatola mia permanen-zaal DISI, senzale quali forseoggi nonsareiqui a scriverei ringraziamenti.Inordinepiu o menosparso..

Alle mie dueamichetteMarina e Stefaniaun ringraziamentoparticolareperaver sopportatoin questianni i miei voli pindarici, aver studiato,discusso,liti-gato,e cucitocappotticappottinicamicetteecc. Non scordero facilmente(e quici sonogli estremiper unacausadi risarcimentoper dannibiologici a Gerry) ipomeriggi,i sabati,e le domenichemattinapersia cercaredi capireseduefrasiin unostessofoglio di appuntifosseroli percasoo perche nellatestadi qualcunoeranoin unaqualcherelazione...

A Sir, peravercondiviso insiemeanoi partedeipomeriggidi cui sopra,perlasuaprecisionemaniacalechenongli impediscedi sembrareunpersonaggiouscitodaun libro di Lewis Carroll ...

2

A Paolo(Paolino)eEmanuele(Emma)perla dedizioneconla qualeriesconoa sopportarele mie amichettee svolgerecontemporaneamenteun lavoro social-menteutile ...

A Monicaperesserela giovanemarmottadi sempreedunadellepocheper-soneal qualesi puo “darela schiena”estarepiu tranquilli di quandoci si volta lespalleallo specchio.

Al Bradiperessereil testonedi sempre,compagnodi moltediscussioni,innu-merevoli pausesulsensodell’esistenzaedunadellepochepersonepiu confusedime.

Alla Lorella fedelespallaquandole discussionicon il bradipodiventavanoimpossibili ...

Ad Andrea,peraverealmenoprovatoadessereun po’ piu diplomaticoconilrestodel mondoe nonostantei risultati nonessersiscoraggiatodel tutto ... a Da-nielaperaver redattoil libretto di istruzionisuAndreain 100semplicifascicoli,anchesetemochenessunoavramaine il tempone la vogliadi leggerli...

A Danielaperla suarisatasolareadEmilio perla suasilenziosatimidezza,adentrambiperessereunasplendidacoppia(nonsi offendanogli altri, e solo l’en-nesimotentativo di conquistareunasediain primafila davanti al megaschermo...lo sapetechealtrimentinonci vedo!!!)

A Milena per le imitazioni dei professorie la perseveranza;a Carla perchenon ho mai avuto voglia di ucciderlaanzi pensavo chefosseil contrario;Ileanaperessere“bastardadentro”e nasconderlodiscretamentebene;a Cristianoperlasuasensibilita, le battuteirripetibili edessersiaddossatogranpartedell’esercita-zionedi ROGA; a Lucae Elisabettaperesserei miei “gemelli”(per loro fortuna)eterozigoti.

Un grazieedun salutospecialeagli amici dellapausapranzo/caffe checonlaloro compagniahannosaputorenderepiacevoli questiultimi mesi(in ordinespar-so): Alberto, Ponta,Biagio, Olcese,Mister, Depra,Lollo, Luisa,ElenaC., ElenaB., Giada,DanielaP., Maraedi suoiripascimenti,Flavia ...

Ai “colleghi” dello CSITA che hannofatto di tutto per farmi sentirea mioagiodurantele mie “collaborazioni”, in particolare,Barbaraper la suaamicizia,la grandespontaneita e tutto cio chemi ha insegnato;Claudiaper la suagenti-lezza;Mauriziaper tutte le risatee le lezioni di depilazione(un giornodi questi

3

mettero in praticatutti i suoi insegnamenti...); Luisaper la fiduciaaccordatami;Beppeperi discorsisullapolitica;Fabioperi CD; Domenicoperavermiconcessola suapostazione.

Veniamoa chi pur restandoal di fuori dell’universita ha contribuito al rag-giungimentodi questoobiettivo incoraggiandomie sopportandoil mio nonfacilecarattere.

I miei genitoriperavermi lasciatosempregrandeautonomiaedavermi finan-ziatoin questalungaimpresa.

Mio fratelloMaurizio,presenzamoltosilenziosamanonperquestomenoim-portante.

Maura,la mia “sorellaadottiva”, peresserela personachein assolutoconoscemeglio il me cheero e per essermistataaccantoquandole cosemi eranomenochiare...

Alessandra,peravermi regalatoa Sienaunadellegiornatepiu belledellamiavita edavermi rassicuratosullemievite precedenti...

I coniugiBinelli perla grandeospitalitae le bellissimegite in montagna.

Gianper il litro di birra a Bellaria ... a pensarcioravedoancoratutto girare,Cristianoe Patriziaper la loro importanteamicizia. Un ringraziamentoancheadAlessio,Fabio,Leo,Tony, Quikkia,Monte,Valle,Fedeetutti quelli cheperlungotempoho frequentatonellavecchiacompagnia.

Infineringraziola prof.ssaCarlaFerrettoperavermisconsigliatol’iscrizionealettere;chiunqueavra occasionedi leggerequestatesipotra infatti rendersicontoquantoio ignori l’arte dellascritturaequantopreziososiastatoil suoconsiglio...

4

Indice

Intr oduzione 1

1 Il contesto 51.1 Agenti esistemimulti-agente. . . . . . . . . . . . . . . . . . . . 5

1.1.1 Definizionedi agente. . . . . . . . . . . . . . . . . . . . 61.1.2 Definizionedi SistemaMulti-Agente(MAS) . . . . . . . 6

1.2 CaseLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2.1 La concettualizzazionedegli agenti . . . . . . . . . . . . 71.2.2 Unagerarchiadi astrazionedi concetti. . . . . . . . . . . 91.2.3 La metodologiadi sviluppo . . . . . . . . . . . . . . . . 11

1.3 Il progettoD-CaseLP . . . . . . . . . . . . . . . . . . . . . . . 141.3.1 Assunzioni . . . . . . . . . . . . . . . . . . . . . . . . . 141.3.2 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . 181.3.3 Lineeguidametodologiche. . . . . . . . . . . . . . . . . 231.3.4 Un FunctionRefinementTreeperD-CaseLP . . . . . . . 271.3.5 Un’interfacciaastrattaperfar comunicaregli agenti. . . . 311.3.6 Dallespecifichein Ag-UML all’esecuzionein D-CaseLP 32

2 Valutazionedi CORBA per realizzare MAS 362.1 CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.1.1 ObjectManagementArchitecture(OMA) . . . . . . . . . 372.1.2 Terminologiain CORBA . . . . . . . . . . . . . . . . . . 382.1.3 La comunicazionetraclienteserver in CORBA . . . . . 412.1.4 ServiziCORBA . . . . . . . . . . . . . . . . . . . . . . 42

2.2 Primodesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.2.1 Funzionalitadafornirenell’immediato . . . . . . . . . . 432.2.2 Comerealizzarela comunicazionetraagentivia CORBA 452.2.3 Configurazionedegli agentiprototipaliperl’esecuzionee

simulazione. . . . . . . . . . . . . . . . . . . . . . . . . 482.2.4 Funzionalitaaggiuntive . . . . . . . . . . . . . . . . . . . 502.2.5 Considerazionidi valutazione . . . . . . . . . . . . . . . 53

5

2.2.6 Conclusioni. . . . . . . . . . . . . . . . . . . . . . . . . 54

3 FIPA 563.1 Introduzionealla FIPA . . . . . . . . . . . . . . . . . . . . . . . 56

3.1.1 Fattori daiquali scaturiscelo standard. . . . . . . . . . . 573.1.2 Assuntieprincipi nellaproduzioneFIPA . . . . . . . . . 583.1.3 La portatadellespecificheFIPA . . . . . . . . . . . . . . 593.1.4 OrganigrammadellaFIPA . . . . . . . . . . . . . . . . . 623.1.5 Il processodi produzionedello standard. . . . . . . . . . 63

3.2 OrganizzazionedellespecificheFIPA . . . . . . . . . . . . . . . 653.3 Architetturaastratta. . . . . . . . . . . . . . . . . . . . . . . . . 66

3.3.1 Tipo opacoediscrizioneai servizi . . . . . . . . . . . . . 673.3.2 Cosaspecifical’architetturaastratta . . . . . . . . . . . . 683.3.3 DirectoryServices . . . . . . . . . . . . . . . . . . . . . 703.3.4 MessaggieMessageTransportServices. . . . . . . . . . 713.3.5 Esempiodi comunicazione. . . . . . . . . . . . . . . . . 74

3.4 Specificadellagestionedegli agentiFIPA . . . . . . . . . . . . . 753.4.1 Un modellodi riferimento . . . . . . . . . . . . . . . . . 753.4.2 Il nomedegli agenti . . . . . . . . . . . . . . . . . . . . 773.4.3 Il DirectoryFacilitator . . . . . . . . . . . . . . . . . . . 783.4.4 AgentManagementSystem . . . . . . . . . . . . . . . . 793.4.5 Ciclo di vita degli agenti . . . . . . . . . . . . . . . . . . 81

3.5 Le ontologie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833.6 ProgettiFIPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843.7 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4 Inclusionedel framework FIPA in D-CaseLP 884.1 Perche includerele specificheFIPA . . . . . . . . . . . . . . . . 88

4.1.1 AggiornamentodelFRT di D-CaseLP . . . . . . . . . . 904.1.2 Le platformaderentialle specificheFIPA . . . . . . . . . 91

4.2 JADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924.2.1 JADE Run-Time . . . . . . . . . . . . . . . . . . . . . . 934.2.2 Il modellodi sviluppodegli agentiJADE . . . . . . . . . 97

4.3 ImplementazioneattravesoJADE di D-CaseLP . . . . . . . . . . 1064.3.1 ComerealizzareconJADE i punti del FRT . . . . . . . . 1064.3.2 Ipotesiperl’utilizzo di JADE in D-CaseLP . . . . . . . 1104.3.3 Gli agentiAg-Java . . . . . . . . . . . . . . . . . . . . . 1124.3.4 Gli agentiAg-Prolog . . . . . . . . . . . . . . . . . . . . 1124.3.5 Iter dagli agentiprototipaliall’esecuzioneusandoJADE . 113

4.4 ConfrontotraJADE eCORBA . . . . . . . . . . . . . . . . . . 1134.5 Conclusione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

6

5 Agenti logici 1175.1 Agenti logici in CaseLP. . . . . . . . . . . . . . . . . . . . . . . 117

5.1.1 ProlAg . . . . . . . . . . . . . . . . . . . . . . . . . . . 1185.1.2 AgentRules . . . . . . . . . . . . . . . . . . . . . . . . 1195.1.3 CaseLP-MASadl . . . . . . . . . . . . . . . . . . . . . 1225.1.4

�������. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

5.1.5 HEMASL . . . . . . . . . . . . . . . . . . . . . . . . . . 1235.1.6 Il CaseLPVisualizer:un’interfacciagraficaperla simula-

zione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1235.1.7 Comandidi shellperl’esecuzionedellasimulazione . . . 123

5.2 ImplementazioniProlog . . . . . . . . . . . . . . . . . . . . . . 1275.2.1 Tipi di interfacceProlog-Java . . . . . . . . . . . . . . . 1285.2.2 tuProlog. . . . . . . . . . . . . . . . . . . . . . . . . . . 129

5.3 Utilizzo degli agentilogici nelmodellodi sviluppoD-CaseLP . . 1345.4 Analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

5.4.1 Obiettivi dell’integrazione . . . . . . . . . . . . . . . . . 1385.4.2 � ProlAg: linguaggiod’implementazione . . . . . . . . . 1395.4.3 UseCaseDiagramperl’estensionedi JADE . . . . . . . 142

5.5 Designdell’estensione . . . . . . . . . . . . . . . . . . . . . . . 1465.5.1 La concorrenzadegli agentiin JADE . . . . . . . . . . . 1465.5.2 Designdi agentilogici con tuPrologeJADE . . . . . . . 147

5.6 Considerazioniconclusive . . . . . . . . . . . . . . . . . . . . . 152

Conclusionee sviluppi futuri 154

7

Intr oduzione

Negli ultimi anniabbiamoassistitoadunasignificativacrescitadell’interessever-so le tecnologieinformatiche. Fattoredeterminantedi questofenomenoe l’af-fermarsidell’utilizzo della“rete”, tantoneicontestidellaproduzionequantonellavita di tutti i giorni. Si pensiadesempioacomel’avventodellarete,in particolaredel World Wide Webe dellapostaelettronica,abbiasignificativamentecambiatoil mododi lavoraree le abitudinidi unapartedellapopolazionecheviveneipaesiindustrializzati.

Allo statoattualela “rete” si ponecomeun’entita passiva: un enormeconte-nitore di “dati” eterogeneiin cui spessola ricercadelle informazionidesideratecomportadedicaremolto tempoa visionareinformazionichepocohannoa chefarecon quellecercate.Perevitare questosprecodi tempoc’e un crescentein-teressea superarela passivita della rete fornendoquelli chepotremmodefinirefunzionalita di nuova generazione.Tali funzionalita permetterannoagli utenti diaccedereadinformazionigia collezionatesecondoi loro interessi.Oggi e possi-bile usarela reteper fruire di un numerosempremaggioredi servizi,chevannodall’acquistodi libri adunaprenotazionedi un postoa teatroo di un viaggio,mae ancoraabbastanzadifficile unire servizi differenti o attuaredei confronti al difuori di quelli chesonostatigia esplicitatidai fornitori di informazione.

Versouna nuova generazionedi funzionalit a per la rete.

Vi e l’esigenzadi superarei limiti attualiecompletarequellacheestatala rivolu-zionedegli ultimi annichehaportatoacio chevienedefinitain terminialtisonanti”new economy”. Per far cio si stannoseguendoalmenodueapprocci. Il primosi basasu unastrutturazionedei “dati” disponibili in reteattraversol’utilizzo dimetalinguaggicomeXML [64]. Il secondoapproccio[51] sottointendel’idea diunasocietavirtualedi processi:unareteflessibiledi processisoftwareeterogeneiognunocon una propria conoscenza,una propria capacita di prenderedecisio-ni e di cooperarecon altri processiper il raggiungimentodi obiettivi intermedicomuni.

1

Le dueapproccinonsonoortogonalifra di loro: il successodellaprimo puoessereutile agli scopidellasecondo.

La tendenzanello sviluppo del software.

Allo stessotempoedin parteanchein seguitoaquesta“esigenza”di dovereacce-derea tutto ovunqueci si trovi, la produzionedel softwarecoinvolgeproblemati-chesemprepiu vaste.La tendenzaedi fornireunnumerosempremaggioredi fun-zionalitaaduninsiemedi utenticonconoscenzeedesigenzedifferenti.Pergestirela crescentecomplessitadeisistemisoftwarei progettistisi trovanosemprepiu adintegrarecomponentieterogeneegia realizzatepiuttostocheprogettarnedi nuovedacapo.Inoltre, la varieta di utentiai quali i softwaresonodestinaticostringonoadotarei prodottidell’intelligenzanecessariaadapparireuserfriendly.

La tecnologia adagenti [35], grazieall’alto livello di astrazioneacui si collo-ca(quelloalivello di cooperazionedellaconoscenzatrasistemiautonomi),risultaparticolarmenteadattaaprogettareapplicazioniconle caratteristichedescritteso-praedcomunitavirtuali; essaconsenteinfatti di modellareentitachecomunicano(dotatequindi di abilita sociali), chemonitoranol’ambientein cui si trovanoesonoin gradodi reagireagli eventi chesi verificano(capacita di reazione), so-no in gradodi prenderel’iniziati vasela situazionelo richiede(proattivita) senzal’interventoumanoo di altri agenti(autonomia). Societa compostedatali entitavengonodefinitesistemimulti-agente(MAS). Essecontemplanola distribuzionedegli agenticoinvolti e dei dati sucui operanoe l’integrazionedi softwaree datieterogenei.Questeduecaratteristichesonofondamentaliper il successodei si-stemisoftwaree sonounadelle ragioni per il consensoricevuto dai MAS sia incampoaccademicocheindustriale.

Nonostantel’interesseele prospettivecheil paradigmaadagentioffre vi sonoancoramolti problemidarisolvereprimachetaletecnologiasi affermi stabilmen-te. Innanzitutto vi e la necessita di individuaremetodologieefficaci e strumentidi sviluppocheaiutino la progettazionee lo sviluppodei sistemimulti-agenteinmodochetaletecnologiasiautilizzabilein ambitoindustriale.In secondoluogo,affinche sianosfruttateappienole potenzialita del paradigmaadagentie siapos-sibile costituirele infrastruttureperla creazionedi comunitavirtuali e necessariochel’applicazionedellemetodologiee dei tool di sviluppoportinoalla realizza-zionedi MAS in gradodi interagiretra di loro. Al fine di promuoverein ambitiindustriali il paradigmaadagentie l’interoperabilita dei MAS, la FIPA (Founda-tion for Intelligent PhysicalAgents)[23, 52] si e fattacaricodi unameritevoleiniziativadi standardizzazione.Taleiniziativahacomeobiettivo forniredellespe-cifiche liberamentefruibili che costituiscanoun punto di partenzaai differentiapproccie realizzazionidi sistemimulti-agente.

2

Strumenti emetodologieper lo sviluppo di sistemiMAS.

Giadatemposi lavoraperoffrire strumentiemetodologiedi supportoallo svilup-podi sistemimulti-agente;in questocontestoil gruppodi programmazionelogicaaveva sviluppatopressoil DISI di Genova uno strumentoper la prototipazionerapidadi sistemiadagentidenominatoCaseLP [40]. In talelavoro si fornivaunambientedi prototipazionebasatosullaprogrammazionelogicae si evidenziava-no i vantaggichetale paradigmaoffre nello studiodi soluzionibasatead agen-ti. Il presentelavoro di tesi nascedall’esperienzadi CaseLP e dall’esigenzadiestenderele funzionalita versoun ambientedi prototipazionedistribuito chesup-porti insiemeal paradigmalogico,strumentichegodanodi unacertapopolarita inambiti industriali.

Struttura della tesi.

Descriviamoin breve il contenutodei capitoli checompongonoquestodocumen-to.

Il capitolo1 puo esseresuddiviso in dueparti. Nella prima diamounade-scrizionedel contestodal qualee iniziato il lavoro, forniamouna introduzioneminimale ai concettidi agentee sistemamulti-agente(MAS), facendoseguireunaintroduzioneallametodologiaedal tool di prototipazioneCaseLP. Nellase-conda,seguiamole lineeguidametodologichepropostedaWieringa[62] e sullabasedi considerazionirelative al ciclo di vita del softwareedalle peculiarita deisistemimulti-agenteindividuiamol’insieme di requisiti di un nuovo tool per laprototipazionerapidadi sistemimulti-agente.L’insiemedi requisiti individuati eabbastanzaesteso,contenentefunzionalitachepotrebberoconsiderarsia livelli diastrazionedifferenti,perquestol’abbiamosuddiviso in duesottoinsiemirispetti-vamentedenominatiM-CaseLP eD-CaseLP. I duesottoinsiemipossonoesserevisti comedueprogettidistinti fortementecorrelatio comedueparti di un unicoambiziosoprogetto.In questatesiabbiamofocalizzatol’attenzionesulleproble-maticherelativeaD-CaseLP.

Nel capitolo2, presentiamoun sottoinsiemedei requisiti fra quelli previsti inD-CaseLP checostituiscecio che intendiamoincluderenei primi prototipi deltool. Le funzionalita sonotutte inerentialle problematichedella distribuzioneedellacomunicazionedegli agenti,quindi, illustriamoun primo studiodelladistri-buzionechevedel’impiego del middlewareCORBA [59] . In conclusionedelcapitolomettiamoin lucele difficolta chesi incontranonel fornire la distribuzio-nedegli agenticontaletecnologia.

3

Nel capitolo3, decriviamo le modalita concui la FIPA staportandoavanti illavoro di standardizzazione,illustrandole caratteristichee la portatadell’inizia-tiva. Presentiamoalcunespecifichecheoffrono interessantispuntiper il nostrolavoro econcludiamoconalcuneosservazionisull’iniziativa.

Nel capitolo4, dopoaver sintetizzatole ragionicheci spingonoadallinearcicon il lavoro FIPA, forniamola descrizionedi JADE [7]: un tool aderenteallaspecifichedi interoperabilita FIPA cheoffre un run-timeper l’esecuzionedistri-buita degli agenti. Tale framework si ponecomeun vero e proprio middlewareperagentiepartedaipotesivicineaquelleeffettuatein CaseLP. In conseguenzadi cio, si e studiatala possibilita di fornire le funzionalita previste in D-CaseLPutilizzandoquestonuovo strumento.Concludiamoil capitolocon un confrontotra il supportoai nostriobiettivi offertodaCORBA equellooffertodaJADE eil-lustrandole motivazionidi progettochehannoportatoasceglieredefinitivamenteJADE.

Nel capitolo5, descriviamole difficoltanell’integrazionedi agentilogici1 conil run-time JADE. PresentiamotuProlog [20] una particolareimplementazioneProlog chefornisceun’integrazionesoddisfacenteconJava, graziealla qualeepossibileeseguireagentilogici nellaplatformoffertadaJADE.

In conclusionedella tesi,si metterannoin lucequelli chesonoi contributi diquestolavoro al progettoD-CaseLP epresenteremogli sviluppi futuri.

1Si leggaagentilogici comesinonimodi agentiscritti in un linguaggiologico.

4

Capitolo 1

Il contesto

In questocapitolodopounabreve introduzionedei concettichestannoalla ba-sedel paradigmaad agenti,descriviamo il lavoro effettuatodal gruppodi pro-grammazionelogica di Genova all’interno del progettoCaseLP, illustrandolemotivazionichehannoportatoad unariformulazionedei requisiti nei termini diD-CaseLP.

1.1 Agenti e sistemimulti-agente

A lungo la comunita scientificache lavora nel campodegli agentisi e postailproblemadi dareunadefinizioneprecisae sufficientementecondivisadi agente.Purtroppo,a renderedifficoltoso tale compitovi e l’inerentemultidisciplinaritadegli studisugliagenti.I campineiquali il paradigmaadagentitrovafondamentosono

� Intelligenzaartificiale;

� Programmazioneadoggettiemetodologieassociate;

� Programmazioneconcorrente;

� Simulazionedi sistemi.

Le differentidefinizionisonoclassificatein strongo weakasecondachecaratte-rizzino gli agentiin termini “mentali” o meno.

Da qualchetempoa questaparte,il dibattito su cosae quali caratteristichedebbaavereun agenteper esseretale, e scematospostandol’attenzionesu pro-blematichedi ordinepiu pratico. La discussionepur non riuscendodel tutto adappianarei differenti punti di vista ha prodottoun insiemedi definizioni suffi-cientementeconosciutenellacomunita dei ricercatori. In questolavoro di tesi si

5

e sceltodi adottarele definizionidi agentee sistemaad agenti multipli propostein [35]. Il lettoreinteressatopuo trovarealtre definizioni e caratterizzazionidelconcettodi agentein [31, 12,32].

1.1.1 Definizionedi agente

Definizione1.1 Un agentee un sistemasu computer, situatoin un qualcheam-biente, capacedi agire in modoflessibile, autonomo,allo scopodi raggiungeregli obiettivi per il qualee statoprogettato.

In taledefinizionetroviamotreconcettichiave:

Situato: l’agentericeve stimoli dall’ambientee puo agiresudi essopermodifi-carloeffettuandoazioni.

Autonomo: l’agentee in gradodi agireprendendoiniziativa senzal’interventoumanoo di altri agentiavendoquindi il controllodel suostatoe dellesueazioni.

Flessibile: perrisultareflessibilel’agentedeveessere

reattivo: riceveregli stimoli dell’ambienteedesserein gradodi rispondereadessiin manieratempestiva1.

proattivo: non deve semplicementerispondereagli stimoli dell’ambiente,madoverichiesto,esibirecomportamentiguidatidaobiettivi.

sociale: deveesserein gradodi interagireconaltri agentiartificiali eumaniquandocio sianecessarioacompletareil propriocompito.

1.1.2 Definizionedi SistemaMulti-Agente (MAS)

Nello stessoarticolo da cui abbiamopresola definizionedi agente,troviamo ladefinizionedi sistemaad agentimultipli:

Definizione1.2 Un MAS puo esseredefinitocomeunaretedi risolutori (agenti)nonstrettamenteaccoppiatiche lavoranoinsiemeper risolvere problemioltre lepropriecapacita individuali o la conoscenzadeisingoli.

Il termineMAS e utilizzato per riferirsi genericamentea tutti quei sistemichesonocompostida componentisemi-autonomemultiple (agenti)cheinteragisco-no tra loro su principi di cooperazioneo competizionee presentanole seguenticaratteristiche:

1Primachela situazionenell’ambientecambiin manierasignificativaperl’agentestesso.

6

� assenzadi controllocentralizzatonel MAS;

� ogni agenteha un puntodi vista limitato; possiedeinfatti informazioniocapacita per risolverepartedel problemaalla cui risoluzionee prepostoilMAS;

� i dati sonodecentrati,suddivisi fra i differentiagenti;

� la computazionedegli agentie asincrona,gli agentisonoconcorrenti.

1.2 CaseLP

D-CaseLP e il proseguimentodi un progettoabbastanzaambiziosocondottodalgruppodi programmazionelogica del DISI di Genova che va sotto il nomediCaseLP[42, 41], il qualeoltre alla progettazionee realizzazionedi un tool perla simulazionedi sistemimunti-agentehavisto lo sviluppodi vari linguaggiperspecificareagentied unametodologiadi supportoallo sviluppatorenelle fasi dianalisie design. Il tool di sviluppoCaseLP pur fornendounadistribuzionelo-gicaerafisicamentecentralizzato.Gli obiettivi di D-CaseLP sonoin granparteun’estensionedel progettoprecedente,nelladirezionedi unadistribuzionefisicadegli agenti.Al finedi far comprenderel’ottica nellaqualeD-CaseLP trovafon-damento,riportiamoqui alcuneparti dellatesi [18], cheillustranoi concettibasein CaseLP. La sezione1.3 illustrera le estensionia tali concetti.

1.2.1 La concettualizzazionedegli agenti

Un agentein CaseLP puo essererappresentatodaduediversipuntidi vista.Daunpuntodi vistadescrittivo,unagenteecaratterizzatodaun’architetturaedairuoli cheessoricopree,di conseguenza,daun insiemedi servizi.L’architetturasi riferisceallastrutturainternadell’agente.Un’architetturaspecifi-casiala strutturadaticheneformale componentiinternecheil flussodi controllocheguidal’attivitadellecomponentistesse.I ruoli possonoessereconsideratidaduepuntidi vista: comeun insiemecoerentedi servizio comele “impersonificazioni”cheun agenteattuanel corsodellasuaesistenza.Ad esempiounagenteattoallacompravenditaricopriraalternativamen-te il ruolo di acquirenteedi venditore.I servizidefinisconofunzionalitachel’agente,o meglio unruolo,fornisceo neces-sitapersvolgereil propriocompito.I servizidipendonotipicamentedal dominiodell’applicazionedel prototipo.

Nel seguito considereremounagentecomeunaentitacaratterizzatada

7

� unostato;

� un programma;

� un engine.

Lo statocontienele informazioniche,durantel’esecuzionedell’agente,possonosubiremodifiche. Ad esempio:un agenteche percepiscee gestisceeventi in-serendolie prelevandoli in/da unaeventqueue,e le cui informazionisul mondosonorappresentateda credenze,avra uno statocheconterra la event queuee lecredenze.

Il programmacontienele informazionichenoncambianodurantel’esecuzio-ne.Peril sempliceagentedescrittosopra,il programmapotrebbeesserecostituitoda un insiemedi regole chedescrivono quali azioni eseguire in funzionedi uneventoe delle credenzecorrenti. Le azioni cheun agentepuo eseguire sonodisvariatanatura,e potrebberocomprendereadesempioaggiornamentidello stato,azionisull’ambienteecomunicazioniconaltri agenti.

L’engine,infine, governal’esecuzionedell’agente.Sempreriferendosiall’e-sempioprecedente,un tipico enginepotrebbeestrarreun evento da una coda,operarela sceltadi unaregolaadattaa gestirel’eventoe chesiaapplicabilenellostatocorrente,edinfineattuarel’esecuzionedi tuttele azioniindicatenellaregola.Va notatocomel’engineedil programmasi collochinoa duelivelli di astrazionediversi: l’engine rappresentainfatti un meta-interpreteper il programmae per idati (stato)sucui il programmaopera.

La applicazionedelleistruzionidell’engineallo statoedal programmadell’a-gentenedeterminanoil comportamento.L’architetturadi unagentedeveconsen-tirnela rappresentazioneneiterminisopradescritti.Essasaraquindicaratterizzatadacomponentichecontengonolo stato,componentichecontengonoil program-ma,e daun enginecheoperasuquestecomponenti.L’assunzionechefacciamosullecomponentichecontengonolo statoechetraesseci siaunamailboxchecon-sentala comunicazioneasincronatra gli agenti. Ogni agentecheconsidereremoavra quindiunaarchitetturachespecializzeraquelladescrittain Figura1.1.

Dueagentipossonoaverele stessecomponenti,contenentigli stessidati, maenginediversi, oppurepossonoavere lo stessoenginee le stessecomponenti,contenentipero dati diversi. In entrambii casi il comportamentodegli agentirisultera in generaledifferente.

Il contenutodelle componenti,caratterizzantelo statoed il programmade-gli agenti,sara espressoin un linguaggiooggettodipendentedalla architettura;l’enginefornira un interpretepertalelinguaggio.

Agenti cheinteragisconotra di loro conle caratteristichedettesoprapossonoesseredescrittiin CaseLP adifferentilivelli di astrazione,usandoi differentilin-guaggie strumentiforniti dall’ambiente.Un Metodoguidal’utentenei vari passi

8

Mailbox

State Program

Engine

Figura1.1: Architetturagenerale.

della prototipazione,dalla descrizioneinformaledell’applicazioneallo sviluppodi un prototipofunzionale. In ogni fasel’utente puo adottareil linguaggioe lostrumentopiu adattotraquelli forniti.

1.2.2 Una gerarchia di astrazionedi concetti

Al fine di permettereunamaggioremodularita e flessibilita nella definizionediagentieterogeneiintroduciamounagerarchiadi livelli di astrazione,illustratainfigura1.2.

� Architetturaastratta. La architetturaastrattadefiniscele componentie lastrutturadi basedell’engine.Perogni macro-istruzionepresentenell’engi-ne e possibilefornire indicazionisui possibili modi per realizzarla,senzanecessariamentearrivareadun livello di dettaglioparagonabileadunaim-plementazione.E possibilestabilireunagerarchiadi architettureastratteincui dettagliarein modoincrementalele architetturecheverrannoutilizzateall’interno del MAS, senzapero arrivarea dettagliimplementativi. Ripren-dendoancorail sempliceesempiodescrittosopra,unaarchitetturaastrattaperl’agentedovrebbeprevedere

– unacomponentepercontenerele credenze;

– unacomponenteperla eventqueue;

– unacomponentepercontenerele regolechedefinisconoil programma.

9

Domain

specificationdependent

Domainindependentspecification

arch.Abstract

Concrete Concrete arch. arch.

Agent class

Agent class

instanceAgent

instanceAgent

Figura1.2: La gerarchiaarchitetturalein CaseLP.

L’enginepotrebbeesserequellogiadescritto,compostodalleseguentimacro-istruzioni

1. estraiuneventodallastrutturaeventqueue;

(a) scegli una regola per gestire l’evento, in baseanchealle credenzecorrenti;

(b) esegui tuttele azioniindicatedallaregola.

La macro-istruzionedell’engine“scegli unaregolapergestirel’evento”potrebbeessererealizzatain modi diversi:

1. scegli acasounaregola;

(a) verificachela testadellaregolasiaugualeall’evento;

(b) verifica che le condizioni sulle credenzeespressenella regola sianosoddisfatte;

10

(c) se entrambele verifiche hannosuccessorestituisci la regola scelta,altrimentiritornaal punto1.

oppure,unaltrasceltapotrebbeessere

1. costruiscil’insiemedi tuttele regoleapplicabili;

(a) restituiscila regolache,tra queste,prevedeil minor numerodi azionidaeseguire.

A suavolta costruiscil’insiemedi tutte le regoleapplicabili potrebbeespandersiin altreistruzioniadalto livello: nonsi pongonolimiti sul livello di annidamentodelledefinizionidellemacro-istruzioni.

� Architetturaconcreta.Unaarchitetturaconcretasi definisceapartiredaunaarchitetturaastrattanel seguentemodo:

– adognicomponentesiassociauntipo traquelli previsti dallinguaggio;

– perogni istruzioneadalto livello contenutanell’enginesi sceglie unadellepossibiliindicazionisucomerealizzarla(setali indicazionisonofornite)e senedaunaimplementazioneconcreta.

Ad esempio,sipotrebbestabilirechele credenzedi un agentesonoconte-nutein unastrutturadati di tipo insieme,mentrele regole sonocontenutein una lista. La event queuesara ragionevolmenteimplementatacon unacoda.Inoltre si dovrebbesceglierecheinterpretazionedare,tra quellepro-poste,alla istruzionescegli una regola, e si dovrebbeinfine fornirne unaimplementazionecoerenteconle indicazionifornite.

� Classedi agente.Unaclassesi definiscea partiredaunaarchitetturacon-cretaistanziandole componenticontenentiil programmadell’agente.Talicomponentisarannodefinitea livello astratto.

� Istanzadi agente.A partiredaunaclasse,si completala istanziazionedellecomponentidellaarchitetturadefinendoil contenutoiniziale dellecompo-nentichecontengonolo stato.

1.2.3 La metodologiadi sviluppo

1. Descrizionearchitetturale statica del prototipo.Lo sviluppatoredeterminala strutturastaticadel MAS. Questopassovieneulteriormentesuddiviso in:

11

(a) Determinarequali ruoli sononecessariall’interno del sistemastudia-to. Tali ruoli sonoinsiemilogici di servizi,chesuggerisconofunzionicomplessechegli agentipresentinelsistemasi troverannoaricoprire.

(b) Stabilirei legamidi soddisfacimentodeiservizitra i ruoli, questofor-nisceunprimo legamedi comunicazionetragli agentiche,in seguito,ricoprirannotali ruoli ;

(c) Stabilireedefinirele necessarieontologie,ossiale specifichedeicon-cetti utilizzati nel dominoapplicativo, necessarioper stabilirein ma-nieraunivocail significatodeimessaggiscambiatiall’internodelMAS.

(d) Raggrupparei ruoli in classidi agentistabilendocosı quali classidiagentisononecessarieall’internodell’applicazione;

(e) Per ciascunaclasse,determinareil tipo d’agente,la suaarchitettu-ra e gli interpretieventualmentenecessari;l’architetturapuo fareri-ferimentoad unagia disponibilein una libreria o essereuna nuovaarchitetturachedebbaancoraesseredefinita;

(f) Determinareil numerodi istanzedi ogni classechesononecessariealla realizzazionedel sistema(ove epossibilestabilirloapriori);

(g) Definire, dove necessario,le interconnessionitra le varie istanzediagentee stabilirei legami tra servizi richiesti edofferti quandoe ne-cessariodifferenziareo specificarea livello di istanza.Questafasede-finiscegli agenticheformanoil prototipoedi canalidi comunicazionetraessi.

2. Indi viduazionedei protocolli di comunicazionetra agentiIl secondopassodellametodologiaconsistenellostabilireedescriverei pro-tocolli di comunicazione(oconversazioni)perciascuncanale,ossiaunlega-metra l’agentecherichiedeunservizioequellochelo fornisce(siaalivellodi ruolo, classeo di istanza)stabilito in precedenza.Un protocollopuo es-sereunistanziazionedi unprotocollogenericoo essereunnuovo protocollodefinito ad hoc. Un protocollostabiliscel’ordine e la forma dei messaggicheverrannoscambiati.All’interno di ciascunprotocollopotrannoesseredefiniti sub-protocollio comportamenticomplessi(scelte,messaggiin pa-rallelo...).Il modellodi conversazionedelMAS includel’insiemecompletodi tutteconversazionistabilitee le eventualirelazionidi sub-conversazione.

3. Specificaad alto livello del sistemaedegli agenti.A questopunto un linguaggio di definizionead alto livello e usatopermodellareil prototipo. Tre diversi livelli di modellazionepossonoessereindividuati:

12

(a) Specificadelle interazionitra gli agentiall’interno del MAS, astraen-do dallaloro architetturae tenendoin considerazioneil modellodelleinterazionispecificatoal passo2;

(b) Specificadella nuova architetturasceltaduranteil passo1, cioe mo-dellarele interazionitra le componentiinternedell’agente;

(c) Specificadelcomportamentodell’agente.

4. Verifica e testingdel sistema.In questopassovieneeffettuatala verifica e/o la validazionepreliminaredella specificaastrattaeffettuataal punto3. La validazionee possibileseil linguaggiodi specificae eseguibile. La verifica e invecepossibilese illinguaggiodi specificausatometteadisposizioneunmeccanismodi prova.Sela specificae statafattautilizzandoun linguaggiologico,un’esecuzionegoal-directede un meccanismodi prova valido. In questocaso,dataunaspecificadelprototipoedunaconfigurazioneinizialedelsistema,epossibileseguirel’evoluzionedi unMAS in dettaglio.E altresı possibileverificareseunaparticolarecomputazionedel sistemapuo essereeseguitao, cosaancorpiu importante,cheogni computazionecheinizia in particolarestatoportiadunostatofinalechesoddisfile proprieta ricercate.

5. Implementazionedel prototipo.Questopassotrasformala specificaastrattadelsistemanel prototipofinale.Un linguaggiodi programmazionelogica estesoviene usatoper l’imple-mentazionedel prototipo. Le interfacceversomoduli software esterniodati sonofornite utilizzandointerpreti appropriati. Inoltre lo scambiodimessaggiper le comunicazionied altri dettagli implementativi cheprece-dentementeeranostati descrittiastrattamenteo non eranostati del affattoconsideratisonoorarealizzati.

6. Esecuzionedel prototipo ottenuto.L’esecuzionedelprototipoottenutoeusatapervalidareil prototiposecondole richiestedeiclienti. L’esecuzionefornisceagli utentiedagli sviluppatoriinformazionisuglieventicheaccadononelMAS, epermetteadessidi con-trollareseil prototiposi comportanellamanieraattesaesepossiedetuttelecaratteristicherichieste.Ogni erroreo malfuzionamentoscopertoin questopassopuo implicareunarevisionedi unaqualunquedelle fasi precedentidellametodologiaadottatadaCaseLP.

Possiamoquindi distingueretre fasiprincipali all’interno del metodoadottatodaCaseLP. I passidall’1 al 4 formanola fasedi modellazione.Il passo5 rappresentala fasedell’implementazionee il passo6 quelladell’esecuzione.

13

1.3 Il progettoD-CaseLP

Si e gia detto che D-CaseLP nascedall’esigenzadi estendereil progettoCa-seLP, buonapartedei contenutiteorici presentiin D-CaseLP sonofrutto di taleesperienza.Le personeattualmentecoinvoltenel progettoD-CaseLP sono,oltreal candidato,StefanoMiglia edAlessandroRolandorispettivamenteconunatesidi laureaedunadi diplomae VivianaMascardi,con la tesi di dottorato”Logic-BasedSpecificationEnvironmentsfor Multi-Agent Systems”.Il professorMau-rizio Martelli coordinail gruppodi lavoro. La finalita del progettoe creareunostrumentocheaiuti la progettazione,prototipazioneerealizzionedi sistemimulti-agente.Purtroppo,perquelcheriguardail tool, sin dal principio si e intesoche,consideratal’esigenzadi sostituireil linguaggioProlog conlinguaggiestrumenti(Java, CORBA) piu vicini alla realta industriali, difficilmentesi sarebberiusci-ti nell’intento di recuperareil codicegia esistente.La complessita legataallosviluppodi un nuovo software,e la suddivisionedel lavoro in piu tesi ha postol’esigenzadi adottareunametodologiadi progettazione.Vista la scarsaforza la-vorodi cui disponevamo,si e sceltodi seguirele lineemetodologicheillustratein[62] piuttostocheunaverae propriametodologia.Ci siamoavvalsi di tali lineemetodologicheessenzialmentenellafasedi analisidei requisiti,perfissarele ca-ratteristichepotenzialiepoterciriferire adessein corsodi discussione.2 L’analisie statafattatentandodi pensare“in grande”,senzapreoccuparcidi cosapotesseeffettivamenteessereportatoa terminenellenostretesi,e checosano. L’ideaeradi tentared’individuarecosaun tool caseperagentidovesseoffrire.

1.3.1 Assunzioni

Illustriamoquali sonole principali assunzionichehannoguidatola progettazionedel nuovo framework. Il leitmotiv checaratterizzale scelteprogettualioperatein D-CaseLP e, perquantopossibile,evitarequelleipotesichein qualchemodopossanolimitare la genericitanell’impiegodel framework prodotto.

Quale ciclo di vita per lo sviluppo di sistemiMAS?

Perrealizzareunostrumentochesiarealmentedi aiutonellaprogettazionedi si-stemimulti-agente,e importanteaverpresentequalisianole problematichelegatealla specificae sviluppodi sistemibasatisu agenti. Altrettanto importantefareattenzioneal contestonel qualegli utilizzatori del tool realizzanoil software. Aquestoscopo,e beneporsile seguentidomande:

2Avendogia fattonotarechesi trattadi lineemetodologichenel seguito ci riferiremoadessesemplicementeconla metodologiaWieringao la metodologia.

14

� Chi sonogli utentidel framework chestiamoprogettando?

� Qualemodellodi sviluppoe ragionevole per il softwarecheil frameworkdovrebbeaiutareasviluppare?

Nonostanteun crescenteinteresse,mostratoin particolaredaaziendedi tele-comunicazioni,e la realizzazionedi un certonumerodi casistudio,il paradigmaad agenti e relativamentegiovane. Non vi e ancoraun’applicazionedelle tec-nologiead essoispiratetale da permetteredi delinearecomee con quali figureprofessionalisi lavori ad un MAS; ne vi sonodomini in cui l’impiego di taletecnologiasiasufficientementeaffermatodapermettered’individuarecomprovatipatternrisolutivi. Tutto cio rendedifficile faredelleassunzionicircachi sianoocomepossanolavorarei potenzialiutentidi D-CaseLP. La mancanzadi standardaffermati limita l’utilizzo del paradigmaadagentinegli ambiti industriali,spessoconfinandoloa progettidi ricerca. Perquestosembraragionevole pensarecheicontestineiquali taletecnologiavengaapplicatasianocaratterizzatidaproblema-tichenuove, le cui soluzionirichiedanoun alto contenutoinnovativo. Si presumeinfatti chesi impieghi unatecnologiagiovanela dove le piu comprovatetecnicherisultino insoddisfacenti.

La risoluzionedi problematicheinnovative,presupponerequisitinuovi; in talifrangentispessonone facile individuaree mantenerestabili i requisitidurantelaprogettazione.Necessitiamoquindidi unmodellodi svilupponeiqualei requisitiiniziali possanoessereparzialmentedelineati,percui sianecessariala produzionedi alcuni prototipi a fine esplorativo. Sulla basedi tali considerazioniabbiamodecisodi ipotizzarechei progettiin cui vengonoutilizzati gli strumentichestiamoprogettandoseguanounmodellodi svilupposimileaquello“a spirale”introdottodaBohemnegli anni’80. Talemodelloprevedepiu iterazioni3 in cui si susseguonofasidi progetto,analisi,prototipazioneevalutazione,comeillustratoin figura1.3.

Analizzandola schematizzazionedel modelloa spiralepartendodal centroeseguendola lineafino alla partepiu esterna,si puo notarechele primeiterazioniportanoalla definizionedi prototipi, mentrele iterazionipiu esterneconsistononel raffinamentodei prototipi fino alla realizzazionedel prodottofinale. In figuravi sonoquattroiterazioni,manulla impediscedi prevederneunnumeromaggiore.La definizionedi prototipi permettedi effettuareun’analisi”incremetale”,parti-colarmenteutile in progettiin cui perla naturastessadelproblemao del dominioapplicativo in cui si lavora, sia difficile individuarei requisiti. CaseLP eraunambientedi prototipazionerapida,e quindi forniva gia gli strumentiper effet-tuareunaanalisiincrementale.Cio di cui nonsi disponeva in CaseLPeranoglistrumentiper raffinareil prototiponel sistemadefinitivo. In altre parole,non si

3Coniterazionisuintendeun giro completoneiquattroquadranti.

15

Figura1.3: Modello aspiralepropostodaBohem.

andava oltre la realizzazionedei prototipi. In D-CaseLP si e cercatodi estende-re il supportoalla progettazioneanchenellefasisuccessive alla realizzazionedelprototipo,accompagnandol’utentefino alla realizzazionefinaledel progetto.

Ipotesi minimali sull’ar chitettura degli agenti.

In letteraturasonostatepropostediversearchitettureper agenti. Seci riferiamoalla concettualizzazionedescrittain 1.2.1,un’architetturaper agentedefinisceilformatoe le strutturedati astratteper stato,programmaed engine. Le svariatearchitetturefornisconodifferenti specifichedi tali componenti,dandoluogo adagenticon diversepeculiarita. In generalesi possonosuddivideregli agenti indeliberativi, reattivi,e ibridi. Consideriamole definizioniillustratein [63].

Definizione1.3 Un agentevienedettodeliberativo qualora mantengauna rap-presentazionelogicadell’ambientein cui esituato;dellaconoscenzaprocedurale,degli obiettivi,e sulla basedi essieseguadei ragionamential finedi determinarele sueazioni.

16

Definizione1.4 Un agentevienedettoreattivoqualora non mantengauna rap-presentazionesimbolicadi ambiente, credenzeedobiettivi. Nonavendotale rap-presentazionee impossibilitatoa ragiornarci sopra. Il comportamentoorientatoagli obiettivi e unaproprieta emergente, determinatoda regoleche diconocosafarequandoarriva uncertoinput.

Esistonopoi architetturedi tipo ibrido cheunisconole caratteristichedelledi-versetipologie.Perottenerecio, in generale,si struttural’agentein unagerarchiadi livelli. La gerarchiapresentanei livelli piu bassicaratteristichedi tipo reattive,mentreai livelli piu alti forniscele capacitadeliberativeeproattive.

Esisteunarelazionetra tipologiadi agentee architetturascelta.Ad esempio,nontutte le architettureperagentefornisconola strutturaadattaa ottenereagentideliberativi. Consideratochela tipologiadell’agentedipendedai compiti dell’a-gentestesso,e i compiti dell’agentedipendonodall’architetturadel MAS4 chesisceglie per risolvereun problema,e difficile operareunasceltaa priori su qua-le architetturadebbanoaveregli agentidi CaseLP o D-CaseLP. Persviluppareunasoluzione,puo esserenecessariaunacertaconcettualizzazionedegli agenti,la cui resapresuppongadi fattounaarchitetturaperagentipiuttostocheun’altra.Si pensiad esempioad unasoluzionein cui gli agentisianopensatiin terminimentali,quindi tramitedesideri,credenze,etc;e chiarochemodellandogli agentiin questitermini sia piu naturaleutilizzareunaarchitetturaBDI (Belief, Desire,Intention)[53] in cui sonosupportateeplicitamentele credenze,i desiderie le in-tenzionidell’agentepiuttostocheunaarchitetturacomela subsumption[11, 10],il cui comportamentoe codificatocon regole del tipo situazione-reazione.None neanchescontatocheall’interno dello stessoMAS gli agentiabbianola stessaarchitettura.A frontedi cio, edal contrariodi cio chevienefattoin altri tool (es.Zeus[65], AgentBuilder[1]) CaseLP eD-CaseLP nonadottanoun’architetturaparticolarefra quellepresentatein letteraturama si limitano ad assumerechelediversetipologiedi agentecondividanoun’architetturaminimale,cheforniscaca-pacita di comunicazione,utilizzandounamailboxper ogni agentee primitive diricezioneasincrona,invio sincronoe asincronodi messaggi.La tendenzain altritool e stataquelladi fornire agentibasatisu un’architetturaibrida, in mododapotermodellarele differentitipologiedi agenti,conla stessaarchitettura.Questoapprocciopermettedi supportaresemplicementestrumentiperscrivereil programdell’agente,fornendointerfaccegrafiche,parser, e simili. Riteniamopero ineffi-cientecostringerel’utenteadusareun’architetturaibrida dove siasufficienteuna

4Si noti la differenzacheintercorretra architetturadi agentee architetturadi MAS: la primasi riferiscealla strutturazionedel micro-livello e permetteall’agentedi averecaratteristichequalila proattivita, rattivita e autonomia,ne e ad esempioistanzela BDI. La secondasi riferisce acomee strutturatoil sistemaMAS adun macrolivello, quindi quantie quali classidi agentesonoimpiegatenellarisoluzionedi un problema.

17

reattiva. Perquestosi e tentatodi lasciareall’utentedegli strumentida noi pro-gettati,la liberta di scegliere in chetermini modellareil proprioMAS decidendoqualearchitetturasiapiu adattaperogniagente.

Assunzionisui linguaggi di sviluppo.

La tendenzachesembraaffermarsinellasceltadel linguaggioconcui implemen-tare platform e gli stessiagenti,va semprepiu nella direzionedi Java; non edifficile capirele motivazionichestannoconsolidandoquestatendenzasesi con-sideranole “f acilitazioni” fornite daJava rispettoalla distribuzionee sincroniz-zazionedi processie il crescenteinteresseversoil paradigmaadagentidapartediaziendecheoperanoin domini applicativi comequello delle telecomunicazioni.See naturalepensarea Java in tali contesti,la sceltaforsepotrebbeapparireme-no scontatain domini comequellomanifatturieroo di controllodei processi.Aifini del nostroprogetto,si e pensatochesviluppareil tool in Java potesseessereun modosempliceper fornire uno strumentochegarantissela portabilia su piusistemioperativi.

Linguaggi d’implementazioneper gli agenti.

Parlaredi linguaggiod’implementazioneperagentie in qualchemodoimproprio:si dovrebbeparlaredi linguaggioconcui esprimerele architettureperagenti5. InCaseLP si utilizzava la programmazionelogica,attraversounaparticolareesten-sionedi Prolog denominataProlAg. Il tool eradi fattoun caseper la prototipa-zionerapidadi agentiscritti e specificatitramite linguaggi logici. Il paradigmalogico offre la possibilitadi programmareadun alto livello di astrazione,manongodedi unagrandepopolaritaal di fuori di ambientidi ricercao dalleuniversita.Essenzialmenteper questoin D-CaseLP si e decisodi affiancareai linguaggilogici Java. Visto il fermentointorno a tale linguaggio,la continuaevoluzionedello stesso,aprirealla programmazionein Java significaaccederea moltedellenovita tecnologichedegli ultimi tempi,estendendoil bacinodi possibiliutentidiCaseLP.

1.3.2 Obiettivi

Distrib uzioneeffettiva.

CaseLP offre unicamenteunadistribuzionelogica,chepermettedi simularel’e-secuzionedistribuita degli agenti. In questomodo l’utente del tool percepisce

5Anche se vista la minimalita dei vincoli sull’architetturanessunoimpedisceall’utente diprogrammarel’agentesenzausarel’astrazionedi architettura.

18

l’esecuzionecomesegli agentifosseroresidentisumacchinedifferenti,mentre,di fatto,sonoeseguiti suunamacchinasolaconall’ausilio di unoschedulatore.Ladistribuzionelogicaoffre unalto livello di astrazionerispettoallacomunicazione,e piu chesufficientesesi vuoleanalizzareun problemasenzaentrarenei dettagliimplementativi, quali livello applicativo e livello di presentazionedi rete. Taletipo di astrazionepuo essereinsufficientesesi vuoleandareoltre lo studiodei re-quisiti versola realizzazioneeffettivadi unprodotto.Illustriamoalcunesituazionichegiustificanol’introduzionedi unadistribuzioneeffettivaperagentinel tool:

scalabilita: vi sonocasiin cui la simulazioneo l’esecuzionedel MAS e compu-tazionalmentepesante,ede necessariodistribuire il carico;

integrazionedi risorse remote: 6 si consideriil casoin cui si stiarealizzandounMAS, nel qualealcuni agentidebbanofareriferimentoa risorselocateinremoto. In un modellodi sviluppoper il softwarecomequelloa spirale,eplausibilechesi abbiabisognodi accedereai dati delle risorseanchenelleprime iterazionidello sviluppo. Nel casoin cui lo sviluppodel softwareavvengain una sededifferenteda dove sonolocatele risorse,si deve inqualchemodoreplicarela risorsao il suocontenuto.La replicazionedi talirisorsepuo comportarealcuniproblemi:

� nonsi disponedelle licenzesoftwareper replicarei server cheforni-sconoinformazioni;

� la risorsarichiederequisitidi sistemachenonsi possiedono;� la risorsaehardware,magarie unaparticolarestrumentazionepropria

deldominioapplicativo in cui lavorail cliente,nonequindi facilmentereplicabile.

In generalesi risolvono i problemidi questotipo costruendorisorse“f an-toccio” chesi comportanocomele risorsereali, fornendodati fuori lineasimili ai reali. La costruzionedi risorsefantoccionon e semprela sceltaottimale: richiedespessounanotevole moledi lavoro aggiuntivo, e poneilproblemadi comesostituirele risorsarealeconquellafantoccioalla messain operadelsistema.Fornendola distribuzionefisica degli agenti e possibilecostruire,gia infasedi prototipazione,un agenteda utilizzare come“interfaccia” alla ri-sorsa. Questotipo di agente,unavolta progettato,non presentai proble-mi di sostituzionepropri delle risorse“f antoccio”, se progettatobeneepotenzialmentel’agentechecomparira nel MAS definitivo. Il paradigma

6Con risorseintendiamobasi di dati, legacy software, dispositivi hardware che fornisconoinformazioni.

19

adagenti,staemergendocomeastrazioneper risolvereproblemidistribui-ti con risorseeterogeneee in uno scenariodi questotipo, la distribuzionefisicadegli agentipuo essereun prerequisitopersoluzionichepermettanoun’integrazionedi legacy software7 piu efficace;

accessoparziale alla risorsa: il clientevuolefornire un accessocontrollatoallarisorsa.Taleeventualitanone cosı remota,perrisorsecomele basedi dati,dove spessovi e un server, si hannostrumentidi autenticazionee gestio-nedei diritti con i quali limitare l’accessoalla risorsa,ma in altri casi(es.hardware)questefunzionalita nonsonodisponibili. Sedisponiamodi unadistribuzioneeffettiva degli agentipotremmopensarechegli agentiinter-facciasianoforniti da terzi, (es. la stessaaziendacliente)e funzioninodafiltro fornendounavisioneparzialedei dati;

testingdi applicazioni: vistochevogliamoaccompagnareil progettatoredelMASlungotuttoil modelloaspirale,vorremmoaiutarloanchenellefasidi testingdel codicechestarealizzandoe fornigli degli strumentiperdistribuire na-turalmentee conpocosforzol’applicazionechehaprogettattoe testatoinregimedi distribuzionelogica. Abbiamogia dettochevorremmochel’ap-plicazionefinale del nostroutentefosseun raffinamentodei prototipi cheavevarealizzato,vorremmoquindipermettergli di recuperarelo sforzofattonel realizzareil prototipoe noncostringerloa riscriversi tutto il codicere-lativo allacomunicazione.Prevederela distribuzionefisicasignificaforniregli strumentichegli permettanodi passaredallafasedi distribuzionelogicaaquelladi distribuzionefisica.

Comunicazione.

Gli agentiper loro naturasonodistribuiti e caratterizzatida unacomunicazionedi tipo asincrono. La comunicazionetra gli agenticoinvolge problematicheadiversolivello di astrazione,comeillustrato in [47]. Affinche la comunicazionepossaavveniresi devonodefinire:

� ontologie;

� linguaggiodi comunicazionetraagenti;

� protocollodi trasporto.

Nelle fasiiniziali di progetto(primeiterazionidellaspirale),enaturalepreoc-cuparsidelleproblematicherelative ad ontologiee linguaggiodi comunicazione

7Perunadefinizionedi cosasi intendecon legacy softwaresi vedail paragrafo“Integrazionelegacy software” a pagina21.

20

traagenti,unadistribuzionelogicadegli agentiequindi piu chesufficiente.Nellefasi successive cambianole esigenze,i problemichesi affrontanocoinvolgeran-no ancheaspettirelativi ai protocolli di trasportosui qualei messaggivengonoscambiati.Pensiamoadunaapplicazionebasatasuagenticheforniscedegli assi-stentivirtuali, eabbastanzanaturalepensarechequestiassistentipossanogiraresuhardwaredifferente(palmari,cellulari,personalcomputer, portatili) e ragionevolepensarecheun palmtope cellulari impieghinodifferentiprotocolli di comunica-zione(es.WAP) rispettoal personalcomputerdi casaconconnessionea internet.In domini applicativi come“l’assistenteelettronico”checi segueovunquei pro-tocolli di trasportogiocanounruoloprimario,e forniresoluzioniversatiliimplicaincluderela progettazionedi questolivello di comunicazionenel progetto.

Monitoring di agenti.

Unadelle fasichebisognaconsiderarein qualsiasiprogettoe il testingdelleap-plicazioni sotto sviluppo, il monitoring dell’esecuzionedegli agentie requisitominimaleal testing. In un ambientedistribuito si deve poterusufruiredi qual-chetool chepresentiunavisionecomplessiva dell’esecuzionedistribuita, dandoalmenola possibilita di osservarele comunicazionifra gli agenti. In CaseLP ilproblemadel monitoringdegli eventi cheoccorrononell’esecuzionedel sistemasotto sviluppo era statooggettodella tesi [50], si vorrebberofornire strumentianaloghiperD-CaseLP.

Simulazione.

Abbiamogia dettocheD-CaseLP e di fattoun’evoluzionedi CaseLP e cheuntool di simulazioneeragia presentenellaversioneoriginale.In CaseLP erapos-sibile simularedei ritardi sui canalidi comunicazionedegli agenti. In futuro sivorrebbecontinuarea usufruirein D-CaseLP degli strumentidi simulazionein-clusi in CaseLP eaggiungernedi piu raffinati. Unaestensionechein prospettivapotrebberivelarsiutile e la possibilitadi salvaree caricarein simulazionesocietadi agentipredefinitepereffettuarneil testinge studiarneil comportamento.Que-stacaratteristicapotrebbeadesempiofacilitarelo studiodi tecnichee modelli dicoordinazionetraagenti.

Integrazione legacysoftware.

Riteniamochela capacita d’integrarerisorsee programmiprecedentementesvi-luppati (legacysoftware) sia fondamentalein ambiti applicativi dove la tecnolo-gia ad agentiaffiancasoftware preesistente.A titolo di esempio,pensiamoadun‘applicazioneperla gestionedel traffico aereo,il cui principaleobiettivo e una

21

razionalizzazionedel traffico aeroportuale.Questocasodi studioestatoanalizza-to daKinny e altri in [38] comeesempioperillustrarela metodologiaBDI. Nellasoluzionedescrittavi e un agenteAircraft perogniaereo,il qualeinteragisceconunagentenellatorredi controllopercontrattarel’ora di atterraggio.L’agenteAir-craftdeveesserein gradodi interagireconil sistemadell’aeroplanopersvolgereipropri compiti e prevederea cheorapotra atterrarein aeroporto.In questoesem-pio il sistemasoftwaredell’aereosi puo considerarelegacysoftware.L’integrazionedel legacy softwarenoneunaproblematicaesclusivadellosvilup-podeisistemiadagenti:sonoallo studiodaannisoluzionipertali problematiche8.Cio chesi puo osservaree chenelleapplicazionibasatesul paradigmaad agen-ti il problemavieneaccentuatodalla naturaeterogeneadei risolutori, per causastessadelladefinizionedi MAS datain 1.2. Probabilmente,fornire soluzioniperunaintegrazioneefficace,si puo considerarecomeunaprecondizioneaffinche latecnologiaadagentiprendapiedeal di fuori dei progettidi ricerca.Nell’articolo[32] sonopresentatitre approcciperagentificareil legacy softwareschematizzatiin figura1.4di cui diamounabrevedescrizione:

Legacy Application

Transducer

Legacy Application

Wrapper Rewrite

Figura1.4: Tremodi peragentificarelegacy software.

Transducer: accettamessaggida altri agenti e li traducein una forma com-prensibilealla legacyapplication. Quindi accettale rispostedell’applica-zionee le spedisceutilizzandomessaggiscritti secondoun linguaggiodicomunicazioneperagenti(es.KQML);

Wrapper: interagisceconil legacy software, attraversounamaggiorecoesione:puo esamininare,accedere,modificaredirettamentele strutturedati dellalegacy application;

8Si pensiadesempioal successodellaarchitetturethreetier e middlewarecomeCORBA chenasconoproprioperaiutarel’integrazionedi softwareeterogeneo.

22

Rewrite code: si riscrive l’applicazionelegacy dacapo.Si sceglie questastradanel casoin cui nonsiapossibileutilizzarenessunodei precedentiapprocci.

Per utilizzare un approccioa transducere necessarioche l’applicazionesia ingradodi comunicarecon l’esternosecondoqualcheprotocollorispettoa cui l’a-gentefungeda interprete. Nel casoin cui non vi sia la possibilita di interagirecon l’applicazionetramiteun protocolloma si dispongadel codicesorgente,sipuo costruireun wrapper. Taleapprocciopermettedi effettuarechiamatedirettealle proceduredel softwareda integrare;nonessendovi alcunprotocollopuo ri-sultarepiu efficienterispettoal primo. Ancheseallo statodei fatti all’interno diD-CaseLP non trova spaziouno studiopiu approfonditodi tali problematiche,vista l’importanzain ambiti applicativi si prevedein futuro di analizzareil pro-blemain modopiu dettagliato.Riteniamopossaessereinteressantefornire dellelineeguidametodologichecheaiutinoagestirel’integrazionedel legacy software.

1.3.3 Linee guida metodologiche

In questasezioneillustriamobrevementele lineeguidacheabbiamoseguitonellefasiiniziali dellaprogettazionedi D-CaseLP, iniziandodallaconcettualizzazionedel softwarechedaWieringa.

Concettualizzazionedel software: Subject Domain, Systeme Context Boun-dary.

Definizione1.5 Il subjectdomaine definitocomel’insiemedi tutti i soggetti deimessaggi chepassanodall’ environmental sistema.

Definizione1.6 Conenvironmentci riferiamo all’ambientein cui il sistemachestiamoprogettandoeposto.

Vediamoun esempioal fine di illustrare i dueconcetti: consideriamoun siste-madi monitoringdi pazientiin un repartoospedaliero.Includeremonel subjectdomaintutti i termini del dominio applicativo chesonorilevanti per il sistema,quindi nel casoin cui un pazientestia malepotremmopassareal sistemale in-formazionirelative alla temperatura,il battitocardiacodel paziente,ecc. In talecontestol’environmentsara compostodalpaziente,le apparecchiaturedi monito-ring, le infermiere,i medici,e tutto cio fa partedella realta chestiamocercandodi modellare.All’interno dell’ambientepossiamoindividuarecontext boundarye systemboundary: abbiamobisognodi questidueconcettiin quantonell’am-bientenontuttele entitasarannougualmentesignificativeperla progettazionedelsistema.

23

Definizione1.7 Il context boundaryrappresentail confineoltre il qualele entitacheappartengonoall’ambientenonsonocosı rilevantiper i nostriscopidaesseremodellate.

Definizione1.8 Il systemboundaryrappresentail confineall’interno delqualeleentita nonvengonomodellatemaprogettate.

Continuandoa ragionareconl’esempiodel monitoringdi pazienti,potremmoin-cluderenel context boundaryil monitor che campionala pressioneo il battitocardiacocon unacertafrequenzatemporale.Dal momentocheapperecchiaturadelgeneresi trovanoin commercioe ragionevolenonprogettarneunadacapomalavoraresuun suomodello.Al contrario,la basedi dati sullaqualeregistriamoicampionamentidellapressione,essendodipendentedai requisitidel progettosiala sceltadelleinformazionidaregistrarenellabasedi dati,siail formatoe le asso-ciazioniconcui rappresentiamole informazioni9, sarapostaall’internodelsystemboundary.Definiamoora comele informazioni attraversanoun genericosistemaunavol-ta fissati i systeme context boundarynell’environment. In figura 1.5, possiamoindividuare

Event: eventochehaluogonell’ambientecircondanteil sistema,di cui il sistemadevetenereconto,peresempioil fattocheunpazientehaunacrisi cardiaca.

Stimuli: ognieventosollecitail sistemaconunoo piu stimoli chesarannoelabo-rati. Gli stimoli sonole informazionisull’eventocheabbiamodecisoessererilevanti,adesempiobattitodel cuore,temperaturacorporea,ecc...

Response:rispostein reazioneagli stimoli che il sistemaelabora,ad esempionecessitadi dareun allarme.

Action: disposizionichevengonoattuate,agentisull’ambientedelsistemain cor-rispondenzadellerisposteelaborate,es.accensionedi unaspiadi allarme.

L’infermiera fara partedell’ambientedel sistema,la spiachesi accendesaraall’internodel context boundary.

9Consideriamola sceltadeidatidipendentedai requisitiin quantosoloconoscendoquali inter-rogazioniverrannoeffettuatesullabasedi dati siamoin gradodi determinarequali informazionisianecessariomemorizzare.Ancheil formatoconcui memorizziamoi datipuo esseredipendentedai requisiti,almenoseconformatointendiamolo schemadelletabellein cui esprimiamoundatochenone un tipo di datosemplice.

24

System Boundary

Contex Boundary

Actions

ResponseStimuli

System

Event

Figura1.5: Schematizzazionedei concetticoncui vienecaratterizzatoil softwaredaWieringa.

Function RefinementTree(F.R.T.).

Un FunctionRefinementTree e una lista gerarchicadelle funzionalita che vo-gliamo sianopresentinel sistema.Puo essererappresentatograficamentecomealberoveroe proprio o in forma testualecomeunalista indentata.Ogni nodoeetichettatoconunafunzione,le funzioni cheetichettanonodi figli rappresentanofunzionalitapiu specificherispettoalla funzionalitacheetichettail nodopadre.

Vediamoalcunedellemotivazionichegiustificanol’impiego dei functionre-finementtree.

� Chiariresystemmission: definirebrevementequalesia lo scopoprincipaledel sistemachestiamoprogettando.Il nodoradicedel functionrefinementtreedovrebbeesserela missionedelsistema.

� Evitareil gold plating: impedirel’aggiuntadi funzioni fantasiosee inutilirispettoi requisitidurantele fasisuccessive.

� Evitareil functiondrift: impedirela perditadi alcunedelle funzioni origi-nariamentepreviste.

� Fornire unavisioneindipendentedall’implementazione:piche siamoa li-vellodi requisitile funzionalitadevonoesserevicineal linguaggiodeldomi-nio applicativo, illustrandocosavogliamoottenereenoncomelo vogliamoottenere.

25

Un FunctionRefinementTreedovrebbeesserecostruitoconla collaborazionedel cliente.E consigliabileannotareognunadellefunzioni desideratenel sistemasuun post-it,eorganizzaregerarchicamentei post-itconcludendoil raffinamentoquandoil livello di dettagliodellefunzioninonepiu comprensibiledal cliente.

Linee guida: modellazionedell’ambiente eanalisi dei requisiti.

L’approccioillustratodaWieringapersvilupparesoftwareadoggetti,si componedi quattroattivitaprincipali10:

Specificadei requisiti: fasein cui si individuanoespecificanoi requisiti,tramiteusecasediagrameFunctionRefinementTree.

Modellazionedell’ambiente: si fornisceuna descrizionedell’ambientein cuiil software dovra operare,di solito si costruisceun Entity RelationshipDiagram.

Progettazionedell’ar chitettura: gli usecasesonoanalizzatiperdefinirel’archi-tetturadel sistemaesuddividerlain sottoparti. I diagrammitipici in questafasesonoclassdiagram,statechart, interactiondiagram.

Implementazionedel progetto: si associanole classiall’architetturadelsistemaattraversocomponentdiagramesi mostracomele componentisonoallocatenei nodi fisici dellarete.

Le fasi sopradescrittenonavvengonotuttesequenzialmente,la specificadeirequisitie la modellazionedell’ambientevannodi paripasso.L’ambientein cui ilsistemaepostovienemodellatoal finedi comprenderei requisitidelsistema.L’i-deaecheil sistemasottosviluppodebbaaiutarel’ambientearaggiungerei propriobiettivi ed i requisiti sianoquindi unaderivazionedelleesigenzedell’ambiente.Continuandosull’esempiodel monitoringdi pazienti,non e dettocheil model-lo dell’ambientesi limiti a considerarela strumentazionepresentein repartocolqualeil sistemadeve interagire.Potrebberisultareutile estenderel’ambienteal-l’organizzazionedelpersonaleperavvertirele persone”giuste” asecondadel tipodi emergenzachesi presenta.Cosavieneinclusonel modelloe cosano dipendedadovesi poneil Context Boundary.Le lineeguidadettanoprincipi chepossonoaiutareaverificarela bontadellapro-gettazioneeffettuata.Peresempioil criterio di Traciability , dicechedeveesserepossibileseguireil trasformarsidegli eventi in stimoli, risposteeazioniall’internodei differenti livelli di dettaglio,manmanochesi completala progettazione.Ciochesi vuole,e poterverificarecomeevolvonole coseall’interno dellespecifiche

10I diagrammidi seguitonominatisi riferisconoallanotazioneUML [48].

26

quandosi verifica un certoevento,e poterscegliere a qualelivello di dettaglioguardare.Possiamoquindi vedereil sistemacomesefosseformatoda un certonumerodi strati annidati. Ogni stratorappresentaunavisionedel sistemaadunlivello di astrazionedifferente. Vorremmoesserein gradodi determinarecomesi trasformanole informazionidello stratoprecedentemanmanochepassiamoagli strati piu interni. Consideratocheogni livello di astrazionee descrittocondiagrammidifferenti,il principio di traciability si applicain ultima istanzaai dia-grammi.Peresempio,nellafasedi progettazionedell’architettura,si dovra porreattenzionecheil classdiagramoffra le funzionalita per realizzareogni usecase,associandoadogniusecasele classi,le operazionee i metodi11 cherealizzanolousecase.

1.3.4 Un Function RefinementTreeper D-CaseLP

Abbiamo costruitoun function refinementtree per D-CaseLP al fine di deli-nearei requisiti chevolevamoincluderenel progettocercandodi includeretut-te le funzionalita chedovevanoesserefornite, senon in un futuro immediato,inprospettiva.

1. ModellazionedelMAS ecreazionedi codiceperil prototipodi MAS.

(a) Modellazioneed integrazionedi componentiriutilizzabili (indipen-dentidall’applicazione).

i. Modellazioneedintegrazionedi architetture.

ii. Modellazioneedintegrazionedi ruoli (rolemodels).

iii. Modellazioneedintegrazionedi ontologie.

(b) Istanziazionedel MAS.

i. Sceltadei ruoli necessarinel MAS.

ii. Sceltadei protocolli tra i vari ruoli.

iii. Istanziazionedellaclassi.

A. Sceltadei ruoli checaratterizzanoogni classe.

B. Sceltadellaarchitetturachecaratterizzala classe,edistanzia-zionedel “programma”checaratterizzala classe.

11Si consideranogli uni o gli altri a secondadi quantosia astrattoil classdiagramchesi staanalizzando.Alla fine del designdel progetto,il classdiagramsara completocontutte le classiei relativi metodi;quindi si potra effettuareunaverificasudi essi.Nelle fasi iniziali dellaproget-tazione,si disporradi classie operazionipiu astratte,in cui nonsara ancorachiaral’associazionefunzionalita-operazioni-metodi.

27

iv. Istanziazionedelleontologie.

v. IstanziazionedelMAS (architetturastaticadelMAS): definizionedelleistanzedi agentimedianteistanziazionedello “stato”.

(c) Creazionedellespecifiche/eseguibili.

i. Controllostaticodellasintassidel “programma”checaratterizzale classiedello “stato” checaratterizzale istanzedi agenti.

ii. Creazioneautomaticadel codice eseguibile delle istanzedegliagenti.

2. Realizzazioneevalidazionedi unprototipodellaapplicazionesottosvilup-po.

(a) Installazionedegli strumentiofferti daD-CaseLP.� Supportoall’installazionevia proceduredi installazione.� Documentazioneperl’installazionee l’utilizzo.

(b) ImplementazioneprototipodelMAS.

i. Integrazione.� Integrazionelegacy software.� Integrazionesemantica.

ii. Supportoalla comunicazione.

iii. Supportoalla mobilita.

(c) MonitoraggioeSimulazionedell’esecuzionedel prototipodel MAS.

i. Configurazionedell’esecuzione.� Comedistribuiregli agenti.� Doverecuperareil codicedegli agenti.

ii. Monitoring grafico.� Visualizzazionedelladistribuzionedegli agenti.� Visualizzazionedellecomunicazionifra gli agenti.

iii. Strumentidi simulazione.� Parametridellasimulazione.

– Ritardi sui canalidi comunicazioneo canaliinaffidabili.

– Input agli agentiin simulazione.

– Attivazionedegli agentidurantela simulazione.

– Gestionedel tempo.� Supportoperla visualizzazionedei risultati.

– VisualizzazioneOn-Line.

28

– VisualizzazioneOff-Line.

3. Implementazionedellaapplicazionefinita.

4. Utilizzo dellaapplicazionefinita.

Suddivisionedel lavoro.

Il functionalrefinementtreeedivisibile in dueparti:

1. ModellazionedelMAS ecreazionedi codiceperil prototipodi MAS.

2. Realizzazioneevalidazionedi un prototipoedell’applicazionefinita.

Mantenendoquestasuddivisioneabbiamoorganizzatoil lavoro in duesotto-progetti:

Ag-UMLspecification byAgent class

Components

Components

For Agent Comunication

Abstract Interface

D-CaseLpTool

Agentsimulation

and execution

Ag-Prolog Ag-Java

M-CaseLp

Semi-automatic

translation of specification

Library

Library

Figura1.6: Un primasuddivisionedel progettoD-CaseLP.

M-CaseLP. Nel qualesono affrontati gli aspettimetodologicicon i seguentiobiettivi:

29

� integrare la metodologiapropostain CaseLP con tecnichedi rolemodeling12;

� definireunanotazionederivatadaUML (Ag-UML) perspecificaregliagenti;

� fornireindicazionisulleproblematicherelativeallatraduzionesemiau-tomaticadellespecificheAg-UML in agentiprototipali.

D-CaseLP. Nel quale si trovano tutti gli aspetti relativi all’esecuzionedegliagentiprototipali,nell’intentodi fornireun ambientein cui si possano

� distribuireedeseguiregli agenti;� accedereastrumentiperil testingdurantel’esecuzioneagenti;� accederea funzionalita di simulazionechesianosupportoall’esecu-

zioneedil testingdegli agenti.

Comeillustratoin figura1.6gli agentidescrittinellaspecificaAg-UML vengo-no tradottiin agentiprototipali(Ag-Prolog o Ag-Java) attraversounatraduzionesemiautomatica,dopodi che,possonoaccederealle funzionalita di D-CaseLPattraversol’interfacciaastrattadelleprimitivedi comunicazione.L’ambientefor-nito in D-CaseLP oltre a tutte le funzionalita di testinge simulazione,offrir al’implementazionedi questeprimitive.

La suddivisionein M-CaseLP eD-CaseLP corrispondeagrandilineeancheacomeci siamosuddivisi i compiti all’internodelnostrogruppodi lavoro. Stefa-no Miglia e AlessandroRolandosi occuperannodelleproblematichecorrelateadM-CaseLP. In particolare,StefanoMiglia degli aspettirelativi la definizionedel-la metodologia,la notazioneconcui esprimeregli agentiAg-UML ela traduzioneautomatica.AlessandroRolandosi occupera di arricchirela libreria di compo-nenti, implementandoalcunearchitettureperagentidi supportoalla progettazio-ne e traduzionesemiautomatica.Invece,le problematicheinerentia D-CaseLPsarannotrattatein questolavoro di tesi,focalizzandosiprimadi tutto sullacomu-nicazionee distribuzionedegli agenti.Tutti gli aspettivengocoordinatie seguitidalladottoressaVivianaMascardie il professorMaurizioMartelli sullabasedegliobiettivi e l’esperienzaCaseLP.

Ovviamentel’albero definitosoprae solounaprimaapprossimazionedei re-quisiti del progettoD-CaseLP, ci aspettiamochela strutturae il contenutodel-l’albero subiscadellemodificheduranteil progettoin funzionedell’emergeredinuoveesigenze.

12Rolemodelinge la modellazionechesi basasul concettodi ruolo,per il qualeunaentita siaessaagenteo oggettooffre dellefunzionalita in baseai ruoli chein uncertoistantegioca.

30

1.3.5 Un’interfaccia astratta per far comunicaregli agenti

L’esigenzadi suddividereil lavoro in piu tesi, ha portatoa definirecomeanellodi congiunzionetra la progettazione-specificadegli agentie l’esecuzionedi questiun’interfacciaastrattadi comunicazione.L’interfacciae l’insiemedelleprimitivecon le quali gli agenticomunicanoed hannola possibilita di fornire e richiede-re servizi. Le primitive di cui si componel’interfacciasonoelencatein tabella1.1, tuttehannoun parametromsgchesvolgeunafunzionedifferentea seconda

Primiti va Tipo di comunicazionesend asincrona

receive sync sincronareceive async asincrona

Tabella1.1: primitive di comunicazionedegli con cui possonocomunicaregliagentiD-CaseLP.

chesia il argomentodi unaprimitiva di ricezioneo si spedizione.In entrambiicasi il parametromsgfara riferimentoad un qualcheAgent ComunicationLan-guage(ACL). Senzaentraretropponei dettagli,un messaggioscritto in un ACLda un puntodi vista astrattocorrispondead unatupla di coppieetichetta-valorerappresentatiinformazioniquali

� il destinatariodel messaggiochesupponiamocontrassegnatodall’etichetta:receiver;

� il mittentedelmessaggiochesupponiamocontrassegnatocon:sender;

� l’atto comunicativo chesi vuoleesprimereconil messaggiocontrassegnatocon:performative);

� il corpodel messaggiocontrassegnatocon:body.

Un sempliceesempiodi messaggioscrittoin un ACL fittizzio, potrebbeessere:

(:sender Pippo, :receiver Pluto,:performative Richiesta,:body "Una cassa di mele")

Questomessaggioesprimetrecose:

1. un agentedi nome“Pippo” comunicaconl’agentedi nome“Pluto”;

2. la comunicazionecorrispondeadun attodi tipo “Richiesta”;

31

3. la richiestariguardaunacassadi mele.

Mentreci aspettiamocheil msgparametrodellaprimitivadi sendsiaunatuplacontutteo quasile componentiistanziate13, nel casodelleprimitivedi ricezione,in generenon e cosı. Di solito un agentein ricezionenonpuo specificaretutti icampidelmessaggiocheaspettaperchenonli conosce:magariconoscela tipolo-giadi messaggiochestaaspettando(es.unarichiesta)o il mittentedelmessaggionel casovoglia servirequalcunoin particolare,ma di solito e interessatoa sele-zionarei messaggichegli arrivono. Perpermetterecio i msgdelle primitive diricezionepossonoesseretupledel tipo precedentementedecrittomaconqualchecampovuoto,in mododarappresentareunaspeciedi schemaperi messaggichesi desideranoselezionareadun certopuntodella computazione.Alla basedellaselezionedeimessaggivi e il meccanismodelPattern Matching, il qualeparten-do daun messaggioparzialmenteistanziato,lo schemadi messaggiodettoanchepattern,individuaqualisonoi messaggicompatibiliconesso.Facciamounesem-pio, abbiamol’agente“Pluto” di prima,chee un fornitore di frutta, ed e quindiinteressatoadtuttele richiestedapartedi tutti gli utenti.Taleagentespecificheranel parametromsgqualcosadel tipo

(:sender *, :receiver Pluto,:performative Richiesta, :body *)

dove lo ’*’ individua l’assenzadi un valore nel campo14. Il primo messaggiocompatibileconlo schemasceltosaracosı selezionatoall’internodellamailboxerestituitodalleprimitive di ricezionein un parametrodi ritorno o sovrascrivendoil parametrocheindividuava lo schema.

1.3.6 Dalle specifichein Ag-UML all’esecuzionein D-CaseLP

In questasezionedescriviamopiu dettagliatamentel’iter di massimachegli svi-luppatoripotrannoseguirenellarealizzazionedei loro sistemimulti-agente.

Tralasciandogli aspettilegati al processodi progettazionechecoinvolgonolametodologiaM-CaseLP, in figura1.7abbiamoillustratounoschemacheforniscel’idea di comeavvienela traduzioneapartiredallespecifichedi agenteespresseinnotazioneAg-UML fino agli agentiprototipali.Le specifichedi agentiin Ag-UMLcontengonol’indicazionesuquali carateristiche(es. ruoli, architettureperagen-ti, protocolli d’interazioneper gli agenti)sonostateattribuite all’agentedurante

13Nell’esempiole specifichiamotutteancheperche l’A CL chestiamoutilizzandoemolto sem-plice. In generenegli ACL realmenteutilizzati per la comunicazionefra agentivi sonoontologieedaltreinformazioni(es.un riferimentoal protocollod’interazioneutilizzato).

14Si sarebbepotutoanchelasciareunospaziobiancoo utilizzareun altro caratterepurche nonvi sianoambiguita,peril nostrolivello di astrazionela sceltadel caratterenonhaimportanza.

32

Specification PrototypeAgents

PrototypeAgents

Translation of

SpecificationAgents Prototype

Ag-Prolog

Ag-UML Agent

specification Translation

Semi-automaticUser inputfor

Translation

Library of Components(Couple of Specification

and Implementation)

Ag-Java

Figura1.7: Iter seguito in M-CaseLP.

la prima fasedi progettazionedel MAS. Ipotizziamoche la libreria delle com-ponenticontengatuttele implementazionidellecomponentichecompaiononellespecificheAg-UML di un certoagentee chedi conseguenzala traduzioneauto-maticaconsistaessenzialmentenell’assemblarele realizzazionidi tali componen-ti pescandodalla libreria. In primaapprossimazionesi e previstaunatraduzionesemi-automaticadellespecificheAg-UML cheforniscedegli “scheletri” ai qualisi dovra aggiungerela logica dipendentedal dominio secondole esigenzedellasoluzionechesi sta approntando.Gli agentiprototipali Ag-Prolog e Ag-Javasonoagentiscritti rispettivamentein codiceProlog eJava.

Facciamoun semplicissimoesempioper chiarire il tipo di interventocheciaspettiamodall’utente.

Si consideriunaspecificadi agentenellaqualesi siaindicatol’utilizzo di unacertaarchitettura.La partedi traduzionechepossiamoottenerein modalita au-tomaticae limitata all’inserimentodell’implementazionedell’enginedell’archi-tetturanel codicedell’agente,mentreil programe lo statodell’agenteessendodipendentidalla particolaresoluzionee dal dominio applicativo non sonocono-sciuti a priori. Il programe lo statodell’agentein questocasorappresentanolalogicadipendentedal dominio applicativo, l’unico in possessodi tale logica e ilprogettista,ede quindi lui chedovra interagirecon il processodi traduzioneperfornirla. Le informazioniottenutegrazieall’interventodell’utilizzatorepossonoessereviste comela logica del dominio con cui si specializzanole componentigenericheindipendentidal dominio.

In figura 1.8 abbiamoillustrato comeil procedimentodi traduzionicontinui

33

Ag-UML Agent M-CaseLP

D-CaseLpRun-Time

D-CaseLp Preprocessor

for simulation / execution

executionready to Agent

Prototyping Agents

Mas Execution

and Simulation

Improvement steps

PreproccessingAgent

Executable Agents

Ag-Java

Gui

toolSimulation

YES

NO

Ag-Prolog

Ag-Prolog Change

or\andAg-Java

MAS and Agent

Parameter

are needed ?New changes

Simulation

Figura1.8: Iter seguito in D-CaseLP.

34

dopola creazionedegli agentiprototipali. Lo scopodi questapartedi iter e ag-giungereagli agentiprototipali le informazionineccessariealla loro esecuzionenel Run-Time D-CaseLP. Si prevedeunafasedi preprocessingin cui tenendocontodegli eventualiparametridi simulazionevienemanipolatoil codicedegliagential fine di aggiungerei layer di comunicazione/esecuzioneed otteneredelcodiceeseguibileconl’ausilio delD-CaseLP run-time.Durantel’esecuzionedelrun-timesara possibileaccederea strumentidi monitoringdegli agenti,utili allaverificadelcorrettofunzionamentodelMAS sottosviluppo.A secondadell’esitodi taleesecuzionesi andra a ritoccareil codicedegli agenti,i parametridi simu-lazioneo nel casoin cui i problemiriscontraticoinvolganola prima partedellaprogettazionedel MAS le specificheAg-UML. Gli schemidell’iter presentatiinquestafasehannolo scopodi dareun’ideadi comesi potra procederenell’uti-lizzo del tool danoi prodottounavolta completato,ovviamentein questafasediprogettononsi puo chedareun iter di massima.Si avra curadi precisarele mo-difichea cui sottoporregli schemimanmanochesi individuerannogli strumentile funzionalitasarannoofferte.

Nei prossimicapitoli verra illustrato lo studio di realizzazionedel tool D-CaseLP considerandodiversi strumentiper realizzarela distribuzionee la co-municazionedegli agentiAg-Prolog eAg-Java.

35

Capitolo 2

Valutazionedi CORBA perrealizzare MAS

In questo capitolo illustriamo lo studio della distribuzione degli agenti inD-CaseLP utilizzandogli strumentiofferti da CORBA. Nelle prime sezionisiintroduconoi concettie le principali caratteristichedi CORBA, successivamen-te al fine di individuareun insiememinimaledelle funzionalita da realizzaresipresentaun sottoinsiemedel F.R.T descrittonel capitoloprecedente.Si concludeillustrandoun primo designdella comunicazionerealizzatain CORBA, cercan-do di evidenziaresee quantogli strumentiofferti da CORBA sianoadattiallarealizzazionedelnostrotool.

CORBA godedi unacertapopolarita cometecnologiaper integrarecompo-nentidistribuiteedeterogenee.Questecaratteristichehannospintoalcuniricerca-tori fra i quali Jennings,Sycarae Wooldridgein [35] a candidareil middlewareperoggetticomestrumentoperla distribuzionedi agentieterogenei.Il capitolohacomeobiettivo daregli strumentichepermettanodi rendersicontodelledifficoltalegateall’utilizzo di CORBA, affincheappaiaevidentequantounmiddlewareperoggettisia di per se inadeguatoal fine di offrire la distribuzionedegli agenti1 escoraggiaredataleimpresachi si trovi asvilupparela distribuzionedi agentisottoipotesiprogettualisimili alle nostre.

2.1 CORBA

Comeillustrato in [59], i fattori chehannodecretatoun generaleinteressever-sostrumenticomeCORBA vannoricercatinel crescenteutilizzo di applicazioni

1Cio nonescludecheriempendola differenzadi astrazionecheintercorretra la comunicazioneclient-serverequellapeer-to-peersi possautilizzareCORBA perrealizzarela comunicazionetraagenti.

36

distribuite sureti eterogenee.Emblematicoesempiodi questointeressee il feno-menoInternete l’impatto chequestatecnologiahaavuto sul lavoro di milioni dipersone.Internete a tutti gli effetti unareteeterogenea:incorporaun insiemeditipi di reti svariato(Ethernet,TCP/IP, Novell Netware)condifferentiprotocolli edifferentehardware(workstatione server UNIX, PCMicrosoft Windows, AppleMacintosh).La convivenzadi reti eterogeneepuo aumentarela flessibilita del sistemaprodut-tivo. Giustoperdareun’ideadi quali vantaggisianolegati all’eterogeneita dellereti, consideriamoil sistemainformaticodi unagrandeazienda.E plausibilecheunagrandeaziendasiasuddivisain repartio divisioni: ognidivisioneavracompitispecifici,e potrebbeaver bisognodi strumentiinformatici (hardwareo software)differenti dalle altre. Allo stessotempo,essendole divisioni parti della stessaaziendae ragionevole prevederechevi sia la necessita di condividerealcuneap-plicazioniperle procedureedi compiticomunia tuttele divisioni. Potersceglierestrumentieterogeneie poterli integrarefra di loro, significaaverela possibilitadiutilizzaresoftwareehardwareadhocperi compitidi ognisingolorepartoo strut-tura, offrendoallo stessotempoproceduredi fatturazioneo richiestad’acquistounificateattraversoun applicativo condivisodatuttele componentidell’azienda.Nell’aprile del 1989su iniziativa di alcuneaziende(Canon,3ComCorporation,SunMicrosystems,ecc.) si forma l’ ObjectManagementGroup(OMG). Il do-cumentocostitutivo includefra gli obiettivi dell’organizzazionela produzionedispecifichee lineeguidaal fine di fornire un strutturazionedel softwarecomuneefavorire la progettazionee lo sviluppodi applicazioniinteroperanti.Fra le speci-fiche chesonostatefino ad oggi prodottevi sonola ObjectModel Architecture(OMA), la CommonObjectRequestBroker Architecture(CORBA) e la UnifiedModelingLanguage(UML). La primadelletre specifichehacomeobiettivo dareun modellodelleapplicazionied individuareunacertastrutturazionedellecom-ponenti;la secondaspecificadescrive un middlewareconil qualele componentipossonocomunicare;la terzaspecificadefinisceunanotazionegraficachepuo es-sereutilizzataper la descrizionedellespecifiche.Essendofra gli scopidi questatesi la distribuzionedegli agentie non la specificadi essi,nelleprossimesezionianalizzeremosoloduedelleprecedentispecifiche:l’OMA eCORBA.

2.1.1 Object ManagementAr chitecture (OMA)

Comeillustratoin [59] il OMA eunmodellocheindicacomesviluppareedimpie-gareoggettidistribuiti interoperantiin unambienteeterogeneo.In questomodelloognioggettoe incapsulatoin unaentitaconunaimmutabileidentita. I servizicheoffre possonoessereaccedutiesclusivamentetramiteunabendefinitainterfaccia,allo stessotempol’implementazionedei servizi dell’entita e la locazionedellastessasonotrasparentiall’entita cliente. Il modelloOMA e compostodaun Ob-

37

jectModeledunReferenceModel. Il primodefiniscei concettichesonoallabasedellaspecifica,illustrandol’accezionein cui sonoutilizzati terminicomeidentita,richiesta,operazione,tipo, segnatura,ecc. Il secondodescrive la suddivisioneincomponentie le interazioniin cui sonocoinvolti. In figura2.1 vi e unaschema-tizzazionedel referencemodel in cui la componenteprincipale,ObjectRequestBroker (ORB), e responsabiledellacomunicazionetra clienti edoggetti.Le altrecomponentiindividuanoquattrotipologiedi interfacceperentita/oggetti:

Object Services: interfaccedi oggetti indipendentidal dominio applicativo cheoffrono servizidi utilit a generalealle altreentita. Esempidi tali servizi inCORBA sonoil NameServiceed il TradingService. Il primo permetteaiclienti di trovaregli oggettiin baseall’identificativo, il secondoin baseadunadescrizionedei serviziofferti.

Common Facilities: sonointerfaccedi oggettiorientatealle applicazioni.Rien-tranoin questatipologiale interfaccechepermettonol’iterscambiodi ogget-ti fra un applicativo edun’altro sullabasedi un modellodi documento.Unesempiosonole interfaccechepermettonodi inserireun foglio di calcoloin un documentoprodottoconun elaboratoredi testi.

Domain Interfaces: sonointerfaccecheanalogamentealle commonfacilities eagli objectservicesfornisconoservizi, solo chele facilitazioni fornite so-no legatea domini applicativi specifici, quali telecomunicazioni,dominifinanziari,ecc.

Application Interfaces: sonointerfaccesviluppateperappositeapplicazioni.Es-sendole funzionalita offerte fortementedipendentidalle particolariappli-cazioni, OMG non si occupadi produrreinterfaccestandardper questacategoria.

2.1.2 Terminologia in CORBA

Di seguito riportiamola terminologiapresentatain [54], la qualeintroducei ter-mini cheusualmentesi usanoperparlaredellatecnologiae dei concettipropri diCORBA. Tale terminologiaci aiutaa comprenderequalesia il ciclo di vita de-gli oggettiCORBA, ecomele richiestesianoserviteattraversol’associazionetraservanteCORBA object.

CORBA object: un’entitavirtualechepossiedeunidentificatoreunivoco.Attra-versoquestoidentificatorel’ ORB e in gradodi consegnarele richiestedeiclienti al CORBA object.

38

InterfaceApplication

InterfaceDomain

FacilitiesCommon

Object Services

Object Request Broker

Figura2.1: Il ReferenceModeldell’OMA.

Servant: l’entita cheforniscel’implementazionedeiserviziindicati in unCOR-BA object. Il CORBA objectriceve le richiestedi servizi da partedi unaentita cliente. Ad ogni CORBA objecte associatoalmenoun servantcheforniscel’implementazionedelle operazionidelle quali si fa richiesta. InCORBA sonoprevisti differenti linguaggiconcui implementarei servant:Ada, C, C++, Java, Cobol, ecc. Per i linguaggi che sonoorientati aglioggetti esisteunacorrispondenzatra i metodidell’oggettoe l’implemen-tazionedei servizi. Nei linguaggi non orientati agli oggetti, il servant eimplementatocomeun insiemedi funzionipermanipolaredati;adesempioin C, un servant potrebbeessereimplementatocon unastruttura. Proprioperche non sonoi CORBA object ad eseguire le richiestesi definiscono“entita virtuali”.

Skeleton: entitachenelleinvocazionistatichepermettela connessionedi unser-vant con un ObjectAdaptor(OA). Ad esempio,in C, uno skeletone unacollezionedi puntatoria funzioni dei servant; in C++ uno skeletone unaclassedallaqualetutti i servantperun certoCORBA objectdevonoesserederivati.

Stub: contropartedelloskeleton,chepermetteai clienti di farerichiesteal COR-BA object.

Object Id: e un identificatoreunico all’interno di un ObjectAdaptorspecifica-to dal sistemao dall’utente. Non si richiedequindi chetale identificatore

39

siauniversalmenteunico,e sufficienteunaunicita entroil singoloprocessoserver.

Activation: e l’atto di attivareunCORBA object.Affinche le richiestedeiclientipossanoesseresoddisfattee necessariocheal CORBA objectsiaassociatoalmenoun servant.

Deactivation: l’atto oppostodell’activation, richiedechesia distruttal’associa-zionetraCORBA objecteservant.La deactivationnonimplicala distruzio-nedelCORBA object,infatti, unCORBA objectpuo essereriattivatodopounadisattivazione.La disattivazionepuo implicare,tuttavia, la distruzionedel servantlegatoal CORBA objectchesi stadisattivando.

Incarnation: l’atto di associareun servant ad un CORBA object. In altre pa-role, la incarnationfornisceun “corpo” con le necessarieimplementazioniall’oggettovirtualeCORBA object.

Etherealization: e l’atto chedistruggel’associazionetra CORBA objecte ser-vant. Dopo l’eterealizzazioneil CORBA objectcontinuaadesisterecomeentita virtuale, ma non avendoservant, e quindi corpo,non puo portareaterminele richieste.

ActiveObject Map: e unatabellachetramitel’object adaptermantienel’asso-ciazionetra CORBA objecte i suoi servant. I CORBA objectattivi sonoidentificati in tabellaconil loro ObjectId.

L’interazionetra gli oggettinelleapplicazioniCORBA si basasuun model-lo di tipo client-server; questo,abbinatoa concettipropri dellaprogrammazioneorientataagli oggetti,fornisceun modellocheprevedel’esistenzadi un oggetto“client” edun oggetto“server”. CORBA e spessoutilizzatoquandovi sonomo-duli chedevonointeragirescritti in differenti linguaggid’implementazione.Taleimpiego e unaconseguenzaall’utilizzo dell’InterfaceDefinition Language,unaspeciedi linguafrancaconqualepossonointeragirele differentientita. In pratica,adogni CORBA objecte associataun’interfacciaIDL chedescrive quali servizisonoofferti edapartiredaessasi generanoi duemoduli stubeskeleton.AbbiamodettocheOMG gestisceunicamentela produzionee l’aggiornamentodelle specifiche,esistonodi conseguenzadifferenti implementazionidi tali spe-cifiche, alcunecommercialie altre sotto licenzaGeneralPublic Licence(GPL).Inizialmentel’esistenzadi differenti implementazioniabbinataall’assenzadi unaspecificadel formatocon cui interagisconooggettie ORB aveva fattoemergereformati proprietariche impedivanodi fatto l’interazionetra le differenti imple-mentazionedell’ORB. Questoproblemae statosuperatocon CORBA 2.0, gra-zie all’introduzionedi un’architetturae protocolloper l’iteroperabilita tra ORB

40

denominataGeneralInter-ORB Protocol(GIOP). Il blasonatoInternetInter-OrbProtocol(IIOP) nonealtrochel’istanzadel (GIOP)suun trasportoTCP/IP.

2.1.3 La comunicazionetra client eserver in CORBA

Al fine di prendereconfidenzaconla tecnologiaCORBA abbiamoprogrammatoun primo sempliceesempioin cui abbiamoun clientee un server. Il server hafrai suoiserviziunafunzionechestampaunmessaggiosul terminaledellamacchinasullaqualerisiede,mentreil clientsi limita aspedireuncertonumerodi richieste.Questoesempioe statorealizzatocon l’implementazionedi CORBA Orbacus[49], distribuita liberamentealmenoperutilizzi noncommerciali,basandosisulladocumentazionedisponibileal download[34].

In figura2.2sonoillustratele componenticoinvoltein unarichiestadi servizioadun CORBA object.

La richiestadi serviziopartedalclient; il clientconoscel’interfacciadeiservi-zi del servereattraversol’ IDL stube in gradodi formularela richiestadeiservizial CORBA object. La richiestavieneconsegnatadall’ORB il qualecooperaconl’Object Adapteral fine di assicurarechearrivi all’appropriatoservant. L’ Ob-ject Adaptere responsabiledel processodi activatione deactivationdei CORBAobjecte di incarnatione etheralizationdei servant. E l’Object Adapterchege-nerai riferimenti agli oggettiadessoregistrati. Dopoaver individuatoil servantdestinatariodellarichiesta,attraversol’ IDL skeletonvengonopassatii parametridella richiestaalle funzioni offertedal servant. Gli eventualiparametridi ritornofrutto dell’elaborazionedel serviziovengonodirettamenterestituiti al client chehaeffettuatola richiesta.

DII IDLStub

IDLSkeleton

DSIAdapterObject

ServantClient

Giop/IIOP ORBCORE

operation()out args + return value

In args

ORBInterface

Figura2.2: Componenticoinvolti in unacomunicazioneclient-serverCORBA.

41

In realta questonone l’unico modoin cui puo avvenirela comunicazione,visonoinfatti duemodi per effettuarel’invocazionedi un serviziodi un CORBAobject:

� tramiteinvocazionestatica;

� tramiteinvocazionedinamica.

Finoadoraabbiamodiscussodi comunicazionidi tipo client-server, nellequa-li le interfaccedei servizi offerti dal server eranofissatistaticamentea tempodicompilazione.Questotipo di invocazioneappartienealla prima delle duecate-gorie. Esistela possibilita di effettuareinvocazionidinamiche grazieall’impie-go dellaDynamicInvocationInterface(DII) e dellaDynamicSkeletonInterface(DSI). La DII permetteadun’applicazioneclientedi effettuarerichiesteadunog-gettosenzaaverenessunaconoscenzaatempodi compilazionedeiservizidaessoofferti mentrela DSI permettedi scrivere i server senzache lo skeletondebbaesserestaticamentecompilatocon il codicedel server. Il procedimentocon cuiavvienel’invocazionedinamicae simile al precedentesolocheal postodell’IDLskeletone dell’IDL stubvengonoimpiegatela DSI e la DII. La comunicazionedinamicaoffre la possibilita a tempodi esecuzionedi scoprirenuovi oggetti eutilizzarei serviziadessiassociati.

2.1.4 Servizi CORBA

L’Object ManagmentGroup(OMG) definisceun certonumerodi servizisottoleObjectfacilitieschesonoin generaleutili allo sviluppodi applicazioni.Comepertuttele specificheOMG, ecompitodeiproduttoriforniredelleimplementazioniacio chee statospecificato.Elenchiamoalcunidei serviziprevisti:

NameService: permettedi registrareerendereaccessibilioggettitramiteuniden-tificativo.

Event Service: fornisceun meccanismoattraversoil qualegli oggettiCORBApossonospediree ricevereeventi.

Object Trade Service: e simile al NameService,solochepermettedi registra-re e individuarei servizi offerti da un oggettoinvecechela locazioneviaidentificativo.

Time Service: serviziocheabilita l’utenteadottenereun’oracorrentecondivisadatutti gli oggettiCORBA.

42

Security Service: interfacceattraversole quali si accedealle funzionalita di si-curezzacomel’identificazionee l’autenticazionedegli utenti, le autoriz-zazioni che essihannoe strumenticomela firma digitale per ottenerelaNon-repudiation2.

Tali strumentivengonosolitamentedistribuiti in moduli separatidall’ORB, evengonodenominatiCORBA service.

2.2 Primo design

Lo scopodi questasezionee illustrarea livello astrattocomepotrebberoesse-re utilizzate le funzionalita offerte da CORBA per implementaregli strumentiprevisti in D-CaseLP.

2.2.1 Funzionalita da fornir e nell’immediato

Innanzituttoabbiamocercatodi definireunsottoinsiemedi funzionalitadarealiz-zarenel primo prototipodel tool D-CaseLP a partiredal sottoinsiemedel Func-tion RefinementTreeinerenteaquestatesi(secondapartedelF.R.T. presentatoinsezione1.3.4).L’ideaeevidenziarequellecheconsidereremounnucleodi funzio-nalita indispensabilidalqualepartirenellavalutazionedi comeequantoCORBAci aiuti nellarealizzazionedel nostroprogetto.

Commentiamobrevementele funzionalita foglia evidenziatein grassettonel-l’albero in figura2.3, in mododadareperognunaqualcheideadi comepotrebbeessereottenutaesevi sianostrumentiofferti daCORBA checi aiutinonellalororealizzazione.

Documentazioneper l’installazione e utilizzo.

E ovvio chesesi vuolefornire unostrumentodi unaqualcheutilit a a terzi, e ne-cessarioinseriretra gli obiettivi di progettodi D-CaseLP la produzionedi unadocumentazioneragionevolmentechiarasu comesi installanoed si utilizzanoipacchettisoftwarechesi produrranno.Nel casoin cui si decidaeffettivamentedirealizzareil tool di esecuzioneesimulazionein CORBA, si produrraun manualed’installazionein cui per cio cheriguardal’installazionedel run-timeCORBAsi fara riferimentoal manualeutentedellaparticolareimplementazioneutilizzata

2La Non-repudiatione il principio secondocui un clientecherichiedeun servizio,non puosuccessivamentesosteneredi nonaverlo richiesto.

43

1. Modellazioneecreazionedi codiceperil prototipodelMAS.... ... ...

2. Realizzazionee validazione di un prototipo della applicazionesottosviluppo.

(a) Installazionedegli strumenti offerti da D-CaseLP.� Supportoall’installazionevia proceduredi installazione.� Documentazioneper l’installazione e l’utilizzo.

(b) Implementazioneprototipo del MAS.

i. Integrazione� Integrazionelegacy software.� Integrazionesemantica.

ii. Supporto alla comunicazione.iii. Supportoalla mobilita.

(c) Monitoraggio e Simulazione dell’esecuzionedel prototipo delMAS.

i. Configurazionedell’esecuzione.� Comedistrib uir e gli agenti.� Dove recuperare il codicedegli agenti.ii. Monitoring grafico.� Visualizzazionedelladistribuzionedegli agenti.� Visualizzazionedellecomunicazionifra gli agenti.

iii. Strumentidi simulazione.� Parametridellasimulazione.

– Ritardi sui canalidi comunicazioneo canaliinaffidabili.

– Input agli agentiin simulazione.

– Distribuzionedegli agentidurantela simulazione.

– Gestionedel tempo.� Supportoperla visualizzazionedei risultati.

– VisualizzazioneOn-Line.

– VisualizzazioneOff-Line.

3. Implementazionedellaapplicazionefinita.

4. Utilizzo dellaapplicazionefinita.

Figura 2.3: FRT conevidenziatele funzionalitachesarannosupportatedalprimoprototipodi D-CaseLP. 44

(Orbacus), mentreper i packageda noi prodotti si specifichera dove andran-no collocatie comedovrannoessereutilizzati in documentazionecompletamentenuova.

Supporto alla comunicazione.

La questionecentralefra le problematichedella tesi e comeimplementarela di-stribuzionedegli agentiderivantidallaspecificasecondola metodologiaCaseLPo D-CaseLP. Abbiamoimpostatoil lavoro in mododaracchiuderel’interazionetra i livelli di specificaedil livello di comunicazionein unaunicainterfacciapre-sentatain tabella1.1; taleinterfaccianasceappuntocomeanellodi congiunzionefra la specificae l’esecuzione.La questionequindi si trasformain comeimple-mentarele primitivedi comunicazioneappartenentiall’interfaccia.Si rimandaladiscussionealla sezione2.2.2.

Comedistrib uir e gli agenti edove recuperare il codicedegli agenti.

Con questefunzionalita intendiamola possibilita di indicarecon qualecodiceesuquali macchinegli agentidevonoessereattivati. CORBA nonoffre strumen-ti propri sull’attivazionedi processiin remoto,dovremoquindi appoggiarciaglistrumentiofferti dal sistemaoperativo sulqualele applicazioniverrannoeseguiteo programmarenoi delleapplicazionicheforniscanoun“front-end”3.

Visualizzazionedellecomunicazionifra gli agenti.

Ancheperquestafunzionalitanonvi esupporto.EssendoCORBA unmiddlewareperoggettidistribuiti nonci aspettavamol’esistenzadi untool specificoperagenti,piuttosto,unaqualchespecificastandardperservizidi debuggingdellechiamateai servleta partiredallaqualerealizzareil visualizzatoredellecomunicazionitraagenti. L’inesistenzadi specifichestandard,nonescludechele differenti imple-mentazioniforniscanoestensioniproprietarie.Non sembrachevi siasupportoinquestadirezionenell’implementazioneda noi candidataall’utilizzo. Rimandia-mo unatrattazionepiu dettagliataa quandoavremospiegatocomesia possibilerealizzarela comunicazione.

2.2.2 Comerealizzarela comunicazionetra agentivia CORBA

Abbiamovisto quantola comunicazionechein CORBA e di solito associataadunarichiestadi servizio,sottointendaun modellodi tipo client-server. In questa

3Con l’espressionefront-endintendiamoun’applicazionechecoordini e facciada interfacciafra l’utilizzatoree le funzionalitaprecedentementedescritte.

45

ottica,implementarele primitivedi comunicazionesignificadefinireun’interfac-cia IDL contenentelasegnaturadeiserviziforniti dall’oggettoCORBA; nelnostrocasorifacendociaquestomododi impostarele cose,dovremmodefinireun’inter-facciacontenentele nostreprimitivedi comunicazionee prevederedifferentiog-gettiCORBA chepermettanoallenostrespecifichedi parlarefra di loro. In figura2.4,abbiamoschematizzatoun’architetturaper la comunicazionenel casodi dueagenti. In tale ipotesiavremoper ogni agenteun placeholder: oggettoCORBAcheoffre le funzionalitadi serverdi comunicazione,esi occupadi mantenereunamailboxconla qualel’agentepotra interagire.

PlaceholderAg1

PlaceholderAg2

Set of CORBA Objects

Client - Server CommunicationClient - Server

CommunicationPeer to Peer

Communication

Agent 1 Agent 2

Figura2.4: Un modopossibiledi per far comunicaregli agenticon l’impiego diplaceholder.

Assumiamochel’argomentodelleprimitivedi comunicazionesianomessaggiespressiin un qualcheAgent ComunicationLanguage[22, 24], a grandi lineele tre primitive di comunicazioneche abbiamoprevisto potrebberoesserecosıprogettate:

send(msg): l’agentechevuole spedireil messaggiomsg lo passaal suoplace-holder; quest’ultimoesaminail contenutodel messaggioed in particola-re estrael’identificativo del destinatario;quindi contattail placeholderdeldestinatarioegli consegnail messaggio.

receive sync(msg): l’agenteaspettacheil suoplaceholdergli passiunmessaggiocondeterminatecaratteristiche(es. mittenteo performative particolari). Ilplaceholderpassail messaggioall’agentein attesaprelevandolodallamail-box. Senonvi sonomessaggiconle caratteristichedesiderateil placeholderaspettachenearrivi uno,nel frattempol’agenterimanebloccato.

receive async(msg): l’agenteinterrogail suoplaceholderchiedendoglisevi eunmessaggiocondeterminatecaratteristiche.Seun messaggiocontali carat-

46

teristichec’e vienerestituito,comunquesia il controllo ritorna all’agentecheproseguela suaesecuzione.

Si osserviche una richiestastandardad un oggettoCORBA si traducein unaesecuzionedi un metodoo funzionee sarebbequindi persuanaturasincrona.Inrealta in CORBA sonoprevistetre tipologiedi invocazionisincrone:

SyncronousInvocation: il clienteinvocala richiestaesi bloccaaspettandola ri-sposta.Questae la piu comunetipologiadi invocazioneessendosupportataanchedall’invocazionestatica.

Deferred SyncronousInvocation: il cliente invoca la richiestae continual’e-secuzionementrela richiestavieneeseguita, successivamenteraccoglielerisposte.Questotipo di invocazionepermettedi invocarepiu serviziadela-borazionelungacontemporaneamentee raccoglieresuccessivamentetuttele risposteinvecechesequenzializzarele richieste.

OnewayInvocation: il cliente invocaun servizioe continuala suaesecuzioneperchenonvi e rispostadaattendere.

La DeferredSyncronousInvocatione supportatasoloda invocazionidinamiche,ma l’OMG sta lavorandoper renderlaaccessibileanchenelle invocazionistati-che. Nel casodelle primitive di comunicazioneda noi definitela sendpotrebbeessereun’invocazionedi tipo Oneway; la receive sync(msg)potrebbeessereditipo SyncronousInvocation;la receive asyncpotrebbeessererealizzataattraversounaSyncronousInvocationin cui nel casononvi sianomessaggisi restituisceilmessaggiovuoto. I parametridelle dueprimitive di ricezionepotrebberoesserepassatiperriferimentoin mododafungereanchedaparametridi ritorno.La comunicazionedaagenteaplaceholderedi tipo client-server, mentrela comu-nicazionedaplaceholdera placeholdere di tipo peer-to-peer, in cui i dueattoridellacomunicazionegiocanoa turnoil ruolo di clientee poi di servitore.Questaimpostazionepresupponerisolverealcuni problemi, illustriamo con un esempioil primo. Consideriamoil casoin cui si stianoeseguendotre agentiA,B,C sutreprocessoridifferenti, ed il placeholderdi A stia comunicandocon il placehoderdell’ agenteC, ed il placeholderdell’agenteB voglia iniziareanch’essounaco-municazionecon il placehoderdi C. E evidentecheil placehoderdeve essereingradodi gestireconcorrentementepiu richieste,none comunquepensabilecheilplacehoderB chedeveconsegnareun messaggiorimangaimpegnatofino a cheilplaceholderdi C nonabbiaterminatola comunicazioneconA.La situazioneeaggravatadal fattochele componentiplaceholderpossonogiocareil ruolodi serverperaltri placeholdereancheperl’agenteallaqualesonoassocia-ti. La soluzioneaquestiproblemiconsistenelstrutturareil placehoderin Thread,unoperognirichiesta.In CORBA eprevistala possibilitadi strutturarei CORBA

47

objectin modocheadogni chiamatavengaautomaticamentegeneratoun thread,talefunzionalita e statapotenziatanelnuovo ObjectAdapter:POA [60, 34].

2.2.3 Configurazionedegli agentiprototipali per l’esecuzioneesimulazione

Unavolta descrittele ideesucomesi possanosfruttarele funzionalitacheCOR-BA offre circa la comunicazione,illustriamo comesia possibileaggiungerelostratodi comunicazioneagli agentiprototipali risultanti dalle fasi di specifica.Innanzi tutto, osserviamoche l’aver creatospecifichesull’astrazionedell’inter-facciadi comunicazione,rendepossibileavvalersidi differenti implementazioninelle fasi di sviluppodel MAS e comequestopossaessereutilizzato all’internodelprocessodi sviluppoavantaggiodell’utente.Consideriamoatitolo di esempiole seguentiimplementazionidelleprimitivedi comunicazione:

ImplementazioneCORBA. Si fornisceuno stratodi comunicazionebasatosuCORBA simile aquellodescrittoin precedenza.

Implementazioneconmonitoring. Si fornisceunostratodi comunicazioneba-satosu CORBA o un’altra tecnologiain cui per ogni messaggiochespe-discel’agente,sene spedisceunacopiaad un agenteprepostoad essereil monitordellacomunicazione.In manieraanalogapuo essereottenutoilmonitoringperla ricezionedi messaggifacendospedireil messaggiocopiaalle receivepiuttostochenellasend.

Implementazionefornita dall’utente. L’utentefornisceimplementazionida luisviluppatein cui offre un’implementazionedell’interfacciadi comunicazio-nebasatasutecnologiediversedaCORBA.

Ipotizzandodi avere a disposizionele tre implementazioniprecedentidelleprimitive, si potrebbeimpiegarel’implementazionecon le primitive chepermet-tonoil monitoringnelleprimefasidi sviluppo,e successivamenteunadellealtredue.

Affinche l’utente trovi effettivamentevantaggionellapossibilita di intercam-biare le diverserealizzazionidelle primitive, dovremoprestareattenzioneai se-guentifattori:

� impatto che l’aggiunta dello stratodi comunicazioneha sul codicedegliagentiprototipali;

� assunzioniche si sonofattesul linguaggiocol qualesonostati scritti gliagentiprototipali.

48

Circoscrivendole modificheche e necessariooperarenel codiceper cambiarel’implementazionedellacomunicazionediventasemplicefornire strumentiauto-matici cheoperinoil cambiamentoda un’implementazioneall’altra. Allo stes-so tempo,ondeevitare di legarel’iterscabiabilita delle implementazionisolo adagentisviluppatiin unodei duelinguaggiconi quali un agentepuo esserescritto(Java, o estensionidelProlog), nel fornireunasoluzionesi dovra fareattenzioneanonutilizzarecaratteristichetroppopeculiaridi unodi essi.Prolog eJava sup-portanoentrambila programmazionemodularee offrono quindi la possibilita diorganizzareil codicein piu moduli. Si potrebbesfruttarequestacaratteristicaperisolarela definizionedelleprimitivedi comunicazionein moduli separatirispettoal codicedegli agentiderivantedalprocessodi specifica.In questomodola sosti-tuzionedell’implementazionedellespecificheconsisterebbenellasostituzionedelmodulochele implementa,eal limite, nelcasoin cui nonvi sialoadingdinamicodi moduli in unaricompilazionedel codice.In figura2.5abbiamoschematizzatole componenticoinvoltenellacomunicazionetraagenti.

Java

Agent

Prolog

Agent

ComunicationModule

Corba ORb

Prolog

ModuleComunicationrecive_sync

send

recive_async

Corba OBJ

PackageJava

Module

OBJCorba Agent Placeholder Agent Placeholder

Figura2.5: Integrazionedelleprimitivadi comunicazionenegli agentiprototipalidi D-CaseLP.

Dalla documentazionesuCORBA difficilmenteci si rendecontocheun pro-gramma,nel nostrocasoun agente,per poteressereclientedi oggettiCORBAdeve averenel suocodiceun qualchetipo di registrazioneal ORB. Questofat-to ha conseguenzeun po’ piu generalidi cio checi si aspetterebbe,in quantoepresumibilechenon sia unaesigenzaesclusiva di CORBA, la conseguenzapiuimmediatae cheprimadi fareunaqualsiasioperazionefra quelledell’interfacciadi comunicazionel’agentedeve registrarsiall’implementazionedelle primitive.Nel casospecificodi CORBA abbiamobisognochel’agentesi siaiscritto ai ser-vizi dell’ORB eabbiarisoltocio chee il riferimentologicostandarddelORB conun riferimentofisico. La questioneaquestopuntodiventacomeedove inserireil

49

codicerelativo allaconnessioneal stratodi comunicazionenelcodicedell’agente.Le istruzioni per la connessioneal ORB o al genericolayer di comunicazione,potrebberoessereinseritenel codicedegli agentiin unodeiseguentimodi:

� fornendoun traduttorechetrasformagli agentiprototipali in agentida si-mulazione;

� estendendol’interfacciadi comunicazioneconunaprimitivadi iscrizioneallivello di comunicazionesottostantegli agenti.

La prima delle duealternative prevedela manipolazioneautomaticadel codicedegli agenti,e l’inserimentodi un “cappello” nel codicein cui vengonoscritteleistruzionio i predicatinecessarialla connessioneconil serviziodi comunicazio-ne.4

La secondaipotesiepiu elegantein quantononbucal’astrazionefornitadall’inter-facciadelleprimitivedi comunicazione,maallo stessotempodelegaall’utentelaresponsabilitadi effettuarela connessioneconil layerdi comunicazioneattraversounaprimitivadi “iscrizione” ai servizidi comunicazione.

2.2.4 Funzionalita aggiuntive

Indichiamoqui, un insiemedi funzionalita chenonsonostateprevistenel F.R.Tma che possonoaiutarci a fornire un tool piu versatile,in cui ad esempiosiapossibileaggiungerea MAS gia progettatinuove istanzedi agenti. Supponiamodi avereun’“ambiente”in cui gli agentivivonoconun qualcheidentificativo as-sociato. Indipendentementeda chi e comesia fornito questoambiente(sistemaoperativo, un platform,un middleware)i seguentiservizisi possonoincludereinesso:

Dir ectory Service: funzionalita chepermettedi risolverel’identificativo simbo-lico associatoadunagenteconl’indirizzo “fisico” dell’agente.

Yellow PagesService: funzionalita chepermettedi individuare,datala descri-zionedi un certoservizio,l’identificativo degli agenticheoffrono taleser-vizio.

Questefunzionalitanoncompaionoall’internodelF.R.T. sucui abbiamoragiona-to fino adora,in quantopotrebberoanchenonesserefornitedalleimplementazio-ni di D-CaseLP. Si potrebbeinfatti pensaredi demandarela loro progettazioneall’utentedi D-CaseLP, chedi volta in volta includenella sviluppodel proprioMAS anchedueagenticheimplementinole funzionidi directoryserviceeyellow

4Si dovrapensareancheall’inserimentodel codicedi sconnessione.

50

pagesservice.In realtasesi consideranoi dominiapplicativi e le problematichechenormalmen-te ci si proponedi risolverecon la tecnologiaagenti,vi sonobuonemotivazioniper includerenel nostrotool la progettazionedi entita cheforniscanotali servi-zi. Illustriamole motivazioniutilizzandoun sempliceesempioin cui vi sonodueagenti e . All’atti vazioneognunodi essisi registraal serviziodi connessione,dopodi che spedisceun messaggioa . Questoesempioe molto semplicemain essoabbiamofattogiaalcuneassunzioni:

� conoscel’esistenzadi un agente ;

� conoscel’“indirizzo” di .

La prima delle dueassunzionisignificachea “tavolino” si e decisochenel no-stroMAS vi sara l’agente , edessononnascene muoreimprovvisamentemaecomponentecostantedell’architetturadel MAS. In altreparoleabbiamopresup-postochel’architetturadel MAS si compongadi un numerodi istanzedi agentiprefissato.La secondadelleassunzioniindicachequalcunohapassatol’indirizzoattualedi ad , taleindirizzo estatopresumilmentepassatoin inputad dopol’inizio dell’esecuzionedi . Nel casoin cui si dispongadi un directoryservicealmenola secondaassunzionedecade,infatti l’agente puo chiedereal directoryservicequal e l’indirizzo attualedi . La presenzadi un yellow pagesserviceciaiutaad evitare la prima ipotesi,chein realta sottointendeanchela conoscenzadel fatto cheesisteun agentedi nome , col qualel’agente deve interloquireal fine di arrivareai suoi obiettivi. Con l’introduzionedel yellow pagesservicenone piu necessarioche conoscal’esistenzadi un agentedi nome : gli bastasaperequaletipo di servizionecessitae sulla basedi essointerrogareil yellowpagesservercircachi forniscetaleservizio.Facciamonotarequantole dueassunzionipossanoesserelimitanti, in particolaresesi pensaai contestiin cui il paradigmaad agentidovrebbetrovaremaggioreapplicazione,contesticaratterizzatidalla necessita di un buon livello di scalabi-lit a in cui spessovi e la necessita di crearedinamicamenteagenti in funzionedell’evolversidellacomputazione.

Alle considerazioniprecedentivannounitealcuneosservazioniderivantidagliobiettivi chesi poneD-CaseLP. D-CaseLP vuoleessereprimadi tutto un am-bientechefaciliti la prototipazionee lo svilupporapidodi sistemimulti-agenti.In questosensola presenzadi un directory serviceed un yellow pagesservicenon puo che esserevista positivamente. Allo stessotempofornire questeduecomponentipuo significareaumentarela moledi lavoro in manieranotevole. Sevogliamomantenerel’interscambiabilita dellediverseimplementazionidelleco-municazioni,bisognafornire un directoryserver e uno yellow server pagesche

51

nondipendanodal tipo di implementazionedel livello di comunicazionee offra-no adesempioun formatodi indirizzi fisici pergli agentiabbastanzagenericodaincludereindirizzi di postaelettronicafino adindirizzi IIOP.

Cio chedobbiamochiarirein questafasedi valutazionecirca l’effettivo van-taggiochesi ha nell’adozionedi CORBA ai nostri scopi, e quantoi servizi inessoofferti, quali NameServicee ObjectTraderService,possanorisultareutilialla costruzionedi undirectoryservero un yellow pageserver.

NameService eDir ectory Service.

Per sfruttareil nameservicecomeDirectory servicee necessarioassociareunagentead un oggetto.Si e molto discussosulladifferenzacheintercorretra og-gettoed agentee non e nostraintenzionerimetterein discussioneil fatto cheleduecosesonoprofondamentedifferenti. Cio chee importantetenerepresenteechequestadifferenzanonimpediscedi svilupparesistemiadagenticonlinguag-gi orientatiagli oggetti. Sesi individuaun oggettochefacciada rappresentantedell’agente,adesempioil placeholdernel nostrocaso,nonvi dovrebberoesseregrossedifficoltanell’utilizzo del NameServicecomedirectoryservice.

Object Trader Servicee Yellow PagesService.

L’ ObjectTradeServiceforniscegli strumentichepermettonoagli oggettiCOR-BA di importareedesportarefunzionalita. L’ideasibasasull’esistenzadi unTradeObjectchefa daintermediariotra gli oggetti.Quandoun oggettoCORBA vuolepubblicizzareun suoserviziotramitel’operazionedi esportazioneda unadescri-zioneal TradeObjectdel serviziochevuole esportare.Seun oggettoCORBAvuole inveceimportareunafunzionalita fornisceal TradeObjectunadescrizio-nedel serviziodi cui necessita;l’intermediarioapplicandoun qualchecriterio disimilarita con la descrizionecheha ricevuto restituiscei fornitori chedichiara-no di offrire tali servizi. Il fulcro della discussionea questopuntosi spostasulformato della descrizionedei servizi. Le funzionalia offerte da CORBA sonopensateperoggettie nonperagenti;ci serve capirequantoriusciamoadadattarela descrizionedi un serviziodi un oggettoCORBA coni servizidi un agente.

A questoscopoillustriamo la descrizionedi un servizio nella specificadelTradeObjectService:

� unainterfacciachedefinisceun segnaturacomputazionaledel servizio;

� zeroo piu “namedpropertytypes”cherappresentanoil comportamentodelserviziocatturandogli aspettinoncomputazionalichenonsonoesprimibilinellasegnatura.

52

Unapropertytypeedefinitacomeunatripla (nome,tipo,modalita)dovela mo-dalita esprimesela proprietachedescrive eobbligatoriaod opzionale,eccetera.

E benericordarechesi accedeadunserviziofornito daunoggettotramiteunachiamataa metododel oggetto,mentrela richiestadi servizioperagentiavvienetramiteunacomunicazionefra gli agentiespressain un qualcheAgentComuni-cationLanguage.Un messaggioespressoin un qualcheagentcomunicationlan-guageconterra informazioniquali il destinatario,il tipo di azionelinguisticacheecontenutanelmessaggio(performative), il corpodelmessaggio,un’ontologiacheassociaunasemanticaai termininel corpodel messaggio.

La primaosservazionechesi puo faree cheun serviziodi unagentepotrebbenonavereunasegnatura,o almenononavereunaunicasegnatura.E chiarochea livello astrattosi potra associareai servizi offerti dagli agentidelle funzioni equindiunaqualchesegnatura,manonedettochel’associazionesiacosı immedia-ta comepergli oggetti. Cio ci dovrebbefar intuire chevi sara qualchedifficoltanell’adattareObjectTradeServer ai nostriscopi.

2.2.5 Considerazionidi valutazione

E evidenteche le ideecheabbiamofornito richiedanoancoramolto lavoro peressererealizzate,vi sonoalcunipunti nellaprogettazionechesonorimastiaperti.Tuttavia, la progettazionefornitaesufficienteadeffettuarele considerazionidi va-lutazionecheseguonosull’impiegodi CORBA perrealizzarela distribuzionede-gli agentiD-CaseLP. Partiamodaquelli chesonotradizionalmenteconsideratiipuntidi forzadi CORBA: comunicazionedi componentidistribuiti eeterogeneitadellecomponenti.

Comunicazionedi componentidistrib uiti.

Indipendentementedaivincoli progettualiimpostidaD-CaseLP la comunicazio-ne tra oggettio generichecomponentisoftwaree profondamentedifferentedallacomunicazionefra agenti. La prima e basatasu unalogica client-server in cuivi e un clientecherichiedeun servizioadun servitore.Non vi e interpretazionenedaunapartenedall’altra dellacomunicazioneed il servitorenonpuo rifiuta-re di servireunarichiesta. La secondautilizza una logica di tipo peer-to-peerin cui nonvi sonone servitori ne clienti madueentita paritarieche“discutono”e collaboranoper ottenereun obiettivo. Il paradigmaad agentipresupponeunacomunicazionesimile a quellaumanachea differenzadi quellafra oggetticoin-volge tre livelli di astrazione:trasporto,linguaggiodi comunicazioneper agentiedontologie5.

5Nel casodella comunicazioneumanai tre livelli di astrazionepotrebberoessere:il mezzodi comunicazione(unalettera,la voce,ecc.),la linguautilizzata(italiano,tedesco,inglese,ecc.),

53

Qualorasi riescaadottenereunacomunicazionepeer-to-peerin CORBA se-guendola progettazionecheabbiamoillustratosi otterrebberosologli strumentipereffettuareil livello di astrazionepiu bassodellacomunicazionetra agenti: iltrasporto.

La comunicazioneoffertadaCORBA e utile alla realizzazionedellacomuni-cazionetraagentisoloperil livello di astrazionepiu basso:il trasporto.

Eterogeneita dellecomponenti.

In D-CaseLP vogliamointegrarenell’esecuzionedelMAS duetipologiedi agentiAg-Prolog edAg-Java rispettivamentescritti in Prolog edin Java.

Uno dei motivazioni che hannoportatoalla valutazionedi CORBA per ladistribuzionedi agentiin D-CaseLP e la possibilita cheessooffre di integrarecomponentiscrittein differenti linguaggidi programmazione.L’OMG specifical’associazionetra l’InterfaceDefinition Language(IDL) e vari linguaggidi pro-grammazionefra cui C, C++, Java, Lisp. Purtroppo,essendocialcunadefinizio-nedi questotipo perProlog, non e possibileintegrareProlog e Java attraversoCORBA rimanendoall’internodellespecificheOMG.

In [61] e indicataunastradaproprietariaperintegrareCORBA eSWI-Prolog,unaparticolareimplementazionedi Prolog. Tale integrazionesembraoffrire uncompilatoreIDL basatosulla possibilita di far interagireProlog con il C. Al dila del fattochevi sonodegli elementichesembranolegarela soluzionepropostaa particolari implementazioniCORBA, non e statopossibilecomprenderedalladocumentazionel’effettivo statodi realizzazionedegli strumentidescritti. Perquestimotivi si ritieneutile valutarealtrestradeal fine di ottenerel’integrazionedell‘esecuzionidegli agentiAg-Prolog eAg-Java.

2.2.6 Conclusioni

L’analisi di CORBA e della suaapplicabilita nel realizzarei nostri obiettivi harichiestoun certo investimentodi risorse,quindi riteniamodi dover concludereillustrandoschematicamentele ragioni chehannoportatoall’abbandonodi que-stastrada,in modochealtri di frontea necessita simili alle nostrepossanotrarrevantaggiodallanostraesperienza.Abbiamosuddiviso le motivazionicheci han-no portatoa non adottareCORBA in due categorie: inerenti al dominio degliagentie dipendentidal progettoD-CaseLP. Le inerential dominio degli agentisonoi problemie le difficolta chesi incontranonel cercaredi utilizzareCORBAindipendentementedalleipotesidel nostroprogettoperil solofattochesi stauti-lizzandounostrumentochenoneunmiddlewareperagenti,mentrele dipendenti

l’accezionedei termini chevengonoutilizzati nelladiscussione.

54

dal progettoD-CaseLP sonole difficolta e gli impedimentichesonodamettersiin relazionealleparticolariipotesicheabbiamofatto.

� Inerential dominiodegli agenti.

Modello di comunicazione.CORBA offre unacomunicazionechee ba-satasulmodelloclient-servere nonsulpeer-to-peer.

Astrazionedella comunicazione.La comunicazioneper gli agenticoin-volegedifferenti livelli di astrazione,CORBA e utilizzabile solo peril livello di trasporto,peroffrire unmezzodi comunicazione.

� DipendentidalprogettoD-CaseLP.

IntegrazioneagentiAg-Prolog eAg-Java. Comeabbiamospigatonel-la sezioneprecedentenonc’e possibilitadi utilizzareCORBA perot-tenereun’integrazioneportabile fra agentiscritti in Java ed agentiscritti in Prolog.

Considerazionisulle risorsecon cui affr ontiamo il progetto. Vistalamo-le di lavoro necessariaperraggiungeresolopartedegli agli ambiziosiobiettivi checi siamoposti, e giustovalutarebenele conseguenzediunasceltacomequellachesi prospettaessereCORBA. Conle attualirisorsedi forza-lavoro di cui disponiamopartire da una distribuzio-nebasataCORBA significarischiaredi averei primi risultati quandosarannoobsoleti.

Dalleosservazioniprecedentisi comprendecheil supportocheCORBA offrein ambitodi distribuzioneed integrazionedi componentieterogenene,diventanopiuttostolimitato nel contestodelladistribuzionedegli agentiin particolaresottole ipotesidanoi fatte.Perquestoabbiamodecisodi scegliereunapolitica di pro-gettodifferentedaquellaconla qualeeravamopartiti, edadoperarcinel recuperodi componentioffertedaterzi.

55

Capitolo 3

FIPA

In questocapitolopresenteremoquellachee iniziativadi standardizzazioneFIPA,illustrandogli obiettivi cheessasi prefiggee parti dellespecifichechesonostateproposte.La iniziativadellaFIPA hannoreppresentatoun puntodi riferimentodifondamentaleimportanzaperquestolavorodi tesi: la progettazionedi D-CaseLPestatainfluenzatain modosostanzialedallespecifichechepresenteremoin questocapitoloedin particolaredall’architetturaastratta[28]. Il capitolopuo esseresud-diviso in dueparti: la primaillustra la struttura,gli obiettivi edil mododi lavoraredell’organizzazione;la secondafornisceunapanoramicasuunsottoinsiemedellespecificheprodottedallaFIPA inerenteagli scopidi questatesi. Perconcludereillustreremobrevementealcuni progetti di validazionedelle specificheFIPA edalcunenostrevalutazionisull’iniziativa. Si tengacontofin dasubitochela stan-dardizzazioneFIPA stariscuotendomolto interessesiain ambitoaccademicochein ambitoindustriale. Tale sforzocongiuntopotrebbefar diventareappetibilelatecnologiaadagentipersviluppareapplicazioni“reali”. Anchenelcasoin cui cionon accadesse,il lavoro della FIPA avrebbecomunquecontribuito a mettereinevidenzaproblematichesullequali focalizzarela ricerca.

3.1 Intr oduzionealla FIPA

La FIPA [23], acronimodi Foundationfor IntelligentPhysicalAgents,nascenel1996conlo scopodi promuovereattraversola produzionedi specifichestandardliberamentefruibili, la diffusionedelle tecnologiebasatesu agenti software ehardware.Taleorganizzazioneecompostadauncertonumerodi gruppidi ricercaedunforumdi aziende,fra le qualialcuneoperantineldominiodelletelecomuni-cazioni.Giustoperdareunaideadellaportatadell’organizzazioneedell’interessechehasuscitato,si puo direcheasettembredel2000la FIPA vedevatrai suoisocirappresentantidi circa65societa,tuttoravi sonoassociatirappresentatidi aziende

56

comeBritish Telecommunications,FranceTelecom,IBM, Hitachi, Intel, Motoro-la, Siemens,Sun,Toshiba.Gli obiettivi di taleorganizzazionesonoesplicitatinel“missionstatement”costitutivo cheriportiamoin figura3.11.

La promozionedelle tecnologiee specificheper l’interoperabilita chepermetta-no l’interoperazionefra sistemiad agenti intelligenti in contesticommercialieindustrialimoderni.

Figura 3.1: Missionstatementcostitutivo dellaFIPA.

Nonostantei propositiiniziali cheprevedevanola produzionedi specificheperagentihardware(Robots)e software,la FIPA hafinito col concentrarsinellapro-duzionedi specificheperagentidelsecondotipo. La forteattenzioneprestatadallaFIPA alle problematichelegateall’interoperabilita e comunicazionedegli agenti,haindottoalcuniharibattezzarel’acronimodell’organizzazionein FoundationforInteroPerableAgents.

Nelle sottosezionisuccessive, analizzeremoalcunidei fattori chehannopor-tato all’intento di standardizzazione,illustrandopoi i principi e la portatadelprocessosullabasedelleosservazionievidenziatein [52] edin [14].

3.1.1 Fattori dai quali scaturiscelo standard

Descriviamoquelli chesonoi duefattori chehannoportatoall’iniziativadi stan-dardizzazionedi cui si e fattacaricola FIPA.

Molti framework differenti evisioni pococonciliabili.

Le ricerchesugliagentiiniziaronomolti anniaddietroal 1995,in quegli annipero,la situazioneche si andava delineandovedeva da unaparteuna rapidacrescitadell’interesseintornoagli agenti,dall’altral’emergeredi unavarietadi frameworkconapproccie visioni differentichedavanoluogoasistemiincapacidi interagiretra loro.

Oltr e il confinedella ricercaaccademica.

Al di fuori di quelli chesonogli ambientidi ricercaspessovi eunacertaresistenzaadadottaretecnologieo “Standard”in cui nonvi sial’accordodi uncertonumerodi compagnie.Per far si cheil paradigmaad agentiprendessepiedeeraneces-sariochevi fosseun certalegittimazioneda partedegli ambientiindustriali. La

1Riportiamoqui anchela fraseoriginale:”The promotionof technologiesandinteroperabilityspecificationsthat facilitate the end-to-endinterworking of intelligent agentsystemsin moderncommercialandindustrialsettings”.

57

standardizzazioneportataavanti dallaFIPA e frutto del crescenteinteressedimo-stratonegli ambiti industrialiper il paradigmaadagentimae ancheun tentativodi ottenerequestalegittimazione2.

3.1.2 Assunti eprincipi nella produzioneFIPA

Descriviamo i principi di cui e permeatala produzioneFIPA, avremo mododiosservare quantoquestisi riflettano a vari livelli nelle specifichee nelle scelteprogettualidellaFIPA.

La primacosachebisognachiarireechela FIPA si proponedi produrrespeci-fichepersistemimulti-agente“aperti”, ovverosistemichegodonodellaproprietadi openness. Definiamotale proprieta a partiredalla descrizionepresentatain[14]:

Definizione3.1 La opennesse unaproprieta chepossonoavere i MAS cheper-metteagli agentidi unirsi o lasciareunMAS a tempodi esecuzionesenzachesianecessariaalcunaricompilazioneo unariconfigurazionedel sistema.

Perillustrarel’utilit a dellaproprieta riconsideriamol’esempiodel sistemaper ilcontrollodel traffico aeroportualedi cui avevamoparlatoin 1.3.2. Nell’esempioin questionesi avevaun agentedi classeAircraft associatoadogni aeroplanochevolevaatterrarenell’aeroportodi cui il MAS gestisceil traffico. In talecontestoepresumibilecheperogninuovo aeroplanocheentrinellazonacontrollatadall’ae-roportosi creiunagenteAircraft checontrattil’atterraggiodell’aereoconla torredi controllo. Allo stessotempo,quandoun aereolasciala zonacontrollatadal-l’aeroporto,l’agenteAircraft dell’aereoin questioneuscira dal MAS. E evidentechela creazionee la cancellazionedi agentideveavveniredinamicamente,nonsipuo pensaredi riavviareil sistemaognivoltachecambial’insiemedegli aereiconcui la torredi controllointeragisce.E dunquequestounesempioin cui tornautilesupportarela proprietadi openness.

Il secondoprincipio alla basedellespecificheFIPA potrebbeesseredenomi-natoprincipio di minimalit a. La minimalita e intesaadevitarechele specificheprodottesi leghinoadun particolarehardware,sistemaoperativo o linguaggiodiprogrammazione.Conil principio di minimalita si vuoleassicurarechele speci-ficheoffranounacertagenericitaeastrazione,in mododafornireunmodellochepossaessereunavisionecomunea diversiapprocci,unaspeciedi “fondamento”dal qualepartire.

2Si tengapresentechela standardizzazionee ancorain pienacorsad’opera,e cheunapienalegittimazionehacomeprerequisitol’esistenzadi unostandard.

58

3.1.3 La portata dellespecificheFIPA

Quandoci si proponedi operareun processodi standardizzazionee importanteindividuarefino a dove si spingatale intento: qualesia il suoconfine. Nel casodegli agentiabbiamoundominiomoltoampioevario,sepotessimopensarlocomeuno spaziogeometricoavrebbeprobabilmenteparecchie“dimensioni”, ognunarappresenterebbeunaproprieta con cui si possonocaratterizzarei MAS. Non esemplicecapirese tutte questedimensionidescrivono uno spazio“ortogonale”e di conseguenzasesonoun buonsistemadi riferimentoper caratterizzaretuttolo spazio,comunquevincolarealcunedi questedimensionia precisiintervalli ciaiutaaporredei limiti nel campodi azionedel processodi standardizzazione.

Intelligenza esterna.

La FIPA si proponedi standardizzarela comunicazioneesternaagli agentievi-tandodi trattarecomegli agentipossanoprocessarei dati ottenuti dalla comu-nicazione3. Cio significache la FIPA si limita ad occuparsidei problemi lega-ti al macro-livello4 degli agenti,evitandodi fareassunzionio fornire specifichesul micro-livello dell’agente,o peggio, legarsiadunaparticolarearchitetturaperagenti.

Neutralit a.

Vieneapplicatoil principio di minimalita di cui si discuteva primaancheperca-pire il livello di astrazionechedeve esseresupportatodalle specificheFIPA. Enegli intenti dell’organizzazionemantenerele specificheil piu possibilegeneralieneutralirispettoa

� servizispecifici5;

� impiego strumentisoftware, infrastrutturehardware e linguaggi d’imple-mentazione.

3Non si occupadel micro-livello, anchesealcuniadesempioin [14] hannofattonotarechelasemanticadi FIPA ACL e statafornita in terminidi credenze(belief),desideri(desire)e intenzioni(intention)e questopotrebbeindurrea fareconfusionesuquestopunto.

4Il macro-livello nella progettazionedei sistemimulti-agentesi riferiscealle problematichechesi occupanodell’iterazione,delle ralazionie dellaconcorrenzatra gli agentiappartenentiaduno stessoMAS. Il terminemicro-livello, invece,si riferiscealle problematicheinerential sin-golo agente,i comportamentie le attitudini di cui deve esseredotato,l’architetturapiu adattaperesprimerele sueattivita.

5Deveesserepossibileaggiungereservizidipendentidalproblemae daldominioapplicativo.

59

Messaging Directory ACL

Concrete Specification: CORBA Elements

Concrete Specification: Java Elements

Abstract Architecture

Messaging Directory ACL

Concrete Realization: CORBA Elements

Concrete Realization: Java Elements

Messaging Directory ACL

Figura 3.2: L’architettura astratta e le sue realizzazioni (specifiche direalizzazione).

Perassicurarela neutralita vienespecificataun’architteturaastratta(AbstractArchitecture)[27] chefornisceun modelloin cui sonopresentatiadalto livello iseguentiinsiemidi servizi:

Dir ectory Service. Insiemedi servizi che offrono funzionalita che permettonoagli agentidi conoscerecaratteristicherelative adaltri agenti.Fra le carat-teristichechee possibileconoscerevi sonogli indirizzi concui e possibilecontattaregli agentie i servizidaessiofferti6.

MessageTransport Service. Insiemedi servizi che fornisconole funzionalitanecessarieaffinche i messaggivenganospeditie consegnatia destinazioneindipendentementedallecaratteristicheedil tipo di retesullaqualeavvienela comunicazione.

Agent Communication Language. Insiemedi specifichechedefinisconole fun-zionalitaedi formatichepermettonodi organizzarei messaggichesi scam-bianogli agenti.

6Si noti che a questolivello di astrazionenon e particolarmenteimportantedistinguereilserviziodi paginebianchedaquellodi paginegialle.

60

Si noti quantoquestecomponentiastrattesianotuttecomponentiin qualchema-nieraorientatealla comunicazione.Non e possibileimplementaredirettamentela specificaastrattama a partireda essae possibiledareuna“specificaconcre-ta” nellaqualesi forniscel’associazionefra le componentiastrattee le tecnologieconcui possonoessererealizzate.Poi a partiredaunaspecificaconcretasi potraimplementareunarealizzazioneconcreta.In figura3.2 si esplicitanovisivamen-te le relazionitra architetturaastratta(AbstractArchitecture),specificaconcreta(ConcreteSpecification)e realizzazioneconcreta(ConcreteRealization).

Recupero di tecnologiepreesistenti.

Un altro elementoper descriverela portatadelle specificheconsistenell’indivi-duarediversi livelli di cui un MAS puo esserecompostoe capireper quali li-velli si voglia fornire unastandardizzazionee perquali esistagia unatecnologiaconsolidata.Nel casoin cui sia possibileimpiegareunatecnologiagia esistenteuno dei problemidiventacomegli agentipossanoessereuniti alle infrastrutturepreesistenti.

Non tutte le componentisonoagenti.

Sipotrebbeessereindotti apensarechei componenticheoffronoserviziagli agen-ti debbanoessereanch’essiagenti. Non e necessariamentecosı. In alcunedelleprimespecificheprodottedallaFIPA, il Message Transporteraspecificatocomeun agente.Questotipo sceltapur essendomolto flessibilerisultava inefficiente.Spieghiamodovefossel’inefficenzaillustrandoi passidellacomunicazionefra unagente“sender”edunagente“receiver” impiegandounagentemessagetransport.

1. L’agente“sender”passaall’agente“messagetransport”un messaggiode-stinatoall’agente“receiver”.

2. L’agente“messagetransport”comunicail messaggiospeditodal senderalreceiver.

L’inefficienzaconsistevanell’impiego di duecomunicazioniogni qualvolta senedoveva effettuareuna. Si puo eliminaretale problemaimplementandoil Mes-sageTransportcomeun modulosoftwareaccessibileattraversounaApplicationProgramInterface(API), piuttostochecomeagente.

L’esempioprecedenteillustra comea volte nonsia convenienteesprimerelecomponentidell’infrastruttura7 in termini di agentie siainvecenecessariopreve-dernealcunenella forma di moduli e oggetti. Poiche le componenticon cui si

7Con infrastrutturasi intende come nel resto del capitolo se non specificatoaltrimenti,l’insiemedellecomponenticheoffronoservizidi “ambiente”agli agenti.

61

interagisceadun certolivello di granularitanonsonopiu agenti,si cercadi recu-perarepatternrisolutivi propostiin contestidiversidal dominiodel paradigmaadagenti. Da qui un ulterioreparametroper deciderequali sianole problematichedi cui la FIPA si deve occupare:quandoil livello di dettaglioescedacio chee ilparadigmaadagentieci si addentrain qualchealtratecnologiale specificheFIPAnonpossonoandaremolto oltre chefornire la standardizzazionedelle interfaccecon qualeaccederealle funzionalita delle componentisottostanti.Senon si fa-cessecosı si legherebberole specifichea qualchetipo di tecnologiao tecnichediimplementazione,perdendopartedellaneutralitaecontravvenendoal principiodiminimalita.

3.1.4 Organigrammadella FIPA

Forniamoqui qualcheinformazionesu comela FIPA e strutturalmenteorganiz-zata. Le informazionicirca la strutturadellaFIPA ci aiuterannoa capireil ciclodi vita cheseguonole specificheede comunqueinteressantedi perse. In figura

Board of Directors

Architeture Board

Techical Committees

Special Interest GroupsMembership and Nomination Committee

CommitteeFinance and Audit Working Groups

Secretarian

Image Committee

Figura3.3: La strutturadellaFIPA.

3.3si puo osservarela suddivisionedell’organizzazione,di seguito forniamounabrevedescrizionedei compiti di ognuna:

62

Board of Dir ectors: i direttori responsabilidellagestionee dellacondottadellaFIPA, decidonosullepolitichee le procedurechela FIPA adottera, defini-sconola direzionedel lavorochedovraessereintrapreso.

Secretariat: si occupadellagestionedelleadesioniedegli aspettifinanziaridellaFIPA.

Image Committee: coordinale attivita di promozionedelleattivita dellaFIPA egestiscela news letters“FIPA Inform!”.

Financial and Audit Committee: si occupadellarevisionedei conti e preparairapportidi verificaperil Boardof Directors.

Membership and Nomination Committee: analizzale qualifichedi ogni can-didatomembro,proponele nomineper l’elezionedel Boardof Directorsfacendoattenzionedi assicurareun certobilanciamentogeograficonell’as-segnazionedellecariche.

Ar chitecture Board: l’autorita responsabiledella consistenza,accuratezza,edadeguatezzadel lavorotecnicointrapresodallaFIPA, sovraintendeal lavorodei TechnicalCommitteesedei WorkingGroups.

TechnicalCommittees(TCs): sonodiversicomitatiognunospecializzatosuundeterminatoargomento.Portanoavanti il lavorotecnicodellaFIPA secondounpianoapprovatodallaArchitectureBoard.Il loro lavoroconsistesianellacreazionedi nuovespecifichesianellamodificadellepreesistenti.

Working Groups(WGs): sonoprogettatiper portareavanti altri aspettidel la-voro della FIPA, non necessariamentetecnici. Possonoavere il compitodi concentrarsisuunaprecisaapplicazioneo essereresponsabiledell’inte-razionecon altri standard.Di solito un WG creadocumentiinformativi oproponemodificheaspecificheesistenti.

SpecialInterestGroups(SIGs): vengonocostituitiperportareavanti lavoroau-siliario sulqualevi siaunparticolareinteressedapartedeimembri.

3.1.5 Il processodi produzionedello standard

La FIPA metteadisposizionedi chi vuoleil propriolavororendendoloaccessibilevia Internet [23]. In questomodo si ha la possibilita di avere i documentiindifferentifasidi lavorazione,nonsolostandardmaanchedocumentipreliminariosperimentali.Sesi vuoletrarreil maggiorvantaggiopossibiledall’impiego dellespecificheFIPA e importantesaperdistinguerelo statodi avanzamentodi ognuna

63

di esse.Ancheperaumentarela trasparenzanel2000estatoufficialmenteadottatoun iter cheregola l’avanzamentodel lavoro contenutonei documentiaccessibili,individuandounveroeproprio“life cycle” perle specificheFIPA. In [52], si trovala descrizionedel life-cyclecheriportiamoin figura3.4.

approval of FABDemotes

date

Deprecated

Experimental

approval of TC

with a retire

Standard

Obsolete

Preliminary

after 2 yearsExiperes

After 6 months

Exipers

after retire date

+ Vote of FIPA members

Approval of FAB

Promotes PromotesApproval of FAB

+ Vote of FIPA members

Retires

Following

Figura3.4: Il lyfe-cycledellespecificheFIPA.

In figurasonoschematizzatii vari stati in cui unaspecificasi puo trovaree imeccanismicheportanounaspecificaa diventarestandardedeventualmenteob-soleta.Unaspecificainizia la suavita nellostatopreliminare(Preliminary)quan-do un comitatotecnico(TC: TechnicalCommittee)creaunabozzadi specifica.Nel momentoin cui il comitatodecidechela bozzaeprontaperessereimplemen-tatala specificaentranello statosperimentale(Experimental),dovepuo rimanereperun periodomassimodi dueanni.Sela sperimentazioneportaa buoni risultatila specificapuo diventarestandarde venireconsiderataa tutti gli effetti stabilee prontaperessereimplementatadalleaziendeo organizzazionichelo vogliano.Nel casoin cui a specificadiventi inutile o venga“sorpassata”danuovaspecificavienemessanello statodeprecatedperun periododi seimesi. In questiseimesichi avesseadottatola specificadivenutadeprecatedha il tempodi aggiornareleproprie implementazionisecondole nuove specifiche. Si osservicheallo statoattualenon vi sonoancoraspecifichecheabbianoraggiuntolo statodi standardedi lavori in fasepiu avanzatasononellostatoExperimental.

64

3.2 OrganizzazionedellespecificheFIPA

Dopo aver presentatol’organizzazione,i principi, e l’iter di specificaadottatatidalla FIPA, diamounabreve presentazionedel lavoro di specificada essaeffet-tuato. L’insiemedellespecificheFIPA e abbastanzavastoquindi ci limiteremoadescriveresolo le parti chesonovicine alle problematichechedobbiamoaffron-tarein D-CaseLP. Rimarchiamoancoraunavoltacheil finedellespecifichenone descriverecomedovrebberoessererealizzatele componentidell’infrastrutturaper sistemimulti-agente,ma fornire le interfaccedelle funzionalita attraversolequali le diversecomponentidi taleinfrastrutturapossonointeragire.Le specifichesonoorganizzatesudifferenti livelli di granularita, in questomodocio chenellaspecificadi livello piu astrattovienedefinitocomeunacomponentecheforniscedeterminatefunzionalita, nellaspecificaa granularita piu fine vienesuddiviso indiversecomponentile cui funzionalita vengonodescrittecon un maggiordetta-glio. In figura 3.5 si possonovedertre livelli (layer) di astrazionein cui sono

Layer 1

Layer 2

Layer 3 AgentCommunication

AgentManagement

Agent MessageTransport

Abstract Architecture

Application

Figura3.5: Le classidi specifichedellaFIPA.

organizzatele classidi specifiche.Peralcunedelleclassidel terzolivello vi eunaulterioresuddivisionecheoffre unagranularita ancorapiu fine. Descriviamonelseguito le classie le sottoclassidi specifiche.

Application. Specifichesull’analisi e il designdi applicazionila cui soluzionepotrebbeesseresviluppatamediantela tecnologiaadagenti.Vengonofor-nite specifichesullefunzionalita chedovrebberoesseresupportatedasiste-mi MAS cherisolvonoproblemiin cui l’impiego del paradigmaad agentidovrebberisultareparticolarmenteutile. Per fare un esempio,una delleapplicazioniconsideratein questaclassee un sistemaper la selezionedeiprogrammitrasmessidaTV via cavo tenendocontodel profilo indicatodaogniutente.

Abstract architecture. Specifichechedefinisconoin astrattole entita e i servizinecessariperfornire agli agentiun ambientein cui possanocomunicareedinteroperaretradi loro.

65

Agent Communication. Specificadell’agentcommunicationlanguageFIPA ACL.All’interno di questaclassedi specificheci sonoulteriori suddivisioni nonvisualizzatein figura:

Interaction Protocols. Rappresentanoschemidi comunicazione,veriepro-pri protocolli di comunicazioneai quali si possonoriferire gli scambidi messaggiFIPA ACL.

Communication Acts. Specificheriguardantile azioni comunicative chesonosupportatedaFIPA ACL.

Content Language. Specificadi alcuni linguaggichepossonoessereuti-lizzati comeContentLanguagenei messaggiFIPA ACL. Contali lin-guaggisi esprimonoi corpidellerichieste,sottoscrizioni,affermazionieproposteindicatedagli atti comunicativi.

Agent Management. Specificheche descrivono la gestioneed il ciclo di vitadegli agentiall’internodi unastessaplatform8 o fra platformdifferenti.

Agent MessageTransport. Specificadi comei messaggipossonoesseretraspor-tati attraversodifferentiprotocolli di rete,anchequestaclassedi specifichee suddivisain tresottoclassi:

ACL Representations.Specifichedelledifferentirappresentazionideimes-saggiFIPA ACL. Sonoprevisti differenti formati, dalla rappresenta-zionea tuplealla rappresentazioneXML.

EnvelopeRepresentation. Specifichedelledifferentirappresentazionidel-le “buste”in cui si possonoincapsularei messaggiFIPA ACL.

Transport Protocols. Specifichedeiprotocolliconcuipossonoesserescam-biati i messaggiFIPA ACL sopradifferentitrasportidi rete.

Nel seguito approfondiremole classidi specificherelative all’architetturaastrat-ta [27] e l’agent management[28]. Lasceremofuori da questapresentazione,praticamenteper intero, le parti relative all’Agent CommunicationedInteractionProtocolschesarannotrattatenel lavoro di tesidi StefanoMiglia e le specificheappartenentiallaclassedell’Application.

3.3 Ar chitettura astratta

L’architetturaastrattae stataottenutabasandosisui principi di analisi e designpropri della programmazionead oggetti,usufruendodella progettazionea “pat-

8Il termine platform si riferisce all’implementazionedelle componentiche forniscono lefunzionalitaprevistenell’ambientein cui gli agenti“vi vono”.

66

tern” ed utilizzandomodellazioneUML9. Il diagramma3.6 illustra le relazionitra le astrazionidefinitenel documentoe le loro istanziazioniconcrete.Semprenellastessafigurasi possonoosservarequattrolivelli di astrazione,dall’alto versoil bassoincontriamoprima il livello piu astrattoal qualetroviamo le comunica-zioni e la semanticadellecomunicazioni,poi l’architetturaastratta,le specificheconcrete,fino alla singolaimplementazioneconcretadell’architetturachestaallivello di astrazionepiu basso.

(ACL, Encodings, Interation Protocols, etc.)

Agent Comunication and Semantics

(Naming, Transport, Encoding, Namespace)

Abstract Architecture

Set 1

Actual

1Implemantation

Actual

2Implemantation

(Gateways, Service, Agent Platform)

Concrete Elements

Set 2

Figura3.6: Relazionetra architetturaastrattaeconcreta.

3.3.1 Tipo opacoed iscrizione ai servizi

Vi sonodueleitmotiv chepermeanola progettazionel’architetturaastratta:l’uti-lizzo delcosiddettotipo opacoe il pattern“f actory”.

Cosasignificachealcuni degli elementidi cui l’architetturasi componesia-no di tipo opaco? Illustriamo il concettocon l’esempiodel MessageTransportService(MTS). Comeavremomododi illustrarepiu dettagliatamentenel segui-to, quandodueagenticomunicanosi vuoleastrarredai possibiliprotocolli di retesui quali puo esseretrasmessoun messaggio.Per questomotivo la comunica-zionee progettatasecondoquello chee statodefinito un approccio“agnostico”

9Nel documentodi specificadell’architetturaastrattasi trovanounaseriedi classdiagramchedescrivonole relazionifra gli elementichecompongonol’architettura.

67

in cui l’implementazionedel trasportoe opacaalle componentichefornisconolefunzionalita di comunicazioneagli agenti. In questomodosi evitano assunzio-ni dipendentidal particolaretipo di trasportoconcui di volta in volta avvienelacomunicazione.Quandounmessaggiovienespeditogli e associatoun identifica-tivo del tipo di trasportochedovra impiegarein funzionedei trasporticondivisidal mittentee dal destinatariodel messaggio.Sulla basedi tale identificativo siselezioneradinamicamenteil tipo di trasportoadattoalla comunicazione.

Elementidi tipo opacosonoutilizzati sia nella codificadei messaggisia neiservizi di directory. Tale espedienteoffre unasoluzioneelegantechepermettel’estensionedinamicadelle funzionalita dell’ambientein cui vivono gli agenti.Si possonoinfatti aggiungeredinamicamentenuovi tipi opachicontenentinuoveimplementazionidi servizi.Si osservicheil meccanismodei tipi opachinonecheun’istanzadelconcettodi polimorfismo.

Un secondoconcettoricorrentenella specificariguarda“l’iscrizione a servi-zio” ovvero il modo in cui gli agentiaccedonoalle funzionalita dell’ambiente.L’applicazionedel concettod’iscrizioneal servizio,prevedecheun agentepossautilizzaresolo i servizidell’ambiente10 ai quali si e iscritto. L’iscrizionerestitui-sceall’agenteun riferimentoal servizio assicurandoall’agentela possibilita diaccedereallo stessosuccessivamente.Questomododi organizzarele cosecorrispondeadun “pattern” molto utilizzatodenominato“f actory”.

3.3.2 Cosaspecifical’ar chitettura astratta

La specificadell’architetturaastratta[27] offre unadescrizioneadalto livello deiserviziedellecomponentichedevonoessereforniti dall’infrastrutturanellaqualevivonogli agenti.L’obiettivo principaledel documentoe assicurarechele realiz-zazioniconcretederivatedall’architetturaastrattasianoin gradodi interoperaretra di loro. L’interoperabilita delle differenti realizzazioniconcretee assicuratadal fatto stessochesianoistanzadell’architetturaastratta,e condividanoquindiun designappositamentepensatoper interoperarecon MAS chesupportanounastrutturasimile.

Vistala centralitadelleproblematichedi comunicazionee interoperazionefraagenti,nel documentosonodescrittii seguentitemi:

� l’interoperabilitacol MessageTransport;

� il supportodi varieformedellerappresentazionidell’AgentCommunicationLanguage;

10Nel sensodi platform.

68

� il supportoadifferentiformedi contentlanguage11;

� il supportoalla rappresentazionedi directoryservicemultipli.

Nell’architetturasi cercadi individuarelemodalitaconcui fornireservizineiqualiACL, contentlanguage,MTS sianoparametrici.Rimanefuori dataledocumento:

� tutto cio chenonpuo esseredescrittoastrattamente(es. gestionedel ciclodi vita degli agentiesicurezza);

� le questionisullequali nonc’e ancoraun sufficienteaccordodaprevedereunastandardizzazione;

� le areeche sonosufficientementespecializzateda non necessitaredi unastandardizzazione;

� il ciclo di vita degli agentie la loro gestione(trattatoin [28]);

� la mobilitadegli agenti;

� l’identita degli agenti;

� le politichedi conversazionedegli agenti(es.interactionprotocol).

E importanteosservarechel’architetturaastrattaspecificagli elementineces-sari ad ottenerela comunicazionee l’interoperazionefra sistemimulti-agente,e questonon significa che componentio problematicheche non sono trattatedell’architetturaastrattasianonecessariamenteproibiteo ignoratedallaFIPA.

Non si e necessariamentecostrettia utilizzatela specificaastrattaper intero,si puo anchefareriferimentoad essaper implementareun singoloelemento;adesempio,si potrebbecreareunaspecificaconcretadell’elementodirectoryserviceche utilizza il Lightweight Directory AccessProtocol(LDAP)12. Essendoquelparticolareelementoun’istanzadi unavisioneastrattapotrebbeessereutilizzatoin diversisistemiadagentichesi riferiscanoallastessavisionecomecomponentedi terzaprovenienza.

Una specificadi un’architetturaconcretaper essereFIPA compatibiledeveincludereil meccanismoperla registrazionee la scopertadegli agentiedil trasfe-rimentodei messaggiintra-agente.

Perspiegarequalielementisianonecessariecomeinteragisconotradi loro, ildocumentodi specificasi serve di un sempliceesempio:dueagentichedevonolocalizzarsiecomunicarel’uno conl’altro.

11linguaggiin cui si esprimela partedomaindependentin un messaggioFIPA ACL.12E unostandardperi servizisuunareteIntraneto Internet.LDAP fornisceservizidi directory

e vienespessoutilizzatoperassociarenomi a numeritelefonicieadindirizzi e-mail.

69

Nel modellopropostodalla FIPA gli agenticomunicanoscambiandosimes-saggicodificati in un agentcommunicationlanguage,di cui daremounabrevissi-madescrizionepiu avanti.

La comunicazioneavvienetramitedueservizidi supportoagli agenti:direc-tory serviceemessage-transport-service13.I serviziin questionepossonoessereforniti comefunzionalitaoffertedaagenti,adesempiotramiteunagentedirectoryservereunagentemessage-transport;oppurein formadiversafornendole interfacceperle implementazioniJava, C++, IDL.Nel casoin cui si scelgadi fornire i servizi via agenti,avremo agenticon unalimitata autonomia.Infatti, adifferenzadegli agentiautonomichedecidonovoltapervolta sefornire un serviziochegli e statorichiesto,gli agentidi cui parlava-mo soprasonovincolati a serviresemprele richieste.Nelle sottosezioniseguentidescriviamopiu accuratamentei servizidi directorye transportmessage.

3.3.3 Dir ectory Services

Il ruolodi undirectory-server14 e fornireuna“locazione”dovegli agentipossonoregistrareunadir ectory entry15 . Nel directoryserver gli agentipossonotrovarele informazioninecessarieperinteragiregli uni congli altri.

Unadirectoryentrye in astrattounatupladi coppievalore-chiaveconsistentedi almenodueelementi:

Agent-name: un nomeunicoperl’agente.

Locator: unoo piu Transport description chedescrivono il tipo di trasportoel’indirizzo da utilizzareper comunicarecon l’agenteutilizzandoun deter-minatotrasporto.Notarechel’indirizzo edipendentedal tipo di trasporto.

All’interno di unadirectoryentrypossonoesseremantenutialtri attributi, adesem-pio la descrizione,il costodell’utilizzo, le restrizionidi impiego dell’agente. Idirectory servicecomprendonoservizi per la registrazione,la cancellazionediunadirectoryentrye l’interrogazionedel directoryserver. Quest’ultimoserviziopermetteagli agentidi ottenerele informazionirelativealtri agentiregistrati.

Perdareun’ideadi comesi svolgonole cose,illustriamocosasuccedequandoun agente vuole publicizzarela suaesistenza.Innanzi tutto lega sestessoad

13Nel seguito si e cercatodi indicarein grassettoi termini chesonoelementispecificatidallaFIPA. Continuiamoadutilizzarel’italico pergli elementichesonointrodotti dallespecifichemacherappresentanoinsiemi di funzionalita o comunquenon hannoun unico corrispondentenellespecifichemenoastratte.

14Con directory server intendiamola componenteo le componentiche offrono i directoryservices,nonavendoun “preciso”corrispondentenellaspecificaastrattae in italico.

15Directoryentrye in grassettoin quantoe un elementobenprecisatonellaspecificaastratta,enonindividuaun gruppodi elementineungruppodi funzionalita.

70

unoo piu trasporti16, dopodi che,costruiscela suadirectoryentrycompletadelsuonomeedei trasporticoni qualipuo esserecontattatopiu attributi opzionalifracui le ontologiechee in gradodi comprendere.Infine registrala directoryentrynel directoryserver.

Semprea titolo di esempiosupponiamochel’agente si registri al directoryserver con unadirectoryentry checontengale coppiechiave-valoreillustrateinfigura3.7.

�agent-service,”com.dowjones.stockticker” ��

ontology, org.fipa.ontology.stockquote�Figura 3.7: Coppiechiave-valorecontenutenelladirectoryentrydell’agente .

�ontology,

�org.fipa.ontology.stockquote� �

Figura 3.8: Chiave-valoredi ricerca.

A questopunto,supponiamoarrivi un agente , cheeffettui unaricercaperunadirectoryentrycheincludele coppiechiave-valorein figura3.8. Il risultatodella ricercachesi vedrebberestituire e la directoryentrydell’agente . Esa-minandoil contenutodel directoryentrychegli e statarestituita, e in gradodiconoscerecon qualetrasportoed a qualeindirizzo puo comunicarecon l’agente .

3.3.4 MessaggieMessageTransport Services

Dopoaverdatoun’ideadi comeunagentepossavenireaconoscenzadell’esisten-zadegli altri agentiin unMAS chegodedellaproprietadi openness,presentiamogli aspettifondamentalidellacomunicazionefra agenti:

� la strutturadei messaggichesi scambiano;

� il trasportodei messaggi.

Struttura dei messaggieFIPA ACL.

Abbiamogiadettochegli agentiFIPA comunicanofra di loro scambiandosimes-saggiespressiin unAgentCommunicationLanguage(ACL). La FIPA hadefinitounsuoagentcommunicationlanguageFIPA ACL, delqualediamodi seguitounabrevissimadescrizione.In astrattoi messaggisonostrutturaticomeun tupla dicoppiechiave-valorechecontengono17:

16In alcuneimplementazioniquestocompitoe delegatoal message-transport-service.17La listanoncomprendetutti gli elementidellastruttura.

71

Sender. Il mittentedel messaggio.

Receiver. Il destinatariodel messaggio. Puo essereindicato anchepiu di undestinatarioperunostessomessaggio.

Performatives. Identificanoil tipo di atto comunicativo al qualesi riferisce ilmessaggio.Ci dice seil messaggioe un’affermazione,unadomanda,unarisposta,un rifiuto o qualcosad’altro.

Content language. Il linguaggioconcui e espressoil contenutodel messaggio.Esistonodifferenti linguaggi che possonoessereimpiegati comecontentlanguage,fra i qualiKIF o FIPA SL.

Content. Il contenutoveroe propriodel messaggiochee espressoin un contentlanguage.Ad esempioseil messaggioha performative “request”la qualeindica che il mittenterichiedeal destinatariodi fareun’azione,il contentconterra la formulazionedell’azionerichiesta.

Ontology. L’ontologiaeil dominioalqualesi riferisconoi terminidelmessaggio,ovveroelementicheapparirannoall’interno del contentma non apparten-gonoalla sintassidel contentlanguage.L’ontologia identifical’accezionecon cui sonoutilizzati i termini ed il significatodei termini appartentialdominiodel discorso.

Nell’architetturaastrattanonsi e obbligatiadadottareFIPA ACL comeACL: ab-biamodatounadescrizionedi FIPA ACL per aver presentequalepuo esserelastrutturaapprossimativadi unmessaggioscrittoin unACL. Permaggiordettagliosullastrutturae gli atti comunicativi supportatidaFIPA ACL si facciariferimen-to a [24] e [30]. In figura 3.9 e fornita unaschematizzazioneriassuntiva dellastrutturadi un messaggioespressoin un agentcommunicationlanguage.Si vedeche il contentlanguagepuo essereriferito ad unaontologia18 ed il messaggiocontieneun mittentee dei destinatariespressicon il nomeunico (agent-name)indipendentedal tipo di trasportoconil qualegli agentisonoraggiungibili.

Trasporto per i messaggi.

Vediamocosaaccadequandounmessaggiovienespeditoattraversounparticola-re trasporto.Comeillustratoin figura3.10,unmessaggioperesserespeditovienecodificatoin un Payloadedinclusoin un Transport Message.Il payloadnon e cheunacodificadel messaggiooriginaleespressain unaforma

18Ricordiamochel’ontologiadefinisceil significatodei terminineicontestichepossonoesserediscussi.

72

regardless of transportUnique names,

Expressed in an Agent comunication language

Message

Sender:Receiver:

Messagecontent

Expressed in acontent languageMay reference an ontology

agent nameagent name

Figura3.9: La strutturaperunmessaggioFIPA.

adattaadesseretrasmessasopraun determitatotrasporto.Supponiamoadesem-pio cheun messaggiodebbaesseretrasmessosu unaconnessionewireless19, alfine di ottimizzarela trasmissione,e quindi il numerodi informazionechepos-sonoesseretrasmessein unostessointervallo di tempo,e convenienteimpiegareunacodificadel messaggiodiversadalla semplicecodifica a stringa(es. FIPABit-EfficientEncoding).

Un transportmessagee formatoda un envelope(la busta)ed il payloaddelmessaggiochedeve esseretrasmesso.L’envelopecontienei transport descrip-tion dell’agentemittentee del destinatario.Un transportdescriptioncontieneleinformazionichepermettonodi spedireil messaggiosul trasporto:le caratteristi-chedel trasporto,l’indirizzo del destinatario,alcunidettaglisucomee realizzatoil trasporto;oltreainformazioniaggiuntivecomel’ encoding-rappresentation, datirelativi alla sicurezza,altri dati chedevonoesserevisibili al trasporto.

In figura3.10si puo osservareunaschematizzazionedelprocessochetrasfor-maunmessaggioin untransportmessage:apartiredalmessaggiovienecreatounpayloadin funzionedel trasportoselezionato;dopodi chesi creaunenvelopeconle informazioniutili al trasporto.Senecessariopossonoessereaggiuntiulteriorienvelope,il tutto componecio cheabbiamodefinitocomemessagetransport.

19La caratteristicadellereti wireless(letteralmentesenzafili) eoffrire unabandadi trasmissionepiuttostolimitata.

73

Sender:Receiver:

MessageMessage

Sender:Receiver:

Message

Sender:Receiver:

agent nameagent name

content

MessageMessage Encoding

content

Message

agent nameagent name

Payload

Payload

content

Message

Transport Message

Envelope

Additional Attributes

XY

Addressing andmore attributes transport description

transport description

Figura3.10:Trasformazionedi unmessaggioin un Transport-Message.

3.3.5 Esempiodi comunicazione

Analogamentea quantofattoper i servizidi directoryserviceriportiamoda[27]un esempioche illustri cosaaccadequandosi spedisceun messaggio.Innanzitutto chiariamoche ogni agenteha un agent-nameunico ed immutabile. Unagentepuo avereunoo piu transport-description cheutilizzaperspedireadaltriagentii propri transport-message.Ogni transport-descriptione correlatoadunparticolaretransport (trasporto,es. IIOP, HTTP). Un transport e dunqueunmeccanismoper trasferiremessaggi.Un transportmessagee un messaggiocheviene speditoda un agentead un altro in un formato che e appropriatoper iltransportusato.Un insiemedi tranport-descriptionpuo esseremantenutoin unlocator. Ricordiamocheil locatore partedelladirectoryentrydi unagente.

Consideriamounagenteconagent-name”ABC” conunadirectoryentrycomequellaschematizzatain tabella3.1.Si osservichetaleagentepuo essereraggiuntoattraversoduedifferentitrasporti,HTTPeSMTP. Supponiamooravi siaunagente

Agent-name:ABCLocator:Transport-type Transport-specific-address Transport-specific-propertyHTTP http://www.whitz.net/abc (none)SMTP Abc@lowcal.whiz.net (none)

Tabella3.1: DirectoryentryperABC

74

con agent-name”123” chevoglia comunicarecon l’agente”ABC” e supportiiltransportHTTP. In figura3.11(a)e illustrato il contenutodel transport messagenelcasoin cui la comunicazionefra i dueavvengatramitetrasportoHTTP. Sempre

Reciever:

Sender:

Message

none

Receiver:Transport-Type:Transport Address:Transport properties:

Transport-Type:Transport Address:Transport properties:

Sender:

HTTP

123ABC

content

Message

Payload

Additional Attributes

FIPA-HTTP

nonehttp://www.whiz.net/ABC

FIPA-HTTPhttp://www.joe.com/123

none

Envelope

Transport Message:

(a)

Transport-Type:Transport Address:Transport properties:

Sender:

Public key:

HTTP

Receiver:Transport-Type:Transport Address:Transport properties:

Payload:

2349890jdhgfjhkiirfoi

kjhfaytvqwe056

erta93:034kkkads

FIPA-HTTPhttp://www.joe.com/123

none

<data>

Envelope

Transport Message:

FIPA-HTTPhttp://www.whiz.net/ABC

Additional Attributes3DES

3-DES encrypt

(b)

3kswermsdf

weproi234023984

Figura3.11: (a)Transport-Messageperla comunicazionetra ”123” e ”ABC”. (b)Lo stessoTransport-Messagecriptato.

in figura3.11(b)vieneillustratoun esempiodi utilizzo degli attributi addizionali,in questocasoperspediremessaggicriptati.

3.4 Specificadella gestionedegli agenti FIPA

Nella sezioneprecedenteabbiamodato un’idea delle componentiastrattechepermettonoagli agentid’interoperare.In questasezionescendiamodi un livel-lo di astrazionee presentiamola specifica[28] chedescrive con maggiordetta-glio com’e fornita l’interoperabilitadegli agentiillustrandoinoltrecomevengonogestitigli agenti.

3.4.1 Un modellodi riferimento

Prima di tutto andiamoa descrivere un modello di riferimento per la gestionedegli agenti,sul qualeillustreremosuccessivamentele operazionidi creazione,registrazione,locazione,comunicazione,migrazionee ritiro di agenti.

75

Software

Message Transport System

Message Transport System

AgentManagement

SystemAgent Facilitator

Agent Platform

Agent Platform

Directory

Figura3.12: Il modellodi riferimentoFIPA perla gestionedegli agenti.

Le entita contenutenel modellodi riferimento illustrato in figura 3.12 sonoinsiemi logici di servizi,none dettochevi siacorrispondenzadi un elementoadunelementoconle componentifisichedi implementazione.Inoltre,nellaspecificaviene lasciataunacertaliberta per i dettagli piu implementativi delle platform.Descriviamobrevementele singoleentita.

Agente: e l’attore fondamentalenellaAgentPlatform(AP), puo faredainterme-diario ad un utenteumanoo ad un softwarepreesistente.Deve avereunidentificatoreAgent Identifier 20 (AID) universalmenteunico. Puo essereregistratoadun certonumerodi indirizzi di trasportoattraversoi quali puoesserecontattato.

Dir ectory Facilitator (DF): e un componenteobbligatoriodellaplatform. Il DFfornisceservizi di paginegialle agli altri agenti. Gli agentipossonoattra-versoessoregistrarei loro servizio chiederequaliservizisianoofferti daglialtri.

20Si facciaattenzionein quantole specificheFIPA si riferisconoall’AID intendendospessooltre all’identificatoreunicoe immutabiledell’agenteancheun insiemedi “parametri”dell’iden-tificatoreadesempioi transportaddresssupportati,questodoppioutilizzo del terminepuo esseremotivo di confusione.

76

Agent ManagementSystem(AMS): eunacomponenteobbligatoriadellaagentplatform, che esercitail controllo e la supervisionedegli accessie l’u-so della platform. Ce n’e uno per ogni Agent platform. Questacompo-nentecollezionagli Agent Identifier (AID) per gli agenti registrati nellaplatform21.

MessageTransport Service (MTS): sonoi serviziusualidi comunicazioneperagentilocati sullastessao sudifferentiplatform. La comunicazioneinter-platformvienespecificatain undocumentoaparte[29].

Agent Platform (AP): forniscel’infrastrutturafisicanellaqualegli agentiposso-noessereimpiegati.La platformpuo consisterein unamacchina,unsistemaoperativo, un softwareper il supportodi agenti,un insiemedi componentimistoagli agenti.La progettazioneinternadellaplatformnone oggettodistandardizzazione.Non e dettochevi sia unaplatform per ogni macchi-na, e possibileimplementaredelle platform distribuite. La FIPA prevedeunavarieta di differentiAP chevannodaun singoloprocessochecontieneagentisottoformadi threadadunaAP totalmentedistribuitacostruitasopramiddlewarestandardo proprietari.FIPA specificasoloconcosae comelacomunicazioneavviene fra agenti. Gli agentipossonoesserenativi dellaplatform,agentiesternialla platform,o agentichedinamicamentesi sonoregistratiadessa.

Software: questacomponentedescrive tutto cio che non e un agentema deveessereaccessibiledall’agente. L’agentepuo accederea software per ag-giungerenuovi servizi,protocolli di interazione,protocollidi negoziazione,algoritmi,protocolli perla sicurezza,eccetera22.

3.4.2 Il nomedegli agenti

Il modellodi riferimentoFIPA identificaun agenteconunacollezionedi coppiechiavevalore,chiamateAgentIdentifier(AID). Questecollezionidi coppieposso-nocontenereunnomeedaltri parametricomegli indirizzi di trasporto,l’indirizzodi un servizio di risoluzionedi nomi ed altro. La naturaestensibiledell’ AIDdovrebbepermetteredi arrichirlo a proprio piacimentocon informazioniquali ilnomesociale,un soprannome,i ruoli chepuo giocaree quant’altrosi voglia. Gli

21Considerandochegli AID possonoaverealcuniparametritra cui i transportaddresssuppor-tati, l’AMS implementail serviziodi paginebianche.Si osservichea questolivello di dettagliovengonodistinti i dueservizi di directorye quindi il serviziodi paginebianchevieneofferto daunacomponente(AMS) differentedaquellacheoffre il serviziodi paginegialle (DF).

22La FIPA haprodottodellespecifichesucomeimportarefunzionalita dasoftwareesterno.Siveda[25].

77

AID sonopensatipercompariredentroagli envelopedei messagginei campi:toe :from. I valori dei parametridi un AID possonoessereeditati e modificati daun agente,e ad esempiopossibilecheun agentevoglia aggiornarela sequenzadei propri indirizzi di trasporto;tuttavia, i parametriobbligatoripossonoesserecambiatiesclusivamentedall’agentea cui l’AID si riferisce. Il parametro:namedi un AID e un identificatoreglobalmenteunico. Un modosempliceperottene-re cio e costruirloa partiredal nomedell’agentee l’indirizzo della platform sucui risiede(homeagentplatform,abbreviato con HAP), separandoi dueconuncarattere’@’. Supponiamoad esempiodi avereun agentedi nome”ABC” cherisiedesullaplatformconHAP ”miaplatform.disi.unige.it”,l’AID risultantesara”ABC@miaplatform.disi.unige.it”

3.4.3 Il Dir ectory Facilitator

Il directory facilitator e un componenteobbligatorio in ogni agentplatform, ilcui compitoe fornire un serviziodi paginegialle agli agenti.Vieneintesocomeun custodebenigno,nel sensochedeve essereimplementatoin modochegli siaimpossibileingannaregli agenticoscientementefornendoinformazionimalizio-seo parzialmenteerrate. In unaAP vi possonoesserepiu DF che lavoranoincollaborazioneconil DF principaleformandouna“federazione”.

Vediamocomeinteragisconogli agenticonil directoryfacilitator. Seunagen-tevuolepubblicizzarei suoiserviziagli altri agenti,devecontattareil DF erichie-derela registrazionedella descrizionedei servizi. L’atto della registrazionenonimplicanessunobbligodapartedell’agentechesi eregistrato,al qualeepermessorifiutareunarichiestadi un serviziodalui precedentementepubblicizzato.Il DFda partesuanon assicurala validita e l’accuratezzadelle informazionichesonostateregistrate,ne operaalcuncontrollo sul ciclo di vita di ogni singoloagen-te. La descrizionedei servizi con la qualel’agentepubblicizzale suecapacitahaunaseriedi parametriobbligatori,ede comunquepossibileaggiungereancheinformazioninonprevistedallo standardFIPA. Illustriamole funzioni chedevo-no esserefornite dal DF, essecorrispondonoad unasemanticabendefinitachenon illustreremoin quantopiuttostointuitiva e troppodi dettaglioper la nostrapresentazione.I servizicomprendono:

� la registrazionedei servizinel DF;

� l’eliminazionedi unaregistrazione;

� la modificadi unaregistrazione;

� la ricercadell’agenteo degli agentiche offrono servizi con determinatecaratteristiche;

78

Il directoryfacilitatorcheesistein ogniAP haunAID riservatosimileaquellochesegue:

(agent-identifier:name df@hap:addresses (sequence hap_transport_address))

Figura 3.13: AID tipo del DirectoryFacilitator.

Questaconvenzionepermetteagli agentichenonconosconol’indirizzo del fa-cilitatoredi registrarei propriserviziin qualsiasiplatformFIPA allaqualeabbianoaccesso.

3.4.4 Agent ManagementSystem

La componenteAMS e obbligatoriaedunicain ogni AP. Talecomponentee re-sponsabiledellagestionedegli agenti(es. creazione,cancellazionedegli agenti)e di tutte le operazionisullaplatformcompresel’accettazionedelle registrazionidi agentipreesistentie la migrazionedegli agentidaunaAP adun’altra23. Vistochele agentplatform possonoaverecaratteristichepiuttostoeterogenee,l’AMSseinterrogatain propositooffre unadescrizionedellarelativaAP. Ad ogniagentee associatounaciclo di vita, questaassociazionevienemantenutadall’AMS. Nelcasoin cui la platform sia distribuita su piu macchinel’AMS rappresental’au-torita in tutte le macchine.L’AMS puo richiedereagli agentidi eseguirealcunefunzioni di gestionecomela terminazionee ha l’autorita di costringerel’esecu-zionedellarichiestasequestavenisseignorata.L’AMS mantieneunindicedi tuttigli agentichein uncertoistanterisiedononellaplatform,mantenendoperognunoil relativo AID. Un agenteeresidentein unaplatformsesi e registratoconl’AMS.Peressereconformeal modellodi riferimentodellaFIPA ogni agentedeve regi-strarsiall’AMS. Conla registrazionel’agenteottienel’autorizzazioneadaccedereal MTS ede quindi in gradodi riceve e spediremessaggi.L’AMS hail compitodi controllarela validita di tutte le descrizionidi agentichegli pervengono,inparticolarecontrollal’unicit a del nomedell’agentenel AID. Le descrizionidegliagentipossonoesseremodificateperqualsiasiragionemale modifichesonosog-gettea politichedi autorizzazione.Dopola cancellazionedi un agente,il relativoAID vienerimossodall’AMS ed e quindi disponibilenel casochequalchealtroagentelo volesseutilizzare. Ogni AMS nel propi AP ha un AID riservatodellaseguenteforma:

23Anchela mobilitadegli agentie gestitadall’AMS.

79

(agent-identifier:name ams@hap:addresses (sequence hap_transport_address))

Figura 3.14: AID tipo del AgentManagementSystem.

Analogamenteacio cheavvenivaconil directoryfacilitator, anchequi, la con-venzionesull’indirizzo dell’AMS permetteagli agentidi registrarsialla platformconoscendosoltantol’indirizzo HAP.

Riepilogandol’AMS deveesserein gradodi eseguirei seguentiservizipergliagenti:

� registrazione;

� cancellazione;

� modifica;

� ricerca;

� restituzionedelledescrizionidellaplatform.

Oltre alle funzionalitadi gestionedegli agenti:

� sospendereunagente;

� terminareunagente;

� creareun agente;

� recuperarel’esecuzionedi unagente;

� invocareun agente;

� eseguireun agente;

� gestirele risorse

Le funzionalitaprecedentisonofornitedall’AMS, vi epero unafunzionechedeveessereobbligatoriamentefornitadagli agenti:la funzione“quit” 24.

24Il fattochequestafunzionalita sia offertadagli agentie dovutaal fattochetale funzionalitapermetteagli agentidi terminarein manieracontrollata.

80

3.4.5 Ciclo di vita degli agenti

A questopuntodovrebbeesserechiarochegli agentiFIPA esistonofisicamentein unaplatform25 il cui compitoe offrire le funzionalita e facilitazionipreceden-tementedescrittea beneficiodegli agentistessi.Nel contestodella platform unagentee un processochedeve esseregestitosecondoun ciclo di vita chemodel-la l’esistenzadi ogni istanzadi agenteindipendentedall’applicazionechesi stasviluppando. In un dato istanteogni agentepuo trovarsi in uno solo degli staticontenutidel ciclo di vita descrittoin figura3.15.

Transit Initiated

Suspended

Suspend

Wait

Wake up Destroy

Quit

Create

Unknown

Invoke

Execute

Move

Resume

Active

Waiting

Figura3.15: Il ciclo di vita degli agentiFIPA.

Vediamoora in ogni statodel life-cycle degli agenticomeviene gestitalacomunicazione.

Active: Il MTS consegnai messaggiall’agentenormalmente.

Initiated/W aiting/Suspended: in questitre stati il MTS collezionai messaggifino aquandol’agentenonritornaattivo. Nel casosiaimpostatounserviziodi inoltro adun’altra locazioneperun agentechesia in unodi questistatieffettual’inoltro.

25Cio cheadunaltro livello di astrazioneabbiamogenericamentedefinitocomeambientein cuigli agentivivono.

81

Transit: il MTS collezionai messaggifino a chel’agentenonritornaattivo. Unagentepuo ritornareattivo siaperche il tentativo di muoversi in unanuovadestinazionee fallito, siaperche l’agentehainiziato la suaesecuzionein unnuovaAP. Sologli agentimobili possonoentrarenellostatoTransit.

Unknown: il MTS puo sia collezionarei messaggisia rifiutarli, dipendedallapolitica del MTS edallerichiestespecificatenel trasportodeimessaggi.

Diamo ora unabreve descrizionedelle transizionichepermettanodi passaredaunostatoall’altro.

Create: la creazioneo l’installazionedi unnuovo agente.

Invoke: l’invocazionedi un nuovo agente.

Destroy: la terminazioneforzatadi unagente,questaoperazionedovrebbeessereiniziatasolodal AMS enonpuo essereignoratadall’agente.

Quit: Unaterminazionepiu gentilechepuo ancheessereignoratadall’agente.

Resume: mettel’agentesospesonellostatoactive. Questatransazionepuo essereiniziatasolodall’AMS.

Suspend: mettel’agentenello statosuspended.Questatransizionepuo essereiniziatasiadall’agentechedallaplatform.

Wait: transizionechemettel’agentenellostatodi Waiting,cio puo avveniresoloperiniziativadell’AMS.

Wakeup: toglie l’agentedallo statodi waiting, questatransizionepuo esserefattasolodall’AMS.

Vi sonopoi duetransizionichepossonoessereusatesolodaagentimobili:

Move: mettel’agentenello statodi Transit,questatransizionepuo essereintra-presasolosuiniziativadell’agentestesso.

Execute: toglie l’agentedallo statoTransit,questatransizionepuo essereintra-presasolodall’AMS.

82

3.5 Le ontologie

Fino adoraabbiamoparlatodei serviziofferti daunaAgentPlatformnonoccu-pandocidi comegli agentipossanoaccedereaquestiservizi.Parlandodell’archi-tetturaastrattaavevamoaccennatoal fattochele componentipossonoessereim-plementatesottoformadi agenti,oggetti,moduli. Nel casoin cui la componentesiaimplementatacomeun oggettoo un insiemedi oggettie possibileaccedereaisuoiservizitramitechiamateametodoo attraversoAPI (ApplicationProgramIn-terface).Diversamentesei servizisonoofferti daagentiepossibileaccederviuti-lizzandodellecomunicazionidi richiesta.Ricordiamochechela comunicazionetraagentiavvienesutre livelli di astrazionedistinti, checoinvolgono:

� ontologie;

� linguaggiodi comunicazioneperagenti;

� protocollodi trasporto.

Peri livelli di astrazionepiu bassicorrispondential linguaggiodi comunicazionee protocolli di trasportoabbiamogia detto cosaprevedonole specificheFIPAfornendoun descrizioneper FIPA ACL e MTS. DescriviamocosaprevedonolespecificheFIPA perle ontologie.

La FIPA assumechesela comunicazionecoinvolgedueagentiquesticondivi-danoalmenounaontologiain comune.Sefossealtrimentii duenonriuscirebberoadarelo stessosignificatoai termini deimessaggichesi scambiano.

Perundeterminatodominoapplicativosi puo pensaredi utilizzarele ontologiein manieraesplicitao implicita. Utilizzarele ontologiein manieraimplicita signi-ficacodificarele ontologienelcodicedegli agenti.In questomodononepossibileaccedereall’ontologiaseessanonestatacodificatadurantelo sviluppodell’agen-te. In alternativa a questotipo di approcciosi possonotrattarele ontologieinmodoesplicito.

Le specificheFIPA permettonoagli agentidi utilizzareontologieespliciteat-traversoquelli chesonogli ontologyservice.Gli ontologyservicesonoforniti daun agentededicatodenominatoOntologyAgent(OA) ecomprendono:

� la scopertadi nuoveontologiepubbliche;

� la conservazionedelleontologieaccessibili;

� la traduzionedi espressionitradueontologiedifferenti26;26Questafunzionalita non deve essereottenutanecessariamentein manieraautomatica,ed e

comunquespessodi difficile realizzazione.Perquestole specificheFIPA prevedonocheadunarichiestadi traduzioneil OA possarisponderechenone in gradodi fornirla.

83

� rispondereadomandesullerelazionicheintercorronotradueterminio dueontologie;

� facilitarel’indi viduazionedi unaontologiacomunetradueagenti;

Non e interessedi questatesi entraretropponel dettagliodellaquestione,ingeneralele ontologiesonodomaindependent,edin [26] vengonoillustrati detta-gliatamentegli ontologyserviceschepotrebberoesseresupportatidall’ambientein cui gli agentivivono. L’esistenzadi un OntologyAgent in unaplatformnoneobbligatorionellespecificheFIPA. Le specificheFIPA oltre a prevederegli stru-mentichefacilitino l’utilizzo delleontologienei contestidipendentidal dominio,definiscedellesueontologiestandardperpermettereagli agentidi accedereallefunzionalitadellecomponentidescrittenellespecifiche.

La FIPA definendole ontologiedei servizioffre gli strumentiperpermettereall’agentedi fareproprierichiesteai componentidell’architettura.Infatti quandounagentevuolerichiedereunservizioadunacomponenteimplementatain formadi agentenonpuo servirsidi unachiamataa metodoo unachiamataa procedura,manecessitadi spedireunamessaggioin FIPA ACL. Peresprimereunarichiestadi registrazionead un DF implementatocomeagente,avra bisognodi un’onto-logia con cui esprimerei concettirelativi alla descrizionedei servizi chevuoleregistrare.

Perportareunesempio,vienepropostaun’ontologiaFIPA-Agent-Managementnellaqualesonodefiniti i termini del linguaggioconcui parlaredel dominodellagestionedegli agentiFIPA. Standardizzarele ontologieconcui parlaredeiserviziofferti dallecomponentiFIPA e equivalentea standardizzarele “procedure”concui si richiedonoi servizi, si noti checio e simile a quello cheabitualmentesiottienenei contestidi programmazioneorientataagli oggettiquandosi definiscel’interfacciaconla qualeaccedereai servizidegli oggetti,solochenel casodegliagentiattraversole ontologielavoriamoadlivello di astrazionepiu elevato. Con-cludiamoosservandochenella specificheFIPA le ontologiehannounadupliceutilit a:

� descriveregli elementidellaspecificae la relativasemantica;

� fornireunstrumentoperrichiederei serviziallecomponentirealizzatecomeagenti.

3.6 Progetti FIPA

Vi sonoalcuniprogettiapartecipazioneinternazionale,chehannoadottatole spe-cificheFIPA in mododaverificarel’applicabilita delledellestesse.Ne descrivia-mobrevementealcuniriportandocio chee illustratoin [52].

84

FACTS: unprogettopervalidareil lavorodellaFIPA especifichestandardprove-nientidaaltri gruppiattraversola costruzionedi sistemibasatisullespecifi-cheFIPA. L’obiettivo delprogettoecontrollarele effettivepotenzialitadel-l’interoperabilita nei termini specificatidallaFIPA. Il progettoe suddivisoin duefasi.Nellaprimafasevengonofatteinteroperareplatformdi differen-te provenienzasuognunodei tre campiapplicativi specificati(audio-videobroadcastingan entertainment,servicereservation, elettroniccommerce).Nellafasesuccessivasi fannointeragiresistemiappartenentiadiversicampiapplicativi.

LEAP: e il precursoredella secondagenerazionedi platform per agentiFIPAcompatibili. LEAP (Lightweight ExtensibleAgent Platform) individua lenecessita relative adinfrastruttureaperteconservizichesupportanodistri-buzionesureti wireless,perquestoparticolarmetedinamichee mobili. Leplatform di questotipo rappresentanounasfidadal puntodi vista tecnico,in quantonecessitanodi generareed eseguireagentiin unagrandevarietadi ambientirun-timein mododa“girare” sudifferentihardware(cellulari,palmari,PC) e comunicarecon unavarieta di meccanismi(TCP/IP, WAP,ecc.).

Agentcities: halo scopodi realizzareapplicazionidi ricercaecommercialibasatisuagenticheaccelerinolo sviluppodi unasuccessivagenerazionedi serviziInternet.Taleobiettivo vieneperseguito in tremodi:

1. sviluppandounainfrastrutturachesiapubblicamenteecontinuamenteaccessibileepossaospitarei servizipergli agenti;

2. sviluppandoi servizi in mododapopolarela retedi unavastaoffertadi servizigratuiti ecommercialisul qualecostruirealtreapplicazioni;

3. incoraggiarela collaborazionenella ricerca: promuovendouna retecheindividui gli obiettivi di ricercae svilupposugrandescalaquindiabiliti lo scambiodi informazionitraprogettiesistentie futuri.

Ognunodi questiprogettihamessoin lucenuoverichiesterispettoalleesigen-ze d’interoperabilita FIPA scavandoulteriormentenegli aspettidella semanticadellainteroperabilita. ProgetticomeAgentcitiesportanoa lavorareulteriormentesulleontologie,le interazionidi servizi,le responsabilitaefiducianegli agenti.

3.7 Conclusioni

In questocapitolo abbiamobrevementepresentatopartedel lavoro della FIPA,concentrandocisugli aspettipiu vicini alle problematichedi comunicazionee le

85

funzionalitachedovrebberoessereoffertedalleplatformperagentiFIPA compa-tibili.

Abbiamoincominciatoadinteressarcial fenomenoFIPA quandoci siamoim-battuti per la prima volta nelle specifichedell’architetturaastratta. Rendendo-ci conto che cio che era specificatonel documentorappresentava una sortadimeta-MAS dalqualel’utentepotevaistanziareil suosistemaadagentipensammochetale framework concettualeci potesseaiutarea focalizzareulteriormenteleesigenzee le problematichechepoteva incontrarel’utentedi D-CaseLP.

Spessoabbiamoavuto a chefareconspecifichesviluppatedaworking groupetechnicalcommitteedifferenti.Cio unitoal fattochela specificaastrattaeappo-sitamentedefinitacomeunaspecificaloose27 e chein unaprima fasenondispo-nevamodi altro materialeal di fuori dellespecificheFIPA per raccapezzarcifragli obiettivi dell’intentodi standardizzazione,nonharesosempliceil compitodiesplorarele specificheemetterlein relazionetradi loro. Quellacheall’inizio do-vevaessereunaveloceocchiataal lavoroaltrui hacambiatole prospettivein cui cimuovevamosvolgendounruolo fondamentalein questolavorodi tesi.Manmanocheprendevamoconfidenzaconle specificheci rendevamocontochele ipotesidanoi operatetrovavanoconfermaedin certi casiunaformapiu definitanel lavoroeffettuatodallaFIPA28.

Il tentativo di standardizzazioneoperatodallaFIPA ha il meritodi essereunpassoversounavisionepiu concretadella tecnologiaadagenti.Siamoconsape-voli chela standardizzazionenone la panaceaa tutti i “mali” maa nostroavvisopuo avere importantibeneficiper cio che riguardal’affermarsidella tecnologiabasatasulparadigmaadagenti.

Perottenereunapienalegittimazioneda partedegli ambientidi produzionee necessariosviluppareun certonumerodi progetti che individuino e mostrinocontributodelletecnicheadagentinellarisoluzioneproblemiconcretie l’effettivovantaggiodel loro impiegorispettoalle tecnologiepiu consolidate.

La ricercadi unalegittimazionenonva consideratacomeil merotentativo ditrovareun’ulterioregratificazioneeconomicaal lavorodi ricerca,mapiuttostoco-meun passofondamentaleperlo sviluppodel paradigmastesso.ComeosservatodaNwanaeNdumuin [47] al finedi avereun’effettivo riscontrodi quellechesonole potenzialita del paradigmaad agentie di primariaimportanzachela tecnolo-gia siaampiamenteimpiegata.Questoimplica la necessita di risolvereproblemiconcretiedaccollarsicosti notevoli, duecondizionidi cui probabilmentesolo le

27Con il termine specifica loose intendiamo una specifica da cui e possibile ottenereimplementazionipiuttostodiversetra loro.

28Si pensiadesempioall’esigenzadi avereun’interfacciaversola comunicazionechepermet-tesseil supportodi differentiimplementazionidellacomunicazioneo le posizionisullaminimalitacheportanoentrambia nonspecificaredettagliinutili delmicro-livello degli agenti.

86

industriesi possonofarecarico.

SempreNwanae Ndumuin [47] analizzanolo scenariochesi prospettanellaproduzionescientificasull’argomentonegli annisuccessivi al 1995fino al 1999eosservanoalcunifenomenia loro dire abbastanzapreoccupanti:

� alcunideilavori pubblicatipresentavanoancoraconfusionetraObjectOrien-tationeconcettirelativi agli agenti;

� molteproposteeranocaratterizzatedaunaprematuramatematizzazione.Laricercadi basimatematicheaveva l’effetto di spostareprematuramentepar-te degli sforzi chepotevanoessereimpiegati nell’individuazionedei van-taggi offerti dal paradigmaad agenti in una ricercadi fondamentiper ilparadigma;

� in alcunilavori si potevaosservareunarietichettatura29 di concettidatemponoti. Questofenomenononsempredi natura“dolosa”portavaa lavori il cuicontributoeradi limitataconsistenza.

A nostroparerela standardizzazionein corsoadoperadellaFIPA, per le moda-lit aedi principi cheabbiamoparzialmentedescritto,pur lasciandounasufficienteliberta di ricercaoffre un framework concettualechepuo fungereda fondamen-to per l’applicazioneconcretadel paradigmaad agenti. Questopuo essereuti-le a focalizzaregli obiettivi della ricercafutura ed in parteeliminarei problemievidenziatidaNwanaeNdumu.

Il fatto che la FIPA nascacomeforum che vedela presenzadi importantiaziendeegruppidi ricerca(anchedi origineaccademica)costituisceun elementopositivo chefa bensperarein questosenso.Cio checi auguriamoe chetale ini-ziativa possagiocareun ruolo simile a quellochel’ OMG hagiocatonell’ambitodelle tecnologieadoggetti. Durantei mesiin cui si e lavoratoa questolavoro ditesi,abbiamoavuto l’impressionechel’interesserispettoall’iniziativasiain con-tinuoaumento,vi sonouncertonumerodi platformchesi sonoadeguateo hannosceltodi aderireallespecificheFIPA. Nei prossimicapitoli illustreremol’impattochele specificheFIPA hannosuD-CaseLP.

29Processosecondoil qualesi dannonominuovi aconcettivecchi.

87

Capitolo 4

Inclusione del framework FIPA inD-CaseLP

In questocapitoloillustriamo qualeimpattoha avuto l’introduzionedelle speci-fiche FIPA sulla progettazionedi D-CaseLP. Daremounadescrizionedelleca-ratteristicheofferte dal tool JADE per lo sviluppodi agentiFIPA compatibili el’apporto chequestoforniscenella realizzazionedi D-CaseLP. Concluderemoconun confrontotra JADE e CORBA, il qualeinsiemealle motivazionidi pro-getto1 ci fornira gli elementichegiustificanola sceltadi abbandonarel’impiegodi CORBA e la decisionedi progettareun D-CaseLP basatosuJADE.

4.1 Perche includere le specificheFIPA

Il modelloconcettualepropostodallaFIPA hacambiatole prospettivedi progettodi D-CaseLP. L’impattodi questavariazionesulnostrolavoro e stataabbastanzaconsistente,nonostantecio vi sonovalidemotivazionealla basedi questoaggiu-stamentodi rotta. A prescinderedal fatto che la realta FIPA si sta evolvendorapidamentee diventasempremenosensatoignorarel’operatodi taleorganizza-zione,valela penaillustrarequali fattori ci hannospintoa mettereD-CaseLP inrelazioneconil lavoro FIPA.

Ar chitetture per agente. La FIPA non standardizzal’intelligenza interna deiMAS, le specifichesi concentranosugli aspettirelativi l’intelligenzaester-na.Questolasciaampialibertarispettoallasceltadell’architetturaperagen-te chesi deve adottarenellarisoluzionedei propri problemi. Permettereal

1Le motivazionidi progettosonotutte le considerazionirelative al contestoprogettualein cuistiamolavorando.

88

progettistadi scegliere qualearchitetturasia piu adeguatainveceche co-stringerload adattarele suesoluzioni su un’architetturasceltaa priori eunodeipunti cruciali di D-CaseLP eprimaancoraCaseLP, il fattochelaFIPA facciaipotesianaloghealle nostree incoraggiante.

Una visioneconcreta. La FIPA offre dellespecifichechesi propongonodi risol-vereproblemida unaprospettiva concreta. Il fatto chevi sianoindustriecoinvolte nell’iniziativa focalizzail lavoro versoobiettivi pratici, il cui fi-neultimo e soddisfarele aspettative di applicazionedegli agenti.Di questiaspettiil progettoD-CaseLP nonpuo chefar tesoro.Il gruppodi program-mazionelogicadell’universita di Genova haavuto esperienzesignificativedi collaborazionicon l’industria per la risoluzionedi problemiconcretisivedanogli articoli [16, 17, 3]. Questeesperienzepero, sonolimitate allaprogettazionedi prototipi di MAS ed all’individuazionedi unasoluzionelogica per i problemi. Per tali progetti, infatti, il grupponon ha curatolapartedi realizzazionesuccessiva alla definizionedel prototipo. L’adozionedellespecificheFIPA ci permettedi indirizzarealcunedelleproblematichechesi incontranononappenasi escedallavisioneastrattadei problemiecipermettedi recuperaredaterzi partedell’esperienzadi cui deficitiamo.

Nuovedir ezioni di ricerca. Le specificheFIPA pur avendocomescopoprinci-palerenderefruibile la tecnologiaadagentiin contestiapplicativi, a voltemettonoin evidenzale problematichesu cui e utile focalizzarela ricerca.Fra le esigenzeteorichechesi stannoevidenziatovi e un’evoluzionedellacomunicazionebasatasuAgentCommunicationLanguageversoil suppor-to di ruoli e interactionprotocol. La FIPA non proponeunametodologiadi sviluppo propria, anchese in un certosensoil framework concettualeche emerge dalle specificheha ancheuna valenzametodologica:si pen-si all’architetturaastrattae l’utilizzo chesene puo fare. Il progettistadiMAS puo far usodell’architetturaastrattaper individuarealcuni dei pro-blemi da affrontareduranteun design,e sfruttaretale specificacomeunaspeciedi “formina” con la qualeprogettaresistemiMAS capacidi intero-perarecon altri. L’architetturaastrattanon e ovviamenteunametodologiaverae propriacorrispondeal massimoad un insiemedi linee guidaper ildesigndi MAS, c’e quindi ampiospazioper proporrenuove metodologieperla realizzazionedi MAS aderentialla FIPA.

Le specifichedellaFIPA coinvolgendodiversigruppidi ricercaoffronounavisioneunitariasuddivisa in piu livelli di astrazionedi quellechesonoleproblematicheancoraaperte,offrendospessoancheun’indicazioneindiret-ta di quali sonole piu urgenti, sesi vuole che il paradigmatrovi un suospazionelmondodelleapplicazioni.

89

Sistemiaperti. Quandoil progettoD-CaseLP e partito ci si limitava a consi-derareambientichiusi, nei quali non si prevedeva che i MAS dovesserointeragireconaltri perrisolverei propri problemi.Questaipotesipuo risul-tareabbastanzalimitativa. Nonostantesiadi difficile realizzazione,echelaspecificaFIPA indirizzi soloalcunidei problemichee necessariorisolvereper ottenerepraticamentesistemiaperti,e futuribile chetale caratteristicagiocheraunruolo importantenellosviluppodelparadigmaadagenti.Negliultimi tempisonoapparsianchearticoli cheinizianoaconsiderarel’impat-to chepotrebbeaverela commercializzazionedi sistemiapertinel contestosociale[13, 51]. La rivoluzionedi cui siamostati testimoninegli ultimiannicon l’avventodi Internet,haavuto un impattosullasocieta chee sot-to gli occhidi tutti2, la realizzazionedi comunita apertedi agentipotrebbeportareal completamentodi questarivoluzione.In unaprospettivaa lungotermineci sembrachela capacitad’interagireconaltri MAS in manieradeltutto dinamica,ovverosenzachei sistemicoinvolti sianostati pensatiperinteragireuno con l’altro, per quantodifficile da otteneresia unadirezio-ne cheva almenotenutapresente.Gli sforzi impiegati versotale direzio-ne senon porterannoal raggiungimentocompletodegli obiettivi possonocomunquefornire interessantispuntiper la risoluzionedei problemilegatiall’integrazionedi softwarelegacy.

4.1.1 Aggiornamentodel FRT di D-CaseLP

La progettazionedel tool ela valutazionedellespecificheFIPA peruncertoperio-do sonostatedueattivita cheabbiamoportatoavanti contemporaneamente.Que-stomododi procederee la consapevolezzacheil progettoD-CaseLP disponevadi una limitata forza lavoro ha fatto si che l’inserimentodelle componentipre-scrittedallaFIPA fossegraduale.Perquantoriguardale caratteristicheFIPA daincluderenel tool, l’idea eradi accontentarsidi un tool parzialmenteaderenteallespecificheFIPA, checontenessealmenole caratteristicheminimerelativeaservizidi DirectoryServiceesupportoa trasportimultipli (MTS).

In figura4.1 illustriamoil FRT aggiornatocongli elementidellaspecificaFI-PA di cui vogliamotenercontogia dai primi prototipi di D-CaseLP. Perquantoriguardai servizidi directorysi pensava di limitarci a fornire serviziequivalentia quelli di paginebianche,lasciandoper eventuali lavori di estensionei servizidi paginegialle. Invece,per i servizi di trasportoci eravamopropostidi fornire

2Si pensiad esempioall’uso della postaelettronicache in ambito lavorativo ha resoprati-camenteobsoletol’utilizzo del FAX o al boomdel Word Wide Web conservizi comel’InternetBanking,il TradingOnLine,maancheagli entusiasmichehannogeneratoespressionicome“neweconomy”.

90

1. Modellazioneecreazionedi codiceperil prototipodelMAS.... ... ...

2. Realizzazionee validazione di un prototipo della applicazionesottosviluppo.

(a) Installazionedegli strumenti offerti da D-CaseLP.

(b) Implementazioneprototipo del MAS.... ...

i. Supporto alla comunicazione.� Dir ectory NameService (FIPA)� Comunicazionevia MTS (FIPA)

3. Implementazionedellaapplicazionefinita. ... ...

4. Utilizzo dellaapplicazionefinita. ... ...

Figura 4.1: Aggiornamentodell’alberodellefunzionalitaD-CaseLP.

un unicotrasportoimplementatoattraversoCORBA manasconderel’implemen-tazioneattraversoil meccanismodi degli MTS, implementandoun trasportochefacesseuso degli envelopee dei messagetransportcomeprescrittodalla FIPA(si vedasez. 3.3.4). Cosı previa la realizzazionedi altri trasportiavremmoot-tenutoin modoeleganteil supportoa diverseimplementazionidelleprimitive dicomunicazione.

4.1.2 Le platform aderenti alle specificheFIPA

L’esistenzadi alcuni tool per la realizzazionedi sistemimulti-agentechefannousodel framework concettualedellaFIPA, ci hafattosorgereil dubbiocheci fos-sequalcosadi giafattodapoterriutilizzareedeventualmenteestendereperforniregli strumentiprevisti in D-CaseLP. Vi sonotool molto differenti fra di loro cheoffrono un supportoversola realizzazionedi MAS FIPA compatibili3 Comeevi-denziatonella tabella4.2, fra i tool aderentialla FIPA ve nee unochehaalcunecaratteristicheinteressantiper i nostri scopi: JADE. Cio checi ha convinto adanalizzarequestotool e l’esplicito riferimentodapartedeiprogettisti[8] allapos-sibilita di implementaredifferentiarchitettureperagentia partiredagli strumentiin essoforniti.

3La lista completa ed aggiornata dei tool e disponibile all’indirizzohttp://www.fipa.org/resources/livesystems.html.

91

Nometool

Linguaggio d’imple-mentazioneper tool

Linguaggio d’im-plementazioneper(program) agenti

Ar chitettura peragenti supportata

Zeus Java desire, belief, in-tention

BDI modificata

JADE Java Java + API Qualsiasi pur-che esprimibile inBehaviour

April C April Qualsiasi esprimibilein April

Fipa-OS Java Java Architettura struttura-ta in stackdi compiti,conversazionie comu-nicazioni su differentilivelli

Figura4.2: ProgettiOpenSourcedi tool perla realizzazionedi MAS aderentiallespecifiched’interoperabilitaFIPA.

4.2 JADE

JADE (JavaAgentDevelopmentEnviroment)eunprogettoopensourcecheoffregli strumentisoftwarechepermettonodi sviluppareapplicazionibasateadagen-ti compatibili con le specifichedi interoperabilita FIPA. Vediamoalcunedelleprincipali caratteristicheoffertedaJADE:

� unaagentplatformdistribuita;

� unaAPI Java perspediree riceveremessaggiFIPA ACL;

� unalibreriadi interactionprotocolpronti peressereutilizzati;

� il supportoalla mobilitadegli agenti;

� librerie pergestireontologiedefinitedagli utenti;

� un’implementazioneaderentealla specificheFIPA del protocolloIIOP perconnettersiadaltreplatform;

� un’iterfacciagraficaper monitoraree controllarel’esecuzionedistribuitadegli agenti;

Nelle sottosezioniseguentipresenteremoil framework ricalcandola suddivisoneutilizzata in [4], dove si presentail tool prima da un puntodi vista descrittivo

92

illustrandole varie componentiche permettonol’esecuzionedegli agentie poidal punto di vista dell’utenteche lo deve utilizzare, descrivendoquali sonoleconoscenzee le classiJava chepermettonodi scriveregli agenti.

4.2.1 JADE Run-Time

Agent platform.

La platformdi JADE, puo essereconsideratala componenteprincipaledel Run-Time, includeun AgentManagementSystem(AMS) edun DirectoryFacilitator(DF) realizzatisottoformadi agentiattivati automaticamenteall’inizializzazionedellaplatform.

La platform JADE puo esseredistribuita su differenti hostsattraversoquellichevengonochiamatiAgent Container. Ogni agent-containervive su unaJavaVirtual Machinedistinta,e un RemoteMethodInvocation(RMI) server ed e re-sponsabilepergli agentiin essoresidenti.Il controllodelciclo di vita degli agentiviene gestito in locale dal singolo agentcontainerche ha la possibilita creare,sospendere,distruggeregli agentiin manieraindipendentedagli altri.

La suddivisionein containere di conseguenzala distribuzionedellaplatformJADE e totalmentetrasparenteagli agentiesternialla platform.Esiste,infatti, unagentcontainerprincipaledenominatoMain-Containero front-endcheincarnalefunzionalita di unaserver IIOP4, attraversoil qualegli agentiresidentisu altreplatform,nonnecessariamenteplatformJADE, possonointeragirecongli agen-ti JADE. Il main-containersulla basedelle informazionicontenutenell’AMS sioccupadi ridistribuire le comunicazioniai containersuiquali risiedonogli agenticoinvolti nellacomunicazione.

La comunicazionetra agenti in JADE.

Comeillustratoin [7] la comunicazionein JADE e di tipo peer-to-peer5 edavvie-netramitescambiodi messaggi.E previstaunadiversamodalita di consegnadeimessaggiFIPA ACL asecondadi dovegli agentisonocollocati.

ComunicazioneIntra-Container: avviene fra agenti residenti in uno stessoAgent-container. Permotivi di efficienzala comunicazioneavvienetramite

4Un server chee in gradodi accettarerichiestecon l’Internet Inter-Orb Protocol(IIOP). Taleprotocollopermettedi inoltrarerichiesteadoggettidistribuiti attraversoil trasportoTCP/IP.

5Ricordiamochequestotipo di comunicazioneal contrariodellacomunicazioneclient-server,prevedechele dueentitacoinvoltenellacomunicazioneabbianouguali“doveri” e “diritti”.

93

un oggettoeventoJava contenenteil messaggiosenzachesianoeffettuatele operazionimarshallingedunmarshallingdel messaggio6.

ComunicazioneInter -Container: avvienefra agentiresidentisudiversiAgent-containermaappartenentiallastessaJADE platform.La comunicazioneinquestocasoeeffettuatatramiteRemoteMethodInvocation(RMI).

ComunicazioneInter -platform Avvienefra agentiresidentisuplatformdistin-te, non necessariamenteJADE Agent Platform, in conformita con quantospecificatodallaFIPA.

La sceltadel tipo di comunicazionetradueagentivieneeffettuataasecondadidovesonocollocati i duein mododel tutto trasparenteagli agentiedal program-matore,in pienacoerenzacon la filosofia FIPA. Al fine di selezionareil mecca-nismodi trasportopiu efficienteogni agent-containermantieneunatabelladellelocazionidegli agentichiamataLocal-AgentDescriptionTable (LDAT). Il main-containeroltre alla LDAT mantieneancheunatabellaGlobal-AgentDescriptionTable(GADT), chemappaogniagentenel riferimentoRMI delsuocontainer. Perevitarecheil main-containersiacontinuamenteinterpellatosonoutilizzatetecni-chedi “caching”dei riferimenti perle comunicazioniinter-container. Le tecnichedi cachingpermettonodi mantenerelocalmenteai vari containerle informazio-ni relative ai riferimenti dei containerche ospitanoagenticon cui e necessariocomunicare.

E nella comunicazioneInter-Platform che entranoin gioco la possibilita diutilizzare differenti implementazionidei trasporti. Comesi accennava prima iltrasportoutilizzatoe in genereIIOP maepossibileaggiungereo sovrascrivereal-tre implementazionidi MTS conle qualieffettuarecomunicazioniinter-platform.Gli autori dichiaranochela progettazionee statafattain mododa poteraggiun-gerealtre tipologiedi trasporto(WAP o quant’altro)senzagrossisforzi. Insiemeal run-timedi JADE e possibileottenerealcuneimplementazionidi MTS, tra lequali il trasportohttpedil trasportoOrbacus IIOP.

Un agentesoftwarein aderenzaallespecificheFIPA haun identificareglobal-menteunico(globally-uniqueidentifier:GUID)7 chepuo essereutilizzatodaogniagenteper indicarenegli appositicampidei messaggiFIPA ACL i destinatariedil mittente. Comeavevamovisto nelle specificheFIPA gli indirizzi degli agentisonodellaforma � nomedell’agente� @� indirizzodellaplatform� .

6L’operazionedi marshallingpermettedi trasformarei messaggiin un formato adeguatoaltrasportosuunacertarete,mentrel’unmarshallinge l’operazioneinversa.In questocaso,trattan-dosi di unacomunicazionetra dueagenticherisiedonosullastessamacchinala conversionedelmessaggioin un formatoadeguatoal trasportosarebbedel tutto inutile.

7Nel capitolorelativo alla FIPA ci eravamoriferiti all’identificatoreglobalmenteunicocomeAgent-IdentifierAID.

94

Ontologieecontent languagedefiniti dall’utente.

Nel capitolodedicatoalla FIPA abbiamogia descrittoil ruolo cheil contentlan-guagee le ontologiegiocanonellacomunicazionetra agenti,abbiamoanchepre-cisatochela FIPA definendoun insiemedi ontologiesupportatedei servizidaleispecificatistandardizzal’interfacciacon la qualesi accedeagli stessi. Al di ladell’usodelleontologieindipendentidal dominioapplicativo dellaFIPA, l’utenteperpermetteredi fornire i servizicheprogettaagli agentiavra bisognodi definiredelleontologiedipendentidal dominio.Nelle versionipiu recentidi JADE, sonoforniti ai programmatorigli strumentiperdarela possibilitadi crearsile loro on-tologieedadottarei loro contentlanguage.Ogni agenteJADE tieneunatabelladovesonoelencatii contentlanguagee le ontologieconosciute.

Strumenti per la gestioneed il monitoring dell’esecuzione.

Oltre cheun’implementazionedella platform in cui possonoessereeseguiti gliagenti,vengonoforniti gli strumentiperil monitoringe la gestionedell’esecuzio-nedistribuita.Tutti gli strumenticheandremoadescriverenelseguitosonofornitisottoformadi agentinellaplatformJADE sullaqualeoperano.

RemoteMonitoring Agent (RMA). Il framework JADE offre i consuetistru-mentigrafici pereffettuareil monitoraggioed il controllo (start,stop,ecc)remotodegli agentieseguiti. L’aspettopiu interessanteecheesisteunapro-postapressola FIPA perstandardizzarel’ontologiadi monitoringutilizzatada JADE, e quindi l’iterf acciacon cui si accedeai servizi di controllo emonitoringdegli agenti. Setalepropostavenisseaccettataedaggiuntaal-l’ontologia Fipa-agent-management, RMA potrebbepotenzialmenteessereutilizzatoancheperil controlloe la gestionedi agentichenonsonoeseguitidallaJADE AgentPlatform. In figura4.3si puo osservarecomesi presental’interfacciagraficadel RMA.

Dummy Agent. E unagentefantocciochepermettedi spediremessaggiFIPA ACLagli altri agentidaun agentefittizio. In questomodosi possonostimolaregli agenticon richiestecostruiteartificialmentevolte a testarneil corret-to funzionamento.La preparazionedei messaggiFIPA ACL e facilitatada un’interfacciache permettedi editaretutti campi di cui i messaggisicompongonoegli envelopein cui racchiuderli.

Sniffer Agent. Questoagentepermettedi visualizzarei messaggichesi scambia-no gli agentiresidentiin unaplatformJADE. E possibileselezionarequaliagentispiarefra tutti quelli in esecuzionenella platform. Oltre a vederechi comunicaconchi tramiteunaspeciedi sequencediagramdeimessaggi(figura4.4),e possibileeditareil contenutodellecomunicazioni.

95

Figura4.3: L’interfacciagraficaconcui si accedonole funzionalitadel RMA.

Figura4.4: L’interfacciagraficadello tool Sniffer.

96

Intr ospectorAgent. Questotool e statoaggiuntonelleultimeversionidi JADE,permettedi visualizzarelo statointernodi unagenteattraversolavisualizza-zionedellacodadeiBehaviour8 e la visualizzazionedellecodedeimessag-gi in uscitaedin entrataall’agente.Vengonovisualizzateanchele codedeimessaggipendentichestannoaspettandodi esserespeditio ricevuti (figura4.5).

Figura4.5: L’interfacciagraficadel tool Introspector.

4.2.2 Il modello di sviluppo degli agentiJADE

In questasottosezioneillustriamoil modelloattraversoil qualesi possonoscrive-re agentiJADE. In questomodello,sonoofferteun insiemedi funzionalita volteadaiutarelo sviluppodegli agentie la loro esecuzionesul run-timeJADE. OgniagenteJADE e un threadeseguito daunodei containerdellaJADE platform. Inconcretogli agentiJADE nonsonoaltro checlassiscrittein Java utilizzandolefunzionalita offerte in unaAPI chepermettedi accedereal run-timee di sfrutta-re unaseriedi classipredefinitepercomporree codificaremessaggiFIPA ACL,

8Peril momentosi considerinoi Behaviour comesonoinsiemi di istruzioni chedefinisconoi compiti dell’agentechesi stamonitorando,sene dara unadettagliatadescrizionenelle sezionisuccessive.

97

gestireontologie,parteciparead interactionprotocol, eccetera.Nel seguito fa-cendoriferimentoa [6] illustriamoalcunedelleclassicheappartengonoalle APIJADE in modo da dareun’idea, seppurminima, degli strumentiofferti per laprogrammazionedi agenti.

La classeAgent.

Ogni agenteestendela classeAgentdefinitanelle librerie JADE. In taleclasseefornita l’implementazionedei metodichepermetterannoalla platformdi control-lare l’agentesecondoil ciclo di vita specificatodalla FIPA. Semprenella classeAgentsottoformadi metodisonofornite le primitive chepermettonoall’agentedi accedereai servizidi comunicazioneofferti dallaplatform.Ogniagentehaunamailboxprivatain cui la platformconsegnai messaggiadessodestinati.L’agentepuo accederein diversimodi al contenutodellasuamailboxattraversole primi-tivedi ricezione.Estendendola classeAgenttuttequestecaratteristichevengonoereditaredagli agentidefiniti dal programmatore.Le primitivedi comunicazionesupportatesono:

blockingReceive(): questometodooffre la possibilitadi accedereallamailboxinmanierabloccante,quindi, seal momentoin cui e invocatoil metodononvi sonomessagginellamailboxconle caratteristichedesideratel’agenteri-manein attesa. Il metodoin questionee overloaded, questoimplica cheesistonodiversesegnaturechepermettonodi specificareun numerovaria-bile di argomentinella chiamatadel metodo. I parametriche e possibilespecificaresono:

� un oggettodi classeMessageTemplate, chespecificale caratteristichedelmessaggioFIPA ACL delqualesi e in attesa.Applicandoil patternmatching9 sui messaggicontenutinella mailbox e possibileselezio-narneunoaderenteallo schemaindicato. Sequestoparametronon especificatosignificachesi e implicitamentein attesadi un messaggioqualunque;

� un timeout,il qualeesprimequantimillisecondisi e dispostiadatten-dereprimacheunmessaggioconlecaratteristichedesideratearrivi. Seil messaggioarriva entroil tempoindicato,vienerestituitonella for-madi unoggetto,seil temposcadeprimavienerestituitoil riferimentoall’oggettonullo “null”. Quandoquestoparametronon e specificatol’attesae realizzatamettendol’agentenello statoBlocked. L’assenzadel timeoutsignificainfatti chesi edispostiadattendereuntempoan-

9Abbiamoillustratola tecnicadelpatternmatchingnellasottosezione1.3.5.

98

cheillimitato l’arrivo di un nuovo messaggio,mettendosinello statoblockedl’agenteverra risvegliatosolosearrivaunnuovo messaggio.

receive(): e la primitiva chepermettedi effettuareunaricezionenon bloccantedei messaggi.Ancheperquestasi ha la possibilita di indicareunoschema(pattern)di messaggio.Nel casoin cui nonvi sianonellamailboxmessaggiconle caratteristichedesideratela primitivaritornaimmediatamente“null”,altrimentirestituisceun oggettoconil messaggioselezionato;

send(): e la primitivachepermettedi spedirein modalitaasincronaunmessaggioespressoin FIPA ACL indicatocomeargomento.

Frale cosechel’agentechestiamoscrivendoereditavi eancheunoschedulerper i Behaviour. I Behaviour sonole componentichedefinisconoil comporta-mentodegli agenti.Perscrivereun agenteJADE e necessarioestenderela classeAgent,edimplementarei compiti di un agentescrivendounoo piu sottoclassidiBehaviour. Andiamoadapprofondirealcuneaspettilegati ai Behaviour, ponendoparticolareattenzioneal modellodi concorrenzacheesottintesonel loro utilizzo.

4.2.2.1 Il modello di concorrenzadi JADE

In questoparagrafodiscutiamole soluzioniadottatedaJADE nel fornire la con-correnzaagli agenti. La comprensionedel modello di concorrenzasottostanteJADE none forsedi immediataassimilazionemae indispensabilesesi voglionoutilizzarecorrettamentegli strumentiforniti dal tool. Abbiamocercatodi fornireanchealcuneinformazionisucomevienegestitoil multithreadingin Java in mo-do chesiapossibilerendersicontodei problemie i vincoli chebisognarisolverenel fornire la concorrenzain un tool sviluppatoin Java.

Gli agentiperle caratteristichedi “sociality” e“autonomy”necessitanodi duelivelli distinti concorrenza:

� concorrenzatra l’esecuzionedegli agenti;

� concorrenzatracompiti indipendenticheun agentedeve intraprendere.

Vistochenonsi puo pensarecheogniagenteo peggioogni suaattivitaabbia-no un processorea disposizione,bisognasimularela concorrenzaconil multita-sking ed il multithreading.Riportiamoper maggiorchiarezzale definizioni permultitasking,multithreadinge threadillustratein [46].

Definizione4.1 Per multitasking si intendela caratteristicadi un sistemaope-rativodi permetterel’esecuzionecontemporanea(o pseudocontemporanea10 [...])di diversi processi.

10Con pseudocontemporaneasi ci riferisce al fatto che se una macchinapossiedeun soloprocessorel’esecuzionecontemporaneanonpuo cheesseresimulata.

99

Definizione4.2 Un thread e un flussodi esecuzionedel processore corrispon-dentead unasequenzadi istruzioniall’interno di un processo.Analogamenteaiprocessi,bisognadistinguere il concettodi esecuzionedi unasequenzadi istru-zionidaquellodi thread,poicheci possonoesserediverseesecuzioniparallelediunostessocodice, chedannoorigine a threaddiversi.

Definizione4.3 Per multithr eading si intendel’esecuzionecontemporanea(opseudocontemporanea,[...]) di diversi threadnell’ambito dello stessoproces-so. La gestionedel multithreadingpuo essere a carico del sistemaoperativo, sequestosupportai thread,mapuo ancheessereassuntadal processostesso.

La differenzafra processiethreadstanel fattochei thread,fattaeccezioneperlo stacke i dati temporaneiusatidalle funzioni, condividono lo stessospaziodimemoria.Questacondivisionerendepiu semplicela comunicazionetra i threade menodispendiosoil cambiodi contestoquandosi passadall’esecuzionedi unthreadadun altro.

In generalevi sonoduetipi di multitasking: il preemptiveo cooperative. Ilprimo tipo di multitaskinghacomecaratteristicaprincipalecheogni attivita unavolta in possessodellarisorsaprocessore,puo essereinterrottaedesserecostrettaa lasciarela risorsaa qualcunaltro. In particolarenei sistemidetti a time-sharingl’interruzioneavvienesullabasedel tempod’utilizzo di un processo,si puo defi-nireun time-sliceoltre il qualeseunprocessononhafinito di utilizzarela risorsavieneinterrotto.Il secondotipo di multitasking,invece,nonhala caratteristicadi essereinterrom-pibile enessunopuo appropiarsidellarisorsafino aquandononvienevolontaria-menterilasciatadal processochela detiene.

Le tipologiedi multitaskingsui processiappenaillustratesi adattanoanchealmultithreading.JADE e completamenteimplementatoin Java chee un linguag-gio semi-interpretato,il cui codiceoggetto(bytecode)e eseguibile su qualsiasipiattaformaper cui sia disponibileun’implementazionedella Java Virtual Ma-chine(JVM). Essendoprogettatoper esserecosı portabile,il bytecodenon puofareriferimentoa funzionalita chestannoad un livello troppobasso.Quandositrattadi offrire le funzionalitadi multithreadingdevebasarsisuun’astrazionedeilivelli sottostanti.Questaastrazioneedefinitadallespecificheufficiali dellaJVM.

Le specifichedellaJVM assumonochei threadsianogestiticonunoschedu-ling di tipo preemptive chiamatofixed-priority scheduling. In questoschemasiprevedechei threadsianoschedulatiin baseadunapriorita,eda partesituazioniparticolari,i threadconprioritapiu altaprevalganosuglialtri nellaconquistadellarisorsa.Anchesein molti sistemioperativi e fornito un multithreadingbasatosu

100

time-slicing11, le specifichedellaJVM nonlo prevedono.E possibiletuttavia, inalcuneimplementazionidellaJVM forzarel’utilizzo dei threaddi sistemaeacce-derea funzionalita nonprevistedallaspecificadellaJVM. Sesi vuolemantenerela completaportabilita del codicechesi producesi deveassumeredi lavoraresuigreenthread , i threadchesonogestiti dai processied ignorati dal sistemaope-rativo. IL fatto che le specifichedella JVM non prevedanoil time-slicingnellaschedulazionedei threadimplica cheaffinche le cosefunzioninocorrettamenteithreadJava devonorilasciarespontaneamentele risorse.

Ritornandoa JADE, abbiamodetto che la platform e distribuita in agent-containerognunocorrispondentead un’attivazionedifferentedella Java VirtualMachine. Ogni istanzadella JVM e un processomentreogni agentee un th-readresidentein uno degli agent-containerdella platform. Quindi in JADE laconcorrenzatraagentivieneottenuta

� graziealla distribuzionesupiu agent-containerfra agentiresidentisudiffe-renti container;

� grazieall’esecuzioneconcorrentedei threadperagentiresidentisullostessocontainerattraversounpreemptivemultithreadingsenzatime-slice.

Ci rimanedaillustrarecomeJADE forniscala concorrenzatra le attivitadegliagenti. Si potrebbepensaredi fornire la concorrenzatra i compiti degli agentiassociandoadogni compitoun threaddistinto.Cosı facendoaumenterebberoco-sistevolmenteil numerodi threadnecessaripereseguireunMAS evaconsideratoil fattocheci possonoesseredei limiti al numerodi threadchesi possonoattivare.Perquestomotivo gli sviluppatorihannopreferitoutilizzaredei threadlogici: iBehaviour. I Behaviour racchiudonosingoli compiti dell’agenteesi basanosuuncooperativemultithreadinggestitodagliagenti.In uncertosensohannoil compi-to di racchiudereistruzioninon interrompibili (seBehaviour semplici)e definiredove un agentepuo lasciarespazioad un altro agente.Nella libreria JADE so-no forniti diversi tipi di Behaviour, di volta in volta a secondadelle esigenzesipuo sceglierequaletipo di Behaviour fra quelli presentinellagerarchiadi classiillustratain figura4.6siail piu adattoadesprimereun certocompito.

Dettagliamole caratteristichedelletipologiedi Behaviour contenutinellage-rarchia.

11Il time-slicing permettedi riapplicarel’algoritmo di schedulazioneindipendentementedalfattocheil threadabbiafinito di utilizzareil processore.

101

Behaviour

+action()+done()+onStart()+onEnd()+block()+restart()

CompositeBehaviour

SimpleBehaviour

OneShotBehaviour CycleBehaviour

SequentialBehaviour

+addSubBehaviour()

ParallelBehaviour

+addSubBehaviour()

FMSBehaviour

+addSubBehaviour()

Model complex taskwhose sub-task are executed sequentially

Model complex taskwhose sub-task are executed concurrently

Model complex taskwhose sub-task corrisponds to the activitiesperformed in the states of a Finite State Machines

Model an atomictask (its done() method returns true)

Model an cyclictask (its done() method returns false)

Model a generic task

Model a complex task i.e.a task that is made up bycomposing a number of other task

Model a simple task i.e.a task that is notcomposed of sub-tasks

0..*

Figura4.6: La gerarchiadeiBehaviour in JADE.

La classeBehaviour.

La classeBehaviour fornisceunabaseastrattasulla qualecostruiretutte le tipo-logie dei Behaviour. Per alcuni dei metodi definiti in questaclassee gia dataun’implementazione,peraltri solola segnatura.

action(): e un metodoastrattocherestituisceil programmatoreriempira con ilcodicecheesprimeil compitorappresentatodal Behaviour.

done(): e anch’essoun metodoastrattocheritorna true quandoil Behaviour haterminatoil suocompito.

onStart(): e un metodochepuo essereridefinito dall’utenteper indicarequaliistruzioni si debbanoeffettuareprima che il Behaviour vengamessonel-l’insiemedeiBehaviour in esecuzione(attivi).

onEnd(): e un metodoche puo essereridefinito dall’utenteper indicarequaliistruzioni si debbanoeffettuarealla fine di un Behaviour. Questometodovieneeseguito dopocheil Behaviour ha terminatola suaesecuzioneed estatotolto dall’insiemedei Behaviour in esecuzione.

restart(): e il metodochefa ripartireil Behaviour.

102

block(): e il metodochepermetteall’oggettoBehaviour di interrompersifino al-l’arrivo di unevento(es.unmessaggio).La chiamatadi questometodononimpedisceagli altri Behaviour dell’agentedi essereschedulati.Tutti i Be-haviour bloccatisonorischedulatiquandoun messaggioarriva. E possibilecheun oggettoBehaviour blocchisestessoperun tempolimitato espressoin millisecondi.Un Behaviour bloccatopuo riprenderela suaesecuzioneinunodi questitrecasi:

1. unmessaggioe ricevutodall’agenteacui il Behaviour appartiene;

2. il timeout specificatoal momentoin cui si e effettuato il blocco escaduto;

3. il metodorestart()vieneesplicitamenterichiamatosulBehaviour bloc-cato.

Si osservicomei Behaviour permettanoun controllodettagliatodel multi-taskingdell’agente.

Descriviamo le implementazionidella classeastrattaBehaviour inclusenella li-breriadi JADE.

SimpleBehaviour. Questaclasseastrattamodellai Behaviour sempliciedatomi-ci, ovverotutti queiBehaviour chesonocostituiti daistruzioni inscindibili.In questaclasseil metodoreset12 non fa nulla, mapuo essereridefinito senecessariodalleclassifiglie.

OneShotBehaviour. Questaclassemodellai comportamentichedevono essereeseguiti solounavolta,questotipo di Behaviour nonpuo esserebloccato.Ilmetododone()restituiscesempretrue13

CyclicBehaviour. E la classeastrattachedefinisceun comportamentoatomicochedeveessererieseguito in continuazione.

CompositeBehaviour. Questaclasseastrattamodellai Behaviour chesonocom-postidauncertonumerodi Behaviour figli. Le operazionichedeveeseguireunBehaviour di questotipo nonsonoscritteall’internodelBehaviour prin-cipalema dentroai Behaviour figli. La classedefinisceun’iterfacciapergestirei sotto-comportamenti(SubBehaviour) manonimplementanessuna

12Nella documentazioneche abbiamoconsultatonon e spiegato precisamentequale sia ilcompitodelmetodoreset,supponiamochesiail metodocherinizializzalo statodeiBehaviour.

13Da cio chesi e potuto intuire, il metododone()restituiscesempretrue perche non essendoquestotipo di Behaviour bloccabilequandovieneattivatola primaoperazioneeseguitae l’action eil metododonepuo essereeseguitosolodopochel’action haterminatola suaesecuzione.In altreparolequestoBehaviour nonnecessitamaidi essererischedulato.

103

politica di schedulazioneper essi. Tale compito e lasciatoalle classicheestendonola CompositeBehaviour.

SequentialBehaviour. E unadelleclassipredefinitechefornisceunapolitica dischedulazioneperi subBehaviour di tipo sequenziale.Terminaquandotuttii sottoBehaviour sonoterminati. Questaclassepuo essereutilizzataquan-do si hannodiversi insiemi di passiatomici chedevono essereeseguiti insequenza.

ParallelBehaviour. Questaclasseeseguei subBehaviour concorrentementeeter-minaquandounaparticolarecondizioneneisuoisottocomportamentie rag-giunta. Si possonodefinire comportamentidi questotipo che terminanoquandotutti i sottocomportamenti,oppureuncertonumerodi sottocompor-tamentidefinitodall’utente,sonoterminati.Questaclassepuo essereutiliz-zatanelcasoin cui uncompitopossaessereformulatoin uncertonumerodisottocompitialternativi con qualchecodizionedi terminazionedipendentedalleconfigurazionidi terminazionedeisottocompiti.

FSMBehaviour. Questaclasseeseguei sottocomportamentiin accordoconunamacchinaastatifiniti definitadell’utente.Ognifiglio rappresentaun’attivitachepuo essereeseguitadentroadunostatoel’utentedefiniscele transizionitra gli statidellamacchinaa statifiniti. Quandoun stato ��� e completatoilsuovaloreerestituitodalmetodoonEnd()epuo essereusatoperselezionarela transizioneda seguire e di conseguenzail prossimostato ������� . Alcunidei comportamentifigli possonoessereregistrati comestati finali, dopolacui esecuzioneil Behaviour termina. Perunadescrizionepiu completailmanualeper i programmatori[6] di JADE rimandaalla documentazionedelleAPI.

L’ar chitettura degli agentiJADE.

In figura4.7illustriamoquellachepotrebbeconsiderarsil’architetturadegli agentiJADE, nel seguito descriviamogli elementidi cui si compone.

Schedulerof behaviour: e lo schedulerdeiBehaviour chevieneereditatoesten-dendola classeagent,abbiamospiegatocomeessosi basisuil cooperativescheduling.

Privatemessageinbox: contienei messaggichesonoarrivati all’agente.Abbia-mo gia descrittole primitive di ricezionechepermettonodi interagireconessa.

104

beliefs

patte

rn m

atch

ing

Tim

eout

bas

ed

bloc

king

-bas

ed

polli

ng-b

ased

���� �� ��

Application dependant

agent resources

Beh

avio

ur 1

Beh

avio

ur 2

Beh

avio

ur n

litiescapabi-

agent behaviours(i.e. Agent intentions)

Active

Scheduler ofbehaviours

Life-cyclemanager

Access mode

Private inbox of ACL messages

Figura4.7: Architetturadegli agentiJADE.

Life-cycle manager: e la componenteche forniscealla platform i metodi pergestireil ciclo di vita dell’agente.

Activeagentbehaviour: e l’insiemedeicomportamentidell’agentein esecuzio-ne(schedulati).

Application dependentagentresouce: le componentifornitedaiprogrammato-ri degli agentiJADE adesempio,le strutturedatinecessarieagli agentipersvolgerei compiti peri quali sonostatiprogettati.

Vorremmochesi osservassechequestaarchitetturae in qualchemanieraunameta-archietturaperagenti.Nella progettazionedi JADE gli sviluppatorihannocercatodi non fareassunzionicirca l’architetturaperagentida utilizzarsi. Tuttele componentichesonopresenti,sononecessarieperassicurareil correttofunzio-namentodell’agenteunavolta inseritonella platform JADE. In particolarel’or-ganizzazionea Behaviour dei compiti dell’agentee stataintrodottaper far fronteal multithreadingofferto da Java ed i limiti al numerodi agentisupportati.Glistessiautori del tool fannoosservarein [8] cheil modellodi agenteda loro rea-lizzato e un modellomolto generalechepuo esserefacilmentespecializzatoperimplementarearchitetturereattiveo BDI. Questacaratteristicadi JADE ci hafattorifletteresullapossibilitadi sfruttareil tool persviluppareil nostroD-CaseLP. InD-CaseLP avevamosuppostodi lavoraresuunmodellodi architetturaperagen-ti generalee condiviso dallevarie architetturepresentiin letteratura.Perquesto

105

motivo, avevamoipotizzatochegli agentiavesserounamailboxprivataal qualeaccedesseroconle primitivedi comunicazionedanoi individuate.Seconfrontia-motalemodelloconil modellodi architetturaadottatoin JADE ci rendiamocontocheil secondomantienele ipotesidanoi fattee potrebbeesserevisto comeunaspecializzazionedellanostraarchitetturain cui si tienecontodeivincoli introdottidai limiti delmultithreadingoffertodaJava.

4.3 ImplementazioneattravesoJADE di D-CaseLP

In questasezionecercheremodi analizzarein chemodosi possautilizzareJA-DE perla realizzazionedel tool D-CaseLP. Illustreremocomepotrebberoessereottenutii punti del sottoinsiemedel FRT iniziale presentatoin figura2.3, “arric-chito” comeillustrato in figura 4.1. Una volta illustrato il supportoofferto daJADE perla realizzazionedei punti funzionalicontenutinel FRT, evidenzieremole ipotesisottole quali sara possibilel’impiegodi JADE ai nostriscopi.

4.3.1 Comerealizzare conJADE i punti del FRT

Vediamonel dettaglioil supportoche JADE ci offre per la realizzazionedellesingolefunzionalitadi D-CaseLP.

Documentazioneper l’installazione e utilizzo.

Abbiamogia fattonotarequantosiaimportanteprodurredelladocumentazionesesi vuole cheil tool da noi realizzatotrovi impiego al di fuori del nostrogruppodi lavoro. L’installazionee l’impiego di JADE e illustrato in duedocumentiincontinuoaggiornamento:un manualeper l’amministratore[5] edun manuleperil programmatore[6]. Nel primo vengonotrattatele questionirelative all’instal-lazione,configurazione,edesecuzionedel tool, fornendounadescrizionesuco-mecambiarel’implementazionedel trasporto(il FIPA transport)o la codificadeimessagginell’esecuzionedella platform. Il secondoillustra comeprogrammareagentiin JADE, dettagliandoalcuniaspettidescrittinellasezioneprecedenteconesempidi codice. Comeavevamogia previsto sel’implementazionefossestatarealizzatain CORBA, si puo fareampioriferimentoaquestadocumentazionepergli aspettichesonogia statisviluppati:usotool, start-up,eccetera.

Supporto alla comunicazione.

Analogamentea cio cheabbiamofattoper illustrarel’ipotesi d’implementazionein CORBA, illustriamo le ideesu comesfruttaregli strumentiofferti da JADEperrealizzarel’interfacciadi comunicazionepresentatain 1.1.

106

Nel framework D-CaseLP abbiamoprevisto duetipologiedi agenti:gli Ag-Prolog e gli Ag-Java. Se non ci preoccupiamodelle differenzeche l’utilizzodi Java e Prolog introducononell’implementazionedell’interfacciadi comuni-cazionenonci sonograndiproblemialla realizzazionedell’interfacciain terminidi funzionalita JADE. Infatti, a parteunaconversionefra i parametri,e possibi-le implementarele primitive D-CaseLP in termini di quelleoffertedalla classeAgentdi JADE ( si vedala presentazionedelleprimitive fattain sezione4.2.2).La conversionedei parametriconsistera nel tradurremessaggio patterndi mes-saggiFIPA ACL espressicomestringhein oggetti su cui chiamarele primitiveJADE. Nelle librerie di JADE esisteunaclasseACLParserchepermettedi farel’analisi sintatticaper messaggiFIPA ACL su unastringaed ottenereun ogget-to di tipo ACLMessage14, mentrenon sembraesistereun metodoche dato unmessaggio(pattern)parzialmenteistanziatoFIPA ACL in forma di stringaresti-tuiscail MessageTemplatecon gli stessicampifissati. Senonsi vuoleavereunpatternmatchingtroppoelaborato,in cui adesempioper lo stessocamposi pos-sanoesprimerepiu possibili valori e ci si limita adun patternmatchingin cui loschemaprevedel’indicazionedi unsolovaloreperognicampopossiamopensaredi implemetaredanoi un metodostaticoACLtoMessageTemplatedi unaclasseDCaseLPTool e realizzarel’interfacciacomesegue:

send(msg). l’agentechevuolespedireil messaggiorichiamala primitiva di JA-DE send. Il parametromsg e una stringache rappresentaun messaggioFIPA ACL. La stringavienetradottain un oggettodi classeACLMessageprontoperesserepassatocomeargomentoallaprimitivasenddi JADE. Tut-to il restodellacomunicazionee gestitoin modotrasparentedallaplatformJADE in aderenzaalle specificheFIPA.

receive sync(msg). Il parametromsg e una stringache esprimelo schemasulqualevogliamoapplicareil patternmatching.Applicchiamoalla stringailmetododanoi implementatoACLtoMessageTemplateottenendoun JADEMessageTemplateechiamiamola blocking receive() suquestooggetto.

receive async(msg).Stessaimplementazionedellaprimitiva bloccantesolo cheinvecechechiamarela primitivaJADE blocking receive()chiamiamosem-plicementela receive().

Facciamoosservare che requisitoa che si possaaccederealle primitive dicomunicazionedefinite nella classeAgent delle API JADE e che gli agentidiD-CaseLP sianoestensionidi taleclasse.

14La conversionedaoggettimessaggioFIPA ACL a stringhenoncreaproblemiin quantonellaclasseACLMessagee statoridefinito il metodotoString().Questometodopermettedi ottenerelacodificain stringadell’oggettoa cui appartiene.

107

Diamo unadefinizionepiu precisadi comesi potrebberealizzareil metodoACLtoMessageTemplate.La primacosacheci serveeunformatoin cui esprime-re il pattern,ispirandocialla rappresentazionein formadi stringhedei messaggiFIPA ACL abbiamodecisodi utilizzareil seguente:

(:nomecampo1 valorecampo1,... ,:n-esimo-nomecampo n-esimo-valorecampo)

Strutturiamoil patterncomeunatupla di coppiein cui la prima parteiniziacon il carattere“:” ed e seguita dal nomedel campoper cui si stafissandounvalore,dopodi cheuno spaziocon in valoreal qualesi stafissandoil pattern.Abbiamoconvenutocheil simbolo* o l’assenzadel relativo campoindichinochenon si intendevincolarealcunvalore. Le andatea caponell’esempionon sonosignificativeper il formatochestiamoesprimendohannoil soloscopodi renderepiu leggibile la descrizione.Ad esempio,supponiamodi avereunastringachecontienela codificadelpatterncomeil seguente:

(:sender pippo, :performative *)

Talestringaesprimeunpatternin cui si hannocomeselezionabilitutti i messaggiil cui mittentee “pippo”, conunaperformativequalsiasi.Inoltre,visto chenonsisonospecificatii valori pertutti gli altri nomicampononsi esprimealcunvincolosudi essi. Illustriamol’algoritmo chesi puo seguireper implementareil metodostaticoACLtoMessageTemplate di conversioneda un patternin forma testualeadun oggettodi classeMessageTemplate:

1. inizializziamounoggetto� di classeMessageTemplatesenzaalcunivinco-lo sui campidi cui si puo comporreun messaggioFIPA ACL, equivalenteal patternchee compatibilecontutti i messaggi;

2. consideriamola stringain input, secontieneun messaggiovuoto o in cuitutti i campicontengonoil carattere* ritorniamol’oggetto � ;

3. fino a quandoil messaggionon e vuoto consideriamoil prossimoidentifi-catoredelcampo(es.:sender)e la costantecherappresentail valoredi quelcamponelpatterndi messaggio(es.unAID di unagente);

4. nel casocheil valoreper quel camposia * si va avanti nell’esaminarelastringa;

5. nel casoin cui il valoresia specificatosi aggiungecon l’appositometodoal pattern� il vincolo sul campo.Nella classeMessageTemplateesisteunmetodocheaggiungeperogni campodi cui si puo comporreun messaggioFIPA ACL un vincoloperun determinatovalore.Si ritornaal passodue.

108

Comunicazionevia MTS eDir ectory NameService (FIPA)

Unavolta chesi sonoimplementatele primitivedi comunicazioneD-CaseLP intermini di quelleofferte da JADE si ha accessoai servizi di MTS. Ricordiamoinfatti cheil trasportosulqualeespeditoil messaggioeassolutamentetrasparenteagli agenti,ede tutto gestitodallaplatform. Pocoimportachea farele chiamatesianogli agentiD-CaseLP “travestiti15” da agentiJADE. In manieraanalogapossiamoragionareper i servizi di directory nameserviceo quant‘altro. Nonsara necessariochegli agentiD-CaseLP utilizzino particolari stratagemmiperinterfacciarsiall’AMS o al directoryfacilitator, sonoinfatti in gradodi interagiretramitespedizionedi messaggie utilizzarele ontologiestandardpereffettuarelerichiesteallecomponenti.

Comedistrib uir e gli agenti edove recuperare il codicedegli agenti.

Quellochevorremmoeavereunaconsolecheci permettadi distribuiregli agentisu diversemacchine,indicandoper ogni agentequalecodiceeseguire. QuestefunzionalitasonoparzialmentesupportatedaJADE.

AbbiamospiegatocheJADE offre la possibilitadi far giraregli agentisuunaplatformdistribuitacompostadaunmain-containeredapiu containerdislocatisumacchinedifferenti. Cio percui nonvi e supportosonole operazionidi start-updei containerremoti. Percrearele parti cheandrannoa comporrela nostraplat-form distribuita e necessarioaccederein localealla macchinasullaqualesi vuolfarpartirel’istanzadi containero main-containeredeseguiredalineadi comandol’istruzione relativa. Questosignificachesevogliamoeseguireunaplatformdi-stribuitasuduemacchinedi nomerispettivamentehostname1e hostname2,avre-mobisognodi collegarciallaprimadelledueedattivareil main-containerconuncomandodel tipo

java jade.Boot -gui -host hostname1

e successivamentecollegarci in remoto sul secondocalcolatorehostname2edeseguireil comando

java jade.Boot -container -host hostname1

cheattiverail secondocontainer. Nel primocomandol’opzione-gui attival’agen-teRemoteMonitoringAgent(RMA) cheoffre l’interfacciagraficaperil controllodi tutta la platform,mentrel’opzione-hostspecificail nomedel hostsucui deve

15Con questoterminesottointendiamoche gli agentiD-CaseLP implementanol’interfacciadegli agentiJADE e la platformnone in gradodi distingueresestagestendoun agenteJADE oun agenteD-CaseLP

109

essereattivatoil main-container16. Nel secondo,l’opzione-containerspecificachesi staattivandoun containermentre-hostindicasuqualemacchinae in esecuzio-neil main-containeral qualeunire il containerchestiamoattivando.In entrambii comandivieneeseguitala classeJava “Boot”, appartenenteal package“jade”.

Si osserviquindi cheper attivarele platform remotamentesi fa affidamentoai servizi offerti dal sistemaoperativo quali eventuali telnet, sshe simili. Unavolta che i containersonoattivati JADE offre tutti gli strumentiper attivare econtrollareagentiremoti. Gli agentisi possonofar partiresiaal momentoin cuisi attivanole variecomponentidellaplatformattraversoappositiopzionidalineadi comandosiadainterfacciagraficain unsecondomomento.A titolo di esempiofacciamovederecomesi attiva da linea di comandoun agentedi nome“pippo”al qualevieneassociatoil codiceJava dellaclasse“primo” suun main-containerchedovrapartiresu“hostname1”:

java jade.Boot -gui -host hostname1 pippo:primo

Visualizzazionedellecomunicazionifra gli agenti.

Perquestafunzionalita c‘e supportoattraversoquellochee lo Sniffer agent,checomeabbiamobrevementeillustrato nella presentazionedi JADE offre tutte lefunzionalita graficheperspiarele comunicazionetra gli agenti,anzi,permettediselezionarequali sorvegliarefra tutti gli agentipresentinelMAS.

4.3.2 Ipotesi per l’utilizzo di JADE in D-CaseLP

Evidenziamole ipotesi in partetaciutedurantela presentazionedella realizza-zione dei punti del FRT che sono necessariealla effettiva realizzazionedelladistribuzionedegli agentiAg-Prolog edAg-Java.

Estensionedella classeAgent di JADE. La prima ipotesi necessariaper poterintegraregli agentisupportatida D-CaseLP con gli strumentiofferti daJADE echegli agentiD-CaseLP implementinola stessainterfacciaoffertadagli agentiJADE. In questomodo,senonsi contravvieneal principio diinformationhiding e andandoa romperel’oggettopervederecomesi sonoimplementatele funzionalita, gli agentiAg-Java o Ag-Prolog risultanointutto pertuttoequivalentiagli agentiJADE.

Ar chitettura degli agenti in termini di Behaviour. La secondaipotesiconsistenel poterstrutturaregli agentiD-CaseLP in Behaviour. Si e gia avuto mo-do di illustrarele motivazionichestannodietro la sceltadi organizzaregli

16Il parametro-hostper l’attivazionedi main-containerepuo anchenonesserespecificato.Intal caso,la platformvieneattivatasul hostindicatodallavariabiledi sistemaLocalHost.

110

agentiJADE in Behaviour. Sesi vuolechegli agentiD-CaseLP sianoese-guiti concorrentemente,enecessariostrutturareanchegli agentiAg-PrologeAg-Java in termini di Behaviour.

Il modo piu sempliceper realizzarela prima ipotesi e progettaregli agentiD-CaseLP comeestensionedella classeAgent, riservandosieventualmentedisovrascriverel’implementazionedi alcunedelle operazionioriginali della corri-spondenteiterfaccia. Questaipotesi evidenziaun primo problemaper l’imple-mentazionedegli agentiAg-Prolog. Infatti, mentree abbastanzasemplicepro-gettaredegli agentiAg-Java chesianoestensionedellaclasseAgent,none cosınel casodegli agentiAg-Prolog, senonaltro perche il concettodi ereditarieta edestensionedi classee supportatodal paradigmaad agentie non dal paradigmalogico. Il problemasara affrontatopiu dettagliatamentenel prossimocapitolo,ilqualetrattera la progettazionedell’integrazionetraagentilogici Ag-Prolog eJA-DE. Perquantoriguardala secondaipotesivorremmoribadireancoraunavoltachenonvi sonograndialternativeperottenerela concorrenzadegli agentisottoleipotesifatte. In unodei primi articoli chetrattanodi JADE gli autori segnalanola possibilita di implementarealtrepoliticheper lo schedulingdei Behaviour. Inparticolareaccennanoallapossibilitadi implemetareunoschedulingdi Behaviourinterrompibili. Questoimplicherebberisponderealmenoalle seguentidomande.

� Comerappresentarelo statodei Behaviour?

� Qualepolitica di schedulazioneperl’interruzione?

� E possibilesfruttarealcuneimplementazionidella JVM chesonopensateperutilizzarei threaddi sistema?

A partela complessita legataalla rappresentazionedellostatodell’esecuzionedeiBehaviour chepotrebberoesserein parterisolti conl’ausilio dellaserializzazione,ci sembrava che la risoluzionedi questeproblematicheaffrontasseroquestionichevannobenoltre questatesi. Non c’e statoil tempodi approfondirequestasoluzione,chesepercorribilecomportaundiscretamolelavoro.

Ricordiamocheabbiamoesplicitamentesuppostocheil tool D-CaseLP

1. possadaresupportosudiversepiattaforme;

2. non facciaipotesi tropporestrittive sul tipo di architetturaper agentechevieneadottata,in particolarenonfissialcunaarchitettura;

3. offra strumentiperil controlloe il monitoringdegli agenti.

Allo statodellecosel’ipotesi unogiustifical’impiego di Java comelinguag-gio d’implementazionedel tool, questosignificanon poter fareaffidamentosui

111

serviziper il multithreadingofferti dal singoloprocessoremasuquelli forniti daun’astrazionecomequella fornita dalla Java Virtual Machine. Osserviamochele ipotesiduee tre esprimonoesigenzechepotrebberoconsiderarsiin contrasto:daunaparteabbiamobisognodi avereunacertaliberta nellasceltadell’architet-tura di cui dotarei nostri agenti,dall’altra ci farebbecomodosaperecomesonofatti dentroper monitorarnee controllarneil comportamento,il tutto per rende-re semplici le cosecon i limiti imposti dall’ipotesi uno. Non e possibilediresela soluzionerappresentatadall’utilizzo dei Behaviour sia la soluzioneottima,senzaaddentrarcitroppo in considerazioneepistemologicheci sembradi poterconsiderarel’architetturaaBehaviour unbuoncompromesso.

4.3.3 Gli agentiAg-Java

Concentriamociorasull’impattochele dueipotesiprecedentihannonelladefini-zionedegli agentiAg-Java. Abbiamocapitochedovrannofornire la stessainter-facciadegli agentiJADE edessereorganizzatiin Behaviour, a questopuntounosi potrebbechiedereperchenonsi faccianocoincideregli agentiAg-Java congliagentinativi di JADE. La questionenonecosı semplice:bisognaindividuarepiuprecisamentequali sonoi requisiti necessariper potereffettuareunatraduzionesemiautomaticadaAg-UML agli agentiAg-Java.

Lo studiodi questeproblematichesara trattatonei lavori successivi a questo,attualmenteperalcuniaspettisonooggettodei lavori di StefanoMiglia eAlessan-droRolando.In particolaresi stavalutandosela traduzionedellespecifichepossaessereeffettuataa partiredaunalibreria di specifichedi componentibasilari(es.interactionprotocol,architettureperagenti,ecc),di cui si haunaimplementazio-ne.Secosı fossepartedellalibreriadi JADE potrebbetornareutile perarricchirela libreria di componentidi D-CaseLP, ma prima decideredi far confluiregliagentiAg-Java negli agentiJADE e necessariovalutareattentamentel’impattochecio hasulleipotesiedi requisitidi D-CaseLP.

4.3.4 Gli agentiAg-Prolog

Gli agentilogici soggiacionoagli stessivincoli degli agentiAg-Java, tratteremonel prossimocapitolo lo studio del designdi tali agentidandounadescrizionedettagliatadi comesi possanoimplementareagentibasatisul paradigmalogico.Cio cheanticipiamofin daora e la possibilita di far interagireJava e Prolog edincapsularedelcodiceProlog all’internodegli agentiJADE.

112

4.3.5 Iter dagli agenti prototipali all’esecuzioneusandoJADE

In figura4.8 abbiamoriportatolo schemadell’iter chepermettera a partiredagliagentiprototipalidi ottenerel’esecuzionesurun-timeJADE.

Confrontandoquestoschemacon quello fornito in figura 1.8 si puo notarecheil primo e sostanzialmenteun’instanzadel secondo.Le modificheapportateconsistononel aver sostituitocio cheera indicatocomeil run-timeD-CaseLPconil run-timeofferto daJADE. In conseguenzadi questasostituzionela fasedipreproccessingconsisteranell’includerein scheletridi agentiJADE danoi fornitiil codicechesi trovanegli Ag-Prolog edAg-Java.

Allo statoattualeprevediamochela libreria di scheletridi agentidovra con-tenereunoscheletropergli agentiAg-Prolog edunopergli agentiAg-Java, inmodochea partiredalle informazionisullo statoiniziale, il programe l’enginedegli agentiprototipalisiapossibileistanziarei rispettivi agentiJADE.

4.4 Confronto tra JADE e CORBA

In figura4.9,utilizzandounatabellaabbiamoriportatole funzionalitaappartenen-ti al functionrefinementtreecheavevamocostruitoin fasedi analisiper la partedi tool relativa la distribuzionee l’esecuzionedegli agentiprototipali. Abbia-mo cercatodi evidenziareil supportofornito daJADE e daCORBA perognunadelle funzionalita cheprevediamodi realizzarenella prima implementazionediD-CaseLP.

Abbiamopreparatounasecondatabella(figura 4.10)per le funzionalita chenon sonoinclusi negli intenti di prima realizzazionedi D-CaseLP ma chepo-trebberoessereinclusenelleversionisuccessivee per le quali JADE offre gia unsupporto.

Le duetabelleevidenzianola distanzacheintercorretraCORBA eJADE. Ve-diamodi illustrarele considerazionidi “progetto”checi hannoaiutatoadoperarela sceltain manieradefinitiva.

ConsiderazionisuJADE.

JADE e un tool piu evolutoecompletodi quellochepotramaiessereD-CaseLPconl’attualeforzalavoro. Negli scopidi questatesie negli obiettivi del progettoin cui e inseritaquestatesi,nonvi e tantol’interessea fornireun nuovo ambientechecompetacon i tool esistenti,quantopermetterela distribuzionedegli agentiAg-Prolog e Ag-Java risultantidall’applicazionedellametodologiaM-CaseLPchee in via di definizionenel lavoro inerentela primapartedel FRT illustrato insezione1.3.4.

113

Ag-UML Agent M-CaseLP

D-CaseLp

for simulation / execution

Agent Preprocessing

Prototyping Agents

Mas Execution

and Simulation

Improvement steps

PreproccessingAgent

Executable Agents COMPILER

JAVA

Gui

toolSimulation

Run-TimeJADE

JADEAGENT

Ag-Java

YES

NO

Ag-Prolog

Ag-Prolog Change

or\andAg-Java

Parameter

are needed ?New changes

MAS and AgentSimulation

Figura 4.8: Dettaglio sulla l’iter di esecuzionedel progettoD-CaseLP conl’ausilio di JADE.

114

Supportoper l’installazionedegli strumentiofferti da D-CaseLPFunzionalita JADE CORBADocumentazione perl’installazione

disponibile per even-tuali riferimenti ladocumentazioned’in-stallazione/utilizzoperil programmatore

disponibile per even-tuali riferimenti ladocumentazioned’in-stallazione/utilizzoperil programmatore

Supportoper l’implementazionedel prototipoMASFunzionalita JADE CORBASupportoalla comuni-cazione

peer-to-peer, FIPAcompatibile

client-server

Directory Name Ser-vice (FIPA)

supportatocon AMSsecondole specificheFIPA

possibile utilizzo deiservizidi CosName

Comunicazione viaMTS (FIPA)

implementato,con uncerto numerodi MTSgia realizzati

nessunsupporto

Supportoal monitoraggio econtrollo degli agentiFunzionalita JADE CORBAConfigurazione delladistribuzione degliagenti

disponibile, una voltachesi sonofatti parti-re i platformcontainerdistribuiti

nessuna

Indicazione su doverecuperare il codicedegli agenti

disponibile,conpossi-bilit a di associareunnome all’agente(vi eimplicitamenteil sup-portoperil concettodiclassedi agente)

nessuna

Visualizzazione dellecomunicazionifra gliagenti

fornita attraverso loSniffer Agent

nessuna

Figura4.9: Confrontotra il supportooffertodaJADE eCORBA.

115

Supportoper l’implementazionedel prototipoMASFunzionalita JADE CORBAIntegrazione semanti-ca

supportale ontologie nessuna

Supportoallamobilita disponibile nessuna

Figura4.10:Confrontotra il supportooffertodaJADE eCORBA sufunzionalitacheprotrebberoessereinclusein un futuro prossimo.

Si tengapresentenessunadellespecifichefino adoraprodottedallaFIPA haraggiuntolo statusdi “standard”,comeabbiamogia osservatoi documentichesitrovanoin fasepiu avanzatasononellafase“experimental”quindiancorasoggettiamoltevariazioni.Manteneretracciadellevariazioniedimplemetarele modificheprescrittedainuovi documentinone ipotizzabileconl’attualeforzalavorodi cui ilgruppodispone.Adottandogli strumentidaterzi il problemadegli aggiornamentirispettole specificheFIPA ricadeper la maggiorpartesul gruppoche fornisceJADE.

JADE non ha unametodologiapropriaed aderendoalle specificheFIPA vanelladirezionein cui si stamuovendoil nostrogruppo,fornendodellefacilitazio-ni chepermettanodi integrarefacilmentegli agentiprototipaliconl’implementa-zionedegli agentiin gradodi girarein JADE si puo effettivamenteavvicinareallametodologiaM-CaseLP adunpubblicopiu ampio.

L’adozionedi JADE ci manleva da un po’ di lavoro. Questoavvicina tem-poralmentela possibilitadi concentraregli sforzi del grupposulla traduzionese-miautomaticadi specificheed aspettipiu innovativi del tool relativi alla simula-zione.

4.5 Conclusione

Alla lucedi cio cherisultadalconfrontotra il supportofornitoci daJADE rispettoquellooffertodaCORBA, e tenutocontodellemotivazioniinerential progetto,cisembrachela sceltamigliore siaadottareunostrumentogia ampiamentetestato.Abbiamoquindi definitivamenteoptatoperJADE sposandocondiderazioniprag-matichevolte a non rifarelavoro chee gia statofatto da altri. E evidentechesisonoalcunequestioniapertesull’integrazionefra JADE egli agentiAg-Prolog edAg-Java. Comeoperarel’integrazionecongli agentiAg-Prolog sara specificatonel prossimocapitolo,mentreperpoterleggerecomesarannointegrati gli agen-ti Ag-Java sara necessarioaspettarela conclusionedei lavori svolti da StefanoMiglia edAlessandroRolando.

116

Capitolo 5

Agenti logici

In questocapitoloillustriamocomesiapossibileottenereagentilogici Ag-Prologche sianoeseguibili dalla platform JADE. Innanzi tutto daremounabreve ras-segnasulle implementazioniProlog cheoffrono la possibilita d’integrareJavae Prolog, ponendoparticolareattenzioneal framework tuProlog. Una volta in-dividuatal’implementazionea nostroavviso piu adatta,descriveremoattraversoalcuniusecasel’analisi dei requisitidi cui dobbiamofornire l’estensionecheper-mettera di eseguiregli Ag-Prolog in JADE. Perfinire daremoun classdiagramconil qualedescriveremole classinecessarieperotteneregli agentilogici.

5.1 Agenti logici in CaseLP.

Il tool di simulazioneCaseLP e interamenterealizzatoin Prolog edil paradigmalogico e utilizzato sia per programmarel’ enginecheesprimereil programdegliagenti.CaseLP offre alcunilinguaggidi specificachesi pongonoadiversilivellidi astrazione,ogni linguaggioe propostocomestrumentoper facilitareil lavorodell’utentenell’applicareunpassodellametodologiaproposta.Nel seguitodiamounabrevissimaintroduzioneai linguaggidisponibili in CaseLP ed il loro ruolosulla basedelleultime evoluzioni del lavoro illustratein [43]. Nel continuarelaletturasi tengapresentechela seguentepresentazionehal’obiettivo di dareun’i-deadelsupportofornito enonhala pretesadi spiegarein pocherighequellocheeun framework moltoarticolato,perunadescrizionecompletasi facciariferimentoanchea [66].

La metodologiadescrittain CaseLP individuaunutilizzo del tool chepossia-mopensaresuddiviso in quattrofasi.

Fase1: modellazione. In questafasepartendodallametodologiaillustratain se-zione1.2.3vengonodefiniti:

117

� i componentiindipendentidaldominio(Architettureperagenti,Ruoli,Ontologie)attraversolinguaggi di specificache comprendono �!"!"# ,HEMASL, UML;

� la strutturastaticadelMAS ovverocomele componentivengonomes-seinsiemeattraversoil linguaggioCaseLP-MASadl;

� la definizionedinamicadel MAS attraversola specificadello statoedelprogramdi ogni istanzadi agente.Perla definizionedelprogramedellostatodegli agentisonostatidefiniti diversilinguaggidi specifica.

Fase2: verifica e validazione. In questafasee possibileeffettuareverificaeva-lidazionedi proprieta chedevonoesseresoddisfattedal MAS attraversolecaratteristicheoffertedalparadigmalogico.

Fase3: implementazione. Dopocheil MAS e statocompletamentespecificatosia negli aspettistatici chenegli aspettidinamici lo sviluppatoredeve im-plementareun prototipo.La coerenzatra le fasidi specificaedil prototipoallo statoattualee responsabilita dello sviluppatore:nonsonostati ancorarealizzatitool automaticidi traduzionedellespecifiche.

Fase4: esecuzione.Il supportooffertodaCaseLP in questafasee legatoai stru-mentidi simulazione(CaseLP simulator) emonitoring(CaseLP visuali-zer) offerti dall’ambienteCaseLP.

Perognunadellefasiprecedentivienefornito o e statostudiatoun supportonellaformadi linguaggidi specifica,traduttoridaun linguaggioadunaltro e tools.

Diamounabrevissimaintroduzioneai linguaggichesonostatisviluppatinelcontestodel progetto.

5.1.1 ProlAg

Unavoltacheil MAS estatospecificatoenecessarioimplementarein unlinguag-gio omogeneole differenticomponenti.

Gli agenti CaseLP, devono in qualchemodo andarsiad interfacciareconl’ambientedi simulazione. E quindi necessarioprevedereun linguaggiodi im-plementazionein cui tradurreomogeneamentealmenole specificherelative allostatoedil programdegli agentiedimplementareil relativo engine.

L’ambientedi simulazioneedesecuzionedi CaseLP e statosviluppatoutiliz-zandoil paradigmalogicoinizialmentedandoneun’implementazionenel linguag-gio ECLiPSE [21], e successivamenteconSICStus Prolog [55].

ProlAg e definitocomelo standardProlog estesoconpredicatichepermetto-no aggiornamentodello statodell’agentein manierasafee predicatiperla comu-nicazionetraagenti.L’impiegodi ProlAg permettedi astrarredaquellechesono

118

le estensioniperla comunicazioneproprietariedi SICStus Prolog edECLiPSE,permettendoriutilizzare enginestatoe programdegli agentispecificatiindipen-dentementedall’implementazioneProlog chesi e utilizzata.

5.1.1.1 Predicati per modificare lo stato

assert state(Fact) asserisceFact nello statodell’agente. L’implementazioneeSafe, nel sensoche qualorail predicatoin cui viene effettuatala assertfallisse,il fattovienerimossodallostato.

retract state(Fact) rimuove il primo fattocheunificaconil Fact. AnchequestopredicatoeSafe, nel casoin cui il predicatoin cui vieneeffettuatala retractfallisse,il fattotolto verrebberiasserito.

5.1.1.2 Predicati per la comunicazione

sync receive(Message)bloccal’agentecheha effettuatola chiamatadi questopredicatofino a quandononarriva nellamailboxdell’agenteun messaggiocheunificaconMessage.

async receive one(Msg input,Msg output) ricercanellamailboxdell’agentecherichiamaquestopredicatoun messaggiocheunifichi conMsg input , seuncosiffattomessaggioepresentenellamailbox,vieneunificatoconMsg output,altrimentiMsg outputvieneunificatoconno message.

async receive all(List of message)prendetutti i messaggi,nella mailbox del-l’agentechiamante,e le unificanellalistaList of Message.

send(Receiver,Message)spedisceil Message dall’agentechiamanteall’agenteReceiver. In CaseLP questoera realizzatoutilizzandole primitive Safeperaggiornarelo statoasserendoil Messagenellamailboxdel Receiver.

Il linguaggio“target” del processodi traduzioneda specificheadalto livelloin specificheeseguibili e ProlAg, con essoe possibileesprimerel’engine degliagenti.

In figura5.1sonoschematizzatii linguaggiper il qualesi fornisceunatradu-zioneo un interpreteversoProlAg.

5.1.2 AgentRules

Questolinguaggiopermettedi specificareil comportamentodi unaclassedi agen-ti conregoledel tipo event-condition-actionperil comportamentoreattivo dell’a-genteo condition-actionper esprimereil comportamentoproattivo dell’agente.Combinandol’utilizzo deiduetipi di regoleepossibileesprimereagentiibridi.

119

Interface for Prolog Extension

SpecificationLanguages

εhhf

ProlAg

AgentRules

Sicstus EclipseCaseLPImplementation

Figura5.1: Uno schemaperla traduzionein codiceeseguibile daCaseLP.

AgentRules essendobasatosulla definizionedi regole e un linguaggiocheci permettedi specificareconfacilita lo statoedil programdi un agenteconunasintassiuser-friendly. Forniamoin figura5.2 la sintassiformaleaffinche siapos-sibile capirecomescriverele specificheutilizzandoAgentRules. Non e difficileimplementareunatraduzionedellespecificheAgentRules versoProlAg: si trattaessenzialmentedi riscrivere le regole cheabbiamoespressocon la sintassipre-sentataprima in predicatiProlAg. Cio cheotterremosara qualcosanella formaillustratain figura5.3.

Facciamonotareil risultatodellatraduzioneesuddivisain tresezioni:

Initial state: statoiniziale definito tramitefatti grounddel tipo fact(B), in cui iltermineB esprimeunacredenzabeliefdell’agente.

Program: programmadell’agentedefinitocomeuninsiemedi regoleevent-condition-action o condition-actionespresserispettivamentecon in predicatireacti-ve rule e proactive rule. Le regole vengonotradottesecondole associa-zioni indicatein tabella5.4.

Auxiliary predicates: sonoclausolecorrispondentia procedurechepossonoes-sereutilizzateperverificarecondizioniausiliarie.

Unavolta tradottele regoleenecessariocheci siaunprogrammachele interpreti.

Successivamentela traduzionedelle regole i predicatipotrannoessereinter-pretatidaunmeta-interpretesimileaquellodefinitodi seguito:

engine :-async_receive_one(Msg_input, Msg_output),{Msg_output== no_message -> actions1=[]

120

InitialState ::= nil $ BeliefsList

BeliefsList ::= Belief $ Belief; BeliefsList

Program ::= program InitialState ReactiveRulesList ProactiveRulesList endprogram

ReactiveRulesList ::= nil $ ReactiveRule $ ReactiveRule; ReactiveRulesList

ReactiveRule ::= on messageMsg checkCondition do ActionsList

ProactiveRulesList ::= nil $ ProactiveRule $ ProactiveRule; ProactiveRulesList

Msg ::= Performative % content: Content; sender: Sender; receiver:Receiver; &Condition ::= StateCondition and AuxiliaryCondition

StateCondition ::= true $ Goal

AuxiliaryCondition ::= true $ Goal

Goal ::= A $ A and Goal $ A or Goal

ProactiveRule ::= checkCondition do ActionsList

Action ::= assert state(Belief) $ retract state(Belief) $send(Msg, Receiver)

Figura5.2: SintassiformaleperAgentRules

%%%%%%%%%%%%%%%% Initial State %%%%%%%%%%%%%%%%%%%fact(B_1).fact(B_2).... ... ...fact(B_n).%%%%%%%%%%%%%%%%%%%% Program %%%%%%%%%%%%%%%%%%%%%reactive_rule(Message_1, Condition_1, Action_1).... ... ...reactive_rule(Message_m, Condition_m, Action_m).proactive_rule(Condition_m+1, Action_m+1).... ...proactive_rule(Condition_m+k, Action_m+k).%%%%%%%%%%%% Auxiliary predicates %%%%%%%%%%%%%%%%p_1(..):-... ... ...p_s(..):-

Figura5.3: La traduzionedelleistruzioniAgentRules.

121

RegolaAgentRules Predicatoon messageMessagecheckConditiondoActions

reactive rule(Message,Condition, Ac-tions)

checkConditiondo Actions proactive rule(Condition,Actions)

Figura5.4: Associazionetra regoleAgentRules epredicati

;select_reactive_rule(Msg_output, Actions1)),select_proactive_rule(Actions2),choose(Actions1, Actions2, Actions),execute(Actions).

Facciamoosservare che scrivere lo statoe il programin AgentRules, de-finirne la traduzionein ProlAg e fornire il meta-interprete,equivale a definireun’architetturaperagentilogici.

5.1.3 CaseLP-MASadl

E un linguaggiochepermettedi specificarel’architetturadel MAS, in particolarein CaseLP eranostateindividuateduetipologiedi agenti:

Logical Agent fornisconoil controlloelacoordinazionedeicomponentidelMAS,graziealle loro complessecapacita di ragionamento,

Interface Agent fornisconol’intefacciafra i moduliesterniegli agentidelMAS.

La sintassidel linguaggiopermetteva di specificarea qualedelledueclassiogniagenteappartenesse,le classidi agentipresentinelMAS e le relazionitradi esse,i servizi richiesti, forniti, il tipo di comportamentoassociataalla classedi agen-ti. Perunatrattazionepiu completasi consigliadi leggere[16], nel qualevieneillustrataanchela sintassidel linguaggioformalizzatain unaBNF.

5.1.4 ')(*(*+Il linguaggiologico lineare �!�!�# [19] e un linguaggioeseguibilepermodellaresi-stemiconcorrenticongestionedi risorsefinite basatosul linguaggioForum[44]. �!�!"# e un linguaggiobasatosulogicamultisetchecombinacaratteristichedi lin-guaggilogici estesicome , Prolog,cioe goalsconimplicazionee quantificazioneuniversalecon la nozionedi formule comerisorseche e alla basedella logicalineare.

122

5.1.5 HEMASL

HEMASL e un linguaggiodi specificaproceduraleperagentichepuo essereuti-lizzatoperdefinireunagenteadogni livello di astrazione.La sceltadi unlinguag-gio imperativo e statafattapoiche essoe maggiormentevicino alle conoscenzedello sviluppatoreindustriale,solitamentepocofamiliarecon il paradigmalogi-co. HEMASL si ponesulivelli similari di �!"!"# fornendounsistemacompletoperla specificadi unagente.

5.1.6 Il CaseLPVisualizer: un’interfaccia grafica per la simu-lazione

Il CaseLPVisualizer[50] fornisceunadocumentazionesugli eventi accadutialivello di agentedurantel’esecuzionedel MAS. In accordocoi bisognidello svi-luppatore,il codicedi unagentepuo essereautomaticamente“instrumentato”do-po chee statocaricato. La “Instrumentazione”aggiungedelle sondenel codicedell’agente;gli eventi correlatial cambiamentodi statoe/oai messaggiscambiatipossonoessereraccoltieregistratiperunesameon-lineo off-line. Sonofornitefi-nestregraficheperinizializzarela mailboxdegli agentio perfissaredeiparametridellasimulazione(lunghezza,granularitadellavisualizzazioneon line).

La figura5.5descrive la finestracheconsentel’inizializzazionedellamailboxdi un agente;la tracciaon-linedellaesecuzionee mostratain figura5.6 dove glieventi e lo statorelativi adogni agentevengonomostrati.La figura5.7mostralatracciadellaesecuzioneoff-line, coneventi e messaggimostratisulle lineeoriz-zontali(agenti),in corrispondenzadell’istantein cui accadono(dimensioneverti-cale,tempo). I dettaglidi ogni eventopossonoessereottenuticliccandovi sopra.La finestrachesi apree mostratain figura5.8. Durantela simulazionevengonomostratidati riguardantigli agenti“Instrumentati”.Al terminedellasimulazioneun tracciacompletadi tutti gli eventi chesonostatiselezionatipuo esserevisua-lizzata. La “Instrumentazione”e completamenteindipendentedall’esecuzione,equindi noninfluenzafuturi cambiamentidel supportodi esecuzione.

5.1.7 Comandi di shell per l’esecuzionedella simulazione

Selo sviluppatorepreferisceutilizzarecomanditestuali,egli puo utilizzareun in-siemedi primitivepereseguirela simulazione.Le primitivemesseadisposizionesono

� compile agent(List modules dynamic predicates files,List state files, List behaviour files, Agent name,Compiled file name):

123

Figura5.5: Finestraperl’inizializzazionedellemailboxes.

Figura5.6: finestrachedescrive l’esecuzioneon line.

124

Figura5.7: Tracciaoff-line delleesecuzioni.

Figura5.8: Dettaglidi uneventotracciato.

125

Il primo argomentoe unalista di files nei quali sonocontenutele dichia-razioni dei moduli esterniche l’agentedovra usaree la lista dei predicatidinamici.Il secondoargomentoe la lista dei files nei quali sonocontenutii fatti cherappresentanolo statoinizialedell’agente.Il terzoargomentoe la lista dei files checontengonole regole chegover-nanol’esecuzionedell’agente(e necessariodefinireil predicato“interpret”perogniagente,e tutti i predicatiausiliari).Il quartoargomentoe il nomedell’agente(le primitiveperinviaremessaggihannoun argomentochee il nomedell’agentea cui mandareil messaggio;talenomedeveessereunico).Il quintoargomento,infine, e il nomedel file cheverra generatoa seguitodi questoprocessodi compilazione.Tale file contieneil codicecompletodell’agente,e verra usatodal predicatoload quandol’agenteverra caricatonel sistema.

� load(File name, Agent name): carical’agentespecificatodal fileFile name,assegnandogliil nomeAgent name

� initialize(List of initial messages): inizializzale mailboxdegli agentidel sistema.

� global parameters(Iter, Min time unit, Out, Verbose):specificai parametridellasimulazione;Iter specificail numerodi iterazio-ni da eseguire nella simulazione,Min time unit specifical’unit a di tempobasedellasimulazioneossiala duratadi ciascunaiterazione,Out e il nomedel file in cui tutti i messaggiscambiativengonoregistrati, Verbosee unflagcheserveperdecideresetutti i messaggiscambiatinel sistemadevonoesseremostratiavideodurantela simulazione.

� net parameters(From ag, To ag, Fail rate, Min late,Max late, Unit): selezionai parametridi comunicazionetraognicop-pia di agentipresentinel sistema;From ag e To ag specificala coppiadiagenti,Fail ratespecificaquantimessaggisu 100.000.000sonopersiperproblemidi comunicazione,Min late e Max late e Unit specificanoil mi-nimo ed il massimotempodi ritardo sul canaleespressoin Unit. Seperuna coppia di agenti non sono specificatiparametrila comunicazioneeimmediatae totalmenteaffidabile.

� start simulation: e il comandochevieneutilizzatoperfar partirelasimulazione.La simulazionee eseguita tramiteunoschedulerround-robinchechiamail predicatocycledi tutti gli agenti.

126

� get statistics: e utilizzatoperraccoglieretuttele informazionisullasimulazionestessa.

5.2 Implementazioni Prolog

Primadi presentarela progettazionedegli agentilogici analizziamoalcunedelleimplementazioniProlog chesi trovanoin reteallo scopodi capirequali sonolepossibilita di integrazionitra Prolog e Java. NonostanteProlog siaunodei lin-guaggitradizionalidell’intelligenzaartificiale,dopola popolaritaacquisitaduran-tegli anni’80 coni progetticorrelatiallearchitetturedi quintagenerazionenonhatrovatomoltospaziofuori dagli ambientiaccademici.NavigandosulWorld WideWeb sembrachenegli ultimi anni ci sia un certo interessea fornire interpretiecompilatoriProlog in gradodi integrarefunzionalita logicheconcodiceJava. Intabella1 5.1abbiamoraccoltouncertonumerod’implementazioniProlog cercan-do di evidenziare,quali di essisonocompilatorie quali interpreti, in cheformasonoforniti i motori inferenzialisucui si basano(binario, libreria), il tipo di li-cenzaconcui e distribuito il software,l’esistenzao menodi unainterfacciaversoJava.

Name Type Licence Java interfaceSICStus Prolog [55] comp/bin commercial JasperSWI-Prolog [56] comp/bin freesoftware JPLbinprolog [9] comp commercial bidirectionalvia librarytuProlog* [57] int/lib freefor noprofit bidirectionalvia libraryJinni* [36] interpreter commercial buit-in (bidirectional)jprolog* [37] interpreter freesoftware JavacallsPrologGNU PROLOG [33] comp GPL none,(C only)MINERVA* [45] comp commercial built-in (bidirectional)

Tabella5.1: Confrontoimplementazionidi Prolog.

Peroperareunasceltain un insiemepiuttostoeterogeneodi implementazionidi Prolog, discutiamoqualicondizionidebbaoffrire l’implementazionecandidataall’impiego in D-CaseLP.

Disponibili a della implementazioneper diversi sistemioperativi: vistocheunadelle motivazionicheci aveva orientatoalla sceltadi Java comelinguag-gio d’implementazionedei tool danoi progettatierala possibilitadi fornire

1Abbreviamo compilatorecon comp, binario con bin, interpretecon int, libreria con lib,traduttorecontrad,l’asteriscoindicacheil linguaggiod’implementazionee Java.

127

strumentiindipendentidai particolari sistemioperativi, vorremmoevitared’introdurrevicoli sul tipo di macchinao sul sistemaoperativo utilizzatonell’integrazionefra Java eProlog.

Una interfaccia Java-Prolog bidir ezionale: pereseguiregli agentilogici in JA-DE avremobisognodi fareriferimentoa oggettiJava all’interno di codiceProlog e dimostrarepredicatiProlog all’interno del codiceJava. In par-ticolare, necessiteremodi un’interfacciada Java a Prolog per includeregli agentilogici negli agentidi JADE e dell’interfacciadaProlog a Javaper richiamarele primitive di comunicazioneofferte da JADE all’internodegli agentilogici. Questoimplica chegli strumenticon cui integreremoagentilogici e agentiJADE dovrannooffrire un’interfacciabidirezionaleProlog-Java.

Software con licenzadi utilizzo: essendoun progettoin ambitouniversitarioenostro interesseche il software, e le estensionida noi prodottesiano ilpiu possibileutilizzatee provateda altri. Prerequisitoaffinche questosiapossibile,e che il software abbiauna licenzache permettadi utilizzarlosenzatroppi oneri, almenonei casi in cui il suoimpiego non sia a fini dilucro. Questorequisitoal contrariodei precedentinone determinantenel-la sceltadell’implementazioneProlog ed e daconsiderarsisolocomeunapreferenza.

5.2.1 Tipi di interfacceProlog-Java

Abbiamogia evidenziatol’esigenzadi avereun’interfacciabidirezionaleProlog-Java, in questasezioneconfrontandola tecnologiaofferta dalle diverseimple-mentazionivorremmoentrareunpo’ piu neldettaglioin quellechesonole moda-lit a con cui l’integrazionevieneeffettuata.Analizzandole implementazionicheabbiamoelencatoin tabella5.1 e possibilerendersicontoche l’integrazionediPrologJava avvienesostanzialmenteperduestrade:

� attraversola ForeignLanguageInterface(FLI);

� utilizzandointerpretiscritti in Java.

Iniziamo con illustrare le caratteristichedella FLI. Le interfacceversoaltri lin-guaggiin Prolog sonovirtualmentedisponibili in tutte le implementazionicom-merciali,essepurdifferendoneiparticolarisi basanosull’ideadi associaredurantela fasedi linking un file oggettodel linguaggiochesi vuole integrareall’esegui-bile del motoreProlog. E generalmentepossibileancheil viceversa,quasituttele implementazionifornisconounalibreria con la qualee possibileaccedereal-le funzionalitadel motoreinferenzialedellaparticolareimplementazioneProlog.

128

Su questotipo di integrazionesonobasatele interfacceversoJava di SICStusProlog (Jasper) e di SWI-Prolog (JPL), ed in generaledi tutte le implemen-tazioni che fornisconoun compilatoreper il linguaggio. Sempreall’interno diquellachepotrebbeesserela filosofiavicina alle FLI vi sonoalcuneimplementa-zioni cheperintegrareProlog in Java utilizzanola la JavaNative Interface(JNI)la qualepermetted’includeredel codicenativo (C, C++). Tale espedienteper-mettedi recuperarelibrerie di integrazioneversoi motori Prolog cheeranostatepensateper il linguaggioC all’interno di Java. L’integrazioneconquestemoda-lit a, passandoper il codiceoggettoponedei limiti alla compatibilita consistemioperativi diversi da quelli in cui il codicee statocompilato,perdendodi fatto ivantaggidi portabilitadi Java. Inoltre,eseguendoalcunitestin SICStus PrologutilizzandoJasper, ci siamoaccortichele integrazionidi questotipo hannodeilimiti sul numerodi motori Prolog attivabili per processo.Sia Jasper cheJPLpermettonodi includereunsolo“motorelogico” perJVM, mentrenoi utilizzandoJADE avremmobisognodi un motorelogico perogni threadcherappresentaunagente.

La secondamodalita d’integrazionevedel’impiego di interpreti al postodicompilatori. In generalequestastradarisultapiu adattaai nostri scopiin quantooffre soluzioniportabili per l’integrazioneJavaProlog e nonsoffre dei limiti sulnumerodi istanzedi motori logici attivabili perprocessoo thread.

Ci sonosvariati interpretiProlog scritti in Java alcunidi essioffrono funzio-nalita d’integrazioneattraversoun’interfacciabidirezionaleassolutamenteporta-bile; noineabbiamoindividuatounochesembraparticolarmenteversatileelegge-ro: tuProlog.Le funzionalitaoffertedatuPrologperl’integrazionesonodiscussenellasezione5.2.2.

5.2.2 tuProlog.

Descriviamoin questasottosezionesullabasedelleinformazionicontenutein [20,2] le caratteristicheprincipali di tuProlog. tuProlog e statoprogettatocon treprincipali obiettivi:

� offrire unmotoreProlog minimale,efficienteeaderenteallespecificheISOin un oggettoJava accessibileconunasempliceinterfaccia;

� darelapossibilitadi estendereil nucleominimaledellinguaggioconlibreriedinamichecontenentinuovi predicati;

� offrire gli strumentiperpoterinteragireecontrollarel’interazioneconcom-ponentiInternet.

129

tuPrologoffre un interpreteProlog realizzatoper intero in Java che e sta-to ideatoappositamenteper costruirecomponenti“intelligenti” che sianofaci-li da utilizzare,leggeri,scalabili,staticamentee dinamicamenteconfigurabiliedinteroperanti.

L’interpreteviene fornito sotto forma di un motoreinferenzialeProlog chechiameremotuPrologVirtual Machine(VM). Ognimotoree istanzadi unaclasseJava. Il fatto che il motoreconsistain un oggettoJava permettedi avere unnumeropotenzialmenteillimitato di istanzeche possonoessereattivateda unostessoprocessoeventualmentesupiu thread.

Chiameremoil motoreconcaratteristicheminimali coretuProlog,ognimoto-re e configuratoindipendentementedagli altri ed a secondadelleparticolariesi-genzepuo essereintegratocon componentinon Prolog sotto forma di oggettoJava. Le componentituPrologpossonointeragireconaltrecomponentinonne-cessariamentelogiche attraversoil consuetoschemacomunicativo client-serverutilizzandostrumenticomeRMI e CORBA. In alternativa, e possibileutilizzareapproccidi comunicazionepeer-to-peerutilizzandounmodellodi comunicazioneablackboard2 in cui le componenticomunicanoaggiungendoe togliendotupleinunospaziocomune.Questotipo di comunicazionepuo risultareparticolarmenteversatileper coordinaree la favorire la cooperazionetra componenti,sianoesseoggettiJava o VM tuProlog.

IntegrazioneProlog- Java.

tuPrologoffre il supportoper integrarecodiceProlog all’interno di applicazioniJava edoggettiJava in programmiProlog.

Questaintegrazioneeessenzialmentebasatasul fattochei motori inferenzialidi tuPrologsonooggettiJava, non facendoriferimentoadalcuncodiceoggettonealle funzionalitadellaJavaNative Interfaceoffre unasoluzioneportabile.

Tramitel’integrazioneoffertale applicazioniJava possonosfruttareil potereespressivo del paradigmalogico per realizzarele parti “intelligenti” in modopiunaturalerispettocheconla solaprogrammazioneorientataagli oggetti.

Includere Prolog in Java.

Perabilitarel’accessoa tuPrologda Java vengonofornite un insiemedi classi,in modocheve ne siaunaper tutte le principali entita Prolog, adesempioi tipidi datostandardProlog vengonoassociatiadoggettidi classeTerm, le variabiliin oggettidi classeVar, i termini composti(funtori conargomenti)in oggettidiclasseCompound, le stringhevengonoassociatea Compound senzaargomenti.

2Tale modello di comunicazioneera offerto in Linda, una famosa estensioneper lacomunicazionefornita in alcuneimplementazionidi Prolog.

130

Theory theory1 = new Theory(new FileInputStream("test.pl"));String text = "append([],X,X). \n \n" +

"append([X|L1],L2,[X|L3]):-append(L1,L2,L3). \n \n";Theory theory2 = new Theory(new ByteArrayInputStream(text));

Figura5.9: Istanziamodueteoriein tuProlog.

public interface Prolog {void setTheory(Theory th)

throws InvalidTheoryException;Theory getTheory();void loadLibrary(String libname)

throws InvalidLibraryException;void unloadLibrary(String libname)

throws UnknownLibrary;SolveInfo solve(Term t);SolveInfo solve(String term)

throws MalformedGoalException;SolveInfo solveNext()

throws NoMoreSolutionException;}

Figura 5.10: Interfaccia per accedereagli oggetti rappresentantiil motoreinferenzialeProlog.

E possibilerappresentaredifferenti teoriecomeoggettidi classeTheory, questioggetti possonoesserecostruiti a partire da un file di testocontenentela defi-nizionedei predicatichesononella teoria. Nell’esempioillustrato in figura 5.9definiamoconalcuneistruzioniJava dueteorie: “theory1” a partiredaun file ditesto“test.pl” il qualeconterra la definizionedi alcuni predicatinon specificatinell’esempio,e “theory2” a partiredallastringa“text” contenentela definizionedelpredicatodi append.Le teoriechedefiniamoandrannoassociateadunmotoreProlog attraversol’interfacciadi figura5.10,cheforniscele operazioninecessa-rie a registrareunateoriaadun motore,caricareunanuove libreria, risolvereuntermine(goal)nel motoreedaccederealle soluzionisuccessivealla prima.

Le soluzionicalcolatedal motorelogico vengonorestituitecomeoggetticheimplementanol’interfacciaSolveInfo illustrata in figura 5.11. Una discussionepiu dettagliatadelleclassiedeimetodidisponibili si possonotrovareconsultandola documentazionedelleAPI tuProlog[58].

131

public interface SolveInfo {boolean success();boolean hasOpenAlternatives();Substitution getSubstitution()

throws NoSolutionException;Term getSolution()

throws NoSolutionException;boolean halt();int getHaltCode()

throws NoHaltException;}

Figura5.11: InterfacciaSolveInfo peraccederealle soluzioni.

Includere oggettiJava nel codiceProlog.

La possibilita di includerecomponentiJava all’interno del codiceProlog vienefornitadallaJavaLibrary, attraversodi essaepossibileincluderein unprogrammaProlog oggettiJava gia istanziati,istanziarnedi nuovi edaccedereai servizidaessi forniti. Vediamoi principali predicatidefiniti nella libreria e la rispettivaarieta:

java object/3 creaun nuovo oggettoJava istanziandolodaunaclassespecifica-ta, epossibileindicaregli argomentidel costruttore.Il riferimentoal nuovooggettovieneassociatoad un terminegroundattraversoil qualesi potrainteragireconl’oggetto.

- -/2 invoca un metodoindicato a destradel simbolo di predicatosull’oggettoJava rappresentatodall’identificatorea sinistradel simbolo di predicato.Conessoepossibileaccedereancheaattributi pubblici dell’oggetto.

returns/2 unificail valoreritornatodall’invocazionedi unmetodoJava contipodi ritorno differenteda“void” chesi trovasinistradel simbolodi predicatoconil termineProlog posizionatoa destradello stesso.

In figura 5.12 vi e un semplicissimoesempiodi un programmaProlog cheistanziaun oggettodallaclasse“Counter” associandoneil riferimentoadun ter-mine“myCounter”,quindivienerichiamatoil metodo“set” epoi unmetodo“get”il cui parametrodi ritornovieneunificatocon“X”, allafine “X” vienestampatoavideo.

Nell’esempioprecedentel’oggettoJava al qualeaccediamoe statoistanziatoall’interno del programmaProlog, invece,in alcuni casipuo essereutile acce-deread oggettiJava chesonostati precedentementeistanziati. Cio e possibile

132

java_object(‘tuprolog.demo.Counter’,[],myCounter),myCounter <- set(5),myCounter <- get returns X,write(X).

Figura5.12: Esempiodi programmaProlog cheistanziaed utilizza un oggettoJava.

graziealla funzionestaticaregister. Tale funzionee richiamabiledal lato Javaattraversola seguentesintassi:

JavaLibrary.register(Struct name, Object obj)

L’effettodi talefunzionee registrareunoggetto“obj” all’internodelmotorePro-log e renderloaccessibileattraversoil riferimento “name”. Nell’utilizzo dellaJavaLibrary si facciaattenzionein quantonon e possibileregistrarelo stessooggettoduevolte anchesecon nomi differenti. Gli oggettiout, in, error appar-tenentialla libreria staticajava.lang.Systemvengonoregistrati automaticamenterispettivamenteconnomi stdout,stdin,stderr.

Estensibilita attraversolibr erie.

Unacaratteristicaimportantedi tuProloge la capacita di gestireestensioniattra-versol’utilizzo delle librerie. Le librerie devonoesseretuttederivatedallaclassedefinitanel framework tuPrologLibrary , questoperassicurarechela libreriaab-bia le caratteristichechele assicurinol’interazionecon il core tuProlog. Tra lelibrerie chesonoattualmentefornite troviamo

MetaLibrary: forniscele primitive perconsultarele teorie,caricaree scaricarele libreria,generarenuovi processiProlog.

JavaLibrary: fornisceun’interfacciaper accedere,creare,e gestiregli oggettiJava dacodiceProlog.

IsoLibrary: forniscei predicatiProlog standardISO.

Vi sonoaltra librerie chepermettonodi accederea spazidi tuple,e infrastruttureInternet. Le tre librerie che abbiamocitato vengonocaricateautomaticamenteogni voltachesi istanziaun motoretuProlog.

tuProlog rispetto le altr e implementazioni.

Cio checi haspintoa scegliere tuPrologcomemotorelogico pergli agentisonoessenzialmenteduefattori:

133

� l’integrazionebidirezionaleeportabileconJava;

� unmotoreinferenzialescrittoin Java, minimaleedestensibileattraversolelibrerie;

tuProloge liberamentescaricabileall’indirizzo [57] in forma di classiJavacompilate,adettadegli autoriprestosara resopubblicoil codicesorgente.

Nel manualedi utilizzo [2] sonopresentatealcuneprovedi prestazione,dovesonoconfrontatituProloged altre implementazionitra cui Jinni e jprolog. Perquantolo studiosiapiuttostolimitato, le performanceottenuteda tuPrologsem-branocomparabiliconle altreimplementazioni,anzi,in alcunicasituPrologoffredelleprestazioniaddiritturamigliori.

Effettuatealcuneprove per prendereconfidenzacon il tool abbiamoavutomodo di renderciconto che il progettoe ancorain fasedi sviluppo: la stes-sa documentazionein rete e work in progress. Nonostantecio, ci sembrachetuPrologsiail tool cheoffreunbuonsupportoai nostriobiettivi edabbiamodecisod’impiegarloperrealizzarel’integrazioneJADE - Prolog.

5.3 Utilizzo degli agenti logici nel modellodi svilup-po D-CaseLP

Primadi passareall’analisi dell’estensionecheci permettera di far eseguireallaplatformJADE agentilogici, vorremmofornire alcuneideesul ruolo cheavran-no gli agentilogici nell’attivita di sviluppodel MAS. Abbiamoipotizzatochelosviluppoavvengaseguendoun ciclo di vita a spirale,cio implica la realizzazionedi uncertonumerodi prototipiallo scopodi raffinarei requisitie la progettazionedel sistemasottosviluppo.Supponiamodi suddividerei requisiti in diversiinsie-mi a secondadi quantoquestirequisiti sianoin relazionee per ogni insiemedisviluppareunprototipo,definiamoalcunedellerelazionichepossonointercorreretra i prototipi cheverrannosviluppati.

Definizione5.1 Presidueprototipi . e / appartenential processodi sviluppodiun sistema,diciamo

/ e raffinamento di . se / e unprototipoper lo stessosottoinsiemedi requisitidelsistemadi cui si occupa. , edalcunedellesoluzioneimplementatein /sonoadunlivello di dettaglio superiorerispettoalle soluzioniimplementatein . ;

/ ha intersezionecon . sei duehannoalmenounrequisitoin comune;

134

/ e indipendenteda . se l’intersezionedegli insiemi dei requisiti di . e / el’insiemevuoto;

Ci sembraragionevole farei seguentiassunti.

Assunto5.1 Ogni singoloprototiposi occupera di un sottoinsiemedei requisitidel MAS, eccettoi prototipi ottenutiversola finedel ciclo a spirale, i quali vistochesi vorrebbearrivaread unaimplementazioneo almenoadun unicoprototipodel sistemaeplausibilecheimplementinotutti i requisiti.

Assunto5.2 Ogni prototipo realizzera un sottoinsiemedegli agenti del MAS fi-nale.

Assunto5.3 Ogni agentein un MAS unito ad altri implementale funzionalitacheservonoper ottenereunoo piu dei requisitidi sistema.

Assunto5.4 Ogni requisitosara implementatoda un insiemedi agenti in fortecoesione.

Facciamoosservareche l’assunto5.1 sottointendeche il sistemavengasvi-luppatotramiteun insiemedi prototipi e duranteil processodi raffinamentosiapossibilefareconfluiredueprototipi in unosoloin modochealla fine si abbiaununicoprototipoo realizzazionedel sistema.

Congli assunti5.3e5.4mettiamoin relazionei prototipiegli agenti.In figura5.14abbiamoillustratoalcuniprototipi chehannounaintersezioneevidenziandogli agentiin essicontenuti.

La figura 5.14dovrebbeaiutarcia comprenderechesesi vuole costruireunsistema,nontutti gli agentidell’architetturaMAS sarannosottosviluppocontem-poraneamente.Venesarannoalcunile cui mansionirisulterannoin qualchemodomarginali rispettoal sottoinsiemedi requisitichesi staanalizzandonel prototipo.Durantel’esecuzionedel prototipoe facilechealcunidegli agentisottosvilupponecessitinodi riferirsi o interagirecon alcuni fra quelli al di fuori del prototipo.Ad esempio,in figura 5.14, e schematizzatoun MAS con tre agenti(cerchi)dacui partonodelle frecceche individuanole interazionifra gli agenti. Si e sud-diviso il MAS (rettangolopiu grande),in dueprototipi (rettangolipiccoli chesiintersecano).Gli agentichestannoentroil confinedel prototiposonogli agentisottosviluppoper quel prototipo,quindi gli agentichesonooggettodella pro-totipazione. Quandosi simulera il prototipoA, e probabilechel’agenteA, percompletareunsuocompitoabbiabisognodi interagireconl’agenteC chenonerasottosviluppo. Un’ideapotrebbeessereutilizzarela programmazionelogicaperscriverevelocementeunagentecheadeterminaterichiestedell’agenteA rispondacomepotrebberisponderel’agenteC.Potremmocosı individuarealcunetipologiedi agenti:

135

MAS

Ag A Ag B

Ag C

Prototype B

Prototype A

MAS

Prototype APrototype B

Ag BAg A

Ag C

Prototype B

Prototype AAg B

Ag C

Ag A

Ag D

(c)

(b)

MAS

(a)

Figura5.13: Schematizzazionedelle relazionitra prototipi: (a) raffinamento,(b)intersezione,(c) indipendenza.

136

MAS

Prototype A

Prototype B

Agent A

Agent B

Agent C

Agent D

Figura 5.14: Esempiodi comepotrebberoesserecoinvolti gli agenti in diversiprototipi.

137

Agenti dummy: agentecheserve solo in fasedi sviluppoper far funzionareilprototipo.

Agenti sotto sviluppo: un Ag-Prolog o un Ag-Java chee in fasedi sviluppoealla finedel ciclo di sviluppofara partedelMAS.

Si osservicomeci si limiti ad associareun agentedummyall’agenteC e nonalD, questoperche essendoC un agentedummynonsfruttera nessunainterazionecon l’agenteD per fornire le rispostea A. Gli agentidummypotrebberoesseredei sempliciagentilogici specificatiadesempiotramiteAgentRules per i qualisi fornisceun comportamentoreattivo. L’esempioprecedenteci suggerisceduemodi di utilizzaregli agentilogici:

� comeagentiprovvisori cheaiutanoasvilupparerapidamenteprototipi;

� comeagentia tutti gli effetti che verrannomantenutinella realizzazionefinali.

5.4 Analisi

Illustriamo finalmentela progettazionedell’estensionecheci permettera di ese-guireagentilogici in JADE.

5.4.1 Obiettivi dell’integrazione

Consideratocheallo statoattualela trattazionedelle problematicherelative allamobilitadegli agentieal di fuori degli obiettivi di D-CaseLP, le funzionalitachel’integrazionedovrebberendereaccessibilisono:

Esecuzionedi agentiAg-Prolog. Si vuole fornire la possibilita di eseguire in-distintamenteagentiAg-Prolog o Ag-Java chegraziealla condivisionediuno stessomodello di comunicazionebasatosullo scambiodi messaggiFIPA ACL sianoin gradodi interagiretra loro alla pari.

Controllo emonitoring suagentiAg-Prolog. Ci aspettiamochel’integrazioneoffra agentilogici chesianoa tutti gli effetti agentidellaplatform,suiqualisia quindi possibileutilizzaregli stessistrumentidi monitoringe control-lo (RMA, Sniffer Agent, IntrospectorAgent, etc) che si applicanoper ilmonitoringe il controllodi agentiJADE ancheagli agentiAg-Prolog.

Al finedi poterutilizzaregli strumentidi JADE suinuovi agentiAg-Prolog, biso-gnachegli agentiAg-Prolog sianonascostiin oggettidellaclasseAgentdi JADE.

138

Unaprimaquestioneedecidereachelivello introdurrele componentilogichene-gli agentiJADE. Gli agentisonoistanzedellaclasseAgent,il cui comportamentoesuddiviso in diversioggettiistanzedellaclasseBehaviour, chevengonoschedu-lati secondounaqualchepolitica. E chiarochepereffettuarel’integrazionesaranecessariooperaredellesceltecircale seguentiquestioni:

� Introduciamouna classeagentelogico o un comportamentologico o en-trambi?

� Nel casoin cui ci avvalessimodi Behaviour, qualetipo di Behaviour e piuadattoai nostriscopi?

Risponderemoalleprecedentiproblematichequandoillustreremoil design.

5.4.2 0 ProlAg: linguaggio d’implementazione

Fino ad ora abbiamoparlatodi agentilogici specificandochesarannoscritti inProlog3, in realta tale linguaggiononnasceperscrivereagentiintelligenti e nonoffre quindi costruttinativi utili peressi. Il Prolog di perse nondisponedi pri-mitiveperla comunicazione,infatti, molti deipredicaticheil linguaggiooffre perla programmazioneconcorrente,i thread,e l’esecuzionedistribuita sonoesten-sioni successive,spessofornite attraversosoluzioniproprietariedifferentidaunaimplementazioneall’altra del linguaggio. E evidentechegli agentiAg-Prolognon possonoesseresemplicementeagentiil cui linguaggiodi programmazionee Prolog, ma abbiamobisognodi estendereil linguaggioed aggiungerealcunipredicatichepermettanodi utilizzareil paradigmalogico perla programmazionedegli agenti.

Il problemacirca qualeestensionedi Prolog sia la piu adattaal fine di uti-lizzarlo comelinguaggioper programmareagentie statoampiamentediscussoe trattato,tant’e vero checi sonovarie proposte.Noi partiremoda Prolog forAgents(ProlAg) [42] chee la soluzionepropostain CaseLP.

La prima ideacheverrebbein mente,e scegliereProlAg comelinguaggiodiprogrammazioneper gli agentiAg-Prolog. Consideratochegli agentiCaseLPeranoimplementatiin ProlAg questasceltadarebbeunacertacontinuita,permet-tendodi recuperareil lavoro gia svolto sui linguaggidi descrizionedel MAS. Eancheverochel’impostazionemetodologicadi D-CaseLP e differentedaquelladi CaseLP, in particolaresi stalavorandoper offrire un supportopiu completodei ruoli per gli agentied un’integrazionedel framework concettualeFIPA, perquestopartedellametodologiaedel lavoroprecedentedovraessereaggiornato.

3Piu precisamentesi pensadi utilizzarel’implementazionedi Prolog fornita in tuProlog

139

Definiamounaversionemodificatadi ProlAg chechiameremoperdistinguer-la dallaprecedente1 ProlAg. UnadelleprimemodificherispettoadProlAg cosıcomeera in CaseLP cosistenel permetterealle primitive di comunicazioneditrattaremessaggiespressiin un qualchelinguaggiodi comunicazioneper agenti(FIPA ACL, KQML). Questoimplicaadesempiocheil destinatariodi unmessag-gio speditoattraversounasendnonsia piu espressocometerminedel predicatomasi trovi all’internodelmessaggiostesso.In generalei parametridelleprimitivesarannocodificheo schemidi messaggiFIPA ACL. In 1 ProlAg abbiamoelimi-natola primitiva asyncreceiveall() in quantopuo essereottenutaa partiredallaasyncreceive().

Non si fornisconole versioni “safe” dell’asserte della retractche possonoessereottenutecomespiegatoin [15], mentrepercio riguardai predicatidi comu-nicazioneabbiamocambiatosostanzialmentesolola sintassi.

Predicati per la comunicazione.

I predicatidi comunicazioniofferti da 1 ProlAg sono l’implementazionedelleprimitive di comunicazioneche appartengonoall’interfacciaastrattapresentatain 1.3.5con alcunemodifichedovuteal fatto chel’interfacciae realizzatain unparadigmalogico.

Si tengapresenteche il paradigmalogico ed in particolareProlog basalesue“computazioni”sul principio di risoluzionedi Robinsone l’unificazione. Ilprimo permettedi combinaredelle clausolein modo da ottenerealtre clausoleconseguenzelogichedelleprecedenti,mentreil secondopermettedi capireseduetermini sono“compatibili” fornendounarelazionefra termini.

L’unificazionedei termini potrebbeessereanchevistacomeunaformabilate-raledi patternmatching,in cui invececheconfrontareunoschemaconqualcosadicompletamenteistanziato,si confrontaunoschemaconunoschemaindividuandoun insiemedi elementicheappartengonoadentrambi.

Datochei presuppostidellaprogrammazionelogicasonofortementedifferentidal paradigmaad oggetti o imperativo, bisognafare attenzioneal modo in cuicodifichiamoi messaggiFIPA ACL in Prolog. La cosamiglioresarebbesfruttarele peculiaritadelparadigmalogicofornendounacodificadeimessaggiFIPA ACLpiu maneggevole rispettoa quellabasatasullestringhechesi erapensatapergliagentiAg-Java.

Chiameremola nuovacodificadeimessaggiPrologACLCode , in essadovre-modefinireun insiemedi termini peresprimereschemiemessaggiFIPA ACL.

In primaapprossimazionedovremoaggiungereunsimbolodi funzioneunariaperogni chiave chepuo esserespecificatain un messaggioFIPA ACL, cosicchele coppiachiave-valoredel tipo

:chiavevalore

140

siaesprimibilenellacodificacome

chiave(valore)

Un messaggioFIPA ACL saraunatuplacontenenteuncertonumerodi coppiechiave valore,nella codificaun messaggiosara rappresentatocomeuna lista ditermini simili aquelli descrittiprecedentemente.

Descriviamonel seguito le primitive inclusein 1 ProlAg.

sync receive(Message)nel casoin cui la mailboxdell’agentecontengaun mes-saggiocheunifica con lo schemadi messaggioindicatocomeargomento,attraversol’unificazionevengonoriempiti i campiliberi dello schema.Senonvi e alcunmessaggiocheunificacon lo schemal’agentechehaeffet-tuatola chiamatavienebloccatofino aquandononarrivaunmessaggiocheunificaconlo schema.

async receive(Msg input,Msg output) controllanella mailbox dell’agentecherichiamaquestopredicatosec’e un messaggiocheunificaconMsg input,se un cosiffatto messaggioe presentenella mailbox, viene unificato conMsg outputetolto dallamailbox,altrimentiMsg outputvieneunificatoconil termineno message.

send(Message)spedisceil Message al destinatarioo ai destinatariindicati congli apposititermininel messaggio.

In analogiacon cio cheeraProlAg in CaseLP, 1 ProlAg si ponecomelin-guaggioin cui tradurrei linguaggidi specificaomogeneamente.Si considerico-meesempiola specificaAgentRules di unagente,cio di cui dovremmoavercuraper eseguretale specificacomeagentelogico in D-CaseLP, e fornire un meta-interpretescrittoin 1 ProlAg cheforniscal’engineallo statoedil programtradottidallaspecifica.

L’astrazionedelleclassidi agentiverra fornito dai linguaggidi specificapre-senti in CaseLP, chesi prevededi renderedisponibili anchenel framework D-CaseLP4.

Allo stato delle cosegli agenti logici che ci proponiamodi fornire in D-CaseLP potrebberoesserecaratterizzatidalpuntodi vistaconcretodallaseguenteequazione:

JADE + 1 ProlAg = Ag-Prolog

Dove 1 ProlAg asuavoltapotrebbeesserevisto come

Prolog + Predicatiperla comunicazione= 1 ProlAg

4Cio cheprevediamodi fornire, eun’implementazionedeipredicatidi ProlAg in 2 ProlAg, inmodochesiapossibilecontinuarea utilizzarelinguaggie traduttoriofferti in CaseLP.

141

5.4.3 UseCaseDiagram per l’estensionedi JADE

Analizziamoin questasezionequali sonoi requisiti chedeve averel’estensionealle librerie JADE, affinche sia possibilescrivereagentilogici. Nello usecasediagramin figura5.15sonoillustrati gli usecasechedescrivonol’iterazionedegliutenti con il packageche forniremo. Abbiamo individuatodue attori coinvoltidellousecase:

Logic Agent Developer: chesi occupadi progettaree programmaregli agentilogici;

MAS Configurator: chesi occupadi configurarliedesegurli.

Mas ConfiguratorLogic AgentDeveloper

Write a Logic Agent(Ag-Prolog)

Install D-CaseLPJade extension

Run a Logic Agent

D-CaseLP Package

Write a New Agent Architecture

Figura5.15:UsecaseperD-CaseLP forniamo.

Descriviamo gli usecasein modo da dareun’idea di cosarappresentanoequali funzionalitapresuppongano.

Write a Logic Agent: il “Logic Agent Developer” specificaun agentelogico,sceglie un’architetturaperagentiimplementatain 1 ProlAg especificain unlinguaggiodipendentedall’architetturasceltalo statoinizialeeil Behaviourdell’agente.

Write a NewAgent Ar chitecture: il “Logic AgentDeveloper”non trova fra learchitettureperagentilogici implementatequellachefaal casosuo,decidequindi di scriverneunanuova.

142

Run a logic agent: unavolta chegli agentisonostatiscritti il “Logic AgentDe-veloper”passaal “Mas Configurator”le componentichesononecessarieal-l’esecuzionedegli agentilogici, in modochequest’ultimopossaconfigurarel’esecuzioneedeseguireil MAS.

Install D-CaseLP JADE extension: in questousecasevienecoinvolto solo il“Mas Configurator”chehail compitodi installaree configurarel’estensio-ni chepermettedi utilizzare gli agenti logici in JADE prima di eseguiregli agentiforniti dal “Logic Agent Developer”. Questafasesara eseguitaunasolavoltaduranteinstallazionedi JADE dalmomentochel’estensioneconsistera in un certoinsiemedi packageJava daaggiungerea quelli JA-DE questousecaseconsistera nel seguiredelleistruzionidi installazioneeconfigurazionefornite daD-CaseLP.

Concludiamoquindi la fasedi analisi fornendoun maggiorlivello di dettaglionellospiegaregli use-caseWrite a Logic Agent eWrite a NewAgent Ar chitec-ture.

5.4.3.1 Write a Logic Agent

Seguendola concettualizzazionedi agentein termini di State-Engine-Programdescrittain sezione1.2.1,raffiniamo lo usecaseWrite a Logic Agent nello usecasediagramin figura 5.16. In essosi possonoindividuareduenuovi usecasenecessarial completamentodellousecaseprecedentementedescritto:

Write a Logic Agent: e lo usecaseprincipalein cui l’utente( attoreLogic AgentDeveloper)definera un agenteAg-Prolog utilizzandol’estensionealla li-breriaJADE fornita in D-CaseLP.

Choosean Agent Engine: l’utente scegliera qualeenginee piu adattoper l’a-gentechestaprogettando.

Write Stateand Behaviours: in dipendenzadel tipo di enginecheha scelto,ilLogic AgentDeveloperscrivera lo statoiniziale e il comportamentodell’a-gente.

5.4.3.2 Write a NewAgent Ar chitecture

Vediamocosasuccedequandoil Logic AgentDevelopernontrovaun’architetturaperagentegia sviluppatachesoddisfa i requisitidalui individuatiperesprimerei

143

Logic Agents Developer

Write anLogic Agent

Choose an Agent Engine

Write Agent Behaviour and State

Include

Include

Figura5.16:Usecaseperscrivereagentilogici.

suoiagenti5. Comeillustratoneldiagramma5.17,lo usecasein questioneincludealtretreattivita.

Write a NewAgent Ar chitecture: l’utentedecidedi progettareunanuovaarchi-tetturaperagente.

Decidea Behavior and StateFormat: l’utenteprogettaunlinguaggioin cuiespri-mereil comportamentoe lo statopergli agenti.Qualoranonsianecessarial’introduzionedi unlinguaggiopiu astrattodi quellochee 1 ProlAg, si pos-sonoesprimerestatoe programin formadi predicati,altrimentisi definiraunanuovasintassiattraversounaBNF e la relativasemantica.

Write a Behavior & StateTranslator to 1 ProlAg: si indicaunaproceduraperla traduzionedegli eventuali linguaggi definiti per esprimerelo statoe ilprogramche l’utente ha progettato. Si fornisceun traduttorechedatalaspecificadel linguaggioper lo statoed il programrestituiscadei predicati1 ProlAg chesarannoutilizzati dall’enginedurantel’esecuzione6.

5Si ricordaunadelle ipotesiprogettualidi D-CaseLP consistenel non vincolarel’utente adutilizzareunapresceltaarchitetturaperagenti,anzisi vorrebbelasciarela possibilitadi impiegarnedifferentiin unostessoMAS.

6Si puo anchedecideredi includereil traduttorenel engine,in tal casonon e necessariodareun traduttore.

144

Logic AgentDeveloper

D-CaseLP Package

Write a New Agent Architecture

Decide a Behaviour and State Format

Write an Engine

Write Behavior & State translator to NProlag

Include Include

Include

Figura5.17:DettagliosullousecaseWriteArchitecture.

Write an Engine: si progettaedimplementain 1 ProlAg unengine,chepresalacodificadi statoe comportamentodell’agentesi comportacoerentementeconil modellodi architetturapensatadall’utente.

Da questopuntoin poi daremoper scontatochequaloral’utentesi definiscauna nuova architetturamettaa disposizionela documentazionee gli strumentinecessarialla realizzazionedello usecase“Write aNew AgentArchitecture”;

Vistocheealtamenteprobabilechel’utentedopoaverdefinitoun’architetturala utilizzi, avremmopotutoincluderenello usecase“Write a New AgentArchi-tecture”lo usecase”Write a Logic Agent”. Tuttavia ci sembrainutile inserireunulteriorevincolo: sequalcunodovessedefinirearchitettureper agentilogici adusodi altri deveessereliberodi poterlofare.

Visto chesesi stascrivendoun agentelogico (usecaseWrite a Logic Agent)si deve averea disposizioneun’architetturaperagente,ovveroun engineespres-so in 3 ProlAg e degli strumentiper tradurrelo statoed il programin predicati3 ProlAg. Assumeremonel restodi questasezionecheil programe lo statosia-no semprestati tradotti dall’utentein 3 ProlAg e sianostati memorizzatiin dei

145

file. Nella prossimasezioneillustreremoil designdell’estensionea JADE, per ilmomentoci concentreremosoprattuttosugli usecasechecoinvolgonole fasi disviluppodegli agentilogici e nonillustreremoin dettaglioquelledi esecuzioneeconfigurazionedel tool.

5.5 Designdell’estensione

In questasezionepresentiamola descrizionedi comepensiamodi otterel’integra-zionegli agentilogici Ag-Prolog apartiredagliagentiJADE e tuProlog.E chiarochepermetterein gradogli utentidi scrivereun’architetturaperagentilogici chesiaeseguibiledallanostraestensionedobbiamospecificarealcunequestioni:

4 qualepredicatoindividual’engine;

4 ipotesichedeve soddisfareun engineaffinche nonsi perdala concorrenzatraagenti.

Perla primadelleduequestioni,la cosapiu semplicee prevederechetutti glienginedelle architetturesianospecificatida uno stessopredicato.Usandotuttala fantasiadi cui disponiamoimporremochel’engine sia indicatodal predicatozero-ario“engine”. Per le problematicherelative alla concorrenza,il discorsoeun pocopiu complicato,si trattaa grandilineedi individuarecomeframmentarel’esecuzionedell’enginein differentiBehaviour di JADE.

5.5.1 La concorrenzadegli agenti in JADE

Comeabbiamoillustrato in sezione4.2.2.1,in JADE gli agenticorrispondonoathreadeseguiti suunaJava Virtual Machine. Il multithreadingofferto daJava edel tipo pre-emptivemultitaskingsenzatime-sharing, in altreparolelo schedulingdei threade interrompibilema non essendociun tempo limite di occupazionedellarisorsa(time-slice) none previstaalcunainterruzioneseun threadoccupailprocessoretroppoa lungo.

In questomodellodi concorrenzaeresponsabilitadelprogrammatorenonscri-verethreadchemonopolizzinola risorsaprocessore.Si pensiadunagentelogicocaratterizzato,adesempio,dallaarchitetturapropostain [39] la qualeprevedeunenginecheconstadi unaseriedi attivita svolte unadopol’altra in un ciclo comequellochesegue

4 Inizio ciclo al tempoT;

1. Osservaregli inputal tempoT;

146

2. Pensare;

3. Scegliereunao piu azionidaeseguire;

4. Eseguirele azioni;

4 Fineciclo: T=T+1.

Innanzitutto talearchitetturacontieneun ciclo e non e pensabileimplemen-tarel’agentelogico fornendoun enginecheconsistain un ciclo potenzialmenteinfinito di attivita. Una sceltadi questotipo comporterebbechel’agentenon ri-lasci mai la CPUcon la conseguenteperditadellaconcorrenzatra gli agentidelMAS. A questoproblemasopperiamononincludendoil ciclo all’interno dell’en-gine,cosicche l’agenterilasci il processoredopochehaeseguitounavolta tutteleattivitaprecedenti.Nonostanteil fattochesi tolgail ciclo dall’enginel’esecuzionedelleattivita rimaneciclica pereffetto dellechiamatesuccessive al predicatocherappresentera l’engineeffettuatedalloschedulatore.

Questotipo di soluzioneperla concorrenzafra gli enginedi agenticoncorrentirisultaefficacequalorasiarispettatala seguenteipotesi:

Ipotesi 5.1 Leattivita contenutein unsingolociclo dell’engineterminanoesonodal puntodi vistacomputazionale“sufficientementeleggere”.

Quantodebbanoessereleggerele computazionidipendein sostanzadal tempodireazionechesi vuole dagli agenti,maggioree la reattivita pretesaminoredeveessereil temponecessarioadeseguireun “ciclo” di istruzioni.

L’ipotesi 5.1 e in generaleragionevole, e noncreaproblemifino a quandosivogliono utilizzareparticolari tipi di agenti. Ad esempiosoddisfanotale ipotesigli agentidummycheabbiamoindividuatocomeutili durantelo sviluppodeipro-totipi del MAS. Questiagenti,infatti, sarannoprincipalmenteagentireattivi chereagisconoagli stimoli/richiestedi altri agenticonrisposte“preconfezionate”.

Qualchedifficolta nel casoin cui si voglianoagentilogici dautilizzarecome“ragionatori”. Questotipo di agentirichiedein generela dimostrazionepredi-cati piuttostocomplessie non e semplicecapiredove possaessereinterrottaladimostrazionesenzaavereinformazionisulledimostrazionistesse.

Per il momentoci concentreremosugli agentiche soddisfano l’ipotesi illu-strandocomeintegrarli in JADE attraversotuProlog.

5.5.2 Designdi agenti logici con tuProlog eJADE

Spieghiamoa partiredatuProloge JADE comeabbiamointenzionedi realizzaregli agentilogici illustrando

4 comevieneinclusoil codice 3 ProlAg negli agentiJADE;

147

4 comeestendiamotuPrologconi predicati 3 ProlAg al fine di permetteredicomunicareconla platformJADE.

Perrispondereaquestedomandeci serviremodelclassdiagramin figura5.18,del qualedescriveremoprimale classiepoi gli oggettichevi compaiono.

Le Classi.

Primadi descriverele singoleclassi,vorremmochiarirecheper ognunadi esseabbiamoevidenziatosoloi metodie gli attributi chein qualchemanieravengonocoinvolti nelladefinizioneedesecuzionedegli agentilogici. L’obiettivo di questadescrizioneedareun’ideaprecisadi comesi possaorganizzarel’integrazionedeivari strumentiadottatirimanendoadun livello progettuale.Descriviamole classichecompaiononelclassdiagramricordandovelocementele funzionalitaassociateai metodi.

Agent: e la classechetutti gli agentiJADE devono estendere.Comeabbiamogia avuto mododi illustrarenellasezionededicataa tale tool, in essasonodefiniti i metodichepermettonod’interfacciaregli agentiallaplatform.

Si ricordacheogniagenteJADE vieneeseguitodallaplatformattraversoilmetodorun, talemetodononpuo esseresovrascrittodallesottoclassi.

Il metodosetuppermettedi prepararel’agenteall’esecuzione,nellasuade-finizionee possibileaggiungerei comportamenti(behaviour) iniziali all’a-genteattraversoil metodoaddBehaviour.

Coni metodisend, receive, blockingReceivesi accedeai servizidi comuni-cazionedegli agenti.

Infine, il metodogetArgumentspermettedi recuperarei parametridell’a-genteche sonostati specificatida linea di comandoo nell’interfacciadistart-up.

Agent1: e una genericaclassedi agentidefinitadall’utente,l’abbiamo inclusanel classdiagramal soloscopodi ricordarechetutti gli agentiJADE sonoistanzedi classicheestendonola classeAgent.

AgProlog: e la classeprincipaledellanostraestensione,dallaqualeistanzieremoagenti logici sulla platform JADE. In tale classesi ridefinisceil metodosetupin mododaeffettuarele seguentioperazioni:

4 leggerei parametriassociatiall’agente(tramitegetParameters)e ve-nire a conoscenzadel nomedei file in cui sonospecificatiil program,engineestatodell’agente;

148

4 creareun motoreinferenzialeProlog a partiredaunaistanzadell’in-terpretetuProlog,a cui si aggiungonole teoriecontenentii predicatiche rappresentanol’estensioneper la comunicazione,ed i predicatiletti dafile chedefinisconostato,program,edenginedell’agente;

4 importareattraversole funzionalita offerteda tuPrologil riferimento(This)all’oggettodi cui stiamodefinendoil metodosetup,in mododapotersiriferire ad essotramite il temine“me” all’interno del codice3 ProlAg;

4 aggiungereall’agenteattraverso il metodoaddbehaviourun’istanzadellaclasseResolveEngine,passandogliil motoreinferenzialeprece-dentementecreato.

CyclicBehaviour: e laclassedefinitanelframeworkJADE chedefinisceuncom-portamentosemplicechevieneripetutoadogni attivazionedell’agente.Leistruzionichecaratterizzanoil comportamentodevonoesserecontenutenelmetodoaction.

ResolveEngine: e classeappartenenteall’estensioneD-CaseLP chespecializzail comportamentodel genericoBehaviour ciclico in un behaviour nel qualevienerisolto il goal “?-engine”. Al costruttoredi questavienepassatoilriferimentoal motorelogico (parametroprolog engine)chevienecustoditoin unattributodellaclassein mododapoterinvocareall’internodelmetodoaction il metodosolvedelgoal.

Prolog: e unaclassecheappartieneal framework tuProlog,ognisuaistanzaeunmotoreinferenzialedifferentein cui sonostatecaricateautomaticamentele librerie ISOLibrary, MetaLibrary e JavaLibrary. Il metodoaddtheorypermettedi aggiungereal motoreinferenzialedellenuove teorie,mentreimetodisolvepermettonodi dimostrareun certogoal espressonella formadi un oggettodi classeTerm(termine)o unastringa.

Theory: unaclasseappartenenteal framework tuPrologchemantienela codi-fica di una teoria ovvero un insiemedi predicatiProlog. Il costruttoredi questaclasseprendecomeargomentounacodifica in stringhedel pro-grammaProlog. Le teoriepossonoessereaggiuntead un motorelogicodinamicamente.

149

Gli oggetti.

Descriviamo gli oggetti checompaiononel diagramma5.18 7, sonotutti istan-ze della classeTheorye rappresentanoinsiemi di predicatiProlog. Gli oggettiEngine,State,Programrappresentanorispettivamentele teoriechecontengonoipredicatichedefinisconoil codicedell’engine,lo statoedil programdell’agentelogico sottosviluppo. Invece,l’oggettoNProlagrappresentai predicatichedefi-nisconol’estensione3 ProlAg del Prolog standard.Tuttequesteteorievengonoaggiunteal motorelogicodi ogni istanzadi agentedellaclasseAgProlog.

Le relazioni contenutenel diagramma.

Nel diagrammaci sonotre tipi di relazioniusatecoerentementeconla notazioneUML:

Generalization: individuatadallafrecciacontinua,indicachela classedallaqua-le parteestendela classein cui arriva.

Use: relazionedi dipendenzaconstereotipousestandardUML, indicachela se-manticadellaclassedi partenzadipendedall partepubblicadellaclasseincui la frecciaarriva.

IstanceOf: relazionedi dipendenzaconstereotipoIstanceOfstandardUML, in-dica chegli oggettida cui partela frecciasonoistanzedella classein cuiarriva.

Rimarchiamoulteriormenteche la classeche implementagli agenti logicisempliciAg-Prolog estendel’Agent di JADE, quindi e un agenteJADE a tut-ti gli effetti ed avra dei comportamentiespressiin termini di Behaviour. Per laprecisioneogniagenteistanzadi AgPrologavraununicobehaviour ResolveEngi-ne,il qualeridefinisceil metodoaction()in modocheil behaviour possarisolvereil goal “?-engine”. Si noti chenel costruttorevienepassatoil riferimentoal mo-tored’inferenzaattivatonell’agente,questoaffinche siapossibileinvocaresutaleoggettoil metodosolve.

Implementazionedell’oggettoNProlag.

NonostantetuPrologpermettadi estenderel’insieme dei predicatibuilt-in attra-versol’utilizzo dellelibrerie,abbiamosceltodi definirei predicatidell’estensione3 ProlAg in unateoriadaaggiungereal motoreinferenzialeProlog.

7Peril lettorenuovo allanotazioneUML, ricordiamochegli oggettivengonorappresentatinelclassdiagramdai rettangoliconetichettasottolineata.

150

Primadi illustrarecomevengonoimplementatii singoli predicatidi comuni-cazioneintrodotti da 3 ProlAg supponiamodi aver definito duepredicatidi ser-vizio checi permettanodi trasformarela codificaPrologACLCodeperesprimerei messaggiFIPA ACL o patterndi messaggi,rispettivamentein oggettidi classeACLMessageo MessageTemplate.

PrologACLMsg(X,Y) predicatochee veroseX e unacodificaPrologACLCodedel messaggioACL contenutonell’oggettorappresentatodal temineY.

PrologACLTemplate(X,Y) predicatochee veroseX e la codificaPrologACL-Codedel patterncheesprimegli stessivincoli dell’oggettoMessageTem-platerappresentatodal temineY.

Nonostantesiaevidentechei predicatiappenadefiniti debbanoal loro internofa-re usodi funzionalita extralogichesenon altro per interfacciarsicon gli oggettiJava, agli scopidi questapresentazioneipotizziamochesianoentrambiinverti-bili. Concio intendiamoadesempiochePrologACLMsg(X,Y) “costruisce”l’og-gettoACLMessagee lo unifica con Y se istanziamoX con un termineground,mentrecostruisceil terminerappresentanteil messaggioin codificaPrologACL-Codeunificandolocon X se istanziamola Y con un termineoggettodi classeACLMessage.

Definiamoorail codicetuPrologconcui si possonoimplementarei predicatidi comunicazioneofferti da 3 ProlAg.

sync_receive(M):- PrologACLTemplate(M,T),me <- blockingReceive(T) return M1,PrologACLMsg(M,M1).

async_receive(M_in,M_out):- PrologACLTemplate(M_in,T),me <- receive(T) return M1,what(M1,M_in, M_out).

what(M1, M_in, M_out):- isnull(M1), !,M_out= no_message.

what(M1, M_in, M_out):- PrologACLMsg(M_in,M1).

send(M):- PrologACLMsg(M,ACL), me <- send(ACL).

L’ideae cheognipredicatodi comunicazionevengatrasformatonel rispettivometodoJADE per la comunicazione.Si noti le primitive che permettonoagliagentiJADE di comunicarevengonoofferte nella forma di metodidella classeAgent.Perquestonel metodosetupavremocuradi renderedisponibileal motore

151

inferenzialeil riferimentoall’oggettoistanzadi AgPrologattraversol’operazionetuProlog

JavaLibrary.register(me, this)

Questaoperazioneci permetteraattraversoil termine“me” associatoal riferi-mentodell’agentedi accederea tutti i metodidi comunicazione.

5.6 Considerazioniconclusive

La progettazionecheabbiamoappenadescrittodovrebbeaver convinto il letto-re chee possibileottenereagentiAg-Prolog, eseguibili sullaplatformJADE. Cisiamoserviti della notazioneUML non tantocon la pretesadi scrivereunaverae propriaspecificaquantoperesprimerein unaformapiu immediatale ideechedovrannoguidarela realizzazione.A causadelle limitate risorsetempoe uomodi cui disponevamoabbiamoeffettuatosolo la “progettazione”dell’integrazionefra JADE e tuProlog. Si prevededi realizzarel’implementazionein un lavoro ditesisuccessivo. Non appenasi disporra di un supportofunzionantepergli agen-ti logici sarebbeinteressantevalidareanchele idee(che trovanoqui unaformaesclusivamenteembrionale)circal’utilizzo degli agenti“dummy” perfacilitareiltestingdi prototipi parzialidel sistemachesi stasviluppando.

152

Agent+run(): void#setup(): void+getArguments(): Object+send(msg:ACLMessage): void+receive(): ACLMessage+receive(pattern:MessageTemplate): ACLMessage+blockingReceive(): ACLMessage+addBehaviour(b:Behaviour): void+removeBehaviour(b:Behaviour): void

Agent class provides to JADE Agent Platform an interface that allows to create, to manage and to control agent execution.

Agent1

User defined JADE Agent

AgProlog

#setup(): void

ResolveEngine+prologEngine: Prolog+ResolveEngine(prologEngine:Prolog)+action(): void

CyclicBehaviour

+action(): void

� <<use>> �

It’s a AgProlog Behaviour

Prolog

+addTheory(theory:Theory): void+solve(goal:java.lang.String): SolveInfo+solve(goal:Term): SolveInfo+Prolog()

EngineState ProgramNProlag

Theory

+Theory(theory:java.lang.String)

Prolog Program Container

Classes provided bytuProlog framework

Classes provided byJADE framework

Classes provided bytuProlog framework

1

1

� <<IstanceOf>> �

Figura5.18: Il classdiagramchespiegacomeintegrarele differenticomponentiperotteneregli agentiAg-Prolog.

153

Conclusionie sviluppi futuri

Questolavorodi tesinascedall’esigenzadi estendereCaseLP: unambienteperlaprototipazionerapidadi sistemimulti-agentebasatosullaprogrammazionelogica.

Una prima partedel lavoro effettuatoe consistitonell’individuarei requisitidell’estensioneapplicandole lineeguidaper il designproposteda Wieringa. Inquestafaseil candidato,la Dott. VivianaMascardie StefanoMiglia hannodefi-nito un FunctionalRefinamentTreecontenetele funzionalita chesi prevedeva diprenderein considerazione.

Il FunctionalRefinamentTreedelleestensionierisultatoabbastanzaarticolatodaesseresuddiviso in dueprogetti: M-CaseLP e D-CaseLP. Il primo racchiu-de le problematicheinerentigli aspettidi progettazionedi sistemimulti-agentee definizionedi prototipi a partiredaunalibreria di componentiriutilizzabili. Ilsecondotrattadegli strumentiadattiadottenereun ambientedistribuito cheper-mettal’esecuzione,la simulazione,emonitoringdi prototipidi agentiAg-PrologedAg-Java.

Vistal’ambizionedel progetto,questolavoro di tesisi concentrasugli aspettirelativi all’esecuzioneed il monitoring degli agentiAg-Prolog e Ag-Java la-sciandofuori gli aspettidi simulazione. Il contributo di questatesi al progettoD-CaseLP sonostati:

4 la valutazionedi CORBA cometecnologiaper ottenerela distribuzionedegli agenti;

4 lo studio e la valutazionedelle specificheFIPA per il designdel tool D-CaseLP;

4 lo studioe la valutazionedel framework JADE;

4 la progettazionedell’integrazionefra agentilogici (Ag-Prolog) estrumentiofferti dal run-timeJADE.

Valutazionedi CORBA.

La comunicazionefra agenticoinvolge tre livelli di astrazione:trasporto(proto-collo di comunicazione),linguaggiodi comunicazioneper agentied ontologie;

154

l’interazionefra gli agentisi basasul modellopeer-to-peernel qualeogni entitacoinvoltahagli stessidoveri ediritti di ognialtra.

Questecaratteristichenon sonosupportateda CORBA il qualee un midd-lewareperoggettifortementebasatosul modellodi comunicazioneclient-server.Inoltre, essendoprogettatoper distribuire componentisoftwarenon intelligenti,CORBA nonprevedeunacomunicazionestrutturatasudiversi livelli di astrazio-neeforniscesupportosoloperil livello piu bassodellacomunicazioneperagenti:il trasporto.

I limiti riscontratiin CORBA hannomessoin luce l’inadeguatezzarispettoagli obiettivi di D-CaseLP. In particolare,l’impiego di CORBA per effettuarela distribuzioneavrebbecomportatoun onereeccessivo rispettola scarsaforzalavoro di cui disponeil progetto.

Studio dellespecificheFIPA.

Il secondocontributo e consistitonellostudiodellapropostadi standardizzazioneeffettuatadallaFIPA pergli aspettiattinentiaD-CaseLP.

La FIPA si prefiggedi standardizzarel’intelligenzaesternadeiMAS lasciandoampialiberta su quali architettureper agentilo sviluppatorepuo utilizzarenellaprogettazionedel suosistema.

Il framework concettualedella FIPA offre un designin cui e fornita la so-luzione ad alcunedelle problematicheprogettualidi D-CaseLP. In particolaree fornito attraverso il concettodi platform il livello di astrazionesufficiente apermettere

4 l’aggiuntae l’eliminazionedinamicadi istanzeperle classidi agentiappar-tenential MAS;

4 la sostituzionedei protocolli con cui gli agenti comunicanoattraverso iserviziofferti dal MessageTransportService(MTS).

Lo studiodellespecificheFIPA haportatoa rifletteresullapossibilitadi pren-derein considerazioneun tool FIPA compliantper la realizzazionedel run-timein cui eseguire gli agentiAg-Prolog ed Ag-Java. Con questoobiettivo si sonovalutatele funzionalitaoffertedaJADE.

Valutazionedi JADE.

JADE si ponecomeun veroe propriomiddlewareperagenti,e si basasuipotesisufficientementeminimali daessereutilizzatocomerun-timeperl’esecuzionede-gli agentiprevisti in D-CaseLP. Gli agentiJADE sonoagentiJava sviluppatiapartiredaunameta-architetturaaBehaviour. Talemeta-architetturaperagentiof-fre unbuoncompromessotrale esigenzedi controllodescrittein FIPA edi vincoli

155

impostidalmultithreadingJava, lasciandoall’utentela possibilitadi istanziarelameta-architetturasulle architettureper agentidescrittein letteratura.Al fine dipoterutilizzareJADE comemiddlewareper l’esecuzionedegli agentiprevisti inD-CaseLP, e necessariosupportaregli agentiAg-Prolog nellastessamanieraincui sonosupportatigli agentinativi JADE per permetteredi applicaregli stru-mentidi monitoringecontrolloanchesugliagentilogici. Taleesigenzahaportatoalla progettazionedell’integrazionedi agentiAg-Prolog in JADE.

Gli agentiAg-Prolog in JADE.

Prerequisitoaffinche siapossibileeseguiregli agentiAg-Prolog in JADE e l’in-tegrazionedi Prolog in Java. Si sonoanalizzatediverseimplementazioniPrologallo scopodi individuarneunacheoffrisseun’interfacciaversoJava bidirezio-nale e sufficientementeastrattada non pregiudicarela portabilita degli agenti.Tali requisiti sonosoddisfatti da tuProlog: un’interpreteProlog completamenterealizzatoin Java originariamentenato per scriverecomponentiintelligenti daimpiegarsiin applicazionichefannoutilizzo dellarete.

Attraversol’analisi di alcuniusecasee sfruttandole funzionalita di tuPrologsi eprogettataunaparticolareclassedi agentiJADE in gradodi incapsulareagentilogici definiti in termini di statoiniziale,programedengine.Taleagentipermet-tonodi eseguireagentilogici nellaplatformJADE usufruendodegli strumentidimonitoringecontrollochesi hannoadisposizionepergli agentinativi del tool.

Lavoro esviluppi futuri.

Il progettoe statosuddiviso in due parti ed attualmentevi sonodue tesi i cuiobiettivi constanonel

4 fornireunsupportometodologicoallaprogettazionedi agentiAg-UML (agen-ti specificatiin UML);

4 definire una libreria di componenticon l’ausilio delle quali fornire unatraduzionesemiautomaticain Ag-Prolog o Ag-Java;

4 arricchirela libreriadi componentidi alcunearchitettureperagentiottenutepartiredallameta-architetturaJADE.

Al di la di questedue tesi il lavoro da fare prima di ottenereun tool con irequisiticheci siamoprepostieancoralungo,indichiamoalcunedelleattivitachesi possonoprevedere:

4 implementazionedell’integrazionefra Ag-Prolog e platformJADE secon-do la progettazioneillustratain questatesi;

156

4 studio di strumentiper la simulazione,in particolarevalutazionedi stru-menti chepermettanodi simularecanalidi comunicazioneinaffidabili uti-lizzandole caratteristichedei MessageTransportFIPA;

4 studio di linee guida metodologicheed eventuali strumentiper l’integra-zionedel software legacy sulla basedelle specificheprodottedalla FIPAsull’argomento.

157

Elencodellefigure

1.1 Architetturagenerale.. . . . . . . . . . . . . . . . . . . . . . . . 91.2 La gerarchiaarchitetturalein CaseLP. . . . . . . . . . . . . . . . 101.3 ModelloaspiralepropostodaBohem. . . . . . . . . . . . . . . . 161.4 Tremodi peragentificarelegacy software. . . . . . . . . . . . . . 221.5 Schematizzazionedeiconcetticoncui vienecaratterizzatoil soft-

waredaWieringa. . . . . . . . . . . . . . . . . . . . . . . . . . . 251.6 Un primasuddivisionedel progettoD-CaseLP. . . . . . . . . . . 291.7 Iter seguito in M-CaseLP. . . . . . . . . . . . . . . . . . . . . . 331.8 Iter seguito in D-CaseLP. . . . . . . . . . . . . . . . . . . . . . 34

2.1 Il ReferenceModeldell’OMA. . . . . . . . . . . . . . . . . . . . 392.2 Componenticoinvolti in unacomunicazioneclient-serverCORBA. 412.3 FRT con evidenziatele funzionalita che sarannosupportatedal

primo prototipodi D-CaseLP. . . . . . . . . . . . . . . . . . . . 442.4 Un modopossibiledi perfar comunicaregli agenticonl’impiego

di placeholder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462.5 Integrazionedelleprimitivadi comunicazionenegli agentiproto-

tipali di D-CaseLP. . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.1 Missionstatementcostitutivo dellaFIPA. . . . . . . . . . . . . . 573.2 L’architetturaastrattae le suerealizzazioni(specifichedi realiz-

zazione).. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.3 La strutturadellaFIPA. . . . . . . . . . . . . . . . . . . . . . . . 623.4 Il lyfe-cycledellespecificheFIPA. . . . . . . . . . . . . . . . . . 643.5 Le classidi specifichedellaFIPA. . . . . . . . . . . . . . . . . . 653.6 Relazionetraarchitetturaastrattaeconcreta.. . . . . . . . . . . . 673.7 Coppiechiave-valorecontenutenelladirectoryentrydell’agente5 . 713.8 Chiave-valoredi ricerca. . . . . . . . . . . . . . . . . . . . . . . 713.9 La strutturaperunmessaggioFIPA. . . . . . . . . . . . . . . . . 733.10 Trasformazionedi un messaggioin unTransport-Message.. . . . 743.11 (a) Transport-Messageper la comunicazionetra ”123” e ”ABC”.

(b) Lo stessoTransport-Messagecriptato. . . . . . . . . . . . . . 75

158

3.12 Il modellodi riferimentoFIPA perla gestionedegli agenti. . . . . 763.13 AID tipo delDirectoryFacilitator. . . . . . . . . . . . . . . . . . 793.14 AID tipo delAgentManagementSystem. . . . . . . . . . . . . . 803.15 Il ciclo di vita degli agentiFIPA. . . . . . . . . . . . . . . . . . . 81

4.1 Aggiornamentodell’alberodellefunzionalitaD-CaseLP. . . . . 914.2 ProgettiOpenSourcedi tool perla realizzazionedi MAS aderenti

alle specifiched’interoperabilitaFIPA. . . . . . . . . . . . . . . . 924.3 L’interfacciagraficaconcui si accedonole funzionalitadel RMA. 964.4 L’interfacciagraficadello tool Sniffer. . . . . . . . . . . . . . . . 964.5 L’interfacciagraficadel tool Introspector. . . . . . . . . . . . . . 974.6 La gerarchiadei Behaviour in JADE. . . . . . . . . . . . . . . . 1024.7 Architetturadegli agentiJADE. . . . . . . . . . . . . . . . . . . 1054.8 Dettagliosulla l’iter di esecuzionedel progettoD-CaseLP con

l’ausilio di JADE. . . . . . . . . . . . . . . . . . . . . . . . . . . 1144.9 Confrontotra il supportooffertodaJADE eCORBA. . . . . . . . 1154.10 Confrontotra il supportoofferto daJADE e CORBA su funzio-

nalita cheprotrebberoessereinclusein un futuro prossimo.. . . . 116

5.1 Unoschemaperla traduzionein codiceeseguibiledaCaseLP. . . 1205.2 SintassiformaleperAgentRules . . . . . . . . . . . . . . . . . . 1215.3 La traduzionedelleistruzioniAgentRules. . . . . . . . . . . . . 1215.4 Associazionetra regoleAgentRules epredicati . . . . . . . . . . 1225.5 Finestraperl’inizializzazionedellemailboxes.. . . . . . . . . . . 1245.6 finestrachedescrive l’esecuzioneon line. . . . . . . . . . . . . . 1245.7 Tracciaoff-line delleesecuzioni.. . . . . . . . . . . . . . . . . . 1255.8 Dettaglidi un eventotracciato. . . . . . . . . . . . . . . . . . . . 1255.9 Istanziamodueteoriein tuProlog. . . . . . . . . . . . . . . . . . 1315.10 Interfacciaperaccedereagli oggettirappresentantiil motoreinfe-

renzialeProlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1315.11 InterfacciaSolveInfo peraccedereallesoluzioni. . . . . . . . . . 1325.12 Esempiodi programmaProlog cheistanziaedutilizzaunoggetto

Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1335.13 Schematizzazionedelle relazioni tra prototipi: (a) raffinamento,

(b) intersezione,(c) indipendenza. . . . . . . . . . . . . . . . . . 1365.14 Esempiodi comepotrebberoesserecoinvolti gli agentiin diversi

prototipi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1375.15 UsecaseperD-CaseLP forniamo. . . . . . . . . . . . . . . . . . 1425.16 Usecaseperscrivereagentilogici. . . . . . . . . . . . . . . . . . 1445.17 Dettagliosullo usecaseWriteArchitecture. . . . . . . . . . . . . 145

159

5.18 Il classdiagramchespiega comeintegrarele differenti compo-nentiperotteneregli agentiAg-Prolog. . . . . . . . . . . . . . . 153

160

Indice analitico

CORBAactivation,40activeobjectmap,40deactivation,40etherealization,40incarnation,40object,38objectId, 39servant,39skeleton,39stub,39

FIPA, 56FIPA ACL, 71AbstractArchitecture

AgentCommunicationLangua-ge,60

DirectoryService,60MessageTransportService,60

AgentIdentifier, 77AgentManagementSystem,79AgentPlatform,77AID, 77AMS, 79DF, 78Directoryentry, 70DirectoryFacilitator, 78DirectoryServices,70HAP, 78platform,66principi

minimalita,58openness,58

specifiche

life cycle,64organizzazione,65

tipo opaco,67JADE, 92

Architecture,104Behaviour, 102DummyAgent,95IntrospectorAgent,97Sniffer Agent,95

MAS, 63 ProlAg, 141ProlAg, 118Prolog

tuProlog,129FLI, 128

CORBAOMA Model,37

Agente,6agentideliberativi, 16agentireattivi, 16

Context Boundary, 24

DCaseLPToolACLtoMessageTemplate,107

Distribuzioneeffettiva,18

Environment,23

greenthread,101

multitasking,99multithreading,100

OMG, 37

161

openness,58

PatternMatching,32peer-to-peer, 47PrologACLCode,140

Sistemadi AgentiMultipli, 6SubjectDomain,23SystemBoundary, 24

thread,100Traciability, 26

162

Bibliografia

[1] AgentBuilder.ReticularSystems,Inc. http://www.agentbuilder.com/.

[2] The aliCE researchteam— DEIS - University of Bologna/Cesena,Italy.tuProlog Documentation, October2001.work in progress.

[3] E. Appiani, M. Martelli, and V. Mascardi. A Multi-Agent ApproachtoVehicleMonitoring in Motorway. TechnicalReportDISI TR-00-13,2000.

[4] F. Bellifemine,A. Poggi,andG. Rimassa.Developingmulti agentsystemswith JADE, 2001.

[5] FabioBellifemine,GiovanniCaire,TizianaTrucco,andGiovanniRimassa.JadeAdministrator’S Guide. CSELT S.p.a,July 2001. Copyright c

62000

CSELT S.p.A, c6

TILab 2001S.p.A.

[6] FabioBellifemine,GiovanniCaire,TizianaTrucco,andGiovanniRimassa.JadeProgrammer’SGuide. CSELT S.p.a,September2001. Copyright c

62000CSELT S.p.A, c

6TILab 2001S.p.A.

[7] Fabio Bellifemine, Agostino Poggi, and Giovanni Rimassa. JADE — AFIPA-compliantagentframework. In Proceedingsof the 4th InternationalConferenceonthePracticalApplicationsof AgentsandMulti-AgentSystems(PAAM-99), pages97–108,1999.

[8] FabioBellifemine,AgostinoPoggi,GiovanniRimassa,andPaolaTurci. Anobject-orientedframwork to realizeagentsystem.

[9] binprolog. BinNet Corporation.http://www.binnetcorp.com/BinProlog/.

[10] Rodney A. Brooks. Intelligencewithout reason.In RayMyopoulos,John;Reiter, editor, Proceedingsof the 12th International Joint ConferenceonArtificial Intelligence, pages569–595,Sydney, Australia, 1991. MorganKaufmann.

163

[11] Rodney A. Brooks. Intelligencewithout representation. Number 47 inArtificial Intelligence,pages139–159.1991.

[12] J. Brustoloni. Autonomousagents: Charaterizationand requirements.Technicalreport,Pittsburgh,1991.

[13] FrankMc Cabe.Sociologicalaspectof theinternetrevolution.FIPA inform!,1(3):3,2000.FIPA newsletters.

[14] P. Charlton,R. Cattoni, A. Potrich, and E. Mamdani. Evaluatingthe FI-PA standardsand its role in achieving cooperationin multiagentsystem.IEEE ComputerSociety, January2000. 33rd Annual Hawaii InternationalConferenceon SystemSciences(HICSS-33).

[15] L. Console,E. Lamma,andM. Milano. ProgrammazioneLogica e Prolog.UTET, 1997.

[16] A. Cuppari,P. L. Guida,M. Martelli, V. Mascardi,andF. Zini. An Agent-BasedPrototypefor FreightTrainsTraffic Management.In P. G. Larsen,editor, Proc. of FMERail Workshop5, Toulouse,France,September1999.Springer-Verlag.A satelliteworkshopof FM’99.

[17] A. Cuppari,P. L. Guida,M. Martelli, V. Mascardi,andF. Zini. PrototypingFreightTrainsTraffic ManagementUsingMulti-Agent Systems.In Proc.ofIEEE International Conferenceon Information, Intelligenceand Systems,Washington,DC, November1999.IEEE.

[18] R. Degl’Innocenti. UML comelinguaggioper specificareagenti: analisi,estensioneedintegrazionein CaseLP.Master’s thesis,DISI – UniversitadiGenova,Genova,Italy, 2000. In Italian.

[19] G. Delzanno.Logic & Object-OrintedProgrammingin Linear Logic. PhDthesis,Universitaof Pisa,Dipartimentodi Informatica,December1996.

[20] Enrico Denti, AndreaOmicini, andAlessandroRicci. tuProlog: A light-weightPrologfor Internetapplicationsandinfrastructures.In I.V. Ramakri-shnan,editor, Practical Aspectsof DeclarativeLanguages, volume1990ofLNCS, pages184–198.Springer-Verlag,2001.3rdInternationalSymposium(PADL 2001),LasVegas(NV), 11–12March2001.

[21] ECLiPSE. c6

IC-Parc 1997-2001,http://www.icparc.ic.ac.uk/eclipse/index.html.

164

[22] T. Finin,R.Fritzson,D. McKay, andR.McEntire.KQML asanAgentCom-municationLanguage.In Proceedingsof the3rd InternationalConferenceon Information and Knowledge Management(CIKM’94), pages456–463,Gaithersburg, Maryland,1994.ACM Press.

[23] FIPA Home Page. Foundation for Intelligent Physical Agents.http://www.fipa.org/.

[24] Foundationfor Intelligent PhysicalAgents. FIPA ACL Message StructureSpecification, August2000.FIPA, ApprovedFor Experimental01-08-2000.

[25] Foundationfor IntelligentPhysicalAgents.FIPA AgentSoftwareIntegrationSpecification, August2000.FIPA, ApprovedFor Experimental14-06-00.

[26] Foundation for Intelligent Physical Agents. FIPA Ontology ServiceSpecification, June2000.FIPA, ApprovedFor Experimental15-06-2000.

[27] Foundationfor Intelligent PhysicalAgents. FIPA Abstract ArchitectureSpecification, February2001.FIPA, ApprovedFor Experimental29-01-01.

[28] Foundation for Intelligent Physical Agents. FIPA Agent ManagementSpecification, August2001.FIPA, ApprovedFor Experimental15-08-01.

[29] Foundationfor IntelligentPhysicalAgents.FIPA AgentMessageTransportServiceSpecification, August2001. FIPA, ApprovedFor Experimental15-08-01.

[30] Foundationfor Intelligent PhysicalAgents. FIPA CommunicativeAct Li-brary Specification, October 2001. FIPA, Approved For Experimental29-01-2001.

[31] GraesserFranklin. Is it an agent,or just a program?: A taxonomyforautonomousagents.Technicalreport,1996.

[32] Michael R. Geneserethand Steven P. Ketchpel. Software agents.Communicationsof theACM, 37(7):49–53,July1994.

[33] GNU PROLOG. ftp://ftp.inria.fr/INRIA/Projects/loco/gnu-prolog/.

[34] O. Inc. Orbacusfor C++ andJava, 1998.

[35] N. R.Jennings,K. Sycara,andM. Wooldridge.A roadmapof agentresearchanddevelopment.Journal of AutonomousAgentsandMulti-AgentSystems,1(1):7–38,1998.

165

[36] Jinni. BinNetCorporation.http://www.binnetcorp.com/Jinni/.

[37] jprolog. http://www.cs.kuleuven.ac.be/bmd/PrologInJava/.

[38] David Kinny, MichaelGeorgeff, andAnandRao. A methodologyandmo-dellingtechniquefor systemsof BDI agents.In RudyvanHoe,editor, Seven-th EuropeanWorkshopon Modelling AutonomousAgentsin a Multi-AgentWorld, Eindhoven,TheNetherlands,1996.

[39] RobertA. Kowalski and Fariba Sadri. From logic programmingtowardsmulti-agentsystems. Annals of Mathematicsand Artificial Intelligence,25(3-4):391–419,1999.

[40] M. Martelli, V. Mascardi,andF. Zini. CaseLP:aComplex ApplicationSpe-cificationEnvironmentBasedon Logic Programming.In Proc.of ICLP’97PostConferenceWorkshoponLogic ProgrammingandMulti–Agents, pages35–50,Leuven,Belgium,July1997.

[41] M. Martelli, V. Mascardi,andF. Zini. A Logic ProgrammingFrameworkfor Component-BasedSoftwarePrototyping. In A. Brogi andP. Hill, edi-tors, Proc. of 2nd International Workshopon Component-basedSoftwareDevelopmentin ComputationalLogic (COCL’99), Paris,France,September1999.

[42] M. Martelli, V. Mascardi,and F. Zini. Specificationand Simulation ofMulti-Agent Systemsin CaseLP. In M. C. Meo andM. Vilares-Ferro,edi-tors, Proc. of Appia–Gulp–Prode1999: Joint Conferenceon DeclarativeProgramming, pages13–28,L’Aquila, Italy, September1999.

[43] V. Mascardi. CaseLP, Logic-BasedSpecificationEnviromentsFor Multi-Agent Systems. PhD thesis, Universita of Genova, Dipartimento diInformaticaeScienzedell’Informazione,December2001.

[44] D. Miller. Forum: A multiple-conclusionspecificationlogic, 1996.

[45] MINERVA. http://www.ifcomputer.co.jp/MINERVA/homeen.html.

[46] MokeByte. TheMoka Book, 2001. MokaBook c6

2001- MokaBytes.r.l.http://www.mokabyte.it/mokabook/.

[47] HyacinthS.NwanaandDivineT. Ndumu.A perspectiveonsoftwareagentsresearch.TheKnowledgeEngineeringReview, 14(2):1–18,1999.

166

[48] Object ManagementGroup. Unified Modelling Language Specifi-cation, version 1.3, March 2000. OMG document formal/00-03-01.URL: http://cgi.omg.org/cgi-bin/doc?formal/00-03-01.ps.gz.

[49] Object Oriented Concept Inc. The Orbacus Homepage, 2000.http://www.ooc.com/ob/.

[50] M. De Pedrini. CaseLP Visualizer: un tool di visualizzazioneper sistemiMulti-agente. Master’s thesis,DISI – Universita di Genova, Genova, Italy,1998. In Italian.

[51] J.Pitt,A. Mamdani,andP. Charlton.Theopenagentsocietyandits enemies:apositionstatementandresearchprogramme.In TelematicsandInformatics,volume18, pages67–87.PERGAMON,January2001. c

62001Elsevier

ScienceLtd.

[52] Stefan PosladandPatricia Charlton. Standardizingagentinteroperability:The FIPA approach. In M. Luck et al, editor, Multi-Agent SystemsandApplications, volume 2086, pages98–117,Prague,CzechRepublic,July2001.Springer-Verlag.9thECCAI AdvancedCourseACAI 2001andAgentLink’s3rd EuropeanAgentSystemsSummerSchool,EASSS2001.

[53] A. S.RaoandM. P. Georgeff. BDI-agents:from theoryto practice.In Pro-ceedingsof theFirst Intl. ConferenceonMultiagentSystems, SanFrancisco,1995.

[54] D. Schmidt and S. Vinoski. Object interconnections: Conceptsandterminology, Oct 1997.

[55] SICStus Prolog. SICSAB. http://www.sics.se/sicstus.html.

[56] SWI-Prolog. http://www.swi.psy.uva.nl/projects/SWI-Prolog/.

[57] tuProlog.http://lia.deis.unibo.it/research/2P/.

[58] tuProlog JavaDoc API Documentation.http://lia.deis.unibo.it/research/2P/javadoc/index.html.

[59] Steve Vinoski. CORBA: Integrating diverseapplicationswithin distribu-ted heterogeneousenvironments. IEEE CommunicationsMagazine, 14(2),1997.

[60] SteveVinoski. New featuresfor CORBA 3.0.Communicationsof theACM,41(10),1998.

167

[61] Jan Wielemaker. A CORBA IDL compiler for SWI-Prolog. University of Amsterdam, The Netherlands.http://www.cs.vu.nl/eliens/documents/corba/pl/plcorba.html.

[62] R.J.Wieringa. DesignMethodfor ReactiveSystems. Universityof Twente,2000.

[63] M. WooldridgeandN. R.Jennings.IntelligentAgents:TheoryandPractice.TheKnowledge EngineeringReview, 10(2):115–152,1995.

[64] Word Wide WebConsortium.ExtensibleMarkupLanguage(XML). W3CWorkingDraft availableathttp://www.w3.org/TR/xml.

[65] TheZeusAgentBuilding Toolkit. British Telecommunications.http://www.labs.bt.com/projects/agents/zeus/.

[66] F. Zini. CaseLP, a RapidPrototypingEnvironmentfor Agent-BasedSoft-ware. PhD thesis,Universita of Genova, Dipartimentodi Informatica eScienzedell’Informazione,December2000.

168