|
|
|
架构评估可以只针对一个架构，也可以针对一组架构。在架构评估过程中，评估人员所关注的是系统的质量属性。有关质量属性，请参考11.6.3节。
|
|
|
|
为了后面讨论的需要，我们先介绍两个概念：敏感点（sensitivity point）和权衡点（tradeoff point）。敏感点和权衡点是关键的架构决策。敏感点是一个或多个构件（和／或构件之间的关系）的特性。研究敏感点可使架构设计师或系统分析师明确在搞清楚如何实现质量目标时应注意什么。权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。例如，改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响系统性能。如果某个机密消息的处理有严格的时间延迟要求，则加密级别可能就会成为一个权衡点。
|
|
|
|
|
|
从目前已有的软件架构评估技术来看，基本可以归纳为3类主要的评估方式：基于调查问卷或检查表的方式、基于场景的方式和基于度量的方式。
|
|
|
|
|
|
CMU/SEI（Carnegie Mellon University/Software Engineering Institute，卡耐基梅隆大学的软件工程研究所）的软件风险评估过程采用了这一方式。调查问卷是一系列可以应用到各种架构评估的相关问题，其中有些问题可能涉及到架构的设计决策；有些问题涉及架构的文档，例如架构的表示用的是何种ADL（Architecture Description Language，架构描述语言）；有的问题针对架构描述本身的细节问题，如系统的核心功能是否与界面分开。检查表中也包含一系列比调查问卷更细节和具体的问题，它们更趋向于考察某些关心的质量属性。例如，对实时信息系统的性能进行考察时，很可能问到系统是否反复多次地将同样的数据写入磁盘等。
|
|
|
|
这一评估方式比较自由灵活，可评估多种质量属性，也可以在软件架构设计的多个阶段进行。但是由于评估的结果很大程度上来自评估人员的主观推断，因此不同的评估人员可能会产生不同甚至截然相反的结果，而且评估人员对领域的熟悉程度、是否具有丰富的相关经验也成为评估结果是否正确的重要因素。尽管基于调查问卷与检查表的评估方式相对比较主观，但由于系统相关的人员的经验和知识是评估软件架构的重要信息来源，因而它仍然是进行软件架构评估的重要途径之一。
|
|
|
|
|
|
场景是一系列有序的使用或修改系统的步骤。基于场景的方式主要应用在架构权衡分析方法（Architecture Tradeoff Analysis Method，ATAM）和软件架构分析方法（Software Architecture Analysis Method，SAAM）中。在架构评估中，一般采用刺激（stimulus）、环境（environment）和响应（response）3方面来对场景进行描述。刺激是场景中解释或描述项目干系人怎样引发与系统的交互部分，环境描述的是刺激发生时的情况，响应是指系统是如何通过架构对刺激作出反应的。
|
|
|
|
基于场景的方式分析软件架构对场景的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。例如，用一系列对软件的修改来反映易修改性方面的需求，用一系列攻击性操作来代表安全性方面的需求等。这一评估方式考虑到了所有与系统相关的人员对质量的要求，涉及到的基本活动包括：确定应用领域的功能和软件架构的结构之间的映射，设计用于体现待评估质量属性的场景，以及分析软件架构对场景的支持程度。
|
|
|
|
不同的系统对同一质量属性的理解可能不同，例如，对操作系统来说，可移植性被理解为系统可在不同的硬件平台上运行，而对于普通的应用系统而言，可移植性往往是指该系统可在不同的操作系统上运行。由于存在这种不一致性，对一个领域适合的场景设计在另一个领域内未必合适，因此基于场景的评估方式是特定于领域的。这一评估方式的实施者一方面需要有丰富的领域知识，以对某一质量需求设计出合理的场景；另一方面，必须对待评估的软件架构有一定的了解，以准确判断它是否支持场景描述的一系列活动。
|
|
|
|
|
|
度量是指为软件产品的某一属性所赋予的数值，如代码行数、方法调用层数、构件个数等。传统的度量研究主要针对代码，但近年来也出现了一些针对高层设计的度量，软件架构度量即是其中之一。基于度量的评估技术都涉及3个基本活动：首先，需要建立质量属性和度量之间的映射原则，即确定怎样从度量结果推出系统具有什么样的质量属性；然后，从软件架构文档中获取度量信息；最后，根据映射原则分析推导出系统的某些质量属性。
|
|
|
|
基于度量的评估方式提供更为客观和量化的质量评估，需要在软件架构的设计基本完成以后才能进行，而且需要评估人员对评估的架构十分了解，否则不能获取准确的度量。
|
|
|
|
|
|
经过对3类主要的软件架构评估方式的分析，我们用下表从通用性、评估者对架构的了解程度、评估实施阶段、评估方式的客观程度等方面对这3种方式进行简单的比较。
|
|
|
|
|
|
|
|
|
|
使用ATAM方法对软件架构进行评估的目标，是理解架构关于软件的质量属性需求决策的结果。ATAM方法不但揭示了架构如何满足特定的质量目标（如性能和可修改性），而且还提供了这些质量目标是如何交互的，即它们之间是如何权衡的。这些设计决策很重要，一直会影响到整个软件生命周期，并且在软件实现后很难以修改这些决策。
|
|
|
|
|
|
|
|
（1）描述ATAM方法。评估小组负责人向参加会议的项目干系人介绍ATAM评估方法。在这一步，要解释每个人将要参与的过程，并预留出解答疑问的时间，设置好其他活动的环境和预期结果。关键是要使每个人都知道要收集哪些信息，如何描述这些信息，将要向谁报告等。
|
|
|
|
（2）描述业务动机。参加评估的所有人员必须理解待评估的系统，在这一步，项目经理要从业务角度介绍系统的概况。
|
|
|
|
（3）描述架构。首席架构设计师或设计小组要对架构进行详略适当的介绍。这一步很重要，将直接影响到可能要做的分析及分析的质量。在进行更详细的分析之前，评估小组通常需要收集和记录一些额外的架构信息。
|
|
|
|
（4）确定架构方法。ATAM评估方法主要通过理解架构方法来分析架构，在这一步，由架构设计师确定架构方法，由分析小组捕获，但不进行分析。
|
|
|
|
（5）生成质量属性效用树。评估小组、设计小组、管理人员和客户代表一起确定系统最重要的质量属性目标，并对这些质量目标设置优先级和细化。这一步很关键，它对以后的分析工作起指导作用。
|
|
|
|
（6）分析架构方法。一旦有了效用树的结果，评估小组可以对实现重要质量属性的架构方法进行考察。这是通过文档化这些架构决策和确定它们的风险、敏感点和权衡点等来实现的。在这一步中，评估小组要对每一种架构方法都考察足够的信息，完成与该方法有关的质量属性的初步分析。这一步的主要结果是一个架构方法或风格的列表，与之相关的一些问题，以及架构设计师对这些问题的回答。通常产生一个风险列表、敏感点和权衡点列表。
|
|
|
|
（7）讨论和对场景分级。场景在驱动ATAM测试阶段起主导作用，实践证明，当有很多项目干系人参与ATAM评估时，生成一组场景可为讨论提供极大的方便。
|
|
|
|
（8）分析架构方法。在收集并分析了场景之后，架构设计师就可把最高级别的场景映射到所描述的架构中，并对相关的架构如何有助于该场景的实现做出解释。在这一步中，评估小组要重复第（6）步中的工作，把新得到的最高优先级场景与尚未得到的架构工作产品对应起来。在第（7）步中，如果未产生任何在以前的分析步骤中都没有发现的高优先级场景，则进入第（8）步，就是测试步骤。
|
|
|
|
（9）描述评估结果。最后，要把ATAM分析中所得到的各种信息进行归纳，并反馈给项目干系人。这种描述一般要采用辅以幻灯片的形式，但也可以在ATAM评估结束之后，提交更完整的书面报告。在描述过程中，评估负责人要介绍ATAM评估的各个步骤，以及各步骤中得到的各种信息，包括业务环境、驱动需求、约束条件和架构等。最重要的是要介绍ATAM评估的结果。
|
|
|
|
：我们可以修改这9个步骤的顺序，以满足架构信息的特殊需求。也就是说，虽然这9个步骤按编号排列，但并不总是一个瀑布过程，评估人员可在这9个步骤中跳转或进行迭代。
|
|
|
|
|
|
ATAM方法的各个步骤是随着时间的推移而展开的，可大致分为两个阶段。第一个阶段以架构为中心，重点是获取架构信息并进行分析；第二个阶段以项目干系人为中心，重点是获取项目干系人的观点，验证第一个阶段的结果。
|
|
|
|
之所以要分为两个阶段，是因为评估人员要在第一个阶段收集信息。在整个ATAM评估过程中，评估小组中的部分人（通常是1~3人）要与架构设计师、1或2个其他关键的项目干系人（例如，项目经理、客户经理、市场代表）一起工作，收集信息。对支持分析而言，在大多数情况下，这种信息是不完整的或不适当的，所以，评估小组必须与架构设计师一起协作引导出必须的信息，这种协作通常要花几周的时间。当评估人员觉得已经收集了足够的信息，并已把这些信息记录成文档，则就可以进入第二个阶段了。
|
|
|
|
|
|
SAAM方法是最早形成文档并得到广泛使用的软件架构分析方法，最初是用来分析架构的可修改性的，但实践证明，SAAM方法也可用于对许多其他质量属性及系统功能进行快速评估。
|
|
|
|
与ATAM方法相比，SAAM比较简单，这种方法易学易用，进行培训和准备的工作量都比较少。SAAM评估可以分6个步骤进行，在这些步骤进行之前，通常有必要对系统做简要的介绍，包括对架构的业务目标的说明等。
|
|
|
|
（1）形成场景。在形成场景的过程中，要注意全面捕捉系统的主要用途、系统用户类型、系统将来可能的变更、系统在当前及可预见的未来必须满足的质量属性等信息。只有这样，形成的场景才能代表与各种项目干系人相关的任务。
|
|
|
|
（2）描述架构。在这一步，架构设计师应该采用参加评估的所有人员都能够充分理解的形式，对待评估的架构进行适当的描述。这种描述必须要说明系统中的运算和数据构件，也要讲清它们之间的联系。除了要描述这些静态特性外，还要对系统在某段时间内的动态特征做出说明。描述既可采用自然语言，也可采用形式化的手段。
|
|
|
|
（3）对场景进行分类和确定优先级。在SAAM评估中，场景就是对所期望的系统中某个使用情况的简短描述。架构可能直接支持该场景，即这一预计的使用情况不需要对架构做任何修改即可实现，一般可以通过演示现有的架构在执行此场景时的表示来确定。在SAAM评估方法中称这样的场景为直接场景。也就是说，直接场景就是按照现有架构开发出来的系统能够直接实现的场景。与在设计时已经考虑过的需求相对应的直接场景并不会让项目干系人们感到意外，但将增进对架构的理解，促进对诸如性能和可靠性等其他质量属性的研究。
|
|
|
|
（4）对间接场景的单个评估。一旦确定了要考虑的一组场景，就要把这些场景与架构的描述对应起来。对于直接场景而言，架构设计师需要讲清所评估的架构将如何执行这些场景；对于间接场景而言，架构设计师应说明需要对架构做哪些修改才能适应间接场景的要求。
|
|
|
|
（5）评估场景的相互作用。当两个或多个间接场景要求更改架构的同一个构件时，我们就称这些场景在这一组构件上相互作用。
|
|
|
|
（6）形成总体评估。最后，评估人员要对场景和场景之间的交互作一个总体的权衡和评价，这一权衡反映该组织对表现在不同场景中的目标的考虑优先级。根据对系统成功的相对重要性来为每个场景设置一个权值，权值的确定通常要与每个场景所支持的业务目标联系起来。如果是要比较多个架构，或者针对同一架构提出了多个不同的方案，则可通过权值的确定来得出总体评价。权值的设置具有很强的主观性，所以，应该让所有项目干系人共同参与，但也应合理组织，要允许对权值及其基本思想进行公开讨论。
|
|
|
|
上述6个步骤是关于SAAM评估中技术方面的问题，与ATAM评估方法类似，在进行SAAM评估时，也要考虑合作关系、准备工作等问题。需要对评估会议的时间做出安排、确定评估小组的人员组成、确定会议室、邀请各类项目干系人、编制会议日程等，这些工作都是必需的。
|
|
|
