【iSAQB软件架构】架构分析-ATAM法

除了审查、单元测试、验收和回归测试外，架构分析是一种重要的技术，在软件架构师的日常工作中为其提供支持。它能够评估软件架构的质量。除了使用合适的质量模型和定义功能流程外，架构分析最重要的前提条件之一是需求分析和架构目标分析。
架构分析的结果可以根据特定的质量标准进行评估，如健壮性、可用性或安全性。这些标准必须在需求规范的早期阶段进行定义和优先排序。

ATAM法

ATAM 代表架构权衡分析方法。它是一种对架构进行定性评估的有条理的方法，并有助于为计划中的系统选择合适的架构。ATAM 是由卡内基梅隆大学的软件工程研究所（SEI）开发的。
ATAM 是架构评估领域的领先方法。

ATAM的优势

• 明确的质量要求
• 改进架构文档
• 一个文档化的架构决策的依据
• 早期识别的风险
• 改善相关方之间的沟通

ATAM的前提条件

• 系统架构师(或技术联系人)
• 架构文档
• 负责客户功能的联系人

评估程序

ATAM将软件架构的评估分为四个阶段(参见下图)。

评估流程图：
架构评估的第一步涉及客户或委托方确定该流程的相关利益相关者。这通常是一个小团队，至少包括（客户）管理层和项目管理层。

在定义评估目标之前，启动阶段包括向利益相关者简要介绍评估方法。所有参与者都应该清楚，目的是确定风险（和非风险）并概述适当的措施。客户提出用于评估的系统的业务目标。

然后，负责的架构师应该简要介绍系统的架构。此介绍包括系统的完整上下文（包括所有相邻系统）、顶级构建块以及最重要用例或变更场景的运行时视图。

利益相关者随后应编制所有重要的质量要求，并在质量树中按层次组织它们。为使评估团队能够开始工作，他们还需要描述最重要质量目标的场景。

在对这些场景进行分析之后，决策应分为四个方面:

• 风险

风险是架构的元素，根据情况的发展，可能危及业务目标的实现, 并导致其他问题。

• 敏感点

在架构的“敏感点”，即使是微小的变化也可能产生广泛的影响。这些是架构中实现质量标准的关键组件。

• 妥协

权衡指定设计决策是否(或如何)相互影响多个质量特性。

• 非风险

哪些场景在所有情况下都能实现(即无风险)?

风险被分类为表明它们可能如何危及业务目标的主题。

图ATAM(来源:软件工程研究所) :

创建质量树

质量树对系统特定或产品特定的质量要求进行分层细化。主要标准位于树的顶部，而更具体的要求则在底部。质量树的“叶子”是场景（见下面的“场景”部分），它们以尽可能具体和详细的方式描述单个特征。

主要利益相关者根据各自的业务收益（见图 ）对特征及其场景进行优先级排序，架构师也根据其技术复杂性进行优先级排序。这在实际评估期间为架构师提供了具有优先级的场景。

对质量特性 1 的评估通常由架构师与一个小组一起按照确定的优先级顺序进行。
这个过程涉及回答一系列不同的问题：

• 为了实现一个场景，做出了哪些架构决策?
• 哪种架构方法支持实现该场景?
• 达成了哪些妥协?
• 是否影响了其他质量特性或架构目标？
• 存在哪些风险?
• 哪些分析、原型或评估支持此决策？
  完成评估后，你应该对以下内容有一个很好的了解:
• 关于定义的场景和特定架构目标的架构质量
• 与实现最重要场景相关的风险
• 消除风险的潜在措施
• 可以无风险实现的场景

场景

在 ATAM 环境中，质量特性通过场景来描述（基于场景的架构评估）。这些场景描述了系统在特定情况下的反应，它们表征了利益相关者与系统的交互，并且它们能够评估实现这些质量特性所涉及的风险。它们用于精确指定项目相关方对特定质量特性的理解 - 例如，“可靠性”对所有相关人员实际意味着什么。

场景类型

场景类型包括:

• 应用场景。这些描述了系统在运行时对特定刺激做出的反应。它们包括用于描述效率和/或性能的场景。
• 变更场景描述了在系统或其直接环境发生变化的情况下会发生什么——例如，如果实现了一个附加的功能。
• 压力或限制场景描述了系统在极端情况下的反应, 例如，电源故障。

场景的元素

场景通常由以下主要元素组成（引自 [HS11]。原始列表来自 [BCK03]）：

• 触发器是由于触发利益相关者与系统之间的特定交互而发生的特定事件 - 例如，当用户调用函数或系统组件发生故障时。
• 源描述了触发器的来源。
• 环境描述了触发器发生时系统的状态。
• 还有一个受触发器影响的系统工件。
• 系统会提供一个响应，作为对触发的反应。
• 响应措施是一种用于测量/评估系统响应质量的评估模型。

