P.9. For Further Reading

The full treatment of software architecturehow to build one, how to evaluate one to make sure it's a good one, how to recover one from a jumble of legacy code, and how to drive a development effort once you have oneis beyond the scope of this book. However, general books on software architecture are becoming plentiful. Bass, Clements, and Kazman [Bass+ 98], Hofmeister, Nord, and Soni [Hofmeister+ 00], Shaw and Garlan [ShawGarlan 96], Bosch [Bosch 00], and Malveau and Mowbray [MalveauMowbray 01] provide good coverage.

The Software Engineering Institute's software architecture Web page [SEIATA] provides a wide variety of software architecture resources and links, including a broad collection of definitions of the term.

David Parnas first made the observation that software can be described by many structures, not just one [Parnas 74]. This insight led directly to the concept of views that we use today. Architectural views in general, and the so-called "4+1 views" in particular, are a fundamental aspect of the Rational Unified Process for object-oriented software [Kruchten 98]. An overview of views is given in [Bass 98] and [Jazayeri 00]; a comprehensive treatment appears in [Hofmeister 00].

One of the goals of documentation is to provide sufficient information so that an architecture can be analyzed for fitness of purpose. For more about analysis and evaluation of software architectures, see [Clements 01].

The seven rules of sound documentation are adapted from [ParnasClements 86], which also espouses a philosophy directly relevant to this book. That paper holds that although system design is often subject to errors, false starts, and resource-constrained compromises, systems should be documented as though they were the product of an idealized, step-by-step, smoothly executed design process. That is the documentation, it says, that will be the most helpful in the long run. This book is consistent with that philosophy, in that it lays out what the end state of your documentation should be. We understand (and sympathize with), but do not emphasize, that the intermediate states may fall considerably short of that goal. It's the final product that is the object of our efforts.

Architectural styles that one chooses (as opposed to the ones that are present in every system) are thoroughly treated in [ShawGarlan 96]. Chapter 3 consists of a number of example problems. For each one, several architectural solutions are presented, each based on the choice of a different style. These side-by-side comparisons not only reveal qualities of the styles themselves, but richly illustrate the overall concept. A tour de force in style comparison is found in [Shaw 95], in which the author examines 11 different previously published solutions to the automobile cruise-control problem and compares each solution through the lens of architectural style.

For encyclopedic catalogs of architectural styles, see [Buschmann+ 96] and [Schmidt+ 00].

Design patterns, the object-oriented and finer-grained analog of architectural styles, are covered in [Gamma+ 95], [Alur+ 01], as well as a host of online resources and conferences. Jacobson et al. devote an entire section to architectural styles for object-oriented systems designed with strategic reuse in mind [Jacobson+ 97]. Smith and Williams include three chapters of principles and guidance for architecting systems in which performance is a concern [SmithWilliams 01].