实用软件体系结构（英文版） (2008 年度畅销榜NO.15328 )

软件体系结构是近来脱颖而出的一个技术领域，面对的是一些新的挑战。本书介绍了软件体系结构及其设计、说明和应用。全书以对工业中（尤其是西门子公司）软件体系结构的研究作为开始，共分四部分。第一部分提供了理解所谓体系结构以及如何建立体系结构设计任务的重要背景知识；第二部分定义了体系结构设计任务，并通过运行中的实例表明它们如何应用于体系结构的设计；第三部分包含对四个工业系统（安全、健康、中心和通信）的详细描述，这些系统来自原始的工业研究，并且代表软件体系结构中工艺的位置；第四部分探究了软件设计者的角色，说明设计者除软件体系结构设计之外还应做的事。
本书采用UML来描述软件体系结构。通过本书的学习，读者能够了解处理体系结构设计问题的一种新的方法，并且提高认识好的解决方案的能力。
高质量的软件体系结构设计通常很重要，而在今天这样一个飞速变化、复杂的发展环境中，它又是必不可少的。一个好的设计方案可以处理复杂事物，权衡矛盾需求，并将高质量软件及时地引入市场。本书集中讨论体系结构的四个基本视图：概念、模块、执行和代码，通过实际的案例学习揭示了在软件体系结构设计过程中有经验的软件设计者的理解和实践。
本书包含以下内容
＊ 建立足够灵活的设计任务以合并未来的工艺
＊ 将体系结构作为基础来满足性能、可修改性、可靠性和安全性的需要
＊ 确定矛盾需求间的优先权并获得一个成功的解决方案
＊ 利用软件体系结构使系统成分一体化

