Gian Luca Pozzato. AgentSpeak (L) & Jason AgentSpeak(L): linguaggio di programmazione per agenti BDI...

Gian Luca Pozzato

AgentSpeak (L)& Jason

AgentSpeak(L): linguaggio di programmazione per agenti BDI introdotto da Rao nel 1996

Si propone di colmare il gap tra specifica teorica ed implementazione di un agente BDI

Jason è la prima significativa implementazione di AgentSpeak(L), realizzata in Java da Bordini e Hubner

Gli agenti BDI vengono da sempre trattati da due punti di vista: - specifica teorica; - implementazione.

Il gap tra teoria e pratica resta eccessivo

Causa principale: complessità del theorem proving e del model checking delle logiche usate per formalizzare i BDI agents

AgentSpeak (L)& Jason

Le implementazioni esistenti utilizzano strutture dati per rappresentare Belief, Desires e Intentions, invece che gli operatori modali

[Rao96] introduce una formalizzazione alternativa degli agenti BDI: AgentSpeak(L)

AgentSpeak(L): architettura per agenti e linguaggio di programmazione

AgentSpeak(L) come estensione della programmazione logica per supportare l’architettura BDI

IN QUESTA PRESENTAZIONE:

Breve introduzione

AgentSpeak(L): linguaggio e funzionamento dell’interprete col sussidio di un esempio

Jason

Conclusioni e alcuni riferimenti utili

Introduzione

Agenti BDI:

sistemi collocati in un ambiente dinamico, che muta nel tempo;

sistemi in grado di percepire informazioni provenienti dall’ambiente;

sistemi in grado di compiere delle azioni (ed apportare modifiche all’ambiente) sulla base delle proprie attitudini mentali: beliefs, desires e intentions sono le principali attitudini.

Agente AgentSpeak(L) Ambiente esterno

Percezione

Azione

Belief componente di informazione

Desire componente motivazionale

Intention componente decisionale

cattura

cattura

cattura

Principali attitudini mentali di un agente BDI

Per formalizzare queste nozioni sono state impiegate logiche multi-modali, temporali, dinamiche e action logics. Tuttavia, la complessità del theorem proving e del model-checking di tali logiche non è ancora chiara ([Rao95] e [RaoGeo91]).

Aspetto teorico

Sono state proposte molte implementazioni di agenti BDI;

tali implementazioni sono state impiegate con successo in molti domini applicativi considerati critici;

[BurSun92], [GeoLan86], [MulPisThi95] e [Sho93] sono alcuni esempi;

in questi sistemi, piani e programmi scritti dagli utenti permettono di migliorare l’efficienza della computazione.

Aspetto pratico (I)

Le implementazioni sono caratterizzate da assunzioni che semplificano le definizioni di belief, desire e intention, in modo da modellare tali attitudini con maggiore facilità;

le basi teoriche che supportano tali sistemi sono deboli.

Aspetto pratico (II)

PROBLEMA: grosso gap tra teoria e pratica.

SOLUZIONE DI RAO:

AgentSpeak(L).

Si parte da un sistema BDI implementato e si formalizza la sua semantica operazionale;

il sistema considerato è il PRS (Procedural Reasoning System) e la sua evoluzione dMARS (Distributed Multi-Agent Reasoning System);

AgentSpeak(L) può essere visto come una versione semplificata e testuale di PRS o dMARS (questi ultimi offrono semplicemente più costrutti per facilitare la programmazione di agenti, ma i linguaggi e le rispettive semantiche operazionali sono simili nei loro dettagli essenziali).

Linguaggio di programmazione basato su un linguaggio del primordine semplificato, con eventi e azioni;

il comportamento di un agente (ossia, le sue interazioni con l’ambiente) è dettato dai programmi scritti in AgentSpeak(L);

beliefs, desires ed intentions NON sono rappresentati esplicitamente con formule modali, bensì il progettista attribuisce tali nozioni all’agente usando il linguaggio AgentSpeak(L).

AgentSpeak(L)

Current belief state dell’agente: modello di sé stesso, dell’ambiente e degli altri agenti;

