软件系统架构 使用视点和视角与利益相关者合作 原书第2版PDF电子书下载

第1章 简介 1

1.1 利益相关者、视点和视角 1

1.2 本书结构 4

1.3 谁应该阅读本书 5

1.4 本书约定 5

第一部分 架构的基本原则 8

第2章 软件架构概念 8

2.1 软件架构 8

2.1.1 系统元素和关系 8

2.1.2 基本系统属性 9

2.1.3 设计和发展的原则 10

2.1.4 系统属性和内部组织形式 10

2.1.5 软件架构的重要性 13

2.2 架构元素 13

2.3 利益相关者 14

2.3.1 个人、团队或组织 14

2.3.2 兴趣和关注点 15

2.3.3 利益相关者的重要性 16

2.4 架构描述 16

2.5 核心概念之间的关系 17

2.6 小结 18

2.7 延伸阅读 19

第3章 视点和视图 20

3.1 架构视图 22

3.2 视点 23

3.3 核心概念之间的关系 24

3.4 使用视点和视图的好处 24

3.5 视点缺陷 25

3.6 视点目录 25

3.7 小结 27

3.8 延伸阅读 28

第4章 架构视角 29

4.1 质量属性 29

4.2 架构视角 30

4.3 向视图应用视角 33

4.4 应用视角的结果 34

4.4.1 深入的观点 34

4.4.2 提升 35

4.4.3 精品内容 35

4.5 核心概念之间的关系 35

4.6 使用视角的好处 36

4.7 视角的缺陷 37

4.8 视角与视点对比 37

4.9 视角种类 38

4.10 小结 39

4.11 延伸阅读 39

第5章 软件架构师的角色 41

5.1 架构定义过程 41

5.1.1 架构定义不仅是设计 42

5.1.2 需求分析和架构定义之间的区别 43

5.1.3 架构定义和设计之间的区别 43

5.2 架构师的角色 44

5.3 核心概念之间的相互关系 46

5.4 架构专门化 47

5.5 组织情境 47

5.5.1 业务分析师 47

5.5.2 项目经理 47

5.5.3 设计主管 48

5.5.4 技术专家 49

5.5.5 开发者 49

5.6 架构师的技能 49

5.7 架构师的责任 50

5.8 小结 51

5.9 延伸阅读 51

第二部分 软件架构过程 54

第6章 软件架构过程简介 54

第7章 架构定义过程 55

7.1 指导原则 55

7.2 过程产出物 56

7.3 过程情境 56

7.4 支持活动 57

7.5 架构定义活动 60

7.6 过程完成标准 62

7.7 软件开发生命周期中的架构定义 64

7.7.1 瀑布式方法 64

7.7.2 迭代方法 65

7.7.3 敏捷方法 65

7.8 小结 66

7.9 延伸阅读 67

第8章 关注点、原则和决定 68

8.1 专注于问题的关注点 70

8.1.1 业务策略 70

8.1.2 业务目标和驱动力 70

8.1.3 系统范围和需求 71

8.1.4 业务标准和政策 72

8.2 专注于解决方案的关注点 72

8.2.1 IT策略 72

8.2.2 技术目标和驱动力 72

8.2.3 技术标准和政策 73

8.3 其他现实世界中的约束 73

8.4 什么决定了好的关注点 75

8.5 架构原则 75

8.5.1 什么造就了好的原则 78

8.5.2 定义自己的原则 78

8.6 架构决定 79

8.7 使用原则关联关注点和决定 81

8.8 检查列表 82

8.9 小结 83

8.10 延伸阅读 83

第9章 确定并引入利益相关者 84

9.1 利益相关者的选择 84

9.2 利益相关者的类别 85

9.2.1 出资方 86

9.2.2 评估者 86

9.2.3 沟通者 86

9.2.4 开发人员 87

9.2.5 维护人员 87

9.2.6 生产工程师 87

9.2.7 供应商 87

9.2.8 支持人员 87

9.2.9 系统管理员 88

9.2.10 测试人员 88

9.2.11 用户 88

9.3 示例 88

9.3.1 非专门设计的部署项目 88

9.3.2 软件产品开发项目 89

9.3.3 合作开发 89

9.4 代理利益相关者 90

9.5 利益相关者组 90

