8. 系统质量属性与架构评估

发表于 分类于

1 软件体系质量属性

软件系统属性包括功能属性和质量属性，软件架构重点关注的是质量属性。

1.1 质量属性概念

  • 软件系统质量：软件系统与明确需求和隐含需求一致的程度。
  • 维度：功能性、可靠性、易用性、效率、维护性、可移植性。

质量属性评估

软件系统质量属性 (Quality Attribute) 是一个系统的可测量或者可测试的属性，用来描述系统满足利益相关者 (Stakeholders) 需求的程度。基于软件系统的生命周期，可以将软件系统的质量属性分为开发期质量属性和运行期质量属性 2 个部分。

1.1.1 开发期质量属性

易理解性、可扩展性、可重用性、可测试性、可维护性、可移植性。

1.1.2 运行期质量属性

  1. 性能：性能是指软件系统及时提供相应服务的能力，如速度、吞吐量和容量等的要求。
  2. 安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
  3. 可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力。
  4. 互操作性：指本软件系统与其他系统交换数据和相互调用服务的难易程度。
  5. 可靠性：软件系统在一定的时间内持续无故障运行的能力。
  6. 可用性：指系统在一定时间内正常工作的时间所占的比例。可用性会受到系统错误，恶意攻击，高负载等问题的影响。
  7. 鲁棒性：是指软件系统在非正常情况(如用户进行了非法操作、相关的软硬件系统发生了故障等)下仍能够正常运行的能力，也称健壮性或容错性

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

  1. 性能 (Performance)
  • 定义：系统的响应能力，即经过多长时间才能对某个事件做出响应，或系统处理事务的数量或系统完成某个事务处理所需的时间。
  • 常用指标：平均失效间隔时间（MTTF）、平均失效时间（MTBF）。
  1. 可靠性 (Reliability)
  • 定义：软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统功能特性的基本能力。
  • 特性：
    1. 容错：确保系统正确行为。
    2. 健壮性：保持应用程序不受错误使用和错误输入的影响。
  • 常用指标：平均失效时间（MTTF）和平均失效间隔时间（MTBF）。
  1. 可用性 (Availability)
  • 定义：系统能够正常运行的时间比例。
  • 特性：
    1. 安全性：提供服务能力。
    2. 可伸缩性：处理用户数量增加。
    3. 互操作性：与其他系统交换数据。
    4. 可管理性：持续工作比例。
  1. 安全性 (Security)
  • 定义：系统在向合法用户提供服务的同时能够防止非授权用户使用系统或拒绝服务的能力。
  • 特性：
    1. 机密性：防止信息泄露。
    2. 完整性：防止信息篡改。
    3. 可控性：防止信息传播。
    4. 可审计性：记录系统活动。
  1. 可修改性 (Modifability)
  • 定义：快速修改系统性能的能力。
  • 特性：
    1. 可维护性：修复错误。
    2. 可扩展性：添加新功能。
    3. 结构重组：重新组织软件。
    4. 可移植性：系统迁移。
  1. 功能性 (Functionality)
  • 定义：系统完成预期工作的能力。
  1. 可变性 (Changeability)
  • 定义：适应新架构的能力。
  1. 互操作性
  • 定义：与其他系统交互操作的能力。

1.3 质量属性场景描述

通常采用质量属性场景 (Quality Attribute Scenario) 作为描述质量属性的手段。质量属性场景是一个具体的质量属性需求，是利益相关者与系统的交
互的简短陈述。

质量属性场景是一种面向特定质量属性的需求。它由 6 部分组成：

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

质量属性场景主要关注性能、可用性、安全性、可修改性、可测试性和易用性等 6 类质量属性，下面分别列表进行介绍。

  1. 性能质量属性场景
  • 性能质量属性场景主要关注系统的响应速度，可以通过效率、响应时间、吞吐量、负载来客观评价性能的好坏。
  1. 可用性质量属性场景
  • 可用性质量属性场景所关注的方面包括系统故障发生的频率、出现故障时会发生什么情况、允许系统有多长是非正常运行、什么时候可以安全地出现故障、如何防止故障的发生以及发生故障时要求进行哪种通知。
  1. 安全性质量属性场景
  • 安全性质量属性场景主要关注系统在安全性方面的要素，衡量系统在向合法用户提供服务的同时，阻止非授权用户使用的能力。
  1. 可修改性质量属性场景
  • 可修改性质量属性场景主要关注系统在改变功能、质量属性时需要付出的成本和难度，可修改性质量属性场景可能发生在系统设计、编译、构建、运行等多种情况和环境下。
  1. 可测试性质量属性场景
  • 可测试性质量属性场景主要关注系统测试过程中的效率，发现系统缺陷或故障的难易程度等。
  1. 易用性质量属性场景
  • 易用性质量属性场景主要关注用户在使用系统时的容易程度，包括系统的学习曲线、完成操作的效率、对系统使用过程的满意程度等。

