Software Architecture in Practice

by Len Bass, Paul Clements, Rick Kazman

Overview

This book introduces the concepts and practices of software architecture-what a software system is designed to do and how that system's components are meant to interact with each other. An architecture is an abstract view distinct from the details of implementation, algorithm, and data representation. Architecture is, increasingly, a crucial part of a software organization's business strategy because it is a reusable asset that can be reapplied to subsequent systems. Reuse leads to the architecture business cycle, allowing an organization to leverage the effort invested in an architecture to enter whole new business areas. Drawing on their extensive experience building and evaluating architectures, the authors cover the essential technical topics for specifying and validating a system. For the first time in a book, they also emphasize the importance of the business context in which large systems are designed. Their aim is to present software architecture in a real-world setting, reflecting both the constraints and the opportunities that companies encounter. To that end, key points of both technical and organizational discussions are illuustrated by a selection of "industrial-strength" case studies. These studies, undertaken by the authors and the Software Engineering Institute, describe how successful architectures have led to the fulfillment of demanding requirements and enhanced an organization's position in its business community. If you design, develop, or manage the building of large software systems, or if you have an interest in acquiring such systems for your corporation or government agency, use this book to quickly get you up to speed on software architecture.

Product Details

ISBN-13:	9780136886020
Publisher:	Pearson Education
Publication date:	06/30/2021
Series:	SEI Series in Software Engineering
Sold by:	Barnes & Noble
Format:	eBook
Pages:	464
File size:	10 MB
Age Range:	18 Years

About the Author

Len Bass, an award-winning author and lecturer, has more than 50 years of advanced software experience, including 25 years at Carnegie Mellon University’s (CMU) Software Engineering Institute (SEI). He now teaches DevOps as an adjunct faculty member at CMU.

Dr. Paul Clements, VP of Customer Success with BigLever Software, helps organizations gain value from Product Line Engineering (PLE). As senior member of technical staff at SEI, he led advanced projects in PLE and software architecture.

Rick Kazman is Professor, University of Hawaii, and Visiting Researcher at SEI. His interests include software architecture, visualization, design, analysis, and economics. He co-created influential architecture analysis methods and tools, including SAAM, ATAM, CBAM, Dali, and Titan.

Read an Excerpt

PREFACE:

Software architecture is an important field of study that is becoming more important and more talked about with every passing day. But, to our knowledge, there exists little practical guidance on how to manage software architecture within a real software development organization from a technical or from a managerial perspective. This book has emerged from our belief that the coupling of the software architecture of a system and its business and organizational context has not been well explored.

Our experience with designing and reviewing large and complex software-intensive systems has led us to recognize the role of business and organization in the design of the system and also in its ultimate success or failure. Systems are built to satisfy an organizationis requirements (or assumed requirements in the case of shrink-wrapped products), and these requirements determine the extent to which a system must meet performance targets, be highly available, interoperate with other systems, or be designed for long lifetimes. These properties of a system are constrained by the systemis software architecture; or, to put it another way, the desire to achieve these properties influences the design choices made by a software architect.

In this book we demonstrate this coupling through the use of case studies drawn from real systems, including the following:

• In Chapter 7, we show how the desire to quickly and easily share documents within an organization, with a minimum of centralized control, led to the software architecture of the World Wide Web.
• In Chapter 11, we discuss how the extreme safety requirements of air traffic control ledone company to build a system around an architecture for achieving ultrahigh availability.
• In Chapter 14, we describe how the distribution of the subsystems of a flight simulator to different remotely located developers led to an architecture geared to enable the easy integration of these subsystems.
• In Chapter 16, we explain how the need to satisfy simultaneous product deliveries led (in fact, forced) one company to adopt an architecture that enabled the company to economically build a set of complex, related software systems as a product line.

These and other case studies show how the architectures flow from requirements of organizations and their business models, from the experience of the organizationis architects, and from the prevailing design climate.

In addition, we discuss how architectures themselves can be powerful vehicles for influencing all of the preceding. A successful product or set of products can influence how other products are built; certainly, the case study of the software underlying the World Wide Web is a good example of this. Before this system existed, there was far less network awareness; less thought was given to accessibility of data; and security was the concern of only a few organizations, typically financial institutions and government agencies.

This book is aimed at the software professionalothe person designing and implementing large software-intensive systemsoand at the managers of software professionals. It does not contain, for example, detailed financial justification for using a software architecture, for doing early architectural analyses, or for investing in a product line approach to building software. We provide only anecdotal evidence to support the claims that these pay off, although we passionately believe they do.

