Thursday, April 21, 2005

The Utility of UML

I think that any software developer likes to see the design of his system in UML just as any engineer might like to see the schematics of a system that he has designed (as opposed to just seeing the final package). For that last few years UML has been put forward as the way of expressing software design. Unfortunately, in the harried trenches, most people can not even understand UML, and often its utility is questioned. Personally I like UML, but mostly because a UML tool will give you a way to diagram a system without forcing you into the endless tweeking of diagrams that you often have to do when making them in word or visio.

So you see, I like UML (and I have spent a lot of time and effort trying to apply it to my everyday work), but even I find it difficult to justify. And I have made zero effort trying to force my co-workers to understand it. Why is this? Is it because secretly I question its utility also. In fact I do question its utility for developing software systems. This week we were trying to come to grips with implementing in new and rather complex system. In terms of our normal project size, this is a good one - not so big that it can not be done, not so small as to be trivial. This for me is where UML comes in. Recently in Queue there have been a series of articles on UML fever and how to get cured of it. The most profound statement of this set of articles for me was that you can use UML to explore the design space (and while doing so, learn how the software should be implemented), but you are still developing software, not UML diagrams. I must say I find this to be a revolutionary way of approaching a problem.

I find that creating a quick UML project (I am using Enterprise Architect) where I can define a set of requirements, hack up a few simple use cases with a scenario or two and then do a simple activity diagram or two allows us to have a concrete base to discuss the design. After this I will (rarely) hack up a few simple class diagrams, but more often than not, I just discuss the ideas with co-workers and we can then start the developement from notes on scraps of paper. The UML diagrams and notes are referenced but are never followed in detail. The thing is that the UML diagrams are just tools to explore the design space. I really don't think UML should be used to over-specify systems where the architechs create every object and every method and the developers just add the boilerplate. This is the way most tool venders feel that you should be using the tool.

But then, have you ever reverse engineered class diagrams from existing code? The result, while it may be pretty and it may impress the boss, is actually almost useless.

1 comment:

ds said...

Anything is easier that Visio. With me a typical visio editing session goes like this:

1. get everything so it is 95% correct.

2. move one points (everything else screws).

3. fix a screw up (10 other things screw up worse).

4. curse.

5. delete the file and hack something with "paint".