T-Core: Transformation Languages Tailored To Your Needs

1. T-Core:Transformation Languages Tailored To Your Needs Eugene Syriani

2. Outline • Model Transformation Languages (MTLs) • Uses & Applications of Model Transformation • Features of Model Transformation Languages • Essence of Model Transformation Languages • Common Basis • A Product Line of MTLs • Explicitly Modelling MTLs • Syntax, Semantics, and All That Stuff • Challenges

3. What is Model Transformation? “The process of converting one model to another model of the same system.” [1] “The automatic generation of a target model from a source model,according to a transformation definition.” [2] “A manipulation of a model with a specific intention.” [3] [1] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12. [2] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And Promise. Addison-Wesley, 2003. [3] Syriani, E. Model Transformation. Summer School on Domain-Specific Modelling: Theory & Practice (DSM-TP’10). Lisbon, 2010.

4. Terminology • The transformation is defined at the meta-model level • The execution of the transformation is applied on the models to automatically transform them • Model-to-Model Transformation • Same meta-models • Same model • Multiple source/target models Source Meta-model Transformation Definition Target Meta-model refers to refers to conforms to conforms to executes Source Model Transformation Target Model reads outputs

5. Types of Transformations Access/Modify operations • Simple operations on a model: • Add an element to the model; • Remove an element from the model; • Update an element’s properties; • Access an element or its properties. • These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

6. Types of Transformations Query Operation that requests some information about a system • This operation takes as input the model M and outputs a view of M • A view is a projection of (a sub-set of) the properties of M • A query is a transformation since it is a projection, obtained by CRUD operations on the properties of M • Restrictive view: Reveal a subset of the properties of M (all, none, some) • Retrieve all cycles in a causal block diagram • Show only classes/associations of a class diagram • Aggregated view: Restriction of M modifying some of its properties • Get the average of all costs per catalogue product in a relational database schema • In a hierarchical model, show top-level elements only, with an extra attribute denoting the number of sub-elements

7. Types of Transformations Synthesis Transform from a higher level specification to a lower level description • Design models translated into source code • DSM compiled into an executable implementation PhoneApps to Statecharts [5] [5] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from Domain-Specific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.

8. Types Of Transformations Translational Semantics • Formalism’s semantic mapping function defined by a transformation • Formalism's semantic domain is a modelling language Finite State Automata to Petri-Net [4] [4] Kühne, T.; Mezei, G.; Syriani, E.; Vangheluwe, H. & Wimmer, M. Explicit Transformation Modeling. MODELS 2009 Workshops,LNCS: 6002, pp. 240-255, Springer. Denver (USA) 2010.

9. Types of Transformations Reverse Engineering Inverse of synthesis: extract higher-level specifications from lower-level ones

10. Types of Transformations Simulation • Update the state of the system modelled • Target model is an “updated” version of the source model • Operational semantics Finite State Automata Simulator

11. Types of Transformations Meta-model instance generation • Automatically generate random models that conform to the language Class diagram meta-model

12. Types of Transformations Migration Transform from a software model written in one language or framework into another, but keeping the same level of abstraction • Evolution to new version Enterprise Java Beans 2.0 to 3.0

13. Types of Transformations Optimization Improve certain operational qualities of the model while preserving its semantics • Typically used on architecture or design models List to Table Optimization

14. Types of Transformations Restructuring Change the internal structure of the model to improve certain quality characteristics without changing its observable behaviour(Understandability, modifiability, reusability, modularity, adaptability) • Typically used on architecture or design models • Refactoring Pull Up Method refactoring

15. Types of Transformations Normalization Decrease syntactic complexity • DesugaringTranslate complex language constructs (syntactic sugar) into more primitive language constructs • Simplification Transform all uses of a language construct in a normal or canonical form • Map the concrete syntax back to the abstract syntax H H H C C O H CH3 CH2 OH H H

16. Types of Transformations Composition Integrate models that have been produced in isolation into a compound model Model Merging Model Weaving

17. Types of Transformations Synchronization Integrate models that have evolved in isolation but that are subject to global consistency constraints • In contrast with composition, synchronization requires that changes are propagated to the models that are being integrated • Source model changes are propagated to corresponding target model changes:Incremental / Change-driven transformation • Synchronization must be ensured in both directions: multi-directional transformation • Inconsistencymanagement Repository

18. Types of Transformations Classification

