Bruikbaarheid van Transformatietalen

IWT Beursaanvraag

Bruikbaarheid van Transformatietalen Bart Meyers

Promotor: Prof. Dr. Dirk Janssens FoTS – Formal Techniques in Software Development

Universiteit Antwerpen Departement Wiskunde-Informatica Middelheimlaan 1, 2020 Antwerpen Mei 2009

1

Probleemstelling

Sendall en Kozaczynski noemen modeltransformaties het hart en de ziel van model driven engineering (MDE) [29]. Omdat modellen als grafen voorgesteld kunnen worden, is het gebruik van graaftransformaties erg populair bij talen voor modeltransformatie. Progres was één van de eerste talen voor graaftransformatie die populair werd in de academische en industriële wereld. Later werden story diagrams ontwikkeld, een variant die gebaseerd is op de unified modeling language (UML) en op Java, en die metamodelleren uitgebreid ondersteunt [6]. Een tool voor story diagrams, genaamd Fujaba, werd ontwikkeld [13] los van de reeds bestaande Progres tool. In dezelfde periode werden heel wat andere transformatietools ontwikkeld die story diagrams of een vergelijkbare taal ondersteunen, zoals MOFLON [1], MOLA [12], GReAT [2] en VMTS [16]. Omdat de tools apart ontwikkeld worden, worden veel dezelfde taalconstructies opnieuw geïmplementeerd in elke tool, ondanks hun gelijkaardige transformatietaal. Dit is te wijten aan een gebrek aan portabiliteit tussen deze tools, en kan opgelost worden door het uitdragen van een standaard, zoals bijvoorbeeld OMG’s Queries/Views/Transformations [22]. Deze standaard is voor veel tool-ontwikkelaars echter veel te uitgebreid om te implementeren. Een standaard moet dus zo bondig mogelijk zijn, om de drempel tot gebruik zo laag mogelijk te houden. Aan de andere kant moet een taal zo bruikbaar mogelijk zijn voor transformatie-ontwerpers. Dit betekent concreet dat de taal leesbaar en bruikbaar moet zijn, en dat editors handig in gebruik moeten zijn door ondersteuning van bijvoorbeeld code completion, debugging en on-the-fly compiling. Hoewel deze twee voorwaarden elkaar lijken tegen te spreken werd er recent toch een oplossing voorgesteld [32]. De gestandaardiseerde transformatietaal is volledig gebaseerd op de UML 1.5, met een UML profiel voor modeltransformatie. Dit profiel wordt het core profiel genoemd, en bestaat uit een minimale groep van een 15-tal taalconstructies voor herschrijfregels en control flow, gedefinieerd als UML language extensions [21]. Bijkomende nuttige taalconstructies kunnen aan de hand van dit core profiel en hogere orde transformaties [35] (HOTs) gedefinieerd worden [19]. Zo kan de taal uitgebreid worden met extensies die op een platformonafhankelijke manier geïmplementeerd zijn. De MoTMoT transformatietool [33] werd ontwikkeld als light-weight tool die dit profiel ondersteunt. Alle modellen (transformatiemodellen, metamodellen en hogere orde transformaties) zijn UML compatibel en kunnen uitgewisseld worden dankzij XML Metadata Interchange (XMI) [25]. Omdat de transformatietaal volledig compatibel is met de UML kunnen UML editors gebruikt worden om transformaties te modelleren. Eenvoudige plug-ins kunnen onwikkeld worden voor deze editors om het gebruiksgemak te optimaliseren voor transformatie-ontwerpers. In de praktijk is er echter meer nodig dan het UML core profiel om transformatiemodellen en hogere orde transformaties te definiëren. Deze transformatiemodellen bevatten operaties voor “UML Data Types” zoals Boolean, String en Integer, maar deze operaties zijn niet in de UML of het core profiel gedefinieerd. In de plaats daarvan is men in MoTMoT afhankelijk van de platform-eigen Java taal. Als oplossing werden transformaties tussen de verschillende talen gesuggereerd [32]. Dit zou echter de uitwisselbaarheid van de taaluitbreidingen en dus de implementatie van het core profiel opnieuw ernstig bemoeilijken. De UML voldoet als transformatietaal en metataal. Maar is er nood aan een algemeen metamodel voor bepaalde taalconstructies, zoals bijvoorbeeld een generisch container en knoop type [17]. Ook een metamodel voor traceability is een nuttige uitbreiding [31]. Als algemeen metamodel zouden deze taalconstructies, net zoals de primitieve UML datatypes en hun operaties, beschikbaar zijn voor elk model ongeacht zijn metamodel. Deze mechanismen zouden deel uitmaken van het core profiel. Op deze manier zouden de eerder voorgestelde HOTs voor taalextensies [32, 17], en transformaties in het algemeen, volledig platformonafhankelijk geïmplementeerd kunnen worden.

