《系统架构设计师教程（第2版）》第8章-系统质量属性与架构评估-03-ATAM方法架构评估实践（上）

最新推荐文章于 2024-04-09 07:00:00 发布

玄德公笔记

最新推荐文章于 2024-04-09 07:00:00 发布

阅读量945

点赞数 19

分类专栏： # 《系统架构设计师教程（第2版）》上册文章标签：系统架构架构系统架构设计师第2版系统质量属性架构评估 ATAM方法架构评估

本文链接：https://blog.csdn.net/xingzuo_1840/article/details/135998561

版权

《系统架构设计师教程（第2版）》上册专栏收录该内容

59 篇文章 14 订阅

订阅专栏

1. 演示 (Presentation)阶段

1.1 介绍ATAM（第1步）

评估负责人：向所有相关参与者提供有关ATAM过程的一般信息
领导者
- 说明评估中使用的分析技术以及评估的预期结果
- 解决小组成员的任何疑虑、期望或问题

1.2 介绍业务驱动因素（第2步）

概述
- 本步骤将定义被评估系统的主要功能以及涉及的利益相关方
- 评估使用的框架：Event框架
Event框架
- 主要功能：处理事件
- 组成：
  - 现有组件：Event框架通过现有组件之间的交互完成事件处理
  - 应用程序组件：
利益相关者
- 最终用户：通过在命令行界面向系统提供输入来使用“成品”
- 架构师：事件框架的创建者
- 应用程序开发人员：负责构建使用事件框架的事件驱动的应用程序

1.3 介绍要评估的体系结构（第3步）

侧重于：体系结构、可用性、体系结构的质量要求
此步骤中的体系结构演示非常重要，因为它会影响分析的质量
涉及的关键问题：
- 技术约束
- 与正在评估的系统交互的其他系统
- 为满足质量属性而实施的架构方法

1.3.2 示例（一）胡佛(Hoover) 事件架构

1）概述

概述：
- 基于事件框架
- 根据事件类型进行不同处理
组成：
- 组成事件框架的组件
- 利用框架服务的应用程序

2）架构类图说明

胡佛事件架构的简单类图（点划线中是胡佛事件框架）：
Event Manager（事件管理器）
- 管理事件队列组件（Qucue）
  - 以先来先服务 (FIFO) 模式进行分派
- 绑定事件队列和事件类型（Type Bindings）
- 维护事件类型注册表（Event Type Registry）
Event（事件）
- 有两个组成部分
  - 类型(Type)
  - 参数 (Args)
- 可关联多个处理程序
  
  事件管理器将事件动态绑定到相应的处理程序中，增加了框架的灵活性。
Handler组件：它是所有处理程序的基类
- 包含两个主要处理程序：
  - STOP handler：负责系统终止
  - IDLE handler：执行“空闲等待”，直到用户输入一个事件
main（主进程）：
- 控制事件类型和应用程序的状态
- 控制着事件管理器
state
- 所有应用程序处理程序都会修改系统的状态（图中用程序组件旁的*表示）

1.3.3 示例（二）银行事件架构

1）概述

组成（与胡佛类似）
- 组成事件框架的组件
- 利用框架服务的应用程序
持定义多个系统事件和多个应用程序处理程序，但只有一个事件队列和一个事件管理器。
和胡佛事件框架的区别：即使没有特有的事件组件，底层主题也可看作是一种事件

2） “银行”体系结构类图

在这里插入图片描述

Event
- 两个主要部分：
  - 类型(Type)
  - 参数 (Args)
事件队列 (Queue) 组件
- 作用：对事件进行排队
- 处理规则：先进先出（FIFO ）模式
- 空闲事件：如果没有要返回的事件，则会生成“空闲”事件
Handler组件
- 包括3个处理程序：
  - START handler：在启动时初始化系统。
  - STOP handler：终止系统。
  - IDLE handler：执行“空闲等待”，直到用户输入一个事件
Main（主程序）
- 作用：从事件队列中取出一个事件，分派给事件管理器处理
Application Handler（应用程序处理器）
- 链接到主程序（这个和胡佛不同）
处理过程：
- 用户输入事件，程序验证输入事件是否有效
  - 有效：则事件排队
  - 无效：则产生另一个空闲事件
- 该处理程序将系统保持在空闲状态，直到系统处理下一个输入事件

2. 调查和分析阶段

目的：对评估期间需要重点关注的关键问题进行彻底调查
这个阶段被细分为后边的3个步骤。

2.1 确定架构方法（第4步）

概述：理解系统关键需求的关键架构方法
- 架构团队解释了架构的流程控制
- 提供了关于如何达成关键目标、是否达到关键目标的适当解释

2.1.1 胡佛的架构

1）架构的流程控制

