Metamodel-Based Models Comparison

Abstract

In this article we share a practical implementation of a structural approach to models comparison, defined at meta-model level. The implementation allows stating:

a partial order relation on the meta-model classes considering their associations;
criteria for identification of the meta-model classes’ instances (the model elements), considering some of their associations and attributes.

The implementation uses topological sorting of the compared models, considering that partial order relation and uses the model element identification criteria for finding matching nodes among those that have the same distance from the minimal elements according to that partial order. That general implementation is provided in ModelAnt as the <compare.models> task, whereas the UML 1.3-specific partial order and identification criteria are defined within its specialization <uml13.diff.models> for UML 1.3 models comparison. Additionally ModelAnt provides <diff.db> macro specialization of <uml13.diff.models> for comparison of database structures, which plays well with the <reverse.db> ModelAnt task. The implementation uses Java Metadata Interface (JMI), MOF 1.4, XMI 1.1/1.2 and ModelAnt scripting front-end.

We examine the benefits of practical usage of models comparison within the coordinated iterative development of several independent, but integrated software products.

Practical Needs

In our practice in software development we:

have several mature products (let’s name them A,B,C,D,E) that implement and maintain different business sub-processes of the overall business process of our company
the products have their own life cycles, developed iteratively and incrementally according to the goals and changes in our business
the products are being developed by different teams, using different technologies, architectures and frameworks
the products are integrated within the overall business process and as such have to share big arrays of common data, spread among their own databases

In this situation the changes in web-service interfaces and database structures are rather easy to introduce and very important for the integrity of the business. Thus we have to control them. The established model-driven development practice using UML 1.3 in team B and the frequent branching and merging, which need also comparing models and detecting changes, gave the approach to solve those integration problems.

Terms

The Object Management Group (OMG) has defined Meta-Object Facility (MOF) framework (i.e. a glossary of terms) to describe:

MOF models are models expressed in MOF terms as structures of MOF objects – instances of the classes (terms) of MOF framework.
- The instances of the MOF terms in those models are referred as model elements.
the meaning of MOF model instantiation
a mechanism to represent a MOF model as
- a DTD (the MOF to XMI mapping), so that any XML document that is compliant with that document type definition is treated as an instance of that MOF model
- an XML Schema (the MOF to XMI mapping), so that any XML document that is compliant with that schema is treated as an instance of that MOF model
- a set of CORBA interfaces (the MOF native mapping to CORBA), designed to allow a user to create, update, and access instances of the MOF model using CORBA client programs
- a set of Java interfaces and their implementations in a repository (the Java Metadata Interface JMI (JSR 40), actually defined in the Java Community Process) as instances of the MOF model
- a set of CORBA interfaces (JMI defines Java interfaces) to access instances of the MOF model, being managed – these are the MOF reflective interfaces
the MOF models by themselves may be:
- just a standalone data models used in some specific business processes
- conceptual (domain) models (A.K.A. abstract syntax) of other modeling languages like UML, CWM, SysML, BPMN, etc. whose own purpose is to describe and build specialized models.
When a MOF model describes an X modeling language, then for the models expressed in terms of X language (X models):
- that MOF model (of X) describes of the terms and relationships of the X language – the abstract syntax of X language.
- that MOF model (of X) is referred as X metamodel.
- the terms of X are represented as instances of the term “Class” of MOF and considering that they are instantiated in the models, they are referred as metaclasses.
- the instances of terms of X used to express the models in X are referred as elements of those models
- the MOF reflective interface for model element in X access the elements of X metamodel which are instances of MOF classes/terms
- MOF itself is described in the terms of MOF, therefore:
  - so there is a MOF model of MOF, referred as MOF metamodel
  - the XMI, CORBA, JMI, etc. mappings are completely applicable to MOF itself and thus they give standard interfaces and XML schema/DTD of MOF itself and MOF models

The MOF reflective interfaces allow manipulating any MOF model instances only within the terms of MOF.

ModelAnt provides the <compare.models> ModelAnt task that compares two models of the same modeling language X, through the MOF reflective interfaces, only within the terms of X metamodel. In our model-driven development practice we use the <compare.models> task compare UML 1.3 models.

Approach

The models comparison in X modeling language is based on the simple principles:

Define a strict partial order relation R on the elements of any models in X language, considering (some of) the relationships of the X model elements.
Define equality criteria Q for the elements of any model in X language, considering local features of the X model elements.
Define correspondence criteria C as: treat element E from the model M as corresponding to the element E’ from the model M’ when comparing the models M, M’ expressed in X language, if and only if:
1. E and E’ are instances of the same term in X abstract syntax
2. the set of the correspondent elements to the elements of M that immediately precede E in the partial order relation R is equal (as set) to the set of elements of M’ that immediately precede E’ in the partial order relation R
3. E and E’ are equal according to the equality criteria Q

In order to define the partial order R on any elements of any model in X language we consider:

We define the relationship R equally:
1. In MOF terms: as a set of associations from the X metamodel – associations of metaclasses of X
2. In math terms: as unification of relationships between the sets of instances of those metaclases, which relationships are represented as associations in the X metamodel.
(Property 1) The graph presenting the metaclasses and only their associations (considering the inheritance in OOP), that are considered in the relationship R, form a direct acyclic graph if and only if the relationship R is a strict partial order over the model elements of any models in X language
The equality criteria Q is expressed as equality of values of specific attributes of the metaclases (considering the inheritance in OOP) of the compared model elements.
For each X model element the access to attributes’ values and associated model elements, thus the evaluation of R and Q, is done using the MOF reflective interfaces which are independent of the actual language X.

Note: The formal proofs of Property 1, 2, 3 require building formal theory of modeling, OOP and MOF terms and its mapping to mathematical terms as sets and relationships, which is subject of another development, which is too long for the format of this article. Thus for brevity and clarity it is skipped and left to mathematician’s and programmer’s notions and reasoning.

Statements that could be proven formally:

(Property 2) The correspondence criteria for E and E’ implies equality of the sets of any model elements that precede E in M (or E’ in M’ correspondingly) as of the relation R. The proof is by induction considering the models are finite sets.
(Property 3) Let m is a model element of M, m’ is a model element of M’ and m corresponds to m’, then m is correspondent to m’ when comparing M and M’ according to C, if and only if m’ is correspondent to m when comparing M’ and M according to C. The proof is by induction considering the models are finite sets.

Applying the correspondence criteria C for the comparison of the models M and M’, their model elements can be split into three sets:

correspondents – a set of pair (m,m’) so that m is a model element of M, m’ is a model element of M’ and m corresponds to m’ and m is correspondent to m’ when comparing M and M’ according to C
M orphans – a set of elements of M that have no correspondent element m’ from M’ when comparing M and M’ according to C
M’ orphans – a set of elements of M’ that have no correspondent element m from M when comparing M and M’ according to C

In the terms of “MDA based – approach for UML Models Complete Comparison” [1] publication the presented approach is a global structural comparison with elements of local and semantic approaches.

Implementation

The general <compare.models> ModelAnt task implements the general mechanism for metamodel-based model comparison. Internally it uses topological sorting of the model elements according to the partial order relationship R above, with some optimizations considering the specifics of definition of the correspondence criterion C to speed up the comparison real life models of many tens of thousands elements.

It identifies the models M, M’ actually by the name of the extent of the model repository (MDR) where those models are loaded. Both names are provided as values of new and old task attributes. The attribute names refer the fact that usually different versions of the the same model are being compared, so the orphans in the new model version are perceived as added, whereas the orphans of the old model version are treated as deleted.

The partial order R and the equality criteria Q are provided to <compare.models> task within a nested <match> element, which contains many instances of:

<equal> element, which states for which metaclass which associations to include in the partial order relation R and which attributes to include in the equality criteria Q. Note that the subclasses of that metaclass inherit those criteria.
<except> element, containing other <equals> elements, which state for which metaclass what associations and attributes not to inherit from the superclass, this way defining specific custom criteria.

In addition, a nested <relax> element, similar to <except> above, defines which comparison criteria to exclude in an optional second pass over the already recognized orphans. That second comparison pass with relaxed equality criteria would recognize more corresponding model elements, but having changes in the attributes of the strict comparison criteria or having changes in the associations in the partial order relation.

The general <compare.models> ModelAnt task allows defining the way (strategy, as of the Strategy design pattern) of handing of the detected corresponding elements and the added/deleted orphans. These are:

Specifically the <detect.changes> strategy does precise detection of the changes happened in the attributes and associations of the recognized corresponding elements. Both strategies allow executing nested ANT / ModelAnt tasks to handle the changes in each pair of corresponding model elements.

In addition it is possible to define the order of the model elements in which they are reported as changed to the nested tasks and in the lists of orphans.

<uml13.compare.models> task

