IT评测·应用市场-qidao123.com技术社区

标题: 《系统架构操持师教程（第2版）》第8章-系统质量属性与架构评估-03-ATAM方 [打印本页]

---

作者: 络腮胡菲菲    时间: 2024-6-11 09:57
标题: 《系统架构操持师教程（第2版）》第8章-系统质量属性与架构评估-03-ATAM方
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）银行体系布局。

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

1）风险和非风险

2）敏感点

这两种体系布局的敏感点：

• 更改体系布局的范围对应用步伐嵌入到系统中的位置数目很敏感
  
• 错误输入的处理对应用步伐中变乱类型的数目很敏感
  

   因为在验证过程中，输入变乱是针对已知变乱进行验证的)。
  

• 系统同等性水平对用于处理流程的控制机制的数目很敏感
  
• 从系统获取所需输出的过程，对组件协调的方式以及相互之间的交互方式非常敏感
  
• 向应用步伐添加新功能的本事，对应用步伐嵌入到系统中的位置数目很敏感。
  

3）权衡点

• 胡佛变乱架构：没有
  
• 银行架构：
  
  
  
  • 应用步伐嵌入到系统中的位置数目
    
         原因：它影响变化性和修改性两个质量属性
     
  
  
  
  • 变化性：更改体系布局的范围
    
  • 修改下：向应用步伐添加新功能的本事
    
     
  

---

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 IT评测·应用市场-qidao123.com技术社区 (https://dis.qidao123.com/)

Powered by Discuz! X3.4