Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica

Elaborato finale in Programmazione I

Tecnologie e strumenti per la realizzazione di applicazioni in ambiente Eclipse

Anno Accademico 2015/2016

Candidato: Daniele Formisano matr. N46001429

A chi ha sempre creduto in me

Indice

Indice .................................................................................................................................................. III

Introduzione ......................................................................................................................................... 4

Capitolo 1: Eclipse ............................................................................................................................... 5

Capitolo 2: Extension e Extension Point.............................................................................................. 7

2.1 Workbench extension points ................................................................................................. 8

2.1.1 Views ............................................................................................................................. 8

2.1.2 Editors ............................................................................................................................ 9

2.1.3 Commands ..................................................................................................................... 9

2.1.4 Menus ........................................................................................................................... 10

2.1.5 Handlers ....................................................................................................................... 11

2.1.6 Bindings ....................................................................................................................... 11

Capitolo 3: Il Plug-in.......................................................................................................................... 12

3.1 Package dstm_plugin.supporto ............................................................................................ 14

3.2 Package dstm_plugin.handlers ............................................................................................ 16

Capitolo 4: Esempi di funzionamento ................................................................................................ 18

Bibliografia ........................................................................................................................................ 22

4

Introduzione

Il linguaggio DSTM (Dynamic State Machine) è un’estensione delle macchine a stati gerarchiche

sviluppata dal gruppo di ricerca del Dipartimento di Ingegneria Elettrica e delle Tecnologie

dell’Informazione nell’ambito del progetto europeo CRYSTAL (CRitical sYSTem engineering

AcceLeration).

DSTM è stato sviluppato per soddisfare i requisiti espressi da Ansaldo STS, azienda leader nel campo

dei sistemi di controllo ferroviario ad alta velocità, al fine di offrire uno strumento formale per lo

sviluppo di modelli del comportamento di sistemi di controllo per applicazioni critiche.

La sua principale caratteristica è di fornire opportune primitive per la modellazione di sistemi di

controllo ferroviario offrendo al contempo una semantica ed una sintassi formale e sufficientemente

espressiva.

L’obiettivo finale di tale attività di ricerca è lo sviluppo di linguaggi e strumenti a supporto del

processo di verifica e validazione. In particolare, il gruppo di ricerca ha sviluppato un generatore di

casi di test per la verifica di requisiti funzionali, a partire da un modello DSTM del sistema e da

opportune specifiche di test.

In questo contesto, lo scopo della presente tesi è stato quello di definire uno strumento in grado di

integrare il tool grafico per la modellazione DSTM di sistemi di controllo ferroviario con i relativi

servizi di verifica dei modelli, merging di data e control flow e generazione dei casi di test.

La tesi è strutturata come segue. Nel primo capitolo viene introdotto brevemente il framework

Eclipse (EMF), sul quale è basato lo sviluppo di tutti gli strumenti di supporto alla modellazione e

alla generazione dei casi di test; il secondo capitolo illustra il concetto di Extension e Extension Point

di EMF, meccanismo alla base dell’espansione delle funzionalità della interfaccia grafica dello

strumento di modellazione DSTM; il terzo capitolo fornisce una descrizione della struttura del plug-

in sviluppato ed il quarto alcuni esempi di funzionamento.

5

Capitolo 1: Eclipse

Eclipse è un potente IDE (integrated development environment) open source, scritto in Java e

quindi indipendente dalla piattaforma sottostante, grazie alle potenzialità della Java Virtual

Machine.

Il progetto Eclipse è sostenuto dalla Eclipse Foundation, un’organizzazione non-profit

composta da più di cento importanti società quali Intel, HP, IBM, Ericsson, ma anche da

un’estesa comunità di sviluppatori open source.

I componenti principali (core components) di Eclipse, sono contenuti nell’Eclipse Project o

anche detto Eclipse Software Development kit (SDK);

Essi sono: Equinox, Platform, Java Development Tools (JDT) e Plug-in Development

Environment (PDE).

Tali componenti rappresentano tutti gli strumenti necessari all’estensione del framework ed alla

creazione di tool basati su Eclipse.

Data infatti la natura Open source dell’IDE, è possibile creare prodotti da esso derivati e

ridistribuirli in forma gratuita sotto licenza Eclipse Public License (EPL).

