软件架构评估-质量属性

性能

性能(performance)是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。

例如:

1. 同时支持1000并发;
2. 响应时间小于1s;
3. 显示分辨率达到4K。

性能战术

1. 资源需求
   提高计算效率、减少计算开销、管理事件率、控制采样频率
2. 资源管理
   引入并发、维持多个副本、增加可用资源
3. 资源仲裁
   资源调度策略:先进/先出、固定优先级、动态优先级、静态调试

可用性

可用性(availability)是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。

例如:

1. 主服务器故障，1分钟内切换至备用服务器;
2. 系统故障，1小时内修复;
3. 系统支持7×24小时工作。

可用性战术

1. 错误检测
   命令/响应【Ping/Echo】、心跳、异常
2. 错误恢复
   表决、冗余【主动/被动】、备件
3. 错误预防
   进程监视器、事务、从服务器删除

安全性

安全性(security)是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。

例如:

1. 可抵御SQL注入攻击;
2. 对计算机的操作都有完整记录;
3. 用户信息数据库授权必须保证99.9%可用

安全性战术

1. 抵抗攻击
   身份验证、用户授权、数据加密、数据完整性、限制暴露、限制访问
2. 检测攻击
   入侵检测
3. 从攻击中恢复
   识别:审计追踪、恢复:冗余【与可用性重叠】

可修改性

可修改性(modifiability)是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。

例如:

1. 更改系统报表模块，必须在2人周内完成;
2. 对Web界面风格进行修改，修改必须在4人月内完成;

可修改性战术

1. 局部化修改
   维持语义一致性、预期期望的变更、泛化模块、限制可能的选择、抽象通用服务
2. 防止连锁反应
   隐藏信息、维持现有的接口、限制通信路径、使用仲裁者
3. 推迟绑定时间
   运行时注册配置文件、多态、组件更换、遵守已定义的协议

易用性

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

例如:

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

可测试性

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

例如:

1. 提供远程调试接口，支持远程调试。

软件架构评估

敏感点：是一个或多个构件（和/或构件之间的关系)的特性。
权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。
风险点：是指架构设计中潜在的、存在问题的架构决策所带来的隐患。
非风险点：是指不会带来隐患，一般以“XXx要求是可以实现（或接受)的”方式表达。

例如:

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

软件架构评估-架构评估方法

1. 基于调查问卷（检查表)的方式
2. 基于度量的方式
3. 基于场景的方式

性能场景示例

软件架构评估- SAAM（场景）

最初用于分析架构可修改性，后扩展到其他质量属性。

软件架构评估-ATAM（场景）

在SAAM的基础上发展起来的，主要针对性能、实用性、安全性和可修改性,在系统开发之前,对这些质量属性进行评价和折中。

软件架构评估-质量效用树