系统接受输入
输入事件被传递给事件管理器
事件管理器将事件存储在事件队列中
主进程从事件队列中取出事件，并将其分派给事件管理器进行处理
事件管理器将事件绑定到其相应的事件处理程序
- 如果事件未被注册
  - 事件管理器丢弃该事件并将控制传递给主进程
  - 主进程取出下一个要处理的事件，并再次发送给事件管理器
- 如果事件已注册
  - 则事件与对应的事件处理程序匹配
  - 事件的处理可能导致系统状态变化
当处理完所有事件，则会生成空闲事件，直到接收到输入为止

2）分析结果

具有高度的可修改性

原因：应用位于框架之外，每个组件都可以独立出来并重新使用

可扩展性好（什么意思）

原因：应用程序构建器提供了明确的钩子接口

在这里插入图片描述

2.1.2 “银行”活动架构

1）架构的流程控制

系统由开始事件初始化
系统接收输入
IDLE_Handler检查输入的有效性，并将事件传递并存储在事件队列的中

注意：这里区别胡佛，胡佛不会检查输入有效性。

主程序从队列中提取事，分派给事件管理器进一步处理
事件管理器将事件与对应的事件处理程序匹配

注意：因为之前检查了输入有效性，因此这里不必判断是否注册（区别于胡佛）

事件处理程序执行事件
当处理完所有事件，则会生成空闲事件，直到接收到输入为止

2）分析结果

可修改性较差

原因：事件管理器组件暴露给了应用程序（没有在框架中封装）

可重用性较差

原因：组件高度相互依赖

可靠性差

原因：只有消除任何有缺陷的输入，才能保证架构的可靠性。

在这里插入图片描述

2.2 生成质量属性效用树（第5步）

质量效用树：在“2-系统架构评估”一节已做讲解，需要的回看
情景：
- 概念：说明利益相关者和系统之间的相互作用的陈述
- 示例：见“2.2.1 情景生产”中的表格，“场景”字段，即本文的情景
利益相关者：依然是终用户、架构师、应用程序开发人员

2.2.1 情景生成

概念：是创建效用树之前的重要步骤
每个利益相关者有关的情景以及它所代表的质量属性，如下表

2.2.2 质量属性效用树生成

上一节，我们讲过，效用树的结构：
树根—质量属性—质量属性场景(叶子节点)

质量数结构
- 根节点：“效用”
- 质量属性：包含在上标第三列（“质量属性”列）
- 质量属性场景：上表中第二列（“场景”列）
优先级排序
- 依据的两个维度：
  - 每个场景对系统成功的重要性
  - 场景实现的难易程度
- 标识：高 (H)、中 (M) 、低 (L)。
2021年真题中的质量效用树：

2.3 分析架构方法（第6步）

行为：
- 分析效用树，找出处理相应质量属性架构的方法
- 确定种架构方法的风险、非风险、敏感点和权衡点。
其四个主要阶段：

2.3.1 调查架构方法

概述：
- 在识别出对系统目标至关重要的质量属性后
- 分析架构，并确定它们如何支持这些质量属性

1）可变性

注：这些属性的定义本章第一节已经讲过了，可以回去看

示例（一）胡佛架构

高度支持可变性

架构清楚地显示了所有组件的交互作用，因此可以重构、添加任何组件，而不影响任何其他组件

示例（二）银行体系结构

吐槽：第4步“确定架构方法”几乎一模一样的分析，又来一遍，意义何在？

架构在一定程度上支持变化

此处教材分析较乱，包括错误内容。
可修改性较差

原因：事件管理器组件暴露给了应用程序（没有在框架中封装）

2）可靠性

示例（一）胡佛架构

可靠性高

原因：终在在事件管理器组件中处理有缺陷的输入

示例（二）银行体系结构

可靠性差

吐槽：之前第5步中分析过，结果一样，但是原因有差异。

之前的原因：只有消除任何有缺陷的输入，才能保证架构的可靠性
此处给出的原因：事件存储到队列中之前，将检查类型和参数的有效性。其他应用程序挂钩到框架，此验证过程必须更改

3）集成性 (Conceptual Integrity)

第一节专门将质量属性的时候，没有提集成性

概述：该属性定义了统一各级系统设计的基础主题。架构应该是一致的，在执行架构的所有进程时使用最少的数据和控制机制。

胡佛架构

集成性高
- 原因：
  - 事件在整个系统中以类似的方式处理
  - 在系统中执行任何操作都涉及很少的控制机制
  控制机制较少的原因：
  - 无论事件类型如何，主模块都将事件传递给事件管理器
  - 事件管理器将事件绑定到执行该过程的处理程序
  - 很少的控制机制

银行体系结构

集成性低
- 原因：控制机制过多
  
  原因：事件传递给事件管理器后，事件管理器对于特定于应用程序的细节处理事件。之后，事件管理器通过调用应用程序处理程序将该事件传播到其处理程序，处理程序依次处理该事件。