A software architecture is the development product that gives the highest return on investment with respect to quality, schedule, and cost. This is because an architecture appears early in a productis lifetime. Getting it right sets the stage for everything to come in the systemis life: development, integration, testing, and modification. Getting it wrong means that the fabric of the system is wrong, and it cannot be fixed by weaving in a few new threads or pulling out a few existing ones, which often causes the entire fabric to unravel. Also, analyzing architectures is inexpensive, compared with other development activities. Thus, architectures give a high return on investment partially because decisions made for the architecture have substantial downstream consequences and because checking and fixing an architecture is relatively inexpensive.

We also believe that reusable components are best achieved within an architectural context. But components are not the only artifacts that can be reused. Reuse of an architecture leads to the creation of families of similar systems, which in turn leads to new organizational structures and new business opportunities.

A large percentage of this book is devoted to presenting real architectures that were designed to solve real problems in real organizations. We chose the case studies to illustrate the types of choices that architects must make to achieve their quality goals and to show how organizational goals affect the final systems.

In addition to the case studies, this book offers a set of techniques for designing, building, and evaluating software architectures. We look at techniques for understanding quality requirements in the context of an architecture and for building architectures that meet these quality requirements. We look at architecture description languages as a means of describing and validating software architectures. We look at techniques for analyzing and evaluating an architectureis fitness for its purpose. Each of these techniques is derived from our experience, and the experience of our colleagues at the Software Engineering Institute, with a variety of software systems. These systems range up to millions of lines of code and are large-team, multiyear development efforts.

We have also provided a visual language for describing software architectures that contains enough expressiveness to describe both procedural and object-oriented systems and enough generality to describe systems at any granularity: a division of functionality, a set of software structures, a set of hardware structures, or any combination of these. Although a visual notation is not, in itself, documentation of an architecture, it is an integral part of such a documentation. One of our complaints with the state-of-the-practice in architecture today is the vagueness of architectural descriptions. We hope that the visual language described here is a contribution to the field, aimed at increasing the effectiveness of architectural documentation.

The book targets software professionals, or students who have knowledge and experience in software engineering, and we anticipate the following three classes of readers:

1. 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
2. Technical managers who wish to understand how software architecture can help them to supervise the construction of systems more effectively and improve their organizations
3. Students in computer science or software engineering who might use this book as supplemental reading in a first or second software engineering course

Although business issues are discussed throughout the book (for example, how an architecture affects an organizationis ability to compete in a market or how the architecture underlying a product family affects time to market), we present this material without going into the business issues in great depth and without using business jargon. We are, after all, software engineers. The technical sections are presented in more depth. These sections represent current work in the field of software architectureothe point where research meets practice; they are the philosophical foundations of the book. The case studies illustrate these technical foundations and show how they are realized in practice. However, we have written the case studies in such a way that expertise in the application domain from which each case study was drawn is not required. You will not need to be a pilot to understand either the air traffic control system or the flight simulation case studies. However, you will need to have a reasonable background in computer science, software engineering, or a related discipline to benefit from the lessons of the case studies.

One final note on the organization of the book. Software Architecture in Practice is not intended to be a prescriptive method for architectural design. In fact, we believe that it is impossible to satisfactorily create such a prescriptive design method. Any design involves trade-offs: Modifiability affects performance, security affects modifiability, scalability affects reliability, and everything affects cost. Any prescriptive method implicity or explicitly assumes that some of these qualities are more important than others and guides users toward the maximization of that goal. Our feeling is that although such an approach may be appropriate in a specific domain, it cannot possibly work in general. Quality requirements are different from organization to organization and from year to year.

By way of contrast, we offer a toolbox approach to design. We believe that different architectural tools and techniques are appropriate for different situations and different quality goals. No single technique will ever suffice. So, we present a number of different architectural tools (layering, multiple views, patterns, blackboards, and so forth) and techniques (analysis methods, integration strategies, engineering principles) and illustrate their usage in different business and technical contexts.

Not surprisingly, most of the case studies use a mix of tools and techniques because they were chosen to illustrate how software architecture was the foundation for a successful system. These systems were successful precisely because they chose the right tools and implemented them using the right techniques. Anything less would not have resulted in a successful system, as we hope to persuade you in the coming pages.

Table of Contents

Table of Contents

Preface....ix

Reader's Guide....xiii

Acknowledgments....xxiii

Part One Envisioning Architecture....1

CHAPTER 1 The Architecture Business Cycle....3

1.1 Where Do Architectures Come From?....6

1.2 Software Processes and the Architecture Business Cycle....12

