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

Bruce Silver’s keynote speech at BPMN 2011 workshop: interoperability and other issues in BPMN and UML

Today at the BPMN 2011 workshop in Luzern, Bruce Silver gave an interesting talk on the status of BPMN 2.0, its adoption, and his proposal for improving its general usage.
I really appreciated the talk because:

  • it focused on the ambiguities of the BPMN notation, even in the so acclaimed 2.0 version
  • it highlighted how users tend to be confused once the notation is so complex.

Bruce presented his well-known approach, with the caveat that probably method and style is too weak as a position, so he proposes to move to the rules term, so that people feel somehow more obliged to comply 🙂 .

    The first issue I take away is the problem of interoperability.
    I would also identify a trend on what I heard here, through a parallel to what is happening in OMG within the Canonical XMI initiative (read something here), performed by the Canonical XMI Finalization Task Force: given a modeling language (or an exchange format like XMI) which is under-specified, too general, or too open for dialects generation, the need arises for putting some stricter limitations to the designers, for making the tools more interoperable and for improving the quality of the models. Interoperability is the explicit aim of XMI, but, since it failed to an extent. Probably the same would apply to XPDL itself: it was designed as an interchange format for business process models, but then ended up being prone to several dialects and interpretations as well. For XMI, the improved interoperability aim is now in charge of Canonical XMI (while no action is being taken on XPDL).  The same purpose is addressed by the BPMN-I initiative by Bruce Silver.

    A similar problem that has been addressed is executability:
    Also on this, I see strong parallelism with the UML world. There is definitely a push towards executability of models: just think about the executable UML fUML and Alf initiatives (you can find a nice overview on both on Jordi’s blog here), at OMG or also some new activities like MiUML, an open-source executable UML project.
    On the other side, also BPMN 2.0 is addressing executability and within WebRatio we are also providing somehow a pragmatic approach to BPMN executability, by generating running Web applications. The question is: are customers asking for that? The claim by Bruce is that they are not for BPMN. Most people only want to model, not to execute. Probably, if you look at the share of interested people, for UML it’s the same. However, I think executability is an interesting property that should be granted to give a general grounding to reality to models (although I acknowledge that some models may not need/allow that).

    A final take from the day is related to choreography.
    Interestingly enough, again people are not using it: neither in the BPMN world nor in the UML one. I don’t have stats on the usage of the different kinds of UML models, but I’m pretty sure people only use class diagrams basically. Some will use activity diagrams, and few sequence diagrams. Anything else?

    Bruce Silver, with Bruce Silver Associates,
    presenting his keynote at the BPMN 2011 workshop.

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

    Panels on Executable UML at OMG tech meeting, Arlington, VA

    User Panel on Executable UML

    A nice discussion developed within the Executable UML (xUML for short, from now on) user panel at the OMG technical meeting in Arlington, VA, today.

    The panel was chaired by Stephen Mellor and Ed Seidewitz. The panelists were:

    • Laurent Rioux from Thales
    • Diarmuid Corcoran from Ericsson
    • Gary Shubert from Lockheed Martin

    Here are some interesting statements that I collected.

    For some apps you don’t even think to executable UML, you use same approach but you typically prefer exploiting DSLs and highly optimized compilers. But this is not a contradiction or a fight between xUML and DSLs, because the approach is actually the same.

    Having a standard UML action language (namely, Alf) will help a lot to promote xUML.
    The way you actually obtain model executability (Model interpretation vs. Code generation) is really a matter of the application domain where you want to use it. For instance, you will never use interpretation in realtime/ critical/ embedded systems (you may also have a quick look at this presentation
    MDD is a largely applied key tool for fighting software complexity (e.g., at Ericsson). Textual syntax has been strongly felt as a missing piece.  

    Don’t try to force people to be modellers if they want to be programmers and vice-versa.

    Modeling and code generation practices have been widely adopted at Lockheed Martin since 1989. For instance, the flight control software for F-35 fighter completely automatically generated (not from UML, though; from mathematical models instead)

    Vendors’ Panel on Executable UML

    The panel involved:

    They presented the status of the implementation of action languages within their tools and discussed the roadmaps towards adoption of fUML and Alf.

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

    Ed Seidewitz tutorial on Alf and fUML at OMG tech meeting, Arlington, VA, March 22, 2011

    These are my notes on Ed Seidewitz tutorial on Alf and fUML at Executable UML info day at today’s OMG technical meeting.

    Alf aims at allowing to program in UML, without bothering to go back and implement at low level things that are specified already at the design level.
    The role of Alf is to provide the missing details that cannot (or are very expensive to) be captured graphically by UML.
    The good thing is that Alf works at the same semantic level of the UML models.

    The picture will be:

    •  fUML = Executable UML Foundation
    •  Alf = Executable language for UML

    Versions will be shortly aligned so that: Alf will be based on fUML 1.1, which is a proper subset of UML 2.4 (and on its semplification UML 2.5 planned for end 2011). 
    The formal foundation of the executable models is specified based on First Order Logic (FOL) .
    The role of Alf is to provide a Java-like syntax that can be familiar for developers/designers. However, the surface syntax actually enables dataflow-based semantics.
    At resources naming level, Alf adopts the UML naming rules (you can have spaces in names; names are case sensitive; and so on. So names may need single quotes for containing the names).

    Several tricks need to be applied to actually design (even fairly simple) activity diagrams. For instance, you cannot have indeterministic semantics when you have outgoing outgoing data flows that land into several activities. A split node must be inserted, and thus the single token is copied into several ones. Or other peculiar cases, like the need of control+dataflows incoming in conditional nodes that produce only control flows. Or you may need to use datastores for multiplying incoming tokens. Or you may need implicit ouptup/input mapping in looping activities. Or to use parallel split for modeling ifs.
    Within activities you only have one scope, while stack of calls is relevant only among activity invocations.
    Alf does not constraint sequentiality. Parallel execution is allowed as soon as there is no dependency between activities.
    Some other critical syntax issues: array indexes start from 1 (as in UML), not from 0 (as in main programming languages); and then details on structural feature actions, comparison with null (equivalent to checking if an item is empty or not empty)
    In fUML an abstract operation has 0 methods, a concrete operation has only 1 method.
    fUML provides reified semantics for associations.
    Standard UML @Construct and @Destroy annotations are interpreted correctly.
    Receptions are optional in UML but are mandatory in fUML if you want an object to receive a signal.
    Profiles and stereotypes are currently not part of the fUML .

    And btw, the hello world example for Alf is:

    activity Hello(){
        WriteLine(“Hello World!”);

    Seems quite easy! 🙂

    The tutorial was given as part of the Executable UML Information Day at the OMG Technical meeting in Arlington, VA, on March 22, 2011. The full program of the day is available here:

    The official Alf specification is here:

    Disclaimer: This post is just a set of notes I took during the tutorial, it’s not meant to be complete or comprehensive, but I think it can provide a good understanding of the critical points.A more comprehensive post (by Ed himself) together with significant links is available here:

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

    Stephen Mellor tutorial on Executable UML at the OMG meeting, Arlington, VA, March 22, 2011

    “Models that don’t execute are like cars without engines”.

    Executable Models implement wrt 3GL the same paradigm that 3GL implemented through compilers or interpreters.

    The model is the system, it’s not something you should maintain or keep aligned separately.
    Executable models help reduce errors (at least of 10%, according to estimates), but most importantly they help to find the errors earlier in the development process, which is the actual critical advantage.

    One of the critical issues is interoperability between modeling tools. A common metamodel for Executable UML must be defined, so that

    The executable UML foundation is defined based on:

    • definition of the executable subset of UML (taken the entire UML metamodel, a subset of it is selected and defined as executable)
    • definition of execution semantics (defined using Executable UML itself)
    • a base semantics (mainly based on FSM and other mathematic model)

    An action language has been defined for foundational UML: it’s a Java-like syntax, with a dataflow underlying semantics (which grants more parallelism, …).

     A few issues need to be addressed, as highlighted during the discussion session: educational issues (make learners approach executable UML as their basic interface with programming, instead of other lower-level languages); integration with existing code, libraries, distribution, and so on.

    Disclaimer: This post is just a set of notes I took during the tutorial, it’s not meant to be complete or comprehensive, but I think it can provide a good understanding of the basic philosophy underlying Executable UML.

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