软考架构师【第八章】系统质量属性与架构评估

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

架构的基本需求是在满足功能属性的前提下，关注软件系统质量属性。

为了精确、定量地表达系统的质量属性，通常会采用质量属性场景的方式进行描述。

软件系统架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。

8.1软件系统质量属性

8.1.1质量属性概念

软件系统的质量就是"软件系统与明确地和隐含地定义的需求相一致的程度"。

软件系统质量是软件与明确地叙述的功能和性能需求文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。

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

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

基于软件系统的生命周期，可以将软件系统的质量属性分为开发期质量属性和运行期质量属性2个部分。

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

运行期质量属性	含义
性能	系统及时提供服务的能力，包括速度、吞吐量、容量
安全性	向合法用户提供服务，阻止非授权使用的能力
可伸缩性	用户数、数据量增加时，仍维持高服务质量的能力
互操作性	与其他系统交换数据、相互调用服务的难易程度
可靠性	系统在一定时间内持续无故障运行的能力
可用性	系统正常工作时间占总时间的比例
鲁棒性（健壮性/容错性）	异常情况下仍能正常运行的能力

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

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

架构评估的质量属性	核心说明
性能	系统响应能力，用响应时间、事务数、吞吐量衡量，常用基准测试程序
可靠性	规定条件与时间内完成功能的能力，用MTTF、MTBF衡量；包含容错、健壮性
可用性	系统正常运行时间比例，用故障间隔、故障恢复速度表示
安全性	阻止非授权访问，保证服务合法使用；包含机密性、完整性、不可否认性、可控性
可修改性	快速、低成本变更系统的能力；包含可维护性、可扩展性、结构重组、可移植性
功能性	系统完成期望工作的能力，多构件协作实现
可变性	架构可扩充、变更为新架构的能力，适用于软件产品线
互操作性	系统与其他系统/环境交互、交换数据与服务的能力

8.1.3质量属性场景描述

为了精确描述软件系统的质量属性，通常采用质量属性场景 (Quality Attribute Scenario) 作为描述质量属性的手段。

质量属性场景是一个具体的质量属性需求，是利益相关者与系统的交互的简短陈述。

质量属性场景 组成部分	英文名	原文说明	总结说明
刺激源	Source	这是某个生成该刺激的实体(人、计算机系统或者任何其他刺激器)	产生刺激的主体
刺激	Stimulus	该刺激是当刺激到达系统时需要考虑的条件	到达系统的事件/条件
环境	Environment	该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况	刺激发生时系统状态
制品	Artifact	某个制品被激励。这可能是整个系统，也可能是系统的一部分	被刺激的系统/组件
响应	Response	该响应是在激励到达后所采取的行动	系统做出的处理动作
响应度量	Measurement	当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试	可量化验证的指标

可用性质量属性场景描述

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

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

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

性能质量属性场景描述

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

可测试性质量属性场景描述

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

易用性质量属性场景描述

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

安全性质量属性场景描述

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

8.2系统架构评估

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

评估方法分类	原文说明
基于调查问卷或检查表的方式	该方法的关键是要设计好问卷或检查表，充分利用系统相关人员的经验和知识，获得对架构的评估。该方法的缺点是在很大程度上依赖于评估人员的主观推断。
基于场景的方式	基于场景的方式由卡耐基梅隆大学软件工程研究所首先提出并应用在架构权衡分析法(Architecture Tradeoff Analysis Method,ATAM)和软件架构分析方法(Software Architecture Analysis Method,SAAM)中。它是通过分析软件架构对场景(也就是对系统的使用或修改活动)的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。
基于度量的方式	它是建立在软件架构度量的基础上的，涉及3个基本活动，首先需要建立质量属性和度量之间的映射原则，然后从软件架构文档中获取度量信息，最后根据映射原则分析推导出系统的质量属性。

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

场景要素	原文说明
敏感点	一个或多个构件(和/或构件之间的关系)的特性。研究敏感点可使设计人员或分析员明确在搞清楚如何实现质量目标时应注意什么。
权衡点	影响多个质量属性的特性，是多个质量属性的敏感点。例如，改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响系统性能。如果某个机密消息的处理有严格的时间延迟要求，则加密级别可能就会成为一个权衡点。
风险承担者（利益相关人）	系统的架构涉及很多人的利益，这些人都对架构施加各种影响，以保证自己的目标能够实现。表8-7列出在架构评估中可能涉及的一些风险承担者及其所关心的问题。

8.2.2系统架构评估方法

1.SAAM方法

SAAM(Scenarios-based Architecture Analysis Method)