9.6 利益相关者的责任 90

9.7 检查列表 91

9.8 小结 91

9.9 延伸阅读 92

第10章 识别并使用场景 93

10.1 场景类型 93

10.2 使用场景 94

10.3 识别场景并排定优先级 95

10.4 捕获场景 96

10.5 什么造就了好场景 98

10.6 应用场景 98

10.6.1 纸质模型 98

10.6.2 走查 99

10.6.3 模拟 100

10.6.4 原型实现的测试 100

10.6.5 完整规模真实测试 100

10.7 有效使用场景 100

10.7.1 识别一系列重点场景 101

10.7.2 使用清晰的场景 101

10.7.3 尽早使用场景 101

10.7.4 包含对系统质量场景的使用 101

10.7.5 包含对故障场景的使用 101

10.7.6 让利益相关者紧密参与 101

10.8 检查列表 102

10.9 小结 102

10.10 延伸阅读 103

第11章 使用样式和模式 104

11.1 设计模式介绍 104

11.2 样式、模式和惯用法 105

11.2.1 架构样式 106

11.2.2 软件设计模式 106

11.2.3 语言惯用法 106

11.2.4 使用样式、模式和惯用法 107

11.3 模式和架构策略 107

11.4 架构样式的例子 108

11.5 使用架构样式的好处 110

11.6 样式和架构描述 111

11.7 应用设计模式和语言惯用法 111

11.8 检查列表 113

11.9 小结 113

11.10 延伸阅读 113

第12章 创建架构模型 115

12.1 模型为什么重要 115

12.2 模型的类型 117

12.2.1 定性模型 117

12.2.2 定量模型 118

12.2.3 示意图 119

12.3 建模语言 119

12.3.1 架构描述语言 119

12.3.2 统一建模语言 120

12.3.3 可执行的领域专用语言 121

12.3.4 其他建模语言 121

12.4 创建有效模型的准则 121

12.4.1 有目的地建模 121

12.4.2 应对受众 122

12.4.3 仔细、准确地抽象 122

12.4.4 根据风险确定工作重点 123

12.4.5 选择描述性的名称 123

12.4.6 定义你的术语 123

12.4.7 以简单为目标 124

12.4.8 使用已定义的标记法 124

12.4.9 了解暗示的语义 124

12.4.10 验证模型 125

12.4.11 保持模型的活力 125

12.5 和敏捷团队一起建模 125

12.6 检查列表 126

12.7 小结 127

12.8 延伸阅读 127

第13章 创建架构描述 128

13.1 有效架构描述的属性 129

13.1.1 正确 129

13.1.2 充分 129

13.1.3 及时 130

13.1.4 简洁 131

13.1.5 清晰 131

13.1.6 最新 132

13.1.7 精确 133

13.2 词汇表 134

13.3 ISO标准 134

13.4 架构描述的内容 135

13.4.1 文档控制 135

13.4.2 内容表 135

13.4.3 介绍和管理纲要 135

13.4.4 利益相关者 136

1 3.4.5 通用架构原则 136

13.4.6 架构设计决定 136

13.4.7 视点 136

13.4.8 视图 136

13.4.9 质量属性摘要 137

13.4.10 重要的方案 137

13.4.11 亟待解决的问题 137

13.4.12 附录 138

1 3.5 展现架构描述 138

13.6 检查列表 139

13.7 小结 140

13.8 延伸阅读 140

第14章 评估架构 141

14.1 为什么要评估架构 141

14.2 评估技术 142

14.2.1 演讲 142

14.2.2 正式评审和结构化的走查 143

14.2.3 通过使用场景来评估 144

14.2.4 原型和概念验证系统 145

14.2.5 骨架系统 146

14.3 基于场景的评估方法 146

14.3.1 以架构为中心的活动 147

14.3.2 以利益相关者为中心的活动 149

14.4 在软件生命周期内评估 150

14.5 验证现存系统的架构 151

14.6 记录评估结果 153

14.7 选择评估方法 154

14.8 检查列表 154

14.9 小结 155

14.10 延伸阅读 155

第三部分 视点类型 158

第15章 视点类型简介 158

第16章 情境视点 160

16.1 关注点 161

16.1.1 系统范围和责任 161

