软件体系结构设计

体系结构设计的过程 重点

1. 分析项目需求和项目约束；
2. 选择体系结构风格；
3. 进行软件体系结构抽象设计；
4. 进行软件体系结构实现设计；
   1. 包（构件）的设计
   2. 确定运行时的进程
   3. 确定物理部署环境
5. 完善软件体系结构设计；
6. 定义构件接口；
7. 迭代过程 3 ～ 6。

包的原则 重点

共同封闭原则 $(\mathrm{CCP})$​

• 共同变化的类应该放在同一个包内。
• 一个变化影响一个包，便影响了包中所有的类，而对于其他的包不造成任何影响。
• 减少软件的发布、重新验证、重新发行的工作量。
• 延伸了开闭原则 $\mathrm{OCP}$​ 的“关闭”概念。

共同重用原则 $(\mathrm{CRP})$​

• 在同一包内的类应当被一起重用。
• 如果重用了包中的一个类，那么也就相当于重用了包中的所有类。
• 核心观念是包中的类应当聚焦在一起，而不是在包中放入很多互不相干的类。

共同重用原则和共同封闭原则间的博弈

• $\mathrm{CCP}$ 和 $\mathrm{CRP}$ 原则是互斥的，即它们不能同时满足。

• $\mathrm{CRP}$ 使重用者的工作更轻松，而 $\mathrm{CCP}$ 则使维护者的工作更轻松。

• $\mathrm{CCP}$ 力求使包尽可能大，而 $\mathrm{CRP}$ 则试图使包尽可能小。

• 在项目早期，架构师可能会设置包结构，使 $\mathrm{CCP}$ 占主导地位，以便于开发和维护。随着架构的稳定，架构师可能会重构包结构，以最大化 $\mathrm{CRP}$，从而方便外部重用者。

重用-发布等价原则 $(\mathrm{REP})$​

• 重用的粒度就是发布的粒度。
• 简单的编写一个类，然后声称它是可重用的做法是不现实的。只有在建立一个跟踪系统，为潜在的使用者提供所需要的变更通知、安全性以及支持后，重用才有可能。
• 减少重用者的工作。

无环依赖原则 $(\mathrm{ADP})$​

• 包之间的依赖结构必须是一个无环图。
• 按照从高到低的结构组织包，增加项目的稳定性。
• 很可能在面向对象式风格中出现。

如果出现了环……

• 第一种方法是创建新的包。如果 $A$ 和 $B$ 相互依赖，那么就把共同的类抽取出来放在 $C$ 中，这样就变成了 $A$ 和 $B$ 共同依赖 $C$；
• 第二种方法是使用 $\mathrm{DIP}$（依赖倒置原则）和 $\mathrm{ISP}$（接口分隔原则）设计原则。如下图所示

稳定依赖原则 $(\mathrm{SDP})$​

• 包的依赖关系总是朝着稳定的方向进行依赖。
• 被许多其他的软件包依赖的包应该是稳定的，反之亦然。
• 稳定性度量：$I={\mathrm{Dependency}}_{out}/({\mathrm{Dependency}}_{in}+{\mathrm{Dependency}}_{out})$​，越大越不稳定。

稳定抽象原则 $(\mathrm{SAP})$​

• 稳定的包应该是抽象的，反之亦然。
• 延伸了开闭原则 $\mathrm{OCP}$​ 的“开放”概念。
• 抽象性度量：$A={\mathrm{Class}}_{abstract}/({\mathrm{Class}}_{abstract}+{\mathrm{Class}}_{concrete})$

包设计的过程

• 先 $\mathrm{CCP}$ 原则对把可能一同变化的类组织成包进行发布；

• 随着系统的不断增长，我们开始关注创建可重用的元素，于是开始使用 $\mathrm{CRP}$ 和 $\mathrm{REP}$ 来指导包的组合。

• 最后使用 $\mathrm{ADP}$、$\mathrm{SDP}$、$\mathrm{SAP}$ 对包图进行度量，去掉不好的依赖。

体系结构构建之间接口的定义 重点

软件体系结构构建

体系结构的原型构建

TODO

体系结构的集成与测试 重点

集成的策略

• 大爆炸集成。将模块一股脑组合在一起。
• 自顶向下集成。
• 自底向上集成。
• 持续集成。尽早集成并频繁集成，强调桩的应用。可以防止软件开发中出现无法集成和发布的情况，也有利于检查和发现集成中的缺陷。

桩和驱动

桩是在软件测试中用来替换某些模块的。桩一般和所替代的模块有相同的接口，并且模拟地实现了模块的行为。由于是模拟实现，所以相对于真实的实现要简单得多。

驱动代码中执行的是用于测试模块接口的集成测试用例。可以根据该模块的接口定义，使用基于规格的测试技术设计集成测试用例或者进行随机测试。

桩模仿的是下层模块，用来测试上层。而驱动则模仿的是上层模块，用来测试下层。