13.5质量属性-架构评估
软件系统的质量属性
可以将软件系统的质量属性，分为开发期质量属性和运行期质量属性2个部分。
开发期质量属性主要指在软件开发阶段所关注的质量属性，主要包含6个方面
(1)易理解性：指设计被开发人员理解的难易程度。
(2)可扩展性：软件因适应新需求或需求变化而增加新功能的能力，也称为灵活性可
(3)重用性：指重用软件系统或某一部分的难易程度。
(4)可测试性：对软件测试以证明其满足需求规范的难易程度。
(5)可维护性：当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度。
(6)可移植性:将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。
运行期质量属性主要指在软件运行阶段所关注的质量属性，主要包含7个方面。
(1)性能：性能是指软件系统及时提供相应服务的能力，如速度、吞吐量和容量等的要求
(2)安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
(3)可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力。
(4)互操作性：指本软件系统与其他系统交换数据和相互调用服务的难易程度。
(5)可靠性：软件系统在一定的时间内持续无故障运行的能力。
(6)可用性：指系统在一定时间内正常工作的时间所占的比例。可用性会受到系统错误，恶意攻击高负载等问题的影响。
(7)鲁棒性：是指软件系统在非正常情况(如用户进行了非法操作、相关的软硬件系统发生了故障等)下仍能够正常运行的能力，也称健壮性或容错性。
软件架构评估
质量属性
掌握：定义、包含子特性、如何解决/达到质量属性
1. 性能
指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量。设计策略:优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。
2. 可靠性
是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。如MTTF、MTBF、MTTR。设计策略:心跳、Ping/Echo、冗余、选举
3. 可用性
是系统能够正常运行的时间比例，经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。如故障间隔时间。设计策略:心跳、Ping/Echo、几余、选举
4. 安全性
是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性。设计策略:入侵检测、用户认证、用户授权、追踪审计。
5. 可修改性
指能够快速的以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量。设计策略:接口-实现分类、抽象、信息隐藏。
6. 功能性
是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
7. 可变性
指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时，可变性是很重要的。
8. 互操作性
作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，也影响应用的软件体系结构。
质量属性场景
质量属性场景是一种面向特定质量属性的需求。它由6 部分组成：
刺激源（Source）：这是某个生成该刺激的实体(人、计算机系统或者任何其他刺激器)
刺激（Stimulus）：该刺激是当刺激到达系统时需要考虑的条件。
环境（Environment）：该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况。
制品（Artifact）：某个制品被激励。这可能是整个系统，也可能是系统的一部分。
响应（Response）：该响应是在激励到达后所采取的行动。
响应度量（Measurement）：当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试、
可修改性质量属性场景描述实例：
- 敏感点：是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。
- 权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。
- 风险点与非风险点：不是以标准专业术语形式出现的，只是一个常规概念，即可能引起风险的因素，可称为风险点。某个做法如果有隐患，有可能导致一些问题，则为风险点；而如果某件事是可行的可接受的，则为非风险点。
- 软件架构评估在架构设计之后，系统设计之前，因此与设计、实现、测试都没有关系。评估的目的是为了评估所采用的架构是否能解决软件系统需求，但不是单纯的确定是否满足需求。
三种常用的评估方式
基于调查问卷（检查表）的方式
类似于需求获取中的问卷调查方式，只不过是架构方面的问卷，要求评估人员对领域熟悉。
基于度量的方式
制定一些定量指标来度量架构，如代码行数等。要制定质量属性和度量结果之间的映射，要求评估人员对架构熟悉。
基于场景的方式
主要方法。首先要确定应用领域的功能和软件架构的结构之间的映射，然后要设计用于体现待评估质量属性的场景（即4+1视图中的场景），最后分析软件架构对场景的支持程度。要求评估人员即对领域熟悉，也对架构熟悉。
从三个方面对场景进行设计：
刺激（事件）
环境（事件发生的环境）
响应（架构响应刺激的过程）
SAAM：基于场景的架构分析方法
SAAM是一种非功能质量属性的架构分析方法，是最早形成文档并得到广泛应用的软件架构分析方法
特定目标：SAAM的目标是对描述应用程序属性的文档，验证基本的架构假设和原则。
质量属性：这一方法的基本特点是把任何形式的质量属性都具体化为场景，但可修改性是SAAM分析的主要质量属性。
架构描述。SAAM 用于架构的最后版本，但早于详细设计。架构的描述形式应当被所有参与者理解。
功能、结构和分配：被定义为描述架构的3个主要方面。
方法活动：SAAM的主要输入是问题描述、需求声明和架构描述。下图描绘了SAAM分析活动的相关输入及评估过程。
包括5个步骤：
- 场景开发
- 架构描述
- 单个场景评估
- 场景交互
- 总体评估
ATTM：架构权衡分析法
让架构师明确如何权衡多个质量目标，参与者有评估小组、项目决策者和其他项目相关人。
ATAM被分为四个主要的活动领域：分别是
- 场景和需求收集
- 体系结构视图和场景实现
- 属性模型构造
- 分析折中
整个评估过程强调以属性作为架构评估的核心概念。主要针对性能可用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。
ATAM方法架构评估实践
CBAM：成本效益分析法
用来对架构建立的成本来进行设计和建模，让决策者根据投资收益率来选择合适的架构，可以看做对ATAM的补充，在ATAM确定质量合理的基础上，再对效益进行分析。有下列步骤：
整理场景：
整理ATAM中获取的场景，并根据商业目标确定场景的优先级，选取优先级最高的1/3场景进行分析。（确定场景，并确定优先级，选择三分之一优先级最高的场景进行分析）。
对场景进行细化：
为每个场景获取最坏情况、当前情况、期望情况和最好情况下的质量属性响应级别。（对每个场景详细分析，确定最好、最坏的情况）。
确定场景的优先级：
项目干系人对场景进行投票，根据每个场景的“所期望的”响应值进行投票，生成一个分值（场景的权值）（项目干系人对场景投票，根据投票结果确定优先级）。
分配效用：
确定场景响应级别（最坏情况、当前情况、期望情况和最好情况）的效用表。（对场景响应级别确定效用表，建立策略、场景、响应级别的表格）。
形成“策略-场景-响应级别的对应关系”：
确定架构策略涉及的质量属性及响应级别，并形成“策略一场景一响应级别”的对应关系。
确定期望的质量属性响应级别的效用：
使用内插法确定“期望的”质量属性响应级别的效用。根据效用表和对应关系，确定架构策略及其对应场景的效用表。（根据效用表确定所对应的具体场景的效用表）。
计算各架构策略的总收益：
根据场景的权值和架构策略的效用表，计算出各架构策略的总收益得分。根据成本限制下的ROI选择架构策略。根据开发经验估算架构策略的成本，结合收益计算出架构策略的ROI，按照ROI排序来确定优先级。根据受成本限制影响的投资报酬率选择架构策略（估算成本，用上一步的收益减去成本，得出收益，并选择收益最高的架构策略）。
其他评估方法了解
1. SAEM方法
将软件架构看作一个最终产品以及设计过程中的一个中间产品，从外部质量属性和内部质量属性两个角度来阐述它的评估模型，旨在为软件架构的质量评估创建一个基础框架。
外部属性指用户定义的质量属性，而内部属性指开发者决定的质量属性。该软件架构评估模型包含以下几个流程：
对待评估的质量属性进行规约建模。
为外部和内部的质量属性创建度量准则，先从评估目的(如软件架构比较、最终产品的质量预测)，评估角度（如开发者、用户、维护者），评估环境（架构作为最终产品或设计中间产品）出发来定义架构评估的目标，再根据目标相关的属性来提出问题，然后回答每个问题并提出相应的度量准则。
评估质量属性，包括
数据收集、度量和结果分析3个活动。
2. SAABNet方法
是一种用来表达和使用定性知识以辅助架构的定性评估。该方法来源于人工智能允许不确定、不完整知识的推理。该方法使用 BBN 来表示和使用开发过程中的知识，包含定性和定量的描述，其中定性的描述是所有结点的图，定量的描述是每个结点状态相关的条件概率。其中的变量可分为 3 类，即架构质量属性变量（如可维护性、灵活性等）、质量属性的度量准则变量（如容错性、响应性等）和架构特征变量（如继承深度、编程语言等），高层抽象的质量属性变量分解为低层抽象的度量准则变量，度量准则变量则分解为更低层抽象的架构特征变量。
3. SACMM方法
是一种软件架构修改的度量方法。
4. SASAM方法
通过对预期架构（架构设计阶段的相关描述材料）和实际架构（源代码中执行的架构）进行映射和比较来静态地评估软件架构。
5. ALRRA方法
是一种软件架构可靠性风险评估方法，该方法使用动态复杂度准则和动态耦合度准则来定义组件和连接件的复杂性因素，其中，动态复杂度准则在某个场景的执行中分析组件的动态行为来度量组件的复杂性，动态耦合度准则在某个场景的执行中分析连接件的消息传递协议来度量连接件的复杂性。利用失效模式和影响分析（FMEA）技术。
6. AHP（层次分析法）方法。
是对定性问题进行定量分析的一种简便、灵活而又实用的多准则决策方法。AHP 方法的特点是把复杂问题中的各种因素通过划分为相联系的有序层次使之条理化，并在一般情况下通过两两对比，根据一定客观现实的主观判断结构，把专家意见和分析者的客观判断结果直接、有效地结合起来，将一定层次上元素的某些重要性进行定量描述，之后利用数学方法计算反映每一层次元素的相对重要性次序的权值，并最后通过所有层次之间的总排序计算所有元素的相对权重及对权重进行排序。
7. COSMIC+UML方法。
基于度量模型来评估软件架构可维护性的方法。针对不同表达方式的软件架构，采用统一的软件度量 COSMIC 方法来进行度量和评估。该方法主要是为了辅助分析软件架构的演化方案是否可行，并在开源软件 DCMMS 的软件架构 UML 组件图上得以验证。
例题
题①
某公司欲开发一个在线交易网站，在架构设计阶段，公司的架构师识别出3个核心质量属性场景。其中”网站正常运行时，用户发起的交易请求应该在3秒内完成“主要与（58）质量属性相关，通常 可采用（59）架构策略实现该属性；”在线交易主站宕机后，能够在3秒内自动切换至备用站点并恢 复正常运行“主要与（60）质量属 性相关，通常可采用（61）架构策略实现该属性；”系统应该具备一定的安全保护措施，从而能够抵挡恶意的入侵破坏行为，并对所有针对网站的攻击行为进行报警和记录“主要与（62）质量属性相关，通常可采用（63）架构策略实现该属性。
（58）A.可用性 B.性能 C.易用性 D.可修改性
（59）A.抽象接口 B.信息隐藏 C.主动冗余 D.资源调度
（60）A.可测试性 B.易用性 C.可用性 D.互操作性
（61）A.记录/回放 B.操作串行化 C.心跳 D.增加计算资源
（62）A.可用性 B.安全性 C.可测试性 D.可修改性
（63）A.追踪审计 B.Ping/Echo C.选举 D.维护现有接口
答案:（58）B、（59）D、（60）C、（61）C、（62）B、（63）A；
题②
架构权衡分析方法（Architecture Tradeoff Analysis Method，ATAM）是一种系统架构评估方法，主要在系统开发之前，针对性能、（57）、安全性和可修改性等质量属性进行评价和折中。 ATAM可以分为4个主要的活动阶段，包括需求收集、（58）描述、属性模型构造和分析、架构决策与折中，整个评估过程强调以（59）作为架构评估的核心概念，某软件公司采用ATAM进行软件架构评估，在评估过程中识别出了多个关于质量属性的描述，其中，“系统在进行文件保存操作时应该与Windows系统的操作方式保持一致，主要与（60）质量属性相关:“系统应该提供一个开放的API接口，支持远程对系统的行为进行控制与调试，主要与（61）质量属性相关。在识别出上述描述后，通常采用（62）对质量属性的描述进行刻画与排序。在评估过程中，（63）是个会影响多个质量属性的架构设计决策。
（57）A.可测试性 B.可移植性 C.可用性 D.易用性
（58）A.架构视图 B.架构排序 C.架构风格 D.架构策略
（59）A.用例 B.视图 C.属性 D.模型
（60）A.可测试性 B.互操作性 C.可移植性 D.易用性
（61）A.可测试性 B.互操作性 C.可移植性 D.易用性
（62）A.期望管理矩阵 B.决策表 C.优先队列 D.效用树
（63）A.风险点 B.决策点 C.权衡点 D.敏感点
答案：（57）C、（58）A、（59）C、（60）D、（61）A、（62）D、（63）C；
转载请注明来源，欢迎大家进行交流讨论。还可通过邮箱联系：youngdream365##qq.com (##替换为@)。
