Link Details

i'm an long-time developer, and i find class diagrams and state diagrams the most useful. like code though, a diagram is only useful if it conveys useful information in a simple way. I found the diagrams shown in the article to be immediately obvious -- they are clearly the strategy pattern. I find this type of thing more useful as it shows the intention more perhaps than the code.

however, other people i know scratch their heads at these diagrams. i'm more of a visual thinker.

I'm with you--it's not an issue with UML per se, it's with how it's used. Much of UML *is* useless, but I don't know too many developers that don't end up drawing diagrams that look suspiciously like UML in one form or another.

UML as a *standard* may well be useless and not cover everything developers need, but many of the principles are sound and used even if we're not calling it "UML".

Code and UML class diagrams are not equivalent. There is a mapping from code to a UML diagram, this mapping is not one-to-one, meaning a UML diagram can represent more than one source code.

That doesn't make it useless. UML diagrams represent documentation that serves alongside the source code and the other comments. It doesn't try to supplant it.

And when you say that you don't have to use the UML convention to draw the "big picture", you are right. But then again, there is no real reason to use the GoF design pattern names, like "strategy" or "state". I could use other names, depending on the situation, and that description might make just as much sense, but the big advantage of using these terms that have become standard is that we share a common vocabulary.

I also disagree with the statement that UML sequence diagrams are a waste of time. I was once in a situation where I could have written a thousand words, and I still wouldn't have been able to crisply explain what the code does. A sequence diagram helped me out here.

UML can be very useful, if used correctly.
Problem is, most people don't use it correctly, and that includes most people teaching it.
Another problem (now getting better through hard lessons learned) is that many still regard UML as some sort of Holy Grail of development. In their worldview, if only the UML is followed strictly everything will be perfect and any failure resulting can only be the result of someone not obeying the Holy UML.

What UML is is a tool to be used to document design decisions and code bases. A diagram can shed light on something that would otherwise be invisible, it can often help make code easier to comprehend that seems incomprehensible (it won't improve bad code, but can help in the decisionmaking process as to how that code can be improved).