系统架构设计师【第8章】: 系统质量属性与架构评估 (核心总结)

文章目录

8.1 软件系统质量属性

8.1.1 质量属性概念

软件系统质量属性是一个系统的可测量或可测试的属性,基于软件系统的生命周期,可将软件系统的质量属性分为开发期质量属性和运行期质量属性。

1.开发期质量属性

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

2.运行期质量属性

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

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

在架构评估过程中, 评估人员所关注的是系统的质量属性。评估方法所普遍关注的质量属性有以下几种。
1.性能
性能 (Performance) 是指系统的响应能力,即要经过多长时间才能对某个事件做出响应,或者在某段事件内系统所能处理的事件的个数。

提升性能的策略可以从以下几个方面考虑:

  • 资源的需求 : 减少处理事件时对资源的占用、减少处理事件的数量、控制资源的使用。
  • 资源管理 : 并发机制、增加资源。
  • 资源仲裁 : 先来先服务、固定优先级、动态优先级、静态调度。

2.可靠性
可靠性 (Reliability) 是软件系统在应用或系统错误面前,在意外或错误使用的情况下维持软件系统的功能特性的基本能力。

  • (1) 容错。出现错误后仍能保证系统争取运行,且自行修正错误;
  • (2) 健壮性。错误不对系统产生影响,按既定程序忽略错误。

3.可用性
可用性 (Availability) 是系统能够正常运行的时间比例。

提升可用性的策略可以从以下几个方面考虑:

  • 错误检测 : 心跳、Ping/Echo、异常。
  • 错误恢复 : 表决、主动冗余、被动冗余、重新同步、内测、检查点/回滚。
  • 错误避免 : 服务下线、事务、进程监控器。

4.安全性
安全性 (Security) 系统向合法用户提供服务并阻止非法用户的能力。

提升安全性的策略可以从以下几个方面考虑:

  • 抵抗攻击 : 用户身份验证、用户授权、维护数据机密性与完整性、限制暴露、限制访问。
  • 检测攻击 : 入侵检测系统。
  • 从攻击中恢复 : 恢复状态、识别攻击者。

5.可修改性
可修改性 (Modifability) 是指能够快速地以较高的性价比对系统进行变更的能力。包含以下4个

方面:

  • (1)可维护性 (Maintainability)。 局部修复使故障对架构的负面影响最小化。
  • (2)可扩展性 (Extendibility)。 因松散耦合更易实现新特性/功能,不影响架构。
  • (3)结构重组 (Reassemble)。 不影响主体进行的灵活配置。
  • (4)可移植性 (Portability)。 适用于多样的环境(硬件平台、语言、操作系统等)。

提升可修改性的策略可以从以下几个方面考虑:

  • 局部化修改 : 高内聚低耦合、预测变更、使模块通用。
  • 防止连锁反应 : 信息隐藏、维持现有接口、限制通信路径、使用中介。
  • 推迟绑定时间 : 运行时注册、多态、配置文件。

6.功能性
功能性 (Functionality) 是系统能完成所期望的工作的能力。

7.可变性
可变性 (Changeability) 是指架构经扩充或变更而成为新架构的能力。

8.互操作性

通过可视化或接口方式提供更好的交互操作体验

8.1.3 质量属性场景描述

质量属性场景是一种面向特定质量属性的需求,由刺激源、刺激、环境、制品、响应、响应度量组成。

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

8.2 系统架构评估

系统架构评估是在对架构分析、评估的基础上,对架构策略的选取进行决策,通常分为:

  • (1)基于调查问卷或检查表的方法: 缺点是很大程度上依赖于评估人员的主观判断。
  • (2)基于场景的评估方法: 应用在架构权衡分析法(ATAM)和软件架构分析方法(SAAM)中。
  • (3)基于度量的评估方法: 建立质量属性和度量之间的映射原则→在软件文档中获取度量信
    息→分析推导系统质量属性。

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

(1) 敏感点: 实现质量目标时应注意的点,是一个或多个构件的特性。

(2) 权衡点: 影响多个质量属性的敏感点。

(3) 风险承担者或利益相关人: 影响体系结构或被体系结构影响的群体。

(4) 场景: 确定架构质量评估目标的交互机制,一般采用触发机制(教材中解释为"刺激")、环境和影响三方面来描述。

8.2.2 系统架构评估方法

(1)软件架构分析方法(Software Architecture Analysis Method,SAAM)

SAAM 是卡耐基梅隆 大学软件工程研究所的 Kazman 等人于 1983 年提出的一种非功能质量属性的架构分析方法,是最早形成文档并得到广泛应用的软件架构分析方法。SAAM 的主要输入是 问题描述、需求说明和架构描述, 其分析过程主要包括 场景开发、架构描述、单个场景评估、场景交互和总体评估,如图

(2) 架构权衡分析法(Architecture Tradeoff Analysis Method,ATAM)

ATAM 是一种系统架 构评估方法,主要在系统开发之前,针对 性能、可用性、安全性和可修改性 等质量属性进行评价和 折中。传统的 ATAM 可以分为 4 个主要的活动阶段,包括需求收集、架构视图描述、属性模型构 造和分析、架构决策与折中,整个评估过程强调以 属性作为架构评估的核心概念。

现代的 ATAM 方法采用效用树对质量属性进行分类和优先级排序。用 ATAM 方法评估软件体 系结构分为演示、调查和分析、测试和报告,如图 :

(3)成本效益分析法(Cost Benefit Analysis Method,CBAM)

分为整理场景→对场景进行求 精→确定场景的优先级→分配效用→架构策略涉及哪些质量属性及响应级别→使用内插法确定"期 望的"质量属性响应级别的效用→计算各架构策略的总收益→根据受成本限制影响的 ROI 选择架 构策略。

(4)其他评估方法

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

8.3 ATAM方法架构评估实践

用ATAM方法评估软件体系结构,其工作分为4个基本阶段,即 演示、调查和分析、测试、报告ATAM。

8.3.1 阶段1---演示(Presentation)

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

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

8.3.2 阶段2---调查和分析

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

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

8.3.3 阶段3---测试

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

8.3.4 阶段4---报告ATAM

提供评估期间收集的所有信息,呈现给利益相关者。 上述两种主要评估方法的对比,如表:

相关推荐
想进大厂的小王1 小时前
项目架构介绍以及Spring cloud、redis、mq 等组件的基本认识
redis·分布式·后端·spring cloud·微服务·架构
阿伟*rui2 小时前
认识微服务,微服务的拆分,服务治理(nacos注册中心,远程调用)
微服务·架构·firefox
ZHOU西口2 小时前
微服务实战系列之玩转Docker(十八)
分布式·docker·云原生·架构·数据安全·etcd·rbac
deephub4 小时前
Tokenformer:基于参数标记化的高效可扩展Transformer架构
人工智能·python·深度学习·架构·transformer
架构师那点事儿6 小时前
golang 用unsafe 无所畏惧,但使用不得到会panic
架构·go·掘金技术征文
W Y8 小时前
【架构-37】Spark和Flink
架构·flink·spark
Gemini19958 小时前
分布式和微服务的区别
分布式·微服务·架构
ftswsfb14 小时前
【系统架构设计师(第2版)】七、系统架构设计基础知识
系统架构
Dann Hiroaki17 小时前
GPU架构概述
架构
茶馆大橘17 小时前
微服务系列五:避免雪崩问题的限流、隔离、熔断措施
java·jmeter·spring cloud·微服务·云原生·架构·sentinel