第8章 系统质量属性与架构评估

8.1软件系统质量属性

软件系统属性包括功能属性和质量属性，软件架构重点关注的是质量属性。架构的基本需求是在满足功能属性的前提下，关注软件系统质量属性。为了精确、定量地表达系统的质量属性，通常会采用质量属性场景的方式进行描述。

在确定软件系统架构，精确描述质量属性场景后，就需要对系统架构进行评估。软件系统架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。它也可以灵活地运用于软件架构评审等工作。

8.1软件系统质量属性
8.1.1质量属性概念

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

1.开发期质量属性

1).易理解：理解的难易程度。让开发人员好理解

2).可扩展：也叫灵活性，适应新需求或需求变化的增加新功能的能力。

3).可重用：重用软件系统或其一部分的难易程度。

4).可测试：测试（满足需求规范）的难易程度。

5).可维护：要修改新增时候，识别修改点并实施修改的难易程度

6).可移植：换一个环境难易程度

2.运行期质量属性

1).性能：及时提供响应服务的能力。

2).安全：兼顾合法用户提供服务，并阻止非授权使用的能力。

3).可伸缩：用户量和数据量增加时候，维持高服务质量的能力。

4).互操作：它与其他系统交互难易程度

5).可靠：一定时间内持续无故障运行的能力

6).可用：一定时间内正常工作时间所占比例。受系统错误，恶意攻击，高负债等等影响。

7).鲁棒：也叫健壮性，容错性。非正常情况下仍能够正常运行的能力。

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

评估架构，所关心的质量属性：

1.性能：响应能力，性能测试经常要使用集中测试程序

2.可靠性：软件系统在系统错误、意外或错误使用的情况下维持软件系统的功能特性的基本能力。它是最重要的软件特性。

平均失效等等时间Mean Tme To Failure MTTF：从运行直到失效的时间间隔。

平均失效间隔时间(平均故障时间)Mean Time Between Failure MTBF：两次失效间隔时间(含修复时间)。

平均维修时间Mean Time To Repair MTTR：发生故障后修复失效并正常运行的时间间隔。

可修复系统中，修复时间不可忽略的：

MTBF =  MTTR + MTTF。

​

可靠性分2方面：

1).容错：目的是发生错误时确保系统的正确行为，并进行内部修复。

2).健壮性：保护应用程序不受错误使用和错误输入的影响，发生意外错误的时候，确保系统处于预先设定的状态。健壮性不是说错误发生时可继续运行，而是保证软件按照某种定义好的方式终止执行。

3.可用性：系统正常运行的时间比例。常用两次故障间隔时间MTBF和出现故障恢复正常的速度来表示。

4.安全性：向合法用户提供服务的同时阻止非授权用户的企图或拒绝服务的能力。

安全性根据根据安全威胁类型划分：机密性、完整性、不可否认性及可控性等。

• 机密性：信息不泄露给未授权用户、实体、进程。
• 完整性：信息的完整和准确，防止被非法修改。
• 不可否认性：不能否认自己发送和接收的信息的行为。
• 可控性：对信息的传播及内容具有控制的能力，防止非法者所用。

5.可修改性：能够快速地较高性价比对系统进行变更的能力。

一般以具体的变更为基准，可修改性4个方面：

• 可维护性(Maintainability)：主要在问题修复上，发生错误后，修复软件系统对其他构件的负面影响尽量小。
• 可扩展性(Extendibility)：使用新特性扩展系统以及改进版本替换构件或删除构件，集成新构件
• 结构重组(Rassemble)：重新组织软件系统的构件及构件间关系。如将构件移动到另一个子系统，改变了位置，原系统减少了构件，调用它的以及它调用的做成改变，系统解雇发生了变化，同样的增加了构件的系统也发生了变化。原则是不影响主体实现的情况下可灵活配置构件，
• 可移植性(Portability)：移植多种平台、环境的能力

6.功能性：完成期望的工作的能力。

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

8.互操作性：与其他系统互操作的能力

8.1.3质量属性场景描述

它是一种手段，为了描述质量属性的。

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

六部分组成：

• 1.刺激源(Source):生成的实体(人、计算机或其他)
• 2.刺激(Stimulus):刺激到达系统时需要考虑的条件
• 3.环境(Environment):该刺激在某些条件内发生，当激励发生时，系统可能处于过载、运行或其他情况。
• 4.制品(Artifact):某个制品被激励。
• 5.响应(Response):激励到达后采取的行动。
• 6.响应度量(Measurement):当响应发生时，应当能够以某种方式对其独立，以对需求进行测试。

