UNIVERSITA DEGLI STUDI DI BARI

Transcript

1 UNIVERSITA DEGLI STUDI DI BARI FACOLTA DI SCIENZE MATEMATICHE, FISICHE E NATURALI CORSO DI LAUREA IN INFORMATICA TESI DI LAUREA IN ARCHITETTURA DEGLI ELABORATORI AGENTI AUTONOMI UBIQUI Relatore: Prof.ssa Berardina DE CAROLIS Laureando: Ignazio PALMISANO Anno Accademico

2 Dedicato ai miei genitori, perché lo hanno reso possibile, ai miei amici, perché senza di loro non sarebbe stata la stessa cosa, e a chi ci ha creduto.

3 Capitolo 1: Ubiquitous computing Introduzione La novità dell Ubiquitous computing L impatto nella vita quotidiana... 6 Capitolo 2: Autonomia e ragionamento Agenti ubiqui Agenti BDI Autonomia e delega Definizione di agente autonomo Il nostro approccio Categorizzazione dell autonomia Come l utente interagisce con gli agenti Modalità di comportamento del MainAgent Meccanismi di ragionamento autonomo Definizione di ragionamento automatico Regole per la descrizione del grafo di una FSM Influenza dell autonomia sul ragionamento Feedback: Incidenza del comportamento dell utente sull autonomia Meccanismi di feedback Modifica delle regole di inferenza Modifica del profilo utente Capitolo 3: Caratteristiche strutturali Piattaforma di implementazione JADE: descrizione generale

4 3.1.2 LEAP: descrizione generale D-Me: descrizione generale La ToDoList Capitolo 4: Architettura D-Me Thinking: ontologie e pensiero Le ontologie in JADE Le ontologie in D-Me Meccanismi di ragionamento basati su task Descrizione dei protocolli utilizzati Protocolli di registrazione Protocolli di ricerca di un agente: Protocollo di richiesta di uno UserConcept: Protocollo di esecuzione di un service di ricerca generico: Capitolo 5: Dettagli sul funzionamento Struttura della mente dell agente D-Me Accesso ai dati permanenti Scambio di messaggi: il MainReceiver Esecuzione dei Desires: agente BDI Esecuzione di un task e generazione di nuovi task Inferenza di nuovi task: trasformazione XSL Capitolo 6: Caso di studio Gestione della ToDoList Aggiunta di task impliciti Task ad alto livello di autonomia

5 6.2.2 Task a basso livello di autonomia Gestione del feedback Conclusioni Bibliografia

6 Capitolo 1: Ubiquitous computing - I need a PC here - You just turn around, and you ll get it in front of you - Yes, I know, but I need it here! 1.1 Introduzione Lo scopo di questa tesi è ampliare un progetto già esistente (il sistema D-Me [11], [17], [18]), per introdurre il trattamento esplicito del concetto di autonomia. Il sistema D-Me è un sistema multiagente (MAS - MultiAgent System) implementato interamente in Java, che sfrutta la piattaforma JADE (Java Agent DEvelopment Framework) per la definizione, creazione e gestione dei suoi agenti. In tale ambiente, ogni utente che interagisce con il sistema è rappresentato da un agente, chiamato MainAgent, che riceve dall utente la delega ad agire come tramite tra l utente stesso e gli altri agenti presenti nel sistema, allo scopo di realizzare i compiti che gli vengono affidati dall utente e gli obiettivi propri dell agente. Vedremo più avanti una descrizione precisa dei meccanismi di ragionamento che il MainAgent utilizza per perseguire i propri obiettivi. 4

7 1.2 La novità dell Ubiquitous computing Ubiquitous computing è il nome che è stato dato al fenomeno in cui si assiste in questi anni: l invasione (pacifica) dei computer. Fino a non molto tempo fa, il modo classico di immaginare i computer era: Sulla mia scrivania, c è una grossa macchina da scrivere capace di fare anche i conti. Quando ne ho bisogno, l accendo e la uso, poi mi alzo e torno al lavoro normale. Negli ultimi tempi, il numero dei computer è cresciuto in maniera impressionante, e di pari passo sono aumentate le funzionalità che la macchina da scrivere mette a disposizione, fino al punto da poter dire che i computer sono ovunque e fanno di tutto. Come dice Negroponte[1], Computing is not about computers anymore. It is about living. Negli ultimi tempi, troviamo computer, e più in generale processori, anche nei frigoriferi [2], nei televisori, nelle automobili. A questo punto diventa imperativo capire qual è il modo migliore per far comunicare i device intelligenti, sia tra loro che con l utente finale. La comunicazione tra device è ormai talmente necessaria che i colossi dei vari rami (elettrodomestici e in generale appliances per la casa) stringono veri e propri patti di collaborazione, come la già citata WhirlPool con la Nokia [3] per sviluppare in joint venture nuove soluzioni. L obiettivo finale, secondo Weiser [4], è quello di fornire all utente applicazioni flessibili, sensibili al contesto, all esperienza accumulata dall utente, addirittura al suo stato emotivo. 5

8 1.3 L impatto nella vita quotidiana Considerando l impatto di questa rivoluzione tecnologica sugli utenti, emergono alcuni problemi fondamentali: non tutti gli utenti hanno le stesse competenze, e solo pochi sono in grado di gestire la complessità dell interazione tra tutti i sistemi elettronici che è possibile trovare in un ambiente intelligente. La presenza di servizi ovunque e in qualunque situazione impone un diverso modo di pensare agli utenti, che sono quindi costretti a un cambio di paradigma nel porsi di fronte alle novità tecniche. Inoltre, la complessità derivante dalla quantità di tecnologia presente in ogni casa finisce per spaventare molti utenti, i quali, imparate le funzioni di base di un elettrodomestico, smettono di curiosare, e quindi non sfruttano appieno le potenzialità di ciò che hanno acquistato. E essenziale, perché le innovazioni tecnologiche siano utili alla società e non restino banali giocattoli, permettere all utente di sfruttare tutti i servizi disponibili in maniera semplice e naturale. Per far ciò, è necessario che l utente abbia la possibilità di delegare a qualcun altro la parte difficile dell utilizzo delle risorse di calcolo a sua disposizione, o meglio la parte noiosa : dal riconoscimento automatico delle periferiche disponibili, concetto che nell ambito dell Ubiquitous Computing si evolve diventando riconoscimento automatico dei dispositivi e delle funzionalità offerte, aggiornato momento per momento, alla configurazione di queste ultime. Il qualcun altro in questione, che Negroponte identificava, sempre in [1], con la cognata appassionata di cinema, è rappresentato da un programma il cui scopo principale è eseguire, facendo le veci dell utente, i compiti che l utente gli delega. 6

