我们来对比一下ATAM 案例（网上书店系统） 和 SAAM 案例（企业 CMS 系统） 在评估目标、流程、产出等方面的核心差异。
📊 ATAM vs SAAM 案例对比
1️⃣ 评估焦点
| 方法 | 案例系统 | 核心问题 |
|---|---|---|
| ATAM | 网上书店 | 多质量属性（性能、安全性、可用性、可修改性）之间存在冲突时，如何权衡？ |
| SAAM | 企业 CMS | 架构对各类型变更的适应能力如何？修改成本高不高？ |
一句话：ATAM 问"哪个更优先？"，SAAM 问"好不好改？"
2️⃣ 评估流程对比
| 流程阶段 | ATAM（网上书店） | SAAM（企业 CMS） |
|---|---|---|
| 准备 | 提前一周发文档 | 提前几天发文档 |
| 评估时长 | 3 天 | 1 天 |
| 参与角色 | 产品、开发、运维、安全、测试（8 人） + 评估组（4 人） | 业务代表、开发、运维、架构师（5-6 人） |
| 开场 | 介绍 ATAM 方法 | 直接描述架构 |
| 业务目标 | 明确业务驱动（如双 11 大促） | 不单独强调业务目标，直接列变更场景 |
| 架构描述 | 详细，包含部署拓扑、服务交互 | 简要分层架构及模块依赖 |
| 关键活动 | 生成效用树 → 分析架构方法 → 识别权衡点 | 枚举开发场景 → 评估每个场景 → 分析场景交互 |
| 优先级确定 | 效用树中标注 H/M/L，基于业务价值 | 利益相关者投票选出最可能发生的场景 |
| 风险识别 | 风险点（如同步支付可能拖垮服务） | 架构弱点（如审核模块硬编码状态） |
| 输出内容 | 效用树、敏感点、权衡点、风险清单、无风险决策 | 架构强点、弱点（敏感组件）、场景交互分析、可修改性评分 |
3️⃣ 核心产出示例对比
| 产出类型 | ATAM（网上书店） | SAAM（企业 CMS） |
|---|---|---|
| 效用树 / 场景 | 层次化：业务目标 → 质量属性 → 量化场景（如"3000 并发，响应 ≤500ms"） | 扁平列表：S1: 增加视频文章类型；S3: 二级审批；S4: 更换数据库 |
| 敏感点 | 缓存失效瞬间数据库压力大；幂等校验增加写入延时 | article 表扩展性差；审核状态机缺失 |
| 权衡点 | 同步支付（性能 vs 用户体验）；JWT 失效（安全 vs 性能） | 无（SAAM 不刻意找权衡点） |
| 风险 | 同步调用外部支付网关 → 雪崩 | S1+S3 同时修改会导致高冲突风险 |
| 建议 | 支付改为异步 + 轮询；引入 JWT 黑名单缓存 | 审核模块改为状态机；数据库抽象层 |
4️⃣ 方法哲学对比
| 维度 | ATAM | SAAM |
|---|---|---|
| 评估对象 | 架构决策对多个质量属性的协同与冲突 | 架构对变更请求的响应代价 |
| 场景来源 | 从业务目标分解得出（自上而下） | 直接收集未来变更需求（自下而上） |
| 是否量化 | 要求量化（响应时间、并发数、可用性百分比） | 多为定性（工作量人日、影响范围高低） |
| 是否需要多属性 | 必须（至少 2 个以上质量属性） | 单一（主要是可修改性） |
| 输出复杂度 | 高（效用树、权衡点、多个清单） | 中（弱点列表、交互分析） |
5️⃣ 适用场景建议
- 用 ATAM：系统对性能、安全、可用性等多个质量属性都有高要求，且业务目标之间存在冲突（如金融、电商、医疗）。
- 用 SAAM：系统未来可能频繁演化（如 CMS、企业内部工具），团队最关心改代码的成本和风险，不涉及复杂的多属性权衡。
6️⃣ 案例中的共通点
- 都使用场景作为核心驱动
- 都需要利益相关者参与（业务、开发、运维）
- 都输出风险/弱点清单和改进建议
- 都强调架构的敏感点（虽然 ATAM 定义更严格）
✅ 总结对照表（简洁版）
| 对比维度 | ATAM（网上书店） | SAAM（企业 CMS） |
|---|---|---|
| 评估时长 | 3 天 | 1 天 |
| 核心问题 | 性能 vs 安全 vs 可用性 怎么取舍？ | 未来改需求时，哪个模块最痛苦？ |
| 场景结构 | 效用树（层次，带优先级和量化） | 扁平列表（投票排名） |
| 关键产物 | 权衡点、敏感点、风险 | 架构弱点、场景交互影响 |
| 量化程度 | 高 | 低 |
| 适合阶段 | 架构设计中期，已有多个备选方案 | 架构早期，或对可修改性特别关注 |