架构质量属性与评估

1. 软件系统质量属性

1.1 概念

1. 软件系统质量：软件系统与明确地和隐含地定义的需求相一致的程度。
2. 软件系统质量属性：是一个系统的可测量或可测试的属性，用来描述系统满足 利益相关者（Stakeholders）需求的程度。

1.2 分类

1. 开发期质量属性
   1. 易理解性：指设计 被开发人员理解 的难易程度。
   2. 可扩展性：软件因 适应新需求 或需求变化而增加新功能的能力，也称为灵活性。
   3. 可重用性：指 重用 软件系统或某一部分的难易程度。
   4. 可测试性：对软件测试以证明其满足需求规范的难易程度。（度量指标有：如果存在缺陷出现故障的概率、测试准备时间、测试环境的准备时间）
      1. 案例题常考，关键词：接口调试，远程调试，测试功能
      2. 与远程调试相关。
   5. 可维护性：当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度。
   6. 可移植性：将软件系统从一个运行环境 转移 到另一个不同的运行环境的难易程度。
2. 运行期质量属性
   1. 性能：性能是指软件系统及时提供相应服务的能力，如速度、吞吐量和容量等的要求。
   2. 安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
   3. 可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力。
   4. 互操作性：指本软件系统 与其他系统交换数据和相互调用服务 的难易程度。
   5. 可靠性：软件系统在一定的时间内持续无故障运行的能力。（多长时间不出问题）
   6. 可用性：指系统在一定时间内正常工作的时间所占的比例。可用性会受到系统错误，恶意攻击，高负载等问题的影响。（出了故障多久能够恢复）
   7. 鲁棒性：是指软件系统在非正常情况（如用户进行了非法操作、相关的软硬件系统发生了故障等）下仍能够正常运行的能力，也称 健壮性 或 容错性。

1.3 面向架构评估的质量属性及其应对措施

1.3.1 性能

1. 概念：指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。如 响应时间、吞吐量。
2. 应对措施：
   1. 资源的需求：减少处理事件时对资源的占用、减少处理时间的数量、控制资源的使用
   2. 资源管理：引入并发机制、增加资源、资源调度（负载均衡、线程池）、减少计算开销
   3. 资源仲裁：多个任务争夺资源时 按优先级分配资源，如 优先级队列、先来先服务、固定优先级、动态优先级、静态调度
3. 关键词：响应速度、吞吐量、负载能力

1.3.2 可靠性

1. 概念：多长时间不出问题。强调在规定时间与条件下无故障地完成规定功能。
2. 衡量指标：
   1. MTTF：平均失效前时间（即正常运行的时间）
   2. MTTR：平均修复时间（即处理故障的时间）
   3. MTBF：平均故障间隔时间（即发生故障的间隔时间）
   4. 在修复时间很短的情况下，MTTR 很短，MTTF ≈ MTBF
3. 细分为两方面：
   1. 容错性：出现错误后仍能保证系统正确运行，且自行修复错误
   2. 健壮性：保护错误不对系统产生影响，按既定程序忽略错误
4. 应对措施：
   1. 心跳、Ping/Echo、冗余、选举

1.3.3 可用性

1. 概念：发生故障快速恢复的能力。系统能够正常运行的时间比例。强调 “能用” 的时间占比。故障间隔时间，出了故障多久能够恢复，恢复速度快，可用性就好。
2. 应对措施：
   1. 错误检测：心跳、Ping/Echo、异常
   2. 错误恢复：表决选举、冗余（主动、被动）、重新同步、内测、检查点/回滚
   3. 错误避免：服务下线、事务、进程监控器
3. 关键词：可恢复能力、系统正常运行的时间

1.3.4 安全性

1. 概念：是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。
2. 包含：保密性、完整性、不可抵赖性、可控性
3. 应对措施：
   1. 抵抗攻击：加密、用户认证、授权、追踪审计、维护数据机密性与完整性、限制暴露、限制访问
   2. 检测攻击：入侵检测
