Analisi e differenti approcci alle. trasformazioni di modelli. Elaborato finale in Programmazione I. Anno accademico 2017/2018

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso 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. N

2 A chi crede in me. 2

3 Indice Introduzione 4 Capitolo 1: Model-driven engineering, modelli e metamodelli 5 I modelli I metamodelli La gerarchia a 4 livelli Metamodeling: esempio Capitolo 2: Trasformazioni di modelli e linguaggi di trasformazione 11 Trasformazioni di modelli Lo standard OMG: QVT ATL: ATLAS Transformation Language Kermeta Capitolo 3: Trasformazione in ATL e Python 21 Metamodello OrariCorsi Metamodello OrariDocenti Obiettivo della trasformazione La trasformazione in ATL La trasformazione in Python Conclusioni 31 Bibliografia 32 3

4 Introduzione In ambito informatico e, più in generale, in quello ingegneristico è sempre necessare adottare un approccio che permetta di affrontare con sistematicità i problemi più complessi. Una delle grandi difficoltà risiede nel dover lavorare con una grande mole di dati che sono, di norma, di tipo eterogeneo. Con il dilagare della Rete, inoltre, tale problematica diviene ancora più 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 riferirà con la terminologia inglese Model-driven engineering, di norma abbreviato in MDE. Attraverso tale metodologia di sviluppo è possibile lavorare ad un livello di astrazione più elevato, facilitando il lavoro e migliorando l efficienza. Tale elaborato ha lo scopo di mettere in luce gli aspetti più salienti e differenti approcci alle trasformazioni di modelli, che costituiscono una parte fondamentale del MDE. Nel primo capitolo vengono introdotti, oltre al già citato MDE, i modelli e i metamodelli con tutte le loro caratteristiche più 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 programmazione 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

5 Capitolo 1: Model-driven engineering, modelli e metamodelli L utilizzo di astrazioni è sempre stato un approccio utilizzato dagli sviluppatori nella realizzazione di soluzioni software. Tali astrazioni, però, sono effettuate nel dominio della soluzione. E necessario, 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 è 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 è definire lo scopo di tale modello, dunque è necessario capire a quali domande si vuole andare a rispondere tramite l ausilio del modello in questione. Inoltre è fondamentale definire dei confini, cioè è necessario concentrarsi solo sulla parte che veramente è di nostro interesse, disinteressandosi di tutto il resto. Dopodichè è necessario identificare i concetti rilevanti e analizzare quali sono le relazioni che intercorrono tra di essi. Realizzare un modello non è 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 nè giusti nè sbagliati [8], ma che possono solamente essere più o meno adatti per quanto riguarda il loro scopo e possono però essere incosistenti riguardo la loro rappresentazione. 5

