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

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.规则系统体系结构风格
基于规则的系统包括规则集、规则解释器、规则/数据选择器工作内存。

答案： B、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.领域工程

答案： A
解析：领域分析。主要目的是获得领域模型。

2.参与DSSA的人员

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

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

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

DSSA包含两个过程：

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

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

质量特性	质量子特性
功能性(functionality)	适宜性(suitability)
	准确性(accurateness)
	互用性(interoperability)
	依从性(compliance)
	安全性(security)
可靠性(reliability)	成熟性(maturity)
	容错性(fault tolerance)
	可恢复性(recoverability)
可用性(usability)	可理解性(understandability)
	易学性(learnability)
	可操作性(operability)
效率(efficiency)	时间特性(time behavior)
效率(efficiency)	资源特性(resource behavior)
可维护性(maintainability)	可分析性(analyzability)
	可修改性(changeability)
	稳定性(stability)
	可测试性(testability)
可移植性(portability)	适应性(adaptability)
	易安装性(installability)
	一致性(conformance)
	可替换性(replaceability)

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

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

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

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

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

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

A.可靠性 B.可测试性 C.可维护性 D.可重用性
A.可用性 B.可扩展性 C.可伸缩性 D.可移植性

答案： 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 类质量属性。

可用性质量属性场景

场景要素	可能的情况
刺激源	系统内部、系统外部
刺激	疏忽、错误、崩溃、时间
环境	正常操作、降级模式
制品	系统处理器、通信信道、持久存储器、进程
响应	系统应该检测事件、并进行如下一个或多个活动:将其记录下来通知适当的各方，包括用户和其他系统:根据已定义的规则禁止导致错误或故障的事件源在一段预先指定的时间间隔内不可用，其中，时间间隔取决于系统的关键程度在正常或降级模式下运行
响应度量	系统必须可用的时间间隔响应度量可用时间系统可以在降级模式下运行的时间间隔故障修复时间

可修改性质量属性场景

场景要素	可能的情况
刺激源	最终用户、开发人员、系统管理员
刺激	希望增加、删除、修改、改变功能、质量属性、容量等
环境	系统设计时、编译时、构建时、运行时
制品	系统用户界面、平台、环境或与目标系统交互的系统
响应	查找架构中需要修改的位置，进行修改且不会影响其他功能，对所做的修改进行测试，部署所做的修改
响应度量	根据所影响元素的数量度量的成本、努力、资金;该修改对其他功能或质量属性所造成影响的程度

性能质量属性场景

场景要素	可能的情况
刺激源	用户请求，其他系统触发等
刺激	定期事件到达、随机事件到达、偶然事件到达
环境	正常模式、超载(Overload)模式
制品	系统
响应	处理刺激、改变服务级别
响应度量	等待时间、期限、吞吐量、抖动、缺失率、数据丢失率

可测试性质量属性场景

场景要素	可能的情况
刺激源	开发人员、增量开发人员、系统验证人员、客户验收测试人员、系统用户
刺激	已完成的分析、架构、设计、类和子系统集成:所交付的系统
环境	设计时、开发时、编译时、部署时
制品	设计、代码段、完整的应用
响应	提供对状态值的访问，提供所计算的值，准备测试环境
响应度量	已执行的可执行语句的百分比如果存在缺陷出现故障的概率执行测试的时间测试中最长依赖的长度准备测试环境的时间

易用性质量属性场景

场景要素	可能的情况
刺激源	最终用户
刺激	想要学习系统特性、有效使用系统、使错误的影响最低、适配系统、对系统满意
环境	系统运行时或配置时
制品	系统
响应	(1)系统提供以下一个或多个响应来支持“学习系统特性”:帮助系统与环境联系紧密;界面为用户所熟悉;在不熟悉的环境中，界面是可以使用的 (2)系统提供以下一个或多个响应来支持“有效使用系统”:数据和(或)命令的聚合:已输入的数据和(或)命令的重用;支持在界面中的有效导航;具有一致操作的不同视图;全面搜索;多个同时进行的活动 (3)系统提供以下一个或多个响应来“使错误的影响最低”:撤销:取消;从系统故障中恢复;识别并纠正用户错误;检索忘记的密码;验证系统资源 (4)系统提供以下一个或多个响应来“适配系统”:定制能力;国际化 (5)系统提供以下一个或多个响应来使客户“对系统的满意”:显示系统状态;与客户的节奏合拍
响应度量	任务时间、错误数量、解决问题的数量、用户满意度、用户知识的获得、成功操作在总操作中所占的比例、损失的时间/丢失的数据量

安全性质量属性场景

场景要素	可能的情况
刺激源	正确识别、非正确识别身份未知的来自内部/外部的个人或系统;经过了授权/未授权它访问了有限的资源/大量资源
刺激	试图显示数据，改变/删除数据，访问系统服务，降低系统服务的可用性
环境	在线或离线、联网或断网、连接有防火墙或者直接连到了网络
制品	系统服务、系统中的数据
响应	对用户身份进行认证;隐藏用户的身份;阻止对数据或服务的访问;允许访问数据或服务:授予或收回对访问数据或服务的许可:根据身份记录访问、修改或试图访问、修改数据服务;以一种不可读的格式存储数据;识别无法解释的对服务的高需求;通知用户或另外一个系统，并限制服务的可用性
响应度量	用成功的概率表示，避开安全防范措施所需要的时间、努力、资源;检测到攻击的可能性:确定攻击或访问、修改数据或服务的个人的可能性:在拒绝服务攻击的情况下仍然获得服务的百分比:恢复数据、服务;被破坏的数据、服务和(或)被拒绝的合法访问的范围

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

A.响应和响应度量 B.系统和系统响应 C.依赖和响应 D.响应和优先级
A可用性 B.性能 C.易用性 D.安全性

答案： 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方法在多个质量属性之间进行评价和折中。

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

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

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

ATAM 主要关注4 类质量属性：性能、安全性、可修改性和可用性，因为这4 个质量属性是利益相关者最为关心的。
得到初始的效用树后，需要修剪这棵树，保留重要场景(不超过50个)，再对场景按重要性给定优先级(用H/M/L 的形式)，再按场景实现的难易度来确定优先级(用H/M/L的形式)，这样对所选定的每个场景就有一个优先级对(重要度、难易度)，如 (H、L)表示该场景重要且易实现。

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

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

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

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