Via Peter O'Kelly's Reality Check:
ACM Queue - UML Fever: Diagnosis and Recovery: Sidebars from Scott Ambler and Craig Larman
I particularly loved this quote:
'Starting in the late 1990s I became curious how the UML CASE tool vendors (including Rational, TogetherSoft, and others) built their own UML tools. So I started to communicate with some of the developers or managers of these tool projects. When I posed my standard question, âDid you use the UML and your UML tool to create its next release?â the answerâin every caseâwas âWe didnâtâ and typically a fleeting facial impression which suggested either embarrassment or âAre you crazy?!?â'
However the thing that really hit home was this:
My observation is that lean and effective organizations conduct upward of 90 percent of all modeling as sketches on paper or whiteboards, with only a few using sophisticated software-based modeling tools. The reality is that the value is typically in the modeling effort itself, not in the model. Why is it that so few software modeling books or academic papers seem to focus on sketching in terms of recommended best practices? Shouldnât we help developers to get better at what effective modelers actually do in practice, instead of trying to inflict the questionable visions of tool vendors and/or inane academic theories on them?"
My biggest problem with UML tools has always been that they don't let me sketch. All UML tools I've used try to enforce a specific vision of how I should work with UML and try to force me to draw diagrams that look a particular way.
Now, obviously UML is supposed to be "standard". However there are still a number of ways most of the tools deviate from eachother in the look of diagrams, and often what you want is NOT standard UML, but almost standard. You want to fudge something - to say "roughly like this [insert handwaving here]".
Invariably, tool shortcomings have forced me to either revert to generic diagram tools which are hellish to use for complex diagrams (why does noone do diagram editors right) or to post process the diagrams from a UML tool in a drawing program (Gimp isn't exactly the most suitable UML tool available, but when the damn editors can't do their job, it's invaluable).
In general, the problem is that most of the tool writers seems to believe they know the "only true way" of using their tools, while in reality humans have very specific ways they like to work with concepts, diagrams and models, just as with code. If the tool doesn't fit that model, people will go to extraordinary lengths to work around the tool to keep working the way they are comfortable with.
A good UML tool would work with the user, not against him/her, by actively supporting the user in violating the model when that is what the user wants. Fine, show an unobtrusive warning, but don't prevent the user from creating the model they want.
Do I believe in UML based code generation?
Not with the current generation of tools. In general, I do believe code generating tools can work, but they'll need to be designed to be flexible enough for the user to bend them into doing what the user want, instead of enforcing a model that does not fit the way the user works, and that will take a lot more research.