系统架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。它利用数学
或逻辑分析技术，针对系统的一致性、正确性、质量属性、规划结果等不同方面，提供描述性、
预测性和指令性的分析结果。
系统架构评估的方法通常可以分为3类：基于调查问卷或检查表的方式、基于场景的方式
和基于度量的方式。
(1)基于调查问卷或检查表的方法。该方法的关键是要设计好问卷或检查表，充分利用系
统相关人员的经验和知识，获得对架构的评估。该方法的缺点是在很大程度上依赖于评估人员
的主观推断。
(2)基于场景的评估方法。基于场景的方式由卡耐基梅隆大学软件工程研究所首先提出
并应用在架构权衡分析法 (Architecture Tradeoff Analysis Method,ATAM) 和软件架构分析方法
(Software ArchitectureAnalysis Method,SAAM) 中。它是通过分析软件架构对场景(也就是对系
统的使用或修改活动)的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。
(3)基于度量的评估方法。它是建立在软件架构度量的基础上的，涉及3个基本活动，首
先需要建立质量属性和度量之间的映射原则，然后从软件架构文档中获取度量信息，最后根据
映射原则分析推导出系统的质量属性。
本节首先介绍系统架构评估中的重要概念，然后对 SAAM、ATAM和 CBAM 等3种重要的
架构评估方法进行详细论述，并简要说明其他评估方法。

1. 一些重要概念

1.1 敏感点 (Sensitivity Point)

• 敏感点：是一个或多个构件的特性
• 研究敏感点可使设计人员或分析员明确在搞清楚如何实现质量目标时应注意什么

1.2 权衡点 (Tradeoff Point)

• 权衡点是影响多个质量属性的特性，是多个质量属性的敏感点
• 举例：改变加密级别可能会对安全性和性能产生非常重要的影响。
  • 提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响系统性能

1.3 风险承担者 (Stakeholders)

• 概念：
  • 即，利益相关人
  • 这些人都对架构施加各种影响，以保证自己的目标能够实现
• 架构评估中可能涉及的一些风险承担者及其所关心的问题

1.3.1 系统生产者

• 软件系统架构师
  • 职责：负责软件架构的质量需求间进行权衡的人
  • 关系的问题：对其他风险承担者提出的质量需求的折中和调停
• 开发人员：
  • 职责：设计人员或程序员
  • 关系的问题：架构描述的清晰与完整、各部分的内聚性与受限藕合、清楚的交互机制
• 维护人员：
  • 职责：系统初次部署完成后对系统进行更改的人
  • 关系的问题：可维护性，确定出某个更改发生后必须对系统中哪些地方进行改动的能力
• 集成人员：
  • 职责：负责构件集成和组装的开发人员
  • 关系的问题：同上
• 测试人员：
  • 职责：负责系统测试的开发人员
  • 关系的问题：集成、一致的错误处理协议，受限的构件耦合、构件的高内聚性、概念完整性
• 标准专家：
  • 职责：负责所开发软件必须满足的标准细节的开发人员
  • 关系的问题：对所关心问题的分离、可修改性和互操作性
• 性能工程师：
  • 职责：分析系统的工作产品以确定系统是否满足其性能及吞吐量需求的人员
  • 关系的问题：易理解性、概念完整性、性能、可靠性
• 安全专家：
  • 职责：负责保证系统满足其安全性需求的人员
  • 关系的问题：安全性
• 项目经理：
  • 职责：负责为各小组配置资源、保证开发进度、保证不超出预算的人员，负责与客户沟通
  • 关系的问题：架构层次清晰，便于组建小组；任务划分结构、进度标志和最后期限等
• 产品线经理：
  • 职责：设想该架构和相关资产怎样在该组织的其他开发中得以重用的人员
  • 关系的问题：可重用性、灵活性

1.3.2 系统消费者

• 客户
  • 职责：系统的购买者
  • 关系的问题：开发的进度、总体预算、系统的有用性、满足需求的情况
• 最终用户
  • 职责：所实现系统的使用者
  • 关系的问题：功能性、可用性
• 应用开发者
  • 职责：利用该架构及其他已有可重用构件，通过将其实例化而构建产品的人员
  • 关系的问题：架构的清晰性、完整性、简单交互机制、简单裁减机制
• 任务专家、任务规划者
  • 职责：知道系统将会怎样使用以实现战略目标的客户代表
  • 关系的问题：功能性、可用性、灵活性

1.3.3 系统服务人员

• 系统管理员
  • 职责：负责系统运行的人员
  • 关系的问题：容易找到可能出现问题的地方
• 网络管理员
  • 职责：管理网络的人员
  • 关系的问题：网络性能、可预测性
