软件架构设计

章节摘录

版权页：   插图：   该定义是“决策派”软件架构概念的典型代表，有如下两个显著特点： （1）关注架构实践中的主体——人，以人的决策为描述对象； （2）归纳了架构决策的类型，指出架构决策不仅包括关于软件系统的组织、元素、子系统和架构风格等几类决策，还包括关于众多非功能需求的决策。 2.1.3 软件架构概念大观 下面再列举几个著名的软件架构定义，请大家： 结合实践，体会自己所认为的“架构”是什么，也可问问周围同事对架构的理解； 体会专家们给“架构”下的定义虽多，但万变不离其宗——都是围绕“组成”和“决策”两个角度定义架构的； 注意区分，下面的定义1和定义2属于架构概念的“决策派”，而定义3、4、5、6、7属于架构概念的“组成派”； 关注定义7（来自SEI的Len Bass等人），它将架构的多视图“本性”体现到了定义当中，是相对比较新的定义，业界都深表认同。 1.Booch、Rumbaugh和Jacobson的定义 架构是一系列重要决策的集合，这些决策与以下内容有关：软件的组织，构成系统的结构元素及其接口的选择，这些元素在相互协作中明确表现出的行为，这些结构元素和行为元素进一步组合所构成的更大规模的子系统，以及指导这一组织——包括这些元素及其接口、它们的协作和它们的组合——架构风格。

名人推荐

与温昱先生初识于一次部门内训，金融机构应用信息技术日久，但业务发展之快仍需信息技术部门不断思索如何提供有力的技术支持，当时系统设计人员思路难成一致，故邀请先生来讲述所得，先生讲座生动有趣，案例均为实践中心得，有助于一线设计人员在低头干事之余，能够抬头看路，从架构高度理解和看待日常工作，《软件架构设计（第2版）》同样着眼于研发实践，不作黄钟大吕之音，而以一觞一咏畅叙分享一线设计师的感悟体会。此书值得一看，作者亦值得一晤！——朱晓光 中国建设银行北京开发中心处长在厦门，曾和温老师有过4天晚上的坐而论道，从技术到业界、从数据模型到软件重构、从职业观到心理学，彼此颇多启发。第一时间收到本书的电子版，读来流畅易懂，胜似面晤对谈。本书内容务实、技能梳理清晰，实乃软件开发者职业生涯发展的重要参考。——朱志 中国建设银行厦门开发中心总工办基于软件架构的开发模式，作为软件开发的最佳实践之一，越来越得到各行各业的重视和关注，但遗憾的是理解其精髓和内涵的人太少。温老师作为软件架构思想的传播者和推动者，在这本书中，对程序员如何成长为优秀的架构师给出了非常具体的指导原则和实现方法，是国内不可多得的真正将软件架构思想阐述如此精准的实践指导书。作为一名软件行业的从业者，我强烈推荐给大家。——李哲洙博士 东软集团电信事业部网管产品与系统部部长这本书以架构设计人员实际工作流程为线索，详细阐述了逻辑架构和物理架构视图的重要性及其在架构设计中的应用方法。此外，本书从实践的角度，给出了架构设计的三个原则和6大步骤，并以具体实践过程为指导，给出了架构设计从需求分析到最后的架构设计、架构验证的完整的架构设计生命周期的实践方法，对软件研发项目团队和架构师的研发实践工作具有很好的指导意义。——杨勇 中兴通讯业务研究院平台总工从事软件工作近十年，由软件功能模块的程序员开始，到独立负责几个软件项目的设计开发，一直对软件架构设计比较关注，有幸听了温昱老师的“软件架构设计”讲座，顿感茅塞顿开，再次阅读温老师的《软件架构设计》，对架构设计有了更深的感悟。如果你对软件架构设计感觉朦朦胧胧，温先生的《软件架构设计（第2版）》定能让你拨开云雾见青天。——杨为禄 南京国睿安泰信科技股份有限公司一线软件工程师近年来，阅读了诸多系统、需求、架构类的书籍资料，温老师的几本书简明扼要，见解独到，颇多启发。“横看成岭侧成峰，远近高低各不同”，大系统架构（体系结构）包括系统组分、组分间的关系，以及演化等三要素；温老师在本书中给出了典型视角、典型模式、典型过程等实践指南。有志创造系统，赋予软件灵魂的架构师，当读此书。——张雪松 中国电子科学研究院复杂大系统研究与仿真架构是很玄的东西，成为优秀的架构师也是大部分程序员的理想。温昱先生这本书的特点就是从程序员角度，深入浅出地讲述了架构师的修炼之道。程序员与架构师区别的最重要一点是看待事物的角度和处理方法，优秀的程序员按照本书的方法，在日常工作中一步步实践，有助于培养出架构师的能力，从而逐步成长成为架构师。架构的目标是为了沟通和交流，温先生也深刻地领悟到这一架构设计的根本目标，并将这一目标转化为方法论。架构设计不是给自己看的，而是为了与客户、领导和团队沟通，本书的重点在于架构设计实践，从用例、需求分析、概念模型、细化模型等一步步地指导如何完成架构设计，并且对于架构设计过程中可能出现的各种问题给予了解答。本书对于有志于成为架构师的程序员们具有非常有效的指导意义，对于已经成为架构师的同行们系统化规范架构设计也是一本很好的教材。——钱煜明 中兴通讯业务研究院移动互联网总工程师早在2009年的时候就读过温老师的《软件架构设计》第一版，2011年有幸请到温老师来公司主讲“软件架构设计”，幸有当面请教的机会，温老师对软件架构独特的授课方法和深厚的功底让我如沐春风、豁然开朗，颇有几分“顿悟”之感。五年磨一剑，如今有幸抢先拜读温老师的《软件架构设计》第二版，更是被书中内容所折服。书中融合了作者多年来在一线的实践和培训经验，深入浅出地阐释了什么是软件架构，手把手教你从客户需求入手顺畅地设计出高可用的软件架构，让你读完本书后情不自禁地感叹：“原来软件架构设计并没有那么高深莫测！”该书理论和实践并重，是一本不可多得的软件架构设计的指导书籍。——崔朝辉 东软集团技术战略与发展部资深顾问站得足够高，才能看得足够远。当今IT的架构设计思想理念已经是经过数次洗礼之后的结晶，而温昱先生抓住了这一结晶生命体的真正骨架，并深入浅出地汇集成这本书。有了这本书，你就可以依据自己的Project来高效地添加血肉，构建出独特的有机生命体。——谌晏生 广州从兴电力事业部一线软件设计师

