The Elements of UML ^2.0 Style

by Scott W. Ambler
Cambridge University Press, Cambridge, UK, 2005
200 pp., illus. Paper, $14.99
ISBN: 0-521-61678-6.

Reviewed by Kasey Asberry
Human Origins
San Francisco, CA

kasberry@humanorigins.org

In Elements of UML ^2.0 Style, Scott Ambler works to fill an important need within the software development community for a concise guide to the UML 2.0 specification. UML (Unified Modeling Language) is the International Standard Organization specification [ISO/IEC 19501] for diagramming Object Oriented Programming. UML has been hashed out and formalized through collaboration and corporate partnership since the mid-1990s, significantly by an early group of independent modelers and then later in concert with software companies.

This effort arose in response to the mission-critical need to regularize software specifications. As development practice has evolved, teams are often large and geographically distributed; software projects have such complex lifecycles that they can’t thrive without meaningful documentation. UML aims to provide clear conventions to streamline and objectify the diagrams that describe information flow and other interactions between software, systems and their users.

Elements of UML ^2.0 Style is a poetically slim volume of guidelines to the application of UML. Patterned after Strunk & White’s definitive The Elements of Style for written English, Ambler’s Elements is vastly more accessible than the ISO specification for UML. Its topical organization is clear, and the language is schematically spare. Each of the 308 concepts is amply illustrated. Ironically, it is the thoroughness of Ambler’s work that demonstrates that UML is neither English nor a Markup Language, both of which are verbal rather than visual systems & amenable to the Standards movement. Concise documentation of UML begs the question of how useful systemized drawing style is in the synthesis of design solutions. The domain UML treats is both cartographic and constructive——that is, in the process of design the space that software operates in is simplified and mapped to a constrained field of vision that creates an artifact that will be carried into development, validation and iteration. The artifact’s primary function is to be understood by the team that must interpret it and secondarily to be constantly valid — that is, consistent through the lifetime of the project.

The design and conservation activity that produces these diagrams is not self-expression in the sense of fine art nor are the most fitting designs negotiated from pattern replication. Such innovators as Enrico Fermi, Robert Feynmann, R.Buckminster Fuller and Christopher Alexander all rely upon visualization to synthesize solutions Their work does not use a formal design language to express their ideas, and yet it is their diagrams that have the most universal appeal because people understand the interplay of complex concepts through them.

Any architect will tell you that its more fun to make rules than it is to follow them; this does not reflect a lack of discipline but rather an availability to effective design process. Excessive focus upon formalism may miss the point of design & language both. The dream of economical communications drives us toward a true UML, even an executable UML. There is a tension in software development between constructive & prescriptive forces; UML as a young discipline falls near the prescriptive pole. Will the investment in formal diagramming that UML represents yield a normalized development process?

Contrast G Polya’s methods as outlined in How to Solve It. "Visualize the problem as clearly as you can" Polya employs diagrams as a tool to construct solutions from the organizing or first principles of a domain, in his case mathematics. In the domain of cartography the cognitive activity associated with mapping is understood to be "constructed and reconstructed until it reveals all the relationships constituted in the interplay of data…a graphic is never an end in itself, it is a moment in the process of decision-making."

Problem-solving in general and design practice in particular share a reliance upon the understanding and application of first principles relative to the domain in consideration. Examples of first principles in software development include service to users’ needs such as

• to minimize cognitive overhead by providing appropriate information at the right time
• limit available choices to those that are meaningful
• mediate business goals with users’ goals

During construction these principles are applied on-the-fly just as we create everyday language. Working from a storehouse of components and connectors a fitting software design is created by clear definition of systemic constraints and opportunities and mediation of them by returning to first principles. How you draw this is less important than that you draw it. Problem solving diagrams work because they move ideas around. UML aspires to ideogramic representation that chunks information and stores it in iconic memory. Can architectural diagrams function as ideograms and still retain their constructive power?

Ambler’s Elements brings this question into focus. The work is particularly refreshing when Ambler calls attention to contradictions in the usage of UML, demonstrating that the debate over how to express ideas diagrammatically remains in flux. A living language requires inconsistency. Ambler’s reflection of the inconsistencies in UML render it more powerful as a language, not less, and this is a strength in his work.

Scott Ambler is well known for his ground-breaking work on Agile Modelling, a refined application of UML and Extreme Programming characterized by the values of: "communication, courage, feedback, simplicity and humility". Unfortunately in Elements these powerful ideals are sometimes contradicted by awkward self-references. This compares unfavourably with the impulse that informs Strunk & White’s work that "evidences the authors’ deep sympathy for the reader". Ambler’s Elements is occasionally weakened by an over-emphasis upon conserving "the" UML as its been developed by its experts at the expense of pushing it to operate and evolve linguistically in service to the user. Elements functions best as an index of modelling opportunities or "moments" and approaches to them. It also graphically illustrates where UML succeeds and what still remains to be done.

The impulse towards a UML is both high-minded and survival-oriented; we wouldn’t have software at all were it not for the commitment to share information in an organized and meaningful way. But Unified Modeling Language is more Esperanto than Swahili, its patterns have had their rough edges removed by committee rather than abraded & refined by linguistic processing. In it we have a constructed language but not a lingua franca for constructive activity.

Ambler’s Elements of UML^2.0 Style is a useful book because it is a compendium of common conditions that software architects treat. It is an interesting work because it reflects, if sometimes uncritically, the state of the art of design in Software Land including its tensions.

References

Alexander, Christopher, (1964) Notes on the Synthesis of Form, Harvard University

Ambler, Scott W., (2002) Agile Modeling: Best Practices for the Unified Process and Extreme Modeling,

Fermi, Enrico: http://en.wikipedia.org/wiki/Enrico_Fermi

Feynman, Robert: http://en.wikipedia.org/wiki/Feynman_diagram

Fuller, R. Buckminster: http://bfi.org/our_programs/who_is_buckminster_fuller/design_science
MacEachren, Alan, (1994) Visualization in Modern Cartography, Pergamon Press

Polya, G. (1945) How to Solve It: A New Aspect of Mathematical Method, Princeton University Press

Strunk,Jr, W, White, EB, (2000) The Elements of Style, 4rth Edition, Allen & Bacon