质量属性场景主要关注的质量属性：可用性、可修改、性能、可测属性、易用性、安全性6类。

1.可用性质量属性场景

可用性质量属性场景所关注的方面包括系统故障发生的频率、出现故障时会发生什么情况、允许系统有多长是非正常运行、什么时候可以安全地出现故障、如何防止故障的发生以及发生故障时要求进行哪种通知。

2.可修改性质量属性场景

主要关注改变功能和质量属性时候付出的成本和难度。它会发生在设计、编译、构建、运行等等多种情况下。

3.性能质量属性场景

关注响应的速度、时间，吞吐量，负载来评价好坏。

4.可测属性质量属性场景

关注系统测试过程中的效率，发现缺陷或故障的难易程度等

5.易用性质量属性场景

用户使用系统的难以程度，系统的学校曲线、完成操作的效率，对系统使用过程的满意度等。

6.安全性质量属性场景

安全性方面的要素，向合法用户提供服务，阻止非授权用户使用的能力。

8.2系统架构评估

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

它利用数学或逻辑分析技术，针对系统的一致性、正确性、质量属性、规划结果等不同方面，提供描述性、预测性和指令性的分析结果。

方法分3类：

基于调查问卷或检查表

关键是设计好问卷或检查表。优点：充分利用系统相关人员的经验和知识，获得对架构评估。缺点：孤独愈来愈人员的主观判断。

基于场景的评估方法

架构权衡分析法ATAM、软件架构分析法SAAM

基于度量的评估方法

建立在软件架构度量的基础上的，设计三个活动：

首 先需要建立质量属性和度量之间的映射原则，然后从软件架构文档中获取度量信息，最后根据

映射原则分析推导出系统的质量属性。

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

·敏感点：是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。

·权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。

·风险点与非风险点不是以标准专业术语形式出现的，只是一个常规概念，即可能引起风险的因素，可称为风险点。某个做法如果有隐患，有可能导致一些问题，则为风险点；而如果某件事是可行的可接受的，则为非风险点。

·软件架构评估在架构设计之后，系统设计之前，因此与设计、实现、测试都没有关系。评估的目的是为了评估所采用的架构是否能解决软件系统需求，但不是单纯的确定是否满足需求。

场景(scenarios)。在架构评估中，一般采用刺激(Stimulus)、环境(Environment)和响应(Response)三方面来对场景进行描述。

8.2.2系统架构评估方法

1.SAAM方法 Snarios-based Architecture Analysis Method

1).特定目标

SAAM的目标是文档(描述应用程序属性的)，验证基本的架构假设和原则。

SAAM直到对架构的检查，使其主要关注签字啊的问题点，如需求冲突。

SAAM有利于评估架构的固有风险，还能评估架构对于特定系统需求的使用能力，也能被用来比较不同的架构。

2).评估技术

场景技术。景代表了描述架构属性的基础，描述了各种系统必须支持的活动和可能存在的状态变化。

3).质量属性

基本点是把质量属性都具体化为场景，主要是可修改性。

4).风险承担者

SAAM协调不同参与者之间感兴趣的共同方面，作为后续决策的基础，达成对架构的共识。

5).架构描述

SAAM用于架构的最后版本，但早于详细设计。

架构的描述形式应当被所有参与者理解。功能、结构和分配被定义为描述架构的3个主要方面。

6).方法活动

主要输入是问题描述、需求声明和架构描述。

评估的5个过程：场景开发、架构描述、单个场景评估、场景交互和总体评估。

具体方式：

通过各类风险承担者协商讨论，开发一些任务场景，体现系统所支持的各种活动。

用一种易于理解的、合乎语法规则的架构描述软件架构，体现系统的计算构件、数据构件

以及构件之间的关系(数据和控制)。对场景(直接场景和间接场景)生成一个关于特定架构的

场景描述列表。通过对场景交互的分析，能得出系统中所有场景对系统中的构件所产生影响的

列表。最后，对场景和场景间的交互作一个总体的权衡和评价。

7).已有知识库的可重用性：不考虑这个问题

8).方法验证

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