16.1.2 外部实体和服务以及所用数据的标识 161

16.1.3 外部实体的本质和特征 162

16.1.4 外部接口的标识和职责 162

16.1.5 外部接口的本质和特征 163

16.1.6 其他外部依赖关系 163

16.1.7 对系统环境的影响 164

16.1.8 总体完成度、一致性和连贯性 164

16.1.9 利益相关者的关注点 165

16.2 模型 165

16.2.1 情境模型 165

16.2.2 交互场景 169

16.3 问题和缺陷 169

16.3.1 遗漏或者错误的外部实体 169

16.3.2 遗漏隐藏的依赖关系 169

16.3.3 松散或不精确的接口描述 170

16.3.4 详细程度不合适 170

16.3.5 范围蔓延 170

16.3.6 隐藏或假设的情境和范围 171

16.3.7 过于复杂的交互 171

16.3.8 过度使用术语 171

16.4 检查列表 172

16.5 延伸阅读 172

第17章 功能视点 173

17.1 关注点 173

17.1.1 功能能力 173

17.1.2 外部接口 174

17.1.3 内部结构 174

17.1.4 功能设计哲学 174

17.1.5 利益相关者的关注点 175

17.2 模型 176

17.3 问题和缺陷 184

17.3.1 设计很差的接口 184

17.3.2 难以理解的职责 184

17.3.3 基础架构作为功能性元素 184

17.3.4 过载的视图 185

17.3.5 没有元素定义的图 186

17.3.6 难以调节多位利益相关者的需求 186

17.3.7 错误的详细程度 187

17.3.8 “神元素” 187

17.3.9 过多依赖关系 188

17.4 检查列表 188

17.5 延伸阅读 188

第18章 信息视点 190

18.1 关注点 191

18.1.1 信息结构和内容 191

18.1.2 信息目的和用途 191

18.1.3 信息所有权 192

18.1.4 企业拥有的信息 193

18.1.5 标识符和映射关系 194

18.1.6 信息语义的易变性 195

18.1.7 信息存储模型 196

18.1.8 信息流 197

18.1.9 信息一致性 198

18.1.10 信息质量 199

18.1.11 及时性、延迟和寿命 200

18.1.12 归档和保留信息 201

18.1.13 利益相关者的关注点 201

18.2 模型 202

18.2.1 静态信息结构模型 202

18.2.2 信息流模型 204

18.2.3 信息生命周期模型 206

18.2.4 其他类型的信息模型 207

18.3 问题和陷阱 209

18.3.1 数据展现不兼容 209

18.3.2 不可避免的多个更新器 210

18.3.3 键值匹配缺陷 211

18.3.4 接口复杂 211

18.3.5 过载的中心数据库 212

18.3.6 不一致的分布式数据库 213

18.3.7 信息质量很差 213

18.3.8 信息延迟过大 213

18.3.9 容量不足 214

18.4 检查列表 214

18.5 延伸阅读 215

第19章 并发视点 216

19.1 关注点 217

19.1.1 任务结构 217

19.1.2 功能元素与任务的映射关系 218

19.1.3 进程间通信 218

19.1.4 状态管理 218

19.1.5 同步和整合 218

19.1.6 支持可伸缩性 219

19.1.7 启动和关闭 219

19.1.8 任务故障 219

19.1.9 重入 219

19.1.10 利益相关者的关注点 220

19.2 模型 220

19.2.1 系统级别的并发模型 220

19.2.2 状态模型 225

19.3 问题和缺陷 228

19.3.1 对错误的并发建模 228

19.3.2 错误地对并发建模 228

19.3.3 过度复杂 229

19.3.4 资源竞争 229

19.3.5 死锁 230

19.3.6 竞争条件 230

19.4 检查列表 230

19.5 延伸阅读 231

第20章 开发视点 232

20.1 关注点 232

20.1.1 模块组织 232

20.1.2 通用处理 233

20.1.3 设计的标准化 233

20.1.4 测试的标准化 233

20.1.5 测试辅助 233

20.1.6 代码行组织 233

20.1.7 利益相关者的关注点 233

20.2 模型 234

20.2.1 模块结构模型 234

20.2.2 通用设计模型 235

20.2.3 代码行模型 238