4）功能性

胡佛架构

满足

教材都是重复内容，没有要理解或掌握的内容

银行体系结构

满足
原因：
- 组件之间存在适当的交互
- 系统适当地执行预期的任务
- 尽管在系统的许多组件中都嵌入了特定于应用程序的细节，但组件协调也是合理的

5）可修改性。

胡佛架构

具有高度可修改性

原因：

应用位于框架之外，每个组件都可以独立出来并重新使用
注册表的内容可变，且依赖于使用事件框架的应用程序

银行体系结构

可修改性较差

吐槽：之前第5步中分析过，结果一样，但是原因有差异

之前的原因：事件管理器组件暴露给了应用程序（没有在框架中封装）
此处给出的原因：应用程序嵌入在许多组件中，因此添加和修改应用程序都很困难。

2.3.2 创建分析问题

与讨论的架构方法相关联、面向重要的质量属性

以下是分析问题列表和正在解决的属性：
①架构的组件可以重复用于未来的项目吗?(变化性)
②未来可以扩展框架以适应新的应用程序或新组件吗?(变化性)
③系统会处理用户提供的任何输入并处理无效输入吗?(可靠性)
④架构的行为是否一致?(概念完整)
⑤是否可以将任何新的应用程序特定功能添加到架构中?(可修改性)
⑥系统能否以短时间和成本效益的方式进行修改?(修改性)
⑦组件是否正确交互? (功能性)
⑧体系结构是否正确执行其事件处理任务?(功能)

2.3.3 分析问题的答案

1）胡佛架构。

①架构的组件可以重复用于未来的项目吗?
如前所述，此体系结构中的每个组件都是相互独立的，并以适当的方式进行协调。例如，无论它链接到哪个组件，事件管理器都会在使用任何注册的事件类型调用时，将事件绑定到相应的处理程序。
②未来可以扩展框架以适应新的应用程序或新组件吗?
是的。这个架构可以很容易地扩展以适应更多的组件和任何给定的应用程序。这是由于上一个问题中给出的原因。
③系统是否处理用户提供的任何输入并处理无效输入?
虽然有缺陷的输入在稍后阶段被识别，但系统会处理用户给出的所有输入并处理任何无效输入。
④架构的行为是否一致?
是的。胡佛的架构在处理所有事件时的行为是一致的。另外，它利用最少数量的控制机制来执行任何给定的任务。
⑤是否可以将任何新的特定于应用程序的功能添加到架构中?
由于应用程序完全独立于此框架组件。在这个体系结构中，可以将任何新功能添加到架构中，而不会影响其他组件。该应用程序被添加到框架中的“挂钩”,这在架构中有明确定义。
⑥系统是否可以在短时间内以具有成本效益的方式进行修改?
是的。因为应用程序没有嵌入到许多组件中，并且在极小的地方与框架链接，所以可以在更短的时间内以经济高效的方式进行修改。
⑦组件是否正确交互?
正如上述架构方法的讨论中所解释的，此架构中的组件以协调的方式进行交互。
⑧体系结构是否正确执行其事件处理任务?
胡佛的体系结构提供了所需的结果，因为事件处理的主要任务是通过系统中各组件之间的适当交互来处理的。

2）银行体系结构。

①架构的组件可以重复用于未来的项目吗?
这些组件可以重用，但会涉及一些重大更改，因为应用程序嵌入了许多组件。但是，像事件队列这样的组件可以被重用。
②未来可以扩展框架以适应新的应用程序或新组件吗?
使用框架来改变应用程序并不是一件容易的事情，因为必须对框架的主要部分进行重大更改。事件管理器组件在此体系结构中是高度特定于应用程序的，并且如果要添加任何应用程序，则必须对其进行修改。出于同样的原因，添加任何新功能都需要付出很大的努力。
③系统是否处理用户提供的任何输入并处理无效输入?
是的。系统处理系统用户给出的所有输入，并丢弃无效的输入事件。
④架构的行为是否一致?
在这种体系结构中，一致性没有充分显示，因为控制权被转移到一系列组件中以执行任何任务。
⑤是否可以将任何新的特定于应用程序的功能添加到架构中?
即使涉及许多组件，也可以向系统添加任何新功能。
⑥系统是否可以在短时间内以具有成本效益的方式进行修改?
鉴于该应用程序嵌入到系统中涉及的许多组件中，所以修改需要更多时间，并且可能不具有成本效益优势。
⑦组件是否正确交互?
这些组件以适当的方式进行交互(如上面在架构方法讨论中所述)。
⑧体系结构是否正确执行其事件处理任务?
我们的体系结构提供了所需的结果，因为事件处理的主要任务得到处理，即使系统中还存在其他缺陷。