1. Model Transformation Eugene SyrianiandHans Vangheluwe

2. Model Transformation Outline 1.What is Model Transformation? Terminology Types of transformations 2.A Family of Transformation Languages Classification 3.Rule-based Transformation How does it work? Tour of Existing Tools Understanding the essence of rule-based model transformation 4.It’s just the beginning... 2

3. Model Transformation 1 What is Model Transformation? “The process of converting one model to another model of the same system.” [OMG03] “The automatic generation of a target model from a source model, according to a transformation definition.” [Kleppe03] “A manipulation of a model with a specific intention.” [Syriani(DSM-TP’10)] 3

4. Model Transformation In a model-driven engineering (MDE) framework modelled Everything is modelled changeon Therefore a change will always be on a model. model We explicitly model everything modelled  A change or modification must itself be modelled  models of transformations.  represents an intentional change (or alteration) of M, which yields M’ MM  defines all possible changes for the same intention from an instance of MM to an instance of MM’ 4 MM’  MMMM’MM  conforms to

5. Model Transformation Terminology Model-to-model transformation Multiple sources Multiple targets The transformation can be interpreted or the result of compilation 5 Target Meta-model Target Meta-model Transformation Definition Transformation Definition Target Model Target Model Source Model Source Model Source Meta-model Source Meta-model readsoutputs refers to conforms to executes conforms to

6. Model Transformation Uses & Needs In Language Engineering The meta-model of a language L defines: 1.The abstract syntax of L 2.The static semantics of L dynamic semantics A transformation defined on L can define the dynamic semantics of L (how model instances behave) Denotational semantics mapping More specifically, translational semantics. The transformation defines a mapping between the two formalisms. semantics This occurs when we transform a model in one formalism into a model in another formalism. Then the semantics of the source formalism is given in terms of the semantics of the target formalism. 6

7. Model Transformation Uses & Needs In Language Engineering Denotational semantics Inter-formalism transformation (a.k.a. model-to-model transformation) PhoneApps To Statecharts [Mannadiar10] 7 PhoneApps DSM of a conference registration mobile applicationRepresentation of the model in Statecharts

8. Model Transformation Uses & Needs In Language Engineering Denotational semantics Code generation (a.k.a. model-to-code transformation) This is a special case of model-to-model transformation. The abstract syntax of programming languages is typically modelled by a grammar. The abstract syntax of a program is then an abstract syntax tree. Statecharts to Python Compiler 8 Statecharts modelGenerated Python code if e == 0:# event “e" if table[1] and self.isInState(1) and self.testCondition(3): if (scheduler == self or scheduler == None) and table[1]: self.runActionCode(4)# output action(s1) self.runExitActionsForStates(-1) self.clearEnteredStates() self.changeState(1, 0) self.runEnterActionsForStates(self.StatesEntered, 1) self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table) handled = 1 if table[0] and self.isInState(0) and self.testCondition(4): if (scheduler == self or scheduler == None) and table[0]: self.runActionCode(5)# output action(s2) self.runExitActionsForStates(-1) self.clearEnteredStates() self.changeState(0, 0) self.runEnterActionsForStates(self.StatesEntered, 1) self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table) handled = 1 e

9. Model Transformation Uses & Needs In Language Engineering Operational semantics Update the state of the system modelled. In this case, the source and target meta-models are identical. Moreover, the target model is an “updated” version of the source model: no new model is created Finite State Automata Simulator 9

10. Model Transformation Uses & Needs In Language Engineering Meta-model instance generation Automatically generate random models that conform to the language. This is very useful, especially for model-based testing. 10 Class diagram meta-model

11. Model Transformation Uses & Needs In Language Engineering Relation between Abstract and Concrete syntax Model transformation can be used to specify mappings within the language too. It can be used only if both the abstract and concrete syntax are themselves modelled. Mapping from the abstract syntax to possibly several concrete representations (textual, graphical,...)  1 abstract syntax to many concrete syntaxes Parser from the concrete syntax to the corresponding abstract syntax (graph)  1 concrete syntax to 1 abstract syntax 11

12. Model Transformation Types of transformations manipulation A model transformation performs a manipulation on a model. Access/Modify operations Simple operations on a model: Add Add an element to the model; Remove Remove an element from the model; Update Update an element’s properties; Access Access an element or its properties. These primitive operations are know as the CRUD operations (Create, Read, Update, Delete) 12

