Opinion: Five Diagrams Redux

In his Sept. 24 Computerworld column, “Five Diagrams Beat a 'Victorian Novel' Text Specification,” Michael Hugos states that Unified Modeling Language “can probably be blamed for many failed system development projects.” He ascribes this to UML's voluminous text-based approach (which he compares to Victorian novels) and, as a remedy, recommends his own homegrown, diagram-based method, since “a picture is worth a thousand words.”

There are, no doubt, valid reasons to criticize UML from a technical perspective — after all, like Fortran, it is in many ways the first of a new generation of computer languages. However, Hugos' critique seems to be based on secondhand knowledge of UML at best. How else can one explain the startling statement that diagram-based approaches to software specification should be used instead of UML? UML is fundamentally a visual language with a diagram-oriented concrete syntax supported by a formal metamodel that defines its well-formed rules and semantics. In fact, its graphical nature has been a primary focus of criticism by those who prefer text-based languages.

Like Moliere's Monsieur Jourdain, who spoke prose all his life without knowing it, Hugos may be surprised to discover that four of his five diagram types are either valid UML diagrams or can be mapped directly to corresponding UML diagrams, with one important difference: UML diagrams are composed of elements that have a standard semantics associated with them. The latter is crucial, since a well-known problem with many modeling notations of the past was that their semantics were either undefined or vague. This often led to misunderstandings that went undetected until extremely late in development and required expensive rework. (Although a picture may be worth a thousand words, for engineering purposes, it is critical that it speaks the same thousand words to each observer.)

Thus, Hugos' process flow diagram, which actually consists of two different diagram types (one representing structure, and the other data flow) combined with some rather monotonous-looking text, is really a special case of a UML class diagram with information flows (for the structural part) and a special case of the UML activity diagram (for the data flow part). Of course, these diagram types in UML offer many additional modeling capabilities, but for those who would prefer to keep things slim, it is always possible to define a UML profile that limits the diagrams to just the desired subset. The advantage of a profile as opposed to a homegrown notation is that one can take full advantage of standard UML tools as well as widely available UML expertise.

The logical data model of Hugos' approach is a limited form of UML class diagram (but one that seems to leave many open questions about aspects such as multiplicities and compositional relationships). The system architecture diagram is a standard example of a UML collaboration diagram (including the use of PC, network and similar icons for the various components), and the software object model is yet another UML class diagram in which all the classes are artifacts.

This leaves the screen map and screen layout “diagrams,” which are indeed outside the scope of UML but that can certainly be combined with UML diagrams in precisely the same way as specified by Hugos.

There is a well-known syndrome among software practitioners who are passionate about their craft, which is best summarized by the phrase “I can do it better.” Unfortunately, this often leads to “reinventing the wheel” syndrome, which seems to be the case here. This is not only wasteful but can also be dangerous, since homegrown notations rarely have the necessary semantic depth and precision necessary, leading to much miscommunication, the need for significant rework late in the development cycle and even project failures.

Bran Selic, an IBM distinguished engineer at IBM Canada, is co-chair of the UML 2 task force in the OMG.

Copyright © 2007 IDG Communications, Inc.

Shop Tech Products at Amazon