Chpater21 架构评估

三种评估形式

• 设计过程中由设计师进行的评估。
• 设计过程中由同行进行的评估。
• 架构设计完成后由外部人员进行的分析。

设计师的评估(Evaluation by the Designer)

• 每当设计师做出关键设计决策时，应对选择的备选方案进行评估。
• “生成和测试”方法中的“测试”部分。
• 需要进行多少分析？有三个因素包括：
  • 决策的重要性。
  • 潜在备选方案的数量。更多的备选方案需要更多的时间进行评估。
  • 足够好与完美相对。不要在决策上花费超过其价值的时间。

同行评审(Peer Review)

• 架构设计可以像代码一样进行同行评审。
• 同行评审可以在设计过程的任何阶段进行，只要存在一个候选架构，或者至少存在一个连贯可审查的部分。
• 至少分配几个小时，可能需要半天的时间。

同行评审步骤

1. 评审人确定一些质量属性场景来引导评审。
2. 架构师呈现要评估的架构部分。目的是让评审人员了解架构。
3. 对于每个场景，设计师遍历架构并解释如何满足该场景。
4. 潜在问题被记录下来。

外部人员的分析(Analysis by Outsiders)

• “外部”是相对的；它可以意味着
  • 在开发项目之外
  • 在项目所在的业务部门之外，但在同一家公司内部
  • 在公司之外。
• 选择外部人员是因为他们拥有专业知识或经验。
• 管理人员倾向于更愿意倾听外部团队发现的问题。
• 用于评估完整的架构。

评估的背景因素(Contextual Factors for Evaluation)

• 结果是公开还是私密的。
• 评估人员的数量和技能。
• 参与的利益相关者是谁。
• 评估人员对业务目标的理解程度。

架构权衡分析方法(The Architecture Tradeoff Analysis Method, ATAM)

• 架构权衡分析方法（ATAM）已经在过去十年中被用于评估从汽车到金融再到国防等各个领域的软件架构。
• ATAM 的设计使评估人员无需熟悉架构或其业务目标，系统尚未构建，可能有大量的利益相关者。

ATAM 的参与者

• 评估团队
  • 3 至 5 人
  • 能胜任的、公正的外部人员
• 项目决策者
  • 项目经理、架构师和担任开发计费的客户
• 架构相关方
  • 开发人员、测试人员、集成人员、维护人员、性能工程师、用户、系统构建者
  • 阐述具体的质量属性目标
  • 对于一个大型的企业关键架构，可能涉及 12 至 15 个相关方。

ATAM 的主要输出

• 一组风险和非风险
  • 风险被定义为在质量属性要求下可能导致不良后果的架构决策。
  • 非风险是被认为安全的架构决策。
• 一组风险主题
  • 检查所有的风险，寻找能够识别架构中系统弱点的主题。
  • 这些风险主题将威胁到项目的业务目标。

ATAM 的其他输出

1. 架构的简明介绍。
2. 业务目标的阐述。
3. 按照质量属性场景表达的优先级排序的质量属性要求。
4. 将架构决策与质量要求进行映射。
5. 一组确定的敏感性和权衡点：对一个或多个质量属性有显著影响的架构决策。

步骤

第一步：介绍 ATAM

• 评估负责人简要描述 ATAM 的步骤和评估的输出。

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

• 项目决策者（最好是项目经理或系统的客户）从业务角度呈现系统概述。
• 该介绍应描述：
  • 重要功能
  • 相关的技术、管理、经济或政治限制
  • 业务目标和背景
  • 主要利益相关者
  • 架构驱动因素（架构上重要的需求）

第三步：介绍架构

• 主架构师进行介绍，描述架构的内容。
  • 技术限制，如操作系统、硬件或中间件的规定使用方式，以及系统必须与之交互的其他系统。
  • 架构方法，即用于满足需求的模式和策略。
• 应该传达架构的核心思想，而不要过于深入细节。

第四步：确定架构方法

• 理解架构的方法，特别是模式和策略。
• 评估团队对已确定的模式和策略进行分类。
• 列表被公开记录，并将作为后续分析的基础。

第五步：生成效用树

• 评估团队与项目决策者合作，确定、优先排序和完善系统的最重要的质量属性目标。
• 通过质量属性效用树详细阐述质量属性目标。
• 场景被分配了重要性等级（高、中、低）。

第六步：分析架构方法