6 I metamodelli Un metamodello è 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 è relativa perchè un modello può essere sia un modello o un metamodello. Dunque un metamodello è 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 dovrà essere conforme al suo metamodello alla stessa maniera in cui un programma per computer è conforme alla grammatica del linguaggio di programmazione in cui è 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 è una tipologia speciale di modello che specifica al sintassi astratta 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 poiché un metamodello può essere sia un modello che un metamodello in base alla prospettiva da cui lo si guarda. Lo standard adottato da OMG per risolvere i problemi legati all eterogeneità della immensa quantità di dati che vengono scambiati al giorno d oggi è MOF (Meta Object Facility [3]. Tale standard definisce 4 layer: 6

7 Il livello M0 è quello più in basso e contiene le istanze run-time degli elementi del modello (quello definito al livello M1). Un modello è un istanza di un metamodello. Un modello rappresenta il sistema al livello M1 e si conforma ad un linguaggio la cui sintassi astratta è rappresentata nel livello soprastante. Per questo motivo si può dire che il modello si conforma al metamodello. 7

8 Allo stesso modo il metamodello si conforma ad un linguaggio la cui sintassi astratta è rappresentata nel livello soprastante. Quindi si può dire che il metamodello si conforma al meta-metamodello. La responsabilità principale di un metamodello è definire il linguaggio per specificare i modelli. UML e OMG CWM sono esempi di metamodelli. 8

9 A terminare la gerarchia vi è il meta-metamodello che è riflessivo e pertanto si conforma ad un linguaggio la cui sintassi astratta è rappresentata da se stesso; questo è il livello M3. Di norma un meta-metamodello è più compatto rispetto ad un metamodello e spesso è possibile che più di un metamodello si conformi ad esso. Vi è, infine, la versione di Bèzivin che raggruppa diversamente la gerarchia realizzando un 3+1 in cui il sistema è rappresentato dal layer M0 mentre i tre restanti corrispondono alla rappresentazione di tale sistema [6] 9

10 Metamodeling: esempio Di seguito è presentato un banalissimo esempio che mostra la relazione che intercorre tra un modello e il suo metamodello. Il compito primario di un metamodello è quello di definire la semantica del modello che si andrà 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 è un istanza della metaclasse Association. Di seguito un immagine che esplica la differenza sostanziale tra un modello e una sua particolare istanza. 10

11 Capitolo 2: Trasformazioni di modelli e linguaggi di trasformazione In questo capitolo verranno introdotte le trasformazioni di modelli e alcuni dei linguaggi di trasformazione di modelli (lo standard QVT, ATL, Kermeta). Trasformazioni di modelli Lo scopo è quello di generare un nuovo modello, definito modello target, a partire da un modello di partenza, definito modello source, seguendo delle regole definite formalmente. Perchè si effettuano tali trasformazioni? Potrebbe capitare di dover estrarre un particolare subset dal modello sorgente (in pratica è 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 può 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 è il seguente: Ogni famiglia ha un cognome ed è 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 personaè, invece, il seguente: 11

12 Ogni persona è composta da un Nome + Cognome (fullname) e può 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

13 Il PIM (platform independent model è, appunto, un modello che non contiene informazioni specifiche riguardanti la piattaforma di implementazione. Il PSM (platform specific model, d altra parte, è il modello realizzato per la specifica implementazione (ad esempio Java oppure C++). Si ha, quindi, che per un singolo PIM possono esserci più PSM. Una trasformazione di modelli, quindi, è un operazione che permette di ottenere un PSM a partire da un PIM.Tale trasformazione ingloba in sè tutte le regole necessarie per poter effettuare l operazione; infatti all interno della trasformazione 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) è 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 (cioè dichiarativo) oppure operazionale (imperativo). Il paradigma relazionale (dichiarativo) permette di esprimere un entità in termini di somiglianza con un altra; non viene però 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) è quello più diffuso nella totalità dei linguaggi di program- 13

14 mazione tradizionali, esso permete di esprimere come un entità 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 modelli; esso è nato nel 2001 ed la sua versione 1.1 è stata rilasciata nel 2011 [5]. Tale standard presenta la seguente architettura: Come è 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 è rappresentato dalle entità Relations, Core e Relations2Core transformation. Relations è un metamodello che, tra le caratteristiche salienti, permette di realizzare dei matching con altri metamodelli implementando la Traceability, cioè la presenza di strutture che mettono in relazione gli elementi del modello sorgente con quelli del modello target. Core è. 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 è un metamodello, mentre il secondo un modello), infatti il linguaggio di Core è più ristretto e, 14

15 dunque, necessita di utilizzare delle definizioni più complesse rispetto a Core. Tale gap semantico è colmato da Relations2Core transformation. Il paradigma operazionale è rappresentato dai due blocchi esterni: Operational Mappings e Black Box. Il paradigma imperativo è necessario poiché in alcune situazioni non è possibile esprimere una trasformazione utilizzando solamente costrutti dichiarativi (nel MDE, però, si tende ad utilizzare tale paradigma solamente quando strettamente necessario). QVT permette, inoltre, di eseguire trasformazioni bidirezionali, modificando sia il modello sorgente che quello target. Dal punto di vista dell organizzazione QVT permette di definire le trasformazioni in moduli (proprietà di modularità) e permette di godere della riusabilità del codice attraverso l ereditarietà. Una trasformazione QVT permette di generare dei nuovi modelli a partire da un modello sorgente (quindi non solamente di modificare un modello target già esistente). Nel caso in cui il modello target sia già esistente viene effettuato un update con cancellazione, cioè tutte le entità 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 è 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 è di nostro interesse al momento. Infine, il linguaggio ATL permette anche di creare librerie indipendenti e di riutilizzarle in più unità ATL differenti. 15

16 Una trasformazione M2M viene realizzata attraverso un unità ATL Module. Tale unità 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 è composto un ATL Module? Un singolo modulo ATL è costituito da 4 elementi primitivi: Una sezione header iniziale in cui vengono specificati alcuni attributi come il nome del modulo (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 modalità di esecuzione: normal oppure refining. La prima tipologia è quella che viene utilizzata in genere per creare dei modelli target che differiscono da quelli sorgente. La seconda, invece, è pensata appositamente per trasformazioni in cui il modello sorgente e target sono molto simili (refining transformation). Utilizzando tale modalità, infatti, è necessario definire solamente gli elementi del modello che andranno trasformati; la parte restante verrà ricopiata nel modello target senza subire variazioni. In ATL entrambi i modelli devono conformarsi allo stesso metamodello. Una sezione (opzionale) in cui è possibile importare una o più 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 è necessario inserire quali sono gli elementi target e quelli sorgente; siccome molto spesso è di interesse performare la trasformazione su un particolare sottoinsieme di elementi che si conformano ad un metamodello è possibile specificare delle condizioni che devono essere soddisfatte dagli elemeneti su cui verrà effettuata la trasformazione. Nella sezione relativa al target, invece, viene definito in quale modo dovrà essere generato il modello in uscita. La prima sezione opzionale permette, invece, di aggiungere delle variabili locali alla regola. La seconda (opzionale), invece, è quella che permette di inserire del codice imperativo che verrà eseguito dopo la generazione dei modelli target. 16

17 Le lazy rules sono simili in tutto è per tutto alle matched rules, l unica cosa che le differenzia è che tali regole vengono eseguite solamente quando richiamate da un altra regola. Le called rules permettono di implementare del codice imperativo. Tali regole accettano parametri 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 perché è 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 è il corrispettivo in ATL dei metodi Java. La caratteristica peculiare di tali helper è 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 è 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 funzionalità che sono espresse anche dallo standard QVT presentato in precedenza (come ad esempio la presenza di entrambi i paradigmi). La possibilità di definire helper e (varie tipologie di) rules donano anche ad ATL la proprietà di modularità; infine, come per QVT, viene implementata la riusabilità tramite ereditarietà. ATL si differenzia da QVT per il modo in cui vengono gestiti il modello sorgente e quello target: il modello sorgente è navigabile, ma non modificabile, mentre il modello target è (ovviamente) modificabile, ma non navigabile. A causa di questa peculiarità ATL non permette di eseguire trasformazioni bidirezionali. Di seguito una tabella riepilogativa delle caratteristiche di ATL: 17

18 Kermeta Kermeta è un linguaggio di metamodeling che permette di descrivere sia il comportamento che la struttura dei modelli. Esso è 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 paradigma di programmazione imperativo, cioè quello utilizzato nella totalità dei linguaggi di programmazione ad oggetti. Tale peculiarità porta con sè una serie di pro e contro. Il linguaggio è completamente assimilabile ad un linguaggio di programmazione moderno e le trasformazioni possono essere considerate in maniera simile a qualsiasi altro linguaggio di programmazione non dichiarativo. Inoltre sono implementati costrutti come if,while, switch ed è possibile addirittura gestire e sollevare eccezioni. La modularità è implementata anche in questo caso attraverso l ereditarietà, ma i costrutti utilizzati sono più complessi. E possibile, inoltre, usufruire dell ereditarietà multipla; tale caratteristica, come è ben noto, porta con sè l inconveniente del diamond problem. Come si evince dall immmagine precedente, sorge il problema riguardante l ereditarietà della fun- 18

19 zionalità che viene ridefinita da più di una classe padre (in questo caso la funzione f()). Tale problema, risolto in informatica da diverso tempo, può essere risolto sia in maniera implicita (cioè viene assegnata implicitamente la funzione da ereditare da uno dei genitori) oppure esplicita (è il programmatore a definire da quale genitore deve essere ereditata la funzione). Kermeta adotta quest ultima soluzione permettendo, in maniera estremamente semplice, di scegliere 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 trasformazione di modelli) e una serie di funzionalità interessanti per lavorare sugli elementi di tali collezioni. Ovviamente non è tutto oro ciò che luccica e infatti alcune operazioni che sono facili in altri linguaggi dichiarativi diventano complicate con Kermeta. Inoltre per leggere e scrivere dei modelli è obbligatorio utilizzare delle primitive specifiche poiché tali operazioni non vengono eseguite automaticamente dal linguaggio. Una grave pecca di tale linguaggio è, poi, la mancanza della possibilità 19

20 di modificare un modello già esistente e, come ATL, l impossibilità di effettuare trasformazioni bidirezionali. 20

21 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 perchè ATL è parte integrante dell EMF) si è 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

