Linguaggi, tecnologie e strumenti a supporto delle trasformazioni tra modelli in ambiente Eclipse

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Programmazione I Linguaggi, tecnologie e strumenti a supporto delle trasformazioni tra modelli in ambiente Eclipse Anno Accademico 2017/2018 Candidato: Antonio Forte matr. N

2 Alla mia famiglia, ai miei compagni di viaggio, ai miei veri amici e alla Prof.ssa Valeria Vittorini

3 Indice Indice... III Introduzione... 5 Capitolo 1: MDE (Model-Driven Engineering)... 7 Capitolo 2: Meta-modeling Sistema Modello Token model Type model Meta-modello Linguaggio di modellazione Capitolo 3: Model Transformation Pattern di trasformazione Classificazione delle trasformazioni di modello ATL e QVT Capitolo 4: ATL (ATLAS Transformation Language) Modulo ATL Sezione intestazione e sezione importazione Helpers Regole di trasformazione Eclipse ADT (Eclipse ATL Development Tools) Capitolo 5: Esempio di una trasformazione ATL Brevi cenni: Finite-State Machine e Petri Net FSM (Finite-State Machine) Petri Net L esempio proposto: Da State Machine a Petri Net Conclusioni Bibliografia... 37

4

5 Introduzione In un mondo in cui sempre più viene richiesta la produzione di software di qualità in tempi ristretti e costi contenuti, sottostimare i costi o i tempi necessari per la produzione di software è tra i problemi principali che ancora oggi le aziende informatiche si trovano ad affrontare se vogliono battere la concorrenza. Per far fronte a questi problemi si adottano approcci disciplinati e strutturati ingegneristici. In effetti già a partire dagli anni 80 del secolo scorso si inizia a lavorare su strumenti software a cui è dato il nome di CASE e che rappresentano i primi strumenti a supporto di quello che oggi definiamo Model-Driven Engineering. I CASE (Computer Aided Software Engineering) sono componenti software che aiutano le attività di processi software come l analisi, la modellazione, il debugging, il testing. Essi permettono di esprimere progetti con rappresentazioni grafiche (es. macchine di stato, diagrammi strutturali, diagrammi di flusso) con l obiettivo di ridurre lo sforzo manuale per la programmazione, il debugging e la portabilità del software. Ridurre lo sforzo manuale lo si può fare ad esempio generando documentazione o codice sorgente in maniera automatica in quanto questo significa che gli sviluppatori saranno privati di questo compito. Essi potranno allora dedicarsi ad altre attività come il raffinamento ulteriore del codice o l innalzamento della qualità del prodotto software. Ciò che nella pratica si fa per ottenere i massimi vantaggi da questi tipi di approcci è utilizzare le trasformazioni di modello per generare modelli sempre più dettagliati, e quindi meno astratti, fino alla generazione automatica di codice eseguibile. In particolare questo elaborato si propone di descrivere in maniera più approfondita i linguaggi, le tecnologie e gli strumenti che sono a supporto delle trasformazioni tra modelli 5

6 in ambiente Eclipse. Per raggiungere tale obiettivo si procederà per piccoli passi. Difatti il Capitolo 1 è dedicato al Model-Driven Engineering che è la metodologia di sviluppo software su cui si basa tutto il nostro discorso. Il Capitolo 2 dedicato alla metamodellazione si occupa invece di presentare le nozioni fondamentali che sono alla base del Model-Driven. Il Capitolo 3 si avvicina in maniera più consistente al nostro obiettivo poiché è un introduzione alle trasformazioni di modello. Il Capitolo 4 descrive invece il linguaggio di trasformazione di modelli ATL che utilizzeremo per sviluppare l esempio finale in ambiente Eclipse presentato nell ultimo capitolo. 6

7 Capitolo 1: MDE (Model-Driven Engineering) Douglas C. Schmidt, informatico e autore di molte opere nel campo della programmazione orientata agli oggetti, nell articolo Model-Driven Engineering descrive il Model-Driven Engineering (MDE) come la metodologia di sviluppo software che ha come obiettivo primario quello di esprimere concetti di dominio in modo efficace grazie alla creazione di modelli e di alleviare la complessità delle piattaforme. Infatti, piuttosto che astrarre il dominio delle tecnologie informatiche, come facevano i linguaggi di programmazione e le piattaforme, il MDE consente di programmare in termini progettuali del dominio applicativo. Sviluppare software in questi termini permette agli sviluppatori di avere una visione più ampia del sistema, delle sue prestazioni, del rispetto dei principi di architettura e di qualità, visto che possono impiegare più energie per fare ciò rispetto al caso in cui approcciassero il problema tramite i linguaggi di programmazione che richiederebbero invece molta attenzione per i dettagli di programmazione. Il MDE per far valere i propri approcci necessita di: DSMLs (Domain Specific Modeling Languages) motori e generatori di trasformazioni I DSMLs sono linguaggi di modellazione di specifico dominio che definiscono vincoli e relazioni tra concetti di uno specifico dominio e formalizzano la struttura applicativa, i requisiti e il comportamento del sistema di interesse. Inoltre, essi descrivono precisamente la sintassi e la semantica del dominio tramite meta-modellazione e ciò fornisce un modo per validare il modello e quindi rilevare e prevenire errori nei primissimi momenti del ciclo di vita del software. 7

