使用体系结构权衡分析法（ATAM）对两种体系结构进行评估

使用体系结构权衡分析法（ATAM）对两种体系结构进行评估

摘要

任何一种软件系统的软件架构都是它的体系结构。 架构决定了系统成功的程度。 因此，找到适当的方法验证任何软件架构以确保整个系统的成功非常重要。 本文使用这种方法之一：体系结构权衡分析方法（ATAM）来评估两种架构。 后者包括Hoover实现的事件架构（第4版）和我们实现的事件架构。 此评估的目标是确定哪个架构能更好地提供系统所需的服务。 本文详细分析了两种体系结构中ATAM的不同阶段。

1.目的

本文的主要目标是在两个为事件系统设计的架构上执行ATAM。 我们希望在评估后收集有价值的信息，以回答以下问题：
?架构是否适合事件系统？
?两种竞争架构中的哪一种最适合这项任务？
在ATAM评估步骤完成后，我们将在第7节中提出这些问题的答案。

2.引言

系统的体系结构指的是系统的组件和这些组件之间的交互。它提供了对系统的有意义的描述。 “架构允许或排除几乎所有系统的质量属性”[1]。这种质量属性的例子包括可修改性，性能，可靠性等等。上面提到的定义让我们提到了关于软件架构评估的这个事实： “如果架构决策决定了系统的质量属性，那么就可以评估架构决策对这些属性的影响”[1]。现在有很多软件架构技术正在使用，但是这个项目只关注体系结构权衡分析方法（ATAM）。这个项目的目标是使用这种方法来评估两种体系结构：Hoover的最新版本的Event体系结构和我们对后者的实现。这两种体系结构有不同的Event框架实现，它提供’事件服务’。这些服务然后被系统中的事件驱动应用程序组件使用。
进行架构评估的主要原因是使用ATAM正式确定在提供上述服务方面哪种架构更好。在对每个架构的ATAM阶段进行全面分析之后，我们将有足够的证据对上述事件系统的更好架构做出明智决策。
本文的结构如下：第三部分介绍了执行软件架构评估的动机。相关的工作部分在第四部分。第五部分简要介绍了主要的ATAM阶段。报告的核心是第六部分，其中ATAM用于评估上述两种体系结构。在第七节中，我们简要讨论前一节的结果，最后的结论在第八节。

3.动机

任何系统的体系结构都直接影响系统的成功。因此，架构越好，系统成功实现其创建目标的可能性就越高。然后在开发过程中尽可能早地验证系统的体系结构，以确保其正确运行。
理想情况下，体系结构评估不应该延迟到体系结构完全确定为止。在系统的早期创建阶段，应该评估架构以确定已经做出的架构决策是否合适，并找出未来决策的可能选项。在这个项目中，正在对两个完全开发的体系结构进行体系结构评估。这不是一个错误的方法，因为评估是一件有用的事情，特别是当给定系统存在竞争架构时。换句话说，在进行架构评估方面迟到比从来没有更好。

4.相关工作

目前有许多软件评估技术。 尽管软件评估方法可能由不同阶段构成，但它们有一个共同的目标，即确定体系结构对其预期系统的适用性。
软件工程研究所开发了三种软件体系结构评估技术：本项目中使用的ATAM，软件体系结构分析方法（SAAM）和中间设计活动评估（ARID）。 尽管这些技术彼此之间有一些相似之处，但每种方法都有一种特有的架构评估方法。 为了节省时间和空间，我们不会停留在任何这些方法上。 我们将严格关注这个项目的ATAM。

5.ATAM的简要描述

本节提供了对ATAM各阶段的排除，不包括所有细节。 下面的第6部分提供了关于正在评估的体系结构的ATAM评估阶段的详细描述。
ATAM根据质量属性要求评估架构决策。 系统中的质量属性对于该系统来说是期望的质量，例如良好的性能，可修改性，安全性等。为了更好地简要介绍ATAM步骤，请参考下图。

请注意，在下一节中，不同ATAM阶段内的步骤是从第一阶段开始递增的。

6.使用ATAM评估这两种架构

阶段1 - 演示（Presentation）

这是使用ATAM评估软件体系结构的初始阶段。 如上图所示，此阶段有三个主要步骤。 在本文中，我们将重点介绍下面的第三个演示步骤。 这些步骤包括以下内容：

第1步：介绍ATAM

这一步涉及ATAM评估过程的描述。在此步骤中，评估负责人向所有相关参与者提供有关ATAM过程的一般信息。领导者解释了评估中使用的分析技术以及评估的预期结果。领导者解决小组成员的任何疑虑，期望或问题。

