第7章-软件体系结构评估课件.ppt

1、课课 程程 内内 容容 软件重用与构件技术软件重用与构件技术 软件体系结构概论软件体系结构概论 软件体系结构的风格软件体系结构的风格 软件体系结构描述软件体系结构描述 软件体系结构设计软件体系结构设计 基于体系结构的软件开发过程基于体系结构的软件开发过程 软件体系结构评估软件体系结构评估 WebWeb服务体系结构服务体系结构 特定领域的软件体系结构特定领域的软件体系结构 软件体系结构集成开发环境软件体系结构集成开发环境 体系结构的选择是一个软件系统设计成败的关键，体系结构的选择是一个软件系统设计成败的关键，但是，怎样才能知道为软件系统所选用的体系结但是，怎样才能知道为软件系统所选用的体系结构是

2、否恰当？如何确保按照所选用的体系结构能构是否恰当？如何确保按照所选用的体系结构能顺利地开发出成功的软件产品呢？要回答这些问顺利地开发出成功的软件产品呢？要回答这些问题，需要使用专门的方法对软件体系结构进行评题，需要使用专门的方法对软件体系结构进行评估。估。 体系结构评估可以只针对一个体系结构，也可以体系结构评估可以只针对一个体系结构，也可以针对一组体系结构。针对一组体系结构。在体系结构评估过程中，评在体系结构评估过程中，评估人员所关注的是系统的质量属性，估人员所关注的是系统的质量属性，所有评估方所有评估方法所普遍关注的质量属性有以下几个：可用性、法所普遍关注的质量属性有以下几个：可用性、性能、

3、可修改性、可靠性、安全性、可测试性、性能、可修改性、可靠性、安全性、可测试性、易用性、可重用性、可集成性等。易用性、可重用性、可集成性等。第第7 7章章 软件体系结构评估软件体系结构评估 7.1 7.1 体系结构评估概述体系结构评估概述第第7 7章章 软件体系结构评估软件体系结构评估 7.1 体系结构评估概述体系结构评估概述 评估的必要性评估的必要性（1 1）软件体系结构反映了系统最初始的设计决策，）软件体系结构反映了系统最初始的设计决策，对同样一个问题，在初始阶段纠正所带来的花费对同样一个问题，在初始阶段纠正所带来的花费和在测试或部署阶段纠正导致的开销不在一个数和在测试或部署阶段纠正导致的开

4、销不在一个数量级。在体系结构视图上一个符号改动比后期大量级。在体系结构视图上一个符号改动比后期大规模的代码改动工作量要少得多，这样，巨大的规模的代码改动工作量要少得多，这样，巨大的额外开销就避免了。有了对体系结构的完整描述，额外开销就避免了。有了对体系结构的完整描述，退一步讲即使是部分描述，就能模拟系统运行时退一步讲即使是部分描述，就能模拟系统运行时行为，对一些设计思想进行探讨，并推断体系结行为，对一些设计思想进行探讨，并推断体系结构应用于系统时的潜在影响。而所有这些工作只构应用于系统时的潜在影响。而所有这些工作只不过需要整个项目周期中的几天时间。不过需要整个项目周期中的几天时间。 第第7 7

5、章章 软件体系结构评估软件体系结构评估 7.1 体系结构评估概述体系结构评估概述 评估的必要性评估的必要性（2 2）评估是挖掘隐性需求并将其补充到设计中的最）评估是挖掘隐性需求并将其补充到设计中的最后机会。由于缺乏充分的交流和不能对软件项目透后机会。由于缺乏充分的交流和不能对软件项目透彻理解，许多涉众并不知道自己到底想要什么。在彻理解，许多涉众并不知道自己到底想要什么。在需求获取阶段，他们会列出自认为最重要的几项要需求获取阶段，他们会列出自认为最重要的几项要求。但是评估之后，这些观点可能会变动很大。有求。但是评估之后，这些观点可能会变动很大。有些起初重视的方面可能并不是那么重要，而另一些些起初

6、重视的方面可能并不是那么重要，而另一些本来看上去无关紧要的东西却被发现需要花更多精本来看上去无关紧要的东西却被发现需要花更多精力来处理。体系结构评估清除了涉众的沟通障碍。力来处理。体系结构评估清除了涉众的沟通障碍。其最直接的结果就是得到各方满意的系统蓝图，而其最直接的结果就是得到各方满意的系统蓝图，而这至少意味者项目成功的一半。这至少意味者项目成功的一半。 第第7 7章章 软件体系结构评估软件体系结构评估 7.1 体系结构评估概述体系结构评估概述 评估的必要性评估的必要性（3 3）体系结构是开发过程的中心，它决定了团）体系结构是开发过程的中心，它决定了团队组织，任务分配，配置管理，文档组织，管

