Domain-Specific Model Verification with QVT

1. Domain-Specific Model Verification with QVT By Maged Elaasar1,2 Jointly with Lionel Briand3, Yvan Labiche1 ECMFA 2011, Birmingham, UK 1Carleton University, Dep. of System and Computer Engineering, Ottawa, Canada 2IBM Canada Ltd., Rational Software, Ottawa Lab, Canada 3Simula Research Laboratory & University of Oslow, Lysaker, Norway

2. Outline • Problem Statement: Model Verification • Existing Model Verification Approaches • Contribution 1: Model Verification with QVT-Relations • Contribution 2: Metamodeling Anti-Pattern Catalog • Contribution 3: Verifying UML Metamodel Case Study • Limitations and Future Work • Summary

3. Problem Statement: Motivation for Model Verification • In MDE, models are the primary form of expression • Models have their abstract syntax defined with MOF-based metamodels • Examples of metamodels: General (e.g., UML) and DSMLs (e.g., BPMN) • Model verification is important activity of MDE • Modeling is labor intensive and error prone • Model verification allows for detecting common problems • Problems can be syntactic, semantic or convention related • Model verification is complex and needs to be automated

4. Problem Statement: Approach for Model Verification • Desired characteristics of model verification formalism: • Applicable to any MOF-based language • Precise and well defined execution semantics • Concise notation with reuse and complexity handling mechanisms • Leverages existing knowledge of modeling practitioners • Reports results in a structured, scalable and easy to inspect way

5. Existing Model Verification Approaches • Logic-based formalisms (models need to be transformed into suitable formats) • Other existing (e.g. SQL) and newly defined (e.g., EVL) query languages • Object Constraint Language (OCL) • OCL constraints (provide no details beyond the context element) context Class: notself.isAbstract implies self.ownedOperation->forAll(not isAbstract) • OCL queries (provide more details but is cumbersome to specify) context Class: self->select(not isAbstract).ownedOperation->select(isAbstract)-> collect(o|Tuple{class=self, operation=o}) • Not clear how to use OCL in a modular way that allows reuse • In our approach, we evaluate the use of QVT (an extension of OCL)

6. Problem Detection with QVT-Relations (QVTR) • QVTR is standard model-to-model transformation language • Inherits OCL expressiveness • Has a flexible syntax with native capability for patterns matching (with templates) • Rule-based, modular with reuse mechanisms (query operations, intermediate properties, rule composition) • PQVT: Using QVTR for problem detection and reporting Language Metamodel QVTR PResult Metamodel conforms to conforms to problem specification pattern role1 role2 Input Model Result Model

7. PResult Metamodel • Allows reporting problem occurrences in a generic and structured way • Occurrences are unique collections of role bindings organized in a tree data structure • Reduces footprint by sharing common role bindings • Allows for easy inspection by ordering bindings by importance down the tree • Related occurrences grouped under problems and problems under categories

8. Example Problem • A class with a required owner property defines another owner property

9. Example Problem Occurrence ‘UML Wellformedness’ ‘ClassWithRequired...’ ‘Owned’ ‘owner1’ ‘owner2’ unique occurrence ‘owner2’

10. Problem Template in PQVT transformation Catalog (in:Language, out:PResult) { toprelation Problem { checkonlydomain in role:Type { /* problem template */ }; enforcedomain out c:Category { /* problem occurrence template */ }; when { /* extra problem conditions */ } } } Language QVTR PResult conforms to conforms to problem specification pattern role1 role2 Input Model Result Model

11. QVTR Object Template transformation UMLAssociations (in:UML, out:PResults) { intermediate property Property::otherEnd : Property = self.association.memberEnd->any(e | e <> self); intermediate property Class::associationEnd : Set(Property) = Property.allInstances()->collect(e | e.otherEnd.type = self); intermediate property Class::allAssociationEnds : Set(Property) = self.associationEnd->union(self.superClass.allAssociationEnds); intermediate property Property::allSubsettedProperties : Set(Property) = self.subsettedProperty->union(self.subsettedProperty.allSubsettedProperties); intermediate property Property::allRedefinedProperties : Set(Property) = self.allRedefinedProperty->union(self.redefinedProperty.allRedefinedProperties); } x : Class { isAbstract = true, ownedAttribute = a : Property { lower = 1 } } <var> : <Type> { <property1> = <value>, <property2> = <value>, .... }