22 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 sviluppano la gerarchia di un determinato Corso di studio. Nella parte superiore della piramide è, infine, presente la classe Università che funge da radice del metamodello Ecore mette a disposizione delle soluzioni semplici per creare dinamicamente istanze a partire da un determinato metamodello. Si è, 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 è il seguente: 22

23 Metamodello OrariDocenti Il metamodello target è 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 è completamente analoga alla sua controparte nel modello sorgente (anche se la trasformazione non effettuerà un matching diretto tra i due modelli). Una classe Lezione che è anch essa analoga alla sua controparte sorgente, tranne per la mancanza dell attributo docente in quanto, data la gerarchia del metamodello target, è possibile risalire allo specifico docente risalendo la piramide. Obiettivo della trasformazione L obiettivo di tale trasformazione è 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 perché a partire da un insieme eterogeneo di lezioni (che appartengono ad un determinato canale di un determinato 23

24 anno di un determinato corso di studi) è difficile risalire agli orari di un determinato docente da noi scelto. Tale trasformazione segue lo stile del classico Family2Persons anche se il grado di difficoltà è leggermente più elevato. La trasformazione in ATL La trasformazione in ATL è 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. Dopodichè si itera tutto l albero 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 è necessario rimuovere tutti i duplicati. C è da notare che, dato che il modello sorgente non presenta la EClass Docente si è 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