内容概要

温昱  资深咨询顾问，软件架构专家。软件架构思想的传播者和积极推动者，中国软件技术大会杰出贡献专家。十五年系统规划、架构设计和研发管理经验，在金融、航空、多媒体、电信、中间件平台等领域负责和参与多个大型系统的规划、设计、开发与管理。

书籍目录

第1章  从程序员到架构师
1

1.1  软件业人才结构
1

1.1.1  金字塔型，还是橄榄型？
1

1.1.2  从程序员向架构师转型
2

1.2  本书价值
3

1.2.1  阅读路径1：架构设计入门
3

1.2.2  阅读路径2：领会大系统架构设计
4

1.2.3  阅读路径3：从需求到架构的全过程
5

1.2.4  阅读路径4：结合工作，解决实际问题
6

第1部分  基本概念篇

第2章  解析软件架构概念
10

2.1  软件架构概念的分类
10

2.1.1  组成派
11

2.1.2  决策派
11

2.1.3  软件架构概念大观
12

2.2  概念思想的解析
13

2.2.1  软件架构关注分割与交互
13

2.2.2  软件架构是一系列有层次的决策
14

2.2.3  系统、子系统、框架都可以有架构
17

2.3  实际应用（1）——团队对架构看法不一怎么办
18

2.3.1  结合手上的实际工作来理解架构的含义
18

2.3.2  这样理解“架构”对吗
19

2.3.3  工作中找答案：先看部分设计
19

2.3.4  工作中找答案：反观架构概念的体现
22

