企业官网建设流程全解析

【软考系统架构设计师全链路通关实战】第 32 篇：架构评估（一）：SAAM 方法

本系列定位：以软考系统架构设计师（高级）考试为主线，语言无关的架构方法论视角，覆盖官方教程（第二版）全部 20 章考点，按「综合知识 → 案例分析 → 论文」三科组织，每篇含考点精讲 + 真题规律 + 应试技巧 + Mermaid 图解。

本篇你将学到

• 架构评估的意义与三大方法流派：基于提问、基于度量、基于场景——为什么场景法成为主流
• 架构评估的最佳时机：为什么「架构定型之前」评估成本最低、收益最大
• SAAM（软件架构分析方法）五步骤详解：场景开发 → 架构描述 → 场景分类 → 场景交互评估 → 形成报告
• 直接场景与间接场景的判别及架构修改代价评估
• SAAM 三种变体的一句话定位：SAAMCS、ESAAM、ATASAAM
• SAAM 的适用场景与局限，为第 33 篇 ATAM 的引入埋好伏笔

模块五（第 20~29 篇）解决「架构怎么设计」，模块六前两篇（第 30~31 篇）解决「质量需求怎么表达与排序」，从本篇开始解决第三个问题：设计出来的架构到底好不好——这就是架构评估。软考对三种评估方法（SAAM、ATAM、CBAM）的考查极有层次感：SAAM 考步骤与场景分类，ATAM 考四类判定（敏感点/权衡点/风险/非风险），CBAM 考成本效益计算。本篇先攻 SAAM。

考点热力表

一、架构评估的方法分类与时机

1.1 为什么要评估架构

架构是项目中最早做出、最难修改、影响最深远的一组决策。第 20 篇讲过架构的核心作用之一是风险控制——架构缺陷如果在编码开始后才被发现，返工成本会呈数量级放大（需求→架构→编码→测试，越往后修复成本越高，这是贯穿软件工程的老规律，第 09 篇生命周期模型、第 14 篇项目管理都反复用到）。架构评估就是在架构尚未大规模实现时，用较低成本暴露其潜在风险、验证其满足质量需求的能力的手段。

1.2 三大方法流派

场景法成为最主流方法的原因是选择题考点：场景把抽象的质量属性翻译成具体的事件（第 30 篇六要素场景正是为此服务），不同背景的干系人（业务、运维、开发、测试）都能围绕场景达成共识，且场景直接对应可验证的响应度量。记忆抓手：提问法问清单、度量法算指标、场景法做考验。

1.3 评估时机：越早越便宜

架构评估的收益与成本随时间变化的规律：评估进行得越晚，未被发现的问题渗入代码越多，修复代价越高；而评估本身（组织干系人开会分析）的成本相对稳定。因此最佳时机是架构定型之前——此时架构文档可以低成本修改，评估结论能真正改变架构决策。

智联云商的实践印证：在微服务拆分方案（第 40 篇展开）定稿前组织了一次场景评估，发现「大促扩容」场景要求订单服务可独立扩容，而初版拆分把订单与库存合并部署——此时调整只是改部署图；若到编码后才发现，则要重新拆分服务、迁移数据。

二、SAAM 五步骤详解

SAAM（Software Architecture Analysis Method，软件架构分析方法）是最早形成体系的架构评估方法，面向非功能属性的评估。它的五步骤顺序是综合知识与案例分析的必考点，必须做到闭卷默写。

2.1 第一步：场景开发

从所有利益相关方（用户、客户、开发、运维、市场）收集他们关心的「系统使用情境与未来变更」，形成场景列表。场景来源两类：用例场景（系统当前预期功能的交互过程，如用户下单）和变更场景（预期的未来修改，如更换短信供应商、新增支付渠道）。第 30~31 篇的质量属性场景六要素在这里直接复用——把「峰值下单 95% 请求 ≤2s」写成含刺激源/刺激/环境/制品/响应/响应度量的完整场景，是评估讨论的共同语言。

