第11章 ATAM：一种进行构架评估的综合方法

 

本章将介绍构架权衡分析方法，它是评估软件构架的一种综合全面的方法。之所以称 为ATAM方法，是因为这种方法不仅可以揭示出构架满足特定质量目标的情况，而且（因 为它认识到了构架决策会影响多个质量厲性）可以使我们更清楚地认识到质量目标之间的 联系一即如何权衡诸多质量目标。

 

评估大型系统的构架是一项复杂的任务。首先，大型系统有一个很大的构架.要在有 限的时间理解这个构架是非常闲难的：其次，根据Nietzsche的观点和构架商业周期 (ABC),计算机系统旨在支持业务目标，评估霈要把这些目标和技术决策联系起来；诚最后，大型系统通常都有多个涉众，在一个有限的时间里获得这些涉众的不同观点要求仔细管理评估过程。从上面列举的这些困难中可以看出，对用于构架评估的有限的时间进行管 理是一个中心问题。

 

ATAM设汁用于获取系统以及构架的业务目标。它还设计用于使用这些目标和涉众参 与来使评估人员把注意力放到对实现这些目标重要的构架部分上。

 

本章将介绍ATAM方法的步骤，然后根据其目的对这些步骤进行讨论。本章还给出了 —个ATAM案例分析（基于该方法的-个应用），

 

11.1 ATAM的参与人员

ATAM要求以下3个小组的参与和合作:

 

(1)评估小组    该小组是所评估构架的项目外部的小组。它通常由3〜5个人组成 在评估期间.该小组的每个成员都耍扮演大量的特定角色（表11.1对这些角色以及期胡毎 个角色所具备的素质进行了描述）.，评估小组可能是一个常设小组，其中要定期执行构架 评估.其成员也可能是为了应对某次评估，从了解构架的人中挑选出来的。他们可能与开发小组（其构架是公开的）为相同的组织工作，也可能是外部的咨询人员。在任何情况下， 他们都应该是有能力、没有偏见且私下没有其他工作要做的外部人员。

 

(2)项目决策者    这些人对开发项目具有发言权，并有权要求进行某些改变。他们 通常包括项目管理人员.如果有•个承担开发费用的可以确认的客户，他（她）或其代表 也应该列入其中，设计师肯定要参与评估一一构架评估的一个基本准则是设计师必须愿意 参与评估。最后，委托进行评估的人通常有权就开发项目发言，如果他没有权利代表项目 发言的话，他（她）也必须是小组中的一个成员。

 

(3)构架涉众    涉众在构架中有-个既得利益（正如所宣称的那样）。他们完成工作 的能力与支持可修改性、安全性、高可靠性等特性的构架密切相关。涉众包括开发人员、 测试人员、集成人员、维护人员、性能工程师、用户、与正在分析的系统交互的系统的构 建人员以及其他人员。在评估期间，他们的工作职责是淸晰明确地阐述构架应该满足的具 体质量厲性目标，以使所开发的系统能够取得成功。根据经验，应该有12〜15个涉众参 与评估。

表11.1 ATAM评估小组的角色

 

11.2 ATAM的结果

ATAM评佔将产生至少如下结果

•    一个简洁的构架表述。我们通常认为构架文档是由对象模型、接口及其签名的列表或其他冗长的列表组成的。但ATAM的一个耍求就足在个小时内表述构架， 这样就得到了 一个简洁、而且通常是可理解的构架表述。

 

•    表述清楚的业务目标。开发小组的某些成贝通常玷在ATAM评估上笫一次看到表 述淸楚的业务目标。

 

•    用场景集合捕获的质量需求。业务目标导致质量需求。一些重要的质量需求是用 场景的形式捕获的。

 

•    构架决策到质量需求的映射。可以根据构架决策所支持或阻碍的质量厲性来解释 构架决策。对在ATAM期间分析的每个质量场景，确定那些有助于实现该质量场景的构架决策。

 

•    所确定的敏感点和权衡点集合。这些是对一个或多个质量属性具有显著影响的构 架决策。例如.采用一个备份数据库很明显是一个构架决策，因为它影响了可靠 性（正面），因此，它是一个关于可靠性的敏感点。然而，保持备份最新消耗了 系统资源，因此影响了系统性能（负面)。因此，它是可靠性和性能之间的权衡 点。该决策足否是有风险的取决于在构架的质量属性需求的上下文中，其性能成 本是否超出正常所需。

 

