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.
Subscribe to:
Post Comments (Atom)
Posts
10 comments:
Kenn, please make the list longer! If I were asked what's wrong with XSD, I could come up with more I'm sure.
You points the congenital problems of UML. But thank you for pointing these issues.
UML is not perfect but it exists.
IMHO. be the UML spec shall be interpreted as a communication data model, not an implementation one.
The point is all tool providers shall ensure the compatibility of their data model with the standard.
For instance tool providers shall add opposite relationships EVERYWHERE in the data model since coders barely need it and the standard does not specify it because of infrastructure packages dependencies (and cross-referencing sucks a lot:).
Another point is making Dependencies available at the Element level (then you can add Dependencies between Dependencies, useful for traceability within complex profiles)...
I think the standard exists and we shall conform to. But it is not a sacred book, but as tool providers we can make some adjustments at implementation to make it usable. But we shall remain compatible with the standard in the way we provide modeling tools (UI, vocabulary, XMI, etc.).
Separation of concerns...
Hi Kenn,
I've also worked for a long time on a UML tool and completely agree with your points. But i would like to add one point: As far as I know there once was a Rational model describing the UML specification. But as far as I know there is now tooling support to check the consistency of this model. This leads to a lot of inconsistencies in the spec. so even though the OMG is advertising MDA, why don't they eat their own dog food to design their specs?
Just my 2 cents,
Matthias
BTW: The AUTOSAR consortium (http://www.autosar.org) is using an MDSD approach to create it's specifications from an EMF metamodel describing their metamodel. So why doesn't the OMG do this? And as a side note: I told Richard Soley about AUTOSAR and why the OMG doesn't use MDA for their specifications. He didn't answer this question, perhaps he was the wrong person to ask ;-)
Perhaps the only "real" standards are de facto, based on proven implementations. I think we are slowly moving towards a world where this is becoming more of a rule than an exception...
Matthias,
I think the biggest reasons for this are lack of (consumable) tooling to do it and vendor unwillingness to invest in something that might conceivably help the competition. Have you seen my MST proposal? I have given up waiting for tool vendors and decided to do something about it myself... Might you be interested in contributing?
Hi Kenn,
I completely agree with you that tooling support would help a lot! Your MDT\MST project looks interesting! But at the moment I'm working on enterprise software, without any modeling techniques, so I can't contribute a lot to such a project :-( But of course I will test drive MDT\MTS when it's released ;-)
That's a good list for the level of abstraction that you considered, but I think the problems are a lot more fundamental.
Your post actually inspired me to start my own blog, so you can read my take on it there.
http://tfmorris.blogspot.com/2008/10/whats-wrong-with-uml.html
Tom, my list of things that are wrong with UML is actually quite long; here, I tried to pick three of them which I think may actually be fixable (many others are a lost cause, and attempting to address them would be an ocean boiling exercise) and which are currently stumbling blocks to reuse and interoperability...
I'll take a look at your blog (I'm glad to have inspired you!) and reply with my comments.
I have found serious errors in some definitions of terms and conventions of UML and the process of using them. Have you observed any such errors? Do you have suggestions for corrections / improvement? Are there any blogs / publications on these.
Is there anything new in the last two years?
Post a Comment