恰如其分的软件架构

第1章 概述
1.1 分治、知识与抽象
1.2 软件架构的三个案例
1.3 反思
1.4 视角转换
1.5 架构师构建架构
1.6 风险驱动的软件架构
1.7 敏捷开发者的架构
1.8 关于本书

第2章 软件架构
2.1 何为软件架构？
2.2 软件架构为何重要
2.3 架构何时重要？
2.4 推定架构
2.5 如何运用软件架构？
2.6 架构无关的设计
2.7 专注架构的设计
2.8 提升架构的设计
2.9 大型组织中的架构
2.10 结论
2.11 延伸阅读

第3章 风险驱动模型
3.1 风险驱动模型是什么？
3.2 你现在采用风险驱动了吗？
3.3 风险
3.4 技术
3.5 选择技术的指导原则
3.6 何时停止
3.7 计划式设计与演进式设计
3.8 软件开发过程
3.9 理解过程变化
3.10 风险驱动模型与软件开发过程
3.11 应用于敏捷过程
3.12 风险与架构重构
3.13 风险驱动模型的替代方案
3.14 结论
3.15 延伸阅读

第4章 实例：家庭媒体播放器
4.1 团队沟通
4.2 COTS组件的集成
4.3 元数据一致性
4.4 结论

第5章 建模建议
5.1 专注于风险
5.2 理解你的架构
5.3 传播架构技能
5.4 作出合理的架构决策
5.5 避免预先大量设计
5.6 避免自顶向下设计
5.7 余下的挑战
5.8 特性和风险：一个故事

第6章 工程师使用模型
6.1 规模与复杂度需要抽象
6.2 抽象提供洞察力和解决手段
6.3 分析系统质量
6.4 模型忽略细节
6.5 模型能够增强推理
6.6 提问在前，建模在后
6.7 小结
6.8 延伸阅读

第7章 软件架构的概念模型
7.1 规范化模型结构
7.2 领域模型、设计模型和代码模型
7.3 指定与细化关系
7.4 主模型的视图
7.5 组织模型的其他方式
7.6 业务建模
7.7 UML的用法
7.8 小结
7.9 延伸阅读

第8章 领域模型
8.1 领域与架构的关系
8.2 信息模型
8.3 导航和不变量
8.4 快照
8.5 功能场景
8.6 小结
8.7 延伸阅读

第9章 设计模型
9.1 设计模型
9.2 边界模型
9.3 内部模型
9.4 质量属性
9.5 Yinzer系统的设计之旅
9.6 视图类型
9.7 动态架构模型
9.8 架构描述语言
9.9 小结
9.10 深入阅读


第10章 代码模型
10.1 模型-代码差异
10.2 一致性管理
10.3 架构明显的编码风格
10.4 在代码中表达设计意图
10.5 模型嵌入代码原理
10.6 表达什么
10.7 在代码中表达设计意图的模式
10.8 电子邮件处理系统预演
10.9 小结

第11章 封装和分割
11.1 多层级故事
11.2 层级和分割
11.3 分解策略
11.4 有效封装
11.5 创建封装接口
11.6 小结
11.7 深入阅读

第12章 模型元素
12.1 和部署相关的元素
12.2 组件
12.3 组件装配
12.4 连接器
12.5 设计决策
12.6 功能场景
12.7 (不变量(约束)
12.8 模块
12.9 端口
12.10 质量属性
12.11 质量属性场景
12.12 职责
12.13 权衡
12.14 小结

第13章 模型关系
13.1 投影(视图)关系
13.2 分割关系
13.3 组合关系
13.4 分类关系
13.5 泛化关系
13.6 指定关系
13.7 细化关系
13.8 绑定关系
13.9 依赖关系
13.10 使用关系
13.11 小结
13.12 深入阅读

第14章 架构风格
14.1 优势
14.2 柏拉图式风格对体验式风格
14.3 约束和以架构为中心的设计
14.4 模式对风格
14.5 风格目录
14.6 分层风格
14.7 大泥球风格
14.8 管道-过滤器风格
14.9 批量顺序处理风格
14.10 以模型为中心的风格
14.11 分发-订阅风格
14.12 客户端-服务器风格和多层
14.13 对等风格
14.14 map-reduce风格
14.15 镜像，支架和农场风格
14.16 小结
14.17 深入阅读

第15章 使用架构模型
15.1 理想的模型特性
15.2 和视图一起工作
15.3 改善视图质量
15.4 提高图的质量
15.5 测试和证明
15.6 分析架构模型
15.7 架构不匹配
15.8 选择你的抽象级别
15.9 规划用户界面
15.10 指定性模型对描述性模型
15.11 对现有系统进行建模
15.12 小结
15.13 深入阅读

第16章 结论
16.1 挑战
16.2 聚焦质量属性
16.3 解决问题，而不是仅仅对它们建模
16.4 使用导轨一样的约束
16.5 使用标准架构抽象
术语表
文献
索引

9.6视图类型
对所有的视图做一次回顾，就可以看到它们的组织方式中有一定的模式。有些视图，相互之间可以很容易地进行验证，而另一些则无法做到。例如，Yinzer系统的功能场景视图和组件装配视图，相互之间是可以验证的，甚至可以想象，即使将这两个视图合并为一个单一视图也并不太难。
很多视图都难以和源代码视图进行对应，比方说，实例对象或实例组件的视图。为了与源代码视图对应，可能不得不遍历源代码，然后在脑子里想象，哪些组件实例将会出现在运行时，又将会运行在什么样的结构之上。换句话说，如果你一只手上有源代码，一只手上有组件装配视图，要想确定代码能不能在运行期创建出组件实例的结构，还是要费一番工夫的。与此同时，功能场景视图和组件装配视图可以轻松对应，但是，要想对应模块视图和运行时视图，看上去也不太容易。把容易对应的视图进行分组，这应该是你最想做的事情。
9.6.1视图类型定义
分组是通过视图类型来完成的。视图类型是一组或一类可以轻松相互对应的视图（Clementsetal.，20lo）。不同视图类型的视图是不能对应的。在软件架构中，视图类型Ⅲ可以应用于任何设计模型和代码模型，包括项层的边界模型，以及嵌套的内部模型或边界模型。
不幸的是，无法轻易地对应软件系统的每一个视图。很显然，从某些意义上来说，所有的视图都必须是可以对应的（即使只是在你的头脑中），因为，所构建的系统应该符合所有的视图。关于对应视图，最好是多看看别人的设计，而不仅仅只看自己的，看看要在他们的视图之间找到缺陷和不一致有多难。
9.6。2标准架构视图类型
软件架构中有三个标准视图类型：模块视图类型、运行时视图类型及部署视图类型。模块视图类型（moduleviewtype）包含了可以在编译时看到的元素视图，包括像源代码和配置文件这样的制品。组件类型、连接器类型及端口类型的定义也是在模块视图类型中，此外，还有类和接口的定义。
......