软考高级之系统架构师系列之软件架构设计

注：本文汇总整理软考高级系统架构设计师试题和分析。

纯理论、纯概念、非原创。

概述

软件系统架构是关于软件系统的结构、行为和属性的高级抽象：

• 描述阶段，主要描述直接构成系统的抽象组件以及各个组件之间的连接规则，特别是相对细致地描述组件的交互关系
• 实现阶段，这些抽象组件被细化为实际的组件，如具体类或对象。

软件系统架构不仅指定软件系统的组织和拓扑结构，而且显示系统需求和组件之间的对应关系，包括设计决策的基本方法和基本原理。

软件架构能够在设计变更相对容易的阶段，考虑系统结构的可选方案，便于技术人员与非技术人员就软件设计进行交互，能够展现软件的结构、属性与内部交互关系。但是软件架构与用户对系统的功能性需求没有直接的对应关系。

软件架构设计包括提出架构模型、产生架构设计和进行设计评审等活动，是一个迭代的过程。架构设计主要关注软件组件的结构、属性和交互作用，并通过多种视图全面描述特定系统的架构。

软件架构设计与系统需求是直交的，两者并无必然联系。

层次

有3个由大到小的层次：

• 架构模式：软件设计中的高层决策，C/S结构就属于架构模式，架构模式反映开发软件系统过程中所作的基本设计决策
• 设计模式：主要关注软件系统的设计，与具体的实现语言无关；垃圾回收机制是Java语言管理内存资源时常用的一种设计模式。
• 惯用法：最低层的模式，关注软件系统的设计与实现，描述如何实现构件及构件之间的关系，实现时通过某种特定的程序设计语言来描述构件与构件之间的关系，例如引用-计数就是C++语言中的一种惯用法。

优点

软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素：

• 软件架构设计能够满足系统的性能、安全性、可维护性等品质；
• 软件架构设计能够帮助项目干系人（Stakeholder）更好地理解软件结构；
• 软件架构设计能够有效地管理系统的复杂性，并降低系统维护费用；
• 软件架构设计对系统开发具有指导性；
• 软件架构设计为系统复用奠定的基础；
• 软件架构设计能够支持冲突分析。

ADL

架构描述语言，Architecture Description Language，ADL是一种为明确说明软件系统的概念架构和对这些概念架构建模提供功能的语言。ADL主要包括以下组成部分：组件、组件接口、连接件和架构配置。ADL对连接件的重视成为和其他建模语言区分的重要特征之一。

复用

软件架构设计的一个核心问题是能否使用重复的架构模式，即能否达到架构级的软件重用。即，能否在不同的软件系统中，使用同一架构。基于这个目的，学者们开始研究和实践软件架构的风格和类型问题。软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。它反映领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。按这种方式理解，软件架构风格定义用于描述系统的术语表和一组指导构件系统的规则。

软件架构复用是指在不改变软件功能的情况下，将已有的软件架构直接或进行微调后复用到新的软件或系统中，从而加快软件开发进程，提高软件生产效率。

软件架构复用包括软件产品复用和软件过程复用两部分的内容。其中，软件产品复用是指将已有的软件组件（如函数、模块、组件等）直接或进行适应性修改后复用到新的软件或系统中；软件过程复用是指将已有的软件生产过程中的各种劳动成果（如设计文档、测试案例、源代码等）直接或进行适应性修改后复用到新的软件或系统中。

复用：开发过程中，只要发现有可复用的资产，就对其进行复用；
计划复用：开发之前就要进行规划，以决定哪些需要复用；

软件架构复用可分为以下几种类型：

• 代码级复用：通过编写公共类和公共函数等，供开发人员直接使用
• 组件级复用：将功能的组件化封装，对外提供API接口
• 模块级复用：在开发的项目或产品中，如果发现大量重复的功能模块，可以在这些模块设计时注重扩展性，使其能应用到其他类似功能的项目中
• 构架级复用：构架级在设计概念上最为高级的一种。它相当于一个平台或思想，在这个平台上，可以开发出根据此平台思想稳定而又高效的软件产品

软件架构复用的实现方式主要包括以下几种：

• 白盒复用：源代码可见，可修改和扩展
• 黑盒复用：源代码不可见，不能修改
• 模块层次复用：接口/类，包括继承和委托等