•    有风险决策和无风险决策，ATAM中有风险决策的定义是：根据所陈述的质屋属 性需求可能导致不期望有的结果的构架决策；无风险决策的定义与此类似：根据 分析被认为是安全的构架决策。所确定的风险可以形成构架风险移植计划的基础：

 

•    风险主题的集合。分析完成时,评估小组将分析所发现的风险的全部集合, 以寻找确定构架甚至构架过程和小组中的系统弱点的总的主题。如不采取相应的措 施，这些风险主题将影响项目的业务目标。

 

评估的结果用于建立一个最终书面报告。该报告概述ATAM方法，总结评估会议记录, 捕获场景及其分析，对得到的结果进行分类。

 

评估还会产生一些副结果。通常情况下会为评估准备淸楚的构架表述，可能比已经存 在的任何构架表述都耍淸晰。这个额外准备的文档经受住了评估的考验，可能会与项目一起保留下來。此外，参与人员创建的场景是业务目标和构架需求的表示，可用来指导构架 的演变。最后，可以把最终报告中的分析内容作为对制定（或未制定）某些构架决策的基 本原理的陈述。副结果是真实的、可列举的。

 

ATAM评估还有些无形的结果。这些结果包括能够使涉众产生“社群感"，可以为 设计师和涉众提供公开交流的渠道，以及使构架的所有参与人员更好地理解构架及其优势 和弱点。尽管这些结果很难度量.但其重要性不亚于其他结果，而且这些结果通常是存在 时间最长的。

 

11.3 ATAM的阶段

ATAM中的活动被分为4个阶段。

 

在第0阶段（合作关系和准备)，评估小组负责人和主要的项目决策者进行非正式会面，以确定此次评估的细节。项目代表向评估人员简要概述项目，以使评估小组可以得到 具备适当专业技术的人员的协助。两个小组就后勤问题达成一致，如会议的时间和地点， 由谁负责带活动挂图以及由谁提供饮食和咖啡。他们还应该就参与评估的涉众的初步列表 达成致（根据名字而非所扮演的角色），此还应就何时、向何人提交最终评估报告进 行协商=他们还要处理一些形式上的东西，如工作说明或保密协议。他们商定应该向评估 小组提交巳有的且可能有用的构架文档。最后，评估小组负责人解释希望管理人员和设计 :师在第1阶段提供什么信息，如果必要的话，帮助他们构造其演示。

 

第1阶段和第2阶段是评估阶段.每个人都应该开始认真考虑分析工作。现在，评估 小组已经研究了构架文档，并对系统、所采用的总体构架方法以及非常重要的质量属性有 了 -个很好的了解。在第1阶段，评估小组与项目决策者进行了会晤（通常是用1天的时 间).以开始信息收集和分析工作。在第2阶段.构架的涉众加入到评估中，分析继续进 行，一般用2天的时问。下一节将详细讲述第1阶段和第2阶段的确切步骤。

 

第3阶段是后续阶段，评估小组需要生成并交付一个最终的书面报告。然而，该阶段 的本质是评估小组的自我检査和改进。在总结会议中，小组讨论哪些活动比较理想，哪些 不尽如人意。他们对在第1阶段和第2阶段分发给参与人员的调查表进行分析.过程观察 员阐述自己的观点。小组成员在如何完成其职责上寻求改进，以使下•次评估能够更顺利 或更有效。评估小组把毎个参与评估的小组（-共有3个）在评估中所付出的工作编成目录，数月后（通常认为这个时间段比较适当），小组负责人与评估客户联系，以评定此次 评估的长期效果.这样就可以对成本和收益进行比较。

 

表11.2给出了 ATAM的4个阶段，谁参与哪个阶段以及侮个阶段所用的时间。

11.3.1    评估阶段的步骤

ATAM分析阶段（第丨阶段和第2阶段）由9步组成-第1〜6步在第1阶段执行： 在第2阶段，所有涉众都将到场，他们对己经完成的步骤进行总结，并执行第7〜9步，

 

分析步骤通常是根据确定的议程按顺序进行《但是，有时可能会由于某个人没有时间 或还没有准备好构架信息而修改时间表。每个评估都存自己的特点。有时，评估小组可能 会简要冋顾•下前面的某一步，或跳到后面的某-步，或在某些步骤间重复.这些都根据 需要来决定。

 

