第八章 系统质量属性与架构评估

• 软件系统属性包括功能属性和质量属性，软件架构重点关注的是质量属性
• 架构的基本需求是在满足功能属性的前提下，关注软件系统质量属性。
• 在确定软件系统架构，精确描述质量属性场景后，就需要i对系统架构进行评估。软件系统架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。它也可以灵活地运用于软件架构评审等工作

8.1 软件系统质量属性

8.1.1 质量属性概念

• 软件系统的质量是软件系统于明确地和隐含地定义的需求相一致的程度。
• 软件系统质量是软件与明确地叙述的功能和性能需求文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度
• 从管理角度对软件系统质量进行度量，可将影响软件质量的主要因素划分为6中维度特性
  • 功能性、可靠性、易用性、效率、维护性与可移植性
    • 功能性包括：适合性、准确性、互操作性、依从性、安全性；
    • 可靠性包括：容错性、易恢复性、成熟性；
    • 易用性包括：易学性、易理解性、易操作性；
    • 效率包括：资源特性和时间特性
    • 维护性包括：可测试性、可修改行、稳定性和易分析性；
    • 可移植性包括：适应性、易安装性、一致性和可替换性
• 软件系统质量属性是一个系统的可测量或者可测试的属性，用来描述系统满足利益相关者需求的程度。基于软件系统的生命周期，划分为开发期质量属性和运行期质量属性2部分
  • 1.开发期质量属性
    • （1）易理解性：
      • 指设计被开发人员理解的难易程度
    • （2）可扩展性：
      • 软件因适应新需求或需求变化而增加新功能的能力，也成为灵活性
    • （3）可重用性：
      • 指重用软件系统或某一部分的难易程度
    • （4）可测试性：
      • 对软件测试以证明其满足需求规范的难易程度
    • （5）可维护性：
      • 当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度。
    • （6）可移植性：
      • 将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度
  • 2.运行期质量属性
    • （1）性能
      • 性能是指软件系统及时提供相应服务的能力，如速度、吞吐量和容量的要求
    • （2）安全性
      • 指软件系统同时兼容向合法用户提供服务，以及阻止非授权使用能力
    • （3）可伸缩性
      • 指当用户数和数据量增加时，软件系统维持高服务质量的能力，如通过增加服务器来提高能力
    • （4）互操作性
      • 指本软件系统与其他系统交换数据和相互调用服务的难易程度
    • （5）可靠性
      • 软件系统在一定时间内持续无故障运行的能力
    • （6）可用性
      • 指系统在一定时间正常工作的时间所占的比例。可用性会收到系统错误、恶意攻击、高负载等问题的影响
    • （7）鲁棒性
      • 是指软件系统在非正常情况（如用户进行了非法操作、相关的软硬件系统发生了故障）下仍能够正常运行的能力，也称健壮性或容错性。

8.1.2 面向架构评估的质量属性

• 1.性能
  • 性能是指系统的响应能力，即要经过多长时间才能对某个时间做出响应，或者某段时间内系统所能处理的时间的个数。常用单位时间内所处理事务的数量或系统完成某个事务处理所需的时间来对性能进行定量表示。
• 2.可靠性
  • 可靠性是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。通常用来衡量在规定的条件和时间内，软件完成规定功能的能力。通常用平均失效等待时间和平时失效间隔时间来衡量。可靠性分为2个方面
    • （1）容错
      • 容错的目的是错误发生时确保系统正确的行为，并进行内部“修复”。
    • （2）健壮性
      • 保护应用程序不受错误使用和错误输入的影响，在发生意外错误事件时确保应用系统处于预先定义好的状态。保证软件按照某种预先定义好方式终止执行。
      • 采用冗余机制，或集成监控构件和异常处理提高系统的可靠性
• 3.可用性
  • 可用性时系统能够正常运行时间比例。经常用两次故障之间的时间或出现故障时系统能过够恢复正常的速度来表示
• 4.安全性
  • 安全性是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。按安全威胁类型分类
    • （1）机密性
      • 机密性保证信息不泄露给未授权的用户、实体或过程
    • （2）完整性
      • 完整性保证信息的完整和准确，防止信息被非法修改
    • （3）不可否认性
      • 不可否认性指信息交换的双方不能否认其在交换过程中发送信息或接收信息的行为
    • （4）可控性
      • 可控性保证对信息的传播及内容具有控制的能力，防止为非法者所用。
