DSL Design. Model Transformations. Model Transformations. Language g Implementation Strategies

Transcription

1 DSL Design Generic Language g Technology 2IS15 Model Transformations Language g Implementation Strategies Stand-alone Marcel van Amstel Embedding Translation / Software Engineering and Technology 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.

2 Model Transformations Model transformation 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 PAGE 8

3 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: Documentation: 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 PAGE PAGE 12

4 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 PAGE PAGE 14 Meta-model of Book: Meta-model of Publication: Example of Book: PAGE PAGE 16

5 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 PAGE 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: _Create_a_simple_ATL_transformation a transformation This will generate automatically the header section PAGE PAGE 20

6 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 PAGE 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; PAGE PAGE 24

7 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); PAGE 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 PAGE PAGE 28

8 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(); PAGE 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 PAGE PAGE 32

9 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 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 PAGE PAGE 36

10 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' ) PAGE 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 PAGE PAGE 40

11 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 (... ),...

12 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 PAGE 46 Lazy rules Lazy rules are like matched rules, but are only applied when called by another rule PAGE PAGE 48

13 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>) 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 PAGE 52

14 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 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 PAGE PAGE 56

15 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 _Overview_of_the_Atlas_Transformation_Language _The_ATL_Language For OCL functions refer to the ATL user guide PAGE 58 Quality of Model Transformations Quality of Model Transformations MDE is gaining popularity are software too Academia Design Methodology Reuse Maintenance Industry

16 Quality of Model Transformations Quality of Model Transformations Reuse 1. As-is Maintenance 1. Corrective 2. With modify 2. Adaptive 3. Perfective PAGE 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 PAGE 63

17 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 PAGE PAGE 66 Quality of Model Transformations Quality of Model Transformations PAGE PAGE 68