1

2

Doelstelling

Het hoofddoel van dit project is de ontwikkeling van een kwaliteitsvol framework voor een uitwisselbare, lightweight, maar toch uitgebreide transformatietaal. De bedoeling is dat tools gebaseerd op graaftransformaties via dit framework modellen gemakkelijk kunnen uitwisselen en hergebruiken, om zo een productieve concurrentie met elkaar aan te gaan. Tool-ontwikkelaars kunnen zich bijgevolg toespitsen op één facet van toolontwikkeling, zoals metamodellering, performantie, editor integratie of code generatie, terwijl ze in hun project volop gebruik kunnen maken van de functionaliteiten die geïmplementeerd zijn door andere tool-ontwikkelaars. Meer concreet zal in dit project een framework worden ontwikkeld dat bestaat uit een transformatietaal en integratievoorzieningen. De transformatietaal ondersteunt het volgende: • een core profiel voor de UML met zeer beperkte omvang. Dit profiel bevat de taalconstructies voor graaftransformatie; • een generisch metamodel voor nodige constructies en operaties. Voorbeelden van constructies zijn elementen voor traceability en generische verzamelingen. Nodige operaties zijn bijvoorbeeld booleaanse expressies en operaties voor strings, integers en collections, net als operaties op bestanden en URLs; • profieluitbreidingen met nieuwe constructies voor de transformatietaal. De eerste twee onderdelen worden tijdens dit project vastgelegd als basis. Nieuwe constructies worden continu door tool-ontwikkelaars toegevoegd aan een gemeenschappelijke repository. Om al meteen een volwassen, bruikbare transformatietaal aan te bieden zullen enkele uitbreidingen toegevoegd worden gedurende het project. Ze gelden ook als gevalstudies voor de platformonafhankelijkheid en uitbreidbaarheid van de transformatietaal: • negative application conditions [11], nondeterminisme [17], iterative states [36], multi objects [36], optional graph elements [36] en rule inheritance [34]; • triple graph grammars [28], of een alternatief om bidirectionele transformaties en dus een mogelijkheid tot modelconsistentie te ondersteunen; • ondersteuning voor transformatieregels in concrete syntax in plaats van abstracte syntax, gelijkaardig als in AToM3 [3], om zo de leesbaarheid te verbeteren en het implementeren van nieuwe regels te vereenvoudigen. Het framework moet op een gebruiksvriendelijke manier gebruikt kunnen worden. Omdat het framework volledig gebaseerd is op de UML, komen modelleertools bekende, populaire UML editors in aanmerking. Voor de integratievoorzieningen zullen volgende voorzieningen geïmplementeerd worden: • een MagicDraw [20] plugin (naargelang de tendens zou een Eclipse [4] EMF/ECore [5] plugin ook zeer belangijk kunnen zijn). Deze populaire tools kunnen zo omgevormd worden tot volwaardige transformatietools waarin een softwaresysteem gemodelleerd kan worden a.h.v. verschillende modellen die achter de schermen consistent gehouden worden door de gedefinieerde modeltransformaties; • specificaties voor backend ontwikkelaars. Syntax en semantiek moeten eenduidig aangeboden worden zodat het framework snel toegepast kan worden voor andere tools (zoals Fujaba) of andere platformen (zoals C++). Binnen de onderzoeksgroep Formal Techniques in Software Development (FoTS) zijn model driven engineering, visueel modelleren en graaftransformatie belangrijke onderzoeksdomeinen. De transformatietool MoTMoT [33] werd ontwikkeld door FoTS. De expertise binnen deze onderzoeksgroep zal zeer nuttig zijn voor dit project.

2

3

Projectbeschrijving

3.1

Situering