Uno dei fattori chiave di Eclipse è appunto la possibilità di estenderne le funzionalità tramite

plug-in che consentono di implementare specifiche funzioni.

Il runtime engine della piattaforma ha il compito di caricare i plug-in in memoria

dinamicamente, cioè solo nel caso in cui l’utilizzo del plug-in si rendesse necessario. Esso

implementa l’OSGI Service Platform, una specifica che permette di costruire applicazioni

modulari a componenti (bundle o plug-in).

Attualmente, mediante il meccanismo dei plug-in, Eclipse consente di supportare lo sviluppo

di software in diversi linguaggi tra cui Java, C++, Perl, Phyton, PHP.

La modularità e la possibilità di ampliamento della piattaforma sono le caratteristiche che hanno

favorito la sua diffusione, ma anche la stabilità, il supporto di tanti sviluppatori e la

distribuzione gratuita.

6

In particolare per l’implementazione del linguaggio DSTM è stato utilizzato l’Eclipse

Modeling Framework.

EMF fornisce strumenti per la modellazione che permettono di costruire e manipolare modelli

strutturati, ma anche di generare automaticamente gli artefatti (incluso il codice Java) necessari

alla gestione automatica dei modelli.

EMF ha come scopo principale l’unificazione di tre differenti strumenti di rappresentazione di

un sistema, ovvero il codice Java, il diagramma delle classi UML e il modello XML.

A partire infatti da una delle tre rappresentazioni del sistema, il framework è in grado di

generare le restanti due utilizzando un modello EMF.

7

Capitolo 2: Extension e Extension Point

In base alle caratteristiche di Eclipse è necessario sviluppare i moduli in modo che siano

quanto meno accoppiati possibile. In questo modo è possibile favorire l'assemblaggio e la

sostituzione dei vari componenti, evitando quindi di dover apportare più modifiche al sistema.

L'accoppiamento lasco si ottiene tramite il meccanismo degli extension e extension points.

Un plug-in che vuole consentire ad altri di estendere le proprie funzionalità dichiara nel file

di manifesto un extension point. Esso rappresenta un contratto, formato da combinazioni di

markup XML e interfacce Java, a cui le extension dovranno fare riferimento.

Un plug-in che ne vuole quindi estendere le funzionalità deve dichiarare nel file di manifesto

un extension appositamente sviluppata.

Il file di manifesto, plugin.xml, descrive quindi come il plug-in estende la piattaforma, quali

extension point mette a disposizione, e come implementa le funzionalità.

Punto chiave è che il Plug-in che viene esteso non deve conoscere i dettagli

dell'implementazione del Plug-in estensore; per questo plug-in sviluppati da aziende e persone

diverse riescono ad interagire senza problemi pur non avendo una conoscenza approfondita

l’uno del funzionamento dell’altro.

La piattaforma Eclipse mette a disposizione diverse tipologie di Extension point:

extension point interamente Dichiarative che non contribuiscono con alcun codice,

come ad esempio l’extension bindings che lega una combinazione di tasti ad un

particolare comando;

extension point per l'override del comportamento originale di un componente;

extension point per gestire elementi dell’interfaccia.

8

Ogni extension point è definito da uno schema file, necessario per dichiarare i propri attributi,

indispensabili ai fini dell’estensione corretta dello stesso. Questo schema viene utilizzato

durante lo sviluppo del plug-in per verificare la presenza di eventuali dichiarazioni invalide

nel file di manifesto ed è impiegato dal wizard del Plugin Development Environment per

guidare l’utente nei passi richiesti per la corretta definizione dell’estensione.

Di seguito sono presentati gli extension points messi a disposizione dal workbench, che

rappresentano la via primaria per estendere la piattaforma e che saranno utilizzati per lo

sviluppo del plug-in;

2.1 Workbench extension points

Il Workbench è la finestra principale dello strumento, ciò che l'utente vede quando avvia

Eclipse, per questo definito anche come “il desktop di Eclipse”.

È formato da view e editor, le cui diverse disposizioni prendono il nome di perspective.

Come detto gli extension point permettono ai plug-in di estendere le funzionalità di editor e

view esistenti o di provvedere all'implementazione di nuovi. Di seguito vengono introdotti