4. 关键词：数据保护、授权、防攻击

1.3.5 可修改性

1. 概念：指能够快速的以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量。
2. 包含：
   1. 可维护性：局部修复使故障对架构的负面影响最小化
   2. 可扩展性：因松散耦合更易实现新特性/功能，不影响架构
   3. 结构重组：不影响主体进行的灵活配置
   4. 可移植性：适用于多样的环境（硬件平台、语言、操作系统等）
3. 应对措施：
   1. 局部化修改：高内聚低耦合、预测变更、使模块通用
   2. 防止连锁反应：接口-实现分类、抽象、信息隐藏、维持现有接口、限制通信路径、使用中介
   3. 推迟绑定时间：运行时注册、多态、配置文件
4. 关键词：系统修改的难易程度、

1.3.6 功能性

1. 概念：是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。需求的满足程度。

1.3.7 可变性

1. 概念：指体系结构经扩充或变更而成为新体系结构的能力。总体架构可变。
2. 这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时，可变性是很重要的。

1.3.8 互操作性

1. 概念：通过可视化或接口的方式提供更好的交互操作体验。
2. 这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时，可变性是很重要的。
3. 程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，也影响应用的软件体系结构。
4. 强调系统间的协同。

1.4 质量属性场景描述

1.4.1 概念

质量属性场景：是一种具体的质量属性需求，作为描述质量属性的手段。

1.4.2 组成部分（六要素）

1. 刺激源（Source）：这是 某个生成该刺激的实体（人、计算机系统或者任何其他刺激器）。
2. 刺激（Stimulus）：该刺激是当刺激到达系统时需要考虑的 条件。
3. 环境（Environment）：该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况。
4. 制品（Artifact）：某个制品被激励。这可能是整个系统，也可能是系统的一部分。
5. 响应（Response）：该响应是在 激励到达后所采取的行动。
6. 响应度量（Measurement）：当响应发生时，应当能够 以某种方式对其进行度量，以对需求进行测试。

2. 系统架构评估

2.1 概念

1. 系统架构评估是在 对 架构分析、评估 的基础上，对 架构策略的选取 进行决策。
2. 软件架构评估在架构设计之后，系统设计之前，因此与设计、实现、测试都没有关系。
3. 评估的目的是 为了评估所采用的架构是否能解决软件系统需求，但不是单纯的确定是否满足需求。
4. 敏感点：是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。
5. 权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。
6. 在架构评估中，场景是从 风险承担者 的角度对与系统交互的描述，一般从三个方面对场景进行设计：
   1. 刺激（事件）
   2. 环境（事件发生的环境）
   3. 响应（架构响应刺激的过程）
7. 风险承担着（利益相关者）需要使用 头脑风暴 的三种场景：
   1. 用例场景：源自最终用户的真实操作，用于 验证系统是否满足其核心业务功能
   2. 增长场景：用来 模拟系统未来可能发生的变化，例如扩展、升级等，体现架构的可扩展性与可演化性
   3. 探索性场景：用于 挑战架构极限，例如极端负载或极端故障情形，测试系统鲁棒性与适应能力

2.2 评估方式

1. 基于 调查问卷（检查表）的方式：类似于需求获取中的问卷调查方式，只不过是架构方面的问卷，要求 评估人员对领域熟悉。
2. 基于 度量 的方式：制定一些定量来度量架构，如代码行数等。要制定 质量属性和度量结果 之间的 映射，强调通过客观的量化数据对系统进行评价。要求 评估人员对架构熟悉。涉及3个基本活动：
   1. 建立映射关系：首先需要建立质量属性和度量之间的映射原则
   2. 提取度量信息：然后从软件架构文档中获取度量信息
   3. 推导质量属性水平：最后根据映射原则分析推导出系统的质量属性
3. 基于 场景 的方式：主要方法。要求 评估人员即对领域熟悉，也对架构熟悉。
   1. 首先要确定应用领域的功能和软件架构的结构之间的映射
   2. 然后要设计用于体现待评估质量属性的场景（即4+1视图中的场景）
   3. 最后分析软件架构对场景的支持程度

