|
|
|
SAAM方法是最早形成文档并得到广泛使用的软件架构分析方法，最初是用来分析架构的可修改性的，但实践证明，SAAM方法也可用于对许多其他质量属性及系统功能进行快速评估。
|
|
|
|
与ATAM方法相比，SAAM比较简单，这种方法易学易用，进行培训和准备的工作量都比较少。SAAM评估可以分6个步骤进行，在这些步骤进行之前，通常有必要对系统做简要的介绍，包括对架构的业务目标的说明等。
|
|
|
|
（1）形成场景。在形成场景的过程中，要注意全面捕捉系统的主要用途、系统用户类型、系统将来可能的变更、系统在当前及可预见的未来必须满足的质量属性等信息。只有这样，形成的场景才能代表与各种项目干系人相关的任务。
|
|
|
|
（2）描述架构。在这一步，架构设计师应该采用参加评估的所有人员都能够充分理解的形式，对待评估的架构进行适当的描述。这种描述必须要说明系统中的运算和数据构件，也要讲清它们之间的联系。除了要描述这些静态特性外，还要对系统在某段时间内的动态特征做出说明。描述既可采用自然语言，也可采用形式化的手段。
|
|
|
|
（3）对场景进行分类和确定优先级。在SAAM评估中，场景就是对所期望的系统中某个使用情况的简短描述。架构可能直接支持该场景，即这一预计的使用情况不需要对架构做任何修改即可实现，一般可以通过演示现有的架构在执行此场景时的表示来确定。在SAAM评估方法中称这样的场景为直接场景。也就是说，直接场景就是按照现有架构开发出来的系统能够直接实现的场景。与在设计时已经考虑过的需求相对应的直接场景并不会让项目干系人们感到意外，但将增进对架构的理解，促进对诸如性能和可靠性等其他质量属性的研究。
|
|
|
|
（4）对间接场景的单个评估。一旦确定了要考虑的一组场景，就要把这些场景与架构的描述对应起来。对于直接场景而言，架构设计师需要讲清所评估的架构将如何执行这些场景；对于间接场景而言，架构设计师应说明需要对架构做哪些修改才能适应间接场景的要求。
|
|
|
|
（5）评估场景的相互作用。当两个或多个间接场景要求更改架构的同一个构件时，我们就称这些场景在这一组构件上相互作用。
|
|
|
|
（6）形成总体评估。最后，评估人员要对场景和场景之间的交互作一个总体的权衡和评价，这一权衡反映该组织对表现在不同场景中的目标的考虑优先级。根据对系统成功的相对重要性来为每个场景设置一个权值，权值的确定通常要与每个场景所支持的业务目标联系起来。如果是要比较多个架构，或者针对同一架构提出了多个不同的方案，则可通过权值的确定来得出总体评价。权值的设置具有很强的主观性，所以，应该让所有项目干系人共同参与，但也应合理组织，要允许对权值及其基本思想进行公开讨论。
|
|
|
|
上述6个步骤是关于SAAM评估中技术方面的问题，与ATAM评估方法类似，在进行SAAM评估时，也要考虑合作关系、准备工作等问题。需要对评估会议的时间做出安排、确定评估小组的人员组成、确定会议室、邀请各类项目干系人、编制会议日程等，这些工作都是必需的。
|
|
|