• 5.可修改性
  • 可修改性是指能够快速地以较高的性价比对系统进行变更的能力。包括以下4方面
    • （1）可维护性
      • 主要提现在问题的修复上，在错误发生后修复软件系统。可维护性好的软件架构往往能做局部的修改并能对其他构建的负面影响最小化
    • （2）可扩展性
      • 使用新特性来扩展软件系统，以及使用改进版本方式来替换构件并删除不需要或不必要的特性和构件。软件系统需要松散耦合的构件。
    • （3）结构重组
      • 处理的重新组织软件系统的构件及构件间的关系，如通过将构件移动到一个不同的子系统而改变它的位置。理想情况下允许开发人员在不影响实现的主体部分的情况下灵活地配置构件
    • （4）可移植性
      • 可移植性使软件系统适用于多种硬件平台、用户界面、操作系统、编程语言和编译器。可移植性使系统能够在不同计算环境下运行的能力
      • 如果移植到新的系统需要适当更改，则该可移植性就是一种特殊的可修改性
• 6.功能性
  • 功能性是系统完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构建的额相互协作
• 7.可变性
  • 可变性是指架构经扩充或变更而成为新架构的能力。要将某个架构作为一系列相关产品的基础时，可变性时很重要的
• 8.互操作性
  • 作为系统组成部分的软件不是独立存在的，通常与其他系统或自身环境相互作用。
  • 为了支持互操作性，软件架构必须要为外部可视的功能特性和数据结构提供精心设计的软件入口
  • 程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题。

8.1.3 质量属性场景描述

• 为了精确描述软件系统的质量属性，通常采用质量属性场景作为描述质量属性的手段。
• 质量属性场景是一种面向特定质量属性的需求，由6部分组成
  • （1）刺激源
    • 这个某个生成该刺激的实体（人、计算机或者其他任何刺激器）
  • （2）刺激
    • 该刺激时当刺激达到系统时需要考虑的条件
  • （3）环境
    • 该刺激在某些条件内发生。当刺激发生时，系统可能处于过载、运行或其他情况
  • （4）制品
    • 某个制品被激励。可能是整个系统，也可能是系统的一部分
  • （5）响应
    • 该响应式在激励达到后所才取得行动
  • （ 6）响应度量
    • 当响应发生时，应当能够以某种方式对其进行度量，以需求进行测试
• 质量属性场景关注6类质量属性
  • （1）可用性质量场景属性
    • 关注得方面包括故障发生的频率、出现故障时会发生什么情况、允许系统有多长时非正常运行、什么时候可以安全地出现故障、如何防止故障的发生以及发生故障时要求进行哪种通知
    • 
  • （2）可修改性质量场景属性
    • 主要关注系统在改变功能、质量属性时需要付出的成本和难度，可能发生在系统设计、编译、构建、运行等多种情况和环境的场景
    • 
  • （3）性能质量场景属性
    • 关注系统的响应速度，可以通过效率，响应时间、吞吐量、负载来客观评价性能的好坏
    • 
  • （4）可测试性质量场景属性
    • 主要关注系统测试过程中的效率，发现系统缺陷或故障的难易程度等
    • 
  • （5）易用性质场景属性
    • 关注用户在使用系统时的容易程度，包括系统的学习曲线、完成操作的效率、对系统使用过程的满意程度等
    • 
  • （6）安全性质量场景属性
    • 关注系统在安全性方面的要素，衡量系统在向合法用户提供服务的同时，阻止非授权用户使用的能力
    • 

8.2 系统架构评估

• 系统架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。它利用数据或逻辑分析技术，针对系统的一致性、正确性、质量属性、规划结果等不同方面，提供描述性、预测性和指令性的分析结果
• 3大重要的架构评估方法：SAAM，ATAM和CBAM
• 系统架构评估的方法3大类
  • （1）基于调查问卷或检查表的方式
    • 该方法的关键是设计好问卷或检查表，充分利用系统相关人员的经验和知识，获得对架构的评估。缺点是很大程度上依赖于评估人员的主观判断
  • （2）基于场景的方式
    • 它是通过分析软件架构对场景（也就是对系统的使用或修改活动）的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度
  • （3）基于度量的方式
    • 它是建立在软件架构度量的基础上的，涉及3个基本活动，首先要建立质量属性和度量之间的映射原则，然后从软件架构文档中获取度量信息，最后根据映射原则分析推导出系统的质量属性。

8.2.1系统架构评估中的重要概念