gli extension point relativi al Workbench tra cui quelli utilizzati per lo sviluppo del plug-in.

2.1.1 Views

Una view è una finestra, usata per presentare liste, gerarchie, informazioni relative al

contenuto dell'editor attualmente utilizzato, proprietà di un oggetto.

Tipicamente solo una istanza di una view può essere presente nel Workbench e ogni

cambiamento effettuato in essa è istantaneamente applicato al Workbench.

L’extension point org.eclipse.ui.views permette ai plug-in di aggiungere view al Workbench

o di estendere le funzionalità di view già esistenti.

In accordo con ciò precedentemente esposto, plug-in che forniscono o estendono una view

devono registrarla nel loro plugin.xml file e fornire le informazioni di configurazione

necessarie, come la classe di implementazione, la category alla quale appartiene, il nome e

l’icona che deve essere usata per rappresentare la view nei menu e nelle label.

9

Per quanto riguarda invece l’implementazione si può far uso dell’interfaccia IViewPart,

oppure si può specializzare la classe ViewPart.

2.1.2 Editors

Un editor è una parte del Workbench che permette all’utente di modificare un oggetto o un

file. Operano in maniera simile agli editor forniti dal sistema operativo, ma sono fortemente

integrati nella UI del Workbench. Un Editor è sempre associato ad un input object

IEditorInput, che rappresenta l’oggetto o il file con cui interagisce. Le modifiche all’oggetto

hanno effetto solo quando vengono confermate dall’utente.

Una differenza con le view è che più tipi dello stesso editor possono essere istanziati nello

stesso Workbench, associati però ad input differenti; se si prova infatti a modificare un oggetto

già associato ad un editor, non verrà istanziato un nuovo editor ma si verrà reindirizzati a

quello già esistente.

L’extension point org.eclipse.ui.editors è usata dai plug-in per aggiungere editor al

Workbench o estendere editor già esistenti.

Plug-in che contribuiscono al Workbench con un editor devono registrare l’extension

dell’editor nel loro file plugin.xml, insieme alle informazioni di configurazione.

Alcuni attributi sono simili a quelli necessari per le view, anche qui bisogna dichiarare infatti

la classe di implementazione, il nome e l’icona da usare per il menu del Workbench e per le

label.

Deve essere però aggiunto l’attributo relativo all’estensione del file con cui l’editor andrà ad

operare.

Per l’implementazione si può far uso dell’interfaccia IEditorPart, oppure si può specializzare

la classe EditorPart.

Quando un editor è attivo, crea una voce nel menu e nella toolbar del Workbench,

usando gli extension point org.eclipse.ui.commands e org.eclipse.ui.menus.

2.1.3 Commands

I command rappresentano un comportamento, a cui viene associato un ID.

Il comportamento sarà poi implementato attraverso uno o più handler.

10

Separare il command dall’implementazione significa dare possibilità a più plug-in

di implementare lo stesso comportamento.

Sono definiti usando l’extension point org.eclipse.ui.commands e richiede gli attributi name,

description e id.

È possibile anche specificare l’id di una categoria di comandi in cui inserirlo.

Un command non ha una implementazione di default, ma diviene concreto solo quando un

plug-in associa ad esso un handler tramite il command id.

Quindi i command possono essere implementati usando gli org.eclipse.ui.handlers ed

essere abbinati ad una combinazione di tasti (key) usando l’extension point

org.eclipse.ui.bindings; E ancora essere associati ad una voce nel menu, nella toolbar ed in

altre aree del Workbench tramite l’extension point org.eclipse.ui.menus.

2.1.4 Menus

L’extension point org.eclipse.ui.menus , permette di definire la posizione in cui un command

deve essere visibile nell’applicazione.

Consente infatti l’aggiunta di un elemento come una label o un bottone ad una parte del

workbench quale il menu o la toolbar principale o il menu di una view.

Per questo tra gli attributi necessari alla definizione dell’estensione sono presenti l’id del menu

o della toolbar o della trim area di interesse ed un punto di inserimento, rappresentato dal

locationURI dell’area di interesse.

Seguono alcuni esempi di locationURI:

o menu:file?after=additions

inserisce l’elemento nel menu File dopo il gruppo additions;

o menu:org.eclipse.ui.views.ContentOutline?after=additions