1.3 What Makes a "Good" Architecture?....17

1.4 Summary....19

1.5 Discussion Questions....19

CHAPTER 2 What Is Software Architecture?....21

2.1 What Software Architecture Is and What It Isn't....21

2.2 Architectural Styles, Reference Models, and Reference Architectures....25

2.3 Other Viewpoints....26

2.4 Why Is Software Architecture Important?....28

2.5 Architectural Structures....36

2.6 Summary....41

2.7 For Further Reading....42

2.8 Discussion Questions....42

CHAPTER 3 A-7E: A Case Study in Utilizing Architectural Structures....45

3.1 Relationship to the Architecture Business Cycle....45

3.2 Requirements and Qualities....47

3.3 Architectural Approach....50

3.4 Architecture for the A-7E Avionics System....57

3.5 Summary....69

3.6 For Further Reading....70

3.7 Discussion Questions....70

Part Two Creating and Analyzing an Architecture....73

CHAPTER 4 Quality Attributes....75

4.1 Architectures and Quality Attributes....76

4.2 Architectural Means for Achieving Qualities....88

4.3 Summary....90

4.4 For Further Reading....90

4.5 Discussion Questions....90

CHAPTER 5 Moving From Qualities to Architecture: Architectural Styles....93

5.1 Introducing Architectural Styles....94

5.2 Organizing Architectural Styles....104

5.3 Refinements of Styles....107

5.4 Using Styles in System Design....113

5.5 Achieving Quality Goals with Architectural Styles....117

5.6 Summary....121

5.7 For Further Reading....121

5.8 Discussion Questions....122

CHAPTER 6 Unit Operations....123

6.1 Introducing Unit Operations....123

6.2 Applying Unit Operations to User-Interface Software....130

6.3 Ramifications of Addressing Quality Attributes....142

6.4 Summary....143

6.5 For Further Reading....143

6.6 Discussion Questions....144

CHAPTER 7 The World Wide Web: A Case Study in Interoperability....145

7.1 Relationship to the Architecture Business Cycle....145

7.2 Requirements and Qualities....147

7.3 Architectural Approach....152

7.4 Architectural Solution....152

7.5 Architecture Business Cycle Today....160

7.6 Summary....161

7.7 For Further Reading....163

7.8 Discussion Questions....163

CHAPTER 8 CORBA: A Case Study of an Industry Standard Computing Infrastructure....165

8.1 Relationship to the Architecture Business Cycle....166

8.2 Requirements and Qualities....169

8.3 Architectural Approach....171

8.4 Architectural Solution....174

8.5 The Web and CORBA....184

8.6 Summary....186

8.7 For Further Reading....186

8.8 Discussion Questions....187

CHAPTER 9 Analyzing Development Qualities at the Architectural Level: The Software Architecture Analysis Method....189

9.1 The How and Why of Analyzing Software Architecture....190

9.2 Overview of Software Architecture Analysis Method....193

9.3 A Small Example of SAAM Application....198

9.4 SAAM Applied to a Financial Management System....202

9.5 SAAM Applied to a Revision-Control System....210

9.6 Observations on SAAM....216

9.7 Summary....219

9.8 For Further Reading....220

9.9 Discussion Questions....220

CHAPTER 10 Architecture Reviews....221

10.1 Costs and Benefits....222

10.2 Review Techniques....225

10.3 The Review Practice....230

10.4 Summary....236

10.5 For Further Reading....237

10.6 Discussion Questions....237

CHAPTER 11 Air Traffic Control: A Case Study in Designing for High Availability....239

11.1 Relationship to the Architecture Business Cycle....242

11.2 Requirements and Qualities....243

11.3 Architectural Approach....244

11.4 Architectural Solution....245

11.5 Assessing the Architecture for Maintainability....259

11.6 Summary....263

11.7 For Further Reading....264

11.8 Discussion Questions....264

Part Three Moving From Architectures to Systems....265

CHAPTER 12 Architecture Description Languages....267

12.1 Architecture Description Languages Today....269

12.2 Capturing Architectural Information in an ADL....271

12.3 How Do ADLs Help System Development?....273

12.4 Choosing an ADL....274

12.5 An Example of an ADL....277

12.6 Summary....283

12.7 For Further Reading....283

12.8 Discussion Questions....284

CHAPTER 13 Architecture-Based Development....285

13.1 Forming the Team Structure....285

13.2 Creating a Skeletal System....288

13.3 Exploiting Patterns in Software Architecture....291

13.4 Ensuring Conformance to an Architecture....297