• （1）敏感点（sensitivity point）和权衡点（tradeoff point）
  • 敏感点和权衡点时关键的架构决策。
  • 敏感点时一个或多个构件或构件之间的关系的特性，研究敏感点可使设计人员或分析员明确在搞清楚如何实现质量目标时应该注意什么
  • 权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。
  • 如改变加密级别可能会对安全性和性能产生非常重要的影响，提高加密级别可以提高安全性，但需要耗费更多的处理时间影响系统性能。如果某个机密的消息的处理有严格的时间延迟要求，则加密击级别可能就成为一个权衡点
• （2）风险承担者或者称为利益相关人
  • 系统的架构涉及很多人的利益，这些人都对架构施加各种影响，以保证自己的目标能够实现
  • 
  • 
• （3）场景
  • 架构评估时，首先要精确地得出具体的质量目标，用以判断该架构优劣的标准。为得出这些目标而采用的机制称之为场景。场景时从风险承担者的角度对于系统交互的简短描述。
  • 在架构评估中，一般采用刺激、环境和响应三方面对场景进行描述

8.2.2 系统架构评估方法

• 1.SAAM 方法 （重点）非功能质量属性架构分析
  • SAAM是一种非功能质量属性的架构分析方法，可用于比较不同软件体系架构，分析系统架构的可修改性，也可用于其他质量属性如可移植性、可扩充性
  • （1）特定目标
    • SAAM的目标是对描述应用程序属性的文档，验证基本的架构假设和原则。
    • 有利于评估架构固有的风险，SAAM指导对架构的检查，使其主要关注潜在的问题点，如需求冲突，或仅从某一参与者观点出发得到的不全面的系统设计
    • SAAM不仅能够评估架构对于特定系统需求的使用能力，也能被用来比较不同的架构
  • （2）评估技术
    • SAAM所使用的评估技术是场景技术，场景代表了描述架构属性的基础，描述了各种系统必须支持的活动和可能存在的状态变化
  • （3）质量属性
    • 基本特点是把任何形式的质量属性都具体化为场景，但可修改性是SAAM分析的主要质量属性
  • （4）风险承担者
    • SAAM协调不同参与者之间感兴趣的共同方面，作为后勤决策的基础，达成对架构的共识
  • （5）架构描述
    • SAAM用于架构的最后版本，但早于详细设计。架构的描述形式应当被所有参与者理解。
    • 功能、结构和分配被定义为描述架构的3个主要方面
  • （6）方法活动
    • SAAM主要输入是问题描述、需求声明和架构描述
    • 
    • SAAM分析评估架构的过程包括5个步骤：场景开发、架构描述、单个场景评估、场景交互和综合体评估
    • 用一种易于理解的、合乎语法规则的架构描述软件架构，提现系统的计算构件、数据构件以及构件之间的关系（数据和控制）
    • 对场景（直接场景、间接场景）生产一个关于特定架构的场景描述列表。通过对场景交互的分析，能得出系统中所有场景对系统构件所产生影响的列表。最后对场景和场景间的交互做一个总体的权衡和评价
  • （7）已有知识库的重用：SAAM不考虑这个问题
  • （8）方法验证：SAAM是一种成熟的方法，已被应用众多系统中，包括空中交通管制、嵌入式音频系统、修改控制系统、上下文查找关键词系统等。