In model driven engineering (MDE) staan modellen centraal. Deze modellen beschrijven een softwaresysteem, en ze zijn in alle ontwikkelingsfases prominent aanwezig. Verschillende soorten modellen worden gebruikt om verschillende aspecten van het systeem te modelleren. Omdat deze modellen allemaal hetzelfde systeem beschrijven moeten ze consistent gehouden worden. Dit gebeurt door modeltransformaties, die een model automatisch omzetten naar een ander model [14]. In een MDE framework moet het mogelijk zijn om nieuwe modelleertalen en modeltransformaties toe te voegen. Modeltransformaties worden in een transformatietaal gedefinieerd. Een belangrijk deel van deze transformatietalen zijn gebaseerd op graaftransformatie [27]. Een graaftransformatie bestaat uit de toepassing van een verzameling transformatieregels. Het uitvoeren van een regel transformeert een deel van het model. MDE leent zich tot kwaliteitsvolle software-ontwikkeling om twee redenen. Ten eerste garandeert het gebruik van kwaliteitsvolle modellen als volwaardige software artefacten ook de kwaliteit van code en test-cases. Ten tweede wordt de kwaliteit van het software-ontwikkelen verbeterd door het gebruik van transformaties tussen de verschillende modellen, waarbij kwaliteitsanalyses verricht kunnen worden [18].

3.2

Core profiel

Van Gorp et al. stelden een UML core profiel op voor transformatiemodellering [32]. De transformatietaal bestaat uit enerzijds transformatieregels (als class diagrams) en anderzijds control flow (als activity diagrams). Naast het gebruik van deze UML diagrammen moet de taal echter nog uitgebreid worden met constructies die eigen zijn aan transformatiemodellering (zoals bijvoorbeeld het matchen/verwijderen/creëren van elementen of de notie van conditionals in de control flow). De UML wordt echter niet uitgebreid via de taal van haar metamodel, de Meta Object Facility (MOF) [23], omdat dan de compatibiliteit met UML niet bewaard blijft. Profile Element ModelTransformation motmot.transformation tag success, failure motmot.constraint tag link, code motmot.transprimitive tag motmot.metatype tag bound create, destroy closure

Related UML Constructs Method Method, Package, Activity Diagram Transition State, String Class, String State, String State, Package, Class Diagram(s) Class Class Class, Association Attribute (initial value) Association

Meaning Callable Transformation Link from method to controlled rewrite rules Match/Mismatch of rule Application condition on state Application condition on node Call to transformation Link from a state in a flow to a rewrite rule Type of rewrite node Parameter node, or node matched by previously executed rule Created/Destroyed elements Node attribute updates Transitive closure for link label

Tabel 1: Het core profiel in MoTMoT [32] (aangepast) In plaats daarvan wordt de UML uitgebreid met “virtuele” metaklassen en “virtuele” metaattributen als zogenaamd “UML profiel” volgens de UML extensie mechanismen [21]. Die worden gedefinieerd door respectievelijk UML stereotypes, en UML tagged values. Het UML core profiel 3

worden gegeven in Tabel 1. Dit profiel bevat enkel de basisconstructies voor modeltransformatie op het niveau van transformatieregels (class diagrams) en control flow (activity diagrams).1

3.3

Generisch metamodel

De transformatietaal bestaat uit de UML en het core profiel, maar dit is nog niet voldoende om gedetailleerde transformatiemodellen op te stellen. Er is nood aan extra constructies en operaties: • operaties voor UML primitieve datatypes zoals Integer, UnlimitedInteger, String, Name, Boolean en eventueel andere [21] zijn nodig [32, 17]. Zulke operaties maken geen deel uit van de UML specificatie, maar zijn wel nodig voor contraints (bij het matchen) en toekenning van attributen (bij het uitvoeren van side-effects na het matchen). Deze operaties worden grotendeels ondersteund door Imperative OCL [22], een extensie van de OCL [24], ondersteund door de OMG’s QVT, dat imperatieve expressies ondersteunt zoals toewijzingen van variabelen. Het mogelijk gebruik van Imperative OCL, maar ook alternatieven, zal dus grondig onderzocht worden; • naast de UML datatypes is er nood aan een type voor een generische knoop en een generische container [17]. Deze types kunnen weer als virtuele metaklassen gebruikt worden, als klassen met bijvoorbeeld stereotypes als GenericNode en GenericContainer. Ook hiervoor komt het gebruik van de OCL in aanmerking, met een OCL Class (zodat attributes en operations gebruikt kunnen worden) als generische knoop en een OCL CollectionType als generische container [24]; • attributen en associaties van klassen moeten opgevraagd kunnen worden. Aangezien attributen en associaties met verschillende multipliciteiten gebruikt kunnen worden zijn bepaalde operaties op collection types nodig (isEmpty, size, union, enzovoort). Hiervoor biedt de OCL weer de geschikte operaties aan in haar OCL standard library [24]. De exacte samenstelling van dit generisch metamodel wordt onderzocht aan de hand van een aantal case studies en vergelijkende studies van bestaande transformatietools. Zo wordt het duidelijk welke operaties en constructies nodig zijn om een expressieve transformatietaal te verkrijgen. Zoals gezegd komt Imperative OCL in aanmerking voor dit generisch metamodel. Het is een voordeel dat OCL deel uitmaakt van de QVT operational mappings taal. OCL is ook goed opgenomen in zowel de academische als de industriële wereld. Er zijn al verschillende mappings geïmplementeerd die zeer goed van pas kunnen komen bij de backend specificaties, zoals OCL naar .NET [15], OCL voor een EMF code generator [8] en OCL naar Java [9].