场景要素	原文说明
特定目标	SAAM 的目标是对描述应用程序属性的文档，验证基本的架构假设和原则。此外，该分析方法有利于评估架构固有的风险。SAAM 指导对架构的检查，使其主要关注潜在的问题点，如需求冲突，或仅从某一参与者观点出发得出的不全面的系统设计。SAAM 不仅能够评估架构对于特定系统需求的使用能力，也能被用来比较不同的架构。
评估技术	SAAM 所使用的评估技术是场景技术。场景代表了描述架构属性的基础，描述了各种系统必须支持的活动和可能存在的状态变化。
质量属性	这一方法的基本特点是把任何形式的质量属性都具体化为场景，但可修改性是 SAAM 分析的主要质量属性。
风险承担者	SAAM 协调不同参与者之间感兴趣的共同方面，作为后续决策的基础，达成对架构的共识。
架构描述	SAAM 用于架构的最后版本，但早于详细设计。架构的描述形式应当被所有参与者理解。功能、结构和分配被定义为描述架构的3个主要方面。
方法活动	SAAM 的主要输入是问题描述、需求声明和架构描述。图8-1描绘了 SAAM 分析活动的相关输入及评估过程。

2.ATAM方法

架构权衡分析方法 (Architecture Tradeoff Analysis Method,ATAM) 是 在 S A A M的基础上发展起来的，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

场景要素	原文说明
特定目标	ATAM 的目标是在考虑多个相互影响的质量属性的情况下，从原则上提供一种理解软件架构的能力的方法。对于特定的软件架构，在系统开发之前，可以使用 ATAM 方法确定在多个质量属性之间折中的必要性。
质量属性	ATAM 方法分析多个相互竞争的质量属性。开始时考虑的是系统的可修改性、安全性、性能和可用性。
风险承担者	在场景、需求收集相关活动中，ATAM 方法需要所有系统相关人员的参与。
架构描述	架构空间受到历史遗留系统、互操作性和以前失败的项目约束。架构描述基于5种基本结构来进行，这5种结构是从 Kruchten 的4+1视图派生而来的。其中逻辑视图被分为功能结构和代码结构。这些结构加上它们之间适当的映射可以完整地描述一个架构。用一组消息顺序图表示运行时的交互和场景，对架构描述加以注解。ATAM 方法被用于架构设计中，或被另一组分析人员用于检查最终版本的架构。
评估技术	可以把 ATAM 方法视为一个框架，该框架依赖于质量属性，可以使用不同的分析技术。它集成了多种优秀的单一理论模型，其中每种都能够高效、实用地处理属性。该方法使用了场景技术。从不同的架构角度，有3种不同类型的场景，分别是用例(包括对系统典型的使用、引出信息)、增长场景(用于涵盖那些对它的系统的修改)、探测场景(用于涵盖那些可能会对系统造成过载的极端修改)。ATAM 还使用定性的启发式分析方法(Qualitative Analysis Heuristics)，在对一个质量属性构造了一个精确分析模型时要进行分析，定性的启发式分析方法就是这种分析的粗粒度版本。
方法的活动	ATAM 被分为4个主要的活动领域(或阶段)，分别是场景和需求收集、架构视图和场景实现、属性模型构造和分析、折中。图8-2描述了与每个阶段相关的步骤，还描述了架构设计和分析改进中可能存在的迭代。属性专家独立地创建和分析他们的模型，然后交换信息(澄清和创建新的需求)。属性分析是相互依赖的，因为每个属性都会涉及其他属性。获得属性关联的方法有两种，即使用敏感度分析来发现折中点和通过检查假设。在架构设计中，ATAM提供了迭代的改进。除了通常从场景派生而来的需求，还有很多对行为模式和执行环境的假设。由于属性之间存在着折中，每一个假设都要被检查、验证和询问，以此作为 ATAM 方法的结果。在完成所有这些操作之后，把分析的结果和需求进行比较；如果系统预期的行为大多接近于需求，设计者就可以继续进行下一步更为详细的设计或实现。
领域知识库的可重用性	领域知识库通过基于属性的架构风格(Attribute Based Architecture Style)维护。ABAS有助于从架构风格的概念转向基于特定质量属性模型的推理能力。获取一组基于属性的架构风格的目标在于要把架构设计变得更为惯例化和更可预测，并得到一个基于属性的架构分析的标准问题集合，使设计与分析之间的联系更为紧密。
方法验证	该方法已经应用到多个软件系统，但仍处在研究之中。虽然软件架构分析与评价已经取得了很大的进步，但是在某些方面也存在一些问题。例如，架构的描述、质量特征的分析、场景不确定性的处理、度量的应用架构分析和评价支持工具等，这些都影响和制约着分析评估技术的发展。Clement认为在未来的5～10年内，架构的分析是架构发展的5个方向之一。
效用树	ATAM 方法采用效用树(Utility tree)这一工具来对质量属性进行分类和优先级排序。效用树的结构包括：树根---质量属性---属性分类---质量属性场景(叶子节点)。需要注意的是，ATAM主要关注4类质量属性：性能、安全性、可修改性和可用性，这是因为这4个质量属性是利益相关者最为关心的。得到初始的效用树后，需要修剪这棵树，保留重要场景(通常不超过50个)，再对场景按重要性给定优先级(用 H/M/L 的形式)，再按场景实现的难易度来确定优先级(用 H/M/L 的形式)，这样对所选定的每个场景就有一个优先级对(重要度、难易度)，如 (H、L) 表示该场景重要且易实现。

