|
|
|
从目前已有的软件架构评估技术来看，基本可以归纳为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种方式进行简单的比较。
|
|
|
|
|
|
|
