Two Basic Correctness Properties for ATL Transformations: Executability and Coverage (MtATL 2011)
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Two Basic Correctness Properties for ATL Transformations: Executability and Coverage (MtATL 2011)

  • 264 views
Uploaded on

 

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
264
On Slideshare
263
From Embeds
1
Number of Embeds
1

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 1

https://www.linkedin.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Good morning everybody. My name is Elena Planas and I will present two Basic Correctness Properties for ATL Transformations.
  • Well, let me begin by explaining the context where this work is situated. Model transformations play a key role with the emergence of Model Driven Engineering, where models are transformed from higher to lower levels of abstraction. In consequence, the quality of the whole transformation process strongly depends on the quality of the parcial model transformations . There is a wide set of research proposals focused on model transformations (for instance: tools for editing, analyzing and testing model transformations). But, however, there is still further work to be done regarding its verification. In particular, there is a lack of efficient methods to analyze rule correctness with respect to the source and target metamodels.
  • In order to alleviate this situation, our GOAL is to define two basic correctness properties of model transformation rules and to propose a method to check these properties. Two outstanding FEATURES of our method are: Fristly, it is a lightweight method : That is, in order to improve its efficiency, our method performs an static analysis without any need to execute the rules. And, secondly, it returns meaningful feedback : If the checked property is not satisfied, the method returns feedback suggesting possible corrections to repair the detected errors. The presented work is only FOCUSED on ATL matched rules, that is, declarative rules that define how the source model elements are matched and navigated to create and initialize the target model elements.
  • The first property we define is called WEAK EXECUTABILITY of an ATL rule.
  • We consider an ATL rule is weakly executable if it has a chance of being successfully executed. That is, if we can find at least one source model on which the rule can be applied and its execution generates a target model consistent with the system's integrity constraints, then, we consider the rule is weakly executable. Otherwise, the rule is useless, as every time it is executed, an error arises because the target model violates some integrity constraints.
  • As an EXAMPLE , consider the following metamodels. The left diagram shows the source metamodel , that consists of people having a name, age and college name. The right diagram shows the target metamodel , that consists of students having a name. Students study at a college and they are enrolled in at least one subject. Suppose we have a source model that conforms to the source metamodel. Suppose we also have the following ATL rule that transforms people into students . For each Person instance in the source model, a Student instance has to be created on the target model with the same name of the person. A college instance is also created and related to the new student. If we apply this rule in our source model, we obtain a target model where the new student is not associated to any subject. Note that this model does not conforms to the target metamodel given that the minimum 1 cardinality of the “Is Enrolled In” association is violated. Then, our method concludes that the rule “Person to student” is not weakly executable. As we will see in the next slides, our method can report that, in order to create a new Student, we need to relate him with at least one subject in the same execution.
  • To determine if a rule is weakly executable our method is based on the concept of DEPENDENCY .
  • A dependency from an update 1 to another update 2 expresses that the second update must be included in all rules where the first update appears to avoid violating the metamodel integrity constraints.
  • For instance, consider a simple target metamodel with two classes: A and B. Our dependencies point out that every time we create a new object of type A on the target model, we must initialize its mandatory attributes (in this case, the attribute “a”); and w e also must create its mandatory links (in this case, link the created object with one object of type B). Therefore, to be executable , a rule must satisfy all dependencies for every update in the rule.
  • To determine if a rule is weakly executable we proceed by applying a two-step verification process . Let’s see how the method works step by step using as example the rule “Person to student”.
  • FIRST STEP consists in computing the dependencies for the input ATL rule. The dependencies for the rule “Person to student” are the following: Every time we create a new student, we must initialize its attribute name, create one link of “studies at” association and create at least one link of “is enrolled in” association. Besides, every time we create a new college, we must initialize its attribute name.
  • After computing the dependencies for the rule, SECOND STEP of the method consists in trying to map the previous dependencies with the rule sentences, that is, c hecking if the required updates are satisfied by the rule itself.
  • First dependency maps correctly with the input rule, given that it contains a sentence for initializing the attribute “name” of the new student.
  • Second dependency also maps correctly with the input rule, given that it contains a sentence for creating a link between the new student and a college.
  • Third dependency does not map with the input rule, given that it does not contain any sentence for creating a link between the new student and a subject.
  • Finally, last dependency maps correctly with the input rule, given that it contains a sentence for initializing the attribute “name” of the new college.
  • Given that not all required dependencies are satisfied , the rule is marked as non weakly executable. Then, a corrective feedback is provided to the designer to help repairing the detected inconsistencies.
  • In the example, code for creating one link between the new student and a subject should be added on the rule to make it weakly executable.
  • The second property we define is called COVERAGE of a set of ATL rules.
  • We consider a set of ATL rules is covering if it allows addressing all elements of the source and target metamodels. This property may be viewed regarding two perspectives: From the source perspective, we call this property SOURCE COVERAGE . From the target perspective, we call this property TARGET COVERAGE .
  • We consider that a set of ATL rules is SOURCE COVERING when all elements of the source metamodel may be navigated through the execution of these rules. It means that, for each element in the source metamodel, there is at least one rule that navigates it. Otherwise, there will be elements of the source metamodel with no relevance in the transformation. For instance , the set composed by the single rule “Person to Student” is not source-covering since rules to navigate “age” attribute and “Knows” association are not specified. Note that, not coverage does not indicate explicitly an error but only a warning . But we feel this property is important to guarantee that no behavioral elements are missing in the rules.
  • On the other hand, we consider that a set of ATL rules is TARGET COVERING when all elements of the target metamodel may be created and initialized through the execution of these rules. It means that, for each element in the target metamodel, there is at least one rule that creates or initializes it. Otherwise, there will be elements of the target metamodel with no relevance in the transformation. For instance , the set composed by the single rule “Person to Student” is neither target-covering since, for instance, rules to create objects of type “Subject” are not specified, forbidding users to create new subjects on the target model.
  • To determine if a set of ATL rules is covering we proceed by applying a three step verification process .
  • Let’s see how the method works step by step using as example the set composed by the single rule “Person to student”.
  • FIRST STEP consists in computing the metamodel elements that should be addressed by the rules. In source metamodels , the metamodel elements are all elements that describe the metamodel (classes, attributes and associations). For instance, in our example, the source metamodel elements are all classes, attributes and associations which appears in the source metamodel. In target metamodels , the metamodel elements are all possible modifiable elements (non-abstract classes, non-derived attributes and non-derived associations). For instance, in our example, the target metamodel elements are all classes, attributes and associations which appears in the target metamodel.
  • SECOND STEP consists in computing the really addressed elements in the set of rules. For source metamodels , navigated elements are elements that appear in the “from” part of the rules or those which are navigated in the “to” part . For instance, navigated elements in the rule “person to student” are marked with a right green icon while non navigated elements are marked with a red error icon. For target metamodels , created and initialized elements are elements that are created or initialized in the “to” part of the rules . Likewise, created and initialized elements in the rule “person to student” are marked with a green right icon while non created or navigated elements are marked with a red error icon.
  • LAST STEP consists in computing the difference between metamodel elements and addressed elements. This difference represent the elements that should be addressed but they are not treat in any rule. In our example , two source metamodel elements are not navigated. Then, our method concludes the rule “Person to student” is not source covering. Besides, three target metamodel elements are not created or initialized. Then, our method also concludes the rule rule “Person to student” is not target covering. For both cases, our method return as feedback the non addressed elements. Their treat should be added in some rule if the designer wants to make the set covering.
  • For CONCLUDING this presentation, I will summarize the relevant points of our work and further research lines: We have defined two fundamental correctness properties of ATL matched rules: weak executability of a rule (which studies whether a rule may be safely applied without breaking the target metamodel integrity constraints) and coverage of a set of rules (which studies whether a set of rules allow addressing all elements of the source and target metamodels). We also have proposed a static method for the analysis of these properties. A relevant feature of our method is the feedback it provides, enabling the correction of the rules.
  • As a FURTHER WORK we would like to extend our method by addressing other types of ATL rules and verifying new correctness properties like redundancies in ATL rules. We also plan to provide tool support , implementing the method and integrating it into a tool for ATL as Eclipse platform.  
  • So, that’s concludes my presentation. THANK YOU very much for your attention! 