第1步：ATAM方法的表述„ ATAM评估的第1步要求评估负赉人向参加会议的项目 代表介绍ATAM。在这一步.要说明每个人将参与的过程.回答提出的问题，并为其他活 动确定上下文和期望。评估负责人使用•个标准的演示来简耍描述ATAM步骤和评估的结果。

 

第2步：商业动机的表述。评估的参与者——项目代表和评估小组成员——需要理解系统的上下文和促成该系统开发的主要商业动机。在这一步屮，项目决策者（最好是项目 经理或系统的客户）从商业的角度介绍系统的概况。该表述应该描述：

 

•    系统最重要的功能

 

•    任何相关的技术、管理、经济和政治限制

 

•    与该项目相关的商业目标和上下文

 

•    主耍的涉众

 

•    构架的驱动因蒺（即促使形成该构架的主要质量属性目标）

 

第3步：构架的表述。首席设计师（或构架小组） 在这一步对构架进行详略适当的介 绍。“详略适当"取决于如下几个因素：该构架的设计已经完成了多少、编写了多少文档、 还有多少时间可用以及行为和质量需求的实质。

 

在这一表述中，设计师应该谈到技术约束条件.如要求使用的操作系统、硬件或中间 件，以及该系统必须与之交互的其他系统。最重耍的是.设计师耍描述用來满足需求的构 架方法（或模式，如果设计师善亍使用该词汇的话)。

 

为了充分利用有限的时间，设计师在表述时需要有一个很高的信噪比。也就是说.他 应该传达构架的本质，不应该讲述不太重耍的方面.或过分详细地讲述某几个方面。因此. 预先将评估小组所需要的信息告知设计师是非常有帮助的。图11.1给出了 一个可以帮助设 计师准备该表述的模板。在第1阶段中还可以进行彩排，这由设计师决定。

 

从表述模板中可以看出，正如第2章所述，我们期望构架视图是设计师用來介绍构架 的主要工具。在毎一次评估中，几乎都要用到上下文图、钳件-连接器视阁、模块或分层 视阁以及部署视阁.设计师应该有这样的准备。如果其他视图也包含了与所评估构架相关的倍息，尤其是包含了与实现重要的质量属性目标相关的信息，那么，也应该给出这些视图。根据经验，设计师应该给出他（她）认为在构架创建期间最重要的视图。

 

                                            构架表述（约20张幻灯片.60分钟〉

 

促使形成该构架的需求，与这些需求相关的可度量的量以及用于滿足这些需求的任何现有的标准模型/方法(2-3张幻灯片）。

        

        重要的构架倍息（4〜8张幻灯片）

        

        •    上下文图—系统将存在的上下文。该系统将与之交互的人或其他系统。

        

        •    模块或分层视图一描述系统功能分解的模块（可以是子系统或层），以及作为其具体内容并体现其相互关系的对象、过程和函数(如过程调用、方法调用、回叫、包含)。

        

        •    组件-连接器视图—进程、线程及其同步关系、数据流及将其连接起来的事件。

        

        •    部署视阁~CPU、存储器、外设/传感器以及连接它们的网络和通倍设备：还显示了在各个处理器上执行的进程。

        

        构架方法、模式或所采用的战术，包括它们实现了什么质量属性以及这些方法如何实现这些属性的描述(3〜6张幻灯片)。

        

        •     商业产品（COTS)的使用及其选择/集成（1〜2张幻灯片）。

        

        •    对1〜3个最重要的用例场景的介绍。如果有可能的话，.包括对每个场景的运行时资源使用情况的介绍(1~3张幻灯片）。

        

        •      对1~.3个最重要的变更场景的介绍。如果有可能的话，.根据所变更的模块或接口來描述变更的影响，即預计的变更的规模/难度(I〜3张幻灯片〉

        

        •    与实现促使形成该构架的需求相关的构架问题/风险（2~3张幻灯片）„

        

        •    术语表（1张幻灯片).

 

                    图11.1构架表述的示例模板

 

在表述构架时，评估小组应根据其在第0阶段对构架文档的分析以及上一步对商业动机的了解，请求给予说明。他们还倾听并写下了他们看到已经采用的任何构架战术或模式。 

第4步：对构架方法进行分类, ATAM主要通过理解其构架方法来分析构架。正如在第5 章所看到的，构架模式对已知的方法是有帮助的，其中，每个方法都影响特定的质量属性。分层模式旨在为系统提供可移植性，但很有可能是以牺牲性能为代价的。在数椐的生产者和消费者的数量上，数据存储库模式通常是可扩充的。

 

到现在为止，评估小组己经充分了解了设计师在设计系统中所使用的模式和方法。他们应该研究构架文档，并且应该倾听设汁师在第3步演示中所做的表述。在这一步中，要求设计师对所使用的模式和方法进行明确命名，但评估小组还应该能够发现没有提及的方 法和模式。

 

在这-步中，评估小组只是对很明显的模式和方法进行了分类。该列表由书记员记录 下来，以供所有人传阅，它是随后进行分析的基础。

 

第5步：生成质量属性效用树。对于根据该构架所构建的系统来说，构架或者适合为 系统提供特定的质量属性，或者不适合。对于一个要求具有安全性的系统来说，性能极高 的构架可能是完全错误的。第2步在表述商业动机时.指定了所分析构架的重要质量厲性目标，但并没有进行任何分析。诸如“可修改性”或“高吞吐最"或“能够移植到大量机器上”这样的主要目标建立了重要的上下文和方向，并提供了 一个可以据之对随后信息进 行表述的背景。然而，这些还不足以使我们知道构架是否足以满足要求。用哪种方式进行 修改？吞吐量有多高？移植到什么机器上？

 

在这-步中.我们通过一种称为效用树的机制对质量属性目标进行了详细淸晰的阐 述。评估小组与项目决策者合作，共同确定出系统域重要的质量属性目标（表示为场景的 形式)，划分这些目标的优先级并对其进行求精。效用树的作用是使质量厲性需求具体化. 从而迫使设计师和客户代表准确地定义出他们将要提供的相关质量需求。

 