• 技术支持人员
  • 职责：为系统在该领域中的使用和维护提供支持
  • 关系的问题：使用性、可服务性、可裁减性 的人员

1.3.4 其它人员

• 领域代表
  • 职责： 类似系统或所考察系统将要在其中运行的系统的构建者或拥有者
  • 关系的问题： 可互操作性
• 系统设计师
  • 职责：整个系统的架构设计师，负责在软件和硬件之间进行权衡并选择硬件环境的人
  • 关系的问题：可移植性、灵活性、性能和效率
• 设备专家
  • 职责：熟悉该软件必须与之交互的硬件的人员，能够预测硬件技术的未来发展趋势的人员
  • 关系的问题：可维护性、性能

1.4 场景 (scenarios)

• 概念：
  • 场景是从风险承担者的角度对与系统的交互的简短描述
  • 是描述架构属性的基础，描述了各种系统必须支持的活动和可能存在的状态变化
• 在架构评估中的描述：
  • 一般采用刺激 (Stimulus)
  • 环 境(Environment)
  • 响应 (Response)

2. 系统架构评估方法

2.1 基于场景的架构分析方法（SAAM）

2.1.1 概述

• 概念
  • Scenarios-based Architecture Analysis Method
  • 一种非功能质量属性的架构分析方法
  • 是评估一个系统架构的通用方法
  • 用于架构的最后版本
• 作用：
  • 指导对架构的检查
    • 关注潜在问题：如：需求冲突、设计的不完全性
    • 评估架构固有的风险
  • 比较不同的架构
• 开始时间：早于详细设计
• 评估技术：场景技术
• 质量属性_{（注意：我们说的是SAAM的质量属）}
  • 都具体化为场景
  • 主要分析可修改性
• 风险承担者

SAAM 协调不同参与者之间感兴趣的共同方面，作为后续决策的基础，达成对架构的共识。

• 架构描述
  • 主要描述3个方面：问题描述、需求声明、架构描述（也是分析过程中SAAM的输入）

2.1.2 分析评估过程

分析评估架构的过程包括5个步骤：

• 场景开发
  通过与各类风险承担者协商，创建一些任务场景来展示系统支持的各种活动
• 架构描述
  使用易于理解且符合语法规则的架构来描述软件架构，其中包括系统的计算构件、数据构件以及它们之间的数据和控制关系
• 单个场景评估
  生成一个关于特定架构的场景描述列表，其中包括直接场景和间接场景
• 场景交互
  通过分析场景交互，可以得出系统中所有场景对系统构件产生影响的列表
• 总体评估
  最后，对场景和场景间的交互进行总体的权衡和评估

2.2 架构权衡分析方法（ATAM）

2.2.1 概述

• 概念：
  • Architecture Tradeoff Analysis Method)
  • 在SAAM的基础上发展起来的
  • 主要针对质量属性：性能、可用性、安全性、可修改性
  • 作用：在系统开发之前，对以上质量属性进行评价和折中
• 风险承担者：
  • 在场景、需求收集相关活动中， 需要所有系统相关人员的参与
• 评估技术：
  • 场景技术
    • 3种不同类型的场景
      • 用例
      • 增长场景：涵盖对系统的修改
      • 探测场景：涵盖对系统造成过载的极端修改
  • 定性的启发式分析方法 (Qualitative Analysis Heuristics)
    • 当需要对 “质量属性的分析模型” 进行分析时，“定性的启发式分析方法” 可以作为这种分析的粗粒度版本。
• 方法验证
  • 已有应用，但仍处在研究之中

存在一些问题，如：架构的描述、质量特征的分析、场景不确定性的处理、度量的应用架构分析、评价支持工具等，这些都影响和制约着分析评估技术的发展。

2.2.2 分析评估过程

四个主要的活动领域(或阶段)：

1. 场景和需求收集
   • 收集场景
   • 收集需求、约束、环境
2. 架构视图和场景实现
   • 描述体系结构视图
   • 实现场景
3. 属性模型构造和分析
   • 特定属性分析（优秀的单一理论）
4. 折中
   • 标志敏感度
   • 标志折中
     

2.2.3 评估中的一些问题

• 需求来源
  • 从场景派生而来
  • 对行为模式和执行环境的假设
    • 每一个假设都要被检查、验证和询问
• 获得属性关联的方法有两种
  • 使用敏感度分析来发现折中点
  • 通过检查假设
• 提供了迭代的改进

2.2.4 领域知识库的可重用性

• 基于属性的架构风格（ABAS）
  • Attribute Based Architecture Style
  • 有助于提升“从架构风格的概念到基于特定质量属性模型”的推理能力