2 系统架构评估

系统架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。它利用数学或逻辑分析技术，针对系统的一致性、正确性、质量属性、规划结果等不同方面，提供描述性、预测性和指令性的分析结果。

系统架构评估方法

  1. 基于调查问卷或检查表的方法
  • 利用系统相关人员的经验和知识，获得对架构的评估。
  1. 基于场景的方法
  • 基于场景的方式由卡耐基梅隆大学提出，包括架构权衡分析法（ATAM）和软件架构分析法（SAAM）。
  1. 基于度量的方法
  • 涉及 3 个基本活动：建立质量度量之间的映射原则，从软件架构文档中获取度量信息，根据映射原则分析推导出系统的质量属性。

2.1 系统架构评估的重要概念

  1. 敏感点 (Sensitivity Point) 和权衡点 (Tradeoff Point)
  • 敏感点：关键架构决策，影响质量目标。
  • 权衡点：影响多个质量属性的特性。
  1. 风险承担者 (Stakeholders) 或者称为利益相关人
  • 定义：与架构设计和实现相关的人员或实体。
  • 角色：系统架构师、开发人员、维护人员等。
  1. 场景 (scenarios)
  • 定义：从风险承担者角度对与系统的交互的简短描述。
  • 描述：一般采用刺激 (Stimulus)、 环境(Environment) 和响应 (Response) 三个方面来对场景进行描述。

2.2 系统架构评估方法

2.2.1 SAAM 方法

  • SAAM（Scenarios-based Architecture Analysis Method）：基于场景的架构分析方法。
  • 目标：描述应用程序属性的文档，验证架构假设和原则。

2.2.2 ATAM 方法

  • ATAM（Architecture Tradeoff Analysis Method）：权衡分析方法。
  • 目标：评估架构的可修改性、性能、安全性和可用性。

2.2.3 CBAM 方法

在大型复杂系统的构建过程中，经济性通常是需要考虑的首要因素。因此，需要从经济角度建立成本、收益、风险和进度等方面软件的“经济”模型。成本效益分析法 (the Cost BenefitAnalysis Method,CBAM) 是在 ATAM 上构建，用来对架构设计决策的成本和收益进行建模，是优化此类决策的一种手段。

CBAM 在 ATAM 结束时开始，它实际上使用了 ATAM 评估的结果。

2.2.4 其他评估方法

  1. SAEM 方法：将软件架构看作一个最终产品以及涉及过程中的一个中间产品，从外部质量属性和内部质量属性阐述的评估模型。
  2. SAABNet 方法：辅助架构的定性评估，帮助诊断软件问题的可能原因，分析架构中的修改给质量属性带来的影响、预测架构的质量属性，帮助架构设计人员做决策。SAABNet 度量的对象包括架构属性、质量准则和质量因素。
  3. SACMM 方法：一种软件架构修改的度量方法，首先基于内核定义差异度量准则来计算两个软件架构之间的距离，然后分析对象之间的相似性。
  4. SASAM 方法：通过对预期架构和实际架构进行映射和比较来静态地评估软件架构。
  5. ALRRA 方法：是软件架构可靠性风险评估方法，使用动态复杂度准则和动态耦合度准则来定义组件和连接件的复杂性因素。
  6. AHP 方法：把定性分析和定量计算相结合，对各种决策因素进行处理。
  7. COSMIC + UML 方法：针对不同表达方式的软件架构，采用统一的软件度量 COSMIC 方法来进行度量和评估。

3 ATAM 方法架构评估实践

3.1 阶段1—演示（Presentation）

使用 ATAM 评估软件体系结构的初始阶段，包括 3 个步骤：

  1. 介绍 ATAM：描述 ATAM 评估过程。
  2. 介绍业务驱动因素：着重业务视角，提供有关系统功能、主要利益相关方、业务目标和其他限制等信息。
  3. 介绍要评估的体系结构：侧重可用性以及体系结构的质量要求。

3.2 阶段2—调查和分析

使用 ATAM 技术评估架构第 2 阶段，对一些关键问题彻底调查，包括 3 个步骤：

  1. 确定架构方法：涉及能够理解系统关键需求的关键架构方法。
  2. 生成质量属性效用树：确定最重要的质量属性，并确定优先次序。
  3. 分析体系结构方法：彻底调查和分析，找出处理相应质量属性架构的方法。包括 4 个主要阶段：调查架构方法→创建分析问题→分析问题的答案→找出风险、非风险、敏感点和权衡点。

3.3 阶段3—测试

  1. 头脑风暴和优先场景：将头脑风暴的优先列表与生成质量属性效用树中所获取的优先方案进行比较。
  2. 分析架构方法

3.4 阶段4—报告 ATAM

提供评估期间收集的所有信息，呈现给利益相关者。

4 我的总结

本章晦涩难懂，前期主要考 kimi 度过，后期地 3.3 章节直接拷贝了《考试32小时通关-第2版（2023）》的内容。