软考高级架构 - 8.3 - ATAM方法架构评估实践 - 超详细讲解+精简总结

总结：（文末有PPT讲解）

        ATAM时评估架构的质量属性方法，帮助权衡和识别风险，分为四个阶段。

• 阶段1——演示

        介绍ATAM方法，介绍软件商业目标和关键需求，详细介绍要被评估的架构。

• 阶段2——调查和分析

        深入分析系统架构，评估关键质量属性，并使用效用树来表示和优先化系统目标，确保架构支持关键质量属性。

• 阶段3——测试

        进行头脑风暴以收集情景，分析高优先级的质量属性和架构方法，找出风险、非风险、敏感点和权衡点，深入理解架构在满足质量属性上的表现。

• 阶段4——报告

        整理和报告评估结果，包括效用树、场景集合、分析问题、风险清单和架构方法的发现，以便利益相关者对系统的质量有全面的认识和改进建议。

8.3 ATAM方法架构评估实践

        ATAM（Architecture Tradeoff Analysis Method）是评估软件架构质量属性需求的方法，它帮助架构师和利益相关者识别架构设计中的权衡和风险。ATAM的实践包括以下几个阶段：

阶段1——演示

第一步：介绍ATAM

        评估负责人向参与者解释ATAM方法、如何评估、使用哪些技术，以及最终期望得到的结果。

第2步：介绍业务驱动因素

       解释为什么系统是这样设计的，也就是它的商业目标和关键需求。团队会讲述系统的主要功能、利益相关方（如最终用户、架构师、开发人员）是谁，以及他们的期望和关心的问题。

第3步：介绍要评估的体系结构

        架构团队详细展示被评估的体系结构，包括它是如何工作的、有哪些技术限制、与其他系统如何交互，以及为了满足性能、可靠性等质量要求采取了哪些措施。

阶段2——调查和分析

第4步：确定架构方法

在这一步，架构团队需要解释架构是如何工作的，以及它是如何满足系统的关键需求的。例如，他们会描述系统处理输入、事件管理和组件交互的方式。举个例子：

• 胡佛架构：输入被传递到事件管理器处理，存储在队列中，按顺序处理，并分配给合适的处理程序。这种架构的优势是高可修改性和组件的独立重用性，但也有扩展的能力。

• “银行”活动架构：该架构初始化和处理事件时，有一系列严格的检查，确保输入的有效性。但这种架构可修改性较差，组件间的依赖性较高，使得重用性较低。

第5步：生成质量属性效用树

        在这一步，团队会确定系统中最重要的质量属性，并按优先级排列。这种“效用树”帮助参与者理解哪些质量属性对系统成功最重要。每个属性通过场景（例如，如何响应用户输入）进行表达，以便更清晰地判断系统是否符合这些目标。场景由利益相关者提供，反映他们对系统的期望和互动。

第6步：分析架构与情景

        在这个步骤中，评估团队将场景与架构方法进行匹配，寻找架构是否能满足这些场景中的质量属性需求。利益相关者和评估团队一起识别出在架构中可能存在的风险和挑战。

阶段3——测试

第7步——头脑风暴和优先场景

     这一阶段旨在通过头脑风暴收集利益相关者的意见，找到与系统质量属性相关的重要场景。然后将这些场景与之前生成的效用树中的场景进行比较和合并。

1. 收集场景：进行头脑风暴活动，利益相关者提出不同的场景。这些场景可以是：

   • 用例场景：关注系统的实际使用，如最终用户的操作方式。
   • 增长场景：描述系统随着时间发展时的扩展方式。
   • 探索性场景：模拟极端情况下系统的表现，如负载突增。

2. 场景优先排序：

   • 将收集到的所有场景进行归类，合并类似的场景。
   • 利益相关者进行投票来选出最重要的场景，每人有固定数量的选票，通常为场景总数的30%。
   • 投票结束后，记录票数，并按票数高低排序，取截止线以上的场景用于后续分析。

3. 比较和整合场景：

   • 将头脑风暴中优先的场景与之前步骤（第5步）中效用树里的场景进行比较。
   • 如果新场景属于已有的质量属性分支，就合并在一起；否则，将其作为新叶子节点添加到树中。

第8步——分析架构方法

       主要目标是分析架构是否能够满足在前一步中识别出的高优先级质量属性，并找出潜在的风险、非风险、敏感点和权衡点。以下是详细步骤：

1. 调查架构方法

这部分分析特定架构设计是否支持实现关键质量属性：

• 安全性：验证系统是否能够防止未经授权的访问，并提供数据机密性。
• 性能：评估系统在响应速度和事务处理效率上的表现。

胡佛架构分析：

• 安全性：胡佛架构通过将数据封装在事件管理器内实现了较好的数据保护，避免了未经授权的访问。
• 性能：由于涉及的组件较少且处理流程简单，系统可以较快地完成任务，满足性能要求。

银行架构分析：

• 安全性：由于应用程序信息分散在多个组件中，系统难以保持数据机密性，整体安全性较弱。
• 性能：处理一个事件涉及的组件数量多，导致响应时间长，不利于性能优化。

2. 创建分析问题

根据高优先级情景，形成以下分析问题：

1. 系统是否限制未经授权访问？（安全）
2. 架构是否保障数据机密性？（安全）
3. 架构是否以最快速度处理任务？（性能）

3. 分析问题的答案

对这两种架构回答上述问题：

• 胡佛架构：
  1. 未经授权的访问得到有效限制。
  2. 数据未在多组件中暴露，确保了机密性。
  3. 因涉及的组件数量少，能快速处理任务。
• 银行架构：
  1. 多组件允许访问，未经授权的风险较大。
  2. 应用程序信息在多组件中暴露，数据机密性较差。
  3. 组件数量多导致任务处理速度慢。

4. 识别风险、非风险、敏感点和权衡点

风险与非风险：

• 胡佛架构：无重大风险，性能和安全性被认为是非风险。
• 银行架构：安全性和性能都是风险。

敏感点：

• 数据保密性对嵌入应用程序位置的数量敏感。
• 处理任务的速度对涉及的组件数量敏感。

权衡点：

• 应用程序特定信息的嵌入位置。
• 处理任务所涉及的组件数量。

总结

胡佛架构在保持数据保密性和性能方面表现较好，而银行架构存在安全性和性能的风险，难以满足高优先级质量属性的需求。

阶段4——报告ATAM

        在此阶段，评估团队会将整个评估过程中收集到的所有信息整合并呈现给利益相关者。

ATAM 团队的主要发现包括：

• 效用树：用于展示系统的整体质量目标及其优先级。
• 生成的场景集合：包含了从头脑风暴和分析中得到的各种情景。
• 分析问题集合：针对质量属性提出的具体问题。
• 风险和非风险清单：识别了系统中的潜在问题和安全领域。
• 确定的架构方法：对比和分析不同架构方法及其在满足质量属性方面的表现。

报告内容概述：

        报告涵盖了前述 ATAM 评估的8个步骤中产生的所有关键信息，旨在帮助利益相关者理解系统架构的质量特征、潜在风险、以及如何改进或优化系统以实现其质量目标。

原文地址：https://blog.csdn.net/weixin_43960657/article/details/143593980

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！