A style manual for the unified modeling language (UML) could not be published at a better time, but this edition of Ambler’s book will not satisfy purists. UML has become a ubiquitous modeling language. Developers now use UML diagrams in place of American National Standards Institute or European Computer Manufacturers Association standard flow charts. Moreover, UML is changing. Initially, UML provided a half-dozen diagrams. It had use case diagrams to model functional requirements, and class diagrams for ontologies and object-oriented designs. State charts showed dynamics. Interaction diagrams showed communications between objects. Deployment and component diagrams modeled hardware and software structures. UML is now evolving toward being a universal modeling language. The new UML 2.0 has 13 diagrams. Many organizations and individuals will need guidance in using them. This book will help. It provides more advice than Fowler’s book [1], but Fowler’s book is a better introduction to UML. Larman’s book [2] is an introduction to a unified process using patterns and parts of UML. Ambler avoids process issues and patterns.

The book is small, so it can sit on a desk next to a developer’s machine. It has 17 chapters and a good bibliography and index. The first 16 chapters offer 308 pieces of advice. The first two are “Avoid crossing lines” and “Depict crossing lines as a jump.” A short explanation follows each piece of advice. Ambler covers every type of diagram. The last chapter summarizes Ambler’s Agile modeling book [3].

Ambler writes well, but his evidence is anecdotal. He seeks simple and obvious ways to express ideas. Sometimes, he ignores or contradicts parts of the Object Management Group’s draft standards for UML 2.0 [4]. It would be better if the author signaled when he does this. For example, Figure 49 follows the older UML standard, not UML 2.0. It shows components on a deployment diagram, not artifacts. Ambler does not mention UML 2.0 artifacts. Fowler [1] and Larman [2] do. Similarly, Figure 7 and the nearby text suggest that property strings are in the object constraint language. They are not.

Sometimes Ambler makes good, but nonstandard suggestions. For example, he recommends using an ellipsis to suggest missing information. I like this, but it is nonstandard. He also shows actors on use case package diagrams (Rule 151).

Ambler also makes suggestions that I dislike. An example is in chapter 10. The first paragraph mentions using activity diagrams for data flow diagrams. Systems analysts often use these diagrams to map out the high-level components in systems. Activity diagrams require too much low-level detail for this purpose [5]. The standard gives a better option. Section 17.2 [4] provides “information flows” as “mechanisms for specifying the exchange of information between entities of a system at a high level of abstraction.” These, plus the standard stereotypes for component («entity», «process», and so on), fit systems analyst’s needs. Activity diagrams are good for low-level logic and flow charting.

I have about a half-dozen other issues with this edition. Most of these are minor and easy to fix. For example, in the introduction, why is there no reference to Kernighan and Plauger’s book on programming style [6]? The book is still timely and helpful. At least 95 percent of the rules are not controversial. If the issues are fixed, even purists can recommend it to all students after some basic UML training.