Software Architecture in Practice [NOOK Book]

Overview

The award-winning and highly influential Software Architecture in Practice, Third Edition, has been substantially revised to reflect the latest developments in the field. In a real-world setting, the book once again introduces the concepts and best practices of software architecture—how a software system is structured and how that system’s elements are meant to interact. Distinct from the details of implementation, algorithm, and data representation, an architecture holds the key to achieving system quality, is a...

See more details below
Software Architecture in Practice

Available on NOOK devices and apps  
  • NOOK Devices
  • NOOK HD/HD+ Tablet
  • NOOK
  • NOOK Color
  • NOOK Tablet
  • Tablet/Phone
  • NOOK for Windows 8 Tablet
  • NOOK for iOS
  • NOOK for Android
  • NOOK Kids for iPad
  • PC/Mac
  • NOOK for Windows 8
  • NOOK for PC
  • NOOK for Mac
  • NOOK Study

Want a NOOK? Explore Now

NOOK Book (eBook)
$31.99
BN.com price
(Save 42%)$55.99 List Price

Overview

The award-winning and highly influential Software Architecture in Practice, Third Edition, has been substantially revised to reflect the latest developments in the field. In a real-world setting, the book once again introduces the concepts and best practices of software architecture—how a software system is structured and how that system’s elements are meant to interact. Distinct from the details of implementation, algorithm, and data representation, an architecture holds the key to achieving system quality, is a reusable asset that can be applied to subsequent systems, and is crucial to a software organization’s business strategy.

The authors have structured this edition around the concept of architecture influence cycles. Each cycle shows how architecture influences, and is influenced by, a particular context in which architecture plays a critical role. Contexts include technical environment, the life cycle of a project, an organization’s business profile, and the architect’s professional practices. The authors also have greatly expanded their treatment of quality attributes, which remain central to their architecture philosophy—with an entire chapter devoted to each attribute—and broadened their treatment of architectural patterns.

If you design, develop, or manage large software systems (or plan to do so), you will find this book to be a valuable resource for getting up to speed on the state of the art.

Totally new material covers

  • Contexts of software architecture: technical, project, business, and professional
  • Architecture competence: what this means both for individuals and organizations
  • The origins of business goals and how this affects architecture
  • Architecturally significant requirements, and how to determine them
  • Architecture in the life cycle, including generate-and-test as a design philosophy; architecture conformance during implementation; architecture and testing; and architecture and agile development
  • Architecture and current technologies, such as the cloud, social networks, and end-user devices
Read More Show Less

Editorial Reviews

Booknews
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.
Read More Show Less

Product Details

  • ISBN-13: 9780132942782
  • Publisher: Pearson Education
  • Publication date: 10/9/2012
  • Series: SEI Series in Software Engineering
  • Sold by: Barnes & Noble
  • Format: eBook
  • Edition number: 3
  • Pages: 624
  • Sales rank: 239,612
  • File size: 24 MB
  • Note: This product may take a few minutes to download.

Meet the Author

Len Bass is a Senior Principal Researcher at National ICT Australia Ltd (NICTA). He joined NICTA in 2011 after twenty-five years at the Software Engineering Institute (SEI) at Carnegie Mellon University. He is the coauthor of two award-winning books in software architecture, including Documenting Software Architectures: Views and Beyond, Second Edition (Addison-Wesley, 2011), as well as several other books and numerous papers in computer science and software engineering on a wide range of topics. Len has almost fifty years’ experience in software development and research in multiple domains, such as scientific analysis systems, embedded systems, and information systems.

Paul Clements is the Vice President of Customer Success at BigLever Software, Inc., where he works to spread the adoption of systems and software product line engineering. Prior to this position, he was Senior Member of the Technical Staff at the SEI, where, for 17 years, he lead or co-lead projects in software product line engineering and software architecture documentation and analysis. Other books Paul has coauthored include Documenting Software Architectures: Views and Beyond, Second Edition (Addison-Wesley, 2011) and Evaluating Software Architectures: Methods and Case Studies, (Addison-Wesley, 2002), and Software Product Lines: Practices and Patterns (Addison-Wesley, 2002). In addition, he has also published dozens of papers in software engineering reflecting his long-standing interest in the design and specification of challenging software systems. Paul was a founding member of the IFIP WG2.10 Working Group on Software Architecture.

Rick Kazman is a Professor at the University of Hawaii and a Visiting Scientist (and former Senior Member of the Technical Staff) at the SEI. He is a coauthor of Evaluating Software Architectures: Methods and Case Studies, (Addison-Wesley, 2002). Rick’s primary research interests are software architecture, design and analysis tools, software visualization, and software engineering economics. He is also interested in human-computer interaction and information retrieval. Rick was one of the creators of several highly influential methods and tools for architecture analysis, including the SAAM (Software Architecture Analysis Method), the ATAM (Architecture Tradeoff Analysis Method), the CBAM (Cost-Benefit Analysis Method), and the Dali architecture reverse engineering tool.

Read More Show Less

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.



Read More Show Less

Table of Contents

Preface xv

Reader’s Guide xvii

Acknowledgments xix

Part One: Introduction 1

