"What UML Is and Isn't"

Java Pro (defunct) has an interesting article entitled, What UML Is and Isn't. The article starts off by slightly comparing software engineering to other disciplines, which have blueprints. The UML is simply a standard diagramming notation, and the OMG describes it as a "standard way to write a system's blueprints."

In other disciplines, the ability to read and interpret a diagram does not imply the ability to create such a diagram, and as LARMAN points out, taking a UML course, being certified in UML notation, or knowing UML from a book does not mean that software engineers can roll out quality software. To create quality software, we must create software with low coupling, high cohesion, easily understandable, and easily modifiable.

The article discusses how the UML's definition kind of pushes us into the "Design All Software Before You Code" mentality, and argues that this is a recipe for disaster. Instead, he recommends using it in the same fashion that the Agile camp views it; use UML as a vehicle to understand and communicate more quickly. Using this diagram, it will guide your development of a feature. Testing and demos of this feature will highlight and clarify your misunderstandings and things that you forgot. I'd have to try it a bit, but it sounds interesting at first thought.

I am slightly concerned with how to keep these diagrams, as he mentions that it should be mostly sketches and very little in a diagramming tool. Sure the diagram tool takes longer to create the diagram, however, it creates a diagram that will last. I'm not sure how useful shifting through a book of a design napkins would be :-).

The article also describes some key Unified Process models, and I found it to be a good quick and dirty overview of UML.