系统架构设计高级技能 · 系统质量属性与架构评估

系列文章目录

系统架构设计高级技能 · 软件架构概念、架构风格、ABSD、架构复用、DSSA（一）【系统架构设计师】
系统架构设计高级技能 · 系统质量属性与架构评估（二）【系统架构设计师】
系统架构设计高级技能 · 软件可靠性分析与设计（三）【系统架构设计师】

现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.

系统架构设计 · 系统质量属性与架构评估（二）

• 系列文章目录
• 一、软件系统质量属性的概念★★★
• 1.1 开发期的质量属性
• 1.2 运行期的质量属性
• 二、面向架构评估的质量属性
• 2.1 性能
• 2.3 可用性
• 2.4 安全性
• 2.3 可修改性
• 2.4 易用性
• 2.5 可测试性
• 2.6 可靠性
• 2.7 功能性
• 2.8 可变性
• 2.9 互操作性
• 三、质量属性场景描述
• 四、系统架构评估
• 4.1 系统架构评估的重要概念
• 4.1.1敏感点、权衡点、风险点、非风险点
• 4.1.2 风险承担者或者相关利益人
• 4.1.3 场景
• 4.2 系统架构评估方法
• 4.2.1 基于场景 - 软件架构分析法SAAM
• 4.2.2 基于场景 - 架构权衡分析法ATAM
• 4.2.3 质量属性效用树

一、软件系统质量属性的概念★★★

1.1 四大质量属性

性能	单位时间可以做的事情，或做完一定数量事情耗费的时间
可用性	系统正常运行的时间比例
可修改性	可扩展性	系统扩展新构件对其他构件的影响程度
	可维护性	系统修改旧的构建以对对其他构件的影响程度
	结构重组	重新组织系统构建之间关系的难易程度
	可移植性	在不同硬件平台、操作系统、编程语言间移植的难易程度
可靠性	容错性和健壮性，系统面对错误输入仍能保持系统功能的基本能力
安全性	系统阻止非法用户访问的能力
易用性	系统使用的难易程度

敏感点： 为了实现某种质量属性，一个或多个系统组件所具有的特性。

权衡点： 指影响多个质量属性，并对多个质量属性来说都是敏感点的系统属性。

风险点： 架构风险是指在架构设计中潜在的、存在问题的架构决策所带来的隐患。

二、面向架构评估的质量属性

在架构评估过程中，评估人员所关注的是系统的质量属性。

2.1 性能

性能（performance）是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。

例如：

• 同时支持1000并发
• 响应时间小于1s
• 显示分辨率达到4K

提升性能的策略（性能战术）可以从以下几个方面考虑：

• 资源需求 ：
  ①提高计算效率、②减少计算开销、③管理（减少处理事件数量）事件率、④控制采样频率（控制资源的使用）
• 资源管理 ：
  ①引入并发机制、②维持多个副本、③增加可用资源
• 资源仲裁 ：
  资源调度策略：①先进先出、②固定优先级、③动态优先级、④静态调式

2.3 可用性

可用性（availability）是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。

例如：

• 主服务器故障，1分钟内切换至备用服务器
• 系统故障，1小时内修复
• 系统支持7×24小时工作

提升可用性的策略（可用性战术）可以从以下几个方面考虑：

• 错误检测 ：
  ①命令/响应【Ping/Echo】、②心跳、③异常
• 错误恢复 ：
  ①表决、②冗余【主动/被动】、③备份【重新同步、内测、检查点/回滚】
• 错误避免 ：
  ①进程监视器、②事务、③从服务器删除【服务下线】

2.4 安全性

安全性（security）是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。

例如：

• 可抵御SQL注入攻击
• 对计算机的操作都有完整记录（日志，审计追踪）
• 用户信息数据库授权必须保证99.9%可用

提升安全性的策略（安全性战术）可以从以下几个方面考虑：

• 抵抗攻击 ：
  ①用户身份验证、②用户授权、③维护数据机密性和完整性、④限制暴露、⑤限制访问
• 检测攻击 ：
  ①入侵系统检测
• 从攻击中恢复 ：
  ①识别攻击者：审计追踪、②恢复状态：冗余【与可用性重叠】

2.3 可修改性

可修改性（modifiability）是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。

例如：

• 更改系统报表模块，必须在2人周内完成
• 对Web界面风格进行修改，修改必须在4人月内完成

可修改性分为四个子属性：
可维护性：局部修复使故障对架构的负面影响最小化。
可扩展性：因松散的耦合更易实现新特性/功能，不影响架构。
结构重组：不影响主体进行的灵活配置。
可移植性：适用于多样的环境（硬件平台、语言、操作系统等）。

提升性能的策略（可修改行战术）可以从以下几个方面考虑：

