Model Transformation

1. Model Transformation Eugene Syriani and Hans Vangheluwe

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

3. 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)]

4. In a model-driven engineering (MDE) framework • Everything is modelled Therefore a change will always be on a model. • We explicitly model everything 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’ MM MM MM’ conforms to conforms to conforms to  M M’

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

6. Uses & Needs In Language Engineering The meta-model of a language L defines: • The abstract syntax of L • The static semantics of L A transformation defined on L can define the dynamic semantics of L (how model instances behave) • Denotational semantics More specifically, translational semantics. The transformation defines a mapping between the two formalisms. 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.

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

8. 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 e • if e == 0: # event “e" • if table[1] andself.isInState(1) andself.testCondition(3): • if (scheduler == selfor 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 == selfor 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 s1 s2 Statecharts model Generated Python code

9. 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

10. 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. Class diagram meta-model

11. 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

12. Types of transformations A model transformation performs a manipulation on a model. • 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)

13. Types of transformations • Query A query is still a transformation. • What is a query? • 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. • 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.

14. Types of transformations • Query • Different views for different observers • 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 • This is called model synchronization Repository

15. 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

16. 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 PhoneApps DSM of a conference registration mobile application Generated AndroidAppsFiles

17. 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

18. Types of transformations • Common Uses of Model Transformation • Reverse Engineering Inverse of synthesis: extract higher-level specifications from lower-level ones • 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. Statechart representing a conference registration model PhoneApps DSM of the same model

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

20. 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 Enterprise Java Beans 2.0 Enterprise Java Beans 3.0

21. 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 List to table optimization

22. 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 Pull up method refactoring

23. 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 H H H C C O H CH3 CH2 OH H H

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

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

26. 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

27. Classification of the types of transformations 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

28. Classification of the types of transformations 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)

29. Classification of the types of transformations 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. refactor/optimize Code DSM in CS ASG parse synthesize Model transformation chain to compile a DSM into executable Java code ASG’ migrate synthesize

30. 2 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. • 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.

31. 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

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

33. Family of Transformation Languages • Features of model transformation languages [Czarnecki06] • 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

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

35. 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 QVT-Relations rule [OMG08] • top relationPackageToSchema { • domainuml p:Package {name = pn} • domainrdbms s:Schema {name = pn} • }

36. 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

37. Family of Transformation Languages • Domain Body • Logic How computations & constraints are specified on model elements

38. Family of Transformation Languages • Domain Body • Logic Declarative vs. Imperative QVT-Relations rule Kermeta operation [Falleri06] • 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

39. Family of Transformation Languages • Domain of Rule • Typing of variables, patterns, and logic • Untyped: free text / free hand drawing • Syntactical typing: variable is associated witha 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 rulewill satisfy certain properties, if the input modelsatisfies some properties. FUJABA [Fischer00] transformation pattern

40. 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. FUJABA: compact notation MoTif [Syriani09a] 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 rule

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

42. Family of Transformation Languages • Application Conditions Pre-condition for the rule before it is executed • QVT-R: when clause • AToM3: rule-level constraint [Lara02] • 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); • } • }

43. Family of Transformation Languages • Intermediate Structures Creation of additional elements which are not part of the domain • AToM3: 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. MoTif rule

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

45. 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) VIATRA generic rule

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

47. Family of Transformation Languages • Rule Scheduling • Form • Implicit: completely determined by the design logic of the rules • 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) • Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10] Rules: Model: ,

48. 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. • 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); • } • }

49. 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: priority, layer/phased, explicit workflow structure, … • Event-driven: rule execution is triggered by external events

50. Family of Transformation Languages • Rule Scheduling Priority-based: AToM3