currently interested in awesomeness and how to create it

Does UML speak the truth?

I DELIEVERED A UML WORKSHOP to a group of my colleagues on Wednesday. They were all eager to participate and we went through many exercises. Given a rather vague assignment, they grouped into small teams, thought aloud, communicated beautifully, and came up with reasonable diagrams.

Throughout the workshop, we tried to design a web portal for a travel agency. I was as direct and clear about what I wanted as a typical stakeholder would be (read: not much). They were supposed to figure out what it was, and use their freshly acquired knowledge to create a model that a development team could use for the actual work.

Their Use Cases were more or less similar. Further into the maze of UML 2.0, similarities ended. The more tools a diagram offered, the more creative my students could afford to be. And they did: each activity and sequence diagram offered a unique view on the system being modeled.

UML is a language. It’s an abstraction layer that’s supposed to cover the underlying reality. And as every abstraction, it’s leaky. Some would argue that code is leaky, too, and I agree. The problem is, if you add another layer, are you moving towards or away from the reality?

Methodologies that are using visual modeling are assuming that visual representation of business requirements expresses the stakeholder’s intent better than his or her words. They might (not everyone has the writing abilities of a seasoned analyst) but they ultimately don’t tell the whole truth. They are useful abstractions but they are leaky. They cover just as much as they reveal.

It has been my experience that visualization is most beneficial at the beginning of the project when people – both stakeholders and the development team – need to find common vocabulary, agree on goals, and unleash their imaginative powers so that unclear needs can be materialized into working software requiremens that a programmer can solve. It’s the code that matters, and the more quickly it can be delivered, the better.  However, relying on UML (and other visualization methods) to provide the complete truth is just as time-wasting as writing tons of specs.

August 19, 2007 | Filed Under Software 

comments

Comments are closed.

Additional comments powered by BackType