9 Si configurano quindi nuovi spunti di ricerca: In che misura l utente delega al programma i propri poteri per l esecuzione di questi compiti? Qual è il grado di autonomia con cui il programma può affrontare l esecuzione di questi compiti? Lo scopo di questa tesi è fornire un analisi di alcuni dei metodi possibili per la gestione esplicita di questo modello, e un prototipo funzionante che ne mostri l effettiva implementazione. 7

10 Capitolo 2: Autonomia e ragionamento 2.1 Agenti ubiqui Date le caratteristiche principali che il nostro programma deve avere, tra i vari paradigmi di progettazione per la realizzazione di un sistema reale bisogna trovarne uno che (possibilmente) risponda ai requisiti salienti del sistema: La capacità di rispondere in maniera flessibile agli stimoli, sia quelli derivanti dal contesto in cui il programma si trova ad operare che quelli provenienti dall utente Le sue caratteristiche di autonomia. Quest ultima in particolare ha orientato la scelta verso il paradigma di progettazione e realizzazione Agent-Oriented. Un agente è un sistema (incapsulato) situato in un ambiente, capace di azioni autonome e flessibili, in quell ambiente, per raggiungere i suoi obiettivi di progetto [6] La prima parte di questa definizione è calzante anche per il paradigma Object- Oriented, che infatti ha molti punti in comune con il paradigma ad agenti: dal punto di vista implementativo, infatti, esistono svariate implementazioni di agenti come oggetti particolari, che basano le loro caratteristiche di autonomia sull incapsulamento di dati e metodi, tipico degli oggetti. 8

11 Tuttavia, il paradigma Agent-Oriented si distingue per la seconda parte della definizione: un agente non è un oggetto passivo, ma è in grado di ragionare sui propri obiettivi e di compiere le azioni necessarie a raggiungerli; esso è quindi intelligente e proattivo. In questo contesto, intelligenza e proattività sono strettamente legate: se la proattività è la capacità di prendere decisioni dirette dalla volontà di raggiungere un set di obiettivi, o goal, allora l intelligenza è il meccanismo (il ragionamento automatico) che permette la realizzazione della decisione (analisi della situazione e scelta tra le varie alternative). Queste caratteristiche rendono questo paradigma idoneo alla progettazione di sistemi di ubiquitous computing. Esse consentono all utente di poter specificare i suoi desideri usando un linguaggio ad alto livello (idealmente il linguaggio naturale), e quindi in modo semplice. Sarà poi competenza dell agente decidere quale strategia adottare e quali servizi dell ambiente utilizzare per soddisfare i bisogni dell utente. In particolare, con riferimento a quanto riassunto da Flores-Mendez in [7], il tipo di agente che appare più adatto ad interagire con l utente per soddisfarne i bisogni è un agente che realizza la weak notion of agency, vale a dire che soddisfa la definizione di Jennings e Woolridge [8]: si tratta quindi di un agente: Autonomo: opera senza il diretto intervento dell utente, e ha controllo sulle proprie azioni e stati interni Sociale: interagisce con altri agenti (potenzialmente umani) attraverso un linguaggio per la comunicazione tra agenti Reattivo: percepisce l environment e reagisce ai cambiamenti 9

12 Proattivo: in grado di prendere l iniziativa per raggiungere i propri goal Lasciamo quindi da parte le caratteristiche che Woolridge e Jennings considerano specifiche della strong notion of agency, come stati emozionali e carattere dell agente (le caratteristiche che di solito associamo ad agenti umani). 2.2 Agenti BDI In precedenza, abbiamo descritto il sistema D-Me come un MAS, cioè un MultiAgent System, che è un sistema che rispetta le seguenti caratteristiche [9]: ogni agente ha delle capacità, ma esse sono insufficienti al completamento del task non c è un meccanismo globale di controllo i dati non sono centralizzati la computazione è asincrona Per far ciò, il MainAgent già esistente nel sistema (il rappresentante dell utente) è strutturato secondo l approccio BDI (Beliefs-Desires-Intentions), come descritto in [10]. In questo approccio, l agente basa il proprio comportamento su tre elementi: Beliefs: le credenze dell'agente Desires: i desideri dell agente Intentions: le intenzioni dell agente per soddisfare i suoi desideri 10

13 E possibile notare un parallelismo tra il modo in cui è strutturato un agente BDI e la mente umana; infatti, l uomo ragiona nello stesso modo, eseguendo delle Intentions, appropriate ai Beliefs, per raggiungere i suoi gola, cioè i suoi Desires. 2.3 Autonomia e delega Il problema di dare una definizione teorica valida per il concetto di autonomia e di delega è stato affrontato da Castelfranchi e Falcone in [5], che hanno basato il loro modello sull idea che è necessario esplicitare i concetti di autonomia e delega, estrapolandoli quindi dal codice ed astraendo dalla particolare implementazione, in modo che sia possibile per l utente mantenere il controllo dell interazione, pur non facendosi carico dei compiti più onerosi o che richiedono maggior attenzione o prontezza di riflessi (i compiti che tipicamente un computer sa eseguire meglio di un essere umano). In particolare, essi distinguono l autonomia in due tipologie: Metaautonomia sulla negoziazione del servizio : è l autonomia che viene conferita al programma al momento della negoziazione del servizio, cioè la sua libertà di contrattazione dell autonomia di realizzazione. Autonomia di realizzazione : essa si situa a un livello più basso, cioè al livello dell esecuzione del compito delegato, e si riferisce alla libertà di iniziativa dell agente nell esecuzione delle varie porzioni in cui può essere 11

