Version control tools for modeling artifacts

Programmers could not live without version control systems like Subversion or Git. However, modelers have been forced to live like that until now.

We don´t have yet the version control for models but some promising initiatives have recently been popping up. In this page I try to list all of them (if I’m missing ANY please let me know, so far I’ve added all the feedback got in comments of the original post on this topic). Of course, all of them can be used to version UML models but most tools are more generic than that and support several kinds of models (e.g. any EMF model).

Also, note that several tools offer some kind of versioning capabilities for models created with that same tool. However, here I focus on generic tools (in the same way SVN can be a repository for any kind of source code, not only source code generated with a specific IDE).

List of Version Control Tools for Models

  • EMF Store project. Probably this new Eclipse project is the most visible tool. EMF Store is a model repository that keeps track of the version history of the models stored in it. EMFStore follows the checkout/update/commit interaction paradigm known from SVN or CVS and offers an interactive model merging interface to resolve conflicts when two users change the same model data. A model migration (to update models after changes on the metamodel they conform to) feature is also integrated. The code is currently hosted on Google code at emfstore.org
  • The new version of the CDO model repository includes branching and merging support for your models
  • The ModelCVS and AMOR (Adaptable Model Versioning) projects that provide semantic-based methods and techniques to leverage version control (like learning from previous conflict resolution decisions made by the user or proposing resolution strategies based on the semantics of the concepts to be merged).The live demos I´ve seen of these tools were really impressive.
  • EMF Compare that implements a two-phase comparison technique for EMF models where the first step (matching) browses the model versions figuring out the relationships between the elements in the “new” and “old” version and the second one (differencing) browses the matching result to create the list of differences.
  • Epsilon Merging Language , a rule-based language for merging homogeneous or heterogeneous models. The correspondences between the models to be merged can be generated using the related Epsilon Comparison Language .
  • The upcoming research projects MetaRep (Metamodel Repository with Version Control) and MORSE (model-aware repository) also deserve a mention although they are not at the same stage as the previous ones.

  • Model versioning was also part of the ModelBus project but there the focus was on tool integration and distributed services that can be run on models.
  • At the metamodel level, Edapt provides support for the evolution of Ecore metamodels and the automatic migration of models to the new metamodel version. Edapt code will be contributed from the COPE project . Similarly, Epsilon Flock is a model migration language built atop EOL, for updating models in response to metamodel changes

Note that all these tools only version the model information but not its graphical representation (e.g. layout). It´s not yet clear what should be considered a change or conflict in this context (e.g. moving a class two inches to right should count as a change? Does this conflict with another “change” in which the class has moved a little bit down?).

Of course, if you prefer to work with textual modeling tools (and follow a purely syntactic approach for model comparison) then the problem disappears and standard version control tools would do the trick.

For the readers interested in the latest research area, the complete Bibliography on Comparison and Versioning of Software Models contains links to (all?) publications in the area, including several workshops specialized in model comparison and versioning.

5 Responses to Version control tools for modeling artifacts

  1. Anonymous says:

    >Programmers could not live without version control systems
    >like Subversion or Git. However, modelers have been forced
    >to live like that until now.

    you may be interested in the Evolve tool we are creating at http://www.intrinsarc.com
    Evolve is the commercialization of component research work from Imperial College, London.

    Evolve adds two constructs to a hierarchical component model: resemblance (a form of component structural inheritance) and evolution. These provide the power of a version control system, but directly into the design language! In other words, designers can utilize the same constructs for evolution and design.

    Evolve also handles the evolution of the diagrams also. UML2 component structure/component diagrams are used to display the architecture.

    Cheers,
    Andrew McVeigh
    London

  2. Anonymous says:

    just a further comment about Evolve — it’s built ON top OF EMF/UML2.

    a multi-USER version (EMF/UML2 backing onto an object database) IS coming out early NEXT YEAR.

  3. Anonymous says:

    Should AML be cited in the 7th item (besides Epsilon Flock and COPE)?
    AML is a DSL for specifying model matching algorithms [1]. An application of AML is model migration.

    [1] http://wiki.eclipse.org/AML

  4. Anonymous says:

    Hi,
    OutSystems’ models ARE completely versioned AND we also have a visual model merge (which IS actually patented). CHECK the demos ON our site…

    IT supports ONLY our model definition… But it IS a good way TO analyze what should be considered AS a difference OR NOT… FOR instance, positioning OF the elements IN the model ARE NOT considered a functionality change.
    Cheers
    Goncalo Borrêga
    http://www.outsystems.com

  5. jordi says:

    Can you explain what you mean by visual model merge?

    And what exactly is the patent about?

    Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Powered by WordPress