NO.7系统架构设计和软件质量

一、系统架构设计概念及生命周期

1、概念

软件架构设计是指通过一系列的设计活动，获得满足系统功能性需求，符合一定非功能性需求与质量属性有相似含义的软件系统框架模型。在软件体系结构设计过程中，主要考虑系统的非功能性需求。软件体系结构设计经验的总结与重用是软件工程的重要目标之一，所采用的手段主要包括体系结构风格、（特定领域的架构）DSSA等技术。

2、软件架构设计与生命周期

（1）需求阶段

软件架构研究还处于起步阶段。在本质上，需求和软件架构设计面临的是不同的对象：一个是问题空间；另一个是解空间。

保持二者的可追踪性和转换，一直是软件工程领域追求的目标。从软件需求模型向软件架构模型的转换主要关注两个问题：

① 如何根据需求模型构建软件架构模型。

② 如何保证模型转换的可追踪性。

（2）设计阶段

是软件架构研究关注的最早和最多的阶段，这一阶段的研究主要包括： 软件架构模型的描述 、软件架构模型的设计与分析方法 ，以及对软件架构设计经验的总结与复用等。有关软件架构模型描述的研究分为三个层次：

✔ SA的基本概念，即SA模型由哪些元素组成，这些组成元素之间按照何种原则组织。传统的设计概念只包括构件（软件系统中相对独立的有机组成部分，最初称为模块）以及一些基本的模块互联机制。随着研究的深入，构件间的互联机制逐渐独立出来，成为与构件同等级别的实体，称为连接子。

✔ 体系结构描述语言（Architecture Description Language，ADL），支持构件、连接子及其配置的描述语言就是如今所说的体系结构描述语言。

✔ 软件架构模型的多视图表示，从不同的视角描述特定系统的体系结构，从而得到多个视图，并将这些视图组织起来以描述整体的软件架构模型。系统的每一个不同侧面的视图反映了一组系统相关人员所关注的系统的特定方面，多视图体现了关注点分离的思想。典型的包括4+1视图。

（3）实现阶段

实现阶段的体系结构研究在以下几个方面：

① 研究基于软件架构的开发过程支持，如项目组织结构、配置管理等。

② 寻求从软件架构向实现过渡的途径，如将程序设计语言元素引入软件架构阶段、模型映射、构件组装、复用中间件平台等。

③ 研究基于软件架构的测试技术。

（4）构件组装阶段

构件组装阶段研究内容包括：

1.如何支持可复用构件的互联，即对SA设计模型中规约的连接子的实现提供支持。

2.组装过程中，如何检测并消除体系结构失配问题。这些问题主要包括：

① 由构件引起的失配，包括由于系统对构件基础设施、构件控制模型和构件数据模型的假设存在冲突引起的失配。

② 由连接子引起的失配，包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的失配。

③ 由于系统成分对全局体系结构的假设存在冲突引起的失配等。要解决失配问题，首先需要检测出失配问题，并在此基础上通过适当的手段消除检测出的失配问题。

（5）部署阶段

部署阶段的软件架构对软件部署作用如下：

① 提供高层的体系结构视图描述部署阶段的软硬件模型。

② 基于软件架构模型可以分析部署方案的质量属性，从而选择合理的部署方案。

（6）后开发阶段

后开发阶段是指软件部署安装之后的阶段。这一阶段的软件架构研究主要围绕维护、演化、复用等方面来进行。典型的研究方向包括动态软件体系结构、体系结构恢复与重建等。

3、基于架构的软件开发方法

✔ 基于体系结构（架构）的软件设计（Architecture-Based Software Design，ABSD)方法。ABSD方法是体系结构驱动，即指构成体系结构的商业、质量和功能需求的组合驱动的。在基于体系结构的软件设计方法中，采用视角与视图来描述软件架构，采用用例来描述功能需求，采用质量场景来描述质量需求。

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

ABSD方法有三个基础：

第一个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术。
第二个基础是通过选择体系结构风格来实现质量和商业需求。
第三个基础是软件模板的使用。软件模板利用了一些软件系统的结构。