Desires: stati che l’agente vuole raggiungere (sulla base di stimoli interni o esterni); per la precisione, AgentSpeak(L) fa riferimento ai Goals, che si possono intendere come Desires adottati/scelti;

Intentions: adozione di programmi per soddisfare certi stimoli.

AgentSpeak(L)

Il linguaggio AgentSpeak(L)

Linguaggio testuale per scrivere programmi per agenti

Nozioni di base beliefs (analoghi ai fatti della programmazione logica), piani, azioni, intentions, eventi, goals

Piani: Context sensitive Possono essere invocati dall’utente Consentono una decomposizione gerarchica dei goals Sintatticamente simili alle clausole della

programmazione logica (anche se con un diverso comportamento)

Variabili

Costanti

Simboli funzionali

Simboli predicativi

Simboli di azione

Connettivi

Quantificatori

Simboli di punteggiatura

Alfabeto del linguaggio formale

della logica del primordine: - & (congiunzione Λ)- not (negazione ¬)- <- (implicazione ←)

! Achievement

? Test

; Sequenza

Connettivi

Termini

Formule

Le variabili del linguaggio sono caratterizzate dall’iniziale maiuscola

Definizioni della logica del primordine


Nozioni del linguaggio

Def 1 [Belief atom] : sia b un simbolo predicativo e siano t1, …, tn termini. Allora:

b(t1, …, tn)

è un belief atom e si scrive anche b(t).

Belief atom

Un belief atom e la sua negazione sono detti belief literal

Un belief atom ground (=senza variabili con occorrenze libere) è detto base belief

Belief

Def 1b [Belief] : siano b(t) e c(s) belief atoms; allora

b(t) Λ c(s)¬b(t)

sono beliefs.

Istanze ground di beliefs si dicono base beliefs.

Esempio

Consideriamo la seguente simulazione:

4 corsie adiacenti Le corsie possono essere percorse da automobili In ciascuna corsia può essere presente della spazzatura Il robot deve raccogliere la spazzatura e depositarla nel

cestino, posizionato in una delle 4 corsie Mentre pulisce, il robot NON deve trovarsi in una corsia

in cui è presente un’auto, per evitare di essere distrutto

Vogliamo scrivere il programma per l’agente che guida il robot nella sua attività.

a b c d


Percezione

Azione

I beliefs rappresentano informazioni su:

Configurazione delle corsie

Posizionamento del robot

Posizione delle auto nelle corsie

Posizione del cestino per la raccolta dei rifiuti

Ad esempio:

adjacent(X,Y)location(robot,X)location(car,X)

I base beliefs (=istanze ground di belief atoms) sono, ad esempio:

adjacent(a,b)location(robot,c)

Goal

E’ uno stato del sistema che l’agente vuole raggiungere

2 tipi di goal:

Achievement goal

Test goal

Achievement goal:

Della forma: !g(t)

L’agente vuole raggiungere uno stato in cui g(t) è un belief VERO

Test goal:

Della forma: ?g(t)

L’agente vuole verificare se la formula g(t) è un belief VERO o FALSO

Def 2 [Goal] : sia g un simbolo predicativo e siano t1, …, tn termini. Allora:

!g(t1, …, tn) ( oppure !g(t) )

è un achievement goal;

?g(t1, …, tn) ( oppure ?g(t) )

è un test goal.

Goal

Esempio:

!cleared(b) : l’agente vuole pulire la corsia b

?location(car,b) : l’agente vuole verificare l’eventuale presenza di un’auto nella corsia b

Goal

Triggering event

Quando un agente acquisisce un nuovo goal oppure nota una modifica nell’ambiente, esso può far scattare aggiunte o cancellazioni di goals o beliefs

Questi eventi vengono detti triggering events

Possibili triggering events: Aggiunta di un belief Aggiunta di un goal Rimozione di un belief Rimozione di un goal

Triggering event

L’aggiunta di un belief/goal è rappresentata dall’operatore +

La rimozione di un belief/goal è rappresentata dall’operatore –

Esempi di triggering events: Notare la presenza di spazzatura nella corsia X è

denotato con il triggering event:+location(waste, X)

Acquisire il goal di ripulire una certa corsia è denotato con il triggering event:

+!cleared(X)

Def 3 [Triggering event] : sia b(t) un belief atom e siano !g(t) e ?g(t) goals. Allora:

• +b(t)• -b(t)• +!g(t)• -!g(t)• +?g(t)• -?g(t)

sono triggering events.

Triggering event

Azione

Scopo di un agente: Osservare l’ambiente e, sulla base di tali osservazioni

e dei propri goals, eseguire determinate azioni

Le azioni compiute dall’agente possono modificare lo stato dell’ambiente

Azione

Esempio:

Se move è un simbolo di azione,

move(X,Y)

è un’azione e rappresenta lo spostamento del robot da X a Y e ha l’effetto di modificare lo stato dell’ambiente. Il robot si trova nella corsia Y e non più nella corsia X

Def 4 [Azione] : sia a un simbolo di azione e siano t1,…, tn termini. Allora

a(t1,…, tn)

è un’azione.

Azione

Piano

Un piano specifica il modo in cui un agente potrebbe raggiungere un determinato obiettivo

<piano>:= <head> ← <body>

<head>:= <triggering event> : <context>

triggering event specifica perché il piano è stato attivato, ossia l’aggiunta/rimozione di un belief o di un goal che tale piano si propone di gestire

context specifica quali beliefs dovrebbero essere soddisfatti nel set delle credenze dell’agente quando il piano è attivato (scatta)

Piano

<piano>:= <head> ← <body>

<head>:= <triggering event> : <context>

body è una sequenza di goals o azioni e specifica:

i goals che l’agente vuole raggiungere (achievement goals) o testare (test goals);

le azioni che l’agente deve eseguire

true rappresenta un componente vuoto (context o body)

Piano

Esempio: piano che scatta quando la spazzatura si viene a trovare in una certa corsia; se il robot si trova in tale corsia:

Raccoglie la spazzatura; Si pone l’obiettivo (achievement goal) di raggiungere il

cestino; Getta via la spazzatura.

Piano

Un possibile piano (P1):

+location(waste, X): location(robot,X) & location(bin,Y)

<- pick(waste); !location(robot, Y); drop(waste).

Piano

Esempio: piano per consentire al robot di spostarsi fra le corsie. Il robot ha l’obiettivo di raggiungere la corsia X, senza dover fare altre operazioni. Se non si trova nella corsia X, il robot deve individuare una corsia Z che sia:

Adiacente alla corsia in cui si trova attualmente Non percorsa da auto

quindi, deve spostarsi in tale corsia.

Piano

Piano (P2):

+!location(robot,X): location(robot,X) <- true.

Piano (P3):

+!location(robot,X): location(robot,Y) &(not (X = Y)) &adjacent(Y,Z) &(not (location(car,Z)))<- move(Y,Z); +!location(robot,X).

Def 5 [Piano] : siano:

• e un triggering event;• b1,…,bm belief literals;• h1,…,hn goals o azioni

allora

e: b1 Λ … Λ bm ← h1; … ; hn

è un piano.La parte a sinistra di ← è detta head, la parte a destra è

detta body. La parte a destra dei : nella head è detta context. Un body vuoto viene riscritto per convenzione con true.

Piano

Progetto di un agente

Le nozioni introdotte finora completano la specifica di un agente;

Il progettista specifica un agente scrivendo: Un insieme di base beliefs; Un insieme di piani.

Il progetto di un agente è, pertanto, del tutto simile alla scrittura di un programma logico, con la definizione di: Un insieme di fatti; Un insieme di regole.(ma con differenze)


La semantica operazionale

A run-time un agente può essere visto come costituito da:

Un set di beliefs B; Un set di piani P; Un set di intentions I; Un set di eventi E; Un set di azioni A; Un set di funzioni di selezione: Sε, SO, SI

Descriviamo informalmente il funzionamento di un agente AgentSpeak(L)…

a b c d


Percezione

Azione

Belief baselocation(robot,b).adjacent(a,b).

Eventi<+location(robot,b),i>

Piani+!location(robot,X): location(robot,X)<-true.

Unifica evento

Unifica contesto

Evento selezionato

Piani rilevanti