7、理队组织，任务分配，配置管理，文档组织，管理策略，还有开发进程安排。不良体系结构往往带策略，还有开发进程安排。不良体系结构往往带来不良的效果，因为它在被使用过程中必须被修来不良的效果，因为它在被使用过程中必须被修改来适应新的考量，或者去弥补那些在开发早期改来适应新的考量，或者去弥补那些在开发早期阶段没考虑到的缺陷，在这些方面进行修改需要阶段没考虑到的缺陷，在这些方面进行修改需要花费大量成本。如果在这些发生之前充分分析一花费大量成本。如果在这些发生之前充分分析一下体系结构就可以部分避免这些问题的发生。下体系结构就可以部分避免这些问题的发生。 第第7 7章章 软件体系结构评估软件体系结构评估 7.

8、2 SA评估的主要方式评估的主要方式 主要的评估方式主要的评估方式 基于调查问卷或检查表的评估方式基于调查问卷或检查表的评估方式 基于场景的评估方式基于场景的评估方式 基于度量的评估方式基于度量的评估方式 第第7 7章章 软件体系结构评估软件体系结构评估 基于调查问卷或检查表的评估方式基于调查问卷或检查表的评估方式(1)(1) CMU/SEICMU/SEI的软件风险评估过程采用了这一方式。的软件风险评估过程采用了这一方式。 调查问卷是一系列可以应用到各种体系结构评调查问卷是一系列可以应用到各种体系结构评估的相关问题，其中有些问题可能涉及到体系结估的相关问题，其中有些问题可能涉及到体系结构的设计

9、决策；有些问题涉及到体系结构的文档，构的设计决策；有些问题涉及到体系结构的文档，有的问题针对体系结构描述本身的细节问题。有的问题针对体系结构描述本身的细节问题。 检查表中包含一系列比调查问卷更细节和具体检查表中包含一系列比调查问卷更细节和具体的问题，它们更趋向于考察某些关心的质量属性。的问题，它们更趋向于考察某些关心的质量属性。7.2 SA评估的主要方式评估的主要方式第第7 7章章 软件体系结构评估软件体系结构评估 基于调查问卷或检查表的评估方式基于调查问卷或检查表的评估方式(2)(2) 这一评估方式比较自由灵活，可评估多种质量属这一评估方式比较自由灵活，可评估多种质量属性，也可以在软件体系结

10、构设计的多个阶段进行。性，也可以在软件体系结构设计的多个阶段进行。但是由于评估的结果很大程度上来自评估人员的主但是由于评估的结果很大程度上来自评估人员的主观推断，因此不同的评估人员可能会产生不同甚至观推断，因此不同的评估人员可能会产生不同甚至截然相反的结果，而且评估人员对领域的熟悉程度、截然相反的结果，而且评估人员对领域的熟悉程度、是否具有丰富的相关经验也成为评估结果是否正确是否具有丰富的相关经验也成为评估结果是否正确的重要因素。的重要因素。 尽管基于调查问卷与检查表的评估方式相对比较尽管基于调查问卷与检查表的评估方式相对比较主观，但由于系统相关的人员的经验和知识是评估主观，但由于系统相关的人

11、员的经验和知识是评估软件体系结构的重要信息来源，因而它仍然是进行软件体系结构的重要信息来源，因而它仍然是进行软件体系结构评估的重要途径之一。软件体系结构评估的重要途径之一。7.2 SA评估的主要方式评估的主要方式第第7 7章章 软件体系结构评估软件体系结构评估 基于场景的评估方式基于场景的评估方式(1) (1) 场景是一系列有序的使用或修改系统的步骤。场景是一系列有序的使用或修改系统的步骤。基于场景的方式由基于场景的方式由SEISEI首先提出并应用在体系结构首先提出并应用在体系结构权衡分析方法（权衡分析方法（ATAMATAM）和软件体系结构分析方法）和软件体系结构分析方法（SAAMSAAM）中

12、。）中。 这种软件体系结构评估方式分析软件体系结构这种软件体系结构评估方式分析软件体系结构对场景也就是对系统的使用或修改活动的支持程对场景也就是对系统的使用或修改活动的支持程度，从而判断该体系结构对这一场景所代表的质度，从而判断该体系结构对这一场景所代表的质量需求的满足程度。例如，用一系列对软件的修量需求的满足程度。例如，用一系列对软件的修改来反映易修改性方面的需求，用一系列攻击性改来反映易修改性方面的需求，用一系列攻击性操作来代表安全性方面的需求等。操作来代表安全性方面的需求等。7.2 SA评估的主要方式评估的主要方式第第7 7章章 软件体系结构评估软件体系结构评估 基于场景的评估方式基于场