• 评估团队逐个检查最高排名的场景；要求架构师解释架构如何支持每个场景。
• 评估团队成员探究用于执行场景的架构方法。
• 评估团队记录相关的架构决策，并确定并分类它们的风险、非风险和权衡点。例如：
  • 风险：心跳频率影响系统检测到故障组件所需的时间。
  • 权衡：心跳频率确定检测故障所需的时间。更高的频率可以提高可用性，但会消耗更多的处理时间和通信带宽（可能降低性能）。

第七步：头脑风暴和优先排序场景

• 场景头脑风暴的目的是了解对利益相关者来说系统成功意味着什么。
• 一旦收集到场景，通过投票对其进行优先排序。
• 优先排序的场景列表与效用树练习中的场景进行比较。
  • 如果它们一致，表示架构师的想法与利益相关者实际期望相吻合。
  • 如果发现额外的关键场景，可能存在利益相关者和架构师之间的一些分歧，这本身可能是一个风险。

第八步：分析架构方法

• 在这一步中，评估团队执行与第六步相同的活动。

第九步：呈现结果

• 根据某些系统缺陷，评估团队将风险分组为风险主题。
  • 例如，一组关于系统在面对各种硬件和/或软件故障时无法正常工作的风险可能会导致关于未充分关注提供高可用性的风险主题。
• 对于每个风险主题，评估团队确定了受到第 2 步中列出的业务驱动因素的影响程度。
• 评估收集的信息被总结并向利益相关者呈现。
• 呈现以下输出：
  • 记录的架构方法
  • 来自头脑风暴的场景集合及其优先级排序
  • 效用树
  • 发现的风险
  • 记录的非风险
  • 发现的敏感点和权衡点
  • 风险主题及其威胁到每个业务驱动因素的情况

ATAM 中的阶段

阶段	活动	参与者	典型持续时间
0	合作伙伴关系和准备：物流、规划、利益相关者招募、团队组建	评估团队领导和主要项目决策者	根据需要进行，可能持续几周
1	评估：步骤 1-6	评估团队和项目决策者	1-2 天，然后中断 2-3 周
2	评估：步骤 7-9	评估团队、项目决策者、利益相关者	2 天
3	后续：报告生成和交付、流程改进	评估团队和评估客户	1 周

轻量级架构评估

• ATAM 是一项庞大的工作
  • 它需要一个由评估团队组成的人力投入，大约需要 20 到 30 个人天的工作量，而架构师和利益相关者的投入可能更多。
  • 在大型和昂贵的项目中投入这么多时间是有意义的。
• 针对规模较小、风险较低的项目，有一种轻量级的架构评估方法。
  • 可以在一天内甚至是半天的会议中进行。
  • 可以完全由组织内部成员来执行。
  • 当然，这种方法可能无法深入探究架构。

步骤	时间	备注
1. 展示 ATAM	0 小时	参与者已熟悉该过程。
2. 展示业务驱动因素	0.25 小时	预期参与者理解系统及其业务目标和优先级。对这些内容进行简要回顾，确保大家都掌握，并且没有意外情况。
3. 展示架构	0.5 小时	所有参与者都应熟悉该系统。介绍架构的简要概述，至少使用模块和 C&C 视图。通过这些视图追踪 1-2 个场景。
4. 确定架构方法	0.25 小时	架构师确定特定质量属性关注点的架构方法。这可以作为第 3 步的一部分完成。
5. 生成 QA 效用树	0.5-1.5 小时	场景可能存在于先前的评估、设计或需求收集的一部分。将这些场景放入一棵树中。或者，可能已经存在一个效用树。
6. 分析架构方法	2-3 小时	此步骤将高排名的场景映射到架构中，耗费大部分时间，可以根据需要进行扩展或压缩。
7. 头脑风暴场景	0 小时	可以省略此步骤，因为预期组合（内部）利益相关者将在第 5 步中贡献表达他们关注的场景。
8. 分析架构方法	0 小时	由于所有分析都在第 6 步中完成，因此可以省略此步骤。
9. 展示结果	0.5 小时	在评估结束时，团队回顾现有和新发现的风险、非风险、敏感性和权衡，并讨论是否出现了任何新的风险主题。

总结

• 如果一个系统对你来说很重要，那么该架构应该进行评估。
• ATAM是一种全面评估软件架构的方法。
• 基于 ATAM 的轻量级架构评估提供了一种廉价的架构评估方法，可在几个小时内完成。
• 每个项目的评估数量和范围可能因项目而异。
  • 设计师应在做出重要决策的过程中进行评估。
  • 可以在项目期间多次进行轻量级评估，作为同行评审的一部分。