Preface
Foreword
Part I Software Architecture
Chapter1 Introduction
1.1 Putting Software Architecture in Context
1.1.1 Softeware Architecture as a Design Plan
1.1.2 Software Architecture as an Abstraction
1.1.3 Software Architecture Terminology
1.2 Where the Four Views Came From
1.2.1 Loose Coupling Between Views
1.2.2 Different Engineering Concerns Addressed by Different Views
1.3 Using the Four Views
1.4 Notation
Part II Designing,Describing,and Using Software Architecture
Chapter2 IS2000:The Advanced Imaging Solution
2.1 System Overview
2.2 Product Features
2.3 System Interactions
2.4 The Future of IS2000
Chapter3 Global Analysis
3.1 Overview of Global Analysis Activities
3.1.1 Analyze Factors
3.1.2 Develop Strategies
3.2 Analyze Organizational Factors
3.3 Begin Developing Strategies
3.4 Analyze Technological Factors
3.5 Continue Developing Strategies
3.6 Analyze Product Factors
3.7 Continue Developing Strategies
3.8 Global Analysis Summary
Chapter4 Conceptual Architecture View
4.1 Design Activities for the Conceptual Architecture View
4.1.1 Global Analysis
4.1.2 Central Design Tasks
4.1.3 Final Design Task:Resource Budgeting
4.2 Design of Conceptual Architecture View for IS2000
4.2.1 Global Analysis
4.2.2 Central Design Tasks:Components,Connectors,and Configuration
4.2.3 Final Design Task:Resource Budgeting
4.2.4 Design Summary for IS2000 Conceptual View
4.3 Summary of Conceptual Architecture View
4.3.1 Traceability
4.3.2 Uses for the Conceptual Architecture View
Chapter 5 Module Architecture View
5.1 Design Activities for the Module Architecture View
5.1.1 Global Analysis
5.1.2 Central Design Tasks
5.1.3 Final Design Task:Interface Design
5.2 Design of Module Architecture View for IS2000
5.2.1 Global Analysis
5.2.2 Central Design Tasks:Modularization and Layering
5.2.3 Final Design Task:Interface Design
5.2.4 Design Summary for IS2000 Module View
5.3 Summary of Module Architecture View
5.3.1 Traceability
5.3.2 Uses for the Module Architecture View
Chapter6 Execution Architecture View
6.1 Design Activities for the Execution Architecture View
6.1.1 Global Analysis
6.1.2 Contral Design Tasks
6.1.3 Final Design Task:Resource Allocation
6.2 Design of Execution Architecture View for IS2000
6.2.1 Global Analysis
6.2.2 Central Design Tasks:Runtime Entities,Communication Paths,and Configuration
6.2.3 Final Design Task:Resource Allocation
6.2.4 Design Summary for IS2000 Exection View
6.3 Summary of Execution Architecture View
6.3.1 Traceability
6.3.2 Uses for the Execution Architecture View
Chapter7 Code Architecture view
7.1 Design Activities for the Code Architecture View
7.1.1 Global Analysis
7.1.2 Central Design Tasks
7.1.3 Final Design Tasks
7.2 Design of Code Architecture View for IS2000
7.2.1 Global Analysis
7.2.2 Central Design Tasks:Source Components,Intermediate Components,and Deployment Components
7.2.3 Final Design Tasks:Build Procedure andd Configuration Management
7.2.4 Design Summary for IS2000 Code Architecture View
7.3 Summary of Code Architecture View
7.3.1 Traceability
7.3.2 Uses for the Code Architecture View
Part III Software Architecture Best Practice
Chapter8 Safety Vision
8.1 Global Analysis
8.1.1 Analyze Product Factors
8.1.2 Analyze Technological Factors
8.1.3 Analyze Organizational Factors
8.1.4 Develop Strategies
8.2 Conceptual Architecture View
8.2.1 Components for Software Specification
8.2.2 Connectors for Software Specification
8.2.3 Conceptual Configuration
8.2.4 Resource Budgeting
8.3 Module Architecture View
8.3.1 ApplicationSoftware Layer
8.3.2 PlatformSoftware Layer
8.4 Execution Architecture View
8.4.1 Processes
8.4.2 Communication Paths
8.4.3 Execution Configuration
8.5 Code Architecture View
8.6 Software Architecture Uses
8.6.1 Softare Process for Projects
8.6.2 Testing of Projects
8.7 Summary
Chapter9 Healthy Vision
9.1 Global Analysis
9.1.1 Analyze Product Factors
9.1.2 Analyze Technological Factors
9.1.3 Develop Strategies
9.1.4 Conceptual Architecture View
9.2 Conceptual Architecture View
9.3 Module Architecture View
9.3.1 Decomposition of the Application Software
9.3.2 Decomposition of the Platform Software
9.3.3 Layering Structure
9.3.4 Error Logging
9.4 Execution Architecture View
9.4.1 Defining Runtime Entities
9.4.2 Communication Paths
9.4.3 Conceptual and Module Views Revisited
9.4.4 Execution Configuration
9.5 Code Architecture View
9.5.1 Development Environment
9.5.2 Configuration Management and Build Strategies
9.6 Software Architecture Uses
9.6.1 Evaluation
9.6.2 Schedule Planning
9.6.3 Implementation
9.6.4 Requirements Tracking
9.7 Summary
9.7.1 Software Architecture Comcepts
9.7.2 Experience
Chapter10 Central Vision
10.1 Global Analysis
10.1.1 Analyze Product Factors
10.1.2 Analyze Technological Factors
10.1.3 Analyze Organizational Factors
10.1.4 Develop Strategies
10.2 Conceptual Architecture View
10.3 Module Architecture View
10.3.1 Decomposition and Layering
10.3.2 Decomposition
10.4 Execution Architecture View
10.4.1 Defining Runtime Entities
10.4.2 Defining Communication Paths
10.4.3 Defining the Execution Configuration
10.4.4 Resource Allocation
10.5 Code Architecture View
10.5.1 Central Design Tasks
10.5.2 Build Procedure and Configuration
10.6 Software Architecture Uses
10.7 Summary
10.7.1 Software Architecture Concepts
10.7.2 Experience
Chapter11 Comm Vision
11.1 Global Analysis
11.1.1 Analyze Product Factors
11.1.2 Analyze Technological Factors
11.1.3 Analyze Organizational Factors
11.1.4 Develop Strategies
11.2 Conceptual Architecture View
11.3 Module Architecture View
11.3.1 Decomposition
11.3.2 SPU Interfaces and Inter-SPU Dependencies
11.3.3 Layering Structure of Shell Model
11.4 Execution Architecture View
11.4.1 Defining Executables and Configurations
11.4.2 Communication
11.4.3 Recovery Suites and Recovery-Tolerant Communication
11.4.4 Resource Allocation
11.5 Code Architecture View
11.5.1 Source Components
11.5.2 Intermediate Components
11.5.3 Configuration Management
11.6 Software Architecture Uses
11.6.1 Simulation and Code Generation
11.6.2 Higher Productivity of Software Production
11.6.3 Stepwise Production Testing of Shells
11.6.4 Architecture Control Process
11.7 Summary
11.7.1 Software Architecture Concepts
11.7.2 Experience
Part IV Software Architecture in Your Future
12.1 The Role of the Software Architect
12.2 Creating a Vision
12.3 The Architect as a Key Technical Consultant
12.4 The Architect Makes Decisions
12.5 The Architect Coordinates
12.6 The Architect Implements
12.7 The Architect Advocates
12.8 Software Architecture as a Career
Glossary
Four Views Quick Reference
Bibliography
Index