3.4

Taaluitbreidingen door higher order transformations

De kern van de transformatietaal is het UML core profiel en het generisch metamodel, oftewel de core taal. Daarnaast is het de bedoeling dat de transformatietaal eenvoudig uitgebreid kan worden met nieuwe taalconstructies. Additionele taalconstructies kunnen dan als plugin in de transformatietaal geïntegreerd worden. Deze constructies dienen voor het gebruiksgemak van de transformatie-ontwerpers te verbeteren. Algemene constructies voor modeltransformatie kunnen toegevoegd worden (zoals negatieve applicatiecondities), maar ook domeinspecifieke constructies (zoals fuzzy pattern recognition) kunnen geïmplementeerd worden. Het is dan aan de gebruiker van de transformatietaal om te kiezen welke taaluitbreidingen hij wilt gebruiken. De syntax van deze nieuwe taalconstructies is gelijkaardig aan de syntax van het core profiel, en maakt dus gebruik van virtuele klassen en attributen. De implementatie van de nieuwe taalconstructies gebeurt door middel van hogere orde transformaties (HOTs) [35]. HOTs zijn transformaties die transformatiemodellen als input en output 1 De constructies voorgesteld in [32] voor iteraties zijn weggelaten. Ze horen immers niet bij de basis-constructies omdat ze geïmplementeerd kunnen worden met een HOT (zie Sectie 3.4).

4

hebben. De transformatiemodellen die nieuwe taalconstructies gebruiken worden getransformeerd naar transformatiemodellen zonder nieuwe taalconstructies, maar met hetzelfde gedrag. De HOT zelf wordt opgesteld in de core taal, zodat geen extra infrastructuur nodig is om de taalextensies te kunnen gebruiken. Hogere orde transformaties voor een copy operator [32], nondeterminisme [17] en negatieve applicatiecondities in patterns [17] werden al opgesteld. De techniek bestaat uit (1) het vinden van een equivalent in de core taal voor de nieuwe taalconstructie en (2) het opstellen van de HOT die elk voorkomen van deze taalconstructie transformeert naar het equivalent. Enkele voorbeelden van taalconstructies die in andere tools beschikbaar zijn, zijn gegeven in Tabel 2. Ook extensies voor bijvoorbeeld performantie, zoals het voorbeeld van het beperken van de zoekruimte, kunnen geïmplementeerd worden aan de hand van deze techniek. Extension NAC on state NAC on attribute NAC on association

NAC on subpattern Traceability Loop states Multi objects Maybe clauses Optional graph element Inheritance Reduce search space

Core language equivalent Swap success and failure transitions. Use motmot.constraint. Remove the NAC association from the pattern and add a second pattern with a NAC on its state containing the two (now bound) nodes on either end of the NAC association. Extract NAC pattern and add negated call in motmot.constraint to created story diagram scheduling the extracted NAC pattern [17]. Annotate the model with generic nodes from the generic metamodel. Mark the elements that match and add a constraint saying that only elements that are not marked can match. Loop the pattern on each occurence of the multi object [36]. Replace the pattern with a pattern for each possibility. These possibilities can be analyzed from parsing the maybe clause [36]. Replace the pattern with a pattern for each possibility [36]. Add the elements of the parent patterns to their child patterns, and replace duplicate elements in the child pattern. Split large patterns.