8 Invece, motori e generatori di trasformazioni analizzando un modello sono in grado di generare codice sorgente automaticamente, generare un modello alternativo o generare una distribuzione XML. Questo processo di trasformazione automatizzato viene anche detto corretto per costruzione visto che c è consistenza tra il modello (che cattura requisiti funzionali e di QoS) e l implementazione. Si noti che in caso contrario il codice sorgente dovrebbe essere sviluppato dagli sviluppatori che potrebbero commettere errori e sarebbero costretti ad occuparsi di procedure noiose. Alcuni degli approcci del MDE sono il MCSD (Model Centric Software Development) e il SEM (System Execution Modeling tools). Il primo dei due approcci permette di soddisfare requisiti come la verifica della correttezza del software, generazione automatica di codice e, tramite meccanismi di reverseengineering, migliorare la comprensione umana del sistema o di una parte del sistema di interesse attraverso l interpretazione visiva. Il reverse-engineering è particolarmente utile ad esempio nell interpretazione di codice sorgente legacy, visto che permette di generare modelli che sono più facilmente interpretabili visivamente rispetto al codice sorgente. Il secondo approccio permette di analizzare progetti alternativi per quantificare impatti e costi di varie scelte di progetto sulla performance di sistemi end-to-end e di correggere problemi di integrazione in fase di progetto e architettura e non più in fase di integrazione. Alberto Rodrigues Da Silva, professore dell università di Lisbona, nell articolo Modeldriven engineering : A survey supported by the unified conceptual model descrive come i vari approcci MD possano essere analizzati e confrontati rispetto ai seguenti aspetti : livello di astrazione dell approccio (high, medium, low) disciplina di ingegneria del software (requisiti, analisi e progettazione, manutenzione, etc.) modelli (linguaggi di modellazione) trasformazioni (linguaggio e tipo di trasformazione) linguaggi di meta-modellazione (tecnologie per definire linguaggi di modellazione) dominio applicativo strumenti supportati dall approccio 8

9 Un possibile modo di rappresentare i vari approcci MD che ci permette di meglio comprenderli e discuterne le caratteristiche è fornito dalla Figura 1. In particolar modo : MDE : il Model-Driven Engineering è l approccio più astratto nella gerarchia. Esso considera i modelli come artefatti fondamentali non solo per la documentazione ma anche per tutte le altre discipline ingegneristiche e in più domini applicativi. Alcune tra le iniziative più note del MDE sono il MDA dell OMG, il MDD, il MDT. Ad esempio, in quest ultima iniziativa (Model-Driven Testing) rientra il PBGT, ossia un approccio che fornisce strategie di test generiche. Affiché questo possa essere realizzato concretamente, PBGT è supportato dall omonimo tool disponibile come plugin Eclipse sotto Eclipse Modeling Framework. MDD : il Model-Driven Development si focalizza su discipline ingegneristiche come l analisi, la progettazione, l implementazione e definisce linguaggi di 9

10 modellazione per specificare il sistema sotto studio sotto diversi livelli di astrazione e per specificare le trasformazioni M2M e M2T per migliorare la qualità e la produttività del processo e del sistema software finale. Nella pratica, ad esempio, Web Service Software Factory è un approccio concreto MDD che fornisce risorse per costruire Web-Services più velocemente e consistenti. Un altro approccio concreto MDD è Silab MDD che si focalizza sulla disciplina dei requisiti, in particolar modo grazie all utilizzo di un particolare linguaggio noto con il nome di Silab Req permette di definire e gestire requisiti basati sulla specifica di use-cases. MDA : il Model-Driven Architecture è un iniziativa dell OMG (Object Management Group) che si focalizza su modelli a diversi livelli di astrazione e su trasformazioni di modelli differenti. Questo tipo di approccio permette quindi ad applicazioni sviluppate sotto MDA di essere indipendenti dalla piattaforma. Nonostante l iniziativa dell OMG sia ad un livello più basso della gerarchia rispetto al MDE e al MDD ancora non risulta essere un approccio concreto poichè non specifica linguaggi e strumenti di modellazione concreti. Tuttavia utilizza diverse specifiche OMG concrete come : - MOF (Meta-Object Facility), che è al centro dell architettura di metamodellazione - QVT (Query/View/Transformation), che è un insieme di linguaggi di trasformazione di modello. - UML profiles che permette di definire DSMLs grafici. EMP : Eclipse Modeling Project che si focalizza sull evoluzione e la promozione di tecnologie di sviluppo basate sul modello. Per fare ciò e in particolar modo per costruire modelli definiti sul meta-meta-modello Ecore coinvolge diversi tools e frameworks come : - EMF (Eclipse Modeling Framework), che è il cuore del framework di modellazione e che sviluppa vari tools come ATL, Acceleo e Sirius. - strumenti di modellazione testuale 10

11 - strumenti di modellazione grafica - strumenti per la generazione di codice In questo caso, un approccio concreto è fornito da XIS-mobile che permette di aumentare la produttività di sviluppo di applicazioni mobile grazie a un framework di supporto che permette di sviluppare applicazioni in quattro fasi separate così strutturate : - definizione delle viste richieste tramite Visual Editor - validazione delle viste tramite Model Validator - generazione dei modelli User-Interfaces Views con Model Generator - generazione del codice sorgente dell applicazione tramite Code Generator 11