13、景的评估方式(2)(2) 这一评估方式考虑到了包括系统的开发人员、这一评估方式考虑到了包括系统的开发人员、维护人员、最终用户、管理人员、测试人员等在维护人员、最终用户、管理人员、测试人员等在内的所有与系统相关的人员对质量的要求。基于内的所有与系统相关的人员对质量的要求。基于场景的评估方式涉及到的场景的评估方式涉及到的基本活动包括基本活动包括确定应用确定应用领域的功能和软件体系结构的结构之间的映射，领域的功能和软件体系结构的结构之间的映射，设计用于体现待评估质量属性的场景以及分析软设计用于体现待评估质量属性的场景以及分析软件体系结构对场景的支持程度。件体系结构对场景的支持程度。 7.2 SA评估

14、的主要方式评估的主要方式 不同的应用系统对同一质量属性的理解可能不同，例不同的应用系统对同一质量属性的理解可能不同，例如，对操作系统来说，可移植性被理解为系统可在不同如，对操作系统来说，可移植性被理解为系统可在不同的硬件平台上运行，而对于普通的应用系统而言，可移的硬件平台上运行，而对于普通的应用系统而言，可移植性往往是指该系统可在不同的操作系统上运行。由于植性往往是指该系统可在不同的操作系统上运行。由于存在这种不一致性，对一个领域适合的场景设计在另一存在这种不一致性，对一个领域适合的场景设计在另一个领域内未必合适，因此个领域内未必合适，因此基于场景的评估方式是特定于基于场景的评估方式是特定于领

15、域的领域的。这一评估方式的实施者一方面需要有丰富的领。这一评估方式的实施者一方面需要有丰富的领域知识以对某一质量需求设计出合理的场景，另一方面，域知识以对某一质量需求设计出合理的场景，另一方面，必须对待评估的软件体系结构有一定的了解以准确判断必须对待评估的软件体系结构有一定的了解以准确判断它是否支持场景描述的一系列活动。它是否支持场景描述的一系列活动。第第7 7章章 软件体系结构评估软件体系结构评估 基于场景的评估方式基于场景的评估方式(3)(3) 7.2 SA评估的主要方式评估的主要方式第第7 7章章 软件体系结构评估软件体系结构评估 基于度量的评估方式基于度量的评估方式(1)(1) 度量是

16、指为软件产品的某一属性所赋予的数值，度量是指为软件产品的某一属性所赋予的数值，如代码行数、方法调用层数、构件个数等。传统如代码行数、方法调用层数、构件个数等。传统的度量研究主要针对代码，但近年来也出现了一的度量研究主要针对代码，但近年来也出现了一些针对高层设计的度量，软件体系结构度量即是些针对高层设计的度量，软件体系结构度量即是其中之一。代码度量和代码质量之间存在着重要其中之一。代码度量和代码质量之间存在着重要的联系，类似地，软件体系结构度量应该也能够的联系，类似地，软件体系结构度量应该也能够作为评判质量的重要的依据。作为评判质量的重要的依据。 7.2 SA评估的主要方式评估的主要方式 赫尔辛

17、基大学提出的基于模式挖掘的面向对赫尔辛基大学提出的基于模式挖掘的面向对象软件体系结构度量技术、象软件体系结构度量技术、KarlskronaKarlskrona和和RonnebyRonneby提出的基于面向对象度量的软件体系结提出的基于面向对象度量的软件体系结构可维护性评估、西弗吉尼亚大学提出的软件构可维护性评估、西弗吉尼亚大学提出的软件体系结构度量方法等都在这方面进行了探索，体系结构度量方法等都在这方面进行了探索，提出了一些可操作的具体方案。我们把这类评提出了一些可操作的具体方案。我们把这类评估方式称作基于度量的评估方式。估方式称作基于度量的评估方式。第第7 7章章 软件体系结构评估软件体系结

18、构评估 基于度量的评估方式基于度量的评估方式(2)(2) 7.2 SA评估的主要方式评估的主要方式第第7 7章章 软件体系结构评估软件体系结构评估 基于度量的评估方式基于度量的评估方式(3) (3) 基于度量的评估技术都涉及三个基本活动：基于度量的评估技术都涉及三个基本活动：首首先需要建立质量属性和度量之间的映射原则，即先需要建立质量属性和度量之间的映射原则，即确定怎样从度量结果推出系统具有什么样的质量确定怎样从度量结果推出系统具有什么样的质量属性；然后从软件体系结构文档中获取度量信息；属性；然后从软件体系结构文档中获取度量信息；最后根据映射原则分析推导出系统的某些质量属最后根据映射原则分析推