Tabel 2: Mogelijke taalextensies en hun equivalent in core taal [17] In Figuur 1 wordt het principe van het uitvoeren van hogere orde transformaties weergegeven. Een eerste orde transformatiemodel TrfoModel is geschreven in de uitgebreide transformatietaal bestaande uit de core taal en de extensies. TrfoModel wordt getransformeerd naar Flattened TrfoModel dat alleen de core taal gebruikt door alle HOTs uit te voeren. Beide transformatiemodellen kunnen gebruik maken van het generisch metamodel. Dit transformatiemodel kan dan uitgevoerd worden op een inputmodel door gelijk welke transformatietool die de core taal ondersteunt. Taalextensies kunnen uitgebreider zijn dan enkele nieuwe taalconstructies zoals in Tabel 2. Bidirectionele transformaties en consistentie kunnen door triple graph grammars (TGGs) [28] verwezenlijkt worden. Een TGG regel bestaat uit drie (in plaats van twee voor graph grammars) grafen. TGG regels kunnen opgedeeld worden in drie graph grammar regels: de forward rule, de reverse rule en de relations rule [10]. De HOT die TGGs implementeert kan een TGG regel dus transformeren naar deze drie regels, die alleen gebruik maken van de core taal. TGGs zijn bijvoorbeeld in Fujaba geïmplementeerd, maar nog niet op een platformonafhankelijke manier. In Fujaba, VMTS, GReAT, MoTMoT, MOFLON en MOLA worden transformatieregels opgesteld in abstracte syntax. Regels kunnen dus minder leesbaar en intuïtief zijn dan in bijvoorbeeld AToM3 , waarbij regels in concrete, grafische syntax geschreven worden. Door het principe van zogenaamde prototypes [17] en HOTs uitvoerig toe te passen is het mogelijk om regels in concrete

5

Figuur 1: Het wegtransformeren van instanties van de taaluitbreidingen syntax op een platformonafhankelijke manier te ondersteunen in de transformatietaal. De transformatieregels in concrete syntax kunnen dan door een HOT geëvalueerd en uitgevoerd worden. In dit geval treedt de HOT op als transformatie-engine, in plaats van de tool. Een andere optie bestaat erin om de transformatieregels in concrete syntax door een HOT te transformeren naar regels in abstracte syntax, die dan door de tool geëvalueerd en uitgevoerd kunnen worden. Er moet een repository-systeem ontwikkeld worden waardoor de extensies gedeeld kunnen worden tussen verschillende tool-ontwikkelaars en -gebruikers. Tools als Maven [7] kunnen hiervoor gebruikt worden.

3.5

UML editor plugin

Om de transformatietaal te kunnen gebruiken is er een integrated development environment (IDE) nodig. Aangezien de taal volledig gebaseerd is op de UML komen UML editors in aanmerking. Omdat de UML erg populair is geworden zijn er heel uitgebreide tools ontwikkeld, zoals MagicDraw [20]. Het is dus aangewezen om voor zulke tools een plugin te ontwikkelen die de taal en de tool integreren in de editor. Dit houdt het volgende in: • integratie van transformatietaal: bepaalde taalconstructies kunnen geïntegreerd worden in de IDE, zoals bijvoorbeeld transformatieregels (als variant van class diagrams), success transitions en elementen van transformatieregels; • code completion: namen van links (UML associaties) en metatypes hoeven niet helemaal getyped worden met een code completion integratie in de editor. Ook multipliciteiten kunnen automatisch aangevuld worden volgens het metamodel; • tool integratie: het uitvoeren van transformaties kan via een eenvoudige druk op de knop. Verschillende eigenschappen voor de transformatie kunnen ook via de IDE ingevuld worden; • debuggen: als er OCL constraints voor de transformatietaal toegevoegd worden kan het debuggen van syntax gebeuren door het verifiëren van deze OCL constraints. Voor het debuggen op run-time kunnen traceability mechanismen gebruikt worden, maar dit is niet zo eenvoudig en zal grondig onderzocht moeten worden.

6

De plugin integreert niet alleen de core taal in de editor maar ook de extensies, en daarom moet de plugin mee evolueren met de extensies. De plugin wordt gepersonaliseerd naargelang welke extensies geïnstalleerd zijn. Als bijvoorbeeld de extensie voor bidirectionaliteit geïnstalleerd is, dan zal de plugin ook mogelijkheden tot het synchroniseren van modellen bevatten, waardoor de editor tot een volwaardige transformatietool uitgroeit. Hierbij is de performantie van het uitvoeren van de transformaties echter heel belangrijk. Ook het installeren zelf van nieuwe extensies uit de repository kan via de plugin gebeuren. Op deze manier kan het gebruik en beheer van de transformatietool uitsluitend via de editor gebeuren, zodat het gebruiksgemak verhoogt.