智联云商评估会收集到的典型场景：大促峰值 10 万并发下单（性能）、支付节点宕机 30 秒内切换（可用性）、更换物流对接服务商 1 人日内完成（可修改性）、用户误删购物车可撤销（易用性）。

2.2 第二步：架构描述

被评估的架构以干系人都能理解的方式呈现（第 21 篇 4+1 视图是常用载体）。注意因果顺序：场景先行、架构描述在后——因为场景是评估的标尺，先有标尺才能保证架构描述围绕评估焦点展开、详略得当，避免写成面面俱到却偏离关注点的文档。这个顺序本身就是选择题考点（SAAM 第一步是场景开发而非架构描述）。

2.3 第三步：场景分类（直接 vs 间接）

逐个把场景与架构比对，分为两类——SAAM 最核心的判定，案例分析高频：

判别技巧：看场景动词与架构预期的关系——「用户使用现有功能完成某事」倾向直接场景；「替换/新增/迁移/支持以前没有的某类需求」倾向间接场景。

智联云商示例：

• 直接场景：用户下单→扣库存→生成订单。订单、库存服务已按此流程设计，架构无需改动。
• 间接场景：引入「先享后付」信用支付，要求订单服务与新增的信用评估服务交互——需新增信用服务构件、修改订单服务的对外依赖连接，属间接场景，架构要改。

2.4 第四步：场景交互评估

SAAM 认为架构质量的重要信号是场景交互（场景间共享同一构件的程度）：

• 多个间接场景的修改都落在同一构件上，说明该构件承担了过多职责、是变更的汇聚点——高耦合的征兆，未来任何一处修改都可能波及多个场景，是重点风险区。智联云商评估发现「更换短信供应商」「调整营销推送规则」「修改订单通知模板」三个间接场景全部命中通知模块，判定其职责过载，给出的改进是拆分为渠道适配层与模板渲染层（正是第 30 篇可修改性战术「封装+中介者」的应用）。
• 反之，场景修改彼此分散、互不重叠，说明变更局部化良好。

若多个间接场景存在，还需评估单个场景单独评估的补充维度：每个间接场景导出的修改涉及哪些构件、多少连接、估计工作量——即架构修改代价。代价的粗粒度表达：受影响构件数、需修改的接口数、预计人日。这与第 27 篇架构演化成本估算一脉相承。

2.5 第五步：形成报告

汇总评估结果：场景分类清单、每个间接场景对应的架构修改点及代价估计、场景交互暴露的耦合风险、对架构改进的建议。报告的呈现形式常用「场景 × 架构元素」映射表——案例题让你「补全评估结果表」时，按行填场景类型、涉及构件、修改代价三列即可。

案例答题模板（SAAM 评估类问题）

题型：「请按 SAAM 方法评估题给架构能否支持 XX 场景 / 判断场景属于直接还是间接并说明理由。」

采分点结构：

1. 报方法名与步骤框架：SAAM 五步（场景开发→架构描述→场景分类→场景交互评估→形成报告），点明题目处于哪一步（框架分）。
2. 场景类型判定给依据：直接场景 = 现有架构不需修改即可支持；间接场景 = 需修改架构（新增/修改构件或连接）（判定 1 分，依据 1 分）。
3. 间接场景必须列修改点：指出要改哪些构件、哪些接口/连接（每处 1 分，这是采分大头，宁可多列）。
4. 场景交互分析：若多个场景命中同一构件，点出高耦合风险并给改进建议（接口分离/职责拆分）（1~2 分）。
5. 结论回扣：该架构对 XX 变更的适应能力如何（1 分）。

2.6 步骤易错点与真题考法

五步骤的考试陷阱集中在三处：