19、导出系统的某些质量属性。性。7.2 SA评估的主要方式评估的主要方式 基于度量的评估方式提供更为客观和量化的质基于度量的评估方式提供更为客观和量化的质量评估。这一评估方式需要在软件体系结构的设量评估。这一评估方式需要在软件体系结构的设计基本完成以后才能进行，而且需要评估人员对计基本完成以后才能进行，而且需要评估人员对待评估的体系结构十分了解，否则不能获取准确待评估的体系结构十分了解，否则不能获取准确的度量。自动的软件体系结构度量获取工具能在的度量。自动的软件体系结构度量获取工具能在一定程度上简化评估的难度，例如一定程度上简化评估的难度，例如MAISAMAISA可从文可从文本格式的本格式的UML

20、UML图中抽取面向对象体系结构的度量。图中抽取面向对象体系结构的度量。第第7 7章章 软件体系结构评估软件体系结构评估 基于度量的评估方式基于度量的评估方式(4) (4) 7.2 SA评估的主要方式评估的主要方式第第7 7章章 软件体系结构评估软件体系结构评估 三种评估方式的比较三种评估方式的比较 7.2 SA评估的主要方式评估的主要方式第第7 7章章 软件体系结构评估软件体系结构评估 基本概念基本概念 （1 1） 敏感点和权衡点敏感点和权衡点 敏感点是一个或多个构件（和敏感点是一个或多个构件（和/ /或构件之间的关系）或构件之间的关系）的特性。研究敏感点可使设计人员或分析员明确在的特性。研究

21、敏感点可使设计人员或分析员明确在搞清楚如何实现质量目标时应注意什么。搞清楚如何实现质量目标时应注意什么。 权衡点是影响多个质量属性的特性，是多个质量权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。例如，改变加密级别可能会对安全属性的敏感点。例如，改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以性和性能产生非常重要的影响。提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响提高安全性，但可能要耗费更多的处理时间，影响系统性能。如果某个机密消息的处理有严格的时间系统性能。如果某个机密消息的处理有严格的时间延迟要求，则加密级别可能就会成为一个权衡点。延迟要求，则加

22、密级别可能就会成为一个权衡点。7.2 SA评估的主要方式评估的主要方式第第7 7章章 软件体系结构评估软件体系结构评估 基本概念基本概念 （2 2）风险承担者）风险承担者 系统的体系结构涉及到很多人的利益，这些人系统的体系结构涉及到很多人的利益，这些人都对体系结构施加各种影响，以保证自己的目标都对体系结构施加各种影响，以保证自己的目标能够实现。能够实现。 7.2 SA评估的主要方式评估的主要方式第第7 7章章 软件体系结构评估软件体系结构评估 基本概念基本概念 （3 3）场景）场景 在进行体系结构评估时，一般首先要精确地在进行体系结构评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该

23、体系结得出具体的质量目标，并以之作为判定该体系结构优劣的标准。我们把为得出这些目标而采用的构优劣的标准。我们把为得出这些目标而采用的机制叫做场景。机制叫做场景。场景是从风险承担者的角度对与场景是从风险承担者的角度对与系统的交互的简短描述。系统的交互的简短描述。在体系结构评估中，一在体系结构评估中，一般从般从刺激源刺激源、刺激刺激、环境、制品、响应环境、制品、响应和和响应度响应度量量这六个这六个方面来对场景进行描述。方面来对场景进行描述。7.2 SA评估的主要方式评估的主要方式第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法SAAMSAAM方法是最早形成文档并得

24、到广泛使用的软件方法是最早形成文档并得到广泛使用的软件体系结构分析方法，最初是用来分析体系结构的体系结构分析方法，最初是用来分析体系结构的可修改性的，但实践证明，可修改性的，但实践证明，SAAMSAAM方法也可用于对方法也可用于对许多质量属性（例如可移植性、可扩充性、可集许多质量属性（例如可移植性、可扩充性、可集成性等）及系统功能进行快速评估。成性等）及系统功能进行快速评估。SAAMSAAM比较简单，这种方法易学易用，进行培训和比较简单，这种方法易学易用，进行培训和准备的工作量都比较少。准备的工作量都比较少。第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法SA