需求

软件架构需求是指用户对目标软件系统在功能、行为、性能和设计约束等方面的期望。需求过程主要是获取用户需求，标识系统中所要用到的构件，并进行架构需求评审。其中标识构件又详细分为生成类图、对类图进行分组和将类打包成构件三步。软件架构需求并不应该包括设计构件的过程。

架构师

架构师的主要职责包括：

1. 确认需求。在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证完整并准确地理解用户需求。
2. 系统分解。依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行纵向分解，还要对同一逻辑层分块，进行横向分解。
3. 技术选型。架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。架构师对产品和技术的选型只限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。
4. 制定技术规格说明。架构师在项目开发过程中，是技术权威。他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照他的架构意图去实现各项功能。架构师通过他制定的技术规格说明书（UML视图、Word文档、Visio文件）与开发者沟通，保证开发者可以从不同角度去观察、理解各自承担的子系统或者模块。架构师还需要与项目经理、需求分析员，甚至与最终用户保持沟通。

建模

应用架构建模中要绘制的第一个物理数据流图（PDFD）是网络架构DFD，它们不显示单位时间的数据流量，需要显示的信息包括服务器及其物理位置；客户端及其物理位置；处理器说明；传输协议。

生命周期

软件架构贯穿于软件的整个生命周期，但在不同的阶段对软件架构的关注力度并不相同。其中需求分析阶段主要关注问题域；设计阶段主要将需求转换为软件架构模型；软件实现阶段主要关注将架构设计转换为实际的代码；软件部署阶段主要通过组装软件组件提高系统的实现效率。其中设计与实现阶段在软件架构上的工作最多，也最重要，因此关注力度最大。

风格

软件架构风格是描述某一特定应用领域中的系统组织方式和惯用模式，反映领域中众多系统所共有的结构和语义两个方面的特征，主要包括架构定义、架构词汇表和架构约束，并指导如何将各个模块和子系统有效地组织成一个完整的系统。

架构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。

架构风格描述一类软件架构的特征，它独立于实际问题，强调软件系统中通用的组织结构选择。

分类

Garlan和Shaw对通用软件架构风格进行分类：

• 数据流风格：包括批处理序列和管道-过滤器两种风格
• 调用/返回风格：包括主程序/子程序、数据抽象、面向对象、层次结构
• 独立构件风格：包括进程通信、事件驱动、发布-订阅风格的系统
• 虚拟机风格：包括解释器和基于规则的系统
• 仓库风格：包括数据库系统、黑板系统和超文本系统
• 过程控制风格：包括有开环、闭环等
• 其他：包括C2、异构风格、混合风格

架构风格大类	架构小类	构件	连接件
数据流风格	批处理序列 管理过滤器	计算单元 过滤器	数据流传输的管道
调用/返回风格	主/子程序 面向对象 层次结构	主子程序 对象 每一层	过程调用 对象间的交付方式 层间的交付方式
独立构件	进程通信 事件驱动	独立进程 模块	消息传递 隐式调用
仓库风格	黑板系统	知识源	黑板或数据库系统

数据流风格

批处理序列

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

特点：强调整体性，无交互

管理过滤器

定义：

• 每个构建都有一组输入、输出，构建读输入的数据流，经过内部处理，然后产生输出数据流，这个过程通常是通过对输入数据流的变换或计算来完成的，包括：
  • 通过计算和增加信息以丰富数据
  • 通过浓缩和删除以精简数据
  • 通过改变记录方式以转化数据和递增的转化数据
• 构建为过滤器，连接件是数据流传输的管道

特点：不适合处理交互式应用

调用/返回风格

主程序/子程序

定义：

• 所有的计算构件作为子程序协作工作，并由一个主程序顺序地调用这些子程序，构件通过共享存储区交换数据。
• 调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性

构件为主程序和子程序，连接件是过程调用

面向对象

定义：建立在数据抽象和面向对象的基础上，数据的表示和它们的相应操作被封装起来。

构件是对象，对象是抽象数据类型的实例，对象之间通过消息机制进行通信，连接件是对象间的交付方式。

层次结构

定义：每层为上层提供服务，并使用下层提供的服务，一般中间层只对相邻层可见。

构件组成一个层次结构，连接件通过层间交互的协议来定义。

物联网属于层次型架构：

