10-系统质量属性与架构评估

Mon, 01 Jan 2024 00:00:00 +0000

10-系统质量属性与架构评估（基于第10小时）

软考-系统架构设计师 | 第3篇架构设计高级知识出题形式：单项选择题 + 下午案例分析题分值占比：约 8-15 分（选择），案例分析 25 分

0. 考点分析

本小时是软考分值最高、案例题最常考的章节之一。涵盖三大主题：

软件系统质量属性（开发期 + 运行期）
系统架构评估（方法、ATAM/SAAM 对比）
质量属性场景描述

考试特点：

选择题 8-15 分（概念必考）
案例分析题核心（ATAM 评估、效用树、风险/敏感点/权衡点识别）
论文题素材来源（架构评估方法、ATAM 实践）

1. 核心知识点

1.1 软件系统质量属性（开发期 + 运行期）

开发期质量属性

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

运行期质量属性

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

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

评估关注的核心属性：

类别	属性	关键点
性能	性能	效率指标：处理任务所需时间或单位时间内的处理量
可靠性	容错	出现错误后仍能保证系统正确运行，且自行修正错误
	健壮性	错误不对系统产生影响，按既定程序忽略错误
	可用性	正常运行的时间比例
	安全性	系统向合法用户提供服务并阻止非法用户的能力
可维护性	可维护性	局部修复使故障对架构的负面影响最小化
可修改性	可扩展性	因松散耦合更易实现新特性/功能，不影响架构
	结构重组	不影响主体进行的灵活配置
	可移植性	适用于多样的环境（硬件平台、语言、操作系统等）
其他	功能性	需求的满足程度
	可变性	总体架构可变
	互操作性	通过可视化或接口方式提供更好的交互操作体验

1.3 提升质量属性的策略（⭐⭐⭐ 案例分析重点）

可用性策略

错误检测：心跳、Ping/Echo、异常
错误恢复：表决、主动冗余、被动冗余、重新同步、内测、检查点/回滚
错误避免：服务下线、事务、进程监控器

性能策略

资源的需求：减少处理时间对资源的占用、减少处理事件数量、控制资源使用
资源管理：并发机制、增加资源
资源仲裁：先来先服务、固定优先级、动态优先级、静态调度

可修改性策略

局部化修改：高内聚低耦合、预测变更、使模块通用
防止连锁反应：信息隐藏、维持现有接口、限制通信路径、使用中介
推迟绑定时间：运行时注册、多态、配置文件

安全性策略

抵抗攻击：用户身份验证、用户授权、维护数据机密性与完整性、限制暴露、限制访问
检测攻击：入侵检测系统
从攻击中恢复：恢复状态、识别攻击者

1.4 质量属性场景描述（6 要素）

要素	说明
刺激源（Source）	某个生成该刺激的实体（人、计算机系统或任何其他刺激器）
刺激（Stimulus）	指当刺激到达系统时需要考虑的条件
环境（Environment）	该刺激在某些条件内发生（系统可能处于过载、运行等情况）
制品（Artifact）	某个制品被激励，可能是整个系统，也可能是系统的一部分
响应（Response）	在激励到达后所采取的行动
响应度量（Measurement）	当响应发生时，应当能够以某种方式对其进行度量

1.5 系统架构评估方法分类

方法	特点	缺点
基于调查问卷或检查表	简单易行	很大程度上依赖评估人员的主观判断
基于场景	应用在 ATAM 和 SAAM 中	场景选择影响结果
基于度量	建立质量属性和度量之间的映射	难以建立映射原则

基于度量的步骤：

建立质量属性和度量之间的映射原则
在软件文档中获取度量信息
分析推导系统质量属性

1.6 架构评估重要概念（⭐⭐⭐ 必考）

概念	定义
敏感点	实现质量目标时应注意的点，是一个或多个构件的特性
权衡点	影响多个质量属性的敏感点
风险承担者/利益相关人	影响体系结构或被体系结构影响的群体
场景	确定架构质量评估目标的交互机制（刺激 + 环境 + 影响）
风险点	存在问题的架构设计决策，可能导致问题
非风险点	良好的架构设计决策

记忆口诀：

风险点 = 有问题
非风险 = 良好
敏感点 = 单个构件特性
权衡点 = 影响多个质量属性的敏感点

1.7 SAAM 评估方法

