Sure enough, I had an inevitable encounter with said company the week before last at the OMG technical meeting in Orlando. As Steve Cook said, he was welcomed with mostly open arms. The Analysis and Design Platform Task Force meeting was a little more interesting than usual because Steve had the gumption to point out many of the problems that exist with UML. I'm glad he did. Although many of his observations weren't a surprise to all of us, with any luck his fresh perspective will inspire the UML community to act rather than sit around and pontificate...
One of the things that came out of the Orlando meeting was the formation of a UML Roadmap working group, participation in which is open to any OMG member. As homework for today, participants were asked to come up with the top three things that they feel are wrong with UML. I'm sure many will cite complexity as a major problem with UML, but as I've said before, I think this failure is largely in the tools, not necessarily the metamodel. Rather than been passing the complexity of UML on to the end user, vendors should work smarter (not harder) to find innovative ways to make consumable products.
I don't claim to know everything about UML, but after spending several years developing and maintaining the de facto reference implementation of UML at Eclipse, I have a few opinions about what's wrong with the language. While difficult to choose only three, here's what I think my picks (mostly related to interchange) are.
1. Un-intended inheritance
The hierarchy of metaclasses in UML is deep and wide, and riddled with multiple inheritance. The designers of UML strived for a rich architecture with many reusable levels of abstraction; unfortunately, one of the side-effects of such a design is that concepts which make sense in one context (metaclass) are unintentionally inherited in another (metaclass). This is further exacerbated by package merge, which combines mutltiple flavours of a metaclass, from various contexts, into one overloaded representation.
2. Undefined namespaces for standard stereotypes and primitive types
The UML specification defines standard stereotypes for use in its higher compliance levels, but fails to define a normative URI via which the profiles containing them can be referenced. Similarly, UML defines a set of four standard primitive types, but rather then defining a model library with a normative namespace URI so that they can be reused, it merges them into the langage itself, forcing other related languages to do the same.
3. Inability to create a usable XML schema for UML
Currently, it's not possible to produce a working XML schema for UML because of its extensive use of multiple inheritance. Even with a schema produced using the XML extension mechanism a copy-down inheritance, a given UML instance document couldn't be validated, because UML doesn't make a consistent distinction between base classes and mixin classes.
Here's hoping this new working group will bear some fruit.
PapyrusUML: Papyrus UML support in Hawk
14 hours ago