1. 顺序陷阱：第一步是场景开发而非架构描述。理由要能复述——场景是评估标尺，先定标尺再组织架构描述，才能保证描述详略围绕评估焦点。真题曾以「SAAM 首先进行架构描述」作为错误选项。
2. 分类混淆：把直接场景误判为「不需要测试」——直接场景仍需在架构上走查执行路径以统一理解，只是不需要修改架构；判据始终是「是否需要改动构件或连接」，与场景是否容易实现无关。
3. 交互方向反转：场景交互多（多个间接场景命中同一构件）在 SAAM 语境里是坏信号（高耦合），而非复用良好的表现——与「构件复用度高」的正面表述区分开，这是最常考的语义反转点。

三步实操建议（案例题时间紧时）：先用一句话报框架，再逐场景给「类型+判定依据」，间接场景列出修改构件清单，最后补一句场景交互结论——按此顺序写，采分点全覆盖。

三、SAAM 的变体与适用边界

3.1 三种变体（一句话定位，选择题常考对应关系）

考试记忆锚点：CS 对应易用性特征（Characteristics），ATA 对应极端情况（Extreme Situation 类语义），ESAAM 即「扩展版」。题干若出现「评估架构在极端场景下的行为」直接锁定 ATASAAM。

3.2 SAAM 的适用场景与局限

适用：

• 关注点以非功能属性为主（SAAM 本身就是非功能属性导向的方法）。
• 架构相对简单、质量需求尚未形成复杂的多属性交织权衡时——SAAM 不做属性间的权衡分析，这是它与 ATAM 的本质分界。
• 干系人需要快速、低成本地获得架构对变更适应性的判断。

局限（也是 ATAM 诞生的原因）：

• 不分析质量属性间的权衡（性能提升是否损害可修改性，SAAM 不回答）。
• 场景覆盖不全的风险：结论依赖所收集场景的代表性。
• 对复杂的多属性交织系统（如同时有严苛性能、安全、可用性要求的系统）分析深度不足。

一句话对比定调（第 33 篇展开）：SAAM 用场景「检验」架构，ATAM 用场景「权衡」架构——前者回答「支不支持」，后者回答「这么做到底值不值、伤不伤别的属性」。

3.3 SAAM 与 ATAM 的分界线预读

进入第 33 篇前，用一张小表固化两者边界，避免案例答题时方法混用：

案例题若只问「能否支持、怎么改」用 SAAM 话术作答；若出现「权衡、敏感点、风险判定」字样，必须切换到 ATAM 话术——方法用错框架分即失。

四、SAAM 全流程演练：智联云商通知模块评估

把五步骤串成一个完整闭环（案例答题时可整段迁移）：

演练结论可提炼为论文素材：在智联云商微服务化前期，我们采用 SAAM 方法对初版服务划分开展评估，识别出 2 个间接场景与 1 处场景交互热点，据此在编码前完成通知服务拆分，避免了上线后通知通道切换牵连营销规则的连锁修改——这段叙述同时覆盖「评估方法 + 项目角色 + 量化结果」三个论文采分维度。

五、本模块方法论沉淀：评估方法的演进逻辑

三种主流方法的演进是「检验 → 权衡 → 算账」逐步深化的过程：SAAM 奠定场景驱动评估范式；ATAM 引入效用树（第 31 篇）与权衡分析，回答「架构决策如何同时影响多个质量属性」；CBAM 再叠加成本维度，回答「投入是否划算」。理解这条演进线，第 33、34 篇的知识就不再是孤立的方法清单，而是同一条问题链上的三次深化。

本篇小结

下篇预告

第 33 篇：架构评估（二）：ATAM 方法与评估实战
ATAM 九步骤全景、敏感点/权衡点/风险点/非风险四类判定（案例分析必考判定题的判定口诀）、效用树驱动的场景分析、智联云商 ATAM 全真演练——评估模块的皇冠明珠。

如果本篇内容对你有帮助，欢迎点赞收藏！有任何疑问，欢迎在评论区交流。