The <uml13.compare.models> ModelAnt task is a specialization of <compare.models> task within the UML 1.3 package of ModelAnt. The <uml13.compare.models> task is dedicated to comparison of any UML 1.3 models. Internally it has set both partial order relationship R and equality criteria Q for UML 1.3. They are defined according to the formal definitions and Property 1 above. They came from the practical needs and tasks to solve in our model-driven development practice in our company.

The <uml13.compare.models> ModelAnt task takes care to load the models to compare, assuming they are UML 1.3 models stored in XMI 1.1 or XMI 1.2 format, to process them and at the end to release those models and any other resources it has allocated.

The <uml13.compare.models> ModelAnt task allows defining several nested “procedures” as groups of ANT/ModelAnt tasks to process the pairs of corresponding elements and the recognized orphans:

<init> group of tasks are executed after the models are loaded, but before they are compared;
<done> group of tasks are executed after the models are compared, before the resources are released;
<orphans> group of tasks are executed after the models are compared and added and deleted lists of orphans are stored as ANT properties in the tasks’ environment;
<changed> group of tasks are executed for each pair of correspondent elements, that have attributes or associations revealed as changed. For more details see <detect.changes>. Notes:
- the correspondent model elements that have the same attribute values and correspondent associated model elements are not reported for processing in <changed>.
- at the moment of execution the lists of orphan model elements are already bound as ANT properties in the tasks’ environment, so they can be accessed or even modified
<added>, <deleted> tasks are executed for each orphan model element revealed as added or deleted, correspondingly. Note that at the moment of execution the lists of orphan model elements are already bound as ANT properties in the tasks’ environment, so they can be accessed or even modified.

This task still needs customization as the nested groups of tasks in order to do something useful – it does not provide default actions.

<uml13.diff.models> task

The <uml13.diff.models> ModelAnt task simplifies the UML 1.3 models comparison and just prints their differences and the changes happened between the old and new version of the common model. Its use is really simple:

<project>
  <typedef resource="uml13/meta.xml"/>

  <uml13.diff.models old="old model file name" 
                     new="new model file name"/>
</project>

Note that the models are complex structures so the task’s output could be long and very detailed.

<diff.db> task

The <diff.db> ModelAnt task additionally simplifies the <uml13.diff.models> ModelAnt task with the assumption that the models being compared are database schemas, probably reverse engineered by <reverse.db> ModelAnt task. It simplifies the output and allows printing the newly added/deleted tables, attributes and associations in a more compact form skipping any not important changes as of the UML 1.3 metamodel.

Usage:

<project>
  <typedef resource="net/mdatools/modelant/uml13/reverse/antlib.xml"/>

  <diff.db old="old model file name" 
           new="new model file name"/>
</project>

Note: it still reports the tables as classes, the columns as attributes and the relationships as associations with their end. Nevertheless it is quite clear what actually changes happened in the DB strictures.

Examples

A report by <diff.db> ModelAnt task revealing that TABLE_1 has an ATTRIBUTE_1 added and a whole new TABLE_2 was created

 Changed:
         Class TABLE_1
     Added:
            Attribute
             name= ATTRIBUTE_1
             type.name= NUMBER
              length:  10
   Added:
         Class TABLE_2
           persistence:  persistent
             Attribute
              name= SYS_OID
              type.name= NUMBER
               length:  20
               RationalRose$Data Modeler:ConstraintType:  Primary Key
             Attribute
              name= SYS_KEY
              type.name= NUMBER
               length:  10
               RationalRose$Data Modeler:ConstraintType:  Primary Key

Other materials on models comparison

Samia Benabdellah Chaouni, Mounia Fredj, Salma Mouline, “MDA based – approach for UML Models Complete Comparison”, http://arxiv.org/ftp/arxiv/papers/1105/1105.6128.pdf
Rainer Lutz, David Wurfel and Stephan Diehl, “How Humans merge UML-Models”, http://www.st.uni-trier.de/~diehl/pubs/esem11_preprint.pdf
Dimitrios S. Kolovos, Richard F. Paige, Fiona A.C. Polack, “Model Comparison: A Foundation for Model Composition and Model Transformation Testing”, http://www.irisa.fr/lande/lande/icse-proceedings/gamma/p13.pdf
“MMDiff: a modeling tool for metamodel comparison”, http://dl.acm.org/citation.cfm?id=2184540&dl=ACM&coll=DL

Licensed by Rusi Popov under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. Based on a work at mdatools.net. Permissions beyond the scope of this license may be available at http://mdatools.net/blog/contacts/.