A motivating factor for all architectures is the desire to achieve particular software qualities. This chapter discusses software qualities and their implications. It presents a method for understanding qualities in architectural terms, by characterizing the stimuli that we apply to systems in order to observe their qualities, and by characterizing the systems' responses in measurable, observable ways when manifesting those qualities.
Once the desired qualities of a system are known, the problem of designing an architecture to achieve these qualities remains. This chapter describes a number of techniques used to achieve development and runtime qualities. The primary mechanisms are tactics, which are design decisions that influence the control of a quality attribute. Tactics can be grouped into architectural strategies and architectural patterns.
A system designed for air traffic control had the quality goal of extremely high availability. This goal motivated a number of architectural decisions, which are discussed in this chapter. In addition, this case study emphasizes the interplay of architectural structures and views (as discussed in Chapter 2) and architectural tactics (as discussed in Chapter 5), and it shows how they work in concert to achieve qualities.
With the foundational tools in hand (architectural views and structures, expressing quality attributes, tactics and patterns for achieving them), we are ready to address creating the architecture. This chapter discusses the role of architecture from the perspective of a system's overall life cycle. It presents a design method for producing an early architecture that can be refined and can evolve. Once the architecture is sketched, it can be used to form the project's team structure and to create a skeletal system as the basis for incremental development.
This chapter describes an architecture for flight simulation. It shows how careful attention to the software architecture in a complex domain enabled the construction of a set of large systems that met their stringent functional and fidelity requirements, could be understood by a variety of software engineers, were easy to integrate, and were amenable to downstream modifications.
An architecture is only as good as its ability to be communicated to and understood by its stakeholders. This chapter lays out an approach to documenting a software architecture. Documenting an architecture is a matter of recording the relevant views and then recording the information that applies across the views. The chapter provides templates for a view, for cross-view information, and for software interfaces.
Suppose we have a system but we don't know its architecture. Perhaps the architecture was never recorded, or was lost, or the system diverged from the architecture through evolution. How do we maintain such a system? How do we manage its evolution to maintain the quality attributes that its architecture has provided for us? Architecture reconstruction is the process where the "as-built" architecture of an implemented system is obtained from an existing system. This chapter presents an approach to architecture reconstruction and an example of its application.