20.3 问题和缺陷 239

20.3.1 过多细节 239

20.3.2 过载的架构描述 239

20.3.3 不平均的重点 240

20.3.4 缺少开发者的关注 240

20.3.5 精度不足 240

20.3.6 特定环境的问题 240

20.4 检查列表 241

20.5 延伸阅读 241

第21章 部署视点 243

21.1 关注点 243

21.1.1 所需的运行时平台 243

21.1.2 硬件或者托管平台所需的规格和品质 244

21.1.3 第三方软件需求 244

21.1.4 技术兼容性 244

21.1.5 网络需求 245

21.1.6 所需的网络能力 245

21.1.7 物理约束 245

21.1.8 利益相关者的关注点 245

21.2 模型 246

21.2.1 运行时平台模型 246

21.2.2 网络模型 249

21.2.3 技术依赖关系模型 250

21.2.4 模型之间的关系 251

21.3 问题和缺陷 252

21.3.1 不清晰或者不精确的依赖关系 252

21.3.2 未经验证的技术 253

21.3.3 不合适或者遗漏的服务级别协议 253

21.3.4 缺少专家的技术知识 253

21.3.5 未能及时考虑部署环境 254

21.3.6 忽略站点间的复杂性 254

21.3.7 提供的净空不合适 254

21.3.8 未指定灾难恢复环境 255

21.4 检查列表 255

21.5 延伸阅读 256

第22章 运维视点 257

22.1 关注点 257

22.1.1 安装和升级 257

22.1.2 功能迁移 258

22.1.3 数据迁移 258

22.1.4 运维监控和控制 259

22.1.5 警告 260

22.1.6 配置管理 260

22.1.7 性能监控 260

22.1.8 支持 261

22.1.9 备份和还原 261

22.1.10 第三方环境中的运维 262

22.1.11 利益相关者的关注点 262

22.2 模型 263

22.2.1 安装模型 263

22.2.2 迁移模型 265

22.2.3 配置管理模型 265

22.2.4 管理模型 267

22.2.5 支持模型 270

22.3 问题和缺陷 273

22.3.1 缺少运维人员的参与 273

22.3.2 缺少撤销计划 273

22.3.3 缺少迁移计划 273

22.3.4 不充分的迁移窗口 274

22.3.5 遗漏管理工具 274

22.3.6 生产环境的约束 274

22.3.7 缺少到生产环境中的整合 275

22.3.8 不充分的备份模型 275

22.3.9 不合适的警告 275

22.4 检查列表 276

22.5 延伸阅读 276

第23章 保持视图一致性 277

23.1 视图之间的关系 277

23.2 情境和功能视图的一致性 278

23.3 情境和信息视图的一致性 278

23.4 情境和部署视图的一致性 279

23.5 功能和信息视图的一致性 279

23.6 功能和并发视图的一致性 279

23.7 功能和开发视图的一致性 280

23.8 功能和部署视图的一致性 280

23.9 功能和运维视图的一致性 280

23.10 信息和并发视图的一致性 281

23.11 信息和开发视图的一致性 281

23.12 信息和部署视图的一致性 281

23.13 信息和运维视图的一致性 281

23.14 并发和开发视图的一致性 282

23.15 并发和部署视图的一致性 282

23.16 部署和运维视图的一致性 282

第四部分 视角 284

第24章 视角类型简介 284

第25章 安全性视角 286

25.1 对视图的适用性 287

25.2 关注点 287

25.2.1 资源 287

25.2.2 当事人 287

25.2.3 策略 287

25.2.4 威胁 288

25.2.5 机密性 288

25.2.6 完整性 288

25.2.7 可用性 288

25.2.8 可说明性 289

25.2.9 检测和恢复 289

25.2.10 安全机制 289

25.3 活动：应用安全视角 290

25.3.1 确定敏感资源 290

25.3.2 定义安全性策略 291

25.3.3 识别对系统的威胁 293

25.3.4 设计安全性实现 294

25.3.5 评估安全风险 296

25.4 架构策略 296

25.4.1 应用识别出的安全性原则 296

25.4.2 对用户进行身份验证 298

25.4.3 授权访问 298

25.4.4 确保信息保密性 299

25.4.5 确保信息的完整性 299