• 感知层：负责信息采集和物物之间的信息传输；实现对物理世界的智能感知识别、信息采集处理和自动控制；包括传感器、执行器、RFID、二维码和智能装置；
• 网络层：利用无线和有线网络对采集的数据进行编码、认证和传输；利用无线和有线网络对采集的数据进行编码、认证和传输，广泛覆盖的移动通信网络是实施物联网的基础设施；
• 应用层：实现应用。提供丰富的基于物联网的应用，物联网发展的根本目标，将物联网技术与行业信息化需求相结合。

独立构件风格

进程通信

定义：构件通常是命名过程，消息传递可以是点对点、异步或同步方式、以及远程过程调用等。

构件是独立的进程，连接件是消息传递

事件驱动系统（隐式调用）

定义：构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发，系统自动调用在这个事件上注册的所有过程。

构件是一些模块，这些模块可以是过程或事件。连接件以过程之间的隐式调用来实现。

优点：增加架构灵活性

缺点：

• 构件放弃对系统计算的控制
• 共享数据问题

C2

Components and Connectors，简称C2。C2体系结构风格可概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。主要用于网络化的软件应用中，特别是那些需要清晰分层和松耦合的系统。

两个基本元素：

• Components：构件，代表系统中的一个模块或功能单元，拥有自己的界面和内部状态，可独立于其他构建件运行。
• Connectors：连接件，负责在构建件之间传递消息、数据或控制流，定义构建件如何交互。

系统组织规则：

• 系统中的构件和连接件都有一个顶部和一个底部；
• 构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；
• 一个连接件可与任意数目的其他构件和连接件连接；
• 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。

优点

• 松耦合：上层构件对下层构件不感知，方便更新或替换下层构件；
• 高内聚：构件之间通过消息交互，相对独立，可封装任意复杂度的构件至系统中；
• 易扩展：构件只与上下层构件交互，功能的修改最多只影响上下层，不扩散影响；
• 可重用：只要符合请求及响应标准，即可重用构件；
• 支持异构系统集成：松耦合，适合集成异构系统和组件；
• 易于理解和实施：清晰的分层和组件化设计使得系统易于理解和实施。

缺点

• 性能开销：若业务处理涉及多个构件层次，在系统执行过程中将存在性能损耗；
• 层次不清：难以划分出合适且正确的层次结构，有时由于需求，需要跨层交互，增加复杂性。

分布式

客户机/服务器系统开发时可采用不同的分布式计算架构：

• 分布式表示架构：将表示层和表示逻辑层迁移到客户机，应用逻辑层、数据处理层和数据层仍保留在服务器上；
• 分布式数据架构：将数据层和数据处理层放置于服务器，应用逻辑层、表示逻辑层和表示层放置于客户机；
• 分布式数据和应用架构：将数据层和数据处理层放置在数据服务器上，应用逻辑层放置在应用服务器上，表示逻辑层和表示层放置在客户机上。

实战

黑板

对于信号处理、语音识别、语音搜索、模式识别、知识推理等问题复杂、解空间很大、求解过程不确定的这一类软件系统，通常会采用黑板架构风格，以知识为中心进行分析与推理。

黑板体系结构风格主要由三部分组成：

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

管道-过滤器

对于因数据而驱动，数据到达某个构件，经过内部处理，产生数据输出的系统通常采用管道-过滤器体系结构风格。

某公司拟为某种新型可编程机器人开发相应的编译器。编译过程包括词法分析、语法分析、语义分析和代码生成四个阶段，每个阶段产生的结果作为下一个阶段的输入，而且需要独立存储。采用管道-过滤器体系结构风格最为合适。

解析：在管道和过滤器软件体系结构中，每个模块都有一组输入和一组输出。每个模块从它的输入端接收输入数据流，在其内部经过处理后，按照标准的顺序，将结果数据流送到输出端，以达到传递一组完整的计算结果实例的目的。最典型的应用是在编译系统。

某软件开发公司负责开发一个Web服务器服务端处理软件，其核心部分是对客户端请求消息的解析与处理，包括HTTP报头分离、SOAP报文解析等功能。该公司的架构师决定采用成熟的架构风格指导整个软件的设计，以下（）架构风格，最适合该服务端处理软件。