“效用”是效用树的根结点。效用是系统的总体“适宜性”的表示。质量属性构成该 树的2级结点，因为它们是效用的组件。在第2步的商业动机表述中指定的质量属性组成 了第2级的最初的集合。一般情况下，性能、可修改性、安全性、易用性和可用性是效用 的子结点，但参与评估的人可以使用自己喜欢的名称描述感兴趣的质量属性。有时不同的 涉众会使用不同的名称表达相同的概念（例如.有的涉众喜欢用“可维护性”一词)。有 时他们使用在其自己的团体中有意义但并没有被大家广泛使用的质量属性名称，如“灵活 的扩展性（llextensibiUty) ”。只要涉众能够在下一级中通过求精解释他们所使用的名称 的含义，使用任何名称都是可以的（参见引文“名称的含义是什么”)。

 

                                                名称的含义是什么

本书的构架评估方法使用场景来捕获质量属性，因为质量属性本身太糢糊，很难进行 分析.然而，ATAM的效用树中又使用质量属性名称，这是否矛盾？实际上这并不矛盾-因为我们并不关心涉众选择什么质量属性。只要激发了他们的思维，他们就可以选择自己 喜欢的任何质量属性名称。例如，在本章后面的表11.5给出的效用树中.您可能会说“可 配置性”和“模块性”是“可修改性”的特殊情况，因此应作为对可修改性的求精出现. 我同意这一说法.但是，在那次评估中，涉众认为它们有很大差别，应该分别在效用树中 表示出来，因此效用树中就包括了这些属性。真正重要的是叶结点上的场景，而非分支的结构.

 

在一次又一次的评估中’我们几乎从来没有看到过相同的质量属性名称，一家组织使 用“可维护性”，而另一家组织则用“可改变性”表达相同的含义.有时，“可移植性”就 是一种可修改性，但很多次涉众都采用自己的习惯用词。可靠性和可用性经常互换使用 我们也看到有一些在小范围内使用的质量属性名称，它们在进行评估的组织.内是为大家所 熟知的，如“可部署性”和“可销售性”我们并不知道这些词的准确意思，但ATAM的 一个很不错的特性就是，不需要花费宝责的时间来争论词语的定义问題.场景提供了可操 作的含义，重要的是这些术语对使用它们的涉众具有某些含义，他们能够使用这些术语回 想起阐述了这些术语的含义的场景。

 

在某次ATAM评估中，开发组织希望有才能的人员能够到位于美国中西部的一个宁静 的小城市工作，该商业动机实际上导致了一个构架关注——构架要采用足以让人产生兴趣 的一流的软件技术，以吸引有才能的人到这儿来工作.

 