12 Capitolo 2: Meta-modeling Nel seguente capitolo saranno presentate le nozioni fondamentali che sono alla base del Model-Driven. Fare chiarezza su nozioni come: sistema, modello, meta-modello, metameta-modello e linguaggio di modello è fondamentale per addentrarsi nel mondo Model- Driven. Per raggiungere quest obiettivo faremo ausilio sia di definizioni formali che di diagrammi illustrativi che meglio aiutano nella comprensione delle definizioni. Tutte le definizioni sono tratte dall articolo Model-driven engineering: A survey supported by the unified conceptual model pubblicato da Alberto Rodrigues Da Silva sul giornale Computer Languages, Systems & Structures. 2.1 Sistema Da Silva definisce sistema un concetto generico utilizzato per descrivere un applicazione, una piattaforma o un qualunque altro artefatto software. Esso può essere composto da altri sotto-sistemi e può avere relazioni con altri sistemi. La Figura 2.1 propone una vista di questa definizione. 2.2 Modello Da Silva definisce, invece, modello un astrazione di un sistema sotto studio che già 12

13 esiste o esisterà in futuro. Esso è spesso una rappresentazione parziale o semplificata del sistema sotto studio; per cui sono necessari modelli multipli per rappresentare, per capire e per descrivere il sistema originario. Inoltre, esso permette di condividere conoscenza e una visione comune tra gli esperti sviluppatori e offre una vista del sistema appropriata per controllarlo. In realtà un modello è esso stesso un sistema e in particolare quando utilizzeremo l espressione modello di un modello distingueremo il primo modello dal secondo sottolineando la differenza tra sistema e sistema sotto studio. La Figura 2.2 illustra la definizione di modello. Si noti che la definizione di modello dovrebbe includere tutto ciò che è utile ma non dovrebbe essere così ampia da diventare inutile, cioè tanto da perdere la sua proprietà discriminatoria. Allo stesso modo bisognerebbe evitare di considerare modello anche ciò che non è un modello. Da questo punto di vista un aiuto è dato dalla stesura delle caratteristiche discriminatorie che ci aiutano a distinguere se un artefatto può essere considerato o meno un modello. Da Silva specifica che affinché un artefatto possa essere considerato modello deve avere le seguenti caratteristiche : Mapping feature: un modello è una rappresentazione di un particolare fenomeno o oggetto del sistema originario Reduction feature: un modello è una versione semplificata del sistema originario, cioè ne riflette solo una parte. Pragmatic feature: un modello è utilizzato al posto del sistema originario per il raggiungimento di uno scopo. 13

14 In generale i modelli possono essere descrittivi o prescrittivi. I modelli descrittivi catturano conoscenza, si pensi ad esempio alla loro applicazione durante l analisi dei requisiti e l analisi del dominio. I modelli prescrittivi, invece, sono modelli di specifica per la progettazione e l implementazione del sistema. Si noti che un modello utilizzato come specifica per la costruzione di un sistema non rispetta il mapping feature in quanto il sistema che vogliamo costruire a partire dalla specifica di costruzione (modello) ancora non esiste, per cui il modello non può essere una mappatura del sistema originario. Tuttavia, li considereremo ancora modelli in quanto essi mappano precisamente il sistema che rappresenteranno, una volta che quest ultimo sarà costruito. Thomas Kuhne nell articolo Matters of (meta-) modeling pubblicato su Softw Syst Model descrive chiaramente sotto quali condizioni una trasformazione tra modelli possa essere considerata essa stessa un modello. In particolare essa è un modello se la si considera come funzione di trasformazione, cioè come schema di mappatura in termini di linguaggio di modellazione, in quanto essa si riferisce a una trasformazione originaria (i collegamenti di mappatura reali tra i modelli origine e destinazione reali). Se invece si considera la trasformazione come qualcosa che si riferisce ai singoli legami di mappatura tra modelli origine e destinazione, allora essa non comportando più alcuna riduzione non può più essere considerata modello. Per lo stesso motivo secondo Kuhne, una copia esatta non può essere considerata modello in quanto non comporta alcuna riduzione, cioè nessun vantaggio sui costi o inaccuratezza rispetto all originale. In poche parole: Token model Un token model è un modello che cattura aspetti particolari (cioè proprietà individuali) degli elementi del sistema originario. Quando si utilizza UML, gli object diagrams sono 14

15 esempi di token model in quanto catturano i valori degli attributi dei singoli elementi del sistema. Data questa loro caratteristica, gli elementi di un token model risultano essere designatori di un sottoinsieme di elementi del sistema originario, motivo per cui diremo che la relazione che vi è tra un token model e il sistema modellato è di tipo transitiva. Altri possibili nomi per un token model sono: - Snapshot model: in quanto catturano una singola configurazione di un sistema dinamico - Modello di istanza: poiché gli elementi di un token model sono istanze di tipi - Modello singolare: poiché gli elementi di un token model designano individui piuttosto che universali Type model Un type model è un modello che descrive un sistema complesso in modo conciso. Per questo motivo i type models risultano essere più economici rispetto ai token models. Un type model cattura aspetti universali degli elementi di un sistema originario (cioè cattura solo i tipi e le loro associazioni ma non gli elementi particolari e i loro collegamenti) per via della classificazione. La classificazione, come il nome suggerisce, classifica sotto un unico tipo elementi considerati equivalenti rispetto a specificate proprietà. I type models sono quindi creati per via di una classificazione motivo per cui diremo che un token model è un istanza di un type model. Con riferimento ad UML, un esempio di type model è il class diagram. Altri possibili nomi per un type model sono: - Schema model - Classification model - Universal model 2.3 Meta-modello La parola meta-modello ha origine dall unione della parola modello con un prefisso ad esso anteposto costituito dal termine meta. 15