• 2.ATAM方法（重点） 架构权衡分析方法
  • ATAM方法：架构权衡分析方法是在SAAM的基础上发展起来的，主要针对性能、实用性、安全性、和可修改性，在系统开发之前，对这些质量属性进行评价和折中
  • （1）特定目标
    • ATAM的目标是在考虑多个相互影响的质量属性的情况下，从原则上提供一种理解软件架构的能力的方法。
    • 对于特定的软件架构，在系统开发之前，可用使用ATAM方法确定多个质量属性之间的必要性
  • （2）质量属性
    • ATAM方法分析多个相互竞争的质量属性。开始时考虑的是系统的可修改性、安全性、性能和可用性。
  • （3）风险承担者
    • 在场景、需求收集相关活动中。ATAM方法需要所有系统相关人员的参与
  • （4）架构描述
    • 架构空间受到历史遗留系统、互操作性和以前失败的项目约束。架构描述基于5种基本机构来表示是由典型的4+1视图派生而来的。（逻辑、进程、开发、物理+场景）其中逻辑视图被分为功能结构和代码结构，它们之间适当的映射可用完整地描述一个架构。
    • ATAM方法被用于架构设计中，或被另一组分析人员用于检查最终版本的架构。
  • （5）评估技术
    • 可用把ATAM视为一个框架，该框架依赖于质量属性，可以使用不同的分析技术。
    • 它集成了多种优秀的单一理论模型，每种都能够高效、实用地处理属性。
    • 该方法实用了场景技术，从不同的架构角度，有3种不同类型的场景
      • 用例，包括对系统典型的实用、引出信息
      • 增长场景，用于涵盖那些对它的系统的修改
      • 探测场景，用于涵盖那些可能会对系统造成过载的的极端修改
    • ATAM还实用定性的启发式分析方法，在对一个质量属性构造了一个精确分析模型时要进行分析，定性的启发式分析方法就是这种分析的粗粒度版本
  • （6）方法的活动
    • ATAM被分为4个主要的活动领域（或阶段）
      • 1.场景和需求收集
      • 2.体系结构视图和场景实现
      • 3.属性模型构造和分析
      • 4.折中
    • 属性分析是相互依赖的，每个属性都会涉及其他属性。获取属性关联的方法有两种：
      • 使用敏感度分析发现折中点
      • 通过检查假设
    • 在架构涉及中，ATAM提供了迭代的该井。除了通常从场景派生而来的需求，还有很多对行为模式和执行环境的假设。
    • 由于属性之间存在折中，每个假设都要被检查、验证和询问
    • 在完成所有这些操作后，把分析的结果和需求进行比较：如果系统预期的行为大多接近于需求，设计者就可以继续进行下一步更为详细的设计和实现
  • （7）领域知识的可重用性
    • 领域知识库通过基于属性的架构风格维护。
    • ABAS有助于从架构风格的概念转向于基于特定质量属性模型的推理能力
    • 获取一组基于属性的架构风格的目标在于要把架构设计变得更为惯例化和更可预测，并得到一个基于属性的架构分析的标准问题集合，是设计和分析之间的联系更紧密
  • （8）方法验证：
    • 架构分析的5个方向
      • 架构的描述
      • 质量特征的分析
      • 场景不确定性的发展
      • 度量的应用架构分析
      • 评价支持工具等
    • ATAM方法采用效用树这一工具对质量属性进行分析和优先级排序
      • 效用树结构包括：数根-质量属性、属性分离、质量属性场景（叶子结点。）
    • ATAM 主要关注4类质量属性：性能、安全、可修改性和可用性
    • 得到初始的效用树后，需要修剪这棵树，保留重要场景（通常不超过50个），再对场景按重要性给定优先级，再按场景实现的难易程度来确定优先级（HML的形式），这样对选定的每个场景就有一个优先级对（重要性和难易度），如H、L来表示该场景重要且易实现
• 3.CBAM方法 （重点）成本效益分析法
  • 在大型复杂系统的构件过程中，经济性通过是要考虑的首要因素。
  • 需要从经济角度建立成本、收益、风险和进度等方面软件的经济模型，CBAM
  • CBAM是在ATAM上构建，用来对架构设计决策的成本和收益进行建模，是优化此类决策的一种手段，
  • CBAM的思想就是架构策略影响系统的质量属性，反过来这些质量属性又会成为系统的项目干系人带来一些收益,CBAM协助项目干系人根据投资回报选择架构策略
  • CBAM在ATAM结束时开始，它实际上使用了ATAM评估的结果
  • CBAM方法分为8个步骤
    • （1）整理场景
      • 整理ATAM中获取的产经，根据商业目标确定这些场景的优先级，并选择最高的1/3场景进行分析
    • （2）对场景进行求精
      • 为每个场景获取最坏情况、当前情况、期望情况和最好情况的质量属性响应级别
    • （3）确定场景的优先级
      • 项目关系人对场景进行投票，其投票时基于每个场景所期望响应值，根据投标结果和票的权值，生一个分值（场景的权值）
    • （4）分配效用
      • 对场景的响应级别（最坏、当前、期望、最好）确定效用表
    • （5）架构策略涉及哪些质量属性及相应级别
      • 形成相关的“策略-场景-响应级别”的对应关系
    • （6）使用内插法确定期望的质量属性响应级别的效用
      • 根据第四步的效用表以及第五步的对应关系，确定架构策略及其对应场景的效用表
    • （7）计算各架构策略的总收益
      • 根据第三步的场景的权值和第六步的架构策略效用表，计算出架构策略的总收益得分
    • （8）根据受成本限制影响的ROI选择架构策略
      • 根据开发经验固件架构策略的成本，结合第七步的收益，计算出架构策略的ROI，按ROI排序，从而确定选择策略的优选级