第2步：介绍业务驱动因素

在这一步中，提到了系统体系结构驱动程序的业务目标。这一步着重于系统的业务视角。它提供了有关系统功能，主要利益相关方，业务目标和系统其他限制的更多信息。
在这一步中，我们将定义被评估系统的主要功能以及涉及的利益相关方。正如引言中所述，本项目中正在评估的体系结构表示应用程序将使用的Event框架。 Event框架的主要功能是处理和处理事件。该任务通过框架中不同现有组件的交互来完成。应用程序组件是利用框架的系统的另一部分。
利益相关者是在被评估的架构中共享任何形式的利益的人。评估这两种架构时考虑的主要利益相关者包括：最终用户，架构师和应用程序开发人员。这三个利益相关者在两个系统中执行不同的重要任务最终用户通过在命令行界面向系统提供输入来使用“成品”。架构师是事件框架的创建者;而应用程序开发人员负责构建使用事件框架的事件驱动的应用程序。所有利益相关者在系统中都有不同的期望和兴趣。

第3步：介绍要评估的体系结构

在这一步中，架构团队描述了要评估的架构。它侧重于体系结构，评估的时间可用性以及所研究体系结构的质量要求。此步骤中的体系结构演示非常重要，因为它会影响分析的质量。本演讲中涉及的一些关键问题是：技术约束，与正在评估的系统交互的其他系统，以及为满足质量属性而实施的架构方法。系统的质量属性是代表系统所需质量的问题。这些属性的例子包括性能，可靠性等。“一个系统的质量属性在很大程度上被其架构所允许或排除”[2]。
以下是两种体系结构的详细介绍：

（1）胡佛(Hoover)的事件架构：

图2显示了Hoover体系结构的简单类图，随后描述了系统及其组件：

胡佛的架构由组成事件框架的组件和利用框架服务的应用程序组成。 框架组件如下所述。
如前所述，框架是一个事件框架。 它的命令是事件和这个事件，它们根据它们的类型进行处理。 因此，一个事件由两个主要部分组成：它的类型和事件需要处理的参数。 为了处理多个事件，系统中存在一个事件队列组件。
事件队列（Event Queue）保存系统中的事件并以先来先服务（FIFO）模式分派它们。 事件队列在任何事件生成任何其他事件时（基于使用此框架的应用程序）特别有用，因为事件需要存储和检索以供将来处理。
该框架的核心组件是事件管理器（Event manager）。 该组件绑定到事件队列和事件组件。 事件管理器维护事件注册表数据结构，并将事件类型注册到与应用程序相关的关联处理程序中。 可能有多个应用程序处理程序可用。 另外，当事件正在执行时，事件管理器将事件绑定到相应的处理程序。 这是可能的，因为事件管理器维护和事件类型注册表。
该框架还有一个Handler组件，它是所有处理程序的基类。 基本处理程序组件包含两个主要处理程序：
? STOP handler - 此处理程序负责系统终止。
? IDLE handler- 此处理程序执行“空闲等待”，直到用户输入输入事件。 它将系统维持在空闲状态，直到有任何输入被提供给系统处理。
应用程序在某些定义的“挂钩”处挂钩到上述框架。 如图2所示，灰色背景阴影区域代表了胡佛架构的框架。 主进程控制事件类型和应用程序的状态。 它也控制着事件管理器。 所有应用程序处理程序都会修改系统的状态（在图2中由应用程序处理程序组件旁边的 * 表示）。但是，只有一个事件管理器控制系统。

（2）“银行”（Banking）事件架构：

图3显示了一个简单的“银行”体系结构类图，其后是对系统及其组件的描述：

“银行”体系结构由组成事件框架的组件和利用框架服务的应用程序组成。 框架组件如下所述。
这个框架与上面描述的Hoover的体系结构类似，但有一些区别。 在这种架构中，即使没有独特的事件组件，底层主题也是一个事件（隐式表示）。 在这种架构中，事件有两个主要部分：类型及其参数。
事件队列（Event Queue）组件通过排队它们并以FIFO模式返回它们来处理事件的维护。 如果没有要返回的事件，则会生成“空闲”事件。
有一个基本的Handler组件，它由三个标准的指定处理程序和应用程序处理程序扩展。 该组件包含以下三个标准指定处理程序：
? START handler - 在启动时初始化系统
? STOP handler - 终止系统。
? IDLE handler - 此处理程序执行“空闲等待”，直到用户输入一个输入事件。 它验证输入事件是否有效。 如果有效，则事件排队，否则会产生另一个空闲事件。 该处理程序将系统保持在空闲状态，直到给系统处理任何输入。
在这个架构中，主模块（Main ）是框架的一部分。 该组件绑定到事件管理器和事件队列。 该模块的基本功能是从事件队列中取出一个事件并将其分派给事件管理器进行处理。 该组件中没有应用程序特定的信息。
在此框架中，应用程序在事件管理器中进行访问。 后者处理绑定事件与事件处理程序的过程。 因此，应用程序被挂接到事件管理器。 应用程序处理程序也链接到此事件管理器，并且此模块中不保留事件注册表存储。 可以有多个可链接到系统的事件和多个链接到从基本处理程序组件派生的事件管理器的应用程序处理程序。 然而在这个框架中只有一个事件队列和一个事件管理器。

