软件的属性包括功能属性和质量属性，但是，软件架构重点关注的是质量属性。因为，在大量可能的结构中，可以使用不同的结构来实现同样的功能性，即功能性在很大程度上是独立于结构的，架构设计师面临决策（对结构的选择），而功能性所关心的是它如何与其他质量属性进行交互，以及它如何限制其他质量属性。

一、软件质量特性

1.1 软件质量特性主要包括

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

系统架构风险是指架构设计中，潜在的、存在问题的架构决策所带来的隐患。
敏感点是为了实现某种特定的质量属性，一个或多个系统组件所具有的特性。
权衡点是指影响多个质量属性，并对多个质量属性来说都是敏感点的系统属性.

1.2 常见质量属性

常见的软件质量属性有多种,例如性能(Performance)、可用性(Availability)、可靠性(Reliability)、健壮性(Robustness)、安全性(Security)、可修改性(Modification)、可变性(Changeability)、易用性(Usability)、可测试性(Testability)、功能性(Functionality)和互操作性(Inter-operation)等
这些质量属性的具体含义是:
1.性能是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理事件的个数.
2.可用性是系统能够正常运行的时间比例.
3.可靠性是指软件系统在应用或错误面前，在意外或错误使用的情况下维持软件系统功能特性的基本能力.
4.健壮性是指在处理或环境中，系统能够承受压力或变更能力。
5.安全性是指系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务
6.可修改性是指能够快速地以较高的性能价格比对系统进行变更的能力
7.可变性是指体系结构经扩充或变更成为新体系结构的能力
8.易用性是衡量用户使用有一个软件产品完成指定任务的难易程度
9.可测试性是指软件开发发现故障并隔离、定位其故障的能力特，以及在一定时间和成本前提下，进行测试设计、测试执行的能力。
10.功能性是系统所能完成所期望工作的能力
11.互操作性是系统所能完成所期望工作的能力

二、常见的质量属性分类

常见的质量属性，可以按照运行期与开发期进行分类：

2.1 运行期质量属性

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

2.2 开发期质量属性

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

架构师在追求质量属性常常陷入“鱼和熊掌”的两难境地，这就需要架构设计师的决策智慧了。

注上表中“+”表示促进作用，“-”则相反

2.3 质量需求怎么描述

在软件系统架构设计中，如何描述软件的质量属性需求呢？一般采用场景的方式进行描述，主要包括6种场景。
本节“场景”指的是软件系统设计中通用的场景。

质量属性场景包括6个元素。

刺激源：生成该刺激的实体（人、计算机系统或其他励志器）；
刺激：刺激达到系统时可能产生的影响（即需要考虑和关注的情况）；
环境：该刺激在某条件内发生。如系统可能正处于过载情况；
制品：系统中受刺激的部分；
响应：刺激到达后所采取的行动；
响应度量：当响应发生时，以某种方式对响应的效果进行度量。

通过对每一类质量属性进行场景化描述，然后，分别制定应对各个场景的策略。

2.3.1 可用性的场景描述以及策略

可用性的策略目标是阻止错误发展成故障，至少能够把错误的影响限制在一定范围内，从而使修复成为可能。主要包括：错误检测、错误恢复、错误预防。

2.3.2 可修改性的场景描述以及策略

可修改性的场景描述如下

为了应对系统的可修改性需求，主要有三种方法：

局部修改。在软件架构设计的时候，对系统进行分解，将预期的变更限定在一定的范围内，从而降低修改的成本。
防止连锁反应。模块之间往往存在依赖性，在修改时要保持接口的一致性。通过限制模块间的通信线路，可以在修改某模块后再恢复通行线路。
推迟绑定时间。系统在运行时进行绑定并允许非开发人员进行修改（配置）。
运行时注册、配置文件、多态（在方法调用的后期绑定）、构件更换（允许载入时绑定）。

3.2.3 性能的场景描述以及策略

性能主要与时间有关，影响事件的响应时间有两个基本因素：资源消耗，闭锁时间（指事件处理碰到资源争用、资源不可用或对其他计算的依赖等情况，产生的等待）。

针对性能要求主要有一下几种应对策略：

资源需求
①减少处理事件流所需的资源：提高计算效率、减少计算开销
②减少处理事件的数量：管理事件率、控制采样频率。
③控制资源的使用：限制执行时间（如减少迭代次数）、限制队列大小

资源管理
引入并发：并发对负载平衡很重要
维持数据或计算的多个副本：C/S结构中客户机C就是计算的副本，它能减少服务器计算的压力；高速缓存可以存放数据副本。
增加可用资源：在成本允许时，尽量使用速度更快的处理器、内存和网络。

资源仲裁
资源仲裁是通过如下调度策略来实现的：
①先进先出FIFO
②固定优先级调度
③动态优先级调度，轮转调度、时限时间最早优先
④静态调度，离线确定调度

