软件系统架构使用视点和视角与利益相关者合作 有更新!

  Bob

基本信息

  • 原书名:Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives (2nd Edition)
  • 原出版社: Addison-Wesley Professional
  • 作者: (英)Nick Rozanski    Eoin Woods   
  • 译者: 侯伯薇
  • 丛书名: 华章程序员书库
  • 出版社:机械工业出版社
  • ISBN:9787111421863
  • 上架时间:2013-5-8
  • 出版日期:2013 年5月
  • 开本:16开
  • 页码:418
  • 版次:1-1
  • 所属分类:
    计算机 > 软件工程及软件方法学 > 综合
     

编辑推荐

软件架构领域开创性著作,资深软件架构师数十年工作经验结晶,具有里程碑意义
深刻阐述如何用架构视点和架构视图的方法定义软件架构,如何用架构视角的方法确保软件质量,以及如何用架构视点和架构视角的方法与利益相关者合作

内容简介

    书籍
    计算机书籍
《软件系统架构:使用视点和视角与利益相关者合作(原书第2版)》是软件系统架构领域的开创性著作,是两位拥有数十年软件行业工作经验的架构师工作经验的结晶,围绕利益相关者、视点和视角三大主题,创新性地提出了如何用架构视点和架构视图的方法来定义软件架构,如何用架构视角的方法来确保软件质量,以及如何用架构视点和架构视角的方法与利益相关者合作,具有里程碑意义。本书还展示了一种实用的、经过验证的框架,你可以应用它来处理架构定义过程,并应对创建软件架构工作所带来的挑战。
《软件系统架构:使用视点和视角与利益相关者合作(原书第2版)》分为五个部分,共30 章。第一部分(第1~5 章)阐释利益相关者、架构描述、视点、视图和视角等基本概念,并描述软件架构师的角色;第二部分(第6~14 章)描述作为架构师所要从事的重要活动,如协商项目的范围、识别并管理利益相关者、使用场景和模式、创建模型以及为架构创建文档并对其加以验证等;第三部分(第15~23 章)集合了在创建架构描述时最重要的七种视点:情境、功能、信息、并发、开发、部署和运维视点;第四部分(第24~29 章)集合了对于信息系统最重要的视角,包括安全性、性能和可伸缩性、可用性和适应性、演进、位置、开发资源、国际化等;第五部分(第30 章)把这些概念融合在一起,并阐释了如何把这些理论应用到实践中。 

作译者

Nick Rozansh,资深软件架构师,拥有30余年软件行业工作经验。他在企业应用程序集成、程序包实现、关系型数据库、数据复制和面向对象的软件开发等领域有自己独到的见解,积累颇丰。他在包括金融、零售、制造和行政等多个领域担任重要的角色,曾任职于多家大型系统集成公司,包括Logica、Capgemini和Sybase,以及玛莎百货和Barclays全球投资公司,目前是英国一家大型银行前端IT部门的主要负责人。他曾在剑桥大学和曼彻斯特大学求学,是英国计算机学会的注册工程师和注册会员。他还是一位经验丰富的技术讲师和通过认证的内部项目审计员。 
Eoin Woods,资深软件架构师,拥有近20年软件行业工作经验。他对软件架构、分布式系统、计算机安全和数据管理等技术都有深入研究。曾在多家技术公司、顾问公司和金融服务公司任职,目前是欧洲一家大型投资银行的首席软件架构师,负责该公司大量关键系统的架构和设计。他拥有布鲁塞尔大学软件工程学士学位和曼彻斯特大学软件工程硕士学位。他还是工程技术协会的注册会员,并且是英国计算机学会的注册工程师和注册会员。 
侯伯薇,资深软件开发工程师、系统工程师和系统分析师,拥有10余年软件行业从业经验。现就职于中荷人寿保险有限公司,担任高级系统分析师。致力于技术与业务的融合,让开发的程序能够真正提高业务人员的工作效率。InfoQ中文站翻译团队主编,热衷于通过翻译和演讲的方式与广大程序员分享和交流,曾翻译过多本技术书籍和几百篇技术短文,并多次在Scrumgathering、QClub、敏捷之旅等活动上发表技术演讲。 

目录

