Friday, June 01, 2007
Should Architects use UML...
Throwing specifications over the wall is growing even more popular with the advent of outsourcing and use of UML in many situations may distort the understanding of the person on the other end. To understand the problem space, one needs to acknowledge that UML neither describes semantics nor metrics.
UML doesn't describe the meanings of classes, objects, states, or sequences. It only provides a bunch of placeholders for words that are supposed to describe these meanings. This means that people will make their own assumptions about what a diagram means based on nothing but the 2-D proximity of your layout. And that's not enough dimensionality to express any significant meaning at all.
What's worse, UML provides no metrics to tell you when a particular diagram or a part of a diagram is well constructed or poorly constructed. And it doesn't help you visualize any such metrics that you might use yourself. There are no UML tools, for example, that will tell you when you have violated the Law of Demeter, or the Open Closed Principle, or even the simple Acyclic Dependencies Principle.
For those that don't understand the Law of Demeter, it specifies that one should only talk to your immediate friends. one should never call a method on an object you got from another call nor on a global object. In non-technical terms, an example would be:
The Open Closed Principle says that software entities should be open for extension, but closed for modification. Think about the principle of immutability here. Acrylic Dependencies define the structure between packages and state that it must not contain cyclic dependencies.
UML is a modeling language without a model and is merely a collection of symbols. I wonder if the folks from the BPM community and their BPMN are taking us down this same rathole...
Links to this post: