May 16, 2008

...Learn TDD with Codemanship

UML Is Alive And Well (And On A Whiteboard Near You)

This post lists 13 reasons for UML's descent into darkness.

Some of them are very valid points. Some of them are misinformed bunkum.

That UML is overly complex and difficult to learn and comprehend is a given. That the over-emphasis on selling modeling tools has clouded the just-sketch-it-at-the-whiteboard benefits of visual modeling is undeniable. That the attempt to turn UML into a programming language has been a bit of a wild goose chase and little more than a minor distraction for your average software developer is as plain as can be.

But the later points in the list display the author's misguided preconceptions about UML. First of all, he bemoans the "lack of solutions for real world problems", and cites "no solution for multitasking and communication between tasks" and "no dependency between use cases" as examples. If I'm reading him right, then he's got that wrong on both counts. You can model multiple concurrent activities in UML, and you can model signals being sent between concurrent threads of activity. And you can most definitely model dependencies between uses cases!

Then he levels the accusation that UML "assumes you can know everything before writing the first line of code". I know from practical experience that you can model a little, implement a little, model a little more, and be pretty iterative and Agile and model-driven at the same time. I think he's confusing code generaton with visual modeling there. And anyhoo, your C++ compiler is a code generator. Do you write the entire program before you ty to compile it into machine-executable instructions?

Certainly, round-trip engineering in UML modeling tools is as clunky as hell, and I recommend you avoid it like the proverbial plague. But drawing a class diagram on a scrap of paper to help visualise or communicate the refactoring you're about to do, for example, doesn't sound very Big Design Up Front to me. Let's make this perfectly clear, UML does not make you do waterfall development. Granted, many in the UML community have that leaning, but it's not the notations that's at fault. They were waterfall-ers long before UML came along.

He continues to dig the hole he's standing in by suggesting that "UML tries to standardize and formalize the unknown, the imagination and the talent". OK. So C# doesn't then? It's a language. Languages constrain thinking to the concepts they support. If UML hasn't got the notation you need to say what you want to say, use another notation. Nobody's gonna hunt you down because you used a non-UML diagram to make yourself understood. Unless, of course, you've forgotten that you don't have to use dedicated UML modeling tools to do visual modeling.

So, while I completely agree with some of the points, I would strongly argue that we avoid throwing the baby out with the bathwater here. The UML notation is still useful,and is still being widely used, albeit in a vastly simplified, cut-down budget version. UML helps developers to visualise and communicate a bunch of stuff that developers are interested in, regardless of what approach they're taking to development.

Contrary to reports of its demise, UML is alive and well on a whiteboard near you.

But then, I would say that, wouldn't I?

Posted 3 weeks, 5 days ago on May 16, 2008