软件系统属性包括功能属性和质量属性，软件架构重点关注的是质量属性。架构的基本需求是在满足功能属性的前提下，关注软件系统质量属性。为了精确、定量地表达系统的质量属性，通常会采用质量属性场景的方式进行描述。
在确定软件系统架构，精确描述质量属性场景后，就需要对系统架构进行评估。软件系统架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。它也可以灵活地运用于软件架构评审等工作。
软件系统质量属性
质量属性概念
软件系统的质量就是“软件系统与明确地和隐含地定义的需求相一致的程度”。更具体地说，软件系统质量是软件与明确地叙述的功能和性能需求文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。根据GB/T16260.1定义，从管理角度对软件系统质量进行度量，可将影响软件质量的主要因素划分为6种维度特性:功能性、可靠性、易用性、效率、维护性与可移植性。其中功能性包括适合性、准确性、互操作性、依从性、安全性；可靠性包括容错性、易恢复性、成熟性;易用性包括易学性、易理解性、易操作性；效率包括资源特性和时间特性；维护性包括可测试性、可修改性、稳定性和易分析性；可移植性包括适应性、易安装性、一致性和可替换性。
软件系统质量属性(Quality Attribute)是一个系统的可测量或者可测试的属性，用来描述系统满足利益相关者(Stakcholders)需求的程度。基于软件系统的生命周期，可以将软件系统的质量属性分为开发期质量属性和运行期质量属性2个部分。
-
开发期质量属性
开发期质量属性主要指在软件开发阶段所关注的质量属性，主要包含6个方面。
(1)易理解性:指设计被开发人员理解的难易程度。
(2)可扩展性:软件因适应新需求或需求变化而增加新功能的能力，也称为灵活性。
(3)可重用性:指重用软件系统或某一部分的难易程度。
(4)可测试性:对软件测试以证明其满足需求规范的难易程度。
(5)可维护性:当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度。
(6)可移植性:将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。 -
运行期质量属性
运行期质量属性主要指在软件运行阶段所关注的质量屆性，主要包含7个方面。
(1)性能:性能是指软件系统及时提供相应服务的能力，如速度、响应时间、吞吐量和容量等的要求。
(2)安全性:指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
(3)可伸缩性:指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力。
(4)互操作性:指本软件系统与其他系统交换数据和相互调用服务的难易程度。
(5)可靠性:软件系统在一定的时间内持续无故障运行的能力。
(6)可用性:指系统在一定时间内正常工作的时间所占的比例。可用性会受到系统错误，恶意攻击，高负载等问题的影响。
(7)鲁棒性:是指软件系统在非正常情况(如用户进行了非法操作、相关的软硬件系统发生了故障等)下仍能够正常运行的能力，也称健壮性或容错性。
面向架构评估的质量属性
性能
性能(Performance)是指系统的响应能力，即要经过多长时间才能对某个事件做出响应（响应时间），或者在某段事件内系统所能处理的事件的个数（QPS）。
经常用单位时间内所处理事务的数量或系统完成某个事务处理所需的时间来对性能进行定量表示。性能测试经常要使用基准测试程序。
可靠性
可靠性(Reliability)是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。可靠性是最重要的软件特性，通常用来衡量在规定的条件和时间内，软件完成规定功能的能力。可靠性通常用平均失效等待时间(Mean Time To Failure,MTTF)和平均失效间隔时间(Mean Time Between Failure,MTBF)来衡量。
在失效率为常数和修复时问很短的情况下，MTTF和MTBF几乎相等。可靠性可以分为两个方面。
- 容错。容错的目的是在错误发生时确保系统正确的行为，并进行内部“修复”。例如在一个分布式软件系统中失去了一个与远程构件的连接，接下来恢复了连接。在修复这样的错误之后，软件系统可以重新或重复执行进程间的操作，直到错误再次发生。
- 健壮性。这里说的是保护应用程序不受错误使用和错误输入的影响，在发生意外错误事件时确保应用系统处于预先定义好的状态。值得注意的是，和容错相比，健壮性并不是说在错误发生时软件可以继续运行，它只能保证软件按照某种已经定义好的方式终止执行。软件架构对软件系统的可靠性有巨大的影响。例如，软件架构设计上通过在应用程序内部采用冗余机制，或集成监控构件和异常处理，以提升系统可靠性。
可用性
可用性(Availability)是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
安全性
安全性(Security)是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性可根据系统可能受到的安全威胁类型来分类。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。其中，机密性保证信息不泄露给未授权的用户、实体或过程；完整性保证信息的完整和准确，防止信息被非法修改;不可否认性是指信息交换的双方不能否认其在交换过程中发送信息或接收信息的行为:可控性保证对信息的传播及内容具有控制的能力，防止为非法者所用。
可修改性
可修改性(Modifiability)是指能够快速地以较高的性价比对系统进行变更的能力。通常以某些具体的变更为基准，通过考查这些变更的代价来衡量可修改性。
可修改性包含以下4个方面。
- 可维护性(Maintainability)。这主要体现在问题的修复上，在错误发生后“修复”软件系统。可维护性好的软件架构往往能做局部性的修改并能使对其他构件的负面影响最小化。
- 可扩展性(Extendibility)。这一点关注的是使用新特性来扩展软件系统，以及使用改进版本方式替换构件并删除不需要或不必要的特性和构件。为了实现可扩展性，软件系统需要松散耦合的构件。其目标是实现一种架构，能使开发人员在不影响构件客户的情况下替换构件。支持把新构件集成到现有的架构中也是必要的。
- 结构重组(Reassemble)。这一点处理的是重新组织软件系统的构件及构件间的关系，例如通过将构件移动到一个不同的子系统而改变它的位置。为了支持结构重组，软件系统需要精心设计构件之间的关系。理想情况下，它们允许开发人员在不影响实现的主体部分的情況下灵活地配置构件。
- 可移植性(Portability)。可移植性使软件系统适用于多种硬件平台、用户界面、操作系统、编程语言或编译器。为了实现可移植，需要按照硬件、软件无关的方式组织软件系统。可移植性是系统能够在不同计算环境下运行的能力，这些环境可能是硬件、软件，也可能是两者的结合。如果移植到新的系统需要做适当更改，则该可移植性就是一种特殊的可修改性。
功能性
功能性(Functionality)是系统能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
可变性
可变性(Changeability)是指架构经扩充或变更而成为新架构的能力。这种新架构应该符合预先定义的规则，在某些具体方面不同于原有的架构。当要将某个架构作为一系列相关产品(例如，软件产品线)的基础时，可变性是很重要的。
互操作性
作为系统组成部分的软件不是独立存在的，通常与其他系统或自身环境相互作用。为了支持互操作性，软件架构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，这种互操作性也影响应用的软件架构。
质量属性场景描述
为了精确描述软件系统的质量属性，通常采用质量属性场景(Quality Attribute Scenario)作为描述质量属性的手段。质量属性场景是一个具体的质量属性需求，是利益相关者与系统的交互的简短陈述。
质量属性场景主要关注可用性、可修改性、性能、可测试性、易用性和安全性等6类质量属性，下面分别列表进行介绍。
可用性质量属性场景
可用性质量属性场景所关注的方面包括系统故障发生的频率、出现故障时会发生什么情况、允许系统有多长是非正常运行、什么时候可以安全地出现故障、如何防止故障的发生以及发生故障时要求进行哪种通知。
可修改性质量属性场景
可修改性质量属性场景主要关注系统在改变功能、质量属性时需要付出的成本和难度，可修改性质量属性场景可能发生在系统设计、编译、构建、运行等多种情况和环境下。
性能质量属性场景
性能质量属性场景主要关注系统的响应速度，可以通过效率、响应时间、吞吐量、负载来客观评价性能的好坏。
可测试性质量厲性场景
可测试性质量属性场景主要关注系统测试过程中的效率，发现系统缺陷或故障的难易程度等。
易用性质量属性场景
易用性质量属性场景主要关注用户在使用系统时的容易程度，包括系统的学习曲线、完成操作的效率、对系统使用过程的满意程度等。
安全性质量属性场景
安全性质量属性场景主要关注系统在安全性方面的要素，衡量系统在向合法用户提供服务的同时，阻止非授权用户使用的能力。
系统架构评估
系统架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。它利用数学或逻辑分析技术，针对系统的一致性、正确性、质量属性、规划结果等不同方面，提供描述性、预测性和指令性的分析结果。
系统架构评估的方法通常可以分为3类:基于调查问卷或检查表的方式、基于场景的方式和基于度量的方式。
基于调查问卷或检查表的方法。
该方法的关键是要设计好问卷或检查表，充分利用系统相关人员的经验和知识，获得对架构的评估。该方法的缺点是在很大程度上依赖于评估人员的主观推断。
基于场景的评估方法。
基于场景的方式由卡耐基梅隆大学软件工程研究所首先提出并应用在架构权衡分析法(Architecture Tradeoff Analysis Method,ATAM)和软件架构分析方法(Software Architecture Analysis Method,SAAM)中。它是通过分析软件架构对场景(也就是对系统的使用或修改活动)的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。
基于度量的评估方法。
它是建立在软件架构度量的基础上的，涉及了个基本活动，首先需要建立质量属性和度量之问的映射原则，然后从软件架构文档中获取度量信息，最后根据映射原则分析推导出系统的质量属性。
系统架构评估中的重要概念
敏感点(Sensitivity Point)和权衡点(Tradeoff Point)。
敏感点和权衡点是关键的架构决策。敏感点是一个或多个构件(或构件之间的关系)的特性。研究敏感点可使设计人员或分析员明确在搞清楚如何实现质量目标时应注意什么。权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。例如，改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响系统性能。如果某个机密消息的处理有严格的时间延迟要求，则加密级别可能就会成为一个权衡点
风险承担者(Stakeholders)或者称为利益相关人。
系统的架构涉及很多人的利益，这些人都对架构施加各种影响，以保证自己的目标能够实现。
场景(scenarios)。
在进行架构评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该架构优劣的标准。为得出这些目标而采用的机制称之为场景。场景是从风险承担者的角度对与系统的交互的简短描述。在架构评估中，一般采用**刺激(Stimulus)、环境(Environment)和响应(Response)**三方面来对场景进行描述。
系统架构评估方法
SAAM方法
SAAM(Scenarios-based Architecture Analysis Method)是卡耐基梅隆大学软件工程研究所的Kazman等人于1983年提出的一种非功能质量属性的架构分析方法，是最早形成文档并得到广泛使用的软件架构分析方法。最初它用于比较不同软件体系的架构，以分析系统架构的可修改性，后来实践证明它也可用于其他质量属性如可移植性、可扩充性等，最终发展成了评估一个系统架构的通用方法。
- 特定目标。SAAM的目标是对描述应用程序属性的文档，验证基本的架构假设和原则。此外，该分析方法有利于评估架构固有的风险。SAAM指导对架构的检查，使其主要关注潜在的问题点，如需求冲突，或仅从某一参与者观点出发得出的不全面的系统设计。SAAM不仅能够评估架构对于特定系统需求的使用能力，也能被用来比较不同的架构。
- 评估技术。SAAM所使用的评估技术是场景技术。场景代表了描述架构属性的基础，描述了各种系统必须支持的活动和可能存在的状态变化。
- 质量属性。这一方法的基本特点是把任何形式的质量属性都具体化为场景，但可修改性是SAAM分析的主要质量属性。
- 风险承担者。SAAM协调不同参与者之问感兴趣的共同方面，作为后续决策的基础，达成对架构的共识。
- 架构描述。SAAM用于架构的最后版本，但早于详细设计。架构的描述形式应当被所有参与者理解。功能、结构和分配被定义为描述架构的3个主要方面。
- 方法活动。SAAM的主要输入是问题描述、需求声明和架构描述。
SAAM分析评估架构的过程包括5个步骤，即场景开发、架构描述、单个场景评估、场景交互和总体评估。通过各类风险承担者协商讨论，开发一些任务场景，体现系统所支持的各种活动。用一种易于理解的、合乎语法规则的架构描述软件架构，体现系统的计算构件、数据构件以及构件之间的关系(数据和控制)。对场景(直接场景和问接场景)生成一个关于特定架构的场景描述列表。通过对场景交互的分析，能得出系统中所有场景对系统中的构件所产生影响的列表。最后，对场景和场景间的交互作一个总体的权衡和评价。 - 己有知识库的可重用性:SAAM不考虑这个问题。
- 方法验证:SAAM是一种成熟的方法，已被应用到众多系统中，这些系统包括空中交通管制、嵌入式音频系统、WRCS(修正控制系统)、KWIC(根据上下文查找关键词系统)等。
ATAM方法
架构权衡分析方法(Architecture Tradeofr Analysis Method,ATAM)是在SAAM的基础上发展起来的，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。
- 特定目标。ATAM的目标是在考虑多个相互影响的质量属性的情况下，从原则上提供一种理解软件架构的能力的方法。对于特定的软件架构，在系统开发之前，可以使用ATAM方法确定在多个质量属性之间折中的必要性。
- 质量属性。ATAM方法分析多个相互竞争的质量属性。开始时考虑的是系统的可修改性、安全性、性能和可用性。
- 风险承担者。在场景、需求收集相关活动中，ATAM方法需要所有系统相关人员的参与。
- 架构描述。架构空间受到历史遗留系统、互操作性和以前失败的项目约束。架构描述基于5种基本结构来进行，这5种结构是从Kruchten的4+1视图派生而来的。其中逻辑视图被分为功能结构和代码结构。这些结构加上它们之间适当的映射可以完整地描述一个架构。用一组消息顺序图表示运行时的交互和场景，对架构描述加以注解。ATAM方法被用于架构设计中，或被另一组分析人员用于检查最终版本的架构。
- 评估技术。可以把ATAM方法视为一个框架，该框架依赖于质量属性，可以使用不同的分析技术。它集成了多种优秀的单一理论模型，其中每种都能够高效、实用地处理属性。该方法使用了场景技术。从不同的架构角度，有3种不同类型的场景，分别是用例(包括对系统典型的使用、引出信息)、增长场景(用于涵盖那些对它的系统的修改)、探测场景(用于涵盖那些可能会对系统造成过载的极端修改)。ATAM还使用定性的启发式分析方法(Qualitative Analysis Heuristics)，在对一个质量属性构造了一个精确分析模型时要进行分析，定性的启发式分析方法就是这种分析的粗粒度版本。
- 方法的活动。ATAM被分为4个主要的活动领域(或阶段)，分别是场景和需求收集、架构视图和场景实现、属性模型构造和分析、折中。
- 领域知识库的可重用性。领域知识库通过基于属性的架构风格(Attribute Based Architecture Style)维护。
- 方法验证。
ATAM方法采用效用树(Utilitytree)这一工具来对质量属性进行分类和优先级排序。效用树的结构包括:树根一质量属性一属性分类一质量属性场景(叶子节点)。需要注意的是，ATAM主要关注4类质量属性:性能、安全性、可修改性和可用性，这是因为这4个质量属性是利益相关者最为关心的。
得到初始的效用树后，需要修剪这棵树，保留重要场景(通常不超过50个)，再对场景按重要性给定优先级(用H/M/L的形式)，再按场景实现难易来确定优先级(用H/M/L的形式)，这样对所选定的每个场景就有一个优先级对(重要度)，如(H、L)表示该场景重要且易实现。（个人想法：是不是再加一个紧急程度(用H/M/L的形式)）
CBAM方法
在大型复杂系统的构建过程中，经济性通常是需要考虑的首要因素。因此，需要从经济角度建立成本、收益、风险和进度等方面软件的“经济”模型。成本效益分析法(the Cost Benefit Analysis Method,CBAM)是在ATAM上构建，用来对架构设计决策的成本和收益进行建模，是优化此类决策的一种手段。CBAM的思想就是架构策略影响系统的质量属性，反过来这些质量属性又会为系统的项目干系人带来一些收益(称为“效用”)，CBAM协助项目干系人根据其投资回报(Return On Investment，ROI)选择架构策略。CBAM在ATAM结束时开始，它实际上使用了ATAM评估的结果。
CBAM方法分为以下8个步骤。
- 整理场景。整理ATAM中获取的场景，根据商业目标确定这些场景的优先级，并选取优先级最高的1/3的场景进行分析。
- 对场景进行求精。为每个场景获取最坏情况、当前情況、期望情況和最好情况的质量属性响应级别。
- 确定场景的优先级。项目关系人对场景进行投票，其投票是基于每个场景“所期望的”响应值，根据投票结果和票的权值，生成一个分值〈场景的权值)。
- 分配效用。对场景的响应级别(最坏情况、当前情况、期望情况和最好情况)确定效用表。
- 架构策略涉及哪些质量属性及响应级别，形成相关的“策略一场景一响应级别”的对应关系。
- 使用内插法确定“期望的”质量属性响应级别的效用。即根据第4步的效用表以及第5步的对应关系，确定架构策略及其对应场景的效用表。
- 计算各架构策略的总收益。根据第3步的场景的权值及第6步的架构策略效用表，计算出架构策略的总收益得分。
- 根据受成本限制影响的ROI选择架构策略。根据开发经验估算架构策略的成本，结合第7步的收益，计算出架构策略的ROI，按ROI排序，从而确定选取策略的优先级。
其他评估方法
上面所介绍的SAAM、ATAM和CBAM方法是架构评估中被公认的3种方法。
ATAM 方法架构评估实践
分析体系结构方法
这是“调查和分析〞阶段的最后一步。在这一步中，人们分析前一步生成的效用树的输出，并进行彻底调查和分析，找出处理相应质量属性架构的方法。人们根据这些质量属性分析这两种架构，并为它们提供适当的解释。这里还确定了每种架构方法的风险、非风险、敏感点和权衡点。
调查架构方法
在识别出对系统目标至关重要的质量属性后，我们分析两种架构并确定它们如何支特这些质量属性。我们对体系结构进行详细的调查，以了解这些质量属性要求是否得到满足。（方案选择其实就是先找到我们所关注的点，然后根据我们最关心的点，来选择相关方案、其中可能需要做权衡，方案也可能并发是非A既B，也可能是结合使用（利用好优点，屏其缺点））
- 可变性。可变性是定义如何扩展或修改架构以生成新体系结构的属性。
- 可靠性。可靠性是决定系统响应故障的行为以及系统如何随时间运行的特性。
- 集成性(Conceptual Integrity)。该属性定义了统一各级系统设计的基础主题。架构应该是一致的，在执行架构的所有进程时使用最少的数据和控制机制。
- 功能性。此属性标识系统中组件之间的交互以及系统是否执行预期的任务。
- 可修改性。顾名思义，该属性验证系统是否能够以一种快速、经济、高效的方式进行修改。它验证了体系结构如何处理对组件所做的更改，以及是否可以将任何不同的应用程序挂接到框架。
创建分析问题
本步骤的下一个阶段涉及收集上面讨论过的高优先级场景中产生的分析问题。在现实生活中，所有利益相关者都会收集分析问题。在这个项目中，我们只是简单地创建了优先场景中显著的示例问题。分析问题与上面讨论的每种架构方法相关联:并面向重要的质量属性。以下是分析问题列表和正在解决的属性:
- 架构的组件可以重复用于未来的项目吗?(变化性)
- 未来可以扩展框架以适应新的应用程序或新组件吗?(变化性)
- 系统会处理用户提供的任何输入并处理无效输入吗?(可靠性)
- 架构的行为是否一致?(概念完整)
- 是否可以将任何新的应用程序特定功能添加到架构中?(可修改性)
- 系统能否以短时间和成本效益的方式进行修改?(修改性)
- 组件是否正确交互?(功能性)
- 体系结构是否正确执行其事件处理任务?(功能)
分析问题的答案
这一步的第三阶段是根据两种评估架构对上述分析问题提供合理的解释或答案。
找出风险、非风险、敏感点和权衡点。
此步骤的最后阶段是确定风险、无风险、敏感点和权衡点。
风险是架构中的一个问题点，后者不支持给定的优先级质量属性。非风险是体系结构的优势，后者实现特定的优先级质量属性。敏感点是一个或多个组件的属性，对于实现给定的质量属性至关重要。如果架构对多个属性敏感，那么该点称为权衡点。
要使用头脑风暴的三种场景:
- 用例场景:在这种情况下，利益相关者就是最终用户。
- 增长情景:代表了架构发展的方式。
- 探索性场景:代表架构中极端的增长形式。
这一步执行的活动如下:
- 首先，情景是在利益相关者的大风暴活动之后收集的。
- 场景优先。与相同质量属性有关的所有场景都被合并，利益相关者投票选出他们认为最重要的场景。每个利益相关者都被分配了一定数量的选票:票数=场景总数×30%。
- 投票结束后，投票结果会被记录下来，场景按总票数排序。采取截止线以上的情况，其余不子考虑。
- 将优先头脑风暴情景列表与优先情景进行比较。增加头脑风暴中的场景。
报告ATAM
这是ATAM评估的最后阶段，其中提供了评估期间收集的所有信息。ATAM团队将他们的发现呈现给利益相关者。
ATAM团队的主要发现通常包括:
- 一种效用树;
- 一组生成的场景;
- 一组分析问题;
- 一套确定的风险和非风险;
- 确定的架构方法。