ABSDM模型把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现和演化等6个子过程，得到细化，直到能产生软件构件和类。

（1）体系结构需求

体系结构需求受技术环境和体系结构设计师的经验影响，需求过程主要是获取用户需求，标识系统中所要用到的构件。如果以前有类似的系统体系结构的需求，我们可以从需求库中取出，加以利用和修改，以节省需求获取的时间，减少重复劳动，提高开发效率。

（2）体系结构设计

①提出架构模型

②映射构件

③分析构件相互作用

④产生架构

⑤设计评审

（3）体系结构文档化

主要产出两种文档：

①架构（体系结构）规格说明

②测试架构（体系结构）需求的质量设计说明书。文档是至关重要的，是所有人员通信的手段，关系开发的成败。

文档的注意事项：

①文档必须从使用者的角度编写

②必须分发给所有与系统有关的开发人员

③且保持开发者手上的文档是最新的

（4）体系结构复审

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

（5）体系结构实现

用实体来显示出架构。实现构件，构件组装成系统复审后的文档化架构：

①分析与设计

②构件实现

③构件组装

④系统测试

需要构件库的支持

（6）体系结构演化

对架构进行改变，按需求增删构件，使架构可复用：

①需求变化分类

②架构演化计划

③构件变动

④更新构件的相互作用

⑤构件组装与测试

⑥技术评审

⑦演化后的架构

例题：

二、软件架构风格

1、软件架构风格的概念

软件体系结构（架构）风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。

词汇表中包含一些构件和连接件类型。
约束指出系统是如何将这些构件和连接件组合起来的。

软件架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。

2、通用架构风格的分类

（1）数据流风格

1.批处理体系结构风格

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

2.管道-过滤器体系结构风格

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

①UNIX Shell编写的程序

②传统的编译器

3.数据流风格的架构的优缺点：

优点	缺点	典型实例
1、高内聚、低耦合 2、良好的重用性/可维护性 3、可扩展性(标准接口适配) 4、良好的隐蔽性 5、支持并行	1.交互性差 2、复杂性较高 3、性能差（每个过滤器都需要解析与合成数据）	传统编译器网络报文处理

（2）调用 / 返回风格

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

① 主程序/子程序风格

② 面向对象风格

③ 层次风格

④ 客户端/服务器风格

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

2.面向对象风格

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

3.层次型体系结构风格。

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

4.客户端/服务器体系结构风格。

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

三层C/S结构增加了应用服务器。整个应用逻辑驻留在应用服务器上，只有表示层位于客户机上，故称为"瘦客户机"。应用功能分为表示层、功能层和数据层三层。

调用/返回优缺点风格的优缺点：

优点	缺点	典型实例
1. 良好的重用性，只要接口不变可用在其它处。 2. 可维护性好。 3. 可扩展性好，支持递增设计。	1. 并不是每个系统都方便分层。 2. 很难找到一个合适的、正确的层次抽象方法。 3. 不同层次之间耦合性高的系统很难实现。	1. 每个层次的组件形成不同功能级别的虚拟机； 2. 多层相互协同工作，而且实现透明性。

（3）独立构件风格

独立构件风格主要强调系统中每个构件为相对独立个体，彼此不直接通信，以降低耦合度、提升灵活性，主要包括进程通信和事件系统风格。

1.进程通信体系结构风格

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

2.事件系统体系结构风格

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

独立构件风格的优缺点：

优点	缺点
1. 松耦合。 2. 良好的复用性/可修改性/可扩展性。	1. 构件放弃了对系统计算的控制。 2. 数据交换问题； 3. 过程的语义必须依赖于被触发事件的上下文约束，正确性的推理存在问题

（4）虚拟机风格

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

1.解释器体系结构风格

一个解释器通常包含解释引擎（完成解释工作）、存储被解释代码的存储区、记录解释引擎当前工作状态的数据结构，以及记录源代码被解释执行进度的数据结构。解释器常用于建立虚拟机以弥合程序语义与硬件语义的差异，但执行效率较低，典型例子是专家系统。

