8.软件架构评估
为什么要进行软件架构评估
软件架构评估是针对软件架构的层级进行的评估，即对软件开发的高层级进行评估
架构评估到底评估什么
看最终设计的架构是否满足需求（更注重非功能需求）
架构评估怎么评
涉及一些方法论，用基于场景的架构评估方法论用的比较多
概念
敏感点（和别的相比受刺激后对系统产生更大影响）
是一个或多个构件（和/或构件之间的关系）的特性。
权衡点（是一种敏感点）
是影响多个质量属性的特性，是多个质量属性的敏感点。例如提升安全性能，性能就会下降（安全和性能是一个矛盾点，找到中和点就是权衡点）
（+表示正相关，-表示负相关， 例如负相关中性能提升，安全性下降） 风险点（带来隐患）
是指架构设计中潜在的、存在问题的架构决策所带来的隐患
非风险点（没有带来隐患）
是指不会带来隐患，一般以“XXX 要求是可以实现（或接受）的”方式表达。
例子
- 对交易请求处理时间的要求将影响系统的数据传输协议和处理过程的设计 - 敏感点（影响属性的单一方面）
- 假设每秒钟用户交易请求的数量是 10 个，处理请求的时间为 30 毫秒，则“在 1 秒内完成用户的交易请求”这一要求是可以实现的 - 非风险点
- 目前对系统信用卡支付业务逻辑的描述尚未达成共识，这可能导致部分业务功能模块的重复，影响系统的可修改性 - 风险点
- 更改加密的级别将对安全性和性能产生影响 - 权衡点
方法
- 基于调查问卷的方式
- 基于度量的方式：注重数据化
基于场景的方式：
【质量属性场景】是从风险承担者的角度与系统交互的简短描述，它通常作为描述质量属性的手段
六个方面
三个方面为：刺激、环境、响应
场景可从六个方面进行描述
- 刺激源【Source】：是某个生成该刺激的实体（人、计算机脚本或者其他任何刺激器）
- 刺激【Stimulus】：该刺激是当刺激到达系统时需要考虑的条件
- 制品【Artifact】：某个制品被激励。这可能是整个系统（或系统的一部分）
- 环境【Environment】:该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况
- 响应【Response】:该响应是在激励到达后所采取的行动
- 响应度量【Measurement】:当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试
场景描述
可用性属性质量场景描述
有多少时间百分比是正常运行的状态
例子：系统能够连续运行的时间不小于 1000 小时，闪退后能够在 15S 内自动重启
其中，系统是刺激源，闪退是刺激，系统是制品，正常操作（系统正常运行的状态）是环境，自动重启是响应，15S 内重启是响应度量
可修改性属性质量场景描述
以较高性价比完成系统的修改
例子：更改 WEB 界面接口必须在 2 人周内完成
其中，发出更改请求的人（用户）是刺激源，更改 WEB 界面接口是刺激，WEB 界面接口相关的是制品，（没有环境，要素缺乏）是环境，完成更改 是响应，2 人周内是响应度量
性能质量属性场景描述
例子：正常负载下，系统必须在 0.5 秒内对用户的交易请求进行响应
其中，用户请求是刺激源，交易请求是刺激，系统是制品，正常模式是环境，完成请求是响应，0.5 秒内是响应度量
可测试性质量属性场景描述
例子：测试人员在开发期间针对一个代码单元，执行一个测试序列，获取结果，并在 20 分钟内完成测试
其中，是测试人员是刺激源，执行测试序列是刺激，代码单元是制品，开发时是环境，完成测试是响应，20 分钟内是响应度量
易用性质量属性场景描述
例子：新用户学习使用系统时间不超过 2 小时
其中，新用户是刺激源，学习使用系统是刺激，系统运行时是环境，系统是制品，学会使用系统是响应，不超过 2 小时是响应度量
安全性质量属性场景描述
例子：信用卡支付必须保证 99.9999%的安全性
其中，用户/消费者/信用卡持卡人是刺激源，是信用卡支付刺激，正常运行的环境是环境，系统中安全服务是制品，安全响应支付是响应，99.9999%是响应度量
SAAM 软件架构分析法
最早关注可修改性，后扩充到可移植性、可扩充性等。 最早形成文档并得到广泛使用的软件架构分析方法
ATAM 架构权衡分析法
从 SAAM 发展而来，主要针对：性能、实用性、安全性、可修改性 在系统开发之前，对这些质量属性进行评价和折中（综合平衡） 不是一种精准的评估工具
主要关注系统的需求说明
CBAM 成本效益分析法
在 ATAM 基础上建立的，软件的“经济“模型
质量（属性）效用树
- 根节点：效用
- 质量属性：构成效用树的辅助级别
树形结构从根节点到叶子节点：树根、质量属性、属性分类、质量属性场景