Dipartimento di Matematica e Informatica

Corso di Laurea in Informatica

25 Marzo 2015

Progettazione e Realizzazione di un

Domain Specific Language per Agenti

Software

Design and Implementation of a Domain

Specific Language for Software Agents

Relatore:Chiar.mo Prof. Federico Bergenti

Candidato:Massimiliano Braglia

Anno Accademico 2013 - 2014

A CamillaAi miei genitori, Isotta e Claudio

Ai miei fratelli, Emanuele e FrancescoAlla mia famiglia

A Alessandra, Lara e NoemiA Laura, Giuliana, Matteo e Luis

A LaraA FrancescoA Eleonora

Agli Anabasi Road, Andrea, Nicholas, Luca, Alessio e RiccardoA tutti coloro che mi sono stati vicini.

Perche e solo grazie a voi, se tutto questo e stato possibile.

Indice

Introduzione ii

1 Agenti Software e JADE 11.1 JADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Ambiente runtime - container e platform . . . . . . . . 11.1.2 Agenti . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1.3 Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . 51.1.4 Comunicazione fra agenti: i messaggi ACL . . . . . . 91.1.5 Ontologie . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Realizzazione di un Domain Specific Language tramite Xtexte Xbase 132.1 Xtext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.1 Usare Xtext . . . . . . . . . . . . . . . . . . . . . . . . 142.2 Xbase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.1 Usare Xbase: MyDsl per ricette culinarie . . . . . . . 19

3 JADEL 293.0.2 JADEL, la grammatica . . . . . . . . . . . . . . . . . 31

Conclusioni 44

A JADEL: Sviluppi Futuri 45A.1 Premessa: i test del linguaggio . . . . . . . . . . . . . . . . . 45A.2 JadelValidator . . . . . . . . . . . . . . . . . . . . . . . . . . 45A.3 JadelJvmModelInferrer . . . . . . . . . . . . . . . . . . . . . . 45A.4 JadelScopeProvider . . . . . . . . . . . . . . . . . . . . . . . . 46A.5 JadelQuickfixProvider . . . . . . . . . . . . . . . . . . . . . . 46A.6 LabelProvider e OutlineTreeProvider . . . . . . . . . . . . . . 46A.7 JadelProposalProvider . . . . . . . . . . . . . . . . . . . . . . 47A.8 JadelFormatter . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Bibliografia 48

i

Introduzione

In questo lavoro di tesi e stato realizzato un primo prototipo di uno strumen-to a supporto di un Domain Specific Language (DSL) denominato JADEL(JADE Language).

Un DSL e un linguaggio specializzato in un certo dominio applicativo,al contrario dei GPL (General Purpose Language) che operano indipenden-temente dal contesto, come C, C++ o Java. Esistono diversi tipi di DSL,che vanno dall’uso comune come HTML per le pagine Web, SQL per l’in-terrogazione di basi di dati, o addirittura DSL per la personalizzazione dialcune parti di sistemi software complessi come, ad esempio, X++ per lacustomizzazione e l’estensione degli applicativi Microsoft Dynamics.

JADEL nasce con l’intento di semplificare l’uso del framework JADE(Java Agent DEvelopment Framework) sviluppato dall’Universita di Parmain collaborazione con Telecom Italia S.p.A. (jade.tilab.com) automatizzandoalcune fasi ripetitive della scrittura del codice grazie al compilatore JADELe migliorarne la leggibilita. Questa tesi e strutturata come segue:

Capitolo 1: Agenti Software e JADEIn questo capitolo vedremo in breve che cosa si intende per agentisoftware e come vengano gestiti in JADE, il nostro dominio applicativo.

Capitolo 2: Realizzazione di un Domain Specific Language tramite Xtexte XbaseXtext e Xbase. Che cosa sono e come si usano.

Capitolo 3: JADELViene descritto il core della tesi: il linguaggio JADEL.

La tesi viene conclusa con un sunto del lavoro svolto e con un’appendiceche descrive in modo strutturato gli sviluppi futuri.

ii

Capitolo 1

Agenti Software e JADE

Il primo capitolo di questa tesi presenta gli agenti software, in particolaregli agenti software che si possono gestire con il framework JADE.

Definizione (Agente software). Un agente software e un’entita softwareautonoma atta al raggiungimento di un certo obiettivo.

JADE (Java Agent DEvelopement Framework, si consulti jade.tilab.com)e un framework open source rilasciato sotto licenza LGPL interamente scrit-to in linguaggio Java. Nasce per semplificare l’implementazione di sistemimulti-agente attraverso un middle-ware conforme allo standard FIPA (TheFoundation for Intelligence Physical Agents, www.fipa.org).

1.1 JADE

Il pacchetto JADE contiene:

• un ambiente runtime nel quale gli agenti JADE vivono e cooperano;

• una libreria di classi che i programmatori utilizzeranno per svilupparei loro agenti;

• un insieme di tool grafici che permettono di gestire e monitorare l’at-tivita degli agenti in azione.

1.1.1 Ambiente runtime - container e platform

Ogni istanza dell’ambiente runtime di JADE e chiamato container ed e l’am-biente in cui vivono gli agenti. L’insieme dei container e denominato AgentsPlatform (AP). Ogni platform ha sempre almeno un container attivo, ilmain container.

1

Figura 1.1: Architettura di JADE

Il main container e il primo container ad essere lanciato. A differenzadegli altri, esso contiene fin da subito due agenti particolari:

AMS (Agent Management System), nasce per fornire un servizio dinaming (per garantire, ad esempio, che ogni agente abbia un nome uni-voco) e rappresenta l’autorita all’interno della platform (ad esempio,la possibilita di creare e/o uccidere agenti su richiesta).

DF (Directory Facilitator), mette a disposizione un servizio di paginegialle all’interno della platform corrente. Questo significa che gli agentiche forniscono servizi possono essere trovati, mediante il DF, da tuttigli altri agenti, che sfruttano tali servizi per il raggiungimento dei loroscopi.

La comunicazione tra agenti avviene attraverso il Message TransportService (MTS ), il servizio di trasporto messaggi fornito dalla loro AP, dae verso gli agenti della stessa o da e verso agenti presenti in un’altra AP.Per essere conformi allo standard FIPA, i messaggi devono essere scritti nel

2

linguaggio ACL (Agent Communication Language), il linguaggio propostodallo standard per la comunicazione fra agenti.

Una volta sviluppato un agente, per attivare JADE, quindi il maincontainer e l’interfaccia di gestione utilizziamo il comando:

java -cp <classpath> jade.Boot -gui

dove <classpath> dovra includere tutte le classi di JADE piu tutte le classinecessarie all’applicazione (quindi anche la classe dell’agente che abbiamocreato).

Utilizziamo, invece, il comando seguente per lanciare un container pe-riferico (opzione -container) che si registra nel main container in esecu-zione su gandalf.unipr.it e attiva un agente chiamato max della classemyPackage.MyClass (opzione -agents).

java -cp <classpath> jade.Boot -container -host

gandalf.unipr.it -agents max:myPackage.myClass

1.1.2 Agenti

Vediamo come scrivere un agente in JADE.In JADE, per creare un agente basta estendere la classe jade.core.Agent

ed implementare il metodo setup():