Pianiapplicabili

SO

Intendedmeans

Intentions

SI

Esecuzione intention

Sε

Evento esterno: nuova intention

Evento interno: push

Azione

Achievement goal

Test goaltrue

a b c d

Internio

Esterni

+!goal-!goal+belief-belief

BeliefRevision Function

Viene generato un triggering event quando un agente nota una modifica nell’ambiente circostante oppure quando un utente esterno chiede all’agente di raggiungere un goal

Gli eventi possono essere: Esterni (modifica dell’ambiente) Interni (modifica dello stato dell’agente)

Gli eventi vengono aggiunti al set E

Sε seleziona in E un evento E0 da processare

E0 viene rimosso da E e viene usato per unificare con i triggering events dei piani del set P

I piani i cui triggering events unificano con E0 sono detti piani rilevanti; l’unificatore è detto unificatore rilevante

L’unificatore rilevante è applicato al contesto dei piani rilevanti

Una correct answer substitution è ottenuta dal contesto

Per alcuni piani le condizioni dei contesti risultano essere conseguenze logiche del set dei base beliefs B: questi piani sono detti piani applicabili mediante un unificatore applicabile

L’unificatore applicabile risulta dalla composizione della correct answer substitution con l’unificatore rilevante

Dato un evento E0, diversi piani/opzioni risultano applicabili

La funzione di selezione SO sceglie uno di questi piani/opzioni che chiamiamo Po

Applicando l’unificatore applicabile a Po si ottiene l’intended means in risposta al triggering event

Ogni intention è uno stack di piani parzialmente istanziati o intention frames

Evento esterno: l’intended means è usato per creare una NUOVA INTENTION, che viene aggiunta al set I

Evento interno: l’intended means è inserito in cima all’intention ESISTENTE che ha “fatto scattare” (triggered) l’evento interno (per raggiungere un goal)

La funzione di selezione SI sceglie una intention da eseguire

Quando l’agente esegue una intention, esegue il primo goal o azione del body del top del’intention: Eseguire un achievement goal equivale a generare un

evento interno per aggiungere il goal alla corrente intention;

Eseguire un test goal equivale a trovare una sostituzione per il goal che lo renda una conseguenza logica dei base beliefs; se viene trovata una sostituzione, il test goal è rimosso dal corpo del top dell’intention;

Eseguire un’azione equivale ad aggiungerla al set di azioni A e rimuoverla dal corpo del top dell’intention.

A questo punto, l’agente torna a valutare il set degli eventi E; il ciclo ricomincia, fino a quando:

il set degli eventi E è vuoto

oppure

Non è possibile eseguire altre intentions.

Def 7 [Intention] : I è il set delle intentions; ogni intention è uno stack di piani parzialmente istanziati, ossia piani dove alcune variabili sono state istanziate.

Un’intention è denotata con uno stack:

[ p1 ‡ p2 ‡ … ‡ pz ]

Intention

stack

bottom top

Una particolare intention è la true intention

True intention:

[ +!true: true <- true ]

Per comodità, la denoteremo con T

Intention

Def 8 [Evento] : il set E è il set degli eventi. Ogni evento è una coppia:

< e, i >

dove:

• e è un triggering event• i è una intention

Se i è la true intention T, l’evento è un evento esterno, altrimenti si dice evento interno.

Evento

Scelto un evento < d, i > dal set E, il triggering event d viene unificato con i triggering event di tutti i piani contenuti nel set P

Il most general unifier (mgu) che unifica i due eventi è detto relevant unifier

L’intention i può essere: La true intention T Un’intention esistente che ha generato l’evento

Ancora sul piano

Piano rilevante

Torniamo all’esempio del traffico

Supponiamo che il triggering event d di Є (ossia l’evento scelto in E dalla funzione di selezione) sia:

+!location(robot,b).

Ripresentiamo i piani introdotti in precedenza per il nostro agente

(P1)+location(waste, X): location(robot,X) & location(bin,Y)

<- pick(waste); !location(robot, Y); drop(waste).

(P2)+!location(robot,X): location(robot,X) <- true

(P3)+!location(robot,X): location(robot,Y) &