解析：Web服务器服务端的核心功能是数据处理，Web服务在数据传输方面具有协议分层的特征，即底层协议会包装上层协议（HTTP协议体中包含整个SOAP消息内容），因此需要数据内容的逐步分解与分阶段处理。由于管道-过滤器的架构风格支持分阶段数据处理，因此特别适合该服务端处理软件的要求。

过程控制

调温器需要实时获取外界的温度信息，与用户定义的温度进行比较并做出动作。根据该系统的应用领域和实际需求，是典型的过程控制架构风格的应用场景。

某公司拟开发一个轿车巡航定速系统，系统需要持续测量车辆当前的实时速度，并根据设定的期望速度启动控制轿车的油门和刹车。采用过程控制架构风格最为合适。

（过程）控制系统的特点是不断采集系统当前状态，与系统中的设定状态进行对比，并通过将当前状态与设定状态进行对比从而进行控制

事件驱动

用户会注册自己的兴趣，系统也会把新闻按兴趣分类，如果某个新闻事件发生，可以通过事件来触发推送动作，将新闻推送给对其感兴趣的用户。事件驱动系统应用场景。

Windows操作系统在图形用户界面处理方面采用的是典型的事件驱动架构风格，首先注册事件处理的是回调函数，当某个界面事件发生时，系统会查找并选择合适的回调函数处理该事件。

隐式调用

某公司欲开发一个基于图形用户界面的集成调试器，该调试器的编辑器和变量监视器可以设置调试断点。当调试器在断点处暂停运行时，编辑程序可以自动卷屏到断点，变量监视器刷新变量数值。采用隐式调用的架构风格最为合适。回调机制。

某公司欲开发一个漫步者机器人，用来完成火星探测任务。机器人的控制者首先定义探测任务和任务之间的时序依赖性，机器人接受任务后，需要根据自身状态和外界环境进行动态调整，最终自动完成任务。针对这些需求，该机器人应该采用隐式调用架构风格最为合适。

解析：漫步者机器人需要根据自身状态和外界环境进行自动调整，这是一个典型的根据外部事件进行响应的场景。

解释器

某企业内部现有的主要业务功能已封装成Web服务。为拓展业务范围，需要将现有的业务功能进行多种组合，形成新的业务功能。针对业务灵活组合这一要求，采用解释器架构风格最为合适。

公司欲开发一个大型多人即时战略游戏，游戏设计的目标之一是能够支持玩家自行创建战役地图，定义游戏对象的行为和对象之间的关系。针对该需求，公司应该采用（解释器）架构风格最为合适。
解析：题目中提及支持玩家自行创建战役地图这说明系统要能应对自定义内容的解析，这需要用到解释器风格。

解释器是一个用来执行其他程序的程序，解释器可针对不同的硬件平台实现一个虚拟机，将高抽象层次的程序翻译为低抽象层次所能理解的指令，以消除在程序语言与硬件之间存在的语义差异。作为一种体系结构风格，解释器已经被广泛应用在从系统软件到应用软件的各个层面，包括各类语言环境、Internet浏览器、数据分析与转换等；LISP，Prolog、JavaScript、VBScript、HTML、Matlab、数据库系统（SQL解释器）、各种通信协议等。

虚拟机

Java是一种解释型语言，在JVM上运行，从架构风格上看是典型的虚拟机风格，即通过虚拟机架构屏蔽不同的硬件环境。

规则系统

规则系统体系结构风格是一个使用模式匹配搜索来寻找规则并在正确的时候应用正确的逻辑知识的虚拟机，其支持把频繁变化的业务逻辑抽取出来，形成独立的规则库。这些规则可独立于软件系统而存在，可被随时地更新。它提供一种将专家解决问题的知识与技巧进行编码的手段，将知识表示为条件-行为规则，当满足条件时，触发相应的行为，而不是将这些规则直接写在程序源代码中，规则一般用类似于自然语言的形式书写，无法被系统直接执行，故而需要提供解释规则执行的解释器。

如扫地机器人。

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

数据共享

现代编译器主要关注编译过程和程序的中间表示，围绕程序的各种形态进行转化与处理。这种情况下，可以针对程序的各种形态构建数据库，通过中心数据库进行转换与处理，数据共享风格最符合要求。