阶段2 - 调查和分析

这是使用ATAM技术评估架构的第二阶段。 在这个阶段，我们对评估期间要重点关注的一些重要问题进行彻底调查。 这个阶段被细分为三个步骤。

第4步：确定架构方法

这一步涉及确定能够理解系统关键需求的关键架构方法。 在这一步中，架构团队解释了架构的流程控制，并提供了关于如何以及是否达到关键目标的适当解释。 以下是与正在评估的两种体系结构有关的两种体系结构方法的讨论。

（1）胡佛的架构：

在此体系结构中，系统从闲置处理程序生成的命令提示符处接受输入。输入事件被传递给事件管理器，事件管理器将事件存储在事件队列中。主进程从事件队列中取出事件，并将其分派给事件管理器进行处理。事件管理器然后将事件绑定到其相应的事件处理程序。如果事件未被注册，则事件管理器丢弃该事件并将控制传递给主进程。下一个要处理的事件从事件队列中取出并再次发送给事件管理器。如果没有要处理的事件，则会生成空闲事件，执行空闲等待，直到从系统用户接收到输入为止。如果事件在事件管理器事件注册表中注册，则事件与正确的事件处理程序匹配。该处理程序然后执行该事件，可能导致系统状态的变化。
从质量属性角度来看结构，可以提出几点。从图2中可以清楚的看出框架之外的应用。每个组件都可以单独出来并重新使用。因此，该架构具有高度的可修改性。另外，这些组件相互适当地进行交互并执行其预期的工作，实现功能的质量属性。架构也可以扩展，因为应用程序构建器可以看到明确的钩子。这涉及到变异性的问题。由于处理在命令行界面输入的无效输入，该系统中的可靠性也得到满足。

（2）“银行”活动架构：

在此体系结构中，系统由“开始”事件初始化，该事件在内部生成并处理。从空闲处理程序生成的命令提示符处接收输入。当输入事件输入时，IDLE_Handler检查它的有效性。传递给将事件存储在事件队列中的主模块的有效输入。处理事件时，首先从队列中提取事件并分派给事件管理器进行进一步处理。由于在初始阶段消除了有缺陷的输入，并且事件管理器知道应用程序处理程序，它会将相应的处理程序与事件匹配并执行事件。如果事件队列中没有可处理的事件，则事件队列发送空闲事件。
关于这个架构中提到的质量属性，可以注意几点。这种体系结构中的一个明显缺陷是，事件管理器组件暴露给应用程序，因此不在框架中（图3中灰色区域之外）。因此可以说，这种架构中没有很好地表现出可修改性。这些组件以协调的方式进行交互，即使它们高度相互依赖。由于组件的相互依赖性，在此体系结构中可重用性不太可能。空闲事件的输入活动需要事件，对其进行解析并消除任何有缺陷的输入，从而实现可靠性问题。

第5步：生成质量属性效用树。

在评估的这个阶段，系统的最重要的质量属性目标被确定，确定优先次序和完善。这一步至关重要，因为它将所有利益相关方和评估人员的注意力集中在对体系成功至关重要的体系结构的不同方面。这是通过建立效用树来实现的。
效用树提供了一种使系统目标更加具体和更具体的方法。它还提供了质量属性目标相对于彼此的重要性的比较。因此，效用树表达了系统的整体“良好”。最重要的是，树包含与系统有关的质量属性，以及对利益相关者重要的质量属性要求。这些要求被称为情景。情景是一个说明利益相关者和系统之间的相互作用的陈述。这些情景是质量目标，体系结构将被判断。
此阶段完成后，结果将成为ATAM评估步骤其余部分使用的情景优先列表。它缩小了在架构中探索风险或架构方法的地点的选择范围。因此，这一步在评估过程中是非常宝贵的。
在这个项目中，Event系统有两个相互竞争的体系结构，在这一步中，将会有一个实用程序树代表Event系统的质量目标。这些场景是代表三个利益相关者生成的：最终用户，架构师和应用程序开发人员。如上所述，质量属性需求（场景）在这一步中是非常重要的。经过仔细的思考实验，我们代表利益相关者提出了可能的情景。
情景生成
情景生成是创建效用树的前一个重要步骤。下面的表1显示了与每个利益相关者有关的情景以及它所代表的质量属性的启发。