3. 基于场景的评估方法

3.1 软件架构分析方法（SAAM，Software Architecture Analysis Method）

3.1.1 概念

1. 是一种 非功能质量属性 的架构分析方法，是最早形成文档并得到广泛应用的软件架构分析方法。
2. 主要目标：支持架构设计决策，尤其是在需求变更和系统演化方面的影响分析
3. 关注的是 最终架构 而非详细设计

3.1.2 内容

1. 特定目标
   1. SAAM 的目标是对描述应用程序属性的 文档，验证基本的架构假设和原则。
2. 质量属性
   1. 这一方法的基本特点是把任何形式的 质量属性都具体化为场景。
   2. 可修改性 是 SAAM 分析的主要质量属性。
3. 架构描述
   1. SAAM 用于架构的 最后版本，但早于详细设计。
   2. 架构的描述形式 应当被所有参与者理解。
   3. 描述架构的3个主要方面：功能、结构 和 分配。
4. 方法活动
   1. SAAM的主要输入是：问题描述、需求声明 和 架构描述。
   2. 分析过程的 5 个步骤：
      1. 场景开发
      2. 架构描述
      3. 单个场景评估
      4. 场景交互
      5. 总体评估

3.2 架构权衡分析方法（ATAM，Architecture Tradeoff Analysis Method）

3.2.1 概念

1. 概念：主要关注系统的 需求说明，在系统开发之前，针对 性能、安全性、可用性、可修改性 等质量属性进行 评价 和 折中。
2. 让架构师明确如何权衡多个质量目标，参与者有 评估小组、项目决策者 和 其他项目相关人。
3. 整个评估过程强调以 属性 作为架构评估的核心概念。
4. ATAM 是在基于 场景 的架构分析方法（Scenarios-based Architecture Analysis Method，SAAM）基础之上发展起来的，分为 4 个主要的活动阶段：
   1. 场景和需求收集
   2. 架构视图和场景实现（架构视图描述）：明确架构的各个视角并对关键场景加以实现
   3. 属性模型构造和分析
   4. 架构决策与折中（属性模型折中）
5. 影响架构设计的因素点：
   1. 敏感点：单个或多个构件（或构件之间的关系）的特性（为了实现某种特性）
   2. 权衡点：影响多个质量属性的特性，是 多个（质量属性）敏感点的汇集（如 加密级别，既影响安全性又影响性能，且提升一方可能降低另一方）
   3. 决策点：某个架构决策的节点
   4. 风险点：架构设计中潜在的存在问题的架构决策所带来的隐患，可能导致系统失败的因素

3.2.2 评估实践阶段划分

1. 现代的 ATAM 方法采用 效用树 对质量属性进行分类和优先级排序。
2. 阶段：
   1. 演示：
      1. 介绍 ATAM
      2. 介绍业务驱动因素
      3. 介绍要评估的体系结构
   2. 调查和分析：
      1. 确定架构方法
      2. 生成质量属性效用树
      3. 分析体系结构方法：调查架构方法 -> 创建分析问题 -> 分析问题的答案 -> 找出风险、非风险、敏感点和权衡点
   3. 测试：
      1. 头脑风暴 和优先场景
      2. 分析架构方法
   4. 报告：
      1. 提供评估期间收集的所有消息，呈现给利益相关者

3.2.3 质量属性效用树

1. ATAM 采用效用树来 刻画和排序质量属性。
2. 概念：
   1. 是进行架构评估的工具之一，包含两部分：
      1. 与系统有关的 质量属性
      2. 对利益相关者的 质量属性要求（情景）。
   2. 情景 是一个说明利益相关者和系统之间的相互作用的描述。
   3. 三个利益相关者（风险承担者）：最终用户、架构师、应用程序开发人员
