新年快乐：软件架构设计的软件架构概述、软件架构建模、软件架构风格

一、软件架构概述

在软件需求和设计之间存在一条很难逾越的鸿沟，从而很难有效地将需求转换为相应的设计。为此，学者们提出了软件架构(Software Architecture)的概念，并试图在软件需求与设计之间架起一座桥梁，重点解决系统结构和需求向实现平坦过渡的问题。

软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用连接件)、指导构件集成的模式以及这些模式的约束组成。软件架构指定了系统的组织结构和拓扑结构，并且显示了系统需求和构件之间的对应关系，提供了一些设计决策的基本原理。

软件架构的意义

(1)架构是项目干系人进行交流的手段。
(2)架构是早期设计决策的体现。
(3)架构明确了对系统实现的约束条件。
(4)架构决定了开发和维护组织的组织结构。
(5)架构制约着系统的质量属性。
(6)架构使推理和控制更改更简单。
(7)架构有助于循序渐进的原型设计。
(8)架构可以作为培训的基础。
(9)架构是可传递和可复用的模型。

软件架构技术发展过程4阶段：

(1)无架构设计阶段。以汇编语言进行小规模应用程序开发为特征。
(2)萌芽阶段。出现了程序结构设计主题，以控制流图和数据流图构成软件结构为特征。
(3)初级阶段。出现了从不同侧面描述系统的结构模型，以UML为典型代表。
(4)高级阶段。以描述系统的高层抽象结构为中心，不关心具体的建模细节，划分了架构模型与传统软件结构的界限。该阶段以Kruchten提出的"4+1"模型为标志。

二、软件架构建模

2.1 软件架构的模型

软件架构的模型可分为五种：

(1)结构模型。这是一种最直观和最普遍的建模方法，它以构件、连接件和其他概念来刻画架构，并力图通过架构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格和性质等。研究结构模型的核心是架构描述语言。
(2)框架模型。与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体结构。框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的架构。
(3)动态模型。是对结构模型或框架模型的补充，研究系统的粗粒度行为性质。例如，描述系统的重新配置或演化等，这类系统通常是激励型的。
(4)过程模型。研究构建系统的步骤和过程。
(5)功能模型。认为架构是由一组功能构件按层次组成的，下层向上层提供服务。可以看作是一种特殊的框架模型。

2.2 4+1视图模型

(1)逻辑视图。主要支持系统的功能需求，即系统提供给最终用户的服务。在OO技术中，用类图来描述逻辑视图。使用的风格为面向对象的风格。
(2)开发视图。也称为模块视图，在UML中被称为实现视图，它主要侧重于软件模块的组织和管理。开发视图要考虑软件内部的需求。通过系统 I/O 关系的模型图和子系统图来描述。
(3)进程视图。侧重于系统的运行特性，主要关注一些非功能性需求。强调并发性、分布性、系统集成性和容错能力，定义了逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。
(4)物理视图。在UML中被称为部署视图，主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装和通信等问题。
(5)场景。可以看作是那些重要系统活动的抽象，它使4个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。对应UML中的用例视图。它可以帮助架构设计师找到构件及其相互关系。

三、软件架构风格

软件体系结构风格(软件系统架构)是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族，即一个架构定义、一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。

架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。

架构设计的一个核心问题是能否达到架构级的软件复用。

架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。

3.1 数据流风格

数据流风格：面向数据流，按照一定的顺序从前向后执行程序，代表的风格有批处理序列、管道-过滤器。

批处理序列：构件为一系列固定顺序的计算单元，构件之间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在其前一步结束后才能开始，数据必须是完整的，以整体的方式传递。

管道-过滤器：每个构件都有一组输入和输出，构件读取输入的数据流，经过内部处理，产生输出数据流。前一个构件的输出作为后一个构件的输入，前后数据流关联。过滤器就是构件，连接件就是管道。

早期编译器就是采用的这种架构，要一步一步处理的，均可考虑此架构风格。

二者区别在于：批处理前后构件不一定有关联，并且是作为整体传递，即必须前一个执行完才能执行下一个。管道-过滤器是前一个输出作为后一个输入，前面执行到部分句可以开始下一个的执行。

3.2 调用/返回风格

调用/返回风格：构件之间存在互相调用的关系，一般是显式调用，代表的风格有 主程序/子程序、面向对象、层次结构。

主程序/子程序：单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序，子程序通常可合成为模块。过程调用作为交互机制，充当连接件的角色。

