伊乐斯（Peter Eeles），IBM RationaI Software的高级IT架构师，主要工作是进行架构设计和实现大规模、分布式的系统。他目前致力于帮助组织提高软件开发能力。除本书外，Eeles还与人合作编写了《Building J2EE Applicatio with  theRatio rlaI Unifjed Process》（Addisorl-WesIey，2003）和《BuiIdlng Busi rless Objects》（Wiley，1998）。
　　克里普斯（Peter Cripps），IBM Global Business Services的高级IT架构师，专注于应用组件和基于服务的开发技术，并在整个IBM公司推广架构设计最佳实践，目前从事IBM Unified Method FrarTlework的开发工作。

　　《架构实战：软件架构设计的过程》从基本原理入手，介绍软件架构设计过程中涉及的一些概念、流程、方法、用到的工作产品及可重用的资源，从第6章开始，通过介绍一个具体的案例来阐述如何定义需求、创建逻辑架构、创建物理架构。在第10章“进阶”中，作者补充说明了架构师和软件开发项目其他方面的关系，后面又说明了各种软件开发项目可能存在的困难及相应的处理方法。
　　《架构实战：软件架构设计的过程》理论结合实践，介绍了一些可以应用到整个或部分的架构设计流程中的最佳方法。不管你是一位资深的架构师还是一位有志于成为架构师的初级使用者，通过阅读《架构实战：软件架构设计的过程》都能从中获益。

　　“软件架构师这个角色在最近几年很盛行，也被认为是项目成功的一个关键因素。然而，即使在今天，人们对如何分析需求、理解关注点、评估可选方案及构建和编写符合目的的架构描述文档等工作仍然缺少一些常规的理解。Eeles和Cripps在他们这本非常有用和有实践性的书中填补了这个空白。书中的内容清楚易懂，遵循从起始到交付的一个逻辑流程，通过研究一个真实的案例对任务和工作产品进行了清楚的解释和阐述。无论对于新的架构师，还是经验丰富的专家，这都是一本重要的手册。”
　　——Nick Rozanski，《软件系统架构》的作者之一
　　“如果您需要一本关于软件架构流程的全面和权威的参考书，那就不用再等待了。Peter Eeles和Peter Cripps已经为这个流程编写了一本权威性的指导参考书。本书中介绍的流程利用一个元模型进行了准确的定义，通过一个真实的研究案例进行了阐述，还清楚地关联到像UML、RUP和IEEE 1471等这样的关键标准，因此为那些大型项目开发中的软件架构提供了颇有价值的指导。我一点都不怀疑本书会成为许多软件架构师的一本很有价值的参考书。”
　　——Eoin Woods，《软件系统架构》的作者之一
　　“Eeles和Cripps把多年的经验汇集到这本指导书中，帮助读者不仅理解架构师生产什么，还理解他们如何生产。本书是一本具有很高实践性的指导书，其中详尽阐述了获得的经验和需要避免的陷阱。已经成为架构师的人将参考本书，因为它能够使他们的技术更完善；而期望成为架构师的人通过阅读它能够获得一些需要多年痛苦的经历才能获得的关键见识。”
　　——Bob Kitzberger，IBM Software Group的程序主管、战略家
　　“就我在这个领域的工作经验来看，软件架构给人的感觉有点像妖术，只有精选的少许专家和天才才有天分从事这项工作。本书先介绍行业最佳实践和作者宝贵的经验，然后把架构解决方案带入一个真实的工程学科的范畴。现在，我有了一本可以传授给新从业者的参考书，一本讲授过去需要多年尝试和出错才能体会到的经验的书。”
　　——Colin Renouf，英国Websphere User Group的副主席，企业架构师和技术作家