质量属性效用树生成
效用树包含“效用”作为根节点，质量属性构成效用树的辅助级别。 这些属性位于上面表1的第三列。 在每个质量属性下，都会包含特定的质量属性细化，以提供对方案更精确的描述。 后者形成了实用程序树中的叶节点。 效用树沿着两个维度排列优先顺序：每个场景对系统成功的重要性以及对此场景实现（从架构师的角度来看）所带来的难度程度的估计。 效用树中的优先级基于相对排名：高（H），中（M）和低（L）。 请参阅图4（下一页）了解实用程序树图。（文中并没有附图……)

第6步：分析体系结构方法

这是“调查和分析”阶段的最后一步。在这一步中，我们分析前一步生成的效用树的输出，并进行彻底的调查和分析，找出处理相应质量属性的架构方法。我们根据这些质量属性分析这两种架构，并为它们提供适当的解释。我们还确定每种架构方法的风险，非风险，敏感点和权衡点。
从步骤5的效用树中，提取高优先级场景。例如，请考虑步骤5中效用程序树中的以下两个方案：
（L，M）所有操作都以最快的速度处理（性能）
（H，M）应该处理使用系统中的用户错误（可靠性）
从场景旁边的（L，M）和（H，M）所示的这些场景的优先级确定，决定选择哪个质量属性。在这个例子中，选择第二种方案是因为它对系统的成功和建筑师的中等难度具有高度重要性。第一种情况不被考虑，因为它对系统的重要性不高。从效用树中获得的高优先级属性是：可变性，可靠性，集成性（Conceptual Integrity），功能性和可修改性。质量属性（如性能，可用性，安全性和可移植性）没有被赋予高优先级，因为它们对系统目标不那么重要（如树中所示）。
这一步分为四个主要阶段：
- 调查建筑方法
- 创建分析问题
- 分析问题的答案
- 找出风险，非风险，敏感点，权衡点。

6.1调查体系结构方法

