八、软考-系统架构设计师笔记-系统质量属性和架构评估

大家好，欢迎来到IT知识分享网。

1、软件系统质量属性

软件架构的定义
软件架构是指在一定的设计原则基础上，从不同角度对组成系统的各部分进行搭配和安排，形成系统的多个结构而组成架构，它包括该系统的各个构件，构件的外部可见属性及构件之间的相互关系。
软件架构是保证软件质量的根本措施。

软件架构设计与生命周期

• 1.需求分析阶段
• 2.设计阶段
• 3.实现阶段
• 4.构件组装阶段
• 5.部署阶段
• 6.后开发阶段

软件架构的作用

• 架构设计能满足系统的品质
• 架构设计使受益人达成一致的目标
• 架构设计能够支持计划编制过程
• 架构设计对系统开发的指导性
• 架构设计能有效地管理复杂性
• 架构设计为复用奠定基础
• 架构设计能够降低维护费用
• 架构设计能够支持冲突分析

体系结构的设计方法(ABSD)概述
ABSD方法是由体系结构驱动的。即指构成体系结构的商业、质量和功能需求的组合驱动的。
ABSD 方法有3个基础：

• 基础功能的分解。在功能分解中，ABSD 方法使用已有的基于模块的内聚和耦合技术。
• 通过选择体系结构风格来实现质量和商业需求
• 软件模板的使用，软件模板包括描述所有这种类型的元素在共享服务和底层构造的基础上如何进行交互。

概念与术语
1.设计元素
ABSD 方法是一个自顶向下，递归细化的方法，软件系统的体系结构通过该方法得到细化直到能产生软件构件和类。在最顶层，系统被分解为若干概念子系统和一个或若干个软件模板。
在第2层，概念子系统又被分解成概念构件和一个或若干个附加软件模板。

例：
基于体系结构的软件设计(Architecture-Based Software Design，ABSD)方法是体系结构驱动，即指构成体系结构的( )的组合驱动的。ABSD方法是一个自顶向下、递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生( )。

A.产品、功能需求和设计活动 B.商业、质量和功能需求 C.商业、产品和功能需求 D.商业、质量和设计活动

A.软件产品和代码 B.软件构件和类 C.软件构件和连接件 D.类和软件代码

答案： B、B

解析 ： ABSD方法是由体系结构驱动的。即指构成体系结构的商业、质量和功能需求的组合驱动的。

ABSD 方法是一个自顶向下，递归细化的方法，软件系统的体系结构通过该方法得到细化直到能产生软件构件和类。

视角与视图
考虑体系结构时，要从不同的视角来观察对架构的描述，这需要软件设计师考虑体系结构的不同属性。例如，展示功能组织的静态视角能判断质量特性，展示并发行为的动态视角能判断系统行为特性，因此，选择的特定视角或视图(如逻辑视图、进程视图、实现视图和配置视图)可以全方位的考虑体系结构设计。使用逻辑视图来记录设计元素的功能和概念接口，设计元素的功能定义了它本身在系统中的角色，这些角色包括功能、性能等。

用例和质量场景
用例是系统给予用户一个结果值的功能点，用例用来捕获功能需求。在使用用例捕获功能需求的同时，人们通过定义特定场景来捕获质量需求，并称这些场景为质量场景。这样一来，在软件开发过程中，人们使用质量场景捕获变更、性能、可靠性和交互性，分别称之为变更场景、性能场景、可靠性场景和交互性场景。质量场景必须包括预期的和非预期的场景。

例如，一个预期的性能场景是估计每年用户数量增加 10% 的影响，一个非预期的场景是估计每年用户数量增加 100% 的影响。非预期场景可能不会真正实现，但它在决定设计的边界条件时很有用。

基于体系结构的开发模型

• 1.体系结构需求
• 2.体系结构设计
• 3.体系结构文档化
• 4.体系结构复审
• 5.体系结构实现
• 6.体系结构演化

体系结构需求
需求过程主要是获取用户需求，标识系统中要用到的构件。架构需求分为需求获取、标识构件和需求评审3个步骤。