25.4.6 确保可负责性 300

25.4.7 保护可用性 300

25.4.8 整合安全性技术 301

25.4.9 提供安全性管理 301

25.4.10 使用第三方的安全性基础架构 301

25.5 问题和缺陷 302

25.5.1 复杂的安全性策略 302

25.5.2 未经验证的安全性技术 302

25.5.3 没有针对故障设计系统 302

25.5.4 缺少管理工具 303

25.5.5 技术驱动的方法 303

25.5.6 没有考虑时间源 303

25.5.7 过度依赖于技术 304

25.5.8 没有清晰的需求或模型 304

25.5.9 把安全性作为事后的想法 305

25.5.10 忽略内部人员的威胁 305

25.5.11 假设客户端是安全的 305

25.5.12 嵌入在应用程序代码中的安全性 306

25.5.13 零碎的安全性 306

25.5.14 临时的安全技术 306

25.6 检查列表 307

25.6.1 获取需求的检查列表 307

25.6.2 架构定义的检查列表 307

25.7 延伸阅读 308

第26章 性能和可伸缩性视角 309

26.1 对视图的适用性 310

26.2 关注点 310

26.2.1 响应时间 310

26.2.2 吞吐量 311

26.2.3 可伸缩性 312

26.2.4 可预测性 312

26.2.5 硬件资源需求 312

26.2.6 峰值负载行为 312

26.3 活动：应用性能和可伸缩性视角 313

26.3.1 获取性能需求 314

26.3.2 创建性能模型 314

26.3.3 分析性能模型 316

26.3.4 执行实际的测试 317

26.3.5 根据需求评估 317

26.3.6 重做架构 318

26.4 架构策略 318

26.4.1 优化重复的处理 318

26.4.2 通过复制减少竞争 319

26.4.3 对处理按优先级排序 320

26.4.4 合并相关的工作 321

26.4.5 随时间分发处理 321

26.4.6 最小化对共享资源的使用 321

26.4.7 重用资源和结果 322

26.4.8 分解和并行化 322

26.4.9 增强或扩展 323

26.4.10 舒缓降级 324

26.4.11 使用异步处理 324

26.4.12 放松事务的一致性 324

26.4.13 做出设计折中 325

26.5 问题和缺陷 325

26.5.1 不精确的性能和可伸缩性目标 325

26.5.2 不实际的模型 326

26.5.3 对复杂情况使用简单的度量 326

26.5.4 不合适的分区 326

26.5.5 无效的环境和平台假设 327

26.5.6 太多间接层 327

26.5.7 与并发相关的竞争 327

26.5.8 数据库竞争 328

26.5.9 事务过载 328

26.5.10 粗心地分配资源 329

26.5.11 忽视网络和进程中调用的区别 329

26.6 检查列表 330

26.6.1 针对获取需求的检查列表 330

26.6.2 针对架构定义的检查列表 330

26.7 延伸阅读 330

第27章 可用性和弹性视角 332

27.1 对视图的适用性 332

27.2 关注点 332

27.2.1 服务的类型 333

27.2.2 有计划的停机时间 333

27.2.3 未经计划的停机时间 334

27.2.4 维修时间 334

27.2.5 灾难恢复 334

27.3 活动：应用可用性和弹性视角 335

27.3.1 捕获可用性需求 335

27.3.2 创建可用性日程表 336

27.3.3 评估平台的可用性 337

27.3.4 评估功能可用性 339

27.3.5 根据需求进行评估 340

27.3.6 应用策略以重做架构 341

27.4 架构策略 342

27.4.1 选择容错硬件 342

27.4.2 使用高可用性集群和负载均衡 342

27.4.3 日志事务 343

27.4.4 应用软件可用性解决方案 344

27.4.5 选择或创建容错软件 344

27.4.6 设计故障 345

27.4.7 考虑组件复制 345

27.4.8 放松事务一致性 345

27.4.9 确定备份和灾难恢复解决方案 346

27.5 问题和缺陷 346

27.5.1 故障单点 346

27.5.2 级联故障 347

27.5.3 由于过载造成的不可用 348

27.5.4 过分激进的可用性需求 348

27.5.5 无效的错误侦测 349

27.5.6 对组件弹性的过度估计 349

