越来越多的人认识到软件系统体系结构的选择对软件系统开发的成功与否是非常重要的那么，问题只在于软件架构各种风格的各种方法、分层架构方法很多，既是CS也是BS，现在既是AS，也是2层、3层或多层，有各种混合。 自己开发中的这个软件系统，如何评价哪个软件系统架构方法更合适呢？

传统的软件体系结构评估方法按评估形式一般分为三类。

一种是问卷调查法，请了解系统架构的专家学者直接主观评价系统架构。 二是将软件系统的体系结构完全量化，通过几个客观的数值指标来评价体系结构好坏的测量方法。 第三种是场景评价法，即选择重要的系统使用场景(一系列有序使用或修改系统的步骤，即系统相关人员如何使用系统)，根据不同场景中的各框架的表现分别进行评价ATAM和SAAM都是场景评价法，主客观度介于前面两种方法之间。

一、ATTM

CMU/SEI (卡梅伦大学软件工程协会)提出了体系结构权衡分析方法、Architachturetradeoffanalysismethod，简称ATAM。

1、评估目的

ATAM的评估目的是根据系统质量属性和业务需求评估设计决策的结果。 ATAM希望查明体系结构满足特定质量目标的情况，并更清楚地认识到质量目标之间的联系，即如何权衡多个质量目标。

这里列举了体系结构中普遍关注的质量属性。 当然，也有可测试性和易用性。

性能：系统的响应能力，即系统运行特定地点所需的时间。 可用性—系统正常工作的时间百分比。 通常表示两个故障之间的时间长度，或者在发生故障时系统恢复正常速度。 安全性是指阻止未经授权的用户尝试使用或拒绝服务的能力。 可以分为机密性、完整性、不可否认性、控制性。 修正可能性：是指以快速、经济高效的方式变更系统的能力。 包括可维护性、可扩展性、结构重组和可移植性。 保密性和权衡是软件体系结构中的重要决定，不同之处在于保密性的决定只影响一个软件质量属性，但权衡会同时影响多个质量属性，有时会在不同属性之间发生冲突。 例如，选择不同的加密方式会同时影响性能和安全性，因此需要进行权衡。

2、评估参与者

评估小组：该小组是评估的体系结构项目的外部小组，通常由3至5人组成。 这个小组的每个成员都必须扮演很多特定的角色。 他们可能在开发组织内部，也可能在外部。 项目丰富的阳光：开发项目有发言权，有权做一些改变，包括项目管理员、重要客户代表、架构师等。 体系结构相关人员：包括重要的模块开发人员、测试人员和用户等。

3、评估活动和过程

ATAM通过理解体系结构方法来分析体系结构，评价过程分为9个步骤

1- 描述ATAM方法

即评估小组负责人向参加会议的风险承担者介绍ATAM的评估方法，明确接下来要做什么、每个人的作用和任务。

2- 描述业务动机

项目经理从业务的角度介绍系统概况，一般包括业务环境、背景、业务约束条件、技术约束、质量属性需求等内容。

3- 描述体系结构

首席设计师或设计团队详细适当地介绍体系结构。 用于满足技术约束、与系统交互的其他系统、质量属性要求的体系结构方法(功能、模块、流程、硬件)。

4- 确定体系结构方法

由设计者决定体系结构方法，由分析小组捕获，但不进行分析。

5- 生成质量属性效用树

评估小组、设计小组、管理人员和客户代表一起确定系统最重要的质量属性目标，并设定优先级和细分。

6- 分析体系结构方法

7- 讨论分级场景

8- 分析体系结构方法

9- 描述评估结果

二、SAAM

-1010可能已经注意到了，最好是叫AMT的方法。 但是，有点太复杂了，也需要时间。 完全评估需要一两个月。 那么，有更简单、更容易操作的方法吗？ 当然有。 它是一种基于场景的评估方法，最初用于分析体系结构的可修改性，然后用于评估其他质量属性。 比SAAM容易多了。

1、评估目的

验证基本体系结构的前提和原则，并评估体系结构的特定风险。 SAAM指导了体系结构的检查，主要关注需求冲突等潜在问题。 SAAM不仅评估体系结构对特定系统要求的有效性

用能力，也能被用来比较不同的体系结构。

2、评估的参与者

风险承担者、记录人员、软件体系结构设计师。

风险承担者：风险承担者是指那些关心软件架构，个人利益受软件架构好坏影响的人，在项目管理领域也称为项目干系人或涉众。这一些人整体上又可以分为系统的生产者和系统的消费者。生产者包括架构师，开发人员，维护人员，测试人员等；消费者包括客户，最终用户等。

3、评估活动和过程

主要包括如下6个步骤：

1 形成场景2描述体系结构3对场景进行分类和确定优先级4对间接场景进行单个评估5 评估场景的相互作用6形成总体评价

下面分别给大家说明一下。

1.形成场景

指的是风险承担者们集中在一起，集体讨论，提出一个个系统需求场景。记录人员把这些场景记录在册，形成文档的过程。

2.描述体系结构

指的是体现结构设计师，对待评估的体系结构进行适当的描述，包括静态属性和动态特征，可以用自然语言也可以用形式化手段，以让参加评估的所有人员都能充分理解。

这一步骤和上一个形成场景的步骤可以合并在一起，重复进行多次。

3.对场景进行分类和确定优先级

系统可分为直接场景和间接场景，直接场景指的是本体系结构可以直接支持的场景，即不需要对体系结构做任何修改即可直接实现。

另外一种间接场景则是需要对现有体系结构做些更改才能支持的场景。

最后用投票的方法，确定间接场景的重要性优先级，以便大家将有限的时间花在最重要的事情上。

4.对间接场景进行单个评估

就是将选出来的重要场景与体系结构描述对应起来。体系结构设计师具体说明体系结构需要做哪些修改变更才能适用间接场景的要求，并估计这些变更的代价。

最后形成一份全部场景的总结性列表。

列表字段包括：场景编号、场景描述、直接/间接、需要做的更改、更改/新增构建数量、更改工作量估计

5.评估场景的相互作用

当两个或多个间接场景需要修改到同一个构建时，这时场景就在这个构件上出现了相互作用，需要特别评估。

出现这种情况，往往是设计方案中功能分配不合理，或者是设计文档未能充分说明体系结构。

6.形成总体评价

最后，评估人员对场景和场景间的相互作用做一个总体的权衡和评价。通过各个场景权重与分值得出一个总体的评价，从多个体系结构，或者一个体系结构的不同设计方案选择出一个最优的方案。