25、AMSAAM是一种直观的方法，它试图通过场景来测量是一种直观的方法，它试图通过场景来测量软件的质量，而不是泛泛的不精确的质量属性描软件的质量，而不是泛泛的不精确的质量属性描述。述。SAAMSAAM也比较简单，仅仅考虑场景和体系结构也比较简单，仅仅考虑场景和体系结构的关系，也不涉及太多的步骤和独特的技术。于的关系，也不涉及太多的步骤和独特的技术。于是，它成为体系结构评估初学者的理想入门方法。是，它成为体系结构评估初学者的理想入门方法。SAAMSAAM最初是为了评估体系结构的可修改性而设计，最初是为了评估体系结构的可修改性而设计，不过经过演化和实际应用，在许多其它常见的质不过经过演化和实际应用，在

26、许多其它常见的质量属性评估方面也展现了威力，并成为其它一些量属性评估方面也展现了威力，并成为其它一些评估方法的基础，比如评估方法的基础，比如ATAMATAM。利用预先定义的场。利用预先定义的场景，景，SAAMSAAM可以检查出被评估体系结构的潜在风险，可以检查出被评估体系结构的潜在风险，并对几个候选体系结构进行比较。并对几个候选体系结构进行比较。第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法另外，另外，SAAMSAAM可以为很多涉众进行（可能是项目启可以为很多涉众进行（可能是项目启动后的第一次）讨论提供平台。这样大家就有机动后的第一次）讨论提供平台。这样大家

27、就有机会用人人都懂的语言来说出各自关心的问题，了会用人人都懂的语言来说出各自关心的问题，了解别人所关心的，并看到这些问题又是如何在蓝解别人所关心的，并看到这些问题又是如何在蓝图中处理的。在此过程中，理解上的偏差和不正图中处理的。在此过程中，理解上的偏差和不正确的设计都将被发现。确的设计都将被发现。 下图给出了下图给出了SAAMSAAM评估的步骤，每个阶段能评估的步骤，每个阶段能得到什么，各个阶段的关系如何。得到什么，各个阶段的关系如何。第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法 SAAMSAAM评估的步骤评估的步骤 1 1、形成场景、形成场景2 2、描述

28、体系结构、描述体系结构3 3、对场景进行分类和确定优先级、对场景进行分类和确定优先级4 4、对间接场景进行单个评估、对间接场景进行单个评估5 5、评估场景的相互作用、评估场景的相互作用6 6、形成总体评估、形成总体评估为了开始评估，必须提供一个体系结构描述，该为了开始评估，必须提供一个体系结构描述，该描述可以是所有参与者能接受并理解的任何形式。描述可以是所有参与者能接受并理解的任何形式。根据特定评估的对象和关注点，描述的详细程度根据特定评估的对象和关注点，描述的详细程度和范围可能不同，有时也需要进行更新或补充。和范围可能不同，有时也需要进行更新或补充。多种不同的候选体系结构的描述都可以拿来评估

29、多种不同的候选体系结构的描述都可以拿来评估以便对比和选择。以便对比和选择。 第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法 SAAMSAAM评估的步骤评估的步骤 场景是体系结构描述之外的另一个关键输入。基于场场景是体系结构描述之外的另一个关键输入。基于场景的评估方法的基本要点就是检查当前的体系结构能景的评估方法的基本要点就是检查当前的体系结构能否直接满足期望的质量需求，并在不能满足时看看可否直接满足期望的质量需求，并在不能满足时看看可以怎样改动。我们几乎不可能对质量属性进行精确测以怎样改动。我们几乎不可能对质量属性进行精确测量，可又希望质量属性对评估有意义，

30、所以必须以一量，可又希望质量属性对评估有意义，所以必须以一种更实在的形式来表述它。这就是场景为什么这么重种更实在的形式来表述它。这就是场景为什么这么重要的原因。有些场景可能可以在功能性需求中提取出要的原因。有些场景可能可以在功能性需求中提取出来，不过大多数都是源自涉众的讨论和头脑风暴。当来，不过大多数都是源自涉众的讨论和头脑风暴。当然，待评估的体系结构起码得支持需求说明中的所有然，待评估的体系结构起码得支持需求说明中的所有功能。而功能。而评估过程的关键是搞清楚体系结构是否能在评估过程的关键是搞清楚体系结构是否能在满足需求的情况下拥有良好的质量属性满足需求的情况下拥有良好的质量属性。 第第7 7