13.5 Building Domain-Specific Languages....299

13.6 Summary....301

13.7 For Further Reading....301

13.8 Discussion Questions....302

CHAPTER 14 Flight Simulation: A Case Study in Architecture for Integrability....303

14.1 Relationship to the Architecture Business Cycle....304

14.2 Requirements and Qualities....305

14.3 Architectural Approach....307

14.4 Architectural Solution....308

14.5 Achievement of Goals....325

14.6 Summary....326

14.7 For Further Reading....327

14.8 Discussion Questions....327

Part Four Reusing Architectures....329

CHAPTER 15 Product Lines: Reusing Architectural Assets within an Organization....331

15.1 Creating Products and Evolving a Product Line....333

15.2 Organizational Implications of a Product Line....334

15.3 Component-Based Systems....337

15.4 Summary....343

15.5 For Further Reading....344

15.6 Discussion Questions....344

CHAPTER 16 CelsiusTech: A Case Study in Product Line Development....345

16.1 Relationship to the Architecture Business Cycle....345

16.2 Requirements and Qualities....363

16.3 Architectural Approach....365

16.4 Summary....372

16.5 For Further Reading....374

16.6 Discussion Questions....374

CHAPTER 17 Communitywide Reuse of Architectural Assets....375

17.1 Reference Architectures....375

17.2 Open Systems....380

17.3 The Process of Engineering an Open System....383

17.4 Standards....385

17.5 Summary....393

17.6 For Further Reading....394

17.7 Discussion Questions....394

CHAPTER 18 The Meteorological Anchor Desk System: A Case Study in Building a Web-Based System from Off-the-Shelf Components....395

18.1 Relationship to the Architecture Business Cycle....397

18.2 Requirements and Qualities....398

18.3 Architectural Approach....402

18.4 Architectural Solution....404

18.5 Summary....414

18.6 Discussion Questions....415

CHAPTER 19 Software Architecture in the Future....417

19.1 The Architecture Business Cycle Revisited....418

19.2 Architecture and Legacy Systems....419

19.3 Achieving an Architecture....422

19.4 From Architecture to System....427

19.5 Summary....429

19.6 For Further Reading....430

Acronyms....433

References....437

Bibliography....443

Index....447

Preface

Software architecture is an important field of study that is becoming more important and more talked about with every passing day. But, to our knowledge, there exists little practical guidance on how to manage software architecture within a real software development organization from a technical or from a managerial perspective. This book has emerged from our belief that the coupling of the software architecture of a system and its business and organizational context has not been well explored.

Our experience with designing and reviewing large and complex software-intensive systems has led us to recognize the role of business and organization in the design of the system and also in its ultimate success or failure. Systems are built to satisfy an organization's requirements (or assumed requirements in the case of shrink-wrapped products), and these requirements determine the extent to which a system must meet performance targets, be highly available, interoperate with other systems, or be designed for long lifetimes. These properties of a system are constrained by the system's software architecture; or, to put it another way, the desire to achieve these properties influences the design choices made by a software architect.

In this book we demonstrate this coupling through the use of case studies drawn from real systems, including the following:

• In Chapter 7, we show how the desire to quickly and easily share documents within an organization, with a minimum of centralized control, led to the software architecture of the World Wide Web.
• In Chapter 11, we discuss how the extreme safety requirements of air traffic control led one company to build a system around an architecture for achieving ultrahigh availability.
• In Chapter 14, we describe how the distribution of the subsystems of a flight simulator to different remotely located developers led to an architecture geared to enable the easy integration of these subsystems.
• In Chapter 16, we explain how the need to satisfy simultaneous product deliveries led (in fact, forced) one company to adopt an architecture that enabled the company to economically build a set of complex, related software systems as a product line.

These and other case studies show how the architectures flow from requirements of organizations and their business models, from the experience of the organization's architects, and from the prevailing design climate.

In addition, we discuss how architectures themselves can be powerful vehicles for influencing all of the preceding. A successful product or set of products can influence how other products are built; certainly, the case study of the software underlying the World Wide Web is a good example of this. Before this system existed, there was far less network awareness; less thought was given to accessibility of data; and security was the concern of only a few organizations, typically financial institutions and government agencies.

This book is aimed at the software professional—the person designing and implementing large software-intensive systems—and at the managers of software professionals. It does not contain, for example, detailed financial justification for using a software architecture, for doing early architectural analyses, or for investing in a product line approach to building software. We provide only anecdotal evidence to support the claims that these pay off, although we passionately believe they do.

