[toc]

系统分析师笔记12_软件架构设计

该笔记内容来自《系统分析师教程》第2版。

软件架构概述

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

软件架构虽脱胎于软件工程，但其形成也借鉴了计算机架构和网络架构中很多宝贵的思想和方法。

软件架构研究的主要内容涉及软件架构描述、软件架构风格、软件架构评估和软件架构的形式化方法等。解决好软件的复用、质量和维护问题，是研究软件架构的根本目的。

软件架构的发展史

纵观软件架构技术的发展过程，从最初的无架构设计到现行的基于架构的软件开发，经历了4个阶段:

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

软件架构建模

软件架构设计的首要问题是如何表示软件架构，即如何对软件架构建模。根据建模的侧重点不同，可以把软件架构的模型分为5种，分别是结构模型、框架模型、动态模型、过程模型和功能模型。

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

在上述5种模型中，最常用的是结构模型和动态模型。这5种模型各有所长，将它们有机地统一在一起，形成一个完整的模型来刻画软件架构更合适。

例如，Kruchten在1995年提出了一个“4+1”的视图模型。“4+1”视图模型从5个不同的视角来描述软件架构，每个视图只关心系统的一个侧面，5个视图结合在一起才能反映软件架构的全部内容。“4+1”视图模型如图12-1所示。

软件架构风格

软件架构风格概述

软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。

体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。例如，如果某人把系统描述为“客户/服务器”模式，则不必给出设计细节，我们立刻就会明白系统是如何组织和工作的。

数据流体系结构风格

数据流体系结构是一种计算机体系结构，直接与传统的冯·诺依曼体系结构或控制流体系结构进行了对比。

数据流体系结构没有概念上的程序计数器:指令的可执行性和执行仅基于指令输入参数的可用性来确定，因此，指令执行的顺序是不可预测的，即行为是不确定的。

数据流体系结构风格主要包括批处理风格和管道-过滤器风格。

批处理体系结构风格

在批处理风格的软件体系结构中，每个处理步骤是一个单独的程序，每一步必须在前一步结束后才能开始，并且数据必须是完整的，以整体的方式传递。

它的基本构件是独立的应用程序，连接件是某种类型的媒介。连接件定义了相应的数据流图，表达拓扑结构

如图所示

管道-过滤器风格

当数据源源不断地产生，系统就需要对这些数据进行若干处理(分析、计算、转换等)。

现有的解决方案是把系统分解为几个序贯的处理步骤，这些步骤之间通过数据流连接，一个步骤的输出是另一个步骤的输入。每个处理步骤由一个过滤器(Filter)实现，处理步骤之间的数据传输由管道(Pipe)负责。每个处理步骤(过滤器)都有一组输入和输出，过滤器从管道中读取输入的数据流，经过内部处理，然后产生输出数据流并写入管道中。

因此，管道-过滤器体系结构风格的基本构件是过滤器，连接件是数据流传输管道，将一个过滤器的输出传到另一过滤器的输入。

如图所示

调用/返回 体系结构风格

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

程序从其执行起点开始执行该构件的代码，程序执行结束，将控制返回给程序调用构件。

调用/返回体系结构风格主要包括：主程序/子程序风格、面向对象风格、层次型风格以及客户端/服务器风格。

主程序/子程序体系结构风格

主程序/子程序风格一般采用单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序。子程序通常可合成为模块。

过程调用作为交互机制，即充当连接件。调用关系具有层次性，其语义逻辑表现为子程序的正确性取决于它调用的子程序的正确性。

面向对象体系结构风格

抽象数据类型概念对软件系统有着重要作用，目前软件界已普遍转向使用面向对象系统。

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

如图所示

层次型体系结构风格

层次系统的组成为一个层次结构，每一层为上层提供服务，并作为下层的客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层接口只对相邻的层可见。

在这样的系统中，构件在层上实现了虚拟机。连接件由决定层间如何交互的协议来定义，拓扑约束包括对相邻层间交互的约束。由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，这同样为软件重用提供了强大的支持。

如图所示

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

在IT发展过程中，网络计算经历了从集中式计算模型到分布式计算模型的演变。