Software architecture is a recently emerged technical field, but it's not a new activity; there have always been good designers who create good software architectures. However, now the consensus is that what these designers do is qualitatively different from other software engineering activities, and we've begun figuring out how they do it and how we can teach others to do it. Software architecture is not just a new label for an old activity; software architects today face new challenges. They are asked to produce increasingly complex software using the latest technologies, but these technologies are changing faster than ever. And they are asked to produce better quality software with a shorter time-to-market. Instead of seeing the architecture as necessarily complicated by these staggering requirements, we need to realize that the architecture is our most powerful tool in meeting them. This book is a practical guide to designing, describing, and applying software architecture. The book began as a study of software architecture in industry, specifically at our company--Siemens. The study told us how practitioners define software architecture, what problems they are trying to solve with it, and how and why they choose particular architectural solutions. We examined how architects design systems so that today's technology can be replaced with tomorrow's. We saw how the experts abstracted the essential aspects of their real-time, safety-critical, reliability, and performance requirements so that they could make good architectural decisions consistently. We also saw how good architecture descriptions improved the development process, making it easier to develop high-quality software in a shorter time. We saw how managers' understanding of the architecture was critical in organizing and scheduling the project. We saw how developers depended on the architecture to define interfaces and boundaries between their component and others, and to target maintenance activities. This book also grew from our experience with software architecture as we applied the principles and techniques we saw the experts use. The description techniques helped uncover architectural problems in existing systems. The design principles guided us in defining architectures for new systems and for proposing solutions to problems in existing systems. Road Map Part I of this book provides important background information for understanding what we mean by software architecture, and how we structure the architecture design tasks. In Part II we define the architecture design tasks, and use a running example to show how they are applied to the design of a software architecture. The example system, IS2000, is an image acquisition and processing system. We don't provide its complete architecture design, but instead describe one of its subsystems in detail. The Additional Reading section at the end of each chapter in Parts I and II gives references to sources of more information on software architecture. Part III contains detailed descriptions of four industrial systems. These systems come from our original industrial study and they represent the state-of-the-art in software architexture. Each chapter in Part m gives a broad overview of the software architecture of a case study; these studies don't have the same level of detail as IS2000. The four systems are 1. Safety Vision--A half-million lines of code (LOC) instrumentation and control system for nuclear power plants 2. Healthy Vision--A million LOC embedded patient monitoring system 3. Central Vision--A half-million LOC centralized patient monitoring system 4. Comm Vision--A multimillion LOC telecommunications system The architects of these systems faced and solved some of the most difficult challenges confronting today's architects: designing large-scale, real-time, safety-critical, highly reliable systems. In Part IV, we examine the software architect's role, describing what an architect must do beyond the software architecture design. A Glossary and a Quick Reference to the architecture design tasks and artifacts are included at the end of the book. The four Quick Reference architecture views can also be found on the front and back endpapers. We have selected the Unified Modeling Language (UML) to describe the software architecture, supplemented by tables or other notations when appropriate. We chose UML because it expresses well most of what we were trying to capture, and it is widely understood. Although the architecture notation is not the essential contribution of this book, we believe that a common notation and a common agreement about what is described will further the field of software architecture by improving our ability to communicate. The main thing you'll learn from this book is a new way to tackle the problem of architecture design. You will learn what the issues are, when they should be addressed, and how they can be addressed. This book will increase your ability to recognize good solutions. Even ff it does not change your eventual architectural solutions, it will help you arrive at those solutions more quickly. Guide to the Reader There are a couple of different ways you can read this book. To get a general overview, we recommend you read Parts I and IV. For managers or others who are interested in understanding what software architecture is and how it is used, this is sufficient. Project managers, system architects, software developers, testers, and those who want a better understanding of the four software architecture views should read, in addition, at least some of Part II. You can get this overview by reading Part II; you may skip the sections that cover the example system. Thus, read the first few pages of Part II, then the first and last sections of chapters 3 through 7. Skip Chapter 2 and Sections 3.2 through 3.7, 4.2, 5.2, 6.2, and 7.2. After this overview, you will be well prepared to read the case studies. This is an option for students of software architecture or others who want to see the architecture of a range of applications. As you would expect, the case studies are all independent, so you can pick any or all to read. Read the introductory pages of Part HI to find out more about the characteristics of each case study. The final option is to read the whole book. This is, of course, what we recommend for software architects and all others who want a thorough understanding of software architecture. However, we don't expect you to digest Part III all at once. The case studies can be read over time, as the need or interest arises. Acknowledgments This book would not have been possible without the contributions of Comelis H. Hoogendoom, Heinz Kossmann, Tony Lanza, Jeff Melanson, and Stephan St6cker. They worked intimately with us to help us understand and describe the systems, which are included as case studies in Part III. We also thank the many Siemens architects and engineers who participated in our initial study of software architectures, those who participated in the Siemens Architecture Workshop, and those who worked with us while we were on assignment at various Siemens companies. We learned from their best practices and we appreciate their willingness to apply our ideas to their products. We are indebted to Thomas Grandke, Thomas Murphy, and Dan Paulish, from Siemens Corporate Research. We also thank Detlef Fischer and Wolfram Btittner from Siemens, and Linda Northrop, from the Software Engineering Institute. Their support created an environment that made writing this book possible. Len Bass, Frank Buschmann, Paul Clements, David Garlan, Hassan Gomaa, Steve Hanson, Dan Paulish, Gaynor Redvers-Mutton, Mary Shaw, Peter Sommerlad, John Viissides, and Michal Young deserve special mention for their encouragement and advice. Several dedicated colleagues at Siemens reviewed and/or used the material in its formative stages: Leonor Abraido-Fandino, Francois Bronsard, Ram Chintala, Paul Drongowski, Gilberto Matos, Dan Paulish, Michael Sassin, Bob Schwanke, Peter Spool, Veronika Strack, and Jim Wood. We also thank Mike Greenberg for contributing his expertise in software development to the Code Architecture View chapter. We also owe a large debt to the many dedicated professionals, both known and unknown to us, who reviewed the book and/or contributed their expertise to specific chapters. Len Bass, Frank Buschmann, Martin Fowler, David Garlan, Cris Kobryn, Heinz Kossmann, Philippe Kmchten, Jeff Melanson, John Moody, Jim Ning, Jim Purtilo, Brett Schuchert, Bran Selic, and Stephan St6cker all contributed insights that challenged us to improve the technical content and readability. This book might not have been written if Mike Hendrickson had not approached us and encouraged us to write a book on software architecture. We owe a great deal to the staff of Addison-Wesley Professional, including associate editors Katie Duffy and Debbie Lafferty, who kept us grounded throughout the process. Finally, we thank our families and friends for their encouragement and support.