质量属性

质量属性六要素

软件系统质量属性（Quality Attribute）是一个系统的可测量或可测试的属性，用来描述系统满足利益相关者需求的程度。

质量属性场景六要素：

1. 刺激源（Source）— 谁发出的刺激
2. 刺激（Stimulus）— 触发系统的事件
3. 环境（Environment）— 事件发生时的条件
4. 制品（Artifact）— 被影响的系统组成部分
5. 响应（Response）— 系统对刺激的反应行为
6. 响应度量（Response Measure）— 可量化的评估指标

简化三要素（场景最小描述）：刺激、环境、响应

---

运行期 vs 开发期质量属性 【软件系统的质量属性】

可以将软件系统的质量属性分为开发期质量属性和运行期质量属性 2个部分。

开发期质量属性

1.开发期质量属性主要指在软件开发阶段所关注的质量属性，主要包含6个方面。

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

运行期质量属性

2.运行期质量属性主要指在软件运行阶段所关注的质量属性，主要包含7个方面。

• (1)性能：性能是指软件系统及时提供相应服务的能力，如速度、吞吐量和容量等的要求。
• (2)安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
• (3)可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力。
• (4)互操作性：指本软件系统与其他系统交换数据和相互调用服务的难易程度。
• (5)可靠性：软件系统在一定的时间内持续无故障运行的能力。
• (6)可用性：指系统在一定时间内正常工作的时间所占的比例。可用性会受到系统错误，恶意攻击，高负载等问题的影响。
• (7)鲁棒性：是指软件系统在非正常情况（如用户进行了非法操作、相关的软硬件系统发生了故障等)下仍能够正常运行的能力，也称健壮性或容错性。

🎯 开发期质量属性：关注开发和维护过程的效率；运行期质量属性：关注系统在线运行时的表现。

分类	包含属性	特点
运行期质量属性	性能、安全性、可用性、可靠性、鲁棒性、互操作性	用户在使用时可直接感知
开发期质量属性	可修改性、可测试性、可重用性、可维护性、可移植性	开发和维护阶段体现

⚠️ 常见坑：可伸缩性（Scalability）是运行期质量属性（与用户数和数据量相关）。

---

面向架构评估的质量属性

性能（Performance）

• 系统的响应能力：响应时间（多久响应）、吞吐量（单位时间处理事件个数）
• 典型场景："并发 10 万用户时，请求响应时间 < 3 秒"
• 架构策略：资源调度、引入并发、增加计算资源

可靠性（Reliability）

🎯 可靠性 = 在规定条件和时间内完成规定功能的能力，核心指标是 MTBF（平均失效间隔时间）。

• 在意外或错误使用情况下维持功能特性的能力
• **MTTF（平均失效等待时间）**和 MTBF（平均失效间隔时间）：在失效率为常数且修复时间很短的情况下，MTTF 和 MTBF 几乎相等
• 与可用性的区别：可靠性侧重"不出错"，可用性侧重"出错后能恢复"

可靠性：是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。如MTTF、MTBF。设计策略：心跳、Pig/Echo、冗余、选举。

包括容错和健壮性。

可用性（Availability）

• 系统故障后恢复并继续提供服务的能力
• 指标：MTBF（故障间隔时间）、MTTR（修复时间）
• 典型场景："主站宕机后，10 秒内自动切换至备用站点"
• 架构策略：心跳（故障检测）、主动冗余（主备切换）

指标 - MTTR

MTTR：平均故障恢复时间。

安全性（Security）

• 抵御恶意攻击的能力
• 典型场景："防止 99% 黑客攻击"、"对恶意操作进行报警和记录"
• 架构策略：追踪审计、检测攻击、权限控制

可修改性（Modifiability）

• 定位修改点并实施修改的难易程度
• 典型场景："二次开发时间不超过 3 个月"、"功能调整不超过 1 人月"
• 包含：可维护性、可扩展性、结构重构、可移植性
• 架构策略：抽象接口、信息隐藏、接口-实现分离

功能性

功能性：是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。

可变性（Variability）

🎯 可变性 = 体系结构经扩充或变更成为新体系结构的能力。注意：归属为可修改性的子维度，但独立考察。

• 可修改性包含：可维护性、可扩展性、结构重构、可移植性
• ⚠️ 常见坑：可变性不属于可修改性的组成部分（它是并列概念）

互操作性

互操作性：作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。

为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。

程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，也影响应用的软件体系结构。

---

质量属性-架构策略速查

有没有可测试性？