在识别出对系统目标很重要的质量属性后，我们分析两种架构并确定它们如何支持这些质量属性。 我们对体系结构进行了详细的调查，以了解这些质量属性要求是否得到满足。
（a）可变性：
可变性是定义可以如何扩展或修改架构以生成新体系结构的属性。
（1）胡佛架构：
在这个架构中，如图2所示，该框架非常灵活。 Event框架维护一个队列;独立于应用程序的处理程序和事件组件。由于该应用程序未嵌入许多组件，因此该系统具有高度可修改性。例如，如果架构团队希望包含主模块调用队列的新方案，则可以在稍后阶段完成。由于架构清楚地显示了所有组件的交互作用，因此可以重构任何组件，或者可以将任何新组件添加到架构中，而不会影响任何其他组件。因此，胡佛的架构高度支持可变性。
（2）银行体系结构：
如图3所示，架构的组件是高度相互依赖的，并且有许多组件包含特定于应用程序的信息。例如，如果主模块调用应用程序处理程序，则事件管理器会受到影响，因为后者包含特定于应用程序的信息。但是，架构的某些部分支持可变性。例如，如果事件队列更改为绑定到事件管理器，而不是当前体系结构中的主模块，则不会影响其他组件。因此，这种架构在一定程度上支持变化。
另外，这种架构的一个主要缺陷是事件管理器被排除在框架之外，因为它包含与应用程序相关的信息。事件管理器应该是框架内的核心组件。如果这种架构在未来得到扩展，这个缺陷将会造成很大的困难。一般而言，某些组件的更改或新组件的包含很可能会影响其他相关组件。
（b）可靠性：
可靠性是决定系统响应故障的行为以及系统如何随时间运行的特性。
（1）胡佛架构：
在这个架构中，在输入阶段，任何输入都是在没有消除任何’有缺陷’的输入的情况下处理的。传播有缺陷的输入直到事件绑定时间的主要原因是它是一个特定于应用程序的细节。因此，框架保持不变，无论应用程序是否与之相关。然而，最终在事件管理器组件中以适当的方式处理了有缺陷的输入。因此，该体系结构支持可靠性。
（2）银行体系结构：
在此体系结构中，在空闲事件的输入活动中识别有缺陷的输入。因此，在事件存储在队列中之前，将检查类型和参数的有效性（请注意，这是一个特定于应用程序的细节）。尽管这是一个与应用程序相关的活动，但系统在任何有缺陷的输入和可靠性得到满足后都会恢复。但是，如果任何其他应用程序挂钩到框架，则此验证过程必须更改。
（c）集成性（Conceptual Integrity）：
该属性定义了统一各级系统设计的基础主题。架构应该是一致的，在执行架构的所有进程时使用最少的数据和控制机制。
（1）胡佛架构：
在这个架构中，事件在整个系统中以类似的方式处理。无论事件类型如何，主模块都将事件传递给事件管理器，后者将事件绑定到执行该过程的处理程序。在系统中执行任何操作都涉及很少的控制机制，并且后者以有效的方式执行。因此概念完整性得以实现。
（2）银行体系结构：
在这个架构中，所有事件都以类似的方式处理，但所使用的控制机制的数量相当高。在这个体系结构中，事件从事件队列中提取并传递给事件管理器，事件管理器相对于某些特定于应用程序的细节处理事件。处理事件后，事件管理器通过调用应用程序处理程序将该事件传播到其处理程序，处理程序依次处理该事件。虽然类似的方法被用于架构中的所有事件，但是使用的控制机制的数量可以被最小化以实现这个目标。因此，在这个架构中，概念完整性的属性没有得到妥善处理。
（d）功能性：
此属性标识系统中组件之间的交互，以及系统是否执行预期的任务。
（1）胡佛架构：
如前所述，在这个架构中，组件之间展示了适当的相互作用。该体系结构还以有效的方式执行事件处理的预期任务。组件之间的交互是合理和适当的。事件队列保存事件，根据请求分派给事件管理器。另外，事件管理器与应用程序处理程序协调并将事件绑定到相应的处理程序。因此，在这种架构中，功能的属性显然是需要关注的。
（2）银行体系结构：
在这种架构中，组件之间存在适当的交互，系统通常适当地执行预期的任务。尽管在系统的许多组件中都嵌入了特定于应用程序的细节，但组件协调也是合理的。因此，在这种架构中适度地解决了功能问题。
（e）可修改性：
顾名思义，该属性验证系统是否能够以一种快速，经济高效的方式进行修改。它验证了体系结构如何处理对组件所做的更改，以及是否可以将任何不同的应用程序挂接到框架。
（1）胡佛架构：
在此体系结构中，可修改性的程度很高，因为所有框架组件都与应用程序分离。如果要包含任何新的特定于应用程序的组件，该体系结构有能力以经济有效的方式适应这种修改。事件管理器组件维护一个事件类型的注册表，它将每个事件注册到它的处理程序。此注册表的内容不固定，但依赖于使用事件框架的应用程序。这确保了架构中的高度可修改性。
（2）银行体系结构：
在这种架构中，应用程序嵌入在许多组件中。因此，重新使用不同应用程序的框架或添加任何新的应用程序特定组件都会涉及很多困难和修改。因此修改过程可能不是成本有效的。鉴于这些观点，这种架构没有表现出足够的可修改性。

6.2创建分析问题

本步骤的下一个阶段涉及收集上面讨论过的高优先级场景中产生的分析问题。在现实生活中，所有利益相关者都会收集分析问题。在这个项目中，我们只是简单地创建了优先场景中显著的示例问题。分析问题与上面讨论的每种架构方法相关联;并面向重要的质量属性。以下是分析问题列表和正在解决的属性：
?架构的组件可以重复用于未来的项目吗？ （变化性）
?未来可以扩展框架以适应新的应用程序或新组件？ （变化性）
?系统会处理用户提供的任何输入并处理无效输入吗？ （可靠性）
?架构的行为是否一致？ （概念完整）
?是否可以将任何新的应用程序特定功能添加到架构中（可修改性）
?系统能否以短时间和成本效益的方式进行修改？（修改性）
?组件是否正确交互？（功能性）
?体系结构是否正确执行其事件处理任务？ （功能）

6.3分析问题的答案