如下图，提供了场景组件元素的概述。

示例场景

以下是一些使用场景来详细说明质量要求的示例。
应用场景

• 在系统正常运行期间，对价格查询的响应必须在 5 秒内显示给最终用户。如果系统在高负载下运行（例如，年终业务），响应可能最多需要 15 秒，但在这种情况下，必须事先向用户显示相应的消息。
• 首次使用系统时，没有先验知识的用户应能够在 15 分钟内找到并使用所需的功能。
• 如果在输入字段中输入无效或不正确的数据，系统必须输出相应的消息文本并继续正常工作。
  变更场景
• 新功能的开发必须在30个工时内完成。
• 必须能够在少于 30 个人工日对新的浏览器版本的支持进行编程和测试。
  压力或极限场景
• 在正常运行时出现CPU中断的情况下，备用系统必须在15分钟内可用。
• 当数据库系统发生故障时，系统将按照规定的性能和容量继续运行。

下表列出了一些性能场景的示例元素。

可靠性场景的部分要素示例如下表所示。

以下是进一步的深入分析：

概述

ATAM 是 Architecture Tradeoff Analysis Method（架构权衡分析方法）的缩写。

关键解读：

1. 核心目的
   由卡耐基梅隆大学软件工程研究所（SEI）开发，用于系统化评估软件架构，聚焦于识别：

   • 质量属性之间的权衡点（Tradeoffs，如性能 vs 安全）
   • 关键风险点（Risks）
   • 架构决策的敏感点（Sensitivity Points）

2. 名称内涵

   • Tradeoff：强调架构决策的本质是质量属性的权衡（例如：提高安全性可能降低性能）。
   • Analysis：通过结构化流程（如业务驱动→质量树→场景分析）实现客观评估。

3. 与类似方法的区别

   方法	全称	核心焦点
   ATAM	Architecture Tradeoff Analysis Method	质量属性权衡与风险分析
   SAAM	Software Architecture Analysis Method	场景驱动的功能可扩展性
   CBAM	Cost Benefit Analysis Method	架构决策的经济效益量化

✅ ATAM 的核心输出：

• 风险列表（例如：单点故障导致可用性不足）
• 敏感点（例如：缓存大小直接影响延迟）
• 权衡点（例如：启用加密降低 20% 吞吐量）
  这些结果直接驱动架构优化和业务决策。

ATAM

ATAM 四阶段流程

1. 准备阶段（Preparation）

   • 介绍ATAM方法、业务驱动力（Business Drivers）和架构概述
   • 目标：对齐评估目标，确保所有参与者理解背景

2. 启动阶段（Kickoff Phase）

   • 识别架构关键方法（Architectural Approaches）
   • 构建质量属性树（Quality Tree）和场景（Scenarios）
   • 初步分析架构方法
   • 目标：聚焦核心质量属性和风险点

3. 评估阶段（Evaluation Phase）

   • 场景的头脑风暴与优先级排序
   • 深度分析架构方法（结合场景验证）
   • 目标：通过场景测试架构决策的可行性

4. 结论阶段（Conclusion）

   • 呈现评估结果（风险、敏感点、权衡点等）
   • 目标：输出可行动的架构改进建议

决策的四个方面

展示了业务驱动力如何转化为风险分析结果，决策需从以下四方面分类：

1. 风险（Risks）

   • 定义：可能阻碍质量目标达成的架构决策。
   • 来源：敏感点（Sensitivity Points）未妥善处理、权衡点（Trade-offs）失衡。
   • 示例：高并发场景下，数据库分片策略可能导致事务一致性风险。

2. 非风险（Non-Risks）

   • 定义：已验证无负面影响的决策或场景。
   • 价值：明确无需投入资源的领域，避免过度优化。
   • 示例：身份验证模块已通过压力测试，满足万级QPS要求。

3. 敏感点（Sensitivity Points）

   • 定义：影响单一质量属性的关键架构参数。
   • 分析重点：调整该点如何专项优化/劣化特定质量属性。
   • 示例：缓存失效时间（TTL）延长 → 提升数据读取性能，但降低数据新鲜度。

4. 权衡点（Trade-offs）

   • 定义：影响多个质量属性的决策，需平衡冲突。
   • 分析重点：揭示属性间的竞争关系（如安全 vs 性能）。
   • 示例：启用全量数据加密 → 提升安全性，但降低系统吞吐量。

场景分析后的决策流程

关键实践建议

1. 风险驱动决策
   • 优先处理高风险项（如：核心流程单点故障）。