• 领域知识库的维护：通过ABAS
  • 获取一组ABAS，把架构设计变得更为惯例化和更可预测
  • 得到一个基于属性的架构分析的标准问题集合，使设计与分析之间的联系更为紧密

2.2.5 效用树 (Utility tree)

• 作用：对质量属性进行分类和优先级排序

• 效用树的结构包括：树根—质量属性—质量属性场景(叶子节点)

  或 树根—质量属性—属性分类—质量属性场景(叶子节点)

• 关注属性：性能、安全性、可修改性、可用性（和ATAM一致）

• 效用树修剪：

  • 保留重要场景(不超过50个)
  • 对场景按重要性给定优先级（H/M/L）
  • 再按场景实现的难易度来确定优先级（H/M/L）
  • 结果：选定的每个场景就都一个优先级对应：(重要度、难易度)，如 (H、L) 表示该场景重要且易实现

2.3 成本效益分析法（CBAM）

2.3.1

• 概念
  • the Cost Benefit Analysis Method
  • 在ATAM上构建
• 作用：
  • 用来对架构设计决策的成本和收益进行建模
  • 以协助项目干系人根据其投资回报 (Return On Investment，ROI) 选择架构策略
• 开始：ATAM 结束时开始

2.3.2 八个步骤。

1. 整理场景
   • 根据商业目标确定这些场景的优先级
   • 选取优先级最高的1/3的场景进行分析
2. 对场景进行求精
   • 为每个场景获取最坏情况、当前情况、期望情况、最好情况的质量属性响应级别
3. 确定场景的优先级
   • 项目关系人对场景进行投票，根据投票数和票的权值，生成一个分值
4. 分配效用
   • 对场景的响应级别确定效用表
5. 形成相关的“策略一场景一响应级别”的对应关系
6. 使用内插法确定“期望的”质量属性响应级别的效用
   • 根据效用表（第4步中）以及对应关系（第5步的），确定架构策略（及其对应场景的）效用表
7. 计算各架构策略的总收益
   • 根据场景的权值（第3步的）及架构策略效用表（第6步的），计算出架构策略的总收益得分
8. 根据受成本限制影响的 ROI选择架构策略
   • 根据开发经验估算架构策略的成本
   • 结合第7步的收益，计算出架构策略的ROI
   • 按 ROI排序，从而确定选取策略的优先级

2.4 其他评估方法

2.4.1 SAEM 方法

• 概念：
  • 将软件架构看作一个中间产品
  • 从外部质量属性和内部质量属性两个角度来阐述它的评估模型
    • 外部属性：用户定义的质量属性
    • 内部属性：开发者决定的质量属性
  • 旨在为软件架构的质量评估创建一个基础框架
• 评估流程
  1. 对待评估的质量属性进行规约建模
     • 先从用户的角度描述架构的外部质量属性
     • 再基于外部质量属性规约从开发者的角度描述架构的内部质量属性
  2. 为外部和内部的质量属性创建度量准则
     • 定义架构评估的目标
       • 评估目的：如软件架构比较、最终产品的质量预测
       • 评估角度：如开发者、用户、维护者
       • 评估环境：架构作为最终产品或设计中间产品
     • 再根据目标相关的属性来提出问题
     • 回答每个问题并提出相应的度量准则
  3. 评估质量属性
     • 数据收集
     • 度量
     • 结果分析

2.4.2 SAABNet 方法

• 概念：
  • Software Architecture assessment Belief Network（软件架构评估信念网络）
  • 是一种用来表达和使用定性知识来辅助架构的定性评估
  • 来源于人工智能 (AI), 允许不确定、不完整知识的推理
  • 该方法使用 BBN来表示和使用开发过程中的知识
    • BBN: (贝叶斯信念网络 Bayesian Belief Networks)
    • 定性描述：所有结点的图
    • 定量的描述：每个结点状态相关的条件概率
• 相关步骤：
  1. 识别架构中的相关变量
  2. 定义变量之间的概率依赖（即，BBN的定性描述）
  3. 评估条件概率（即，BBN 的定量描述）
  4. 测试BBN来验证其输出是否正确
• 变量的分解
  • 变量分类（吐槽：这里的分类和后文“度量对象”的变量，完全对不上。（之后会继续整理一下））
    • 架构质量属性变量：如可维护性、灵活性等
    • 质量属性的度量准则变量：如容错性、响应性等
    • 架构特征变量：如继承深度、编程语言等
  • 变量分解：高层抽象分解为低层抽象
    • 质量属性变量 --(分解)–> 度量准则变量
    • 度量准则变量 --(分解)–> 架构特征变量