3.CBAM方法

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

步骤	原文说明
(1) 整理场景	整理 ATAM 中获取的场景，根据商业目标确定这些场景的优先级，并选取优先级最高的1/3的场景进行分析。
(2) 对场景进行求精	为每个场景获取最坏情况、当前情况、期望情况和最好情况的质量属性响应级别。
(3) 确定场景的优先级	项目关系人对场景进行投票，其投票是基于每个场景"所期望的"响应值，根据投票结果和票的权值，生成一个分值(场景的权值)。
(4) 分配效用	对场景的响应级别(最坏情况、当前情况、期望情况和最好情况)确定效用表。
(5) 建立对应关系	架构策略涉及哪些质量属性及响应级别，形成相关的"策略---场景---响应级别"的对应关系。
(6) 确定期望效用	使用内插法确定"期望的"质量属性响应级别的效用。即根据第4步的效用表以及第5步的对应关系，确定架构策略及其对应场景的效用表。
(7) 计算总收益	根据第3步的场景的权值及第6步的架构策略效用表，计算出架构策略的总收益得分。
(8) 按ROI选择策略	根据受成本限制影响的 ROI 选择架构策略。根据开发经验估算架构策略的成本，结合第7步的收益，计算出架构策略的 ROI，按 ROI 排序，从而确定选取策略的优先级。

4.其他方法

评估方法	原文说明
SAEM 方法	将软件架构看作最终产品及设计中间产品，从外部质量属性（用户定义）和内部质量属性（开发者决定）评估。流程：①按ISO/IEC 9126-1规约建模内外质量属性；②为属性创建度量准则；③数据收集、度量、结果分析。
SAABNet 方法	源于AI，用贝叶斯信念网络（BBN）表达和使用定性知识辅助架构定性评估。步骤：①识别相关变量；②定义概率依赖（定性）；③评估条件概率（定量）；④测试BBN。变量分三类：架构质量属性、度量准则、架构特征。
SACMM 方法	软件架构修改度量方法，基于图内核定义差异度量计算架构距离。用图模型描述架构，考虑抽象层次、结点标签、连接标签。可建模架构修改过程，解决重命名匹配与结果稳定问题，已在开源软件验证。
SASAM 方法	静态评估方法，映射比较预期架构与实际架构，结合PuLSE-DSSA。有10个评估目的：产品线可能性、产品对准性、重用可能性、组件充分性、对架构理解、一致性、完备性、文档、控制演化、支持架构分解。
ALRRA 方法	软件架构可靠性风险评估方法。用动态复杂度、动态耦合度定义组件/连接件复杂度，用FMEA定义故障后果严重性，组合得到启发式风险因素。步骤：ADL建模、仿真分析、FMEA分析、定义风险因素、构造CDG、图遍历评估。
AHP 方法	层次分析法，定性问题定量分析的多准则决策方法。步骤：确定总目标、建立多层次递阶结构、构造判断矩阵求相对权值、计算合成权重总排序、决策。用于架构评估中质量属性冲突分析与方案排名。
COSMIC+UML 方法	基于面向对象可维护性度量（复杂度、耦合度、内聚），用COSMIC度量UML组件图架构。步骤：关联对象度量与COSMIC、完善COSMIC标记适配UML、提出组件图度量准则。辅助架构演化方案分析，已验证。

8.3ATAM方法架构评估实践

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

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