某公司为其研发的硬件产品设计实现一种特定的编程语言，为了方便开发者进行软件开发，公司拟开发一套针对该编程语言的集成开发环境，包括代码编辑、语法高亮、代码编译、运行调试等功能。针对上述描述，该集成开发环境应采用（ ）架构风格最为合适。

答案：数据仓储（数据共享）。
解析：现代编译器的集成开发环境一般采用数据仓储（即以数据为中心的架构风格）架构风格进行开发，其中心数据就是程序的语法树。

编译器

• 早期的编译器采用管道-过滤器架构风格，以文本形式输入的代码被逐步转化为各种形式，最终生成可执行代码。大多数编译器在词法分析时创造独立的符号表，在其后的阶段会不断修改符号表，因此符号表并不是程序数据的一部分
• 现代的编译器采用以数据共享为中心的架构风格，主要关心编译过程中程序的中间表示；分析树是在语法分析阶段结束后才产生作为语义分析的输入，分析树是数据中心中重要的共享数据，为后续的语义分析提供帮助。

DSSA

特定领域软件架构，Domain Specific Software Architecture，以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成的开发基础架构，其目标是支持一个特定领域中多个应用的生成。在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构。

特定领域的架构可分为：

• 垂直域：定义一个特定的系统族，包含整个系统族内的多个系统，结果是在该领域中可作为系统的可行解决方案的一个通用软件体系结构
• 水平域：定义在多个系统和多个系统族中功能区城的共有部分。在子系统级上涵盖多个系统族的特定部分功能。

DSSA通常是一个具有三个层次的系统模型：领域开发环境、领域特定应用开发环境和应用执行环境，其中应用工程师主要在领域特定应用开发环境中工作。

基本活动包括：

• 领域分析：主要目的是获得领域模型。领域模型描述领域中系统之间共同的需求，即领域需求；
• 领域设计：主要目标是获得DSSA，DSSA描述领域模型中表示需求的解决方案；
• 领域实现：主要目标是依据领域模型和DSSA开发和组织可重用信息，并对基础软件架构进行实现。

参与DSSA的人员可划分为4种角色：

• 领域专家：提供关于领域中系统的需求规约和实现的知识
• 领域分析者：控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中
• 领域设计人员：根据领域模型和现有系统开发出DSSA，并对DSSA的准确性和一致性进行验证
• 领域实现人员：

ABSD

基于架构的软件开发，Architecture Based Software Development，强调由商业、质量和功能需求的组合驱动软件架构设计，视角和视图来描述软件架构，用例和质量属性场景（Quality Attribute Scenario）来描述需求。用例描述的是功能需求，质量属性场景描述的是质量需求（或侧重于非功能需求）。

ABSD方法有三个基础：

• 功能分解，使用已有的基于模块的内聚和耦合技术
• 通过选择体系架构风格来实现质量属性和商业需求
• 采用软件模板设计软件结构

ABSD方法主要包括6个主要活动：

• 架构需求：
• 架构设计：
• 架构文档化：应该从使用者的角度进行书写，针对不同背景的人员采用不同的书写方式，并将文档分发给相关人员。架构文档要保持较新，但不要随时保证文档最新，要保持文档的稳定性。架构文档化的主要输出结果是架构规格说明书和架构质量说明书。
• 架构复审：目标是标识潜在的风险，及早发现架构设计中的缺陷和错误
• 架构实现：
• 架构演化：针对用户的需求变化，修改应用架构，满足新的需求

使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，并且设计活动的开始并不意味着需求抽取和分析活动可以终止，而是应该与设计活动并行。ABSD方法是一个自顶向下递归细化的过程，软件系统的架构通过该方法得到细化，直到能产生软件构件和类。

架构设计、文档化和复审是一个迭代的过程。在一个主版本的软件架构分析之后，要安排一次由外部人员（用户代表和领域专家）参加的复审。架构复审过程中，通常会对一个可运行的最小化系统进行架构评估和测试。

质量属性

刻画质量属性的手段由六部分组成：刺激源、刺激、环境、制品、响应、响应度量；

最常见的质量属性：可用性（Availability）、可修改性（Modifiability）、性能（Performance）、安全性（Security）、可测试性（Testability）、易用性（Usability）。

一种分类：

• 运行期质量属性：
• 开发期质量属性：

运行期质量属性：