14 diviso il compito assegnato, o task; essa riguarda quindi l interazione con altri agenti, con dispositivi fisici, la deduzione di dati non esplicitamente introdotti dall utente, l avvio di sottotask non indispensabili per l esecuzione del task principale ma ritenuti utili all utente, e l eventuale mancata esecuzione di alcune parti del task esplicitamente richieste. Su tale base si configurano delle variazioni nel tipo di aiuto fornito dal programma all utente, che si possono classificare considerando tre categorie: OverHelper : il programma può eseguire un task, rappresentato come un piano, che include il task iniziale e altri sottotask ritenuti utili SubHelper : il programma può limitarsi a eseguire solo una porzione del piano originale CriticalHelper : il programma può anche decidere di attuare un piano diverso da quello definito dall utente, spinto a ciò da limiti di tipo ambientale o da constraints imposte da un autorità superiore a quella dell utente, come potrebbe essere, ad esempio, la presenza di filtri per contenuti non adatti ai minori nell accesso a risorse su web. 12

15 2.4 Definizione di agente autonomo L autonomia è la caratteristica che distingue un programma da un agente: essa è la capacità di scegliere tra più alternative (flusso di controllo o valori da assegnare a una variabile), necessaria perché l agente non debba dipendere da un altra entità esterna ad esso. Come in [14], un agente autonomo è un agente che ha controllo sulle proprie azioni. In base alla definizione di agente, secondo cui un agente è un entità in grado di percepire l ambiente attraverso dei sensori, e agire su di esso con degli attuatori [14], si possono escludere dispositivi del mondo fisico che rientrano nella prima definizione, ma che è eccessivo considerare agenti (per esempio, un termostato). Castelfranchi e Falcone considerano, per la trattazione teorica della delega e dell autonomia nelle interazioni tra agenti i seguenti insiemi: un insieme di atti o azioni: gli atti che un agente può mettere in esecuzione un insieme di agenti: gli agenti che popolano l ambiente, e che possono comunicare tra loro una libreria di piani: i piani per l esecuzione degli obiettivi Con questi insiemi di primitive, si può considerare il piano (o il bisogno) che un agente (o l utente) A sta cercando di soddisfare come un piano MA 13

16 (MultiAgente), in cui parte del piano è affidata ad altri agenti (S) che il primo agente può contattare. In tal senso, questi ultimi agenti hanno un goal, nella loro azione, limitato al goal dell agente che ha richiesto aiuto, comportandosi quindi da serventi (questi agenti non prendono iniziative, all interno della loro porzione di piano; si limitano ad eseguire quanto richiesto, rispettando lo spirito cooperativo dell ambiente). Nel modo in cui l agente servente viene incluso nel piano, è possibile distinguere tre casi diversi: Weak delegation : l agente A sfrutta i servizi offerti da un agente S, senza influenzare la sua autonomia (S è completamente autonomo); Mild delegation : l agente A non esegue una richiesta, ma crea le condizioni per cui S si senta spinto ad eseguire l azione che A desidera Strong delegation : in tal caso, è esplicita sia la richiesta che l accettazione del task, cioè vi è una contrattazione esplicita tra A e S, con evevntuale negoziazione del livello di autonomia di S per l esecuzione del task. Si introducono quindi tre operatori, uno per ognuno dei tre casi: W-Delegates (A S P): A weak-delegates P (il piano o porzione di piano) to S M-Delegates (A S P): A mild-delegates P to S S-Delegates (A S P): A strong-delegates P to S D altra parte, è possibile considerare due modi in cui S può intraprendere l azione: 14

17 Weak-adoption : si verifica quando S crede che A abbia bisogno di una particolare azione da parte sua, e decide di eseguirla. Non è detto che ci sia comunicazione esplicita tra S e A, e neanche che A utilizzi i risultati prodotti da S. In questo caso, A potrebbe aver attuato una weak-delegation o una mild-delegation, o anche nessuna delegation. Strong-adoption : si verifica quando S esegue l azione dopo aver ricevuto una richiesta ed aver negoziato il task con A. In tal caso, è necessario che da parte di A ci sia stata una strong-delegation E possibile anche introdurre una distinzione sul livello di dettaglio a cui è specificato il piano di A che S deve eseguire: Close-delegation : il piano è completamente specificato. Open-delegation : il piano non è completamente specificato, per cui a S è lasciata più autonomia su come realizzare quelle parti del paino che non sono dettagliate. Control-based delegation : viene specificato il controllo che A esercita su S. A livello di negoziazione (delega/accettazione) è possibile che vi siano delle modifiche al piano o al goal sia da parte di S che di A: Da parte di S: SubHelp : S realizza solo una parte del piano originario OverHelp : S non cambia il piano, ma adotta come proprio goal un goal di livello più alto 15

18 CriticalHelp : S raggiunge lo stesso goal, ma cambia il piano, considerando una soluzione alternativa Dal punto di vista di A: SubHelp : analogamente al caso precedente, A riduce il piano che S deve eseguire OverHelp : A aumenta la dimensione del piano che S deve eseguire, considerando un piano che va oltre gli obiettivi precedenti CriticalHelp : A modifica il piano, delegando a S una soluzione alternativa al piano precedentemente negoziato, ma con lo stesso goal OpeningDelegation : A delega a S un piano più astratto del precedente ClosingDelegation : A delega ad S un piano meno astratto, specificato a un livello più basso In base a queste possibili situazioni di modifica della delega, l autonomia dell agente S viene variata: essa può essere variata a livello della negoziazione del piano, oppure a livello dell autonomia di realizzazione, del livello di controllo o del tipo di delega/accettazione. In tutti questi casi, si può dire: Se a variare la delega è S, la sua autonomia di negoziazione deve variare sempre: infatti, è S a prendere l iniziativa di variare la delega; invece, non è detto che vari la sua autonomia di realizzazione Se a variare la delega è A, l autonomia di negoziazione di S non cambia mai; infatti, le ragioni che spingono A a modificare la delega non influenzano S. E possibile invece che venga modificata l autonomia di realizzazione di S: ciò 16