A software architecture is the development product that gives the highest return on investment with respect to quality, schedule, and cost. This is because an architecture appears early in a product's lifetime. Getting it right sets the stage for everything to come in the system's life: development, integration, testing, and modification. Getting it wrong means that the fabric of the system is wrong, and it cannot be fixed by weaving in a few new threads or pulling out a few existing ones, which often causes the entire fabric to unravel. Also, analyzing architectures is inexpensive, compared with other development activities. Thus, architectures give a high return on investment partially because decisions made for the architecture have substantial downstream consequences and because checking and fixing an architecture is relatively inexpensive.

We also believe that reusable components are best achieved within an architectural context. But components are not the only artifacts that can be reused. Reuse of an architecture leads to the creation of families of similar systems, which in turn leads to new organizational structures and new business opportunities.

A large percentage of this book is devoted to presenting real architectures that were designed to solve real problems in real organizations. We chose the case studies to illustrate the types of choices that architects must make to achieve their quality goals and to show how organizational goals affect the final systems.

In addition to the case studies, this book offers a set of techniques for designing, building, and evaluating software architectures. We look at techniques for understanding quality requirements in the context of an architecture and for building architectures that meet these quality requirements. We look at architecture description languages as a means of describing and validating software architectures. We look at techniques for analyzing and evaluating an architecture's fitness for its purpose. Each of these techniques is derived from our experience, and the experience of our colleagues at the Software Engineering Institute, with a variety of software systems. These systems range up to millions of lines of code and are large-team, multiyear development efforts.

We have also provided a visual language for describing software architectures that contains enough expressiveness to describe both procedural and object-oriented systems and enough generality to describe systems at any granularity: a division of functionality, a set of software structures, a set of hardware structures, or any combination of these. Although a visual notation is not, in itself, documentation of an architecture, it is an integral part of such a documentation. One of our complaints with the state-of-the-practice in architecture today is the vagueness of architectural descriptions. We hope that the visual language described here is a contribution to the field, aimed at increasing the effectiveness of architectural documentation.

The book targets software professionals, or students who have knowledge and experience in software engineering, and we anticipate the following three classes of readers:

1. 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
2. Technical managers who wish to understand how software architecture can help them to supervise the construction of systems more effectively and improve their organizations
3. Students in computer science or software engineering who might use this book as supplemental reading in a first or second software engineering course

Although business issues are discussed throughout the book (for example, how an architecture affects an organization's ability to compete in a market or how the architecture underlying a product family affects time to market), we present this material without going into the business issues in great depth and without using business jargon. We are, after all, software engineers. The technical sections are presented in more depth. These sections represent current work in the field of software architecture—the point where research meets practice; they are the philosophical foundations of the book. The case studies illustrate these technical foundations and show how they are realized in practice. However, we have written the case studies in such a way that expertise in the application domain from which each case study was drawn is not required. You will not need to be a pilot to understand either the air traffic control system or the flight simulation case studies. However, you will need to have a reasonable background in computer science, software engineering, or a related discipline to benefit from the lessons of the case studies.

One final note on the organization of the book. Software Architecture in Practice is not intended to be a prescriptive method for architectural design. In fact, we believe that it is impossible to satisfactorily create such a prescriptive design method. Any design involves trade-offs: Modifiability affects performance, security affects modifiability, scalability affects reliability, and everything affects cost. Any prescriptive method implicity or explicitly assumes that some of these qualities are more important than others and guides users toward the maximization of that goal. Our feeling is that although such an approach may be appropriate in a specific domain, it cannot possibly work in general. Quality requirements are different from organization to organization and from year to year.

By way of contrast, we offer a toolbox approach to design. We believe that different architectural tools and techniques are appropriate for different situations and different quality goals. No single technique will ever suffice. So, we present a number of different architectural tools (layering, multiple views, patterns, blackboards, and so forth) and techniques (analysis methods, integration strategies, engineering principles) and illustrate their usage in different business and technical contexts.

Not surprisingly, most of the case studies use a mix of tools and techniques because they were chosen to illustrate how software architecture was the foundation for a successful system. These systems were successful precisely because they chose the right tools and implemented them using the right techniques. Anything less would not have resulted in a successful system, as we hope to persuade you in the coming pages.

Editorial Reviews

An introduction to the concepts and practices of software architecture, emphasizing the importance of the business context in which large systems are designed. The volume's 19 chapters are divided into four sections: envisioning architecture; creating and analyzing an architecture; moving from architectures to systems; and reusing architectures. Annotation c. by Book News, Inc., Portland, Or.

Booknews