Model interoperabilty in MDE: a lost battle?

If you have been extensively using software modeling tools, you have probably experienced the awful situation where you want to move models from one tool to the other, but this ends up not being possible.
Why? Because you are using different languages? Not at all: even just moving a “standard” model from a modeler to another is a pain.
Concretely, each tool stores and manages the models with its own internal format or its own “dialect”, even if a standard format is adopted.

This is a major concern for developers, who need to check every time the actual possibility of exchanging the same kinds of models between editors, and often still need to struggle finding the mappings and defining the bridges between the formats by themselves. This hampers the possibility of effectively exploiting different tools in the development process. This is is definitely a minus for the developers, since having several tools at hand to be used upon the same model could allow to use the different features provided by the different vendors, based on availability but also taste of the developer himself. For instance, in an ideal world a developer could design the models with a modeling tool MT1 (e.g., because the editor of MT1 is more usable and allows higher productivity) and then immediately move to another tool MT2 for the verification phase (e.g., because MT2 provides more precise or extensive rules), and to tool MT3 for model execution (code generation or model interpretation, e.g., because it’s not provided by other tools).
Even in the case of well established standards like UML or BPMN, their abstract definition is still not enough for leading modeling tools from different vendors to share their models in a seamless way.

Interoperability is addressed also by standardization bodies. They are well aware that the supposed role of facilitating communication and information interchange that (standard) models should cover, is not a reality yet.
To improve interoperability between modeling tools, standardization bodies have defined specific model interchange languages. Examples of these languages can be found both for GPLs and for DSLs.
The most known model interchange language is XMI (XML Metadata Interchange), a standard proposed by OMG for serializing and exchanging UML models. Unfortunately, even if this has been devised as an interchange format, different tools still adopt it with different flavors. Therefore, the need arises of constraining the language even more. That’s why OMG is now running an activity for defining a canonical version of XMI (Canonical XMI), which is a strict subset of XMI and forces the adopters to follow stricter constraints.
A similar situation can be found in the most popular DSLs too. For instance, BPMN has an interchange counterpart in the XPDL language (XML Process Definition Language). In turn, this interchange language suffers of the same problems of XMI. Indeed, it is very difficult to actually move BPMN projects from a modeling environment to another.

This leads to my initial question:

  • Is modeling interoperability a moving target that will never be reached? 
  • Is it doomed to fail anyway and anyhow?

To keep updated on my activities you can subscribe to the RSS feed of my blog or follow my twitter account (@MarcoBrambi).

