【系统架构设计师】十二、系统质量属性与架构评估(开发期质量属性|运行期质量属性|面向架构评估的质量属性|质量属性效用树|质量属性场景)

一、软件系统质量属性

1.1 开发期质量属性

1.2 运行期质量属性

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

1.4 质量属性效用树

1.5 质量属性场景

1.5.1 可用性质量属性场景描述

1.5.2 可修改性质量属性场景描述

1.5.3 性能质量属性场景描述

一、软件系统质量属性

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

1.1 开发期质量属性

开发期质量属性主要指在软件开发阶段所关注的质量属性，主要包含6个方面。

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

1.2 运行期质量属性

运行期质量属性主要指在软件运行阶段所关注的质量属性，主要包含7个方面。

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

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

为了评价一个软件系统，特别是软件系统的架构，需要进行架构评估。在架构评估过程中，
评估人员所关注的是系统的质量属性。

(1)性能：指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量。
设计策略：优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。

(2)可靠性：是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。如MTTF、MTBF、MTTR。
设计策略：心跳、Ping/Echo、冗余、选举

(3)可用性：是系统能够正常运行的时间比例，经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。如故障间隔时间。
设计策略：心跳、Ping/Echo、冗余、选举。

(4)安全性：是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性。
设计策略：入侵检测、用户认证、用户授权、追踪审计。

(5)可修改性：指能够快速的以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量。包含以下4个方面：
a.可维护性，局部修复使故障对架构的负面影响最小化；
b.可扩展性，因松散耦合更易实现新特性/功能，不影响架构；
c.结构重组，不影响主体进行的灵活配置；
d.可移植性，适用于多样的环境（硬件平台、语言、操作系统等）。
设计策略：接口-实现分类、抽象、信息隐藏。

(6)功能性：是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。

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

(8)互操作性：作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，也影响应用的软件体系结构。

1.4 质量属性效用树

质量属性效用树（Utility Tree）是一种树状结构，其根节点代表系统的整体质量，而子节点则代表不同的质量属性（如性能、可修改性、可用性、安全性等）。这些质量属性进一步被分解为更具体的场景，每个场景都描述了系统在使用过程中可能遇到的情况或需求。

1.5 质量属性场景

质量属性场景 (Quality Attribute Scenario) 作为描述质量属性的手段。质量属性场景是一个具体的质量属性需求，是利益相关者与系统的交互的简短陈述。
        质量属性场景是一种面向特定质量属性的需求。它由6部分组成：
        (1)刺激源 (Source)：这是某个生成该刺激的实体(人、计算机系统或者任何其他刺激器)。
        (2)刺激 (Stimulus)：该刺激是当刺激到达系统时需要考虑的条件。
        (3)环境 (Environment)：该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况。
        (4)制品 (Artifact)：某个制品被激励。这可能是整个系统，也可能是系统的一部分。
        (5)响应 (Response)：该响应是在激励到达后所采取的行动。
        (6)响应度量 (Measurement)：当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。

质量属性场景主要关注可用性、可修改性、性能、可测试性、易用性和安全性等6类质量属性。质量属性描述场景在2024年5月份的时候考到了哦。

1.5.1 可用性质量属性场景描述

可用性质量属性场景描述
场景要素	可能的情况
刺激源	系统内部、系统外部
刺激	疏忽、错误、崩溃、时间
环境	正常操作、降级模式
制品	系统处理器、通信信道、持久存储器、进程
响应	系统应该检测事件、并进行如下一个或多个活动：将其记录下来通知适当的各方，包括用户和其他系统；根据已定义的规则禁止导致错误或故障的事件源。在一段预先指定的时间间隔内不可用，其中，时间间隔取决于系统的关键程度在正常或降级模式下运行。
响应度量	系统必须可用的时间间隔可用时间系统可以在降级模式下运行的时间间隔故障修复时间

1.5.2 可修改性质量属性场景描述

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

1.5.3 性能质量属性场景描述

性能质量属性场景描述
场景要素	可能的情况
刺激源	用户请求，其他系统触发等
刺激	定期事件到达、随机事件到达、偶然事件到达
环境	正常模式、超载 (Overload)模式
制品	系统
响应	处理刺激、改变服务级别
响应度量	等待时间、期限、吞吐量、抖动、缺失率、数据丢失率

还有可测试性、易用性和安全性质量属性场景描述没有提供，可以自己参考着写一下。

历年真题练习

1.某公司欲开发一个网上商城系统，在架构设计阶段，公司的架构师识别出3个核心质量属性场景。其中"系统主站断电后，能够在2分钟内自动切换到备用站点，并恢复正常运行"主要与(1)质量属性相关通常可采用(2)架构策略实现该属性;"在并发用户数不超过1000人时，用户的交易请求应该在0.5s内完成'主要与(3)质量属性相关，通常可采用(4)架构策略实现该属性;"系统应该能够抵挡恶意用户的入侵行为，并进行报警和记录"主要与(5)质量属性相关，通常可采用(6)架构策略实现该属性

(1):A.性能        B.可用性 C.易用性 D.可修改性
        (2):A.主动冗余 B.信息隐藏 C.抽象接口 D.记录/回放
(3):A.性能        B.可用性 C.易用性 D.可修改性
(4):A.操作串行化 B.资源调度 C.心跳 D.内置监控器
        (5):A.可用性 B.安全性 C.可测试性 D.可修改性
        (6):A.内置监控器 B.记录/回放 C.追踪审计 D.维护现有接口

人工分割线-答案

    1.B、A
        A、B
B、C