全称：Software Architecture Analysis Method
提出：1983 年，卡耐基梅隆大学软件工程研究所 Kazman 等人
特点：最早形成文档并得到广泛应用的非功能质量属性架构分析方法
输入：问题描述、需求说明、架构描述
过程：场景开发 → 架构描述 → 单个场景评估 → 场景交互 → 总体评估
特定目标：通过程序文档验证体系结构，注重发现潜在问题，可用于单系统评价或多系统比较
主要质量属性：可修改性是主要分析内容
架构描述：围绕功能、结构和分配描述

1.8 ATAM 评估方法（⭐⭐⭐ 案例题核心）

全称：Architecture Tradeoff Analysis Method（架构权衡分析法）
特点：系统开发之前，针对性能、可用性、安全性和可修改性等质量属性进行评价和折中
现代 ATAM：采用效用树对质量属性进行分类和优先级排序

传统 ATAM 四活动阶段

需求收集
架构视图描述
属性模型构造和分析
架构决策与折中

现代 ATAM 评估实践四阶段

阶段	步骤
演示（Presentation）	① 介绍 ATAM ② 介绍业务驱动因素 ③ 介绍要评估的体系结构
调查和分析	① 确定架构方法 ② 生成质量属性效用树 ③ 分析体系结构方法
测试	① 头脑风暴和优先场景 ② 分析架构方法
报告 ATAM	提供评估期间收集的所有信息，呈现给利益相关者

分析体系结构方法的 4 个主要阶段：

调查架构方法
创建分析问题
分析问题的答案
找出风险、非风险、敏感点和权衡点

1.9 SAAM 与 ATAM 对比（⭐ 案例分析重点）

项目	SAAM	ATAM
特定目标	通过程序文档验证体系结构，注重发现潜在问题，可用于评价单系统或进行多系统比较	确定在多个质量属性之间折中的必要性
评估技术	场景技术	场景技术 + 启发式分析方法
质量属性	可修改性是主要分析内容	性能、可用性、安全性和可修改性
风险承担者	所有参与者	场景和需求收集过程中的相关人
架构描述	围绕功能、结构和分配描述	五个基本结构及其映射关系
方法活动	场景开发、体系结构描述、单个场景评估、场景交互和总体评估	场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中
知识库可复用性	不涉及	有基于属性的体系模型，可复用
方法验证	空中交通管制系统、嵌入式音频系统、修正控制系统	仍处于研究中

1.10 其他评估方法

方法	特点
CBAM（成本效益分析法）	整理场景→对场景进行求精→确定场景的优先级→分配效用→架构策略涉及哪些质量属性及响应级别→使用内插法确定"期望的"质量属性响应级别的效用→计算各架构策略的总收益→根据受成本限制影响的 ROI 选择架构策略
SAEM	将软件架构看作最终产品以及涉及过程中的中间产品，从外部质量属性和内部质量属性阐述评估模型
SAABNet	辅助架构的定性评估，诊断软件问题可能原因，度量对象：架构属性、质量准则、质量因素
SACMM	软件架构修改的度量方法，基于内核定义差异度量准则计算两个软件架构之间的距离
SASAM	通过对预期架构和实际架构进行映射和比较来静态评估软件架构
ALRRA	软件架构可靠性风险评估方法，使用动态复杂度准则和动态耦合度准则
AHP	把定性分析和定量计算相结合，对各种决策因素进行处理
COSMIC+UML	针对不同表达方式的软件架构，采用统一的软件度量 COSMIC 方法

2. 关键概念速查

概念	定义/说明	常见考点
易理解性	设计被开发人员理解的难易程度	开发期属性
可维护性	识别修改点并实施修改的难易程度	开发期 vs 运行期辨析
性能	速度、吞吐量、容量	运行期核心属性
安全性	合法服务 + 阻止非授权	三大策略（抵抗/检测/恢复）
可用性	正常运行时间比例	三大策略（检测/恢复/避免）
鲁棒性	非正常情况仍正常运行（健壮性/容错性）	vs 容错的区别
敏感点	一个或多个构件的特性	单个属性
权衡点	影响多个质量属性的敏感点	多个属性
风险点	存在问题的架构设计决策	vs 非风险
SAAM	1983 年 CMU 提出，最早的架构评估方法	主要分析可修改性
ATAM	架构权衡分析法	性能/可用性/安全性/可修改性
CBAM	成本效益分析法	基于 ROI
效用树	对质量属性进行分类和优先级排序	现代 ATAM 工具
质量属性场景 6 要素	刺激源/刺激/环境/制品/响应/响应度量	6 个不能漏

3. 典型例题

例题 1（风险/敏感/权衡点辨析）