2. 量化权衡点
   • 用数据支持决策（如：加密导致延迟增加 15%，评估业务容忍度）。
3. 敏感点监控
   • 将敏感点转化为可配置参数（如：动态调整线程池大小）。
4. 非风险归档
   • 记录非风险结论，避免团队重复讨论。

✅ ATAM核心价值：将模糊的“架构质量”转化为可管理的 风险、敏感点、权衡点，为决策提供系统性证据链。结论阶段的输出直接对应决策中的最终产物（Risks），形成闭环。

质量树

质量树（Quality Tree）是ATAM方法中将抽象质量属性转化为可评估场景的核心工具。以下是完整构建指南和示例解析：

质量树构建四步法

步骤1：定义顶层质量属性（业务驱动级）

• 来源：业务目标、利益相关者诉求
• 要求：覆盖系统关键质量维度（效率、可用性、可维护性等）
• 附件2示例：

步骤2：分解为具体质量特性（技术实现级）

• 原则：
  • 每个顶层属性拆解为 2~5个可测量子特性
  • 避免重叠（如“延迟”与“吞吐量”是效率的两个独立维度）
• 附件1示例：
  • 效率 → {延迟, 吞吐量}
  • 可维护性 → {新中间件集成, 新产品类别开发}

步骤3：绑定可验证场景（叶子节点）

• 关键规则：
  • 场景必须量化（含数值/条件）
  • 一个子特性对应1~N个场景
• 附件1&2场景示例：

  质量特性	场景	量化指标
  延迟 (Latency)	支持1000+并发用户	响应时间 < 1秒
  新产品开发 (Maintainability)	新增产品类别的实现周期	< 30人天(PT/PM)
  故障容错 (Availability)	硬件故障恢复时间	未提供（需补充如 <5分钟）

步骤4：双维度优先级排序

• 业务优先级（利益相关者评定）：
  • 标准：对业务目标的贡献度（如收入增长、客户满意度）
  • 附件2示例：效率优先级=3（最高）
• 技术优先级（架构师评定）：
  • 标准：实现复杂度/风险（如技术债务、依赖难度）
  • 附件2示例：效率技术优先级=1（低难度）

质量树在ATAM中的作用

1. 风险识别
   • 低业务优先级+高技术复杂度 = 高风险点（如附件2中“新中间件”优先级2+技术复杂度1）
2. 决策依据
   • 高业务优先级场景（效率=3）驱动架构资源倾斜
3. 冲突暴露
   • 例：高吞吐量（效率）与全量数据加密（安全）的资源竞争

完整质量树示例（整合附件1&2）

# 质量属性树 (Quality Tree)

## 1. 效率 (Efficiency) [业务优先级: 3, 技术优先级: 1]
   - **1.1 延迟 (Latency)**  
     - 场景: 支持1000+并发用户时，API响应时间 < 1秒  
   - **1.2 吞吐量 (Throughput)**  
     - 场景: 订单处理峰值 ≥ 500 TPS

## 2. 可维护性 (Maintainability) [业务优先级: 2, 技术优先级: 1]
   - **2.1 新中间件集成**  
     - 场景: 接入Kafka消息队列的实施周期 ≤ 15人天  
   - **2.2 新产品开发**  
     - 场景: 新增支付渠道的实现周期 < 30人天

## 3. 可用性 (Availability) [业务优先级: 3, 技术优先级: 2]
   - **3.1 硬件故障恢复**  
     - 场景: 服务器宕机后，系统自动切换 ≤ 3分钟  
   - **3.2 运维故障恢复**  
     - 场景: 数据库误操作后，数据回滚 ≤ 10分钟

构建陷阱与规避策略

✅ 最佳实践：用颜色标记优先级（红=高业务+高技术），在ATAM评估阶段聚焦红色区域。质量树的最终输出应直接链接到风险主题（Risk Themes），形成“业务驱动→质量需求→风险”的证据链。

场景

在ATAM（架构权衡分析方法）中，场景（Scenarios） 是将抽象质量属性转化为可评估、可测试的具体实例的核心工具。基于您提供的场景元素模板（附件）和场景类型分类，以下是系统化解析：

一、场景的三大类型

1. 应用场景（Use Case Scenarios）

• 定义：描述系统在正常业务流程中的预期行为。
• 目的：验证功能正确性和核心质量属性（如效率、可用性）。
• 示例：

  “用户提交订单后，系统在1秒内返回支付成功响应。”

2. 变更场景（Change Scenarios）

• 定义：模拟系统演进需求（如新增功能、修改逻辑、技术升级）。
• 目的：评估可维护性、可扩展性。
• 示例：

  “新增支持加密货币支付，开发周期需≤30人天。”

3. 压力/限制场景（Stress/Limit Scenarios）