14 thoughts on “Model interoperabilty in MDE: a lost battle?

  1. Marco —

    Actually, Canonical XMI was originally suggested as simply a pragmatic set of rules for formatting XMI documents so that they could be compared easier. This was to facilitate interoperability testing by the OMG Model Interchange Working Group (MIWG), making it easier to compare an export from a tool to the expected XMI. (I actually originally proposed this idea, but Pete Rivett did most of the work defining Canonical XMI.) It is still expected that a conforming UML tool will be able to import any XMI that conforms to the XMI standard, not just Canonical XMI. Since then, there has been some question as to why the XMI standard allows as much variability as it does — making it harder to implement — leading to the idea of restricting the standard to just Canonical XMI. But that has not been done yet and was not the original purpose of Canonical XMI.

    — Ed

  2. Also, XMI-based interoperability has improved a great deal between the major vendors involved in the MIWG, over the 2 years we have been doing testing. In the end, though, vendors improve tool interoperability only to the extent that their users push for it — they don't have much incentive otherwise. So, for UML tools at least, I would encourage anyone who has tool interoperability issues to take a look at the MIWG Wiki at http://www.omgwiki.org/model-interchange/doku.php and then press their tool vendors to improve their tools!

    (Of course, XMI does not address diagram interchange, but there is finally a new standard for that — but it will unfortunately probably still be a couple years before implementations of that are mainstream…)

  3. Maybe we should create a neutral format like I've seen in the Computer-Aided Design world with the IGES format. But this was easy for IGES because geometry is universal. How can we create a neutral format for such different approaches found in the software modeling world?

  4. I think that model interoperability *through a common standard* is doomed to fail. It does not work well with fixed method tools (E.g. UML-driven). With increasing use of DSLs, such common exchange medium is becoming meaningless. With DSLs, it is inevitable for DSL developers to make bridges between models and model formats. What would help, is to have access to tool-specific model formats ( standartization of generic aspects such as diagram information would be nice). Another important factor is optimal development tools for defining model bridges (in other words, model transformation tools). Unfortunately, the currentt state of such tools in use by industrial companies is very bad.

  5. Model interchange should be nothing more than a mapping (transformation) from one meta model(-s serialization format) to another meta model(-s serialization format).

    In the case of UML or BPMN it's no wonder that that is difficult, since these standards (at least UML) have specifications that are quite open to interpretation. When it comes to the aspects which are not in the specification but which are important for (UML) tools, i.e. diagram visualization and such, there's no specification at all.

    Even if this problem were solved for something like UML, you'd still only have interoperability between UML tools which quite limits the whole usefulness because it still only pertains to one meta model (with a very limited degree of extensibility) – I'm no fan of UML because it's too large and very difficult to make domain-specific in a deep and comfortable way. So, I'd go for option b and say that this endeavor is doomed to fail since standards like UML will not be the ultimate answers to our modeling needs.

    On the other hand, XMI works beautifully in the EMF world precisely because there it is “no more” than a serialization format for models which adhere to some explicit meta model which has Ecore as meta meta model. Model interchange is then mostly a manner of reading in the serialization and performing some mapping on model/instance level. That in itself could be difficult but only if the mapping (transformation) between the respective meta models is difficult, e.g. because the “technological spaces” are quite far apart but that represents a different problem than just the interoperability.

    In fact, the EMF world has an UML implementation which serves as a good common base for a number of popular UML tools out there so it sort-of is the de facto standard for UML model interoperability. I've done code generation from UML models in a number of modeling (MagicDraw, RSM) and code generation tools (oAW/Xpand, a custom Groovy+StringTemplate engine) and the interoperability between those (and in that direction) was clearly one of the smaller issues.

  6. It's extremely irritating for sure. We've been trying to get ARIS to talk to pega with no success. Our version of visio won't even export to ARIS.

    The way I see it, interoperability isn't in the best interests of the vendors – with more an more building strategy to execution software (think TIBCO & Nimbus, ARIS & Webmethods) the ability to model and execute within the one piece of software will become the norm.

  7. Hello Ed,
    thanks for your insights. Despite not being the original objective of Canonical XMI, probably having a narrower set of option definitions in XMI would be appreciated by most developers. I think the idea is good anyway and that Canonical XMI can have a huge impact on every-day activities.

  8. Thanks Ed,
    I think the MIWG is a great initiative. I'm wondering how big is the commitment of vendors vs. users. (see also posts of Jordi Cabot and The Process Ninja).

    Wrt diagram interchange: for sake of completeness, I guess you refer to the Diagram Definition specification, which is under finalization now, right?
    http://www.omg.org/spec/DD/

  9. Rui,
    I think the DD (Diagram Definition) specs by OMG is a good example of this, but it obviously deals only with the graphical part of the design languages. Semantics and detailed metamodels are much harder to tackle.
    Marco

  10. Hello,
    I see this is a more general problem. And we need to consider several issues, including advantages for tool vendors, and so on.
    However, here we are not talking about complex, vendor-specific files (e.g., project files, in programming). Instead, I'm addressing the basic modeling artifacts: single models.
    It's just like when you have a C file and different editors cannot open it..

  11. Yes.
    Probably the advantage/disadvantage of vendors is one of the main issues here. Typically, the main driver toward addressing an issue is the request from (big) customers.
    Ourselves, with WebRatio we had to deal with interoperability issues on BPMN with a major enterprise and business modeling tool, to accommodate a large project need.
    We ended up with bi-lateral agreements and conversion with the other tool, addressing orthogonal aspects.
    But being this the general rule, it's quite scary.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s