Change Impact Analysis & Constraint Violation Detection

by: Markus Zoffi, Christina Zrelski, Roland Jöbstl, Christian Johannes Tomaschitz 

Whenever teamwork is part of the development process, one is not capable to avoid merging of double edited files. However, if these files only contain code the merge process can be resolved very easily, but if there are more complex constructs - like models - the merging process also increases its complexity. During the participation of the Advanced Model Engineering Lecture we worked on an efficient way to detect constraint violations after merging the models, which is presented in the following.

Goal of the Project

The overall idea of this project was concentrated on performing a change impact analysis of parallely evolved model versions. Thereby every model version in itself was valid, but the conjunction of different and/or parallel modifications caused one or more violations in constraints. The resulting constraint violations should not only be detected, we also wanted to identify the cause of the violation.

Defining Metamodel and OCL Constraints

The first step and general setup for the project was to create a simple metamodel and add some OCL constraints. Our metamodel is basically a simplification of an UML class diagram, it contains four classes: the class SimpleClassDiagram, SimpleClass, SimpleAttribute and SimpleRelation.

A SimpleClassDiagram consists of a number of SimpleClasses, which can in turn specify inheritance (superclass relation), attributes (relation to SimpleAttribute) and relations (bidirectional relation to SimpleRelation). A SimpleAttribute specifies certain properties of a SimpleClass, each one having a name and type, whereas a SimpleRelation defines the relation between classes as well as the properties of the relation itself (minCardinality, maxCardinality).

Afterwards we defined some basic OCL constraints in the metamodel (using OCLinEcore) which could be easily violated during a merge process for our testing purposes.

The following five constraints were used:

• Unique Attribute Name:
  context SimpleClass
  inv: self.attributes->isUnique(name);
• Limit Number Of Attributes:
  context SimpleClass
  inv: self.attributes->size() < 6;
• Attribute Name Not Empty:
  context SimpleAttribute
  inv: self.name->notEmpty();
• Cardinality of Relation Within Range:
  context SimpleRelation
  inv: self.minCardinality > -1 and self.maxCardinality < 50 and self.minCardinality <= self.maxCardinality;

Merging the Models 

In the context of model merging and diffmodel analysis we used the EMF Compare Framework, which provides comparison and merge facility for any kind of EMF models. For the merging task we use a three-way-merge, which means that two revised versions and their common ancestor model had to be specified. Thereby the ancestor model is treated as a reference for identifying and connecting the differences.

Detecting the Violations 

The first step was to iterate over the given models and identify which model elements matched to each other. Afterwards, for each two matching elements the differences between them were detected.
Thereby, each difference corresponds to a change (where change means, ADD, CHANGE, DELETE, MOVE Operation). In detail, all model elements that changed were processed and compared to the invalid trace object. The goal thereby was to identify the model element which was responsible for the validation error in the OCL constraint. These information was then processed in a further step to generate the output for the user.

Demonstrating our approach

For our demonstration let's take the following two models:

The merging process leads to a constraint violation with the Limit Number of Attributes constraint with the following output.