• 性能：指软件系统及时提供相应服务的能力。（速度、吞吐量、持续高速性）
• 安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力
• 易用性：指软件系统易于被使用的程度
• 可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力
• 互操作性：与其他系统交换数据和相互调用服务的难易程度
• 可靠性：在一定的时间内无故障运行的能力
• 持续可用性：指系统长时间无故障运行的能力。与可靠性相关联，常将其纳入可靠性中
• 鲁棒性：是指软件系统在一些非正常情况（如用户进行非法操作、相关的软硬件系统发生故障等）下仍能够正常运行的能力。也称健壮性或容错性。

开发期质量属性：

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

可伸缩性和可扩展性：

• 可伸缩性：Scalability，指系统在保持性能稳定的前提下，能通过增加资源（计算或存储）应对增长的需求（应对高负载）。例如，水平扩展（添加更多服务器）或垂直扩展（提高单个服务器的性能）以处理更多的请求；
• 可扩展性：Extensibility，指系统在不影响现有系统结构和功能的前提下，能较方便地添加新功能或模块（应对业务需求）。关注的是系统在未来变更需求下的灵活性。

另一种分类，软件质量特性包括6个方面，每个方面都包含若干个子特性：

• 功能性：适合性、准确性、互操作性、依从性、安全性
• 可靠性：成熟性、容错性、易恢复性
• 易用性：易理解性、易学性、易操作性
• 效率：时间特性、资源特性
• 可维护性：易分析性、易改变性、稳定性、易测试性
• 可移植性：适应性、易安装性、遵循性、易替换性

软件质量属性通常需要采用特定的设计策略实现，设计策略会对其他质量属性产生影响。

改善（提高）软件质量属性的常见策略：

• 可用性（可靠性）
  • 错误检测：命令/响应、心跳机制、Ping/Echo、异常监控
  • 错误恢复：表决（裁决表）、主动冗余、被动冗余、备件（备份）、状态再同步、检查点/回滚、选举
  • 错误预防：从服务中删除异常（失效/失联）节点、事务（要么全成功，要么全失败）、定期重置、进程监视器
• 安全性
  • 抵抗攻击：对用户进行身份验证、对用户进行授权、维护数据的机密性、维护完整性、限制暴露的信息（信息隐藏）、限制访问
  • 检测攻击：部署入侵检测系统、追踪审计
  • 被攻击后恢复：恢复、识别攻击者
• 可修改性
  • 局部化修改：维持语义一致性、预期期望变更、泛化该模块、限制可能的选择、接口-实现分离
  • 防止连锁反应：信息隐藏（高内聚低耦合）、维持现有的接口、限制通信路径、使用仲裁者
  • 推迟绑定时间：运行时注册、配置文件、多态、构件更换
• 性能
  • 资源需求：减少处理时间所需的资源、减少所处理事件的数量、控制资源使用（改善资源需求）、限制执行时间、降低计算复杂度（减少计算开销）
  • 资源管理：引入并发、维持数据或计算的多个副本、增加可用（计算）资源
  • 资源仲裁：先进/先出、固定优先级、动态优先级调度、静态调度
• 可测试性
  • 输入/输出：记录/回放、将接口—实现分离、优化访问线路/接口
  • 内部监控：当监视器处于激活状态时、记录事件

SAAM

基于场景的架构分析方法，Scenarios-based Architecture Analysis Method。卡耐基梅隆大学软件工程研究所的Kazman等人于1983年提出的一种非功能质量属性的架构分析方法，是最早形成文档并得到广泛应用的软件架构分析方法。

其分析过程主要包括：场景开发、体系结构（架构）描述、单个场景评估、场景交互和总体评估。

场景

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

• stimulus：刺激，场景中解释或描述风险承担者怎样引发与系统的交互部分。如，用户可能会激发某个功能，维护可能会做某个更改，测试人员可能会执行某种测试
• environment：环境，描述的是刺激发生时的情况。如，当前系统处于什么状态？有什么特殊约束条件？系统负载是否很大？某个网络通道是否出现阻塞等
• response：响应，指系统是如何通过体系结构对刺激作出反应的例如，用户所要求的功能是否得到满足？维护人员的修改是否成功？测试人员的测试是否成功等

SAAM的主要输入：问题描述、需求说明和架构描述；

架构描述