• 作用：是辅助架构的定性评估
  • 帮助诊断软件架构问题的可能导致原因
  • 分析架构中的修改给质量属性带来的影响
  • 预测架构的质量属性
  • 帮助架构设计做决策
• 度量的对象：架构属性、质量准则、质量因素
  • 架构属性变量：
    • 架构风格：管道-过滤器、代理、层、平台
    • 类继承深度：深、不深
    • 组件粒度：细粒度、粗粒度
    • 组件互依赖性：多、少
    • 内容选择：多、少
    • 组合：静态、松散
    • 文档：好、坏
    • 动态绑定：高、低
    • 异常处理：有、无
    • 执行语言：
    • 接口粒度：细粒度、粗粒度
    • 多重继承：有、无
    • 线程应用：高、低
  • 质量准则变量：
    • 容错：高容错、地容错
    • 水平复杂度：高、低
    • 内存使用：高、低
    • 响应：好、坏
    • 安全性：安全、不安全
    • 可测试性：好、坏
    • 数据吞吐：好、坏
    • 易理解性：好、坏
    • 垂直复杂度：高、低
  • 质量因素变量：
    • 复杂度：高、低
    • 性能：好、坏
    • 配置：好、坏
    • 可信度：好、坏

2.4.3 SACMM 方法

• 概念：是一种软件架构修改的度量方法

知道是干什么的即可，其他不考

2.4.4 SASAM 方法

• 概念：通过对“预期架构”和“实际架构”进行映射和比较来静态地评估软件架构
  • 预期架构：架构设计阶段的相关描述材料
  • 实际架构：源代码中执行的架构
  • 静态评估：对以上两个模型的每个元素进行映射，比较两边是否都存在
    • 比较：手工完成
    • 映射：评估工具中执行
• 10个评估目标
  • 产品线可能性：分析几个不相干的系统是否能成为预期产品线的一部分
  • 产品对准性：评估系统的软件架构是否与产品线的软件架构一致
  • 重用可能性：分析组件是否能重用
  • 组件充分性：评估组件的内在质量
  • 对软件架构的理解
  • 一致性：评估架构文档和执行的一致性
  • 完备性：检测未被文档化的架构实体
  • 软件系统或产品线的文档
  • 控制演化
  • 支持架构结构的分解

2.4.5 ALRRA 方法

• 概念：
  • 软件架构可靠性风险评估方法
  • 度量内容：
    • 组件的复杂性：使用动态复杂度准则，分析组件的动态行为
    • 连接件的复杂性：使用动态耦合度准则，分析连接件的消息传递协议
• 可靠性风险的两个主要因素
  • 故障发生的可能性
  • 故障所致后果的严重性
• 评估的步骤：

  1. 使用架构描述语言 (ADL) 建模软件架构

  2. 使用仿真进行复杂性分析

  3. 使用 FMEA和失效严重性分析

  4. 为组件和连接件启发式地定义可靠性风险因素

     启发式：指在没有完整数据或详细分析的情况下，通过经验给出初始结果

  5. 构造架构的 CDG, 对每个结点 C_i赋予组件的可靠性风险 hrf_i, 对 C_i和 C_j之间连接件赋连接件的可靠性风险 hrf_ij

     吐槽：教材里CDG这个缩写给的太突兀，猜是Casual Dependency Graph（风险评估依赖图）

  6. 执行架构的风险评估和分析

     • 方法：图遍历算法
     • 架构的可靠性风险因素：通过集成各组件和各连接件的风险因素来获取

2.4.6 层次分析法（AHP）

• 概念：
  • Analytical Hierarchy Process
  • 是对定性问题进行定量分析的方法
  • 把复杂问题中的各种因素通过划分为相联系的有序层次使之条理化
• 分析、度量步骤：
  1. 收集系统信息

  如：规划决策所涉及的范围、所要采取的措施方案和政策、实现目标的准则以及策略和各种约束条件等

  2. 将系统分为多层次的递阶结构
  3. 确定相邻层次元素间的相关程度

  相对权值：相关元素对于上一层指定元素的重要程度

  4. 计算各层元素对系统目标的合成权重，并排序
  5. 根据分析计算结果，考虑相应的决策。
     软件架构评估包括对各种质量属性的评估以及其他一些非功能非质量因素的评估，这些属
     性之间有时存在某些冲突。 AHP是一种重要的辅助决策方法，通常被用来解决这种冲突。 AHP
     可以帮助对提供的设计方案进行整体排名。

2.4.7 COSMIC+UML方法

吐槽：这段教材不知道从哪的资料里抄了一段，没头没尾，我猜肯定不考

---