2.ATAM方法  Architecture Tradeoff Analysis Method

它是在SAAM的基础上发展起来的，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

1).特定目标

目标是在考虑多个相互影响的质量属性的情况下，从原则上提供一种理解软件架构的能力的方法。

在系统开发之前，可以使用ATAM方法确定在多个质量属性之间折中的必要性。

2).质量属性

分析多个相互竞争的质量属性。

3).风险承担者

需要所有系统相关人员的参与。

4).架构描述

架构空间受到历史遗留系统、互操作性和以前失败的项目约束。

架构描述基于5种基本结构来进行，这5种结构是从Kruchten的4+1视图派生而来的。

5).评估技术

可以把ATAM方法视为一个框架，该框架依赖于质量属性，可以使用不同的分析技术。

如场景技术(用例、增长、探测场景)、定性的启发式分析方法。

6).方法的活动

TAM被分为4个主要的活动领域(或阶段),分别是场景和需求收集、架构视图和场景实现、属性模型构造和分析、折中。

7).领域知识库的可重用性

域知识库通过基于属性的架构风格(Attribute Based Architecture Style)维护。ABAS有助于从架构风格的概念转向基于特定质量属性模型的推理能力。

8).方法验证

已经应用，虽有进步但也有问题。

        

3.CBAM方法

在ATAM基础上，来对架构设计决策的成本和收益进行建模。

思想就是架构策略影响系统的质量属性，反过来这些质量属性又会为系统的项目干系人带来一些收益(称为“效用”)。

CBAM在ATAM结束时开始，它实际上使用了ATAM评估的结果。
 

CBAM方法分为以下8个步骤。

1).整理场景

整理ATAM中获取的场景，根据商业目标确定这些场景的优先级，并选取优先级最高的1/3的场景进行分析。

2).对场景求精

为每个场景获取最坏情况、当前情况、期望情况和最好情况的质量        属性响应级别。

3).确定场景优先级

项目关系人对场景进行投票，其投票是基于每个场景“所期望的”响应值，根据投票结果和票的权值，生成一个分值(场景的权值)。

4).分配效用

对场景的响应级别(最坏情况、当前情况、期望情况和最好情况)确定效用表。

5).架构策略涉及哪些质量属性及响应级别

架构策略涉及哪些质量属性及响应级别，形成相关的“策略一场景一响应级别”的对应关系。

6).使用内插法确定"期望的"质量属性响应级别的效用。

即根据第4步的效用表以及第5步的对应关系，确定架构策略及其对应场景的效用表。

7).计算各架构策略的总收益

根据第3步的场景的权值及第6步的架构策略效用表，计算出架构策略的总收益得分。

8).根据受成本限制影响的ROI选择架构策略

根据开发经验估算架构策略的成本，结合第7步的收益，计算出架构策略的ROI,按ROI排序，从而确定选取策略的优先级。

4.其他评估方法

SAEM、SAABNet、SACMM、SASAM、ALRRA、AHP、COSMIC+UML

8.3ATAM方法架构评估实践

该方法评估软件体系结构4各基本阶段：演示、调查和分析、测试、报告ATAM。

8.3.1阶段1——演示(Presentation)

初始阶段，3各步骤：

1.介绍ATAM

向所有人介绍ATAM评估过程及其相关信息，说明评估中使用的分析技术及评估的预期结果，解答成员问题。

2.介绍业务驱动因素

从系统业务的角度定义要评估的系统功能，利益相关方、要达成的业务目标，还有一些其他必须好绿的系统限制信息。

利益相关者：最终用户、架构师、开发人员。

评估中使用Event框架，最终用户提供系统输入，架构师是时间框架的创建者，开发人员负责构建使用事件框架的事件驱动的应用程序。

3.介绍要评估的体系结构

这里要介绍一下要评估的架构了，侧重描述体系结构、事件可用性以及体系结构的质量要求。还需要演示架构。

关键问题：技术约束、架构与其他系统的交互、为满足质量属性而实施的架构方法。        

举例：参考胡佛(Hoover)事件架构和“银行”(Banking)事件架构

8.3.2阶段2——调查和分析

这一阶段是对初始阶段的评估中重点关注的一些关键问题进行彻底调查。

第4步：确定架构方法

这一步是理解系统关键的需求的关键架构方法。架构团队解释架构的流程控制，采取了哪些措施达成关键目标以及达成关键目标的解释(标准)。

