|
31 of 31 people found the following review helpful:
4.0 out of 5 stars
A fine book despite some reservations, January 27, 2002
An excellent book well organized and generally well written. Recommended either to learn about Rational Corporation's Rational Unified Process (RUP) or even just to get a general acquaintance with current ideas about software development methodology.Mr. Kruchten advocates describing a software product with various summary, abstract views. In this book, he practices what he preaches by giving just the "architectural" view of RUP, whose in-depth treatment would not fit in just 300 pages. There are seventeen chapters divided into two sections. A reader interested only in RUP's distinctive features may skip chapters 1 and 14-17. Section I comprising chapters 1-6 provides the motivation (software development best practices) and the dominant themes (architecture and use cases) of RUP, describing it also along two main dimensions: the dynamic dimension of phase and iteration and the static dimension of workflow. Section II dedicates a chapter to each of RUP's nine workflows. There are two final chapters, one with sample plans for iterations in different project phases and one discussing how to implement RUP in a development organization. There are two useful appendices, a dictionary of acronyms, a glossary, and a quite helpful annotated bibliography. In RUP a workflow is an interrelated set of activities producing a cohesive subset of the artifacts of a software development project. The chapters describing workflows vary somewhat in length and quality, but they all follow the same pattern: (1) start with guiding principles; (2) describe the activities, workers, and artifacts of the workflow; (3) conclude with some comments on tool support (a little marketing for Rational Corporation's tool suite). The best workflow chapters: Project Management, Business Modeling, Test, Configuration and Change Management. The high recommendation comes not without some reservations. Architectures are important in RUP, but Chapter 5, "An Architecture-centric Process," garbles this message by describing architectures as mere derivatives of "complete" system descriptions (called "models"): "Architecture is what remains when you cannot take away any more things and still understand the system and explain how it works (p. 82)." Again, " . . . models are complete representations of the system, whereas an architectural view focuses only on what is architecturally significant (p. 89)." Finally, "Architectural views are like slices cut through the various models, illuminating only the important, significant elements . . . (p. 90)." These explanations fail to recognize that architectures come first. Architectures are constraints that determine subsequent design and construction of the system. They are primary, not derivative, not mere views of models. Fortunately, RUP recognizes the primacy of architecture even if these explanations do not. These explanations also fail to recognize that an architecture is a complete and distinct model in its own right. They are out of harmony with the book's own (wordy) definition of architecture, which includes "The selection of structural elements and their interfaces by which the system is composed . . . (p. 84)." So when the elements and interfaces have been defined, the architecture is complete, right? It escapes this reader how architectures can be inherently less complete than models (whatever they are), when there is not even any one model that completely describes a system (see p. 81). The relationship that Chapter 5 describes between architectures and models is very similar to that described in Chapter 10 between the analysis model and the design model. Mr. Kruchten limits the value of retaining the analysis model as a distinct artifact: "Generally, there is one design model . . .. The upper layers of this model describe the application-specific, or more analysis-oriented, aspects . . . In some companies-those in which systems live for decades or there are many variants of the system-a separate analysis model has proved useful (p. 175)." Generally, companies that plan to stay in business DO expect their systems to live for decades-as do companies that spend millions of dollars using RUP to build them. As for "the extra work required to ensure that the analysis and design models remain consistent (p. 175)," the right tool can make all the difference. Anyone familiar with tools for database design (Erwin, for example) knows that they provide extensive facilities for maintaining separate, consistent analysis (logical) and design (physical) models. The tools offered by Rational Corporation, however, do NOT provide such a facility. Could Mr. Kruchten be tailoring the methodology to fit the limitations of the tool that his sponsor sells? Compare his attitude toward the analysis model with that of another author in the Addison-Wesley Object Technology Series. Martin Fowler in his UML Distilled says, " . . . it is very important to separate the specification perspective and the implementation perspective (p. 52)." Mr. Fowler uses different terminology, but he is saying essentially that the analysis model ("specification perspective") is valuable as an artifact distinct from the design model ("implementation perspective"). Despite these issues-which might profitably have been discussed at greater length-this fine book admirably fulfills its purpose.
|
by Alistair Cockburn
by Ivar Jacobson
by Grady Booch
by Daryl Kulak
See all 100 books citing this book