面向对象：构件是对象，对象是抽象数据类型的实例。连接件就是对象间交互的方式，对象是通过函数和过程的调用来交互的。

层次结构：构件组成一个层次结构，连接件通过决定层间如何交互的协议来定义。每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。修改某一层，最多影响其相邻的两层(通常只能影响上层)。

层次结构优点:

(1)支持基于可增加抽象层的设计，允许将一个复杂问题分解成一个增量步骤序列的实现。
(2)不同的层次处于不同的抽象级别，越靠近底层，抽象级别越高。
(3)由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件复用提供了强大的支持。

层次结构缺点：

(1)并不是每个系统都可以很容易的划分为分层的模式。
(2)很难找到一个合适的、正确的层次抽象方法。

3.3 独立构件风格

独立构件风格：构件之间是互相独立的，不存在显式的调用关系，而是通过某个事件触发->异步的方式来执行，代表的风格有进程通信、事件驱动系统(隐式调用)。

进程通信：构件是独立的进程，连接件是消息传递。构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式，以及远程过程(方法)调用等。

事件驱动系统(隐式调用)：构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发时系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用来实现的。

优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便。
缺点是构件放弃了对系统计算的控制。

3.4 虚拟机风格

虚拟机风格：自定义了一套规则供使用者使用，使用者基于这个规则来开发构件，能够跨平台适配，代表的风格有解释器、基于规则的系统。

解释器：通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码的存储区被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，缺点是执行效率低。

基于规则的系统：包括规则集、规则解释器、规则/数据选择器和工作内存。一般用在人工智能领域和DSS(Decision Support System，决策支持系统)中。

3.5 以数据为中心的体系结构风格

仓库架构风格：仓库是存储和维护数据的中心场所。在仓库体系结构格中，有两种不同的构件：中央数据结构(说明当前数据的状态)，以及一组对中央数据进行操作的独立构件，仓库与独立构件间的相互作用在系统中会有大的变化。

黑板系统：包括知识源、黑板和控制三部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板；黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯媒介，知识源响应是通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中(信号处理、问题规划和编译器优化等)。

现代编译器的集成开发环境一般采用数据仓库(即以数据为中心的架构风格)架构风格进行开发，中心数据就是程序的语法树。

3.6 层次架构风格

3.6.1 两层C/S架构

两层C/S 体系结构有3个主要组成部分：数据库服务器、客户应用程序和网络。服务器(Server，后台)负责数据管理，客户机(Client，前台)完成与用户的交互任务，称为"胖客户机，瘦服务器"。

客户端和服务器都有处理功能，现在已经不常用，原因有：开发成本较高、客户端程序设计复杂、信息内容和形式单一、用户界面风格不软件移植困难、软件维护和升级困难、新技术不能轻易应用、安全性问题、服务器端压力大难以复用。

3.6.2 三层C/S架构

将处理功能独立出来，表示层和数据层都变得简单。表示层在客户机上，功能层在应用服务器上，数据层在数据库服务器上。既然将两层C/S架构中的数据从服务器中独立出来了。其优点下面四点：

(1)各层在逻辑上保持相对独立，整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可扩展性；
(2)允许灵活有效的选用相应的平台和硬件系统，具有良好的可升级性和开放性；
(3)各层可以并行开发，各层也可以选择各自最适合的开发语言；
(4)功能层有效的隔离表示层与数据层，为严格的安全管理奠定了坚实的基础，整个系统的管理层次也更加合理和可控制。

三层C/S架构设计的关键在于各层之间的通信效率，要慎重考虑三层间的通信方法、通信频度和数据量，否则即使分配给各层的硬件能力很强，性能也不高。

3.6.3 三层B/S架构

B/S架构的全称为Browser/Server，即浏览器/服务器结构。三层B/S架构是三层C/S架构的变种，将客户端变为用户客户端上的浏览器，将应用服务器变为网络上的WEB服务器，又称为0客户端架构，虽然不用开发客户端，但有很多缺点：

(1)B/S架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能；
(2)安全性难以控制；
(3)在数据查询等响应速度上，要远远低于C/S架构；
(4)数据提交一般以页面为单位，数据的动态交互性不强，不利于OLTP应用。

OLTP（Online Transaction Processing，联机事务处理）是一种基于计算机处理事务的方式，主要用于处理企业级应用程序中的实时业务数据。

3.6.4 混合架构风格

内外有别模型：企业内部使用C/S，外部人员访问使用B/S。

查改有别模型：采用B/S查询，采用C/S修改。

混合架构实现困难，且成本高。

3.7 面向服务的架构风格

