当前位置：首页 > news >正文

【第八章软件质量属性域架构评估】

news 2026/7/16 3:26:02

第八章软件质量属性域架构评估

8.1 软件系统质量属性（非常重要，选择，案例）

定义
软件系统的质量就是“软件系统与明确地和隐含地定义的需求相一致的程度”影响软件质量的主要因素划分为6个维度特性:

6大21小（制作口诀）（背）

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

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

面向架构评估的质量属性
1.性能（重要）
指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。

性能战术
资源需求:提高计算效率、减少处理事件流所需的资源、减少所处理事件的数量、控制资源的使用:
资源管理:引入并发、维持数据或计算的多个副本、增加可用资源
资源仲裁:资源调度策略、先进先出、固定优先级调度、动态优先级调度、静态调度

2.可靠性
可靠性是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。通常用来衡量在规定的条件和时间内，软件完成规定功能的能力。

平均失效间隔时间(MTBF):是指相邻两次故障之间的平均时间，也称为平均故障间隔。
平均失效等待时间(MTTF)也称平均无故障时间【（运行时间-故障时间）/故障次数】，是指某个元件预计的可运作平均时间
平均故障修复时间(ITTR):是描述产品由故障状态转为工作状态时修理时间的平均值。表示计算机的可维修性【平均故障耗时】。

MTBF= MTTF + ITTR

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

可用性战术
错误检测:命令/响应、心跳线、异常处理
错误恢复:表决(通过冗余构件与表决器相联)、主动冗余、被动冗余、备件、状态再同步、检查点/回滚
错误预防:从服务中删除、事务(事务保证一致性)、进程监视器。

4.安全性（重要）
是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性。

常见场景分析:
(1)可抵御SQL注入攻击。(2)对计算机的操作都有完整的记录。(3)用户信息数据库授权必须保证 99.9%可用。

设计策略:
入侵检测、用户认证、用户授权、追踪审计。
抵抗攻击:对用户身份进行验证、授权、维护数据的机密性、完整性、限制暴露的信息、限制访问
检测攻击:“入侵检测”
从攻击中恢复:识别攻击者(审计追踪)、恢复(冗余)

5.可修改性（理解）
可修改性(Modiability)是指能够快速地以较高的性价比对系统进行变更的能力。通常以某些具体的变更为基准，通过考查变更的代价来衡量可修改性。可修改性包含以下4个方面:
(1)可维护性
(2)可扩展性
(3)结构重组
(4)可移植性

常见场景分析
(1)更改系统报表模块，必须在2人周内完成。
(2)对Web界面风格进行修改，修改必须在4人月内完成。
可修改性战术
局部化修改:维持语义的一致性（前后一致）、预期期望的变更、泛化该模块、限制可能的选择
防止连锁反应:信息隐藏、维持现有的接口、限制通信路径、仲裁者的使用
推迟绑定时间:运行时注册、配置文件、多态、构件更换、遵守已定义的协议。

6.功能性

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

扩展：
9、易用性
被易于使用的程度
1、常见场景(1)界面友好。(2)新用户学习使用系统时间不超过2小时。
2、易用性战术
运行时:任务的模型、用户的模型、系统的模型(维护任务、用户、系统信息，了解系统用户的需求等)
设计时:接口与其余部分分离
支持用户主动操作:如取消、撤销等

10、可测试性
对软件系统进行测试以证明满足需求规格的能力。指的是通过测试揭示软件缺陷的容易程度。
1、常见场景:提供远程调试接口，支持远程调试。
2、可测试性策略
输入/输出:记录回放、接口与实现分离、优化访问线路接口内部监控

质量属性场景描述（重要）
是一个具体的质量属性需求，由6部分组成

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

8.2 系统架构评估

相关该概念
（1）敏感点(Sensitivity Point)和权衡点 (Tradeoff Point)。（背诵定义）
敏感点是一个或多个构件(和或构件之间的关系)的特性。研究敏感点可使设计师明确在搞清楚如何实现质量目标时应注意什么。
权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。例如，改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响系统性能。如果某个机密消息的处理有严格的时间延迟要求，则加密级别可能就会成为一个权衡点。
（2）风险承担者(Stakeholders)或者称为利益相关人。系统的架构涉及很多人的利益，这些人都对架构施加各种影响，以保证自己的目标能够实现。

风险：会带来隐患、不确定
非风险：可控/可接受点

（3）场景
在进行架构评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该架构优劣的标准。为得出这些目标而采用的机制称之为场景。场景是从风险担者的角度对与系统的交互做的简短描述。在架构评估中，一般采用刺激、环境和响应三方面来对场景进行描述。