13. Model Transformation Types of transformations Query A query is still a transformation. What is a query? information A query is an operation that requests some information about a system. This operation takes as input the model M and outputs a view of M. view A view is a projection of (a sub-set of) 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  Is a query a transformation? It is a projection, obtained by CRUD operations on the properties of M. 13

14. Model Transformation Types of transformations Query Different views for different observers repository Views must be kept consistent with the repository This can be ensured by a model transformation that defines a relation between the repository and a view [Guerra06] Read-only views: propagate any changes from repository to all views (or some of them) Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other views model synchronization This is called model synchronization 14 Repository

15. Model Transformation Types of transformations Common Uses of Model Transformation (inspiration from [Mens06]) Synthesis Transform from a higher level specification to a lower level description Code Generation Source code translated into machine code Design models translated into source code 15

16. Model Transformation Types of transformations Common Uses of Model Transformation (inspiration from [Mens06]) Synthesis Transform from a higher level specification to a lower level description Code Generation DSM compiled into an executable implementation 16 PhoneApps DSM of a conference registration mobile applicationGenerated AndroidAppsFiles

17. Model Transformation Types of transformations Common Uses of Model Transformation Reverse Engineering Inverse of synthesis: extract higher-level specifications from lower-level ones C# to UML Class Diagram 17

18. Model Transformation Types of transformations Common Uses of Model Transformation Reverse Engineering Inverse of synthesis: extract higher-level specifications from lower-level ones bi-directional transformation If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1, then T is said to be a bi-directional transformation. 18 PhoneApps DSM of the same modelStatechart representing a conference registration model

19. Model Transformation Types of transformations Common Uses of Model Transformation Simulation Update the state of the model Operational semantics 19

20. Model Transformation Types of transformations Common Uses of Model Transformation 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 20 Enterprise Java Beans 3.0Enterprise Java Beans 2.0

21. Model Transformation Types of transformations Common Uses of Model Transformation Optimization Improve certain operational qualities of the model while preserving its semantics Typically used on architecture or design models 21 List to table optimization

22. Model Transformation Types of transformations Common Uses of Model Transformation Restructuring Change the internal structure of the model to improve certain quality characteristics without changing its observable behaviour (Understandability, modifiability, reusability, modularity, adaptability) Refactoring: restructuring in an object-oriented context 22 Pull up method refactoring

23. Model Transformation Types of transformations Common Uses of Model Transformation Normalization Decrease syntactic complexity Desugaring: Translate 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 23 HH H H C H H CO CH 3 CH 2 OH

24. Model Transformation Types of transformations Common Uses of Model Transformation Composition Integrate models that have been produced in isolation into a compound model 24 Model merging Model weaving

25. Model Transformation Types of transformations Common Uses of Model Transformation 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 Incremental / Change-driven Source model changes are propagated to corresponding target model changes: Incremental / Change-driven transformation. multi-directional Synchronization must be ensured in both directions: multi-directional transformation. Inconsistency management Inconsistency management 25 Repository

26. Model Transformation Classification of the types of transformations Relationship between source & target meta-models Endogenous: Source meta-model = Target meta-model Exogenous: Source meta-model ≠ Target meta-model Relationship between source & target models In-place: Transformation executed within the same model Out-place: Transformation produces a different model 26 EndogenousExogenousEither In-placeAccess/Modify, SimulationXX Out-place Restrictive query, Simplification Aggregate query, Synthesis, Reverse engineering, Migration, Desugaring Composition, Synchronization EitherOptimization, RestructuringXX

27. Model Transformation Classification of the types of transformations Abstraction level Horizontal: source and target models reside at the same abstraction level. Vertical: source and target models reside at different abstraction levels 27 EndogenousExogenousEither Horizontal Access/Modify, Simulation, API migration Language migrationComposition Vertical Formal refinement, Restructuring, Restrictive query, Optimization, Simplification Aggregate query, Synthesis, Reverse engineering, DesugaringX

28. Model Transformation Classification of the types of transformations What about composition? It is certainly out-place, but it also depends if: Merging different views of the same repository Interoperating with other languages Merging an old version of the model with a newer one What about synchronization? It is orthogonal to the other types It is certainly out-place You can synchronize any two models as long as you give it a precise meaning. Synthesis + reverse-engineering (in loop) Refactoring or migration (if retaining snapshots of all versions) 28