在IEEE、 ISO或ANSI标准质量属性名称的任何列表中.您都不会发现“lowa-bility”， 但我们可以在ATAM效用树中发现它，在那里,它充当的只是一个刺激对场景进行思考， 以表达所关心问题的手段.

 

 

在每个质量属性下都对该质量属性进行了进•步的求精。例如，“性能”被分解成“数 据延迟”和“交易吞吐量”，这就向着将质量属性目标求精为足够具体、能划分优先级并 进行分析的质量属性场景迈出了重要的一步。“数据延迟"又被进一步分解为“把客户数据库的存储延迟减到最小值20毫秒”和“提供20帧/秒的实时视频阁像”，因为这两种数 据延迟都与该系统相关。

 

场景（已在第4章描述）是使所期望质量厲性的主要（模糊的）陈述变得具体和可测试的机制。它们組成了效用树的叶子，根据它们所表示的质量厲性进行分组。场景由6部分组成（已在笫4章给出），我们对这6部分进行了简化，以支持评佔的进行„ ATAM场 景由3部分组成：刺激（什么条件到达了系统、谁生成了它以及它刺激了什么系统制品）、 环境（描述刺激发生时的情况）和响应（系统对以一种可度量的方式表示的刺激所做出的 反应）。

 

现在我们就可以根据一些具体的内容对构架进行评估。实际上，ATAM的分析步骤包 括选择一个场景，然后看看构架对该场景的响应或实现情况。下-步将对此进行更详细的 说明。    .

 

一些场景可能会表达多个质量属性，因此可能会出现在效用树屮的多个地方。这不一定会成为问题，但评估负责人应该防止一个场景涉及过多的质量厲性，因为这样会很难进行分析。试着对此类场景进行划分，使每个场景关注的内容减少。

 

评估小组不仅霈要理解构架要实现的准确目标，而且还需要理解其相对重要性。效用 树的叶结点上很可能会包含50个场景，但因为时间有限，不可能在评估会议上对所有这些场景进行分析。因此，效用树生成还包括一个划分优先级的步骤。在获得一致同意后， 项目决策者为每个场景分配一个优先级。所设置的优先级可能是从0到10的数字，也可 能会使用高、中、低的形式（我们更喜欢用高/中/低的形式，因为它既能满足我们的需求， 与分配具体数字相比所用的时间又少)。

 

然后，使用不同的标准再次划分场景的优先级。设计师需要根据构架满足每个场景的 难度来确定场景的优先级。这时，还是要选用简单的高/中/低方法。

 

现在，毎个场景都有-个相关的顺序对：（H,H) (H,M) (H，L)，等等。我们要把宝 贵的分析时间用在最重要且最难实现的场景上，并把其余场景记录下來。不太可能对标记 为不重要（L，*)或很容易实现（*,L)的场景进行认真分析。

 

构建效用树的结果是得到了一组划分了优先级的场景，这组场景引导着我们展开随后的其他ATAM评估步骤。它告诉ATAM小组应该把（相对有限的）时间用在什么地方， 特别是应该在什么地方探查构架方法和风险。效用树使评估人员更容易关注满足叶结点上 高优先级场景的构架方法。

 

此时，进行分析需要的所有信息都已放在了表中：从第2步的商业动机表述中得到的 期望构架提供的重要质量属性以及第5步的效用树：在第3步的构架表述中捕获的构架以 及第4步中对所使用方法的分类。表11.5以表格形式给出了效用树的示例（省略了根效用 结点)。

 

第6步：分析构架方法。在这里，评估小组每次分析一个最高优先级的场景：耍求设 计师解释构架如何支持毎个场景。小组成员（尤其是提问者）探査设计师用来实现场景的 构架方法。在分析构架方法的过程中，评估小组把相关构架决策编成文构’确定其有风险 决策、无风险决策、敏感点、权衡点，并对其进行分类。对于众所周知的方法’评估小组 询问设计师如何克服了该方法中已知的弱点或设计师如何确保该方法能够满足要求。评估 小组的目标是，确信该方法的实例化适合满足所要达到的质量属性需求。

 

例如，同时数据库客户机的数量将影响数据库每秒钟所能处理的交易的数量。因此，对于用每秒钟的交易数度量的响应来说，给服务器分配客户机就是一个敏感点。一些分配 方法将导致不可接受的响应值——这些就是有风险决策。当我们发现构架决策是多个质量属性的敏感点时，就将其指定为权衡点。

 