inserisce l’elemento nella vista Outline dopo il gruppo additions;

o toolbar:org.eclipse.ui.views.ContentOutline?after=additions

inserisce l’elemento nella toolbar della vista Outline dopo il gruppo additions;

Verrà poi associato il Command id del comando da eseguire quando l’elemento sarà attivato.

11

Gli elementi che compongono il menu seguono nell’interfaccia le stesse posizioni che hanno

nel file plugin.xml.

2.1.5 Handlers

L’handler dunque rappresenta l’implementazione di un command. Ogni plug-in può fornire

un handler per ogni command. Sarà poi il workbench a determinare quale handler è attivo in

ogni momento.

Per ogni comando può esserci un solo gestore attivo alla volta.

Mentre un command può avere un handler di default, più handler possono essere associati allo

stesso command.

È possibile utilizzare l’espressione <activeWhen/> nel file plugin.xml per specificare lo scope

di attivazione dell’handler, ad esempio una finestra specifica o una parte attiva.

L’implementazione dell’handler prevede l’uso dell’interfaccia IHandler oppure la

specializzazione della classe AbstractHandler.

All’attivazione dell’handler sarà invocato il metodo execute(ExecutionEvent) che raccoglierà

quindi il codice di interesse per l’implementazione del command.

Tramite l’oggetto ExecutionEvent si può ricavare qualsiasi parametro dall’oggetto chiamante,

tra cui il contesto dell’applicazione in cui il command è eseguito. Si possono quindi ottenere

molte informazioni relative allo stato corrente del workbench, come ad esempio la finestra

attiva del workbench, la shell attiva, la parte attiva, l’editor attivo.

2.1.6 Bindings

Il seguente extension point permette di associare un command ad una specifica combinazione

di tasti.

L’associazione è detta Key binding ed i plug-in possono definirle tramite l’extension point

org.eclipse.ui.bindings.

La combinazione di tasti usata per invocare un comando è definita dall’attributo sequence,

mentre l’attributo contextID indica in quale contesto la binding è attiva.

Viene ovviamente specificato il commandId del comando da eseguire.

12

Capitolo 3: Il Plug-in

Il fine del plug-in sviluppato è quello di integrare il tool grafico per la modellazione di sistemi

di controllo ferroviario con i relativi servizi di verifica dei modelli, merging di data e control

flow e generazione dei casi di test.

Eclipse fornisce un wizard che crea la struttura standard del plug-in e prevede l’aggiunta di

un Sample Menu nella menu bar e un bottone nella tool bar.

Sia l’elemento del menu che il bottone nella toolbar invocano lo stesso Sample Command

che apre una semplice finestra di dialogo. Il Sample Command è richiamabile anche da una

combinazione di tasti.

13

Il plug-in in sviluppo prevede l‘aggiunta di un singolo Menu alla menu bar di Eclipse, che

conterrà diversi elementi, ognuno dei quali invocherà un differente servizio.

Quindi, prendendo in analisi il file plugin.xml, avremo bisogno di diversi Command,

uno per ogni servizio che il plug-in deve essere in grado di invocare e altrettanti Handler da

collegare a ciascun Command, ed infine i Menu.

Sono superflui dunque gli extension points relativi al bottone nella toolbar e quello relativo al

key bindings, che saranno rimossi.

Ad ogni Handler come visto nel capitolo 2 sarà associata una classe java che si occuperà di

implementare il comando vero e proprio.

Il plug-in prevede i seguenti comandi:

COMANDI DESCRIZIONE

VerifyAll Verifica la correttezza del modello delle strutture di controllo e delle

strutture dati

VerifyData Verifica la correttezza delle strutture dati

VerifyTrigger Verifica la correttezza dei Trigger

VerifyCondition Verifica la correttezza delle Condizioni

VerifyAction Verifica la correttezza delle Azioni

VerifyModel Verifica la correttezza del modello delle strutture di controllo

VerifyParameter Verifica la correttezza dei Parametri

Merge Genera un modello Merged a partire dal modello delle strutture di

controllo e dalle strutture dati

Generate Genera casi di test a partire dal modello delle strutture di controllo e

dalle strutture dati

Generate with Input Genera casi di test a partire dal modello delle strutture di controllo e