在集中式计算技术时代，广泛使用的是大型机(或小型机)计算模型。它是通过一台物理上与宿主机相连接的非智能终端来实现宿主机上的应用程序。在多用户环境中，宿主机应用程序既负责与用户的交互，又负责对数据的管理。集中式的系统使用户能共享贵重的硬件设备，例如，磁盘机、打印机和调制解调器等。但随着用户的增多，对宿主机能力的要求增高，而且开发人员必须为每个新的应用重新设计同样的数据管理构件。

20世纪80年代以后，集中式结构逐渐被以PC为主的微机网络所取代。PC和工作站的采用，永远改变了协作计算模型，导致了分布式计算模型的产生。一方面，由于大型机系统固有的缺陷(例如，缺乏灵活性)，无法适应信息量急剧增长的需求，并为整个企业提供全面的解决方案;另一方面，由于微处理器的日新月异，其强大的处理能力和低廉的价格使微机网络迅速发展，用户可以选择适合自己需要的工作站、操作系统和应用程序。

因此出现了如下的演变。

二层架构（Client/Server，C/S架构）

客户机/服务器(Client/Server，C/S)架构是基于资源不对等，且为实现共享而提出来的，是20世纪90年代成熟起来的技术。C/S架构定义了工作站(客户应用程序)如何与服务器相连，以实现数据和应用分布到多台计算机上。

• 服务器负责有效地管理系统的资源，其主要任务集中于对DBMS的管理和控制，以及数据的备份与恢复;
• 客户应用程序的主要任务是提供用户与数据库交互的界面，向服务器提交用户请求并接收来自服务器的信息，对存在于客户端的数据执行应用逻辑要求。

这是一种“胖客户机(fat client)、瘦服务器(thin server)”的架构，其处理流程如图12-7所示。

C/S架构的优点

与集中式系统相比，C/S架构的优点主要在于，系统的客户应用程序和服务器构件分别运行在不同的计算机上，系统中每台服务器都可以适合各构件的要求，这对于硬件和软件的变化显示出极大的适应性和灵活性，而且易于对系统进行扩充和缩小。

在C/S架构中，系统中的功能构件充分隔离，客户应用程序的开发集中于数据的显示和分析，而服务器的开发则集中于数据的管理，不必在每一个新的应用程序中都要对一个DBMS进行编码。将大的应用处理任务分布到许多通过网络连接的低成本计算机上，以节约大量费用。

C/S架构具有强大的数据操作和事务处理能力，模型思想简单，易被人们理解和接受。

C/S架构的缺点

随着企业规模的日益扩大，软件的复杂程度不断提高，C/S架构逐渐暴露出以下缺点:

• (1)开发成本较高。C/S架构对客户端软硬件配置要求较高，尤其是软件的不断升级，对硬件要求不断提高，增加了整个系统的成本。
• (2)客户端程序设计复杂。采用C/S架构进行软件开发，大部分工作量放在客户端的程序设计上，客户端显得十分庞大。
• (3)用户界面风格不一，使用繁杂，不利于推广使用。
• (4)软件移植困难。采用不同开发工具或平台开发的软件，一般互不兼容，不能或很难移植到其他平台上运行。
• (5)软件维护和升级困难。采用C/S架构的软件要升级，开发人员必须到现场为客户机升级软件，每个客户机上的软件都需要维护。对软件的一个小小改动，每一个客户端都必须更新。
• (6)新技术不能轻易应用。因为一个软件平台及开发工具一旦选定，不可能轻易更改。
• (7)可扩展性差。C/S架构是单一服务器且以局域网为中心的，所以难以扩展至大型企业广域网或Internet，软硬件的组合和集成能力有限。客户机的负荷太重，难以管理大量的客户机，系统的性能容易变坏。
• (8)系统安全性难以保证。因为客户端程序可以直接访问数据库服务器，所以，在客户端计算机上的其他程序也可想办法访问数据库服务器，从而使数据库的安全性受到威胁。

三层C/S架构

正是因为C/S 架构有这么多缺点，因此，三层C/S架构应运而生。为了区分，把传统的C/S架构称为二层 C/S 架构。

与二层C/S架构相比，在三层C/S架构中，增加了一个应用服务器。可以将整个应用逻辑驻留在应用服务器上，而只有表示层存在于客户机上。这种客户机称为瘦客户机(thinclient)。