31、章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法 SAAMSAAM评估的步骤评估的步骤 SAAMSAAM主要是以评估报告的形式输出。如果是评估主要是以评估报告的形式输出。如果是评估单个体系结构，那么报告的内容将包括该体系结单个体系结构，那么报告的内容将包括该体系结构设计不能满足质量需求的缺陷；多个体系结构构设计不能满足质量需求的缺陷；多个体系结构情况下将报告哪个候选体系结构能最好地满足场情况下将报告哪个候选体系结构能最好地满足场景。由不适当分解或过分复杂导致不良设计也会景。由不适当分解或过分复杂导致不良设计也会在报告中被指出。最后，在报告中被指出。最后，SAAMSAAM

32、可以估计修改导致可以估计修改导致的费用和范围，以避免盲目的修改。的费用和范围，以避免盲目的修改。第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法 SAAMSAAM评估的步骤评估的步骤 除此之外，除此之外，SAAMSAAM还有一些优点。它增强了涉众对还有一些优点。它增强了涉众对体系结构的理解，强制对体系结构更好的编档，体系结构的理解，强制对体系结构更好的编档，澄清系统将来演化最可能的方向。通过涉众广泛澄清系统将来演化最可能的方向。通过涉众广泛的讨论，业务目标的优先级和潜在的场景也得以的讨论，业务目标的优先级和潜在的场景也得以澄清。澄清。 第第7 7章章 软件体系

33、结构评估软件体系结构评估 7.3 SAAM评估方法评估方法 SAAMSAAM评估的步骤评估的步骤 1 1、形成场景、形成场景 在形成场景的过程中，要注意全面捕捉系统的在形成场景的过程中，要注意全面捕捉系统的主要用途、系统用户类型、系统将来可能的变更、主要用途、系统用户类型、系统将来可能的变更、系统在当前及可预见的未来必须满足的质量属性系统在当前及可预见的未来必须满足的质量属性等信息。只有这样，形成的场景才能代表与各种等信息。只有这样，形成的场景才能代表与各种风险承担者相关的任务。风险承担者相关的任务。第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法 SAAMS

34、AAM评估的步骤评估的步骤 形成场景的过程也是集中讨论的过程。集体讨论形成场景的过程也是集中讨论的过程。集体讨论能够使风险承担者在一个友好的氛围中提出一个能够使风险承担者在一个友好的氛围中提出一个个场景，这些场景反映了他们的需求，也体现了个场景，这些场景反映了他们的需求，也体现了他们对体系结构将如何实现他们的需求的认识。他们对体系结构将如何实现他们的需求的认识。某一个场景可能只反映一个风险承担者的需求，某一个场景可能只反映一个风险承担者的需求，也可能反映多个风险承担者的需求。例如，对于也可能反映多个风险承担者的需求。例如，对于某个变更，开发人员关心的是实现该变更的难度某个变更，开发人员关心的是

35、实现该变更的难度和对性能的影响，而系统管理员则关心此变更对和对性能的影响，而系统管理员则关心此变更对体系结构的可集成性的影响。在评估过程中，随体系结构的可集成性的影响。在评估过程中，随着场景的不断提出，记录人员要把它们都记录在着场景的不断提出，记录人员要把它们都记录在册，形成文档，供所有参加评估的人员查阅。册，形成文档，供所有参加评估的人员查阅。第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法 SAAMSAAM评估的步骤评估的步骤 提出和收集场景的过程经常要重复两次或多提出和收集场景的过程经常要重复两次或多次。形成场景和描述体系结构的工作是相关次。形成场景和描

36、述体系结构的工作是相关联的，这两个步骤可重复进行，是一个迭代联的，这两个步骤可重复进行，是一个迭代的过程。的过程。 第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法 SAAMSAAM评估的步骤评估的步骤 2 2、描述体系结构、描述体系结构 在这一步，体系结构设计师应该采用参加评估在这一步，体系结构设计师应该采用参加评估的所有人员都能充分理解的形式，对待评估的体的所有人员都能充分理解的形式，对待评估的体系结构进行适当的描述。这种描述必须要说明系系结构进行适当的描述。这种描述必须要说明系统中的运算和数据构件，也要讲清它们之间的联统中的运算和数据构件，也要讲清它们之

37、间的联系。除了要描述这些静态特性外，还要对系统在系。除了要描述这些静态特性外，还要对系统在某段时间内的动态特征做出说明。描述既可采用某段时间内的动态特征做出说明。描述既可采用自然语言，也可采用形式化的手段。自然语言，也可采用形式化的手段。第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法 SAAMSAAM评估的步骤评估的步骤 场景的形成和对体系结构的描述通常是相互促场景的形成和对体系结构的描述通常是相互促进的。一方面，对体系结构的描述使风险承担进的。一方面，对体系结构的描述使风险承担者考虑针对所评估的体系结构的某些具体特征者考虑针对所评估的体系结构的某些具体特征