29. Model Transformation Classification of the types of transformations Syntactical vs. Semantical Transformations A syntactical transformation solely modifies the representation of the model In a semantical transformation, the output model has a different meaning than the input model, although the representation of the latter may or may not have been modified. 29 DSM in CS ASG Code parserefactor/optimizesynthesize ASG’ synthesize migrate Model transformation chain to compile a DSM into executable Java code SyntacticalQuerySynthesis Reverse Engineering SimplificationDesugaring-- Semantical Access / Modify SimulationMigrationOptimizationRestructuringCompositionSynchronization

30. Model Transformation 2 Family of Transformation Languages Model Transformation has many applications: Generatereverse engineering Generate PSMs form PIMs and reverse engineering Mapsynchronize Map and synchronize among models at the same or different level of abstraction views Create views of a system evolution 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. We will now explore all the features that a model transformation language can have. It covers more than what current tools support but this framework may change because of the very active research in the field. 30

31. Model Transformation Family of Transformation Languages Feature diagram [Kang90] Hierarchy of common and variable features characterizing the set of instances of a concept. Tree-like structure where each combination of the leaves yields one possible instance of the concept. (sub-set of) Elements of a Feature Diagram Root: Concept Mandatory sub-feature: parent feature cannot exist without sub-feature Optional sub-feature: sub-feature may or may not be present Sub-features: by default OR Alternative sub-features: XOR Group: typical features, does not cover all possibilities Leaf: primitive feature, but maybe split in further sub-feature at a later stage 31

32. Model Transformation Family of Transformation Languages Feature diagram Example: 32

33. Model Transformation Family of Transformation Languages Features of model transformation languages [Czarnecki06] 33 Specification Pre/post condition on the transformation: Function between source & target models Relation may be executable or not Transformation Rules Smallest transformation unit, used to specify a transformation Rule-based transformations Rule-based transformations: pre-condition & post-condition for rewriting Transformation units defined as functions Templates Rule Organization General structuring issues of rules Modularization Composition Re-use Source-Target Relationship In-place Out-place 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) Tracing Mechanisms for recording different aspects of transformation execution: Create & maintain trace links between source & target model elements Rule Application Control Where is a rule applied on the model In what order are the rules executed

34. Model Transformation Family of Transformation Languages Transformation Rules Smallest transformation units A model transformation is mainly specified in terms of rules 34 : :

35. Model Transformation Family of Transformation Languages Domain Defines how a rule can access elements of the models 1..* domains: examples of 1-way transformation? 2-way? n-way? Domain language The language in which models are defined. Typically MOF [OMG06] Modes Read-only: source domain of synthesis Write-only: target domain of synthesis Read-write: domain of simulation 35 top relation PackageToSchema { domain uml p:Package {name = pn} domain rdbms s:Schema {name = pn} } QVT-Relations rule [OMG08]

36. Model Transformation Family of Transformation Languages Domain Body Patterns Model fragment internally represented as: Strings: Template-based transformation Terms: tree representation of models Graph: Model-to-model transformation 36

37. Model Transformation Family of Transformation Languages Domain Body Logic How computations & constraints are specified on model elements 37 ImperativeDeclarative Executable Java API for MOF models OCL query Non-executableX QVT-R relation