体系结构设计
体系结构设计是一个迭代过程，分为提出软件架构模型、把已标识的构件映射到软件架构中、分析构件之间的相互作用、产生软件体
系结构及设计评审。

体系结构文档化
文档是在系统演化的每个阶段，系统设计与开发人员的通信媒介，是为验证体系结构设计和提炼或修改这些设计 (必要时)所执行预先
分析的基础。体系结构文档化过程主要输出架构需求规格说明和测试架构需求的质量设计说明书。

体系结构复审
体系结构设计、文档化和复审是一个迭代过程。复审由外部人员（用户代表和领域专家）进行。
复审的目的是标识潜在的风险，及时发现体系结构设计中的缺陷和错误，包括体系结构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求等。

体系结构实现
实现的过程以复审后的文档化的架构说明书为基础，在架构说明书中，已经定义了系统中的构件及它们间的关系，可以从构件库中查找符
合接口约束的构件，必要时开发新的满足要求的构件。然后，按照设计提供的结构，通过组装支持工具把这些构件的实现体组装起来，完成整个软件系统的连接与合成。

体系结构的演化
在构件开发过程中，用户的需求可能会有变动，需要相应地修改软件体系结构，以适应已发生变化的软件需求。

2、系统架构评估

架构风格概述
架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族，即一个架构定义一个词汇表和一组约束。词汇表包含一些构件和连接件类型，约束指出系统是如何将这些构件和连接件组合起来的。架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。

通用架构风格的分类如下：

• (1)数据流风格：批处理序列；管道/过滤器。
• (2)调用/返回风格：主程序/子程序；面向对象风格；层次结构；客户端/服务器。
• (3)独立构件风格：进程通信；事件系统。
• (4)虚拟机风格：解释器；基于规则的系统。
• (5)仓库风格：数据库系统；超文本系统；黑板系统。

数据流体系结构风格

1.批处理体系结构风格
在批处理风格的软件体系结构中，每个处理步骤是一个单独的程序，每一步必须在前一步结束后才能开始，并且数据必须是完整的，以整体的方式传递。它的基本构件是独立的应用程序，连接件是某种类型的媒介。连接件定义了相应的数据流图，表达拓扑结构。

例：
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式，其中，在批处理风格软件体系结构中，每个处理步骤是一个单独的程序，每一步必须在前一步结束后才能开始，并且数据必须是完整的，以( )的方式传递。基于规则的系统包括规则集、规则解释器、规则/数据选择器及( )。
A.迭代 B.整体 C.统一格式 D.递增
A.解释引擎 B.虚拟机 C.数据 D.工作内存

答案： B、D

管道-过滤器体系结构风格
当数据源源不断地产生，系统就需要对这些数据进行若干处理(分析、计算、转换等)。解决方案是把系统分解为几个序贯的处理步骤，步
骤之间通过数据流连接，一个步骤的输出是另一个步骤的输入。每个处理步骤由一个过滤器(Fiter)实现，处理步骤间的数据传输由管道(Pipe)负责。每个处理步骤(过滤器)都有一组输入和输出，过滤器从管道中读取输入的数据流，经过内部处理，然后产生输出数据流并写入管道中。管道-过滤器风格的基本构件是过滤器。典型的管道/过滤器体系结构的例子：

• ①UNIX Shell编写的程序
• ②传统的编译器

调用/返回体系结构风格
调用/返回风格是指在系统中采用了调用与返回机制。利用调用返回实际上是一种分而治之的策略，主要思想是将一个复杂的大系统分解为若干子系统，以便降低复杂度，并且增可修改性。调用/返回体系结构风格主要包括：

• 主程序/子程序风格
• 面向对象风格
• 层次风格
• 客户端/服务器风格

主程序/子程序风格
主程序/子程序风格一般采用单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序。子程序通常可合成为模块。过程调用作为交互机制，即充当连接件。调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性。

面向对象风格
面向对象风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象，或者说是抽象数据类型的实例。

层次型体系结构风格
层次系统组成一个层次结构，每一层为上层提供服务，并作为下层的客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层接口只对相邻的层可见。由于每一层最多只影响两层，只要给相邻层提供相同的接口，允许每层用不同的方法实现，这同样为软件重用提供了强大的支持。这样的系统中构件在层上实现了虚拟机。连接件由通过决定层间如何交互的协议来定义，拓扑约束包括相邻层间交互的约束。