第3章  理解架构设计视图
24

3.1  软件架构为谁而设计
24

3.1.1  为用户而设计
25

3.1.2  为客户而设计
26

3.1.3  为开发人员而设计
26

3.1.4  为管理人员而设计
26

3.1.5  总结
27

3.2  理解架构设计视图
28

3.2.1  架构视图
28

3.2.2  一个直观的例子
28

3.2.3  多组涉众，多个视图
29

3.3  运用“逻辑视图+物理视图”设计架构
30

3.3.1  逻辑架构
31

3.3.2  物理架构
32

3.3.3  从“逻辑架构+物理架构”到设计实现
32

3.4  实际应用（2）——开发人员如何快速成长
33

3.4.1  开发人员应该多尝试设计
33

3.4.2  实验项目：案例背景、训练目标
34

3.4.3  逻辑架构设计（迭代1）
35

3.4.4  物理架构设计（迭代1）
35

3.4.5  逻辑架构设计（迭代2）
36

3.4.6  物理架构设计（迭代2）
37

第2部分  实践过程篇

第4章  架构设计过程
40

4.1  架构设计的实践脉络
41

4.1.1  洞察节奏：3个原则
41

4.1.2  掌握过程：6个步骤
43

4.2  架构设计的速查手册
45

4.2.1  需求分析
45

4.2.2  领域建模
46

4.2.3  确定关键需求
47

4.2.4  概念架构设计
49

4.2.5  细化架构设计
50

4.2.6  架构验证
51

第5章  需求分析
53

5.1  需求开发（上）——愿景分析
53

5.1.1  从概念化阶段说起
54

5.1.2  愿景
54

5.1.3  上下文图
56

5.1.4  愿景分析实践要领
60

5.2  需求开发（下）——需求分析
60

5.2.1  需求捕获vs.需求分析vs.系统分析
61

5.2.2  需求捕获及成果
63

5.2.3  需求分析及成果
64

5.2.4  系统分析及成果
65

5.3  掌握的需求全不全
65

5.3.1  二维需求观与ADMEMS矩阵
65

5.3.2  功能
66

5.3.3  质量
68

5.3.4  约束
71

5.4  从需求向设计转化的“密码”
72

5.4.1 “理性设计”还是“拍脑袋”
72

5.4.2  功能：职责协作链
73

5.4.3  质量：完善驱动力
74

5.4.4  约束：设计并不自由
74

5.5  实际应用（3）——PM Suite贯穿案例之需求分析
75

5.5.1  PM Suite案例背景介绍
76

5.5.2  第1步：明确系统目标
77

5.5.3  第2步：范围 + Feature + 上下文图
77

5.5.4  第3步：画用例图
82

5.5.5  第4步：写用例规约
85

5.5.6  插曲：需求启发与需求验证
86

5.5.7  插曲：非功能需求
88

5.5.8  《需求规格》与基于ADMEMS矩阵的需求评审
88

第6章  用例与需求
89

6.1  用例技术族
89

6.1.1  用例图
90

6.1.2  用例简述、用户故事
90

6.1.3  用例规约
91

6.1.4  用例实现、鲁棒图
92

6.1.5  4种技术的关系
93

6.2  用例技术族的应用场景
94

6.2.1  用例与需求分析
94

6.2.2  用例与需求文档
95

6.2.3  用例与需求变更
97

6.3  实际应用（4）——用例建模够不够？流程建模要不要
99

6.3.1  软件事业部的故事
99

6.3.2  小型方法：需求分析的三套实践论（上）
99

6.3.3  中型方法：需求分析的三套实践论（中）
100

6.3.4  大型方法：需求分析的三套实践论（下）
101

6.3.5  PM Suite应用一幕
102

第7章  领域建模
105

7.1  什么是领域模型
106

7.1.1  领域模型“是什么”
106

7.1.2  领域模型“什么样”
106

7.1.3  领域模型“为什么”
107

7.2  需求人员视角——促进用户沟通、解决分析瘫痪
108

7.2.1  领域建模与需求分析的关系
108