38. Model Transformation Family of Transformation Languages Domain Body Logic Declarative vs. Imperative 38 Kermeta operation [Falleri06] operation transform(source:PackageHierarchy): DataBase is do result := DataBase.new trace.initStep(“uml2db”) source.hierarchy.each{ pkg | var scm: Schema init Schema.new scm.name := String.clone(pkg.name) result.schema.add(scm) trace.addlink(“uml2db”, “package2schema", pkg, scm) } end top relation PackageToSchema { domain uml p:Package{name=pn} domain rdbms s:Schema{name=pn} } QVT-Relations rule

39. Model Transformation Family of Transformation Languages Domain of Rule Typing of variables, patterns, and logic Untyped: free text / free hand drawing Syntactical typing: variable is associated with a meta-model element & can hold its instances Semantical typing: Static semantics: well-formed rules Dynamic semantics: behavioural properties (DSLTrans) Example of type system: Ensure the output of a rule will satisfy certain properties, if the input model satisfies some properties. 39 FUJABA [Fischer00] transformation pattern

40. Model Transformation Family of Transformation Languages Syntactic Separation Clear separation of parts of the rule operating on the source model from the parts operating on the target model. 40 module Person2Contact; create OUT: MMb from IN: MMa { rule Start { form p: MMa!Person( p.function = ‘Boss’ ) to c: MMb!Contact( name <- p.first_name + p.last_name) } MoTif [Syriani09a] rule ATL rule FUJABA: compact notation

41. Model Transformation Family of Transformation Languages Multi-directionality Ability to execute a rule in different directions. E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94] 41 top relation PackageToSchema { domain uml p:Package {name = n} domain rdbms s:Schema {name = n} } QVT-Relations rule TGG rule

42. Model Transformation Family of Transformation Languages Application Conditions Pre-condition for the rule before it is executed QVT-R: when clause AToM 3 : rule-level constraint [Lara02] 42 top relation ClassToTable { domain uml c:Class { package = p:Package{}, isPersistent = true, name = cn } domain rdbms 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); }

43. Model Transformation Family of Transformation Languages Intermediate Structures Creation of additional elements which are not part of the domain AToM 3 : generic links ATL: automatic creation of traceability links. Each newly created element is linked back to element(s) of the source model. AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on the same element. 43 MoTif rule

44. Model Transformation Family of Transformation Languages Parameterization Control Parameters Pre-defined binding of some model elements ProGreS: variable parameter passing [Zundorf94] GReAT: pivot nodes [Agrawal06] 44 ProGreS in/out parameters GReAT pivot passing

45. Model Transformation Family of Transformation Languages Parameterization Generics Pass element types to rules In this case, the types of the elements in the patterns are variable Higher-Order Transformation Rule Takes a rule as input and outputs another rule (see “Higher-Order Transformation” lecture) 45 VIATRA generic rule

46. Model Transformation Family of Transformation Languages Location Determination Strategy for determining the application locations of a rule 46 Model: Rule:

47. Model Transformation Family of Transformation Languages Rule Scheduling Form Implicit: completely determined by the design logic of the rules Unordered Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration Grammar Grammar: unordered with start model and terminal states (generation or recognition) Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10] 47 Model:Rules:,

48. Model Transformation Family of Transformation Languages Rule Scheduling Form Explicit internal: a rule may invoke other rules. In ATL [Jouault08], 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. 48 top relation ClassToTable { domain uml c:Class { package = p:Package{}, isPersistent = true, name = cn } domain rdbms 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); }

49. Model Transformation Family of Transformation Languages Rule Scheduling Form Explicit external: Clear separation between the rules and the scheduling logic. Use a control structure to define rule scheduling Ordered Ordered: priority, layer/phased, explicit workflow structure, … Event-driven Event-driven: rule execution is triggered by external events 49

50. Model Transformation Family of Transformation Languages Rule Scheduling Priority-based: AToM 3 50

51. Model Transformation Family of Transformation Languages Rule Scheduling Layered/Phased: AGG 51

52. Model Transformation Family of Transformation Languages Rule Scheduling Explicit workflow 52 GReAT data flow FUJABA story diagram

53. Model Transformation Family of Transformation Languages Explicit Scheduling features [Syriani09] 53 PRoGReSFUJABAVIATRAAToM 3 GReAT VMTS [Lengyel06] MoTif Control structure Imperative language Story Diagram Abstract state machine Priority ordering Data flow Activity diagram DEVS Atomicity transaction, rule RulegtruleRuleExpressionStepARule Sequencing&YesseqImplicitYes Branchingchoose...elseBranch activityif-then-elseNoTest / Case Decision step, OCL Query LoopingloopFor-all patterniterate, forallImplicitYesSelf loop FRule, SRule, LRule Non- determinism and, orNorandomWithin layer 1−n connection No Selector pattern RecursionYesNoYesNoYes ParallelismNoOptionalNoOptionalNoFork, Join Synchronizer pattern Back- tracking ImplicitNo choose (implicit) No XRule HierarchyModularisationNested stateYesNo Block, ForBlock High-level step CRule

54. Model Transformation Family of Transformation Languages Explicit Scheduling features What these languages/tools have in common: Graph transformation Graph transformation (GT) paradigm with explicit external scheduling Not complete list: AGG: layered graph transformation MOLA [Kalnins05]: structured flowchart T-Core [Syriani10]: primitive graph transformation operators combined with Python DSLTrans:... and many more Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta 54

