Eclipse Coordination Tools

Lo strumento principale per l’utilizzo del linguaggio Reo per il coordinamento di componenti `e l’Eclipse Coordination Tools [110]. L’Eclipse Coordination Tools (ECT) `e un toolbox che comprende un insieme di strumenti integrati ed `e disponibile come plugin per la piattaforma Eclipse [111]. ECT supporta l’utente nel processo di creazione, animazione, verifica e simulazione di con- nettori Reo.

In particolare, ECT raggruppa al suo interno degli strumenti che, tra le altre cose, mettono a disposizione le seguenti funzionalit`a:

• creazione e modifica di connettori ed automi con vincoli (CA) in un ambiente visuale;

• animazione di connettori attraverso la generazione on-the-fly di anima- zioni Flash;

• generazione di codice a partire da connettori o CA; • model checking di connettori;

• conversione di modelli BPMN e BPEL in connettori Reo.

La principale modalit`a di interazione dell’utente con l’ECT `e quella che passa per l’editor grafico. ECT infatti mette a disposizione un ambiente visuale per la creazione di connettori Reo. L’ambiente permette agli utenti uno svilup- po relativamente agile di elementi Reo, complice l’integrazione nell’ambiente Eclipse, con il quale molti sviluppatori hanno una discreta familiarit`a. Uno dei ruoli fondamentali dell’editor grafico `e quello di fungere da “intermedia- rio” nei confronti di altre funzionalit`a integrate in ECT quali la generazione di animazioni e di codice. La Figura 4.26 ci permette di farci un’idea su come si

Fig. 4.26: ECT - Editor grafico e animatore di connettori Reo

presenta l’editor di connettori Reo. L’interazione con l’ambiente grafico non `

alcuni strumenti per la creazione di circuiti Reo a partire da rappresentazioni fornite in altri linguaggi. BPEL2Reo ad esempio `e uno strumento che per- mette la conversione di processi BPEL in circuiti Reo [178]. Il convertitore, che implementa un mapping del nucleo del linguaggio [178], `e stato realizza- to dall’Universit`a di Teheran e successivamente integrato nel toolbox. ECT include un altro convertitore, che permette la creazione di connettori Reo a partire da diagrammi espressi in un opportuno sottoinsieme di elementi della popolare notazione BPMN [9], di cui ci siamo occupati nella sezione 4.1. Il convertitore `e realizzato per mezzo di un insieme di regole di trasformazione e di pattern matching implementate in Atlas Transformation Language (ATL).

Uno degli accessori pi`u utili del toolbox `e sicuramente lo strumento di ani- mazione di connettori, che genera animazioni Flash on the fly a partire da diagrammi di connettori. La generazione di animazioni utilizza la semanti- ca basata su colorazione di connettori (che abbiamo presentato nella sezione 4.2.2.1). In particolare, lo strumento che realizza l’animazione utilizza il sim- bolo per indicare la presenza di flusso in un certo istante, ed i simboli e per l’assenza di flusso.

La Figura 4.27 mostra due stati dell’animazione di un messenger con due client. La parte sinistra della figura modella il momento in cui il client sini- stro invia un messaggio, che viene memorizzato nel buffer. Il secondo passo dell’animazione, raffigurato nella parte destra, il messaggio raggiunge il mixed node e viene replicato per essere quindi inviato al client destro e al mittente stesso.

Fig. 4.27: Animazione di un connettore Reo

