I teach a course at Trent University on Object Oriented Analysis and Design with UML, and have done since the last century. I teach my students how to make decisions about the systems they will some day build, and how to draw diagrams that communicate those decisions to others. We find as often as not that the act of trying to make the diagram leads us through the thought processes that are needed to make good decisions. That brings huge value even if you never show the diagram to anyone else and never update it.

I've never been a big fan of "technical documentation" in the form of a giant binder that some poor person has to keep up to date any time the code changes. If you want to know all the methods of the Employee class, why not use Intellisense or the Object Browser or the like? But that doesn't mean I don't like making those diagrams at the beginning, when they help me to do my thinking. I also make them when I have something to explain, including when I bring a new person onto a project. So how much do I love this quote?

the UML ... was to be a language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system—in short, a graphical language to help reason about the design of a system as it unfolds. Most diagrams should be thrown away, but there are a few that should be preserved, and in all, one should only use a graphical notation for those things that cannot easily be reasoned about in code.

It's in an interview I already linked to, but it took Patrick Smacchia to point our those sentences to me. As I wind up the last few weeks of the course, it's nice to know that my position on the point of the diagrams and deliverables is aligned with one of my heroes.

Kate