email article printer friendly more resources

What UML Is and Isn't
Apply the UML during object-oriented analysis and design to build beautiful Java applications
by Craig Larman

Posted February 20, 2004

The UML is relatively trivial and unimportant. Surprised by that statement? Many are, but we shouldn't be. Nor should the statement be misinterpreted as implying the UML is not useful—it is.

But perspective is critical. The Unified Modeling Language (UML) is merely a standard diagramming notation: boxes, bubbles, lines, and text. The Object Management Group (OMG) UML specification calls it "a standard way to write a system's blueprints," and the term blueprints is an apropos choice. Civil and electrical engineers have standard diagramming languages to illustrate the structure and wiring in a building. We do not equate the ability to read and write standard blueprint diagramming languages with the knowledge and skill to envision and design a building—to be an architect or engineer.

Yet in the context of software development and the UML, acquiring skills to read and write UML notation is often equated incorrectly with skill in object-oriented analysis and design (OOA/D). Getting a book or taking a course that focuses on UML, becoming certified in UML 2.0 notation, or knowing how to use a UML CASE tool has nothing to do with being able to think or analyze in objects or creating well-designed, object-oriented systems. Indeed, there are some who have learned the notation or a UML tool, yet can't skillfully cut code in Java or design with patterns, and in some odd value system are therefore assigned a senior role as an analyst or architect who does the "advanced" work of drawing UML diagrams for others to program. Of course, the diagrams are worthless. Useful UML is sketched by deeply experienced OO programmers (ideally in pairs at whiteboards) as an aid to creative thought and communication before they themselves use their own sketches as inspiration during programming.

What is important is being able to create good object designs and programs—the art of OOA/D. When the rubber hits the road and code needs to be cut, what matters is our ability to assign responsibilities and create a design with low coupling, high cohesion, comprehensibility, and ease of modification. That's very different than knowing a diagramming notation such as the UML.

All that said, I'm an enthusiastic promoter of doing some visual sketching before programming and know that visual modeling (in the UML or any notation) can be a great aid in development, especially when applied in the spirit of agile modeling. Now, let's explore the critical skill, OOA/D, and see how the UML can be applied effectively during analysis and design.

Key Models
Models are abstractions of something. They ignore certain details or summarize. We'll explore various models here, but before going into the specifics, consider this important point: the UML does not define any models. The UML is not a method; it is just raw diagramming notation.