📅 日期：2026-05-15
📚 科目：软件设计师 · 系统开发基础
🏷️ 标签： 软件架构架构评估ATAM 质量属性案例分析
⭐ 重要度：高频考点（选择题 + 案例分析 + 论文）
架构风格 = 词汇表（一组构件和连接件的类型）+ 约束（构件和连接件的组合规则）+ 语义（构件和连接件的含义）
常见架构风格：
| 风格 | 特点 | 典型应用 |
|---|---|---|
| 管道-过滤器 | 每个构件独立，数据流驱动 | 编译器、Unix管道 |
| 数据抽象与面向对象 | 封装、继承、多态 | OOP系统 |
| 事件驱动（隐式调用） | 构件通过事件交互，松耦合 | GUI框架、消息队列 |
| 层次结构 | 每层只与相邻层交互 | OSI模型、三层架构 |
| 仓库风格（数据库系统） | 共享数据存储为中心 | 数据库、黑板系统 |
| C/S & B/S | 客户端-服务器 / 浏览器-服务器 | Web应用、分布式系统 |
| 作用 | 说明 |
|---|---|
| 交流手段 | 项目干系人之间的沟通桥梁 |
| 可传递可复用 | 通过研究架构可预测软件质量 |
| 原型设计 | 有助于循序渐进的原型开发 |
架构设计是降低成本、改进质量、按时按需交付的关键因素。
需求分析→ 设计→ 实现→ 构件组装→ 部署→ 后开发
| 阶段 | 核心要点 | 补充说明 |
|---|---|---|
| 需求分析 | 根据需求构建SA模型 | 模型必须可追溯到需求 |
| ★ 设计 | SA研究最核心阶段 | 使用ADL和4+1视图描述架构 |
| 实现 | 根据设计进行代码实现 | 架构约束代码结构 |
| 构件组装 | 高层次实现系统 | 强调集成效率和正确性 |
| 部署 | SA提供高层视图指导部署 | 映射到物理节点 |
| 后开发 | 系统结构动态变化 | 支持结构恢复、重建、演化 |
从5个视角描述软件架构，不同角色关注不同视图。
| 视图 | 面向对象 | 关注点 | 核心内容 | 补充举例 |
|---|---|---|---|---|
| 逻辑视图 | 用户/设计者 | 功能需求 | 类、对象 | 用例图、类图、状态图 |
| 开发视图 | 程序员 | 代码结构 | 配置、装配 | 组件图、包图、模块划分 |
| 进程视图 | 系统集成人员 | 运行时行为 | 并发、性能、吞吐量、可伸缩性 | 活动图、进程/线程模型 |
| 物理视图 | 系统工程师 | 部署结构 | 硬件节点、网络拓扑、部署方式 | 部署图、网络拓扑图 |
| ★ 用例视图（场景） | 分析/测试人员 | 功能场景 | 驱动其他4个视图 | 用例图、用户故事 |
用例视图是核心，驱动其他4个视图。这是选择题高频考点！
不同角色看不同视图 → 这是多视图存在的根本原因。
4+1视图不是孤立的，各视图之间存在映射关系：
定义：一种形式化语言，为软件系统的概念体系结构提供具体的语法和概念框架。
| 要素 | 定义 | 类比 | UML对应 |
|---|---|---|---|
| 构件（Component） | 计算或数据存储单元 | 房间的墙壁 | 类、组件、包 |
| 连接件（Connector） | 构件之间交互的构造块及规则 | 房间的门和走廊 | 接口、依赖、消息传递 |
| 架构配置（Configuration） | 构件与连接件的链接图 | 房间的平面图 | 部署图、组件图 |
| 对比维度 | ADL | UML |
|---|---|---|
| 侧重点 | 架构级抽象（构件+连接件） | 详细设计级（类、方法、属性） |
| 形式化程度 | 高度形式化，支持分析和验证 | 半形式化，偏重可视化建模 |
| 连接件 | 一等实体，有独立语义 | 关系是二等概念，无独立语义 |
| 适用范围 | 架构分析和评估 | 全生命周期建模 |
| 工具支持 | 较少，学术为主 | 丰富，工业界广泛使用 |
| ADL | 特点 | 适用场景 |
|---|---|---|
| C2SADL | 基于组件和消息传递 | GUI系统、客户端应用 |
| Wright | 支持分布式和并发系统建模 | 分布式系统、并发系统 |
| ACME | 架构互换的通用描述语言 | 不同ADL之间的架构交换 |
| UniCon | 基于组件和连接 | 组件复用系统 |
| Rapide | 基于事件的模拟 | 事件驱动系统、行为模拟 |
| 质量属性 | 定义 | 衡量指标 | 实现手段 | 典型场景 |
|---|---|---|---|---|
| 性能 | 系统响应速度和处理能力 | 响应时间、吞吐率、并发数 | 缓存、负载均衡、异步处理、CDN | 用户请求页面在2秒内返回 |
| 可用性 | 正常运行时间比例和故障恢复能力 | 可用率（99.9%）、MTBF、MTTR | 冗余部署、故障转移、健康检查、熔断 | 系统全年可用时间不低于99.9% |
| 安全性 | 阻止非授权访问和抵御攻击的能力 | 非授权访问阻止率、漏洞数 | 认证授权、加密传输、防火墙、WAF | 防止SQL注入和XSS攻击 |
| 可修改性 | 系统进行变更所需的代价 | 变更成本、变更时间、影响范围 | 松耦合、模块化、配置化、接口抽象 | 新增支付方式只需修改配置 |
| 属性 | 度量公式 | 说明 |
|---|---|---|
| 可用性 | MTBF / (MTBF + MTTR) × 100% | MTBF=平均故障间隔，MTTR=平均修复时间 |
| 性能 | 响应时间、吞吐量（TPS/QPS） | TPS=每秒事务数，QPS=每秒查询数 |
| 可修改性 | 变更影响的模块数 / 总模块数 | 影响范围越小，可修改性越好 |
| 安全性 | 攻击成功率、漏洞修复时间 | 攻击成功率越低越好 |
关注开发和维护阶段的质量特征
| 属性 | 含义 |
|---|---|
| 易理解性 | 代码和架构容易被开发者理解 |
| 可扩展性 | 容易添加新功能 |
| 可重用性 | 组件可以在其他系统中复用 |
| 可测试性 | 容易编写和执行测试 |
| 可维护性 | 容易修复缺陷 |
| 可移植性 | 容易迁移到新环境 |
关注系统运行阶段的质量特征
| 属性 | 含义 |
|---|---|
| 性能 | 响应速度和处理能力 |
| 安全性 | 抵御攻击的能力 |
| 可伸缩性 | 应对负载增长的能力 |
| 互操作性 | 与其他系统交互的能力 |
| 可靠性 | 在规定条件下完成功能的能力 |
| 可用性 | 正常运行时间比例 |
| 鲁棒性 | 在异常条件下继续运行的能力 |
开发期："理扩重测维移"（理解、扩展、重用、测试、维护、移植）
运行期："性安伸互Rel可鲁"（性能、安全、伸缩、互操作、可靠性、可用性、鲁棒性）
| 对比 | 可靠性 | 可用性 |
|---|---|---|
| 定义 | 在规定条件和时间内完成功能的能力 | 系统处于可正常使用状态的时间比例 |
| 关注点 | 是否正确执行功能 | 是否能执行功能 |
| 度量 | MTBF（平均故障间隔时间） | MTBF/(MTBF+MTTR) |
| 举例 | 系统运行不出错 | 系统挂了能在5分钟内恢复 |
质量效用树是ATAM方法中用于组织和优先级排序质量属性场景的工具。
结构：树根（系统目标）→ 质量属性 → 细分类别 → 具体场景
每个叶子节点（场景）需要标注两个维度：
| 维度 | 含义 | 标注 |
|---|---|---|
| 重要性 | 该场景对系统成功的重要程度 | H（高）/ M（中）/ L（低） |
| 难易度 | 实现该场景的困难程度 | H（难）/ M（中）/ L（易） |
优先级策略：高重要性 + 高难度的场景优先评估（风险最大）
标注格式：(重要性, 难易度)，如 (H, H) 表示最重要且最难实现
这四个概念是案例分析题的必考点，必须能准确识别和区分。
| 概念 | 定义 | 关键词 | 识别技巧 | 示例 |
|---|---|---|---|---|
| 风险点 | 潜在的、存在问题的架构决策带来的隐患 | 隐患、问题、可能 | 找"可能出问题"的决策 | 单台数据库服务器（单点故障）、使用不成熟的新技术 |
| 非风险点 | 不会带来隐患的可接受决策 | 可接受、安全、成熟 | 找"合理、稳妥"的决策 | 采用Spring Boot框架、使用MySQL主从复制 |
| 敏感点 | 实现某种特定质量属性，构件所具有的特性 | 单一质量属性、特定 | 只影响一个属性 | 数据库索引策略（只影响性能）、加密算法选择（只影响安全性） |
| 权衡点 | 影响多个质量属性的特性（多个敏感点的交集） | 多个质量属性、折中 | 同时影响多个属性 | 缓存策略（影响性能+一致性）、日志级别（影响可维护性+性能） |
| 维度 | 敏感点 | 权衡点 |
|---|---|---|
| 影响范围 | 只影响一个质量属性 | 影响多个质量属性 |
| 关系 | 单一特性 | 多个敏感点的交集 |
| 举例 | 索引策略→性能 | 缓存策略→性能+一致性 |
| 维度 | 风险点 | 敏感点 |
|---|---|---|
| 性质 | 隐患（有问题的决策） | 特性（构件的属性） |
| 视角 | 从负面角度看 | 从技术特性角度看 |
| 举例 | 单点故障是风险 | 索引策略是敏感点 |
风险点 = 有问题的决策（隐患）
非风险点 = 没问题的决策（安全）
敏感点 = 影响"一个"质量属性
权衡点 = 影响"多个"质量属性 = 多个敏感点的交集
权衡点是ATAM方法的核心产出物！
| 场景描述 | 判断 | 理由 |
|---|---|---|
| 系统采用单台数据库服务器 | 风险点 | 单点故障，数据库挂了全系统不可用 |
| 系统采用成熟的微服务框架 | 非风险点 | 成熟技术，风险低 |
| 使用Redis作为缓存层 | 非风险点 | 成熟的缓存方案 |
| 数据库读写分离策略 | 敏感点 | 只影响性能（读写分离提升读性能） |
| 数据库索引设计策略 | 敏感点 | 只影响查询性能 |
| 数据加密传输策略 | 敏感点 | 只影响安全性 |
| 缓存数据一致性策略 | 权衡点 | 影响性能（缓存快）+ 一致性（缓存可能过期） |
| 系统日志记录级别 | 权衡点 | 影响可维护性（日志越多越好排查）+ 性能（日志越多越慢） |
| 数据同步频率 | 权衡点 | 影响数据一致性 + 网络性能 |
| 系统认证方式选择 | 权衡点 | 影响安全性（强认证更安全）+ 性能（强认证更慢）+ 可用性 |
| 使用未经验证的第三方组件 | 风险点 | 不成熟技术可能带来安全和稳定性隐患 |
| 系统采用负载均衡部署 | 非风险点 | 成熟方案，提升可用性和性能 |
| 方法 | 全称 | 侧重点 | 复杂度 | 核心产出 | 关系 |
|---|---|---|---|---|---|
| SAAM | Software Architecture Analysis Method | 可修改性 | 低 | 可修改性评估结果 | 最早的方法 |
| ATAM ★ | Architecture Tradeoff Analysis Method | 多质量属性评价与折中 | 中 | 敏感点、权衡点、风险点 | 在SAAM基础上发展 |
| CBAM | Cost-Benefit Analysis Method | 成本效益分析 | 高 | 性价比最优方案 | 在ATAM基础上增加成本 |
SAAM → ATAM → CBAM（复杂度递增，评估维度递增）
SAAM 只看可修改性 → ATAM 看多个质量属性 → ATAM + 成本分析 = CBAM
SAAM 是最早的架构评估方法，最初只用于分析可修改性，后来扩展到其他质量属性。
| 步骤 | 内容 | 详细说明 |
|---|---|---|
| ① 形成场景 | 收集变更场景 | 从干系人处获取可能的系统变更场景（如需求变更、平台迁移） |
| ② 描述架构 | 用视图描述架构 | 用适当的视图（通常是开发视图）描述候选架构 |
| ③ 场景分类 | 区分直接/间接场景 | 直接场景：不需要修改架构即可实现 间接场景：需要修改架构才能实现 |
| ④ 场景评估 | 评估间接场景影响 | 分析间接场景需要修改哪些构件，评估修改代价 |
| ⑤ 场景交互 | 发现场景间交互 | 多个间接场景影响同一构件 → 场景交互（变更冲突） |
| ⑥ 总体评估 | 给出评估结论 | 综合所有场景的评估结果，判断架构对可修改性的支持程度 |
不需要修改架构就能实现的场景
说明架构已经支持该变更
例：系统已预留扩展接口，新增支付方式无需改动架构
需要修改架构才能实现的场景
说明架构不支持该变更，需要额外工作
例：从单体架构迁移到微服务，需要大量架构修改
ATAM是案例分析题的必考内容，必须掌握四个阶段、8个步骤、以及核心产出。
评估对象：性能、可用性、安全性、可修改性（四大质量属性）
| 阶段 | 步骤 | 内容 | 详细说明 | 参与者 |
|---|---|---|---|---|
| 第一阶段 场景和需求收集 |
① 收集场景 | 从干系人获取使用场景 | 通过头脑风暴等方式，收集所有干系人关心的场景，包括使用场景、变更场景、异常场景 | 所有干系人 |
| ② 收集需求/约束/环境 | 明确系统约束条件 | 收集系统的功能需求、质量属性需求、设计约束和环境约束 | 架构师、客户 | |
| 第二阶段 架构视图和场景实现 |
③ 描述架构视图 | 用4+1视图等描述架构 | 架构师用4+1视图、ADL或其他方式描述当前架构方案 | 架构师 |
| ④ 实现场景 | 将场景映射到架构上 | 将第一步收集的场景映射到架构视图上，分析每个场景如何在架构中实现 | 架构师 + 分析师 | |
| 第三阶段 属性模型构造和分析 |
⑤ 特定属性分析 | 构造质量属性模型 | 针对关键质量属性（如性能、可用性），构造分析模型（如排队模型、故障树） | 分析团队 |
| ⑥ 单一理论分析 | 评估单一质量属性 | 用定量或定性方法分析单个质量属性的满足程度 | 分析团队 | |
| 第四阶段 折中 |
⑦ 标志敏感度 | 识别敏感点 | 找出对质量属性有显著影响的架构决策（敏感点） | 全体参与者 |
| ⑧ 标志折中 | 识别权衡点 | 找出同时影响多个质量属性的架构决策（权衡点），这是ATAM的核心产出 | 全体参与者 |
| 产出物 | 说明 |
|---|---|
| 敏感点列表 | 影响单一质量属性的架构决策 |
| 权衡点列表 | 影响多个质量属性的架构决策（最重要产出） |
| 风险点列表 | 可能带来问题的架构决策 |
| 非风险点列表 | 可接受的、安全的架构决策 |
| 质量效用树 | 质量属性的层次化组织和优先级排序 |
| 风险主题 | 由多个风险点归纳出的系统性风险 |
CBAM在ATAM基础上引入成本效益分析，帮助在多个架构方案中选择性价比最高的方案。
| 维度 | 说明 |
|---|---|
| 核心思想 | 不仅评估质量属性，还考虑实现成本 |
| 分析对象 | ATAM识别出的权衡点和敏感点 |
| 关键公式 | 净收益 = Σ(质量属性收益 × 权重) - 实现成本 |
| 决策依据 | 选择净收益最大（性价比最高）的架构方案 |
| 适用场景 | 有多个候选架构方案需要做选择时 |
| 方式 | 说明 | 优点 | 缺点 |
|---|---|---|---|
| 基于调查问卷 | 通过问卷收集干系人意见 | 简单易行，覆盖面广 | 主观性强，不够精确 |
| 基于度量 | 通过量化指标评估 | 客观精确，可对比 | 度量指标定义困难 |
| ★ 基于场景 | 通过具体场景评估质量属性 | 最常用，贴近实际 | 场景选取影响评估结果 |
场景 = 从风险承担者角度与系统交互的简短描述。每个场景由六个要素构成。
| 要素 | 定义 | 示例 | 记忆要点 |
|---|---|---|---|
| 刺激源 | 生成刺激的实体 | 用户、外部系统、定时任务 | 谁发起的？ |
| 刺激 | 在某些条件下发生的事件 | 请求、故障、攻击、超时 | 发生了什么？ |
| 制品 | 被刺激的对象 | 整个系统或某个组件 | 影响了谁？ |
| 响应 | 刺激到达后采取的行动 | 处理请求、记录日志、触发故障转移 | 怎么处理的？ |
| 响应度量 | 可度量的响应指标 | 响应时间、恢复时间、成功率 | 效果如何衡量？ |
| 环境 | 刺激发生时系统所处状态 | 正常操作、降级操作、过载 | 在什么条件下？ |
源（谁）→ 激（事）→ 品（谁受影响）→ 应（怎么处理）→ 量（怎么衡量）→ 境（什么条件）
| 要素 | 内容 |
|---|---|
| 刺激源 | 用户 |
| 刺激 | 发起商品搜索请求 |
| 环境 | 正常操作，1000并发用户 |
| 制品 | 搜索服务 |
| 响应 | 返回搜索结果列表 |
| 响应度量 | 95%请求响应时间 < 2秒 |
| 要素 | 内容 |
|---|---|
| 刺激源 | 系统内部（硬件/软件故障） |
| 刺激 | 数据库服务器崩溃 |
| 环境 | 正常操作 |
| 制品 | 数据库服务 |
| 响应 | 检测故障 → 记录日志 → 切换到备用数据库 |
| 响应度量 | 故障恢复时间 < 30秒，系统可用率 > 99.9% |
| 要素 | 内容 |
|---|---|
| 刺激源 | 外部攻击者 |
| 刺激 | 发起SQL注入攻击 |
| 环境 | 正常操作 |
| 制品 | Web应用的数据库查询模块 |
| 响应 | WAF检测并拦截恶意请求 → 记录攻击日志 |
| 响应度量 | 攻击阻止率 > 99%，无数据泄露 |
| 要素 | 内容 |
|---|---|
| 刺激源 | 开发人员 |
| 刺激 | 需要新增一种支付方式（微信支付） |
| 环境 | 设计阶段 |
| 制品 | 支付模块 |
| 响应 | 修改支付接口实现，不影响其他模块 |
| 响应度量 | 修改涉及 < 3个文件，2人天内完成 |
| 分类 | 说明 | 举例 |
|---|---|---|
| 用例场景 | 正常的功能使用场景 | 用户下单、查询订单 |
| 变更场景 | 系统可能发生的变化 | 新增功能、更换数据库 |
| 异常场景 | 系统可能遇到的异常 | 服务器宕机、网络中断、遭受攻击 |
| 增长场景 | 系统负载增长的情况 | 用户量从1万增长到100万 |
案例分析题通常给出一个系统描述，要求识别风险点、敏感点、权衡点，并说明使用了哪种评估方法。
XXX是一个风险点，因为可能导致YYY问题XXX是一个非风险点，因为采用了成熟的技术/方案，风险较低XXX是一个敏感点，它影响系统的YYY属性XXX是一个权衡点，它同时影响系统的YYY属性和ZZZ属性，需要在两者之间进行权衡本项目采用ATAM方法进行架构评估，具体过程如下：
最终产出：质量效用树、敏感点列表、权衡点列表、风险点列表、非风险点列表。
| 题目场景 | 推荐方法 | 理由 |
|---|---|---|
| 只关注可修改性评估 | SAAM | SAAM最早用于可修改性评估，方法简单直接 |
| 需要评估多个质量属性及其权衡 | ATAM | ATAM支持多属性评估，能识别敏感点和权衡点 |
| 需要在多个方案中选择性价比最高的 | CBAM | CBAM在ATAM基础上增加成本效益分析 |
| 初步评估，时间有限 | SAAM | SAAM复杂度低，快速评估 |
| 全面评估，有充足时间 | ATAM | ATAM是业界最全面的架构评估方法 |
场景：当【刺激源】在【环境】下对【制品】产生【刺激】时，系统应【响应】，度量指标为【响应度量】。
示例：当外部攻击者在正常操作下对Web应用发起SQL注入攻击时，系统应检测并拦截攻击请求、记录攻击日志，度量指标为攻击阻止率 > 99%。
| # | 考点 | 答案 |
|---|---|---|
| 1 | 4+1视图中哪个视图驱动其他视图？ | 用例视图 |
| 2 | ADL的三个基本要素是什么？ | 构件、连接件、架构配置 |
| 3 | SAAM最早用于评估什么质量属性？ | 可修改性 |
| 4 | ATAM针对哪四大质量属性？ | 性能、可用性、安全性、可修改性 |
| 5 | CBAM在ATAM基础上增加了什么？ | 成本效益分析 |
| 6 | 权衡点的定义是什么？ | 影响多个质量属性的特性 |
| 7 | 敏感点和权衡点的区别？ | 敏感点影响一个属性，权衡点影响多个 |
| 8 | ATAM的核心产出是什么？ | 权衡点列表 |
| 9 | 架构风格定义了什么？ | 一个词汇表和一组约束 |
| 10 | 哪种评估方式最常用？ | 基于场景的评估 |
| # | 考点 | 答题要点 |
|---|---|---|
| 1 | 识别风险点、敏感点、权衡点、非风险点 | 按概念定义逐一识别，给出理由 |
| 2 | ATAM的四个阶段和8个步骤 | 场景收集→视图实现→属性分析→折中 |
| 3 | 质量效用树的构建和优先级确定 | 先按重要性，再按难易度；(H,H)优先 |
| 4 | 根据场景描述判断质量属性类型 | 性能→速度；可用→正常运行；安全→防护；可修改→变更代价 |
| 5 | 选择合适的架构评估方法 | 可修改→SAAM；多属性→ATAM；成本→CBAM |
| 6 | 构造质量属性场景 | 六要素：刺激源、刺激、环境、制品、响应、响应度量 |
"4+1视图用例驱，ADL有三件，ATAM四阶段，敏感权衡要分清"
| 考点 | 口诀 | 解释 |
|---|---|---|
| 4+1视图 | "用例驱动逻辑进程开发物理" | 用例视图驱动其他4个视图 |
| ADL三要素 | "构件连接配置" | 构件+连接件+架构配置 |
| ATAM四阶段 | "场视属折" | 场景收集→视图实现→属性分析→折中 |
| 敏感vs权衡 | "一敏多权" | 敏感点影响一个属性，权衡点影响多个 |
| 评估方法 | "SA可修，AT多属，CB成本" | SAAM可修改性，ATAM多属性，CBAM成本 |
| 开发期属性 | "理扩重测维移" | 理解、扩展、重用、测试、维护、移植 |
| 运行期属性 | "性安伸互Rel可鲁" | 性能、安全、伸缩、互操作、可靠性、可用性、鲁棒性 |
| 场景六要素 | "源激品应量境" | 刺激源、刺激、制品、响应、响应度量、环境 |
📚 相关笔记链接
[[软件架构的概念]] [[4+1视图]] [[ADL]] [[架构评估]] [[ATAM]] [[SAAM]] [[CBAM]] [[质量属性]] [[敏感点]] [[权衡点]]
📅 生成日期：2026-05-15 | 📝 基于架构描述与评估总结.md补充整理