2.规则系统体系结构风格

基于规则的系统涵盖规则集、规则解释器、规则/数据选择器及工作内存。

虚拟机架构风格的优缺点：

优点	缺点	要点
可以灵活应对自定义场景	复杂度较高	1、解释器：适用于需要"自定义规则"的场合。 2、规则为中心：在解释器的基础上增加经验规则。适合于专家系统。

（5）仓库风格

仓库体系结构风格：仓库(Repository)是存储和维护数据的中心场所，以数据为中心。

在仓库风格中，有两种不同的构件：

①中央数据结构(仓库)，说明当前数据的状态。

②独立构件，它对中央数据进行操作。

1.数据库系统：

构件主要有两大类，一类是中央共享数据源，保存当前系统的数据状态；另一类是多个独立处理单元，处理单元对数据元素进行操作。场景：ORACLE数据库开发的系统

2.黑板体系结构风格

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

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

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

（6）闭环风格

闭环控制:当软件被用于操作一个物理系统时，软件与硬件之间可粗略表示为一个反馈循环。该反馈循环通过接受一定输入，确定一系列输出，最终使环境达到新状态，适用于嵌入式系统，涉及连续动作与状态。

场景：空调控温恒温机制。

（7）C2风格

C2体系结构风格可概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。

C2风格中的系统组织规则如下：

(1) 系统中的构件和连接件都有一个顶部和一个底部；

(2) 构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；

(3) 一个连接件可以和任意数目的其它构件和连接件连接；

(4) 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。

（8）MDA风格

①平台独立模型（PIM） ：具有较高抽象层次，独立于任何实现技术的模型。

②平台相关模型（PSM） ：为某种特定实现技术量身定做，是可用实现构造来描述系统的模型。PIM会被变换成一个或多个PSM。

③代码：用源代码对习题进行描述，每个PSM都将被变换成代码。

例题：

三、系统架构复用及特点领域软件架构

1、软件架构复用的定义及分类

软件复用是一种系统化的软件开发过程，通过识别、开发、分类、获取和修改软件实体，以便在不同的软件开发过程中重复使用它们。早期的软件复用主要是代码级复用，被复用的专指程序，后来扩大到包括领域知识、开发经验、体系结构、需求、设计、测试、代码和文档、过程方法和工具等一切有关方面。

软件架构复用的类型包括机会复用和系统复用：

①机会复用 是指开发过程中，只要发现有可复用的资产，就对其进行复用。

②系统复用 是指在开发之前，就要进行规划，以决定哪些需要复用。

2、软件架构复用的原因

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

3、软件架构复用的基本过程

复用的基本过程包括3个阶段：

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

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

1.构件分类，是指将数量众多的构件按照某种特定方式组织起来。

2.构件检索，是指给定几个查询需求，能够快速准确地找到相关构件。

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

4、特定领域软件架构DSSA

（1）特定领域软件架构DSSA概念

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

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

（2）DSSA的基本活动

①领域分析 ：主要目的是获得领域模型。领域模型描述领域中系统之间的共同的需求，所描述的需求为领域需求。

②领域设计 ：主要目的是获得DSSA。DDSA描述在领域模型中表示需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统需求的一个高层次的设计。

③领域实现 ：主要目的是依据领域模型及DSSA开发和组织可重用信息。

（3）参与DSSA的人员

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

（4）DSSA的建立过程

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

①定义领域范围：主要输出是领域中的应用需要满足一系列用户的需求。

②定义领域特定的元素：编译领域字典和领域术语的同义词词典。

③定义领域特定的设计和实现需求约束。

④定义领域模型和架构。

⑤产生、搜集可重用的产品单元。

（5）DSSA的两个过程

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

四、软件系统的质量属性

1、质量属性概念

软件系统的质量就是"软件系统与明确地和隐含地定义的需求相一致的程度"。影响软件质量的主要因素划分为6个维度（口诀：功靠用效维移。必背熟！）特性：

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

2、开发期质量属性

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

①易理解性：指设计被开发人员理解的难易程度。