三层C/S架构将应用系统分成表示层、功能层和数据层三个部分，如图12-8所示。

• (1)表示层。表示层是系统的用户接口部分，担负着用户与系统之间的对话功能。它用于检查用户从键盘等输入的数据，显示输出的数据。为使用户能直观地进行操作，通常使用图形用户界面，操作简单、易学易用。
• (2)功能层。功能层也称为业务逻辑层，是将具体的业务处理逻辑编入程序中。例如，在制作订购合同时要计算合同金额、按照预定的格式配置数据、打印订购合同，而处理所需的数据则要从表示层或数据层取得。
• (3)数据层。数据层相当于二层C/S架构中的服务器，负责对DBMS进行管理和控制。

三层C/S架构对这三层进行明确分割，并在逻辑上使其独立。

三层C/S架构的关键是要将表示层和功能层分离成各自独立的程序，并且还要使这两层间的接口简洁明了。通常的做法是只将表示层配置在客户机中，如图12-9(a)或图12-9(b)所示。如果像图12-9(c)所示的那样连功能层也放在客户机中，与二层C/S架构相比，其程序的可维护性要好得多，但是其他问题并未得到解决。客户机的负荷太重，其业务处理所需的数据要从服务器传给客户机，所以系统的性能容易变坏。

如果将功能层和数据层分别放在不同的服务器中，如图12-9(b)所示，则服务器之间也要进行数据传送。由于三层是分别放在各自不同的硬件系统上的，所以灵活性很高，能够适应客户机数目的增加和处理负荷的变动。例如，在追加新业务处理时，可以相应增加装载功能层的服务器(应用服务器)。因此，系统规模越大，这种形态的优点就越显著。在三层C/S架构中，中间件是最重要的构件。

三层C/S架构的优点

与传统的二层C/S架构相比，三层C/S架构具有以下优点:

• (1)允许合理地划分三层的功能，使之在逻辑上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统的可维护性和可扩展性。
• (2)允许更灵活、有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层，并且这些平台和各个组成部分可以具有良好的可升级性和开放性。
• (3)系统的各层可以并行开发，各层也可以选择各自最适合的开发语言，使之能并行且高效地进行开发，达到较高的性能价格比。对每一层的处理逻辑的开发和维护也会更容易些。
• (4)利用功能层可以有效地隔离表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段非法访问数据层，这就为严格的安全管理奠定了坚实的基础。

但是，若三层C/S架构各层间的通信效率不高，即使分配给各层的硬件能力很强，其作为整体来说也达不到所要求的性能。此外，设计时必须慎重考虑三层间的通信方法、通信频度和数据量，这是三层C/S架构设计的关键问题。

B/S架构

浏览器/服务器(Browser/Server，B/S)架构是三层C/S架构的一种实现方式，其具体结构为“浏览器/Web服务器/数据库服务器”。

B/S架构利用不断成熟的浏览器技术，结合浏览器的多种脚本语言，用通用浏览器就实现了原来需要复杂的专用软件才能实现的强大功能，并节约了开发成本。从某种程度上来说，B/S架构是一种全新的软件架构。

在B/S架构中，除了数据库服务器外，应用程序以网页形式存放于Web服务器上，用户运行某个应用程序时，只需在客户端的浏览器中键入相应的网址，调用Web服务器上的应用程序，并对数据库进行操作，完成相应的数据处理工作，最后将结果通过浏览器显示给用户。

基于B/S架构的软件，系统安装、修改和维护全在服务器端解决。用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。

但是，与C/S架构相比，B/S架构也有许多不足之处，例如，缺乏对动态页面的支持能力，没有集成有效的数据库处理功能;安全性难以控制;采用B/S架构的系统在数据查询等响应速度上远远低于C/S架构;B/S架构的数据提交一般以页面为单位，数据的动态交互性不强，不利于OLTP应用。

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

以数据为中心的体系结构风格主要包括仓库风格和黑板风格。

仓库风格

仓库(repository)是存储和维护数据的中心场所。

在仓库体系结构风格(如图12-10所示)中，有两种不同的构件:中央数据结构(说明当前数据的状态)，以及一组对中央数据进行操作的独立构件，仓库与独立构件间的相互作用在系统中会有大的变化。这种风格的连接件即为仓库与独立构件之间的交互。