(not (X = Y)) &adjacent(Y,Z) &(not (location(car,Z)))<- move(Y,Z); +!location(robot,X).

Piano rilevante

I piani P2 e P3 sono rilevanti

L’unificatore rilevante è:σ = { X/b }

(P2)+!location(robot,X): location(robot,X) <- true



Piano applicabile

Un piano rilevante è anche applicabile se esiste una sostituzione che, composta con l’unificatore rilevante ed applicata al contesto, fa sì che quest’ultimo risulti una conseguenza logica dei base beliefs B

In altre parole, la condizione del contesto di un piano rilevante DEVE essere conseguenza logica di B affinchè il piano sia applicabile

Piano applicabile

Vediamo ancora l’esempio del traffico

Supponiamo che i base beliefs del nostro agente siano:

adjacent(a,b).adjacent(b,c).adjacent(c,d).location(robot,a).location(waste,b).location(bin,d).

Il piano P3 è il solo applicabile mediante il seguente unificatore applicabile:

={X/b, Y/a, Z/b}

a b c d




Unificatore applicabile: ={X/b, Y/a, Z/b}

Intended means

Come detto, la funzione Sε seleziona un evento < d, i >

La natura di i determina il tipo di evento

A seconda del tipo di evento (interno o esterno), l’agente esegue un opportuno intended means


(P1) +location(waste,X): location(robot,X) & location(bin,Y) <- pick(waste); !location(robot, Y); drop(waste).

(P2) +!location(robot,X):location(robot,X) <- true

(P3) +!location(robot,X):location(robot,Y) & (not (X = Y)) & adjacent(Y,Z) & (not (location(car,Z))) <- move(Y,Z); !location(robot,X).

<+!location(robot,b),T>

Sε


SO

Unifica evento

P2 e P3 rilevanti con {X/b}

Unifica contesto

P3 applicabile con {X/b,Y/a,Z/b}

P3[ +!location(robot,b):location(robot,a) & (not (b = a)) & adjacent(a,b) & (not (location(car,b))) <- move(a,b); !location(robot,b)].

SI


a b c d

[ +!location(robot,b): location(robot,a) & (not (b = a)) & adjacent(a,b) & (not (location(car,b)))

<- move(a,b); !location(robot,b) ].




Sε


SO

Unifica evento


Unifica contesto

P3 applicabile con {X/b,Y/a,Z/b}

P3SI


adjacent(a,b).adjacent(b,c).adjacent(c,d).location(robot,b).location(robot,b).location(waste,b).location(bin,d).

<+location(robot,b),T>

[ +!location(robot,b):location(robot,a) & (not (b = a)) & adjacent(a,b) & (not (location(car,b))) <- !location(robot,b)].!location(robot,b)].

a b c d




Sε


Unifica evento

Nessun piano rilevante

Unifica contesto

Nessun piano applicabile

SO-SI


adjacent(a,b).adjacent(b,c).adjacent(c,d).location(robot,b).location(waste,b).location(bin,d).


[ +!location(robot,b):location(robot,a) & (not (b = a)) & adjacent(a,b) & (not (location(car,b))) <- !location(robot,b)].

<+!location(robot,b), >

a b c d




Sε

Unifica evento


Unifica contesto

P2 applicabile con {X/b}




[ +!location(robot,b):location(robot,a) & (not (b = a)) & adjacent(a,b) & (not (location(car,b))) <- !location(robot,b)‡ +!location(robot,b):location(robot,b)<-true].

SOP2SI


a b c d




Sε

Unifica evento


Unifica contesto


SOP2


[ +!location(robot,b):location(robot,a) & (not (b = a)) & adjacent(a,b) & (not (location(car,b))) <- !location(robot,b)].


SI


a b c d




Sε

Unifica evento


Unifica contesto


SOP2


[ +!location(robot,b):location(robot,a) & (not (b = a)) & adjacent(a,b) & (not (location(car,b))) <-truetrue].


SI


a b c d

Ancora l’esempio

Alla successiva iterazione del ciclo dell’agente, dopo che il robot si muove dalla corsia a alla corsia b, l’ambiente invia all’agente un evento di belief update per modificare la locazione del robot (che ora si troverà in b); in sostanza:

- location(robot,b) viene aggiunto a B;- l’evento +location(robot,b) viene aggiunto ad E.

A questo punto, non vi sono piani rilevanti; il sistema sceglie, pertanto, di ESEGUIRE l’intention mostrata nella slide precedente.

L’esecuzione dell’intention (caso a) porta ad aggiungere un evento al set E che diventa:

{ < +!location(robot,b), i > }

dove i è l’intention considerata:

[ +!location(robot,b): location(robot,a) &(not (b = a)) &adjacent(a,b) &(not (location(car,b)))<- +!location(robot,b) ]

Ancora l’esempio

A questo punto, il piano P2

risulta applicabile con l’unificatore applicabile = { X/b }

+!location(robot,X): location(robot,X) <- true


Ancora l’esempio

Il corpo del piano è true; pertanto, l’intention è soddisfatta ed il set E è vuoto

L’esecuzione dell’agente è sospesa e riprenderà nel momento in cui un nuovo evento verrà aggiunto all’insieme E

Ancora l’esempio

Implementazioni di AgentSpeak(L)

Jason

Jason

Java-based agentSpeak interpreter used with saci for multi-agent distribution over the net

E’ la prima implementazione significativa di AgentSpeak(L), dovuta a Bordini e Hubner

Implementato in Java

Disponibile OpenSource

Impiegando SACI, un’infrastruttura per la comunicazione fra agenti, è possibile distribuire un sistema multi-agente sulla rete

Jason

Interpreta il linguaggio AgentSpeak(L) originale

Aggiunge alcune importanti caratteristiche:

Gestione del fallimento dei piani Supporto per lo sviluppo di ambienti da programmare in

Java Possibilità di eseguire un ambiente multi-agente

utilizzando SACI …

… Possibilità di personalizzare (in Java) funzioni di

selezione, di belief-revision, di azione, di comunicazione fra agenti

Libreria di “azioni interne” di base Possibilità di aggiungere “azioni interne” definite in

Java dall’utente Aggiunta della negazione forte

Jason

Jason

Costruire un agente AgentSpeak(L) con Jason è molto semplice

E’ sufficiente:

1. Inserire il nome dell’agente nel file di configurazione

2. Creare un file .asl contenente i piani che descrivono il comportamento dell’agente

Jason: differenze con AgentSpeak(L)

Come accennato in precedenza, Jason presenta una serie di differenze rispetto al linguaggio AgentSpeak(L) originale ([Rao])

Illustriamo le principali differenze…


Possibile uso della negazione forte

La negazione debole è usata nel contesto dei piani come in AgentSpeak(L), introdotta dal not

Es.: not location(car,Y).

La negazione forte è usata per negare un predicato/fatto:

Es: ~location(waste,b).


Termini

Possono essere:

Atomi Strutture Variabili Liste (tipo Prolog) Numeri (interi o floating point) Stringhe (tra “”)


Predicati (atomi) annotati

Possibilità di specificare annotazioni ai predicati nella base belief, per esempio per conservare l’origine di tale informazione

Annotazione: lista di termini tra parentesi quadre associata ad un predicato

Due annotazioni particolari: [percept]: l’informazione è stata percepita

dall’ambiente; [self]: l’informazione è stata aggiunta dall’agente

stesso durante l’esecuzione di un piano


Piani con labels

E’ possibile associare una label a ciascun piano

La label può essere un qualsiasi predicato (consigliata arietà zero), quindi anche un predicato con annotazione

Utili per personalizzare le funzioni di selezione


Gestione del fallimento dei piani

Sono previsti eventi per la gestione del fallimento dei piani

Tale evento è generato se un’azione fallisce o non vi sono piani applicabili per un evento con aggiunta di un goal +!g

In tali situazioni viene generato un evento interno per -!g associato alla stessa intention. Se il programmatore ha previsto un piano per -!g e questo risulta applicabile, verrà eseguito. Altrimenti, viene eliminata l’intera intention e segnalato un warning


Azioni interne

Possono essere usate sia nel contesto che nel body di un piano

Introdotte dal punto: Es: .send(…)

