图书介绍
软件架构设计 程序员向架构师转型必备pdf电子书版本下载
- 温昱著 著
- 出版社： 北京：电子工业出版社
- ISBN：9787121170874
- 出版时间：2012
- 标注页数：246页
- 文件大小：60MB
- 文件页数：265页
- 主题词：软件设计－教材
PDF下载
下载说明
软件架构设计 程序员向架构师转型必备PDF格式电子书版下载
下载的文件为RAR压缩包。需要使用解压软件进行解压得到PDF格式图书。建议使用BT下载工具Free Download Manager进行下载,简称FDM(免费,没有广告,支持多平台）。本站资源全部打包为BT种子。所以需要使用专业的BT下载软件进行下载。如 BitComet qBittorrent uTorrent等BT下载工具。迅雷目前由于本站不是热门资源。不推荐使用！后期资源热门了。安装了迅雷也可以迅雷进行下载！
（文件页数 要大于 标注页数，上中下等多册电子书除外）
注意：本站所有压缩包均有解压码： 点击下载压缩包解压工具
图书目录
第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部分 基本概念篇 10
第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部分 实践过程篇 40
第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部分 模块划分专题 202
第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