黑板风格

黑板体系结构风格(如图12-11所示)适用于解决复杂的非结构化问题，能在求解过程中综合运用多种不同的知识源，使得问题的表达、组织和求解变得比较容易。

黑板系统它将问题的解空间组织成一个或多个与应用相关的分级结构。分级结构的每一层信息由一个唯一的词汇来描述，它代表了问题的部分解。

领域相关的知识被分成独立的知识模块，它将某一层次中的信息转换成同层或相邻层的信息。各种应用通过不同知识表达方法、推理框架和控制机制的组合来实现。

黑板系统的传统应用是信号处理领域，如语音识别和模式识别。另一应用是松耦合代理数据共享存取。

虚拟机体系结构风格

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

虚拟机体系结构风格主要包括解释器风格和规则系统风格。

解释器体系结构风格

一个解释器通常包括完成解释工作的解释引擎，一个包含将被解释的代码的存储区，一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行进度的数据结构。

规则系统体系结构风格

基于规则的系统(如图12-13所示)包括规则集、规则解释器、规则/数据选择器及工作内存。

独立构件体系结构风格

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

独立构件风格主要包括进程通信和事件系统风格

进程通信体系结构风格

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

事件系统体系结构风格

事件系统风格(如图12-14所示)基于事件的隐式调用风格的思想，构件不直接调用一个过程，而是触发或广播一个或多个事件。

系统中其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。

面向服务的架构风格（SOA架构）

迄今为止，对于面向服务的架构(Service-Oriented Architecture，SOA)还没有一个公认的 定义。

许多组织从不同的角度和不同的侧面对SOA进行了描述，较为典型的有以下三个:

• (1)W3C的定义:SOA是一种应用程序架构，在这种架构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成业务流程。
• (2)Service-architecture.com的定义:服务是精确定义、封装完善、独立于其他服务所处环境和状态的函数。SOA本质上是服务的集合，服务之间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务之间需要某些方法进行连接。
• (3)Gartner的定义:SOA是一种C/S架构的软件设计方法，应用由服务和服务使用者组成，SOA与大多数通用的C/S架构模型不同之处，在于它着重强调构件的松散耦合，并使用独立的标准接口。

软件架构标准

软件架构的五个标准要素

• (1)任务(Mission)。任务是指一种使用或操作，是一个系统想要满足一名或多名利益相关者的目标，为达成这个目标，完成相对应的软件架构设计。这是软件架构标准设计的第一步，即需要明确软件的任务是什么，从而根据任务来进行软件架构的设计。任务通常可以是为了更大的利益、为了更高的市场占有率或完善产品系列等，这是软件架构标准中的第一层设计标准。
• (2)环境(Environment)、系统(System)以及架构(Architecture)。一个完整的系统是由系列组件组成的，将这些组件组织在一起，相互作用从而完成一个或者一些特殊的功能。在软件开发过程中，系统是任何对其设计、构造、部署和演变有重要影响的组成，包括单个应用程序、传统意义上的系统、子系统、产品线、产品系列、整个企业和其他利益。同时系统不可能单独存在，它总是存在于一个环境之中。在软件架构标准中，将系统范围之外的、对系统有影响、有交互的客观存在定义为环境，有时也称为上下文。并且每一个系统都应该实现一种或多种的软件架构，无论是否有意设计或者自发形成，这是软件架构标准中为了完成任务所进行的第二层设计标准。
• (3) 利益相者(Stackholder)、构说明(Architecture Description) 以及原理(Rationale).一个系统拥有多个利益相关者，并且系统架构也需要架构说明来进行描述，从而满足不同利益相关者的利益，从架构描述中可以识别出不同利益相关者的相关利益。同时在设计软件架构时，软件架构工程师需要做出许多取舍以及选择，需要给出选择或者不选择的理由，以及架构设计是如何满足功能性需求和非功能性需求的，这是软件架构标准第三层的设计标准。
• (4)关注(Concern)、关注点(Viewpoint)、视图(View)。一个系统的利益相关者对系统和与其有关的问题进行关注。一个关注点可能由一个或多个利益相关者持有。在整个生命周期中，对系统的需求和要求以及实施和运行的考虑等都可能成为关注点。关注点可以通过多种形式表现出来，例如与一个或多个利益相关者的需求、目标、期望、责任、要求、设计约束、假设、依赖性、质量属性、架构决策、风险或其他与系统有关的问题有关。不同的利益相关者其关注点不尽相同，有时甚至是矛盾的。站在不同的关注点，就会对系统架构形成不同的视图，视图和关注点是一一对应的关系。并且视图受关注点的制约:关注点确立了构建、解释和分析视图的规范。关注点的制约可以包括语言、符号、模型种类、设计规则，以及建模方法、分析技术和其他对视图的操作。
• (5)关注点库(Library Viewpoint)、模型(Model)。关注点库中存放了前人针对各种系统、各种不同的利益相关者、各种不同的关注点总结出来的观察点，方便后人参考使用。Model，可直译为模型，它是用来表示视图的方法，即使用图形化的表示，将不同视图下的系统元素组织起来，并将这些元素整体发挥的作用表现出来。

