7.1.1 评估关注的质量属性
软件体系结构的设计是整个软件开发过程中关键的一步。对于当今世界上庞大而复杂的系统来说，如果没有一个合适的体系结构而要有一个成功的软件设计几乎是不可想象的。
不同类型的系统需要不同的体系结构，甚至一个系统的不同子系统也需要不同的体系结构。体系结构的选择是一个软件系统设计成败的关键。但是，怎样才能知道为软件系统所选用的体系结构是否恰当？如何确保按照所选用的体系结构能顺利地开发出成功的软件产品呢？要回答这些问题，需要使用专门的方法对软件体系结构进行分析和评估。
体系结构评估可以只针对一个体系结构，也可以针对一组体系结构。在体系结构评估过程中，评估人员所关注的是系统的质量属性，所有评估方法所普遍关注的质量属性有以下几个。
1．性能
性能是指系统的响应能力，即要经过多长时间才能对某个事件作出响应，或者在某段时间内系统所能处理的事件的个数。经常用单位时间内所处理事务的数量或系统完成某个事务处理所需的时间来对性能进行定量的表示。性能测试经常要使用基准测试程序(用以测量性能指标的特定事务集或工作量环境)。
2．可靠性
可靠性是软件系统在应用或系统错误面前、在意外或错误使用的情况下维持软件系统的功能特性的基本能力。可靠性是最重要的软件特性，通常用它衡量在规定的条件和时间内，软件完成规定功能的能力。可靠性通常用平均失效等待时间(Mean Time To Failure，MTTF)(指软件在失效前正常工作的平均统计时间 )和平均失效间隔时间(Mean Time Between Failure，MTBF)来衡量。在失效率为常数和修复时间很短的情况下，MTTF和MTBF几乎相等。MTBF可用下式表示：
MTBF TTF TTR(平均修复时间)
可靠性可以分为两个方面：
(1) 容错。其目的是在错误发生时确保系统正确的行为，并进行内部“修复”。例如在一个分布式软件系统中失去了一个与远程构件的连接，接下来恢复了连接。在修复这样的错误之后，软件系统可以重新或重复执行进程间的操作直到错误再次发生。
(2) 健壮性。其能保护应用程序不受错误使用和错误输入的影响，在遇到意外错误事件时确保应用系统处于已经定义好的状态。和容错相比，健壮性并不是在错误发生时软件可以继续运行，它只能保证软件按照某种已经定义好的方式终止执行。软件体系结构对软件系统的可靠性有巨大的影响。例如，软件体系结构通过在应用程序内部包含冗余、集成监控控件和异常处理来支持可靠性。
3．可用性
可用性是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
4．安全性
安全性是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性是根据系统可能受到的安全威胁的类型来分类的。
安全性又可划分为机密性、完整性、不可否认性及可控性等特性。其中，机密性保证信息不泄露给未授权的用户、实体或过程；完整性保证信息的完整和准确，防止信息被非法修改；不可否认性是指正确认定发送者，使之不能否认已发送过的数据的过程；可控性保证对信息的传播及内容具有控制的能力，防止为非法者所用。
5．可修改性
可修改性是指能够快速地以较高的性能代价比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。可修改性包含四个方面：
(1) 可维护性。这主要体现在问题的修复上；在错误发生后“修复”软件系统。做好为可维护性准备的软件体系结构往往能做局部性的修改并能使对其他构件的负面影响最小化。
(2) 可扩展性。这一点关注的是使用新特性来扩展软件系统，以及使用改进版本来替换构件并删除不需要或不必要的特性和构件。为了实现可扩展性，软件系统需要松散耦合的构件。其目标是实现一种体系结构，它能使开发人员在不影响构件客户的情况下替换构件。支持把新构件集成到现有的体系结构中也是必要的。
(3) 结构重组。这一点处理的是重新组织软件系统的构件及构件间的关系，例如通过将构件移动到一个不同的子系统而改变它的位置。为了支持结构重组，软件系统需要精心设计构件之间的关系。理想情况下，它们允许开发人员在不影响实现的主体部分的情况下灵活地配置构件。
(4) 可移植性。可移植性使软件系统适用于多种硬件平台、用户界面、操作系统、编程语言或编译器。为了实现可移植，需要按照硬件无关的方式组织软件系统，其他软件系统和环境被提取出。可移植性是系统能够在不同计算环境下运行的能力。这些环境可能是硬件、软件，也可能是两者的结合。在关于某个特定计算环境的所有假设都集中在一个构件中时，系统是可移植的。如果移植到新的系统需要作些更改，则可移植性就是一种特殊的可修改性。
6．功能性
功能性是系统能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
7．可变性
可变性是指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品(例如，软件产品线)的基础时，可变性是很重要的。
8．可集成性
可集成性是指系统能与其他系统协作的程度。
9．互操作性
作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，这种互操作性也影响应用的软件体系结构。
7.1.2 评估的必要性
Barry Boehm说过，“匆忙之中选择某个体系结构，闲暇之时就会深深懊悔”。糟糕的体系结构实际上宣判了项目的死刑。关于评估的必要性有以下三点：
(1) 软件体系结构反映了系统最初始的设计决策，对同样一个问题，在初始阶段纠正所带来的花费和在测试或部署阶段纠正导致的开销不在一个数量级。毕竟在体系结构视图上一个符号改动比后期大规模的代码改动工作量要少得多，这样，巨大的额外开销就避免了。
有了对体系结构的完整描述，退一步讲即使是部分描述，也能模拟系统运行时的行为，对一些设计思想进行探讨，并推断体系结构应用于系统时的潜在影响。而所有这些工作只不过需要整个项目周期中的几天时间。
(2) 评估是挖掘隐性需求并将其补充到设计中的最后机会。由于缺乏充分的交流和不能对软件项目透彻理解，许多涉众并不知道自己到底想要什么。在需求获取阶段，他们会列出自认为最重要的几项要求。但是评估之后，这些观点可能会变动很大。有些起初重视的方面可能并不是那么重要，而另一些本来看上去无关紧要的东西却被发现需要花更多精力来处理。
在评估过程中，涉众会感受到群体力量的强大，同时对自己的参与带来的正面影响也很振奋。而架构师会在此阶段的活动中了解涉众的各种想法，调整初始设计以做出权衡(也可能是对候选体系结构的对比和选择)。对架构师来讲，这也是加深对待建系统理解的好机会。总之，体系结构评估清除了涉众的沟通障碍。其最直接的结果就是得到各方满意的系统蓝图，而这至少意味着项目成功了一半。
(3) 体系结构是开发过程的中心，它决定了团队组织、任务分配、配置管理、文档组织、管理策略，当然还有开发进程安排。不良体系结构往往带来一塌糊涂的效果，因为它在被使用过程中必须被修改以适应新的考量，或者去弥补那些在开发早期阶段没有考虑到的缺陷，在这些方面进行修改需要花费大量成本。
更糟糕的是，团队会面临着项目失控的可怕境遇：改了旧错误带来了更多的新错误；过时的体系结构会破坏现有的开发团队结构，而这又进一步干扰了开发工作；客户、管理层和开发者都急切地盼望者噩梦结束，但谁都不知道这样的日子何时到来。如果在这些发生之前充分分析一下体系结构就可以部分避免这些问题的发生。
因此，体系结构想要付诸实践的话，就必须被评估。
7.2 软件体系结构评估的主要方式
7.2.1 主要评估方式简介和比较
从目前已有的软件体系结构评估技术来看，某些技术通过与经验丰富的设计人员交流获取他们对待评估软件体系结构的意见；某些技术对针对代码质量度量进行扩展以自底向上地推测软件体系结构的质量；某些技术分析把对系统的质量的需求转换为一系列与系统的交互活动，分析软件体系结构对这一系列活动的支持程度等。
尽管看起来它们采用的评估方式都各不相同，但基本可以归纳为三类主要的评估方式：基于调查问卷或检查表的方式、基于场景的方式和基于度量的方式。
1．基于调查问卷或检查表的评估方式
卡耐基梅隆大学的软件工程研究所(CMU/SEI)的软件风险评估过程采用了这一方法。调查问卷是一系列可以应用到各种体系结构评估的相关问题，其中有些问题可能涉及到体系结构的设计决策；有些问题涉及到体系结构的文档，例如体系结构的表示用的是何种ADL；有的问题针对体系结构描述本身的细节问题，如系统的核心功能是否与界面分开。检查表中也包含一系列比调查问卷更细节和具体的问题，它们更趋向于考察某些关心的质量属性。例如，对实时信息系统的性能进行考察时，很可能问到系统是否反复多次地将同样的数据写入磁盘等。
这一评估方式比较自由灵活，可评估多种质量属性，也可以在软件体系结构设计的多个阶段进行。但是由于评估的结果很大程度上来自评估人员的主观推断，因此不同的评估人员可能会产生不同甚至截然相反的结果，而且评估人员对领域的熟悉程度、是否具有丰富的相关经验也成为评估结果是否正确的重要因素。
尽管基于调查问卷与检查表的评估方式相对比较主观，但由于系统相关人员的经验和知识是评估软件体系结构的重要信息来源，因而它仍然是进行软件体系结构评估的重要途径之一。
2．基于场景的评估方式
场景是一系列有序的使用或修改系统的步骤。基于场景的方式由SEI首先提出并应用在体系结构权衡分析方法(Architecture Tradeoff Analysis Method，ATAM)和软件体系结构分析方法(Software Architecture Analysis Method，SAAM)中。这种软件体系结构评估方式分析软件体系结构对场景，也就是对系统的使用或修改活动的支持程度，从而判断该体系结构对这一场景所代表的质量需求的满足程度。例如，用一系列对软件的修改来反映易修改性方面的需求，用一系列攻击性操作来代表安全性方面的需求等。
这一评估方式考虑到了包括系统的开发人员、维护人员、最终用户、管理人员、测试人员等在内的所有与系统相关的人员对质量的要求。基于场景的评估方式涉及到的基本活动包括确定应用领域的功能和软件体系结构的结构之间的映射，设计用于体现待评估质量属性的场景以及分析软件体系结构对场景的支持程度。
不同的应用系统对同一质量属性的理解可能不同，例如，对操作系统来说，可移植性被理解为系统可在不同的硬件平台上运行，而对于普通的应用系统而言，可移植性往往是指该系统可在不同的操作系统上运行。由于存在这种不一致性，对一个领域适合的场景设计在另一个领域内未必合适，因此基于场景的评估方式是特定于领域的。这一评估方式的实施者一方面需要有丰富的领域知识以对某一质量需求设计出合理的场景，另一方面，必须对待评估的软件体系结构有一定的了解以准确判断它是否支持场景描述的一系列活动。
3．基于度量的评估方式
度量是指为软件产品的某一属性所赋予的数值，如代码行数、方法调用层数、构件个数等。传统的度量研究主要针对代码，但近年来也出现了一些针对高层设计的度量，软件体系结构度量即是其中之一。代码度量和代码质量之间存在着重要的联系，类似地，软件体系结构度量应该也能够作为评判质量的重要的依据。赫尔辛基大学提出的基于模式挖掘的面向对象软件体系结构度量技术、 Karlskrona和Ronneby提出的基于面向对象度量的软件体系结构可维护性评估、西弗吉尼亚大学提出的软件体系结构度量方法等都在这方面进行了探索，提出了一些可操作的具体方案。我们把这类评估方式称做基于度量的评估方式。
基于度量的评估技术都涉及三个基本活动：首先需要建立质量属性和度量之间的映射原则，即确定怎样从度量结果推出系统具有什么样的质量属性；然后从软件体系结构文档中获取度量信息；最后根据映射原则分析推导出系统的某些质量属性。因此，这些评估技术被认为都采用了基于度量的评估方式。
基于度量的评估方式提供更为客观和量化的质量评估。这一评估方式需要在软件体系结构的设计基本完成以后才能进行，而且需要评估人员对待评估的体系结构十分了解，否则不能获取准确的度量。自动的软件体系结构度量获取工具能在一定程度上简化评估的难度，例如MAISA可从文本格式的UML图中抽取面向对象体系结构的度量。
4．三种评估方式比较
经过对三类主要的软件体系结构质量评估方式的分析，表7-1从通用性、评估者对体系结构的了解程度、评估实施阶段、评估方式的客观程度等方面对这三种方式进行简单的
比较。
7.2.2 基于场景的评估方法概念介绍
最著名的体系结构评估方法均是基于场景的。场景是系统使用或改动的假定情况集合。各种场景可以抽象成包含6个部分的一般形式，以方便后期的评估。
(1) 刺激源：这是某个生成该刺激的实体(人、计算机系统或任何其他可以起到刺激作用的实体)。
(2) 刺激：刺激源对系统的影响。
(3) 环境：与刺激相关的上下文条件。当刺激发生时，系统可能处于过载，或者正在运行，也可能是其他情况。
(4) 制品：接收刺激的实体。可能是整个系统，也可能是系统的一部分。
(5) 响应：是在刺激到达后所采取的行动。
(6) 响应度量：当响应发生时，应该能够以某种方式对其进行度量，以对需求进行测试来确定其是否能被满足。
场景的一个优点就在于它是针对特定系统的，也就是说它不会被领域所限。场景可以充分自由地表达刺激源导致的系统响应。更重要的是场景可以将多个涉众的建议统一起来。不同的涉众可以对相似的情况从各自的角度作出解释，然后这些解释就可以在删除冗余信息后整合到一个场景里。
若干知名的评估方法均使用场景，例如SAAM、ATAM、SAEM等。下面对其中的SAAM和ATAM方法进行较详细的介绍。
7.3 SAAM软件体系结构分析方法
SAAM是最早精心设计并形成文档的分析方法。它出现于1993年，发表于1994年(Kazman，1994)。后来Kazman对其进行改进，在参考文献[72]中对其提供了几个深入的案例研究。
SAAM是一种直观的方法，它试图通过场景来测量软件的质量，而不是泛泛的不精确的质量属性描述。SAAM也比较简单，仅仅考虑场景和体系结构的关系，也不涉及太多的步骤和独特的技术。
于是，它成为体系结构评估初学者的理想入门方法。SAAM最初是为了评估体系结构的可修改性而设计，不过经过演化和实际应用，在许多其他常见的质量属性评估方面也展现了威力，并成为其他一些评估方法的基础，比如ATAM。利用预先定义的场景，SAAM可以检查出被评估体系结构的潜在风险，并对几个候选体系结构进行比较。
另外，SAAM可以为很多涉众进行(可能是项目启动后的第一次)讨论提供平台。这样大家就有机会用人人都懂的语言来说出各自关心的问题，了解别人所关心的，并看到这些问题又是如何在蓝图中处理的。在此过程中，理解上的偏差和不正确的设计都将被发现。
7.3.1 SAAM的一般步骤
SAAM的一般步骤看上去非常简单直观，图7-1揭示了评估的一般步骤，每个阶段能得到什么，各个阶段的关系如何。
从图7-1可以清楚地看到SAAM的输入、输出。为了开始评估，必须提供一个体系结构描述，该描述可以是所有参与者能接受并理解的任何形式。根据特定评估的对象和关注点，描述的详细程度和范围可能不同，有时也需要进行更新或补充。多种不同的候选体系结构的描述都可以拿来评估以便对比和选择。
图7-1 SAAM的活动和依赖
场景是体系结构描述之外的另一个关键输入。基于场景的评估方法的基本要点就是检查当前的体系结构能否直接满足期望的质量需求，并在不能满足时看看可以怎样改动。我们几乎不可能对质量属性进行精确测量，可又希望质量属性对评估有意义，所以必须以一种更实在的形式来表述它。这就是场景为什么这么重要的原因。有些场景可能可以在功能性需求中提取出来，不过大多数都是源自涉众的讨论和头脑风暴。当然，待评估的体系结构起码得支持需求说明中的所有功能。而评估过程的关键是搞清楚体系结构是否能在满足需求的情况下拥有良好的质量属性。
SAAM主要是以评估报告的形式输出。如果是评估单个体系结构，那么报告的内容将包括该体系结构设计不能满足质量需求的缺陷；多个体系结构情况下将报告哪个候选体系结构能最好地满足场景。由不适当分解或过分复杂导致的不良设计也会在报告中被指出。最后，SAAM可以估计修改导致的费用和范围，以避免盲目的修改。
除此之外，SAAM还有一些优点。它增强了涉众对体系结构的理解，强制对体系结构更好的编档，澄清系统将来演化最可能的方向。通过涉众广泛的讨论，业务目标的优先级和潜在的场景也得以澄清。
下面详细介绍SAAM每个阶段的活动和技术。
7.3.2 场景生成
场景生成是各种涉众参与讨论和头脑风暴的过程。每个参与者都有自己的视角，并提供基于此的场景。对于某个修改，项目投资方关注其导致的费用，程序员在意哪些模块将受到影响，买主关心价格，最终用户关心由修改带来的好处。有关联的，甚至是相互矛盾的场景可能在这个过程中出现并被编档。评估过程中最重要的是保证一个可以自由进行评论的氛围。生成的所有场景都应该认真记录到列表中以便涉众之后审查。对那些缺乏评估经验的人，可能需要一个指导教程，这样才能保证“好”的场景生成。所谓“好”场景，是指这些场景反映了系统主要用例、潜在修改或更新，或系统行为必须符合的其他质量指标。
此阶段可能会迭代进行几次。收集场景的时候，参与者可能会在当时的文档中找不到需要的体系结构信息。而补充的体系结构描述反过来又会触发更多的场景。场景开发和体系结构描述是互相关联、互相驱动的。
7.3.3 体系结构描述
体系结构文档包括了需要评估的信息，当然大多数信息都是在评估前就必须准备好的。为了更好地进行评估，体系结构描述应该以一种参与者都能接受的形式表达，对构件、连接件、模块、配置、依赖、部署等概念要区分清楚。只要能清晰无歧义，自然语言、框图、数据表或者形式化模型等任何形式都可以用来表达体系结构。如上节所述，场景生成和体系结构描述阶段可能会迭代进行几次，它们互相关联、互相驱动。
7.3.4 场景的分类和优先级确定
SAAM中的场景分为两类：直接场景和间接场景。直接场景指当前体系结构不经修改即可支持的场景。如果一个场景能在原始需求(该需求在设计当前体系结构时已经被考虑)找到类似的内容，那么显然该场景很容易被满足。架构师可以引入一系列的响应行为来证明这些场景确实得到满足。通常，直接场景虽然对揭示体系结构缺陷没有帮助，却可以提高涉众对体系结构的理解程度，有助于对其他场景的评估。
间接场景不能直接被当前体系结构支持。为了满足间接场景，就需要对体系结构进行某种修改，比如添加一个或多个构件、取出间接层、用更合适的模块替代、改变或增强接口、重定义元素间关系或者上述情况组合。间接场景是SAAM后续活动最关键的驱动器。通过充分考虑各种间接场景，可以在很大程度上预测系统将来的演化，尽管这种预测可能很模糊。
有了架构师的帮助，对场景分类就很容易了。纵然如此，场景还是可能会多到无法一一仔细评估。由于时间和资源有限，就需要通过设置优先级的方法来选择最关键的场景。CMU SEI建议以涉众范围内投票的方式决定哪些是“关键”的。每个人都拿到固定数量的选票，大概是场景总数的30%。投票策略是只要每个人投票总数不超过手中的选票总数，他可以为任何场景投任何数目的票。然后按照得到选票数目的顺序对所有场景进行排序，并根据具体情况选择一定数目的排序靠前的场景。有时候，排序后的列表可能会有一个泾渭分明的分界，一边是得票数很多的场景，另一边得票数很少(如图7-2所示)的场景，那么直接选择得票多的场景即可。
其他时候，可以计算一下评估多少场景比较适合，或者估计一下评估时间内能完成多少。典型的比如说，一整天可以评估完8个场景而计划两天的时间进行场景的单个评估，那么选择15或16个比较合适。要注意的是即使根据预先定好的规则某些场景是应该放弃的，但如果它们的提出者仍然坚持而其他人又不反对的话，那么也可以添加到“关键”列表中。
图7-2 选择关键场景
7.3.5 间接场景的单独评估
涉众最关心的信息莫过于间接场景会怎么影响当前的候选体系结构。需要做什么修改？修改是否在项目预期的费用、时限和范围内？如果是，那么到底需要多少额外的工作？如果不是，有没有替代方案？这些问题在评估的这个阶段都需要回答。对于每个候选体系结构，都要评估一下在每个间接场景下的表现。在此，体系结构的元素被映射到具体的质量属性。
间接场景都要求改动当前体系结构。大多数时候，架构师负责解释需要的变更。如果连他们都没法说清楚该如何处理这些变更，评估前体系结构描述的完整性就值得怀疑了。具体来说，这种解释包括改动涉及的范围、该范围内具体的元素和估计的工作量。一般这些信息都要以表7-2的形式进行总结。
表7-2给出了后续变更工作的启动基础。涉众根据此表就可以决定哪些工作是最紧急并需要尽快进行，哪些工作应该延迟一段时间，还有哪些工作因其完成的可能性不高不应该在当前项目中实施。如果一个场景需要过多修改，可以认为有设计缺陷，可能需要在修改发生处做重新设计。
7.3.6 对场景关联的评估
如果不同的场景都要求对同一个体系结构元素进行修改，则称这些场景关联于此元素。场景关联意味着原始设计的潜在风险。这里需要强调的一点是，所谓场景“不同”是指场景的语义有差异，该语义由涉众决定。在分类和设置优先级处理之前，有共同点的场景可以被归为一组或合并以避免评估冗余，最终保留那些反映典型用例、典型修改或其他质量属性而又很少重叠的场景。语义不同的场景影响同一体系结构元素(比如，同一个构件)的情况表明设计不良。
场景关联的程度高意味着功能分解不良，当然如果某些经典体系结构模式的工作方式就是如此，就可以当例外来处理。一般说来，场景关联可能是灾难的种子，因为将来系统演化的时候该关联会导致混乱的修改。虽然无需认定所有的场景都是灾难之源，但它们必须得到足够的重视。
不过在识别场景关联时要小心一些伪关联。有时体系结构文档表明某个构件参与了某个关联，但是实际上是该构件内部分解良好的子构件独立处理了不同的“关联”场景。这时可以返回到步骤2——体系结构描述，检查一下文档的详细程度是否满足关联识别所需。
7.3.7 形成总体评估
SAAM的最后一步是形成总结报告。如果候选体系结构只有一个，那么总体评估要做的就是审查前面步骤的结果并总结成报告。修改计划将基于此报告。
如果有多个候选体系结构，就需要进行一番比较。为此需要根据各个关键场景和商务目标的关系来决定每个关键场景的权重。比较体系结构时会发现，某个体系结构在某些场景下表现突出，而另一个体系结构在另一些场景下最好。有时简单的根据候选体系结构在哪些场景下具有优势很难做出最好的选择。
而事实上，即使同样叫做关键场景，场景的重要性也是不同的。这可以通过设置权重来体现。多年来，出现了几种决定权重的策略。其中一种方式是利用涉众的讨论，有时是争论来得到相对权重。或者，如果有历史记录，则是很好的参考资料。
直接场景也影响总体评估结果。不同的候选体系结构几乎总是有各自不同的直接场景。回忆一下，直接场景是不经修改就被体系结构支持的那些场景。所以支持更多直接场景的体系结构也暗示着这是一个更好的候选。有时，也会把直接场景的重要性放到总体评估这里一起考虑。
最后，架构师对每个关键场景下各个候选体系结构打分。一般来说，打分采用相对值的方法，比如“1，0，-1”(或“2，1，0”、“+，0，-”等)。1表示体系结构在该场景下表现很好；-1相反；0则表示体系结构对该场景无关紧要。根据需要把范围定到5或者10也没问题。有了场景权重和体系结构的得分，就可以画一个类似表7-3的表格。然后把该表格和独立场景评估、场景关联评估和直接场景分析的结果结合起来，选择一个最好的体系结构作为下一步开发的基础。
7.4 ATAM体系结构权衡分析方法
ATAM方法可看做SAAM方法的增强版。从名字可以看出，ATAM方法除了能暴露被评估体系结构的潜在缺陷和风险外，还能使我们更好地理解和权衡多个相关的，甚至是不一致的质量需求或目标。
ATAM的基础来自3个领域：体系结构风格、质量属性分析组(包含丰富的质量属性和体系结构对应关系的库)和SAAM。
下面首先按照历史顺序回顾一下ATAM在各个发展阶段的大概步骤，然后介绍ATAM主要步骤要做的工作以及在这些步骤中采取的技术。
7.4.1 最初的ATAM
大多数设计都是对目标进行权衡。如果不需要权衡，那么实际上也没必要做设计，因为只要根据需求做些固定的计算就行了。大多数的权衡源自非技术的原因。比如说，为了保证系统的可伸缩性，可能需要更多的间接层，从而导致更多的编程和测试工作，也意味着整个项目需要更多的花费，可能也需要更多的时间。再比如，两个涉众持有截然相反的需求，结果开发进程受阻。
架构师的职责是进行设计，方式是采集需求并把需求映射到软件的结构和行为描述中去。不过除此之外，他们更重要的责任是从技术和社会学的视角做权衡。ATAM就是做此类权衡的合适工具。ATAM和其他评估方法或技术有着根本的不同，它明确考虑多个质量属性之间的关联，并可以对这些关联必然导致的权衡进行原则上的推理。为了达到这个目标，最初的ATAM分成4个阶段内的6个步骤，如图7-3所示。
图7-3 ATAM的步骤
螺旋模型源自Boehm(1986)，该文引入了一个描述软件开发的类似的螺旋模型。图7-3把评估集成到了整个设计过程中。6个步骤，即收集场景，收集需求、限制和环境，描述体系结构视图，属性特定分析，识别敏感度和识别权衡，构成了一轮迭代。完成上述步骤后如果评估结果表明当前体系结构能满足期望的质量需求，就可以进行详细设计或实现了。否则，可以制定修改计划更新已有设计，新的设计将进入第二轮ATAM的迭代。值得注意的是，这些步骤并不需要按照线性顺序操作。每个步骤都可能会触发任何其他步骤的改进，正如图7-3所示。又如，属性特定分析可能需要收集更多的场景来保持各个属性的均衡。
在进行一次迭代时，第一阶段关注场景输入。第一步仅仅关注“使用场景”，尽量增进参与者对体系结构的理解。这样沟通的基础就建立了。第二步是收集质量相关信息，也是以场景的形式表达。这些场景可以被看做是质量需求假设，是后续步骤的基础。得到需求之后，就可以利用需求的限制开始第一阶段的设计。设计出来的体系结构被编档以备评估。
接下来评估就开始了。首先独立分析每个质量属性，这时候不必考虑场景关联。单独评估可以使得各个质量属性方面的专家最大程度地利用属性特定的技术或模型进行分析。比如，马尔科夫模型擅长可用性分析，而SPE(即软件性能工程)分析性能特别方便。属性特定分析的结果以特定模型中数据的测量值来表述，例如“最坏情况下请求必须在500 ms内得到响应”，或者“在理想环境下系统的可用性为99.99%”。
最后要做的是识别敏感度和权衡。在解释这两个步骤之前，先定义一下“体系结构元素”。体系结构元素是指任何构件、构件属性或构件关系的属性，只要它们对质量属性有影响。敏感点是指会由于体系结构元素的修改而发生显著变化的系统模型参数。例如，基于C/S的系统，服务器的冗余度影响整个系统的可用性。增加一个后备服务器会把平均每年的系统崩溃时间降低一个数量级。这里系统平均崩溃时间就是一个敏感点。一个权衡点是指与多个敏感点有关的体系结构元素。
就是说，如果一个构件、构件属性或关系属性变化了，若干质量属性会大幅度地变得更好或更坏。 例如，C/S系统中服务器冗余度就是一个权衡点，因为它的改动将导致可用性、费用、安全性等属性的显著变化，这些特性有些是互相冲突的。权衡点揭示了架构师需要密切关注的问题。
7.4.2 改进版ATAM
1999年，ATAM在几个实际项目中应用后，有了升级和增强。ATAM的原有步骤有的进行了合并，另外又补充了几个其他的步骤(如图7-4所示)。比如，增加了“场景分组和设置优先级”，这个步骤和SAAM中类似。有几个步骤被浓缩成一个，如“体系结构介绍”。
图7-4 改进版ATAM的步骤
对改进版ATAM主要有两点值得注意。第一点是怎样才知道什么时候停止场景生成比较合适。从图7-4可以看到第3步进行场景覆盖检查。CMU SEI专门为此步骤定义了一套针对特定质量属性的问题，回答这些问题可以帮助评估者找到遗漏的有用场景并补充进来。
另外一点就是引入了很多ABAS(基于属性的体系结构风格)。ABAS是一种分析辅助工具，可以帮助涉众识别体系结构风格的质量属性，比如性能、可用性、安全性、可测试性、可修改性等。简言之，ABAS就是带有属性值以反映质量信息的体系结构风格。ABAS的著名例子是用于多个并发进程的性能分析。如果软件系统使用多个进程，每个进程都竞争有限的计算资源，该系统就可以称做性能ABAS。对此ABAS应当进行以下相关参数信息的质询，比如进程优先级、同步位置、排队策略和估计执行时间。但是，仅仅知道性能相关的信息并不足够，还需要把这些信息输入到分析框架以便分析。例如，单调速率分析是实时系统的一个有效分析框架。
对比两个版本的ATAM，可以看到一个趋势，就是更多实际的技术和关注点被加入进来。第一版建立在螺旋开发模型之上，理论的味道很浓。在第二版，步骤进行了重新调整以更好地符合实际需要。除此之外，也引入了一些需要的辅助技术，尽管其中有些从评估的角度看并不能算是核心技术。
简单地说，这些变化试图为如下问题提供答案：怎样帮助涉众知道做什么和怎么做从而为评估过程做贡献？怎样引导涉众精确清晰地理解待评估的体系结构？怎样生成对评估有益的场景，同时避免忽略某些必需的场景，并从所有场景中选出最重要的？怎么把场景映射到体系结构，以便识别敏感点和权衡点？最后，怎样对特定的质量属性进行具体的评估并生成负责规划后续活动的评估报告？这些问题是大多数评估方法的共同问题。尽管经历了众多项目的实际应用和数以千计的架构师、设计人员和软件工程师的改进，ATAM仍在不断调整以追求更好的评估效果。
下一节我们将介绍ATAM现在的情况，看看又有什么新技术被引入进来。
7.4.3 ATAM的一般过程
当前ATAM的完整过程包括4个阶段，共9个主要步骤。在此，步骤仍然不必是线性执行的。实践上，评估负责人可以决定应该执行哪些步骤，或者直接跳到本应在若干步之后才实施的步骤。这些都视情况而定。步骤仅仅表明评估中间制品的生成顺序。顺序靠后的步骤总需要靠前步骤的制品作为输入。因此，如果评估团队已经有了某一步骤生成的信息，或者这些信息对此次评估没有用处，就可以跳过这一步。
ATAM的一般过程如图7-5所示。阶段Ⅰ和Ⅱ是评估的核心。
图7-5 ATAM的一般过程
阶段0是准备阶段。考虑到ATAM评估的范围、时间和费用，有必要就评估时间表、费用计划、参与者组织等问题进行讨论甚至签署严格的合同协定。评估前首先应该搞清楚进行评估是否可行、谁参与评估、评估的对象是什么、评估结果提交给谁、评估后又该做什么。为了避免核心评估阶段中断，上面提到的每个问题都需要仔细考虑和计划。然后，需要建立一个评估团队(如果准备评估的组织没有专职评估团队的话)，负责接下来的工作。该团队中需要定义几个角色，包括团队领导、评估领导、书记员、计时者、提问者、监督员等。同一个人可以扮演多个角色。通常，在阶段0会开一个评估团队会议以明确责任并为下一阶段做好准备。
阶段Ⅲ是评估收尾阶段。这时有两项任务必须要做。首先是要产生最终报告，记录核心评估阶段的过程、信息和基于此的结论。另一项任务是进行总结以便改进今后的评估。一方面，可以询问评估成员或者其他参与者感觉哪些活动好，哪些不好，为什么。可以收集关于本次评估的花费和收益的信息。这种数据挖掘可能会有利于找到各种活动的可改进之处。另一方面，可以整理本次的场景和相关的问题，以备下次评估类似项目。在领域特定的开发中，这项活动因其强大的可重用性而非常有效。
阶段Ⅰ和阶段Ⅱ是核心评估阶段，共有9个步骤，和前面小节曾讲的步骤类似。这些步骤又进一步分为如下4个子阶段：
1．介绍
(1) 介绍ATAM：介绍ATAM的步骤、活动和技术。
(2) 介绍商业动机：介绍商业目标以识别主要质量需求。
(3) 介绍体系结构：解释当前体系结构如何满足商业动机。
2．研究和分析
(4) 识别体系结构方法：找到建立体系结构所用的方法。
(5) 生成质量属性效用树：以树的形式产生反映系统效用的带有优先级的场景。
(6) 分析体系结构方法：对支持关键场景的体系结构方法进行分析，并识别风险、非风险、敏感点和权衡点。
3．测试
(7) 头脑风暴和给场景指定优先级：由更多的涉众生成更多的场景。
(8) 分析体系结构方法：同步骤(6)，不过采用的场景来自步骤(7)。
4．报告
(9) 报告结果：产生评估报告。
实际上，主要阶段Ⅰ和Ⅱ分别是上述步骤的一次迭代，当然包括的具体步骤和参与者范围有所不同，如表7-4所示。主要阶段Ⅱ需要更多类型的涉众参与场景生成和分析讨论。主要阶段Ⅰ则试图利用几个原则识别主要的质量属性，为后续评估打好基础。主要阶段Ⅰ只包含步骤(1)～(6)。当然，不必机械式地执行这两次迭代。实际应用时评估团队可以调整迭代这些步骤的时间计划，并可以自行决定每次迭代的参与者。
读者可能会看到一些不熟悉的概念，如“效用树”、“风险”或者“非风险”，也可能会问为什么步骤(6)看上去和步骤(8)一样。这些问题在后面的小节中将有详细介绍。
7.4.4 介绍
这个子阶段的目标是界定哪些行动是有益的，而哪些不是。该阶段引导参与者致力于系统设计并能做出贡献。同时，后续步骤所需的输入也由此阶段提供。
步骤(1)——介绍ATAM。
这一步回答了“什么是ATAM？”和“ATAM参与者都做些什么？”的问题。这是因为除了专业的评估团队，其他涉众可能是第一次参与评估。评估负责人需要向参与者介绍ATAM，回答他们的相关问题。在此过程中，评估负责人的工作集中在场景确定优先级、效用树构建等操作的步骤、概念和技术，评估的输入输出及其他有关信息。
步骤(2)——介绍商业动机。
项目领导人(项目主要管理者或类似人员)需要向所有参与者解释主要的商业动机。毕竟，场景开发和特定的评估需要此类信息。这项介绍的主题应该包括：主要商业目标，需求说明中已文档化的主要功能，来自技术、管理、经济、政策方面的有关限制，还有涉众的重要质量需求。注意“涉众”这个概念，在不同主要阶段，涉众的范围不同，这就使得关注点会有所偏重。这种差异也能作为一个参照，以便暴露那些没被考虑的问题。
步骤(3)——介绍体系结构。
首席架构师介绍已有的体系结构，通常采用多视图的形式。大多数项目需要展示静态逻辑结构的分解视图、运行时结构的构件-连接件视图、逻辑结构和物理实体之间映射的分布视图和描述期望行为的行为视图。不过特定情况下，架构师有权决定使用其他视图展示系统某个特定区域，以此提供与关键质量属性对应的体系结构信息。
体系结构介绍的详细程度直接影响后续的分析。根据在准备阶段设定的评估的期望效果，架构师有义务选择一个对评估比较合适的详细程度。当然在评估时，如果需要的体系结构信息未被提供，涉众可以向架构师询问。最后，一个重要任务就是列出明确使用的体系结构方法，为下一步做准备。
7.4.5 研究和分析
在这个子阶段，涉众开始将体系结构与质量属性对应起来。不过和前述ATAM的其他版本相比，在此使用的具体方法更加出色。这里捕获分析的不是体系结构元素，而是体系结构方法；用于场景生成的不是头脑风暴一类的办法，而是采用效用树。在效用树中，每个场景的优先级由二维估计值来测量。评估中，要识别风险、非风险、敏感点和权衡点，不过这些识别是分析的开始而非结束。
步骤(4)——识别体系结构方法。
识别体系结构方法的原因是这些信息提供了体系结构构建背后的基本原则。简言之，一个体系结构方法是指根据功能或质量需求而做的设计决定。
众所周知，软件体系结构风格和模式包含了大量的有用信息，这些信息与进行特定设计的原理紧密相关。体系结构模式描述了必要的抽象元素、这些元素的结构和相关的一些约束。每个体系结构模式的优缺点和基本原理都有成千上万次的使用作基础。ATAM第二版中提到的ABAS尤其有用。和ABAS相联系的属性值暴露了主要的质量属性目标，也能用来分析能否满足这些目标。
但是并不是所有的体系结构方法都可以用体系结构风格或模式的形式表达。如果是这样，架构师就需要用自然语言解释为什么做出这样的设计，或为什么设计会以期望的方式运行。架构师应该能讲清楚使用的每个体系结构方法。这样，对于那些架构师觉得很基础，但是对评估非常重要的体系结构方法(于是如果不是被明确的问到，架构师不会做特别说明)，其他评估参与者也有机会理解。
尽管这一步骤需要清晰的解释，但是不需要对方法的分析，那是步骤(6)中的任务。
步骤(5)——生成质量属性效用树。
本步骤将识别关键质量属性目标，参与者是评估团队和核心项目成员，如管理者、客户代表和首席架构师。这里主要的目标是避免在评估上时间和费用的浪费。如果参与者不能决定出关键的质量属性目标或就此达成一致，评估就无法得到应有的效果。质量属性效用树是达到此目标的强大工具。
质量属性效用树(Quality Attribute Utility Tree，QAUT)以树的形式表现质量属性的细化。QAUT的根是效用，接下来是质量属性层，典型的有可用性、可修改型和安全性等。再接着下一层是质量属性具体描述分类，也就是把某个质量属性分成几个主题。第四层也是最后一层，是具体的场景，精确定义了质量需求以允许后续分析。一般来说，QAUT把系统的期望效用翻译成了场景。
每个场景有两维度量：
(1) 此场景对系统成功的重要程度。
(2) 架构师所估计的支持此场景的开发难度。测量所用的标度可以定为类似高、中、低这样范围为3的序数尺度，范围为5或者10等也可以。标记好度量后，场景就可以排出优先级了，最上面的是参与者希望得到的最关键的质量属性目标。
图7-6是QAUT的一个例子。实际上，真实项目中生成的场景比此例复杂得多。最终QUAT生成了带有优先级的场景列表，顺序应该是(H，H)、(H，M)、(M，H)……(L，L)。这个优先级清楚地揭示了各种涉众的全面关注。也许有人认为性能是关键需求，而另一些人坚持可用性需要更多的关注。但是在建立QAUT之前，每个人的想法可能都是凌乱的。QAUT引导并澄清系统的质量需求及其相对重要性。于是，评估的时间和成本不够时就可以省略优先级低的场景。因为分析不重要或者很简单的场景没什么意义。
步骤(6)——分析体系结构方法。
QAUT指明了评估的方向，之后就该分析体系结构方法处理高优先级场景的机制了。在这一步骤，评估团队和架构师一道识别在那些和重要场景相关的方法中存在的风险、非风险、敏感点和权衡点。
图7-6 质量属性效用树示例
风险是已经做出的但是在特定的可能情况下出现潜在问题的决策。而非风险正好相反。可能有人会说风险应该受到更多关注，因为它们是将来的问题之源。不过，非风险也一样重要，因为它们暗示了哪些体系结构方法值得保留和坚持。更重要的是，当上下文变化的时候，非风险可能会转变成风险。因此，显式地列出非风险是有用的。
敏感点是指会被某些体系结构元素显著影响的系统模型的属性值。权衡点是系统内与几个敏感点都相关的地方。在步骤(4)和步骤(5)中这些需要的信息应该就准备好了。不过若评估团队感到有什么信息缺失，可以询问架构师。
为了识别风险、非风险、敏感点和权衡点，全体参与者都要完成下述工作：
(1) 识别出试图支持重要场景的体系结构方法并弄清楚这些方法在当前体系结构中是怎么实例化的。
(2) 分析每个方法，考虑其明显的优点和缺点，判断其是否对质量属性带来负面影响。这项工作可以利用询问一系列附属于这种体系结构方法的特定问题来完成。
(3) 在回答这些问题的基础上，识别风险、非风险、敏感点和权衡点并分别记录在文档中。
这一步骤结束，主要阶段Ⅰ就完成了。如果一切顺利，评估团队应该对体系结构有了大致的了解，也清楚了其优缺点。
7.4.6 测试
这一阶段的目的是对到目前为止所作的分析进行测试。会有更多种类的涉众就系统质量需求给出建议。讨论的范围被扩大了，因而会有额外的问题和关注点出现来对系统需求进行补充。
步骤(7)——头脑风暴和设定场景优先级。
在步骤(5)中，场景表示为QAUT，表明项目决策者心目中的体系结构该是什么样子。不过在这一步，评估团队的范围更大了。这里得到更多场景的有效方法是头脑风暴，就像SAAM的场景生成采用的方式。这种环境容易激发创造性的想法和新颖的建议。按性质场景可以分为以下3类：
(1) 用例场景：描述被评估体系结构所在的系统在最终用户的特定操作下如何动作和响应。
(2) 增长式场景：描述被评估体系结构所在的系统怎样支持快速修改和演化的，比如添加构件、平台移植或者与其他系统集成。
(3) 探索式场景：探索被评估体系结构所在系统的极端增长情况。如果说增长式场景试图揭示期望中的和可能的修改，那么探索式场景使评估参与者有机会知道重大变更后系统会发生什么。比如说，性能必须提高5倍，或可用性需要提高一个数量级。根据这类场景，额外的敏感点和权衡点将会暴露，评估测试可基于此。
头脑风暴后，利用投票为场景设置优先级，这和SAAM类似。显然步骤(5)和本步骤生成的场景有显著差异。利用QAUT生成场景是细化的过程，看起来是自顶向下的风格。评估团队和核心项目决策人通过QAUT找到当前体系结构的主要质量驱动。而头脑风暴生成的场景需要几乎所有涉众的合作。测试时，本步骤生成的场景将和QAUT的结果比对。新的场景成为QAUT已有分支的叶子节点，也可能原来就完全没有相应的质量属性分支。评估测试的目的也正是如此，即暴露二者之间的差异，补充未考虑到的场景。
步骤(8)——分析体系结构方法。
这一步使用的方法和技术同步骤(6)，主要差别在于，在此涉众分析的是步骤(7)产生的体系结构方法。如果一切顺利，那么架构师只需要解释是如何用那些被捕获的方法来实现场景的。但是如果存在某些场景不能被直接支持，那么评估团队应该记录在档以便制定修改计划。
7.4.7 报告
步骤(9)——提供评估结果。
这是ATAM一轮迭代的最后一步，包括已收集在原始体系结构文档内的、涉众生成的和分析得到的所有信息都要体现在评估报告中。最重要的内容或者说ATAM的输出，包括文档化的体系结构方法(包括这些方法附属的问题)、带优先级的场景、QAUT、关键质量需求、风险、非风险、敏感点和权衡点。所有涉众一起讨论来解决当前体系结构的问题，尤其是风险和权衡点。
7.5 SAAM方法评估实例
我们在本节介绍一个使用SAAM方法的实例。 我们使用SAAM方法对第3章介绍过的KWIC(在文章中查找和重组关键词)系统中的不同场景进行评估。
1．定义角色和场景
KWIC系统感兴趣的角色有两个，分别是最终用户和开发人员。使用四个场景，其中两个场景经过了不同的最终用户的讨论，即
(1) 修改KWIC程序，使之成为一个增量方式而不是批处理的方式。这个程序版本将能一次接受一个句子，产生一个所有置换的字母列表。
(2) 修改KWIC程序，使之能删除在句子前端的噪音单词(例如前置词、代名词、连词等)。
使用的另外两个场景是经过开发人员讨论，但最终用户不知道的，即
(1) 改变句子的内部表示(例如，压缩和解压缩)。
(2) 改变中间数据结构的内部表示(例如，可直接存储置换后的句子，也可存储转换后的词语的地址)。
2．描述体系结构
第2步就是使用通用的表示对待评估的体系结构进行描述，这种描述是为了使评估过程更容易，使评估人员知道体系结构图中的框或箭头的准确含义。这里对两种体系结构风格进行评估。
1) 共享内存的解决方案
在第一个待评估的体系结构中，有一个全局存储区域，被称做Sentences，用来存储所有输入的句子。其执行的顺序是：输入例程读入句子→存储句子→循环转换例程转换句子→字母例程按字母顺序排列句子→输出。当需要时，主控程序传递控制信息给不同的例程。图7-7描述了这个过程，不同计算构件上的数字代表场景编号，在这一步中可忽略(将在后面用到)。
图7-7 共享内存的解决方案示例
2) 抽象数据类型解决方案
待评估的第2个体系结构使用抽象数据类型(Abstract Data Type，ADT)，如图7-8所示。其中每个功能都隐藏和保护了其内部数据表示，提供专门的存取函数作为唯一的存储、检索和查询数据的方式。ADT Sentences有两个函数，分别是set和getNext，用来增加和检索句子；ADT Shifted Sentences提供了存取函数setup和getNext，分别用来建立句子的循环置换和检索置换后的句子。
图7-8 抽象数据类型解决方案示例
ADT Shifted Sentences使用ADT Sentences的getNext函数来重新存储输入的句子。ADT Alphabetized Sentences提供了一个setup函数和一个i-th函数，setup函数重复调用Shifted Sentences的getNext函数，以检索已经存储的所有行并进行排序，i-th函数根据参数i，从存储队列中返回第i个句子。
3．评估体系结构
既然已经把待评估的体系结构用通用的符号标记了出来，接下来就是评估体系结构满足场景的程度。通过依次考虑每个场景来进行评估。我们所选择的用来评估的所有场景都是间接场景，也就是说，这些场景不能被待评估的体系结构直接执行，因此评估依赖于体系结构的某些修改。
(1) 场景1。第一个场景是从批处理模式转移到增量模式，也就是说，不是把所有句子都输入完后再一次性进行处理，而是一次只处理一个句子。
对共享内存解决方案而言，这需要修改Input例程，使之在读入一个句子后让出控制权，同时，也要修改Master Control主控程序，因为子例程不再是按顺序一次只调用一个，而是一个迭代调用的过程。还要修改Alphabetizer例程，因为使用增量模式后，牵涉到插入排序的问题。我们假设Circular Shift例程一次只处理一个句子，且输出函数只要被调用，就可以输出。
注意，我们所作的假设只是针对共享内存解决方案而言的，一般来说，判断的准确性取决于不同的计算构件的内部工作知识。这也是为什么要期望评估人员中，既有具有计算构件一般知识的人，也有具有特定构件知识的人。
对抽象数据类型解决方案而言，Input函数需要修改，使之在被调用时，一次只输入一行。假设Sentence当存储了输入之后放弃控制权，则无需改变。也假设当Shifted Sentences被调用时，能请求和转换所有可获得的句子，这样，该例程也无须改变。与在共享内存解决方案中一样，Alphabetized Sentences也必须修改。
综上所述，对第一个场景而言，两个待评估的体系结构受到的影响是均等的，因此，我们判定其为中性的。
(2) 场景2。第二个场景要求删除句子中的“噪音”单词。无论在共享内存解决方案还是在抽象数据类型解决方案中，这种需求均可通过修改转换函数很容易地实现(在共享内存体系结构中，修改Circular Shift函数；在抽象数据类型体系结构中，修改Shifted Sentences函数)。因为在两种体系结构中，转换函数都是局部的，且噪音单词的删除不会影响句子的内部表示，所以，对两种体系结构而言，这种修改是等价的。
(3) 场景3。第三个场景要求改变句子的内部表示，例如从一个未压缩的表示转换到压缩的表示。在共享内存体系结构中，所有函数共享一个公用的表示，因此，除了主控函数Master Control外，所有函数都受该场景的影响。在抽象数据类型中，输入句子的内部表示由Sentence提供缓冲。因此，就第三个场景而言，抽象数据类型体系结构比共享内存的体系结构要好。
(4) 场景4。第四个场景要求改变中间数据结构的内部表示(例如，既可直接存储置换后的句子，也可存储转换后的词语的地址)。对于共享内存体系结构，需要修改Circular Shift、Alphabetize和Output三个例程。对于抽象数据类型体系结构，需要修改抽象数据类型中的Shifted Sentences和Alphabetized Sentences。因此，抽象数据类型解决方案所受影响的构件数量要比共享内存体系结构解决方案的少。
(5) 比较分析。图7-7和图7-8都标记了反映每个场景的影响。例如，在图7-7中，Master Control构件中的“1”反映了该构件必须修改以支持场景1。检查待评估体系结构，看其有多少个构件受场景的影响，每个构件最多受多少个场景的影响。从这方面来看，抽象数据类型体系结构要比共享内存体系结构好。在共享内存体系结构和抽象数据类型体系结构中，两者都有4个构件受场景的影响，但是，在共享内存体系结构中，有两个构件(Circular Shift和Alphabetize)受三个场景的影响，而在抽象数据类型体系结构中，所有构件最多只受两个场景的影响。
(6) 评估结果。表7-5概括了评估的结果，其中0表示对该场景而言，两个体系结构不分好坏，在实际的评估中，还需要根据组织的偏好设置场景的优先级。例如，如果功能的增加是风险承担者最关心的问题(就像第2个场景一样)， 那么这两个体系结构是不相上下的，因为在这一点上，它们之间没有什么区别。
但是，如果句子内部表示的修改是风险承担者最关心的问题(就像第3个场景一样)，那么抽象数据类型体系结构显然是要首选的体系结构。
使用SAAM方法评估系统的结果通常容易理解，容易解释，而且和不同组织的需求目标联系在一起。开发人员、维护人员、用户和管理人员会找到对他们关心的问题的直接回答，只要这些问题是以场景的方式提出的。
7.6 本 章 小 结
体系结构评估，是指对系统的某些值得关心的属性进行评价和判断。评估的结果可用于确认潜在的风险，并检查设计阶段所得到的系统需求的质量。体系结构评估可以只针对一个体系结构，也可以针对一组体系结构。在体系结构评估过程中，评估人员所关注的是系统的质量属性。本章首先介绍了几个几乎所有评估方法都普遍关注的质量属性：性能、可靠性、可用性、安全性、可修改性、功能性等，然后从三个方面讨论了体系结构评估的必要性。
从目前已有的软件体系结构评估技术来看，尽管它们采用的评估方式都各不相同，但基本可以归纳为三类主要的评估方式：基于调查问卷或检查表的方式、基于场景的方式和基于度量的方式。最著名的体系结构评估方法均是基于场景的。场景是系统使用或改动的假定情况集合。本章详细介绍了两个最著名的基于场景的评估方法——SAAM 和ATAM。SAAM本质上是一个寻找受场景影响的体系结构元素的方法，而ATAM建立在SAAM基础上，关注对风险、非风险、敏感点和权衡点的识别。
SAAM和ATAM表现了大多数基于场景评估方法的共同特性。它们以场景和体系结构描述作为输入，评估判断当前体系结构(或候选体系结构)能否满足期望质量属性。潜在的缺陷和风险被识别，这是修改工作启动的基础。最后，原始的评估得到的数据被收集起来以备后用，例如用作进一步开发时的提示信息，或者积攒起来作为重用时重要的历史数据。
习 题
1．为什么要评估软件体系结构？从哪些方面评估软件体系结构？
2．软件体系结构评估的主要方法有哪三种？请简单解释每种方法。
3．ATAM评估方法的基本步骤是什么？
4．选择你所熟悉的一个软件系统，给出4～5种质量属性。在该系统中，设计者最为关心哪些质量属性？这些质量属性是如何定义的？需要实现到什么程度？
5．分别使用SAAM方法和ATAM方法，对上题中的系统的体系结构进行分析和评估。