3. 沿着 两个维度 进行优先级排序：
   1. 每个场景对系统成功的重要性
   2. 对此场景实现（从架构师角度）所带来的难易程度的估计
4. 树形结构 从根部到叶子节点 依次是：
   1. 根部：以 “效用” 作为根节点
   2. 质量属性：性能、安全性、可用性、可修改性等
   3. 属性分类：质量属性下的属性分类（如性能可分为响应时间、吞吐量等）
   4. 质量属性场景：具体的质量属性场景为叶子节点

3.3 成本效益分析法（CBAM，the Cost Benefit Analysis Method）

3.3.1 概念

1. 用来对架构建立的成本来进行设计和建模，让决策者根据 投资收益率 来选择合适的架构
2. 可以看做 对 ATAM 的补充，在 ATAM 确定质量合理的基础上，再对效益进行分析。

3.3.2 步骤

1. 整理场景（确定场景，并确定优先级，选择三分之一优先级最高的场景进行分析）；
2. 对场景进行细化（对每个场景详细分析，确定最好、最坏的情况）；
3. 确定场景的优先级（项目干系人对场景投票，根据投票结果确定优先级）；
4. 分配效用（对场景响应级别确定效用表，建立策略、场景、响应级别的表格）；
5. 形成 “策略-场景-响应级别的对应关系”；
6. 确定期望的质量属性响应级别的效用（根据效用表确定所对应的具体场景的效用表）；
7. 计算各架构策略的总收益；
8. 根据受成本限制影响的投资报酬率选择架构策略（估算成本，用上一步的收益减去成本，得出收益，并选择收益最高的架构策略）。

3.4 其他评估方法

3.4.1 SAEM 方法

1. 将软件架构看作一个最终产品以及设计过程中的一个中间产品，从 外部质量属性 和 内部质量属性 两个角度来阐述它的评估模型，旨在为软件架构的质量评估创建一个基础框架。
2. 外部属性：指用户定义的质量属性
3. 内部属性：指开发者决定的质量属性。

3.4.2 SAABNet 方法

1. 是 一种使用贝叶斯信念网络（BBN）来表达和使用定性知识以辅助架构的定性评估。该方法来源于人工智能，允许不确定、不完整知识的推理。

3.4.3 SACMM 方法

1. 是一种 软件架构修改的度量方法。

3.4.4 SASAM 方法

1. 软件架构静态分析方法：通过对 预期架构（架构设计阶段的相关描述材料）和 实际架构（源代码中执行的架构）进行映射和比较来 静态地评估 软件架构。

3.4.5 ALRRA 方法

1. 是一种 软件架构可靠性风险评估方法，该方法使用 动态复杂度准则 和 动态耦合度准则 来定义组件和连接件的复杂性因素。
2. 动态复杂度准则：在某个场景的执行中分析组件的动态行为来度量组件的复杂性
3. 动态耦合度准则：在某个场景的执行中分析连接件的消息传递协议来度量连接件的复杂性。
4. 利用失效模式和影响分析（FMEA）的技术。

3.4.6 AHP（层次分析法）方法

1. 是对定性问题进行 定量分析 的一种 简便、灵活、实用 的 多准则决策方法。
2. AHP方法的特点是把复杂问题中的各种因素通过划分为相联系的有序层次使之条理化，并在一般情况下通过两两对比，根据一定客观现实的主观判断结构，把专家意见和分析者的客观判断结果直接、有效地结合起来，将一定层次上元素的某些重要性进行定量描述，之后利用数学方法计算反映每一层次元素的相对重要性次序的权值，井最后通过所有层次之间的总排序计算所有元素的相对权重及对权重进行排序。

3.4.7 COSMIC+UML 方法

1. 基于 度量模型 来评估软件架构可维护性的方法。
2. 针对不同表达方式的软件架构，采用统一的软件度量 COSMIC 方法来进行度量和评估。
3. 该方法主要是为了辅助分析软件架构的演化方案是否可行，并在开源软件 DCMMS 的软件架构 UML 组件图上得以验证。