Sono azioni interne, distinte dalle azioni che l’agente compie sull’ambiente mediante gli attuatori

Azioni interne standard (directory src/stdlib) e definite dall’utente in Java


Esempi di azioni interne standard:

.send(receiver,illocutionary_force, propositional_content)

Usata nella comunicazione tra agenti. Receiver è il nome del destinatario del messaggio; illocutionary_force descrive il tipo di messaggio (es. tell, achieve); propositional_content è un predicato che rappresenta l’informazione trasmessa.


Esempi di azioni interne standard:

.print(…)

Scrive messaggi sulla console su cui l’agente o SACI è in esecuzione. Ha un numero qualsiasi di parametri, che possono essere stringhe così come termini AgentSpeak(L).

Jason

Sistemi multi-agente

Jason: sistemi multi-agente

L’utente può definire un sistema di multipli agenti AgentSpeak(L)

Un sistema multi-agente prevede: un ambiente in cui gli agenti AgentSpeak(L)

vengono collocati, programmato in Java Un set di istanze di agenti AgentSpeak(L)

La configurazione dell’intero sistema multi-agente è data da un semplice file di testo

Jason: sistemi multi-agente

File di configurazione di un sistema multi-agente: file con estensione

.mas2j

Nel file vengono indicati il nome attribuito alla società di agenti, gli agenti AgentSpeak(L) che ne fanno parte, l’ambiente in cui si collocano tali agenti (=la classe Java, eventualmente ridefinita dall’utente, per programmare l’ambiente)

Jason offre una serie di script e un’interfaccia grafica che rendono immediate ed intuitive la compilazione e l’esecuzione di un sistema multi-agente

Jason

Personalizzazione

Jason: personalizzazione

Jason consente di personalizzare:

Alcuni elementi di base di un agente, tipo le funzioni di selezione;

I meccanismi di percezione, di azione, di comunicazione tra agenti e la belief revision function;

Le azioni interne; L’ambiente in cui collocare un sistema multi-

agente.

Vediamo brevemente come fare…


Personalizzare un agente

Jason offre la possibilità di modificare il codice di funzioni quali:

selectEvent selectOption selectIntention

Il programmatore deve semplicemente definire una classe Java che estende la classe Agent, ridefinendo opportunamente i metodi da personalizzare

Infine, basta segnalare il cambiamento nel file .mas2j


Personalizzare un agente

Esempio: ridefiniamo la funzione Sε:

import jason.*;import java.util.*;

public class MyAgent extends Agent{ public Event selectEvent(List evList){ System.out.println(“Selezione di un evento”); return((Event)evList.remove(0)); }}

E’ sufficiente specificare agentClass MyAgent nella entry del dato agente nel file di configurazione .mas2j


Personalizzare l’architettura

L’utente può creare l’architettura per l’agente, ossia è possibile modificare i metodi:

perceive checkMail brf act

Il codice di default è presente nelle classi SaciAgArch.java e CentralisedArch.java nella directory src/jason


Personalizzare l’architettura

Esempio: ridefiniamo il meccanismo di percezione:

import jason.*;

public class MyAgArchitecture extends CentralisedAgArch{ public void perceive (){ /* per esempio, simulare un fallimento nella

percezione modificando le liste “percepts” e “negPercepts” */

System.out.println(“Fase di percezione in corso”); super.perceive(); }}

Specificare agentArchClass MyAgArchitecture nella entry dell’agente nel file .mas2j


Personalizzare le azioni interne

Come detto, le azioni interne standard si trovano nella directory src/stdlib

Le azioni interne definite dall’utente in Java possono essere collocate in una directory predefinita ulib, eventualmente organizzate in librerie specifiche

Per invocare un’azione personalizzata:

nomeLibreria.nomeAzione


Personalizzare le azioni interne

Il nome di un’azione deve iniziare con una lettera minuscola, il suo codice deve essere contenuto in un file con nome:

nomeAzione.java La classe in questione deve ridefinire il metodo execute:package <nomeLibreria>;import jason.*;

public class <nomeAzione>{ public static boolean execute (…) throws Exception{ … }}


Personalizzare l’ambiente