ANSI/IEEE 1471-2000是对软件密集系统的架构进行描述的标准。系统是为了达成利益相关人（Stakeholder）的某些使命（Mission），在特定环境（Enviroment）中构建的。每一个系统都有一个架构（Architecture）。架构是对所有利益相关人的关注点（Concern）的响应和回答，通过架构描述（Architecture Description）来说明。每一个利益相关人都有各自的关注点。这些关注点是指对其重要的，与系统的开发、运营或其他方面相关的利益。

架构描述本质上是多视图的。每一个视图（View）是从一个特定的视角（View Point）来表述架构的某一个独立的方面。试图用一个单一的视图来覆盖所有的关注点当然是最好的，但实际上这种表述方式将很难理解。视角的选择，基于要解决哪些利益相关人的哪些关注点。它决定用来创建视图的语言、符号和模型等，以及任何与创建视图相关的建模方法或分析技术。一个视图包括一个或多个架构模型（Model），一个模型也可能参与多个视图。模型较文本表述的好处在于，可以更容易的可视化、检查、分析、管理和集成。

视图主要用于描述软件架构模型；

ATAM

架构权衡分析方法，Architecture Tradeoff Analysis Method。主要关注系统的需求说明。该方法强调对软件的质量属性进行分析、分类和优先级排序等工作，在此基础上构建质量属性效用树对质量属性描述进行刻画和排序，并对风险点、非风险点、敏感点和权衡点进行识别和分析。ATAM要求在系统开发之前，首先针对性能、可用性、安全性和可修改性等质量属性进行评价和折中。

在SAAM基础之上发展起来的一种系统架构评估方法，主要对软件体系结构的设计结果进行评估。评估是软件系统详细设计、实现和测试之前的阶段工作，因此评估不涉及系统的实现代码和测试，因为评估是考査软件体系结构是否能够合适地解决软件系统的需求，并不对软件需求自身是否准确进行核实，而软件需求是否准确是需求评审阶段的工作。不是一种精确的评估方法，主要形式是评审会议。

整个评估过程强调以属性作为架构评估的核心概念。

主要包括：场景和需求收集、架构视图和场景实现、属性模型构造和分析、属性模型（架构决策）与折中等4个阶段。

效用树从根部到叶子节点依次是：树根、质量属性、属性分类、质量属性场景。

1. 特定目标：是在考虑多个相互影响的质量属性的情况下，从原则上提供一种理解软件体系结构的能力的方法。对于特定的软件体系结构，在系统开发之前，可使用ATAM确定在多个质量属性之间折中的必要性
2. 质量属性：ATAM分析多个相互竞争的质量属性。考虑系统的可修改性、安全性、性能和可用性
3. 风险承担者：在场景、需求收集有关的活动中，ATAM需要所有系统相关人员的参与
4. 体系结构描述：体系结构空间受到历史遗留系统、互操作性和以前失败的项目约束。在五个基本结构的基础上进行体系结构描述，这五个结构是从Kruchten的4+1视图派生而来的。其中逻辑视图被分为功能结构和代码结构。这些结构加上它们之间适当的映射可以完整地描述─个体系结构。

4点

识别风险、非风险、敏感点和权衡点是进行软件架构评估的重要过程：

• 风险点：是某个存在问题的架构设计决策，可能会导致问题。非风险与风险相对，是良好的架构设计决策。风险点与非风险点不是以标准专业术语形式出现的，只是一个常规概念，即可能引起风险的因素，可称为风险点。
• 敏感点：是一个或多个构件（和/或构件之间的关系）的特性。研究敏感点可使设计入员或分析员明确在搞清楚如何实现质量目标时应注意什么。敏感点是实现一个特定质量属性的关键特征，该特征为一个或多个软件构件所共有。
• 权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。权衡点是影响一个或多个质量属性的特性，是多个质量属性的敏感点。

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

【改变业务数据编码方式会对系统的性能和安全性产生影响】是对权衡点的描述；
【改变加密的级别可能会对安全性和性能都产生显著的影响】是对系统权衡点的描述；
【假设用户请求的频率为每秒1个，业务处理时间小于30毫秒，则将请求响应时间设定为1秒钟是可以接受的】是对非风险的描述
【系统需要支持的最大并发用户数量直接影响传输协议和数据格式】描述敏感点

参考

• 软考高级试题及解析