Transcript

  • 1. Two Basic Correctness Properties for Transformations: Executability and Coverage Elena Planas Jordi Cabot Cristina Gómez Universitat Oberta de Catalunya (Spain) École des Mines de Nantes – INRIA (France) Universitat Politècnica de Catalunya (Spain) MtATL 2011: 3rd International Workshop on Model Transformation with ATL July 1st, 2011 - Zürich, Switzerland
  • 2. model transformations play a key role with the emergence of MDE . the quality of the transformation process depends on the quality of the model transformations. 1/20 Related work tools analysis testing lightweight verification
  • 3. 2/20 Define two basic correctness properties of model transformations rules Propose a method to check these properties goal Lightweight (efficient) verification method Feedback suggesting possible corrections method features matched rules (declarative rules) focus
  • 4. Property #1: weak executability of an rule 3/20
  • 5. An rule is weakly executable if it has a chance of being successfully executed (the rule’s execution generates a target model consistent with the target metamodel integrity constraints). Source MetaModel Target MetaModel 4/20 rule Conforms To Conforms To
  • 6. 5/20 rule Person2Student { from p: PersonMM!Person to s: StudentMM!Student ( name  p.name college  c ), c: StudentMM!College ( name  p.collegeName ) } rule Person name: String age: Integer collegeName: String * * Knows {Sym} PersonMM Student name: String Subject * IsEnrolledIn 1..* id: String College name: String * StudiesAt 1 StudentMM name: Erik age: 21 collegeName: UOC name: Erik name: UOC StudiesAt NOT Conforms To Conforms To
  • 7. A dependency 6/20
  • 8. from an update up 1 to another update up 2 expresses that up 2 must be included in all rules where up 1 appears to avoid violating the metamodel constraints. A dependency 6/20
  • 9. A dependency Every time we… we must… … and… TargetMM B * 1 attrB: Type A attrA: Type 6/20 Create a new object … to o: TargetMM!A … Initialize its mandatory attributes … to o: TargetMM!A( attrA  value) … Create its mandatory links … to o: TargetMM!A( b  obj) …
  • 10. 1 2 rule is weakly executable rule is not weakly executable no yes 7/20 Compute dependencies Map dependencies All dependencies mapped? rule FEEDBACK
  • 11. rule Person2Student { from p: PersonMM!Person to s: StudentMM!Student ( name  p.name college  c ), c: StudentMM!College ( name  p.collegeName ) } 1 is weakly executable rule is not weakly executable no yes 8/20 Compute dependencies Map dependencies All dependencies mapped? 2 rule FEEDBACK rule Subject * IsEnrolledIn 1..* id: String College name: String * StudiesAt 1 Student name: String rule Create a new Student requires: Initialize its name attribute Create 1 link of StudiesAt association Create at least 1 link of IsEnrolledIn association Create a new College requires: Initialize its name attribute Dependencies
  • 12. 2 rule is weakly executable rule is not weakly executable no yes Dependencies Create a new Student requires: Initialize its name attribute Create 1 link of StudiesAt association Create at least 1 link of IsEnrolledIn association Create a new College requires: Initialize its name attribute rule Person2Student { from p: PersonMM!Person to s: StudentMM!Student ( name  p.name college  c ), c: StudentMM!College ( name  p.collegeName ) } 9/20 Compute dependencies Map dependencies 1 rule All dependencies mapped? FEEDBACK rule
  • 13. 2 rule is weakly executable rule is not weakly executable no yes Dependencies Create a new Student requires: Initialize its name attribute Create 1 link of StudiesAt association Create at least 1 link of IsEnrolledIn association Create a new College requires: Initialize its name attribute rule Person2Student { from p: PersonMM!Person to s: StudentMM!Student ( name  p.name college  c ), c: StudentMM!College ( name  p.collegeName ) } 9/20 Compute dependencies Map dependencies 1 rule All dependencies mapped? FEEDBACK rule
  • 14. 2 rule is weakly executable rule is not weakly executable no yes Dependencies Create a new Student requires: Initialize its name attribute Create 1 link of StudiesAt association Create at least 1 link of IsEnrolledIn association Create a new College requires: Initialize its name attribute rule Person2Student { from p: PersonMM!Person to s: StudentMM!Student ( name  p.name college  c ), c: StudentMM!College ( name  p.collegeName ) } 9/20 Compute dependencies Map dependencies 1 rule All dependencies mapped? FEEDBACK rule
  • 15. 2 rule is weakly executable rule is not weakly executable no yes Dependencies Create a new Student requires: Initialize its name attribute Create 1 link of StudiesAt association Create at least 1 link of IsEnrolledIn association Create a new College requires: Initialize its name attribute rule Person2Student { from p: PersonMM!Person to s: StudentMM!Student ( name  p.name college  c ), c: StudentMM!College ( name  p.collegeName ) } 9/20 Compute dependencies Map dependencies 1 rule All dependencies mapped? FEEDBACK rule
  • 16. 2 rule is weakly executable rule is not weakly executable no yes Dependencies Create a new Student requires: Initialize its name attribute Create 1 link of StudiesAt association Create at least 1 link of IsEnrolledIn association Create a new College requires: Initialize its name attribute rule Person2Student { from p: PersonMM!Person to s: StudentMM!Student ( name  p.name college  c ), c: StudentMM!College ( name  p.collegeName ) } 9/20 Compute dependencies Map dependencies 1 rule All dependencies mapped? FEEDBACK rule
  • 17. Dependencies Create a new Student requires: Initialize its name attribute Create 1 link of StudiesAt association Create at least 1 link of IsEnrolledIn association Create a new College requires: Initialize its name attribute rule is not weakly executable no rule is weakly executable yes rule Person2Student { from p: PersonMM!Person to s: StudentMM!Student ( name  p.name college  c ), c: StudentMM!College ( name  p.collegeName ) } 9/20 Compute dependencies Map dependencies 1 2 rule All dependencies mapped? rule FEEDBACK is not Weakly Executable rule Person2Student ERROR:
  • 18. Dependencies Create a new Student requires: Initialize its name attribute Create 1 link of StudiesAt association Create at least 1 link of IsEnrolledIn association Create a new College requires: Initialize its name attribute rule is not weakly executable no rule is weakly executable yes ADD FEEDBACK rule Person2Student { from p: PersonMM!Person to s: StudentMM!Student ( name  p.name college  c ), c: StudentMM!College ( name  p.collegeName ) } 9/20 Compute dependencies Map dependencies 1 2 rule All dependencies mapped? rule FEEDBACK is not Weakly Executable rule Person2Student ERROR:
  • 19. Property #2: coverage of an rule set 10/20
  • 20. A set of rules is covering if it allows addressing all elements of the source and target metamodels. source perspective source-coverage target perspective target-coverage 11/20
  • 21. A set of rules is source-covering when all elements of the source metamodel may be navigated throught the execution of these rules. 12/20 … is not source-covering (warning) rule’s set rule Person2Student { from p: PersonMM!Person to s: StudentMM!Student ( name  p.name, college  c ), c: StudentMM!College ( name  p.collegeName ) } Person name: String age: Integer collegeName: String * * Knows {Sym} PersonMM
  • 22. A set of rules is target-covering when all elements of the target metamodel may be created or initialized throught the execution of these rules. 13/20 rule’s set rule Person2Student { from p: PersonMM!Person to s: StudentMM!Student ( name  p.name, college  c ), c: StudentMM!College ( name  p.collegeName ) } Student name: String Subject * IsEnrolledIn 1..* id: String College name: String * StudiesAt 1 StudentMM … is not target-covering (warning)
  • 23. rule set 1 2 3 14/20 Compute metamodel elements FEEDBACK Compute addressed elements Compute non-addressed elements
  • 24. 14/20 Compute metamodel elements rule set FEEDBACK Compute addressed elements Compute non-addressed elements 1 2 3
  • 25. rule set 1 2 3 15/20 Compute metamodel elements FEEDBACK Compute addressed elements Compute non-addressed elements Person class name attribute (of Person ) age attribute (of Person ) collegeName attribute (of Person ) Knows association Student class name attribute (of Student ) College class name attribute (of College ) Subject class id attribute (of Subject ) StudiesAt association IsEnrolledIn association
  • 26. rule set 1 2 3 16/20 Person class name attribute (of Person ) age attribute (of Person ) collegeName attribute (of Person ) Knows association Student class name attribute (of Student ) College class name attribute (of College ) Subject class id attribute (of Subject ) StudiesAt association IsEnrolledIn association Compute metamodel elements FEEDBACK Compute addressed elements Compute non-addressed elements Is navigated? Is created/initialized?
  • 27. 17/20 rule set 1 2 3 Non-addressed Non-addressed Non-addressed Non-addressed Non-addressed Is navigated? Is created/initialized? Person class name attribute (of Person ) age attribute (of Person ) collegeName attribute (of Person ) Knows association Student class name attribute (of Student ) College class name attribute (of College ) Subject class id attribute (of Subject ) StudiesAt association IsEnrolledIn association Compute metamodel elements FEEDBACK Compute addressed elements Compute non-addressed elements rule set is not source covering WARNING: is not target covering rule set WARNING:
  • 28. Conclusions: 18/20 weak executability coverage feedback
  • 29. Further work: 19/20 weak executability coverage feedback Address new correctness properties Provide tool support Address other types of rules
  • 30. Elena Planas [email_address] Thanks for your attention! 20/20