目录
第1章 解析软件架构概念 3
1.1 软件架构概念的分类 3
1.1.1 组成派 4
1.1.2 决策派 5
1.2 软件架构概念大观 5
1.2.1 Booch、Rumbaugh和Jacobson的定义 5
1.2.2 Woods的观点 6
1.2.3 Garlan和Shaw的定义 6
1.2.4 Perry和Wolf的定义 6
1.2.5 Boehm的定义 6
1.2.6 IEEE的定义 6
1.2.7 Bass的定义 6
1.3 软件架构关注分割与交互 7
1.4 软件架构是一系列有层次性的决策 8
1.5 PM Tool案例：领会软件架构概念 10
1.5.1 案例故事 10
1.5.2 软件架构概念的体现 13
1.5.3 重要结论 14
1.6 总结与强调 14
第2章 子系统、框架（Framework）与架构（Architecture） 15
2.1 子系统和框架在架构设计中的地位 16
2.1.1 关注点分离之道 16
2.1.2 子系统和框架在架构设计中的地位 17
2.2 子系统与软件架构 19
2.2.1 不同粒度的软件单元 20
2.2.2 子系统也有架构 21
2.2.3 子系统不同，架构不同 21
?2.2.4 不同实践者眼中的粒度 23
2.3 框架与软件架构 23
2.3.1 框架的概念 23
2.3.2 架构和框架的区别 24
2.3.3 架构和框架的联系 25
2.3.4 框架也有架构 26
2.4 超越概念：立足实践理解架构 26
2.4.1 理解架构 26
2.4.2 回到实践 28
2.5 专题：框架技术 29
2.5.1 框架vs.类库 29
2.5.2 框架的分类 30
2.5.3 框架的开发过程 32
2.5.4 如何实现框架中的扩展点 33
2.6 总结与强调 36
第3章 软件架构的作用 37
3.1 充分发挥软件架构的作用 37
3.2 软件架构对新产品开发的作用 38
3.3 软件架构对软件产品线开发的作用 40
3.4 软件架构对软件维护的作用 42
3.5 软件架构重构 42
3.6 总结与强调 43
第4章 软件架构视图 47
4.1 呼唤软件架构视图 47
4.1.1 办公室里的争论 48
4.1.2 呼唤软件架构视图 48
4.2 软件架构为谁而设计 49
4.2.1 为用户而设计 49
4.2.2 为客户而设计 50
4.2.3 为开发人员而设计 50
4.2.4 为管理人员而设计 51
4.2.5 总结 51
4.3 引入软件架构视图 52
4.3.1 生活中的“视图”运用 53
4.3.2 什么是软件架构视图 54
4.3.3 多组涉众，多个视图 54
4.4 实践指南：逻辑架构与物理架构 55
4.4.1 逻辑架构 56
4.4.2 物理架构 57
4.4.3 从逻辑架构和物理架构到设计实现 58
4.5 设备调试系统案例：领会逻辑架构和物理架构 59
4.5.1 设备调试系统案例简介 59
4.5.2 逻辑架构设计 59
4.5.3 物理架构设计 61
4.6 总结与强调 62
第5章 架构设计的5视图法 63
5.1 架构设计的5视图法 64
5.2 实践中的5视图方法 66
5.3 办公室里的争论：回顾与落实 67
5.4 案例：再谈设备调试系统 67
5.4.1 根据需求决定引入哪些架构视图 68
5.4.2 开发架构设计 68
5.4.3 运行架构设计 69
5.5 总结与强调 71
第6章 从概念性架构到实际架构 73
6.1 概念性架构 73
6.2 实际架构 77
6.3 从概念性架构到实际架构 78
6.4 网络管理系统案例：从分层架构开始 78
6.4.1 构思：概念性架构设计 78
6.4.2 深入：实际架构设计 81
6.5 总结与强调 82
第7章 如何进行成功的架构设计 83
7.1 何谓成功的软件架构设计 83
7.2 探究成功架构设计的关键要素 84
7.2.1 是否遗漏了至关重要的非功能需求 84
7.2.2 能否驯服数量巨大且频繁变化的需求 86
7.2.3 能否从容设计软件架构的不同方面 86
7.2.4 是否及早验证架构方案并做出了调整 87
7.3 制定软件架构设计策略 87
7.3.1 策略一：全面认识需求 88
7.3.2 策略二：关键需求决定架构 89
7.3.3 策略三：多视图探寻架构 89
7.3.4 策略四：尽早验证架构 90
7.4 总结与强调 90
第8章 软件架构要设计到什么程度 93
8.1 软件架构要设计到什么程度 94
8.1.1 分而治之的两种方式 94
8.1.2 架构设计与详细设计 96
8.1.3 软件架构是团队开发的基础 96
8.1.4 架构设计要进行到什么程度 98
8.2 高来高去式架构设计的症状 98
8.2.1 缺失重要架构视图 99
8.2.2 浅尝辄止、不够深入 100
8.2.3 名不副实的分层架构 101
8.3 如何克服高来高去症 101
8.4 网络管理系统案例：如何将架构设计落到实处 102
8.4.1 网管产品线的概念性架构 102
8.4.2 识别每一层中的功能模块 102
8.4.3 明确各层之间的交互接口 103
8.4.4 明确各层之间的交互机制 104
8.4.5 案例小结 105
8.5 总结与强调 105
第9章 软件架构设计过程 107
9.1 打造有效的架构设计过程 107
9.1.1 一般的软件过程 107
9.1.2 架构师自己的架构设计过程 109
9.2 软件架构设计过程解析 111
9.2.1 架构设计策略应成为一等公民 111
9.2.2 架构设计过程中的工作产品 112
9.3 总结与强调 114
第10章 需求分析 115
10.1 软件需求基础 116
10.1.1 什么是软件需求 116
10.1.2 需求捕获vs.需求分析vs.系统分析 116
10.1.3 需求捕获及其工作成果 118
10.1.4 需求分析及其工作成果 118
10.1.5 系统分析及其工作成果 119
10.2 需求分析在软件过程中所处的位置 120
10.2.1 概念化阶段所做的工作 120
10.2.2 需求分析所处的位置 122
10.3 架构师必须掌握的需求知识 123
10.3.1 软件需求的类型 123
10.3.2 各类需求对架构设计的不同影响 127
10.3.3 超市系统案例：领会需求类型的不同影响 129
10.3.4 各类需求的“易变更性”不同 130
10.3.5 质量属性需求与需求折衷 132
10.4 PM Tool实战：需求分析 135
10.4.1 上游活动：确定项目愿景 135
10.4.2 第1步：从业务目标到特性列表 135
10.4.3 第2步：从特性列表到用例图 136
10.4.4 第3步：从用例图到用例规约 138
10.4.5 需求启发与需求验证 139
10.4.6 最终成果：《软件需求规格说明书》 140
10.5 总结与强调 141
第11章 专题：用例技术及应用 133
11.1 用例图vs.用例简述vs.用例规约vs.用例实现 133
11.2 储蓄系统案例：需求变化对用例的影响 138
11.3 用例技术应用指南 140
11.4 用例与需求捕获 142
11.5 用例与需求分析 143
11.6 用例与《软件需求规格说明书》 144
11.7 总结与强调 145
第12章 领域建模 147
12.1 领域模型基础知识 147
12.1.1 什么是领域模型 148
12.1.2 领域模型相关的UML图 148
12.2 领域建模在软件过程中所处的位置 149
12.2.1 领域建模的必要性：从需求分析的两个典型困难说起 149
12.2.2 领域建模与需求分析的关系 151
12.2.3 领域建模所处的位置 152
12.3 领域模型对软件架构的重要作用 153
12.3.1 配置管理工具案例：探索复杂问题、固化领域知识 153
12.3.2 人事管理系统案例：决定功能范围、影响可扩展性 155
12.3.3 在线拍卖系统案例：提供交流基础、促进有效沟通 158
12.4 领域模型 vs. 文字说明 160
12.5 PM Tool实战：建立项目管理的领域模型 161
12.5.1 领域建模实录（1） 161
12.5.2 领域建模实录（2） 164
12.6 总结与强调 166
第13章 确定对软件架构关键的需求 167
13.1 虚拟高峰论坛：穷兵黩武还是择战而斗 167
13.1.1 需求是任何促成设计决策的因素 168
13.1.2 很少有开发者能奢侈地拥有一个稳定的需求集 168
13.1.3 关键性的第一步是缩小范围 168
13.1.4 要择战而斗 168
13.1.5 功能、质量和商业需求的某个集合塑造了构架 169
13.2 关键需求决定架构 169
13.2.1 实践中的常见问题 169
13.2.2 关键需求决定架构 171
13.3 确定关键需求在软件过程中所处的位置 172
13.3.1 对架构关键的需求vs.需求优先级 172
13.3.2 关键需求对后续活动的影响 173
13.4 什么是对软件架构关键的需求 174
13.4.1 关键的功能需求 174
13.4.2 关键的质量属性需求 175
13.4.3 关键的商业需求 175
13.5 如何确定对软件架构关键的需求 176
13.5.1 全面整理需求 177
13.5.2 分析约束性需求 178
13.5.3 确定关键功能需求 178
13.5.4 确定关键质量属性需求 179
13.6 PM Tool实战：确定关键需求 180
13.7 总结与强调 180
第14章 概念性架构设计 183
14.1 概念性架构设计的步骤 184
14.2 鲁棒性分析 185
14.2.1 分析和设计之间的鸿沟 185
14.2.2 鲁棒图简介 186
14.2.3 从用例到鲁棒图 187
14.3 运用架构模式 188
14.3.1 架构模式简介 188
14.3.2 架构模式的经典分类 189
14.3.3 架构模式的现代分类 190
14.3.4 分层 191
14.3.5 MVC 191
14.3.6 微内核 192
14.3.7 基于元模型的架构 193
14.3.8 管道-过滤器 194
14.4 PM Tool实战：概念性架构设计 194
14.4.1 进行鲁棒性分析 194
14.4.2 引入架构模式 196
14.4.3 质量属性分析 196
14.4.4 设计结果 197
14.5 总结与强调 198
第15章 质量属性分析 199
15.1 质量属性需求基础 200
15.2 质量属性分析的位置 201
15.3 利用“属性－场景－决策”表设计架构决策 201
15.3.1 概述 201
15.3.2 “属性－场景－决策”表方法 202
15.3.3 题外话：《需求文档》如何定义质量属性需求 204
15.4 PM Tool实战：可扩展性设计 204
15.5 总结与强调 205
第16章 细化架构设计 207
16.1 架构细化在软件过程中所处的位置 208
16.1.1 我们走到哪了 208
16.1.2 运用基于5视图方法进行架构细化 209
16.2 设计逻辑架构 210
16.2.1 概述 210
16.2.2 识别通用机制 210
16.3 设计开发架构 213
16.3.1 概述 213
16.3.2 分层和分区 213
16.4 设计数据架构 216
16.4.1 概述 216
16.4.2 如何将OO模型映射为数据模型 217
16.5 设计运行架构 219
16.5.1 概述 219
16.5.2 运用主动类规划并发 220
16.5.3 应用协议的设计 224
16.6 设计物理架构 224
16.6.1 概述 224
16.7 注意满足所有约束性软件需求 225
16.8 PM Tool实战：细化架构设计 226
16.9 总结与强调 229
第17章 实现并验证软件架构 231
17.1 基础知识 232
17.1.1 原型技术及分类 232
17.1.2 验证架构的两种方法 235
17.2 实现并验证软件架构的具体做法 235
17.3 总结与强调 237
第18章 MIME编码类案例：从面向过程到面向对象 239
18.1 设计目标 239
18.2 MIME编码基础知识 240
18.3 MIME编码类的设计过程 240
18.3.1 面向过程的设计方案 240
18.3.2 转向面向对象设计 242
18.3.3 面向对象设计方案的确定 245
18.3.4 Template Method和Strategy模式的对比 248
第19章 突破OOP思维：继承在OOD中的应用 249
19.1 从一则禅师语录说起 249
19.1.1 见继承是继承——程序员境界 250
19.1.2 见继承不是继承——成长境界 250
19.1.3 见继承只是继承——设计师境界 250
19.2 从OOD层面认识继承 250
19.3 针对接口编程——隔离变化 251
19.3.1 相关理论 251
19.3.2 针对接口编程举例——用于架构设计 251
19.3.3 针对接口编程举例——用于类设计 253
19.4 混入类——更好的重用性 254
19.4.1 相关理论 254
19.4.2 混入类举例 254
19.5 基于角色的设计——使用角色组装协作 255
19.5.1 相关理论 255
19.5.2 基于角色的设计举例 256
第20章 细微见真章：耦合其实并不空洞 257
20.1 顺序耦合性简介 257
20.2 案例研究：顺序耦合性Bug一例 257
20.2.1 项目简介 258
20.2.2 新的需求 258
20.2.3 发现顺序耦合性Bug 259
20.2.4 跟踪调试 259
20.2.5 分析原因 261
20.2.6 解决策略 261
20.2.7 运用重构的“Extract Method”成例 261
20.2.8 运用重构的“Hide Method”成例 262
20.2.9 运用重构的“Introduce Parameter Object”成例 262
20.2.10 其它改进 262
第21章 敏捷设计：从理论到实践 265
21.1 换个角度考察依赖 266
21.1.1 依赖的概念 266
21.1.2 从会不会造成“实际危害”的角度考察依赖 266
21.2 良性依赖原则 266
21.2.1 依赖是不可避免的 266
21.2.2 重要的是如何务实地应付变化 267
21.3 案例：需求改变引起良性依赖变成恶性依赖 267
21.4 案例：隔离第三方SDK可能造成的冲击 269
21.5 案例：对具体类的良性依赖 271
21.6 总结：如何处理好依赖关系 273
第22章 基于角色的设计：从理论到实践 275
22.1 基于角色的设计理论 276
22.2 基于角色的设计与团队开发 276
22.3 基于角色的设计实践 277
22.4 基于角色的设计案例 279
22.4.1 项目简介 279
22.4.2 通过基于角色的设计组织子系统之间的协作 279
22.4.3 通过基于角色的设计组织同一子系统内不同模块之间的协作 280
22.5 基于角色的设计与面向对象分析 281
第23章 超越设计模式：理解和运用更多模式 283
23.1 关于模式的两个问题 283
23.2 模式的正交分类法 284
23.2.1 正交思维 284
23.2.2 正交思维用于模式分类 285
23.3 专攻性能：性能模式简介 287
23.4 模型驱动开发的方方面面：MDD模式简介 289
23.5 总结：拥抱模式 290
第24章 如此轻松：立足图论学UML 291
24.1 管窥UML中的OO思想 292
24.1.1 一道笔试题的故事 292
24.1.2 UML背后的思想 293
24.2 图的定义与UML应用 294
24.2.1 图的定义 294
24.2.2 图的定义的UML应用——UML的图论观点 295
24.2.3 图的定义的UML应用——关联类语法的理解 296
24.2.4 图的定义的UML应用——说说序列图 297
24.3 有向边与UML应用 298
24.3.1 有向边 298
24.3.2 有向边的UML应用——依赖关系 298
24.3.3 有向边的UML应用——泛化、实现和关联的依赖思想 300
24.3.4 有向边的UML应用——一个例子 300
24.4 着色顶点与UML应用 301
24.4.1 着色顶点 301
24.4.2 着色顶点的UML应用——通过颜色为图元分类 302
24.4.3 着色顶点的UML应用——UML彩色建模方法介绍 303
24.5 着色边与UML应用 305
24.6 图的同构与UML应用 306
24.6.1 图的同构 306
24.6.2 图的同构的UML应用——UML风格 306
第25章 理解软件过程：解析RUP核心概念 309
25.1 架构师必须了解软件过程 309
25.1.1 架构师的工作职责 309
25.1.2 架构师必须了解软件过程 310
25.2 RUP实践中的常见问题 310
25.3 RUP核心概念解析 311
25.3.1 一图胜千言 311
25.3.2 角色执行活动，活动生产工件 311
25.3.3 阶段和迭代：提供不同级别的决策时机 312
25.3.4 配置和变更管理支持迭代式的基于基线的开发 314
25.3.5 发布是什么，发布不是什么 315
第26章 海阔凭鱼跃：通盘理解软件工程 317
26.1 什么是软件工程概念模型 317
26.2 一个精简的软件工程概念模型 317
26.3 一个细化的软件工程概念模型 318
26.3.1 模型概述 319
26.3.2 方法论 319
26.3.3 过程 319
26.3.4 目标 320
26.3.5 项目 320
26.3.6 其他 321
26.4 软件工程概念模型的具体应用 321
26.4.1 搞清楚Agile是过程还是方法论 321
26.4.2 为CMM定位 322
26.4.3 理解RUP定制 323
26.5 总结：软件工程概念模型的启示 323
26.5.1 软件工程，一门实践的科学 323
26.5.2 软件过程，合适的才是最好的 324
26.5.3 对个人的启示 324
26.5.4 呼唤高层次人才 324
展开
方法如路标。如果地形复杂，我们会迷路，但有了路标，则有利于我们找到前进的方向。好的方法也是如此，它对实践者有启发和指引作用。
我们需要一种有条理的架构设计方法。
这种方法必须有针对性。如何应对需求变更？如何为非功能需求而设计？如何设计架构的不同方面？如何验证架构的可行性？解决这些问题的思路，必须被贯穿到架构设计方法之中，且要显而易见才好。
这种方法必须易于掌握。换句话说，技术要主流；如果都是一线软件人员不熟悉的阳春白雪级的东西，大家掌握起来就比较困难了。
这种方法不能太重。迭代可以为这种方法锦上添花，但不应成为掌握这种方法的障碍；建模也不应滥用，虽然建模不仅有用而且关键……
本书紧紧围绕“软件架构设计”这一主题，立足实践解析了软件架构的概念、阐述了切实可行的软件架构设计方法、提供了可操作性极强的完整的架构设计过程。另外，本书从思维方式的突破、面向对象设计、UML建模、过程与管理等关键过渡环节，为广大程序员的成长提供了切中肯綮的指导。
理论与实践并重是本书的特点。架构设计要如何开展？架构设计要进行到什么程度？各类需求对架构设计的影响有何不同？关键需求决定架构的具体做法是什么？如何运用“属性-场景-决策”表规划非功能需求？如何运用OO原则进行敏捷设计？对这些问题书中都进行了深入阐述，并结合金融、航空、网络管理等行业软件的成功架构设计案例，将理性的思考和宝贵的实践经验奉献给读者。
感谢微软研究院的刘铁锋、《程序员》的孟岩、BeyondSoft的夏桅、IBM的罗景文等朋友的大力支持，他们为本书的策划贡献了真知灼见。感谢我的妻子徐异婕，她对本书的内容、形式、案例均提出了大量宝贵意见和建议。感谢所有为本书提出建议的朋友。
感谢父母长久以来对我的鼓励。感谢岳父岳母在整个漫长的写作过程中对宝宝无微不至的照顾，使我有更多精力铺在写作上。
由于作者水平有限，本书不足和错误之处在所难免，恳请专家和读者批评指正，欢迎来信（shanghaiwenyu@163.com）。本书的支持网站为松耦合空间（www.ou-he.com），提供与本书内容有关的资源、信息、课件等。
温 昱
2007.2.25
于上海浦东