软件架构设计 · 质量属性：GB/T16260 六特性、六元组与战术

是，先把这段总纲听准，它定调整个后半章。原文说：架构的基本需求主要是在满足功能属性的前提下，关注软件质量属性，架构设计则是为满足架构需求寻找适当的「战术」。软件属性包括功能属性和质量属性，但是软件架构及软件架构设计师重点关注的是质量属性。为什么？因为在大量的可能结构中，可以使用不同的结构来实现同样的功能性，即功能性在很大程度上是独立于结构的，架构设计师面临着对结构选择的决策。

但它是原文原话，判断题会原样出现。接着看标准。《GB/T16260-1996(idt ISO/IEC9126:1991) 信息技术软件产品评价质量特性及其使用指南》里描述的软件质量特性包括 6 个方面，每个方面都包含若干个子特性。六个大特性先报出来：功能性、可靠性、易用性、效率、可维护性、可移植性。

子特性逐个点名，一个都不能漏，因为选择题就爱拿「甲特性的子特性」冒充「乙特性的」。功能性：适合性、准确性、互操作性、依从性、安全性。可靠性：成熟性、容错性、易恢复性。易用性：易理解性、易学性、易操作性。效率：时间特性、资源特性。可维护性：易分析性、易改变性、稳定性、易测试性。可移植性：适应性、易安装性、遵循性、易替换性。

三处最容易串。第一，安全性是功能性的子特性，不在可靠性名下——很多人想当然觉得安全跟可靠是一家，按这个标准它挂在功能性下面。第二，稳定性在可维护性名下，别把它塞给可靠性。第三，易理解性和易学性归易用性，但易分析性、易测试性归可维护性，这四个「易」字头的要分两堆。

原文接下来还说：软件的质量属性很多，也有各种不同的分类法和不同的表述，虽然术语没有统一的定义，但其含义可以认为业界已有共识。下面选取常用的质量属性术语逐一说明，分成运行期和开发期两组。先看运行期质量属性，七项。

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

问到点子上了，这是判断题高发区。性能管的是快不快、吞吐大不大，不涉及故障；可靠性管的是在「一定时间内」不坏；持续可用性强调「长时间」，原文明确说它与可靠性相关联、常将其纳入可靠性中——所以选项里问持续可用性归哪类，答归入可靠性。鲁棒性强调非正常情况下还能跑，别名健壮性、容错性，这三个名字对同一件事。

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

一句口诀式的理解：运行期属性是系统跑起来之后用户感受得到的——性能、安全性、易用性、可伸缩性、互操作性、可靠性、持续可用性、鲁棒性；开发期属性是开发者在造和改的过程中关心的——易理解性、可扩展性、可重用性、可测试性、可维护性、可移植性。考试会问「以下哪项属于运行期质量属性」，比如拿可测试性当干扰项，你按「谁在感受」来分就不会错。

还有一处细节别漏：可扩展性也称灵活性，别名也要背，选项会用「灵活性」这个词来考你。另外注意易用性在 GB/T16260 那张表里是六大特性之一，在运行期属性清单里又出现一次，两处内涵一致，不冲突。原文最后还点了架构师的处境：在实践中，架构设计师追求质量属性常常陷入「鱼和熊掌」的两难境地，这就需要架构设计师的决策智慧了。原文用一张表反映质量属性之间相互制约的关系，正号代表行属性能促进列属性，负号则相反——例如许多属性对性能有副作用，性能对许多属性也有副作用，认识这一点对架构决策的权衡很重要。这为后面的权衡点、ATAM 埋了伏笔。

背全了。下一集继续 9.2.2——本章把质量属性重新归成六种来研究：可用性、可修改性、性能、安全性、可测试性、易用性，还有质量属性场景的六个组成部分和「战术」的定义。「战术」是什么、心跳属于哪类战术，练习题直接考，下集一个不落。