1 import jade . core . Agent ;2 import jade . core .AID ;34 public class HelloAgent extends Agent {5 protected void setup ( ) {6 // He l l o myAgent !7 System . out . p r i n t l n ( ‘ ‘ Hel lo , myAgent ! My AID i s ’ ’ +8 getAID ( ) . getName ( ) ) ;9 }

10 }

setup() e il metodo che inizializza l’agente. Vedremo successivamentecome un agente opera.

Ogni agente viene identificato tramite un oggetto jade.core.AID (AgentIdentifier), ottenibile mediante il metodo getAID(). Un’istanza della classejade.core.AID include al suo interno un nome univoco globale ed un certonumero di indirizzi corrispondenti alla platform nella quale l’agente vive. Inomi hanno la seguente forma:

<nickname>@<platform-name>

dove <nickname> e il nome locale dell’agente e platform-name il nome dellaplatform nella quale <nickname> vive (ad esempio max@P1, l’agente max vivein P1).

3

1 St r ing nickname = ”max” ;2 AID id = new AID( nickname , AID .ISLOCALNAME) ;

Se conosciamo il <nickname> di un agente, con queste due righe di codicene otteniamo l’AID. ISLOCALNAME indica che <nickname> rappresenta un<nickname> locale alla platform corrente e non il nome univoco globale.

HelloAgent viene compilato come segue:

javac -classpath <JADE-classes> HelloAgent.java

Per lanciarlo, invece, e necessario scegliere un nickname ed il JADEruntime environment deve essere attivo:

java -classpath <JADE-classes>;. jade.Boot max:myAgent

E importante notare che gli agenti non terminano la propria esecuzio-ne a meno che non venga chiamato il metodo doDelete() o non venganoesplicitamente uccisi dalla GUI di JADE.

Il metodo takeDown(), come per setup(), e chiamato dal JADE runtimeprima della terminazione dell’agente. Questo metodo nasce per eseguire leoperazioni di pulizia dell’agente:

1 import jade . core . Agent ;2 import jade . core .AID ;34 public class HelloAgent extends Agent {5 protected void setup ( ) {6 // He l l o myAgent !7 System . out . p r i n t l n ( ‘ ‘ Hel lo , myAgent ! My AID i s ’ ’ +8 getAID ( ) . getName ( ) ) ;9 doDelete ( ) ;

10 }1112 protected void takeDown ( ) {13 // Bye bye myAgent !14 System . out . p r i n t l n ( ‘ ‘ Bye bye myAgent ! ’ ’ +15 getAID ( ) . getName ( ) + ‘ ‘ i s going to be terminated ’ ’ ) ;16 }17 }

E inoltre possibile passare degli argomenti all’agente in fase di creazionecome array di Object, ottenibile tramite il metodo getArguments().

4

1.1.3 Behaviour

Gli agenti utilizzano i behaviour per eseguire operazioni e raggiungere iloro obiettivi. Un behaviour rappresenta un compito di un agente. Perimplementare un behaviour e necessario estendere la classe jade.core.

behaviours.Behaviour e, per fare in modo che venga eseguito, va aggiunto,con il metodo addBehaviour() della classe Agent, alla lista dei behaviourdi un agente.

I behaviour possono essere aggiunti in qualsiasi momento, quindi anchenel metodo setup() o entro altri behaviour.

Ogni estensione di Behaviour deve implementare il metodo action(),in quanto definisce le operazioni che devono essere eseguite, e il metododone() che specifica se il compito e stato completato (e quindi il behaviourdeve essere rimosso dalla lista dei behaviour dell’agente) oppure no.

Schedulazione ed esecuzione dei behaviour

Ogni agente ha al suo interno una lista di behaviour. Da essa verra sele-zionato il behaviour che si vuole eseguire e, a questo punto, il suo metodoaction() verra eseguito dalla chiamata alla sua terminazione (quindi finchenon ritorna). In questo modo, il programmatore sa che verra completamenteeseguita action() prima di passare ad un altro behaviour.

Questa scelta porta diversi vantaggi:

• garantisce un solo thread per agente, migliorando le performance;

• il behaviour switch e piu veloce del thread switch di Java;

• elimina problemi di sincronizzazione all’accesso di risorse condi-vise;

• permette di catturare snapshot dell’agente, in modo da recuperaresuccessivamente il suo stato (persistenza).

La Figura 1.2 seguente mostra il ciclo di vita di un agente ed esecuzionedei behaviour.

5

Figura 1.2: Ciclo di vita di un agente

6

Il riquadro seguente mostra l’implementazione di un behaviour di esem-pio.

1 import jade . core . behaviours . Behaviour ;23 public class MyBehaviour extends Behaviour {4 private boolean OperationPerformed = fa l se ;56 public void ac t i on ( ) {7 System . out . p r i n t l n ( ‘ ‘ He l lo MyBehaviour ! ’ ’ ) ;89 this . OperationPerformed = true ;

10 }1112 public boolean done ( ) {13 return OperationPerformed ;14 }15 }

Per aggiungere un behaviour alla lista dei behaviour attivi di un agen-te e sufficiente richiamare il metodo addBehaviour() della classe Agent epassargli il behaviour interessato.

1 HelloAgent he l loAgent = new HelloAgent ( ) ;2 MyBehaviour helloMyBehaviour = new MyBehaviour ( ) ;34 he l loAgent . addBehaviur ( helloMyBehaviour ) ;

Quando la lista dei behaviour di un agente e vuota, il suo thread vieneaddormentato in modo da non consumare risorse e tempo CPU. Esso verrarisvegliato non appena sara presente un nuovo behaviour.

In JADE sono presenti tre tipologie di behaviour.

jade.core.behaviours.OneShotBehaviour:

I jade.core.behaviours.OneShotBehaviour vengono utilizzati per esegui-re il metodo action() una sola volta. Questa classe implementa diretta-mente il metodo done() ritornando il valore true.

Esempio:

1 import jade . core . behaviours . OneShotBehaviour ;2 public class MyOneShotBehaviour extends OneShotBehaviour {3 public void ac t i on ( ) {4 System . out . p r i n t l n ( ‘ ‘ a c t i on ( ) v i ene e s e gu i t o ’ ’ +5 ‘ ‘ solamente una vo l t a . ’ ’ ) ;6 }7 // Ne l l a c l a s s e jade . core . behav iours . OneShotBehaviour8 // i l metodo done () e ’ implementato come segue :9 // pu b l i c boo lean done () {

10 // re turn t rue ;11 // }12 }

7

jade.core.behaviours.CyclicBehaviour:

Questi sono i behaviour che non si completano mai. Il loro metodo action()

esegue le stesse operazioni ogni volta che e chiamato. Nella classe jade.core.behaviours.CyclicBehaviour, il metodo done() ritorna sempre false.

Esempio:

1 import jade . core . behaviours . Cycl icBehaviour ;23 public class MyCyclicBehaviour extends Cycl icBehaviour {4 public void ac t i on ( ) {5 System . out . p r i n t l n ( ‘ ‘ a c t i on ( ) v i ene e s e gu i t o ’ ’ +6 ‘ ‘ f i n ch e ’ l ’ Agente non v iene terminato . ’ ’ ) ;7 }89 // Ne l l a c l a s s e jade . core . behav iours . Cyc l icBehav iour

10 // i l metodo done () e ’ implementato come segue :11 // pu b l i c boo lean done () {12 // re turn f a l s e ;13 // }14 }

jade.core.behaviours.Behaviour:

Behaviour nel senso piu generico. Essi incorporano al loro interno uno statoe si completano solamente quando viene rispettata una certa condizione. Siail metodo action() che il metodo done() devono essere implementati.

Esempio:

1 import jade . core . behaviours . Behaviour ;2 public class MyGenericBehaviour extends Behaviour {3 private int s tep = 0 ;4 public void ac t i on ( ) {5 switch ( s tep ) {6 case 0 :7 System . out . p r i n t l n ( ‘ ‘ Eseguo i l metodo ’ ’ ) ;8 break ;9 case 1 :

10 System . out . p r i n t l n ( ‘ ‘ a c t i on ( ) ’ ’ ) ;11 break ;12 case 2 :13 System . out . p r i n t l n ( ‘ ‘ t r e vo l t e . ’ ’ ) ;14 break ;15 }16 step++;17 }18 public boolean done ( ) {19 return s tep == 3 ;20 }21 }

8

Ogni behaviour ha al suo interno una variabile protetta denominatamyAgent. Essa e un puntatore all’agente che sta eseguendo il behaviour.

Inoltre, JADE fornisce anche supporto a behaviour complessi come com-posizione di behaviour semplici (quelli appena visti).

1.1.4 Comunicazione fra agenti: i messaggi ACL

In JADE una delle caratteristiche piu importanti degli agenti e l’abilita dicomunicare. Il paradigma di comunicazione adottato e il passaggio asincronodi messaggi (Figura 1.3).

Ogni agente ha una casella di posta (una coda di messaggi) nella quale ilruntime di JADE inserisce i messaggi inviati da altri agenti. Ogni volta cheun messaggio e inserito nella mailbox, l’agente destinatario viene notificato.La gestione della casella dei messaggi (quindi la lettura e il processare laposta in arrivo) e a completa discrezione del programmatore.

I messaggi che gli agenti JADE si possono scambiare devono rispettareil formato specificato da ACL (Agent Communication Language), definitonello standard internazionale FIPA. ACL ci mette a disposizione un certonumero di campi, di seguito alcuni di essi.

• Sender, il mittente del messaggio.

• Receivers, la lista dei destinatari.

• Performative, il motivo della comunicazione che puo essere:

– REQUEST, per richiedere un’azione;

– INFORM, per informare di un fatto;

– QUERY IF, per verificare una data condizione;

– CFP (Call For Proposal), per proporre una negoziazione;

– ACCEPT PROPOSAL, per accettarla;

– REJECT PROPOSAL, per rifiutarla;

– etc.

• Content, l’effettivo contenuto del messaggio (ad esempio la descrizio-ne della REQUEST o l’evento di INFORM).

• Language, la sintassi usata per esprimere il content (sia mittenteche destinatario devono essere in grado di codificare/decodificare nellinguaggio impostato).

• Ontology, il vocabolario dei simboli e relativo significato usato incontent.

• . . .

9

Figura 1.3: Il passaggio asincrono di messaggi

JADE e ACLMessage

In JADE un messaggio ACL e un’istanza di jade.lang.acl.ACLMessage.Per inviare un messaggio basta compilare i campi di ACLMessage e quindi

utilizzare il metodo send() della classe Agent:

1 import jade . lang . a c l . ACLMessage ;23 . . .45 ACLMessage msg = new ACLMessage (ACLMessage .INFORM) ;6 msg . addReceiver (new AID( ‘ ‘max ’ ’ , AID .ISLOCALNAME) ) ;7 msg . setLanguage ( ‘ ‘ I t a l i a n o ’ ’ ) ;8 msg . setOntology ( ‘ ‘ Meteo−onto logy ’ ’ ) ;9 msg . setContent ( ‘ ‘ Oggi e ’ s o l e g g i a t o ’ ’ ) ;

10 send (msg) ;

Per riceverli all’interno di un behaviour, invece, la documentazione uffi-ciale consiglia di utilizzare un pattern come quello di seguito:

1 import jade . lang . a c l . ACLMessage ;2 import jade . core . behaviours . Cycl icBehaviour ;34 public class ReceiveBehaviour extends Cycl icBehaviour {5 public void ac t i on ( ) {6 ACLMessage msg = myAgent . r e c e i v e ( ) ;7 i f (msg != null ) {8 // Messaggio r i c e vu t o . E ’ ora nece s sa r i o9 // p ro c e s s a r l o .

10 }11 else {12 block ( ) ;13 }14 }15 }

10

Quando aggiungiamo un behaviour ad un agente, il suo thread iniziaun loop continuo per eseguirlo in attesa del completamento. Questo e unovvio spreco di tempo CPU in quanto, nel caso dei behaviour nati per lagestione dei messaggi, vorremmo che il metodo action() venisse attivatosolamente quando un messaggio e ricevuto. Per questo usiamo il metodoblock() presente all’interno della classe Behaviour. block() ci serve perimpostare lo stato del behaviour come bloccato, in modo da evitare unanuova esecuzione dello stesso. Quando si ricevera un nuovo messaggio, tuttii behaviour verranno sbloccati e potranno tentare di processare il messaggioricevuto.

E possibile anche utilizzare i jade.lang.acl.MessageTemplate (schemidi messaggi) per matchare (quindi avere una corrispondenza) con i messaggiconcreti ricevuti. In questo modo, riusciamo ad effettuare una ricezioneselettiva su certe tipologie di messaggio.

1.1.5 Ontologie

Gli agenti, per poter comunicare correttamente, devono condividere lo stes-so linguaggio, lo stesso vocabolario e gli stessi protocolli di comunicazione.Al momento della definizione degli agenti e necessario definire anche il lorovocabolario e la semantica dei contenuti dei messaggi che si possono scam-biare. Questo significa definire un’ontologia. JADE fornisce tre modi perprocedere:

1. Utilizzare String per rappresentare il contenuto di un messaggio.Utile quando si vogliono trasferire informazioni semplici (si utilizzanoi metodi getContent() e setContent());

2. Serializzare oggetti Java direttamente nel content (tramite i metodigetContentObject() e setContentObject());

3. Definire sottoclassi di jade.content.onto.Ontology, in modo cheJADE possa codificare e decodificare i messaggi in un formato FIPAstandard (metodi extractContent() e fillContent()).

Un’ontologia descrive gli elementi che possono essere utilizzati come con-tenuto del messaggio. Ha al suo interno un vocabolario che descrive i concetti(Concept), i predicati (Predicate) e le azioni degli agenti (AgentAction)usati dagli agenti nella loro comunicazione e una descrizione delle relazioniche intercorrono fra i concetti, della loro semantica e della loro struttura.

Vediamo cosa significa definire una sottoclasse di Ontology (contenutanel package jade.content.onto).

11

Seguiamo i seguenti passi per definire un’ontologia:

1. Estendere jade.content.onto.Ontology;

2. Dare un nome all’ontologia;

3. Definire un vocabolario;

4. Dare una struttura di tipo Singleton;

5. Aggiungere gli schemi per Concept, Predicate e AgentAction.

1 import . . . ;2 public class ExampleOntology extends Ontology {3 // I l nome che i d e n t i f i c a l ’ on t o l o g i a corren te .4 public stat ic f ina l St r ing ONTOLOGYNAME5 = ‘ ‘ Example−onto logy ’ ’ ;6 // I l v o cabo l a r i o :7 public stat ic f ina l St r ing PERSONA = ‘ ‘ Persona ’ ’ ;8 public stat ic f ina l St r ing PERSONANAME = ‘ ‘Nome ’ ’ ;9 public stat ic f ina l St r ing COSTA = ‘ ‘ Costa ’ ’ ;

10 public stat ic f ina l St r ing COSTA ITEM = ‘ item ’ ’ ;11 public stat ic f ina l St r ing COSTA PREZZO = ‘ ‘ prezzo ’ ’ ;12 public stat ic f ina l St r ing VENDERE = ‘ ‘Vende ’ ’ ;13 public stat ic f ina l St r ing VENDERE ITEM = ‘ ‘ item ’ ’ ;14 // La s i n g l e t o n i s t an z a d e l l ’ Onto log ia .15 private stat ic Ontology the Ins tance = new ExampleOntology ( ) ;16 public stat ic Ontology ge t In s tance ( ) {17 return the Ins tance ;18 }19 // Cos t ru t t o r e p r i v a t o .20 private BookTradingOntology ( ) {21 super (ONTOLOGYNAME, BasicOntology . g e t In s tance ( ) ) ;22 try {23 add (new ConceptSchema (PERSONA) , Persona . class ) ;24 add (new PredicateSchema (COSTS) , Costs . class ) ;25 add (new AgentActionSchema (SELL) , S e l l . class ) ;26 // S t ru t t u ra d e l l o schema per i l conce t to Persona .27 ConceptSchema cs = (ConceptSchema ) getSchema (ITEM) ;28 cs . add (PERSONANAME, ( PrimitiveSchema )29 getSchema ( BasicOntology .STRING) ) ;30 // S t ru t t u ra d e l l o schema per i l p r ed i ca t o Costa .31 . . .32 // S t ru t t u ra d e l l o schema per l a AgentAction Vendere33 AgentActionSchema as =34 (AgentActionSchema ) getSchema (SELL) ;35 as . add (VENDERE ITEM,36 (ConceptSchema ) getSchema (PERSONA) ) ;37 }38 catch ( OntologyException oe ) {39 oe . pr intStackTrace ( ) ;40 }41 }42 }

12

Capitolo 2

Realizzazione di un DomainSpecific Language tramiteXtext e Xbase

Xtext e un plugin open source per l’IDE Eclipse nato per implementare nuoviDSL. Come visto nell’introduzione, i DSL (Domain Specific Languages) sonolinguaggi (di programmazione e non) nati per l’uso in un particolare dominioapplicativo. Programmi o specifiche scritti in un certo DSL possono esserecompilati in un GPL (General Purpose Language, come Java).

Ma allora, perche utilizzare un DSL? Usiamo i DSL nel caso in cui af-frontiamo problemi specifici in quanto e piu semplice e, probabilmente, piuveloce risolverli con essi, piuttosto che utilizzare un GPL.

2.1 Xtext

Xtext e utilizzato assieme ad Eclipse per lo sviluppo di DSL e copre tuttigli aspetti dell’implementazione di un linguaggio fino alla sua integrazionecon Eclipse stesso. Al suo interno disponiamo di tutto cio che ci serve per:

• scrivere la grammatica del linguaggio e, grazie ad ANTLR, creare ilparser;

• implementare regole di typing e scoping;

• generare il compilatore e/o l’interprete;

• realizzare un ambiente di programmazione completo di IDE.

L’ultimo punto e una parte importantissima di Xtext. Ad oggi, sono pochii linguaggi di programmazione utilizzati senza un IDE. Xtext permette diarrivare a generare un Eclipse completo di tutti gli aspetti classici dell’IDE,come, ad esempio, le funzioni di syntax highlighting, background parsing etc.

Ma vediamo in dettaglio cosa possiamo fare con Xtext.

13

2.1.1 Usare Xtext

In primo luogo, colleghiamoci al sito di Xtext (www.eclipse.org/Xtext).Da qui e possibile scaricare un Eclipse gia configurato oppure ottenere leinformazioni per installare Xtext in uno gia presente in macchina usando ilseguente update site:

http://download.eclipse.org/modeling/tmf/xtext/updates/

composite/releases

Una volta configurato correttamente l’IDE, apriamo Eclipse e creiamoun progetto Xtext cliccando su File → New → Project. . . e, dalla cartelladenominata Xtext, selezioniamo Xtext Project. La maschera successiva cichiede di inserire le informazioni relative al linguaggio che stiamo andando acreare. La Figura 2.1 ci mostra le finestre che Eclipse ci proporra. Vediamoil classico Hello World! applicato a Xtext (Figura 2.2).

Figura 2.1: Creazione di un progetto Xtext

14

Figura 2.2: Hello Xtext!

Il wizard creera 4 progetti e aprira il file Mydsl.xtext:

1. org.xtext.example.mydsl, il progetto principale che conterra i filedel nostro linguaggio;

2. org.xtext.example.mydsl.sdk, contenente la configurazione dell’am-biente di sviluppo generato;

3. org.xtext.example.mydsl.test, in cui si creeranno tutti i test;

4. org.xtext.example.mydsl.ui, per la customizzazione dell’IDE gene-rato.

15

Figura 2.3: Run As → Generate Xtext Artifacts

MyDsl.xtext e il file che contiene la grammatica che generera il nostroDSL. Vediamone la struttura.

1 grammar org . xtext . example . mydsl .MyDsl with org . e c l i p s e . xtext .common . Terminals

23 generate myDsl ”http ://www. xtext . org /example/mydsl/MyDsl”45 Model :6 g r e e t i n g s+=Greet ing ∗ ;78 Greet ing :9 ’ He l lo ’ name=ID ’ ! ’ ;

Questa e una semplicissima grammatica che genera un linguaggio com-posto dalla parola chiave ‘Hello’ seguito da un identificatore e, infine,un ‘!’. Proviamolo, generando l’infrastruttura del linguaggio e lanciandoEclipse personalizzato per MyDsl. Clicchiamo col pulsante destro del mousesul file che contiene la grammatica e navighiamo su Run As e poi GenerateXtext Artifacts.

Nella console, Eclipse ci rivolgera una domanda:

It is recommended to use the ANTLR 3 parser generator (BSD

licence - http://www.antlr.org/license.html).

Do you agree to download it (size 1MB) from

‘http://download.itemis.com/antlr-generator-3.2.0-patch.jar’?

(type ‘y’ or ‘n’ and hit enter)

16

Figura 2.4: Run As → Eclipse Application

Rispondendo ‘y’, verra scaricato e incluso al progetto il generatore di parserANTLR (ANother Tool for Language Recognition, www.antlr.org). Essonon puo essere incluso nel pacchetto di installazione di Xtext, in quanto sonopresenti incompatibilita di licenza software. A questo punto, verranno gene-rati tutti i file necessari per l’effettiva creazione del linguaggio. Aspettiamoche finisca la compilazione. Quando nella console troveremo un messaggiocome questo

[main] INFO .emf.mwe2.runtime.workflow.Workflow - Done.

allora saremo pronti.

Xtext ci ha gia configurato tutto il necessario per provare il runtime diEclipse. La Figura 2.4 ci mostra come fare.

Questo processo aprira una nuova istanza di Eclipse vuota. ProviamoMyDsl. Creiamo un nuovo progetto generale ed aggiungiamo un nuovo filecon estensione .mydsl. Eclipse ci chiedera se vogliamo aggiungere la cosid-detta “Xtext nature” al progetto. Confermiamo e, come si puo notare dallaFigura 2.5, avremo davanti a noi un Eclipse perfettamente integrato con illinguaggio MyDsl. Fin da subito si nota l’evidenziatura delle parole chiaveed eventuali errori (vedi l’uso di “Hey!” nel file HelloMyDsl.mydsl).

17

Figura 2.5: MyDsl ed Eclipse

Figura 2.6: Classi generate da Xtext

18

In questo momento, MyDsl e completo per quanto riguarda la sintassi.Mancano tutti gli aspetti semantici, come la validazione e la compilazio-ne del codice. Xtext ci ha gia preparato le classi necessarie a tale scopo(Figura 2.6).

2.2 Xbase

Xbase e un linguaggio di espressioni che si integra perfettamente nel typesystem di Java. Xtext lo mette a disposizione per coloro che vogliono com-pilare il proprio DSL in Java. Creare un DSL basato su Xbase significaereditare una sintassi Java-like (quindi espressioni, strutture di controllo,cicli), integrare il type checking e il compilatore che genera codice Java.Grazie a Xbase avremo anche la possibilita di accedere a tutti i tipi e tuttele librerie nate per Java.

2.2.1 Usare Xbase: MyDsl per ricette culinarie

In questa sezione vedremo un semplice DSL, anch’esso chiamato MyDsl,basato su Xbase. Il dominio di questo DSL sono le ricette culinarie. MyDslnasce con l’intento di eseguire le ricette che l’utente specifica, utilizzandogli ingredienti e le indicazioni forniti e per produrre un certo numero divolte il risultato della ricetta. Quindi, vogliamo che MyDsl gestisca ricette(recipe), ingredienti (ingredient) e indicazioni (direction).Creiamo un nuovo progetto Xtext e scriviamo la grammatica:

1 grammar org . xtext . example . mydsl .MyDsl2 with org . e c l i p s e . xtext . xbase . Xbase3 generate myDsl ”http ://www. xtext . org /example/mydsl/MyDsl”4 Recipe :5 ’ r e c i p e ’ name = ValidID6 body = RecipeBlock ;7 RecipeBlock :8 {RecipeBlock }9 ’ { ’

10 rec ipeElements += RecipeElement∗11 ’make ’ ’ i t ’ t imes = INT ’ t imes ’12 ’ } ’ ;13 RecipeElement :14 D i r e c t i on | I ng r ed i en t ;15 D i r e c t i on :16 ’ d i r e c t i o n ’ returnType = JvmTypeReference name = ValidID17 ’ ( ’ ( params += FullJvmFormalParameter18 ( ’ , ’ params += FullJvmFormalParameter ) ∗) ? ’ ) ’19 body = XBlockExpression ;20 Ing r ed i en t :21 ’ i n g r ed i e n t ’ type = JvmTypeReference name = ValidID22 ( ’=’ i n i tExp r e s s i on = XExpression ) ? ’ ; ’ ;

19

Vediamola piu in dettaglio.In primo luogo, si nota subito che la grammatica non deriva piu dal-

la grammatica di base di Xtext (org.eclipse.xtext.common.Terminals),ma da Xbase (org.eclipse.xtext.xbase.Xbase). Vengono specificate leseguenti parser rule:

• Recipe essa verra tradotta in una classe Java;

• Direction diventeranno i metodi della classe corrente;

• Ingredient le proprieta.

In particolare, sia Direction che Ingredient utilizzeranno i tipi di datodi Java. Infine, si specifichera il numero di volte che vogliamo preparare ilrisultato della nostra ricetta.

Una volta scritta la grammatica generiamo gli artefatti di linguaggio(Figura 2.3).

Recipe

Proviamo l’IDE generato per vedere se tutte le parole chiave sono ricono-sciute e per verificare eventuali errori di sintassi.

Creiamo questa volta un progetto Java, in modo da includere le libreriestandard di Java (JRE System Library). Aggiungiamo anche le libreriestandard di Xtend (Xtend Library), in modo da avere accesso alle API diXbase. Per effettuare questa operazione clicchiamo col pulsante destro delmouse sul progetto nel Package Explorer, navighiamo su Build Path e quindiAdd Libraries. . .

La Figura 2.7 ci mostrera le librerie subito disponibili. Selezioniamocome da figura e clicchiamo su Avanti e quindi Fine.

Scriviamo il semplice programma riportato dalla Figura 2.8.Toast e una semplice ricetta nella quale sono presenti:

• tre ingredienti (le proprieta) di tipo String;

• un’indicazione (un metodo) che ritorna un oggetto di tipo String;

• una direttiva make it che indica il numero di volte che la ricetta deveessere preparata.

Come si nota dalla Figura 2.8, essa e sintatticamente corretta. Eclipsenon ci mostra nessun errore. A questo punto dobbiamo realizzare l’effettivagenerazione del codice Java.

Visto che stiamo utilizzando Xbase, non si deve implementare l’interfac-cia IGenerator come per i DSL basati su Terminals, ma dovremo utilizzare

20

Figura 2.7: Aggiungere la Xtend Library

Figura 2.8: Il file Toast.mydsl aperto in Eclipse

21

Figura 2.9: org.xtext.example.mydsl.jvmmodel.MyDslJvmModelInferrer

il JvmModelInferrer. Ricordo che quando si generano gli artefatti di lin-guaggio, Xtext ci prepara gia tutto cio di cui abbiamo bisogno. Infatti, laFigura 2.9 ci mostra dov’e contenuto.

MyDslJvmModelInferrer.xtend

L’Inferrer e scritto nel linguaggio Xtend, un dialetto del linguaggio Java.Ma perche utilizzare Xtend, invece che Java stesso? Le motivazioni sonomolteplici.

• E piu facile da utilizzare.

• Permette di scrivere codice piu leggibile.

• Fornisce funzionalita aggiuntive quali:

– lambda expression;

– extension method;

– costrutto switch applicabile su tipi di dato;

– multi-line text template;

– . . .

In particolare, Xtend e fortemente legato a Xtext. Lo utilizziamo so-prattutto per scrivere meno codice che potrebbe essere ridondante e confu-sionario.

22

Alla creazione, MyDslJvmModelInferrer.xtend si presenta cosı:

1 package org . xtext . example . mydsl . jvmmodel2 import . . .3 /∗ <p>I n f e r s a JVM model from the source model .</p>4 ∗ <p>The JVM model should conta in a l l e lements that would5 ∗ appear in the Java code which i s generated from the6 ∗ source model . Other models l i n k aga in s t the JVM model7 ∗ ra the r than the source model .</p>∗/8 class MyDslJvmModelInferrer extends Abst rac tMode l In f e r r e r {9 @Inject extension JvmTypesBuilder

10 /∗ The d i spatch method {@code i n f e r } i s c a l l e d f o r each11 ∗ i n s t ance o f the g iven element ’ s type that i s12 ∗ conta ined in a r e sou r c e .13 ∗ @param element14 ∗ the model to c r e a t e one or more from .15 ∗ @param acceptor16 ∗ each crea ted without a conta ine r should be passed17 ∗ to the acceptor in order get attached to the cur rent18 ∗ r e s ou r c e .19 ∗ The acceptor ’ s accept ( . . ) } method takes the20 ∗ cons t ruc ted empty type f o r the pre−index ing phase .21 ∗ This one i s f u r t h e r i n i t i a l i z e d in the index ing22 ∗ phase us ing the c l o s u r e you pass to the returned23 ∗ i n i t i a l i z e L a t e r ( . . ) } .24 ∗ @param isPreIndex ingPhase25 ∗ whether the method i s c a l l e d in a pre−index ing26 ∗ phase , i . e . when the g l oba l index i s not yet f u l l y27 ∗ updated . You must not r e l y on l i n k i n g us ing the28 ∗ index i f i sPreIndex ingPhase i s <code>true</code>.∗/29 def dispatch void i n f e r ( Recipe element ,30 IJvmDeclaredTypeAcceptor acceptor ,31 boolean i sPreIndex ingPhase ) {32 // Here you exp la in how your model i s mapped to Java33 // elements , by wr i t i ng the ac tua l t r a n s l a t i o n code .34 // An implementation f o r the i n i t i a l h e l l o world example35 // could look l i k e t h i s :36 // acceptor . accept ( element . toClas s (”my. company . ” +37 // ” g r e e t i n g . MyGreetings ”) ) [38 // f o r ( g r e e t i n g : element . g r e e t i n g s ) {39 // members += gr e e t i n g . toMethod (” h e l l o ” +40 // g r e e t i n g . name , typeRef ( S t r ing ) ) [41 // body = ’ ’ ’42 // return ”He l lo <<g r e e t i n g . name>>”;43 // ’ ’ ’44 // ]45 // }46 // ]47 }48 }

23

MyDslJvmModelInferrer e una classe Xtend che estende la classe astrat-ta AbstractModelInferrer e ci serve per mappare il modello di dominiodel nostro linguaggio nel linguaggio Java. In questa classe e presente unmetodo dispatch chiamato infer:

1 def dispatch void i n f e r ( Recipe element ,2 IJvmDeclaredTypeAcceptor acceptor ,3 boolean i sPreIndex ingPhase )

Presenta tre parametri:

• Recipe element, l’elemento interessato che vogliamo tradurre;

• IJvmDeclaredTypeAcceptor acceptor, il traduttore;

• boolean isPreIndexingPhase, non verra utilizzato per i nostri scopi.

Nel caso di MyDsl per ricette culinarie, il modello e composto da ricet-te. Come detto precedentemente, le Recipe vogliamo tradurle in classi, gliIngredient in proprieta e le Direction in metodi.

Useremo gli extension method forniti da Xbase per la traduzione. Gliextension method sono metodi che e possibile aggiungere a tipi gia esistenti,senza che sia necessario modificarli. Il funzionamento e basato su un sempli-ce artificio sintattico: l’oggetto che richiama l’extension method, in realta,viene passato allo stesso come primo argomento.

Esempio:

"hello".toFirstUpper()

// Richiama StringExtensions.toFirstUpper("hello") dove

// StringExtensions e una classe che contiene il metodo

// toFirstUpper(String s)

Utilizzeremo i seguenti metodi per la mappatura:

• toClass(EObject sourceElement, String name);

• toField(EObject sourceElement, String name,

JvmTypeReference typeRef);

• toMethod(EObject sourceElement, String name,

JvmTypeReference returnType);

• toParameter(EObject sourceElement, String name,

JvmTypeReference typeRef).

Come si puo notare dai nomi di questi metodi, sourceElement verratradotto rispettivamente: dal primo in una classe di nome name, dal secondoin un campo (proprieta privata) della stessa di nome name di tipo typeRef,dal terzo in un metodo di nome name e di tipo returnType e tipo name ereturnType ed infine dal quarto in un parametro di un metodo.

24

Qui di seguito la classe MyDslJvmModelInferrer.xtend finita:

1 package org . xtext . example . mydsl . jvmmodel2 import . . . ;34 class MyDslJvmModelInferrer extends Abst rac tMode l In f e r r e r {5 @Inject extension JvmTypesBuilder6 def dispatch void i n f e r ( Recipe r ec ipe ,7 IJvmDeclaredTypeAcceptor acceptor ,8 boolean i sPreIndex ingPhase ) {9 // Ogni r i c e t t a v i ene compi lata in una c l a s s e Java .

10 acceptor . accept ( r e c i p e . toClas s ( r e c i p e . name) ) [11 documentation = r e c i p e . documentation12 // Ogni i n g r ed i e n t e d iventa un campo d e l l a r i c e t t a13 // co r r en t e .14 for ( i ng r : r e c i p e . body . rec ipeElements . f i l t e r (15 Ing r ed i en t ) )16 members += ing r . t oF i e l d ( ing r . name , i ng r . type ) [17 documentation = ing r . documentation18 i f ( i ng r . i n i tExp r e s s i on != null )19 i n i t i a l i z e r = ing r . i n i tExp r e s s i on20 s t a t i c = true21 ]22 // Ogni i nd i c a z i on e v i ene mappata con un metodo .23 for ( d i r : r e c i p e . body . rec ipeElements . f i l t e r (24 D i r e c t i on ) )25 members += d i r . toMethod ( d i r . name ,26 d i r . returnType ) [27 documentation = d i r . documentation28 for ( param : d i r . params )29 parameters += param . toParameter (30 param . name , param . parameterType )31 s t a t i c = true32 body = d i r . body33 ]34 // Per ogni r i c e t t a v i ene c r ea to anche un metodo35 // main in modo da poter e s e gu i r e i l programma .36 members += r e c i p e . toMethod ( ”main” , typeRef (void ) ) [37 parameters += toParameter ( ” args ” ,38 typeRef ( S t r ing ) . addArrayTypeDimension )39 s t a t i c = true40 body = ’ ’ ’41 System . out . p r i n t l n (”Ho f a t t o <<r e c i p e . body .42 times>> <<r e c i p e . name>> seguendo l e43 i n d i c a z i o n i :\n”) ;44 <<FOR d i r : r e c i p e . body . rec ipeElements45 . f i l t e r ( D i r e c t i on )>>46 System . out . p r i n t l n(<<d i r . name>>() ) ;47 <<ENDFOR>>48 ’ ’ ’49 ]50 ]51 }52 }

25

Vediamo in dettaglio. In primo luogo utilizziamo:

1 // Ogni r i c e t t a v i ene compi lata in una c l a s s e Java .2 acceptor . accept ( r e c i p e . toClas s ( r e c i p e . name) )

per creare la classe Java denominata col nome della Recipe. Adesso voglia-mo tradurre ogni Ingredient in un campo privato:

1 // Ogni i n g r ed i e n t e d iventa un campo d e l l a r i c e t t a co r r en t e .2 for ( i ng r : r e c i p e . body . rec ipeElements . f i l t e r ( Ing r ed i en t ) )3 members += ing r . t oF i e l d ( ing r . name , ing r . type )

In questo modo accediamo ai recipeElements all’interno del body di recipe(vedi grammatica 2.2.1) e tramite l’extension method Filter otteniamo unIterable<Ingredient>. Successivamente, aggiungiamo alla lista members

questo campo usando toField() e, se presente, lo inizializziamo al valoreindicato dal programmatore.

Lo stesso discorso vale per le Direction con la sola differenza che vo-gliamo mapparle a metodi:

1 // Ogni i nd i c a z i on e v i ene mappata con un metodo .2 for ( d i r : r e c i p e . body . rec ipeElements . f i l t e r ( D i r e c t i on ) )3 members += d i r . toMethod ( d i r . name , d i r . returnType )

Filtriamo per Direction e cicliamo sul risultato. Per ognuno creiamo un me-todo con toMethod() usando come corpo la XBlockExpression dir.body,come indicato nella grammatica.

Infine aggiungiamo un main(String[] args) in modo da poter eseguiredirettamente la recipe descritta.

1 // Per ogni r i c e t t a v i ene c r ea to anche un metodo2 // main in modo da poter e s e gu i r e i l programma .3 members += r e c i p e . toMethod ( ”main” , typeRef (void ) ) [4 parameters += toParameter ( ” args ” , typeRef ( S t r ing )5 . addArrayTypeDimension )6 s t a t i c = true7 body = ’ ’ ’8 System . out . p r i n t l n (”Ho f a t t o <<r e c i p e . body . times>> ” +9 ”<<r e c i p e . name>> seguendo l e i n d i c a z i o n i :\n”) ;

10 <<FOR d i r : r e c i p e . body . rec ipeElements11 . f i l t e r ( D i r e c t i on )>>12 System . out . p r i n t l n(<<d i r . name>>() ) ;13 <<ENDFOR>>14 ’ ’ ’15 ]

Per ognuna delle proprieta e dei metodi creati viene utilizzato il mo-dificatore static per poterlo utilizzare in main() e viene agganciata ladocumentazione se presente.

Il main() stampera con System.out.println() una stringa che descri-vera le operazioni effettuate.

26

Figura 2.10: Toast.mydsl e Toast.java

Per testare l’Inferrer apriamo l’IDE generato. Si nota subito dallaFigura 2.10 che la cartella src-gen adesso contiene un file (se cosı nonfosse, salvare di nuovo il file Toast.mydsl) denominato Toast.java. Inesso e contenuto il codice Java che Xtext e Xbase hanno generato trami-te il MyDslJvmModelInferrer. La Figura 2.11 ci mostra l’esecuzione delprogramma Toast.java.

27

Figura 2.11: Toast.java eseguito e relativo output

28

Capitolo 3

JADEL

JADEL e un DSL nato con l’intento di semplificare l’uso del frameworkJADE (Java Agent DEvelopment Framework) sviluppato dall’Universita diParma in collaborazione con Telecom Italia S.p.A.

JADEL deve essere in grado di fornire agli sviluppatori astrazioni dialto livello per assicurare produttivita e qualita del software prodotto sen-za forzare le metodologie esistenti ne accettare compromessi nello sviluppoe, oltretutto, permettere di scrivere con una sintassi piu leggibile rispettoall’utilizzo delle API di JADE.

La grammatica di JADEL e basata su Xbase, in questo modo avremouna sintassi Java-like, la possibilita di riutilizzare eventuali librerie gia scrittein Java e far sentire a casa i programmatori gia abituati all’uso di Java eJADE.

Gli elementi principali JADEL sono:

1. agenti, raggruppati in famiglie;

2. behaviour, i task che gli agenti devono eseguire per raggiungere ipropri scopi;

3. ontologie, atte al supporto della comunicazione tra agenti (esse sonopuramente descrittive e non hanno stato).

Questi sono raggruppati in package, in modo da evitare il conflitto franomi. I package seguono esattamente la struttura dei package di Java.

Un file .jadel al suo interno potra contenere, quindi, la definizione diagenti, behaviour o ontologie mediante le parole chiave agents, behaviourse ontology.

29

Vediamone un esempio per tipo. Non e necessario esplicitare alcunFullyQualifiedName in quanto tutti fanno parte dello stesso package.

ExampleAgent:

1 package j a d e l . examples23 agents ExampleAgent {4 use ontology ExampleOntology5 use active behaviour ExampleBehaviour67 on create {8 // I n i z i a l i z z a r e l ’ agente qui .9 }

10 }

Questo esempio mostra com’e facile implementare un nuovo agente. Siutilizza la parola chiave agents seguita da un nome (ExampleAgent), si apreun nuovo blocco nel quale, tramite la parola chiave use, si specificano i be-haviour (active o blocked) e le ontologie che si vogliono aggiungere e sigestiscono gli eventi di creazione e cancellazione dell’agente tramite i blocchion create e on delete (quelli che nell’uso di JADE sono l’implementazionedei metodi setup() e takeDown()).

ExampleBehaviour:

1 package j a d e l . examples23 cycl ic behaviours ExampleBehaviour {4 use ontology ExampleOntology5 on message msg6 when {7 performative i s INFORM and8 ontology i s ExampleOntology and9 content i s prop

10 }11 do {12 // Esegui ope r a z i on i .13 }14 }

Anche in questo caso abbiamo la parola chiave cyclic che identifica il tipodi behaviour, la parola chiave behaviours e un identificatore valido peril behaviour corrente. All’interno specifichiamo l’ontologia interessata e,tramite un blocco on...when...do, specifichiamo le condizioni per matchare(quindi jade.lang.acl.MessageTemplate) il message msg ed eseguire leoperazioni contenute nel blocco do. Esse sono l’implementazione del metodoaction() di jade.core.behaviours.Behaviour.

30

ExampleOntology:

1 package j a d e l . examples23 ontology ExampleOntology {4 proposition prop5 predicate pred {6 // Esegui ope r a z i on i .7 }8 }

In questo esempio, invece, viene definita l’ontologia ExampleOntology tra-mite:

1. parola chiave ontology seguita dal nome della stessa;

2. parola chiave proposition per le proposizioni;

3. parola chiave predicate per i predicati.

Proposizioni e predicati di questa ontologia sono i riferimenti utilizzatinegli esempi precedenti.

Vediamo ora la grammatica che descrive la sintassi di JADEL.

3.0.2 JADEL, la grammatica

La grammatica che descrive JADEL e una grammatica basata su Xbase.La parser rule principale di JADEL si chiama Model ed e riportata nel

riquadro seguente:

1 grammar i d e . j a d e l . Jade l with org . e c l i p s e . xtext . xbase . Xbase2 generate j a d e l ” http ://www. j a d e l . i de / Jade l ”34 /∗∗∗ Domain Model ∗∗∗/56 Model :7 {Model}8 ’ package ’ name = Qualif iedName9 importSect ion = XImportSection ?

10 element = AbstractElement11 ;1213 AbstractElement :14 JadelAgents | AbstractBehaviours | AbstractOnto log i e s15 ;1617 /∗∗∗ End Domain Model ∗∗∗/

Essa definisce la struttura di un file JADEL sintatticamente corretto.

31

Vediamo le parser rule di Xbase che verranno utilizzate piu di frequentenella grammatica:

• ValidID permette la scrittura di soli identificativi validi, ovvero quelliche sono matchati dalla regular expression‘^’? (‘a’..‘z’|‘A’..‘Z’|‘$’|‘ ’)

(‘a’..‘z’|‘A’..‘Z’|‘$’|‘ ’|‘0’..‘9’)*;

• QualifiedName permette solamente dei nomi qualificati, quindi nomiche convalidati da ValidID (=>‘.’ ValidID)* (ad esempio jadel.

examples.ExampleAgent);

• XExpression e XBlockExpression sono espressioni che vengono di-rettamente mappate nel codice Java, quindi dichiarazione di variabili,istanziazione di oggetti, chiamate a funzione, blocchi di espressioni(contenute in ‘{’ e ‘}’), etc.

Tornando alla grammatica, abbiamo la definizione del package cor-rente, di seguito una XImportSection e, infine, deve essere presente unAbstractElement dove:

• il nome del package corrente e un QualifiedName

• XImportSection e un’altra parser rule predefinita di Xbase che cipermette di utilizzare le direttive import esattamente come in Java;

• AbstractElement e la parser rule core della grammatica. Da qui sidistinguono le tipologie di elementi che si possono scrivere in JADEL.

Quindi nei file .jadel descriviamo con le parser rule:

1. JadelAgents gli agenti;

2. AbstractBehaviours i behaviour;

3. AbstractOntologies le ontologie.

Il plugin di Xtext ha al suo interno una view che ci mostra il cosiddettoXtext syntax graph. Questo e stato molto utile durante la stesura dellagrammatica in quanto aiuta a capire visualmente se sono state scritte delleparser rule che ciclano su se stesse.

32

Figura 3.1: Syntax Graph for Model and AbstractElement

La lettura di un syntax graph e molto semplice:

Il nodo iniziale non ha elementi decorativi ed e etichettato con il nomedella parser rule che descrive;

I nodi racchiusi in un rettangolo rappresentano una keyword del lin-guaggio che si sta generando;

I nodi racchiusi in un rettangolo arrotondato sono il riferimento adun’altra parser rule presente;

Gli archi definiscono le produzioni della grammatica.

La Figura 3.1 ci mostra il grafo delle parser rule appena viste. Questaview si trova in Eclipse navigando nel menu Window → Show View →Other. . . e, dalla finestra appena aperta, nella cartella Xtext e quindi XtextSyntax Graph.

33

JadelAgents

1 /∗∗∗ Agents ∗∗∗/23 JadelAgents :4 ’ agents ’ name = ValidID ’ { ’5 onto logy = OntologyDec larat ion ?6 behaviours += UseBehaviour∗78 ( ’ on ’ ’ c r e a t e ’ createBody = XBlockExpression ) ?9 ( ’ on ’ ’ d e l e t e ’ deleteBody = XBlockExpression ) ?

10 ’ } ’11 ;1213 UseBehaviour :14 ’ use ’ s t a t e = ActiveBlockedBehaviour ’ behaviour ’15 name = [ AbstractBehaviours | Qualif iedName ]16 ;1718 ActiveBlockedBehaviour :19 ’ a c t i v e ’ | ’ b locked ’20 ;2122 /∗∗∗ End Agents ∗∗∗/

La parser rule JadelAgents ci permette di descrivere gli agenti.Il nome di un agente deve essere un ValidID. All’interno del blocco del-

l’agente e possibile (quindi non obbligatorio) specificare l’ontologia che essorispettera nell’invio e nella ricezione dei messaggi. OntologyDeclaration

verra vista in piu in dettaglio nella sezione su AbstractOntology.

1 onto logy = OntologyDec larat ion ?

E possibile specificare un qualsivoglia numero di behaviour grazie all’ag-giunta di elementi UseBehaviour alla lista behaviours.

1 behaviours += UseBehaviour∗

UseBehaviour permette di inizializzare anche lo stato del behaviour chesi sta aggiungendo alla lista behaviours (quindi active o blocked). Perquanto riguarda il nome del behaviour che si vuole utilizzare e presente ilcostrutto [AbstractBehaviours|QualifiedName]. In questo caso, il ‘|’(pipe) non e un’alternativa, ma indica che in quel punto deve essere scrittoun riferimento ad un AbstractBehaviours esistente nel package corrente.

34

Figura 3.2: Syntax graph for JADEL agents

1 UseBehaviour :2 ’ use ’ s t a t e = ActiveBlockedBehaviour ’ behaviour ’3 name = [ AbstractBehaviours | Qualif iedName ]4 ;56 ActiveBlockedBehaviour :7 ’ a c t i v e ’ | ’ b locked ’

Infine, sono presenti i blocchi on create e on delete, utilizzati per im-plementare i metodi setup() e takeDown() della classe Agent di JADE. Illoro corpo e una XBlockExpression.

1 ( ’ on ’ ’ c r e a t e ’ createBody = XBlockExpression ) ?2 ( ’ on ’ ’ d e l e t e ’ deleteBody = XBlockExpression ) ?

La Figura 3.2 mostra il syntax graph di quanto esposto.

35

Figura 3.3: Syntax graph for behaviours, prima parte

AbstractBehaviours

La parte della grammatica di JADEL relativa ai behaviour contiene al suointerno diverse parser rule:

1 /∗∗∗ Behaviours ∗∗∗/23 AbstractBehaviours :4 SimpleBehaviour5 ;67 SimpleBehaviour :8 {SimpleBehaviour}9 type = SimpleBehaviourType ’ behaviours ’ name = ValidID

10 body = BehaviourBody11 ;1213 enum SimpleBehaviourType :14 oneshot | c y c l i c15 ;

Attualmente in JADEL sono gestiti solamente behaviour di tipo sempli-ce, non e possibile usare behaviour diversi dai quelli OneShot e Cyclic. Lagrammatica, pero, e stata pensata fin dall’inizio in modo che sia estendi-bile con nuove feature, grazie all’astrazione data da AbstractBehaviours.In questo modo, all’aggiunta di altre tipologie di behaviour, non dovremomodificare nel complesso le parser rule, ma solamente aggiungere una nuovaalternativa all’interno di AbstractBehaviours. La Figura 3.3 ci mostra ilsyntax graph per questa parte della grammatica sui behaviour.

SimpleBehaviour ci permette di scrivere specificare il tipo del behaviourche si vuole implementare grazie all’enum SimpleBehaviourType (oneshot

36

si riferisce a jade.core.behaviours.OneShotBehaviour e cyclic a jade.

core.behaviours.CyclicBehaviour). E necessario specificare il nome delbehaviour come ValidID ed il corpo gestito da BehaviourBody.

1 BehaviourBody :2 {BehaviourBody}3 ’ { ’4 e xp r e s s i on s += XExpressionOrVarDeclaration ∗5 onto logy = OntologyDec larat ion ?6 event = HandleBehaviourEvent ?7 ’ } ’8 ;9

10 HandleBehaviourEvent :11 ’ on ’ event = BehavioursEvent eventName = ValidID12 ( ’when ’13 whenBody = WhenBodyExpression14 ) ?15 ’ do ’16 body = XBlockExpression17 ;1819 BehavioursEvent :20 ’ message ’21 ;

BehaviourBody e divisa in due parti. Nella prima e possibile usare delleXExpression (quindi istanziazione di variabili, chiamate a funzione, etc.),nella seconda si specifica una possibile ontologia che verra utilizzata nellagestione dell’evento. Per ora gli eventi gestibili in JADEL sono solamentei messaggi. Per questo, e stata specificata una regola per aggiungere ilsupporto nativo a nuove tipologie di evento (basta aggiungere un’alternativaalla regola BehavioursEvent).

HandleBehaviourEvent e la regola che ci serve per effettuare il matchdel messaggio. Composta dalla parola chiave on seguita dall’evento e dalValidID che identifica possiamo specificare un blocco when per indicare conche criteri matchare il template, grazie alla parser rule WhenExpression.Il blocco do, invece, e proprio l’implementazione del metodo action() dijade.core.behaviours.Behaviour.

Il grafo di sintassi per le regole BehaviourBody, HandleBehaviourEvente BehavioursEvent e mostrato dalla Figura 3.4.

37

Figura 3.4: Syntax graph for behaviours, seconda parte

Particolarmente interessanti sono le parser rule di tipo WhenExpression,in quanto sono state scritte nel rispetto delle regole di precedenza deglioperatori logici and e or e ! (not). Inoltre e possibile utilizzare le parentesidove si ritiene piu opportuno.

Vediamo le parser rule di tipo WhenExpression:

1 WhenBodyExpression returns WhenExpression :2 {WhenBodyExpression}3 ’ { ’4 e xp r e s s i on s += WhenExpression∗5 ’ } ’6 ;

Innanzitutto abbiamo WhenBodyExpression che ci serve per poter creare unblocco di espressioni When. Come si vede dalla definizione della regola, essaci serve per aggiungere le espressioni interessate all’interno di un blocco ‘{’‘}’.

A questo punto dobbiamo evitare che la nostra grammatica diventi ricor-siva sinistra, in quanto ANTLR non le gestisce. Per garantire la precedenzadegli operatori e l’associativita (che permette la precedenza degli operatoriin assenza di parentesi) dobbiamo definire innanzitutto le WhenExpression

atomiche. Esse sono riportate di seguito.

38

1 WhenAtomic returns WhenExpression :2 {Performat ive } ’ pe r fo rmat ive ’ ’ i s ’3 per fo rmat ive = PerformativeEnum |4 {Ontology} ’ onto logy ’ ’ i s ’5 onto logy = [ OntologyStructure | Qualif iedName ] |6 {Content} ’ content ’ ’ i s ’7 p r opo s i t i on = [ Propo s i t i on s | Qualif iedName ]8 ;

L’elenco successivo mostra la precedenza che hanno gli operatori logici,a partire da quello che ha meno priorita:

1. or;

2. and;

3. ! (operatore di negazione logica).

Per costruire quest’ordine, usiamo le seguenti regole:

1 WhenExpression :2 WhenOr3 ;45 WhenOr returns WhenExpression :6 WhenAnd ({WhenOr . l e f t = current} ’ or ’ r i g h t = WhenAnd) ∗7 ;89 WhenAnd returns WhenExpression :

10 WhenPrimary ({WhenAnd . l e f t = current} ’ and ’11 r i g h t = WhenPrimary ) ∗12 ;1314 WhenPrimary returns WhenExpression :15 ’ ( ’ WhenExpression ’ ) ’ |16 {Not} ’ ! ’ e xp r e s s i on = WhenPrimary |17 WhenAtomic18 ;

Era possibile aggiungere, vista la massima priorita, l’operatore ! all’in-terno delle espressioni atomiche ma, visto che comunque un passo di valuta-zione e necessario, sono state aggiunte le WhenPrimary. Questo ci permetteanche di dare la possibilita all’utente di aggiungere le parentesi, qualora loritenesse necessario.

Di seguito il syntax graph delle WhenExpression.

39

Figura 3.5: Syntax graph for behaviours, terza parte

40

Esiste una parser rule ti tipo enum che integra a livello di linguaggio tuttele performative presenti in JADE:

1 enum PerformativeEnum :2 ACCEPT PROPOSAL | AGREE | CANCEL | CFP | CONFIRM |3 DISCONFIRM | FAILURE | INFORM | INFORM IF |4 INFORM REF | NOTUNDERSTOOD | PROPAGATE | PROPOSE |5 PROXY | QUERY IF | QUERYREF | REFUSE |6 REJECT PROPOSAL | REQUEST | REQUESTWHEN |7 REQUESTWHENEVER | SUBSCRIBE | UNKNOWN8 ;9

10 /∗∗∗ End Behaviours ∗∗∗/

AbstractOntologies

Come per i behaviour, la parser rule AbstractOntologies e stata scrittain modo da poter estendere la grammatica con nuove tipologie di ontologie,qualora ne esistessero, semplicemente aggiungendo un’alternativa ad essa.

La regola base delle ontologie e OntologyStructure la quale permettedi specificare un’ontologia mediante semplici passaggi. Si utilizza la parolachiave ontology seguita da un identificatore valido (il suo nome), si apre unblocco (grazie a OntologyBody) e se ne specificano gli elementi.

1 /∗∗∗ Onto log i e s ∗∗∗/23 AbstractOnto log i e s :4 OntologyStructure5 ;67 OntologyStructure :8 ’ onto logy ’ name = ValidID9 body = OntologyBody

10 ;1112 OntologyBody :13 {OntologyBody}14 ’ { ’15 e lements += OntologyElements∗16 ’ } ’17 ;

Gli elementi di un ontologia sono specificati dalla parser ruleOntologyElements e possono essere proposizioni o predicati (rispettivamen-te regole Propositions e Predicate).

41

1 OntologyElements :2 Propo s i t i on s | Pred i ca t e s3 ;45 Propo s i t i on s :6 ’ p r opo s i t i on ’ name = ValidID7 ;89 Pred i ca t e s :

10 ’ p r ed i c a t e ’ name = ValidID11 body = XBlockExpression12 ;

Come si nota dalla definizione delle regole, per aggiungere gliOntologyElements e necessario usare la parola chiave proposition, con ilrelativo ValidID, e la parola chiave predicate, con ValidID e corpo dellostesso.

Per poter utilizzare invece un’ontologia, come visto in nelle sezioniJadelAgents e AbstractBehaviours, e necessario usare le parole chiave use

ontology seguite da un riferimento ad un OntologyStructure esistente.

1 OntologyDec larat ion :2 ’ use ’ ’ onto logy ’ onto logy =3 [ OntologyStructure | Qualif iedName ]4 ;56 /∗∗∗ End Onto log i e s ∗∗∗/

La Figura 3.6 mostra il syntax graph per AbstractOntology.

42

Figura 3.6: Syntax graph for behaviours, terza parte

43

Conclusioni

In questa tesi e stata completata la grammatica di un linguaggio di pro-grammazione orientato agli agenti software, JADEL. Inizialmente sono statestudiate le tesi degli studenti che avevano gia approfondito queste tematichee, successivamente, analizzata la loro compatibilita con l’ultima release diXtext. Si e pensato di riscrivere l’intero progetto per vari motivi, quali:

• avere una maggiore confidenza con le tecnologie disponibili;

• impostare in modo che fosse facilmente estendibile;

• garantire che la grammatica fosse piu semplice e conforme ai requisiti.

Lavorare con Xtext e Xtend non e stato particolarmente facile. Sonostrumenti molto potenti, permettere di scrivere DSL ed integrarli con Eclipsenon e cosa da poco, ma le risorse a supporto (quali documentazione edesempi) non sono propriamente chiari. Inoltre, nell’ultima release (2.7.3)sono state deprecate funzioni e reso indispensabile un porting manuale dallevecchie versioni.

Nell’appendice di questa tesi viene riportato un elenco di sviluppi futuriche permetteranno di completare JADEL.

44

Appendice A

JADEL: Sviluppi Futuri

In questa appendice vedremo i possibili sviluppi futuri di JADEL attual-mente analizzati, in ordine di come dovranno essere implementati.

A.1 Premessa: i test del linguaggio

Ad ogni passo di implementazione di JADEL, i test saranno fondamentali.Xtext ci fornisce supporto a JUnit, il che ci permette di scrivere classi Xtendper avere JUnit test per ognuno (validazione, Inferrer, etc.). Questo ap-proccio e chiamato TDD (Test Driven Development). Tutti i file di testsaranno all’interno del package ide.jadel.tests.

A.2 JadelValidator

Implementare la classe Xtend JadelValidator e il primo passo. Con lafase di validazione del codice e possibile creare vincoli sul codice che nonpossono essere verificati al momento del parsing. Bastera dire ad Xtextquali sono i possibili warning e/o errori significativi che si vogliono notificaretramite l’IDE all’utente nel caso in cui tali vincoli non vengano rispettati.La validazione e effettuata in background nel mentre il programmatore stascrivendo, in modo da avere un feedback immediato.

La specifica di errori e warning significativi permettera all’utente diriucsire a capire qual e il problema e di risolverlo in modo agevole.

A.3 JadelJvmModelInferrer

Come visto nel capitolo su Xtext e Xbase, JadelJvmModelInferrer ci per-mette di mappare i concetti JADEL in elementi del linguaggio Java. InJADEL vogliamo che vengano estese le classi di JADE in questo modo:

45

• agenti JADEL che estendono la classe Agent con implementati i metodisetup() e takeDown() con la gestione degli eventi on create e on

delete con l’aggiunta dei behaviour e ontologie mediante use;

• behaviour JADEL che estendono la classe OneShotBehaviour o la clas-se CyclicBehaviour, in base al tipo specificato dal programmatore(oneshot o cyclic) e abbiano implementato il metodo action() e lagestione dei messaggi grazie al blocco on...when...do;

• ontologie JADEL che estendono la classe Ontology e che introduca leproposition e i predicate.

A.4 JadelScopeProvider

IScopeProvider e l’interfaccia Xtend che, una volta implementata, permet-te la personalizzazione dello scope del proprio DSL. In questo caso, essendoJADEL basato su Xbase, e necessario verificare come viene gestito lo scopee, nel caso non sia corretto o non conforme ai requisiti, si implementi unJadelScopeProvider.

A.5 JadelQuickfixProvider

La classe XbaseQuickfixProvider e fortemente legata al Validator, inquanto essa nasce per fornire dare proposte di risoluzione a problemi natinella fase di validazione (quindi i warning e gli errori). Xtext e Xbase met-tono a disposizione questa classe Xtend, in modo da permettere al designerdel DSL di implementare questi meccanismi.

Una volta definito il JadelValidator, si ha gia la possibilita di for-nire per ognuno dei warning o errori una proposta di soluzione tramite ilJadelQuickfixProvider.

A.6 LabelProvider e OutlineTreeProvider

Xtext fornisce tutto il necessario per aggiungere feature all’IDE Eclipsegenerato. E possibile:

• etichettare con testo e icone le entita del DSL che si stanno scrivendo(mediante l’estensione di XbaseLabelProvider);

• gestire l’albero della view “Outline”, quindi aggiungere e/o rimuove-re nodi che specificano meglio la struttura del file corrente (tramitel’estensione di DefaultOutlineTreeProvider.

Outline stessa si servira del LabelProvider per ottenere testo e icone. InJADEL, i file Xtend che contengono queste classi sono JadelLabelProvider

e JadelOutlineTreeProvider.

46

A.7 JadelProposalProvider

Questa classe Xtend e quella che ci permette di personalizzare il content assi-st di Eclipse per JADEL (il menu a tendina che viene mostrato alla pressionedei tasti ctrl + space). In questo modo l’IDE generato fornira un suppor-to piu completo al linguaggio, in quanto fornira suggerimenti piu precisi edettagliati al programmatore mentre sta lavorando, come ad esempio perindicare la lista degli eventi possibili dopo la parola chiave on.

A.8 JadelFormatter

Nella classe JadelFormatter e possibile specificare un comportamento per-sonalizzato del menu Format di Eclipse per JADEL. In questo modo si per-mette di automatizzare la formattazione del codice (indentazione, spaziatu-ra, etc.).

47

Bibliografia

[1] Fabio Bellifemine Giovanni Caire and Dominic Greenwood. DevelopingMulti-Agent Systems With JADE. John Wiley and Sons, Ltd, 2007.

[2] Giovanni Caire. JADE Programming for Beginners. 2009.

[3] Fabio Bellifemine Giovanni Caire Tiziana Trucco and Giovanni Rimassa.JADE Programmer’s Guide. 2010.

[4] Fabio Bellifemine Giovanni Caire Tiziana Trucco Giovanni Rimassa andRoland Mungenast. JADE Administrator’s Guide. 2010.

[5] Jean Vaucher and Ambroise Ncho. Using ontologies. http://www.iro.

umontreal.ca/~vaucher/Agents/Jade/Ontologies.htm, 2004.

[6] Federico Bergenti. An Introduction to the JADEL ProgrammingLanguage. 2014.

[7] Xtext online documentation. https://eclipse.org/Xtext/

documentation.html.

[8] Lorenzo Bettini. Implementing Domain-Specific Languages with Xtextand Xtend. Packt Publishing, 2013.

[9] Riccardo Monica. Introduzione del Supporto per Behaviour Complessi inun Linguaggio per Agenti Software. 2014.

48