②可扩展性：软件因适应新需求或需求变化而增加新功能的能力，也称为灵活性。

③可重用性：指重用软件系统或某一部分的难易程度。

④可测试性：对软件测试以证明其满足需求规范的难易程度。

⑤可维护性：当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度。

⑥可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。

3、运行期质量属性

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

①性能：指软件系统及时提供相应服务的能力，如速度、吞吐量、容量等要求。

②安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。

③可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如通过增加服务器来提高能力。

④互操作性：指本软件系统与其他系统交换数据和相互调用服务的难易程度。

⑤可靠性：指软件系统在一定的时间内持续无故障运行的能力。

⑥可用性：指系统在一定时间内正常工作的时间所占的比例。可用性会受到系统错误、恶意攻击，高负载等问题影响。

⑦鲁棒性：指软件系统在非正常情况下（如用户进行了非法操作、相关的软硬件系统发生了故障等)，仍能够正常运行的能力，也称健壮性或容错性。

4、质量属性场景描述

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

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

② 刺激：该刺激是当刺激到达系统时需要考虑的条件。

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

④ 制品：某个制品被激励。可能是整个系统，也可能是系统的一部分。

⑤ 响应：该响应是在激励到达后所采取的行动。

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

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

（1）可用性的场景属性

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

（2）可修改性的场景属性

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

（3）性能质量场景属性

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

（4）可测试性质量场景属性

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

（5）易用性质量场景属性

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

（6）安全性质量场景属性

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

例题：

五、软件架构评估

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

性能
可靠性
可用性
安全性
可修改性
功能性
可变性
互操作性

1、可靠性

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

①容错。容错的目的是在错误发生时确保系统正确的行为，并进行内部"修复"。

②健壮性。这里说的是保护应用程序不受错误使用和错误输入的影响，在发生意外错误事件时确保应用系统处于预先定义好的状态。

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

✔ 平均失效等待时间(MTTF)也称平均无故障时间，是指某个元件预计的可运作平均时间。

✔ 平均故障修复时间(MTTR)：是描述产品由故障状态转为工作状态时修理时间的平均值。表示计算机的可维修性。

平均失效间隔时间(MTBF)常与MTTF发生混淆。因为两次故障之间必然有修复行为，因此，MTBF中应包含MTTR。

MTBF= MTTR+ MTTF 实际应用中MTTR很小，所以MTBF≈MTTF

2、可修改性

（1）可修改性概念

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

①可维护性

②可扩展性

③结构重组

④可移植性

（2）常见场景分析

①更改系统报表模块，必须在2人周内完成。

②对Web界面风格进行修改，修改必须在4人月内完成。

（3）可修改性战术

局部化修改：维持语义的一致性、预期期望的变更、泛化该模块、限制可能的选择
防止连锁反应：信息隐藏、维持现有的接口、限制通信路径、仲裁者的使用
推迟绑定时间：运行时注册、配置文件、多态、构件更换、遵守已定义的协议。

3、可变性

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

其中，产品线是指一个产品的集合，这些产品共享一个公共的、可管理的特征集，这个特征集能满足特定领域的特定需求，是一个十分适合专业开发组织的软件开发方法，能有效提高生产率和质量，缩短开发时间。核心资源 + 产品集合

	演化方式	革命方式
基于现有产品	基于现有产品架构设计产品线的架构，经演化现有构件，开发产品线构件	核心资源的开发基于现有产品集的需求和可预测的、将来需求的超集
全新产品线	产品线核心资源随产品新成员的需求而演化	开发满足所有预期产品线成员的需求的核心资源

将现有产品演化为产品线
用软件产品线替代现有产品集
全新软件产品线的演化
全新软件产品线的开发

4、性能

（1）性能概念

指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。

（2）常见场景分析

①同时支持1000并发。

②响应时间应小于1s。

③显示分辨率达到4k。

（3）性能战术

设计策略：

资源需求：提高计算效率、减少处理事件流所需的资源、减少所处理事件的数量、控制资源的使用
资源管理：引入并发、维持数据或计算的多个副本、增加可用资源
资源仲裁：资源调度策略、先进先出、固定优先级调度、动态优先级调度、静态调度