Chapter 1: What Is Software Architecture? 3

1.1 What Software Architecture Is and What It Isn’t 4

1.2 Architectural Structures and Views 9

1.3 Architectural Patterns 18

1.4 What Makes a “Good” Architecture? 19

1.5 Summary 21

1.6 For Further Reading 22

1.7 Discussion Questions 23

Chapter 2: Why Is Software Architecture Important? 25

2.1 Inhibiting or Enabling a System’s Quality Attributes 26

2.2 Reasoning About and Managing Change 27

2.3 Predicting System Qualities 28

2.4 Enhancing Communication among Stakeholders 29

2.5 Carrying Early Design Decisions 31

2.6 Defining Constraints on an Implementation 32

2.7 Influencing the Organizational Structure 33

2.8 Enabling Evolutionary Prototyping 33

2.9 Improving Cost and Schedule Estimates 34

2.10 Supplying a Transferable, Reusable Model 35

2.11 Allowing Incorporation of Independently Developed Components 35

2.12 Restricting the Vocabulary of Design Alternatives 36

2.13 Providing a Basis for Training 37

2.14 Summary 37

2.15 For Further Reading 38

2.16 Discussion Questions 38

Chapter 3: The Many Contexts of Software Architecture 39

3.1 Architecture in a Technical Context 40

3.2 Architecture in a Project Life-Cycle Context 44

3.3 Architecture in a Business Context 49

3.4 Architecture in a Professional Context 51

3.5 Stakeholders 52

3.6 How Is Architecture Influenced? 56

3.7 What Do Architectures Influence? 57

3.8 Summary 59

3.9 For Further Reading 59

3.10 Discussion Questions 60

Part Two: Quality Attributes 61

Chapter 4: Understanding Quality Attributes 63

4.1 Architecture and Requirements 64

4.2 Functionality 65

4.3 Quality Attribute Considerations 65

4.4 Specifying Quality Attribute Requirements 68

4.5 Achieving Quality Attributes through Tactics 70

4.6 Guiding Quality Design Decisions 72

4.7 Summary 76

4.8 For Further Reading 77

4.9 Discussion Questions 77

Chapter 5: Availability 79

5.1 Availability General Scenario 85

5.2 Tactics for Availability 87

5.3 A Design Checklist for Availability 96

5.4 Summary 98

5.5 For Further Reading 99

5.6 Discussion Questions 100

Chapter 6: Interoperability 103

6.1 Interoperability General Scenario 107

6.2 Tactics for Interoperability 110

6.3 A Design Checklist for Interoperability 114

6.4 Summary 115

6.5 For Further Reading 116

6.6 Discussion Questions 116

Chapter 7: Modifiability 117

7.1 Modifiability General Scenario 119

7.2 Tactics for Modifiability 121

7.3 A Design Checklist for Modifiability 125

7.4 Summary 128

7.5 For Further Reading 128

7.6 Discussion Questions 128

Chapter 8: Performance 131

8.1 Performance General Scenario 132

8.2 Tactics for Performance 135

8.3 A Design Checklist for Performance 142

8.4 Summary 145

8.5 For Further Reading 145

8.6 Discussion Questions 145

Chapter 9: Security 147

9.1 Security General Scenario 148

9.2 Tactics for Security 150

9.3 A Design Checklist for Security 154

9.4 Summary 156

9.5 For Further Reading 157

9.6 Discussion Questions 158

Chapter 10: Testability 159

10.1 Testability General Scenario 162

10.2 Tactics for Testability 164

10.3 A Design Checklist for Testability 169

10.4 Summary 172

10.5 For Further Reading 172

10.6 Discussion Questions 173

Chapter 11: Usability 175

11.1 Usability General Scenario 176

11.2 Tactics for Usability 177

11.3 A Design Checklist for Usability 181

11.4 Summary 183

11.5 For Further Reading 183

11.6 Discussion Questions 183

Chapter 12: Other Quality Attributes 185

12.1 Other Important Quality Attributes 185

12.2 Other Categories of Quality Attributes 189

12.3 Software Quality Attributes and System Quality Attributes 190

12.4 Using Standard Lists of Quality Attributes–or Not 193

12.5 Dealing with “X-ability”: Bringing a New Quality Attribute into the Fold 196

12.6 For Further Reading 200

12.7 Discussion Questions 201

Chapter 13: Architectural Tactics and Patterns 203

13.1 Architectural Patterns 204

13.2 Overview of the Patterns Catalog 205

13.3 Relationships between Tactics and Patterns 238

13.4 Using Tactics Together 242

13.5 Summary 247

13.6 For Further Reading 248

13.7 Discussion Questions 249

Chapter 14: Quality Attribute Modeling and Analysis 251

14.1 Modeling Architectures to Enable Quality Attribute Analysis 252

14.2 Quality Attribute Checklists 260

14.3 Thought Experiments and Back-of-the-Envelope Analysis 262

14.4 Experiments, Simulations, and Prototypes 264

14.5 Analysis at Different Stages of the Life Cycle 265

14.6 Summary 266

14.7 For Further Reading 267

14.8 Discussion Questions 269

Part Three: Architecture in the Life Cycle 271

