我们还选择了具有集成COTS产品经验的人，因为客户告诉 我们Nightingale采用了几个商业软件包。令人欣喜的是，我们的‘个提问者还具有在卫生 保健业工作的经验.
我们举行了 一个为时1天的开工会议，由评估小组、项目经理、首席设计师和 Nightingale的第1位客户的项目经理参加。项目经理、首席设计师和Nightingale的第1位 客户的项目经理是Nightingale的决策制定者。在会议上，我们听到了介关Nightingale的 隹力和需求的更多愤息，收到了 一个可用的构架文档的目录（我们从中选杼那些希望进行分析的文档)，并编写了 一个参加第2阶段评估的涉众列表。我们对第1阶段和第2阶段 :的会议安排以及提交最终报告的时间达成了一致。最后，我们仔细检杳了要求项目经理和 设计师分别在第1阶段的第2步和第3步所做的表述，以确保他们淸楚我们希望看到的是什么信息。
最后，在第1阶段幵始前，评估小组进行了 2个小时的会晤。小组负责人再次审查角色分配，以确保每个人都知道自己的职责是什么。此外，我们大致看了 一下已经收到的构架文档，对它说明的模式和战术做了注解。这种开工会议有助于评估小组在某种程度上了 解构架（因而提萵了毎个人的自信)，而且它为对模式和方法进行分类的第4步打下了基础。
在Nightingale评估中，评估小组指出文档是不完整、不淸楚的。该文档还没有章节内容，它基本上是一个定义不充分的框线图集合。我们感觉如果在这时开始第1阶段评估的话，那么从概念上说此时的基础就不牢固。因此我们给设计师打了电话，请他口头补充了 构架文档中的一些空白。在那时，尽管我们知道在知识上仍然有欠缺，但至少可以放心地 始评佔了。我们做了一个注解，说明不完整的文档是需要进行分类的风险„
H.4.2第1阶段：评估
正如在第1阶段中所耍求的，评估小组与项目的决策者进行了会谈。除己经参加了开 会议的人外（项3经理、首席设计师和Nightingale的第一位客户的项目经理），还有两位首席设计人员参与了此次会议。
第1步：ATAM方法的表述。评估负责人使用对ATAM方法进行了说明的标准视图软件包进行农述。长达1小时的表述列出了该方法的步骤和阶段，描述了 ATAM的概念基础（如场景、构架方法、敏感点等)，并列出了评估结束后将产生的结果。
决策者基本上，已经熟悉ATAM,在第0阶段的讨论中己听到过对该方法的描述，因此这步进展很顺利.没有任何问题。
第2步：商业动机的表述。评估时，客户组织的项目经理从开发组织以及将购买该系统姐织的角度。表述Nightingale系统的商业目标。对于幵发组织来说，Nightingale解决如下业务需求：
• 支持其第1位客户的不同用途（如治疗跟踪、支付历史和趋势发现等)。
• 创建个面向多位客户的新的系统版本（如管理医生的办公室），以使开发组织 能够把该产品卖给其他客户。
第2个商业动机提醒我们，该构架是面向整个软件产品线（参见第14章）而非-个 系统的.
对第I位客户来说，Nightingale将代替多个现有的早期系统，它们是：
• 老系统（己有25年以上的历史）
• 基于过时的语言和技术（如COBOL和IBM汇编语言）
• 很难维护
• 无法对卫生保健站点当前的和预计的业务需要做出迅捷的响应
第1位客户的业务需求包括：
• 处理不同的文化和地域差异的能力
• 处理多种语言（尤其是英语和西班牙语）和货币（尤其逛美元和墨西哥比索）的 能力
• 至少要和所更换的任何早期系统一样快的一个新系统
• 一个绀合了不同的早期财务管理系统的单一系统
该系统的业务限制包括：
• 承诺通过对现有员工进行再培训，使其不失去工作
• 采用一个“购买而非构建”的软件方法
• 识别客户的市场已经缩小（也就是竞争对手的数盪〉
该系统的技术限制包括：
• 在任何可能的时候都使用商业软件组件
• 用两年的时间来实现该系统，每26周更换一次物理硬件
如下的质量属性被确认为高优先级的质量属性：
• 性能.。卫生保健系统要求快速的响应时间。早期系统5秒的响应时间太慢， 这是早期系统对在线査询和生成报表的响应时间。系统吞吐麗也是一个性能关 注点。
• 易用性。这是决定系统用户量的一个很关键的因素，因此这也是一个東要的客户 问题。新系统必须易于学习和使用。
• 可维护性。系统必须可维护、 可配置、可扩展，以支持新的市场（如管理医生的 办公室）、新的客户需求、州的法令变更以及不同的地区和文化的滞要。
经理将下列质量属性确定为重要、但优先级较低的属性：
•安全性。系统必须提供财务系统所要求的正常的商业级安全性（如机密性和数据完整性)。
•可用性。在正常的工作时间内，系统必须具有极高的可用性„
•可扩充性。系统必须具有足够的可扩充性，以满足规模很大的医疗机构的需要， 以及无需经过预约的小型诊所的需要。
•模块性。开发组织正在考虑不仅要销售Nightingale的新版本，而且要销售它的隼个组件。提供该能力耍求与可维护性和可扩充性紧密相关的质量属性。
•可测试性和可支持性。因为员工培训和保持是个问题，因此对于客户的技术人员 来说，系统必须是可以理解的。
步骤3。构架的表述，在评估小组与设计师进行交流期间，在评估幵始前和评估进行 中，潘要有儿个构架视阁和构架方法。如下几点内容非常关键：
• Nightingale由两个主耍子系统组成：在线事务管理器（OnLine Transaction Manager. OLTM)和决策支持与报表生成管埋器（Decision Support and Report Generation Manager. DSRGM)。OLTM满足了交互性能滞求.而DSRGM更像是-个批处理系统，其任务定期启动。
• 要将Nightingale构建为具有极高的可配置性。
• OLTM 子系统耍进行分层。
• Nightingale 是一个基于存储库的系统，该系统的中心有一个大型的商业数据库„
• Nightingale采用了很多COTS软件，包括中心数据库、规则引擎、工作流引笮、 CORBA、Web 引擎、软件分配工具等。
• Nightingale是高度面向对象的，它依赖对象框架來实现其大多数可配覽性。
图11.3给出了在设计师所使用的非正式的表示法中，所表示的OLTM的分层视图„ 图11.4通过给出部署在各种硬件处理器上的系统各部分之间的主耍通信和数据流路径，描 述了 OLTM如何在运行时工作。提供这些图主要是为了使您更好地了解ATAM评佔的实 际情况。请注意，这两个图并没有完全进行映射，也就是说，在图11.3中有事务管理器和 CORBA，但它们并没有出现在图11.4中。在我们所进行的很多ATAM评估中.这种省略 是具有代表性的,在第3步中出现的-个活动就是评估人员询问有关图中的不一致的问题， 以进一步理解构架。图11.5给出了一个类似的OLTM运行时视围。其中，可以在整个系统中跟踪事务，这又带来了类似的不一致性，在这种情况下，没有描述箭头的含义。我们 确定这些箭头也表示数据流。
.png)
.png)
.png)
Nightingale的所有这些视阁都同样合理，它们传达了重要的信息„每个视阁都展示了 与不同的关注点相关的一个方面，所有这些视图都用来执行ATAM评估的分析步骤„
第4步：对构架方法进行分类。进行了构架表述后，评佔小组列出他们曾听到的构架 方法，以及那些在对文档进行评估前的评审中所了解到的方法。主要方法包括：
• 分层，尤其是在OLTM中
• 面向对象
• 无需重新编码或重新编译，使用配置文件实现可修改性
• 客户机-服务器亊务处理
• 以数据为中心的构架模式，其中心有一个大型商业数据库
这些和其他方法为评估小组提供了-个概念上的立足点，当场景分析开始时，他们可
以据此询问探查性的问题。
第5步：生成质量属性效用树。表11.5给出了在对Nightingale评佔期间生成的质量
属性效用树。请注意，在第2歩确定的所有质量属性都出现了，而且每-个质量属性都求 精为一个或多个具体的含义。
有几个质量厲性求精没有与它们相关的场景。这种情况经常出现，这并不是问题。对 于某个质量属性，人们有时能够想出个合理的求精，但当让他们在自己系统的上下文中对该质麗属性用具体例证进行说明时.却发现该求精实际上并不适用。
为了捕获效用树以使所有人都能看到，进展书记员对每个质量属性用一页活动挂图进 行了描述，并把它贴在了墙上。然后，随着该质量属性被进一步求精和用场景进行说明， 也就捕获了活动挂图上的信息。
表11.5对Nightingale进行ATAM评估的效用树表格
.png)
.png)
表11.5中的场景给出了决策者所分配的优先级。在每-对有序的字母中，第一个代表 能力的重要性，第二个代表设计师对实现该质量属性的困难的估计„
请注意，一些场景已经很完备，具备了刺激、环境和响应3部分：一些场景没有刺激： 还有一些场景没有响应。在这个阶段，只要涉众能够理解场景的含义，不明确的场景说明 是允许的。如果所选择的场景用于进行分析，那么，该场景中的刺激和响应必须明确。
第6步：分析构架方法„我们从表11.5中可以看出，并没存产生标记为（H，H)的场 景，即应首先对其进行分析的最重要和最难实现的场景。因此，我们寻找标记为（H,M) 的场景，在模块性下面有一组标记为（H，M)的场景，该属性假定在系统中更换各种COTS 产品。尽管广泛使用COTS产品是降低开发风险的-个有意义的策略，但它也会使项目的 管理人员不安，因为他们会觉得该系统（以及购买该系统的客户）受许多COTS厂商的支配，因此，实现换出了 COTS产品的构架灵活性也是他们的关注所在。
我们与设计师一起对每个场景进行了分析，分析每个场景所用的时间平均为半个小 时。由于这些是关于变更的场景，因此我们询问了这些变更的范围和影响。我们了解到 了如下信息：
• 用另外-家厂商提供的数据库更换商业数据库是很困难的。整个Nightingale中都 使用了特定于当前数据库厂商的SQL专业用语（ANSI标准SQL的一个超集)， 正如几个特定于厂商的工具和组件-样。设计师认为更换数据库几乎是不可能 的，因此也就不再关心转移到另一个系统是很昂贵的。然而.这对项目经理来说 可是一个新信息，他不相信该场景不可能实现。我们记录下了第一个基于分析的构架风险：“因为Nightingale使用特定于厂商的工具、组件.以及其他厂商提供的 数据库不支持或与之不兼容的SQL专业用语，因此.更换数据库将非常困难且 代价昂资，这要求投入几个人年的工作。将构架与数据庳结合起来的构架决策也 被记录为一个敏感点，它会对可修改性产生负面影响。
• 更换操作系统将是一个非常合理的、简单的变化。在服务器端.操作系统被层隔 离开，这使得必须做的改变局限在一小部分丄。然而.OLTM直接依赖于NT认 证机制，更换操作系统必须提供类似的功能.以使所做的改变简单直接。在 DSRGM方，所有的操作系统依赖都己在源代码中消除：DSRGM是在Windows NT平台上开发、但在UNIX上部署的，这提供了非常冇说服力的证据，即它已 经独立于操作系统。这里我们记录下了第一个无风险决策：“因为操作系统依赖 已经被局部化或从OLTM和DSRGM中消除，因此，用另一个操作系统来更换操 作系统只需要进行-小部分修改。”封装操作系统依赖被记录为一个敏感点，这 对可修改性产生了正面影响。
• 改变规则引擎引发了几个问题。该场景并不是不可能的，因为我们了解到有几个 与使用规则引擎相关的相关性能和可维护性问题。最有可能的场景是删除（而非 更换）规则引擎，然后直接用C++实现规则。由于规则之间的前向链已经被禁止(专门比较明智地保持该选项的开放〉，因此，规则是高效地程序性的，且可以 进行编译。这样一个改变将会产生几个重要的结果：
• 它很可能会改进性能（尽管这个问题还没有得到权威的回笞).，
• 它会消除对人员进行规则语言培训的需耍.并消除了了解规则引擎的需耍。
• 它使幵发小组丧失了有用的规则开发和模拟环境。
• 它可能会导致规则“隐藏”在其余的C++代码中，从而使得它们更容易缠绕在并不与规则严格相关的功能代码中，因此更难识别和维护„
• 它消除了规则引用实际上并不存在的某个对象的可能性，这是一种当前存在 的可能性，它代表了一种难以想像地通过了过去的测试，并进入了生产系统 的错误。用C++编写规则将会在编译时消除该错误。
为了促进该变化.需要编写C++代码生成器规则，这是一项涉及范围广，而且困难未 知的开发工作。对于该场景，我们把删除规则引擎所需要的主要工作记录为一个风险。我 们还把使用规则引擎记录为构架中的一个权衡点。这使得开发和改变规则库的工作变得更 容易.然而，获得这些优势是以性能降低为代价的.尤其是需要培训开发人员，且测试变 得更加困难。
还宵很多内容，在此就不一一详述了。我们继续该场景，检查商业Web托管引擎，商 业计账软件包、工作流引擎和在Sun平台上运行的Solaris操作系统的更换问题。
这时，第I阶段的会议已经结束。我们记录了 6个敏感点、1个权衡点、4个有风险 决策和5个无风险决策。
11.4.3第2阶段：评估（继续）
在屮断了2个星期后，笫2阶段会议开始。在中断期间，评估小组洋细描述了到目前为止可以完成的最终报告的那一部分：商业动机、所表述的构架、方法列表、效用树以及 第1阶段的分析。我们还通过电话与设计师进行了交流，以检查我们对某些技术问题的理解：我们还通过电话与项目经玴进行了交流，以确保能有一个出色的涉众代表参加第2阶 段的会议。
在第2阶段，除了参加第1阶段会议的项目决策者外，还有9位涉众参加了会议。他 们包括开发人员、维护人员、第-个客户的代表和两个最终用户，
第2阶段首先进行的活动是为新的参与人员重复第I步（描述ATAM)，然后概述第1 阶段的结果，以使每个人都熟悉评估。完成这些工作后，进行第7〜9步的活动。
第7步：集体讨论并确定场景的优先级。在这一步中，涉众总共提出72个场景。 在这些场景中，有十几个场景在第5步的效用树的叶子上，但在第1阶段并没有进行分析。 这样做不仅正确而且值得鼓励。涉众以这种方式表达了他们的观点：有•些场景耍比第1 阶段的场景值得投入更多的精力。
表11.6给出了涉众在笫7步中提出的部分更感兴趣的场景。请注意，其中的一些场景结构并不是很好，而且有一些场最的含义非常模糊。这反映了集体讨论的-个本质，即每 个人都是积极参与其中的。在集体讨论时，我们并非是一提出某个场景，就花上几分钟的 时间来对其进行绀织并仔细斟酌用词，而是集中精力捕获人们头脑中的新想法。如果在投 票前或对场景进行分析前就需要推敲某个场景的含义.那么，我们很高兴花时间这样做（在提出这个场景的人的帮助下)
表11.6集体讨论确定的场聚
.png)
在把儿个类似场景合并后.涉众进行了投票，我们给毎个涉众发放了 22张选票（72
个场景的30%,向上取整到与结果最接近的偶数)，涉众分两轮进行投票。我们清点选票， 并用半个小时的时间与小组一起将大约十几个优先级最高的场景放在第5步创建的效用树 中。在此次评估中，我们可以把所有高优先级的场景作为现有分支的新叶子直接放在效用 树中。这说明设计师与涉众在认为哪些质量属性重要方面的看法是一致的。
在对新的场拔与效用树进行后，我们开始分析得票最多的场景。
第8步：分析构架方法。在第8步中，我们分析了 7个额外的场锻，这个数最比ATAM 评估的平均值稍微多点•考虑到空间限制，场景15的引文只对其中的一个场景的分析 进行了总结。
第9步：结果的表述。第9步是到两小时的表述，它总结了此次评估的结果。这一步开始时先提供了 一组包含方法概述的样本幻灯片，然后提供了一些可以在其中添上商业 动机总结、构架总结、方法列表、效用树、场景分析以及分析结果列表的空白的模板幻灯片。
评估小组在第2阶段的后期碰头，把到目前为止收集到的所有结果编辑在-起„在第 9步开始前，当评估小组可以召开会议并完成软件包时，第2阶段的日程安排中还有一大段时间。
除了有风险决策、无风险决策、敏感点和权衡点外，评估小组还表述了一些风险主题， 从系统的角度看，这些风险主题看起来可以解释构架中存在问题的方而。这可能是参评人 员唯一没有看到的内容。对于每个风险主题，我们还明确地陈述了为什么它是重要的， 这对客户是很由怠义的：我们识別了每个风险主题将耍危及的所陈述的商业动机。
对于Nightingale,我们确定了 3个风险主题：
(1)过分依赖于特定的COTS产品，过分依赖于COTS产品会在如下方面产生困难:
更换数据痄，删除规则引擎，依赖数据库可移植性层的-个老的、可能己不再支持的版本。 该风险主题对一个可维护系统的商业动机造成了威胁。
(2)没有完全定义错误恢复过程，客户关于可用工具的知识不全面。有几个场景负责发现数据库中的错误，并阻止这些错误发生。尽管该构架为那些过程提供了充分足够的 支持，但很明显，设汁师和设计人员是第一次考虑其中的一些过程。第-位客户的代表说 他们并没有适当的过程（或者是它们自己的，或者是从开发绀织那里得到的）用來纠正此 类错误。该风险主题威胁到了易用性以及支持客户组织的商业动机。
(3)文档问题,，Nightingale项目的文档陈述不够充分。早在第1阶段的会议中，该 小组就认识到了这一问题。在第2阶段分析的儿个场景又进行了强调。尽管有大量评细的 文档（如那些通过UML和Rose模型生成的文档），但该构架几乎没有介绍性的或概述性 的文裆，而这对于培训、向项目中增加人员、维护以及指导开发和测试至关重要。管理 Nightingale的行为的扩展的规则库还没有编成文档，这与数据转换和移植过程相同。如果 没有此类文档，第•位客户就无法维护该系统，这位客户就耍使用该系统了.因此对 Nightingale来说就危及到了 一个关键的商业动机——支持客户的组织。
第3阶段：后续工作
ATAM评估的-个具体结果就是生成了最终报告，该报告包括一有风险决策、无风 险决策、敏感点和权衡点的列表。它还包括一个涉及如下内容的目录：所使用的构架方法、 效用树、经过集体讨论确定的场景以及所选择的每个场景的分析记录。最后，最终报告还 包括由该评估小组所确定的风险主题的集合，并指出了每个风险主题所危及的商业动机• 像结果的表述一样，我们使用一个样板文件模板，其中有许多已完成的标准部分（如 ATAM描述)：以及有待填充内容的其他部分。在第1阶段和第2阶段之间的中断时间， 我们还编写了部分嚴终报告，如效用树和第6步的分祈。准备工作得到了回报：过去需要 花大约两周的时间为ATAM客户生成最终报告，现在大约用两天就可以产也-个高质量 的、全面的报告。
11.5小 结
ATAM是评估软件构架的一个健壮的方法。在该方法中.项日决策者和涉众要清晰阐述一个准确的质量厲性需求列表（以场景的方式〉，并说明与实现每个高优先级场景相 关的构架决策。然后，把这些决策确定为有风险决策或无风险决策，以找到构架屮任何存在问题的地方。
除了理解什么是ATAM外，理解什么不是ATAM也很重要.
• ATAM不是需求评估。也就是说，基于ATAM的评估不会说明是否系统的所有需 求都得到了满足*它只会告诉您在给定的当前设计下，是否满足了总的需求。
• ATAM不是代码评估。因为它是在生命期的早期进行的，因此它没有假定代码已 经存在，也不进行代码审査。
• ATAM不包括实际的系统测试。同样是因为ATAM是在生命期的早期进行的，因 此它没有假定系统已经存在，也不进行任何类型的实际测试。
• ATAM不是•个准确的手段，但它识别了构架中可能存在风险的区域。这些风险 包含在敏感点和权衡中。ATAM依赖于设计师的知识，因此，无法检测出某些风 险是可能的。此外，被检测出来的风险没有被量化。也就是说，我们不会试图说 明如果不纠正的话，某个敏感点将会造成多大的损失。在第12章讨论成本收益 分析方法（CBAM)时，我们将解决这一问题。
我们已经参与了大量使用ATAM进行的评估，向进行评估的人传授知识，观察进行评 估的人的行为。几乎在每次评估中，所评估构架的技术人员都对在如此短的时间内发现这 丨么多的风险感到惊奇。管理人员做出的反映是，现在他们知道了为什么某个技术问题会威 胁到商业目标的实现。ATAM已证明自己是一个有用的评估工具。
11.6可进一步参阅的文献
[在本书即将出版之际，对ATAM培训课程的初稿进行了检验。如欲获知详情，请访问 SEI的构架权衡分析网站：
http://www.sei.cmit.edu/ata-init.html。如欲获知关于ATAM的更 幽B的内容.包括将ATAM应用到NASA卫星数据系统中的案例分析,请参见[Clements 02aJ。
[Chung 00]论述了质量属性需求和它们与设计决策的关系。它参考了 [Boehm 76], [Boehm 76]中给出了 一棵与ATAM中使用的效用树非常相似的软件质量特性树。
[如欲了解ATAM的历史源头，以及另外一种（更简单的）构架评估方法，您可以阅读 [Kazman94]中关于软件构架分析方法的内容。
11.7讨论题
(丨）考虑•下您所在软件组织中的某个重要的软件系统。您能使用本窣给出的模板表 述命业动机或对构架进行讨论吗？如果不能，遗漏了什么信息？您能为该系统画出效用树的草图吗？
(2)如果您打算对该系统的构架进行评估，您想U:谁参与此次评估.涉众起到的作用 ri什么？您可以让谁代表涉众发挥这些作用？