3.7.1 SOA 概述

SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型。

在SOA中，服务是一种为了满足某项业务需求的操作、规则等的逻辑组合。它包含一系列有序活动的交互，为实现用户目标提供支持。

SOA并不仅仅是一种开发方法，还具有管理上的优点，管理员可直接管理开发人员所构建的相同服务，多个服务通过企业服务总线(ESB)提出服务请求，由应用管理来进行处理，如下：

SOA设计原则：

(1)明确定义的接口。服务请求者依赖于服务规约来调用服务，因此，服务定义必须长时间稳定，一旦公布，不能随意更改。
(2)自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和构件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。
(3)粗粒度。服务数量不应该太多，依靠消息交互而不是远程过程调用，通常消息量比较大，但是服务之间的交互频度较低。
(4)松耦合。服务请求者可见的是服务的接口，其位置、实现技术、当前状态和私有数据等，对服务请求者而言是不可见的。
(5)互操作性、兼容和策略声明。为了确保服务规约的全面和明确，策略成为一个越来越重要的方面。

基于服务的构件与传统构件的区别有四点：

服务构件粗粒度，传统构件细粒度居多；
服务构件的接口是标准的，主要是WSDL接口，而传统构件常以具体API形式出现；
服务构件的实现与语言是无关的，而传统构件常绑定某种特定的语言；
服务构件可以通过构件容器提供QoS的服务，而传统构件完全由程序代码直接控制。

从基于对象到基于构件再到基于服务，架构越来越松散耦合，粒度越来越粗，接口越来越标准。

注：QoS（Quality of Service，服务质量）是网络或通信系统中的一组技术和机制，用于确保在不同网络应用和服务之间分配和提供适当的服务质量水平。

3.7.2 SOA 的关键技术

与SOA紧密相关的技术主要有统一描述、发现和集成(UDDI)、Web服务描述语言(WSDL)、简单对象访问协议(SOAP)和表述性状态转移(REST)等，而这些技术都是以XML为基础发展起来的。

3.7.2.1 UDDI

UDDI 用于Web服务注册和服务查找，描述了服务的概念，定义了编程的接口，供其他企业来调用。在UDDI技术规范中，主要包含以下三部分内容：

(1)数据模型。是一个用于描述业务组织和服务的XMLSchema。
(2)API。是一组用于查找或发布UDDI数据的方法，UDDIAPI基于SOAP。
(3)注册服务。是SOA中的一种基础设施，对应着服务注册中心的角色。

3.7.2.2 WSDL

WSDL 对服务进行描述的语言，它有一套基于XML的语法定义。描述的重点是服务，包含服务实现定义和服务接口定义。

3.7.2.3 SOAP

SOAP 定义了服务请求者和服务提供者之间的消息传输规范。SOAP用XML来格式化消息，用HTTP来承载消息。通过SOAP，应用程序可以在网络中进行数据交换和远程过程调用(RPC)。SOAP主要包括以下4个部分：

(1)封装。定义了一个整体框架，用来表示消息中包含什么内容，谁来处理这些内容，以及这些内容是可选的还是必须的。
(2)编码规则。定义了一种序列化的机制，用于交换系统所定义的数据类型的实例。
(3)RPC表示。定义了一个用来表示远程过程调用和应答的协议。
(4)绑定。定义了一个使用底层传输协议来完成在节点之间交换S0AP封装的约定。

S0AP消息包括以下三个部分:

(1)封装(信封)。封装的元素名是Envelope,在表示消息的XML文档中，封装是顶层元素，在SOAP消息中必须出现。
(2)SOAP头。SOAP头的元素名是Header,提供了向SOAP消息中添加关于这条SOAP消息的某些要素的机制。
(3)SOAP体。SOAP体的元素名是Body,是包含消息的最终接收者想要的信息的容器。

3.7.2.4 REST

REST 是一种只使用HTTP和XML进行基于Web通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。REST从根本上来说只支持几个操作(POST、GET、PUT和DELETE)。REST提出了如下一些设计概念和准则：

(1)网络上的所有事物都被抽象为资源。

(2)每个资源对应一个唯一的资源标识。

(3)通过通用的连接件接口对资源进行操作。

(4)对资源的各种操作不会改变资源标识。

(5)所有的操作都是无状态的。

3.7.3 SOA的实现方法

3.7.3.1 WEB Service

WEBService有三种工作角色，如下：