3.6

Kwaliteit

Om de kwaliteit te garanderen van het framework moet het geëvalueerd worden aan de hand van de volgende criteria [18]: • herbruikbaarheid: het delen van dit framework gebeurt met het oog op het hergebruiken van transformaties, HOTs en metamodellen van andere tool-ontwikkelaars. Op regelniveau van de transformatietaal wordt herbruikbaarheid gestimuleerd door de beschikbare extensie voor rule inheritance, die als case studie geïmplementeerd wordt; • onderhoudbaarheid: omdat het framework afhankelijk is van de UML en het minimale implementatie vereist is het makkelijk te onderhouden; • gebruiksvriendelijkheid: de talrijke taalextensies, bijvoorbeeld transformatieregels in concrete syntax, zorgen voor een gebruiksvriendelijke transformatietaal. Omdat de transformatietaal volledig gebaseerd is op de UML is het mogelijk om UML editors te gebruiken. Mits een plugin voor de transformatietaal verkrijgt men een zeer gebruiksvriendelijke modelleeromgeving; • flexibiliteit: de transformatietaal kan per tool aangepast worden naargelang de voorkeur van de gebruikers. Domeinspecifieke taalconstructies kunnen toegevoegd worden aan de repository voor taalextensies, en hoeven niet door elke tool die het framework ondersteunt geïntegreerd worden; • eenvoud in regels: door “syntactic sugar” wordt de transformatietaal erg uitgebreid, waardoor het mogelijk is om erg beknopt te modelleren; • verificatie en debugmogelijkheden in regels: hoewel dit niet in dit project expliciet aan bod komt, biedt het framework toch een mogelijkheid aan tot verificatie en debugging, aan de hand van HOTs en traceability; • transformeerbaarheid van modellen [30]: hiervoor moeten modellen compleet zijn (alles in het desbetreffende domein kan uitgedrukt worden met de modellen), relevant zijn (er zijn geen nutteloze onderdelen in het model), well-formed zijn (het model volgt zijn metamodel) en precies zijn (het model is gedetailleerd genoeg om te transformeren): – compleetheid: nieuwe taalextensies kunnen domeinspecifiek zijn. De compleetheid van een model in een bepaald domein kan via case studies aangetoond worden; – relevant: dit criterium wordt niet altijd als een correct requirement geïnterpreteerd [18]. Voor bepaalde transformaties worden bepaalde elementen uit het inputmodel genegeerd. Dit is ook nuttig, en zelfs essentieel in bijvoorbeeld bidirectionele endogene verticale transformaties. Dit criterium wordt in dit project niet als requirement aanzien; – well-formedness: het metamodelleren in de UML zou uitgebreid kunnen worden met constraints (OCL [24]). Dit hoort niet tot dit project, aangezien de nadruk op de transformaties zelf ligt;

7

– precisie: bepaalde domeinspecifieke analyses kunnen uitgevoerd worden op het model voordat het getransformeerd wordt. Aan de ene kant kan dit gebeuren door andere tools die gespecialiseerd zijn in dit domein omdat de modellen uitwisselbaar zijn door XMI. Aan de andere kunnen er met de transformatietaal zelf transformaties gedefinieerd worden die analyses op modellen uitvoeren.

8

4 4.1

Planning Eerste periode, jaar 1

Eerst wordt er een eenvoudige taalextensie geïmplementeerd om deze techniek te valideren. Aangezien ik hierin ervaring heb [17], zal dit op korte tijd gerealiseerd worden. Het geheel wordt gepubliceerd als workshop paper. Het eerste jaar zal ik vooral werken aan de ontwikkeling van de transformatietaal zelf. Dit houdt in dat de vereisten voor het core profiel en het generisch metamodel geanalyseerd worden. Deze requirements zullen geïmplementeerd worden, en terwijl zullen de specificaties voor backend gebruikers opgemaakt worden. De taal wordt gevalideerd door het implementeren van taalextensies. Hierover wordt een conference paper gepubliceerd.

4.2

Eerste periode, jaar 2