19 avviene nel caso in cui A attua la ClosingDelegation, specificando un piano più a basso livello, e di fatto limitando l autonomia di S nell esecuzione 2.5 Il nostro approccio L idea alla base del sistema multiagente, che sarà presentato in dettaglio nel capitolo 3, è quella di rappresentare l utente attraverso un agente del sistema, che chiameremo MainAgent. In quanto rappresentante dell utente, il MainAgent gioca il ruolo di A nell intraprendere un piano ad alto livello; esso, tuttavia, può anche agire da servente per un altro agente MainAgent o per un ServiceAgent, in determinate condizioni; ad esempio, può accadere che uno degli utenti desideri conoscere un particolare concetto; può allora richiedere a un altro utente, e quindi al suo MainAgent, di fornire le informazioni richieste. Possiamo considerare l autonomia del MainAgent come una funzione in uno spazio multidimensionale. Tale funzione non è conosciuta con precisione, poiché è problematico stabilire quante siano le dimensioni e se sia possibile applicare a queste dimensioni metriche discrete o continue; per ovviare a questo problema, abbiamo effettuato delle scelte, in parte arbitrarie, su tipo e numero di dimensioni. Considereremo quindi una proiezione di tale funzione, scegliendo un numero di dimensioni e fissando una metrica discreta per tali dimensioni. Otterremo (in base a come si vuole che il sistema risponda all utente) un insieme di valori che 17

20 rappresentano una mappatura parziale della funzione. In particolare, cercheremo di mettere in evidenza quei punti in cui i valori della funzione determinano un comportamento interessante (per il nostro campo d indagine) dell agente: punti in cui il livello di autonomia permette al sistema di generare un nuovo task (prevedendo le necessità dell utente e cercando di anticiparle, comportandosi quindi in modo proattivo) punti in cui il livello di autonomia è insufficiente per l esecuzione del piano originario, e ciò costringe il sistema a cambiarlo e a introdurre una richiesta all utente per ottenere l autorizzazione all esecuzione di un particolare compito. In tali condizioni limite, infatti, verrà evidenziato il modo in cui il sistema modifica esplicitamente la sua autonomia, in relazione all ambiente e all utente che utilizza il sistema Categorizzazione dell autonomia Considerando l autonomia di un agente, abbiamo già visto che emerge la necessità di considerare diverse dimensioni [5] e diversi livelli di autonomia, con riferimento a una metrica ben definita. E possibile considerare un numero finito di livelli, dal punto di vista quantitativo, e un numero finito di dimensioni, dal punto di vista qualitativo. Dato che non è possibile definire un numero massimo di dimensioni, a causa della molteplicità di ambienti e di tipologie di agenti, né un numero massimo di livelli, 18

21 poiché la granularità appropriata potrebbe essere differente al variare sia dell ambiente che dell agente, è necessario scegliere un sottoinsieme di dimensioni e livelli di autonomia per il particolare sistema. Tale sottoinsieme va scelto in modo da mettere in evidenza le caratteristiche peculiari che si vogliono studiare, che saranno quindi il più possibile tra loro ortogonali, cioè indipendenti. In questa tesi, prenderemo in considerazione le seguenti dimensioni (variazione qualitativa): Autonomia di esecuzione : quanta autonomia ha un agente, quando deve eseguire una particolare azione (ad esempio, intraprendere un determinato compito senza richiedere conferma all utente sia per l esecuzione che per i parametri necessari se mancanti, dedotti dalla base di conoscenza - )? Autonomia di comunicazione : quanta autonomia ha un agente, quando vuole comunicare con l utente? L agente può prendere l iniziativa di comunicare con l utente in ogni momento o esistono delle constraints dettate dall ambiente o dall utente? Quanto deve essere invadente la comunicazione? Per questa particolare dimensione, sorge anche il problema di determinare quanto un certo messaggio sia invadente. Tale concetto è fondamentale per una trattazione organica, ma, mancando del background di analisi psicologica, per semplicità considereremo questa dimensione alla stregua delle altre. 19

22 Autonomia di diffusione di dati personali : l agente può svolgere di propria iniziativa compiti che richiedono la diffusione di dati personali? Se sì, quali, e in che misura? Autonomia di sfruttamento risorse : l agente può utilizzare, per eseguire i propri task, risorse dell utente (come il numero della carta di credito oppure il suo tempo fissare appuntamenti, per esempio - )? Per ognuna di queste dimensioni, scegliamo una suddivisione dei possibili valori in quattro categorie: null : nessuna autonomia; il sistema deve attenersi strettamente a quanto ordinato dall utente, e qualunque variazione al piano o dato mancante deve essere esplicitamente richiesto low : livello di autonomia bassa; il sistema può prendere iniziative che riducano il piano originario. Per esempio, in caso di fallimenti di sottopiani, ma deve evitare di prendere iniziative; le deduzioni devono essere tutte sottoposte all utente per approvazione middle : livello di autonomia media; le iniziative che il sistema può prendere sono più numerose che nel caso precedente, e non deve essere immediatamente notificato all utente che per i suoi dati sono state effettuate delle deduzioni dalla base di conoscenza high : livello di autonomia massima; il sistema ha la più ampia libertà di azione possibile, fermi restando gli eventuali vincoli imposte dall utente (ad esempio, limiti massimi di spesa) 20