例：
软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式，按照软件架构风格，物联网系统属于( )软件架构风格。
A.层次型
B.事件系统
C.数据流
D. C2

答案： A

解析：
物联网系统是指通过互联网将各种物理设备、传感器、软件、网络等连接起来的系统。在物联网系统中，通常采用层次型的软件架构风格。
层次型架构将系统划分为多个层次或层，每个层次都有特定的责任和功能。数据和控制流沿着层次进行传递和处理，各个层次的功能相对独立，各层之间通过定义好的接口进行通信和交互。

客户端/服务器体系结构风格
C/S软件体系结构是基于资源不对等，且为实现共享而提出的，两层 C/S 体系结构有3 个主要组成部分：数据库服务器、客户应用程序和网络。服务器 (后台)负责数据管理，客户机(前台)完成与用户的交互任务，称为”胖客户机，瘦服务器”。

以数据为中心的体系结构风格
1.仓库体系结构风格
仓库(Repository)是存储和维护数据的中心场所。在仓库风格中，有两种不同的构件：

• 中央数据结构(仓库)，说明当前数据的状态。
• 独立构件，它对中央数据进行操作。

黑板体系结构风格
黑板体系结构风格适用于解决复杂的非结构化的问题，能在求解过程中综合运用多种不同知识源，使得问题的表达、组织和求解变得比较容易。黑板系统是一种问题求解模型，是组织推理步骤、控制状态数据和问题求解之领域知识的概念框架。
黑板系统的传统应用是信号处理领域，如语音和模式识别。另一应用是松耦合代理数据共享存取。

黑板系统主要由三部分组成：

• (1)知识源。知识源中包含独立的、与应用程序相关的知识，知识源之间不直接进行通讯，它们之间的交互只能通过黑板来完成。
• (2)黑板数据结构。黑板数据是按照与应用程序相关的层次来组织的解决问题的数据，知识源通过不断地改变黑板数据来解决问题。
• (3)控制。控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识。

虚拟机体系结构风格
虚拟机体系结构风格的基本思想是人为构建一个运行环境，在这个环境之上，可以解析与运行自定义的一些语言，这样来增加架构的灵活性。虚拟机体系结构风格主要包括解释器风格和规则系统风格。

1.解释器体系结构风格
一个解释器通常包括完成解释工作的解释引擎，一个包含将被解释的代码的存储区，一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行进度的数据结构。解释器通常被用来建立一种虚拟机以弥合程序语义与硬件语义之间的差异。其缺点是执行效率低。典型的例子是专家系统。

2.规则系统体系结构风格
基于规则的系统包括规则集、规则解释器、规则/数据选择器工作内存。

例：
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式，其中，在批处理风格软件体系结构中，每个处理步骤是一个单独的程序，每一步必须在前一步结束后才能开始，并且数据必须是完整的，以( )的方式传递。基于规则的系统包括规则集、规则解释器、规则/数据选择器及( )。
A.迭代 B.整体 C.统一格式 D.递增
A.解释引擎 B.虚拟机 C.数据 D.工作内存

独立构件体系结构风格
独立构件风格主要强调系统中的每个构件都是相对独立的个体，它们之间不直接通信，以降低耦合度，提升灵活性。独立构件风格主要包括进程通信和事件系统风格。

1.进程通信体系结构风格
在进程通信结构体系结构风格中，构件是独立的过程，连接件是消息传递。这种风格的特点是构件通常是命名过程，消息传递的方式可以是点到点、异步或同步方式及远程过程调用等。

2.事件系统体系结构风格
基于事件的隐式调用风格的思想是构件不直接调用一个过程而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样一个事件的触发就导致了另一模块中的过程的调用。
特点是事件的触发者并不知道哪些构件会被这些事件影响，这使得不能假定构件的处理顺序，甚至不知道哪些过程会被调用，因此，许多隐式调用的系统也包含显式调用作为构件交互的补充形式。

