Università degli studi di Ferrara

FACOLTA’ DI INGEGNERIA
Tesina di Ingegneria del Software 2

Agent AUML
e sua modellizzazione dei Sistemi
Multi Agente

Di Elisa Benetti

Anno Accademico 2007/2008

Indice

Introduzione ...............................................................................................1

1. Agenti
1.1. Definizione.......................................................................................3
1.2. Caratteristiche…………………………………………………..….4
1.3. Tipologie…………………………………………………………...5
1.4. Ambienti in cui lavorano……………………………………….…7

2. Sistemi Multi Agente (MAS)

2.1. Definizione….……………………………………………………..8
2.2. Organizzazione di un MAS………………………………….…...10
2.3. Modelli fisici...................................................................................11
2.4. Strategie di coordinamento e negoziazione....................................12

3. FIPA (Foundation for Intelligent Physical Agents)

3.1. Architettura..………………………………………………….......14
3.2. Agente secondo Fipa…………………………………………..…15
3.2.1. Agent Platform (AP)……………………………………...…16
3.2.2. Agent Management System (AMS)…………………………18
3.2.3. Directory Facilitator (DF)…………………………..…….…19
3.2.4. Message Transport Service (MTS)……………………….....20
3.2.5. Messaggi FIPA-ACL……………………………………..…21

II
4. Agenti e Linguaggio a Oggetti
4.1. Differenza tra Agente e Oggetto…………………………..…..…24
4.2. Programmazione ad Oggetti ed UML………………………....…25

5. Agent UML
5.1. I Diagrammi AUML………………………………………...……30
5.1.1. Diagrammi di Interazione/Protocollo…………………...….31
5.1.2. Diagrammi di Classe……………………………………..…33
5.2. Elaborazione Interna degli Agenti…………………………….…35
5.3. Rappresentazione dei Ruoli………………………………………36
5.4. Stereotipi……………………………………………………….....39

6. Conclusioni……………………………………………………………40

III
Introduzione

Possiamo notare come, in passato, siano stati i linguaggi di programmazione ad

introdurre nuove astrazioni, le quali sono state solo successivamente assimilate ed
elaborate dall’ Ingegneria del Software (l’ esempio più ovvio è il concetto di object-
oriented).
Ci si trova invece oggi a far puntare la ricerca scientifica prima sulle metodologie in
quanto la velocità di evoluzione dei sistemi nel presente porta l’ ingegnere a trovarsi
spesso a voler progettare un sistema con astrazioni che linguaggi e tecnologie
esistenti e consolidate ancora non supportano.
Chiaro esempio di questo capovolgimento del tradizionale flusso di evoluzione delle
tecnologie informatiche è appunto l’avvento del paradigma ad agenti e
dell’ingegneria del software orientata agli agenti (Agent-Oriented Software
Engineering, AOSE).
Nel caso dell’approccio ad agenti, infatti, per prime le metodologie di sviluppo
hanno seguito un approccio topdown, dove i sistemi software sono stati analizzati,
modellati e progettati attraverso il paradigma ad agenti e la metafora delle
organizzazioni umane.
In seguito i linguaggi e gli strumenti di sviluppo per sistemi multi-agente hanno
subito un’evoluzione bottom-up, partendo dai linguaggi di programmazione già
esistenti (principalmente object-oriented) ed estendendoli utilizzando il paradigma ad
agenti, mentre il processo di creazione di nuovi linguaggi a livello industriale è stato
rallentato a causa della mancanza di uno standard globalmente accettato.
Abbiamo così da un lato delle astrazioni agent-based disponibili per la fase di
progettazione di elevato livello tali da poter affrontare tematiche complesse come
rappresentazione della conoscenza, ragionamento automatico, comunicazione e
cooperazione tra entità autonome ed eterogenee, dall’altro degli strumenti di

1
sviluppo, che nella maggior parte dei casi sono ancora allo stadio di prototipi prodotti
nelle università e nei centri di ricerca.
Questa tesina si propone quindi di spiegare nel primo capitolo cosa si intenda con la
parola Agente, estendendo poi il concetto ai Sistemi Multi Agente (MAS) nel
capitolo due. Il terzo capitolo prende in esame come ciò che abbiamo descritto finora
sia stato definito dal FIPA (Foundation for Intelligent Physical Agents), e, dopo un
breve quarto capitolo che descrive le differenza fra i concetti di Agente ed Oggetto e
dimostra come con il linguaggio UML non possano essere modellati Agenti e MAS,
si termina con un quinto capitolo che tratta in modo approfondito l’ Agent UML,
standard sviluppato dal FIPA come estensione dell’ UML per sopperire alle carenze
suddette.

2
Capitolo 1

Agenti

Dai concetti dell’intelligenza artificiale, è risultata di grande interesse tra i ricercatori

l’idea di riprodurre il comportamento umano all’interno di entità software, che hanno
proposto in questo ambito numerose nuove teorie, tra le quali spicca la teoria degli
agenti.
Storicamente, infatti, il concetto di agente deriva dall’ “actor model” (modello degli
attori), nato negli anni ’70 nell’ambito dell’Intelligenza Artificiale Distribuita (DAI,
Distributed Artificial Intelligence). Da allora molte definizioni di agente sono state
date in letteratura, ne vedremo adesso alcuni esempi.

1.1 Definizione
Una delle prime definizioni che sia stata data è la seguente, di Hewitt nel 1977:
“Una attore è un’ entità software che possiede un indirizzo di posta e
un comportamento. Gli attori comunicano scambiandosi messaggi e
agiscono con correntemente”.
Il concetto di attore si è poi evoluto in quello di agente, e una delle definizioni più
diffuse è del 1995, scritta da Wooldridge e Jennings:
“Un agente è un sistema informatico situato in un certo ambiente,
capace di azioni autonome in tale ambiente allo scopo di raggiungere
i propri obiettivi”.
Va chiarito, in effetti, che non esiste una definizione di agente che sia a oggi
universalmente accettata e per questo motivo spesso si rinuncia a dare una
3
definizione formale e precisa di agente, preferendo concentrarsi sulla descrizione di
altri aspetti, quali:

 le caratteristiche degli agenti

 le diverse tipologie di agenti esistenti
 le caratteristiche dell' ambiente in cui essi operano

Passiamo ora a descrivere questi punti in modo più approfondito.

