|
|
|
使用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个其他关键的项目干系人（例如，项目经理、客户经理、市场代表）一起工作，收集信息。对支持分析而言，在大多数情况下，这种信息是不完整的或不适当的，所以，评估小组必须与架构设计师一起协作引导出必须的信息，这种协作通常要花几周的时间。当评估人员觉得已经收集了足够的信息，并已把这些信息记录成文档，则就可以进入第二个阶段了。
|
|
|