25 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 settimana (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 operazione select(var condizione) si recuperano tutte le istanze dei giorni il cui nome corrisponde con quello in ingresso alla lazy rule. Il punto finale è 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 avrà una serie di istanze della classe Lezione all interno 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 è presente nel modello destinazione), tale funzionalità finale è implementata dalla terza lazy rule: makelessons. 25

26 Eseguendo tale trasformazione il risultato finale è 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 è: tutto ciò non sarebbe stato possibile attraverso una semplice query su una base di dati? La risposta è sì. 26

27 Il motivo di tale trasformazione è, innanzitutto, mostrare l utilizzo di un linguaggio di trasformazione di modelli (evidenziando anche le differenze con un linguaggio tradizione), mettere in evidenza la possibilità di riorganizzare i dati per guardarli da un punto di vista diverso. Dunque nonostante questo sia un problema giocattolo applicato ad un problema su un dominio estremamente specifico esso è quantomeno utile per i sopracitati motivi. La trasformazione in Python Per eseguire la stessa trasformazione in Python si è utilizzato un framework realizzato appositamente per poter implementare EMF/Ecore su Python, il suo nome è PyEcore (tale framework è presente gratuitamente su GitHub) [4] PyEcore permette di gestire modelli e metamodelli fornendo anche delle funzionalità che permettono di effettuare l ereditarietà, serializzazione e deserializzazione XMI. Dando per scontato che si abbia già installato Python sulla propria macchina installare anche PyEcore è 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, cioè quello operazionale, il framework mette anche a disposizone delle funzionalità, come ad esempio mapping che implementano dei costrutti che sono di tipo relazionale (in realtà il codice dietro la funzione mapping è, ovviamente, di tipo imperativo però l utente finale non se ne rende conto). Facendo un confronto a livello di funzionalità è possibile paragonare tale framework a Kermeta. La facilità d utilizzo di Python e la possibilità di lavorare anche su modelli target preesistenti rendono, a mio parere, PyEcore migliore di Kermeta. Passando all analisi della trasformazione in Python si ha la seguente parte iniziale di codice: 27

