Scuola Politecnica e delle Scienze di BaseCorso di Laurea in Ingegneria Informatica

Elaborato finale in Programmazione I

Analisi e differenti approcci alle

trasformazioni di modelli

Anno accademico 2017/2018

Candidato Angelo Delicato

matr. N46002831

1

A chi crede in me.

2

Indice

Introduzione 4

Capitolo 1: Model-driven engineering, modelli e metamodelli 5

I modelli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

I metamodelli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

La gerarchia a 4 livelli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Metamodeling: esempio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Capitolo 2: Trasformazioni di modelli e linguaggi di trasformazione 11

Trasformazioni di modelli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Lo standard OMG: QVT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

ATL: ATLAS Transformation Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Kermeta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Capitolo 3: Trasformazione in ATL e Python 21

Metamodello OrariCorsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Metamodello OrariDocenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Obiettivo della trasformazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

La trasformazione in ATL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

La trasformazione in Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Conclusioni 31

Bibliografia 32

3

Introduzione

In ambito informatico e, piu in generale, in quello ingegneristico e sempre necessare adottare un

approccio che permetta di affrontare con sistematicita i problemi piu complessi.

Una delle grandi difficolta risiede nel dover lavorare con una grande mole di dati che sono, di nor-

ma, di tipo eterogeneo. Con il dilagare della Rete, inoltre, tale problematica diviene ancora piu

pressante. Nasce quindi l’esigenza di trovare soluzioni che possano ovviare a tale problematica,