19. Characteristics of MTLs • Feature model [6] • Specification • Pre/post condition on the transformation: • Function between source & target models • Relation may be executable or not • Rule Organization • General structuring issues of rules • Modularization • Composition • Re-use • Transformation Rules • Smallest transformation unit, used to specify a transformation • Rule-based transformations: pre-condition & post-condition for rewriting • Transformation units defined as functions • Templates • Incrementality • Ability to update existing target models based on changes in the source models • Directionality • Transformation executed in one direction or in multiple directions (uni-/multi-directional transformation) • Rule Application Control • Where is a rule applied on the model • In what order are the rules executed • Tracing • Mechanisms for recording different aspects of transformation execution: • Create & maintain trace links between source & target model elements • Source-Target Relationship • In-place • Out-place [6] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

20. Characteristics of MTLs Transformation Unit • Smallest transformation element • A transformation is mainly specified in terms of rules • Pre-condition on the input model • Post-condition on the output model : :

21. Characteristics of MTLs Transformation Unit • Logic How computations & constraints are specified on model elements QVT-Relations rule [7] Kermeta operation [8] • top relationPackageToSchema { • domainuml p:Package{name=pn} • domainrdbms s:Schema{name=pn} • } operation transform(source:PackageHierarchy): DataBaseis do result := DataBase.new trace.initStep(“uml2db”) source.hierarchy.each{ pkg | varscm: Schema initSchema.new scm.name := String.clone(pkg.name) result.schema.add(scm) trace.addlink(“uml2db”, “package2schema", pkg, scm) } end [7] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008. [8] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in Kermeta. ECMDA-TW'06, pp. 31-40, HAL-CCSd-CNRS. Bilbao (Spain), July 2006.

22. Characteristics of MTLs Transformation Unit • Syntactic separation FUJABA [10] rule: compact notation MoTif [9] graph transformation rule • module Person2Contact; • create OUT: MMbfrom IN: MMa { • rule Start { • form p: MMa!Person( • p.function = ‘Boss’ • ) • to c: MMb!Contact( • name <- p.first_name + p.last_name) • } ATL [11] rule [9] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In: Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC Press. Boca Raton (USA), 2009. [10] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764, pp. 296-309, Springer-Verlag. Paderborn (Germany), 2000. [11] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.

23. Characteristics of MTLs Transformation Unit • Parameterization Exchange control parameters: pre-defined binding of some model elements ProGreS [13] in/out parameters GReAT [12] pivot passing [12] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006. [13] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.

24. Characteristics of MTLs Directionality • Unidirectional transformation:create (or update) the target model only • Multi-directional transformation :can be executed in any direction • Operational rules have a functional character:given an input model, produce a target model • Causality from source to target model • Declarative rules:gives a relation between both models that must be satisfied • Acausal relationship between the models Triple Graph Grammar [11] rule QVT-R relation • top relationPackageToSchema { • domainuml p:Package {name = n} • domainrdbms s:Schema {name = n} • } [14] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In: Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC Press. Boca Raton (USA), 2009.

25. Characteristics of MTLs Directionality TGG rule TGG operational rules • One TGG rule generates 7 TGG operational rules: • Every new element in a model has a correspondence in the other [x2] • When an element is removed from a model, its correspondent element(s) is (are) deleted appropriately [x2] • Enforce the consistency relations between attributes [x2] • Create a correspondence between unmapped elements of the two models [x1]

26. Characteristics of MTLs Location Determination • Strategy for determining the application locations of a rule Model: Rule:

27. Characteristics of MTLs Rule Scheduling Implicit • Unordered One rule that is applicable is selected to be applied non-deterministically at each iteration • Grammar Unordered with start model and terminal states (generation or recognition) Rules: , Model:

28. Characteristics of MTLs Rule Scheduling QVT-R relation Explicit internalA rule may invoke other rules • In ATL, a matched rule (implicitly scheduled) may invoke a called rule in its imperative part. Lazy rules • In QVT, the when/where clauses of a rule may have a reference to other rules.When: the former will be applied after the latter. Where: the latter will be applied after the former. • top relationClassToTable { • domainuml c:Class { • package = p:Package{}, • isPersistent = true, • name = cn • } • domainrdbms t:Table { • schema = s:Schema{}, • name = cn, • cols = cl:Column { • name = cn + ‘_tid’, • type = ‘NUMBER’}, • pkey = cl • } • when { • PackageToSchema (p, s); • } • where { • AttributeToColumn (c, t); • } • }

29. Characteristics of MTLs Rule Scheduling Explicit externalClear separation between the rules and the scheduling logic.Use a control structure to define rule scheduling • OrderedPriority, layer/phased, explicit workflow structure, … • Event-drivenRule execution is triggered by external events

30. Characteristics of MTLs Rule Scheduling • Priority-based: AToM3 [15] [15] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS: 2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.

31. Characteristics of MTLs Rule Scheduling • Layered/Phased: AGG[16] [16] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software. AGTIVE'03, LNCS: 3062, pp. 446-453, Springer-Verlag, 2004.

32. Characteristics of MTLs Rule Scheduling • Explicit workflow: GReAT data flow FUJABA story diagram

33. Characteristics of MTLs Rule Scheduling: Feature Matrix [17] [17] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2, School of Computer Science, March 2009

34. Characteristics of MTLs Rule Scheduling: Feature Matrix What these languages/tools have in common: • Graph transformation (GT) paradigm with explicit external scheduling • Not complete list: • AGG: layered graph transformation • MOLA [18]: structured flowchart • T-Core [19]: primitive graph transformation operators combined with Python • ... • Non GT languages with explicit control structure:QVT-Operational Mappings, Kermeta [18] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS: 3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005. [19] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29 (GT-VMT'10), Paphos (Cyprus), March 2010.

35. Family of transformation languages • Model Transformation has many applications: • Generate PSMs form PIMs and reverse engineering • Map and synchronize among models at the same or different level of abstraction • Create views of a system • Model evolution tasks • Since the applications are very different in nature, it is not optimal to have a single model transformation language that supports all of the above. • Instead, it is more appropriate to have dedicated transformation languages tailored to specific transformation problems.

36. Essence of Model Transformation Languages What is common to the different rule-based transformation approaches? • Pre-/Post- condition patterns • Matching • Rewriting • Validation of consistent rule application • Matches manipulation • Iteration • Roll-back • Control flow • Choice • Concurrency • Composition

37. T-Core Primitive Transformation Operations T-Core Module • Pattern representation • Matches processed structure • 8 primitive transformation operators

38. T-Core Patterns • Dissociate pre- from post-condition patterns • Query vs. Rule • Embedded inside Matcher & Rewriter

39. T-Core Packet Data-Structure • Packet • Host graph • MatchSet • Matches for a given pattern • Match • Sub-model of interest • Pivot • Node binding (across match sets) • Parameterized rule • All messages exchanged

40. T-Core Core Operators Amalgamated Rules [20] • Dissociate Match from Rewrite: • match-rewrite- match-rewrite • match-match-match • match-match-rewrite-rewrite • Matcher • Find one, max, all (parameter) • Store matches in packet • Rewriter • Apply rewriting phase • Consume matches • Resolver • Conservative check of conflicts among match sets • Customizable resolution function [20] Rensink, A. and Kuperus, J.-H. (2009) Repotting the geraniums: On nested graph transformation rules. GT-VMT’09, EASST: 18, March 2009.

41. T-Core Match Manipulation • Iterator • Randomly choose a match in a match set • Number of iterations • Rollbacker • Ensure transactional behaviour • Restore packet when all matches exhausted • Number of iterations • Combine to handle multiple matches FUJABA loops

42. T-Core Control Flow • Selector • Can store packets • Select one on demand • Synchronizer • Can store packets • Merge packets on demand • Customizable merge function Priorities in AToM3

43. T-Core Composition • Meaningfully compose its sub-primitives • User-defined composition • Common interface

44. T-Core is... • A minimal collection of model transformation primitives • De-construct to optimal granularity • Not restricted to any form of specification of transformation unit • Rule-based, Constraint-based, Function-based • Bidirectional, Functional • Query, Transformation • Modularly encapsulates combinations of primitives • Composition • Re-use • Interface • Executable • Self-contained • Easily integrable

45. Transformation Language product line Primitive transformation operators (sub-set of) T-Core module + Scheduling language • Programming language (Python, Java) • Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)  Transformation Language

46. General purpose vs. Problem-specific Transformations • There are many transformation languages and tools out there • Very good at what they do • Most of them tend to provide a generic tool to solve any kind of model transformation problem • They must therefore be very expressive • Analysis of transformation models built using these general purpose transformation is very hard • One can use T-Core primitives to restrict a transformation language for one specific purpose • The expressiveness then depends on the glue language used and the primitive operators chosen

47. Problem-specific MTLs with T-Core

48. Fujaba: for-all Pattern [10] [10] Fischer, T., et. al., (2000) Story diagrams: A new graph rewrite language based on the UML and Java. In Ehrig, H., et al., (eds.), Theory and Application of Graph Transformations, LNCS, 1764, pp. 296–309. Springer-Verlag.

49. Fujaba: for-all Pattern

50. Fujaba: for-all Pattern