Il programmatore può personalizzare l’ambiente in cui si collocano gli agenti AgentSpeak(L)

In particolare, è possibile descrivere come si evolve l’ambiente in seguito all’esecuzione di un’azione da parte di un agente, modificando il codice del metodo executeAction

Possibilità di simulare fallimenti nell’esecuzione delle azioni

Possibilità di limitare ad un sottinsieme dell’ambiente la percezione di ciascun agente


Personalizzare l’ambiente

Il file contenente la classe dell’ambiente personalizzato va specificato nel file di configurazione

import java.util.*; import jason.*;

public class <nomeAmbiente> extends Environment{ …

public boolean executeAction (String ag, Term act){ … }}

ag è l’agente che esegue l’azione rappresentata dal termine act; il metodo restituisce true se l’azione è stata eseguita con successo

Jason: riferimenti importanti

Per scaricare gratuitamente l’ultima versione di Jason:

http://jason.sourceforge.net

Per scaricare gratuitamente SACI:

http://www.lti.pcs.usp.br/saci/

Conclusioni

Linguaggio di programmazione per agenti BDI

Molti lavori per estendere il linguaggio di base, che non descrive, ad esempio, come gestire il fallimento dei piani

Utilizzato solo di recente anche grazie a Jason

AgentSpeak(L)

Jason

Implementazione Java di AgentSpeak(L) esteso

Semplice definizione di un ambiente multiagente con l’uso di SACI

Molteplici possibilità di personalizzazione

Ancora molto lavoro da fare: Documentazione carente Difficile osservare l’evoluzione del sistema: opportuna

un’evoluzione dell’interfaccia e del supporto al programmatore

Gli autori lo hanno sviluppato a “tempo perso”

Bibliografia

BurSun92. B. Burmeister e K. Sundermeyer. Cooperative problem-solving guided by intentions and perception. In E. Werner and Y. Demazeau, editors, Decentralized A.I. 3, Amsterdam, Olanda, 1992.

GeoLan86. M.P. Georgeff e A.L. Lansky. Procedural knowledge. In Proceedings of the IEEE Special Issue on Knowledge Representation, volume 74, 1383-1398, 1986.

IngGeoRao92. F.F. Ingrand, M.P. Georgeff e A.S. Rao. An architecture for real-time reasoning and system control. IEEE Expert, 7(6), 1992.

MulPisThi95. J.P. Muller, M. Pischel e M. Thiel. Modelling reacting behaviour in vertically layered agent architectures. In Intelligent Agents: Theories, Architectures, and Languages. LNAI 890, Heidelberg, Germania, 1995.

Rao95. A.S. Rao. Decision procedures for propositional linear-time belief-desire-intention logics. In Working notes of the IJCAI-95 Workshop on Agent Theories, Architectures, and Languages, Montreal, Canada, 1995.

Rao96. A.S. Rao. AgentSpeak(L): BDI Agents Speak Out in a Logical Computable Language. MAAMAW 1996: 42-55, 1996.

RaoGeo91. A.S. Rao e M.P. Georgeff. Modeling rational agents within a BDI-architecture. In J. Allen, R. Fikes, and E. Sandewall, editors, Proceedings of the 2° International Conference on Principles of Knowledge Representation and Reasoning, 1991.

RaoGeo93. A.S. Rao e M.P. Georgeff. A model-theoretic approach to the verification of situated reasoning systems. In Proc. Of the 13° Intern. Joint Conf. On Artificial Intelligence (IJCAI-93), Chambery, Francia, 1993.

Sho93. Y. Shoham. Agent-oriented programming. Artificial Intelligence, 60(1), 51-92, 1993.

BorHub04. R.H. Bordini e J.F. Hubner. Jason: a Java-based agentSpeak interpreter used with saci formulti-agent distribution over the net. Disponibile all’indirizzo jason.sourceforge.net/Jason.pdf.

Date post:	02-May-2015
Category:	Documents
Upload:	silvana-forti
View:	213 times
Download:	0 times

Gian Luca Pozzato. AgentSpeak (L) & Jason AgentSpeak(L): linguaggio di programmazione per agenti BDI...

Documents