nasce l’ingegneria guidata dal modello (a cui d’ora in poi ci si riferira con la terminologia inglese

Model-driven engineering, di norma abbreviato in MDE. Attraverso tale metodologia di sviluppo

e possibile lavorare ad un livello di astrazione piu elevato, facilitando il lavoro e migliorando l’effi-

cienza. Tale elaborato ha lo scopo di mettere in luce gli aspetti piu salienti e differenti approcci alle

trasformazioni di modelli, che costituiscono una parte fondamentale del MDE. Nel primo capitolo

vengono introdotti, oltre al gia citato MDE, i modelli e i metamodelli con tutte le loro caratteristi-

che piu importanti.

Nel secondo capitolo vengono presentate le trasformazioni di modelli e, in particolare, vengono

mostrati alcuni linguaggi di trasformazione di modelli quali QVT (lo standard OMG), ATL e

Kermeta. Vengono inoltre messe in evidenza le principali differenze che intercorrono tra questi

linguaggi.

Nel terzo capitolo vengono realizzati due metamodelli specifici con la relativa istanziazione di un

modello (sorgente) e viene eseguita una trasformazione tra modelli utilizzando prima il linguaggio

ATL e, successivamente, viene effettuata la stessa trasformazione utilizzando un linguaggio di pro-

grammazione tradizionale (Python) attraverso l’aiuto di un particolare framework realizzato dalla

community di sviluppatori.

Nel capitolo conclusivo vengono espresse delle considerazioni riguardanti tale metodologia di

sviluppo software.

4

Capitolo 1: Model-driven engineering, modelli e metamodelli

L’utilizzo di astrazioni e sempre stato un approccio utilizzato dagli sviluppatori nella realizzazione

di soluzioni software. Tali astrazioni, pero, sono effettuate nel ”dominio della soluzione”. E’ neces-

sario, dunque, un modo per innalzare ulteriormente il livello di astrazione per poter rappresentare

non la soluzione, bensı il problema stesso in termini astratti [7]

Nasce in questo modo l’MDE il quale permette di definire:

• Dei linguaggi di modellazione per poter formalizzare strutture, comportamenti e requisiti

all’interno di un determinato problema specifico. Tali linguaggi si avvalgono, pertanto, di

metamodelli, i quali sono introdotti nelle pagine successive

• Linguaggi di trasformazione e generatori per poter manipolare istanze di determinati modelli

e generare diverse rappresentazioni di un modello o, addirittura, del codice sorgente.

I modelli

Un modello e una rappresentazione esplicita di fenomeni nel mondo reale dal punto di vista di

coloro che vogliono esplorare, trasformare quella specifica parte del mondo reale. Quando si va a

realizzare un modello la cosa fondamentale e definire lo scopo di tale modello, dunque e necessa-

rio capire a quali domande si vuole andare a rispondere tramite l’ausilio del modello in questione.

Inoltre e fondamentale definire dei ”confini”, cioe e necessario concentrarsi solo sulla parte che

veramente e di nostro interesse, disinteressandosi di tutto il resto. Dopodiche e necessario identifi-

care i concetti rilevanti e analizzare quali sono le relazioni che intercorrono tra di essi. Realizzare

un modello non e un processo lineare, ma molto spesso richiede di iterare questi passaggi prima di

poter ottenere un modello che sia adatto alle nostre esigenze.

E’ importante notare che i modelli non sono ne giusti ne sbagliati [8], ma che possono solamen-

te essere piu o meno adatti per quanto riguarda il loro scopo e possono pero essere incosistenti

riguardo la loro rappresentazione.

5

I metamodelli

Un metamodello e esso stesso un modello che viene utilizzato per descrivere un altro modello

utilizzando un linguaggio di modellazione. Il prefisso meta deriva dal greco e significa ”dopo,

oltre”; ma in questo caso la situazione e relativa perche un modello puo essere sia un modello o

un metamodello. Dunque un metamodello e semplicemente un modello ad un differente livello

di astrazione che ci permette di fare dichiarazioni riguardanti la struttura di un altro modello (o

un intero set di modelli) senza interessarsi del contenuto. Il modello dovra essere conforme al suo

metamodello alla stessa maniera in cui un programma per computer e conforme alla grammatica

del linguaggio di programmazione in cui e scritto [9]. Ci sono vari benefici nell’ausilio di un

metamodello:

• Ci si assicura che tutti utilizzino il linguaggio di modellazione in maniera consistente.

• Utilizzare un metamodello permette di utilizzare degli algoritmi per verificare la correttezza

del modello.

• Si ha un alto grado di disaccoppiamento. In questo modo un metamodello potrebbe risultare

utile in situazioni totalmente differenti.

Ricapitolando: un metamodello e una tipologia speciale di modello che specifica al sintassi astrat-

ta di un linguaggio di modellazione.

La gerarchia a 4 livelli

Ma a cosa si conforma un metamodello?

Un metamodello, semplicemente, si conforma ad un meta-metamodello. Teoricamente potremmo

iterare questo processo all’infinito poiche un metamodello puo essere sia un modello che un me-

tamodello in base alla prospettiva da cui lo si guarda. Lo standard adottato da OMG per risolvere

i problemi legati all’eterogeneita della immensa quantita di dati che vengono scambiati al giorno

d’oggi e MOF (Meta Object Facility [3]. Tale standard definisce 4 layer:

6

Il livello M0 e quello piu in basso e contiene le istanze run-time degli elementi del modello (quello

definito al livello M1).

Un modello e un’istanza di un metamodello. Un modello rappresenta il sistema al livello M1 e si

conforma ad un linguaggio la cui sintassi astratta e rappresentata nel livello soprastante. Per questo

motivo si puo dire che il modello si conforma al metamodello.

7

Allo stesso modo il metamodello si conforma ad un linguaggio la cui sintassi astratta e rappresenta-

ta nel livello soprastante. Quindi si puo dire che il metamodello si conforma al meta-metamodello.

La responsabilita principale di un metamodello e definire il linguaggio per specificare i modelli.

UML e OMG CWM sono esempi di metamodelli.

8

A terminare la gerarchia vi e il meta-metamodello che e riflessivo e pertanto si conforma ad un

linguaggio la cui sintassi astratta e rappresentata da se stesso; questo e il livello M3. Di norma un

meta-metamodello e piu compatto rispetto ad un metamodello e spesso e possibile che piu di un

metamodello si conformi ad esso.

Vi e, infine, la versione di Bezivin che raggruppa diversamente la gerarchia realizzando un 3+1

in cui il sistema e rappresentato dal layer M0 mentre i tre restanti corrispondono alla rappresenta-

zione di tale sistema [6]

9

Metamodeling: esempio

Di seguito e presentato un banalissimo esempio che mostra la relazione che intercorre tra un mo-

dello e il suo metamodello. Il compito primario di un metamodello e quello di definire la semantica

del modello che si andra ad istanziare.

Nella figura soprastante vi sono le due metaclassi Class e Association che sono entrambe definite

come parte del metamodello UML. Le classi Studente e Corso di Laurea sono entrambi istanze

della metaclasse Class e l’associazione tra Studente e Corso di Laurea e un’istanza della meta-

classe Association. Di seguito un’immagine che esplica la differenza sostanziale tra un modello e

una sua particolare istanza.

10

Capitolo 2: Trasformazioni di modelli e linguaggi di trasformazione

In questo capitolo verranno introdotte le trasformazioni di modelli e alcuni dei linguaggi di trasfor-

mazione di modelli (lo standard QVT, ATL, Kermeta).

Trasformazioni di modelli

Lo scopo e quello di generare un nuovo modello, definito modello target, a partire da un modello di

partenza, definito modello source, seguendo delle regole definite formalmente. Perche si effettuano

tali trasformazioni?

• Potrebbe capitare di dover estrarre un particolare subset dal modello sorgente (in pratica e

come se si eseguisse una query sul modello sorgente).

• Generare un nuovo modello che si conforma ad un altro metamodello che sia in qualche modo

”equivalente” al modello di partenza.

• Rappresentare il modello sorgente da un diverso punto di vista.

L’esempio basilare (che puo essere considerato l’Hello World del Model-driven engineering):

Family 2 Person. Si realizza, pertanto, una trasformazione che a partire da una lista di famiglie

realizza una lista di persone. Il metamodello di una famiglia e il seguente:

Ogni famiglia ha un cognome ed e costituita da un padre, una madre e un numero variabile di

figli/figlie (0,1 oppure n), tutti con un nome. Il metamodello di una personae, invece, il seguente:

11

Ogni persona e composta da un Nome + Cognome (fullName) e puo essere un Maschio oppure una

Femmina. Dunque tale trasformazione vuole realizzare, a partire da una lista di famiglie, una lista

di persone. E’ dunque necessario ricavare per ogni membro della famiglia il cognome e eliminare

qualsiasi tipo di associazione tra membri appartenenti alla stessa famiglia. Di seguito uno schema

riassuntivo delle trasformazioni tra modelli:

E’ possibile, inoltre, realizzare dei modelli che siano indipendenti dalla specifica implementazione.

Si ha il seguente schema concettuale:

12

Il PIM (platform independent model e, appunto, un modello che non contiene informazioni spe-

cifiche riguardanti la piattaforma di implementazione. Il PSM (platform specific model, d’altra

parte, e il modello realizzato per la specifica implementazione (ad esempio Java oppure C++). Si

ha, quindi, che per un singolo PIM possono esserci piu PSM. Una trasformazione di modelli,

quindi, e un’operazione che permette di ottenere un PSM a partire da un PIM.Tale trasformazione

ingloba in se tutte le regole necessarie per poter effettuare l’operazione; infatti all’interno della tra-

sformazione sono definite tutte le regole che permettono di tradurre i costrutti del PIM in quelli del

PSM. Oltre a poter generare dei PSM a partire da PIM (model to model transformation) e possibile

trasformare anche un PSM in codice sorgente oppure generarne la documentazione (model to text

transformation).

I linguaggi di trasformazione di modelli possono seguire due tipi di paradigmi di programmazione:

relazionale (cioe dichiarativo) oppure operazionale (imperativo).

Il paradigma relazionale (dichiarativo) permette di esprimere un entita in termini di somiglianza

con un’altra; non viene pero descritto il modo in cui questa somiglianza viene implementata. Nello

specifico caso delle trasformazioni di modelli si esprime solamente quali sono le relazioni tra il

modello sorgente e il modello target.

Il paradigma operazionale (imperativo) e quello piu diffuso nella totalita dei linguaggi di program-

13

mazione tradizionali, esso permete di esprimere come un’entita debba essere realizzata. Nel caso

delle trasformazioni di modelli si esprime il modo in cui il modello target debba essere modificato

in relazione al modello sorgente.

Lo standard OMG: QVT

QVT (Query/View/Transformation) rappresenta lo standard OMG per le trasformazioni di mo-

delli; esso e nato nel 2001 ed la sua versione 1.1 e stata rilasciata nel 2011 [5]. Tale standard

presenta la seguente architettura:

Come e facilmente intuibile dal nome, QVT specifica un linguaggio per:

• eseguire query

• estrapolare viste

• realizzare trasformazioni

Essendo QVT uno standard, esso implementa entrambi i paradigmi di programmazione.

Quello dichiarativo e rappresentato dalle entita Relations, Core e Relations2Core transforma-

tion.

Relations e un metamodello che, tra le caratteristiche salienti, permette di realizzare dei matching

con altri metamodelli implementando la Traceability, cioe la presenza di strutture che mettono in

relazione gli elementi del modello sorgente con quelli del modello target.

Core e. invece, un modello che, in linea di massima, permette di eseguire le stesse operazioni di

Relations. La differenza tra Relations e Core risiede nel grado di astrazione (non a caso il primo

e un metamodello, mentre il secondo un modello), infatti il linguaggio di Core e piu ristretto e,

14

dunque, necessita di utilizzare delle definizioni piu complesse rispetto a Core. Tale gap semantico

e colmato da Relations2Core transformation.

Il paradigma operazionale e rappresentato dai due blocchi esterni: Operational Mappings e Black

Box. Il paradigma imperativo e necessario poiche in alcune situazioni non e possibile esprimere una

trasformazione utilizzando solamente costrutti dichiarativi (nel MDE, pero, si tende ad utilizzare

tale paradigma solamente quando strettamente necessario).

QVT permette, inoltre, di eseguire trasformazioni bidirezionali, modificando sia il modello sorgen-

te che quello target. Dal punto di vista dell’organizzazione QVT permette di definire le trasforma-

zioni in moduli (proprieta di modularita) e permette di godere della riusabilita del codice attraverso

l’ereditarieta.

Una trasformazione QVT permette di generare dei nuovi modelli a partire da un modello sorgente

(quindi non solamente di modificare un modello target gia esistente). Nel caso in cui il modello tar-

get sia gia esistente viene effettuato un update con cancellazione, cioe tutte le entita del modello

target che non presentanto corrispondenze nel modello sorgente vengono scartate. Di seguito una

tabella riepilogativa delle caratterstiche appena presentate:

ATL: ATLAS Transformation Language

ATL e un linguaggio di trasformazione di modelli sviluppato da INRIA e utilizzato principalmente

all’interno dell’EMF (Eclipse Modeling Framework). Anch’esso, come lo standard QVT, mette a

disposizione entrambi i paradigmi di programmazione.

Oltre alle citate trasformazioni M2M, ATL permette anche di trasformare un modello in istanze di

tipi primitivi attraverso l’ausilio delle ATL Queries, ma tale argomento non e di nostro interesse al

momento. Infine, il linguaggio ATL permette anche di creare librerie indipendenti e di riutilizzarle

in piu unita ATL differenti.

15

Una trasformazione M2M viene realizzata attraverso un’unita ATL Module. Tale unita permette

allo sviluppatore di definire in che modo devono essere generati i modelli target a partire da quelli

sorgente; ogni modello che prende parte a tale trasformazione deve, ovviamente, conformarsi al

rispettivo metamodello.

Da cosa e composto un ATL Module? Un singolo modulo ATL e costituito da 4 elementi primitivi:

• Una sezione header iniziale in cui vengono specificati alcuni attributi come il nome del modu-

lo (che, come accade in Java, deve essere uguale al nome del file), i moduli in ingresso/uscita

e il tipo di esecuzione della trasformazione. E’ possibile, infatti, scegliere tra due modalita

di esecuzione: normal oppure refining. La prima tipologia e quella che viene utilizzata in

genere per creare dei modelli target che differiscono da quelli sorgente. La seconda, invece, e

pensata appositamente per trasformazioni in cui il modello sorgente e target sono molto simili

(refining transformation). Utilizzando tale modalita, infatti, e necessario definire solamente

gli elementi del modello che andranno trasformati; la parte restante verra ricopiata nel model-

lo target senza subire variazioni. In ATL entrambi i modelli devono conformarsi allo stesso

metamodello.

• Una sezione (opzionale) in cui e possibile importare una o piu librerie tramite la keyword uses

nomelibreria;.

• Un insieme di rules che definiscono come verranno generati i modelli target. ATL fornisce tre

tipologie di rules:matched rules, lazy rules e called rules.

Le matched rules costituiscono la parte dichiarativa di una trasformazione ATL. Esse sono

costituite da due sezioni obbligatorie e due opzionali. Nelle sezioni obbligatorie e necessario

inserire quali sono gli elementi target e quelli sorgente; siccome molto spesso e di interesse

performare la trasformazione su un particolare sottoinsieme di elementi che si conformano ad

un metamodello e possibile specificare delle condizioni che devono essere soddisfatte dagli

elemeneti su cui verra effettuata la trasformazione. Nella sezione relativa al target, invece,

viene definito in quale modo dovra essere generato il modello in uscita. La prima sezione

opzionale permette, invece, di aggiungere delle variabili locali alla regola. La seconda (opzio-

nale), invece, e quella che permette di inserire del codice imperativo che verra eseguito dopo

la generazione dei modelli target.

16

Le lazy rules sono simili in tutto e per tutto alle matched rules, l’unica cosa che le differenzia

e che tali regole vengono eseguite solamente quando richiamate da un’altra regola.

Le called rules permettono di implementare del codice imperativo. Tali regole accettano pa-

rametri in ingresso e sono costituite da tre sezioni (che, tra l’altro, sono tutte opzionali): una

sezione target, una sezione per il codice imperativo e una per le variabili locali. Tali rules,

infatti, permettono di generare dei modelli target a partire dai dati ingresso e dalle variabili

locali (eventualmente); questo perche e assente la sezione dedicata al modello sorgente da

cui estrapolare informazioni. La sezione imperativa, infine, permette di eseguire dell’ulteriore

codice imperativo contenuto in un’altra called rule. Questa tipologia di regole viene eseguita

solamente se richiamata nella sezione imperativa di una matched rule o in quella di un’altra

called rule.

• Un insieme di helpers che e il corrispettivo in ATL dei metodi Java. La caratteristica peculiare

di tali helper e che devono necessariamente avere un tipo di ritorno e un contesto in cui essere

definiti. E’ possibile fare un’analogia tra il contesto e l’appartenenza di un metodo ad una

specifica classe. Gli helper accettano anche parametri in ingressi, ma essi sono opzionali. E’

possibile poi definire dei particolari helper, gli attributi, che sono in tutto e per tutto degli

helper, ma senza parametri in ingresso. Il guadagno nell’utilizzare gli attributi al posto degli

helper con zero parametri in ingresso e che tali attributi vengono eseguiti solamente quando

richiamati la prima volta, mentre gli helper vengono rieseguiti ad ogni chiamata [1].

Le sopracitate caratteristiche di ATL implementano funzionalita che sono espresse anche dallo

standard QVT presentato in precedenza (come ad esempio la presenza di entrambi i paradigmi).

La possibilita di definire helper e (varie tipologie di) rules donano anche ad ATL la proprieta di

modularita; infine, come per QVT, viene implementata la riusabilita tramite ereditarieta.

ATL si differenzia da QVT per il modo in cui vengono gestiti il modello sorgente e quello target:

il modello sorgente e navigabile, ma non modificabile, mentre il modello target e (ovviamente)

modificabile, ma non navigabile. A causa di questa peculiarita ATL non permette di eseguire tra-

sformazioni bidirezionali. Di seguito una tabella riepilogativa delle caratteristiche di ATL:

17

Kermeta

Kermeta e un linguaggio di metamodeling che permette di descrivere sia il comportamento che la

struttura dei modelli. Esso e stato realizato per essere conforme sia a MOF (per la precisione ad

EMOF) che ad Ecore.

A differenza dei due linguaggi presentati in precedenza, Kermeta implementa solamente il paradig-

ma di programmazione imperativo, cioe quello utilizzato nella totalita dei linguaggi di programma-

zione ad oggetti. Tale peculiarita porta con se una serie di pro e contro.

Il linguaggio e completamente assimilabile ad un linguaggio di programmazione moderno e le tra-

sformazioni possono essere considerate in maniera simile a qualsiasi altro linguaggio di program-

mazione non dichiarativo. Inoltre sono implementati costrutti come if,while, switch ed e possibile

addirittura gestire e sollevare eccezioni.

La modularita e implementata anche in questo caso attraverso l’ereditarieta, ma i costrutti utiliz-

zati sono piu complessi. E’ possibile, inoltre, usufruire dell’ereditarieta multipla; tale caratteristica,

come e ben noto, porta con se l’inconveniente del diamond problem.

Come si evince dall’immmagine precedente, sorge il problema riguardante l’ereditarieta della fun-

18

zionalita che viene ridefinita da piu di una classe padre (in questo caso la funzione f()). Tale

problema, risolto in informatica da diverso tempo, puo essere risolto sia in maniera implicita (cioe

viene assegnata implicitamente la funzione da ereditare da uno dei genitori) oppure esplicita (e il

programmatore a definire da quale genitore deve essere ereditata la funzione).

Kermeta adotta quest’ultima soluzione permettendo, in maniera estremamente semplice, di sceglie-

re da quale genitore ereditare [2]:

Infine, in maniera completamente analoga ad ATL, sono messi a disposizione del programmatore

una serie di costrutti per gestire collezioni di elementi (come ci si aspetta da un linguaggio di tra-

sformazione di modelli) e una serie di funzionalita interessanti per lavorare sugli elementi di tali

collezioni.

Ovviamente non e tutto oro cio che luccica e infatti alcune operazioni che sono facili in altri lin-

guaggi dichiarativi diventano complicate con Kermeta. Inoltre per leggere e scrivere dei modelli e

obbligatorio utilizzare delle primitive specifiche poiche tali operazioni non vengono eseguite auto-

maticamente dal linguaggio. Una grave pecca di tale linguaggio e, poi, la mancanza della possibilita

19

di modificare un modello gia esistente e, come ATL, l’impossibilita di effettuare trasformazioni

bidirezionali.

20

Capitolo 3: Trasformazione in ATL e Python

In questo capitolo vengono realizzati due metamodelli ed eseguita una trasformazione tra di essi

sia attraverso il linguaggio ATL sia attraverso un’implementazione specifica di Ecore su Python.

Proprio per questa motivazione (e anche perche ATL e parte integrante dell’EMF) si e deciso di

utilizzare Ecore per il metamodeling.

Sono stati dunque realizzati i metamodelli OrariCorsi e OrariDocenti.

Metamodello OrariCorsi

Tale metamodello nasce come generalizzazione dall’impostazione degli orari dei corsi utilizzata

nel nostro ateneo.

Come si evince dall’immagine soprastante sono state realizzate le seguenti classi:

21

• La classe Lezione che contiene i campi docente, nome(il nome della materia), aula, orario

di inizio e orario di fine lezione.

• La classe Giorno che contiene il nome del giorno specifico e una EReference alla classe

Lezione (in un giorno si svolgeranno da 0 ad n lezioni)

• La classe Canale che contiene anch’essa il nome di un determinato Canale universitario e

una EReference alla classe Giorno (ogni canale ha una serie di giorni, massimo 5, in cui si

svolgono lezioni)

• Le classi Anno e CorsodiStudio hanno la stessa struttura e fungono da container che svilup-

pano la gerarchia di un determinato Corso di studio.

• Nella parte superiore della piramide e, infine, presente la classe Universita che funge da

radice del metamodello

Ecore mette a disposizione delle soluzioni semplici per creare dinamicamente istanze a partire da

un determinato metamodello.

Si e, dunque, realizzata un’istanza (modello) di tale metamodello utilizzando come dati in ingresso

tutti gli orari dei corsi di studio di Ingegneria Informatica e Ingegneria Informatica Magistrale del

primo semestre dell’a.a. 2018/2019. Il risultato e il seguente:

22

Metamodello OrariDocenti

Il metamodello target e simile (ma non uguale) a quello sorgente. Sono presenti:

• Una classe Root che funge da radice del modello

• Una classe Docente (non presente nel metamodello sorgente) costituita dal nome del docente

e da una EReference alla classe Giorno

• Una classe Giorno che e completamente analoga alla sua controparte nel modello sorgente

(anche se la trasformazione non effettuera un matching diretto tra i due modelli).

• Una classe Lezione che e anch’essa analoga alla sua controparte sorgente, tranne per la man-

canza dell’attributo ’docente’ in quanto, data la gerarchia del metamodello target, e possibile

risalire allo specifico docente ”risalendo la piramide”.

Obiettivo della trasformazione

L’obiettivo di tale trasformazione e quello di, partendo da un insieme di lezioni di un determinato

canale, ottenere un modello che contenga tutti i docenti e che permetta di visualizzare in maniera

semplice quali siano le lezioni tenute per tutti i giorni della settimana. Questo perche a partire da

un insieme eterogeneo di lezioni (che appartengono ad un determinato canale di un determinato

23

anno di un determinato corso di studi) e difficile risalire agli orari di un determinato docente da noi

scelto.

Tale trasformazione segue lo stile del classico Family2Persons anche se il grado di difficolta e

leggermente piu elevato.

La trasformazione in ATL

La trasformazione in ATL e costituita da 1 rule e da 3 lazy rules. La prima rule crea una nuova

Root nel modello target per ogni Universita nel modello sorgente. Dopodiche si itera tutto l’al-

bero fino a raggiungere tutte le lezioni e vengono estratti i nomi di tutti i docenti di ogni lezione

e inseriti in una Collection. Dopo aver inserito indiscriminatamente tutti i docenti con duplicati

all’interno della Collection e necessario rimuovere tutti i duplicati.

C’e da notare che, dato che il modello sorgente non presenta la EClass Docente si e deciso di

collezionare un insieme di istanze di Lezione che hanno tutte un ’docente’ differente. In questo

modo si ha un matching perfetto tra il numero delle lezioni nella collection e il numero di classi

’Docente’ da creare nel modello target. Viene dunque lanciata la lazy rule makeDocenti che, a

24

partire da tali lezioni che non presentano il campo ’docente’ duplicato genera per ognuno la classe

Docente nel modello target; per ognuno dei docenti vengono creati e inseriti tutti i giorni della set-

timana (da lunedi a venerdi) utilizzando la sezione di ATL dedicata alle variabili locali. All’atto

dell’inserimento di ogni giorno all’interno della classe docente viene eseguita a catena la lazy rule

makeDays; essa prende in ingresso il nome del giorno e quello del docente. Attraverso la funzione

AllInstancesFrom() vengono recuperate tutte le istanze della classe Giorno e attraverso l’opera-

zione select(var — condizione) si recuperano tutte le istanze dei giorni il cui nome corrisponde

con quello in ingresso alla lazy rule. Il punto finale e quello di iterare lungo ognuno di questi giorni

per ricavare le lezioni in cui il campo ’docente’ corrisponde con il secondo parametro in ingresso

alla lazy rule. Al termine di tale operazione si avra una serie di istanze della classe Lezione all’in-

terno di una collection. Queste lezioni rappresentano le lezioni di quel determinato prof in quella

determinata giornata e dovranno essere mappate nel modello target rimuovendo il campo docente

(che non e presente nel modello destinazione), tale funzionalita finale e implementata dalla terza

lazy rule: makeLessons.

25

Eseguendo tale trasformazione il risultato finale e il seguente:

Si ha dunque una vista chiara e sistematica di quali siano le lezioni di ciascun docente in ciascun

giorno della settimana. La domanda che sorge spontanea e: ”tutto cio non sarebbe stato possibile

attraverso una semplice query su una base di dati?” La risposta e sı.

26

Il motivo di tale trasformazione e, innanzitutto, mostrare l’utilizzo di un linguaggio di trasformazio-

ne di modelli (evidenziando anche le differenze con un linguaggio tradizione), mettere in evidenza

la possibilita di riorganizzare i dati per guardarli da un punto di vista diverso. Dunque nono-

stante questo sia un problema giocattolo applicato ad un problema su un dominio estremamente

specifico esso e quantomeno utile per i sopracitati motivi.

La trasformazione in Python

Per eseguire la stessa trasformazione in Python si e utilizzato un framework realizzato apposita-

mente per poter implementare EMF/Ecore su Python, il suo nome e PyEcore (tale framework e

presente gratuitamente su GitHub) [4]

PyEcore permette di gestire modelli e metamodelli fornendo anche delle funzionalita che permet-

tono di effettuare l’ereditarieta, serializzazione e deserializzazione XMI. Dando per scontato che si

abbia gia installato Python sulla propria macchina installare anche PyEcore e davvero un gioco da

ragazzi grazie all’ausilio di pip. Basta infatti lanciare il seguente comando per installarlo:

pip install pyecore

Oltre al paradigma di programmazione standard di Python, cioe quello operazionale, il framework

mette anche a disposizone delle funzionalita, come ad esempio mapping che implementano dei

costrutti che sono di tipo relazionale (in realta il codice dietro la funzione mapping e, ovviamente,

di tipo imperativo pero l’utente finale non se ne rende conto). Facendo un confronto a livello di

funzionalita e possibile paragonare tale framework a Kermeta.

La facilita d’utilizzo di Python e la possibilita di lavorare anche su modelli target preesistenti ren-

dono, a mio parere, PyEcore migliore di Kermeta.

Passando all’analisi della trasformazione in Python si ha la seguente parte iniziale di codice:

27

Come si puo ben notare la prima parte della trasformazione e costituita da un caricamento e re-

gistrazione dei metamodelli (si evince anche che e possibile lavorare con un numero imprecisato

di metamodelli contemporaneamente). Dopodiche viene caricato anche il modello; tali passaggi

devono essere eseguiti in ordine. Infatti se si tenta di caricare un modello prima del metamodello

a cui esso si conforma si ottiene un errore poiche il campo nsURI non e stato ancora registrato. In

seguito si ha il seguente codice:

Questa e la soluzione che ho realizzato per poter creare dinamicamente delle EClass (che in que-

sto caso saranno delle pyecore.class.NOMECLASSE) a partire da quelle presenti nei metamodelli

sorgente e target. Al termine di questi due cicli for e possibile creare un’istanza di una classe ap-

partenente ad uno dei metamodelli tramite la seguente linea di codice:

Di seguito viene eseguita la funzione rule1() che e composta dalla seguente porzione di codice:

Dopo aver creato la radice del modello target viene chiamata la funzione makeDocenti(). In questo

28

caso il codice e molto piu semplice rispetto alla sua controparte ATL. Attraverso una chiamata alla

funzione eAllContents() vengono selezionate tutte le istanze della classe Lezione, ne viene estra-

polato il docente ed inserito in una Python list. Rimuovere i duplicati in questa situazione e ancora

piu semplice, basta utilizzare la funzione set().

Al termine della chiamata di tale funzione si ha una lista con tutti i nomi dei docenti senza duplica-

ti. Il resto del codice e analogo alla controparte ATL (anche se molto piu leggibile): per ogni prof

vengono inseriti i giorni ad uno ad uno, all’atto di inserimento di ogni giorno vengono estrapolate

tutte le lezioni che si svolgono in quella giornata e sono tenute da quel determinato docente. Al

termine delle varie iterazioni non serve fare altro che creare un file .XMI e serializzarlo attraverso

le funzioni fornite dal framework.

29

Cio che si evince e che Python, nonostante non vi sia una completa implementazione dei costrutti

dichiarativi, ben si presta a questo tipo di operazioni.

30

Conclusioni

Il suddetto elaborato ha messo in evidenza, in particolare, le caratteristiche salienti delle trasforma-

zioni di modelli. Cio che si evince e anche il grandissimo vantaggio che si ottiene nell’utilizzare

un livello di astrazione piu elevato. Nonostante l’esempio di trasformazione proposto sia estrema-

mente banale diviene evidente che utilizzare i metamodelli e le trasformazioni di modelli permette

di ottenere tutta una serie di vantaggi nei loro utilizzatori. Basta pensare, ad esempio, che in am-

biente business, utilizzare MDE permette di velocizzare il processo di sviluppo. Sorge spontanea

l’analogia tra i linguaggi di programmazione tradizionali e, ad esempio, il linguaggio Assembler;

e chiaro che lavorare su un livello di astrazione maggiore permette di risparmiare una notevole

quantita di tempo.

Per lo stesso motivo, quindi, anche commettere errori diventa molto piu raro.

Nell’ultima parte, invece, l’utilizzo di Python come linguaggio di trasformazione di modelli ha reso

chiaro che, attraverso l’utilizzo dei costrutti implementati attraverso il framework esterno, e possi-

bile utilizzare un linguaggio tradizionale per compiere operazioni non tradizionali. Tale framework

dunque, costituisce, seppure in minima parte, un ponte tra la programmazione tradizionale e quella

relazionale rendendo Python un linguaggio piu potente di quanto non lo sia gia di sua natura.

Linguaggi realizzati appositamente per le trasformazioni di modelli (come, appunto, ATL) sono

ovviamente piu adatti per queste situazioni; si auspica dunque che l’evoluzione dei linguaggi di

programmazione tradizionali tenga conto della sempre piu pressante necessita dell’utilizzo del

MDE.

31

Bibliografia

[1] Atl guide. https://wiki.eclipse.org/ATL/User_Guide_-_The_ATL_Language.

[2] Kermeta reference manual. http://www.kermeta.org/docs/kermeta2/html/Kermeta-Manual.

docb/Kermeta-Manual.docb.html.

[3] Metaobject facility. https://www.omg.org/mof/.

[4] Pyecore documentation. https://pyecore.readthedocs.io/en/latest/user/quickstart.html.

[5] Qvt declarative documentation. http://download.eclipse.org/qvtd/doc/0.14.0/qvtd.pdf.

[6] Gonzalo Genova. What is a metamodel: The omg’s metamodel infrastructure. http://www.ie.inf.

uc3m.es/ggenova/Warsaw/Part3.pdf.

[7] Douglas C. Schmidt. Model-driven engineering. http://citeseerx.ist.psu.edu/viewdoc/

download?doi=10.1.1.106.9720&rep=rep1&type=pdf.

[8] Transentis. Models and metamodels. https://www.transentis.com/methods-techniques/

models-and-metamodels/.

[9] Wikipedia. Metamodellazione. https://it.wikipedia.org/wiki/Metamodellazione.

32