尧图网站建设 
【软考系统架构设计师全链路通关实战】第 32 篇架构评估一SAAM 方法本系列定位以软考系统架构设计师高级考试为主线语言无关的架构方法论视角覆盖官方教程第二版全部 20 章考点按「综合知识 → 案例分析 → 论文」三科组织每篇含考点精讲 真题规律 应试技巧 Mermaid 图解。本篇你将学到架构评估的意义与三大方法流派基于提问、基于度量、基于场景——为什么场景法成为主流架构评估的最佳时机为什么「架构定型之前」评估成本最低、收益最大SAAM软件架构分析方法五步骤详解场景开发 → 架构描述 → 场景分类 → 场景交互评估 → 形成报告直接场景与间接场景的判别及架构修改代价评估SAAM 三种变体的一句话定位SAAMCS、ESAAM、ATASAAMSAAM 的适用场景与局限为第 33 篇 ATAM 的引入埋好伏笔模块五第 20~29 篇解决「架构怎么设计」模块六前两篇第 30~31 篇解决「质量需求怎么表达与排序」从本篇开始解决第三个问题设计出来的架构到底好不好——这就是架构评估。软考对三种评估方法SAAM、ATAM、CBAM的考查极有层次感SAAM 考步骤与场景分类ATAM 考四类判定敏感点/权衡点/风险/非风险CBAM 考成本效益计算。本篇先攻 SAAM。考点热力表考点综合知识案例分析论文评估方法三分类提问/度量/场景★★ 高频选择题☆★★ 可作论文论证素材评估时机与成本收益关系★★ 常考概念题★ 偶现于方案选择题★SAAM 五步骤顺序★★★ 必考排序/步骤题★★★ 高频按步骤分析给定架构★★ 论文评估方法段直接场景 vs 间接场景★★ 高频辨析题★★★ 常考判定给定场景类型并说明★场景交互与修改代价评估★ 常考★★ 常与架构演化/重构结合★SAAM 变体与适用场景★★ 常考对应关系选择☆☆一、架构评估的方法分类与时机1.1 为什么要评估架构架构是项目中最早做出、最难修改、影响最深远的一组决策。第 20 篇讲过架构的核心作用之一是风险控制——架构缺陷如果在编码开始后才被发现返工成本会呈数量级放大需求→架构→编码→测试越往后修复成本越高这是贯穿软件工程的老规律第 09 篇生命周期模型、第 14 篇项目管理都反复用到。架构评估就是在架构尚未大规模实现时用较低成本暴露其潜在风险、验证其满足质量需求的能力的手段。1.2 三大方法流派流派做法代表优点局限基于提问用一组问题清单检查架构按是/否/不适答作答架构权衡提问清单类方法简单快速覆盖面广答案粒度粗难以定位具体缺陷基于度量对架构制品建立度量指标耦合度、内聚度、扇入扇出等用数据评价度量分析法客观、可量化、可横向比较指标与质量属性间的因果链条弱难以回答「耦合度 0.3 意味着什么」基于场景用质量属性场景逐个「考验」架构看架构能否支撑SAAM、ATAM最主流场景具体、针对性强、利益相关方都能参与、结果直观场景选取的完备性无保证评估质量依赖场景质量场景法成为最主流方法的原因是选择题考点场景把抽象的质量属性翻译成具体的事件第 30 篇六要素场景正是为此服务不同背景的干系人业务、运维、开发、测试都能围绕场景达成共识且场景直接对应可验证的响应度量。记忆抓手提问法问清单、度量法算指标、场景法做考验。1.3 评估时机越早越便宜架构评估的收益与成本随时间变化的规律评估进行得越晚未被发现的问题渗入代码越多修复代价越高而评估本身组织干系人开会分析的成本相对稳定。因此最佳时机是架构定型之前——此时架构文档可以低成本修改评估结论能真正改变架构决策。需求分析架构设计★最佳评估窗口改文档即可详细设计评估成本上升牵动接口编码实现返工代价大测试运行问题修复呈数量级放大智联云商的实践印证在微服务拆分方案第 40 篇展开定稿前组织了一次场景评估发现「大促扩容」场景要求订单服务可独立扩容而初版拆分把订单与库存合并部署——此时调整只是改部署图若到编码后才发现则要重新拆分服务、迁移数据。二、SAAM 五步骤详解SAAMSoftware Architecture Analysis Method软件架构分析方法是最早形成体系的架构评估方法面向非功能属性的评估。它的五步骤顺序是综合知识与案例分析的必考点必须做到闭卷默写。① 场景开发收集干系人关注点形成场景集合② 架构描述呈现被评估架构③ 场景分类直接场景 / 间接场景④ 场景交互评估间接场景映射修改点分析场景间共享构件⑤ 形成报告场景-架构映射表修改代价与风险2.1 第一步场景开发从所有利益相关方用户、客户、开发、运维、市场收集他们关心的「系统使用情境与未来变更」形成场景列表。场景来源两类用例场景系统当前预期功能的交互过程如用户下单和变更场景预期的未来修改如更换短信供应商、新增支付渠道。第 30~31 篇的质量属性场景六要素在这里直接复用——把「峰值下单 95% 请求 ≤2s」写成含刺激源/刺激/环境/制品/响应/响应度量的完整场景是评估讨论的共同语言。智联云商评估会收集到的典型场景大促峰值 10 万并发下单性能、支付节点宕机 30 秒内切换可用性、更换物流对接服务商 1 人日内完成可修改性、用户误删购物车可撤销易用性。2.2 第二步架构描述被评估的架构以干系人都能理解的方式呈现第 21 篇 41 视图是常用载体。注意因果顺序场景先行、架构描述在后——因为场景是评估的标尺先有标尺才能保证架构描述围绕评估焦点展开、详略得当避免写成面面俱到却偏离关注点的文档。这个顺序本身就是选择题考点SAAM 第一步是场景开发而非架构描述。2.3 第三步场景分类直接 vs 间接逐个把场景与架构比对分为两类——SAAM 最核心的判定案例分析高频类别判定标准含义需要做什么直接场景用现有架构不需要任何修改即可支持场景所涉功能已被当前设计覆盖开发者按图索骥即可实现在架构上「走一遍」验证执行路径确认理解一致间接场景需要修改架构改构件、加构件、改连接/依赖才能支持场景超出当前设计预设暴露架构对未来变化的适应能力标出必须修改的构件与连接评估修改代价——这是评估的重头戏判别技巧看场景动词与架构预期的关系——「用户使用现有功能完成某事」倾向直接场景「替换/新增/迁移/支持以前没有的某类需求」倾向间接场景。智联云商示例直接场景用户下单→扣库存→生成订单。订单、库存服务已按此流程设计架构无需改动。间接场景引入「先享后付」信用支付要求订单服务与新增的信用评估服务交互——需新增信用服务构件、修改订单服务的对外依赖连接属间接场景架构要改。2.4 第四步场景交互评估SAAM 认为架构质量的重要信号是场景交互场景间共享同一构件的程度多个间接场景的修改都落在同一构件上说明该构件承担了过多职责、是变更的汇聚点——高耦合的征兆未来任何一处修改都可能波及多个场景是重点风险区。智联云商评估发现「更换短信供应商」「调整营销推送规则」「修改订单通知模板」三个间接场景全部命中通知模块判定其职责过载给出的改进是拆分为渠道适配层与模板渲染层正是第 30 篇可修改性战术「封装中介者」的应用。反之场景修改彼此分散、互不重叠说明变更局部化良好。若多个间接场景存在还需评估单个场景单独评估的补充维度每个间接场景导出的修改涉及哪些构件、多少连接、估计工作量——即架构修改代价。代价的粗粒度表达受影响构件数、需修改的接口数、预计人日。这与第 27 篇架构演化成本估算一脉相承。2.5 第五步形成报告汇总评估结果场景分类清单、每个间接场景对应的架构修改点及代价估计、场景交互暴露的耦合风险、对架构改进的建议。报告的呈现形式常用「场景 × 架构元素」映射表——案例题让你「补全评估结果表」时按行填场景类型、涉及构件、修改代价三列即可。案例答题模板SAAM 评估类问题题型「请按 SAAM 方法评估题给架构能否支持 XX 场景 / 判断场景属于直接还是间接并说明理由。」采分点结构报方法名与步骤框架SAAM 五步场景开发→架构描述→场景分类→场景交互评估→形成报告点明题目处于哪一步框架分。场景类型判定给依据直接场景 现有架构不需修改即可支持间接场景 需修改架构新增/修改构件或连接判定 1 分依据 1 分。间接场景必须列修改点指出要改哪些构件、哪些接口/连接每处 1 分这是采分大头宁可多列。场景交互分析若多个场景命中同一构件点出高耦合风险并给改进建议接口分离/职责拆分1~2 分。结论回扣该架构对 XX 变更的适应能力如何1 分。2.6 步骤易错点与真题考法五步骤的考试陷阱集中在三处顺序陷阱第一步是场景开发而非架构描述。理由要能复述——场景是评估标尺先定标尺再组织架构描述才能保证描述详略围绕评估焦点。真题曾以「SAAM 首先进行架构描述」作为错误选项。分类混淆把直接场景误判为「不需要测试」——直接场景仍需在架构上走查执行路径以统一理解只是不需要修改架构判据始终是「是否需要改动构件或连接」与场景是否容易实现无关。交互方向反转场景交互多多个间接场景命中同一构件在 SAAM 语境里是坏信号高耦合而非复用良好的表现——与「构件复用度高」的正面表述区分开这是最常考的语义反转点。三步实操建议案例题时间紧时先用一句话报框架再逐场景给「类型判定依据」间接场景列出修改构件清单最后补一句场景交互结论——按此顺序写采分点全覆盖。三、SAAM 的变体与适用边界3.1 三种变体一句话定位选择题常考对应关系变体针对性扩展一句话定位SAAMCS面向易用性的特征扩展把「特征」概念引入场景评估架构对易用性相关特征的支撑ESAAM基于扩展的 SAAM在 SAAM 基础上扩展评估范围如对框架类、产品线类架构的适配ATASAAM面向极端情况/极端场景的评估专门评估架构在极端输入、极端负载等极端情况下的表现考试记忆锚点CS 对应易用性特征CharacteristicsATA 对应极端情况Extreme Situation 类语义ESAAM 即「扩展版」。题干若出现「评估架构在极端场景下的行为」直接锁定 ATASAAM。3.2 SAAM 的适用场景与局限适用关注点以非功能属性为主SAAM 本身就是非功能属性导向的方法。架构相对简单、质量需求尚未形成复杂的多属性交织权衡时——SAAM 不做属性间的权衡分析这是它与 ATAM 的本质分界。干系人需要快速、低成本地获得架构对变更适应性的判断。局限也是 ATAM 诞生的原因不分析质量属性间的权衡性能提升是否损害可修改性SAAM 不回答。场景覆盖不全的风险结论依赖所收集场景的代表性。对复杂的多属性交织系统如同时有严苛性能、安全、可用性要求的系统分析深度不足。一句话对比定调第 33 篇展开SAAM 用场景「检验」架构ATAM 用场景「权衡」架构——前者回答「支不支持」后者回答「这么做到底值不值、伤不伤别的属性」。3.3 SAAM 与 ATAM 的分界线预读进入第 33 篇前用一张小表固化两者边界避免案例答题时方法混用维度SAAMATAM评估焦点架构能否支撑场景非功能属性导向质量属性间的权衡与风险核心工具场景直接/间接分类效用树 场景 架构方法分析关键产出场景-架构映射表、修改代价估计敏感点/权衡点/风险/非风险四类判定适用架构较简单、属性间冲突不复杂多属性严苛交织的复杂系统案例题若只问「能否支持、怎么改」用 SAAM 话术作答若出现「权衡、敏感点、风险判定」字样必须切换到 ATAM 话术——方法用错框架分即失。四、SAAM 全流程演练智联云商通知模块评估把五步骤串成一个完整闭环案例答题时可整段迁移下单/支付/查询等 6 个更换短信供应商引入信用支付场景开发8 个场景6 个用例 2 个变更架构描述呈现三层架构与服务划分图场景分类直接场景现有架构可支撑间接场景需改架构场景交互评估两个场景均命中通知模块且通知模块同时承担模板渲染判定职责过载/高耦合风险形成报告建议拆分渠道适配层与模板层预计修改 3 构件/2 接口/5 人日演练结论可提炼为论文素材在智联云商微服务化前期我们采用 SAAM 方法对初版服务划分开展评估识别出 2 个间接场景与 1 处场景交互热点据此在编码前完成通知服务拆分避免了上线后通知通道切换牵连营销规则的连锁修改——这段叙述同时覆盖「评估方法 项目角色 量化结果」三个论文采分维度。五、本模块方法论沉淀评估方法的演进逻辑SAAM 1993场景检验非功能属性ATAM场景效用树权衡分析敏感点/权衡点判定CBAM成本效益视角在 ATAM 基础上算经济账SAAM 变体CS/ESAAM/ATASAAM垂直方向特化三种主流方法的演进是「检验 → 权衡 → 算账」逐步深化的过程SAAM 奠定场景驱动评估范式ATAM 引入效用树第 31 篇与权衡分析回答「架构决策如何同时影响多个质量属性」CBAM 再叠加成本维度回答「投入是否划算」。理解这条演进线第 33、34 篇的知识就不再是孤立的方法清单而是同一条问题链上的三次深化。本篇小结知识点核心内容评估三分类提问清单、度量指标、场景考验架构——场景法最主流评估时机架构定型之前越早修复成本越低、评估收益越大SAAM 五步场景开发→架构描述→场景分类→场景交互评估→形成报告顺序必背直接/间接场景直接 不改架构即支持间接 需修改构件/连接须列修改点与代价场景交互多场景命中同一构件 高耦合风险是架构改进的信号三变体SAAMCS 易用性、ESAAM 扩展版、ATASAAM 极端情况SAAM 边界非功能属性导向、架构较简单适用不做属性权衡ATAM 补位下篇预告第 33 篇架构评估二ATAM 方法与评估实战ATAM 九步骤全景、敏感点/权衡点/风险点/非风险四类判定案例分析必考判定题的判定口诀、效用树驱动的场景分析、智联云商 ATAM 全真演练——评估模块的皇冠明珠。如果本篇内容对你有帮助欢迎点赞收藏有任何疑问欢迎在评论区交流。 第32篇-架构评估（一）：SAAM 方法
【软考系统架构设计师全链路通关实战】第 32 篇架构评估一SAAM 方法本系列定位以软考系统架构设计师高级考试为主线语言无关的架构方法论视角覆盖官方教程第二版全部 20 章考点按「综合知识 → 案例分析 → 论文」三科组织每篇含考点精讲 真题规律 应试技巧 Mermaid 图解。本篇你将学到架构评估的意义与三大方法流派基于提问、基于度量、基于场景——为什么场景法成为主流架构评估的最佳时机为什么「架构定型之前」评估成本最低、收益最大SAAM软件架构分析方法五步骤详解场景开发 → 架构描述 → 场景分类 → 场景交互评估 → 形成报告直接场景与间接场景的判别及架构修改代价评估SAAM 三种变体的一句话定位SAAMCS、ESAAM、ATASAAMSAAM 的适用场景与局限为第 33 篇 ATAM 的引入埋好伏笔模块五第 20~29 篇解决「架构怎么设计」模块六前两篇第 30~31 篇解决「质量需求怎么表达与排序」从本篇开始解决第三个问题设计出来的架构到底好不好——这就是架构评估。软考对三种评估方法SAAM、ATAM、CBAM的考查极有层次感SAAM 考步骤与场景分类ATAM 考四类判定敏感点/权衡点/风险/非风险CBAM 考成本效益计算。本篇先攻 SAAM。考点热力表考点综合知识案例分析论文评估方法三分类提问/度量/场景★★ 高频选择题☆★★ 可作论文论证素材评估时机与成本收益关系★★ 常考概念题★ 偶现于方案选择题★SAAM 五步骤顺序★★★ 必考排序/步骤题★★★ 高频按步骤分析给定架构★★ 论文评估方法段直接场景 vs 间接场景★★ 高频辨析题★★★ 常考判定给定场景类型并说明★场景交互与修改代价评估★ 常考★★ 常与架构演化/重构结合★SAAM 变体与适用场景★★ 常考对应关系选择☆☆一、架构评估的方法分类与时机1.1 为什么要评估架构架构是项目中最早做出、最难修改、影响最深远的一组决策。第 20 篇讲过架构的核心作用之一是风险控制——架构缺陷如果在编码开始后才被发现返工成本会呈数量级放大需求→架构→编码→测试越往后修复成本越高这是贯穿软件工程的老规律第 09 篇生命周期模型、第 14 篇项目管理都反复用到。架构评估就是在架构尚未大规模实现时用较低成本暴露其潜在风险、验证其满足质量需求的能力的手段。1.2 三大方法流派流派做法代表优点局限基于提问用一组问题清单检查架构按是/否/不适答作答架构权衡提问清单类方法简单快速覆盖面广答案粒度粗难以定位具体缺陷基于度量对架构制品建立度量指标耦合度、内聚度、扇入扇出等用数据评价度量分析法客观、可量化、可横向比较指标与质量属性间的因果链条弱难以回答「耦合度 0.3 意味着什么」基于场景用质量属性场景逐个「考验」架构看架构能否支撑SAAM、ATAM最主流场景具体、针对性强、利益相关方都能参与、结果直观场景选取的完备性无保证评估质量依赖场景质量场景法成为最主流方法的原因是选择题考点场景把抽象的质量属性翻译成具体的事件第 30 篇六要素场景正是为此服务不同背景的干系人业务、运维、开发、测试都能围绕场景达成共识且场景直接对应可验证的响应度量。记忆抓手提问法问清单、度量法算指标、场景法做考验。1.3 评估时机越早越便宜架构评估的收益与成本随时间变化的规律评估进行得越晚未被发现的问题渗入代码越多修复代价越高而评估本身组织干系人开会分析的成本相对稳定。因此最佳时机是架构定型之前——此时架构文档可以低成本修改评估结论能真正改变架构决策。需求分析架构设计★最佳评估窗口改文档即可详细设计评估成本上升牵动接口编码实现返工代价大测试运行问题修复呈数量级放大智联云商的实践印证在微服务拆分方案第 40 篇展开定稿前组织了一次场景评估发现「大促扩容」场景要求订单服务可独立扩容而初版拆分把订单与库存合并部署——此时调整只是改部署图若到编码后才发现则要重新拆分服务、迁移数据。二、SAAM 五步骤详解SAAMSoftware Architecture Analysis Method软件架构分析方法是最早形成体系的架构评估方法面向非功能属性的评估。它的五步骤顺序是综合知识与案例分析的必考点必须做到闭卷默写。① 场景开发收集干系人关注点形成场景集合② 架构描述呈现被评估架构③ 场景分类直接场景 / 间接场景④ 场景交互评估间接场景映射修改点分析场景间共享构件⑤ 形成报告场景-架构映射表修改代价与风险2.1 第一步场景开发从所有利益相关方用户、客户、开发、运维、市场收集他们关心的「系统使用情境与未来变更」形成场景列表。场景来源两类用例场景系统当前预期功能的交互过程如用户下单和变更场景预期的未来修改如更换短信供应商、新增支付渠道。第 30~31 篇的质量属性场景六要素在这里直接复用——把「峰值下单 95% 请求 ≤2s」写成含刺激源/刺激/环境/制品/响应/响应度量的完整场景是评估讨论的共同语言。智联云商评估会收集到的典型场景大促峰值 10 万并发下单性能、支付节点宕机 30 秒内切换可用性、更换物流对接服务商 1 人日内完成可修改性、用户误删购物车可撤销易用性。2.2 第二步架构描述被评估的架构以干系人都能理解的方式呈现第 21 篇 41 视图是常用载体。注意因果顺序场景先行、架构描述在后——因为场景是评估的标尺先有标尺才能保证架构描述围绕评估焦点展开、详略得当避免写成面面俱到却偏离关注点的文档。这个顺序本身就是选择题考点SAAM 第一步是场景开发而非架构描述。2.3 第三步场景分类直接 vs 间接逐个把场景与架构比对分为两类——SAAM 最核心的判定案例分析高频类别判定标准含义需要做什么直接场景用现有架构不需要任何修改即可支持场景所涉功能已被当前设计覆盖开发者按图索骥即可实现在架构上「走一遍」验证执行路径确认理解一致间接场景需要修改架构改构件、加构件、改连接/依赖才能支持场景超出当前设计预设暴露架构对未来变化的适应能力标出必须修改的构件与连接评估修改代价——这是评估的重头戏判别技巧看场景动词与架构预期的关系——「用户使用现有功能完成某事」倾向直接场景「替换/新增/迁移/支持以前没有的某类需求」倾向间接场景。智联云商示例直接场景用户下单→扣库存→生成订单。订单、库存服务已按此流程设计架构无需改动。间接场景引入「先享后付」信用支付要求订单服务与新增的信用评估服务交互——需新增信用服务构件、修改订单服务的对外依赖连接属间接场景架构要改。2.4 第四步场景交互评估SAAM 认为架构质量的重要信号是场景交互场景间共享同一构件的程度多个间接场景的修改都落在同一构件上说明该构件承担了过多职责、是变更的汇聚点——高耦合的征兆未来任何一处修改都可能波及多个场景是重点风险区。智联云商评估发现「更换短信供应商」「调整营销推送规则」「修改订单通知模板」三个间接场景全部命中通知模块判定其职责过载给出的改进是拆分为渠道适配层与模板渲染层正是第 30 篇可修改性战术「封装中介者」的应用。反之场景修改彼此分散、互不重叠说明变更局部化良好。若多个间接场景存在还需评估单个场景单独评估的补充维度每个间接场景导出的修改涉及哪些构件、多少连接、估计工作量——即架构修改代价。代价的粗粒度表达受影响构件数、需修改的接口数、预计人日。这与第 27 篇架构演化成本估算一脉相承。2.5 第五步形成报告汇总评估结果场景分类清单、每个间接场景对应的架构修改点及代价估计、场景交互暴露的耦合风险、对架构改进的建议。报告的呈现形式常用「场景 × 架构元素」映射表——案例题让你「补全评估结果表」时按行填场景类型、涉及构件、修改代价三列即可。案例答题模板SAAM 评估类问题题型「请按 SAAM 方法评估题给架构能否支持 XX 场景 / 判断场景属于直接还是间接并说明理由。」采分点结构报方法名与步骤框架SAAM 五步场景开发→架构描述→场景分类→场景交互评估→形成报告点明题目处于哪一步框架分。场景类型判定给依据直接场景 现有架构不需修改即可支持间接场景 需修改架构新增/修改构件或连接判定 1 分依据 1 分。间接场景必须列修改点指出要改哪些构件、哪些接口/连接每处 1 分这是采分大头宁可多列。场景交互分析若多个场景命中同一构件点出高耦合风险并给改进建议接口分离/职责拆分1~2 分。结论回扣该架构对 XX 变更的适应能力如何1 分。2.6 步骤易错点与真题考法五步骤的考试陷阱集中在三处顺序陷阱第一步是场景开发而非架构描述。理由要能复述——场景是评估标尺先定标尺再组织架构描述才能保证描述详略围绕评估焦点。真题曾以「SAAM 首先进行架构描述」作为错误选项。分类混淆把直接场景误判为「不需要测试」——直接场景仍需在架构上走查执行路径以统一理解只是不需要修改架构判据始终是「是否需要改动构件或连接」与场景是否容易实现无关。交互方向反转场景交互多多个间接场景命中同一构件在 SAAM 语境里是坏信号高耦合而非复用良好的表现——与「构件复用度高」的正面表述区分开这是最常考的语义反转点。三步实操建议案例题时间紧时先用一句话报框架再逐场景给「类型判定依据」间接场景列出修改构件清单最后补一句场景交互结论——按此顺序写采分点全覆盖。三、SAAM 的变体与适用边界3.1 三种变体一句话定位选择题常考对应关系变体针对性扩展一句话定位SAAMCS面向易用性的特征扩展把「特征」概念引入场景评估架构对易用性相关特征的支撑ESAAM基于扩展的 SAAM在 SAAM 基础上扩展评估范围如对框架类、产品线类架构的适配ATASAAM面向极端情况/极端场景的评估专门评估架构在极端输入、极端负载等极端情况下的表现考试记忆锚点CS 对应易用性特征CharacteristicsATA 对应极端情况Extreme Situation 类语义ESAAM 即「扩展版」。题干若出现「评估架构在极端场景下的行为」直接锁定 ATASAAM。3.2 SAAM 的适用场景与局限适用关注点以非功能属性为主SAAM 本身就是非功能属性导向的方法。架构相对简单、质量需求尚未形成复杂的多属性交织权衡时——SAAM 不做属性间的权衡分析这是它与 ATAM 的本质分界。干系人需要快速、低成本地获得架构对变更适应性的判断。局限也是 ATAM 诞生的原因不分析质量属性间的权衡性能提升是否损害可修改性SAAM 不回答。场景覆盖不全的风险结论依赖所收集场景的代表性。对复杂的多属性交织系统如同时有严苛性能、安全、可用性要求的系统分析深度不足。一句话对比定调第 33 篇展开SAAM 用场景「检验」架构ATAM 用场景「权衡」架构——前者回答「支不支持」后者回答「这么做到底值不值、伤不伤别的属性」。3.3 SAAM 与 ATAM 的分界线预读进入第 33 篇前用一张小表固化两者边界避免案例答题时方法混用维度SAAMATAM评估焦点架构能否支撑场景非功能属性导向质量属性间的权衡与风险核心工具场景直接/间接分类效用树 场景 架构方法分析关键产出场景-架构映射表、修改代价估计敏感点/权衡点/风险/非风险四类判定适用架构较简单、属性间冲突不复杂多属性严苛交织的复杂系统案例题若只问「能否支持、怎么改」用 SAAM 话术作答若出现「权衡、敏感点、风险判定」字样必须切换到 ATAM 话术——方法用错框架分即失。四、SAAM 全流程演练智联云商通知模块评估把五步骤串成一个完整闭环案例答题时可整段迁移下单/支付/查询等 6 个更换短信供应商引入信用支付场景开发8 个场景6 个用例 2 个变更架构描述呈现三层架构与服务划分图场景分类直接场景现有架构可支撑间接场景需改架构场景交互评估两个场景均命中通知模块且通知模块同时承担模板渲染判定职责过载/高耦合风险形成报告建议拆分渠道适配层与模板层预计修改 3 构件/2 接口/5 人日演练结论可提炼为论文素材在智联云商微服务化前期我们采用 SAAM 方法对初版服务划分开展评估识别出 2 个间接场景与 1 处场景交互热点据此在编码前完成通知服务拆分避免了上线后通知通道切换牵连营销规则的连锁修改——这段叙述同时覆盖「评估方法 项目角色 量化结果」三个论文采分维度。五、本模块方法论沉淀评估方法的演进逻辑SAAM 1993场景检验非功能属性ATAM场景效用树权衡分析敏感点/权衡点判定CBAM成本效益视角在 ATAM 基础上算经济账SAAM 变体CS/ESAAM/ATASAAM垂直方向特化三种主流方法的演进是「检验 → 权衡 → 算账」逐步深化的过程SAAM 奠定场景驱动评估范式ATAM 引入效用树第 31 篇与权衡分析回答「架构决策如何同时影响多个质量属性」CBAM 再叠加成本维度回答「投入是否划算」。理解这条演进线第 33、34 篇的知识就不再是孤立的方法清单而是同一条问题链上的三次深化。本篇小结知识点核心内容评估三分类提问清单、度量指标、场景考验架构——场景法最主流评估时机架构定型之前越早修复成本越低、评估收益越大SAAM 五步场景开发→架构描述→场景分类→场景交互评估→形成报告顺序必背直接/间接场景直接 不改架构即支持间接 需修改构件/连接须列修改点与代价场景交互多场景命中同一构件 高耦合风险是架构改进的信号三变体SAAMCS 易用性、ESAAM 扩展版、ATASAAM 极端情况SAAM 边界非功能属性导向、架构较简单适用不做属性权衡ATAM 补位下篇预告第 33 篇架构评估二ATAM 方法与评估实战ATAM 九步骤全景、敏感点/权衡点/风险点/非风险四类判定案例分析必考判定题的判定口诀、效用树驱动的场景分析、智联云商 ATAM 全真演练——评估模块的皇冠明珠。如果本篇内容对你有帮助欢迎点赞收藏有任何疑问欢迎在评论区交流。