• 4. 其他评估方法
  • 1）SAEM方法
    • SAEM方法将软件架构看作一个最终产品以及设计过程中的一个中间产品，从外部质量和内部质量属性两个角度来阐述它的评估模型，旨在为软件架构的质量评估创建一个基础框架
      • 外部属性指用户定义的质量属性
      • 内部属性指开发者决定的质量属性
    • SAEM方法的流程
      • （1）对待评估的质量属性进行规约建模
        • 先从为用户角度描述架构的外部质量属性，再基于外部质量属性规约从开发者角度描述架构的内部质量属性
      • （2）为外部和内部的质量属性创建度量准则
        • 先从评估目的，评估角度，评估环境出发来定义架构评估的目标，再根据目标相关的属性来提出问题，然后回答每个问题并提出相应的度量准则
      • （3）评估质量属性
        • 包括数据收集、度量和结构分析3个活动
  • 2） SAABNet方法
    • 软件架构定性的评估技术依赖于专家知识，包括某些特定类型的问题的解决方案以及可能的诱导因素、统计知识，审美观等，这些定性知识比较含糊且难以文档化
    • 来源于人工智能，允许不确定、不完整知识的推理。使用BBN来表示和使用开发过程中的知识，包含定性和定量的描述，
      • 其中定性的描述是所有结点的图，
      • 定量的描述是每个结点状态相关的条件概率
    • 将软件架构开发中的定性知识放到BBN中，需要经过以下几个步骤
      • （1）识别架构中的相关变量
      • （2）定义变量之间的概率依赖，这就是BBN的定性描述
      • （3）评估条件概率，这就是BBN的定量描述
      • （4）测试BBN来验证其输出是否正确
    • 基于BBN正确的定量规约和定性规约，可以用数学方法推到出架构正确性概率
    • SAABNet的3类变量
      - 架构质量属性变量（如可维护性、灵活性等）
      - 质量属性的度量准则变量（如容错性、响应性等）
      - 架构特征变量（如继承深度、编程语言等）
    • SAABNet的目的是辅助架构的定性评估，因此定量规约不是必要的
    • SAABNet可以帮助诊断软甲架构问题的可能导致原因，以及分析架构中的修改给质量属性带来的影响、预测架构的质量属性，帮助架构设计决策
    • SAABNet度量的对象包括架构属性、质量准则和质量因素3部分
  • 3）SACMM方法
    • SACMM方法是一种软件架构修改的度量方法，首先基于图内核定义差异度量准备来计算两个软件架构之间的距离，图内核的基本思想是将结构化的对象描述为它的子结构的集合，通过子结构的配对比较来分析对象之间的额相似性
  • 4）SASAM方法
    • SASAM方法通过对预期架构（架构设计阶段的相关描述材料）和实际架构（源代码中执行的架构）进行映射和比较来静态地评估软件架构
    • 静态评估方对预期架构模型和实际架构模型的每个元素进行映射，比较某个模型元素或关联是否再两个架构模型中都存在，还是只存在某个架构模型中，从而得到评估结果。
    • 评估的目的
      • （1）产品线可能性。是否适用于某个共有得架构，能否成为预期产品线的一部分
      • （2）产品对准性
      • （3）重用可能性（组件的）
      • （4）组件充分性（组件质量评估）
      • （5）对软件架构的理解
      • （6）一致性
      • （7）完备性
      • （8）软件系统或产品线的文档
      • （9）控制演化
      • （10）支持架构结构的分解
  • 5）ALRRA方法
    • 可靠性风险评估主要包含两个因素：故障发生的可能性以及故障所致后果的严重性
    • ALRRA方法是一种软件架构可靠性风险评估方法，该方法使用动态复杂度准则和动态耦合度准则来定义组件和连接件的复杂性因素，
      • 其中，动态复杂度准则在某个场景的执行中分析组件的动态行为来度量组件的复杂性，
      • 动态耦合度准则在某个场景执行中分析连接件的消息传递协议来度量连接件的复杂性。
    • 步骤
      • （1）使用架构描述语言ADL建模软件架构
      • （2）使用仿真进行复杂性分析
      • （3）使用FMEA和失效严重性分析
      • （4）为组件和连接件启发式地定义可靠性风险因素
      • （5）构造架构的CDG，对每个结点赋予组件的可靠性风险hrf，对连接件赋予连接件的可靠性风险hrf
      • （6）用图遍历算法执行架构的风险评估和分析
  • 6）AHP方法
    • 在软件架构评估量化方式中，层次分析法AHP是多种架构评估度量方法的基础理论
    • 特点是把复杂问题中的各种因素通过划分为相联系的有序层次使之条理化，并在一般情况下通过两两对比，根据一定客观现实的主观判断结构，把专家意见和分析者的客观判断结果直接、有效地结合起来，将一定层次上元素的某些重要性进行定量描述，之后利用数学方法计算反映每一层次元素的相对重要次序的权值，并最后通过所有层次之间的总排序计算所有元素的相对权重及权重排序。
    • 步骤
      • （1）通过对系统的认识，确定系统的总目标，得出规划决策的范围，所有采取的的措施方案和正常，实现目标的准则和各种约束条件等，并后记在分析过程中要用到的信息
      • （2）建立一个多层次的递阶结构，按目标的不同、功能的差异，将系统分为几个等级
      • （3）确定以上递阶结构中相邻层次元素间的相关程度，通过数学方法得到相对权值
      • （4）计算各层元素对系统目标的合成权重，排序
      • （5）根据分析计算结果，考虑相应的决策
  • 7） COSMIC+UML方法
    • 基于度量模型来评估软件架构可维护性的方法。
    • 针对不同表达方式的软件架构，采用统一的软件度量COSMIC方法来进行度量和评估
    • 可维护性度量包括3个步骤
      • （1）将面向对象的度量准则与COSMIC方法相关联
      • （2）对COSMIC标记进行完善以适用于描述UML组件图
      • （3）提出UML组件图的度量准则：复杂度、耦合度和内聚度等

