原子标签索引：[概念×18 | 机制×3 | 流程×7 | 分类×5 | 判据×8 | 数据×3 | 案例×2] 上游：第7章（架构风格与开发方法） 下游：第13～19章（各领域架构实践的质量设计） ⚠️ 本章是案例考试最核心章节：质量属性场景六元组、ATAM/SAAM 术语与判据必须逐字精确。

标准表述

• 软件系统质量是"软件系统与明确地和隐含地定义的需求相一致的程度"。
• 依据 GB/T 16260.1，影响软件质量的主要因素划分为 6 种维度特性：功能性、可靠性、易用性、效率、维护性与可移植性。
• 功能性的子项共 5 个：适合性、准确性、互操作性、依从性、安全性。
• 可靠性的子项共 3 个：容错性、易恢复性、成熟性。
• 易用性的子项共 3 个：易学性、易理解性、易操作性。
• 效率的子项共 2 个：资源特性与时间特性。
• 维护性的子项共 4 个：可测试性、可修改性、稳定性，加上易分析性。
• 可移植性的子项共 4 个：适应性、易安装性、一致性，加上可替换性。
• 开发期质量属性 6 个：易理解性、可扩展性、可重用性、可测试性、可维护性、可移植性。
• 运行期质量属性 7 个：性能、安全性、可伸缩性、互操作性、可靠性、可用性、鲁棒性。
• 性能是系统及时提供相应服务的能力（速度、吞吐量、容量）；可伸缩性是用户数和数据量增加时维持高服务质量的能力。
• 鲁棒性（健壮性/容错性）是非正常情况下仍能正常运行的能力。
• 可靠性用 MTTF（平均失效等待时间）和 MTBF（平均失效间隔时间）衡量；失效率为常数且修复时间很短时 MTTF≈MTBF。
• 可靠性分两个方面：容错（错误发生时确保系统正确行为并内部"修复"）和健壮性（保证软件按某种已定义好的方式终止执行，并非继续运行）。
• 可用性是系统能够正常运行的时间比例。
• 安全性可划分为：机密性、完整性、不可否认性及可控性。
• 机密性保证信息不泄露给未授权的用户、实体或过程；完整性保证信息的完整和准确，防止非法修改；不可否认性指交换双方不能否认发送或接收信息的行为；可控性保证对信息的传播及内容具有控制能力。
• 可修改性包含 4 个方面：可维护性（修复问题）、可扩展性（新特性扩展、松散耦合）、结构重组（重新组织构件及关系）、可移植性（多环境下运行，是特殊的可修改性）。
• 可变性是架构经扩充或变更而成为新架构的能力，对软件产品线很重要。
• 质量属性场景由 6 部分组成：刺激源（Source）、刺激（Stimulus）、环境（Environment）、制品（Artifact）、响应（Response）、响应度量（Measurement）。
• 架构评估方法分 3 类：基于调查问卷或检查表、基于场景、基于度量。基于场景的方法由卡耐基梅隆大学软件工程研究所（SEI）首先提出并应用在 ATAM 和 SAAM 中。
• 基于度量的方法 3 个基本活动：建立质量属性和度量之间的映射原则 → 从架构文档获取度量信息 → 根据映射原则推导质量属性。
• 敏感点是一个或多个构件（和/或构件之间关系）的特性，对实现某个质量属性至关重要。
• 权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。例：加密级别影响安全性与性能。
• 场景是从风险承担者角度对与系统的交互的简短描述；评估中用刺激、环境、响应三方面描述。
• SAAM：CMU-SEI 的 Kazman 等人提出（教材记为 1983 年），最早形成文档并得到广泛使用的架构分析方法；主要质量属性是可修改性；评估技术是场景技术。
• SAAM 评估过程 5 步：场景开发、架构描述、单个场景评估、场景交互、总体评估。
• ATAM 在 SAAM 基础上发展而来，主要针对性能、实用性（可用性）、安全性和可修改性，在系统开发之前评价和折中。
• ATAM 架构描述基于 5 种基本结构，从 Kruchten 的 4+1 视图派生（逻辑视图分为功能结构和代码结构）。
• ATAM 三类场景：用例（典型使用）、增长场景（系统修改）、探测场景（可能造成过载的极端修改）。
• ATAM 分 4 个活动领域：场景和需求收集、架构视图和场景实现、属性模型构造和分析、折中。
• ATAM 使用效用树（Utility Tree）对质量属性分类和优先级排序；结构：树根—质量属性—属性分类—质量属性场景（叶子节点）。
• ATAM 主要关注 4 类质量属性：性能、安全性、可修改性和可用性（利益相关者最关心）。
• 效用树修剪：保留重要场景（通常不超过 50 个），按重要性和实现难易度分别用 H/M/L 排序，形成优先级对。
• CBAM（成本效益分析法）在 ATAM 上构建，对架构决策的成本和收益建模，协助干系人根据投资回报 ROI 选择架构策略；CBAM 在 ATAM 结束时开始，使用 ATAM 的评估结果。
• 架构评估实践 8 步分 4 阶段：演示（介绍 ATAM、业务驱动因素、要评估的架构）→ 调查和分析（确定架构方法、生成效用树、分析架构方法）→ 测试（头脑风暴和优先场景、分析架构方法）→ 报告 ATAM。
• 风险是架构中不支持给定优先级质量属性的问题点；非风险是实现了特定优先级质量属性的优势。
• 头脑风暴投票：每个利益相关者的票数=场景总数×30%（到最近整数）。