《软件系统架构:使用视点和视角与利益相关者合作(原书第2版)》 
译者序 
前言 
第1版前言 
第1章 简介 1 
1.1 利益相关者、视点和视角 1 
1.2 本书结构 4 
1.3 谁应该阅读本书 5 
1.4 本书约定 5 
第一部分 架构的基本原则 
第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 
第二部分 软件架构过程 
第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 
13.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 
13.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 
第三部分 视点类型 
第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 信息和并发视图的一致性 
23.11 信息和开发视图的一致性 
23.12 信息和部署视图的一致性 
23.13 信息和运维视图的一致性 
23.14 并发和开发视图的一致性 
23.15 并发和部署视图的一致性 
23.16 部署和运维视图的一致性 
第四部分 视角 
第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 
 

译者序

  作为一名程序员,对未来的职业规划会有很多种。有人想要走管理路线,基本目标是成为项目主管或者项目经理;有人对数据库感兴趣,期望成为DBA;有人对测试感兴趣,期望成为测试方面的专家或者质量保证方面的高手;还有很多人希望做架构师,能够从总体上把握一个系统或者一个组织中的所有系统。 
  和其他角色相比,在一个系统的设计和开发过程中,架构师的地位显得尤为重要,颇有“运筹帷幄之中,决胜于千里之外”的架势。但是,很多时候,在很多组织中,架构师只不过是一个职位的概念,很多人即便在拥有这个头衔之后,还是会有很多的疑问亟待解答,比如: 
  架构师需要哪些能力? 
  架构师需要从事哪些工作? 
  想要设计出良好的架构,需要考虑哪些问题? 
  如何与系统的各种利益相关者相互协调?他们的关注点一般又会有哪些? 
  如何编写出能够让相关人员都很好了解的架构文档? 
  如何评估设计出的架构? 
  在解决某些特定系统问题时,应该采用何种合适的方法? 
  很少有一本书能够系统地回答这么多问题,能够为迷茫的架构师做出有效的指导。我自己也是一样,作为一名程序员,对架构方面还是如履薄冰,了解了一些皮毛,绝不敢以架构师来自居。 
  直到偶然与这样的一本书相遇,我才发现,其实想要成为架构师,或者在成为架构师之后,想要更好地完成相应的工作,这本书都能够提供很好的指导和帮助。其中提出的各种视图、视点和视角,可以帮助我们更好地了解架构的诸多方面,从而在设计架构的时候,能够根据最重要的利益相关者的关注点,更好地进行平衡。 
  也正因为如此,我才争取到这样的机会,把这么好的一本书翻译成中文,呈献给国内的程序员朋友们,希望他们能够通过阅读这本书,更好地了解架构设计和架构师这种职业,也更好地为他们解决架构方面的问题。 
  不得不说,翻译这样一本大部头的确是很辛苦的事情,这也是我所翻译的最厚的一本书,所以首先要感谢我的家人对我的理解和支持,让我抽出晚上和周末的时间来从事该书的翻译工作。还要感谢关敏老师,容忍我一再延期交稿。还要感谢张勇等人的参与,正是大家的帮助,才让我最终完成了这本书的翻译。 
  愿这本书能够帮助更多有志成为架构师或者已经是架构师的朋友们! 
  

