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

论文题目：Evaluation of two architectures Using the Architecture Tradeoff Analysis Method (ATAM)
作者：Mildred N. Ambe Frederick Vizeacoumar {mildred, fred}@cs.ualberta.ca
仅供参考，如有错误欢迎指正。

摘要

任何一种软件系统的软件架构都是它的体系结构。 架构决定了系统成功的程度。 因此，找到适当的方法验证任何软件架构以确保整个系统的成功非常重要。 本文使用这种方法之一：体系结构权衡分析方法（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 - 此处理程序负责系统终止。