蒸馏笔记

概念

• 质量属性：系统可测量或可测试的属性，描述系统满足利益相关者需求的程度。
• 质量属性场景：一个具体的质量属性需求，是利益相关者与系统交互的简短陈述。
• 刺激源：生成刺激的实体（人、计算机系统或其他刺激器）。
• 刺激：刺激到达系统时需要考虑的条件。
• 环境：刺激发生的条件（过载、运行等）。
• 制品：被激励的对象（整个系统或其一部分）。
• 响应：刺激到达后所采取的行动。
• 响应度量：对响应的度量方式，用于测试需求。
• 敏感点：单个质量属性的关键构件特性。
• 权衡点：影响多个质量属性的特性，即多个质量属性的敏感点。
• 风险承担者：对架构施加影响以保证自身目标实现的人（架构师、开发人员、维护人员、客户、最终用户等）。
• MTTF：平均失效等待时间；MTBF：平均失效间隔时间。
• 效用：质量属性为项目干系人带来的收益（CBAM 核心概念）。
• ABAS：基于属性的架构风格，维护 ATAM 的领域知识库，使架构设计更惯例化和可预测。

机制

• 架构的基本需求：在满足功能属性的前提下关注质量属性 → 用质量属性场景精确、定量地表达。
• ATAM 迭代改进：属性分析相互依赖 → 用敏感度分析发现折中点、通过检查假设获得属性关联 → 分析结果与需求比较后决定是否进入详细设计。
• CBAM 经济链：架构策略 →(影响)→ 质量属性响应级别 →(产生)→ 效用 →(结合成本)→ ROI →(排序)→ 策略选择。

流程

