domain-specific model verification with qvt

Domain-Specific Model Verification with QVTBy

Maged Elaasar1,2

Jointly withLionel Briand3, Yvan Labiche1

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

ECMFA 2011, Birmingham, UK

Copyright 2011, Maged Elaasar

IBM Software Group | Rational software | Rational Modeling PlatformDomain-Specific Model Verification with QVT

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: not self.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 PResult Metamodel

problem specification

conforms to conforms to

pattern

role1

role2

Input Model Result Model

QVTR



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’

‘owner2’unique occurrence



10

Problem Template in PQVT

transformation Catalog (in:Language, out:PResult) {

top relation Problem {

checkonly domain in role:Type {

/* problem template */

};

enforce domain out c:Category {

/* problem occurrence template */

};

when {

/* extra problem conditions */

}

}

} Language PResult

problem specification

conforms to conforms to

pattern

role1

role2

Input Model Result Model

QVTR



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

}

<var> : <Type> { <property1> = <value>, <property2> = <value>, ....}

x : Class { isAbstract = true, ownedAttribute = a : Property { lower = 1 }}



12

PQVT Exampleimport 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



checkonly domain in role:Type { /* problem template */ };

when { /* extra problem conditions */ }

where {

Variant1 (role,...,null);

Variant2 (role,...,null);

}

}

relation Variant1 {

checkonly domain in role:Type { /* variant template */ };

enforce domain out c:Category { /* variant occurrence */ }

when { /* extra variant conditions */ }

}

}



14

Problem Dependency Template in PQVT



checkonly domain in role:Type { /* problem1 template */ };

enforce domain out c:Category { /* problem2 occurrence */ }

when {

/* extra problem1 constraints */

Problem2 (role, ..., c);

}

}

top relation Problem2 {

checkonly domain in role:Type { /* problem2 template */ };

enforce domain 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

AssociationClassCommentConstraintDataTypeElementImport

EnumerationEnumerationLiteralGeneralizationInstanceValueLiteralBooleanLiteralReal

LiteralIntegerLiteralStringLiteralUnlimitedNaturalOpaqueExpressionOperationPackage

PackageImportPackageMergeParameterPrimitiveTypeProperty

Based on well-formedness constraints in the UML specification:

UML1UML2UML3UML4UML5UML6UML7UML8

Class With Required Owner Property Defines Another OwnerClassifier Has Attribute Not Redefining Inherited One With Same NameComment Has No Annotated ElementsConstraint Expression Has Parse ErrorsConstraint Has No Constrained ElementsNamespace Has Indistinguishable MembersProperty Has Invalid Default ValueProperty Is Derived But Has Default Value



17

MOF Well-formedness Problems

Based on well-formedness constraints in the MOF specification:

MOF1

MOF2

MOF3

MOF4

MOF5

MOF6

MOF7

MOF8

Association Does Not Have Two Member Ends

Element Is Not Allowed In Metamodel

Enumeration Has Operations

Multiplicity Element Is Multi Valued But Has Default Value

Named Element Has No Name

Named Element Is Not Public

Parameter Has Effect

Typed Element Has No Type



18

Semantic Problems

Problems that raise practical difficulty using or implementing a metamodel

SEM1

SEM2

SEM3

SEM4

SEM5

SEM6

SEM7

SEM8

SEM9

SEM10

SEM11

SEM12

SEM13

SEM14

Association Has Asymmetric Redefinition

Association Has Asymmetric Subsetting

Association Is Bidirectional With Asymmetric Derived Ends

Association IsDerived Conflicts With Ends IsDerived

Classifier Has Ambiguous Non-Owned End

Classifier Has Redundant Generalizations

Classifier Is Abstract With One Direct Subtype

Constraint Has Trivial Expression

Constraint References Non Context Element Only

Multiplicity Element Has Redundant Lower Bound

Multiplicity Element Has Redundant Upper Bound

Namespace Has Identical Constraints

Operation Could Be Converted To Derived Attribute

Operation Is Not Query



19

Convention Problems

Violations of used conventions in defining metamodels

CON1

CON2

CON3

CON4

CON5

CON6

CON7

CON8

CON9

CON10

CON11

CON12

Association Member Ends Are Reversed

Association Has Non-Default Name

Classifier Name Is Part Of General Classifier Name

Named Element Has No Documentation When It Should

Named Element Has Multiple Documentations

Named Element Is Not Alphabetic

Named Element Starts With Upper Case

Operation Has Return Parameter Not Named “result”

Property Is Boolean But Does Not Start With “is”

Property Is Derived With No Derivation Constraint

Property Derivation Constraint Does Not Reference Property

Typed Element Has Default Value Literal With Type Set



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:

Category (# ) Relations Roles Constraints

Avg. Tot. Avg. Tot. Complex Depends on Reuse Facilities

UML (33) 37 2.09 69 3.39 112 37 40

MOF (32) 32 1.56 50 1.59 51 22 3

Semantic (33) 36 2.03 67 3.18 105 34 20

Convention (15) 17 1.4 21 3.73 56 24 1

Total (113) 122 1.69 207 2.86 324 117 64

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)

UML 2.2 UML 2.3 UML 2.4 Beta UML 2.4 Final

# of occurrences 2558 2120 1670 786

UML MOF Semantic Convention

# of occurrences 287 30 1195 159

% of resolutions 30% 100% 59% 40%

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, [email protected]



28

Backup Slides

domain-specific model verification with qvt

Documents