遍历场景将引发对潜在的风险决策、无风险决策、敏感点或权衡点的分析。反过来， 这些内容又可能会引发更深入的讨论，这取决于设计师的回答。例如，如果设计师不能刻画出客户机的数量，不能说明如何通过为硬件分配进程来实现负载平衡，则进行复杂的棑 队或速率单调性能分析是没有什么意义的。如果能够冋答此类问题，则评估小组至少能够进行一个初步的、大致的分析，以确定这些构架决策是否有问题或是否与所要满足的质量 属性需求相适应。不要求进行详细全面的分析，关键是要得到关于构架的足够多的信息， 以在已经做出的构架决策和所要满足的质量属性需求之间建立起联系。

 

图11.2给出了捕获-个场景的构架方法分析的表格。如图所示，根据这一步的结果， 评估小组可以确认并记录一组敏感点和权衡点、有风险决策和无风险决策。所有的敏感点 和权衡点都有可能成为有风险决策。在ATAM分析结束时，要按照是有风险决策还是无风 险决策.对每个敏感点和权衡点进行分类。要分别将敏感点、权衡点、有风险决策和无风 险决策列成一个单独的表，图11.2中的R8，T3, S4, N12等代表的就是这些表中的条目。

                            图11.2构架方法分析示例来源：改编自[Clements 02a1

 

在这-步结束时.评估小组将会对整个构架的绝大多数重要方面，所做出的关键决策 的基本原理，以及有风险决策、无风险决策、敏感点和权衡点的列表有一个淸楚的认识。

 

 

第1阶段已经结束.第2阶段即将开始。这时.第1阶段已经结朿-评佔小组对所获

得的知识进行总结，并在1或2周的中断时间内与设计师进行非正式会晤（通常以电话的 形式进行〉。可以在这段时间内分析更多的场景（如果希望的话），也可以解决已澄淸的 问题。

 

当项目的决策者准备继续开始评估并且将涉众召集在一起时，第2阶段就开始了。涉 众将参与本阶段的评估。首先重复第1步，以使涉众能够理解该ATAM方法和他们要扮演的角色。 然后，评佔负责人概述第2〜6步的结果，并给涉众提供•份有风险决策、无风险决策、 敏感点和权衡点的当前列表.，现在.涉众已经熟悉了到目前为止所进行的评估的结果，可 以进行下面的3步了。

 

第7步:集体讨论并确定场景的优先级。生成效用树主要是为了了解构架设汁师是如

何看待和处理质量属性构架驱动因素的。对场景进行集体讨论则是为了了解多数涉众的看 法。当参与评估的人员较多时，对场景进行集体讨论的做法很有效，可以创造出•个人的 想法激发其他人的灵感的氛围。这-讨论过程能促进相互交流、发挥创造性，并起到表达参评人员的共同意愿的作用。这时，我们需要把通过集体讨论确定了优先级的一组场景与效用树中的那组场景进行比较。如果相同，则表明设计师所想的与涉众实际所耍的非常吻 合：如果乂发现了其他驱动场景，则可能就是一个风险，它表明涉众和设计师之间的目标 还存在不一致..

 

在这-步屮，if佔小组请求涉众对场景进行集体讨论。不同的场景对处于不同角色的涉众具有怠义-例如，维护人员很可能会建议一个可修改性场景，而用户可能会提出一个表示了有用的功能或易操作性的场景。

 

我们鼓励涉众考虑效用树中尚未分析过的场景，把这些场景作为集体讨论的对象显然是合情合理的。这能够使涉众再次考察他们可能认为在第5步和第6步中没有引起足够重 视的场景。

 

确定场景后，必须划分其优先级，出于同样的原因，需要对效用树中的场景划分优 先级：评估小组需要知道把有限的评估时间用在什么地方。首先，耍让涉众将他们认为代 表相同行为或相同质量厲性的场景合并起来。然后，让他们通过投票表决确定哪些场景是最重要的。在分配选票时，每个涉众都会拿到相当于总场景数的30%的选票，并且此数值只入不舍。因此，如果共有20个场景，则每个涉众将取到6张选票。在投票时，涉众 可以随便使用这些选票：可以把这6张选票都投给1个场景，也可以给1个场景投1张选 栗，或者是介于以上两者之间的其他方式。

 

毎个涉众都耍公幵投票。实践经验告诉我们，这样做更富有趣味性，也有利于促进参 评人员之间的团结。淸点选票后，评估负责人按照得票数对场景进行排序，并找出选票数相差悬殊之处。选择“在某得票数之上”的场景，供后续步骤使用。例如，评估小组可能 只考虑得票数最多的前5个场景。

 

第8步：分析构架方法。在已收集了若干场景并确定了其优先级之后，评估小组引导 设计师实现在第7步屮得到的优先级最高的场景。设计师对相关的构架决策如何有助于实 现每个场景进行解释。理想情况下，这一活动主要是由设汁师用已经讨论过的构架方法对 这些场景做出解释。

 

在这一步中，评估小组要做与第6步相同的工作，即把新得到的最高优先级的场景与 尚未得到的构架制品对应起来。

 

第9步：结果的表述„最后，需要把在ATAM分析中得到的各种信息进行归纳总结， 并呈现给涉众。这种表述一般是采用辅以幻灯片的口头形式，但也可以在ATAM评估结束 之后递交更完整的书面报告。在这-表述中，评估负责人概要介绍ATAM评估的各个步骤 和在各步骤中得到的各种信息，包括商业环境、促成该构架的主要需求、约朿条件和构架 等。然后表述如下的ATAM结果：

 

•    已编写了文档的构架方法

 

•    经过讨论得到的场景集合及其优先级

 

•    效用树

 

•    所发现的有风险决策

 

•    已编成文档的无风险决策

 

•    所发现的敏感点和权衡点

 

我们在评估过程中得到了这些结果，并对其进行了讨论和分类。然而，在第9步中， 评估小组还根裾一些常见的基本问题或系统缺陷（即当前构架存在的问题）将风险分纽为风险主题，从而增添了价 值。例如，可以将文档编写不充分或文档陈旧的若干个风险归为一个风险主题，即没有足 够重视文档编写。可以将关于系统不能在采用多种硬件时正常运行和/或软件故障归结为一 个风险主题，即未提供备份能力或未提供高可用性。

 

对于每一个风险主题，评估小组都要确定将会影响第2步中所列商业因素中的哪几个。 确定风险主题并将它们与具体驱动因素联系起来有两方面的作用。筲先，这种做法通过将 最终结果与最初描述联系起來而使评估过程完满结束。其次，这种方法使所发现的风险得 以提升，从而使其引起管理层的注意。有些问题原来在经理看来可能属于技术层次上的， 现在被明确为是对经理所关心的某个问题的威胁。

 

表11.3对ATAM方法的9个步骤进行了总结,并给出了每个步骤能够为最终的ATAM 结果提供信息的愔况。“**"表示该步骤是此结果的主要来源，"*”衣示该步骤是此结果 的次要来源。

a；商业动机中包括刚开始时对质fflJM性的粗略概述。

 

b：商业动机的表述可能会揭露出一个应捕获的已发现或长期存在的风险。

 

c:设汁师在自己的表述中可能会发现某个风险。

 

d,设计师在自己的表述中可能会发现某个敏感点或权衡点

 

e：许多构架方法都有与之相关的祢准风险。

 

r： 许多构架方法都有与之相关的标准敏感点或权衡点

 

g：分析步骤可能会得出在第（4)步中未发现的一个成多个构架方法，这可能会产生新的针对构架方法的问题。

 

来源：改编自[Cleincnts 02a]

 

 

他们的解决方案无效

ATAM分析方法的步骤可能暗示着涉众的作用只是帮助构思构架目标的表述，然后帮 助清楚地阐明场景“然而，他们在多个场合出席构架的表述和评估都是至关重要的.当构 架（或其表述者）掩盖了某个重要的问题时，只有涉众具备进行澄•清所需要的深入知识. 例如，在评估一个财务管理系统时，ATAM的参与者并不是财务管理系统应用领域的专家. 因此，在评估过程中就出现了如下对话：

 

此处要说明的是，需要专业的涉众来发现非专业人员可能发现不了的问题.

 

11.3.2有效利用有限的评估时间

 

在介绍中，我们把时间有限作为进行构架评估时的•个主要问题,，现在，我们可以看 —下ATAM如何解决该问题。业务目标被作为收集表示效用树场景的动机。对其他场景划 分优先级，基本上是对效用树的自顶向下的场景生成进行由底向上的检查。仅分析优先级高的和较难实现的场景。在ATAM方法的步骤的引导下，评估人员找到了构架的重要但是存在问题的方面。这些就是将会产生最重要结果的方面。