• SAAM 评估 5 步： 1. 场景开发（风险承担者协商讨论开发任务场景） 2. 架构描述（功能、结构、分配三方面；易理解、合乎语法） 3. 单个场景评估（区分直接场景和间接场景） 4. 场景交互（得出所有场景对构件影响的列表） 5. 总体评估（对场景和场景间交互总体权衡评价）
• ATAM 评估 4 阶段 8 步： | 阶段 | 步骤 | |---|---| | 演示 | 1 介绍 ATAM；2 介绍业务驱动因素；3 介绍要评估的体系结构 | | 调查和分析 | 4 确定架构方法；5 生成质量属性效用树；6 分析体系结构方法 | | 测试 | 7 头脑风暴和优先场景（投票）；8 分析架构方法（针对新出现的高优先级属性） | | 报告 | 输出：效用树、场景集、分析问题集、风险/非风险集、确定的架构方法 |
• 效用树构造：根=效用 → 二级=质量属性 → 三级=属性分类 → 叶子=质量属性场景 → 修剪（≤50 个重要场景）→ 双维度 H/M/L 排序（重要度、难易度）。
• 第 6/8 步分析四阶段（两步通用）：调查架构方法 → 创建分析问题 → 分析问题的答案 → 找出风险、非风险、敏感点和权衡点。
• CBAM 8 步： 1. 整理场景（按商业目标排序，取优先级最高的 1/3） 2. 对场景进行求精（最坏/当前/期望/最好四种响应级别） 3. 确定场景优先级（干系人投票，生成场景权值） 4. 分配效用（对四种响应级别确定效用表） 5. 形成"策略—场景—响应级别"对应关系 6. 用内插法确定期望响应级别的效用 7. 计算各架构策略的总收益 8. 按受成本限制的 ROI 选择架构策略
• AHP 五步（层次分析法，T.L.Saaty 于 20 世纪 70 年代提出）：确定总目标收集信息 → 建立多层次递阶结构 → 构造比较判断矩阵确定相对权值 → 计算合成权重总排序 → 依据结果决策。
• ALRRA（可靠性风险评估）步骤：ADL 建模 → 仿真复杂性分析 → FMEA 失效严重性分析 → 启发式定义风险因素 → 构造 CDG（组件依赖图）赋风险值 → 图遍历执行风险评估。

分类体系

• 质量属性场景关注的 6 类属性：可用性、可修改性、性能、可测试性、易用性、安全性。
• 六类场景要点（案例题直接引用）： | 属性 | 刺激源 | 刺激 | 环境典型 | 响应度量典型 | |---|---|---|---|---| | 可用性 | 系统内部/外部 | 疏忽、错误、崩溃、时间 | 正常操作、降级模式 | 可用时间、故障修复时间 | | 可修改性 | 最终用户、开发人员、系统管理员 | 增加/删除/修改功能、质量属性、容量 | 设计时/编译时/构建时/运行时 | 修改成本、影响程度 | | 性能 | 用户请求、其他系统触发 | 定期/随机/偶然事件到达 | 正常、超载模式 | 等待时间、期限、吞吐量、抖动、缺失率、数据丢失率 | | 可测试性 | 开发/验证/验收测试人员等 | 集成完成、交付系统 | 设计时/开发时/编译时/部署时 | 已执行语句百分比、出现故障概率、测试时间 | | 易用性 | 最终用户 | 学习特性、有效使用、降低错误影响 | 运行时或配置时 | 任务时间、错误数量、满意度 | | 安全性 | 正确/非正确识别的身份、内部/外部来源 | 显示数据、改变/删除数据、访问服务、降低可用性 | 在线/离线、联网/断网、有无防火墙 | 攻击检测可能性、拒绝服务下仍获得服务百分比、恢复数据 |
• 架构评估方法三类：调查问卷/检查表（依赖主观推断）、场景（ATAM/SAAM）、度量。
• ATAM 三类场景：用例场景、增长场景、探测场景。
• 风险承担者三大类：系统生产者（架构师/开发/维护/集成/测试/标准专家/性能工程师/安全专家/项目经理/产品线经理）、系统消费者（客户/最终用户/应用开发者/任务专家/系统管理员/网络管理员/技术支持人员）、其他人员（领域代表/系统设计师/设备专家）。
• 其他评估方法一览：SAEM（外部/内部质量属性评估模型）、SAABNet（贝叶斯信念网络 BBN 辅助定性评估）、SACMM（图内核度量架构修改）、SASAM（预期架构与实际架构映射比较的静态评估）、ALRRA（可靠性风险评估）、AHP（多准则决策）、COSMIC+UML（可维护性度量）。

判据