23 2.5.2 Come l utente interagisce con gli agenti L interazione dell utente con l agente che lo rappresenta (e che quindi maschera la complessità del sistema, presentandosi come unica entità all utente) è basata sul concetto di task, vale a dire di azione che l utente desidera che l agente svolga. Uno dei Desire dell agente è appunto Eseguire i task dell utente nell ambiente opportuno. L utente vede un task come voglio che il sistema esegua questo compito, dove il compito può essere prenota un esame, prenota una vacanza, avvisami se ho dimenticato di comprare qualcosa al supermercato, e via dicendo, ovviamente fornendo al sistema le informazioni essenziali per l esecuzione di questi task. Da parte sua, il sistema opera una valutazione dei task per stabilire quali dati sono effettivamente necessari e quali possono essere dedotti (dalla storia delle interazioni passate oppure da specifici dati relativi a ciò che il sistema sa dell utente), basando quindi le sue richieste di dati sulla conoscenza dell utente. In tal modo, si semplificano notevolmente le procedure richieste all utente per l esecuzione di un task, fornendo l equivalente di un wizard che propone come valori di default quelli che più sono vicini alle caratteristiche dell utente. Inoltre, dato che la modellazione dell utente è un attività continua, perché per sua natura evolve col passare del tempo, il modello dell utente varia tenendo conto di ciò che l utente fa: sia il wizard per la generazione dei nuovi task che l interfaccia utente forniscono quindi un feedback al sistema, permettendo di rendere il modello 21

24 dell utente, e di conseguenza il ragionamento, più vicino a quello di cui l utente ha bisogno Modalità di comportamento del MainAgent Il livello predefinito di aiuto dell agente MainAgent nei confronti dell utente è, secondo la categorizzazione vista prima, quello di OverHelper : l agente quindi esegue tutto ciò che l utente ordina esplicitamente, e in più prende l iniziativa di eseguire nuovi task, generati automaticamente, se crede che l utente abbia necessità di tali servizi, cioè se le sue regole di ragionamento deducono dall input implicito (cioè dalle caratteristiche dello User Model[20] e del Context Model[19], che vedremo più avanti) che uno o più nuovi task devono essere intrapresi. Tale modalità di aiuto può essere modificata durante l utilizzo del sistema, sia automaticamente (l agente adatta l esecuzione dei propri task in rispetto ad alcune condizioni ambientali o dell utente), sia con ordini espliciti dell utente (ad esempio, l utente può disabilitare tutti i messaggi, per un certo periodo di tempo, se è impegnato in qualche attività per cui non può essere disturbato). 22

25 2.6 Meccanismi di ragionamento autonomo Definizione di ragionamento automatico Il ragionamento automatico che considereremo in questo contesto, come già evidente dalla scelta di un agente BDI, è basato sul modello di un sistema a produzioni: vi saranno quindi regole formalizzabili come ( (Condizione 1) AND (Condizione 2) AND (Condizione n) ) Azione. La strategia per il raggiungimento del goal che utilizzeremo è volutamente semplice. Questa scelta è motivata dalla complessità computazionale dell intero sistema D-Me e del framework JADE (che vedremo in dettaglio nel Capitolo 3), unita alla penalizzazione di prestazioni dovuta all utilizzo del linguaggio Java e quindi alla necessità dell utilizzo di una Virtual Machine. Tuttavia, il progetto del sistema non preclude l utilizzo di una strategia più complessa; è sufficiente modificare la classe che implementa la strategia di ragionamento (ThinkBehaviour) e le classi che rappresentano i Desires e le Intentions (Desire e Intention rispettivamente). 23

26 Abbiamo optato per una strategia a un solo passo. Le regole di ragionamento (le Intentions dell agente) prevedono la possibilità di realizzare il Desire (o goal) direttamente, utilizzando come unico operatore la sequenza, e senza consentire la nidificazione delle Intentions. Inoltre, non è previsto un meccanismo di backtracking a livello di Intentions. A livello di descrizione dei task, invece, è possibile rappresentare un task complesso come una FSM (Finite State Machine, macchina a stati finiti), per la quale ogni stato è rappresentato dall esecuzione di un sottotask, che a sua volta può essere un task complesso o un task elementare. A seconda dell esito, positivo o negativo, di un sottotask, il task principale può prevedere una strada alternativa per raggiungere il proprio scopo. Attualmente, il sistema non prevede la possibilità che la struttura dei task possa essere modificata dinamicamente (creando quindi una vera struttura di ragionamento, in sostituzione all uso di piani preordinati e statici), ma è possibile sviluppare il sistema in tal senso, adattando la classe CompositeTaskActuator. Vediamo la struttura gerarchica dei vari tipi di task: (Figura 2.1) 24

27 Figura 2.1 In particolare, la lista SubTaskList è una lista di Task, come è più evidente dalla rappresentazione XML di un task (Figura 2.2): 25

28 Figura 2.2 La rappresentazione XML di un task è un flattening (appiattimento) della gerarchia, vale a dire che il record XML possiede tutti i campi della classe padre Task, più gli attributi di tutte le classi figlie; tali attributi hanno valore solo se il tipo di task, identificato dall attributo action, è quello corrispondente alla sottoclasse in cui quel valore esiste. Ciò è stato fatto per semplificare sia la progettazione della struttura del file XML che la realizzazione delle classi Java e delle relative classi ontologiche. Sfruttando tale rappresentazione, è possibile esprimere il piano associato a un task come grafo, trasformato in una lista e memorizzato con questo formalismo XML. 26

29 2.6.2 Regole per la descrizione del grafo di una FSM Il grafo di un task è soggetto ai seguenti vincoli: L insieme degli stati componenti la FSM è contenuto in una lista memorizzata all interno del task (la subtasklist); Lo stato iniziale della FSM deve essere il primo elemento della lista, per identificare il punto di inizio in modo semplice; Ogni stato nella lista ha due attributi, nextok e nexterror ; entrambi contengono un valore long, che corrisponde all identificativo di un altro stato nella stessa lista. Essi rappresentano la transizione dallo stato precedente (l elemento Task di cui fanno parte) allo stato successivo. nextok contiene l identificativo del sottotask successivo da eseguie quando il task corrente viene eseguito con successo, nexterror l identificativo del sottotask alternativo, quando il task corrente fallisce l esecuzione. Di conseguenza, ci possono essere solo due transizioni in uscita da uno stato, una etichettata con Ok e memorizzata in nextok, e l altra etichettata con Error e memorizzata in nexterror; uno stato i cui due successori sono entrambi 0 (cioè non puntano a nessuno stato valido, poiché gli identificatori dei task sono tutti valori strettamente positivi) è uno stato finale, da cui si va solo nello stato di conclusione del behaviour; Lo stato iniziale e quello finale del behaviour FSM, come definito nel framework, non sono rappresentati nel task, in quanto identici per tutti i possibili grafi; 27