前言

  和十年前我们开始撰写本书第1 版时相比,当前IT 业界的状况已经发生了天翻地覆的变化。计算机和互联网已经成为很多人日常工作和生活的重要组成部分,这使得整个世界更紧密地连接在一起。同时,这也让用户和其他利益相关者对系统寄予更大的期望,他们希望系统功能完备、易于使用、健壮稳定、方便扩展且安全可靠。我们认为,在实现这些目标的过程中,架构师扮演了非常重要的角色,而且广大专业的软件开发者以及高级业务和技术经理也深以为然。 
  我们非常高兴地看到,本书第1 版得到了软件从业者、有抱负的软件架构师以及学术界的认可。读者认为它有用、可理解且内容丰富。然而,架构是一种不断变化的规则,因此本书第2 版会反映出从第1 版的出版到现在我们在实践中所学到和已经做出的改善。它还包括了读者发来的大量非常有用的评论和改进建议,对此我们深表感谢。 
  然而,本书的基础内容保持不变。本书的首要关注点依然在于:架构是为利益相关者提供的服务,并且是确保信息系统能够满足他们需求的一种方式。本书还是会强调视图(view)的极端重要性,它会以利益相关者可以理解的方式来显示架构的复杂性。我们还坚持认为,架构必须定义系统能如何提供利益相关者所要求达到的质量属性—如可扩展性、弹性和安全性—还要定义静态和动态结构,以及能够提供有效方式达到这些目的的透视图。 
  本书的主要受众是架构师或者期望成为架构师的人,但是,我们希望其他可能会和架构师一起工作的IT 专业人士、某天可能会成为架构师的学生,都认为这本书值得一读。 
  第2 版中做出的最重要改变如下。 
  本书引入了一种叫做情境的新视角(Context viewpoint),它会描述系统及其所处环境(人、系统以及与之交互的外部实体)之间的关系、依赖和交互。这部分内容还会将第1 版第8 章中对范围和情境相对简要的讨论进行扩展、格式化和标准化。 
  第二部分进一步讨论了架构角色的不同方面。 
  修订了大多视角和透视图的定义,特别是功能(Functional)和并发(Concurrency)视图以及性能(Performance)和可扩展性(Scalability)透视图。 
  修订和扩展了大多数章节的参考文献和延伸阅读部分。 
  更新了第1 版中的部分内容,使其可以与新的国际架构标准ISO 42010(它继承自IEEE 标准1471)中的概念和术语保持一致。 
  更新了UML 建模的建议和示例,从而适应UML 在第2 版中所引入的变更。 
  我们希望你能够发现,本书第2 版对第1 版做出了很有用的提升和扩展,我们也邀请你访问本书的网站:www.viewpoints-and-perspectives.info,在那里你可以获得更多软件架构的资源,或者可以与我们联系,提供对本书的反馈。 
  致谢 
  除了在第1 版中感谢的人,我们还要感谢审阅了本书第2 版的各位朋友:Paul Clements 、Tim Cull 、Rich Hilliard 、Philippe Kruchten 和Tommi Mikkonen,还有勤勉负责的文字编辑Barbara Wood 。特别要感谢Paul 彻底、具有洞察力和挑战性的意见与改进建议,这些对我们帮助很大。 
  第1版前言 
  本书的两位作者都是实践经验丰富的软件架构师,在信息系统开发项目中担当这个角色多年,在有些项目中是共同担任架构师,在有些项目中是分别担任的。在那期间内,我们看到软件架构师的数量得到了显著增加,而且该角色的重要性也得到同事、管理层和客户的认可。现在,所有大型的软件开发项目都需要架构师的参与,甚至在先进的开发团队中,会存在架构师小组。 
  尽管人们已经达成共识,认为软件架构师的角色非常重要,但是关于这一角色所包含的工作并没有一致的意见。谁是我们的客户?我们应该对谁负责?他们期望我们交付什么?一旦架构设计完成,我们又该做些什么?以及可能最重要的是,需求、架构和设计之间的边界是什么? 
  因为当前软件项目(特别是项目的架构师)中有很多亟待解决的问题,所以缺少对架构师角色的清晰定义,这导致了更多问题。 
  用户和其他利益相关者在功能、容量、推向市场的时间以及灵活性方面提出了更多苛求。 
  漫长的系统开发时间导致范围持续改变,进而导致系统架构和设计经常变更。 
 