7.2.2  沟通不足
109

7.2.3  分析瘫痪
110

7.2.4  案例：多步领域建模，熟悉陌生领域
111

7.3  开发人员视角——破解“领域知识不足”死结
113

7.3.1  领域模型作为“理解领域的手段”
113

7.3.2  案例：从词汇表到领域模型
113

7.4  实际应用（5）——功能决定如何建模，模型决定功能扩展
115

7.4.1  案例：模型决定功能扩展
116

7.4.2  实践：功能决定如何建模
118

7.4.3  PM Suite领域建模实录（1）——类图
122

7.4.4  PM Suite领域建模实录（2）——状态图
125

7.4.5  PM Suite领域建模实录（3）——可扩展性
126

第8章  确定关键需求
129

8.1  众说纷纭——什么决定了架构
129

8.1.1  用例驱动论
130

8.1.2  质量决定论
131

8.1.3  经验决定论
132

8.2  真知灼见——关键需求决定架构
132

8.2.1 “目标错误”比“遗漏需求”更糟糕
132

8.2.2  关键需求决定架构，其余需求验证架构
132

8.3  付诸行动——如何确定关键需求
133

8.3.1  确定关键质量
133

8.3.2  确定关键功能
135

8.4  实际应用（6）——小系统与大系统的架构分水岭
137

8.4.1  架构师的“拿来主义”困惑
137

8.4.2  场景1：小型PMIS（项目型ISV背景）
138

8.4.3  场景2：大型PM Suite（产品型ISV背景）
139

8.4.4  场景3：多个自主产品组成的方案（例如IBM）
140

8.4.5 “拿来主义”虽好，但要合适才行
141

第9章  概念架构设计
143

9.1  概念架构是什么
144

9.1.1  概念架构是直指目标的设计思想、重大选择
144

9.1.2  案例1：汽车电子AUTOSAR——跨平台复用
145

9.1.3  案例2：腾讯QQvideo架构——高性能
149

9.1.4  案例3：微软MFC架构——简化开发
150

9.1.5  总结
151

9.2  概念架构设计概述
151

9.2.1 “关键需求”进，“概念架构”出
151

9.2.2  概念架构≠理想化架构
152

9.2.3  概念架构≠细化架构
152

9.3  左手功能——概念架构设计（上）
153

9.3.1  什么样的鸿沟，架什么样的桥
153

9.3.2  鲁棒图“是什么”
153

9.3.3  鲁棒图“画什么”
154

9.3.4  鲁棒图“怎么画”
156

9.4  右手质量——概念架构设计（下）
159

9.4.1  再谈什么样的鸿沟，架什么样的桥
159

9.4.2  场景思维
159

9.4.3  场景思维的工具
160

9.4.4  目标—场景—决策表应用举例
162

9.5  概念架构设计实践要领
163

9.5.1  要领1：功能需求与质量需求并重
163

9.5.2  要领2：概念架构设计的1个决定、4个选择
163

9.5.3  要领3：备选设计
165

9.6  实际应用（7）——PM Suite贯穿案例之概念架构设计
165

9.6.1  第1步：通过初步设计，探索架构风格和高层分割
165

9.6.2  第2步：选择架构风格，划分顶级子系统
169

9.6.3  第3步：开发技术、集成技术与二次开发技术的选型
171

9.6.4  第4步：评审3个备选架构，敲定概念架构方案
172

第10章  细化架构设计
174

10.1  从2视图方法到5视图方法
175

10.1.1  回顾：2视图方法
175

10.1.2  进阶：5视图方法
175

10.2  程序员向架构师转型的关键突破——学会系统思考
176

10.2.1  系统思考之“从需求到设计”
177

10.2.2  系统思考之“5个设计视图”
179

10.3  5视图方法实践——5个视图、15个设计任务
181

10.3.1  逻辑架构＝模块划分＋接口定义＋领域模型
181

10.3.2  开发架构＝技术选型＋文件划分＋编译关系
184

10.3.3  物理架构＝硬件分布＋软件部署＋方案优化
185