(1)服务提供者。是服务的所有者，负责定义并实现服务，使用WSDL对服务进行详细、准确、规范的描述，并将该描述发布到服务注册中心，供服务请求者查找并绑定使用。
(2)服务请求者。是服务的使用者，虽然服务面向的是程序，但程序的最终使用者仍然是用户。
(3)服务注册中心(可选)。是连接服务提供者和服务请求者的纽带，服务提供者在此发布他们的服务描述，而服务请求者在服务注册中心查找他们需要的服务。

Web Service模型中的操作包括发布、查找和绑定等，可以单次或反复出现。

Web Service模型中应用系统大致可以分为如下6个层次：

(1)底层传输层。主要负责消息的传输机制，HTTP、Java消息服务(JMS)和SMTP都可以作为服务的消息传输协议。
(2)服务通信协议层。主要功能是描述并定义服务之间进行消息传递所需的技术标准，常用的标准是SOAP和REST协议。
(3)服务描述层。主要以一种统一的方式描述服务的接口与消息交换方式，相关的标准是WSDL。
(4)服务层。主要功能是将遗留系统进行包装，并通过发布的WSDL接口描述来定位和调用处于服务层的服务。
(5)业务流程层。主要功能是支持服务发现，服务调用和点到点的服务调用，并将业务流程从服务的底层调用抽象出来。相关的标准是WSBPEL。
(6)服务注册层。主要功能是使服务提供者能够通过WSDL发布服务定义，并支持服务请求者查找所需的服务信息。相关的标准是UDDL。

3.7.3.2 服务注册表

服务注册表可以包括有关服务和相关构件的配置、依从性和约束文件。从理论上来说，任何帮助服务注册、发现和查找服务合约、元数据和策略的信息库、数据库、目录或其他节点都可以被认为是一个注册表。大多数商用服务注册产品支持如下功能：

(1)服务注册：应用开发者(服务提供者)在注册表中公布服务的功能。
(2)服务位置：服务使用者(服务应用开发者)，帮助他们查询注册服务，寻找符合自身要求的服务。
(3)服务绑定：服务使用者利用检索到的服务接口来编写代码，所编写的代码将与注册的服务绑定，调用注册的服务，以及与它们实现互动。

3.7.3.3 企业服务总线ESB

企业服务总线 ESB 提供了一种基础设施，消除了服务请求者与服务提供者之间的直接连接，使得服务请求者与服务提供者之间进一步解耦。ESB具有下列六点功能:

(1)支持异构环境中的服务、消息和基于事件的交互，并且具有适当的服务级别和可管理性。
(2)通过使用ESB，可以在几乎不更改代码的情况下，以一种无缝的非侵入方式使现有系统具有全新的服务接口，并能够在部署环境中支持任何标准。
(3)充当缓冲器的ESB(负责在诸多服务之间转换业务逻辑和数据格式)与服务逻辑相分离，从而使不同的系统可以同时使用同一个服务，用不着在系统或数据发生变化时，改动服务代码。
(4)在更高的层次，ESB还提供诸如服务代理和协议转换等功能。允许在多种形式下通过像HTTP、SOAP和JMS总线的多种传输方式，主要是以网络服务的形式，为发表、注册、发现和使用企业服务或界面提供基础设施。
(5)提供可配置的消息转换翻译机制和基于消息内容的消息路由服务，传输消息到不同的目的地。
(6)提供安全和拥有者机制，以保证消息和服务使用的认证、授权和完整性。

在企业应用集成方面，与现存的、专有的集成解决方案相比，ESB具有以下优势：

(1)扩展的、基于标准的连接。
(2)灵活的、服务导向的应用组合。
(3)提高复用率，降低成本。
(4)减少市场反应时间，提高生产率。

四、软件架构标准

IEEE1471-2000定义了以下软件架构标准要素之间的关系，具体分为5个层次：

