What's wrong with UML?

The catalyst for finally starting a blog was Kenn Hussey's post about What's Wrong with UML... I wanted to contribute to the discussion, but my comments would have been way too long for that little tiny comment box.

Apparently the Object Management Group (OMG) has asked its members to come to the next meeting with a list of their top three things which are wrong with UML. Wow! Where to begin?

Without meaning to criticize Kenn, because I think he's done more than almost anyone to help open up UML and the OMG process, I think his list is made from much too much of an insider's perspective. Here's his list:

1. Un-intended inheritance
2. Undefined namespaces for standard stereotypes and primitive types
3. Inability to create a usable XML schema for UML

Let's take a few giant steps back here to get a little bit better view of the problem from the point of view of a UML user. As someone who's spent years working on an open source UML editor where I actually have to deal with users who are affected by this problems as they try to do their work, let me give you my list:

1. Lack of Interoperability
2. Incompatibility
3. The OMG

Let's take a closer look at each one.

Interoperability - The dirty little secret of all the UML tool vendors is that there simply is none -- and no one cares. I could go on about XMI this and MOF that, but let's start with the basics. UML is a visual/graphical modeling language. There is absolutely no way to interchange the graphical representation. WTF? With a little bit of luck, a consultant who's got a bag full of XSLT scripts, and two tools that don't stray too far from the spec, you might be able to get the semantic contents of your model across from one tool to another, but what about all those diagrams that you spent days and weeks slaving over? All completely gone. You'll need to redraw them from scratch. Sure, a spec for UML Diagram Interchange was promulgated (six or seven years after the initial UML specs were released), but no one's implemented it and the Eclipse folks have said that they consider it unimplementable so they're going to work to get their own standard adopted instead.

Even if we just look at the semantic contents of the model, as serialized in an XMI file, interoperability is very dodgy. Different tools have different bugs in their XMI reading/writing code which don't get fixed, vendors use proprietary extensions, and different tools implement different versions of the spec, but the biggest problem is that there's no systematic focus on improving interoperability. It's been broken so long that people don't expect it to get fixed. Each customer is own their own to fight with their own specific vendor and the vendors believe they have no incentive to fix the problems since it helps guarantee vendor lock-in. (They're wrong in their belief that this is to their economic benefit, but that's another story).

Compatibility - I mentioned different tools implementing different versions of the spec. Why is this important? Because the OMG has paid absolutely zero attention to compatibility between versions. UML 1.5 is the only version which was a pure superset of the previous version. In every other release, they've made incompatible changes at multiple levels of the specification. Not only have they changed the language itself in incompatible ways, but they've incompatibly changed the metamodel that's used to define it and the file format that's used to serialize it. Two tools which both implemented UML 1.3 wouldn't be compatible if one serialized using XMI 1.0 and the other serialized using XMI 1.1, let alone if one implemented UML 1.3 and the other implemented UML 1.4

This has an obvious negative effect on interchange/interoperability, but it has impacts throughout the modeling ecosystem. Vendors waste engineering effort reimplementing things just to conform to the new specification. Customers have to upgrade tool chains in lock-step and may not be able to upgrade at all if even a single vendor lags. Downstream standards groups working on modeling standards for bioinformatics, finance, or health care have to either freeze on an old standard as their basis or let the incompatibilities ripple downstream to their consumers.

UML 2.x deserves a special mention here because it is such a massive dislocation in the time/space continuum. In addition to the normal changes in the layer above (MOF) and the layer below (XMI), fundamental concepts of the UML itself were completely thrown out and reinvented for UML 2.x. These changes were so extensive that the OMG didn't even attempt to produce a change-barred spec or keep a comprehensive list of them. Instead entire sections will have a tiny little note at the end that says something like "This concept from UML 1.x has no equivalent."

Object Management Group (OMG) - This is probably going to seem harsh, and since they're local, I may even have friends working there, but I believe both of the problems above, and many of UML's other problems, can be traced back to the OMG and how it works. I'll reserve detailing the problems for a separate post, but they can be summarized as:

• Industry trade group, not a standards body
• Don't eat their own dog food
• Closed to participation by individuals, (most) users, and open source groups
• Too slow
• Too fast (ie not careful enough)

More on the OMG in another post.

As far as UML goes, there are any number of problems which could be enumerated, but if the interoperability nut could be cracked, they could build the momentum to address the other problems.

UML has been around since 1999 and its whole raison d'être is to be the lingua franca of the modeling world. Why not make it a goal to actually achieve this aim before the 10 year anniversary rolls around?