16 Il prefisso meta viene utilizzato per indicare che l operazione che segue è compiuta due volte. Tipicamente poi si aggiunge un ulteriore meta per ogni ulteriore applicazione di quell operazione. Il termine meta-modello vuole quindi indicare che l applicazione di modellazione è applicata due volte. Un meta-modello è quindi un modello di modelli o equivalentemente diremo che un modello è un istanza linguistica di un meta-modello (nel senso che la sua forma rispetta delle regole fissate dal meta-modello). In effetti un meta-modello, secondo Da Silva, è un modello che definisce la struttura di un linguaggio di modellazione e i modelli che sono conformi ad esso costituiscono gli elementi dell insieme di tutte frasi che possono essere generate da questo linguaggio. Quanto detto è ben rappresentato nella Figura 2.3. Abbiamo detto che un meta-modello è un modello di un linguaggio di modellazione; ciò vuol dire che ci deve essere un meta-meta-modello che descrive il linguaggio di modellazione a cui il meta-modello è conforme e così via. Una soluzione adottata anche da OMG è di definire un meta-meta-modello MOF che descrive sé stesso nel suo proprio linguaggio. Un esempio di questa idea, lontano dal mondo della programmazione, è dato dal linguaggio inglese che descrive sé stesso in inglese al livello della definizione della grammatica. La Figura 2.4 illustra bene questa idea. 16

17 In definitiva un linguaggio di definizione può essere considerato modello per la sua capacità di essere un type model per tutti i modelli esprimibili con esso, quindi per la sua capacità di classificare istanze linguistiche. 2.4 Linguaggio di modellazione Da Silva descrive un linguaggio di modellazione come un insieme di modelli tutti conformi alla sintassi astratta del linguaggio di modellazione stesso. La sintassi astratta è rappresentata da una o più sintassi concrete e soddisfa una data semantica. Ciò che tipicamente si fa per definire un linguaggio di modellazione è prima di tutto identificare i concetti e le relazioni che esistono tra questi ultimi attraverso un processo di astrazione del sistema. Il risultato di questo sforzo è la sintassi astratta, o in altri termini, il meta-modello. La sintassi astratta è composta da una semantica strutturale che definisce le regole che esistono tra gli elementi del sistema. Queste regole possono essere definite attraverso un linguaggio dichiarativo di vincoli come OCL (Object Constraint Language), attraverso una specifica informale in linguaggio naturale o con un approccio combinato. La definizione delle regole permette agli utenti di evitare di creare modelli inconsistenti, tuttavia per raggiungere questo obiettivo vi è bisogno anche di un tool di supporto appropriato. La definizione della sintassi astratta dei linguaggi di modellazione avviene tipicamente tramite tecniche di meta-modellazione (es. UML profile mechanism, MOF language). 17

18 Questo processo è il corrispettivo delle grammatiche per i linguaggi naturali e delle notazioni BNF (Backus-Naur Form) per i linguaggi di programmazione. Una sintassi concreta specifica invece il modo in cui gli utenti impareranno e useranno il linguaggio di modellazione. Essa dovrebbe essere semplice ed espressiva con riferimento alla leggibilità, all efficacia, alla writability e alla learnability. Inoltre la sintassi concreta può definire notazioni: - grafiche: con l intento di illustrare relazioni tra concetti, sequenze temporali e casuali, e flussi dati e di controllo. - testuali: che permettono di scrivere e visualizzare espressioni logiche - tabellari La semantica di un linguaggio di modellazione specifica invece il significato dei costrutti del linguaggio. Infine, la pragmatica del linguaggio di modellazione guida gli utenti nell utilizzo del linguaggio nella maniera più appropriata. In particolare la pragmatica può riferirsi ad aspetti pratici dell utilizzo del linguaggio di modellazione, si pensi ad esempio ai vantaggi dovuti alla generazione automaticamente di codice o ai vantaggi dell integrazione del linguaggio con altri strumenti di sviluppo. Uno schema riassuntivo di quanto detto è proposto dalla Figura