12. PQVT Example import UMLAssociations; transformation MetamodelingProblems (in:UML, out:PResults) { top relation ClassWithRequiredOwnerDefinesAnotherOwner { checkonly domain in Owned:Class { allAssociationEnds = owner1:Property { lower = 1, otherEnd = :Property { aggregation = AggregationKind::composite } }, associationEnd = owner2:Property { otherEnd = :Property { aggregation = AggregationKind::composite } } } enforce domain out c:Category { name = ’UML Well-formedness’, pattern = p:Pattern { name = ’ClassWithRequiredOwnerDefinesAnotherOwner’, root = rb1:RoleBinding { name = ’Owned’, element = Owned, child = rb2:RoleBinding { name = ’owner1’, element = owner1, child = rb3:RoleBinding { name=’owner2’, element = owner2 }}}}}; when { owner1 <> owner2; owner2.allSubsettedProperties->excludes(owner1); owner2.allRedefinedProperties->excludes(owner1); } } }

13. Problem Variant Template in PQVT transformation Catalog (in:Language, out:PResult) { toprelation Problem { checkonlydomain in role:Type { /* problem template */ }; when { /* extra problem conditions */ } where { Variant1 (role,...,null); Variant2 (role,...,null); } } relation Variant1 { checkonlydomain in role:Type { /* variant template */ }; enforcedomain out c:Category { /* variant occurrence */ } when { /* extra variant conditions */ } } }

14. Problem Dependency Template in PQVT transformation Catalog (in:Language, out:PResult) { toprelation Problem { checkonlydomain in role:Type { /* problem1 template */ }; enforcedomain out c:Category { /* problem2 occurrence */ } when { /* extra problem1 constraints */ Problem2 (role, ..., c); } } top relation Problem2 { checkonlydomain in role:Type { /* problem2 template */ }; enforcedomain out c:Category { /* problem2 occurrence */ } when { /* extra problem2 conditions */ } } }

15. Metamodeling Anti-Pattern Catalog • Metamodels tend to have a large number of problems • We defined a catalog of MOF 2.4 problems (anti-patterns) • MOF 2.4 adopts UML 2.4 and adds extra well-formedness constraints • The catalog includes 113 problems in four categories: • UML Well-formedness (33 problems) • MOF Well-formedness (32 problems) • Semantic (33 problems) • Convention (15 problems) • Complete catalog is documented at: • https://sites.google.com/site/metamodelingantipatterns/catalog • Or google ‘metamodeling antipatterns’

16. UML Well-formedness Problems • We identified the relevant subset of UML for metamodeling • Based on well-formedness constraints in the UML specification:

17. MOF Well-formedness Problems • Based on well-formedness constraints in the MOF specification:

18. Semantic Problems • Problems that raise practical difficulty using or implementing a metamodel

19. Convention Problems • Violations of used conventions in defining metamodels

20. Case Study: Verifying UML Metamodel • Specified the catalog using PQVT • Used the catalog to verify UML metamodel • Assessed three criteria: • The expressiveness of PQVT • The effectiveness of PQVT • The performance of PQVT • Result data are available at : https://sites.google.com/site/metamodelingantipatterns/casestudy

21. PQVT Expressiveness • Defined a reusable module with 16 intermediate properties and 13 queries • Defined a PQVT module for each category in catalog • Collected some metrics from the modules: • Problems had 1-6 roles each with average of 1.69 (generally small) • Problems had 1-11 constraints with average of 2.86 (generally simple) • 64% of constraints were in the simple ‘property=value’ form • 80% of constraints were simple enough to express without reuse facilities

22. PQVT Effectiveness • Verified recent revisions of UML (occurrences decreased over revisions) • 53% reduction between UML 2.4 Beta and Final • Why not all problem occurrences got resolved? • RTF ran out of time and decided to defer (e.g. fixing OCL constraints) • The cost of fixing them now (on tool migration) outweighed the value (e.g., changes to names) • They were confirmed as exceptions to the rules (e.g., some associations names)

23. PQVT Performance • We used Medini QVT to run the catalog on UML metamodel • We improved the performance of the execution (10x) by: • Caching the result of queries and intermediate properties • Improved graph matching algorithm to prune the search tree with constraints asap • UML (unmerged) metamodel is a large model • 426 classes, 1246 properties 267 operations and 778 constraints • Under a minute to run the whole catalog on UML metamodel • UML (22s) • MOF (8s) • Semantic (15s) • Convention (5s)

24. Limitations and Future Work • Problem specification is a bit verbose with QVTR • Define a concise problem specification DSL and map it to QVTR • Problem specifications do not specify fixes • Specify fixes with QVTR rules from result model to language models • Problem specifications are bound to one modeling language • Define generic QVTR transformations and bind them to individual languages

25. Conclusions • We presented an approach to specify and detect domain-specific modeling problem with QVT called PQVT. • We presented a new catalog of metamodeling anti-patterns • We presented a case study where the catalog was specified with PQVT and used to verify recent revisions of UML metamodel

26. Ph.D. Research Direction • The analysis of models through the identification of patterns • Design Patterns (enhances model comprehension and documentation) • Design Problems (avoid common mistakes and pitfalls) • Use of a transformation-based approach (with QVT) to detect patterns

27. Thank You Maged Elaasar, melaasar@ca.ibm.com

28. Backup Slides