55. Model Transformation Family of Transformation Languages Rule Organization Modularization: Package rules into modules. Module imports (QVT, VIATRA, ATL) Reuse: Define rules based on other rules. QVT specification presents very sophisticated reuse mechanisms, but no implementation of it. ATL allows a rule to inherit from another rule: union of pre-conditions and bindings. 55

56. Model Transformation Family of Transformation Languages Source-Target relationship Graph transformation approaches are in-place by construction ATL is out-place only. QVT allows creating a new model or updating an existing one. Extension Only updates: an existing element (source or already created) may not be deleted Destructive update: emulates out-place transformations by first creating new elements and then deleting source model elements 56

57. Model Transformation Family of Transformation Languages Incrementality incremental transformation An incremental transformation is defined as a set of relations between a source and target meta- models. These relations define constraints on models to be synchronized. The first time it is run, it creates a target model. Trace links are often automatically created. propagates Then, if a change is detected in one of the models, it propagates this change to the other model, by adding, removing, or updating an element so that the relations are still satisfied. There are 4 standard scenarios in model synchronization: Create a target model from the source model Propagate changes in the source model to the target model Propagate changes in the target model to the source model Verify consistency between the two models 57

58. Model Transformation Family of Transformation Languages Directionality Unidirectional : create (or update) the target model only Multi-directional: can be executed in any direction Need multi-directional rules Define separate unidirectional rules, one for each direction Operational Operational rules have a functional character: given an input model, produce a target model.  Causality  Causality from source to target model Declarative Declarative rules: gives a relation between both models that must be satisfied  Acausal  Acausal relationship between the models 58

59. Model Transformation Family of Transformation Languages TGG rules are bi-directional The denotational rules are converted into operational rules: 59 TGG rule 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] TGG operational rules

60. Model Transformation Family of Transformation Languages Tracing is the runtime footprint of a transformation execution Traceability links Traceability links connect source & target elements They are instances of the mappings between the domains Impact analysis Direction of the synchronization Debugging transformations Automatic creation of trace links: QVT, ATL Traces can be considered as any other model, but has to be manually created: e.g., AGG, AToM 3, VIATRA 60

61. Model Transformation Different Model Transformation Approaches Model-to-text (concrete syntax) Visitor-based: traverse the model in an object-oriented framework Template-based: target syntax with meta-code to access source model Model-to-Model Direct manipulation: access to the API of M3 and modify the models directly Operational: similar to direct manipulation but at the model-level (OCL) Rule-based Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of describing operations on models. Relational: declarative describing mathematical relations. It define constraints relating source and target elements that need to be solved. They are naturally multi-directional, but in-place transformation is harder to achieve 61

62. Model Transformation 3 Rule-based Transformation By Example: Simplified PacMan formalism [Heckel06] 62

63. Model Transformation Rule-based Transformation Build the meta-model of the PacMan formalism in AToM 3 63

64. Model Transformation Rule-based Transformation Build the graph transformation to specify the semantics of the language 64

65. Model Transformation Rule-based Transformation Build the graph transformation to specify the semantics of the language 65 1 4 2 1 2 5 pacLink 3 ghostLink 3 1: return self.LHS.nodeWithLabel(1).score + 1 1 2 3 1 2 3 5 4 pacLink foodLink 6 4 pacLink P 1 P 2

66. Model Transformation Rule-based Transformation Build the graph transformation to specify the semantics of the language 66 4 12 3 5 gridLeft ghostLink 12 3 4 6 gridLeft ghostLink 4 12 6 gridRight pacLink 12 4 5 gridRight pacLink 3 3 P 3

67. Model Transformation Rule-based Transformation Simulation of a model 67 1.pacmanDie 2.pacmanEat 3.ghostMoveLeft 4.ghostMoveRight 5.ghostMoveUp 6.ghostMoveDown 7.pacmanMoveLeft 8.pacmanMoveRight 9.pacmanMoveUp 10.pacmanMoveDown P1 P2 P3

68. Model Transformation Rule-based Transformation Mechanics of Rule Application 68 right left right left updownupdown right LKR G gLinkgLink gLink pLinkfLink left right left updownupdown G’ gLink pLinkfLink m If there exists an occurrence of L in G then replace it with R