软件架构复用的定义及分类
软件复用是一种系统化的软件开发过程，通过识别、开发、分类、获取和修改软件实体，以便在不同的软件开发过程中重复的使用它们。早期的软件复用主要是代码级复用，被复用的专指程序，后来扩大到包括领域知识、开发经验、体系结构、需求、设计、测试、代码和文档、过程方法和工具等一切有关方面。软件架构复用的类型包括机会复用和系统复用。机会复用是指开发过程中，只要发现有可复用的资产，就对其进行复用。系统复用是指在开发之前，就要进行规划，以决定哪些需要复用。

软件架构复用的原因
软件架构复用可以减少开发工作、减少开发时间以及降低开发成本，提高生产力。还可以提高产品质量使其具有更好的互操作性。同时，软件架构复用会使产品维护变得更加简单。

软件架构复用的基本过程
复用的基本过程包括三个阶段：

• 1.构造/获取可复用的软件资产
• 2.管理可复用资产
• 3.使用可复用的资产

1.构造/获取可复用的软件资产
首先需要构造恰当的、可复用的资产，并且这些资产必须是可靠的、可被广泛使用的、易于理解和修改的。

2.管理可复用资产
通过构件库对可复用构件进行存储和管理，构件库应提供的主要功能包括构件的存储、管理、检索以及库的浏览与维护等，以及支持使用者有效地、准确地发现所需的可复用构件。在这个过程中，存在两个关键问题：

• 构件分类，是指将数量众多的构件按照某种特定方式组织起来。
• 构件检索，是指给定几个查询需求，能够快速准确地找到相关构件。

3.使用可复用的资产
在最后阶段，通过获取需求，检索复用资产库，获取可复用资产，并定制这些可复用资产：修改、扩展、配置等，最后将它们组装与集成，形成最终系统。

例：
软件复用过程的主要阶段包括( )。
A.分析可复用的软件资产、管理可复用资产和使用可复用资产
B.构造/获取可复用的软件资产、管理可复用资产和使用可复用资产
C.构造/获取可复用的软件资产和管理可复用资产
D.分析可复用的软件资产和使用可复用资产

答案：B

特定领域软件架构DSSA
特定领域软件架构是在一个特定领域中为一组应用提供组织结构参考的标准软件框架。其目标是支持在一个特定领域中多个应用的生成。

DSSA中领域的含义：

• (1)垂直域。定义一个特定的系统族，包含整个系统族内的多个系统，结果是在该领域中可作为系统的可行解决方案的一个通用软件架构。
• (2)水平域。定义了在多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统族的特定部分功能，无法为系统提供完整的通用架构。

1.DSSA的基本活动

• (1)领域分析。主要目的是获得领域模型。领域模型描述领域中系统之间的共同的需求，所描述的需求为领域需求。
• (2)领域设计。主要目的是获得DSSA。DDSA描述在领域模型中表示需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统需求的一个高层次的设计。
• (3)领域实现。主要目的是依据领域模型及DSSA开发和组织可重用信息。

例：
DSSA(Domain Specific Software Architecture)就是在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构，实施DSSA的过程中包含了一些基本的活动。其中，领域模型是( )阶段的主要目标。
A.领域设计
B.领域实现
C.领域分析
D.领域工程

2.参与DSSA的人员

• 领域专家：有经验的用户，从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师。
• 领域分析师：具有知识工程背景的有经验的系统分析员来担任。
• 领域设计人员：由有经验的软件设计人员来担任。
• 领域实现人员：由有经验的程序设计人员来担任。

3.DSSA的建立过程
DSSA的建立过程分为5个阶段，每个阶段又可分为一些步骤和子阶段，是并发的、递归的、反复的，是螺旋的。

• (1)定义领域范围。主要输出是领域中的应用需要满足一系列用户的需求。
• (2)定义领域特定的元素。编译领域字典和领域术语的同义词词典。
• (3)定义领域特定的设计和实现需求约束。
• (4)定义领域模型和架构。
• (5)产生、搜集可重用的产品单元。

DSSA包含两个过程：

• 领域工程：为一组相近或相似的应用建立基本能力与必备基础的过程，它覆盖了建立可重用软件元素的所有活动。
• 应用工程：通过重用软件资源，以领域通用体系结构为框架，开发出满足用户需求的一系列应用软件的过程 。
  

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

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