• 权衡点判据：某特性对 ≥2 个质量属性都构成敏感点 → 即为权衡点（如"应用程序嵌入的地点数量"同时影响可变性和可修改性）。
• 风险判据：该架构问题点不支持给定的优先级质量属性 → 风险；反之实现优先级属性 → 非风险。
• 直接场景 vs 间接场景（SAAM）：架构无需修改即可支持的为直接场景；需修改架构才能支持的为间接场景——间接场景的修改代价是评估依据。
• 效用树优先级对判读：(H,L)=重要且易实现；(H,M)=重要且中等难度——优先分析高 H 的场景。
• 投票数判据：票数=场景总数×30%，四舍五入取整（16 场景→5 票）。
• CBAM 场景筛选判据：只分析优先级最高的 1/3 场景。
• 健壮性 vs 容错：容错=错误时系统正确运行并内部修复；健壮性=错误时按预定方式终止执行，不能继续运行。
• 可用性 vs 可靠性辨析：可用性=正常工作时间比例；可靠性=规定条件时间内完成规定功能的能力（持续无故障）。
• ATAM 架构描述判据：基于 5 种基本结构（由 4+1 派生，逻辑视图拆分为功能结构和代码结构）+ 一组消息顺序图注解。

数据

• 效用树结构四层：树根（效用）→ 质量属性 → 属性分类 → 质量属性场景（叶子）。
• 效用树重要场景保留上限：通常不超过 50 个。
• 优先级刻度：重要性 H/M/L；实现难易度 H/M/L；组合成优先级对如 (H,L)。
• SAAM 验证应用系统：空中交通管制、嵌入式音频系统、WRCS（修正控制系统）、KWIC（根据上下文查找关键词系统）。
• SAABNet 变量三类：架构质量属性变量（可维护性、灵活性等）→ 质量属性度量准则变量（容错性、响应性等）→ 架构特征变量（继承深度、编程语言等）。
• 投票示例：16 个场景 × 30% = 4.8 ≈ 5 票/人。

案例

• ATAM 实践完整案例：Event 框架的胡佛（Hoover）架构 vs 银行（Banking）架构对比评估，最终用户/架构师/应用程序开发人员三方利益相关者参与（8.3 节）。
• 案例结论梗概：胡佛架构=框架与应用分离、事件管理器封装在框架内 → 可变性/可靠性/概念一致性/功能性/可修改性均为非风险，无权衡点；银行架构=事件管理器暴露给应用程序、组件高度相互依赖 → 可变性/概念一致性/可修改性为风险，安全性/性能也是风险，权衡点为"应用程序嵌入的地点数量"和"处理任务所涉及的组件数量"。

易错点 / 边界情况

• 运行期质量属性中"安全性"的表述：同时兼顾向合法用户提供服务与阻止非授权使用——两个方向缺一不可（简答题采分点）。
• 鲁棒性=健壮性=容错性（教材对鲁棒性的三种称呼），但可靠性内部的"容错"含义更窄（错误时继续正确运行），注意语境。
• 可移植性属于开发期质量属性之一，同时也是可修改性的 4 个方面之一——两处出现不矛盾。
• ATAM 关注 4 类属性是"性能、安全性、可修改性、可用性"，不含可靠性和易用性——考题常混入"可靠性"作干扰项。
• 效用树叶子节点是"质量属性场景"，不是质量属性本身；优先级对第一维是重要性、第二维是实现难易度，顺序不能反。
• SAAM 的主要输入：问题描述、需求声明和架构描述；架构描述针对"最后版本"但早于详细设计。
• CBAM 不是独立评估方法，它复用 ATAM 结果做经济决策；先 ATAM 后 CBAM 的顺序常考。
• 敏感点、权衡点都是"架构决策/特性"层面的概念，风险/非风险是"架构问题/优势"层面的概念，四者并列出现在 ATAM 第 6/8 步。
• 互操作性在 GB/T 16260.1 中归入"功能性"维度（互操作性是功能性的子特性），而运行期质量属性中互操作性单独列出——两套体系不要混。
• 头脑风暴三类场景与 ATAM 三类场景对应：用例场景（最终用户）、增长场景（架构发展方式）、探索性/探测场景（极端增长/过载）。
• 报告 ATAM 的产出物 5 项：效用树、生成场景集、分析问题集、风险和非风险集、确定的架构方法。