3.2.4 安全性的场景描述以及策略

针对安全性要求的策略主要包括：

抵抗攻击
对用户进行身份验证：动态密码、一次性密码、数字证书、生物识别
对用户进行授权：即对用户的访问进行控制管理
维护数据的机密性：一般通过对数据和通信链路进行加密来实现
维护完整性：对数据添加校验或哈希值；限制暴露的信息
限制访问：如用防火墙、DMZ策略

检测攻击
一般通过“入侵检测”系统进行过滤、比较通信模式与历史基线等方法。

从攻击中恢复
恢复：与可用性中的战术相同；
识别攻击者：作为审计追踪，用于预防性或惩罚性目的。

3.2.5 可测试性的场景描述以及策略

可测试性策略：

输入/输出
①记录/回放：指捕获跨接口的信息，并将其作为测试专用软件的输入；
②接口与实现分离：允许使用实现的替代（模拟器）来支持各种测试目的；
内部监控
当监视器处于激活状态时，记录时间（如通过接口的信息）。

3.2.6 易用性的场景描述以及策略

针对易用性要求的策略，主要包括：

运行时策略
任务模型：维护任务的信息，使系统了解用户试图做什么，并提供各种协助；
用户模型：维护用户的信息，例如使用以用户可以阅读页面的速度滚动页面
系统的模型：维护系统的信息，它确定了期望的系统行为，并向用户提供反馈。

设计时策略
将用户接口与应用的其余部分分离开来，预计用户接口会频繁发生变化，因此，单独维护用户接口代码将实现变更局部化。

用户主动操作
支持用户的主动操作，如支持“取消”、“撤销”、“聚合” 和“显示多个视图”

3.3 软件体系架构——质量属性分析

以《淘宝网》为例，描绘质量属性的六个常见属性场景，将上述整理为一篇博客发表。

3.3.1 可用性分析

可用性分析所关注的方面包括：如何检测系统故障，系统故障发生的频度，出现故障时会发生什么情况，允许系统有多长时间非正常运行，什么时候可以安全地出现故障，如何防止故障的发生以及发生故障时要求进行哪种通知。
场景：双十一或者春晚抽奖导致淘宝用户猛增
刺激源：淘宝用户
刺激：登录人数过多，导致淘宝无法响应，淘宝瘫痪，网页无法向下进行
制品：淘宝的处理器、通信通道、存储器、进程
环境：用户的正常浏览操作
响应：淘宝页面呈现“网络出现故障，重新刷新”等的提示信息，提示用户下一步操作
响应度量：系统降级模式下继续运行，用户刷新页面或者重新登录之后可继续正常使用。

3.3.2 可修改性分析

可修改性是有关变更的成本问题。可以修改什么（制品）和何时进行变更以及由谁进行变更（环境）。
场景：新年来临，淘宝app要修改自己的系统页面，并且添加一些其他的功能
刺激源：系统开发人员
刺激：系统界面要修改为新年主题，增加抽奖红包等功能
制品：淘宝界面即抽奖领取红包界面
环境：淘宝正常登录运行时
响应：针对页面查找构架中需要修改的位置，进行修改添加并且不影响其他功能，对修改进行测试，部署所做修改
响应度量：系统人员后台更新，测试部署成功自动更新，用户登录即可

3.3.3 性能分析

性能与时间有关。事件（中断、消息、用户请求或时间已到）发生时，系统必须做出响应。事件到达和相应有很多特性，但性能基本上与事件发生时，将要耗费系统多长时间做出响应有关。
场景：淘宝用户购买商品
刺激源：淘宝用户
刺激：购买商品
制品：系统生成订单
环境：淘宝正常运行
响应：淘宝生成订单，提示用户进行支付，检测网络环境
响应度量：在短时间内显示商品状态以及支付状态，显示交易的完成度

3.3.4 安全性分析

安全性是衡量系统在向合法用户提供服务的同时，阻止非授权使用的能力。试图突破安全防线的行为被称为攻击，它可以是未经授权试图访问数据或服务，或试图修改数据，也可能是试图使系统拒绝向合法用户提供服务。

场景：一个通过身份验证的人试图从外部站点更改系统数据
刺激源：淘宝用户
刺激：试图从外部站点修改系统数据
制品：系统服务、系统中的数据
环境：在线连接有防火墙
响应：对用户身份进行验证，阻止其对数据的访问
响应度量：短时间内审核身份，拒绝其访问，并限制系统可用性

3.3.5 可测试性分析

软件可测试性是指通过测试揭示软件缺陷的容易程度。
场景：单元测试人员测试商品浏览查询模块
刺激源：单元测试人员
刺激：测试人员输入商品关键词，进行商品查询
制品：商品搜索模块的代码
环境：在开发时进行
响应：通过商品关键词查询，所检索出的商品信息呈列表显示
响应度量：在较短的时间内完成对商品的检索

3.3.6 易用性分析