dalle strutture dati e dagli input

14

Gli input del plug-in sono dunque il file Model ed il file Dataflow che dovranno essere

contenuti nella cartella model di ogni progetto di interesse.

La struttura del plug-in prevede tre package:

dstm_plugin contiene la classe Activator, che gestisce il ciclo di vita del plug-in stesso;

dstm_plugin.handlers contiene i 10 handler;

dstm_plugin.supporto contiene le classi Console e GetResource.

Segue dunque l’analisi di alcune delle classi principali suddivise per package.

3.1 Package dstm_plugin.supporto

1) Console

La classe Console si rende necessaria dato che per offrire un output in console il plug-in,

non può utilizzare il classico outputstream System.out, deve invece creare una nuova istanza

di IConsole e connetterla alla Console view.

È chiara dunque la finalità della classe.

Avendo a che fare con output di tipo testuale, sarà istanziata una MessageConsole.

Necessaria l’aggiunta al plug-in della nuova dipendenza org.eclipse.ui.console.

La classe quindi espone il metodo print(String) che localizza o istanzia una console etichettata

come “Console”, apre uno stream verso di essa e trasmette la stringa.

2) GetResource

La classe GetResource è da considerarsi tra le più funzionali del plug-in.

Il suo ruolo è quello di prelevare da un qualsiasi progetto presente nel workspace di Eclipse,

i due file DSTM e Dataflow.

15

Essa espone due metodi: getDSTM e getDataflow.

Funzione primaria dei due metodi è quella di localizzazione dei file;

la procedura si divide in due passi:

Utilizzando le classi IWorkbenchWindow, IStructuredSelection, IProject si risale al

path del progetto attualmente selezionato.

Dal path, usufruendo del metodo list(), si localizza la cartella model e se presente

vengono cercati in essa rispettivamente il file DSTM per il metodo getDSTM e il file

Dataflow per il metodo getDataflow. A questo punto si dispone del path di entrambi i

file.

Ora il comportamento si specializza:

Il metodo getDSTM, invocando la funzione loadXmiModel della classe DSTM4RailReader,

messa a disposizione dalla libreria DSTMv5.0.1, restituisce un Oggetto DSTM facendo uso

del path precedentemente ricavato.

Il metodo GetDataflow restituisce invece una stringa rappresentante il data flow del modello;

la lettura è effettuata utilizzando l’apposita funzione file2string, messa a disposizione dalla

medesima libreria DSTMv5.0.1.

Sono ovviamente presenti i controlli necessari ad evitare la richiesta dei servizi senza aver

prima selezionato un progetto o qualora nel progetto non sia presente la cartella

model o i file di interesse.

L’attuale implementazione porta con sé due vincoli legati ai file in ingresso.

Il primo prevede che i file DSTM e Dataflow siano contenuti nella cartella model del progetto

selezionato.

Il secondo vincolo pone una limitazione sul numero di file presenti nella cartella model;

deve necessariamente essere presente un solo file DSTM ed un solo file Dataflow, in quanto

non è stata gestita la presenza di più file, scenario di poco interesse.

16

3.2 Package dstm_plugin.handlers

Sono stati definiti tre gruppi di handler, ognuno relativo ad uno specifico proxy per

l’invocazione dei servizi di seguito descritti.

1) DSTMVerifier

Gli handler relativi al proxy DSTMVerifier, consentono di invocare tutti i servizi necessari

alla verifica del modello. La loro struttura è molto omogenea, segue quindi il singolo esempio

relativo al VerifyAll_Handler.

Come anticipato nel capitolo 2, il codice relativo al command rappresenta il corpo della

funzione execute della classe handler;

Vengono istanziate le classi Console e GetResource del package dstm_plugin.supporto ,

di cui invocati i metodi getDSTM() e getDataflow() per leggere i file di input.

È poi istanziato l’oggetto DSTMVerifierProxy ed invocato il suo metodo

verify(dstm,dataSpecification), che invia l’opportuna richiesta al server e ricevuta risposta

ritorna l’esito in forma booleana, che sarà stampato in console.

Gli altri Handler di verifica seguono la medesima struttura, con la differenza che, in base al

comando, sarà istanziato un differente proxy ed invocata la funzione necessaria.

2) Merger