　　2.4 架构设计的优点
　　总的来说，架构设计是降低成本、改进质量、支持按计划及时交付、支持按需求交付及降低风险的-个关键因素。在这一部分，我们集中讲述架构设计有助于达成这些目标的更明确的优点。
　　另外，因为架构师有时候必须证明架构设计的存在是合理的，这一部分将提供一些有用的资料来证明架构设计是软件开发流程中的一个重要组成部分。
　　2.4.1 架构设计解决系统的质量问题
　　系统的功能性是通过组成架构的各种元素之间发生的交互来支持的。不管怎样，架构设计的关键特征之一是系统质量是通过架构这个工具达到的。在缺少统一的架构设想的情况下，像性能、安全及可维护性这样的质量是不可能保证的，这些质量不仅限于单个架构元素，而是遍布于整个架构。
　　例如，为了处理性能的需求，必须考虑架构的每个组件执行的时间以及组件之间通信所花的时间。同样，为了处理安全的需求，必须考虑组件之间的通信类型，而且在必要的地方引入专门的具有安全意识的组件。所有这些考虑都是关于架构的，而且，在这些例子中，涉及这些组件本身以及它们之间的联系。
　　架构设计的一个相关优点是使得在项目生命周期的早期评估这类质量成为可能。通常特意创建架构的概念模型以确保处理这类质量。通过一个真实的实现（在这种情况下采用架构概念模型）来证明达到这类质量要求，这很重要，因为一个架构无论在纸上看起来多么优秀，只有可执行软件才是这种架构已经处理这类质量的唯一真实标准。
　　2.4.2 架构设计促进达成共识
　　架构设计流程促进不同的利益相关者达成共识，因为它提供了一个工具使大家能够对系统解决方案进行辩论。为了支持这样的辩论，架构设计流程必须确保架构被清楚地交流和证实。
　　一个可以被有效交流的架构使得大家对决策和折中进行辩论，使检查变得容易，还使得大家达成一致。相反，一个缺乏交流的架构不会使这样的辩论发生。没有这样的输入，最终的架构可能是低质量的。很明显，对一个架构进行有效交流的一个重要方面是为它适当地编写文档。这是架构师的主要关注点，也是第4章“编写软件架构文档”的主题。
　　需要注意的是，架构可以作为培训的一部分，促进架构师（及他们的设想）和新的或现有的团队成员之间达成共识。为了取得这个好处，架构还必须进行有效地交流。清楚知道他们正在实现的内容的开发团队会更有可能按期望实现产品。
　　通过验证架构是否符合规定的需求也可以促进达成共识。正如前一部分提到的，创建可执行概念模型是证明一个架构达到一定运行期质量的一个极好方式。

译者序
序
前言
致谢
作者简介

第1章 导言
1.1 流程应用
1.2 流程概述
1.3 范围
1.4 总结

第2章 架构，架构师和架构设计
2.1 架构
2.1.1 架构定义结构
2.1.2 架构定义行为
2.1.3 架构关注重要的元素
2.1.4 架构平衡利益相关者的需要
2.1.5 架构基于合理证据使决策具体化
2.1.6 架构会遵循一种架构风格
2.1.7 架构受它的环境影响
2.1.8 架构影响开发团队的结构
2.1.9 所有系统都存在架构
2.1.10 架构有特定的范围
2.2 架构师
2.2.1 架构师是技术领导
2.2.2 架构师的角色可能由一个团队来履行
2.2.3 架构师理解软件开发流程
2.2.4 架构师掌握业务领域的知识
2.2.5 架构师掌握技术知识
2.2.6 架构师掌握设计技能
2.2.7 架构师具备编程技能
2.2.8 架构师是优秀的沟通人员
2.2.9 架构师进行决策
2.2.10 架构师知道组织政策
2.2.11 架构师是谈判专家
2.3 架构设计
2.3.1 架构设计是一门科学
2.3.2 架构设计是一门艺术
2.3.3 架构设计跨越很多方面
2.3.4 架构设计是一个渐进的活动
2.3.5 架构设计受许多利益相关者驱动
2.3.6 架构设计经常包括折中
2.3.7 架构设计承认经验
2.3.8 架构设计既由上而下也由下而上
2.4 架构设计的优点
2.4.1 架构设计解决系统的质量问题
2.4.2 架构设计促进达成共识
2.4.3 架构设计支持计划编制流程
2.4.4 架构设计促进架构的完整性
2.4.5 架构设计有助于管理复杂性
2.4.6 架构设计为重用提供基础
2.4.7 架构设计降低维护成本
2.4.8 架构设计支持影响分析
2.5 总结