书摘

  第 1 章 
  简介 
  当今的大规模软件系统是人类有史以来构建的最复杂的结构之一,其中包含上百万行代码、成千上万的数据库表以及成百上千的组件,所有这一切都运行在几十甚至上百台计算机中。这对软件开发团队提出了十分严峻的挑战,如果不及早处理其中的问题,那么系统就会延迟交付,超出预算,或者质量极差让人无法接受。 
  当前大多数项目都意识到拥有软件架构师的重要性,或者在某些项目中会成立软件架构师小组,由他们指导和引领团队的其他成员。然而,IT业界对于软件架构师应该做什么,应该怎样做以及他们应该交付什么样的成果,都没有普遍可接受的定义。 
  1.1利益相关者、视点和视角 
  本书的目的是为软件架构师—不管是有经验的架构师还是处于初级阶段的架构师—提供实践指导。本书的重点在于三个基本概念:利益相关者(stakeholder)、视点(viewpoint)和视角(perspective)。为了阐释这三个概念的重要性,让我们看看下面的例子,了解软件架构的实践是什么样的。 
  示例萨莉是一家大型商业机构的软件架构师。作为IT雇员中最重要的成员之一,萨莉需要参与到多种不同的活动中,但是,她主要的职责是引领组织中信息系统的定义和设计工作。最近,她在一个系统中花费了大量时间和精力。 
  刚开始时事情很简单:机构要求萨莉对一项方案进行检查,该方案会用更先进的系统来替换当前的库存管理系统(该系统基于批处理,已经非常陈旧),新系统能够更好地支持业务经常变化的需求。业务部门特别要求,系统要更具交互性,让员工可以实时地转移货物,而不是输入数据之后,直到第二天才能够看到结果。当前系统造成的时间延迟是一个非常大的问题,并且由于缺少即时的反馈而导致出现很多错误。 
  乍一看,问题似乎并不复杂。萨莉与机构中的几个人讨论了新系统的需求,之后不久,她就有了主意,知道该如何开始了。她和业务分析师以及总部的一些主要用户面谈,从而获得了一些关键需求。这看起来非常简单。然后萨莉就开始筹划可行的解决方案。 
  然而,当在全公司范围内讨论她的想法时,萨莉遇到了一些人,他们在系统关键需求方面的想法完全不同。分发仓库中用户的需求与总部员工所需要的信息完全不同。而总部的商务经理又说,在一天中随时都能够看到实时的摘要汇报非常重要。但是,这会大大减慢主要的事务流程,而物流组的成员无法接受这一点,并且他们正是为系统埋单的人。 
  萨莉还和前线业务领域之外的人面谈,他们也有自己的意见。IT运维组的成员对采用新技术表示担心,认为他们无法管理萨莉计划使用的应用程序服务器。IT审计员通知她,他们需要两年内所有货物发放授权的存档,以防可能出现的欺诈。暂且不说收集这些信息的难度,在系统中所保存的库存移动数据就已经很多了。 
  萨莉尽量调节她所会过面的人们提出的各种相互冲突的需求。她还担心遗漏了重要人员,或者没能找对关键的需求。 
  上述示例中的架构师需要和大量不同人员协作,每种人对新系统都有不同的兴趣和关注点。传统情况下,软件开发者只关注最终用户的需求,有时也会关注开发者的需求,但是正如示例中所显示的,如果你想要创建能够满足它所影响的所有人的系统,这种视点就太过狭窄了。 
  我们把系统所影响的人称为利益相关者。由于利益相关者的需求是系统最初创建的原因,因此满足这些需求就是你作为架构师的主要目标。为了做到这一点,你需要清晰地识别出利益相关者,与他们协作以了解他们关注的问题,平衡他们必然会出现冲突的优先级顺序,并且设计出尽可能有效地满足他们的需求的架构。 
  贯穿本书我们一直都会提到利益相关者。我们会在第一部分研究这个概念,在第二部分说明如何有效地和他们协作,并且在第三和第四部分向你展示如何创建架构来满足他们的需求。接下来让我们继续看例子。 
  萨莉做了不少工作来理解她的利益相关者,并让他们参与进来,尽管她觉得可能无法满足他们所有的需求,但至少现在她觉得已经很好地理解了他们所关注的问题。 
  基于她对重要的利益相关者需求的理解,萨莉开始认真地设计架构。她先设计出系统功能结构的草稿,确定关键的组件,并设计让它们协同工作以提供所需要的功能。当她考虑这些问题的时候,还开始按照过程对组件进行分组,并设计出这些过程会在数据中心的什么位置运行。为了满足运维组的需求,萨莉还在她的设计中增加了一些系统管理组件,这会使系统更便于管理。她意识到需要考虑系统中的数据,因此创建了主数据库,并对关键组件之间的数据流做了注解。这些工作暂时转移了她的注意力,因为它们非常复杂,但是在几个星期过后,萨莉就设计出可以展示给大家的详细架构模型。 
  她把文档发送给大家,但是对于他们所做出的回应,萨莉非常不满意。大多数人根本就没有回复,而回复的人似乎更关心系统的细枝末节,甚至是她的文档格式。萨莉直接找到一些审查了文档的最终用户、开发者以及IT运维人员,希望通过交流找到他们无法提供更好反馈的原因。 
  与利益相关者的谈话让她很泄气,似乎没有人抓住模型的重点所在。开发者分心去考虑运维组件,例如服务器和磁盘阵列,他们为应用程序部署到数据中心上的方式而担心,但那并不是他们的主要责任。IT运维人员很高兴在模型中看到了他们的系统管理软件,但是他们一直询问关于数据库和数据流的问题,在萨莉看来,那很显然不应该是他们所应该关心的。最终用户没有真正理解任何东西,却一直在问:“但是它会做什么呢?”萨莉觉得这实在是太不公平了,因为她耗费了那么大的精力来确保系统所能做的一切都体现在文档中了。 
  尽管萨莉创建了详细的架构设计,但似乎她没有让任何人理解她的系统。她不知道应该如何重新组织文档,才能够更清晰地传达她所要表达的信息。 