38、的场景；另一方面，场景也反映了对体系结构的场景；另一方面，场景也反映了对体系结构的需求，因此必须体现在体系结构的描述中。的需求，因此必须体现在体系结构的描述中。 第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法 SAAMSAAM评估的步骤评估的步骤 3 3、对场景进行分类和确定优先级、对场景进行分类和确定优先级 在在SAAMSAAM评估中，场景就是对所期望的系统中某评估中，场景就是对所期望的系统中某个使用情况的简短描述。体系结构可能直接支持个使用情况的简短描述。体系结构可能直接支持该场景，即这一预计的使用情况不需要对体系结该场景，即这一预计的使用情况不需要对体

39、系结构做任何修改即可实现。这一般可以通过演示现构做任何修改即可实现。这一般可以通过演示现有的体系结构在执行此场景时的表示来确定。在有的体系结构在执行此场景时的表示来确定。在SAAMSAAM评估方法中称这样的场景为评估方法中称这样的场景为直接场景直接场景。即直。即直接场景是按照现有体系结构开发出来的系统能够接场景是按照现有体系结构开发出来的系统能够直接实现的场景。直接实现的场景。第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法 SAAMSAAM评估的步骤评估的步骤 如果所评估的体系结构不能直接支持某一场景，如果所评估的体系结构不能直接支持某一场景，就必须对所描述

40、的体系结构做些修改。可能要就必须对所描述的体系结构做些修改。可能要对执行某一功能的一个或多个构件进行更改、对执行某一功能的一个或多个构件进行更改、为实现某一功能而增加一个构件，为已有构件为实现某一功能而增加一个构件，为已有构件建立某种新的联系、删除某个构件或某种联系、建立某种新的联系、删除某个构件或某种联系、更改某一接口，或者是以上多种情况的综合，更改某一接口，或者是以上多种情况的综合，这样的场景叫做这样的场景叫做间接场景间接场景。第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法 SAAMSAAM评估的步骤评估的步骤 间接场景就是需要对现有体系结构做些修改才间

41、接场景就是需要对现有体系结构做些修改才能支持的场景，间接场景对于衡量体系结构对能支持的场景，间接场景对于衡量体系结构对系统在演化过程中将出现的变更的适应情况十系统在演化过程中将出现的变更的适应情况十分关键。通过各种间接场景对体系结构的影响，分关键。通过各种间接场景对体系结构的影响，可以确定出体系结构在相关系统的生命周期内可以确定出体系结构在相关系统的生命周期内对不断演化的使用的适应情况。对不断演化的使用的适应情况。第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法 SAAMSAAM评估的步骤评估的步骤 评估人员通过对场景设置优先级，可保证在评估评估人员通过对场景

42、设置优先级，可保证在评估的优先时间内考虑最重要的场景。这里的的优先时间内考虑最重要的场景。这里的“重要重要”完全是由风险承担者及其所关心的问题确定的。完全是由风险承担者及其所关心的问题确定的。风险承担者们通过投票表达出所关心的问题。每风险承担者们通过投票表达出所关心的问题。每个参加评估的风险承担者都将拿到固定数量的选个参加评估的风险承担者都将拿到固定数量的选票，向每个风险承担者发放的选票数一般是待评票，向每个风险承担者发放的选票数一般是待评估场景数量的估场景数量的30%30%，他们可以用自己认为合适的，他们可以用自己认为合适的方式投票，可把这些票全部投给某一个场景，或方式投票，可把这些票全部投

43、给某一个场景，或者每个场景投者每个场景投2-32-3张票，还可以一个场景一张票张票，还可以一个场景一张票等。等。第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法 SAAMSAAM评估的步骤评估的步骤 只要每个人投票总数不超过手中的选票总数，他只要每个人投票总数不超过手中的选票总数，他可以为任何场景投任何数目的票。然后按照得到可以为任何场景投任何数目的票。然后按照得到选票数目的顺序对所有场景进行排序，并根据具选票数目的顺序对所有场景进行排序，并根据具体情况选择一定数目的排序靠前的场景。有时候，体情况选择一定数目的排序靠前的场景。有时候，排序后的列表可能会有一个泾

44、渭分明的分界，一排序后的列表可能会有一个泾渭分明的分界，一边是得到很多票的场景，另一边得票数很少（如边是得到很多票的场景，另一边得票数很少（如图图7-27-2所示），那么直接选择得票多的场景即可。所示），那么直接选择得票多的场景即可。第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法 SAAMSAAM评估的步骤评估的步骤 第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法 SAAMSAAM评估的步骤评估的步骤 其它时候，可以计算一下评估多少场景比较适合，其它时候，可以计算一下评估多少场景比较适合，或者估计一下评估时间内能完成多少。