不是，这个混淆点必须先掰开。9.2.2 的原话：本节从架构关注点来研究质量属性的实现，将质量属性分为 6 种：可用性、可修改性、性能、安全性、可测试性、易用性。注意这个清单和 GB/T16260 的功能性、可靠性、易用性、效率、可维护性、可移植性不是一回事，它换了口径——其他的质量属性一般可纳入这六个属性中，例如可扩充性可归入可修改性中，也就是修改系统容量；可移植性也可以作为平台的可修改性来获得。

是，直接进选项。那怎么描述质量属性需求呢？原文采用质量属性场景作为一种描述规范，它由 6 个部分组成。逐个说，每个都要能听出差别。刺激源：生成该刺激的实体，人、计算机系统或其他激励器。刺激：刺激到达系统时可能产生的影响，即需要考虑和关注的情况。环境：该刺激在某条件内发生，如系统可能正处于过载情况。

制品：系统中受刺激的部分，某个制品被刺激。响应：刺激到达后所采取的行动。响应度量：当响应发生时，应能够以某种方式对应其度量，用于对是否满足需求的测试。

记住一条主宾关系：刺激源是「谁发起的」，是个实体；刺激是「发生了什么」，是情况本身。比如「用户在系统过载时输入错误数据」这个场景里，用户是刺激源，错误数据的到达是刺激，「系统正处于过载」是环境，「输入校验模块」是制品，拒绝并记录是响应，「两秒内返回提示」是响应度量。六个位置一摆，谁都冒充不了谁。

再辨一对词：一般场景和具体场景。一般的质量属性场景，是指独立于具体系统、适合于任何系统的一般性场景；具体的质量属性场景，是指适合于正在考虑的某个特定系统的场景，通常是从一般场景中抽取特定的、面向具体系统的内容。原文下面给每个质量属性一张表，列出场景各部分的可能取值，实际应用时从表里选取适当的值，就变成了可读性强、可应用的具体场景，可以把具体场景的集合作为系统的质量属性需求。

漂亮。接下来是本集最重要的定义，练习题第三题的答案。原文：实现这些质量属性的基本设计决策，称为「战术」，而把战术的集合称为「架构策略」，这些架构策略供架构设计师选择。「战术」作为逻辑部件位于质量属性场景图的制品中，它旨在控制对刺激的响应。

方向反了——不是战术归入风格，恰恰是后面 9.6 节会讲：架构模式也称为架构风格，它是适当地选取战术的结果。也就是说战术是砖、风格是砌好的墙，选项说「战术是架构风格的集合」是把墙说成砖的集合，主客颠倒。另外两个干扰项「系统的功能需求描述」「架构评估的结果」也都是偷换，战术服务的是质量属性不是功能需求，评估只是后面检验架构的手段。四个选项一个一个排掉，这题就是送分题。

对，战术清单是本章记忆量最大的一块，我们分两集啃。先把六个属性和它们战术的顶层分类报一遍，你心里有张总目录：可用性战术分错误检测、错误恢复、错误预防三类；可修改性战术分局部化修改、防止连锁反应、推迟绑定时间三类；性能战术分资源需求、资源管理、资源仲裁三类；安全性战术分抵抗攻击、检测攻击、从攻击中恢复三类；可测试性战术分输入/输出和内部监控两类；易用性战术分运行时战术、设计时战术、支持用户主动操作三类。

对，可用性的目标先记一句：阻止错误发展成故障，至少能够把错误的影响限制在一定范围内，从而使修复成为可能。错误和故障这两个词的递进关系就藏在这句里——战术的目标是在错误变成故障之前拦住它。

收尾点一下：战术与刺激的关系是「控制响应」，这句在选项里会变成「战术旨在消除所有错误」之类的绝对化说法，错，原文是阻止错误发展成故障、限制影响范围。下一集讲可用性战术全家桶——命令/响应、心跳、异常属于错误检测，表决、主动冗余、被动冗余、备件、状态再同步、检查点/回滚属于错误恢复，从服务中删除、事务、进程监视器属于错误预防，练习题第十二题「心跳属于哪类」就在其中。