越来越多的人认识到，软件系统架构的选择对于软件系统开发的成败至关重要，那么问题来了，软件架构各种风格各种方法，光分层架构方法就很多，又是CS、又是BS，现在还有AS，又是两层、三层甚至多层的，还有各种混合，自己开发中的这个软件系统，如何评估哪个软件系统架构方法更合适呢？
传统软件架构评估方法按评估形式，一般分为三种：
- 一是调查问卷法，即直接请对系统架构了解的专家学者对系统架构做出主观评估。
- 二是度量法，即将软件系统架构完全量化，通过一些客观的数字指标来评估架构的好坏。
- 三是场景评估法，即挑选出重要的系统使用场景(一系列有序的使用或修改系统的步骤，即系统涉众如何使用系统的 )，根据不同场景中各架构的表现分别作评估，ATAM和SAAM都属于场景评估法，主客观程度介于前面两种方法之间。
一、ATTM
CMU/SEI（卡梅隆大学软件工程协会）提出了一套架构权衡分析方法，Architachture Tradeoff Analysis Method，简称ATAM。
1、评估目的
ATAM的评估目的是依据系统质量属性和商业需求评估设计决策的结果。ATAM希望揭示出架构满足特定质量目标的情况，使我们更清楚地认识到质量目标之间的联系，即如何权衡多个质量目标。
这里先列举一下架构所普遍关注的质量属性，当然还有可测试性和易用性。
性能：指系统的响应能力，即系统执行某个特定事务所需要的时间。
可用性：是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
安全性：是指阻止非授权用户使用的企图或拒绝服务的能力。又可分为机密性、完整性、不可否认性及可控性。
可修改性：是指能够快速地以较高的性价比对系统进行变更的能力。包括可维护性，可扩展性，结构重组和可移植性。
敏感点和权衡点都是在软件架构中所做的关键决策，不同的是，敏感点决策只影响一个软件质量属性，而权衡点则同时影响多个质量属性，有时不同属性间还会互相冲突，比如选择不同的加密方式同时影响性能和安全性，所以需要权衡。
2、评估参与者
- 评估小组：该小组是所评估架构项目外部的小组，通常由3~5人组成。该小组的每个成员都要扮演大量特定的角色。他们可能是开发组织内部的，也可能是外部的。
- 项目决策者：对开发项目具有发言权，并有权进行某些改变，包括项目管理人员、重要的客户代表、架构设计师等。
- 架构涉众：包括关键模块开发人员、测试人员、用户等。
3、评估活动和过程
ATAM通过理解体系结构方法来分析体系结构，评估过程分9个步骤
1- 描述ATAM方法
即评估小组负责人向参加会议的风险承担者介绍ATAM评估方法，让大家清楚接下来要做什么，每个人的角色和任务。
2- 描述业务动机
项目经理从业务角度介绍系统的概况，一般包括业务环境，背景，业务约束条件，技术约束，质量属性需求等内容。
3- 描述体系结构
首席设计师或设计小组对体系结构进行详略适当的介绍。包括技术约束，与本统交互的其他系统，用以满足质量属性要求的体系结构方法（功能，模块，进程，硬件）。
4- 确定体系结构方法
由设计师确定体系结构方法，由分析小组捕获，但不进行分析。
5- 生成质量属性效用树
评估小组，设计小组，管理人员和客户代表一起确定系统最重要的质量属性目标，并对这些目标设置优先级和细化。
6- 分析体系结构方法
7- 讨论分级场景
8- 分析体系结构方法
9- 描述评估结果
二、SAAM
大家可能已经注意到，AMMT这种方法好是好，就是太复杂了一点，耗时也比较长，完整评估下来要一两个月的时间。那有没有比较简单易操作一点的方法呢，当然是有的。那就是SAAM(Scenario-based Architecture Analysis Method)，它也是一种基于场景的评估方法，最早用于分析体系结构的可修改性，后来也用于其他质量属性的评估。相比于SAAM，要简单许多.
1、评估目的
验证基本的体系结构假设和原则，评估体系结构固有的风险。SAAM指导对体系结构的检查，使其主要关注潜在的问题点，如需求冲突。SAAM不仅能够评估体系结构对于特定系统需求的使用能力，也能被用来比较不同的体系结构。
2、评估的参与者
风险承担者、记录人员、软件体系结构设计师。
风险承担者：风险承担者是指那些关心软件架构，个人利益受软件架构好坏影响的人，在项目管理领域也称为项目干系人或涉众。这照些人整体上又可以分为系统的生产者和系统的消费者。生产者包括架构师，开发人员，维护人员，测试人员等；消费者包括客户，最终用户等。
3、评估活动和过程
主要包括如下6个步骤：
1 形成场景
2描述体系结构
3对场景进行分类和确定优先级
4对间接场景进行单个评估
5 评估场景的相互作用
6形成总体评价
下面分别给大家说明一下。
1.形成场景
指的是风险承担者们集中在一起，集体讨论，提出一个个系统需求场景。记录人员把这些场景记录在册，形成文档的过程。
2.描述体系结构
指的是体现结构设计师，对待评估的体系结构进行适当的描述，包括静态属性和动态特征，可以用自然语言也可以用形式化手段，以让参加评估的所有人员都能充分理解。
这一步骤和上一个形成场景的步骤可以合并在一起，重复进行多次。
3.对场景进行分类和确定优先级
系统可分为直接场景和间接场景，直接场景指的是本体系结构可以直接支持的场景，即不需要对体系结构做任何修改即可直接实现。
另外一种间接场景则是需要对现有体系结构做些更改才能支持的场景。
最后用投票的方法，确定间接场景的重要性优先级，以便大家将有限的时间花在最重要的事情上。
4.对间接场景进行单个评估
就是将选出来的重要场景与体系结构描述对应起来。体系结构设计师具体说明体系结构需要做哪些修改变更才能适用间接场景的要求，并估计这些变更的代价。
最后形成一份全部场景的总结性列表。
列表字段包括：场景编号、场景描述、直接/间接、需要做的更改、更改/新增构建数量、更改工作量估计
5.评估场景的相互作用
当两个或多个间接场景需要修改到同一个构建时，这时场景就在这个构件上出现了相互作用，需要特别评估。
出现这种情况，往往是设计方案中功能分配不合理，或者是设计文档未能充分说明体系结构。
6.形成总体评价
最后，评估人员对场景和场景间的相互作用做一个总体的权衡和评价。通过各个场景权重与分值得出一个总体的评价，从多个体系结构，或者一个体系结构的不同设计方案选择出一个最优的方案。