19 2.4.1 Classificazione dei linguaggi di modellazione I linguaggi di modellazione possono essere classificati: in base al dominio applicativo in base al/ai punto/i di vista forniti Nel primo caso essi si dividono in GPMLs (General Purpose Modeling Languages) e in DSMLs (Domain Specific Modeling Languages). I GPMLs hanno molti costrutti generici per specificare e documentare più domini applicativi (es. UML). I DSMLs hanno invece pochi costrutti che risultano essere specifici di un solo dominio per volta. Da questo punto di vista i DSMLs hanno dei vantaggi rispetto ai GPMLs in termini di produttività, manutenibilità, portabilità, validazione, e inoltre facilitano la comunicazione tra gli sviluppatori. Tuttavia essi presentano anche degli svantaggi; si pensi ad esempio al costo di apprendimento e al mantenimento di un ulteriore linguaggio e alla necessità di un tool di supporto ad hoc per svilupparlo. In base al/ai punto/i di vista invece i linguaggi di modellazione si distinguono: - in base al livello di astrazione (CIM, PIM, PSM, multipli) - in base alle proprietà prospettiche (statici, dinamici, multipli) Un modo per analizzare e per confrontare diversi linguaggi di modellazione può essere quello di valutare alcune caratteristiche rilevanti come la loro semplicità (ossia la definizione di pochi concetti e notazioni consistenti e semplici), la loro espressività e la loro usabilità. 19

20 Capitolo 3: Model Transformation Le trasformazioni di modello sono le operazioni di maggior rilievo che possono essere applicate ai modelli. Una trasformazione di modello è un modo per modificare e creare modelli in maniera automatica con lo scopo di: ridurre l astrazione dei modelli aggiungendo dettagli al fine di generare automaticamente codice eseguibile tradurre dati tra sorgenti di dati eterogenee poter sfruttare i vantaggi del reverse engineering applicare il refactoring (ossia modificare la struttura interna di porzioni di codice senza modificarne il comportamento esterno) Affinché sia possibile realizzare una trasformazione di modello è però necessario poter usufruire sia di un linguaggio di trasformazione di modello (es. ATL, Acceleo, QVT), o eventualmente di un linguaggio di programmazione general purpose; sia di un tool di supporto di qualità (es. ambiente di esecuzione basato sul framework Eclipse) che supporti i linguaggi di trasformazione per le attività di: - editing - compilazione - esecuzione - debugging 3.1 Pattern di trasformazione Le trasformazioni di modello seguono un pattern noto con il nome di pattern di 20

21 trasformazione di modello che è mostrato nella Figura 3. Dove: - MMa: rappresenta il meta-modello che definisce la sintassi astratta del linguaggio di modellazione a cui il modello Ma di ingresso alla trasformazione è conforme - MMb: rappresenta il meta-modello che definisce la sintassi astratta del linguaggio di modellazione a cui il modello Mb di uscita dalla trasformazione è conforme - MMt: rappresenta il meta-modello che definisce la sintassi astratta del linguaggio di trasformazione a cui il modello Tab (programma di trasformazione) è conforme 3.2 Classificazione delle trasformazioni di modello Esistono diversi modi di classificare le trasformazioni di modello. Una prima distinzione può essere fatta sulla base dell output generato da una trasformazione. In base a questo tipo di classificazione si distinguono trasformazioni M2M (Model to model transformation) e trasformazioni M2T (Model to text transformation). Un altra distinzione che pure può essere presa in considerazione si focalizza sul numero di modelli in ingresso e in uscita alla trasformazione. In particolar modo, l unico vincolo che deve sempre essere rispettato, è che in ingresso alla trasformazione ci sia sempre almeno un 21

22 modello. Questo vincolo non è presente invece in uscita; infatti possono esistere casi in cui a seguito di una trasformazione non viene generato nessun modello. In quel caso alla trasformazione viene dato il nome di analisi di modello o alternativamente di query di modello. Inoltre una trasformazione può essere endogena o esogena a seconda se essa rispettivamente a partire da uno o più modelli sorgente espressi in un linguaggio di modellazione genera o meno uno o più modelli destinazione espressi nello stesso linguaggio di modellazione. In ultimo, ma non di importanza, possiamo classificare le trasformazioni come unidirezionali o bidirezionali. Le trasformazioni unidirezionali sono caratterizzate dal fatto che il modello sorgente che è a sola lettura può essere navigato ma non modificato mentre il modello destinazione è a sola scrittura e non può essere navigato. In una trasformazione bidirezionale invece uno stesso tipo di modello può fungere sia da input che da output per quella data trasformazione. 3.3 ATL e QVT In questo paragrafo si vuole offrire un breve confronto tra i due principali linguaggi di trasformazione di modello che vanno sotto il nome di QVT e ATL. QVT (Query/View/Transformation) è un insieme di linguaggi di trasformazione di modello. Esso è uno standard OMG che permette non solo di definire le trasformazioni così come sono intese nel caso più generale, ma permette anche di definire casi particolari di trasformazioni come i model queries e i model views. Lo standard QVT definisce tre linguaggi di trasformazione di modello : - QVT-Operational - QVT-Relations - QVT-Core Tutti e tre questi linguaggi sono conformi al meta-meta-modello MOF (Meta-Object Facility). Inoltre, lo standard QVT integra ed estende lo standard OCL 2.0 con costrutti imperativi. 22

23 Tuttavia, nonostante QVT possa essere utilizzato in molti contesti in cui è richiesta una trasformazione di modello, esso non riesce a coprire tutti i contesti di trasformazione possibili in quanto i linguaggi QVT non permettono trasformazioni da o verso modelli testuali, per cui sono possibili solo trasformazioni M2M e non M2T. ATL è sia un linguaggio di trasformazione di modelli che un toolkit sviluppato da OBEO e AtlanMod (prima meglio conosciuto come ATLAS Group) ed è un componente M2M che fa parte del più ampio EMP (Eclipse Modeling Project). ATL nasce come risposta a QVT dell OMG da cui prende in prestito molte caratteristiche principali. In effetti ATL permette solo trasformazioni M2M allo stesso modo di QVT, è inoltre un linguaggio ibrido dichiarativo (utilizzando OCL come pure fa QVT) e imperativo così come QVT. Come risultato di tutto ciò ATL può essere applicato in tutti gli scenari di trasformazione QVT oltre che ad una più ampia gamma di scenari. 23

