《系统架构设计师教程（第2版）》第8章-系统质量属性与架构评估-01-软件系统质量属性

1. 质量属性概念

1.1 软件系统质量

• 软件系统质量：

  • 软件与需求文档中明确描述的开发标准，以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度

• 影响软件质量的主要因素

  • 功能性：适合性、准确性、互操作性、依从性、安全性
  • 可靠性：容错性、易恢复性、成熟性
  • 易用性：易学性、易理解性、易操作性
  • 效率：资源特性、时间特性
  • 维护性：可测试性、可修改性、稳定性、易分析性
  • 可移植性：适应性、易安装性、一致性、可替换性

1.2 软件质量属性概述

• 软件系统质量属性
  • Quality Attribute
  • 是系统的可测量或者可测试的属性
  • 用来描述系统满足利益相关者 (Stakeholders) 需求的程度

1.3 各生命周期的质量属性

1.2.1 开发期质量属性

• 易理解性：指设计被开发人员理解的难易程度。
• 可扩展性：软件因适应新需求或需求变化而增加新功能的能力，也称为灵活性。
• 可重用性：指重用软件系统或某一部分的难易程度。
• 可测试性：对软件测试以证明其满足需求规范的难易程度。
• 可维护性：当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度。
• 可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。

1.2.2 运行期质量属性

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

  如：用户进行了非法操作、相关的软硬件系统发生了故障等

2. 面向架构评估的质量属性

• 在架构评估过程中，评估人员所关注的是系统的质量属性
• 普遍关注的质量属性有以下几种：

2.1 性能(Performance)

• 概念 ：指系统的响应能力
• 定量表示：
  • 单位时间内所处理事务的数量
  • 系统完成某个事务处理所需的时间
• 性能测试经常要使用基准测试程序

2.2 可靠性 (Reliability)

• 概念：软件系统在意外或错误使用的情况下维持软件系统的功能特性的基本能力
• 作用：衡量在规定的条件和时间内，软件完成规定功能的能力
• 衡量：
  • 平均失效等待时间 (Mean Time To Failure,MTTF)
  • 平均失效间隔时间 (Mean Time Between Failure,MTBF)

在失效率为常数和修复时间很短的情况下， MTTF 和 MTBF几乎相等

• 提升可靠性：冗余机制、集成监控构件、异常处理
• 可靠性可以分为两个方面。

2.2.1 容错

• 概念：错误发生时确保系统正确，并进行内部“修复”

2.2.2 健壮性

• 概念：在发生意外错误事件时确保应用系统处于预先定义好的状态。
• 和容错比较：只保证应用系统处于预先定义好的状态（并不一定保证系统继续运行）

2.3 可用性 (Availability)

• 概念 ：系统能够正常运行的时间比例
• 衡量：
  • 两次故障之间的时间长度
  • 故障时，系统恢复正常的速度

2.4 安全性 (Security)

• 概念：系统向合法用户提供服务的同时，阻止非授权用户使用的能力
• 根据安全威胁类型来分类：
  • 机密性：保证信息不泄露给未授权的用户、实体或过程。
  • 完整性：保证信息的完整和准确，防止信息被非法修改
  • 不可否认性：信息交换的双方不能否认其在交换过程中发送信息或接收信息的行为
  • 可控性：保证对信息的传播及内容具有控制的能力，防止为非法者所用。

2.5 可修改性

• 概述
  • Modifability
  • 指能够快速地以较高的性价比对系统进行变更的能力
  • 衡量：通过考查变更的代价来衡量可修改性
• 可修改性包含以下4个方面：

2.5.1 可维护性 (Maintainability)

这主要体现在问题的修复上，可维护性好的软件架构往往能做局部性的修改并能使对其他构件的负面影响最小化。

2.5.2 可扩展性 (Extendibility)

• 关注点：
  • 使用新特性来扩展软件系统
  • 使用改进版本方式来替换构件（并删除不需要或不必要的特性和构件）
• 目标：现一种架构
  • 在不影响构件客户的情况下替换构件
  • 新构件集成到现有的架构中
• 实现方法：软件系统需要松散耦合的构件

2.5.3 结构重组 (Reassemble)

• 概念：重新组织软件系统的构件及构件间的关系
  • 举例：通过将构件移动到一个不同的子系统而改变它的位置
• 实现方法：精心设计构件之间的关系

  理想情况下，它们允许开发人员在不影响实现的主体部分的情况下灵活地配置构件。

2.5.4 可移植性 (Portability)

• 概念：系统能够在不同计算环境下运行的能力

  • 其环境包括：硬件、软件、软硬结合

  使软件系统适用于多种硬件平台、用户界面、操作系统、编程语言、编译器

• 实现方法：按照硬件、软件无关的方式组织软件系统

2.6 功能性 (Functionality)

• 概念：系统能完成所期望的工作的能力

2.7 可变性(Changeability)

• 概念：指架构经扩充或变更而成为新架构的能力
• 当要将某个架构作为一系列相关产品的基础时，可变性是很重要的 (如，软件产品线)。

2.8 互操作性

• 概念：与其他系统或自身环境相互作用
• 实现方法：软件架构必须设计软件入口

3. 质量属性场景描述

3.1 概述

3.1.1 质量场景属性的概念

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

3.1.2 组成成分：

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

3.2 几个质量属性场景

3.2.1 可用性质量属性场景

• 关注的方面：
  • 系统故障发生的频率
  • 出现故障时会发生什么情况
  • 允许系统有多长时间是非正常运行
  • 什么时候可以安全地出现故障
  • 如何防止故障的发生
  • 发生故障时要求进行哪种通知
