Building good software is like building many other kinds of systems. You start by building a skeleton, and then you add on to that skeleton, making sure that whatever you add to the system later will not impact what you built previously. When it comes to software, you can, after some initial prototyping, design a skinny system that includes the skeleton that you can build upon. To make sure that you can grow the skinny system to become the full-fledged system, you must determine whether the features not yet included in the skinny system can be added later without redesign of the system. In fact, you need to make sure that all risks that may impact the graceful growth of the skinny system can be taken care of without redesign.
The skinny system is developed as an early version of the system, called the architecture baseline. It contains the small but representative parts of the system, including requirements, analysis, design, code, and tests—but only the important ones. Accompanying the architecture baseline is an architecture description that consolidates your decisions.
The quality of the architecture is one of the most significant determinants of the success of the project. The emphasis in the early part of a project is on establishing a resilient architecture, one that systematically keeps concerns separate. Since there are different kinds of concerns, you use different techniques, too. With object orientation, you can keep the specifics of different kinds of objects separate with classes. You apply layering to keep the specifics of the domain separate from those of the application. However, the emphasis of this book is about keeping crosscutting concerns separate, and we spend time on this topic. In particular, we demonstrate how, with use-case slices, you can:
Keep use-case specifics separate from use-case generics.
Keep the handling of extensions separate from a base.
Keep the realization of nonfunctional requirements separate from functional ones.
Keep platform-specific separate from platform-independent elements.
Keep test, control, and instrumentation separate from the elements being tested.
You must also consider the composition of multiple use-case slices to evaluate performance and other characteristics. After all, the design model is the sum of all the use-case slices. By tracing through a representative set of use-case slices, you evaluate the architecture baseline for its performance, reliability, and other execution characteristics. Thus, developing architecturally significant use cases early in the project naturally leads you toward an effective architecture that is designed for maintainability, extensibility, performance, and reliability.
Part IV includes the following chapters:
Chapter 11, “Road to a Resilient Architecture”
Chapter 12, “Separating Functional Requirements with Peer Application Use Cases”
Chapter 13, “Separating Functional Requirements with Extension-Application Use Cases”
Chapter 14, “Separating Nonfunctional Requirements with Infrastructure Use Cases”
Chapter 15, “Separating Platform Specifics with Platform-Specific Use-Case Slices”
Chapter 16, “Separating Tests with Use-Case Test Slices”
Chapter 17, “Evaluating the Architecture”
Chapter 18, “Describing the Architecture”