 |
|
Ivar Jacobson is generally considered the "father" of use cases. He appears to have written most of this book, and in a more general sense, he has clearly convinced Rational to build its development process around this concept. In The Unified Software Development Process, Jacobson comes across as a preacher out to convince lost souls about his truth.
For instance, on page 34 he states that "use cases drive the development process." In my experience, this is not necessarily the case. The main value of use cases is during the analysis stage and when developing system test cases. In truth, they don't help much at the design and implementation stages. For example, use cases do not carry information about structural aspects of the system and nonfunctional aspects. Nor, for that matter, do other process approaches (such as those described in Object-Oriented Development at Work: Fusion In the Real World, by R. Malan, R. Letringer, and D. Coleman, Prentice-Hall, 1996, or Use Cases Combined with Booch/OMT/UML: Process and Products, by P.P. Texel and C.B. Williams, Prentice-Hall, 1997), give such prominence to use cases.
The Unified process does not make a clear distinction between analysis and design; its analysis model uses controller and view classes. In my opinion (as well as James Rumbaugh's; see "OMT: The Development Process," JOOP, May 1995 -- why didn't he speak up here?), these classes are software artifacts and don't belong here. In fact, this separation of classes is just an application of an architectural design pattern -- the MVC -- which is not even mentioned in The Unified Software Development Process. No mention of analysis patterns can be found either, even though they will likely become very important to produce correct models of complex systems.
The discussion of architecture (page 83) doesn't consider important aspects such as mapping to hardware, distribution, serious use of architectural patterns, and the like. Design patterns also don't have an important role here.
Components are defined as "physical packaging of model elements;" that is, they are just the resulting implementations of the model classes. How about the use of components in a more modern fashion, JavaBeans, for instance, as done in the Nokia process (see "Extending the Object-Oriented Software Process with Component-Oriented Design," by M. Laitkorpi and A. Jaaksi, JOOP March-April 1999). In fact, components do not even have to be object based.
Although Rational is a well-known producer of tools, the process described in The Unified Development Process surprisingly doesn't make a significant use of tools. Three pages discuss tools in general at the beginning of the book and tools are briefly mentioned later, but there is no clear integration with the proposed process. Likewise, testing is also dealt with rather superficially. The chapter on testing deals mostly with integration testing. There is almost nothing on class testing; for example, the authors of The Unified Development Process don't consider the use of pre- and postconditions and other important issues. What is worse, the concept that testing should be applied at all stages of development is not considered. The references in this section reflect a lack of awareness of progress in this area.
On the upside, at least in terms of practical value, the book provides a clear definition and separation of roles and people involved in the process. This is probably the strongest point of the Unified process described in the book. The running examples are good and help the reader to understand the concepts. They should have been given more importance. Some data on the experience of using this approach would have been useful.
The style is clear, but verbose. More examples, diagrams, and discussion of cases would have been more appropriate than so many philosophical discussions about the value of their approach. Pages 441-480, for instance, are a glossary -- the need for which I cannot understand in an advanced book like this. Do readers need to be told what an "object" or "state" is?
In summary, The Unified Software Development Process should be taken as a user manual for anyone already using or contemplating use of the Rational process. It doesn't provide much insight on how this approach compares to other approaches. Most of the references are to the work of Rational people, the process models of others are ignored. The book doesn't much help somebody looking for a possible process to use. Truly, this is not a scholarly book, but it would have been nice to see how they compare their approach to others.
There is no doubt that the authors have a good deal of knowledge and experience. My objections are to the biased approach and the lack of comparison with other approaches. This book looks too much like a typical vendor book, i.e. "We invented everything." Also, Jacobson has completely smothered Rumbaugh and Booch here; their process philosophies don't shine through. What is worse, the Unified process as described here appears antiquated because of its lack of emphasis on patterns and components.
I am not saying that you cannot learn something from The Unified Software Development Process, but I found it disappointing, especially after seeing the other two volumes by this trio (for more information, see http://www.ercb.com/brief/brief.0097.html).
-- Eduardo Fernandez
| 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, 5 stars = stellar.