系统质量属性与架构评估

1 软件系统质量属性的概念

1.1 开发期的质量属性

属性	说明
易理解性	指设计开发人员理解的难易程度
可扩展性	软件因适应新需求变化而增加新功能的能力，也称为灵活性
可重用性	指重用软件系统或其一部分的难易程度
可测试性	当软件测试以证明其满足需求规范的难易程度
可维护性	当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度
可移植性	将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度

1.2 运行期的质量属性

属性	说明
性能	软件系统即时提供相应的服务能力，如速度、吞吐量和容量等
安全性	软件系统同时兼顾向合法用户提供服务，以及组织非授权使用的能力
可伸缩性	当用户数和数据量增加时，软件系统维持高服务质量的能力
互操作性	软件系统与其他系统交换数据和相互调用服务的难易程度
可靠性	软件系统在一定时间内持续无故障运行的能力
可用性	系统在一定时间内正常工作的时间所占比例
健壮性	软件系统在非正常情况（用户非法操作、相关软硬件系统发生故障）下仍正常运行的能力，也称容错性

2 面向架构评估的质量属性

2.1 性能

性能（performance）是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。例如：同时支持1000并发；响应时间小于1s；显示分辨率达到4K

提升性能的策略（性能战术）可以从以下几个方面考虑：

资源需求：
①提高计算效率、②减少计算开销、③管理（减少处理事件数量）事件率、④控制采样频率（控制资源的使用）
资源管理：
①引入并发机制、②维持多个副本、③增加可用资源
资源仲裁：
资源调度策略：①先进先出、②固定优先级、③动态优先级、④静态调式

2.2 可用性

可用性（availability）是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。例如：主服务器故障，1分钟内切换至备用服务器；系统故障，1小时内修复；系统支持7×24小时工作

提升可用性的策略（可用性战术）可以从以下几个方面考虑：

错误检测：
①命令/响应【Ping/Echo】、②心跳、③异常
错误恢复：
①表决、②冗余【主动/被动】、③备份【重新同步、内测、检查点/回滚】
错误避免：
①进程监视器、②事务、③从服务器删除【服务下线】

2.3 安全性

安全性（security）是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。例如：可抵御SQL注入攻击；对计算机的操作都有完整记录（日志，审计追踪）；用户信息数据库授权必须保证99.9%可用

提升安全性的策略（安全性战术）可以从以下几个方面考虑：

抵抗攻击：
①用户身份验证、②用户授权、③维护数据机密性和完整性、④限制暴露、⑤限制访问
检测攻击：
①入侵系统检测
从攻击中恢复：
①识别攻击者：审计追踪、②恢复状态：冗余【与可用性重叠】

2.4 可修改性

可修改性（modifiability）是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。例如：更改系统报表模块，必须在2人周内完成；对Web界面风格进行修改，修改必须在4人月内完成

可修改性分为四个子属性：
可维护性：局部修复使故障对架构的负面影响最小化。
可扩展性：因松散的耦合更易实现新特性/功能，不影响架构。
结构重组：不影响主体进行的灵活配置。
可移植性：适用于多样的环境（硬件平台、语言、操作系统等）。

提升性能的策略（可修改行战术）可以从以下几个方面考虑：

局部化修改：
①高内聚低耦合、②预测变更、③使模块通用、④泛化模块、⑤维持语义的一致性、⑥限制可能的选择、⑦抽象通用服务
防止连锁反应：
①隐藏信息、②维持现有接口、③限制通信路径、④使用仲裁者
推迟绑定时间：
①运行时注册、②配置文件、③多态、④组件更换、⑤遵守已定义的协议

2.5 易用性

易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类。例如：

界面友好
新用户学习使用系统时间不超过2小时

2.6 可测试性

软件可测试性是指通过测试揭示软件缺陷的容易程度。例如：

提供远程调试接口，支持远程调试

2.7 可靠性

分为两个子属性：
容错性：出错后仍能保证系统争取运行，且自行修正错误。
健壮性：错误不对系统产生影响，按既定程序忽略错误。

2.8 功能性

需求的满足程度。

2.9 可变性

总体架构可变。

2.10 互操作性

通过可视化或接口方式提供更好的交互操作体验。

3 质量属性场景描述

质量属性场景是一种面向特定质量属性的需求，由刺激源、刺激、环境、制品、响应、响应度量组成。
（1）刺激源（Source）：某个生成该刺激源的实体（人、计算机系统或者任何其他刺激器）。
（2）刺激（Stimulus）：指当刺激到达系统时需要考虑的条件。
（3）环境（Environment）：指该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况。
（4）制品（Artifact）：某个制品被激励，可能是整个系统，也可能是系统的一部分。
（5）响应（Response）：指在激励到达后所采取的行动。
（6）响应度量（Measurement）：当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。

4 系统架构评估

4.1 重要概念

4.1.1 敏感点、权衡点、风险点、非风险点

敏感点（Sensitivity Point） ：是一个或多个构件（和/或构件之间的关系）的特性。

权衡点（Tradeoff Point） ：是影响多个质量属性的特性，是多个质量属性的敏感点。

风险点（Risk Point ） ：是指架构设计中潜在的、存在问题的架构决策所带来的隐患。

非风险点（Non-Risk Point ） ：是指不会带来隐患，一般以“XXX要求是可以实现（或接受）的”方式表达。

例如：

对交易请求处理时间的要求将影响系统的数据传输协议和处理过程的设计（敏感点）
假设每秒中用户交易请求的数量是10个，处理请求的时间为30毫秒，则“在1秒内完成用户的交易请求”这一要求是可以实现的 （非风险点）
目前对系统信用卡支付业务逻辑的描述尚未达成共识，这可能导致部分业务功能模块的重复，影响系统的可修改性 （风险点）
更改加密的级别将对安全性和性能产生影响 （权衡点）

4.1.2 风险承担者或者相关利益人

影响体系结构或被体系结构影响的群体。

4.1.3 场景

确定架构质量评估目标的交互机制，一般采用触发机制（刺激）、环境和影响三方面来考虑。

4.2 系统架构评估方法

基于调查问卷或检查表的评估方法
是指组织相关人员进行评估，这种方式最简单易行，但是主观性强。
基于度量的评估方法
强调量化指标，最客观，但是这种方式实施难度大，因为需要评估者对系统非常熟悉，不然很难量化清楚各项指标。
基于场景的评估方法
筛选出系统的关键场景，根据系统在不同场景中的表现进行评估，这种方式客观程度介于2者之间，这也是目前较为流行的结构评估方法。

基于场景的方式主要有三种（前2种方式用得比较多）：

软件架构分析法（SAAM，Software Architecture Analysis Method）
架构权衡分析法（ATAM，Architecture Tradeoff Analysis Method）
成本效益分析法（CBAM，the Cost Benefit Analysis Method）

4.2.1 基于场景 - 软件架构分析法SAAM

SAAM，最初用于分析架构可修改性，后扩展到其它质量属性。
SAAM分析评估架构的过程包括5个步骤 ，如下图：
（1）场景开发
（2）架构描述
（3）单个场景评估
（4）场景交互评估
（5）整体评估

4.2.2 基于场景 - 架构权衡分析法ATAM

架构权衡分析法（ATAM，Architecture Tradeoff Analysis Method）是在SAAM上发展而来。核心是结合质量属性效用树对系统进行评价，确定风险点、敏感点、权衡点，并对系统架构做出决策和折中。整个评估过程强调以质量属性作为评估核心，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

ATAM分成4个阶段，如下图：
（1）场景和需求收集
（2）架构视图和场景实现
（3）质量模型构造和分析
（4）质量模型折中