24 Capitolo 4: ATL (ATLAS Transformation Language) Come già accennato nel paragrafo 3.3 di questo elaborato ATL è un linguaggio di trasformazione di modelli. È un linguaggio che presenta sia costrutti dichiarativi che imperativi per definire trasformazioni M2M unidirezionali. Tipicamente quando ci si accinge a scrivere un programma di trasformazione di modelli si preferisce utilizzare i costrutti ATL di tipo dichiarativo in quanto si avvicinano di più al modo in cui la mente umana percepisce le relazioni tra modelli sorgente e modelli destinazione. Tuttavia in alcuni casi per realizzare una trasformazione è necessario poter usufruire anche di costrutti imperativi, e da questo punto di vista ATL non fa mancare il suo supporto. I modelli sorgente e destinazione di una trasformazione ATL possono essere espressi in formato di serializzazione XMI OMG, mentre i rispettivi meta-modelli possono essere espressi in XMI o KM Modulo ATL Una trasformazione ATL è definita in un modulo con estensione.atl. Un modulo ATL si compone di: - una sezione di intestazione (obbligatoria) - una sezione di importazione - helpers - regole di trasformazione 24

25 4.1.1 Sezione intestazione e sezione importazione La sezione di intestazione dà il nome al modulo ATL e dichiara i modelli sorgente e destinazione. Tipicamente è possibile specificare più modelli di origine e più modelli destinazione. Un esempio di una possibile sezione di intestazione per un modulo ATL è: dove OUT e IN specificano rispettivamente i modelli destinazione e sorgente, mentre Relational e Class sono i rispettivi meta-modelli. La sezione di importazione a differenza della sezione di intestazione non è obbligatoria Helpers Un helper può essere specificato su un tipo OCL o un tipo di metamodello di origine. Gli helpers si dividono in: - operation helpers: che definiscono operazioni nel contesto di un elemento di un modello o di un intero modulo; inoltre possono usare ricorsione e possono avere parametri di input - attribute helpers: che definiscono valori a sola lettura per gli elementi del modello sorgente; inoltre hanno un nome, un contesto e un tipo, possono essere definiti ricorsivamente e non hanno parametri di input. I valori di un operation helper sono specificati da un espressione OCL. Un esempio di un possibile operation helper è: Regole di trasformazione Le regole di trasformazione vengono utilizzate per esprimere la logica di trasformazione. Esse si dividono in: - matched rules: regole dichiarative composte da un source pattern, che specifica il tipo sorgente e una guardia, e da un target pattern che specifica un tipo 25

26 destinazione e delle associazioni, ossia delle caratteristiche (attributi, riferimenti) con i relativi valori di assegnazione. - called rules: regole imperative con un nome e con degli argomenti opzionali - action block: costrutto imperativo che consiste in una sequenza di frasi imperative che in ATL sono anche responsabili del flusso di controllo. Alle caratteristiche delle matched rules si fa corrispondere un link di tracciabilità verso il modello di origine. Un link di tracciabilità specifica una regola di corrispondenza tra i nuovi elementi creati nel modello destinazione e gli elementi nel modello di origine. L inizializzazione di una caratteristica in una matched rule avviene grazie all algoritmo di risoluzione ATL il quale lavora come specificato di seguito. Se il tipo ritornato da un espressione vincolante OCL è primitivo o è un elemento del modello destinazione esso è subito assegnato alla caratteristica, altrimenti se è un elemento del modello di origine viene prima risolto in un elemento del modello destinazione e poi assegnato alla caratteristica. Una regola può anche ereditare da una regola genitore, in quel caso la regola in questione prende il nome di sottoregola. Ciò che avviene quando una regola eredita da un altra regola è che: - la guardia della sottoregola forma una congiunzione con la guardia della regola genitore - il modello sorgente della sottoregola ha sottotipi che rimpiazzano i tipi nel modello origine della regola genitore - il modello destinazione della sottoregola può sottotipizzare i tipi nel modello destinazione del padre, rimpiazzare o aggiungere legami e aggiungere elementi nel modello destinazione del genitore. L ordine di esecuzione delle regole non è deterministico, tuttavia per un dato modello origine il modello destinazione generato è sempre lo stesso visto che i modelli sorgente sono a sola lettura e quelli destinazione a sola scrittura. 26