28 Come si può ben notare la prima parte della trasformazione è costituita da un caricamento e registrazione dei metamodelli (si evince anche che è possibile lavorare con un numero imprecisato di metamodelli contemporaneamente). Dopodiché 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 poiché il campo nsuri non è stato ancora registrato. In seguito si ha il seguente codice: Questa è la soluzione che ho realizzato per poter creare dinamicamente delle EClass (che in questo caso saranno delle pyecore.class.nomeclasse) a partire da quelle presenti nei metamodelli sorgente e target. Al termine di questi due cicli for è possibile creare un istanza di una classe appartenente ad uno dei metamodelli tramite la seguente linea di codice: Di seguito viene eseguita la funzione rule1() che è composta dalla seguente porzione di codice: Dopo aver creato la radice del modello target viene chiamata la funzione makedocenti(). In questo 28

29 caso il codice è molto più semplice rispetto alla sua controparte ATL. Attraverso una chiamata alla funzione eallcontents() vengono selezionate tutte le istanze della classe Lezione, ne viene estrapolato il docente ed inserito in una Python list. Rimuovere i duplicati in questa situazione è ancora più semplice, basta utilizzare la funzione set(). Al termine della chiamata di tale funzione si ha una lista con tutti i nomi dei docenti senza duplicati. Il resto del codice è analogo alla controparte ATL (anche se molto più 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

30 Ciò che si evince è che Python, nonostante non vi sia una completa implementazione dei costrutti dichiarativi, ben si presta a questo tipo di operazioni. 30

31 Conclusioni Il suddetto elaborato ha messo in evidenza, in particolare, le caratteristiche salienti delle trasformazioni di modelli. Ciò che si evince è anche il grandissimo vantaggio che si ottiene nell utilizzare un livello di astrazione più elevato. Nonostante l esempio di trasformazione proposto sia estremamente 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 ambiente 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; è chiaro che lavorare su un livello di astrazione maggiore permette di risparmiare una notevole quantità di tempo. Per lo stesso motivo, quindi, anche commettere errori diventa molto più 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, è possibile 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 più potente di quanto non lo sia già di sua natura. Linguaggi realizzati appositamente per le trasformazioni di modelli (come, appunto, ATL) sono ovviamente più adatti per queste situazioni; si auspica dunque che l evoluzione dei linguaggi di programmazione tradizionali tenga conto della sempre più pressante necessità dell utilizzo del MDE. 31

32 Bibliografia [1] Atl guide. [2] Kermeta reference manual. docb/kermeta-manual.docb.html. [3] Metaobject facility. [4] Pyecore documentation. [5] Qvt declarative documentation. [6] Gonzalo Génova. What is a metamodel: The omg s metamodel infrastructure. uc3m.es/ggenova/warsaw/part3.pdf. [7] Douglas C. Schmidt. Model-driven engineering. download?doi= &rep=rep1&type=pdf. [8] Transentis. Models and metamodels. models-and-metamodels/. [9] Wikipedia. Metamodellazione. 32