企业官网建设流程全解析

上一篇讲了架构风格——那是「架构长什么样」。这一篇讲架构评估——那是「这个架构到底好不好，怎么证明」。两者在教材里前后相邻，在考卷上也经常一起出现：风格题考你识别，评估题考你判断。

一、架构评估在评什么

先说清楚一个前提，否则后面的方法会显得很玄。

架构评估最大的特点是：它不运行代码。评估发生在详细设计和编码之前，此时系统还不存在，你没法压测、没法看监控。那怎么判断架构好坏？

答案是用场景当探针。

思路是这样的：架构决策会影响质量属性（性能、可用性、可修改性等），而质量属性可以写成具体的、可度量的场景。于是只要把场景往架构上一"放"，就能看出这个架构在哪些场景下会吃力——这是一种绕过实现、直接推理的评估方式。

所以场景的质量直接决定评估的质量。这就引出了那个必考的六要素：

六要素缺一不可，且响应度量必须量化。只写"提高性能"是不得分的，必须落到"响应时间小于 1 秒""可用性 99.99%"这种可核对的标准上。

教材里质量属性场景主要关注六类：可用性、可修改性、性能、可测试性、易用性、安全性。

二、SAAM：最早的架构分析方法

SAAM（Software Architecture Analysis Method）是最早形成文档、并被广泛使用的架构分析方法。它的出身很具体——最初就是为了分析架构的可修改性，后来才扩展到其他质量属性。

它的五步流程如下：

直接场景 vs 间接场景（核心概念）

这是 SAAM 里最容易考、也最容易记反的一组：

记忆钩子：改不动的叫直接，要动刀的叫间接。

场景交互为什么重要

如果两个语义上不相干的间接场景，却需要修改同一个构件，这说明什么？说明这个构件承担了本该分开的职责——功能划分不合理。

反过来，语义相近的场景交互在同一个构件上，是正常的。

所以场景交互评估，本质上是在检测架构的关注点分离做得如何。这一点在案例题里经常作为"请分析该架构存在什么问题"的答案素材。

三、ATAM：四阶段九步

ATAM（Architecture Tradeoff Analysis Method）是 SAAM 的演进。它名字里的Tradeoff（权衡）就是核心差异：

SAAM 主要看架构满足不满足某个质量属性；ATAM 进一步看多个质量属性之间如何互相牵制。

ATAM 关注的质量属性通常是四类：性能、安全性、可修改性、可用性。

九个步骤按四个阶段组织（死记九步容易乱，按阶段记就稳了）：

三个年年考的易混点

第一，步骤 4 只识别、不分析。这一步是把已有的架构方法登记下来，分析推迟到步骤 6。如果选项说"步骤 4 用于评估架构方法的优劣"，是错的。

第二，两批人、两批场景。步骤 5 的效用树场景来自项目决策者一侧；步骤 7 再由更广泛的干系人头脑风暴补充并投票。这个设计是刻意的——防止评估被小圈子的需求绑架。

第三，步骤 6 与步骤 8 做的事同构。都是"针对场景分析架构、产出四类判定"，区别只在场景来源：一个来自效用树，一个来自集体头脑风暴。两者互为交叉验证，所以这个阶段叫"测试"。

ATAM 的三类参与角色

注意参与时机的差异：步骤 1–6 只有评估小组与项目决策者参与；步骤 7 起，更广泛的干系人才加入头脑风暴并投票。评估通常分两天或两次集会进行。

四、效用树：ATAM 的核心工具

效用树（Utility Tree）是把"系统好不好"这个模糊问题结构化的工具。

它的结构是四层：

叶节点要标注优先级对（重要度, 难易度），各取 H / M / L。例如：

• (H, M)：高并发下单响应小于 1 秒——重要，但实现有中等难度

• (H, L)：重要且容易实现——这类应该优先处理，投入产出比最高

• (M, L)：中等重要、容易实现

效用树生成后会经过修剪，通常只保留不超过 50 个场景。为什么要修剪？因为效用树是给后续步骤 6 做分析用的输入，场景太多会导致分析无法收敛。

效用树的结构包括：树根—质量属性—属性分类—质量属性场景（叶子节点）重点记忆

五、四类判定：案例题的给分点

这是整章最有"得分感"的一块。ATAM 的分析结论最终落在四个概念上，案例题几乎每年都出现。

关键理解：这是两个独立维度

很多资料把四者串成一条判断链，容易把人绕晕。更准确的理解是两个互相独立的维度：

• 维度一（影响范围）：影响一个属性 → 敏感点；影响多个属性 → 权衡点

• 维度二（风险性质）：可能危及目标 → 风险点；确认无虞 → 非风险点

同一个决策完全可以既是权衡点、又是风险点。比如"为了提高吞吐量把连接池调到 500"，它同时影响性能和资源占用（权衡点），如果评估发现高并发下会导致内存告罄，那它同时也是风险点。

用一道典型题收尾：

「提高加密级别」属于哪一类？

加密级别提高，安全性变好、性能变差——一个决策影响多个质量属性，因此是权衡点。这也是教材里频繁出现的原例。

六、三种评估方法对比

一句话记住三者的递进关系：SAAM 回答"行不行"，ATAM 回答"哪里行哪里不行、为什么"，CBAM 回答"值不值得"。

七、选择题高频陷阱清单

1. 直接场景 / 间接场景别记反：现有架构就能支持的是"直接"，需要改架构的才是"间接"。
2. ATAM 是自顶向下还是自底向上：效用树是自上而下细化（效用 → 属性 → 场景），不是自底向上归纳。
3. 步骤 4 只识别不分析，出现"评估优劣"即为错误项。
4. 效用树的优先级对是（重要度, 难易度），两个维度，不要只写一个。
5. 效用树的根是"效用"，不是"质量属性"，也不是"场景"。
6. 敏感点的定义落在"构件/构件之间关系的特性"上，不是笼统的"设计决策"。
7. 权衡点是"影响多个质量属性的敏感点"——它是敏感点的特例，这个包含关系常被反过来考。
8. 风险点与非风险点是"判断结论"，不是流程步骤，不会出现在九步里。
9. 步骤 7 才引入更广泛的干系人，步骤 1–6 没有。
10. 响应度量必须量化，凡是只写"提高""改善"而没有指标的，都是错的。

八、记忆锚点汇总

九、小结

架构评估这一章的复习顺序，建议和上一篇反过来：先背答案，再理解流程。

理由是：四类判定、效用树结构、SAAM 五步、ATAM 四阶段九步，这些都是定义型考点，背下来就能拿分，性价比极高；而"为什么 ATAM 要分两批人收场景"这类理解型内容，是帮你记住定义、防止记混的辅助。

先把硬骨头（定义与步骤）啃下来，理解会自然跟上。

下一篇我会拆「ABSD 基于架构的软件设计」——它和架构风格、架构评估共同构成本章选择题的主力分值。

本文为软考系统架构设计师备考系列文章，内容依据《系统架构设计师教程》与历年真题考点分布整理。