质量属性	典型场景关键词	首选架构策略
性能	响应时间、并发用户数、时延	资源调度、引入并发
可用性	宕机切换、自动恢复、双机热备	心跳、主动冗余
安全性	防攻击、加密、入侵检测、报警记录	追踪审计、检测攻击
可修改性	二次开发、功能调整、替换中间件	抽象接口、接口-实现分离
可测试性	测试、验证	记录/回放、内置监控器
易用性	操作一致性、用户满意度、学习成本	—

面向架构评估的质量属性和运行期质量属性的区别

两组质量属性分类，是从不同视角对软件质量属性的划分，二者是交叉重叠但不完全等同的关系

---

两种分类的视角

分类	划分依据	关注阶段	典型属性
开发期 vs. 运行期质量属性	按时间阶段划分	开发阶段 vs. 运行阶段	开发期：可维护性、可扩展性、可测试性等 运行期：性能、可靠性、安全性等
面向架构评估的质量属性	按架构设计决策与评估的需要划分	跨越开发期和运行期，重点关注对架构有显著影响的属性	性能、可靠性、可用性、安全性、可修改性、功能性、可变性、互操作性

---

运行期质量属性 → 几乎全部出现在架构评估列表中

• 性能 → 架构评估中的“性能”
• 安全性 → 架构评估中的“安全性”
• 互操作性 → 架构评估中的“互操作性”
• 可靠性 → 架构评估中的“可靠性”
• 可用性 → 架构评估中的“可用性”

运行期特有的属性，在架构评估中被归入其他属性或细分

• 可伸缩性：通常被视为性能的一个子维度（通过资源调度、水平扩展来实现）。
• 鲁棒性（健壮性/容错性）：通常被视为可靠性或可用性的一个方面（例如容错设计、异常处理）。

架构评估列表中额外包含的、不属于运行期的属性

• 可修改性：属于开发期质量属性（包含可维护性、可扩展性、可移植性等）。
• 功能性：跨越开发期和运行期，是系统“能否完成期望工作”的基本能力，架构评估中常单独列出。
• 可变性：有时作为可修改性的子维度，有时独立考察（例如产品线架构中的变点设计），也属于开发期/设计期。

---

关系图

┌─────────────────────────────────────────────────┐
│           面向架构评估的质量属性                  │
│  ┌───────────────────────────────────────────┐  │
│  │  运行期质量属性                            │  │
│  │  • 性能 (可伸缩性归入)                     │  │
│  │  • 安全性                                  │  │
│  │  • 互操作性                                │  │
│  │  • 可靠性 (鲁棒性归入)                     │  │
│  │  • 可用性                                  │  │
│  └───────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────┐  │
│  │  开发期/设计期质量属性                      │  │
│  │  • 可修改性 (含可维护性、可扩展性等)       │  │
│  │  • 可变性                                  │  │
│  │  • 功能性 (跨阶段)                         │  │
│  └───────────────────────────────────────────┘  │
└─────────────────────────────────────────────────┘

• 考试中如果问“以下哪些属于运行期质量属性”，要能区分开发期属性（如可测试性、可移植性）不选。
• 如果问“”，则要包含可修改性、可变性、功能性等看似不属于运行期的属性。
• 注意可伸缩性和鲁棒性虽然不在标准运行期七项之外单独列出（有时独立），但通常可以归入性能/可靠性；考试中若选项同时出现，按教材定义选择。

---

补充：质量属性战术详解（Architecture Tactics）

战术（Tactics）是针对特定质量属性的具体设计决策，用来控制质量属性响应。选择题常考"以下哪个是针对 X 属性的战术"。

性能战术：

战术	说明
引入并发	多线程/多进程并行处理
资源调度	优先级队列、动态资源分配
预计算/缓存	提前计算结果，减少实时计算
减少计算开销	算法优化、降低复杂度

可用性战术：

战术	说明
心跳（Heartbeat）	故障检测，周期发送信号
主动冗余（Active Redundancy）	多节点同时运行，故障自动切换
被动冗余（Passive Redundancy）	主备切换，备用节点待命
异常检测与恢复	捕获异常并回滚到安全状态

安全性战术：

战术	说明
认证（Authentication）	验证用户身份
授权（Authorization）	控制访问权限
加密（Encryption）	数据传输和存储加密
审计追踪（Audit Trail）	记录操作日志

可修改性战术：

战术	说明
抽象接口	隐藏实现细节，面向接口编程
信息隐藏	封装变化点
运行时绑定	动态加载/插件机制

⚠️ 常见坑："设置进程监视器"是可用性战术（监控进程健康状况），不是性能战术。

---