这一步的第三阶段是根据两种评估架构对上述分析问题提供合理的解释或答案。以下是在每个架构中如何处理这些问题的讨论。
（1）胡佛架构：
?架构的组件可以重复用于未来的项目吗？
如前所述，此体系结构中的每个组件都是相互独立的，并以适当的方式进行协调。例如，无论它链接到哪个组件，事件管理器都会在使用任何注册的事件类型调用时将事件绑定到相应的处理程序。
?未来可以扩展框架以适应新的应用程序或新组件？
是的，这个架构可以很容易地扩展以适应更多的组件和任何给定的应用程序。这是由于上一个问题中给出的原因。
?系统是否处理用户提供的任何输入并处理无效输入？
虽然有缺陷的输入在稍后阶段被识别，但系统会处理用户给出的所有输入并处理任何无效输入。
?架构的行为是否一致？
是的，胡佛的架构在处理所有事件时的行为是一致的。另外，它利用最少数量的控制机制来执行任何给定的任务。
?是否可以将任何新的特定于应用程序的功能添加到架构中？
由于应用程序完全独立于此框架组件
体系结构中，可以将任何新功能添加到架构中，而不会影响其他组件。该应用程序被添加到框架中的’挂钩’，这在这个架构中明确定义。
?系统是否可以在短时间内以具有成本效益的方式进行修改？
是的，因为应用程序没有嵌入到许多组件中，并且在极小的地方与框架链接，所以可以在更短的时间内以经济高效的方式进行修改。
?组件是否正确交互？
正如上述架构方法的讨论中所解释的，此架构中的组件以协调的方式进行交互。
?体系结构是否正确执行其事件处理任务？
胡佛的体系结构提供了所需的结果，因为事件处理的主要任务是通过系统中各组件之间的适当交互来处理的。
（2）银行体系结构：
?架构的组件可以重复用于未来的项目吗？
这些组件可以重用，但会涉及一些重大更改，因为应用程序嵌入了许多组件。但是，像事件队列这样的组件可以被重用。
?未来可以扩展框架以适应新的应用程序或新组件？
使用框架来改变应用程序并不是一件容易的事情，因为必须对框架的主要部分进行重大更改。事件管理器组件在此体系结构中是高度特定于应用程序的，并且如果要添加任何应用程序，则必须对其进行修改。出于同样的原因，添加任何新功能都需要付出很大的努力。
?系统是否处理用户提供的任何输入并处理无效输入？
是的，系统处理系统用户给出的所有输入并丢弃无效的输入事件。
?架构的行为是否一致？
在这种体系结构中，一致性没有充分显示，因为控制权被转移到一系列组件中以执行任何任务。
?是否可以将任何新的特定于应用程序的功能添加到架构中？
即使涉及许多组件，也可以向系统添加任何新功能。
?系统是否可以在短时间内以具有成本效益的方式进行修改？
鉴于该应用程序嵌入到系统中涉及的许多组件中，所以修改需要更多时间，并且可能不具有成本效益。
?组件是否正确交互？
这些组件以适当的方式进行交互（如上面在架构方法讨论中所述）。
?体系结构是否正确执行其事件处理任务？
我们的体系结构提供了所需的结果，因为事件处理的主要任务得到处理，即使系统中还存在其他缺陷。

6.4找出风险，非风险，敏感点，权衡点。

涉及此步骤的最后阶段是确定风险，无风险，敏感点和权衡点。
风险是架构中的一个问题点，后者不支持给定的优先级质量属性。 非风险是体系结构的优势，后者实现特定的优先级质量属性。 敏感点是一个或多个组件的属性，对于实现给定的质量属性至关重要。 如果架构对多个属性敏感，那么该点称为权衡点。

敏感点：
对于这两种体系结构，以下是敏感点：
?更改体系结构的范围对应用程序嵌入到系统中的位置数量很敏感。
?错误输入的处理对应用程序中事件类型的数量很敏感（因为在验证过程中，输入事件是针对已知事件进行验证的）。
?系统一致性水平对用于处理流程的控制机制的数量很敏感。
?从系统获取所需输出的过程对组件协调的方式以及彼此之间的交互方式非常敏感。
?向应用程序添加新功能的能力对应用程序嵌入到系统中的位置数量很敏感。
权衡点：
从敏感点可以清楚地看出，应用程序嵌入系统的地方数量会影响变化性和可修改性质量属性。 因此，这形成了一个权衡点。
基于这一观察，我们发现银行业务体系结构具有上述的权衡点，而胡佛的体系结构则没有。

阶段3 - 测试

第7步：头脑风暴和优先场景

