文章目录
第21章 评估架构
医生可以掩埋自己的错误，但建筑师只能建议客户种上藤蔓。
—Frank Lloyd Wright
在 第 2 章 中，我们提到架构之所以重要的一个主要原因是，在构建系统之前，通过检查其架构，你可以预测从中衍生出来的任何系统的质量属性。如果你仔细想想，这是一个相当不错的事情。而这一章就是这种能力得以体现的地方。
“架构评估” 是确定架构在多大程度上适合其预期目的的过程。架构对系统和软件工程项目的成功起着如此重要的作用，因此停下来确保你正在设计的架构能够提供所有预期的功能是有意义的。这就是评估的作用，它基于对各种替代方案的分析。幸运的是，有一些成熟的方法可以分析架构，这些方法使用了你在本书中已经学到的许多概念和技术。
为了有用，评估的成本需要低于它所提供的价值。考虑到这种关系，一个重要的问题是 “评估将花费多少时间和金钱？” 不同的评估技术有不同的成本，但所有这些都可以根据参与评估活动的准备、执行和后续工作的人员所花费的时间来衡量。
22.1 评估作为一种降低风险的活动
每一个架构都伴随着风险。架构评估的输出包括识别架构中的风险部分。风险是一个既有影响又有概率的事件。风险的预估成本是该事件发生的概率乘以影响的成本。修复这些风险不是评估的输出。一旦风险被识别出来，那么修复它们就像评估本身一样，是一个成本 / 收益的问题。
将这个概念应用到架构评估中，你可以看到，如果正在构建的系统成本达数百万或数十亿美元，或者具有重大的安全关键影响，那么风险事件的影响就会很大。相比之下，如果系统是一个基于控制台的游戏，创建成本为几万或几十万美元，那么风险事件的影响就会小得多。
风险事件的概率与正在开发的系统及其架构的先例性或无前例性等因素有关。如果你和你的组织在这个领域有长期而深入的经验，那么产生不良架构的概率就会比这个项目是你的首次尝试时要小。
因此，评估就像一份保险。你需要多少保险取决于你对不适当架构的风险暴露程度以及你的风险承受能力。
评估可以在开发过程的不同阶段进行，由不同的评估人员进行，并且评估的执行方式也有所不同 —— 我们将在本章中介绍一些选项。无论其具体细节如何，评估都建立在你已经学到的概念之上：系统是为了满足业务目标而构建的，业务目标通过质量属性场景来体现，而质量属性目标是通过应用策略和模式来实现的。
21.2 有哪些关键的评估活动？
无论由谁进行评估以及何时进行评估，评估都是基于架构驱动因素 —— 主要是以质量属性场景表示的架构重要需求（ASRs）。第 19 章 描述了如何确定 ASRs。进入评估的 ASRs 的数量是上下文因素和评估成本的函数。接下来我们描述架构评估的可能上下文因素。
在设计过程中的任何一点，只要存在候选架构，或者至少存在一个连贯的可审查部分，就可以进行评估。
每次评估都应该包括（至少）以下步骤：
- 评审人员各自确保他们理解架构的当前状态。这可以通过共享文档、架构师的演示或这些方式的某种组合来实现。
- 评审人员确定一些驱动因素来指导评审。这些驱动因素可能已经有文档记录，也可以由评审团队或其他利益相关者制定。通常，最重要的评审驱动因素是高优先级的质量属性场景（而不是纯粹的功能用例）。
- 对于每个场景，每个评审人员都应该确定该场景是否得到满足。评审人员提出问题以确定两种类型的信息。首先，他们要确定场景实际上得到了满足。这可以通过让架构师讲解架构并解释场景是如何得到满足的来实现。如果架构已经有文档记录，那么评审人员可以使用该文档进行评估。其次，他们要确定由于正在评审的架构部分中做出的决策，是否有任何其他正在考虑的场景将无法得到满足。评审人员可以针对当前设计的任何有风险的方面提出替代方案，这些替代方案可能更好地满足场景。这些替代方案应该接受相同类型的分析。时间限制在确定这一步骤可以持续多长时间方面起作用。
- 评审人员记录在前一步中暴露的潜在问题。这个潜在问题列表构成了评审后续工作的基础。如果潜在问题是一个实际问题，那么要么必须解决它，要么设计师和项目经理必须明确做出决定，即他们愿意接受风险。
你应该进行多少分析呢？为实现一个驱动架构需求而做出的决策应该比其他决策进行更多的分析，因为它们将塑造架构的关键部分。一些具体的考虑因素包括：
- 决策的重要性。决策越重要，在做出决策和确保其正确性时就应该越谨慎。
- 潜在替代方案的数量。替代方案越多，评估它们可能花费的时间就越多。
- 足够好而不是完美。很多时候，两个可能的替代方案在其后果上没有显著差异。在这种情况下，做出选择并继续进行设计过程比绝对确定正在做出最佳选择更为重要。
21.3 谁可以进行评估？
评估人员应该在系统所要评估的领域以及各种质量属性方面具备高技能。出色的组织和引导能力对于评估人员来说也是必不可少的。
由架构师进行评估
每次架构师做出关键设计决策以解决架构重要需求（ASR）或完成设计里程碑时，都会进行（隐性或显性的）评估。这种评估涉及在相互竞争的替代方案中做出决策。正如我们在 第 20 章 中讨论的那样，由架构师进行的评估是架构设计过程的一个组成部分。
通过同行评审进行评估
针对 ASR 的架构设计可以像代码一样进行同行评审。应该为同行评审分配固定的时间，通常是几个小时到半天。
如果设计人员正在使用 第 20 章 中描述的属性驱动设计（ADD）过程，那么可以在每次 ADD 迭代的步骤 7 结束时进行同行评审。评审人员还应该使用我们在 第 4 章-第 13 章 中介绍的基于策略的问卷。
由外部人员进行评估
外部评估人员可以更客观地看待架构。“外部” 是相对的；这可能意味着在开发项目之外、项目所在业务单元之外但在同一家公司内，或者完全在公司之外。在一定程度上，评估人员越是 “外部的”，他们就越不太可能害怕提出敏感问题，或者因为组织文化或 “我们一直都是这样做的” 而不明显的问题。
通常，选择外部人员参与评估是因为他们拥有专业知识或经验，例如对正在审查的系统很重要的质量属性的知识、对所采用的特定技术的技能，或者在成功评估架构方面有长期经验。
此外，无论是否合理，经理们往往更倾向于听取由花费大量成本聘请的外部团队发现的问题，而不是组织内的团队成员提出的问题。对于可能已经抱怨了数月相同问题却毫无结果的项目工作人员来说，这可能会令人沮丧，这是可以理解的。
原则上，外部团队可以评估一个完整的架构、一个不完整的架构或架构的一部分。在实践中，由于聘请他们很复杂且通常很昂贵，所以他们往往被用于评估完整的架构。
21.4 背景因素
对于同行评审或外部分析，在设置评估时必须考虑许多背景因素：
- 有哪些工件可用？ 要进行架构评估，必须有一个既描述架构又容易获取的工件。一些评估可能在系统运行后进行。在这种情况下，可以使用一些架构恢复和分析工具来帮助发现架构、查找架构设计缺陷，并测试已建成的系统是否符合设计的系统。
- 谁能看到结果？ 一些评估是在所有利益相关者完全知情并参与的情况下进行的。其他评估则更私密地进行。
- 哪些利益相关者将参与？ 评估过程应该包括一种方法来引出重要利益相关者对系统的目标和关注点。在这个阶段，确定所需的人员并确保他们参与评估至关重要。
- 业务目标是什么？ 评估应该回答系统是否将满足业务目标。如果在评估之前没有明确捕获并确定业务目标的优先级，那么评估的一部分应该致力于此任务。
同行和外部评估人员进行的评估很常见，因此我们有正式的流程来指导评估。这些流程定义了谁应该参与以及在评估期间应该进行哪些活动。正式确定流程可以让组织使该流程更具可重复性，帮助利益相关者了解评估将需要什么以及将交付什么，培训新的评估人员使用该流程，并了解进行评估所需的投入。
我们首先描述一个外部评估人员的流程（架构权衡分析方法）；然后描述一个同行评审的流程（轻量级架构评估）。
21.5 架构权衡分析方法
架构权衡分析方法（ATAM）是我们为进行架构评估而正式确定的流程。二十多年来，ATAM 一直被用于评估从汽车到金融再到国防等领域的大型系统的软件架构。ATAM 的设计使得评估人员无需事先熟悉架构或其业务目标，并且系统也无需已经构建完成。ATAM 评估可以面对面进行，也可以远程进行。
ATAM 的参与者
ATAM 需要三个群体的参与和相互合作：
-
评估团队：这个群体来自正在被评估架构的项目外部。它通常由三到五人组成。在评估期间，团队的每个成员都被分配了一些特定的角色；在一次 ATAM 评估中，一个人可能承担多个角色。（有关这些角色的描述请参见 表 21.1。）评估团队可以是一个定期进行架构评估的常设单位，或者其成员可以从一群有架构意识的人员中为特定场合挑选出来。他们可以与架构正在被评估的开发团队来自同一组织，也可以是外部顾问。在任何情况下，他们都需要被认为是有能力、无偏见的外部人员，没有隐藏的议程或别有用心的目的。
表 21.1 ATAM 评估团队角色
角色 职责 团队领导 进行评估设置；与客户进行协调，确保满足客户需求；建立评估合同；组建评估团队；确保最终报告得以生成并交付。 评估负责人 主持评估；促进场景的引出；管理场景优先级确定过程；促进根据架构对场景进行评估。 场景记录员 在场景引出过程中以可共享的、公开的形式编写场景；记录每个场景的商定措辞，在准确措辞被记录下来之前暂停讨论。 电子记录员 以电子形式记录评估过程：原始场景、激发每个场景的问题（这些问题常常在场景的措辞中被遗漏）以及每个场景分析的结果；还生成一份已采纳场景的列表分发给所有参与者。 提问者 提出基于质量属性的深入问题。 -
项目决策者。这些人有权代表开发项目发言，或者有权强制对项目进行变更。他们通常包括项目经理，如果有可识别的客户为开发项目付费，那么该客户的代表也可能出席。架构师总是包括在内——架构评估的一条重要规则是架构师必须自愿参与。
-
架构利益相关者。利益相关者在架构如所宣传的那样运行时有既得利益。他们是那些能否完成工作取决于架构是否促进可修改性、安全性、高可靠性等的人。利益相关者包括开发人员、测试人员、集成人员、维护人员、性能工程师、用户以及与正在考虑的系统进行交互的其他系统的构建者。在评估期间，他们的工作是明确架构应该满足的特定质量属性目标，以使系统被认为是成功的。一个经验法则 —— 也仅仅是一个经验法则 —— 是在评估一个大型企业关键架构时，你应该期望招募 10 到 25 个利益相关者。与评估团队和项目决策者不同，利益相关者并不参与整个评估过程。
ATAM 的产出
- 简洁的架构呈现：ATAM 的一个要求是在一个小时或更短的时间内呈现架构，这使得架构呈现既简洁又通常易于理解。
- 明确阐述业务目标：在 ATAM 评估过程中呈现的业务目标常常是一些参与者首次看到的，这些目标会在输出结果中被捕获。对业务目标的这种描述会在评估后留存下来，成为项目遗产的一部分。
- 以质量属性场景形式表达的已确定优先级的质量属性需求：这些质量属性场景采用 第 3 章 中描述的形式。ATAM 使用已确定优先级的质量属性场景作为评估架构的基础。这些场景可能已经存在（也许是由于先前的需求捕获活动或属性驱动设计（ADD）活动的结果），但如果不存在，它们将由参与者在 ATAM 评估过程中生成。
- 一组风险和非风险：架构风险是指根据已声明的质量属性需求可能导致不良后果的决策。类似地，架构非风险是指经过分析被认为是安全的决策。已识别的风险构成架构风险缓解计划的基础。这些风险是 ATAM 评估的主要输出结果。
- 一组风险主题：当分析完成时，评估团队检查所有已发现的风险，以寻找总体主题，这些主题可以确定架构甚至架构过程和团队中的系统性弱点。如果不加以处理，这些风险主题将威胁项目的业务目标。
- 将架构决策映射到质量需求：架构决策可以根据它们支持或阻碍的驱动因素来解释。对于在 ATAM 评估过程中检查的每个质量属性场景，确定并捕获那些有助于实现该场景的架构决策。它们可以作为这些决策的理由陈述。
- 一组已确定的敏感点和权衡点：敏感点是对质量属性响应有显著影响的架构决策。当两个或多个质量属性响应对同一架构决策敏感，但其中一个得到改善而另一个恶化时，就会出现权衡。
ATAM 评估的输出结果可用于构建最终报告，该报告回顾评估方法、总结评估过程、捕获场景及其分析，并对评估结果进行分类。
基于 ATAM 的评估还会产生一些不应被忽视的无形结果。这些结果包括利益相关者的社区感、架构师与利益相关者之间开放的沟通渠道，以及所有参与者对架构及其优缺点的更好整体理解。虽然这些结果难以衡量，但它们与其他结果同样重要。
ATAM 的阶段
基于 ATAM 的评估活动分布在四个阶段：
- 在第 0 阶段 “合作与准备” 中，评估团队领导和关键项目决策者制定评估的细节。项目代表向评估人员介绍项目，以便评估团队可以由具有适当专业知识的人员补充。两个小组共同商定后勤事宜，例如评估的时间和用于支持会议的技术。他们还商定利益相关者的初步名单（按姓名而不仅仅是角色），并协商最终报告的交付时间和交付对象。他们处理诸如工作说明书或保密协议等手续。评估团队检查架构文档以了解架构及其包含的主要设计方法。最后，评估团队领导解释在第 1 阶段期望经理和架构师展示哪些信息，并在必要时帮助他们构建演示文稿。
- 在第 1 和第 2 阶段，统称为 “评估”，每个人都开始进行分析工作。到这时，评估团队将已经研究了架构文档，并对系统的内容、采用的主要架构方法以及至关重要的质量属性有很好的了解。在第 1 阶段，评估团队与项目决策者会面，开始信息收集和分析。在第 2 阶段，架构的利益相关者为评估过程和分析提供他们的输入。
- 在第 3 阶段 “跟进” 中，评估团队生成并交付最终报告。这份报告 —— 可能是一份正式文件或仅仅是一组幻灯片 —— 首先分发给关键利益相关者，以确保其中没有理解错误。在这次审查完成后，它将交付给客户。
表 21.2 显示了 ATAM 的四个阶段、每个阶段的参与者以及在该活动上花费的典型累计时间 —— 可能分几个阶段进行。
表 21.2 ATAM 阶段及其特征
| 阶段 | 活动 | 参与者 | 典型累计时间 |
|---|---|---|---|
| 0 | 合作与准备。 | 评估团队领导和关键项目决策者。 | 根据需要非正式地进行，可能持续几周。 |
| 1 | 评估 | 评估团队和项目决策者。 | 1–2 天 |
| 2 | 评估（续） | 评估团队、项目决策者和利益相关者。 | 2天 |
| 3 | 跟进 | 评估团队和评估客户。 | 1 周 |
來源：改編自[Clements 01b]。
评估阶段的步骤
ATAM 分析阶段（阶段 1 和阶段 2）包括九个步骤。步骤 1 至步骤 6 在阶段 1 由评估团队和项目决策者（通常是架构团队、项目经理和客户）执行。在阶段 2，所有利益相关者参与进来，对步骤 1 至步骤 6 进行总结，并执行步骤 7 至步骤 9。
步骤 1：介绍 ATAM
步骤1要求评估负责人向聚集的项目代表介绍 ATAM。这个时间用于解释每个人将遵循的流程、回答问题，并为后续活动设定背景和期望。使用标准演示文稿，负责人简要描述 ATAM 步骤和评估的输出结果。
步骤 2：介绍业务目标
参与评估的每个人 —— 项目代表以及评估团队成员 —— 都需要了解系统的背景以及推动其开发的主要业务目标。在这一步中，项目决策者（理想情况下是项目经理或客户代表）从业务角度呈现系统概述。这个演示应描述项目的以下方面：
步骤 3：介绍架构
首席架构师（或架构团队）进行演示，以适当的详细程度描述架构。“适当的程度” 取决于几个因素：架构设计和记录的程度、可用的时间以及行为和质量需求的性质。
在这个演示中，架构师涵盖技术约束，例如操作系统、规定使用的平台以及该系统必须与之交互的其他系统。最重要的是，架构师描述用于满足需求的架构方法（或模式，或策略，如果架构师熟悉这些词汇）。
我们期望如 第 1 章 中介绍并在 第 22 章 中详细描述的架构视图成为架构师传达架构的主要手段。上下文图、组件和连接器视图、模块分解或分层视图以及部署视图在几乎每个评估中都很有用，架构师应准备好展示它们。如果其他视图包含与手头架构相关的信息，特别是与满足重要质量属性需求相关的信息，则可以展示这些视图。
步骤 4：识别架构方法
ATAM 通过理解架构方法来分析架构。架构模式和策略对于（除其他原因外）每种方法以已知方式影响特定质量属性是有用的。例如，分层模式往往会为系统带来可移植性和可维护性，可能以性能为代价。发布 - 订阅模式在数据的生产者和消费者数量方面具有可扩展性，而主动冗余模式可提高高可用性。
步骤 5：生成质量属性效用树
质量属性目标通过质量属性效用树进行详细阐述，我们在 19.4 节 中介绍了效用树。效用树通过精确定义架构师努力提供的相关质量属性需求来使需求具体化。
在考虑中的架构的重要质量属性目标在 “步骤2：介绍业务目标” 时被命名或暗示，但没有达到足以进行分析的具体程度。诸如 “可修改性”“高吞吐量” 或 “能够移植到多个平台的能力” 等广泛目标确立了背景和方向，并为后续信息的呈现提供了背景。然而，它们不够具体，无法让我们判断架构是否足以实现这些目标。在哪些方面可修改？吞吐量有多高？移植到哪些平台以及需要多少时间？这些问题的答案以表示具有架构重要性的需求的质量属性场景的形式表达。
回想一下，效用树是由架构师和项目决策者构建的。他们一起确定每个场景的重要性：架构师对场景的技术难度或风险进行评级（H、M、L 级别），项目决策者对其业务重要性进行评级。
步骤 6：分析架构方法
估团队依次检查排名最高的场景（如在效用树中确定的）；要求架构师解释架构如何支持每个场景。评估团队成员 —— 尤其是提问者 —— 探寻架构师用于实现场景的架构方法。在此过程中，评估团队记录相关架构决策，并识别和编目其风险、非风险和权衡。对于众所周知的方法，评估团队询问架构师如何克服该方法中的已知弱点，或者架构师如何获得该方法足以满足需求的保证。目标是让评估团队确信该方法的实例化对于满足其旨在满足的特定属性需求是适当的。
场景演练会引发对可能的风险和非风险的讨论。例如：
- 心跳频率影响系统检测故障组件的时间。某些分配将导致此响应的不可接受的值；这些是风险。
- 心跳频率决定故障检测时间。
- 更高的频率会提高可用性，但也会消耗更多的处理时间和通信带宽（可能导致性能降低）。这是一种权衡。
这些问题反过来可能会引发更深入的分析，具体取决于架构师的回应。例如，如果架构师无法描述客户端的数量，也不能说明如何通过将进程分配到硬件来实现负载均衡，那么进行任何性能分析都没有意义。如果这些问题可以得到回答，评估团队可以进行至少初步的或粗略的分析，以确定这些架构决策在满足它们旨在解决的质量属性需求方面是否存在问题。
步骤 6 中的分析并不意味着是全面的。关键是引出足够的架构信息，以在已做出的架构决策和需要满足的质量属性需求之间建立一些联系。
图 21.1 显示了用于捕获针对场景的架构方法分析的模板。如图所示，基于这一步骤的结果，评估团队可以识别并记录一组风险和非风险、敏感点和权衡。
图 21.1 架构方法分析示例（改编自 [Clements 01b]）
在步骤 6 结束时，评估团队应该对整个架构的最重要方面、关键设计决策的基本原理以及风险、非风险、敏感点和权衡点列表有清晰的了解。
至此，阶段 1 结束。
暂停与阶段 2 的开始
评估团队总结他们所学到的内容，并在大约一周的暂停期间与架构师进行非正式的互动。如果需要，在此期间可以分析更多的场景，或者可以澄清在阶段 1 中提出的问题的答案。
参加阶段 2 会议的人员包括更多的参与者，其他利益相关者加入讨论。用编程来打个比方：阶段 1 就像你用自己的标准测试自己的程序。阶段 2 就像你把你的程序交给一个独立的质量保证小组，他们可能会让你的程序在更广泛的测试和环境中进行测试。
在阶段 2 中，重复步骤 1，以便利益相关者理解该方法以及他们要扮演的角色。然后，评估负责人回顾步骤 2 至步骤 6 的结果，并分享当前的风险、非风险、敏感点和权衡点列表。在让利益相关者了解到目前的评估结果后，就可以进行剩下的三个步骤了。
步骤 7：头脑风暴并确定场景优先级
评估团队要求利益相关者就对他们各自的角色具有实际意义的质量属性场景进行头脑风暴。维护人员可能会提出一个可修改性场景，而用户可能会提出一个表达易操作性的场景，质量保证人员可能会提出一个关于测试系统或能够复制导致故障的系统状态的场景。
虽然生成效用树（步骤 5）主要是为了理解架构师如何感知和处理质量属性架构驱动因素，但场景头脑风暴的目的是了解更广泛的利益相关者群体的想法：了解对他们来说系统成功意味着什么。场景头脑风暴在较大的群体中效果很好，营造出一种一个人的想法和观点激发其他人的想法的氛围。
一旦收集到场景，就必须对其进行优先级排序，原因与效用树中的场景需要进行优先级排序的原因相同：评估团队需要知道在哪里投入有限的分析时间。首先，要求利益相关者合并他们认为代表相同行为或质量关注点的场景。接下来，他们对他们认为最重要的场景进行投票。每个利益相关者被分配的票数等于场景数量的 30%（向上取整）1。因此，如果收集了 40 个场景，每个利益相关者将获得 12 票。这些票可以由利益相关者以任何他们认为合适的方式分配：12 票都投给一个场景，1 票投给 12 个不同的场景中的每一个，或者介于两者之间的任何分配方式。
将已确定优先级的场景列表与效用树练习中的场景进行比较。如果它们一致，这表明架构师的想法与利益相关者的实际需求之间有良好的一致性。如果发现了其他驱动场景 —— 通常会这样 —— 如果差异很大，这本身可能就是一种风险。这样的发现表明利益相关者和架构师在系统的重要目标上存在一定程度的分歧。
步骤 8：分析架构方法
在步骤 7 中收集并确定场景优先级后，评估团队引导架构师分析排名最高的场景。架构师解释架构决策如何有助于实现每个场景。理想情况下，此活动将主要由架构师根据先前讨论的架构方法解释场景。
在这一步中，评估团队执行与第6步相同的活动，使用新生成的排名最高的场景。通常，根据时间允许，这一步可能涵盖前五个到十个场景。
步骤 9：呈现结果
在步骤 9 中，评估团队召集会议，并根据一些共同的潜在关注点或系统性缺陷将风险分组为风险主题。例如，一组关于文档不足或过时的风险可能被归为一个风险主题，表明文档没有得到足够的考虑。一组关于系统在面对各种硬件和 / 或软件故障时无法运行的风险可能导致一个关于对备份能力或提供高可用性关注不足的风险主题。
对于每个风险主题，评估团队确定第2步中列出的哪些业务目标受到影响。确定风险主题，然后将它们与特定的驱动因素联系起来，通过将最终结果与初始演示联系起来，使评估圆满完成，从而为评估活动提供了令人满意的结束。同样重要的是，它将发现的风险提升到管理层的关注层面。原本在经理看来可能像是深奥的技术问题，现在明确地被确定为对经理公开表示关心的事情的威胁。
从评估中收集的信息被总结并呈现给利益相关者。呈现以下输出结果：
- 记录的架构方法。
- 头脑风暴产生的场景及其优先级。
- 效用树。
- 发现的风险和非风险。
- 发现的敏感点和权衡点。
- 风险主题以及每个主题所威胁的业务目标。
脱离脚本
多年的经验告诉我们，没有一次架构评估活动会完全按照书本进行。然而，尽管评估活动可能会以各种方式出现严重错误，可能会忽略所有的细节，可能会伤害到脆弱的自尊心，也可能会涉及到很高的风险，但我们从未有过一次架构评估活动失去控制。每一次评估都取得了成功，这是通过我们从客户那里收集到的反馈来衡量的。
虽然它们都成功了，但也有一些令人难忘的惊险时刻。
有好几次，我们开始进行架构评估，却发现开发组织没有可评估的架构。有时只有一堆类图或模糊的文本描述伪装成架构。有一次，我们得到承诺说在评估活动开始时架构就会准备好，但尽管有良好的意图，它却没有准备好。（我们并不总是在评估前的准备和资格审查方面如此谨慎。我们现在的勤勉是这些经历的结果。）但没关系。在这种情况下，评估的主要结果包括明确阐述的质量属性集、在评估过程中绘制的 “白板” 架构，以及为架构师规定的一组文档义务。在所有情况下，客户都认为详细的场景、我们能够对引出的架构进行的分析以及对需要做什么的认识，完全证明了评估活动是合理的。
有几次我们开始评估，却在评估过程中失去了架构师。有一次，架构师在评估的准备和执行之间辞职了。这个组织处于混乱之中，架构师只是在其他更平静的环境中得到了更好的机会。通常，没有架构师我们是不会继续进行的，但这次没关系，因为架构师的徒弟介入了。进行了一些额外的准备工作让他做好准备，我们就一切就绪了。评估按计划进行，徒弟为评估所做的准备极大地帮助他接替了架构师的角色。
有一次，在一次 ATAM 评估活动进行到一半时，我们发现我们准备评估的架构被抛弃了，取而代之的是一个新的架构，而没有人提及过这个新架构。在阶段 1 的步骤 6 中，架构师在回应一个场景提出的问题时不经意地提到 “新架构” 不会有那个缺陷。房间里的每个人，包括利益相关者和评估人员，都面面相觑，陷入了困惑的沉默。“什么新架构？” 我茫然地问道，然后事情就暴露了。开发组织（为美国军方承包项目的承包商，委托进行了这次评估）为系统准备了一个新架构，以应对他们知道未来会出现的更严格的要求。我们叫了暂停，与架构师和客户商议，决定继续进行评估活动，以新架构为评估对象而不是旧架构。我们退回到步骤 3（架构展示），但其他所有的东西 —— 业务目标、效用树、场景 —— 仍然完全有效。评估继续进行，在评估活动结束时，我们的军方客户对所获得的知识非常满意。
在我们经历过的也许是最奇怪的一次评估中，我们在阶段 2 进行到一半时失去了架构师。这次评估的客户是一个正在进行大规模重组的组织中的项目经理。这位经理是一个和蔼可亲、有敏锐幽默感的人，但有一种潜在的感觉是他不能被违抗。架构师在不久的将来会被重新分配到组织的另一个部门；这无异于被从这个项目中解雇，经理说他想在他的架构师尴尬离开之前确定架构的质量。（我们直到评估后才发现这些情况。）当我们设置 ATAM 评估活动时，经理建议初级设计师参加。“他们可能会学到一些东西，” 他说。我们同意了。随着评估活动的开始，我们的时间表（一开始就非常紧张）不断被打乱。经理希望我们与他公司的高管会面。然后他希望我们和一个他说能给我们更多架构见解的人一起吃一顿长时间的午餐。结果，在我们预定的会面时间，高管们很忙。所以经理问我们是否可以回来以后再和他们会面。
到现在，阶段 2 已经严重偏离了时间表，以至于让我们惊恐的是，架构师不得不离开去飞回他在遥远城市的家。他对在他不在的情况下评估他的架构非常不高兴。他说，初级设计师永远无法回答我们的问题。在他离开之前，我们的团队聚在一起商议。评估活动似乎处于灾难的边缘。我们有一个不高兴离开的架构师、一个被打乱的时间表和有问题的可用专业知识。我们决定把我们的评估团队一分为二。一半的团队将继续进行阶段 2，以初级设计师为我们的信息资源。另一半的团队将在第二天通过电话与架构师一起继续进行阶段 2。我们将以某种方式在这种糟糕的情况下尽力而为。
令人惊讶的是，项目经理似乎对这些情况的转变完全无动于衷。“我确定会没事的，” 他愉快地说，然后退回去与各位副总裁商议重组事宜。
我带领团队采访初级设计师。我们从未从架构师那里得到一个完全令人满意的架构展示。对文档中的差异，他轻松地回应说：“哦，好吧，实际情况不是那样的。” 所以我决定从 ATAM 步骤 3 重新开始。我们问这大约六个设计师他们对架构的看法是什么。“你们能画出来吗？” 我问他们。他们紧张地互相看了看，但有一个人说：“我想我能画出一部分。” 他走到白板前，画出了一个非常合理的组件和连接器视图。另一个人自愿画出一个进程视图。第三个人画出了系统一个重要离线部分的架构。其他人也加入进来帮忙。
当我们环顾房间时，每个人都在忙着抄写白板上的图片。没有一张图片与我们迄今为止在文档中看到的任何东西相对应。“这些图在任何地方有记录吗？” 我问。一个设计师从他忙碌的抄写中抬起头来笑了笑。“现在有了，” 他说。
当我们进行到步骤 8，使用先前捕获的场景分析架构时，设计师们在共同回答我们的问题方面做得非常出色。没有人知道所有的事情，但每个人都知道一些事情。在半天的时间里，他们一起呈现出了一个清晰一致的整个架构的画面，比架构师在为期两天的评估前讨论中愿意呈现的任何东西都更加连贯和易于理解。在阶段 2 结束时，设计团队发生了转变。这个以前缺乏信息、只有有限的局部知识的团队变成了一个真正的架构团队。成员们展示并认可了彼此的专业知识。这种专业知识在每个人面前 —— 最重要的是，在他们的项目经理面前 —— 被揭示和验证，项目经理悄悄回到房间观察。他脸上露出了极度满意的表情。我开始明白 —— 你猜对了 —— 没关系。
结果发现，这个项目经理知道如何以一种会让马基雅维利印象深刻的方式操纵事件和人。架构师的离开不是因为重组，只是与之巧合。项目经理精心策划了这一切。经理觉得架构师变得过于专制独裁，他想给初级设计人员一个成长和做出贡献的机会。架构师在评估过程中的离开正是项目经理所希望的。而设计团队在压力下的崛起一直是这次评估活动的主要目的。虽然我们发现了与架构有关的几个重要问题，但项目经理在我们到达之前就已经知道了每一个问题。事实上，他通过在休息时间或一天的会议后发表一些谨慎的言论，确保我们发现了其中的一些问题。
这次评估活动成功了吗？客户再满意不过了。他对架构的优势和劣势的直觉得到了证实。我们在帮助他的设计团队方面发挥了作用，这个团队将在公司重组的风暴中引导系统，在恰当的时候作为一个有效和有凝聚力的团队团结在一起。客户对我们的最终报告非常满意，他确保公司董事会看到了这份报告。
这些惊险时刻在我们的记忆中肯定非常突出。没有记录的架构。但没关系。不是正确的架构。但没关系。没有架构师。但没关系。客户真正想要的是实现团队重组。在每一个例子中，我们都尽可能合理地做出反应，每次都没关系。
为什么？为什么一次又一次地结果都还好呢？我认为有三个原因。
首先，委托进行架构评估的人真的希望它成功。应客户要求聚集在一起的架构师、开发人员和利益相关者也希望它成功。作为一个群体，他们帮助评估活动朝着获得架构洞察力的目标前进。
其次，我们总是诚实的。如果我们觉得评估活动偏离了轨道，我们会叫暂停，在我们自己之间商议，通常也会与客户商议。虽然在评估活动中一点虚张声势可能会派上用场，但我们永远不会试图在评估中蒙混过关。参与者本能地能察觉到虚假的迹象，评估团队绝不能失去其他参与者的尊重。
第三，这些方法是为了在整个评估活动中建立和保持稳定的共识而构建的。在最后没有意外。参与者为构成合适架构的要素制定基本规则，并且他们在评估的每一步都为发现的风险做出贡献。
所以：尽你最大的努力。诚实。相信这些方法。相信你聚集在一起的人的善意和良好意图。那么就会没事的。
—PCC (Adapted from [Clements 01b])
21.6 轻量级架构评估
轻量级架构评估（LAE）方法旨在项目内部环境中使用，由同行定期进行评审。它使用与 ATAM 相同的概念，并旨在定期进行。可以召开一次 LAE 会议，重点关注自上次评审以来架构或架构驱动因素的变化，或者检查架构中以前未检查过的部分。由于范围有限，许多 ATAM 的步骤可以省略或缩短。
LAE 评估的持续时间取决于生成和检查的质量属性场景的数量，而这又基于评审的范围。检查的场景数量取决于被评审系统的重要性。因此，一次 LAE 评估可以短至几个小时，也可以长达一整天。它完全由组织内部成员进行。
由于参与者都是组织内部人员，并且数量比 ATAM 少，所以让每个人发表意见并达成共同理解所需的时间要少得多。此外，因为 LAE 是一个轻量级过程，所以可以定期进行；反过来，该方法的许多步骤可以省略或只是简要提及。LAE 评估中的潜在步骤以及我们在实践中的经验如 表 21.3 所示。LAE 评估通常由项目架构师召集并领导。
表 21.3 轻量级架构评估的典型议程
| 步骤 | 笔记 |
|---|---|
| 1: 介绍方法步骤 | 假如参与者熟悉该流程，此步骤可以省略。 |
| 2：审查业务目标。 | 参与者应该理解系统及其业务目标以及它们的优先级。可以进行简要审查，以确保这些内容在每个人的脑海中都是清晰的，并且没有意外情况。 |
| 3：审查架构 | 所有参与者都应该熟悉该系统，所以会使用至少模块视图和组件与连接件视图对架构进行简要概述，突出自上次审查以来的任何变化，并通过这些视图追踪一两个场景。 |
| 4：审查架构方法 | 架构师强调针对特定质量属性关注点所使用的架构方法。这通常在步骤3的一部分中完成。 |
| 5：审查质量属性效用树 | 效用树应该已经存在；团队审查现有效用树，并在需要时使用新场景、新响应目标或新的场景优先级和风险评估对其进行更新。 |
| 6：头脑风暴并确定场景优先级 | 此时可以进行一个简短的头脑风暴活动，以确定是否有任何新场景值得分析。 |
| 7：分析架构方法 | 这一步（将高优先级的场景映射到架构上）会耗费大部分时间，并且应该聚焦于架构的最新变化，或者团队之前未分析过的架构部分。如果架构发生了变化，应该根据这些变化重新分析高优先级的场景。 |
| 8：记录结果 | 在评估结束时，团队审查现有的和新发现的风险、非风险、敏感性和权衡，并讨论是否出现了任何新的风险主题。 |
没有最终报告，但（与 ATAM 一样）有一名记录员负责记录结果，这些结果可以随后被分享，并作为风险补救的基础。
整个轻量级架构评估可以在不到一天的时间内完成 —— 也许一个下午就可以。结果将取决于参与的团队对该方法的目标、技术以及系统本身的理解程度。评估团队由于是内部的，通常比外部评估团队的客观性要低，这可能会影响其结果的价值：人们往往听到较少的新想法和不同意见。然而，这种评估版本成本低、容易召集，并且相对不那么正式，所以每当项目需要进行架构质量保证的合理性检查时，它可以快速部署。
基于策略的问卷调查
在 第 3 章 中我们讨论过的另一种（甚至更轻量级的）轻量级评估方法是基于策略的问卷调查。基于策略的问卷调查每次聚焦于一个质量属性。它可以被架构师用于辅助反思和内省，或者可以用于构建评估者（或评估团队）与架构师（或一组设计师）之间的问答环节。这种环节通常很短 —— 每个质量属性大约一小时，但可以揭示出很多关于为了控制某个质量属性而做出的以及未做出的设计决策，以及那些决策中常常隐藏的风险。我们在 第 4 章 至 第 13 章 中提供了特定质量属性的问卷调查，以帮助你在这个过程中进行指导。
基于策略的分析可以在很短的时间内产生令人惊讶的结果。例如，有一次我在分析一个管理医疗保健数据的系统。我们同意分析安全这个质量属性。在这个环节中，我尽职地按照基于安全策略的问卷调查进行，依次询问每个问题（你可能还记得，在这些问卷调查中，每个策略都被转化为一个问题）。例如，我问：“系统支持入侵检测吗？”“系统支持消息完整性验证吗？” 等等。当我问到 “系统支持数据加密吗？” 这个问题时，架构师停顿了一下，然后笑了。接着他（不好意思地）承认系统有一个要求，即任何数据都不能在网络上以明文形式（即不加密）传输。所以他们在通过网络发送所有数据之前对其进行了异或运算。
这是一个很好的例子，说明基于策略的问卷调查可以非常快速且低成本地揭示出这种风险。是的，从严格意义上说，他们满足了要求 —— 他们没有以明文形式发送任何数据。但是他们选择的加密算法一个能力一般的高中生就能破解！
—RK
21.7 小结
如果一个系统重要到需要你明确地设计其架构，那么这个架构就应该被评估。
评估的次数以及每次评估的程度可能因项目而异。设计师应该在做出重要决策的过程中进行评估。
ATAM 是一种用于评估软件架构的综合方法。它的工作方式是让项目决策者和利益相关者明确列出一份精确的质量属性需求清单（以场景的形式），并阐明与分析每个高优先级场景相关的架构决策。然后可以从风险或非风险的角度理解这些决策，以找出架构中的任何问题点。
轻量级评估可以作为项目内部同行评审活动的一部分定期进行。基于 ATAM 的轻量级架构评估提供了一种成本低、形式简单的架构评估，可以在不到一天的时间内完成。
21.8 扩展阅读
关于 ATAM 的更全面论述，请参见 [Clements 01b]。
有多个应用 ATAM 的案例研究可供参考。可以通过访问sei.cmu.edu/library并搜索 “ATAM 案例研究” 找到它们。
已经开发了几种更轻量级的架构评估方法。它们可以在 [Bouwers 10]、[Kanwal 10] 和 [Bachmann 11] 中找到。
对从 ATAM 中得出的各种见解的分析可以在 [Bass 07] 和 [Bellomo 15] 中找到。
21.9 问题讨论
1. 想一个你正在参与的软件系统。准备一个 30 分钟的关于这个系统的业务目标的演示。
2. 如果你要评估这个系统的架构，你希望谁来参与？利益相关者的角色是什么，你能找到谁来代表这些角色？
3. 计算一个基于 ATAM 的大型企业级系统架构评估的成本。假设参与者的完全负担劳动成本为每年 25 万美元。假设评估发现了一个架构风险，并且缓解这个风险可以节省项目成本的 10%，在什么情况下，这个 ATAM 对一个项目来说是一个明智的选择？
4. 研究一个可以归因于一个或多个糟糕的架构决策的代价高昂的系统故障。你认为架构评估可能会发现这些风险吗？如果是，将故障的成本与评估的成本进行比较。
5. 一个组织评估两个相互竞争的架构并不罕见。你将如何修改 ATAM 以产生有助于这种比较的定量输出？
6. 假设你被要求秘密地评估一个系统的架构。架构师不可用。你不被允许与系统的任何利益相关者讨论评估。你将如何进行？
7. 在什么情况下你会想要使用完全强度的 ATAM，在什么情况下你会想要使用轻量级架构评估（LAE）？
这是一种常见的促进头脑风暴技术。 ↩︎