系统评估方法（重要）
1.基于调查问卷或检查表的方式（主观）
2.基于场景的方式
3.基于度量的方式
度量是指为软件产品的某一属性所赋予的数值，如代码行数、方法调用层数、构件个数等。

(1)软件架构分析法-SAAM方法:最初关注可修改性，后扩充到可移植性、可扩充性等。
SAAM 分析评估架构的过程包括5个步骤，即场景开发、架构描述、单个场景评估、场景交互和总体评估。通过各类风险承担者协商讨论，开发一些任务场景，体现系统所支持的各种活动。用一种易于理解的、合乎语法规则的架构描述软件架构，体现系统的计算构件、数据构件以及构件之间的关系(数据和控制)。对场景(直接场景和间接场景)生成一个关于特定架构的场景描述列表。通过对场景交互的分析，得出系统中所有场景对系统中的构件所产生影响的列表。最后，对场景和场景间的交互作一个总体的权衡和评价。

(2)架构权衡分析法-ATAM方法:由SAAM发展而来，主要针对性能、实用性、安全性、可修改性。
4个主要的活动领域（重要）

场景和需求收集
架构视图和场景实现
属性模型构造和分析
折中

效用树（重要）
ATAM方法采用效用树(Utilitytree)这一工具来对质量属性进行分类和优先级排序。
效用树的结构包括:树根一质量属性一属性分类一质量属性场景(叶子节点)。
ATAM 主要关注4类质量属性:性能、安全性、可修改性和可用性，因为这4个质量属性是利益相关者最为关心的。得到初始的效用树后，需要修剪这棵树，保留重要场景(不超过50个)，再对场景按重要性给定优先级(用H/ML的形式)，再按场景实现的难易度来确定优先级(用H/M/的形式)，这样对所选定的每个场景就有一个优先级对(重要度、难易度)，如(H、L)表示该场景重要且易实现。

(3)成本效益分析法-CBAM方法，在ATAM基础上建立的软件的“经济”模型。
CBAM 的思想就是架构策略影响系统的质量属性，反过来这些质量属性又会为系统的项目干系人带来一些收益(称为效用)，CBAM 协助项目干系人根据其投资回报(ROI)选择架构策略。

八个步骤（了解）
(1)整理场景。
(2)对场景进行求精。
(3)确定场景的优先级。
(4)分配效用。
(5)架构策略涉及哪些质量属性及响应级别，形成"策略一场景一响应级别"的对应关系。
(6)使用内插法确定"期望的"质量属性响应级别的效用。
(7)计算各架构策略的总收益
(8)根据受成本影响的ROI选择架构策略

(4) SAAM (了解)

8.3 ATAM方法架构评估实践

ATAM方法评估软件体系结构，分为4个基本阶段:

描述和介绍阶段(演示)
调查和分析阶段
测试阶段
报告阶段

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

二、阶段2–调查和分析
在这个阶段，对评估期间需要重点关注的一些关键问题进行彻底调查。这个阶段细分为3个步骤。
第4步:确定架构方法
这一步涉及能够理解系统关键需求的关键架构方法。在这一步中，架构团队解释架构的流程控制，并提供关于如何达成关键目标以及是否达到关键目标的适当解释。
第5步:生成质量属性效用树
在评估阶段，确定系统最重要的质量属性目标，并确定优先次序和完善。这一步至关重要，通过建立效用树，将所有利益相关方和评估人员的注意力集中在关系到体系成功至关重要的体系结构的不同方面。
第6步:分析体系结构方法
这是"调查和分析"阶段的最后一步。在这一步中，分析前一步生成的效用树的输出并进行彻底调查和分析，找出处理相应质量属性架构的方法。
这里还要确定每种架构方法的风险、非风险、敏感点和权衡点。

三、阶段3一测试
第7步:头脑风暴和优先场景
这是 ATAM测试阶段的第一步。前者代表利益相关者的利益，用于理解质量属性要求。在效用树生成步骤中，主要结果是从架构师的角度来理解质量属性。在这一步中，目标是让更大的利益相关者参与其中。
第8步:分析架构方法
这是测试阶段的最后一步。在这一步中，我们分析上一步中高优先级的质量属性。找到了处理这些质量属性的架构设计方案，并检查相应的架构设计方案是否可支持满足这些属性。这一步重复“调查和分析”阶段的第6步。唯一的区别在于，在步骤6中，高优先级质量属性来自效用树，而这一步需要考虑在头脑风暴投票中，高得票数的质量属性。

四、阶段4–报告ATAM
这是ATAM 评估的最后阶段，其中提供了评估期间收集的所有信息。ATAM 团队将他们的发现呈现给利益相关者。ATAM团队的主要发现通常包括:
1种效用树;