题目：识别风险、非风险、敏感点和权衡点是进行软件架构评估的重要过程。“改变业务数据编码方式会对系统的性能和安全性产生影响"是对（1）的描述，“假设用户请求的频率为每秒 1 个，业务处理时间小于 30 毫秒，则将请求响应时间设定为 1 秒钟是可以接受的"是对（2）的描述。

（1）A. 风险点 B. 非风险 C. 敏感点 D. 权衡点（2）A. 风险点 B. 非风险 C. 敏感点 D. 权衡点

答案：D（权衡点）、B（非风险）

解析：

改变业务数据编码方式同时影响性能和安全性两个属性→权衡点
请求频率 1/秒、业务时间 30ms、响应 1s 是良好的架构决策（无问题）→非风险

例题 2（效用树案例）

题目：某电子商务公司升级在线交易系统，需要构建质量属性效用树。题干描述中（a）-（m）各对应不同质量属性场景。

已知：

(a) 正常负载 0.5s 内响应
(b) 信用卡支付 99.999% 安全性
(d) 网络失效 2 分钟内发现并启用备用
(e) 高峰负载 10s 内完成支付
(h) 30 人·月添加事务中间件
(j) 主站点断电 3s 内重定向备用
(k) 用户信息数据库 99.999% 可用
(l) 4 人·月完成 Web 界面修改

答案：

编号	质量属性
(1)	性能
(2)	可修改性
(3)	(e) 高峰负载 10s 内完成
(4)	(j) 主站点断电 3s 内重定向
(5)	(l) Web 界面修改 4 人·月
(6)	(k) 数据库 99.999% 可用

解析：效用树主要关注性能、可修改性、可用性、安全 4 个方面。

例题 3（风险/敏感/权衡点识别）

题目：题干描述中，关于风险/敏感/权衡点的描述：

(f) 系统拟采用新的加密算法，会提高安全性，但会降低性能
(g) 对交易请求处理时间的要求将影响系统数据传输协议和交易处理过程的设计
(i) 现有架构设计中的支付部分与第三方支付平台紧耦合，当系统需要支持新的支付平台时，会导致支付部分代码的修改，影响系统的可修改性

答案：

(f) → 权衡点（同时影响安全性和性能）
(g) → 敏感点（对处理时间的要求影响多个构件的设计）
(i) → 风险（紧耦合导致修改困难，存在问题的架构决策）

例题 4（SAAM 与 ATAM 区别）

题目：以下关于 SAAM 和 ATAM 的描述中，错误的是：

A. SAAM 是最早形成文档的架构分析方法
B. ATAM 主要分析性能、可用性、安全性和可修改性
C. SAAM 主要分析可修改性
D. ATAM 的质量属性评估比 SAAM 少

答案：D

解析：ATAM 评估多个质量属性（性能/可用性/安全性/可修改性），SAAM 主要分析可修改性，ATAM 评估范围更广。

4. 高频考点

4.1 必须记住的核心要点

质量属性分类：
- 开发期：易理解、可扩展、可重用、可测试、可维护、可移植
- 运行期：性能、安全性、可伸缩、互操作性、可靠性、可用性、鲁棒性
三大质量策略：
- 可用性：检测/恢复/避免
- 性能：资源需求/管理/仲裁
- 可修改性：局部化/防连锁/推迟绑定
- 安全性：抵抗/检测/恢复
场景 6 要素：刺激源/刺激/环境/制品/响应/响应度量
风险/敏感/权衡点：
- 风险 = 有问题
- 非风险 = 良好
- 敏感点 = 单个构件特性
- 权衡点 = 影响多个质量属性的敏感点
SAAM vs ATAM 关键区别：
- SAAM：1983 年、场景技术、可修改性、多系统比较
- ATAM：性能/可用/安全/可修改、效用树、五个基本结构、可复用知识库
现代 ATAM 四阶段：演示→调查和分析→测试→报告
效用树关注 4 大属性：性能、可修改性、可用性、安全

4.2 易混淆对比

对比项	区别
敏感点 vs 权衡点	敏感点影响一个属性，权衡点影响多个属性
风险 vs 非风险	风险是有问题的决策，非风险是良好的决策
SAAM vs ATAM	SAAM 主分析可修改性，ATAM 分析 4 大属性（含权衡）
容错 vs 健壮性	容错是错误后修正，健壮性是错误不影响系统
性能 vs 可伸缩性	性能是单次响应能力，可伸缩是负载增加时维持服务质量
可用性 vs 可靠性	可用性是时间比例，可靠性是无故障运行能力
可维护性 vs 可修改性	可维护性是修复缺陷的难易，可修改性是架构层面的修改难易

质量评估 on Liangweidong's blog