第3章 方法基本原理
3.1 关键概念
3.2 方法内容
3.2.1 角色
3.2.2 工作产品
3.2.3 活动
3.2.4 任务
3.3 流程
3.3.1 瀑布流程
3.3.2 迭代流程
3.3.3 敏捷流程
3.4 总结

第4章 编写软件架构文档
4.1 最终的结局
4.2 关键概念
4.3 视点和视图
4.3.1 基础视点
4.3.2 交叉视点
4.3.3 视图及图表
4.3.4 视点及视图的优点
4.4 模型
4.4.1 实现的层级
4.4.2 模型的优点
4.5 架构描述框架的特征
4.5.1 软件架构的4+1视图模型
4.5.2 Zachman框架
4.5.3 R0zanski和W00ds框架
4.6 一个架构描述框架
4.6.1 视点
4.6.2 产品
4.6.3 实现的层级
4.6.4 视图一致
4.7 软件架构文档
4.8 总结

第5章 可重用架构资源
5.1 架构的来源
5.2 架构资源元模型
5.2.1 开发期资源
5.2.2 运行期资源
5.3 资源类型
5.3.1 参考架构
5.3.2 开发方法
5.3.3 视点目录
5.3.4 架构风格
5.3.5 架构机制
5.3.6 模式
5.3.7 参考模型
5.3.8 架构决策
5.3.9 现有的应用程序
5.3.10 封装的应用程序
5.3.11 应用框架
5.3.12 组件库／组件
5.4 架构资源的属性
5.5 重用的其他考虑因素
5.6 总结

第6章 案例介绍
6.1 流程应用
6.2 案例研究范围
6.2.1 项目团队
6.2.2 外部影响因素
6.3 应用简介
6.4 YourFour的愿景
6.4.1 问题声明
6.4.2 利益相关者
6.4.3 系统功能
6.4.4 系统的质量
6.4.5 约束
6.5 总结

第7章 定义需求
7.1 关联需求和架构
7.2 功能性需求和非功能性需求
7.3 编写需求文档的技术
7.4 流程应用
7.5 理解任务描述
7.6 定义需求：活动概览
7.7 总结

第8章 创建逻辑架构
8.1 从需求走向解决方案
8.2 逻辑架构的价值
8.2.1 使逻辑架构最小化
8.2.2 把逻辑架构作为一项投资
8.2.3 可追溯性的重要性
8.3 流程应用
8.4 创建逻辑架构：活动概览
8.5 总结

第9章 创建物理架构
9.1 从逻辑架构到物理架构
9.2 流程应用
9.3 创建物理架构：活动概览
9.4 任务：调查架构资源
9.5 任务：定义架构概览
9.6 任务：编写架构决策文档
9.7 任务：概述功能性元素
9.7.1 将逻辑功能元素映射到物理功能元素
9.7.2 确认物理功能元素
9.7.3 采购产品
9.7.4 适应特定技术的模式
9.8 任务：概述部署元素
9.8.1 映射逻辑部署元素到物理部署元素
9.8.2 确认物理部署元素
9.8.3 采购硬件
9.9 任务：检验架构
9.10 任务：构建架构概念证明
9.11 任务：细化功能性元素
9.12 任务：细化部署元素
9.13 任务：确认架构
9.14 任务：更新软件架构文档
9.15 任务：和利益相关者复审架构
9.16 总结

第10章 进阶
10.1 架构师和项目团队
10.1.1 架构师和需求
10.1.2 架构师和开发
10.1.3 架构师和测试
10.1.4 架构师和项目管理
10.1.5 架构师和配置管理
10.1.6 架构师和变更管理
10.1.7 架构师和开发环境
10.1.8 架构师和业务分析
10.2 架构师和外界影响
10.2.1 企业架构
10.2.2 设计权威
10.2.3 基础设施提供者
10.2.4 系统维护者
10.3 复杂系统的架构设计
10.3.1 许多独特的功能正在开发
10.3.2 许多人员参与开发
10.3.3 系统是高度分布式的
10.3.4 开发团队是分布式的
10.3.5 运行质量非常有挑战性
10.3.6 存在系统之系统
10.4 总结
附录A 软件架构元模型
附录B 视点目录
附录C 方法概述
附录D 架构需求检查列表
术语表
参考文献