5、可用性

（1）可用性概念

是系统能够正常运行的时间比例，经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。如故障间隔时间。

（2）常见场景分析

①主服务器故障，1分钟内切换至备用服务器。

②系统故障，1小时内修复。

③系统支持7*24小时。

（3）可用性战术

错误检测：命令/响应、心跳线、异常处理
错误恢复：表决（通过冗余构件与表决器相联）、主动冗余、被动冗余、备件、状态再同步、检查点/回滚
错误预防：从服务中删除、事务（事务保证一致性）、进程监视器。

6、安全性

1、安全性概念

是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性。

2、常见场景分析

①可抵御SQL注入攻击。

②对计算机的操作都有完整的记录。

③用户信息数据库授权必须保证99.9%可用。

3、安全性战术

设计策略：入侵检测、用户认证、用户授权、追踪审计
抵抗攻击：对用户身份进行验证、授权、维护数据的机密性、完整性、限制暴露的信息、限制访问
检测攻击："入侵检测"
从攻击中恢复：识别攻击者（审计追踪）、恢复（冗余）

7、易用性

（1）常见场景

①界面友好。

②新用户学习使用系统时间不超过2小时。

（2）易用性战术

✓ 运行时：任务的模型、用户的模型、系统的模型（维护任务、用户、系统信息，了解系统用户的需求等）

✓ 设计时：接口与其余部分分离

✓ 支持用户主动操作：如取消、撤销等

8、可测试性

可测试性：对软件系统进行测试以证明满足需求规格的能力。指的是通过测试揭示软件缺陷的容易程度。

①常见场景：提供远程调试接口，支持远程调试。

②可测试性策略：输入/输出：记录回放 or 日志logs、接口与实现分离、优化访问线路接口。内部监控

例题：

例题：

六、系统架构评估方法

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

（1）敏感点(Sensitivity Point)和权衡点 (Tradeoff Point)。

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

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

（2）风险承担者 (Stakeholders)

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

（3）场景

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

例题：

2、系统架构评估的评估方法

基于调查问卷或检查表的方式
基于场景的方式
基于度量的方式

3、三种评估方法比较

评估方式	调查问卷	检查表	场景	度量
通用性	通用	特定领域	特定系统	通用或特定领域
评估者对体系结构的了解程度	粗略了解	无限制	中等了解	精确了解
实施阶段	早	中	中	中
客观性	主观	主观	较主观	较客观

4、基于调查问卷或检查表的方式

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

优点：自由灵活，可评估多种质量属性，也可以在架构设计的多个阶段进行。

缺点：评估的结果很大程度上来自评估人员的主观推断，因此不同的评估人员可能会产生不同甚至截然相反的结果，而且评估人员对领域的熟悉程度、是否具有丰富的相关经验也成为评估结果是否正确的重要因素。

5、基于场景的评估方式

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

✔刺激：是场景中解释或描述项目干系人怎样引发与系统的交互。

✔环境：描述刺激发生时的情况。

✔响应：指系统是如何通过体系结构对刺激作出反应的。

6、基于度量的评估方式

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

✔ 建立质量属性和度量之间的映射原则，即确定怎样从度量结果推出系统具有什么样的质量属性

✔ 从软件体系结构文档中获取度量信息

✔ 根据映射原则分析推导出系统的某些质量属性。

基于度量的评估方式又包括：

①软件架构分析法-SAAM方法：最初关注可修改性，后扩充到可移植性、可扩充性等。

②架构权衡分析法-ATAM方法：由SAAM发展而来，主要针对性能、实用性、安全性、可修改性。

③成本效益分析法-CBAM方法，在ATAM基础上建立的软件的"经济"模型。

（1）软件架构分析法-SAAM方法

SAAM方法是最早形成文档并得到广泛使用的软件体系结构分析方法，最初是用来分析体系结构的可修改性的，但实践证明，SAAM方法也可用于其他质量属性如可移植性、可扩充性等，最终发展成了评估一个系统架构的通用方法。

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

