UML 2 Toolkit (Paperback)

This book is the best guide I've seen so far. It covers all of the major kinds of graphical notation - over a dozen - that UML uses for describing systems and software. The first part book follows a clear, logical path from the original exploration of requirements, into basic, static design of program elements, and on to the dynamic behavior of software and the systems built around it. UML isn't just about software - it's about meeting real human needs using complex systems.

One strength here is that the authors show Java-based examples of wht the UML notations really mean. That has always caused difficulty for beginners - which Java language constructs are the 'right' representations of UML specifications? The answer has ambiguities, but the authors show some ways to create a proper correspondence.

The later parts of the book describe successively higher levels of system representation, as supported by the UML. They show how design patterns look in proper UML - a real help, since the best DP books predate modern UML. The authors also demonstrate how UML can be extended to meet new needs, or to represent fine, application-specific levels of detail.

I admit to mixed feelings about extensions to the standard. In some ways, extensions are necessary. I have found even basic class diagrams desperately in need of extension - when they address my program design issues at all, they immediately lock in details of implementation that should have been left open. On the other hand, an extension to the standard is, by definition, non-standard. Extensions almost automatically violate UML's goal of uniformity and shared ways of expressing shared concepts. Perhaps I need to see more real-world examples of successful extensions.

The final chapters of the deal with the fundamental concepts needed to make UML work properly: the Model Driven Architecture and broad script for using UML within that paradigm.

Although the authors do a good job of presenting the material, this part of the UML spec is where I have my strongest reservations. I'll agree that analysis and architecture are different from programming, and probably deserve different ways to express their concepts. I certainly agree that all of the different ways to view a system need coherency and cross-validation. My notation should be my servant, though, not my master. Forcing myself into the mold of a person for whom UML works is painful and unproductive. If the notation is so complex that it can only be used within elaborate tool suites, I wonder how well it will accept the sets of tools that I already use. Can I really get UML tools to integrate with Mathematica, Java, Word, VHDL, and source control? If not, then they do not really work with my system. I know, my combinations of tools are idiosyncratic, but other development environments use tool combinations at least as complex. Finally, if UML requires such tool support, does it really meet my needs as a mere human?

UML is real, it has wide value and acceptance in the industry. This book, from the OMG press, comes straight from the UML standards body. I recommend it as a good way to start with most of UML's features, almost an index to the reams of OMG standards documents. I advise the reader to approach UML carefully, though: use it to support your design needs, don't subjugate your design to it.

This isn't an easy read.