1.开发期质量属性
开发期质量属性指在软件开发阶段所关注的质量属性，包括：

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

2.运行期质量属性
运行期质量属性指在软件运行阶段所关注的质量属性，包含：

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

例：
软件系统质量属性(Quality Attribute)是一个系统的可测量或者可测试的属性，它被用来描述系统满足利益相关者需求的程度，其中，( )关注的是当需要修改缺陷、增加功能、提高质量属性时，定位修改点并实施修改的难易程度；( )关注的是当用户数和数据量增加时，软件系统维持高服务质量的能力。

答案： C 、B

面向架构评估的质量属性
为了评价一个软件系统，特别是软件系统的架构，需要进行架构评估。评估方法关注的质量属性有以下几种。

• 1.性能
• 2.可靠性
• 3.可用性
• 4.安全性
• 5.可修改性
• 6.功能性
• 7.可变性
• 8.互操作性

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

• (1)容错。容错的目的是在错误发生时确保系统正确的行为，并进行内部“修复”。
• (2)健壮性。这里说的是保护应用程序不受错误使用和错误输入的影响，在发生意外错误事件时确保应用系统处于预先定义好的状态。

平均失效间隔时间(MTBF)：是指相邻两次故障之间的平均时间，也称为平均故障间隔。

• 平均失效等待时间(MTTF)也称平均无故障时间，是指某个元件预计的可运作平均时间
• 平均故障修复时间(MTTR)：是描述产品由故障状态转为工作状
  态时修理时间的平均值。表示计算机的可维修性。平均失效间隔时间(MTBF)常与MTTF发生混淆。因为两次故障之间必然有修复行为，因此，MTBF中应包含MTTR。MTBF= MTTR+ MTTF 实际应用中MTTR很小，所以MTBF≈MTTF

例：
平均失效等待时间(mean time to failure, MTTF)和平均失效间隔时间(mean time between failure, MTBF)是进行系统可靠性分析时的重要指标，在失效率为常数和修复时间很短的情况下，( )。
A.MTTF远远小于MTBF
B.MTTF和MTBF无法计算
C.MTTF远远大于MTBF
D.MTTF和MTBF几乎相等

答案： D

2.可修改性
可修改性 (Modiability) 是指能够快速地以较高的性价比对系统进行变更的能力。通常以某些具体的变更为基准，通过考查变更的代价来衡量可修改性。可修改性包含以下 4个方面：

• (1)可维护性
• (2)可扩展性
• (3)结构重组
• (4)可移植性

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

质量属性场景描述
为了精确描述软件系统的质量属性，通常采用质量属性场景作为描述质量属性的手段。质量属性场景是一个具体的质量属性需求，是利益相关者与系统的交互的简短陈述。它由 6 部分组成：

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

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

可用性质量属性场景

可修改性质量属性场景

性能质量属性场景

可测试性质量属性场景

易用性质量属性场景

安全性质量属性场景

例：
为了精确描述软件系统的质量属性，通常采用质量属性场景(Quality Attibute Scenario)作为描述质量属性的手段。质量属性场景是一个具体的质量属性需求，是利益相关者与系统的交互的简短陈述，它由刺激源、刺激、环境、制品、( )六部分组成。其中，想要学习系统特性、有效使用系统、使错误的影响最低、适配系统、对系统满意属于( )质量属性场景的刺激。

答案： A 、C

解析： 见上面表格内容

系统架构评估的评估方法

• 1.基于调查问卷或检查表的方式
• 2.基于场景的方式
• 3.基于度量的方式

1.基于调查问卷或检查表的方式
该方法的关键是要设计好问卷或检查表，充分利用系统相关人员的经验和知识，获得对架构的评估。

• 优点：自由灵活，可评估多种质量属性，也可以在架构设计的多个阶段进行。
• 缺点：评估的结果很大程度上来自评估人员的主观推断，因此不同的评估人员可能会产生不同甚至截然相反的结果，而且评估人员对领域的熟悉程度、是否具有丰富的相关经验也成为评估结果是否正确的重要因素。

