SAAM（Software Architecture Analysis Method）是一种早期的软件架构评估方法

题13的正确答案是 D。SAAMSoftware Architecture Analysis Method是一种早期的软件架构评估方法侧重于通过场景分析来评估架构对质量属性如可修改性、性能等的支持程度而ATAMArchitecture Tradeoff Analysis Method是在SAAM基础上发展起来的更全面、更系统的评估方法增加了风险识别、敏感点/权衡点分析、质量属性效用树等机制。关键区别如下A 正确SAAM步骤较少主要包括场景生成、架构描述、场景评估、结果汇总ATAM步骤更多含介绍阶段、调查与演示、场景和需求收集、架构分析、报告等B 正确SAAM本身不显式包含系统性的风险识别与跟踪机制而ATAM明确将风险作为核心分析对象C 正确SAAM对质量属性未作严格区分和优先级排序常以通用场景驱动ATAM则要求明确质量属性目标并构建效用树强调属性间的权衡D 错误即“不包括”的选项SAAM通常只需1–2天完成ATAM需3–5天甚至更久因此SAAM更省时D项表述与事实相反故为本题答案。# 简要对比表伪代码形式示意saam_vs_atam{duration:{SAAM:1-2 days,ATAM:3-5 days},risk_analysis:{SAAM:implicit/none,ATAM:explicit structured},quality_attribute_handling:{SAAM:scenario-driven, undifferentiated,ATAM:utility-tree-based, prioritized traded}}SAAM中的“场景”是评估架构的核心输入其生成和使用过程如下生成方式场景由利益相关者如客户、开发人员、维护人员提出聚焦于系统预期行为或变更需求例如“在不修改核心模块的前提下将报表导出格式从PDF扩展为Excel”场景强调具体性、可操作性、与架构元素的可映射性但不要求按质量属性分类或量化优先级通常由评估主持人引导头脑风暴获得数量一般为10–30个覆盖主要功能与变更点。使用方式将每个场景映射到架构中对应的构件、连接件及交互路径分析架构是否能直接支持该场景支持/部分支持/不支持识别冲突、冗余或缺失的机制汇总结果形成“场景支持矩阵”据此判断架构在可修改性等关键质量属性上的优劣SAAM虽不显式区分质量属性但实际分析常隐含指向可修改性、功能性等。与ATAM中“效用场景”的本质差异维度SAAM场景ATAM效用场景目的验证架构对变更/行为的响应能力量化评估架构满足关键质量目标的程度来源利益相关者自发提出无结构约束基于效用树Utility Tree自顶向下推导严格对应质量属性及其子目标形式要求自然语言描述无需优先级或权重必须包含刺激Stimulus、环境Environment、响应Response、响应度量Response Measure四要素分析粒度宏观、定性支持/不支持细粒度、半定量如“95%请求在200ms内响应”作用揭示架构结构性问题支撑风险识别、敏感点定位与权衡决策简言之SAAM场景是驱动式、经验性、轻量级的探针ATAM效用场景是目标导向、结构化、可度量的质量验证契约。# SAAM场景示例非结构化saam_scenario用户希望新增短信通知功能且不影响现有邮件通知模块# ATAM效用场景示例四要素完备atam_utility_scenario{quality_attribute:availability,stimulus:主数据库宕机,environment:系统处于高峰负载1000 TPS,response:自动切换至备用数据库并恢复服务,response_measure:RTO ≤ 30秒数据丢失 ≤ 1条事务}