系统质量属性与架构评估
本章导读
质量属性是衡量软件系统优劣的关键指标,架构评估则是验证架构设计是否满足质量要求的重要手段。本章详细介绍开发期和运行期质量属性、面向架构评估的六大质量属性(性能、可靠性、可用性、安全性、可修改性、功能性)及其设计策略,重点掌握 ATAM 和 SAAM 两种主流评估方法的流程与区别。
学习目标
- 理解开发期与运行期质量属性的分类
- 掌握面向架构评估的六大质量属性及其设计策略
- 熟练运用质量属性场景描述的六要素
- 理解敏感点、权衡点等关键概念
- 掌握 ATAM 四阶段评估流程
- 掌握 SAAM 评估方法的输入和过程
- 能够区分 ATAM 与 SAAM 的特点
软件系统质量属性
质量属性分类
软件系统质量属性是**可测量或可测试**的属性,基于软件生命周期分为两大类:
mindmap
root((质量属性))
开发期质量属性
易理解性
可扩展性
可重用性
可测试性
可维护性
可移植性
运行期质量属性
性能
安全性
可伸缩性
可操作性
可靠性
可用性
鲁棒性 开发期质量属性
| 属性 | 定义 | 关注点 |
|---|---|---|
| 易理解性 | 设计被开发人员理解的难易程度 | 代码可读性、文档完整性 |
| 可扩展性 | 因适应新需求而增加新功能的能力 | 也称**灵活性** |
| 可重用性 | 重用软件系统或某一部分的难易程度 | 组件化、模块化程度 |
| 可测试性 | 测试以证明满足需求规范的难易程度 | 可观察性、可控制性 |
| 可维护性 | 识别修改点并实施修改的难易程度 | 修复缺陷、增加功能、提高质量 |
| 可移植性 | 从一个运行环境转移到另一个的难易程度 | 平台无关性 |
运行期质量属性
| 属性 | 定义 | 关键指标 |
|---|---|---|
| 性能 | 及时提供相关服务的能力 | 速度、吞吐量、容量 |
| 安全性 | 响应合法用户并阻止非授权使用的能力 | 认证、授权、加密 |
| 可伸缩性 | 用户数和数据量增加时维持高服务质量的能力 | 水平/垂直扩展能力 |
| 可操作性 | 与其他系统交换数据和调用服务的难易程度 | 也称**互操作性** |
| 可靠性 | 在一定时间内持续无故障运行的能力 | MTTF、MTBF |
| 可用性 | 系统在一定时间内正常工作的时间比例 | 通常用百分比表示 |
| 鲁棒性 | 非正常情况下仍正常运行的能力 | 也称**健壮性**或**容错性** |
面向架构评估的质量属性 ⭐
重要提示
面向架构评估的质量属性是考试重点,需要掌握每个属性的定义、设计策略。
六大核心质量属性
graph TB
subgraph 核心质量属性
A[性能<br>Performance]
B[可靠性<br>Reliability]
C[可用性<br>Availability]
D[安全性<br>Security]
E[可修改性<br>Modifiability]
F[功能性<br>Functionality]
end
B --> B1[容错]
B --> B2[健壮性]
E --> E1[可维护性]
E --> E2[可扩展性]
E --> E3[结构重组]
E --> E4[可移植性] 质量属性详解
| 属性 | 核心定义 | 设计策略 |
|---|---|---|
| 性能 | 处理任务所需时间或单位时间内的处理量 | 优先级队列、增加计算资源、减少计算开销、引入并发机制、资源调度 |
| 可靠性 | 出现错误后仍能保证系统正确运行 | 心跳、Ping/Echo、冗余、选举 |
| 可用性 | 系统正常运行的时间比例 | 心跳、Ping/Echo、冗余、选举 |
| 安全性 | 向合法用户提供服务并阻止非法用户的能力 | 入侵检测、用户认证、用户授权、追踪审计 |
| 可修改性 | 快速以较高性价比对系统进行变更的能力 | 信息隐藏、接口实现分离、运行时注册 |
| 功能性 | 需求满足程度 | 需求分析、功能设计 |
可靠性 vs 可用性
当题目同时出现可靠性和可用性选项时,优先选择可用性。
- 可靠性:强调系统不出故障
- 可用性:强调系统正常运行的时间占比
可修改性的四个子属性
| 子属性 | 说明 |
|---|---|
| 可维护性 | 局部修复使故障对架构的负面影响最小化 |
| 可扩展性 | 因松散耦合更易实现新特性/功能,不影响架构 |
| 结构重组 | 不影响主体进行的灵活配置 |
| 可移植性 | 适用于多样的环境(硬件平台、语言、操作系统等) |
策略与质量属性对照表
| 设计策略 | 主要提高的质量属性 |
|---|---|
| Ping/Echo | 可用性 |
| 心跳 | 可用性、可靠性 |
| 限制访问 | 安全性 |
| 运行时注册 | 可修改性 |
| 接口实现分离 | 可修改性 |
| 主动冗余 | 可靠性 |
| 队列调度 | 性能 |
| 信息隐藏 | 可修改性 |
| 记录回放 | 可测试性 |
质量属性场景描述
质量属性场景是面向特定质量属性的需求描述,由**六个部分**组成:
graph LR
A[刺激源] --> B[刺激]
B --> C[环境]
C --> D[制品]
D --> E[响应]
E --> F[响应度量]
style A fill:#e1f5fe
style B fill:#b3e5fc
style C fill:#81d4fa
style D fill:#4fc3f7
style E fill:#29b6f6
style F fill:#03a9f4 | 要素 | 定义 | 示例 |
|---|---|---|
| 刺激源 | 生成刺激的实体(人、计算机系统或其他刺激器) | 用户、外部系统、攻击者 |
| 刺激 | 刺激到达系统时需要考虑的条件 | 用户请求、系统故障、安全攻击 |
| 环境 | 刺激发生的条件(系统状态) | 正常运行、过载、启动中 |
| 制品 | 被激励的对象 | 整个系统或系统的某一部分 |
| 响应 | 激励到达后采取的行动 | 处理请求、记录日志、发出警报 |
| 响应度量 | 对响应进行度量的方式 | 响应时间、吞吐量、可用时间比例 |
场景示例:可用性
- 刺激源:系统内部
- 刺激:组件故障
- 环境:正常运行状态
- 制品:数据库服务
- 响应:自动切换到备用服务
- 响应度量:切换时间 < 3 秒,服务可用率 > 99.9%
系统架构评估
评估方法分类
| 方法类型 | 描述 | 特点 |
|---|---|---|
| 基于调查问卷或检查表 | 通过问卷收集评估信息 | 很大程度依赖评估人员的**主观判断** |
| 基于场景的评估方法 | 通过构建场景评估架构 | ATAM、SAAM 采用此方法 |
| 基于度量的评估方法 | 建立质量属性和度量的映射 | 从软件文档获取度量信息 |
关键概念
graph TB
A[敏感点] --> |多个质量属性| B[权衡点]
C[风险承担者] --> |影响/被影响| D[体系结构]
E[场景] --> |描述| F[触发机制<br>环境<br>影响] | 概念 | 定义 |
|---|---|
| 敏感点 | 实现质量目标时应注意的点,是一个或多个构件的特性 |
| 权衡点 | 影响多个质量属性的敏感点 |
| 风险承担者 | 影响体系结构或被体系结构影响的群体(利益相关人) |
| 场景 | 确定架构质量评估目标的交互机制 |
权衡点示例
"改变加密的级别可能会对安全性和性能都产生显著的影响"
这是一个典型的**权衡点**描述:
- 提高加密级别 → 安全性↑,性能↓
- 降低加密级别 → 安全性↓,性能↑
ATAM:架构权衡分析法 ⭐
ATAM 概述
ATAM(Architecture Tradeoff Analysis Method)是一种架构评估方法,主要在系统开发之前,针对**性能、可用性、安全性、可修改性**等质量属性进行评价和折中。
ATAM 四阶段流程
graph TB
subgraph 阶段1-演示
A1[介绍ATAM]
A2[介绍业务驱动因素]
A3[介绍要评估的体系结构]
end
subgraph 阶段2-调查和分析
B1[确定架构方法]
B2[生成质量属性效用树]
B3[分析体系结构方法]
end
subgraph 阶段3-测试
C1[头脑风暴和优先场景]
C2[分析架构方法]
end
subgraph 阶段4-报告
D1[呈现评估结果]
end
A1 --> A2 --> A3 --> B1 --> B2 --> B3 --> C1 --> C2 --> D1 阶段详解
目标:让所有参与者了解评估背景
| 步骤 | 内容 |
|---|---|
| 1. 介绍 ATAM | 描述 ATAM 评估过程 |
| 2. 介绍业务驱动因素 | 业务视角:系统功能、主要利益相关方、业务目标、限制 |
| 3. 介绍要评估的体系结构 | 架构可用性及质量要求 |
目标:深入分析架构的关键问题
| 步骤 | 内容 |
|---|---|
| 1. 确定架构方法 | 识别满足关键需求的架构方法 |
| 2. 生成质量属性效用树 | 确定最重要的质量属性并排序 |
| 3. 分析体系结构方法 | 找出风险、非风险、敏感点、权衡点 |
分析过程:
目标:验证架构分析结果
| 步骤 | 内容 |
|---|---|
| 1. 头脑风暴和优先场景 | 与效用树中的优先方案比较 |
| 2. 分析架构方法 | 进一步验证分析结果 |
目标:汇总并呈现评估结果
提供评估期间收集的所有信息,呈现给利益相关者。
ATAM 核心特点
- 强调对**质量属性**进行分析、分类和优先级排序
- 构建**质量属性效用树**
- 识别和分析**风险点、非风险点、敏感点、权衡点**
SAAM:软件架构分析方法
SAAM 概述
SAAM(Software Architecture Analysis Method)是一种非功能质量属性的架构分析方法,是**最早形成文档并得到广泛应用**的软件架构分析方法。
SAAM 的输入与过程
graph LR
subgraph 输入
A[问题描述]
B[需求说明]
C[架构描述]
end
subgraph 评估过程
D[场景开发]
E[架构描述]
F[单个场景评估]
G[场景交互]
H[总体评估]
end
A --> D
B --> D
C --> D
D --> E --> F --> G --> H SAAM 五步评估过程
| 步骤 | 内容 |
|---|---|
| 场景开发 | 开发评估场景 |
| 架构描述 | 描述被评估的架构 |
| 单个场景评估 | 评估每个场景 |
| 场景交互 | 分析场景之间的交互影响 |
| 总体评估 | 综合评估整体架构 |
ATAM vs SAAM 对比
| 对比项 | SAAM | ATAM |
|---|---|---|
| 特定目标 | 验证架构,发现潜在问题 可用于单系统评估或多系统比较 | 确定在多个质量属性之间折中的必要性 |
| 评估技术 | 场景技术 | 场景技术 + 启发式分析方法 |
| 质量属性 | **可修改性**是主要分析内容 | 性能、可用性、安全性、可修改性 |
| 风险承担者 | 所有参与者 | 场景和需求收集过程中的相关人 |
| 架构描述 | 围绕功能、结构和分配描述 | 五个基本结构及其映射关系 |
| 方法活动 | 场景开发→架构描述→单场景评估→场景交互→总体评估 | 场景/需求收集→架构视图/场景实现→属性模型构造/分析→折中 |
| 知识库复用 | 不涉及 | 有基于属性的体系模型,可复用 |
| 应用领域 | 空中交通管制、嵌入式音频、修正控制系统 | 仍处于研究中 |
记忆技巧
- SAAM:侧重**可修改性**,评估**单一质量属性**
- ATAM:侧重**权衡分析**,评估**多个质量属性**的折中
其他评估方法
成本效益分析法(CBAM)
CBAM 评估流程:
graph LR
A[整理场景] --> B[场景求精]
B --> C[确定优先级]
C --> D[分配效用]
D --> E[分析质量属性]
E --> F[确定响应级别效用]
F --> G[计算总收益]
G --> H[选择架构策略] 其他方法简介
| 方法 | 特点 |
|---|---|
| SAEM | 从外部和内部质量属性阐述评估模型 |
| SAABNet | 辅助架构定性评估,基于贝叶斯网络 |
| SACMM | 软件架构修改的度量方法,计算架构间距离 |
| SASAM | 通过预期架构和实际架构的比较进行静态评估 |
| ALRRA | 软件架构可靠性风险评估方法 |
| AHP | 把定性分析和定量计算相结合 |
| COSMIC+UML | 采用统一的 COSMIC 方法进行度量 |
本章小结
核心知识点
- 质量属性分类:开发期(6 个)vs 运行期(7 个)
- 架构评估质量属性:性能、可靠性、可用性、安全性、可修改性、功能性
- 场景六要素:刺激源、刺激、环境、制品、响应、响应度量
- 关键概念:敏感点(单属性)、权衡点(多属性)
- ATAM:四阶段(演示→调查分析→测试→报告),构建效用树
- SAAM:五步骤(场景开发→架构描述→单场景评估→场景交互→总体评估)
重要对照表
| 设计策略 | 质量属性 |
|---|---|
| Ping/Echo、心跳、冗余、选举 | 可用性、可靠性 |
| 入侵检测、用户认证、用户授权、追踪审计 | 安全性 |
| 信息隐藏、接口实现分离、运行时注册 | 可修改性 |
| 队列调度、增加资源、并发机制 | 性能 |
| 记录回放 | 可测试性 |
考试重点
| 知识点 | 考查形式 |
|---|---|
| 质量属性与设计策略对应 | 给出策略判断提高哪个属性 |
| 敏感点与权衡点区分 | 根据描述判断是敏感点还是权衡点 |
| ATAM 四阶段流程 | 流程排序或阶段内容识别 |
| SAAM vs ATAM | 两种方法的特点对比 |
学习建议
- 质量属性:牢记设计策略与质量属性的对应关系
- 场景六要素:结合实际案例理解每个要素的含义
- 评估方法:重点掌握 ATAM 的四阶段和 SAAM 的五步骤
- 概念区分:理解敏感点和权衡点的区别