In het tweede jaar zal ik vooral aandacht besteden aan de gebruiksvriendelijkheid, de uitwisselbaarheid en de integratie van het framework. Daarom wordt er een plugin ontwikkeld voor een toonaangevende UML editor zoals MagicDraw. Daarnaast wordt de repository manager voor taalextensies ontwikkeld. De realisatie van dit bruikbaar, lightweight MDE framework resulteert in een conference paper. Het jaar wordt afgesloten met een IWT-aanvraag voor een tweede periode.

4.3

Tweede periode, jaar 1

In het derde jaar zal ik de transformatietaal verder verfijnen door de implementatie van de twee meer vergaande taalextensies, transformatieregels in concrete syntax en bidirectionele transformaties. De plugin evolueert mee met de uitbreidingen van de nieuwe taal.

4.4

Tweede periode, jaar 2

In het laatste jaar zal ik de taalextensies afwerken. Zo heeft er zich een afgewerkt framework gevormd. De inhoud van het hele project wordt gepubliceerd als journal paper. Daarnaast wordt er een groot deel van de tijd besteed aan het schrijven van de thesis.

9

10

5

Toepassingsmogelijkheden

Het voorgestelde framework is nuttig omdat het principes als hergebruik en uitwisselbaarheid zeer goed ondersteunt. Tools die het framework ondersteunen moeten niet meer helemaal los van elkaar geïmplementeerd en gebruikt worden. De tijd die daarbij vrijkomt kan gebruikt worden voor veel gespecialiseerdere tooluitbreidingen. Het resultaat is een zeer uitgebreide en configureerbare transformatietaal. In model driven engineering zijn domein-specifieke talen essentieel. Door de flexibiliteit van het framework wordt het mogelijk om de tool en transformatietaal zelf domein-specifiek, maar toch uitwisselbaar te maken. Hierdoor is het gebruik erg gespecialiseerde, maar toch eenvoudige, en vooral snel configureerbare transformatietools mogelijk. Men kan dan spreken van domein-specifieke metatalen. Er kan bijvoorbeeld een transformatietool opgesteld worden voor een taal die heel geschikt is voor artificiële intelligentie. Hiervoor kan bij het pattern matchen een vorm van fuzzy logic gebruikt worden, waardoor attributen en/of elementen in patterns niet precies gematcht moeten worden, maar wel ongeveer. De uitwisselbaarheid met andere tools blijft hierbij uiteraard wel bestaan. Een ander voorbeeld zou een tool met taalconstructies op metaniveau met een notie van tijd kunnen zijn.

11

Bibliografie [1] C. Amelunxen, A. Königs, T. Rötschke, and A. Schürr. MOFLON: A Standard-Compliant Metamodeling Framework with Graph Transformations. In A. Rensink and J. Warmer, editors, Model Driven Architecture - Foundations and Applications: Second European Conference, volume 4066 of Lecture Notes in Computer Science (LNCS), pages 361–375, Heidelberg, 2006. Springer Verlag. [2] D. Balasubramanian, A. Narayanan, C. van Buskirk, and G. Karsai. The graph rewriting and transformation language: GReAT. Electronic Communications of the EASST, 1, 2006. [3] J. De Lara, H. Vangheluwe, and M. Alfonseca. Meta-modelling and graph grammars for multi-paradigm modelling in atom3. Software and Systems Modeling (SoSyM), 3(3):194 – 209, 2000. [4] Eclipse Foundation. Eclipse IDE, 2009. [5] Eclipse Foundation. Eclipse modeling framework. http://eclipse.org/emf/, 2009. [6] T. Fischer, J. Niere, L. Torunski, and A. Zündorf. Story diagrams: A new graph rewrite language based on the unified modeling language and java. In TAGT’98: Selected papers from the 6th International Workshop on Theory and Application of Graph Transformations, pages 296–309, London, UK, 2000. Springer-Verlag. [7] T. A. S. Foundation. Maven. http://maven.apache.org/, 2007. [8] M. Garcia and A. J. Shidqie. OCL Compiler for EMF. In Eclipse Modeling Symposium at Eclipse Summit Europe 2007, Stuttgart, Germany, 2007. [9] M. Garcia and A. J. Shidqie. Ocl tools: Status and perspectives. Technische Universität Hamburg-Harburg, 2007. [10] L. Grunske, L. Geiger, and M. Lawley. A graphical specification of model transformations with triple graph grammars. In In First European Conference Model Driven Architecture Foundations and Applications, number 3748 in Lecture Notes in Computer Science, pages 284–298. Springer, 2005. [11] A. Habel, R. Heckel, and G. Täntzer. Graph grammars with negative application conditions. Fundamenta Informaticae, 26:287–313, 1995. [12] A. Kalnins, J. Barzdins, and K. Podnieks. http://mola.mii.lu.lv/, 2008.