27 4.2 Eclipse ADT (Eclipse ATL Development Tools) ATL è accompagnato da tools costruiti sulla piattaforma Eclipse che vanno sotto il nome di ATL Development Tools. La Figura 4.1 ne mostra l architettura. Il blocco Engine rappresenta il motore di trasformazione che si occupa sia della compilazione in un tipo di byte-code specializzato che sarà poi eseguito dalla VM (Virtual Machine), che dell esecuzione di questo byte-code. I blocchi Editor Builder Debug costituiscono invece quello che prende il nome di IDE (Integrated Development Environment). Una rappresentazione più dettagliata del motore di esecuzione ATL è data dalla Figura 4.2. La figura specifica come in realtà ATL può funzionare su diversi sistemi di gestione di modello (cioè su diverse specifiche). Il Model Handler Abstraction Layer traduce le istruzioni per la manipolazione del modello della VM in istruzioni dell handler specifico; per cui permette di separare la VM dalle specifiche. Il Model Repository si occupa 27

28 dell archiviazione dei modelli e, nel caso particolare di Eclipse rappresenta il file system dello spazio di lavoro. Il formato XMI 2.0 rappresenta il formato dei modelli sorgente e destinazione quando si lavora sotto EMF. L editor ATL permette di evidenziare la sintassi, segnalare errori e inoltre offre una vista della struttura, ossia una rappresentazione ad albero del programma ATL. Il compilatore ATL è chiamato automaticamente su ogni file ATL presente in ogni progetto ATL ogni qual volta un file è modificato (salvato). Per poter eseguire una trasformazione è necessario impostare la configurazione di avvio dove vengono specificati i modelli e i meta-modelli sorgente e destinazione della trasformazione. Per finire, il blocco debug permette di visualizzare il valore delle variabili dinamicamente e inoltre, utilizzando la stessa configurazione di avvio, è possibile eseguire la trasformazione ATL sia passo dopo passo sia con modalità di esecuzione standard. Nel secondo caso l esecuzione viene interrotta quando viene raggiunto un breakpoint o si riscontra un errore. 28

29 Capitolo 5: Esempio di una trasformazione ATL L esercizio che si vuole presentare in questo capitolo finale rappresenta il raggiungimento dell obiettivo che avevamo fissato all inizio di questo elaborato (ossia introdurre il lettore alla conoscenza delle tecnologie, gli strumenti e i linguaggi a supporto delle trasformazioni tra modelli in ambiente Eclipse). Difatti, questo semplice esempio che sarà presentato di seguito rappresenta il concretizzarsi di tutto quello che si è detto nei capitoli precedenti ed è quindi anche un sunto del nostro lavoro. L esempio che viene proposto è quello di una trasformazione ATL in ambiente Eclipse di un modello conforme a un meta-modello FSM (Finite-State Machine) in un modello conforme a un meta-modello Petri Net. In realtà, come vedremo, prenderemo in considerazione una sottoclasse della più generale Petri Net. 5.1 Brevi cenni: Finite-State Machine e Petri Net In questo paragrafo si descrivono brevemente le caratteristiche delle FSMs e delle Petri Nets in quanto questo ci aiuterà a comprendere meglio l esercizio proposto FSM (Finite-State Machine) Un FSM è un automa che permette di descrivere in maniera formale il comportamento dinamico (ossia la caratteristica di evolvere nel tempo passando da uno stato all altro) di molti sistemi in cui l insieme d ingresso, di uscita e di stato sono finiti. Per definire in maniera formale un automa si necessita di un modello matematico formato da una quintupla: A = {S, I, U, f, g} 29

30 Dove: - S è l insieme degli stati - I è l insieme degli ingressi - U è l insieme delle uscite - f è la funzione di transizione che descrive il passaggio da uno stato al successivo - g è la funzione di uscita che specifica il valore delle uscite Tipicamente un automa può essere deterministico o non deterministico. Nel primo caso, in qualunque stato ci si trovi, per qualsiasi input, esisterà una e una sola transizione, mentre nel secondo caso almeno uno stato presenta più di una possibile computazione per determinati caratteri in ingresso. Un automa a stati finiti può essere rappresentato da una tabella di transizione o da un grafo orientato noto con il nome di grafo di transizione o di diagramma degli stati. Una tabella di transizione è una tabella che associa alle righe gli stati dell automa e alle colonne tutti i possibili ingressi. Gli elementi della matrice costituiscono il risultato dell applicazione della funzione di transizione. In un grafo di transizione, invece, i nodi rappresentano gli stati dell automa e gli archi le transizioni. Le transizioni sono etichettate con i relativi ingressi che generano la transizione. Un ultima considerazione che vale la pena fare sugli automi a stati finiti è che questi si distinguono in automi di Moore e automi di Mealy a seconda se l uscita dipende solo dallo stato o anche dall ingresso Petri Net Una rete di Petri, nota anche con il nome di place/transition net, è una delle possibili rappresentazioni matematiche che si può utilizzare per descrivere un sistema distribuito discreto. Essa è costituita da nodi (places, transitions) e da archi. Esiste un vincolo particolare nelle reti di Petri, infatti, è possibile definire archi tra places e transitions e tra transitions e places ma non è possibile definire archi tra places e places e tra transitions e transitions. 30