8.3 ATAM方法架构评估实践

• ATAM方法评估软件体系架构，分为4个基本阶段：演示、调查和分析、测试、报告ATAM
• 

8.3.1 阶段1 演示

• 演示是ATAM评估软件体系结构的初始阶段，主要有3个主要步骤
  • 1）第一步介绍ATAM
    • 涉及ATAM评估过程的描述，评估负责人向所有相关参与者提供有关ATAM过程的一般信息
    • 领导者说明评估中使用的分析技术以及评估的预期结果
    • 领导者解决小组成员的任何疑虑、期望或者问题
  • 2）第二步介绍业务驱动因素
    • 提到了系统体系结构驱动程序的业务目标。着重于系统的业务视角。它提供了有关系统功能、主要利益相关方、业务目标和系统其他限制的更多信息
    • 将定义被评估系统的主要功能以及涉及的利益相关方，使用event框架，主要功能是处理和处理事件
  • 3）第三步介绍要评估的体系结构
    • 架构团队描述了要评估的架构，侧重于体系结构、时间可用性以及体系结构的质量要求。此步骤中的体系架构演示非常重要，因为会影响分析的质量，

8.3.2 阶段2 调查和分析

• 该阶段，人们对评估期间需要重点关注的一些关键问题进行彻底的调查
  • 4 ）第四步确定架构方法
    • 涉及能够理解系统关键需求的关键架构方法。这一步中，架构团队解释了架构的流程控制，并提供了关于如何达成关键目标以及是否达到关键目标的适当解释。
    • （1）胡佛的架构
      • 此体系架构中，系统从闲置处理程序生成的命令提示符处接受输入。输入事件传递给事件管理器，事件管理器将事件存储在事件队列中。主进程从事件队列中取出事件，并将其分派给事件管理器进行处理。事件管理器将事件绑定到相应的事件处理程序
      • 如果事件未被注册，则丢弃该事件并将控制传递给主进程，下一个要处理的事件从事件队列中取出，并再次发送个事件管理器。如果没有要处理的事件，则生成空闲事件，执行空闲等到，直到从系统用户接收到输入为止
      • 如果事件在事件管理器事件注册表中已注册，则事件与正确的事件处理程序匹配，该处理程序执行该事件，可能导致系统状态的变化
      • 从质量属性角度看结构，每个组件都可以独立出来重新使用，具有高度的可修改性，这些组件相互之间适当地进行交互并执行预期的工作，实现功能的质量属性。由于应用程序构建起提供了明确的钩子接口，使得架构也可以扩展
    • （2）“银行”活动架构
      • 此体系架构中，系统由开始事件初始化，该事件在内部生成并处理，从空闲处理程序生成的命令提示符处接收输入。当输入事件输入时，IDLE_Handler检查他的有效性，将事件传递并存储在事件队列的主模块中，作为有效输入。
      • 处理事件时，首先从队列中提取事件并分派给事件管理器进一步处理，由于初始阶段消除了有缺陷的输入，并且事件管理器直到应用程序处理程序会将相应的处理程序与事件进行匹配，并执行事件。如果无处理事件则发送空闲事件
      • 该架构的质量属性：1.明确缺陷是事件管理器组件暴露给了应用程序，没有在框架中封装，因此可修改性差；2.组件高度相互依赖，相互协同完成特定功能，可重构性差，3空闲事件的输入需要额外的处理空间，因为对其进行解析并消除任何有缺陷的输入们才能保证架构的可靠性。
  • 5）第五步 生成质量属性效用树
    • 在评估阶段，系统最重要的质量属性目标被确定，并确定优先次序和完善。这步至关重要，因为它将所有利益相关方和评估人员的注意力集中在关系到体系成功至关重要的体系结构的不同方面。这是通过建立效用树来实现的
    • 1）场景生成
      • 情景生成时创建效用之前的重要步骤，显示了每个利益相关者有关的场景以及它代表的质量属性
    • 2）质量属性效用树生成
      • 效用树以效用为根结点，质量属性构成效用树的辅助级别。
      • 每个质量属性中都含有特定的质量属性说明，以提供对方案更精确的描述
      • 效用树沿着两个维度进行优先顺序，每个场景对系统成功的重要性以及对此场景实现所带来的难易程度的估计
      • 效用树的优先排名为HML（高中低）
  • 6）第六步 分析体系结构方法
    • 这是调查分析的最后异步，根据前一步生成的效用树的输出，并进行彻底调查和分析，找出处理相应属性的架构的的方法。人们根据这些质量属性分析这两种架构，并未它们提供适当的解释，确定每种架构方法的风险、非风险、敏感点和权衡点
      • A.调查架构方法
        • 识别对对系统目标至关重要的质量属性后，分析两种架构并确定它们如恶化支持这些质量属性
        • （1）可变性
          • 胡佛结构高度支持。每个组件都可以独立的原因
          • 银行活动结构，由于组件相互依赖，高度耦合，部分支持可变性
        • （2）可靠性
          • 胡佛结构由于没有消除有缺陷的输入，最终在事件管理器组件中以适当的方式处理有缺陷的输入，支持可靠性
          • 银行体系结构，能识别有缺陷的输入，在事件存储到队列前做了检查类型和参数的有效性，
        • （3）集成性
          • 定义了同一个各级系统设计的基础主体，架构应该是一致的，在执行架构的所有进程时使用最少的数据和控制机制
          • 胡佛结构把所有事件通过主模块传递给事件处理器，然后绑定执行处理程序，涉及很少的控制机制，因此概念完整性得以实现
          • 银行体系结构需要事件传播，使用的控制机制数量是可以被最小化的，因此概念完整性没有得到妥善处理
        • （4）功能性
          • 表示系统中组件之间的交互以及系统是否执行预期的任务
          • 胡佛结构以有效的方式执行事件处理的预期任务，该架构中功能的属性是需要关注的
          • 银行体系结构中，系统通常适当地执行预期的任务，属于适度地解决了功能问题
        • （5）可修改性
          • 验证系统是否能够以一种快速、经济、高效的方式进行修改，验证了体系结构如何处理对组件的更改，以及是否可以将任何不同的应用程序挂接到框架
          • 胡佛结构中，每个组件独立的原因，维护一个事件类型的注册表，高度可修改性。
          • 银行体系结构中，程序嵌入到组件中，重使用不同应用程序的框架和田间新的应用程序的组件都涉及很多困难和修改，没有足够的可修改性
      • B.创建分析问题
        • 本阶段收集上一阶段讨论过的高优先级场景中产生的问题，在现实生活中，所有利益相关者都会收集分析问题。以下是分析问题列表和正在解决的属性
          • （1）架构的组件可以重复用于未来的项目吗？（变化性）
            • 胡佛架构：每个组件相互独立的，并与适当的方式进行协调
            • 银行体系架构：可以重用，但会涉及重大的应用程序的修改，因为程序嵌入到组件中
          • （2）未来可以扩展组件以适应新的应用程序或新组件吗（变化性）
            • 胡佛架构：是的，每个组件相互独立可以容易扩展
            • 银行体系架构：是困难的，因为程序嵌入到组件中，需要对框架主要部分修改
          • （3）系统会处理用户提供的任何输入并处理无效输入吗（可靠性）
            • 胡佛架构：输入时未处理，在稍后阶段处理
            • 银行体系架构：是的，输入时会丢弃无用的输入事件。
          • （4）架构的行为是否一致（完整性）
            • 胡佛架构：是的，且利用最少控制机制处理任务
            • 银行架构体系：一致性没有充分现实，需要事件传播到程序处理，控制机制数量多
          • （5）是否可以将任何新的应用程序特定功能添加到架构中（可修改性）
            • 胡佛架构：应用程序完全独立于此框架结构，不影响任何组件
            • 银行体系架构：及时涉及许多组件，有可以添加
          • （6）系统是否已短时间和成本效益方式进行修改（可修改性）
            • 胡佛架构：由于程序没有嵌入到架构中，并且极小的于框架连接，所以是的
            • 银行体系架构：程序嵌入到框架中，需要更多修改时间不具备成本效益
          • （7）组件是否正确交互（功能性）
            • 胡佛架构：正确交互，组件以协调的方式进行交互
            • 银行体系结构：正确交互，组件以系统的方式进行交互，
          • （8）体系结构是否正确执行事件处理任务（功能性）
            • 胡佛架构：正确执行，事件处理任务通过组件之间的交互处理的
            • 银行体系结构：正确执行，尽管程序嵌入到组件中，也能适度地完成预期的任务
      • C.分析问题的答案
        • 第三阶段是根据两种评估架构对上述分析问题提供合理的解析或者答案
      • D.找出风险、非风险、敏感点和权衡点
        • 风险是架构中的一个问题点，不支持给定的优先级质量属性
        • 非风险是体系架构的优势，实现特定的优先级质量属性
        • 敏感点是一个或多个组件的属性，对于实现给定的质量属性至关重要。以下是2中体系结构敏感点
          • 更改体系结构的范围对应用程序嵌入到系统中的位置数量很敏感
          • 错误输入的处理对应用程序事件类型的数量很敏感
          • 系统一致性水平对用于处理流程的控制机制的数量很敏感
          • 从系统获取所需输出的过程，对组件协调的方式及交互的方式非常敏感
          • 向应用程序添加新功能的能力，对应用程序嵌入到系统中的位置数量很敏感
        • 权衡点是架构对多个属性敏感
          • 从敏感点看出，应用程序嵌入系统的地方，数量会影响变化性和可修改性，这就成为了权衡点
          • 基于这中观测发现银行体系结构具有上述权衡点，而胡佛体系结构没有