2.基于场景的评估方式
通过分析软件架构对场景(也就是对系统的使用或修改活动)的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。
在体系结构评估中，采用刺激、环境和响应三方面对场景进行描述。

• 刺激：是场景中解释或描述项目干系人怎样引发与系统的交互。
• 环境：描述刺激发生时的情况。
• 响应：指系统是如何通过体系结构对刺激作出反应的。

3.基于度量的评估方式
度量是指为软件产品的某一属性所赋予的数值，如代码行数、方法调用层数、构件个数等。基于度量的评估技术涉及3个基本活动：

• 建立质量属性和度量之间的映射原则，即确定怎样从度量结果推出系统具有什么样的质量属性
• 从软件体系结构文档中获取度量信息
• 根据映射原则分析推导出系统的某些质量属性。

3类评估方法比较

系统架构评估中的重要概念
1.敏感点(Sensitivity Point)和权衡点 (Tradeoff Point)。

• 敏感点是一个或多个构件(和或构件之间的关系)的特性。研究敏感点可使设计师明确在搞清楚如何实现质量目标时应注意什么。
• 权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。

例如，改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响系统性能。如果某个机密消息的处理有严格的时间延迟要求，则加密级别可能就会成为一个权衡点。

例：
改变加密级别可能会对安全性和性能产生非常重要的影响，因此，在软件架构评估中，该设计决策是一个( )。
A.敏感点
B.风险点
C.权衡点
D.非风险点

答案： C

2、风险承担者 (Stakeholders)
或者称为利益相关人。系统的架构涉及很多人的利益，这些人都对架构施加各种影响，以保证自己的目标能够实现。

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

系统架构评估方法
1.SAAM方法
SAAM方法是最早形成文档并得到广泛使用的软件体系结构分析方法，最初是用来分析体系结构的可修改性的，但实践证明，SAAM方法也可用于其他质量属性如可移植性、可扩充性等，最终发展成了评估一个系统架构的通用方法。SAAM 分析评估架构的过程包括5 个步骤，即场景开发、架构描述、单个场景评估、场景交互和总体评估。

通过各类风险承担者协商讨论，开发一些任务场景，体现系统所支持的各种活动。用一种易于理解的、合乎语法规则的架构描述软件架构，体现系统的计算构件、数据构件以及构件之间的关系(数据和控制)。对场景(直接场景和间接场景)生成一个关于特定架构的场景描述列表。通过对场景交互的分析，得出系统中所有场景对系统中的构件所产生影响的列表。最后，对场景和场景间的交互作一个总体的权衡和评价。

ATAM方法
架构权衡分析方法(ATAM)是评价软件构架的一种综合全面的方法。
主要针对性能、可用性、安全性和可修改性，在系统开发之前，可以使用ATAM方法在多个质量属性之间进行评价和折中。

ATAM 分为4个主要的活动领域(阶段)

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

ATAM方法采用效用树 (Utility tree) 这一工具来对质量属性进行分类和优先级排序。效用树的结构包括:树根→质量属性→属性分类→质量属性场景 (叶子节点)。

例：
效用树是采用架构权衡分析方法(Architecture TradeoffAnalysis Method，ATAM)进行架构评估的工具之一，其树形结构从根部到叶子节点依次为( )。
A.树根、属性分类、优先级，质量属性场景
B.树根、质量属性、属性分类，质量属性场景
C.树根、优先级、质量属性、质量属性场景
D.树根、质量属性、属性分类，优先级

答案： B
解析：效用树的结构包括:树根→质量属性→属性分类→质量属性场景 (叶子节点)。

CBAM方法
成本效益分析法 (CBAM)是在ATAM上构建，用来对架构设计决策的成本和收益进行建模，是优化此类决策的一种手段。CBAM 的思想就是架构策略影响系统的质量属性，反过来这些质量属性又会为系统的项目干系人带来一些收益(称为效用)，CBAM 协助项目干系人根据其投资回报(ROI)选择架构策略。CBAM在ATAM结束时开始，它实际上使用了 ATAM评估的结果。

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

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

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团队的主要发现通常包括：

• 一种效用树;
• 一组生成的场景;
• 一组分析问题;
• 一套确定的风险和非风险;
• 确定的架构方法。