30 Questo consente di realizzare piani complessi, senza modifiche al codice, semplicemente scrivendo un file XML adatto. In particolare, è possibile tradurre un grafo di tipo AND-OR in questo formalismo (vedi figura 2.3). In questo esempio, è rappresentato il grafo, costruito rispettando il formalismo appena descritto, corrispondente al grafo AND-OR che si può esprimere come ((SottoTask A) and (SottoTask C) and (SottoTask D)) or (SottoTask B) Figura

31 2.6.3 Influenza dell autonomia sul ragionamento L introduzione dell autonomia nel ragionamento automatico inserisce un nuovo vincolo nel database globale: le Intentions di un agente, il cui grado di autonomia è variabile in più dimensioni indipendenti, devono tener conto esplicitamente di tale grado. Esse perciò saranno del tipo: IF ( (Autonomia(Categoria) = Livello) AND (Condizione 1) AND (Condizione 2) AND (Condizione N) ) THEN Azione Per semplificare il processo di matching, è possibile suddividere le Intentions in sottoinsiemi aventi il medesimo livello di autonomia. In tal modo, al momento di determinare il conflict set (l insieme delle Intentions applicabili a una data istanza dell insieme dei Beliefs), si prendono in considerazione solo quelle Intentions appartenenti agli insiemi la cui autonomia richiesta è minore o uguale a quella del task in quel momento in esecuzione. Per esempio, avendo due Intentions: <Intention name="get Contextualized User Model" slotname="intention"> <Precondition slotname="precondition" value="dme.onto.um.useridentify"/> <Precondition slotname="precondition" value="dme.onto.architecture.agentid"/> <Obtain slotname="obtain" value="dme.onto.um.user"/> 29

32 </Intention> <Intention name="find a list of suitable tasks for the available environment" slotname="intention"> <Precondition slotname="precondition" value="dme.onto.um.useridentify"/> <Precondition slotname="precondition" value="dme.onto.architecture.agentid"/> <Obtain slotname="obtain" value="dme.onto.architecture.listservicetask"/> </Intention> si nota che entrambe hanno le stesse precondizioni; se esse richiedono differenti livelli di autonomia per l esecuzione, il conflict set viene ridotto alla Intention il cui livello di autonomia è compatibile col livello di autonomia dell agente. In questo modo, se l agente possiede un livello di autonomia elevato, potrà scegliere di eseguire una qualunque Intention, mentre se il suo grado di autonomia è basso il conflict set sarà creato a partire da un set di Intentions più ristretto. Considerando il Desire caratteristico dell agente D-Me, che è quello di Eseguire i task dell utente nell ambiente adatto, risulta conveniente considerare una diversa autonomia per ogni task, data la natura eterogenea degli stessi. E infatti inconcepibile per l utente che per un task come stasera devi andare al cinema l agente abbia la stessa autonomia di azione che per il task prenota l esame di Programmazione. E evidente che il secondo task è di gran lunga più importante per l utente, perciò il sistema potrà prendere in considerazione molti più modi di portare a termine il task. Avrà quindi maggiore autonomia, in particolare maggiore autonomia di comunicazione e maggiore autonomia di azione. 30

33 Di conseguenza, nell implementazione del sistema ogni task (e, per ricorsività, ogni sottotask) possiede una classe Autonomia, che funge da contenitore per i valori dell autonomia di quel particolare task; possiamo considerarle come le coordinate di quel task nello spazio dell autonomia. Tale classe serve per consentire all agente di ragionare sul task, nel momento in cui il piano richiede che il task venga eseguito. Supponendo, ad esempio, che l utente abbia inserito un task che richiede al MainAgent di intraprendere una certa azione, che però richiede un livello di autonomia superiore a quella che l utente ha concesso per il task principale, allora l azione non può essere eseguita; a questo punto, le alternative possibili per il MainAgent sono le seguenti: Richiesta all utente di modificare il livello di autonomia dell agente per il task corrente : in questo caso, l agente sta sfruttando la sua metaautonomia [5], negoziando con l utente una modifica della propria autonomia; Modifica del livello di aiuto fornito all utente : in tal caso, il MainAgent interrompe l esecuzione di quella parte del piano e continua seguendo la strada alternativa, se esiste; altrimenti termina il compito. Si tratta quindi di un cambiamento da OverHelper (che è la strategia standard del sistema, come accennato in precedenza) a SubHelper, poiché l agente si limita ad eseguire una porzione del piano originale. Richiesta all utente di modificare il livello di autonomia del tipo di sottotask che sta eseguendo : si tratta, in questo caso, di modificare l interpretazione del mondo dell agente. Questo può essere utile quando 31

34 l utente si accorge che l azione di un particolare sottotask è stata valutata male; nel caso specifico, è stata definita un autonomia di esecuzione troppo alta, restringendo inutilmente la libertà d azione dell agente. La modifica dell autonomia richiesta dal sottotask permette all agente di intraprenderlo senza chiedere conferma all utente, rendendolo quindi meno intrusivo Feedback: Incidenza del comportamento dell utente sull autonomia Bisogna prendere in considerazione altri aspetti del ragionamento: Accettazione da parte dell utente delle iniziative dell agente Capacità dell agente di eseguire ciò che l utente desidera Conflitti tra Desires dell agente Questi tre punti vengono presi in esame e formalizzati sempre in [5]. A tale proposito vengono definiti vari livelli di aiuto dell agente in base alla personalità dell utente (e quindi al suo tipo di delega). Si distinguono gli utenti secondo le categorie: sempre delegante : l utente è pigro, delega i suoi task all agente anche quando potrebbe svolgerli da solo delegante per necessità : l utente delega un task all agente solo quando non è in grado di eseguirlo personalmente non delegante : l utente non delega mai task all agente 32