27.5.7 忽略全球可用性需求 350

27.5.8 不兼容的技术 350

27.6 检查列表 351

27.6.1 针对需求获取的检查列表 351

27.6.2 针对架构定义的检查列表 351

27.7 延伸阅读 352

第28章 演进视角 353

28.1 对视图的适用性 354

28.2 关注点 354

28.2.1 产品管理 354

28.2.2 变化的量级 354

28.2.3 变化的维度 355

28.2.4 变化的可能性 355

28.2.5 变化的时间跨度 355

28.2.6 何时为变化支付 355

28.2.7 由外部因素驱动的变更 356

28.2.8 开发复杂度 356

28.2.9 知识的保存 356

28.2.10 变更的可靠性 357

28.3 活动：应用演进视角 357

28.3.1 描绘演进需求的特征 357

28.3.2 评估当前演进的难易程度 358

28.3.3 考虑演进的取合 359

28.3.4 重做架构 359

28.4 架构策略 359

28.4.1 包含变更 359

28.4.2 创建可扩展的接口 360

28.4.3 应用促进变更的设计技术 361

28.4.4 应用基于元模型的架构样式 361

28.4.5 把变化点构建到软件中 362

28.4.6 使用标准的扩展点 362

28.4.7 达到可靠地变更 363

28.4.8 保存开发环境 364

28.5 问题和缺陷 364

28.5.1 对错误的维度按优先级排序 364

28.5.2 永远不会发生的变更 364

28.5.3 演进对重要质量属性的影响 365

28.5.4 过度依赖特定的硬件或软件 365

28.5.5 丢失开发环境 366

28.5.6 临时的发布管理 366

28.6 检查列表 367

28.6.1 对于需求获取的检查列表 367

28.6.2 对于架构设计的检查列表 367

28.7 延伸阅读 367

第29章 其他视角 369

29.1 可访问性视角 370

29.1.1 对视图的适用性 370

29.1.2 关注点 371

29.1.3 活动：应用可访问性视角 371

29.1.4 架构策略 371

29.1.5 问题和缺陷 372

29.1.6 检查列表 372

29.1.7 延伸阅读 373

29.2 开发资源视角 373

29.2.1 对视图的适用性 374

29.2.2 关注点 374

29.2.3 活动：应用开发资源视角 375

29.2.4 架构策略 375

29.2.5 问题和缺陷 376

29.2.6 检查列表 376

29.2.7 延伸阅读 377

29.3 国际化视角 377

29.3.1 对视图的适用性 377

29.3.2 关注点 378

29.3.3 活动：应用国际化视角 379

29.3.4 架构策略 379

29.3.5 问题和缺陷 379

29.3.6 检查列表 380

29.3.7 延伸阅读 380

29.4 位置视角 380

29.4.1 对视图的适用性 381

29.4.2 关注点 381

29.4.3 活动：应用位置视角 382

29.4.4 架构策略 382

29.4.5 问题和缺陷 383

29.4.6 检查列表 383

29.4.7 延伸阅读 384

29.5 法规视角 384

29.5.1 对视图的适用性 384

29.5.2 关注点 385

29.5.3 活动：应用法规视角 386

29.5.4 架构策略 386

29.5.5 问题和缺陷 386

29.5.6 检查列表 386

29.5.7 延伸阅读 387

29.6 易用性视角 387

29.6.1 对视图的适用性 387

29.6.2 关注点 388

29.6.3 活动：应用易用性视角 389

29.6.4 架构策略 389

29.6.5 问题和缺陷 389

29.6.6 检查列表 390

29.6.7 延伸阅读 390

第五部分 把所有内容组合起来第30章 作为软件架构师工作 392

30.1 项目生命周期中的架构 392

30.1.1 小型和低风险项目中的架构 392

30.1.2 敏捷项目中的架构 393

30.1.3 计划驱动项目中的架构 395

30.1.4 大型项目中的架构 396

30.2 支持不同类型的项目 398

30.2.1 内部系统开发 398

30.2.2 新产品开发 399

30.2.3 企业服务 399

30.2.4 对已经存在系统的扩展 400

30.2.5 程序包实现 400

30.2.6 Internet支持程序 401

30.2.7 退役 401

附录A 其他视点集 402

参考文献 408