Bits of History (UML/MOF Alignment)

The long story of UML/MOF Alignment

The word alignment has been very often used when there are two divergent views and we need to show a consistency or a correspondence between these views. For example the business/IT alignment is often quoted as an important goal when IT platforms are rapidly changing and when business goals and global context are similarly evolving.

Alignment is related to interoperability or integration. It is particularly important when it comes to guarantee mutual consistency between two dynamically evolving views or situations. Alignment may be partial. It is a concept that is becoming quite popular in software modeling. Wikipedia defines ontology alignment as the process of determining correspondences between concepts ( The notion of model weaving in Eclipse proposed a way to compute, to represent and to enforces the abstract and declarative correspondences between two models by a specific model called the weaving model ( The AESIG OMG initiative (Architecture Ecosytem Special Interest Group) has the objective of managing the alignments between different recommendations or communities at OMG, UML and SysML or UML and BPMN for example (

The issue of alignment is more than a technical issue. Since it often involves two different communities, each having its specific goal and roadmap, it may be seen also as an organisational, social and human relation issue. This is why the rise of abstraction, from programming to modeling, often brings to the forefront alignment enforcement difficulties.

As an example of a situation of continuous alignment spanning now on more than fifteen years, we may look at the competition/collaboration between two modeling visions/communities at OMG, the so-called heavyweight and lightweight communities.

As a summary of previous episodes, Ed Seidewitz has nicely reported how UML 1.0/1.1 introduced stereotypes and tagged values for extension and openness, but that the notion of “profile” came later, proposed by himself and Dave Frankel in the context of the Business Object Initiative. I copy below the beginning of this proposal:

It seems clear that these guys were trying to define a new language for business modeling (a DSL for Enterprise Distributed Object Computing) but knew that they would never be allowed to draft a completely stand-alone language that could compete with UML. Very wisely they managed to present this as just a minor variant of UML, and this was not only accepted but encouraged by UML tool vendors because it could be integrated in their products and in their strategy.

Since I was just an observer and I could just attend a meeting from time to time, my reporting may be distorted. At OMG academics are not full players and are just allowed to watch the game. I was just trying to understand and explain what was going on. Digging in my old stuff, I recently found two slides that I used to explain my personal interpretation of OMG ongoing work to my students at that time. The first one shows my understanding of the evolution of modeling languages.

  • Phase (a) Since UML is not only unified but “universal”, it is able to describe everything in the computer or business world. As a consequence it should also be able to describe itself.
  • Phase (b) UML is mainly for code and the CWMI (Common Warehouse Metadata Interchange) for data. So we need an upper language that could describe at the same time UML and CWMI. Let’s call this upper language the MOF (Meta Object Facility).
  • Phase (c) As a matter of fact the MOF may not only define UML and CWMI but also Workflow situations, software process (Process Working Group or PWG to become SPEM later), Component model, Action language, etc. This corresponds to the heavyweight language definition. When the language to define is “closer” to UML, it is possible to take a less expensive way to define it, called ligthweigth extension mode. For example if we wish to define a “UML for Business Objects” or a “UML for C++” or “UML for CORBA“.

It is clear that the lightweight definition mode is perfectly acceptable for UML tool vendors. But what about the heavyweight one? Will people need a different CASE tool to produce and edit MOF metamodels? This was a big concern. Finally there was an agreement that MOF will be allowed to fly only if MOF metamodels may be defined by UML tools. In other words, MOF and UML should be permanently aligned. As a matter of fact, MOF should be aligned with a clearly identified subset of UML .

So this lead us, about fifteen years later, in the same situation, with two different ways to define DSLs, full-fledged metamodels or UML profiles. And during these fifteen years or so, the two communities of MOF and UML orthodoxies have been obliged to maintain the strict alignment.

In retrospect it is quite interesting to analyze this situation.  We can make a number of remarks.

This has been possible under the strong supervision of the AB at OMG (Architecture Board or AB is the “police of OMG”, checking that everything is in line and politically correct).

Technically there are few examples of two different languages having been aligned for such a long period. But now we are starting to understand  why this has been possible. Of course UML and MOF have completely different purposes and semantics. It is complete nonsense to align the semantics of these two languages. The trick has been to align only the concrete syntaxes of MOF and UML. And since UML tools do nearly no semantic work, everybody was happy.

In the few situations where there were small problems, then ad-hoc situations could be found. For example in the Sun MDR/NetBeans system, an open source tool that was quite popular was the UML2MOF tool. This tool may be found as a servlet for example at:

It is funny to notice that when metamodels were mainly paper metamodels, the MOF/UML alignment posed absolutely no problem. The first difficulties emerged only with transformation languages like QVT or ATL when we needed real metamodels. This operation UML2MOF was called a promotion operation because it transformed a model into a metamodel. Later, when transformation tools improved, the need for this operation became less important and this transformation was even proposed as a standard transformation, in the ATL transformation library. It is interesting to note that the reverse operation of demotion (transforming a metamodel  into a UML model).

So, basically the language alignment between MOF and UML was possible because it was an alignment of concrete syntaxes only and the few difficult cases, a simple transformation could do the trick.

But in retrospect, this “strongly encouraged” alignment between MOF and UML had some positive impact to Model Driven Engineering. It contributed to the unification of models (instance or terminal models), metamodels and metametamodels. All these entities are abstract models, i.e. typed graphs.  And this is a noted advantage of Modelware on Grammarware.  In Grammarware, there is no such alignment on the concrete syntaxes of EBNF and Java for example.

This entry was posted in MOF, OMG, SPEM, UML. Bookmark the permalink.

3 Responses to Bits of History (UML/MOF Alignment)

  1. Jim Steel says:

    I’ve often found the close paradigmatic (and lexical) alignment between UML class diagrams and MOF problematic when it came to teaching people about MDE. Everyone has heard enough to want to understand how UML fits with MOF, but both are Classes, Associations, Packages, etc, and it looks very confusing drawing that on a whiteboard. For a long time, I would ignore UML class diagrams and use something from a different paradigm to demonstrate what a metamodel was. Something like a workflow language works well, or even another part of UML like state machines.

  2. Ed Seidewitz says:

    Jean, I can’t keep up with your interesting posts!

    As I just commented back on your “SPEM and UML Profiles” post, the alignment of MOF and UML will be completed with MOF 2.4 and UML 2.4. The MOF 2.4 Core meta-metamodel will be defined as a strict subset of the UML 2.4 abstract syntax metamodel. But, as you say, this is just syntactic alignment. The specific metamodel semantics of MOF models will still be as defined in the MOF spec. (And MOF will also still add reflection capabilities not in UML, but this is mostly a semantic extension.)

    But even just the syntactic alignment has a lot of benefits. You will now be able to create a fully conformant MOF metamodel using a regular UML tool, which was technically not possible before (without doing some sort of “MOF promotion”, as you noted in your post). And MOF models will be interchangable using regular UML XMI — there will no longer be any need to worry about UML XMI vs. CMOF XMI vs. EMOF XMI (which, up until now, were technically all distinct!).

    Indeed, in spirit at least, MOF 2.4 will pretty much just be the profile of UML for metamodeling! It is a subset of UML identified for a specific community of use with semantics tailored for that community. Indeed, if one required the use of the existing standard UML “metamodel” and “metaclass” stereotypes in MOF models, then MOF Core could become UML profile in fact as well as spirit! (This is not what is actually being proposed, though, largely for backward compatibility and convenience reasons.)

  3. Pingback: Architecture Ecosystem « Models Everywhere

Leave a Reply

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

You are commenting using your 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