1.2 Caratteristiche
L' agente deve essere prima di tutto autonomo: senza alcun intervento dell' utente
deve essere in grado di eseguire azioni legate a un processo o a un obiettivo. I due
esempi più rilevanti di autonomia sono i seguenti:
 autonomia dinamica (anche chiamata “proattività”, in contrapposizione alla
reattività), o capacità di dire “go”: consiste nell' essere in grado di prendere
l'iniziativa per raggiungere i propri obiettivi.
 autonomia deterministica,o capacità di dire “no”: se un agente comanda un
altro agente al fine di fargli eseguire un' azione, questi può rifiutarsi.
Le altre caratteristiche proprie degli agenti, oltre all' autonomia sono:
 abilità a comunicare: nel sistema possono essere presenti svariate sorgenti:
altri agenti, basi di dati, pagine web, esseri umani. L'agente deve essere in
grado di accedere alle loro informazioni, e comunicare le proprie;
 capacità di cooperazione: gli agenti devono poter agire insieme nel caso si
debbano eseguire processi complessi per il raggiungimento di obiettivi comuni;
 capacità di ragionamento: un agente deve poter prendere decisioni in base alla
propria esperienza e alle proprie conoscenze;

4
  capacità di adattamento: (concetto noto anche come “apprendimento”) l'
agente deve poter valutare lo stato attuale del suo dominio esterno e inserire
queste informazioni all'interno delle decisioni future;
 sincerità: l'agente deve sempre agire e fornire le informazioni a sua
disposizione, in modo sincero verso l'utente e gli altri agenti.
Infine l' agente deve agire sempre per il bene del suo proprietario.
Non è detto che un agente debba rispettare sempre tutte queste caratteristiche, ad
esempio vi sono molte applicazioni in cui l' apprendimento non solo non è richiesto,
ma potrebbe addirittura risultare nocivo.
Per ogni agente viene,di norma,definito un effector capacity, ovvero un insieme di
azioni per lui disponibili. Il suo problema primario diventa quindi la decisione di
quale di queste azioni effettuare per raggiungere il suo obiettivo nel miglior modo
possibile, dove con “migliore” si intende il soddisfacimento di una certa funzione
predefinita di costo o di guadagno.

1.3 Tipologie

Le sette tipologie di agenti che si possono descrivere, creandone una suddivisione

anche a seconda degli obiettivi, motivazioni e problemi che li caratterizzano, sono i
seguenti:

 Collaborative Agents (agenti collaborativi): strettamente legati al concetto di

