![]() |
|
Bingo! Ladies and gentlemen, we have a winner -- Use Case Driven Object Modeling with UML, by Doug Rosenberg (with Kendall Scott) has more hot buzzwords in its title than anything that's come across my desk in a long time. It is also a readable, informative, and practical guide to using UML, and will probably replace Fowler's UML Distilled on my recommended reading list.
UML (short for the "Unified Modeling Language") is an everything-for-everyone collection of graphical notations for object-oriented analysis and design. It includes use cases, class hierarchies, state charts, sequence diagrams, and just about everything else that its authoring committee thought might be useful. Most CASE tool vendors have already shipped UML-aware versions of their tools, and many recent books on Java, design patterns, and business reengineering have adopted it for diagramming.
All of which would be good news, except for two things: UML's breadth makes it hard to navigate, and it still leaves an uncomfortably wide gulf between the analysis ("what") and design ("how") phases of a project. The principal value of this book is that it tackles both of these issues head-on. In just eight chapters, Rosenberg (who is the founder and president of ICONIX) presents a slimmed-down core of UML, organized around a four-stage design process. Each stage has clearly defined steps, and concrete milestones that specify what ought to be produced (that is, how to tell when you're finished).
UML's second weakness is addressed by one new bit of notation, which Rosenberg calls a "robustness diagram." While the connection between the general idea of robustness and these diagrams seems a bit tenuous to me, they appear to be a useful bridge between use cases on the one hand, and implementation-oriented diagrams on the other. Their value becomes clear during the development of the book's running example, a simple stock-trading system.
I have only two criticisms of this book. The first is that Rosenberg repeatedly refers to, and discusses, both older design notations and debates about the finer points of UML -- in fact, he devotes an entire appendix to the difference between "uses" and "extends," despite the fact that he clearly doesn't think the difference is significant. This material might be of interest to the cognoscenti, but is out of place in a book aimed at newcomers.
The second criticism of this book is one that I thought I'd never make: It is simply too short. Having finally found a useful, readable, and practical description of a design-centered development methodology, I really wanted a dozen or more examples of each point to work through. If the authors were to produce a companion workbook, I can promise them that they'd have at least one buyer...
-- Gregory V. Wilson (gvwilson@interlog.com)
| Readability |
|
| Originality |
|
| Organization |
|
| Accuracy |
|
| Consistency |
|
| Depth |
|
| Timeliness |
|
| Editing |
|
| Design |
|
| Overall Value |
|
Explanation of ERCB rating scale: No stars = unacceptable, 1 Star = marginal, 2 Stars = average, 3 Stars = above average, 4 Stars = exceptional.