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 (http://en.wikipedia.org/wiki/Ontology_alignment). 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 (http://wiki.eclipse.org/AMW). 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 (http://www.omgwiki.org/architecture-ecosystem).

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: http://www.soluta.net/en/page/18/xmi2mof.php

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.

Bits of History (SPEM and UML Profiles)

SPEM and the motivation for UML Profiles

As discussed in a previous post, one of the important move in the UML history was to change from Unified Method to Unified Language. Ed Seidewitz rightly suggests that the credit should probably be given to Rational (Jim Rumbaugh and Grady Booch) for this move. Remember that all this process was in the sequence of the work of the OOADTF group at OMG (Object-Oriented Analysis and Design Task Force) and that this  group was organizing a confrontation and convergence between methodologies and methodologists. The idea of a methodology-agnostic language took thus some time to mature. If this idea seems obvious today, it was not always the same in 1995.

My observation point was the attendance to some OMG meetings from time to time. I had no information from inside Rational. I understand that the RUP (Rational Unified Process) was very important but I have no idea on the origin of the project inside Rational. I imagine that Philippe Kruchten was very influential on the process, but I don’t know the dates of these contributions and influences.

Coming back to this drawing of the previous post reproduced above, I should have mentioned that this is completely abstract and artificial. The dichotomy between product and process in software modeling is conceptually well presented above but there are two  errors in the picture:

• The first one is that the name SPEM was found much later. If my memory is good, the work started with an unnamed goal, some sort of Unified Software Process Language.
• The second error in the picture was that there was never consensus on the use of a full fledged metamodel for SPEM. This is the story I want to record in this post.

The context was the continuing tension at OMG between so called lightweight and heavyweight modeling approaches, between UML strict orthodoxy and MOF deviants. The lessons of this tension could perhaps be examined today in a less passionate debate, but let us keep that for another discussion.

Of course nobody is naive and we all know the major influence of tool vendors on the definition of modeling standards and recommendations. At that time this was particularly important. After all, these companies were taking a major risk and it may seem normal to give them a major role in the definition of these standards. But it should be made clear that it was not industrial users or academics or any other categories of people that took the main decisions

The definition of SPEM was more or less made at the same period that the definition of UML profiles. The official motivation for profiles was to provide openness to the UML definition. But the real risk for providers of UML tools was to see the concurrent corporation of CAPE tools catching the market of software processes (CAPE = Computer Assisted/Aided Process Engineering). As a matter of fact, the description of the production of software (who is doing what, when, how and why?) is very similar to the process description of any other marketed goods.

In order to keep the SPEM market within the CASE scope (Computer Assisted Software Engineering, understand UML modelers), it was important that SPEM could be defined not only as a metamodel, but also as an UML profile.

This strategy worked quite well and has been more recently proposed again with BPMN. My opinion is that the profile mechanism has not been defined for conceptual reasons, but mainly for economical reasons, to protect the business of UML tool vendors and to allow them to make the heavy investments on building and maintaining their software tools.

There is now a significant literature on comparing the strict metamodeling approach and the UML profiling for defining Domain Specific Languages (DSLs).  The debate is far from being closed. I just wished here to state that the rationale for initially introducing UML profiles was an economic and industrial strategy choice made by CASE tools vendors. The SPEM metamodel is much simpler than the UML metamodel and a pure SPEM tool would have been much easier to build. But the missed revenues would have weakened the UML tool market.

Bits of History (The birth of XMI)

Serialization: One missing feature for UML

The story starts in Montreal, at the OMG technical meeting of June 1997. Once again this was at the time OMG knew where to organize nice meeting and Montreal in June, just before the Jazz festival, is obviously quite a different experience than this awful  Hyatt hotel in Santa Clara! So this OMG meeting supported by the Ericsson company in Montreal was the place where UML got stabilized. More precisely, there was a final meeting at this nice hotel in the old Montreal area, in a big room completely crowded (probably more than 100 people attending). In front of the room, all the major contributors of UML were there, including the three amigos (Jim, Ivar and Grady).

All the issues having been settled before, the meeting turned out to be a self-congratulation meeting. Most talks were about how nice this UML language was and how important it was going to become for the whole profession.

At some point of time, there was a small question from someone in the assembly to the panel: “Knowing how successful UML was going to become, it is likely that several tools vendors were going to provide UML support in addition of the Rational company. What do you suggest for exchanging UML models between tools provided by several vendors?”

It was funny to realize that nobody on the panel was prepared to answer this simple (and natural) question. After a long silence, finally somebody (in my memory it was somebody from Rational), started to answer and made this funny reply: “There is no problem and we anticipated this problem. This is why we have provided a standard way to plug any UML tool on the CORBA bus. Thus if  another tool vendor wishes to exchange UML models with Rational Rose, the simple solution is to use a CORBA connection“.

This answer closed the discussion on the subject of model interchange.  But then many people started to ask themselves additional questions. What if the tools could not be connected in permanent mode through CORBA? What if people wished to exchange UML models on Internet? (the answer was then IIOP in theory). What if people wished to exchange UML models with floppy disks? The final discussion of this meeting was about collecting ideas on how to improve the UML practice. In the list of idea, there was a mention of needed serialization.

The Montreal meeting finished thus without any satisfactory answer to this problem of  UML model exchange from and to the dominant Rational Rose tool. But the problem was stated and immediately after the meeting in June 1997, some people started immediately to deal with this missing feature and as soon as December 1997, a new RFP was ready (see document OMG 97-12-03.pdf) launching the SMIF initiative (Stream-based Model Interchange Format):

The SMIF Problem Statement stated that:

“The OMG has adopted specifications for an Object Analysis and Design (OAD)Facility and a Meta-Object Facility (MOF). The OAD Facility uses the Unified Modeling Language (UML) as the meta-model and graphical notation for OADmodels. The MOF provides a set of IDL interfaces for distributed meta-object management. However, in addition to a graphical modeling language anddynamic interchange of model information using OMG IDL, these and other planned OMG facilities (e.g. Workflow Management Facility) also need a stream-based model interchange format.”

More precisely, the objective of this RFP was stated as:

“This RFP asks for a stream-based model interchange format (SMIF).The specific objectives of this RFP are the following:

· Establish an industry standard specification for a stream-based model interchange format,

· Provide a generic format that can be used to transfer a wide variety ofmodels,

· Demonstrate that it can be used to exchange OMG Object Analysis andDesign Facility (OADF) compliant models (UML based) and models compliant to other MOF-compliant metamodels and extensions (e.g.Workflow Management Facility and Business Object Facility metamodels),and

· Leverage existing vendor-neutral transfer formats as much as possible.

This RFP solicits proposals for the following:

· A transfer format specification for file export/import of models. The scope for the type of models that can be exported / imported using thisspecification are those that are MOF-compliant representations of industry standard metamodels or metamodel extensions that are compliant with theMOF’s metamodel extension specification. This includes OMG approved metamodels, future OMG approved meta-models, and other current and future industry standard metamodels such as the committee draft (CD)International Standards Organization (ISO) / International ElectrotechnicalCommission (IEC) Joint Technical Committee 1 (JTC1) Subcommittee 7(SC7) Working Group 11 (WG11) CASE Data Interchange Format (CDIF)meta-model standards (CD 15476) and the metamodels that are parts of theISO International Standards (IS) for the Exchange of Product Data (STEP,ISO 10303).

· A transfer format specification for unique identification of the version of the MOF meta-metamodel and any metamodels referenced but not included in an SMIF-compliant transfer. An example use of  the transfer format specification for one or more models complaint with the OMG approved Unified Modeling Language (UML) meta-model specification.”

The funny  thing is that if you search for the string “XML” in this document, you’ll find no occurrence. That means that initially the OMG was looking for a native solution to serialization of UML models in december 1997.

The rest of the story is more well known. Instead of directly defining a serialization file format for UML graphs, the study revealed that the XML community had already a natural serialization format of trees. The decision was thus taken to go from graphs to trees, and then from trees to text files by using the intermediary XML encodings.  Furthermore it was possible to exploit the properties of XML to make a correspondence from <model,metamodel> to <document,XMLschema> (or at least <document,DTD> at the beginning).

From that point in time, nobody heard about SMIF anymore and all efforts were spent on XMI. Due to the efforts of a group around Sridhar Iyengar and Steve  Brodsky, this recommendation was stabilized in november 1998 (98-10-17.pdf):

The implementation of XMI went on quite rapidly and in december 1998, it was possible to illustrate the progresses by the so-called Burlingame demonstration where four different UML tools were able to exchange UML models: the interoperability problem was solved, thanks to XMI.

We know today that this was an impression and that the real model interchange is still a problem, but probably more a semantic problem than a syntactic problem.

This story teaches us many things. One of them is that the OMG is able to learn rapidly from its errors or omissions. Due to the short meeting cycle (one meeting every 3 months), it was possible to find rapidly a solution to a problem that had been overlooked.

Was the solution to use an XML vocabulary a good solution? At that time, and in view of the urgency of the problem probably yes. But today XMI is not probably seen as the best OMG proposal.  XML is verbose and   probably the cholesterol of Internet.  It the SMIF problem had to be solved today, it is probable that solutions like JSON would probably be much better (see JSON, the fat-free alternative to XML).

Bits of History (The birth of UML)

Niçoise salad, Salade niçoise or Insalata nizzarda

or

How to choose the good ingredients to get a good UML?

In novembre 1996, I was lucky to attend the OMG meeting in Nice, France.  The weather was splendid and at that time OMG was still organizing meetings outside USA, in wonderful places. But this meeting was particularly important because it was there that the main initial decisions about UML were taken.

The big player in the game was Rational (at that time Rational had not been acquired by IBM). The main opposition was coming from IBM, allied to a small canadian company called ObjectTime (Bran Selic was behind this company). The problem was to unify different proposals to the ongoing RFP. I remember having been asked by IBM to present at the time our three-layer metamodeling system (sNets) in a private IBM meeting.   I believe that, at the same meeting,  Trygve Reenskaug also tried to convince them to make the concept of role first class in UML, without more success.

But the rule of the game was different. It was obvious that Rational proposal was going to be overwhelming accepted. The only question was about how. It was difficult to accept 100% of the Rational proposal and 0% of the IBM proposal.  IBM should be allowed to make a marginal contribution to UML.

As a matter of fact, IBM was proposing two important contributions to UML: The schema organization and the OCL annotation language. The guy behind both proposals was Steve Cook (the same Steve that is today still working on UML, but on behalf of Microsoft). Steve was not present in Nice, but he was probably the main artisan of IBM proposal. If I remember well, the IBM negotiation team was led by Dipayan Gangopadhyay (I met him at TOOLS much later and he had left IBM).

The following slide presented the IBM/ObjectTime main contribution:

The proposal was quite clear. OCL on one side and a clean mechanism for modeling language extension called Modeling Schemes on the other side.

This is the place where history was made. Probably not in a full OMG meeting at the main hotel, but in some café of the”Promenade des anglais”. I suspect that the discussion went somehow as follows: “It is impossible to ignore IBM proposal, but on the other side we don’t want to take their full proposal. Which one shall we chose? OCL or Modeling Schemas?“

I dont claim that they used coin tossing, but the result was clear: OCL was choosen for the best and the worst and the second proposal of Modeling Schemes was simply ignored.

This is the sad story. This is why we have to deal today with the ugly OCL syntax. And this is probably why we miss so much a clean extensibility scheme or all the OMG modeling languages. I remember this with a lot of sadness and I often look to the following slide that was also presented in Nice by the IBM/ObjectTime team:

Isn’t this slide fantastic? Presented at the initial UML definition meeting in 1996. And this was simply ignored at the time. What a pity!

Of course, Steve Cook was probably proposing ideas in advance of their time in 1996. But some cycles later (i.e. some OMG meetings later), people had completely forgotten this. And they started complaining of missing parametrization and openness of UML. Guess what they did at that time: invent the notion of UML Pofile! What a pity. But this is another story that we may discuss later.

By the way, if you want to know the main culprits, here is a list of people involved in this OMG meeting in Nice.

As you can see, Steve Cook is not on the list but he was certainlythe “eminence grise” at IBM at the time.

Anyway, this story shows that UML started from the beginning as a “salade niçoise” as they call it there!