5.4 架构分析

除了审查、单元测试、验收和回归测试外，架构分析是一种重要的技术，在软件架构师的日常工作中为其提供支持。它能够评估软件架构的质量。除了使用合适的质量模型和定义功能流程外，架构分析最重要的前提条件之一是需求分析和架构目标分析。 架构分析的结果可以根据特定的质量标准进行评估，如健壮性、可用性或安全性。这些标准必须在需求规范的早期阶段进行定义和优先排序。

5.4.1 ATAM法

ATAM 代表架构权衡分析方法。它是一种对架构进行定性评估的有条理的方法，并有助于为计划中的系统选择合适的架构。ATAM 是由卡内基梅隆大学的软件工程研究所（SEI）开发的。 ATAM 是架构评估领域的领先方法。 • ATAM的优势 o 明确的质量要求 o 改进架构文档 o 一个文档化的架构决策的依据 o 早期识别的风险 o 改善相关方之间的沟通 • ATAM的前提条件 o 系统架构师(或技术联系人) o 架构文档 o 负责客户功能的联系人 评估程序 ATAM将软件架构的评估分为四个阶段(参见图5-2)。

图5-2评估流程 架构评估的第一步涉及客户或委托方确定该流程的相关利益相关者。这通常是一个小团队，至少包括（客户）管理层和项目管理层。

在定义评估目标之前，启动阶段包括向利益相关者简要介绍评估方法。所有参与者都应该清楚，目的是确定风险（和非风险）并概述适当的措施。客户提出用于评估的系统的业务目标。

然后，负责的架构师应该简要介绍系统的架构。此介绍包括系统的完整上下文（包括所有相邻系统）、顶级构建块以及最重要用例或变更场景的运行时视图。

利益相关者随后应编制所有重要的质量要求，并在质量树中按层次组织它们。为使评估团队能够开始工作，他们还需要描述最重要质量目标的场景。

在对这些场景进行分析之后，决策应分为四个方面（见图 5 - 3）: • 风险 风险是架构的元素，根据情况的发展，可能危及业务目标的实现, 并导致其他问题。 • 敏感点 在架构的“敏感点”，即使是微小的变化也可能产生广泛的影响。这些是架构中实现质量标准的关键组件。 • 妥协 权衡指定设计决策是否(或如何)相互影响多个质量特性。 • 非风险 哪些场景在所有情况下都能实现(即无风险)? 风险被分类为表明它们可能如何危及业务目标的主题。

图5-3ATAM(来源:软件工程研究所) 创建质量树 质量树对系统特定或产品特定的质量要求进行分层细化（见图 5 - 4）。主要标准位于树的顶部，而更具体的要求则在底部。质量树的“叶子”是场景（见下面的“场景”部分），它们以尽可能具体和详细的方式描述单个特征。

图5-4The层次树的质量 主要利益相关者根据各自的业务收益（见图 5 - 5）对特征及其场景进行优先级排序，架构师也根据其技术复杂性进行优先级排序。这在实际评估期间为架构师提供了具有优先级的场景。

图中的5-5Prioritization质量树 对质量特性 1 的评估通常由架构师与一个小组一起按照确定的优先级顺序进行。 这个过程涉及回答一系列不同的问题： • 为了实现一个场景，做出了哪些架构决策? • 哪种架构方法支持实现该场景? • 达成了哪些妥协? • 是否影响了其他质量特性或架构目标？ • 存在哪些风险? • 哪些分析、原型或评估支持此决策？ 完成评估后，你应该对以下内容有一个很好的了解: • 关于定义的场景和特定架构目标的架构质量 • 与实现最重要场景相关的风险 • 消除风险的潜在措施 • 可以无风险实现的场景 场景 在 ATAM 环境中，质量特性通过场景来描述（基于场景的架构评估）。这些场景描述了系统在特定情况下的反应，它们表征了利益相关者与系统的交互，并且它们能够评估实现这些质量特性所涉及的风险。它们用于精确指定项目相关方对特定质量特性的理解 - 例如，“可靠性”对所有相关人员实际意味着什么。 场景类型 场景类型包括: • 应用场景。这些描述了系统在运行时对特定刺激做出的反应。它们包括用于描述效率和/或性能的场景。 • 变更场景描述了在系统或其直接环境发生变化的情况下会发生什么——例如，如果实现了一个附加的功能。 • 压力或限制场景描述了系统在极端情况下的反应, 例如，电源故障。 场景的元素 场景通常由以下主要元素组成（引自 [HS11]。原始列表来自 [BCK03]）： • 触发器是由于触发利益相关者与系统之间的特定交互而发生的特定事件 - 例如，当用户调用函数或系统组件发生故障时。 • 源描述了触发器的来源。 • 环境描述了触发器发生时系统的状态。 • 还有一个受触发器影响的系统工件。 • 系统会提供一个响应，作为对触发的反应。 • 响应措施是一种用于测量/评估系统响应质量的评估模型。 图5 - 6提供了场景组件元素的概述。

图5-6场景组成要素 示例场景 以下是一些使用场景来详细说明质量要求的示例。 • 应用场景 o 在系统正常运行期间，对价格查询的响应必须在 5 秒内显示给最终用户。如果系统在高负载下运行（例如，年终业务），响应可能最多需要 15 秒，但在这种情况下，必须事先向用户显示相应的消息。 o 首次使用系统时，没有先验知识的用户应能够在 15 分钟内找到并使用所需的功能。 o 如果在输入字段中输入无效或不正确的数据，系统必须输出相应的消息文本并继续正常工作。 • 变更场景 o 新功能的开发必须在30个工时内完成。 o 必须能够在少于 30 个人工日对新的浏览器版本的支持进行编程和测试。 • 压力或极限场景 o 在正常运行时出现CPU中断的情况下，备用系统必须在15分钟内可用。 o 当数据库系统发生故障时，系统将按照规定的性能和容量继续运行。 表5-2列出了一些性能场景的示例元素。

表5-2性能场景元素示例

可靠性场景的部分要素示例如表5-3所示。

表5-3可靠性场景元素示例