这是ATAM测试阶段的第一步。前者代表利益相关者的利益，用于理解质量属性要求。在效用树生成步骤中，主要结果是从建筑师的角度来理解质量属性。在这一步中，目标是让更大的利益相关者参与其中。该
将头脑风暴情景的优先列表与在步骤5中从树中获得的优先方案进行比较。利益相关者需要头脑风暴三种场景：
? 用例场景 - 在这种情况下，利益相关者就是最终用户。
? 增长情景 - 代表了架构发展的方式
? 探索性场景 - 代表架构中极端的增长形式。
在这一步中执行的活动如下：
? 首先，情景是在利益相关者的大风暴活动之后收集的。
? 场景优先：与相同质量属性有关的所有场景都被合并，利益相关者投票选出他们认为最重要的场景。从[1]中可以看出，每个利益相关者都被分配了一定数量的选票，如下所示：

票数=场景总数的30％

? 投票结束后，投票结果会被记录下来，场景按总票数排序。采取截止线以上的情况，其余不予考虑。
? 将优先头脑风暴情景列表与优先情景进行比较
从步骤5中的效用树中获得。头脑风暴的场景被放置在
在实用程序树中适当的分支。它可能是树中已经存在的场景的副本，或者它可能在新的叶子下，或者可能不适合任何分支。
在这个阶段提及这一点很重要，因为我们正在进行两次ATAM
一个项目中的体系结构，我们只能模拟利益相关者，他们的想法和他们的兴趣。这个阶段有一些步骤，在现实生活中有很多利益相关者，评估团队，建筑师和开发人员，这些步骤更加明智。在这个项目中，我们尽可能地尝试来表示这个过程的不同部分。
我们首先介绍这一步中的头脑风暴情景列表，为我们正在评估的架构中的三个利益相关者。场景列表不需要与步骤5中生成的场景不同，但也可以通过头脑风暴过程生成新场景。下面的表3显示了编号方案的列表，方案的类型以及它所代表的质量属性。

在这一点上，头脑风暴的场景清单已经准备就绪。 下一步是让利益相关者为他们认为重要的情景进行投票。 分配给每个利益相关者的票数定义如下：

票数= 30％ （情景总数）= 0.3 16（到最近的整数）= 5

因此，三个利益相关者每个都有5张投票可供选择。 接下来，我们模仿一个投票活动，每个利益相关者对与他们最感兴趣的情景进行投票。 在这个阶段，我们根据不同的利益相关者进行思考，并对各种情况进行投票。 示例投票活动的结果显示在下面的表4中（所有得到总共0张选票的情况均不包含在此表中）：

第8步：分析架构方法

这是“测试”阶段的最后一步。在这一步中，我们分析上一步中高质量的质量属性。我们找到了处理这些质量属性的架构方法，并检查架构是否支持这些属性。这一步重复“调查和分析”阶段的第6步。唯一的区别在于，在步骤6中，高优先级质量属性来自效用树，而这一步需要高度投票的头脑风暴质量属性。一些来自步骤6的优先级质量属性可能在这里重新发生，而一些新的可能会出现。最后，分析优先方案的风险，非风险，敏感点和权衡点。
从上一步的投票表中，高质量的质量属性是：功能性，可靠性，可修改性，安全性，性能和可变性。由于其中一些质量属性已经在步骤6中讨论过，所以我们只关注新出现的属于安全和性能质量属性的情况。在这一步中，仅根据这两种情况分析两种体系结构。
这一步分为四个主要阶段：
- 调查建筑方法
- 创建分析问题
- 分析问题的答案
- 找出风险，非风险，敏感点，权衡点。

8.1调查建筑方法

（a）安全性：
此属性验证系统是否有能力限制未经授权的访问，以及体系结构是否提供任何数据机密性。
（1）胡佛架构：
在这种架构中，一些组件以适当的方式使用数据封装。例如，只有事件管理器执行事件注册表活动，因此未经授权的组件不能执行此任务，或者操作事件注册表数据结构。由于框架完全独立于特定于应用程序的信息，因此组件的协调确保正确的数据封装，并且信息仅对需要它的组件可见。因此，解决了安全问题。
（2）银行体系结构：
在这种体系结构中，特定于应用程序的信息被嵌入到架构中的许多组件中，因此数据机密性处理不当。因此，框架的结构非常“开放”。但是，在某些情况下，保密性是可以达到的。例如，应用程序处理程序仅由事件管理器调用，并且不能由其他组件访问。这支持一些受限组件的安全性，但不支持整体体系结构。
（b）性能：
该属性使我们能够了解系统的响应性。性能因素通常表示为每单位时间的交易次数或执行一次交易所花费的时间。
（1）胡佛架构：
在此体系结构中，用户界面是命令驱动的，因此整个系统的性能不能以每单位时间的事务数量来衡量。但是，由于执行任何给定流程所涉及的组件都很少，我们可以推断执行一项事务所花费的时间很少。因此，该体系结构解决了性能问题。
（2）银行体系结构：
这种体系结构也是由命令驱动的，并且如果根据处理任何事件所涉及的组件数量来计算性能，则可以说该体系结构中的这个数字更高。因此，这种体系结构中的性能不足。

