Tools vendors stuck on UML and agility People sometimes do a double take when I talk about analysis, design and agility in the same sentence. And if I mention UML and agility, they spin round several times and fall over. At the expense of inviting a flurry of email replies for posing a rhetorical question, I have to ask: why? Aside from the analysis paralysis issue …
If you recognise that your UML should be kept on the whiteboard, and not as some uber-design document, then you won't have this problem.
If the tools don't work - perhaps its a sign that you shouldn't use them...
(picture of m$, as this is blatant case of selling products that shouldn't exist)
UML has 2 problems:
1) It has everything, including the kitchen sink, in it. This makes for a big complicated application that is hard to learn.
2) UML doesn't enforce a work flow from design to code. It fact it has no direct decomposition into code the way a structured design would.
The main problem is the tendency for developers to be programmers instead of software engineers. The mindsets are different: one is death-or-glory/John Wayne type of person and the other makes solid dull code that works and knows how to handle things when it didn't work (BSOD anyone?)
Do any of you other old-timers feel like UML exists mainly to sell CASE tools and consulting time? I've seen God-knows-how-many projects where everyone was *required* to know, say, Rational Rose, but there was absolutely no requirement that the project have anybody who used it particularly well. Kind of like MS Project or it's much better, more upscale distant cousin, Primavera. If you see MS Project on every screen, you know the project's in trouble; if you see Primavera on a few top managers' screens, and nobody else diddles with it, you start thinking that "maybe this project has a chance".
Or have I been wrong for the last few years, and Agile wasn't primarily a defiant scream of independence from just such mind-rot?
Whilst I accept that UML tools could be better I have to agree with James Richardson when he says “UML should be kept on the whiteboard”. Fleshing out a high level design (which is surely what UML good for) is often best done in a group session with all your diagramming being done by hand on a whiteboard. One of the reasons this doesn’t happen, in my experience, is that people don’t learn to “write” UML. Instead they see a need for a tool before they can produce anything. Kind of like being able to type but not write anything by hand. When I learned UML (see my post http://outofthetriangle.wordpress.com/2007/07/25/learning-uml/) I spent some time practicing drawing diagrams by hand.
Have a look at Trace Modeler, it's a UML tool that's actually easy to use and smart about its domain - sequence diagrams.
http://www.tracemodeler.com
It even has two refactorings, split activation and inline call ;o)
Plus it does all layout automatically so you can focus on the content.
It's really fast for editing, simply drag & drop an activation and it will reconnect and move everything around it so the diagram remains correct and pretty.
There's a 30 sec demo that shows you how it works at
http://www.tracemodeler.com/download/index.html
IMHO, most uml tool vendors focus too much on providing an exhaustive features set and forget all about basic usability.
That's why I created Trace Modeler. I does only sequence diagrams, but it does it very good.
It's interesting that Anonymous Coward brings up the "programming" vs. "software engineering" distinction.
A engineering model is a simplification of a system (aircraft, bridge, office block) that ignores unimportant aspects of the system so that the the engineer can easily and cheaply prove that the system as designed will have certain desired properties (fly, handle expected traffic volumes, not fall over in high winds).
UML cannot be used for creating engineering models. You can't prove interesting runtime characteristics from UML models.
So what is UML good for?
Maybe for visualising ideas on a whiteboard or paper, but it's a piss poor notation for software visualisation.
Maybe as a notation for software blueprints, but if you have enough detail in the diagram to mechanically produce code, you have code and you need all the testing tools as well as refactoring tools, to work with it.
What else...?
I have to agree with Nat Pryce here - UML does not prove that your software will work. You can’t find a bug in your UML and you can’t create UML that can be compiled and that an end user can test. Sometimes I think that is what attracts people to it! I said as much in my post on Effective UML (http://outofthetriangle.wordpress.com/2007/10/06/effective-uml/) as well as listing what you can do to make sure the UML you produce is useful.
Matt Stephens last suggestion is pure bull. However I like the idea of being able to code using graphical+text code rather than just pure text. But the CASE tool should actually produce a working program so UML diagram makers need to concentrate on that aspect - on turning UML into a full featured programming language; anything in-between is not really worth having.
The point at which these graphical tools turn into programming languages will be the point at which they take off.
Don't bother with using UML to document your work; use it as Agile programmers do.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