35 e gli agenti come: ipercooperativo : l agente esegue sempre i task che l utente gli affida, e interviene quando crede che l utente possa aver necessità di un certo task, o quando pensa che un certo task sia gradito all utente (anche quando l utente è in grado di svolgere da solo tale task) benevolente : l agente esegue un task sia quando l utente glielo ordina, sia quando pensa che l utente non sia in grado di eseguirlo da solo aiutante : l agente esegue sempre i task dell utente, ma non prende iniziative egoista : l agente non esegue mai i task dell utente Si distinguono diverse coppie possibili utente/agente; scartiamo le possibilità chiaramente prive di interesse (come utente non delegante o agente egoista ), che nel nostro sistema non hanno riscontro e sarebbero di poca rilevanza, in quanto un utente non delegante lascerebbe il sistema inattivo, e viceversa un agente egoista sarebbe un pessimo rappresentante dell utente. Esamineremo quindi le coppie: Utente sempre delegante delegante per necessità Agente ipercooperativo benevolente oppure aiutante In tutti i casi, il feedback dell utente (vale a dire il modo in cui l utente approva il comportamento del sistema) può far cambiare categoria all agente: per esempio, 33

36 un agente ipercooperativo può diventare un agente aiutante se il comportamento dell utente evidenzia che l utente è un delegante per necessità ; l autonomia di azione dell agente diminuisce in conseguenza di questo, impedendo all agente di prendere iniziative. 2.7 Meccanismi di feedback Prenderemo in esame due tipi possibili di feedback: Feedback positivo : tale tipo di feedback si realizza nel momento in cui l utente, avendo davanti a sé l interfaccia che mostra come l agente abbia preso un iniziativa, la visualizza e l approva. Feedback negativo : tale tipo di feedback avviene quando, sempre visualizzando le attività intraprese autonomamente dall agente, l utente ne trova una o più che non vuole vengano eseguite. In tal caso, è possibile sospendere l attività o annullarla. Nel primo caso, l agente ritiene che la generazione del task sia stata una scelta giusta, per cui le regole di decisione restano invariate. Nel secondo caso, invece, è necessario modificare i criteri di scelta delle regole. 34

37 2.7.1 Modifica delle regole di inferenza Considerando dal punto di vista dell agente il feedback dell utente, tale feedback si traduce in una modifica ai valori dell autonomia. Vi sono due possibili modi di variare l autonomia di un agente, relativamente all inferenza di nuovi task: Si può modificare l autonomia di esecuzione delle regole di inferenza per l agente; tale modifica ha l effetto di rendere l agente più o meno autonomo, riguardo alla generazione di nuovi task, ma non distingue tra una regola e l altra; Si può considerare l autonomia necessaria per l esecuzione di ogni singola regola di inferenza; per far ciò, bisogna definire l autonomia di ogni regola come livello minimo di autonomia dell agente perché la regola possa essere applicata. In tal modo, l agente può eseguire, in un particolare momento, solo quelle regole la cui autonomia minima è compatibile con l autonomia di cui dispone l agente in quell istante di tempo. A un feedback positivo o negativo corrisponde rispettivamente un abbassamento o un innalzamento dell autonomia minima della regola la cui attuazione ha causato il feedback. Quando il livello di autonomia necessario per l esecuzione di una regola è massimo, un ulteriore feedback negativo da parte dell utente ha come conseguenza la rimozione della regola dalle regole che l agente usa normalmente per l inferenza. Perché tale regola possa essere reintrodotta nel sistema, è necessario un intervento esplicito dell utente (che deve modificare manualmente l autonomia necessaria per l esecuzione di una regola). 35

38 Nell implementazione del sistema, abbiamo scelto la seconda alternativa, in quanto essa permette un controllo più fine sul comportamento dell agente, permettendo di agire separatamente su ogni regola Modifica del profilo utente L agente deve sempre permettere all utente di verificare i dati che vengono inferiti sulla personalità di delega, quindi sui livelli di autonomia; questo perché tale trasparenza è necessaria perché l utente mantenga il controllo dell interazione e quindi possa fidarsi dell agente e delegare un qualsiasi task. Navigando questi dati, l utente può confermare o negare le inferenze dell agente, o ancora modificare alcuni dei dati precedentemente asseriti; in tal modo, egli fornisce sia un feedback positivo che uno negativo: positivo sulle inferenze che sono giuste, negativo su quelle sbagliate. In tal modo, viene rivista l autonomia delle regole di decisione che hanno portato alle inferenze in questione. La tematica della modellazione dell utente è stata già descritta in [20]. 36

39 Capitolo 3: Caratteristiche strutturali 3.1 Piattaforma di implementazione JADE: descrizione generale JADE (Java Agent DEvelopment Framework) [12] è un framework che rende possibile la creazione e la comunicazione tra agenti software, fornendo sia una shell per l avvio e la gestione degli agenti, che protocolli per la comunicazione (conformi allo standard FIPA [13], Foundation for Intelligent Physical Agents). Inoltre, sono disponibili tool per l analisi degli agenti presenti e il debug. E sviluppato dal TILAB (Telecom Italia Lab, ex CSELT) [16] ed è distribuito sotto licenza LGPL (Lesser GNU Public License). L intero framework è realizzato in Java. Esso fornisce i componenti standard per la gestione della piattaforma: ACC (Agent Communication Channel): canale per la comunicazione interpiattaforma e intrapiattaforma AMS (Agent Management System): agente il cui compito è gestire gli altri agenti (servizio di naming) DF (Directory Facilitator): agente che si occupa di registrare i servizi offerti dagli altri agenti (servizio di yellow pages) 37

40 E anche possibile per un agente muoversi all interno della piattaforma (che è composta di diversi Container, non necessariamente residenti sullo stesso host). Lo scambio di informazioni tra agenti avviene attraverso l uso di messaggi, codificati secondo gli standard FIPA, definiti ACL messages. Figura 3.1 In figura 3.1 è possibile vedere un esempio dell interfaccia grafica del framework JADE. Da questa interfaccia è possibile attivare o eliminare un agente in un particolare container, visualizzare l elenco delle piattaforme, dei container e degli agenti presenti, oppure lanciare gli strumenti di debug. 38