.  萨莉面临的问题与很多架构师类似:如何向不同的人描述像架构这样复杂、包含多方面内容的系统,并让他们理解?事实上,从计算机科学的早期开始,这就是软件工程的问题之一。 
  如果你阅读了关于软件架构的最新文献,那么最有用的就是,你会看到架构视图(architectural view)的概念。架构视图是对系统架构的一个方面的描述,并且是对“分而治之”(divide and conquer)这种解决问题原则的应用。你可以通过多种独立的视图来考虑系统架构,从而以可选择的方式来理解、定义和沟通复杂的架构,避免你的读者被总体上的复杂性吓到。架构视图的示例包括系统的功能结构、信息组织以及部署环境等。 
  尽管使用视图来描述架构有助于对架构进行分块描述,并且让它易于理解,但是你还是要解决使用哪些视图,以及如何来创建它们的问题。在过去,很多架构师都需要面对这个问题。一种已经得到验证的解决方案是使用模板化的视图,叫做架构视点(architectural viewpoint),来指导创建描述架构的视图的过程。 
  使用视点和视图来指导定义架构的过程,是本书的核心主题。我们会在第一部分对其进行介绍和说明,并把它们放在相关的情境中,而第三部分中包含了一系列完整的视点定义,你可以直接在自己的架构项目中使用。现在,让我们看一下萨莉是如何在我们的示例中使用视点的。 
  萨莉决定使用一系列视点来创建基于视图的架构描述。因为工作的完成期限已经快到了,所以她把注意力放在了系统功能、重要的信息流以及部署环境上。这会有效地说明架构,而且能够满足大多数萨莉在与利益相关者的讨论过程中所表现出来的需求。她的想法得到了验证,从而系统的第一个版本的开发工作也随之开始。软件开发进展得很顺利,但是又出现了新的麻烦。 
  在查看了集成测试日志,并与一些系统测试人员交谈之后,萨莉开始担心系统的性能。她在早期没有过多地考虑性能,因为似乎没有人对此表示关心,但是,即便是在测试数据的规模,她看到的性能也非常差。 
  同时,一些安全和审计组的成员开始对系统的安全性表示担心。当萨莉搜集需求的时候,他们还没有提到这一点,但是现在系统已经开始成型了,他们开始讨论要保证不同的用户只能看到系统的部分功能,并且要求他们确保,系统的数据库不会在未经授权的情况下被维护人员更改。这更麻烦,尽管萨莉对解决性能问题还有些自信,而对于安全性则很不确定。 
  最后,公司的业务持续性小组发送了一封严格要求的邮件,要求所有系统都能够在发生重大故障的8小时之内从物理上的远程恢复站点恢复。但萨莉之前并不知道这个与IT一起工作的小组。她通常处理的大型计算机上的应用程序会自动从主机环境继承灾难恢复的工具,因此之前她根本不需要担心这个问题。 
  尽管看起来系统能够提供人们所要求的功能,但是萨莉担心他们还是对系统不满意,因为它不够快、无法解决安全性问题,或者在发生重大系统故障的时候无法恢复。 
  意识到了这些问题之后,萨莉不确定应该如何做来解决。她了解性能和可用性,但是她不清楚如何提高系统的安全等级。尽管拥有很多技术知识,但是萨莉还是不知道如何重新设计系统,才能够平衡这些不同的关注点—这些在获取需求的时候谁都没有提到的关注点。 
  上述示例中的架构师已经意识到,系统能够做什么只是一部分,而系统如何提供服务通常会对利益相关者的感受产生很大的影响。你为系统选择的架构决定了它能以多快的速度运行、它的安全性有多高、它的可用性有多好、对其进行修改有多容易等很多其他非功能性的方面,对于上述问题,我们统称为质量属性(quality property)。作为架构师,设计出能够达到可接受的质量属性的系统是工作的重要组成部分。 
  实现质量目标是架构定义过程的跨结构内容(事实上,人们也认为质量属性是涉及多个方面的关注点),并且很可能会影响到组成架构的所有结构。这意味着达到质量目标可能会影响到架构描述中的所有视图。 
  我们发现,传统的视图和视点方法对于定义架构的结构非常有效,但是在考虑质量属性的时候却没有什么帮助。我们需要一种更好的方式,能够确保架构表现出所需要的质量属性,并且组织关于质量属性的架构知识。为了做到这一点,我们定义了一种新概念—架构视角(architectural perspective),它和视点类似,但它表示的并非是单一类型的架构结构,而是要表示特定的质量属性(像性能、安全性或可用性等)。 
  对视图应用视角可以确保它们表现出所需要的质量属性,这是本书的另一重要主题。本书第一部分概览了视角,而第四部分则包含了完整系列的视角定义,你可以在自己的架构项目中直接使用,从而避免示例中让架构师头疼的问题。 
  一言概之,本书的核心主题就是利益相关者、视点和视角。 
  利益相关者是我们为之创建系统的人。你作为架构师的重要工作就是要知道如何与利益相关者协作,从而创建能够满足他们复杂、重复并且经常冲突的需求。 
  视点(和视图)是确定架构定义过程和架构描述的结构的方法,它基于分离关注点的原则。视点包含了已经过验证的架构知识,以引导架构的创建过程,我们会以一系列特定视图的形式来描述它(每种视图都是在特定的视点下应用指引的结果)。 
  视角是我们在本书中引入的一种概念,它是视点的有效补充。视角包含已经过验证的架构知识,会分离关注点,关注跨结构的质量属性而不是架构结构,从而帮助我们确定架构定义过程的结构。 
  在本书中,我们会介绍、说明和探究这三个概念,并定义一种方法,为你的信息系统创建有效的架构。当然,我们在此所展示的方法是经过简化的。架构定义并不会一帆风顺、一挥而就的,在现实中它是一个渐进的过程,其中包含了迭代的循环过程,包括捕获信息、创建模型、复审和改进等过程。我们在此展现的是一种实用的、经过验证的框架,你可以应用它来处理架构定义过程,并应付创建软件架构这种迷人的工作所带来的挑战。 
  1.2本书结构 
  本书分为五个部分。 
  第一部分会对我们在本书中使用的概念进行介绍和回顾(例如:利益相关者、架构描述、视点、视图和视角),并描述软件架构师的角色。 
  第二部分会描述作为架构师所要从事的重要活动,例如商量确定项目的范围,识别并管理利益相关者,使用场景和模式,创建模型,以及为架构创建文档并对其加以验证等。 
  第三部分集合了最重要的七种视点,你在创建架构描述的时候会需要它们:情境(Context)、功能(Functional)、信息(Information)、并发(Concurrency)、开发(Development)、部署(Deployment)和运维(Operational)视点。 
  第四部分集合了对信息系统最重要的视角,包括安全性、性能和可伸缩性、可用性和弹性、演进、位置、开发资源、国际化等。 
  第五部分把这些概念融合在一起,并说明你应该如何把这些理论应用在实践中。 

软件系统架构使用视点和视角与利益相关者合作.pdf


[软件系统架构使用视点和视角与利益相关者合作.pdf]

本资料仅供个人学习参考,请勿用于商业用途,如有能力请尽量购买正版图书,也是对作者的支持。 如需下载加QQ群铂金信息技术交流群 151258054获取访问密码