Chapter 15: Architecture in Agile Projects 275

15.1 How Much Architecture? 277

15.2 Agility and Architecture Methods 281

15.3 A Brief Example of Agile Architecting 283

15.4 Guidelines for the Agile Architect 286

15.5 Summary 287

15.6 For Further Reading 288

15.7 Discussion Questions 289

Chapter 16: Architecture and Requirements 291

16.1 Gathering ASRs from Requirements Documents 292

16.2 Gathering ASRs by Interviewing Stakeholders 294

16.3 Gathering ASRs by Understanding the Business Goals 296

16.4 Capturing ASRs in a Utility Tree 304

16.5 Tying the Methods Together 308

16.6 Summary 308

16.7 For Further Reading 309

16.8 Discussion Questions 309

Chapter 17: Designing an Architecture 311

17.1 Design Strategy 311

17.2 The Attribute-Driven Design Method 316

17.3 The Steps of ADD 318

17.4 Summary 325

17.5 For Further Reading 325

17.6 Discussion Questions 326

Chapter 18: Documenting Software Architectures 327

18.1 Uses and Audiences for Architecture Documentation 328

18.2 Notations for Architecture Documentation 329

18.3 Views 331

18.4 Choosing the Views 341

18.5 Combining Views 343

18.6 Building the Documentation Package 345

18.7 Documenting Behavior 351

18.8 Architecture Documentation and Quality Attributes 354

18.9 Documenting Architectures That Change Faster Than You Can Document Them 355

18.10 Documenting Architecture in an Agile Development Project 356

18.11 Summary 359

18.12 For Further Reading 360

18.13 Discussion Questions 360

Chapter 19: Architecture, Implementation, and Testing 363

19.1 Architecture and Implementation 363

19.2 Architecture and Testing 370

19.3 Summary 376

19.4 For Further Reading 376

19.5 Discussion Questions 377

Chapter 20: Architecture Reconstruction and Conformance 379

20.1 Architecture Reconstruction Process 381

20.2 Raw View Extraction 382

20.3 Database Construction 386

20.4 View Fusion 388

20.5 Architecture Analysis: Finding Violations 389

20.6 Guidelines 392

20.7 Summary 393

20.8 For Further Reading 394

20.9 Discussion Questions 395

Chapter 21: Architecture Evaluation 397

21.1 Evaluation Factors 397

21.2 The Architecture Tradeoff Analysis Method 400

21.3 Lightweight Architecture Evaluation 415

21.4 Summary 417

21.5 For Further Reading 417

21.6 Discussion Questions 418

Chapter 22: Management and Governance 419

22.1 Planning 420

22.2 Organizing 422

22.3 Implementing 427

22.4 Measuring 429

22.5 Governance 430

22.6 Summary 432

22.7 For Further Reading 432

22.8 Discussion Questions 433

Part Four: Architecture and Business 435

Chapter 23: Economic Analysis of Architectures 437

23.1 Decision-Making Context 438

23.2 The Basis for the Economic Analyses 439

23.3 Putting Theory into Practice: The CBAM 442

23.4 Case Study: The NASA ECS Project 450

23.5 Summary 457

23.6 For Further Reading 458

23.7 Discussion Questions 458

Chapter 24: Architecture Competence 459

24.1 Competence of Individuals: Duties, Skills, and Knowledge of Architects 460

24.2 Competence of a Software Architecture Organization 467

24.3 Summary 475

24.4 For Further Reading 475

24.5 Discussion Questions 477

Chapter 25: Architecture and Software Product Lines 479

25.1 An Example of Product Line Variability 482

25.2 What Makes a Software Product Line Work? 483

25.3 Product Line Scope 486

25.4 The Quality Attribute of Variability 488

25.5 The Role of a Product Line Architecture 488

25.6 Variation Mechanisms 490

25.7 Evaluating a Product Line Architecture 493

25.8 Key Software Product Line Issues 494

25.9 Summary 497

25.10 For Further Reading 498

25.11 Discussion Questions 498

Part Five: The Brave New World 501

Chapter 26: Architecture in the Cloud 503

26.1 Basic Cloud Definitions 504

26.2 Service Models and Deployment Options 505

26.3 Economic Justification 506

26.4 Base Mechanisms 509

26.5 Sample Technologies 514

26.6 Architecting in a Cloud Environment 520

26.7 Summary 524

26.8 For Further Reading 524

26.9 Discussion Questions 525

Chapter 27: Architectures for the Edge 527

27.1 The Ecosystem of Edge-Dominant Systems 528

27.2 Changes to the Software Development Life Cycle 530

27.3 Implications for Architecture 531

27.4 Implications of the Metropolis Model 533

27.5 Summary 537

27.6 For Further Reading 538

27.7 Discussion Questions 538

Chapter 28: Epilogue 541

References 547

About the Authors 561

Index 563

Read More Show Less

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.



Read More Show Less

Introduction

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 led one companyto 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.



Read More Show Less

Customer Reviews

Average Rating 3.5
( 2 )
Rating Distribution

5 Star

(1)

4 Star

(0)

3 Star

(0)

2 Star

(1)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)