8.3.3 阶段3 测试

• 测试
  • 7）第七步 头脑风暴和优先场景
    • 是ATAM测试的第一阶段，代表利益相关者的利益，用于理解质量属性要求。在效用树生成步骤中，主要结果是从架构师角度理解之来给你属性，目标是让更大的利益相关者参与其中
    • 从第五步生成质量属性效用树中，利益相关者需要使用头脑风暴的三种场景
      • 用例场景：利益相关者是最终用户
      • 增长场景：代表了架构发展的方式
      • 探索性场景：代表了架构中极端的增长形式
    • 该阶段执行活动如下
      • 首先，情景是在利益相关者头脑风暴活动后收集的
      • 场景优先，相同质量属有关的所有场景都被合并，利益相关者票选出最重要的场景，每个利益相关的票数=场景总数30%
      • 投票结束后，投票结果记录下来，场景按总票数排序
      • 将优先头脑风暴场景列表与优先场景进行比较，
  • 8）第八步 分析架构方法
    • 是测试的最后一阶段，这一步重复了调查与分析中的第六步的分析体系结构方法。
    • 区别是，步骤6中高优先级质量属性来自效用树，而这一步需要考虑头脑风暴中高得票数的质量属性，最后分析架构设计方案中的风险、非风险、敏感点和权衡点。
      • A.调查架构方法
      • B.创建分析问题
      • C.分析问题的答案
      • D.找出风险、非风险、敏感点和权衡点

8.3.4 阶段4 报告ATAM

• 报告ATAM评估的最后阶段，提供了评估期间收集的所有信息。ATAM团队将他们的发现呈现给利益相关者
• ATAM团队主要发现通常包括
  • 一种效用树
  • 一组生成的场景
  • 一组分析的问题
  • 一套确定的风险和非风险
  • 确定的架构方法

本文参考文档：《系统架构设计师 第二版》