Più articolato il funzionamento dell’handler Merge.

Esso fa uso della libreria ModelMergeProxy.

La prima parte del codice segue la struttura vista per gli handler di verifica istanziando un

proxy di tipo ModelMergeProxy, e invocando la sua funzione mergeModel con input il DSTM

e Dataspecification ottenuti tramite l’oggetto getResorce.

17

Elemento di differenza è il tipo di oggetto restituito dalla funzione che non sarà un booleano,

bensì un oggetto DSTM da memorizzare nella root del progetto selezionato.

L’operazione di memorizzazione è cosi implementata:

1) Ottenuto il path del progetto di interesse, è creato alla radice il file merged.dstm4rail;

2) Viene associato ad esso lo stream FileOutputStream;

3) Quindi si converte l’oggetto DSTM in stringa, utilizzando la funzione modelToString

della classe DstmProxyUtils, fornita dalla libreria modelmergeproxy;

4) Si trasmette dunque la stringa al file tramite lo stream di output.

3) TestCaseGenerator

Il Generate_Handler e GenerateWithInput_Handler fanno uso del proxy TestCaseGenerator.

Anche in questo caso la struttura del codice è la medesima e l’elemento di differenza sarà

ancora l’oggetto restituito dalle funzioni del proxy invocate.

Il proxy istanziato è di tipo TestCaseGeneratorProxy e generate l ’identificativo della

funzione invocata. I parametri sono il DSTM e il Dataspecification a cui si affianca un vettore

di stringhe in qualità di input per il command GenerateWithInput.

Saranno quindi ritornati i casi di test raccolti in un vettore di stringhe che saranno stampate in

Console.

18

Capitolo 4: Esempi di funzionamento

In questo capitolo saranno mostrati tre diversi esempi di funzionamento, uno per ogni proxy

utilizzato.

Verranno invocate le funzioni VerifyAll, Merge e Generate.

Sarà fornito in input il Modello di un FlipFlop RS, circuito elettronico sequenziale utilizzato

nell’elettronica digitale come dispositivo di memoria, caratterizzato da due ingressi

denominati Set e Reset e da un’uscita Q.

In qualità di macchina sequenziale, il valore dell’uscita Q dipende oltre che dagli input anche

dallo stato precedente della macchina.

Control flow Data Flow

19

4.1 Esempio di chiamata al Verifier

Prima operazione da eseguire è selezionare il progetto all’interno del Package Explorer, da

cui il plug-in leggerà i file da analizzare.

Non è possibile procedere altrimenti, il plug-in infatti stamperebbe in console un messaggio

di errore.

Quindi utilizzando la voce VerifyAll del menu Verify, sarà richiesto al proxy Verifier l’analisi

degli input, e l’esito sarà stampato in console. L’implementazione è stata analizzata in

dettaglio nel paragrafo 3.2.1 .

In figura è presente un esempio di output.

20

4.2 Esempio di chiamata al Merger

Selezionato il progetto di interesse nel Package Explorer, utilizzando la voce Merge del menu

Verify sarà richiesto al proxy ModelMerge il servizio di merging di data e control flow.

L’esito della procedura è riportato in console e se positivo comporterà la creazione del

modello merged nella directory radice del progetto.

L’implementazione è stata analizzata in dettaglio nel paragrafo 3.2.2 .

In figura è presente un esempio di output.

21

4.3 Esempio di chiamata al TestCaseGenerator

Selezionato il progetto di interesse nel Package Explorer, utilizzando la voce Generate del

menu Verify sarà richiesto al proxy TestCaseGenerator il servizio di generazione dei casi di

test. L’implementazione è stata analizzata in dettaglio nel paragrafo 3.2.3 .

I casi di test saranno riportati in Console.

In figura è presente un esempio di output.

22

Bibliografia

[1] Dave Steinberg, Frank Budinsky, Marcel Paternostro, Ed Merks,

EMF Eclipse Modeling Framework

[2] Eclipse documentation,

http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fworkbe

nch_cmd_commands.htm

[3] clipse Plug-in Development FAQ

http://wiki.eclipse.org/Eclipse_Plug-

in_Development_FAQ#How_do_I_read_from_a_file_that_I.27ve_included_in_my_bundle.2Fplug

-in.3F