41 Figura 3.2 In figura 3.2 si può osservare la schermata dell Introspector. Esso è un tool che consente di visualizzare tutti i behaviour di un agente e tutti i messaggi da esso ricevuti o inviati, compresi quelli ancora in attesa di essere letti dall agente. E utile per verificare se i behaviour vengono caricati ed eseguiti nel modo previsto. 39

42 Figura 3.3 In figura 3.3 si vede la schermata dello Sniffer. Tale tool è in grado di spiare tutti i messaggi che vengono scambiati dagli agenti sulla piattaforma. Scegliendo un sottoinsieme di agenti, è possibile verificare la corretta esecuzione dei protocolli di comunicazione tra agenti, nonché visualizzare il contenuto dei messaggi, per verificarne la correttezza. 40

43 Figura 3.4 In figura 3.4 si può osservare l interfaccia grafica del DF, che è uno degli agenti che obbligatoriamente devono essere presenti su una piattaforma. Tale agente fornisce il servizio di Yellow Pages, cioè fornisce un servizio di registrazione per tutti gli agenti che offrono servizi presenti sulla piattaforma LEAP: descrizione generale LEAP (Lightweight Extensible Agent Platform)[ è una piattaforma a footprint ridotto, quindi con richieste minime di risorse hardware, indipendente dal sistema operativo, e conforme a FIPA. Tale piattaforma consiste 41

44 in un adattamento della piattaforma JADE (da cui mutua parte del codice sorgente) alle specifiche delle macchine virtuali Pjava (PersonalJava) e MIDP (Mobile Information Device Profile), rilasciate da Sun Microsystems [ l utilizzo di tale framework alternativo consente di far funzionare gli agenti Java che lavorano con JADE anche su dispositivo palmare. In particolare, l utilizzo della versione di LEAP compilata per Personal Java (o Pjava) è pensata per essere utilizzata su dispositivi palmari del tipo Compaq Ipaq[ o equivalenti, con virtual machine come Jeode[ oppure con la virtual machine di riferimento della Sun. Inoltre, è possibile lavorare con i rispettivi emulatori e ambienti di simulazione (in particolare J2ME Wireless Toolkit per la versione MIDP e Personal Java Environment Emulation per la versione Pjava). 42

45 3.2 D-Me: descrizione generale Il sistema D-Me consiste di un insieme di agenti, organizzati per Environment. Un agente, il MainAgent, rappresenta l utente del sistema: le varie istanze del MainAgent possono essere residenti in vari container, anche su piattaforme remote, e registrano la loro presenza in un ben definito Environment. L approccio che abbiamo seguito prevede che l utente che desidera utilizzare i servizi di un Environment si sposti (fisicamente o logicamente) in questo ambiente, spostando quindi il suo MainAgent. L Environment corrisponde, nella metafora del sistema, a un luogo fisico oppure logico, come ad esempio la biblioteca, il supermercato, il pub, fisicamente realizzato come un ambiente 43

46 smart, cioè dotato di tecnologia Ubiquitous computing, con opportuni devices, come sensori, microfoni, schermi a parete; dato che simili ambienti esistono solo a livello sperimentale, gli Environment sono realizzati in questo sistema come entità software, composte quindi solo da agenti software. In particolare, un Environment è caratterizzato da: Key : il nome dell Environment EnvironmentKeeperAgent : un agente specifico per l Environment Insieme dei Service afferenti all Environment. Insieme dei MainAgent registrati presso un EnvironmentKeeperAgent; tale insieme varia nel tempo, quando i MainAgent migrano da un ambiente all altro. I Service sono essi stessi agenti, che forniscono particolari servizi ad altri agenti che li richiedano. Essi si registrano, al momento della loro creazione, col Keeper di ambiente al quale afferiscono. In dipendenza dalla natura dei servizi offerti, i ServiceAgent possono essere accessibili solo agli agenti presenti nell Environment, oppure essere disponibili per qualunque agente che sappia come contattarli. A tal fine, i vari Environment sono registrati presso un MainKeeper, il cui scopo è tener traccia dei Keeper di ambiente presenti e fornirne l indirizzo ai richiedenti. Il MainKeeper è l unico agente il cui indirizzo deve essere noto a priori per il generico agente MainAgent, nel momento in cui questo viene attivato. Successivamente, esso ricerca l Environment in cui è situato e si collega al relativo Keeper, in modo da poter svolgere le sue funzioni. 44

47 E possibile richiedere informazioni e servizi non solo ai Service di un ambiente, ma anche agli altri MainAgent presenti nel sistema: essi sono infatti registrati presso il Keeper in modo simile a quanto avviene per i Service, e possono essere interrogati alla stessa maniera. Data la natura potenzialmente eterogenea degli agenti MainAgent (essi sono specializzazioni dell agente standard di JADE, ma non ci sono limiti alla loro differenziazione), e al particolare utente di cui sono rappresentanti, i MainAgent possono decidere se rispondere a una particolare richiesta degli altri agenti o no, a differenza dei Service; questo perché, per fare un esempio, un utente può non aver delegato al suo agente la diffusione dei suoi dati personali. Pertanto, alla richiesta di un altro agente, del tipo chi sei?, il MainAgent non è autorizzato a rispondere. Il MainAgent ha bisogno, per eseguire le sue funzioni e prendere le decisioni necessarie, di due tipi di informazioni: informazioni sull utente che esso rappresenta (User Modeling Components, vedi [20]) e informazioni sul contesto fisico in cui è immerso (Context Modeling Components, vedi [19]). Le informazioni sull utente sono gestite da un ulteriore agente specializzato, l UMKeeper. Tale agente ha come compito quello di conservare in modo permanente i dati statici dell utente (nome, indirizzo) e quelli riguardanti la personalità, le capacità, le conoscenze dell utente. Tali dati vengono immessi direttamente dall utente, tramite un interfaccia grafica, o dedotti dal MainAgent, analizzando l interazione con l utente e traendo le conclusioni sulla base di un set di regole specializzate. E responsabilità dell UMKeeper aggiornare i dati memorizzati e fornirli su richiesta del MainAgent. Esso può risiedere sul dispositivo portatile dell utente, oppure essere localizzato fisicamente su un server 45