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

几年前，作者们开始注意到Grady Booch首创的《软件架构手册》（《Handbook of Software Architecture》，wwwhandbookofsoftwarearchitecturecom）。Grady起初的目的是：
整理许多有趣的软件密集型系统的架构，以揭示它们的基本模式以及允许在域和架构风格之间进行比较的方式，并把它们呈现出来。
　　当Grady正关注于最终架构的时候，我们感到理解成功架构师创建他们的架构时所遵循的流程同样很有趣。当然，我们最终的目的是复制他们的成功。我们花了好几年的时间才完成这个过程。我们做了许多项目，和许多架构师进行了交流，还对许多开发方法进行了梳理——所有这些都有助于我们理解当构建一个软件系统时起作用和不起作用的因素的本质。本书是我们经历的这个过程的总结。
　　许多优秀的书讲述了软件架构过程的特定方面，我们借鉴了这些书中的相关内容。例如，其中有些书注重编写一个软件架构的文档，另一些书注重如何评价一个软件架构。其中任意一方面都适合比较大的场景，因为每一方面都呈现了软件架构过程中的一个重要因素。因此，本书的一个目的是通过提供在一个典型软件开发项目的环境中架构的所有方面的概览来呈现这个大场景。
　　应该指出的是，本书没有指定一个专门的软件开发方法。更确切地说，本书讲述了人们在支持构建过程的任意现代开发方法中可能遇到的关键因素。
本书是为谁准备的
　　显然，本书是针对那些想了解他们的角色如何适应整个软件开发过程的软件架构师（或者立志成为软件架构师的人）。本书也适合“专门”的架构师角色，如应用架构师和安全架构师。更笼统地说，本书适合那些想更好地了解软件架构师这个角色的人。就这点而言，它对一个软件开发团队的所有成员也都有好处，包括开发人员、测试人员、业务分析人员、项目经理、配置经理和过程控制工程师。本书也特别适合那些在软件开发的尝试中想了解日益重要的软件架构师角色的大学生。
如何阅读本书
　　本书大致分为三个部分：
　　第1~5章为第一部分，概述了架构、架构师、架构设计、编写软件架构文档、可重用架构资源的核心概念。
　　第6~9章为第二部分，这部分包含了相关案例研究的章，通过一个基于样例应用程序的典型软件开发项目，重点体现架构师这个角色，提供一个指导性指南。这些章的编写方式，使你很容易找到感兴趣的特定主题。每个相关案例研究的章主要按照任务进行组织，另外，在这些章中我们使用了一些排版体例。特别是，对流程元素的所有引用，如任务、工件和角色，都用黑体加以强调，例如当我们描述软件架构文档工件的时候。
　　第10章为第三部分，包含额外讨论的话题和思考，尤其是，在前面的章中描述的概念如何应用于架构复杂的系统。
　　在本书中，你还会发现一些如下进行分类的有用的补充内容：
　　 概念补充内容： 介绍与讨论与主题相关的想法或整套想法。
　　 检查清单补充内容： 包含当执行某一特定任务时，可以进行检查的有用的项目。
　　 最佳实践补充内容： 介绍已经在实践中证实为有效的方法。
　　 缺陷补充内容： 介绍最好避免的方法，因为它们会导致负面效果。
　　我们在本书中大范围地使用统一建模语言（UML）来描述架构的某些方面。所有的UML图表都是通过IBM Rational Software Architect创建的。
附属站点
　　本书有一个附属的站点： processofsoftwarearchitectingcom，读者可以在这个站点上找到额外的信息，也可以和作者进行交流。

“软件架构师这个角色在最近几年很盛行，也被认为是项目成功的一个关键因素。然而，即使在今天，人们对如何分析需求、理解关注点、评估可选方案及构建和编写符合目的的架构描述文档等工作仍然缺少一些常规的理解。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的副主席，企业架构师和技术作家

计算机\软件工程

成功的软件离不开好的软件架构，高效的架构设计需要透彻地理解组织的角色、工件、执行的活动以及执行这些活动的最优顺序。
本书介绍了如何应对软件系统架构设计时的各种挑战，引入了基于Java EE、Microsoft .NET或其他技术的最佳实践。书中首先阐述了架构设计文档、可重用资源等软件架构的相关概念，接着通过一个典型项目介绍了一个容易理解的、关注任务的旅游指导（这个项目关注架构师的角色），并讨论了一些常见问题，最后总结了一组可以应用于当今最复杂系统的最佳实践。
本书适合软件架构师、项目经理和软件从业人员阅读。
本书主要内容
·在典型的软件开发项目中架构师扮演的角色
·如何编写软件架构文档来满足不同利益相关者的需求
·架构设计过程中可重用资源的适用性
·在定义需求时架构师扮演的角色
·如何基于一组需求来获取架构
·创建复杂系统的过程中架构设计的相关性
作者简介
Peter Eeles　 IBM Rational Software的高级IT架构师，其主要工作室进行架构设计和实现大规模、分布式的系统。他目前致力于帮助组织提高软件开发能力。除本书外，Eeles还与人合作编写了《Building J2EETM Applications with the Rational Unified Process》（Addison-Wesley，2003）和《Building Business Objects》（Wiley，1998）。

Peter Cripps　 IBM Global Business Services的高级IT架构师，专注于应用组件和基于服务的开发技术，并在整个IBM公司推广架构设计最佳实践，目前从事IBM Unified Method Framework的开发工作。

（英）Peter Eeles　 Peter Cripps　著：暂无简介

蔡黄辉 马文涛 译：暂无简介

光阴荏苒，时光如逝，一转眼，我已经工作十年有余。在这十年间，我基本上一直在从事软件开发的工作。从编码到设计，再到需求，再参与一些管理工作。我相信大部分从事软件行业的人都和我有相似的经历。在这个过程中，大家都会时不时地思考一些和软件开发相关的问题：什么是软件项目？软件项目的目的是什么？如何在资源（人力、成本、时间等）有限的情况下尽可能地开发出高质量的软件产品？架构在软件项目的整个过程中起到什么作用？架构师在软件项目中担任什么角色，能起到什么作用？等等。对于这些问题，在本书中都能找到答案。
　　本书从基本原理入手，介绍软件架构设计过程中涉及的一些概念、流程、方法、用到的工作产品及可重用的资源，从第6章开始，通过介绍一个具体的案例来阐述如何定义需求、创建逻辑架构、创建物理架构。在第10章“进阶”中，作者补充说明了架构师和软件开发项目其他方面的关系，后面又说明了各种软件架构设计过程中可能存在的困难及相应的处理方法。总的来说，本书理论结合实践，介绍了一些可以应用到整个或部分的架构设计过程中的最佳方法。不管你是一位资深的架构师还是一位有志于成为架构师的初级使用者，通过阅读本书都能从中获益。
　　本书的第1~5章由我翻译，第6~10章由我的朋友马文涛翻译。由于时间仓促，书中有些处理不妥的地方，敬请谅解。
　　最后，我要感谢我的父母和妻子，感谢他们在我翻译的过程中所给予的帮助和支持。

蔡黄辉
2010年3月5日

译者序
序
前言
致谢
作者简介
第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2Zachman框架
453Rozanski 和Woods框架
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4YourTour的愿景
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架构需求检查列表
术语表
参考文献