8.2创建分析问题

以下是利益相关方收集的分析问题清单，并基于高度投票的情景。
?系统是否允许未经授权的访问？ （安全）
?架构是否描绘数据机密性？ （安全）
?架构是否以最快的速度处理任何任务？ （性能）

8.3分析问题的答案

现在我们在这两种体系结构中找到这些分析问题的合理答案。
（1）胡佛架构：
?系统是否允许未经授权的访问？
在组件层面，胡佛的架构中未经授权的访问受到限制。但是，在应用程序级别，如果需要，可以通过修改应用程序组件来限制访问。
?架构是否描绘数据机密性？
如前所述，特定于应用程序的信息并未嵌入组件的许多部分，因此数据得到了很好的保护。
?架构是否以最快的速度处理任何任务？
由于执行任何任务所涉及的组件数量极少，并且每个组件中的处理量在此架构中最小，因此后者以最快的速度执行操作。
（2）银行体系结构：
?系统是否允许未经授权的访问？
在组件级别，某些组件受到限制，而体系结构中的大多数组件都可用于访问未经授权的组件。
?架构是否描绘数据机密性？
考虑到应用程序特定的信息在许多组件中可用，这些信息分散在架构中，因此不存在数据机密性。
?架构是否以最快的速度处理任何任务？
由于涉及事件处理的组件数量很多，因此此架构不能以最快的速度执行操作。

8.4找出风险，无风险，敏感点，权衡点。

风险与无风险：

敏感点：
?数据保密级别对嵌入应用程序的地点数量很敏感。
?执行任务的平均速度对处理任务所涉及的组件数量敏感。
权衡点：
考虑到上述敏感点和步骤6中列出的敏感点，我们得出以下权衡点。
?应用程序嵌入的地点数量
?处理任务所涉及的组件数量
基于这些权衡点，我们可以推断Hoover的架构在框架中没有应用程序特定信息，并且执行任务所涉及的组件数量很少，而在银行架构中，这两个权衡点都不被处理正确。

阶段4 - 报告ATAM

这是ATAM评估的最后阶段，其中提供了评估期间收集的所有信息。 ATAM团队将他们的发现呈现给利益相关者群体。
ATAM团队的主要发现通常包括：
- 一种效用树
- 一组生成的场景
- 一组分析问题
- 一套确定的风险和非风险
- 确定的建筑方法
鉴于通过这份报告我们已经介绍了这些发现，这个阶段是多余的。

7.从ATAM评估观察

在使用ATAM技术评估这两种架构之后，我们发现了许多有趣的结果。 ATAM评估的主要目标是为开发系统确定更好的体系结构。如表2和表6所示，其中包含两种架构的风险和非风险，我们发现Hoover的架构没有任何风险，而银行架构则有三种风险。
同样，第8步（测试阶段）的结果显示，银行架构中存在两个权衡点，而胡佛架构中没有权衡点。
因此，在这个时刻，考虑到从ATAM评估中获得的所有输出，我们有足够的证据从架构角度证明Hoover的架构最适合它所设计的基于事件的系统。另一方面，可以改进银行业务体系结构以更好地满足系统的需求，但讨论如何实现这一点超出了本项目的范围。

8.结束语

这个项目的目标是使用ATAM来评估2个已经开发的架构。 使用ATAM非常有趣，因为评估过程提出了每个体系结构中不一定很明显的关键部分。 尽管“测试”阶段与“调查和分析”阶段几乎完全相同，但确保过程彻底，并且利益相关者的观点受到高度重视。
在现实生活中，由于上述原因，ATAM将成为一种很好的评估技术。 在这个项目中，我们必须考虑系统的三个利益相关者，并进行思考实验以实施一些ATAM步骤。
一般来说，从事这个项目的工作对软件体系结构评估，质量属性要求以及所有利益相关者参与系统评估的重要性有一定的了解。

参考文献：

[1] Paul Clements, Rick Kazman and Mark Klein, “Evaluating Software Architectures: Methods and Case Studies”, SEI Series in Software Engineering.
[2] “Software Architecture Evaluation: A Key to System Success”, http://interactive.sei.cmu.edu
[3] Dr. James Hoover, “Hoover’s Architecture Version 4”.