45、典型的比或者估计一下评估时间内能完成多少。典型的比如说，一整天可以评估完如说，一整天可以评估完8 8个场景而你计划两天个场景而你计划两天的时间进行场景的单个评估，那么选择的时间进行场景的单个评估，那么选择1515或或1616个个比较合适。要注意的是即使根据预先定好的规则比较合适。要注意的是即使根据预先定好的规则某些场景是应该放弃的，但如果它们的提出者仍某些场景是应该放弃的，但如果它们的提出者仍然坚持而其它人又不反对的话，那么也可以添加然坚持而其它人又不反对的话，那么也可以添加到到“关键关键”列表中。列表中。 第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法 S

46、AAMSAAM评估的步骤评估的步骤 4 4、对间接场景进行单个评估、对间接场景进行单个评估 一旦确定了要考虑的一组场景，就要把这些场一旦确定了要考虑的一组场景，就要把这些场景与体系结构的描述对应起来。对于直接场景而景与体系结构的描述对应起来。对于直接场景而言，体系结构设计师需要讲清所评估的体系结构言，体系结构设计师需要讲清所评估的体系结构将如何执行这些场景；对于间接场景而言，体系将如何执行这些场景；对于间接场景而言，体系结构设计师应说明需要对体系结构做哪些修改才结构设计师应说明需要对体系结构做哪些修改才能适应间接场景的要求。能适应间接场景的要求。第第7 7章章 软件体系结构评估软件体系结构评估

47、 7.3 SAAM评估方法评估方法 SAAMSAAM评估的步骤评估的步骤 对每一个间接场景，必须列出为支持该场景而需对每一个间接场景，必须列出为支持该场景而需要对体系结构所做的改动，并估计出这些变更的要对体系结构所做的改动，并估计出这些变更的代价。对体系结构的更改意味着引入某个新构件代价。对体系结构的更改意味着引入某个新构件或新联系，或者需要对已有构件或联系的描述进或新联系，或者需要对已有构件或联系的描述进行修改。在这一步快结束时，应该给出全部场景行修改。在这一步快结束时，应该给出全部场景的总结性列表。对每个间接场景，都应描述出要的总结性列表。对每个间接场景，都应描述出要求做的更改，并由记录人

48、员记录下来，形成文档。求做的更改，并由记录人员记录下来，形成文档。在描述中应包括对完全实现每个更改的代价的估在描述中应包括对完全实现每个更改的代价的估计（包括测试和调试的时间）。计（包括测试和调试的时间）。( (表表7-2)7-2)第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法 SAAMSAAM评估的步骤评估的步骤 第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法 SAAMSAAM评估的步骤评估的步骤 表表7-2 SAAM间接场景单个评估表间接场景单个评估表场景编场景编号号场景描述场景描述所需改动所需改动需改动元需改动元素数

49、素数估计工作估计工作量量F4允许同其它系统交换数据数据序列化模块，数据交换接口212个工作日F8加入上下文相关的帮助上下文相关的UI控制，帮助文档230个工作日F9支持多个DBMS数据管理抽象13个工作日 5 5、评估场景的相互作用、评估场景的相互作用 当两个或多个间接场景要求更改体系结构的同当两个或多个间接场景要求更改体系结构的同一个构件时，我们就称这些场景在这一组构件上一个构件时，我们就称这些场景在这一组构件上相互作用。那么，为什么要强调场景的相互作用相互作用。那么，为什么要强调场景的相互作用呢？呢？ 首先，场景的相互作用暴露了设计方案中的功首先，场景的相互作用暴露了设计方案中的功能分配。

50、场景相互作用的多少与结构复杂性、耦能分配。场景相互作用的多少与结构复杂性、耦合度、内聚性等有关。合度、内聚性等有关。第第7 7章章 软件体系结构评估软件体系结构评估 7.3 SAAM评估方法评估方法 SAAMSAAM评估的步骤评估的步骤 例如，如果场景例如，如果场景1 1和场景和场景2 2是属于不同类别的，是属于不同类别的，并且都影响构件并且都影响构件X X，那末构件，那末构件X X在结构划分方面在结构划分方面可能存在着耦合问题。这时场景可能存在着耦合问题。这时场景1 1和场景和场景2 2的交的交互体现出系统结构没有很好地划分构件。另一互体现出系统结构没有很好地划分构件。另一方面，如果场景方面