Sistema Multi Agente, sono agenti autonomi con la capacità di collaborare con
altri agenti. La capacità di apprendimento è un requisito non essenziale in
questo caso.
 Interface Agents (agenti d' interfaccia): chiamati anche personal assistants,
hanno il compito di comunicare con l' utente. Sono autonomi ma, al contrario

5
 della tipologia precedente, hanno capacità di apprendimento e non
comunicano solitamente con altri agenti.
 Mobile Agents (agenti mobili): agenti in grado di spostarsi (migrare) da un
terminale a un altro, durante la loro stessa esecuzione.
 Information/Internet Agents: agenti atti alla gestione delle informazioni,
ingenti ed eterogenee, provenienti da differenti fonti. Queste informazioni sono
spesso prelevate da Internet tramite una interazione con i motori di ricerca.
 Reactive Agents (agenti reattivi): agenti privi di proattività, che agiscono solo
secondo il principio richiesta-risposta.
 Hybrid Agents (agenti ibridi): agenti che combinano una o più delle tipologie
qui sopra illustrate.
 Smart Agents (agenti intelligenti): agenti dotati di autonomia, collaborazione
ed apprendimento.

Il termine intelligente dipende dal contesto, ma sicuramente non significa che non
commettano errori.
Solitamente indica invece un agente in grado di ottenere i propri obiettivi eseguendo i
propri compiti in modo flessibile e razionale, date le informazioni possedute, così da
ottimizzare una data misura di prestazione.

6
1.4 Ambienti in cui lavorano

Una possibile classificazione delle possibili proprietà degli ambienti è stata data da
Russel e Norvig, nel seguente modo:

 accessibilità/non accessibilità;
 determinismo/non determinismo;
 episodicità/non episodicità: avvenimenti periodici sono più semplici da
affrontare; l' agente infatti può in questo caso decidere quale azione compiere
basandosi unicamente sull' episodio corrente;
 staticità/dinamicità;
 discreto/continuo: per capire questo concetto possiamo pensare alle pedine su
una scacchiera come esempio di moto discreto, e un veicolo come esempio di
moto continuo;

Nei casi reali abbiamo una maggiore corrispondenza con le classi di ambienti più
complesse, ovvero quelle inaccessibili, non deterministiche, non episodiche,
dinamiche e continue.

7
Capitolo 2

Sistemi Multi Agente (MAS)

Le motivazioni per cui si rende necessario un sistema multi agente possono essere
riassunte nei seguenti punti:
 Problemi troppo grandi e complessi per un singolo agente
 Necessità di una interconnessione di sistemi esistenti
 Soluzioni a problemi inerentemente distribuiti (Air Traffic Control)
 Soluzioni a problemi in cui l'esperienza è distribuita (Sanità)
 Miglioramento della performance, nel caso la comunicazione venga limitata
 Affidabilità (recover from failure) ed estensibilità
Partiamo quindi cercando di definire un sistema multi agente

2.1 Definizione

Non si può pensare ad un sistema multi agente semplicemente come ad un insieme di

agenti, ma esso è composto da più agenti che interagiscono comunicando, che sono
capaci di agire nell' ambiente in cui si trovano, che hanno diverse “sfere d'influenza”
(che in alcuni casi possono anche coincidere) e che sono legati da altre relazioni ad
altre entità organizzative.

8
 Figura 2.1 Architettura Multi Agente
Se gli agenti sono molto numerosi diventa difficile considerarli individualmente ed è
più conveniente trattarli collettivamente come società di agenti o agenzia.
Il termine “agenzia” è stato usato per la prima volta da M. Minsky secondo il quale
gli agenti sono quelle entità della nostra mente che sono in grado di svolgere compiti
semplici, ma presi individualmente non sono in grado di svolgere un compito
complesso.
Secondo Minsky per fare in modo che ciò sia possibile basta strutturare
adeguatamente l' interazione tra gli agenti elementari. Si rende disponibile l'
informazione di cosa un agente fa, ma non di come lo fa (interfaccia).
In questo contesto gli agenti sono sede di attività inferenziale, ovvero di una
produzione di nuova conoscenza partendo da quella di base, e sono quindi agenti
intelligenti.
Una volta progettati i singoli agenti, per inserirli infine in un' agenzia bisogna
definirne il livello di: interazione (perché gli agenti cooperano?), cooperazione (quali
meccanismi assicurano la cooperazione?), comunicazione (come comunicano tra
loro?), organizzazione.
Valutiamo un po' più approfonditamente proprio quest'ultima.

9
2.2 Organizzazione di un MAS

Figura 2.2: Redundancy vs Specialisation

Una prima definizione delle possibili organizzazioni è data dalla tabella seguente:

 Non-redundant generalist organisation: ogni agente può eseguire più azioni e

ogni azione è eseguita solo da pochi agenti.
 Redundant specialist organisation: ogni agente può eseguire solo poche azioni
e ogni azione è eseguita da più agenti.
 Redundant generalist organisation: ogni agente può eseguire molte azioni e
ogni azione è eseguita da più agenti.
 Non-redundant specialist organisation: ogni agente può eseguire poche azioni
e ogni azione è eseguita da pochi agenti.

Ulteriori specifiche della tipologia dell' organizzazione sono date da:

 Organizzazione verticale: tra due agenti, uno è sempre identificabile come
master e l' altro come slave. In questa struttura il master assegna i compiti allo
slave e usa i risultati che esso gli fornisce;
 Organizzazione orizzontale: se ogni agente può essere sia master che slave.

10
2.3 Modelli fisici

I sistemi multi agente possono rispecchiare i seguenti diversi modelli fisici:

 Blackboard: vi sono diverse KS (Knowledge Sources) indipendenti e
asincrone, le quali comunicano mediante un database condiviso (la blackboard
appunto) in cui le KS possono leggere o scrivere in determinati livelli;
 Contract-Net: un' unica unità centrale costituisce il piano e provvede poi a
distribuirlo ad agenti organizzati orizzontalmente.Si usa un sistema di richieste
ed offerte tra agenti “manager” e “contractor” al fine di mantenere la
distribuzione del piano uniforme.
 Centralized Multiagent Planning: prevede un piano centrale che, per essere
eseguito, richiede che ogni agente esegua i suoi piani individuali. Ogni piano
individuale può essere anche in opposizione ad altri, in quanto un singolo
agente ha una vista parziale del sistema. Questi conflitti vengono risolti da un
agente privilegiato.
 Deductive Belief Model: agenti-osservatori costruiscono dei piani in base alla
conoscenza degli agenti-attori.
 Body-Head-Mouth: Suddivisione in tre componenti, uno funzionale (corpo)
orientato alla risoluzione dei problemi, uno cooperativo (testa) che conosce gli
altri agenti, infine uno comunicativo (bocca) che gestisce l’invio dei messaggi
da e per la testa. Gli agenti richiedono la collaborazione solo quando non sono
in grado di risolvere un task.
 Choir: agenti visti come robot, con capacità quindi attuative e percettive. Un
particolare agente identificato come “direttore”, sincronizza gli agenti e attua
pianificazioni dinamicamente. Ogni agente opera al fine di raggiungere il
proprio obiettivo e ha una percezione di come il sistema si stia muovendo
verso l’obiettivo globale.

11
  Molecolare: agenti visti come molecole che comunicano fra loro con messaggi,
anche di tipo broadcast.

Questi modelli riassumono al loro interno le principali strategie tramite le quali gli
agenti comunicano tra di loro. Ne analizziamo in seguito tre particolari.

2.4 Stragtegie di coordinamento e negoziazione

Innanzitutto è necessario specificare che l’utilizzo di una delle seguenti strategie

piuttosto che di un’ altra dipende principalmente dal tipo di organizzazione:
gerarchica, ad autorità strutturata, a mercato, a comunità.

 Pianificazione multi-agente: è una organizzazione di tipo master-slave in cui

per prima cosa il master definisce i vari piani parziali e li invia ad un insieme
di agenti (slave) che li possono eseguire; in seguito ogni slave esegue i suoi
piani ed invia i risultati; infine il master compone i risultati ricevuti.
 Contrattazione: si compone di tre fasi:
1. Recognition: l’ agente riconosce di avere in carico un problema per il
quale necessita di aiuto, o perché non ha le capacità di raggiungere il
goal da solo, o perché (per problemi di qualità della soluzione, deadline,
ecc) preferisce non arrivare al goal da solo.
2. Announcement: l’agente che possiede il task in questione manda un
annuncio in cui include delle specifiche, come la descrizione del task,
eventuali vincoli, eccetera. L’ annuncio è un broadcast.
3. Bidding: gli altri agenti decidono se offrirsi o no per il task, se sì
emettono un’ offerta.

12
 4. Awarding: l’agente che ha inviato il task guarda le varie offerte e decide
chi assegnare al contratto e comunica la decisione a tutti coloro che
avevano fatto un’ offerta.
5. L’ appaltatore quindi spedisce il task.
 Risoluzione distribuita dei problemi: esempio del metodo dei piani parziali
globali: ogni agente definisce un piano globale, lo invia agli altri agenti
coinvolti nel piano, riceve i piani globali di tutti gli altri e costruisce un piano
parziale globale; ciclicamente ognuno invia il piano parziale globale agli altri,
riceve i loro piani parziali globali e modifica il proprio; questo finchè il proprio
piano non è uguale a quelli ricevuti.

13
Capitolo 3

FIPA (Foundation for Intelligent Phisical Agents)

Fipa (Foundation for Intelligent Physical Agents) è un'associazione no-profit nata nel
1996 e registrata a Ginevra, Svizzera. E’ un'organizzazione internazionale con lo
scopo di promuovere l'industria degli agenti intelligenti sviluppando le specifiche che
sostengono l’interoperabilità fra gli agenti e le applicazioni basate su di essi.
Questo viene effettuato tramite una collaborazione aperta fra le relative
organizzazioni, che sono aziende ed università attive nel campo degli agenti. FIPA
fornisce i risultati delle relative attività disponibili a tutte le parti interessate ed
intende fornire i relativi risultati agli organismi appropriati ove necessario.
I membri di FIPA sono impegnati individualmente e collettivamente in una
competizione aperta nello sviluppo delle applicazioni basate sugli agenti, dei servizi e
delle attrezzature. Coloro che collaborano con FIPA possono essere corporazioni,
associazioni, organismi di governo od organizzazioni internazionali senza limitazioni.
Le specifiche di FIPA sono sviluppate con la partecipazione diretta dell'insieme dei
membri di FIPA. Lo stato di queste specifiche può essere Preliminare, Sperimentale,
Standard, Disapprovato od Obsoleto.

3.1 Architettura

Le specifiche attualmente approvate sono callsificate per argomenti, come

schematizzato nella seguente figura:

14
 Figura 3.1: Categorie delle specifiche FIPA
 Agent Comunication: definisce la struttura generica del linguaggio di
comunicazione tra gli agenti (FIPA-ACL) e specifica alcuni protocolli di
interazione, che vengono formalizzati tramite diagrammi AUML.
 Agent Management: definisce un’ infrastruttura generica in cui si possano
muovere gli agenti e specifica le entità necessarie alla comunicazione e alla
gestione degli agenti stessi.
 Agent Message Transport: definisce come deve avvenire la trasmissione dei
messaggi.
 Abstract Architecture: definisce in modo astratto le entità che compongono un
sistema ad agenti, anche attraverso rappresentazioni UML, concentrandosi
soprattutto sull’ interoperabilità tra gli agenti.
 Applications: esempi di applicazioni concrete dei sistemi ad agenti.

Molte delle specifiche FIPA sono “normative”, quindi obbligatorie per ogni
implementazione, mentre altre sono “informative”, ovvero solo linee guida che non si
è obbligati a seguire.

3.2 Agente secondo FIPA

La definizione di agente data data da FIPA nel 2001 risulta molto generica:
“Un processo computazionale che implementa le funzionalità di
autonomia e comunicazione di un’applicazione”.

15
Ogni agente segue un ciclo di vita riassunto nello schema seguente:

Figura 3.2: Ciclo di vita di un agente FIPA

Inoltre ogni agente è caratterizzato da un AID (Agent Identifier), una collezione di
coppie parametro/valore che oltre al nome comprende:

 Tutti gli indirizzi che indicano dove l’agente sia stato: su quale host,
piattaforma e contenitore;
 I resolver, ovvero gli agenti presso cui l’ agente in questione è registrato
 Altri parametri a discrezione del progettista

Il nome dell’ agente è invariabile, tutti gli altri parametri variano durante il suo ciclo
di vita.

3.2.1 Agent Platform (AP)

Un agente può esistere solo all’ interno di un contenitore di agenti, presso una
piattaforma in esecuzione.

16
FIPA definisce questa piattaforma (Agent Platform, AP) come la realizzazione
concreta dell’ Abstract Architecture, ed è l’ambiente in cui gli agenti possonoesistere
ed interoperare.
E’ un sistema composto da uno o più contenitori di agenti, che però possono
appartenere ad ogni istante ad un solo AP, avendo però la possibilità di spostarsi da
una piattaforma all’ altra quando lo ritengono necessario.

La struttura di un’ AP è la seguente:

Figura 3.3: Struttura di un’ Agent Platform

Come si può notare dalla figura, oltre che dall’ hardware e dal sistema operativo, essa
è suddivisa in diverse componenti: software di supporto agli agenti, i FIPA
management components, gli agenti.
Le entità fondamentali per il corretto funzionamento dell’ AP sono appunto i tre
agent management components: Agent Management System (AMS), Directory
Facilitator (DF) e Message Transport Service (MTS) che ci apprestiamo a descrivere.

17
3.2.2 Agent Management System (AMS)
Questo componente è una sorta di supervisore, che controlla l’ accesso e l’uso della
piattaforma. E’ implementato a sua volta come un agente ed è responsabile inoltre
dell’ identificazione e della registrazione degli agenti residenti.

L’AMS gestisce l’intero ciclo di vita di ogni agente e può richiedergli di svolgere uno
specifico compito. Inoltre, se necessario, è in grado di forzare l’esecuzione di un
particolare task. Fornisce inoltre un servizio di “white pages”, “pagine bianche”
tenendo aggiornato un indice di tutti gli agenti presenti in ogni istante sulla
piattaforma, compresi i loro AID.
Tutti gli agenti devono registrarsi presso l’AMS della propria HAP (Home Agent
Platform), cioè la AP dove sono stati creati e che è responsabile dell’identità degli
agenti stessi. Questa registrazione, tramite una fase di autenticazione, comporta
l’autorizzazione di accesso al MTP (Message Transport Service) per poter svolgere le
mansioni di invio e ricezione di messaggi.
La vita di un agente presso una AP termina con la sua deregistrazione. In questa fase
il suo AID diviene disponibile per essere assegnato, eventualmente, ad un altro
agente.
Trattandosi di un agente, anche l’AMS possiede un AID, riservato e rappresentato
nella forma seguente:

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

Due sono i modi con cui un agente si registra presso l’AMS:

 l’agente viene creato sulla AP,

18
  l’agente è stato creato su un’altra AP ed è migrato su quella corrente.(questo
vale solo per le piattaforme che supportano gli agenti mobili.

Un agente può richiedere quattro diversi servizi all’AMS:

 Register: realizza le operazioni di registrazione di un agente
 Deregister: realizza le operazioni di deregistrazione di un agente
 Search: realizza le operazioni di ricerca di un agente
 Modify: realizza le operazioni di modifica dei parametri descrittivi di un agente

3.2.3 Directory Facilitator (DF)

Anche il DF è solitamente implementato come un agente, e fornisce un servizio di
“yellow pages”, “pagine gialle”, tenendo una lista di agenti e dando origine a un
dominio (AD, Agent Domain) con un insieme di agenti e servizi.
L’ utilità del DF consiste nella possibilità di informare il sistema, l’ Ams ed altri
agenti, sia all’ interno della stessa AP che tra AP diverse, dell’ esistenza e
funzionalità degli iscritti.
Per questo motivo deve esistere almeno un DF per ogni AP, che tra le altre cose è
abilitato al mantenimento di collegamenti ad altri DF sulle altre piattaforme.
Il DF ha le stesse funzioni dell’ Ams (register, deregister, search, modify), ma a
differenza dell’ AMS, consente agli agenti di registrarsi indicando non solo il loro
nome ma anche i loro particolari servizi.
Gli agenti possono quindi iscriversi al DF per far conoscere le proprie funzionalità
agli altri agenti, e sempre tramite il DF effettuare ricerche per trovare gli agenti che
offrono un particolare servizio.

19
3.2.4 Message Transport Service (MTS)
L’MTS è il servizio che consente agli agenti di comunicare tra di loro e con AMS e
DF.
Generalmente è implementato in un componente chiamato ACC (Agent
Communication Channel) che utilizza le informazioni dell’AMS (riguardanti lo stato,
l’identità e la locazione di appartenenza degli agenti) per gestire lo scambio di
messaggi tra gli agenti.
Gli agenti comunicano tra loro scambiandosi messaggi FIPA-ACL che vengono
fisicamente trasportati da un agente all’altro (e, se necessario, da una piattaforma
all’altra) dall’MTS utilizzando un protocollo di trasporto (MTP, Message Transport
Protocol). Affinché gli agenti residenti su due piattaforme diverse possano operare, le
due AP devono implementare i protocolli di trasporto definiti da FIPA:

 HTTP (HyperText Transfer Protocol): il noto protocollo applicativo per la

trasmissione di testo e contenuti multimediali su cui si basa il World Wide
Web
 WAP (Wireless Application Protocol): insieme di protocolli che specificano
come i dispositivi senza fili (ad es. telefoni cellulari) possono accedere a
Internet.
 IIOP (Internet Inter-ORB Protocol): protocollo che consente ad applicazioni
distribuite scritte in linguaggi diversi di comunicare attraverso Internet. IIOP fa
parte dello standard CORBA (Common Object Request Broker Architecture).

All’interno di una particolare AP FIPA permette di utilizzare altri tipi di protocolli di

rasporto, ma stabilisce che per la comunicazione interpiattaforma deve essere
utilizzato uno dei tre protocolli sopra elencati.
Da specificare inoltre che non necessariamente MTS e ACC coincidono: l’ MTS può
essere visto come il sistema di trasporto interno alla singola piattaforma (che utilizza

20
spesso un protocollo proprietario) e con ACC il componente che gestisce la
comunicazione con altre piattaforme.
A differenza di AMS e DF, generalmente ACC non è implementato come un agente.

3.2.5 Messaggi FIPA-ACL

Essendo la comunicazione uno degli aspetti fondamentali di un MAS, e dal momento
che essa avviene tramite lo scambio di messaggi, FIPA ha ritenuto necessario definire
un linguaggio univoco (Agent Communication Language, ACL), basato sull’ analisi
linguistica della comunicazione umana e incentrato sull’ idea che con un dialogo si
esprime un’ affermazione ma viene anche compiuta una vera e propria azione.
Un messaggio FIPA-ACL è costituito da uno o più elementi. Nella tabella all’ inizio
della prossima pagina vediamo la descrizione dei principali, definiti dalle specifiche
FIPA, ma oltre a questi, gli sviluppatori sono liberi di aggiungerne di nuovi.
Quali di questi elementi siano necessari dipende dalla situazione; molti possono
essere omessi in quanto ricavabili dal contesto.
L’unico obbligatorio è il performative, ma la maggior parte dei messaggi conterranno
anche gli elementi sender, receiver e content.

Tabella 3.1: Elementi di un messaggio ACL

21
Per quanto riguarda l’ elemento performative elenchiamo qui di seguito i tipi di atti
comunicativi standard di FIPA:

Tabella 3.2: Atti Comunicativi FIPA

22
La rappresentazione fisica dei messaggi può avvenire in modi diversi.
Il formato più utilizzato è quello di stringa, di cui ne vediamo un esempio:
(request
:sender (agent-identifier :name Agent1)
:receiver (set (agent-identifier :name ams))
:content
:language
:ontology FIPA-Agent-Management
:protocol FIPA-Request
:conversation-id 12345
)
La sintassi degli elementi illustrata è chiamata Semantic Language (SL).
Gli altri linguaggi specificati da FIPA sono: Resource Description Framework
(RDF, basato su XML), Knowledge Interchange Format (KIF) e Constraint Choice
Language (CCL, per la definizione di vincoli).

23
Capitolo 4

Agenti e linguaggio a oggetti

Come già accennato nell’ introduzione, l’ avvento di una nuova tecnologia come
quella degli agenti comporta sicuramente dei rishi e il modo migliore per ridurli e
partire da solide basi preesistenti presentando quindi la tecnologia ad agenti come
un’ estensione di un paradigma già noto ed affermato: lo sviluppo del software
orientato agli oggetti.

4.1 Differenza tra Agente e Oggetto

Spesso un agente è implementato come un oggetto, ovevro come una classe che
incapsula le funzionalità implementate dall’ agente, i cui metodi definiscono i
servizi che mette a disposizione degli altri agenti. Nonostante ciò l’ agente è molto
più di un oggeto, o di un insieme di oggetti.
Lo schema seguente ne riassume le principali differenze:

Tabella 4.1: Agenti ed Oggetti

24
 Innanzitutto notiamo che gli agenti, rispetto agli oggetti, sono attivi: possono
prendere iniziative e decidere quando e come elaborare le richieste ricevute.
Inoltre gli agenti non agiscono isolati, ma in cooperazione o coordinazione con altri
agenti.
Per quanto riguarda lo scambio di messaggi, questo esiste sia nel contesto degli
agenti che in quello degli oggetti, ma con significati diversi:
 per gli oggetti significa invocazione di metodi, ossia chiamate di procedure
(generalmente sincrone);
 per gli agenti significa invio e ricezione di atti comunicativi (generalmente
asincroni).
Se implementati come oggetti, gli agenti si scambiano messaggi facendo riferimento
a un identificativo (ad esempio l’ AID), ma mai conservando riferimenti espliciti ad
altri agenti, né invocando direttamente i metodi.

4.2 Programmazione ad Oggetti ed UML

Dal momento che il concetto di agente può essere descritto come un’ estensione del
concetto di oggetto, anche le metodologie di sviluppo dei sistemi ad agenti possono
essere costruite sulla base di quelle ad oggetti.
Nell’ evoluzione delle tecniche Object-Oriented ha avuto un ruolo fondamentale l’
UML (Unified Modeling Language) che, creato inizialmente da Booch, Rumbaugh e
Jacobson, è stato adottato come standard dall’ OMG (Object Management Group) nel
1997 ed è in continua evoluzione.
L’UML è nato per unificare e formalizzare i numerosi approcci esistenti al ciclo di
vita del software object-oriented, e viene utilizzato in tutte le fasi dello sviluppo,
dall’analisi dei requisiti al rilascio del sistema. Ad un livello molto concreto, l’UML
può essere semplicemente visto come un insieme di diversidiagrammi, divisi in
quattro gruppi o modelli , che vediamo rappresentati nella seguente figura e verranno
spiegati brevemente in seguito ad essa:

25
 Figura 4.1: Principali diagrammi UML

 Modello della struttura statica:

o Diagrammi delle classi (Class diagrams): rappresentano un insieme di
classi e le relazioni tra di esse. Non necessariamente sono le classi che
verranno realizzate nell’implementazione: l’UML può e deve essere usato

26
 anche nelle fasi di analisi e progetto, durante le quali le classi possono
rappresentare ad esempio concetti o entità del mondo reale.
o Diagrammi degli oggetti (Object diagrams): come i diagrammi a classi,
con la differenza che rappresentano oggetti concreti, istanze delle classi.
o Diagrammi dei package (Package diagrams): dividono le classi e/o gli
oggetti in raggruppamenti (package), che possono contenere classi, altri
package, o entrambe le cose. I package formano una struttura ad albero
che consente di organizzare meglio un progetto.
 Modello dinamico:
o Diagrammi di sequenza (Sequence diagrams): rappresentano le interazioni
tra gli oggetti (passaggio di messaggi) mettendo in evidenza la dimensione
temporale.
o Diagrammi di collaborazione (Collaboration diagrams): semanticamente
equivalenti ai diagrammi di sequenza, mettono tuttavia in risalto la
dimensione “spaziale” (ovvero le relazioni tra gli oggetti) rispetto a quella
temporale. Nota: i diagrammi di sequenza e di collaborazione sono
chiamati, nel loro complesso, diagrammi di interazione (Interaction
diagrams).
o Diagrammi di attività (Activity diagrams): simili ai “classici” diagrammi di
flusso (e anche, in un certo senso, alle reti di Petri), descrivono la sequenza
di operazioni che devono essere compiute per risolvere un determinato
problema. Non è detto che queste operazioni siano svolte tutte da uno stesso
oggetto: è possibile dividere un diagramma in “corsie” (swimlanes) per
rappresentare le diverse entità che svolgono le azioni.
o Diagrammi di stato (State diagrams o Statecharts): simili ai “classici”
automi a stati finiti, rappresentano i possibili stati (e le transazioni tra essi)
di un singolo oggetto. Uno stato può contenere altri stati “annidati”.

27
 Modello use case:
o Diagrammi Use Case: specificano il modo in cui un sistema interagisce con
“attori esterni” (ad esempio gli utenti o altri sistemi).
 Modello dell’implementazione:
o Diagrammi dei componenti (Component diagrams): rappresentano insiemi
di componenti software e le relazioni tra essi. I componenti spesso sono
istanze concrete di classi definite nel modello statico.
o Diagrammi di deployment (tradotto talvolta come diagrammi di
distribuzione o di rilascio): rappresentano i componenti hardware di un
sistema e le relazioni tra essi. Le entità hardware possono contenere i
componenti descritti dei diagrammi dei componenti.

L’UML è un vero e proprio linguaggio, con una grammatica ed una sintassi, che
fornisce tra l’altro molti meccanismi di estensione, risultando così molto flessibile e
facilmente adattabile alle esigenze degli sviluppatori. L’esempio più comune è quello
dei diagrammi ibridi, dove vengono usati simboli presi da diversi diagrammi.

Questo linguaggio purtroppo presenta però anche svariate carenze:

 Modellazione dei messaggi: come in ogni metodo di specifica ad oggetti, lo
scambio di messaggi è assimilato alla chiamata di metodo. Questo però non è
adatto per modellare lo scambio di messaggi in un MAS, innanzitutto la
comunicazione in un MAS solitamente non è sincrona, inoltre l’eterogeneità
degli agenti in un MAS costringe ad adottare soluzioni più complesse rispetto
alla chiamata di un metodo.
 Modellazione dei protocolli di comunicazione: UML fornisce gli interaction
diagrams per stabilire il flusso delle comunicazioni tra due o più istanze di
classe, nell’ambito di un MAS servirebbe la possibilità invece di modellare il
protocollo di comunicazione tra due o più ruoli che possono essere ricoperti da
agenti.
28
  Modellazione dei ruoli: in UML lo stato ed il comportamento di un oggetto
definiscono il ruolo che un oggetto può ricoprire. A sua volta un ruolo adempie
le responsabilità dell’ oggetto, ovvero tutti i servizi che l’ oggetto fornisce per
ogni contratto che supporta. Comunque un oggetto non cambia i servizi offerti
col cambiare dei ruoli, l’interfaccia che esso esporta rimane statica. Un agente
è invece maggiormente dinamico e al mutare dei suoi ruoli muta anche i servizi
offerti.
 Assegnazione dei ruoli a una specifica classe di agente: in UML non esiste un
“diagramma dei ruoli”, che sono invece un’ utile astrazione per gli agenti.

Allo stato attuale questo strumento non risulta quindi sufficiente per modellare gli
agenti e i sistemi multi agente, che necessitano di una metodologia che supporti l’
intero processo di sviluppo ad agenti: pianificazione, analisi, progetto, realizzazione
del sistema , collaudo, manutenzione.
Tra le principali organizzazioni che si occupano di studiare estensioni alle
metodologie esistenti troviamo appunto FIPA, che propone l’ estensione chiamata
Agent UML (AUML), trattata nel prossimo capitolo.

29
Capitolo 5

Agent UML

Attualmente l’AUML non è ancora un vero standard, quanto piuttosto un obiettivo.

Le principali estensioni dell’AUML proposte da diversi ricercatori finora, riguardano
i seguenti argomenti:

 Protocolli di interazione: formalizzano le sequenze di messaggi scambiati tra

due o più agenti. Generalmente vengono rappresentati con diagrammi di
sequenza (opportunamente modificati), ma possono anche essere modellati con
diagrammi di attività, di collaborazione o di stato.
 Classi di agenti: rappresentate con diagrammi delle classi.
 Elaborazione interna agli agenti: rappresentata con diagrammi dinamici,
soprattutto attività e stato.
 Modellamento dei ruoli: rappresentazione dei molteplici ruoli che un agente
può assumere in una conversazione.

L’AUML propone inoltre formalismi per modellare numerose altre caratteristiche

tipiche degli agenti, come ad esempio l’eventuale mobilità, l’uso di agenti come
interfacce verso sistemi, e relazioni complesse tra agenti.

5.1 I Diagrammi AUML

Analizziamo ora le principali novità dell’estensione, evidenziandone in particolare le
differenze rispetto all’ UML.

30
5.1.1 Diagrammi di Protocollo
Un protocollo di interazione tra agenti (AIP, Agent Interaction Protocol) descrive un
modello di comunicazione, ovvero la sequenza consentita dei messaggi scambiati ed
eventuali vincoli sui contenuti di tali messaggi.
In AUML un AIP è rappresentato con un’estensione del diagramma di sequenza: il
diagramma di protocollo (Protocol diagram).
L’esempio che segue mostra un esempio del Contract Net, uno dei protocolli di
negoziazione più diffusi.

Figura 5.1: Protocollo Contract Net

L’ interno protocollo è racchiuso in un package così che il protocollo possa
rappresentare un’ entità a sé all’ interno del progetto. Ricordiamo che nell’ UML i
package raggruppano soltanto classi mentre in AUML possono raggruppare
qualunque elemento. Il protocollo è anche un pattern i cui parametri sono elencati nel
riquadro tratteggiato.
Come nei normali diagrammi UML la dimensione verticale (lifeline), rappresenta il
tempo, che scorre dall’ alto verso il basso. Nella dimensione orizzontale invece non

31
abbiamo più oggetti ma ruoli, che in questo esempio sono Initiator (entità che dà
inizio alla conversazione) e Partecipant (entità che riceve il primo messaggio).
Le frecce indicano l’ invio dei messaggi asincroni da un’ entità all’ altra, con
eventuale aggiunta di simboli alle estremità per indicarne la molteplicità.
Sono stati inoltre inseriti nuovi simboli per indicare delle “decisioni” circa i messaggi
(o atti comunicativi) da inviare, il cui significato è spiegato nella seguente figura:

Figura 5.2: Relazioni fra atti comunicativi

Nell’esempio del Contract Net, l’Initiator inizia la conversazione con un atto “call-
for-proposal”, e il Participant può scegliere di rispondere con “refuse”, “propose” o
“not-understood” (la “x” indica l’or esclusivo tra i messaggi), infine “deadline”
indica il tempo limite oltre il quale un’eventuale proposta da parte di Participant verrà
automaticamente rifiutata dall’Initiator.
Il diagramma di protocollo può esprimere anche la concorrenza dell’elaborazione: ad
esempio, i due frammenti di diagramma che seguono sono equivalenti (in figura
viene mostrato il caso “exclusive or”, ma esistono rappresentazioni analoghe nei casi
“and” e “or”).

Figura 5.3: Rappresentazione di thread concorrenti

32
Un protocollo, quindi, è un modello (template), i cui parametri generici sono
chiamati unbound parameters. Volendo applicare il pattern ad un caso concreto,
occorre sostituirli con i loro valori effettivi (bound parameters).
Questo modo di utilizzare i modelli fa parte dell’AUML, non dell’UML.
Nel seguente esempio in figura , i nomi dei ruoli sono stati sostituiti dai nomi
effettivi degli agenti,la deadline generica è diventata un istante di tempo; addirittura
sono stati introdotti due tipi diversi di messaggio “refuse”.

Figura 5.4: Istanza di un template di protocollo

5.1.2 Diagrammi di Classe

Per rappresentare una “classe di agenti” rendendola distinguibile da una classe
ordinaria, l’ AUML propone un nuovo simbolo, mostrato nella figura a sinistra.
Alternativamente si può usare la notazione UML classica con l’aggiunta di uno
stereotipo ( con cui si intende una versione specializzata di un simbolo già esistente)
“agent” .

Figura 5.5: Rappresentazioni di una classe di agenti

33
Una ulteriore proposta è quella nella seguente figura, e permette di specificare
informazioni più dettagliate circa un agente.

Figura 5.6: Rappresentazione nuova (sinistra) e notazione classica (destra)

Innanzitutto si ha nella prima riga il nome della classe di agenti, seguita, dopo la
barra, da un elenco di ruoli che l’agente può ricoprire. Il nome può anche essere
sottolineato per indicare che si sta descrivendo un agente concreto (individual agent,
ovvero un’istanza) e non una classe.
La descrizione dello stato contiene un normale elenco di campi, come in UML:
tuttavia viene definito un nuovo tipo di dato, chiamato “wff” (“well formed formula”,
formula ben formata), utilizzato per rappresentare qualsiasi tipo di descrizione logica
dello stato, indipendentemente dalla particolare implementazione. Ad esempio, se si
modella un agente con la tecnica BDI, è possibile definire quattro variabili: beliefs,
desires, intentions e goals (questi ultimi, eventualmente, suddivisi in permanent-goals
e actual-goals), tutte di tipo “wff”. Alcuni attributi possono essere persistenti, in tal
caso ad ognuno di essi è aggiunto lo stereotipo “persistent”.

34
Le azioni si differenziano dai metodi in quanto modellano i comportamenti reattivi e
proattivi dell’agente, rispettivamente rappresentati dagli stereotipi “reactive” e “pro-
active” (non mostrati nella figura); le azioni sono visibili agli altri agenti, mentre i
metodi sono utilizzabili solo dall’agente stesso. Per il resto, azioni e metodi sono
specificati in modo identico, secondo le consuete regole dell’UML.
L’interfaccia di un agente verso il mondo esterno è costituita dall’invio e ricezione di
atti comunicativi, rappresentati con i due simboli a forma di frecce nella figura di
sinistra, oppure, nella figura di destra, con i cerchi che in UML rappresentano il
concetto di “interfaccia”. La notazione “atto/protocollo” (ad esempio “CA-
1/protocol” nella figura) indica che un messaggio contenente un certo tipo di atto
comunicativo è ricevuto nell’ambito di un certo protocollo (“default” indica un atto
comunicativo qualsiasi). Al posto di “atto/protocollo” si può scrivere
“protocollo[atto]”.
Infine, l’ “agent-head-automata” rappresenta il comportamento dell’agente, il suo
“motore”.
Nel prossimo paragrafo verrà trattato come il “cuore” di un agente possa essere
rappresentato tramite diagrammi di attività e stato.

5.2 Elaborazione interna degli agenti

L’ AUML introduce nuovi simboli anche per rappresentare attività di altri agenti,.
Nei diagrammi di attività i rettangoli con interruzioni agli angoli indicano attività
esterne:

Figura 5.7: Esempio di Activity Diagram esteso

35
Nei diagrammi di stato le attività esterne sono rappresentate da frecce tratteggiate:

Figura 5.8: Esempio di Statechart esteso

Infine l’ AUML dà la possibilità di aggiungere i simboli di ricezione e di invio
(ovvero le frecce) nei diagrammi di stato così da rappresentare come un “agent head
automata” reagisce ad un determinato tipo di atto comunicativo:

Figura 5.9: Altro esempio di Statechart esteso

5.3 Rappresentazione dei ruoli

Un ruolo (“agent-role”) è un insieme di agenti che soddisfano certe proprietà. UML
già supporta questo concetto prevedendo anche la possibilità di classificazione
multipla e di classificazione dinamica (caso di un agente che cambia ruolo nel
tempo).

36
Il fatto che una classe di agenti supporti alcuni ruoli si indica con la seguente
notazione:
nome-classe-agente / ruolo1, ruolo2, …
Per indicare invece che un certo numero di istanze (agenti) soddisfano certi ruoli, si
usa questa notazione:
istanza1, istanza2, … / ruolo1, ruolo2, … : nome-classe-agente
Nelle due figure seguenti vediamo come sia possibile modellare i ruoli con i classici
diagrammi di sequenza UML:

Figura 5.10: Modellamento dei ruoli con UML standard

Figura 5.11: Modellamento alternativo dei ruoli con UML standard

37
Nella prima figura, per ogni agente si ha una diversa linea di vita per ogni ruolo che
rappresenta, nella seconda ci si concentra solo sui ruoli. Si può notare come,
descrivendo pochi agenti con limitatissimi ruoli assegnati a ciascuno, risultino
diagrammi già complessi e di difficile comprensione.
L’ AUML propone due estensioni per rappresentare in maniera più agevole la
rappresentazione dei ruoli nelle conversazioni. Le prossime due figure ne danno un
esempio:

Figura 5.12: Modellamento dei ruoli con AUML

Figura 5.13: Modellamento dei ruoli alternativo con AUML

38
Nella prima figura gli agenti sono indicati soltanto una volta ciascuno, e ad ogni linea
di vita è associato un ruolo indicato dallo stereotipo “role”.
Nella seconda figura, invece, le barre di attivazione vengono “etichettate” con il
nome del ruolo.

5.4 Stereotipi
In quest’ ultimo paragrafo vengono presentati in una tabella alcuni stereotipi proposti
per rappresentare concetti usati frequentemente nell’ ambito di sistemi ad agente.

Tabella 5.1: Stereotipi AUML

39
Capitolo 6

Conclusioni

Nell' ultimo capitolo abbiamo approfondito le novità introdotte nell' Agent UML
come estensione di UML, per rendere possibile la rappresentazione degli agenti e
dell' interazione fra questi.
Si deve ricordare però che l' AUML è ancora in fase di studio, ed ha quindi alcune
lacune ancora presenti.
Riprendiamo ad esempio i diagrammi di protocollo: questi possono essere usati per
dare informazioni su come gli agenti si attivano l'un l'altro temporalmente e, tramite l'
uso di AND, OR e XOR la possibilità che un agente richiami uno o più altri agenti in
attività parallele. E' da notare però come la gestione di eccezioni sia ancora da
definire: le proposte sono state svariate ma poco rappresentative (ad esempio Bergent
e Poggi hanno proposto piccoli commenti testuali a lato del diagramma per
specificare eccezioni).
In un paper di Lynch e Rajerdan viene proposto un diagramma, in grado di illustrare
complesse catene di attività di agenti ed eccezioni, che hanno chiamato “schedule
diagram”.
Vediamone un esempio nella figura nella pagina seguente,concludendo con questo lo
studio dell' Agent UML:

40
 Figura 6.1: Schedule Diagram

Questo diagramma rappesenta un semplice processo con la richiesta “move the red
block onto the green one” dove un braccio robotico riceve istruzioni vocali per
muovere i blocchi. Vengono rappresentate atività sia sequenziali che parallele con
agenti chiamati: textOut, speak e animate. Sono infine mostrati i punti in cui l'agente
può incorrere in un fallimento: gli agenti possono infatti lanciare esplicitamente
eccezioni o, in caso di morte di un agente o timeout, le eccezioni sono lanciate dal
kernel.
L' equivalente del diagramma mostrato in figura è il codice seguente:

(try (seq (par (animate (grasp red#4)

:throw exit1)
(speak (picking up red))
(textOut (grasp red))
)
41
 (par (animate (drop on green#3)
:throw exit2)
(speak (dropping on green))
(textOut (drop on green))
)
(speak (ok, what now))
)
(catch exit1
(seq (speak (unable to grasp red))))
(catch exit2
(seq (speak (unable to drop on green))))
)

Questa sintassi è in grado di differenziare chiaramente il caso in cui un agente ne

attivi un altro e il caso in cui un agente ne chiami un altro, aspettando la risposta.
Possono essere inoltre inclusi nel diagramma punti di resincronizzazione, e i ritardi
sono implementati tramite una icona ad orologio con annotato il delay time.
Le eccezioni sono chiaramente evidenziate e , se necessario, i diagrammi possono
essere suddivisi in diversi sotto-diagrammi o sezioni.
Oltre a questo paper, esistono molti libri in letteratura in cui diversi ricercatori
propongono soluzioni nuove in grado di sopperire a mancanze dell’ AUML.
Si può quindi sostenere che, nonostante FIPA sia attualmente stabile per quanto
riguarda le specifiche dell’ AUML, e nonostante siano ora presenti UML 2.1 ed altri
standard come il Systems Modeling Language (SysML) rilasciati dall’ OMG (Object
Management Group) che comprendono molti dei concetti necessari alla descrizione
dei Sistemi Multi Agente, lo studio sull’ AUML non è comunque terminato, anzi, è
sempre aperto a nuovi studi su quali altre modifiche sarebbero necessarie per una
migliore rappresentazione degli agenti e dei sistemi basati su agenti.

42