connettore. Lo strumento di animazione genera tutto lo spazio degli stati e produce le animazioni possibili. Nel caso in cui siano specificati dei ci- cli (che comportano un numero potenzialmente infinito di possibili stati), lo strumento seleziona gli scenari “interessanti”. L’utente pu`o inoltre scegliere di eseguire l’animazione un passo alla volta, scegliendo manualmente tra le possibili alternative di instradamento del flusso.

Abbiamo introdotto nella sezione 4.2.2.1 il concetto di Constraint Au- tomaton (automa con vincoli) e abbiamo specificato che questi particolari automi sono uno dei metodi utilizzati per catturare la semantica del linguag- gio Reo.

All’interno del toolbox ECT `e presente anche uno strumento per la creazione di automi a partire da connettori Reo. Tale strumento, oltre che per dare una visione formale dei connettori, serve da connessione con altri strumenti quali il generatore di codice, il model checker ed il simulatore. La genera- zione di un CA a partire da un connettore sfrutta la composizionalit`a della semantica, infatti prima vengono generati i CA relativi ai canali (ed ai nodi) e successivamente dagli automi di base viene ricavato il CA finale attraverso l’applicazione del prodotto, che riproduce l’operazione di join.

Un ulteriore strumento contenuto in ECT `e il generatore di codice per con- nettori Reo. La generazione di codice avviene a partire dal CA che modella il connettore che si vuole implementare. Il CA viene utilizzato per la gene- razione di codice da dare in pasto ad una macchina a stati eseguibile, che implementa il coordinamento dei componenti, che devono comunque essere noti a priori. Nel momento in cui viene innescata una transizione, pu`o av- venire il passaggio di dati tra due punti di sincronizzazione corrispondenti a due porte. I meccanismi utilizzati per la sincronizzazione dipendono dalle primitive messe a disposizione dal linguaggio. Attualmente il componente in questione produce codice Java e i componenti devono implementare l’inter- faccia cwi.ea.runtime.ReoComponent.

Abbiamo discusso in precedenza come i Quantitative Intentional Auto- mata (QIA) [8], che estendono i Constraint Automata (CA) con propriet`a QoS, costituiscano un modello semantico per i connettori Reo. Attraverso l’utilizzo dei QIA `e possibile specificare modelli di coordinamento prenden- do in considerazione il costo dei componenti e del loro coordinamento. Per supportare l’analisi delle prestazioni dei connettori, in ECT `e stato integrato uno strumento di simulazione che permette di utilizzare varie distribuzioni di probabilit`a sui canali. Alcune delle opzioni che `e possibile specificare per l’esecuzione della simulazione sono:

• Terminazione della simulazione: basata su eventi o a tempo.

• Durata del periodo di warm-up: tempo o numero di eventi prima che si inizino le statistiche.

• Durata della simulazione: tempo o eventi prima del termine della si- mulazione.

• Individuazione di deadlock/livelock: la simulazione si interrompe ap- pena si individua un deadlock o un livelock.

Alcuni dei dati proposti in output al termine della simulazione sono i seguenti: • Richieste perse: percentuale di richieste perse in canali LossySync ri-

spetto al numero totale.

• Tempo medio di attesa: tempo medio di attesa delle richieste che non vengono bloccate.

• Utilizzo dei buffer: percentuale di tempo in cui il buffer FIFO `e pieno. • Utilizzo del canale: percentuale di tempo in cui il canale `e in uso. • Ritardo punto a punto: ritardo medio totale tra due punti.

• Tempo di arrivo: tempo medio tra due arrivi consecutivi in un punto finale a partire da un certo punto iniziale.

Accanto all’analisi a posteriori offerta dallo strumento di simulazione, ECT permette di eseguire analisi statiche sui connettori. Reo offre meccanismi relativamente semplici per la creazione di connettori, tuttavia man mano che aumenta la complessit`a dei connettori, cresce la difficolt`a di interpretar- li. Dunque l’applicazione di Reo a scenari complessi richiede la presenza di strumenti che supportino l’analisi dei meccanismi di coordinamento [58]. L’esecuzione di model checking sui connettori parte dalla conversione degli

stessi in Constraint Automata, che pi`u volte abbiamo menzionato. Attra- verso l’uso di un modello simbolico e di una logica in stile CTL, `e possibile specificare e verificare propriet`a.

Vereofy `e un model checker per il linguaggio Reo che `e stato implementato presso la Technische Universit¨at di Dresden e permette di eseguire il model checking con Logica Temporale Lineare e Branching, e il controllo di equiva- lenza di connettori. Vereofy pu`o essere utilizzato come strumento stand-alone o come componente del toolbox ECT.