• 定义：测试系统在极端条件下的行为（高负载、故障注入、异常输入）。
• 目的：验证鲁棒性、容错能力、性能边界。
• 示例（来自附件）：

  “外部系统发送意外消息时，进程通知运维人员并继续运行，确保零停机。”

二、场景六大核心元素（附件解析）

您提供的附件展示了压力场景的完整元素分解：

✅ 关键点：

• 响应度量必须量化（如附件中“零停机”需明确为“停机时间=0秒”或“SLA=99.99%”）。
• 工件需具体化（如“订单处理服务”而非泛指的“系统”）。

三、场景构建实战指南

步骤1：关联质量属性树

• 每个场景必须映射到质量树的叶子节点（具体质量特性）。
  示例：

  graph LR
    A[效率] --> B[吞吐量]
    B --> C[场景：1000并发用户响应<1秒]
    D[可用性] --> E[故障恢复]
    E --> F[场景：硬件故障零停机]
  

步骤2：填充六大元素模板

### **变更场景示例**  
- **触发器**： 需求新增“多语言支持”  
- **触发源**： 产品经理  
- **环境**： 系统维护窗口期  
- **工件**： 前端UI服务、数据库词条表  
- **响应**： 动态加载语言包，不重启服务  
- **响应度量**： 新增语言部署时间 ≤ 2小时  

步骤3：优先级双维度过滤

• 业务优先级：删除低价值场景（如边缘功能）。
• 技术优先级：合并相似技术难度的场景（如多个数据库相关场景）。

四、常见陷阱与解决方案

五、在ATAM中的作用

1. 风险暴露
   • 例：压力场景中“外部系统意外消息”暴露集成接口鲁棒性风险。
2. 决策验证
   • 通过变更场景验证架构扩展性（如新增中间件是否满足30人天要求）。
3. 权衡分析
   • 比较“1000并发响应<1秒”（效率）与“全链路加密”（安全）的资源冲突。

🔍 输出到评估报告：
每个场景的分析结果转化为 风险（Risks）、敏感点（Sensitivity Points） 或 权衡点（Trade-offs），最终驱动架构优化。

场景示例

根据您提供的性能场景（附件1）和可靠性场景（附件2）要素表，以下是两类场景的标准化构建指南及对比分析：

一、性能场景（附件1）核心要素解析

1. 要素定义

2. 完整场景示例

### 支付峰值性能场景
- **触发源**: 外部用户（移动端APP）  
- **触发器**: 提交支付请求  
- **环境**: 促销期间峰值负载（3000 TPS）  
- **系统工件**: 支付处理微服务集群  
- **响应**:   
  - 核心支付功能保持响应  
  - 非实时报表服务自动降级  
- **响应度量**:  
  - 95%请求延迟 ≤ 150ms  
  - 错误率 < 0.1%  
  - 资源利用率 ≤ 80%  

二、可靠性场景（附件2）核心要素解析

1. 要素定义

2. 完整场景示例

### 数据库主节点故障场景
- **触发源**: 硬件故障（服务器断电）  
- **触发器**: 主数据库节点不可用  
- **环境**: 正常服务期间（日均负载50%）  
- **系统工件**: 订单数据库集群  
- **响应**:  
  - 10秒内检测故障  
  - 自动选举新主节点  
  - 只读模式运行至恢复  
- **响应度量**:  
  - 故障检测时间 ≤ 15s  
  - 数据零丢失（RPO=0）  
  - 服务恢复时间（RTO）≤ 90s  

三、性能 vs 可靠性场景关键差异

四、场景构建陷阱与解决方案

性能场景常见问题

• 陷阱：度量指标模糊（如“快速响应”）
  解决：强制量化（例：定义P95延迟≤200ms）
• 陷阱：忽略资源约束（如未监控CPU/内存）
  解决：增加资源利用率指标（例：内存占用≤70%）

可靠性场景常见问题

• 陷阱：恢复目标不明确（如“尽快恢复”）
  解决：声明SLA具体值（例：RTO<5分钟）
• 陷阱：未定义故障传播边界
  解决：明确影响范围（例：“仅影响报表服务，不影响交易核心”）

五、在ATAM评估中的应用

1. 性能场景→暴露效率风险
   • 例：峰值负载下延迟超标 → 需优化缓存策略
2. 可靠性场景→暴露容错风险
   • 例：数据库故障导致数据丢失 → 需加强复制机制
3. 冲突分析
   • 可靠性措施（如同步复制）可能降低性能 → 需权衡RTO与吞吐量

🔧 输出到架构决策：
通过场景验证结果，生成 敏感点（如线程池大小影响延迟）、权衡点（如数据一致性vs性能）、风险项（如单点故障）。