MOLA - MOdel transformation LAnguage.

[13] T. Klein, U. A. Nickel, J. Niere, and A. Zündorf. From uml to java and back again. Technical Report tr-ri-00-216, University of Paderborn, Paderborn, Germany, September 1999. [14] A. Kleppe, J. Warmer, and W. Bast. MDA Explained: The Model Driven Architecture– Practice and Promise. Addison-Wesley Professional, April 2003.

12

[15] L. Lengyel, T. Levendovszky, and H. Charaf. Implementing an ocl compiler for .net. In In Proceedings of the 3rd International Conference on .NET Technologies, pages 121–130, Plzen, Czech Republic, May 2005. [16] T. Levendovszky, L. Lengyel, G. Mezei, and T. Mészáros. VMTS - Visual Modeling and Transformation System. http://www.vmts.aut.bme.hu/, 2007. [17] B. Meyers. Hybrid rule scheduling in story driven modeling – a tool-independent approach. Master’s thesis, University of Antwerp, 2009. [18] P. Mohagheghi and V. Dehlen. An overview of quality frameworks in model-driven engineering and observations on transformation quality. In L. Kuzniarz, J. L. Sourrouille, and M. Staron, editors, Proceedings of the 2nd Workshop on Quality in Modeling, pages 3–17, Nashville, TN, USA, 2007. [19] O. Muliawan. Extending a model transformation language using higher order transformations. In WCRE ’08: Proceedings of the 2008 15th Working Conference on Reverse Engineering, pages 315–318, Washington, DC, USA, 2008. IEEE Computer Society. [20] No Magic. Magicdraw uml, 2009. [21] OMG. OMG Unified Modeling Language Specification, Version 1.4, June 2001. [22] OMG. MOF QVT final adopted specification, November 2005. [23] OMG. Meta Object Facility (MOF) Core Specification, Version 2.0, Januari 2006. [24] OMG. OMG Object Constraint Language, Version 2.0, May 2006. [25] OMG and R. Soley. XML metadata interchange (XMI) specification, Version 2.0, May 2005. [26] L. F. Pires and S. Hammoudi, editors. Model-Driven Enterprise Information Systems, Proceedings of the 2nd International Workshop on Model-Driven Enterprise Information Systems, MDEIS 2006, In conjunction with ICEIS 2006, Paphos, Cyprus, May 2006. INSTICC Press, 2006. [27] G. Rozenberg, editor. Handbook of Graph Grammars and Computing by Graph Transformations, Volume 1: Foundations. World Scientific, 1997. [28] A. Schürr. Specification of graph translators with triple graph grammars. In 20th International Workshop on Graph-Theoretic Concepts in Computer Science, pages 151–163, London, UK, 1995. Springer-Verlag. [29] S. Sendall and W. Kozaczynski. Model transformation - the heart and soul of model-driven software development. IEEE Software, Special Issue on Model Driven Software Development, pages 42–45, 2003. [30] I. Solheim and T. Neple. Model quality in the context of model-driven development. In Pires and Hammoudi [26], pages 27–35. [31] P. Van Gorp. Model-driven Development of Model Transformations. PhD thesis, University of Antwerp, 2008. [32] P. Van Gorp, A. Keller, and D. Janssens. Transformation language integration based on profiles and higher order transformations, 2008. [33] P. Van Gorp, H. Schippers, and O. Muliawan. MoTMoT. http://motmot.sourceforge.net/, 2007.

13

[34] D. Varró and A. Pataricza. VPM: A visual, precise and multilevel metamodeling framework for describing mathematical domains and uml (the mathematics of metamodeling is metamodeling mathematics). Software and System Modeling, 2(3):187–210, 2003. [35] D. Varró and A. Pataricza. Generic and meta-transformations for model transformation engineering. In T. Baar, A. Strohmeier, A. Moreira, and S. Mellor, editors, Proc. UML 2004: 7th International Conference on the Unified Modeling Language, volume 3273 of LNCS, pages 290–304, Lisbon, Portugal, October 10–15 2004. Springer. [36] A. Zündorf. Rigorous Object Oriented Software Development. PhD thesis, University of Paderborn, 2002.

14