DSL Design Generic Language g Technology 2IS15 Model Transformations Language g Implementation Strategies Stand-alone Marcel van Amstel Embedding Translation / Software Engineering and Technology 9-1-2012 PAGE 2 Model Transformations Model Transformations Semi-Thue systems A model transformation is a mapping from a set of source models to a set of target models defined as a set of transformation rules.
Model Transformations Model transformation 9-1-2012 PAGE 6 Model Transformations Implementation approaches Model transformation formalisms Direct model manipulation Intermediate representation Model transformation language ATL Xtend Xtext Xpand QVT Relations QVT Operations QVT Core ASF+SDF Stratego/XT VIATRA Tefkat ETL (Epsilon) GrGen Platform: Eclipse and EMF 9-1-2012 PAGE 8
Model Transformations ATL characteristics: Hybrid language (declarative and imperative constructs) Transformation is a set of transformation rules and helpers OCL for source model navigation Limited escape mechanism to use Java In-place transformation simulated using refining mode The Atlas Transformation Language (ATL) is a hybrid language (a mix of declarative and imperative constructions) designed to express model transformations A model transformation in ATL is expressed as a set of transformation rules Hybrid style of programming: Declarative transformation based on simple mappings Imperative for complex mappings OCL is used to expression constraints on rules Guards (constraints) on the entry point for a rule Documentation: http://www.eclipse.org/gmt/atl/doc Documentation: www.eclipse.org/m2m/atl/doc/ 9-1-2012 PAGE 10 An ATL transformation program is composed of rules that define how source model elements are matched and navigated to create and initialize the elements of the target models The ATL programs for model to model transformation are called modules An example of an ATL specification The goal is to present a use case of a model to model transformation written in ATL This use case is named: Books to Publications Initially we have a text t describing a list of books We want to transform this into another text describing a list of publications 9-1-2012 PAGE 11 9-1-2012 PAGE 12
ATL: Book2Publication example ATL: Book2Publication example MMM Ecore MM a MM t MM b MM Book ATL MM Publication M t Book2Publication M a Transformation M b Book Transformation Publication 9-1-2012 PAGE 13 9-1-2012 PAGE 14 Meta-model of Book: Meta-model of Publication: Example of Book: 9-1-2012 PAGE 15 9-1-2012 PAGE 16
First we create an ATL project Getting started Select in Eclipse File/New/ATL Project Select then the Finish button First we have to create/ obtain meta-models Next we create an ATL file Getting started Select in Eclipse File/New/ATL File Select then the Next button 9-1-2012 PAGE 17 9-1-2012 PAGE 18 Next we have to set the Input/Output parameters of ATL transformation: Select then the Finish button A detailed description of the transformation can be found at: http://wiki.eclipse.org/atl/tutorials_- _Create_a_simple_ATL_transformation a transformation This will generate automatically the header section 9-1-2012 PAGE 19 9-1-2012 PAGE 20
ATL transformation code A header section that defines some attributes that are relative to the transformation module An optional import section that enables to import some existing ATL libraries A set of helpers that can be viewed as an ATL equivalent to Java methods Header: The header section names the transformation module and names the variables corresponding to the source and target models ("IN" and "OUT") together with their meta-models ( Book" and Publication") acting as types. module Book2Publication; create OUT : Publication from IN : Book; A set of rules that defines the way target models are generated from source ones 9-1-2012 PAGE 21 9-1-2012 PAGE 22 Libraries: The optional import section enables to declare which ATL libraries have to be imported The declaration of an ATL library is achieved as follows: uses extensionless_library_file_name; library name; ATL helpers ATL helpers can be viewed as the ATL equivalent to Java methods They make it possible to define factorized ATL code that can be called from different points of an ATL transformation Body of helpers is OCL code For example: uses strings; 9-1-2012 PAGE 23 9-1-2012 PAGE 24
An ATL helper is defined by the following elements: a name a context type The context type defines the context in which this attribute is defined Optional a return value type. Note that, in ATL, each helper must have a return value an OCL expression that represents the code of the ATL helper; an optional set of parameters, in which a parameter is identified by a couple (parameter name, parameter type). Helper functions: A helper is an auxiliary function that computes a result needed in a rule helper context Book!Book def : getauthors() : String = self.chapters-> collect(e e.author)-> asset()-> iterate(authorname, acc : String = '' acc + if acc = '' then authorname else ' and ' + authorname endif); 9-1-2012 PAGE 25 9-1-2012 PAGE 26 Select the chapters Get the authors of each chapter Filter duplicates To iterate over a collection helper context Book!Book def : getauthors() : String = self.chapters-> collect(e e.author)-> asset()-> iterate(authorname; acc : String = '' acc + if acc = '' then authorname else ' and ' + authorname endif); source -> iterate(elem, var : Type = init_exp body ) var is an accumulator which gets an initial value elem is an iterator which iterates on each element of the collection For each iteration body is evaluated and then used to update var Build a list 9-1-2012 PAGE 27 9-1-2012 PAGE 28
Helper To get the total of pages helper context Book!Book def : getnbpages() : Integer = self.chapters-> collect(f f.nbpages)-> iterate(pages, acc : Integer = 0 acc + pages); It is possible to consider a helper that returns the maximum of two integer values: the contextual integer and an additional integer value which is passed as parameter: helper context Integer def : max(x : Integer) : Integer =...; Alternative helper context Book!Book def : getnbpageseasy() : Integer = self.chapters -> collect(f f.nbpages) -> sum(); 9-1-2012 PAGE 29 9-1-2012 PAGE 30 ATL Rules There exist three different kinds of rules that correspond to the two different programming modes matched rules (declarative programming), lazy rules, called rules (imperative programming). ATL matched rule mechanism provides a mean to specify the way target model elements must be generated from source model elements. A matched rule enables to specify: 1. which source model element must be matched, 2. the number and the type of the generated target model elements, and 3. the way these target model elements must be initialized from the matched source elements 9-1-2012 PAGE 31 9-1-2012 PAGE 32
Each matched rule is identified by its name (rule_name). A matched rule name must be unique within an ATL transformation. An ATL matched rule is composed of two mandatory sections from and to parts. two optional sections: using and do parts. The different variables that may be declared in the scope of a rule (the source and target pattern elements and the local variables) must have a unique name. Matched rules rule rule_name{ from in: MM1!MetaClass(<matching condition>) using{<variable definitions> to out1: MM2!MetaClass1( <bindings1> ), out2: MM2!MetaClass2( <bindings2> ) do{<imperative block> Matches on all model elements of type MM1!MetaClass, similar to ASF s traversal functions 9-1-2012 PAGE 33 Rules rule Book2Publication { from b : Book!Book ( b.getnbpages() > 2 ) to out : Publication!Publication ( title <- b.title, authors <- b.getauthors(), nbpages <- b.getnbpages() ) Assigning attributes in ATL rules: In/out pattern Meta model identification Meta model element identification rule example1{ from in: MM1!MetaClassA to out: MM2!MetaClassB( attr <- in.attr ) Attribute assignment 9-1-2012 PAGE 35 9-1-2012 PAGE 36
Source pattern The from section corresponds to the rule source pattern. This pattern (a single source pattern element) contains the source variable declaration (in_var) of the type of the source model elements that will be matched by the rule (in_type). It may contain, between brackets, an optional boolean expression (condition) The following code illustrates the syntax of the from section: Assignment statement enables to assign target model element features target <- exp; from p : MMPerson!Person e ( p.name = 'Smith' ) 9-1-2012 PAGE 37 9-1-2012 PAGE 38 If statement enables to define alternative treatments if(condition) then { statement1 else { statement2 endif ATL imperative code For statement enables to define iterative imperative computations: for(iterator in collection) { statements Condition is an OCL expression 9-1-2012 PAGE 39 9-1-2012 PAGE 40
The initialization of the attributes of a generated target model element by assigning references: Model target element generated by current rule Default target model element generated by another rule Non-default target model element generated by another rule The first case (assigning g a model element produced by the same rule) is the simplest one: the considered reference can be initialized with the name of the other target pattern element consider the following example in which the rule Case1 has two target pattern model elements (o_1 and o_2), with o_1 having a reference to a Class2 model element defined (linktoclass2): rule Case1 { from i : MM_A!ClassA to o_1 : MM_B!Class1 ( linktoclass2 <- o_2 ), o_2 : MM_B!Class2 (... ) In the second case (assigning g the default target element of another rule): the considered reference has to be initialized with the source model element which is matched by the remote rule for generating the target model element to be assigned In the following example, the rule Case2_R1 aims to generate a target model element (o_1) that has a reference to a target model element that corresponds to the default target pattern (o_1) of the rule Case2_R2 Assuming that the source model element matched by Case2_R1 has a reference (linktoclassb) to the relevant MM_ A!ClassB source model element, this assignment is expressed as follows: rule Case2_R1 { from i : MM_A!ClassA to o_ 1 : MM_ B!Class1 ( linktoclass2 <- i.linktoclassb ) rule Case2_R2 { from i : MM_A!ClassB to o_1 : MM_B!Class2 (... ),...
rule Case2_R1 { from i : MM_A!ClassA to o_1 : MM_B!Class1 ( linktoclass2 <- i.linktoclassb ) rule Case2_R2 { from i : MM_A!ClassB to o_1 : MM_B!Class2 (... ),... Alternative (also used in the non-default target element) rule Case2_R1 { from i : MM_A!ClassA to o_1 : MM_B!Class1 ( linktoclass2 <- thismodule.resolvetemp(i.linktoclassb, o_1 ) ) rule Case2_R2 { from i : MM_ A!ClassB to o_1 : MM_B!Class2 (... ),... Example of assignments 9-1-2012 PAGE 46 Lazy rules Lazy rules are like matched rules, but are only applied when called by another rule 9-1-2012 PAGE 47 9-1-2012 PAGE 48
Lazy rules lazy rule rule_name{ from in: MM1!MetaClass using{<variable definitions> to out1: MM2!MetaClass1( <bindings1> ), out2: MM2!MetaClass2( <bindings2> ) do{<imperative block> Generates new target elements for every er call to the rule Invoked from other rules as follows: thismodule.rule_name(<model element of type MM1!MetaClass>) 9-1-2012 PAGE 50 Unique lazy matched rules unique lazy rule rule_name{ from in: MM1!MetaClass using{<variable definitions> to out1: MM2!MetaClass1( <bindings1> ), out2: MM2!MetaClass2( <bindings2> ) do{<imperative block> Always returns rns the same target elements for a given source element, i.e., target elements are generated only once per source element Called rules The called rules provide ATL developers with convenient imperative programming facilities. Called rules can be seen as a particular type of helpers: they have to be explicitly called to be executed and they can accept parameters called rules can generate target model elements as matched rules do A called rule has to be called from an imperative code section, either from a matched rule or another called rule A called rule does not include a source pattern 9-1-2012 PAGE 52
Called rules [entrypoint]? rule rule_name(<parameters>){ using{<variable definitions> to out1: MM2!MetaClass1( <bindings1> ), out2: MM2!MetaClass2( <bindings2> ) do{<imperative block> For generating target elements from imperative code No from clause Example of a called rule rule NewPerson (na: String, s_na: String) { to p : MMPerson!Person ( name <- na ) do { p.surname <- s_na 9-1-2012 PAGE 54 Besides matched rules, ATL defines an additional kind of rules enabling to explicitly generate target model elements from imperative code Except for the entrypoint called rule, this kind of rules must be explicitly called from an ATL imperative block. A called rule is identified by its name (rule_name). A called rule name must be unique within an ATL transformation must not collide with a helper name a called rule cannot be called "main" A called rule can optionally be declared as the transformation entrypoint/endpoint. p an ATL transformation can include one entrypoint/endpoint called rule. it is implicitly invoked at the beginning/ending of the transformation execution 9-1-2012 PAGE 55 9-1-2012 PAGE 56
Helper with context helper context MM!MetaClass def: helper_name(<parameters>): return_type = let <variable definition> in <expression>; Invocation: <model element of type MM!MetaClass>.helper_name(<parameters>) The context should never be of a collection type Helper without context helper def: helper_name(<parameters>): return_type = let <variable definition> in <expression>; Invocation: thismodule.helper_name(<parameters>) More reading material http://wiki.eclipse.org/atl/user_guide_- _Overview_of_the_Atlas_Transformation_Language http://wiki.eclipse.org/atl/user_guide_- _The_ATL_Language For OCL functions refer to the ATL user guide 9-1-2012 PAGE 58 Quality of Model Transformations Quality of Model Transformations MDE is gaining popularity are software too Academia Design Methodology Reuse Maintenance Industry
Quality of Model Transformations Quality of Model Transformations Reuse 1. As-is Maintenance 1. Corrective 2. With modify 2. Adaptive 3. Perfective 9-1-2012 PAGE 61 9-1-2012 PAGE 62 Quality of Model Transformations Quality of Model Transformation are software too Internal vs. external quality Design Methodology Maintenance Reuse Quality attributes t Understandability Modularity They should not become the next maintenance nightmare Modifiability Reusability Consistency Completeness Conciseness 9-1-2012 PAGE 63
Quality of Model Transformations Quality of Model Transformations Quality assessment techniques Direct quality assessment Metrics Indirect quality assessmente Debugging of domain-specific models Analysis of domain-specific models Determining the effect of a source model change 9-1-2012 PAGE 65 9-1-2012 PAGE 66 Quality of Model Transformations Quality of Model Transformations 9-1-2012 PAGE 67 9-1-2012 PAGE 68