软件架构实现

传统的软件开发过程从概念到实现可以划分为若干个阶段，包括问题定义、需求分析、软件设计、软件实现及软件测试等。如果采用传统的软件开发模型，软件体系结构的建立应位于需求分析之后、概要设计之前。传统软件开发模型存在开发效率不高、不能很好地支持软件重用等缺点。

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

体系结构需求

需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。

体系结构需求受技术环境和体系结构设计师的经验影响。需求过程主要是获取用户需求，标识系统中所要用到的构件。

体系结构需求过程如图12-21所示。如果以前有类似的系统体系结构的需求，我们可以从需求库中取出，加以利用和修改，以节省需求获取的时间，减少重复劳动，提高开发效率。

体系结构设计

体系结构需求用来激发和调整设计决策，不同的视图被用来表达与质量目标有关的信息。体系结构设计是一个迭代过程，如果要开发的系统能够从已有的系统中导出大部分，则可以使用己有系统的设计过程。

软件体系结构设计过程如图所示。

体系结构文档化

绝大多数的体系结构都是抽象的，由一些概念上的构件组成。例如，层的概念在任何程序设计语言中都不存在。因此，要让系统分析员和程序员去实现体系结构，还必须要把体系结构进行文档化。

体系结构文档化过程的主要输出结果是体系结构规格说明和测试体系结构需求的质量设计说明书这两个文档。这些文档是需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。

体系结构复审

体系结构设计、体系结构文档化和体系结构复审是一个迭代过程。

复审的目的是标识潜在的风险，及早发现体系结构设计中的缺陷和错误，包括体系结构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求等。

体系结构实现

所谓“实现”就是要用实体来显示出一个软件体系结构，即要符合体系结构所描述的结构性设计决策，分割成规定的构件，按规定方式互相交互。体系结构的实现过程如图所示。

图中的虚线框部分是体系结构的实现过程。整个实现过程是以复审后的文档化的体系结构说明书为基础的，每个构件必须满足软件体系结构中说明的对其他构件的责任。这些决定即实现的约束是在系统级或项目范围内给出的，每个构件上工作的实现者是看不见的。

体系结构演化

在构件开发过程中，用户的需求可能还有变动。在软件开发完毕，正常运行后，由一个单位移植到另一个单位，需求也会发生变化。在这两种情况下，就必须相应地修改软件体系结构，以适应新的变化了的软件需求。

体系结构演化过程如图所示。

软件架构质量属性

软件系统属性包括功能属性和质量属性，软件架构重点关注的是质量属性。架构的基本需求是在满足功能属性的前提下，关注软件系统质量属性。

为了精确、定量地表达系统的质量属性，通常会采用质量属性场景的方式进行描述。

在确定软件系统架构，精确描述质量属性场景后，就需要对系统架构进行评估。软件架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。它也可以灵活地运用于软件架构评审等工作。

质量属性概念

软件系统质量属性(Quality Attribute)是一个系统的可测量或者可测试的属性，用来描述系统满足利益相关者(Stakeholders)需求的程度。

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

面向架构评估的质量属性

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

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

质量属性场景描述

为了精确描述软件系统的质量属性，通常采用质量属性场景(Quality Attribute Scenario)作为描述质量属性的手段。质量属性场景是一个具体的质量属性需求，是利益相关者与系统的交互的简短陈述。

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

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