This book is for software professionals, or students who have knowledge and experience in software engineering. We anticipate three classes of reader:
• Practicing software engineers who wish to understand both the technical basis of software architecture and the business and organizational forces that are acting on them.
• Technical managers who wish to understand how software architecture can help them to supervise the construction of systems more effectively and improve their organizations.
• Students of computer science or software engineering who might use this book as supplemental reading in a first or second software engineering course.
The book is divided into four parts, roughly following a life-cycle perspective, which we call the Architecture Business Cycle, of how architectures fit into a business:
• Envisioning Architecture—Chapters 1–3
• Creating an Architecture—Chapters 4–10
• Analyzing an Architecture—Chapters 11–13
• Moving from One System to Many—Chapters 14–19
The case studies are in Chapters 3, 6, 8, 13, 15, 16 and 17, and are clearly noted in the chapter titles.
In detail, the parts and chapters cover the following ground.
Chapter 1 – The Architecture Business Cycle
The theme that weaves through this book is that architectures do not exist by themselves, but are part of a cycle. Architecture is a means toward an end. It is influenced by the functional and quality goals of both the customer and the developing organization. It is also influenced by the architect's background and experiences and by the technical environment. Architecture in turn influences the system being developed, and it may be a core asset that influences the developing organization. The system also has an effect on the developing organization; the architecture; and, potentially, the technical environment. This effect affects the future goals for the system and its organization. The influences and feedback loops that surround an architecture form the ABC.
Chapter 2 – What Is Software Architecture?
An architecture is a description of system structures, of which there are several (module decomposition, process, deployment, layered, etc.). Architecture is the first artifact that can be analyzed to determine how well its quality attributes are being achieved, and it also serves as the project blueprint. An architecture serves as the vehicle for communication, is the manifestation of the earliest design decisions, and is a re-usable abstraction that can be transferred to new systems. These are the things we mean when we use the word architecture.
Chapter 3 – A-7E Avionics System: A Case Study in Utilizing Architectural Structures
The A-7E Avionics System was a project that paid special attention to the engineering and specification of three distinct architectural structures to achieve developmental simplicity and modifiability. The chapter shows how (and why) the structures were designed and documented.
Chapter 4 – Understanding Quality Attributes
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.
Chapter 5 – Achieving 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.
Chapter 6 – Air Traffic Control: A Case Study in Designing for High Availability
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.
Chapter 7 – Creating the Architecture
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.
Chapter 8 – Flight Simulation: A Case Study in Architecture for Integrability
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.
Chapter 9 – Documenting Software Architectures
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.
Chapter 10 – Reconstructing Software Architectures
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.
Chapter 11 – The ATAM: A Comprehensive Method for Architecture Evaluation
The Architecture Tradeoff Analysis Method is a way to evaluate architectural decisions in light of specific behavioral and quality attribute requirements. This chapter describes the ATAM and walks through a comprehensive example of its application.
Chapter 12 – The CBAM: A Quantitative Approach to Architecture Design Decision Making
The software architect or project decision maker wishes to maximize the difference between the benefit derived from a system and the cost of implementing the design. The Cost Benefit Analysis Method addresses this need for economic decision making centered on an analysis of architecture. The CBAM builds on the ATAM to model the costs and the benefits of architectural design decisions and provides a means of optimizing such decisions. This chapter presents the CBAM and a case where it was applied.
Chapter 13 – The World Wide Web: A Case Study in Interoperability
The World Wide Web was created out of a single organization's desire to ex-change information among its researchers, but it has far outgrown those original goals. This chapter describes the architecture of the software underlying the Web, how this architecture has changed to allow the Web to grow, and how that growth, in turn, has influenced the organizations that use it.
Chapter 14 – Product Lines: Re-using Architectural Assets within an Organization
One of the most powerful applications of software architecture is its use as the foundation of a software product line. This chapter presents the basics of software product line production, highlighting architecture as the keystone for achieving large improvements in productivity, time-to-market, quality, and cost. The chapter explores in detail a few of the software engineering development and management activities that take on a special dimension in a product line context.
Chapter 15 – CelsiusTech: A Case Study in Product Line Development
CelsiusTech is an organization that successfully implemented a product line based on an architecture. This chapter describes the architecture of the product line and shows why this architecture was crucial to CelsiusTech's success. Without this approach, it would not have been able to build these systems—it simply did not have adequate personnel. The product line approach brought consequent changes to the organizational structure and the manner in which it both solicits and contracts for business.
Chapter 16 – J2EE/EJB: A Case Study of an Industry-Standard Computing Infrastructure
This chapter presents an overview of Sun Microsystems's Java 2 Enterprise Edition (J2EE) architecture specification, as well as an important portion of that specification, the Enterprise JavaBeans (EJBs) architecture specification. The J2EE specification provides a standard description of how distributed object-oriented programs written in Java should be designed and developed. The chapter examines the business drivers that led to the creation of such an industry standard architecture for building distributed systems, and shows how the J2EE/EJB architecture addresses such needs.
Chapter 17 – The Luther Architecture: A Case Study in Mobile Applications Using J2EE
The Luther architecture was designed to provide a general framework to provide customized solutions in the domain of maintenance or operation of large vehicles or industrial infrastructure. It is based on J2EE, and so this chapter becomes an application of the general J2EE/EJB framework discussed in Chapter 16. This case deals with an environment where the end user is connected over a wireless network and has a device with limited input/output capabilities, limited computational capabilities, or both.
Chapter 18 – Building Systems from Off-the-Shelf Components
Systems are being constructed with more and more off-the-shelf components. The use of such components changes the design process because the components can constrain the architecture. Typically, components are chosen to achieve some set of functionality, but they also embody architectural (and hence quality) assumptions. This chapter describes a lightweight process to guide an architect in choosing components that will work well in concert. The chapter includes a demonstration of the process applied to a recently fielded system.
Chapter 19 – Software Architecture in the Future
We look at the Architecture Business Cycle again and identify some of the yet to be solved problems associated with software architecture and discuss why more research is needed.
We realize that different readers of the book will want to mine different information from it, and that most of them will want to read the book at various levels of detail. To address this need, we have organized the case studies in a consistent fashion around the following sections:
• A brief description of the study, the problems it was solving, and the points about software architecture it illustrates
• A description of how the ABC was realized (or partially realized) in this study
• The requirements and qualities that propelled the design
• The architectural solution: a detailed discussion that comprises the bulk of many of the case studies
• A summary of the important points made in the chapter
The architectural solution contains most of the detail in the case studies. If you are interested only in the technical and business environment and a high-level description of the architectural approach, you can get the gist of a case study by reading the brief description of it, its requirements and quality goals, and the summary. For a fuller discussion, you can also read the architectural solution section of each case.
While the ABC is the primary theme of the book, other conceptual threads run through it. A reader interested in pursuing a particular aspect of architecture may wish to concentrate on the chapters that carry one or more of the following threads:
• Where do architectures come from?—Chapters 1, 2, 4, 7, 11 and 12
• Business issues—Chapters 1, 4, 7, 11, 12, 14, 15 and 18
• How qualities derive from architectures—Chapters 4, 5, 11 and 12 and the case studies
• Case studies of qualities deriving from architecture—Chapters 3, 6, 8, 13, 15, 16 and 17
• Architecture as a re-usable asset—Chapters 14, 15, 16, 17 and 18
• Component-based systems and commercial infrastructures—Chapters 13, 16, 17 and 18
• Architectures for real-time systems—Chapters 3, 5, 6, 8 and 15
• Architectures for information systems—Chapters 13, 16, 17 and 18