69. Model Transformation Rule-based Transformation Mechanics of Rule Application Matching Phase Find an embedding ( m ) of the LHS pattern ( L ) in the host graph ( G ). match An occurrence of L is called a match: m(L). Thus, m(L) is a sub-graph of G. Rewriting Phase Transform G so that it satisfies the RHS pattern: 1.Remove 1.Remove all elements from m(L-K) from G. 2.Create 2.Create the new elements of R-K in G. 3.Update 3.Update the properties of the elements in m(L  K). applicable When a match of the LHS can be found in G, the rule is applicable. applied When the rewriting phase has been performed, the rule was successfully applied. 69

70. Model Transformation Rule-based Transformation How to find a match? The matching phase is NP-Complete, the rewriting phase is linear. There are various exponential-time worst case solutions for pattern matching, for which the average-time complexity can be reduced with the help of heuristics. Search Plan Approach Define the traversal order for the nodes of the model to check whether the LHS can be matched. Compute the cost tree of the different search paths and choosing the less costly one. Complex model-specific optimization steps can be carried out for generating efficient adaptive search plans. Constraint Satisfaction Solving Approach Consider the LHS elements as variables, the elements of model form the domain and typing, and the links and attribute values form the set of constraints. Based on back-tracking algorithms. 70

71. Model Transformation Rule-based Transformation Complexity of a rule What is the worst upper-bound of the complexity for applying a rule?  O(|L| |G| + |R|) = O(|L| |G| )  O(|L| |G| + |R|) = O(|L| |G| ) CRUD operations 71

72. Model Transformation Most Used Rule-based Transformation Tools Programmed Graph Rewriting System: ProGReS 72 Manfred NaglAndy SchürrAlbert Zündorf 1988-1999 University of Aachen (Germany)

73. Model Transformation Most Used Rule-based Transformation Tools Programmed Graph Rewriting System: ProGReS 73

74. Model Transformation Most Used Rule-based Transformation Tools From UML to JAVA And Back Again: FUJABA 74 Since 1998 Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)

75. Model Transformation Most Used Rule-based Transformation Tools From UML to JAVA And Back Again: FUJABA 75

76. Model Transformation Most Used Rule-based Transformation Tools MOFLON 76 Since 2004 University of Darmstadt (Germany)

77. Model Transformation Most Used Rule-based Transformation Tools MOFLON 77

78. Model Transformation Most Used Rule-based Transformation Tools Graph Rewriting and Transformation: GReAT 78 Gabor KarsaiAditya Agrawal Since 2001 Vanderbilt University, Nashville (USA)

79. Model Transformation Most Used Rule-based Transformation Tools 79 Graph Rewriting and Transformation: GReAT

80. Model Transformation Most Used Rule-based Transformation Tools Visual Modelling and Transformation System: VMTS 80 Since 2004 Budapest University of Technology and Economics (Hungary) Tihamér LevendovszkyLászló Lengyel

81. Model Transformation Most Used Rule-based Transformation Tools 81 Visual Modelling and Transformation System: VMTS

82. Model Transformation Most Used Rule-based Transformation Tools Graph Rewriting and Transformation: VIATRA 82 Since 2002, VIATRA2 since 2006 Budapest University of Technology and Economics (Hungary) Dániel Varró

83. Model Transformation Most Used Rule-based Transformation Tools Graph Rewriting and Transformation: VIATRA 83

84. Model Transformation Most Used Rule-based Transformation Tools ATLAS Transformation Language: ATL 84 Since 2005 École des Mines de Nantes (France) Jean BézivinFrédéric Jouault

85. Model Transformation Most Used Rule-based Transformation Tools ATLAS Transformation Language: ATL 85

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

87. Model Transformation Primitive Transformation Operations T-Core Module [Syriani10] 87 Pattern representation Matches processed structure 8 primitive transformation operators

88. Model Transformation Primitive Transformation Operations T-Core Module 88 Dissociate pre- from post-condition patterns ‒ Query vs. Rule ‒ Embedded inside Matcher & Rewriter

89. Model Transformation Primitive Transformation Operations T-Core Module 89 Packet ‒ Host graph MatchSet ‒ Matches for a given pattern Match ‒ Sub-model of interest Pivot ‒ Node binding (across match sets) ‒ Parameterized rule

90. Model Transformation Primitive Transformation Operations T-Core Module 90 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

91. Model Transformation Primitive Transformation Operations T-Core Module 91 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