• 其质量场景
  • 刺激源：系统内部、系统外部
  • 刺激：疏忽、错误、崩溃、时间
  • 环境：正常操作、降级模式
  • 制品：系统处理器、通信信道、持久存储器、进程
  • 响应：系统应该检测事件、并进行如下一个或多个活动：
    • 将其记录下来通知适当的各方（用户和其他系统）
    • 根据已定义的规则禁止导致错误或故障的事件源
    • 在一段预先指定的时间间隔内不可用，其中，时间间隔取决于系统的关键程度在正常或降级模式下运行
  • 响应度量：
    • 系统必须可用的时间间隔
    • 可用时间
    • 系统可以在降级模式下运行的时间间隔
    • 故障修复时间

3.2.2 可修改性质量属性场景

• 主要关注：
  • 系统在改变功能、质量属性时需要付出的成本和难度
• 其质量场景
  • 刺激源：最终用户、开发人员、系统管理员
  • 刺 激：希望增加、删除、修改、改变功能、质量属性、容量等
  • 环境：系统设计时、编译时、构建时、运行时
  • 制品：系统用户界面、平台、环境或与目标系统交互的系统
  • 响应：
    • 查找架构中需要修改的位置
    • 进行修改且不会影响其他功能
    • 对所做的修改进行测试
    • 部署所做的修改
  • 响应度量：
    • 根据所影响元素的数量度量的成本、努力、资金
    • 该修改对其他功能或质量属性所造成影响的程度

3.2.3 性能质量属性场景

• 主要关注：系统的响应速度
• 评价：效率、响应时间、吞吐量、负载
• 其质量场景
  • 刺激源：用户请求，其他系统触发等
  • 刺激：定期事件到达、随机事件到达、偶然事件到达
  • 环境：正常模式、超载 (Overload) 模式
  • 制 品：系统
  • 响应：处理刺激、改变服务级别
  • 响应度量：等待时间、期限、吞吐量、抖动、缺失率、数据丢失率

3.2.4 可测试性质量属性场景

• 主要关注：系统测试过程中的效率，发现系统缺陷或故障的难易程度等
• 其质量场景
  • 刺激源：开发人员、增量开发人员、系统验证人员、客户验收测试人员、系统用户
  • 刺激：已完成的分析、架构、设计、类和子系统集成；所交付的系统
  • 环境：设计时、开发时、编译时、部署时
  • 制品：设计、代码段、完整的应用
  • 响应：提供对状态值的访问，提供所计算的值，准备测试环境
  • 响应度量：
    • 已执行的可执行语句的百分比
    • 如果存在缺陷出现故障的概率
    • 执行测试的时间
    • 测试中最长依赖的长度
    • 准备测试环境的时间

3.2.5 易用性质量属性场景

• 主要关注：用户在使用系统时的容易程度
  • 包括系统的学习曲线、完成操作的效率、对系统使用过程的满意程度等
• 其质量场景
  • 刺激源：最终用户
  • 刺激：想要学习系统特性、有效使用系统、使错误的影响最低、适配系统、对系统满意
  • 环境：系统运行时或配置时
  • 制品：系统
  • 响应：
    • 系统提供以下一个或多个响应来支持“学习系统特性”
      • 帮助系统与环境联系紧密
      • 界面为用户所熟悉
      • 在不熟悉的环境中，界面是可以使用的
    • 系统提供以下一个或多个响应来支持“有效使用系统”:
      • 数据和(或)命令的聚合
      • 已输入的数据和(或)命令的重用
      • 支持在界面中的有效导航
      • 具有一致操作的不同视图
      • 全面搜索
      • 多个同时进行的活动
    • 系统提供以下一个或多个响应来“使错误的影响最低”:
      • 撤销
      • 取消
      • 从系统故障中恢复
      • 识别并纠正用户错误
      • 检索忘记的密码
      • 验证系统资源
    • 系统提供以下一个或多个响应来“适配系统”:
      • 定制能力
      • 国际化
    • 系统提供以下一个或多个响应来使客户“对系统的满意”:
      • 显示系统状态
      • 与客户的节奏合拍
  • 响应度量：任务时间、错误数量、解决问题的数量、用户满意度、用户知识的获得、成功操作在总操作中所占的比例、损失的时间/丢失的数据量

3.2.6 安全性质量属性场景

• 主要关注：系统在安全性方面的要素
• 其质量场景
  • 刺激源：
    • 正确识别、非正确识别的来自内部/外部的个人或系统
  • 刺激：试图显示数据，改变/删除数据，访问系统服务，降低系统服务的可用性
  • 环境：在线或离线、联网或断网、连接有防火墙或者直接连到了网络
  • 制品：系统服务、系统中的数据
  • 响应：
    • 对用户身份进行认证
    • 隐藏用户的身份
    • 阻止对数据或服务的访问
    • 允许访问数据或服务
    • 授予或收回对访问数据或服务的许可
    • 根据身份记录访问、修改或试图访问、修改数据、服务
    • 以一种不可读的格式存储数据
    • 识别无法解释的对服务的高需求
    • 通知用户或另外个系统，并限制服务的可用性
  • 响应度量：
    • 用成功的概率表示，避开安全防范措施所需要的时间、努力、资源
    • 检测到攻击的可能性
    • 确定攻击或访问、修改数据或服务的个人的可能性
    • 在拒绝服务攻击的情况下仍然获得服务的百分比
    • 恢复数据、服务
    • 被破坏的数据、服务和(或)被拒绝的合法访问的范围

---