(1)任务。是指一种使用或操作，是一个系统想要满足一名或多名利益相关者的目标，为达成这个目标，完成相对应的软件架构设计。
(2)环境、系统以及架构。一个完整的系统是由一系列组件组成的，将这些组件组织在一起，相互作用从而完成一个或者一些特殊的功能。系统不可能单独存在，它总是存在于一个环境之中。在软件架构标准中，将系统范围之外的、对系统有影响、有交互的客观存在定义为环境，有时也称为上下文。并且每一个系统都应该实现一种或多种的软件架构。
(3)利益相关者、架构说明以及原理。一个系统拥有多个利益相关者，并且系统架构也需要架构说明来进行描述，从而满足不同利益相关者的利益，从架构描述中可以识别出不同利益相关者的相关利益。同时在设计软件架构时，软件架构工程师需要做出许多取舍以及选择，需要给出选择或者不选择的理由，以及架构设计是如何满足功能性需求和非功能性需求的。
(4)关注、关注点、视图。一个系统的利益相关者对系统和与其有关的问题进行关注。一个关注点可能由一个或多个利益相关者持有。在整个生命周期中，对系统的需求和要求以及实施和运行的考虑等都可能成为关注点。不同的利益相关者其关注点不尽相同，有时甚至是矛盾的。站在不同的关注点，就会对系统架构形成不同的视图，视图和关注点是一一对应的关系。
(5)关注点库、模型。关注点库中存放了前人针对各种系统、各种不同的利益相关者、各种不同的关注点总结出来的观察点，方便后人参考使用。模型是用来表示视图的方法，即使用图形化的表示，将不同视图下的系统元素组织起来，并将这些元素整体发挥的作用表现出来。

五、软件架构实现

基于架构的软件开发模型（ABSDM）把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现和演化等6个子过程，如下图所示。

（1）架构需求：重在掌握标识构件的三步，如下左图。

需求获取：体系结构需求一般来自三个方面，分别是系统的质量目标、系统的商业目标和系统开发人员的商业目标。
标识构件：为系统生成初始逻辑结构，标识大致的构件。包括图中三个步骤。

（2）架构设计：将需求阶段的标识构件映射成构件，进行分析，如下右图。

（3）架构(体系结构)文档化：主要产出两种文档，即架构(体系结构)规格说明，测试架构(体系结构)需求的质量设计说明书。文档是至关重要的，是所有人员通信的手段，关系开发的成败。

（4）架构复审：由外部人员(独立于开发组织之外的人，如用户代表和领域专家等)参加的复审，复审架构是否满足需求，质量问题，构件划分合理性等。若复审不过，则返回架构设计阶段进行重新设计、文档化，再复审。

（5）架构实现：用实体来显示出架构。实现构件，构件组装成系统，如下左图：

（6）架构演化：对架构进行改变，按需求增删构件，使架构可复用，如下右图:

六、软件系统的质量属性

6.1 质量属性概念

可以将软件系统的质量属性分为开发期质量属性和运行期质量属性2个部分。

1.开发期质量属性主要指在软件开发阶段所关注的质量属性，主要包含6个方面。

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

2.运行期质量属性主要指在软件运行阶段所关注的质量属性，主要包含7个方面。

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

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

为了评价一个软件系统，特别是软件系统的架构，需要进行架构评估。在架构评估过程中，评估人员所关注的是系统的质量属性。

(1)性能：指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量。
- 设计策略：优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。
(2)可靠性 ：是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。如MTTF、MTBF、MTTR。
- 设计策略：心跳、Ping/Echo、冗余、选举。
(3)可用性 ：是系统能够正常运行的时间比例，经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。如故障间隔时间。
- 设计策略：心跳、Ping/Echo、冗余、选举。
(4)安全性 ：是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性。
- 设计策略：入侵检测、用户认证、用户授权、追踪审计。
(5)可修改性 ：指能够快速的以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量。包含以下4个方面：
- a.可维护性，局部修复使故障对架构的负面影响最小化；
- b.可扩展性，因松散耦合更易实现新特性/功能，不影响架构；
- c.结构重组，不影响主体进行的灵活配置；
- d.可移植性，适用于多样的环境（硬件平台、语言、操作系统等）。
- 设计策略：接口-实现分类、抽象、信息隐藏。
(6)功能性 ：是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
(7)可变性 ：指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时，可变性是很重要的。
(8)互操作性 ：作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，也影响应用的软件体系结构。

6.3 质量属性场景描述

质量属性场景是一种面向特定质量属性的需求。它由6部分组成：

(1)刺激源 (Source)：这是某个生成该刺激的实体(人、计算机系统或者任何其他刺激器)。

(2)刺激 (Stimulus)：该刺激是当刺激到达系统时需要考虑的条件。

(3)环境 (Environment)：该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况。

(4)制品 (Artifact)：某个制品被激励。这可能是整个系统，也可能是系统的一部分。

(5)响应 (Response)：该响应是在激励到达后所采取的行动。

(6)响应度量 (Measurement)：当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。

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

6.3.1 可用性质量属性场景描述

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

6.3.2 可修改性质量属性场景描述

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

6.3.3 性能质量属性场景描述

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

还有可测试性、易用性和安全性质量属性场景描述没有提供，可以自己参考着写一下。