92. Model Transformation Primitive Transformation Operations T-Core Module 92 Selector ‒ Can store packets ‒ Select one on demand Synchronizer ‒ Can store packets ‒ Merge packets on demand ‒ Customizable merge function

93. Model Transformation Primitive Transformation Operations T-Core Module 93 Meaningfully compose its sub- primitives User-defined composition Common interface

94. Model Transformation Primitive Transformation Operations 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 94

95. Model Transformation Primitive Transformation Operations There are many transformation languages and tools out there. They are very good at what they do. Also, most of them tend to provide a generic tool to solve any kind of model transformation problem. Because of the high amount of expressiveness, analysis of transformation models built using these general purpose transformation is very hard. Providing control over T-Core primitives allows to restrict a transformation language for one specific purpose. It depends on the expressiveness of the glue language used and the primitive operators chosen. 95

96. Model Transformation Primitive Transformation Operations 96

97. Model Transformation Primitive Transformation Operations Query 97

98. Model Transformation Primitive Transformation Operations Atomic Rule 98

99. Model Transformation Primitive Transformation Operations Rule applied as long as possible 99

100. Model Transformation Primitive Transformation Operations Combining rules with Python 100

101. Model Transformation 4 What is Required for Industrial Adoption? Scalability Scalability Size of source model How big of a model can be handled: 10 3, 10 5, 10 6 elements? Size of transformation Size of the total sequence of rules applied Number of rules evaluated at a given point ? Interoperability Treat transformations as black-boxes but ensure the communcation between them Common formalism acting as a “bus” Expressiveness Expressiveness Pattern language Scheduling language Reversibility / Bidirectionality Reversibility / Bidirectionality Handle arbitrarily complex attribute constraints 101

102. Model Transformation What is Required for Industrial Adoption? Analysis Analysis Model Checking Input & output model Transformation model Verification Transformation: correct application, property satisfaction Rules: parallel independence Testing Testing Adequate test input How to assess quality of models? Adequate design of oracle Generic? Domain specific? Transformation specific? 102

103. Model Transformation What is Required for Industrial Adoption? Debugging Debugging Transformation Appropriate support for user to determine origin of failure Generated Artefacts Debug in terms of output model (or input model) Profiling Profiling Time efficiency Profile results in terms of transformations, domain-specific Traceability Traceability Trace back to origin of error Trace back to which element the created/modified element originated form Evolution Evolution Of the languages Of the transformations 103

104. Model Transformation Making a Well-Informed Choice Commercial point of view Evaluate a tool Types of transformations supported Transformation class Supported features Be up-to-date with recent innovations Research point of view What is still open for research Be aware of what has been solved Challenges 104

105. Model Transformation References [OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12. [Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And Promise. Addison-Wesley, 2003. [Mannadiar10] 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. [Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142 Tallinn (Estonia), March 2006. [Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06, LNCS: 4178, pp. 351-366, Springer-Verlag, 2006. [Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute, Carnegie Mellon University, November 1990. [Czarnecki06] 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. [OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006. [OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008. [Fischer00] 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), November 2000. 105

106. Model Transformation References [Falleri06] 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. [Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in Computer Science, LNCS: 903, pp. 151-163, Springer-Verlag. Heidelberg (Germany), June 1994. [Lara02] de Lara, J. & Vangheluwe, H. AToM 3 : A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS: 2306, pp. 174-188, Springer-Verlag. Grenoble (France), April 2002. [Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software. AGTIVE'03, LNCS: 3062, pp. 446-453, Springer-Verlag, 2004. [Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of Computer Programming, 68, no. 3, pp. 214-234, Elsevier North-Holland, 2007. [Zundorf94] 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. [Agrawal06] 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. [Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp. 479-485, Springer-Verlag, 2004. [Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental Approaches to Software Engineering, LNCS: 6013, pp. 29-43, Springer, 2010. [Jouault08] 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. 106

107. Model Transformation References [Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997. [Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2, School of Computer Science, March 2009. [Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow Language. IJCS, 1, no. 1, pp. 45-53, 2006. [Syriani09a] 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. [Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS: 3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005. [Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29 (GT-VMT'10), Paphos (Cyprus), March 2010. [Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier 2006. 107

108. Model Transformation Additional References The following web page offers around 240 literature citations in the field of model transformation It provides more details in each topic outlined in this talk and more http://msdl.cs.mcgill.ca/people/eugene/30_litterature 108