31 I places possono contenere un certo numero di token e questi sono fondamentali per stabilire se una transition successiva può o meno essere abilitata. In particolare, se la transizione scatta essa consuma token dai suoi places di ingresso e posiziona un numero specificato di token nei places di uscita. Una caratteristica che vale la pena sottolineare delle reti di Petri è che la loro esecuzione è non deterministica, questo vuol dire che se più transizioni sono abilitate nello stesso momento, una qualsiasi di esse può scattare e inoltre non è affatto garantito che una transizione abilitata scatti. Questa caratteristica di rilievo nelle reti di Petri le rende adatte a modellare il comportamento dei sistemi concorrenti. 5.2 L esempio proposto: Da State Machine a Petri Net Come accennato all inizio di questo capitolo prenderemo in considerazione nel nostro esempio un caso particolare di rete di Petri, noto come il nome di state machine, in cui ogni transizione ha un solo arco entrante e un solo arco uscente. Questo vincolo si traduce nel fatto che nella nostra rete non c è concorrenza ma è possibile invece che ci sia conflitto in termini di scelta di dove indirizzare un particolare token di un dato place. Lo schema di trasformazione che terremo in considerazione è quello proposto in Figura 5.1. I meta-modelli di ingresso e di uscita sono quindi definiti in StateMachine.ecore e PetriNet.ecore. Nella Figura 5.2 viene proposta la loro implementazione sulla piattaforma Eclipse. 31

32 Nel file StateMachine.xmi proposto in Figura 5.3 è invece rappresentato il modello di un distributore automatico di caramelle dal costo di 15 e 20 e che accetta monete dal valore di 5 e 10. Per meglio comprendere il file formato xmi si propone di seguito il grafo di transizione corrispondente. Si noti che si è deciso di proporre due rappresentazioni dello stesso grafo di transizione ognuna delle quali focalizza l attenzione su un determinato aspetto del grafo. Si è deciso di optare per questa scelta onde evitare di sovraffollare il grafo e di conseguenza rendere inutili le sue proprietà chiarificatorie. In particolare la prima rappresentazione esplicita gli stati e le transizioni mentre la seconda rappresentazione si concentra sul loro significato, Figura

33 Il file StateMachine2PetriNet.atl rappresenta il nostro modello di trasformazione che a partire dal file StateMachine.xmi genera automaticamente il file PetriNet.xmi. La relativa implementazione sulla piattaforma Eclipse è fornita di seguito: 33

34 Come conseguenza della trasformazione viene generato il modello PetriNet.xmi presentato in Figura 5.5: Per una maggiore comprensione del file PetriNet.xmi si propone la visualizzazione grafica della Petri Net corrispondente. Anche in questo caso si propongono due rappresentazioni della stessa Petri Net. La prima rappresentazione esplicita i places, le transitions e gli archi 34

35 mentre la seconda rappresentazione si concentra sul loro significato, Figura

36 Conclusioni In definitiva possiamo dire che l approccio del MDE ha portato grossi vantaggi nel mondo dello sviluppo software e ad oggi risulta essenziale utilizzare approcci tipici del MDE se si vuole sviluppare software corretto in minor tempo e con minor costo. I modelli sono essenziali sia come documentazione che come artefatti per la generazione automatica di codice. Tuttavia c è ancora parecchia strada da fare per poter risolvere questioni come: - l applicazione degli approcci MDE a sistemi complessi - la raccolta di materiale tecnico e solido sulle tecnologie MDE - la valutazione dei benefici effettivi del MDE - la valutazione delle aree dove l aiuto del MDE può essere migliorato Ad esempio si può migliorare il debug al livello di modellazione, si possono sviluppare altre rappresentazioni di modelli, si può tentare di automatizzare la specifica e la sintesi delle trasformazioni di modelli e delle proprietà QoS per semplificare l evoluzione di modelli e metamodelli e si può migliorare il supporto in settori come l ingegneria della concorrenza. Da questo punto di vista, l esempio che si è sviluppato può essere aggiunto all ATL Transformations Zoo, ossia una raccolta di trasformazioni ATL attualmente composta da 103 scenari di trasformazioni di modello, per poter essere parte integrante di quella raccolta di materiale sulle tecnologie MDE di cui si necessita per poter comprendere sempre meglio questi tipi di approcci. 36

37 Bibliografia [1] Douglas C. Schmidt, Model-Driven Engineering, IEEE Computer Society, Febbraio 2006 [2] Alberto Rodrigues da Silva, Model-driven engineering: A survey supported by the unified conceptual model, Computer Languages, Systems & Structures, 43, , 2015 [3] Thomas Kuhne, Matters of (meta-) modeling, Softw Syst Model, 5, , 2006 [4] Wikipedia, 29 Maggio 2018 [5] Wikipedia, 6 Agosto 2017 [6] Wikipedia, 7 Aprile 2018 [7] Frédéric Jouault, Freddy Allilaire, Jean Bézivin, Ivan Kurtev, ATL: A model transformation tool, Science of Computer Programming, 72, 31-39, 2008 [8] Wikipedia, 19 Settembre 2017 [9] Eclipse, [10] Eclipse, 18 Settembre 2012 [11] Eclipse, [12] Wikipedia, 1 Novembre 2017 [13] Eclipse, [14] Eclipse, [15] Wikipedia, 23 Marzo 2018 [16] Dacrema, [17] Wikipedia, 7 Maggio 2018 [18] R. Pais, L. Gomes, J. P. Barros, Towards Statecharts to Input-Output Place Transition Nets Transformations [19] Wikipedia, 23 Marzo 2018 [20] Tadao Murata, Petri Nets: Properties, Analysis and Applications [21] Eclipse, et[v00.01].pdf, 18 Luglio