（2）架构权衡分析法-ATAM方法

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

ATAM分为4个主要的活动领域：

✔ 场景和需求收集

✔ 架构视图和场景实现

✔ 属性模型构造和分析

✔ 折中

ATAM方法采用效用树（Utility tree）这一工具来对质量属性进行分类和优先级排序。

效用树的结构包括：树根 →质量属性 →属性分类 →质量属性场景 （叶子节点）。

例题：

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

ATAM方法评估软件体系结构，分为4个基本阶段：

✔ 描述和介绍阶段(演示)：

是ATAM评估软件体系结构的初始阶段。此阶段有3个主要步骤：

第1步：介绍ATAM：涉及ATAM评估过程的描述。在此步骤中，评估负责人向所有相关参与者提供有关ATAM过程的一般信息。领导者说明评估中使用的分析技术以及评估的预期结果。领导者解决小组成员的任何疑虑、期望或问题。

第2步：介绍业务驱动因素：在这一步中，提到了系统体系结构驱动程序的业务目标。这一步着重于系统的业务视角。它提供了有关系统功能、主要利益相关方、业务目标和系统其他限制的更多信息。主要利益相关方：最终用户、架构师、应用程序开发人员。

第3步：介绍要评估的体系结构：在这一步中，架构团队描述要评估的架构。它侧重于体系结构、时间可用性以及体系结构的质量要求。此步骤中的体系结构演示非常重要，因为它会影响分析的质量。这里涉及的关键问题包括技术约束，与正在评估的系统交互的其他系统，以及为满足质量属性而实施的架构方法。

✔ 调查和分析阶段

是对评估期间需要重点关注的一些关键问题进行彻底调查。这个阶段细分为3个步骤：

第4步：确定架构方法：这一步涉及能够理解系统关键需求的关键架构方法。在这一步中，架构团队解释架构的流程控制，并提供关于如何达成关键目标以及是否达到关键目标的适当解释。

第5步：生成质量属性效用树：在评估阶段，确定系统最重要的质量属性目标，并确定优先次序和完善。这一步至关重要，通过建立效用树，将所有利益相关方和评估人员的注意力集中在关系到体系成功至关重要的体系结构的不同方面。

第6步：分析体系结构方法 ：这是"调查和分析"阶段的最后一步。在这一步中，分析前一步生成的效用树的输出并进行彻底调查和分析，找出处理相应质量属性架构的方法。这里还要确定每种架构方法的风险、非风险、敏感点和权衡点。

✔ 测试阶段

第7步：头脑风暴和优先场景：这是ATAM测试阶段的第一步。前者代表利益相关者的利益，用于理解质量属性要求。在效用树生成步骤中，主要结果是从架构师的角度来理解质量属性。在这一步中，目标是让更大的利益相关者参与其中。

第8步：分析架构方法：这是测试阶段的最后一步。在这一步中，我们分析上一步中高优先级的质量属性。找到了处理这些质量属性的架构设计方案，并检查相应的架构设计方案是否可支持满足这些属性。这一步重复"调查和分析"阶段的第6步。唯一的区别在于，在步骤6中，高优先级质量属性来自效用树，而这一步需要考虑在头脑风暴投票中，高得票数的质量属性。

✔ 报告阶段

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

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

①一种效用树；

②一组生成的场景；

③一组分析问题；

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

⑤确定的架构方法。

（3）成本效益分析法-CBAM方法

成本效益分析法（CBAM）是在ATAM上构建，用于对架构设计决策的成本和收益建模以优化决策。其思想是架构策略影响系统质量属性，质量属性为项目干系人带来收益（效用），协助项目干系人依投资回报（ROI）选择架构策略，在ATAM结束时开始，使用ATAM评估结果。

CBAM方法步骤：

①整理场景

②对场景进行求精

③确定场景的优先级

④分配效用

⑤架构策略涉及质量属性及响应级别，形成"策略---场景---响应级别"对应关系

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

⑦计算各架构策略的总收益

⑧根据受成本影响的ROI选择架构策略

例题：

七、软件可靠性设计