• 局部化修改 ：
  ①高内聚低耦合、②预测变更、③使模块通用、④泛化模块、⑤维持语义的一致性、⑥限制可能的选择、⑦抽象通用服务
• 防止连锁反应 ：
  ①隐藏信息、②维持现有接口、③限制通信路径、④使用仲裁者
• 推迟绑定时间 ：
  ①运行时注册、②配置文件、③多态、④组件更换、⑤遵守已定义的协议

2.4 易用性

易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类。

例如：

• 界面友好
• 新用户学习使用系统时间不超过2小时

2.5 可测试性

软件可测试性是指通过测试揭示软件缺陷的容易程度。

例如：

• 提供远程调试接口，支持远程调试

2.6 可靠性

分为两个子属性：
容错性：出错后仍能保证系统争取运行，且自行修正错误。
健壮性：错误不对系统产生影响，按既定程序忽略错误。

2.7 功能性

需求的满足程度。

2.8 可变性

总体架构可变。

2.9 互操作性

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

三、质量属性场景描述

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

四、系统架构评估

架构评估的基准是架构质量属性。

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

4.1.1敏感点、权衡点、风险点、非风险点

敏感点（Sensitivity Point） ：是一个或多个构件（和/或构件之间的关系）的特性。

权衡点（Tradeoff Point） ：是影响多个质量属性的特性，是多个质量属性的敏感点。

风险点（Risk Point ） ：是指架构设计中潜在的、存在问题的架构决策所带来的隐患。

非风险点（Non-Risk Point ） ：是指不会带来隐患，一般以“XXX要求是可以实现（或接受）的”方式表达。

例如：

• 对交易请求处理时间的要求将影响系统的数据传输协议和处理过程的设计（敏感点）
• 假设每秒中用户交易请求的数量是10个，处理请求的时间为30毫秒，则“在1秒内完成用户的交易请求”这一要求是可以实现的 （非风险点）
• 目前对系统信用卡支付业务逻辑的描述尚未达成共识，这可能导致部分业务功能模块的重复，影响系统的可修改性 （风险点）
• 更改加密的级别将对安全性和性能产生影响 （权衡点）

4.1.2 风险承担者或者相关利益人

影响体系结构或被体系结构影响的群体。

4.1.3 场景

确定架构质量评估目标的交互机制，一般采用触发机制（刺激）、环境和影响三方面来考虑。

4.2 系统架构评估方法

架构的评估方法通常分为3类：

• 基于调查问卷或检查表的评估方法
  是指组织相关人员进行评估，这种方式最简单易行，但是主观性强。

• 基于度量的评估方法
  强调量化指标，最客观，但是这种方式实施难度大，因为需要评估者对系统非常熟悉，不然很难量化清楚各项指标。

• 基于场景的评估方法
  筛选出系统的关键场景，根据系统在不同场景中的表现进行评估，这种方式客观程度介于2者之间，这也是目前较为流行的结构评估方法。

基于场景的方式主要有三种（前2种方式用得比较多）：

• 软件架构分析法（SAAM，Software Architecture Analysis Method）
• 架构权衡分析法（ATAM，Architecture Tradeoff Analysis Method）
• 成本效益分析法（CBAM，the Cost Benefit Analysis Method）

4.2.1 基于场景 - 软件架构分析法SAAM

SAAM，最初用于分析架构可修改性，后扩展到其它质量属性。
SAAM分析评估架构的过程包括5个步骤 ，如下图：
（1）场景开发
（2）架构描述
（3）单个场景评估
（4）场景交互评估
（5）整体评估

图4_1 SAAM分析评估过程

4.2.2 基于场景 - 架构权衡分析法ATAM

架构权衡分析法（ATAM，Architecture Tradeoff Analysis Method）是 在SAAM上发展而来。核心是结合质量属性效用树对系统进行评价 ，确定风险点、敏感点、权衡点，并对系统架构做出决策和折中。整个评估过程 强调以质量属性作为评估核心，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

ATAM分成4个阶段，如下图：
（1）场景和需求收集
（2）架构视图和场景实现
（3）质量模型构造和分析
（4）质量模型折中

图4_2 ATAM分析评估过程

4.2.3 质量属性效用树

质量属性效用树：识别质量属性并排序，主要包含性能、可用性、可修改性、安全性四个方面。

性能：性能延时（将用户数据库存储延迟到了最小值300ms，提供了实时的视频图像），交易吞吐量（使认证服务器的平均吞吐量最大化）。

可修改性：新增产品目录，商业产品修改（已小于20人月的工作量添加CORBA中间件，以小于4人周的工作量更改web界面）。

可用性：硬件故障（若站点A断电，要求在3秒内将任务重定向到站点B，若磁盘出现故障，要求在5分钟内重新启动，要在1-5分钟之内检测并恢复网络故障），商业软件故障。