比如 胡佛的架构，从事件输入到事件消费的过程，构建如何调用，重用程度等等，完成了预期工作还有具有高度的可修改性，而且也留有钩子接口，可扩展性强。这就是解释了真个事件的流程，采取了事件控制器、队列等等达成了任务处理的关键目标，以及这样也是标准的事件框架的方式(达成目标的解释)。

第5步：生成质量属性效用树

在评估阶段系统最重要的质量属性目标被确定，并确定优先次序和完善。

这一步至关重要，因为它将所有利益相关方和评估人员的注意力集中在关系到体系成功至关重要的体系结构的不同方面。这是通过建立效用树来实现的。

效用树作用：

• 提供了一种使系统目标更加具体的方法，还提供了质量属性目标重要性的比较方式。因此它表达了系统整体的良好程度。

• 效用树包含了与系统有关的质量属性。
• 对利益相关者重要的质量属性要求(称之为情景)。

情景是一个说明利益相关者和系统之间的相互作用的陈述。这些情景用来判断架构的质量目标。

此阶段完成的结果是后面步骤使用的参考(情景优先列表).

具体步骤：

1)情景生成

情景生成是创建效用树之前的重要步骤。

下面的表显示了与每个利益相关者有关的情景以及它所代表的质量属性。

2)质量属性效用树生成

效用树以“效用”作为根结点，质量属性构成效用树的辅助级别。这些属性位于表8-9中的第3列。在每个质量属性中都会包含特定的质量属性说明，以提供对方案更精确的描述。后者形成了实用程序树中的叶节点。效用树沿着两个维度进行优先顺序：每个场景对系统成功的重要性以及对此场景实现(从架构师的角度来看)所带来的难易程度的估计。效用树中的优先级排名为高(H)、中(M)和低(L)。

效用为根节点，每个质量属性的精确描述为叶节点(一边是对系统成功的重要性，一边是此场景实现所带来的难易程度的统计)。 H>M>L

第6步：分析体系结构方法

利用效用树，彻底调查和分析，找出处理响应质量属性架构的方法，根据这些质量属性分析这些架构方法，并提供适当的解释。涉及架构方法的风险、非风险、敏感点、权衡点。

简单说就是根据效用树的这些质量属性找到达成目标的方法，然后取分析这些方法，解释为啥这样做，并用风险、非风险、敏感点、权衡点来表达。

这一步可分4各阶段

• 调查架构方法。

• 创建分析问题。

• 分析问题的答案
• 找出风险、非风险、敏感点和权衡点。

具体的例子看书吧。

8.3.3阶段3——测试

第7步——头脑风暴和优先场景

主要是从架构师的角度来理解理解质量属性要求。

利益相关者需要使用头脑风暴的三种场景：

●用例场景：在这种情况下，利益相关者就是最终用户。

●增长情景：代表了架构发展的方式。

●探索性场景：代表架构中极端的增长形式。

这一步执行的活动如下：

●首先，情景是在利益相关者的大风暴活动之后收集的。

●场景优先。与相同质量属性有关的所有场景都被合并，利益相关者投票选出他们认为最

重要的场景。每个利益相关者都被分配了一定数量的选票：

票数=场景总数×30??

●投票结束后，投票结果会被记录下来，场景按总票数排序。采取截止线以上的情况，其

余不予考虑。

●将优先头脑风暴情景列表与优先情景进行比较。优先方案从步骤5中的效用树中获得，

增加头脑风暴中的场景。

简单理解：

效用树虽然是有了，但是还需要头脑风暴再收集情景的优先列表(用于补充效用树)，然后跟效用树比较，最终投票排出来顺序。

第8步——分析架构方法

这一步与第6步类似，唯一区别是第6步的分析体系结构方法高优先级的质量属性来自效用树，这里是经过头脑风暴补充后的汇总结果来分析。

这一步分为四个主要阶段：

●调查架构方法。

●创建分析问题。

●分析问题的答案。

●找出风险、非风险、敏感点和权衡点。

具体例子看书吧

8.3.4阶段4——报告ATAM

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

ATAM团队的主要发现通常包括：

●一种效用树；

●一组生成的场景；

●一组分析问题；

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

●确定的架构方法。

报告中包含的所有内容在前述的8个步骤中已经进行了介绍。