1、可靠性基本概念

①复杂性。软件内部逻辑高度复杂，硬件则相对简单，这就在很大程度上决定了设计错误是导致软件失效的主要原因，而导致硬件失效的可能性则很小。

②物理退化。软件不存在物理退化现象，硬件失效则主要是由于物理退化所致。

③唯一性。软件是唯一的，软件复制不改变软件本身，而任何两个硬件不可能绝对相同。

④版本更新较快。硬件的更新周期通常较慢，软件较快。

影响软件可靠性的主要因素：

（1）运行剖面（环境）。软件可靠性的定义是相对运行环境而言的，一样的软件在不同的运行剖面下，其可靠性的表现是不一样的。

（2）软件规模。软件规模也就是软件的大小，一个只有数十行代码的软件和几千、几万行代码的软件是不能相提并论的。

（3）软件内部结构。结构对软件可靠性的影响主要取决于软件结构的复杂程度，一般来说，内部结构越复杂的软件，所包含的软件缺陷数就可能越多。

（4）软件的开发方法和开发环境。软件工程表明，软件的开发方法对软件的可靠性有显著影响。例如，与非结构方法相比，结构化方法可以明显减少软件的缺陷数。

（5）软件的可靠性投入。

2、可靠性建模

（1）串联系统

假设一个系统由n个子系统组成，当且仅当所有的子系统都有能正常工作时，系统才能正常工作，这种系统称为串联系统。

如果系统的各个子系统的可靠度分别用表示，则系统的可靠度为：R =R 1×R 2×...×Rn 失效率 λ =λ 1+λ 2+⋅⋅⋅⋅⋅⋅

（2）并联系统

假设一个系统由n个子系统组成，当且一个子系统正常工作时，系统就能正常工作，这种系统称为并联系统。

可靠度为：R=1-(1-R1)×(1-R2)×...×(1-Rn)

例题：

（3）N模冗余系统可靠性

m模冗余系统由m（m=2n+1，n>1）个相同的子系统和一个表决器组成，经过表决器表决后，m个子系统中占多数相同结果的输出作为系统的输出。

3、可靠性设计（容错设计）

冗余思想有：

①结构冗余（硬件、软件冗余）

②信息冗余（校验码）

③时间冗余（重复多次进行相同的计算）

容错技术主要有：N版本程序设计（静态冗余）、恢复块设计（动态冗余）、防卫式程序设计等。

①N版本程序设计：N版本程序设计是一种静态的故障屏蔽技术，采用前向恢复的策略。

N版本设计增加了三个新的阶段：相异成份、规范评审、相异性测试、背对背测试。

②恢复块设计：有n个后备块的动态容错策略。

比较	恢复块	N版本程序设计
硬件运行环境	单机	多机
错误检测方法	验证测试程序	表决
恢复策略	后向恢复	前向恢复
实时性	差	好

③防卫式程序设计：一种不采用任何传统的容错技术就能实现软件容错的方法，对于程序中存在的错误和不一致性，防卫式程序设计的基本思想是通过在程序中包含错误检查代码和错误恢复代码，使得一旦发生错误，程序就能撤消错误状态，恢复到一个已知的正确状态中去。

N版本程序设计和恢复块方法都是基于设计冗余的思想，这给程序员和处理机都增加了许多工作，而且它们的结构本身又带来了一些问题和困难，例如，多版本程序设计中的相关性错误问题和恢复块方法中的验证测试的设计等。

防卫式程序设计实现策略包括错误检测、破坏估计和错误恢复三个方面。

通常在系统配置中可以采用相应的容错技术，通过系统的整体来提供相应的可靠性，主要有双机热备技术和服务器集群技术。

1）双机热备技术

双机热备模式（主系统、备用系统）
双机互备模式（同时提供不同的服务，心不跳则接管）
双机双工模式（同时提供相同的服务，集群的一种）

2）服务器集群技术

集群技术是指一组相互独立的服务器在网络中组合成为单一的系统工作，并以单一系统的模式加以管理。此单一系统为客户工作站提供高可靠性的服务。