安全性：数据机密性（信用卡交易在99.999%的时间内是安全的，客户数据库z认证在99.999%的时间内能正常工作），数据完整性。

质量属性效用树，示例图如下：

                                                   图4_3 质量属性效用树

SAAM（Scenarios-based Architecture Analysis Method，基于场景的架构分析方法 ）是卡耐基梅隆大学软件工程研究所的。Kazman等人于1983年提出的。最早用于比较不同软件体系的体系结构，以分析SA（软件架构）的可修改性 。后来实践证明也可用于其他的质量属性。如可移植性、可扩充性等，发展成为一个系统的体系结构。

• 特定目标

SAAM的目标是对描述应用程序属性的文档，验证基本的体系结构假设和原则。此外，该分析方法有利于评估体系结构固有的风险。SAAM指导对体系结构的检查，使其主要关注潜在的问题点，如需求冲突，$仅从某一参与者的观点出发的不全面的系统设计。SAAM不仅能够评估体系结构对于特定系统需求的使用能力，也能被用来比较不同的体系结构。

• 评估技术

SAAM所使用的评估技术是场景技术。场景代表了描述体系结构属性的基础，描述了各种系统必须支持的活动和将要发生的变化

• 风险承担者

SAAM协调不同参与者所感兴趣的方面，作为后续决策的基础，提供了对体系结构的公共理解。

• 体系结构描述

SAAM用于体系结构的最后版本，但早于详细设计。体系结构的描述形式应当被所有参与者理解。功能、结构和分配被定义为描述体系结构的三个主要方面。

• 方法活动

SAAM的主要输入问题是问题描述、需求声明和体系结构描述 。

• 目前知识库的可用性

SAAM不考虑这个问题。

• 方法验证

SAAM是一种成熟的方法，已被应用到众多系统中，这些系统包括空中交通管制、嵌入式音频系统、WRCS（修正控制系统）、KWIC[8]（根据上下文查找关键词系统）等。

体系结构全会分析方法（Architecture Tradeoff Analysis Method），是在SAAM的基础上发展起来的，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

• 特定目标

ATAM的目标是在考虑多个相互影响的质量属性的情况下，从原则上提供一种理解软件体系结构的能力的方法。对于特定的软件体系结构，在系统开发之前，可以使用ATAM方法确定在多个质量属性之间折中的必要性。

• 质量属性

ATAM方法分析多个相互竞争的质量属性。开始时考虑的是系统的可修改性、安全性、性能和可用性。

• 风险承担者

在场景、需求收集有关的活动中，ATAM方法需要所有系统相关人员的参与。

• 体系结构描述

体系结构空间受到历史遗留系统、互操作性和以前失败的项目约束。在5个基本结构的基础上进行体系结构描述，这5个结构是从Kruchten的4+1视图派生而来的。其中逻辑视图被分为功能结构和代码结构。这些结构加上它们之间适当的映射可以完整地描述一个体系结构。

用一组消息顺序图显示运行时的交互和场景，对体系结构描述加以注解。ATAM方法被用于体系结构设计中，或被另一组分析人员用于检査最终版本的体系结构。

• 评估技术

可以把方法视为一个框架，该框架依赖于质量属性，可以使用不同的分析技术。它集成了多个优秀的单一理论模型，其中每一个都能够髙效、实用地处理属性。该方法使用了场景技术。从不同的体系结构角度，有三种不同类型的场景，分别是用例（包括对系统典型的使用，还用于引出信息）、增长场景（用于涵盖与它的系统修改）、探测场景（用于涵盖那些可能会对系统造成压迫的极端修改）。

ATAM还使用定性的启发式分析方法（QualitativeAnalysisHeuristics），在对一个质量属性构造了一个精确分析模型时要进行分析，定性的启发式分析方法就是这种分析的粗粒度版本。

• 方法的活动

ATAM被分为4个主要的活动领域（或阶段），分别是场景和需求收集、体系结构视图和场景实现、属性模型构造和分析 。

• 领域知识库的可重用性

领域知识库通过基于属性的体系结构风格（Attribute-BasedArchitectareStyle）维护。ABAS有助于从体系结构风格的概念转向基于特定质量属性模型的推理能力。获取一组基于属性的体系结构风格的目标在于要把体系结构设计变得更为惯例化、更可预测，并得到一个基于属性的体系结构分析的标准问题集合，使设计与分析之间的联系更为紧密。

• 方法验证

该方法已经应用到多个软件系统，但仍处于研究之中。虽然软件体系结构分析与评价已经取得了很大的进步，但是在某方面也存在一些问题。例如，习题结构的描述、质量特征的分析、场景不确定性的处理、度量的应用体系结构分析和评价支持工具等。这些都影响和制约着分析评估技术的发展。