步骤	原文说明
第1步：介绍ATAM	这一步涉及ATAM评估过程的描述。在此步骤中，评估负责人向所有相关参与者提供有关ATAM过程的一般信息。领导者说明评估中使用的分析技术以及评估的预期结果。领导者解决小组成员的任何疑虑、期望或问题。
第2步：介绍业务驱动因素	在这一步中，提到了系统体系结构驱动程序的业务目标。这一步着重于系统的业务视角。它提供了有关系统功能、主要利益相关方、业务目标和系统其他限制的更多信息。本步骤将定义被评估系统的主要功能以及涉及的利益相关方。评估考虑的主要利益相关者包括：最终用户、架构师和应用程序开发人员。
第3步：介绍要评估的体系结构	在这一步中，架构团队描述了要评估的架构。它侧重于体系结构、时间可用性以及体系结构的质量要求。关键问题包括技术约束，与正在评估的系统交互的其他系统，以及为满足质量属性而实施的架构方法。系统的质量属性包括性能、可靠性等。

胡佛 (Hoover) 事件架构

胡佛的事件架构由组成事件框架的组件和利用框架服务的应用程序组成。

如前所述，该框架基于事件框架，根据事件不同的类型进行相应处理。一个事件由两个主要部分组成：事件类型 (Event Type) 和事件需要处理的参数 (Args)。 为了处理多个事件，系统中存在一个事件队列 (Qucue) 组件。

事件队列(Event Queue) 保存系统中的事件，并以先来先服务 (FIFO) 模式进行分派。事件队列能够存储任意时间内产生的事件，并支持检索以供将来处理。

该框架的核心组件是事件管理器 (Event Manager)。 该组件绑定事件队列和事件类型 (Type Bindings)。 事件管理器还维护事件类型注册表 (Event Type Registry) 数据结构，并将事件类型注册到相关关联的处理程序中。一个事件可能关联多个处理程序。当事件正在执行时，由于事件管理器维护着事件类型注册表。它能将事件动态绑定到相应的处理程序中，这大大增加了框架的灵活性。

"银行" (Banking) 事件架构

"银行"体系结构由组成事件框架的组件和利用框架服务的应用程序组成。

这个框架与上面描述的架构类似，但有一些区别。在这种架构中，即使没有特有的事件组件，底层主题也可看作是一种事件(框架默认)。在这种架构中，事件有两个主要部分：类型(Type) 及其参数 (Args)。

事件队列 (Queue) 组件对事件进行排队，并以先进先出FIFO 模式进行处理。如果没有要

返回的事件，则会生成"空闲"事件。

框架中有一个基本的处理程序 (Handler) 组件，该组件由三个标准的指定处理程序和相应

的扩展接口。

● START handler: 在启动时初始化系统。

● STOP handler: 终止系统。

● IDLE handler: 此处理程序执行"空闲等待",直到用户输入一个事件。当用户输入事

件后，该处理程序验证输入事件是否有效。如果有效，则事件排队；否则会产生另一个

空闲事件。该处理程序将系统保持在空闲状态，直到系统处理任何输入事件。

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

步骤	原文说明
第4步：确定架构方法	理解系统关键需求的关键架构方法，架构团队解释流程控制、目标达成情况。对比两种架构：胡佛架构（组件独立、可修改性/可重用性/可扩展性好）；银行活动架构（事件管理器未封装、组件依赖高、可修改性与可重用性差，可靠性通过提前校验实现）。
第5步：生成质量属性效用树	确定并排序系统最重要质量属性目标，通过效用树聚焦关键架构方面。效用树根为"效用"，下分质量属性与场景叶节点，按重要性与难易度标H/M/L优先级。场景来自最终用户、架构师、应用开发人员，对应安全性、性能、可用性等质量属性。
第6步：分析体系结构方法	分析效用树输出，调查架构方法，识别风险、非风险、敏感点、权衡点。高优先级属性：可变性、可靠性、概念一致性、功能性、可修改性。分别从可变性、可靠性、概念完整性、功能性、可修改性对比两种架构，给出分析问题与答案，最终提炼敏感点与权衡点。

8.3.3阶段3------测试

步骤	原文说明
第7步：头脑风暴和优先场景	扩大利益相关者参与，生成并筛选场景，分为用例场景、增长场景、探索性场景。票数=场景总数×30%，投票后排序取高优场景，与效用树场景合并。
第8步：分析架构方法	分析头脑风暴得出的高优先级质量属性（功能性、可靠性、可修改性、安全性、性能、可变性），重点新增分析安全性与性能。从调查架构方法、创建分析问题、给出答案、识别风险/非风险/敏感点/权衡点四阶段开展，对比胡佛架构与银行架构。

8.3.4阶段4------报告ATAM

这是ATAM评估的最后阶段，其中提供了评估期间收集的所有信息。A T A M团队将他们的发现呈现给利益相关者。

A T A M 团队的主要发现通常包括：

● 一种效用树；

● 一组生成的场景；

● 一组分析问题；

● 一套确定的风险和非风险；

● 确定的架构方法。