December 21, 2006

...Learn TDD with Codemanship

OOA/D (not necessarily) using UML

UML is not important.

What is important is good design. Well-designed software meets the needs of the people who use it, is maintainable by software developers who didn't write it, and ultimately satisfies the goals that we had in mind when we created it. All of this is eminently achievable without using UML.

What's unavoidable is the thinking process that leads us to well-designed software. I know two things for sure about good design thinking processes:

1. They are evolutionary and allow for feedback from many iterations
2. They are collaborative



UML is focused on helping with the second requirement. Collaboration in design requires us to externalise our ideas so we can share them with other people - like the customer, users, other developers, testers and so on. Until they invent a telepathy headset, externalising our design ideas requires some kind of representational medium in which to express them. In other words, we need a language for design.

But, just as The Bible doesn't have to be written in Latin to makes its point, software designs don't have to be expressed using UML diagrams. What we're trying to say is infinitely more important than how we choose to say it, provided we can make ourselves understood.

Take use cases, for example: what we're trying to say is who will be using the system and what will they be using it to do? An actor represents a type of user, and a use case represents a functional goal. We could also express the same ideas using personas and tasks, or users stories and customers. It doesn't really matter, just as long as we all understand each other.

Similarly, we can use Class Responsibility Collaboration (CRC) cards to describe what objects are involved in a scenario, what each object does and how they interact. These can be just as effective as sequence diagrams or class diagrams.

And we can model state machines using a state transition table instead of UML state charts. (Indeed, they may turn out to be more complete that way.)

It's quite feasible to get from requirements to well-designed working code using alternative representations. What is much more difficult is to get there using no representations at all, since that makes understanding and communicating designs a lot harder and more error prone.

Now, having said all that, I know from personal experience that these other techniques are really no easier than UML, and no more expressive or powerful. That's why I usually choose a UML diagram for most aspects of software design. No doubt in years to come we'll have better visualisations to work with - we are lagging behind other engineering and creative disciplines quite a lot. But for now, 90% of the time, UML will do the job.

There are a few "Agilistas" who refuse to use UML. Personally, I think they're being a bit awkward. Sure, there are alternatives, but there aren't many better alternatives at the moment. Feel free to invent some ;-)
Posted 4 days, 19 hours ago on December 21, 2006