10.3.4  运行架构＝技术选型＋控制流划分＋同步关系
187

10.3.5  数据架构＝技术选型＋存储格式＋数据分布
188

10.4  实际应用（8）——PM Suite贯穿案例之细化架构设计
189

10.4.1  PM Suite接下来的设计任务
189

10.4.2  客户端设计的相关说明
191

10.4.3  细化领域模型时应注意的两点
192

第11章  架构验证
194

11.1  原型技术
194

11.1.1  水平原型vs.垂直原型，抛弃原型vs.演进原型
195

11.1.2  水平抛弃原型
196

11.1.3  水平演进原型
197

11.1.4  垂直抛弃原型
197

11.1.5  垂直演进原型
197

11.2  架构验证
198

11.2.1  原型法
198

11.2.2  框架法
199

11.2.3  测试运行期质量，评审开发期质量
199

第3部分  模块划分专题

第12章  粗粒度“功能模块”划分
202

12.1  功能树
203

12.1.1  什么是功能树
203

12.1.2  功能分解≠结构分解
203

12.2  借助功能树，划分粗粒度“功能模块”
204

12.2.1  核心原理：从“功能组”到“功能模块”
205

12.2.2  第1步：获得功能树
207

12.2.3  第2步：评审功能树
211

12.2.4  第3步：粗粒度“功能模块”划分
212

12.3  实际应用（9）——对比MailProxy案例的4种模块划分设计
213

12.3.1  设计
213

12.3.2  设计的优点、缺点
213

12.4  实际应用（10）——做总体，要提交啥样的“子系统划分方案”
214

第13章  如何分层
217

13.1  分层架构
218

13.1.1  常见模式：展现层、业务层、数据层
218

13.1.2  案例一则
218

13.1.3  常见模式：UI层、SI层、PD层、DM层
219

13.1.4  案例一则
220

13.2  分层架构实践技巧
221

13.2.1  设计思想：分层架构的“封装外部交互”思想
221

13.2.2  实践技巧：设计分层架构，从上下文图开始
221

13.3  实际应用（11）——对比MailProxy案例的 4种模块划分设计
223

13.3.1  设计
223

13.3.2  设计的优点、缺点
224

第14章  用例驱动的模块划分过程
225

14.1  描述需求的序列图 vs. 描述设计的序列图
225

14.1.1  描述“内外对话” vs. 描述“内部协作”
226

14.1.2 《用例规约》这样描述“内外对话”
227

14.2  用例驱动的模块划分过程
228

14.2.1  核心原理：从用例到类，再到模块
228

14.2.2  第1步：实现用例需要哪些类
231

14.2.3  第2步：这些类应该划归哪些模块
235

14.3  实际应用（12）——对比MailProxy案例的 4种模块划分设计
236

14.3.1  设计
236

14.3.2  设计的优点、缺点
236

第15章  模块划分的4步骤方法——运用层、模块、功能 模块、用例驱动
238

15.1  像专家一样思考
238

15.1.1  自顶向下vs.自底向上，垂直切分vs.水平切分
238

15.1.2  横切竖割，并不矛盾
239

15.2  模块划分的4步骤方法——EDD方法
241

15.2.1  封装驱动设计的4个步骤
241

15.2.2  细粒度模块的划分技巧
242

15.3  实际应用（13）——对比MailProxy案例的4种模块划分设计
245

15.3.1  设计
245

15.3.2  设计的优点、缺点
246

编辑推荐

《软件架构设计:程序员向架构师转型必备(第2版)》编辑推荐：详解软件架构设计实践过程及方法，要成为软件架构设计师必读书。

作者简介

《软件架构设计:程序员向架构师转型必备(第2版)》围绕“软件架构设计”主题，从“程序员”成长的视角，深入浅出地讲述了架构师的修炼之道。从“基础篇”、到“设计过程篇”、到“模块划分专题”，《软件架构设计:程序员向架构师转型必备(第2版)》覆盖了架构设计的关键技能项，并且对于架构设计过程中可能出现的各种问题给与了解答。

图书封面

---

 软件架构设计下载 精选章节试读

---