Friday, June 01, 2007

 

Should Architects use UML...

If you work in a large enterprise that understands the distinction between a project management lifecycle and a software development lifecycle, you may be compelled to use UML for designs, yet no one has taken the time to understand why UML continously disappoints...



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:

  • You can play with yourself.

  • You can play with your own toys (but you can't take them apart),

  • You can play with toys that were given to you.

  • And you can play with toys you've made yourself.


  • 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...






    << Home
    | | View blog reactions


    This page is powered by Blogger. Isn't yours?