本书第丨部分介绍了构架商业周期（ABC),它为分析软件构架獎定了莲础。尤其是， 它陈述了当设计师开始构建系统时的各种影响因素，并指出了特定的质量属性要求（如性 能或可修改性）通常产生于组织的业务目标。设计师如何创建构架？这就足第丨丨部分的艰 点。因为质1域性的实现对系统的成功至关重要，因此我们开始对质狱厲性以及设计师如 何借助他的工具箱来实现质fi厲性进行讨论。
对质量好坏做出评判的通常是旁观者（Booth Tarkington的解释）。这对设汁师来说总 味着客户可能不喜欢某个设计方案，因为他们的质量属性概念与设汁师不同，质量厲性场景就是把质量属性从旁观者的角度转换为更加客观的基础的手段。在第4章，我们探讨了 可能适合构架的不同类型的质量属性。对于6个重要的质量属性（可用性、可修改性、性 能、安全性、可测试性和易用性)，我们描述了如何生成可以用来刻画质量需求的场景。 这些场景说明了对某个特定的系统来说质量意味着什么，它们为设计师和客户提供了 -个 对设计进行评判的基础。
当然，知道质量需求仅为设计师提供了-个目标。在第5章中，我们列出了设计师可 以用来实现质贴耑求的战术和模式。例如，高可用性依赖于在数据或代码中某种形式的冗 余，这种冗余需要设汁师考虑额外的因素（如确保复制的同步)。
在第6章.我们介绍了第2个案例分析——设计用来支持联邦航空局的空中交通管制 功能的系统。该系统设计用來满足极高的可用性需求（每年的停机时间耍少于5分钟)， 并说明了在第5韋所列举的战术。
质量属性场景和构架战术是-些可用于创建构架的工具。在第7萆中，我们讨论了如 何在设汁构架和构建骨架系统的过程中应用这些工具，以及构架如何反映在绀织的结构中。
在第8章我们给出了关于飞行模拟器的第3个案例分析。这些系统被设计用来实现 实时性能和可轻松修改性。本章说明了实现这些目标的方式。
设计了构架后，必须将其编成文档。首先把相关视图编成文档，然后把所有特定视图都不能表达的内容编成文档。第9章详细阐述了构架编档.
我们通常得不到系统的构架：可能是因为根本没有把构架编成文档，或虽然编成了文档，但丢失了，或现在的系统不同于所设计出来的系统。第10章将介绍如何根据现有系统 恢复构架..
第4章理解质量属性
在前面讲述构架商业周期时我们看到，商业目的决定了系统构架必须满足的一些质量 属性。这些质量属性是高于对系统功能（即对系统能力、服务和行为）的基本要求的。尽 管系统的功能与系统其他方面的厲性紧密相连（下面我们将会讲到），但在幵发过程中功 能要求一般是首先也是唯一要考虑的。经常重新设计系统并不是因为该系统在功能上有缺 格~更改后的部分在功能上一般没有什么改动——而是由于系统的维护、移植或扩展十 分困难。系统运行速度太慢，或者是因为系统遇到了网络黑客的攻击。在第2章我们曾经 说过，构架是实现质量需求的软件创建中的第一个阶段•它是软件功能到软件结构的映射， 而软件结构确定了构架对质麗属性的支持。在第5章我们将讨论构架设计决策如何支持质 量属性，在第7章则讨论设计师如何管理所有设计中所固有的权衡。
我们根据某个构架创建一个或多个系统，本章的重点是理解如何表示希望该构架为上 述系统提供的质量属性。我们通过仔细分析质量属性来讨论质量属性和软件构架之间的关 系。说某个系统是可修改的、可靠的或安全的是什么意思？本章描述了这些属性，并讨论了 如何使用这作描述来表示某个系统的质量需求。
4.1功能性和构架
功能性和质量属性是正交的。最初听到这种说法时觉得它相当冒失，但仔细考虑一下，您就会意识到，这两者不可能是其他关系。如果功能性和质量属性之间不是正交关系，那么，功能选择将会规定安全性、性能、可用性或易用性的级别。然而毋庸迓疑的是，对于每个质量属性，都可以独立地选择所期望的级别。这并不是说可以用任何功能实现任何质 量厲性的所有级別。处理复杂的图形图像或对巨大的数据库进行排序在本质上都是非常复杂的，这使得不可能有非常快速的性能。怛可以做到的是对所选择的任何功能，设计师都 将确定每个质量属性的相对级别。-些构架选择将会导致更高的性能：一些构架选择会导 致性能降低。考虑到上述因素，本章的目的就是（对一个好的构架）分离关注点。反过来， 我们将会分析每个重要的质量属性.学习如何以一种规范的方式对该质量城性进行思考。
什么是功能性？功能性指系统能够完成所期望的工作的能力。某项任务的完成通常要 求系统中的很多成绝大多数元素协作.就像在蛊房子时，设计者、电工、管道工、油漆工、 木工等相关人员耍相互协作样。所以，如果各元素的责任划分不合理，或没街提供与其 他元素协调的适当的设施（例如，使它们知道何时开始执行自己所要完成的任务).系统 就不能提供所需要的功能性。
在大量可能的结构中.可以通过使用任意•个结构来实现功能性。实际上.如果功能 性是系统的惟需求的话，整个系统就可以是一个根本没有内部结构的单一模块。相反， 系统被分解成多个模块，以使其变得可理解，并支持各种其他目的。由此，功能性在很大 程度上是独立于结构的。当其他质量属性很重要时.软件构架会限制各结构的功能分配。 例如，我们经常将系统划分成几个部分，以便由多个人员共同开发（这实际上也是-个上 市时间的问题.虽然很少这样表述）。功能性所关心的是它如何与其他质量属性交互，以 及它是如何限制其他质量属性的。
4.2构架和质量属性
必须在从设计、实现到部署的整个过程中考虑质量属性的实现。没有任何--个质量属 性是完全依赖于设计的，它也不完全依赖于实现或部署。满意的结果就是使总体蓝阁（构 架）以及细节（实现）正确。例如：
• 易用性涉及构架和非构架两个方面。例如，非构架方面包括使用户界面淸晰、易 用。应该在用户界面上用单选按钮还是复选框？什么样的界而布局最为直观？什 么样的字体最淸晰可辨？虽然类似这样的细节对最终用户来说非常重要，并且也 影响系统的易用性，但因为它们厲于设计细节方面的问题，因此它们都不是需要 在构架层次上解决的问题。然而，系统是否能为用户提供取消操作、撤销操作或重用以前输入的数据的能力则属于构架方面的问题。这些需求涉及到多个元素之 间的协作。
• 可修改性由划分功能的方式（构架方面的）和模块中的编码技巧（非构架方面的） 决定。因此，如果变更仅涉及极少不同的元素.那么，系统就是可修改的。这就 是第3章的A-7E模块分解结构的基础„然而，即使有了理想的构架，可读性很 差的代码也可能会使系统变得很难修改。
• 系统性能则是一个既依赖于构架又不完全依赖T•构架的质量属性。系统性能受各 组件之间必须进行通信的数据的制约（构架方面的），受为每个组件所分配的 功能的影响（构架方面的），受分配共亨资源的方式的影响（构架方面的），同时 也受所选择的实现某个功能的算法的限制（不是构架方面的）.受这些算法的编 码方式的限制（不是构架方面的)。
所以，本节所讲的内容具有以下两重含义：
(1)对我们所关心的许多系统质爾;属性的实现而言，构架具有重要意义。在构架设 计过程中就应考虑到这些质蜇城性，并在构架层次上进行相应的评估。
(2)构架并不能独自实现质量厲性。它提供了实现质量属性的基础，但如果不关注 细节，那么，这个基础也没什么用处。
在复杂的系统中.决不可能以孤立的方式实现质量厲性。任何-个质M•属性的实现都 会对其他质尬厲性的实现带来积极或消极的影响。例如，安全性和可靠性之间就具有这样 的关系：坡安全的系统-般都冇安全的内核，其故障点最少：最可靠的系统则有最多的故故障点，通常在这样的系统中要配置一组冗余的处理器或进程。从而保证-个处理器或进程 出现故障时不会导致整个系统的崩溃。说明质量属性相互影响的另一个例子是，几乎每个质量属性都会对系统性能产生消极影响.例如可移植性。保证软件系统具有良好的可移植 性的主要手段是隔离系统的相互依赖性，这加大了系统执行的开销，通常会对进程或过程 的边界有所限制.这就对系统性能带来了负面影响。
下面我们就开始具体讨论各个质ill:域性。我们将分析以下3类质量属性：
(1)系统的质量属性。我们将重点讲述可用性、可修改性、性能、安全性、可测试性和易用性。
(2)受构架影响的商业属性（如上市时间）。
(3)与构架本身相关的一些质量厲性（如概念完整性)，它们会间接影响其他质量属 性.如可修改性。
4.3系统的质量属性
至少从20肚纪70年代开始，系统的质量属性就引起了软件团体的注意。现在.已经
有许多关于质狃厲性的分类和定义，其中的很多分类和定义都有自己的研究和实践者团 体。从设计师的角度看，以前对系统质量属性的讨论中存在以下3个问题：
•为厲性提供的定义并不是可操作的。称某个系统足可修改的是没冇意义的。对于 -组变化来说，每个系统都是可修改的；而对于另-•组变化來说，每个系统又都 足+可修改的。其他的属性也是如此。
• 讨论的中:点通常足个特定的方面属于哪个质最属性。系统故障属于可用性方 面、安全性方面还是易用性方面？可用性团体声称系统故障属于可用性问题。安 全性团体声称系统故障属于安全性问题；而易用性团体则声称系统故障域f易用 性问题。
• 侮个属性团体都开发了其自己的词汇。性能团体具有到达某个系统的“事件”， 安全团体具有到达某个系统的“进攻”，可用性团体具有系统的“故障”，易用 性团体具有“用户输入”。实际上.所有这些可能指的都是同一个事件，但却是 使用不同的术语进行描述的。
前两个问题（不可操作的定义和重复强调的属性）的解决方案是使用质量属性场景作 为刻画质量属性的手段。第三个问题的解决方案是简耍讨论一下每个厲性——集中在其根 本的关注点上一以说明对该属性团体来说很基本的概念。
4.3.1质量属性场景
质蛩诚性场设是.种面向特定的质量属性的需求。它由以下6部分组成：
• 刺激源。这足某个生成该刺激的实体（人、计算机系统或任何其他激励器)。
• 刺激.，该刺激是当刺激到达系统时需要考虑的条件。
• 环境.、该刺激在某些条件内发生。当刺激发生时，系统可能处f过战.或者正在 运行，也可能趄其他情况。
• 制品.，某个制品被刺激。这可能是整个系统•也可能是系统的一部分。
• 响应.、该响应是在刺激到达后所采取的行动。
• 响应度量。当响应发生时，应该能够以某种方式对其进行度姐以对需求进行测试。
我们将一般的质量属性场景（一般场景）与具体的质量属性场景（具体场景〉区分开 来；前者是指那些独立于系统，很可能适合任何系统的场景，后者是指适合正在考虑的某 个特定系统的场谀。我们以一般场景集合的形式提供属性描述。然而，为了把属性描述转 换为对某个特定系统的需求，需要把相关的一般场景变为面向特定系统的。
图4.1给出了质量属性场景的6个部分。
可用性场景.，图4.2给出了可用性质量属性的一般场景。该图给出了其6个部分，并 简要说明了它们可取值的范围。可以从该图中得出具体的、特定于系统的场景。并不是每个特定于系统的场思都凤备所有这6个部分。每个场景所必须具有的就是应用场景的结 果以及将耍执行的测试类型，这些测试将用以确定是否实现了该场景。
通过用具体例子说明每一部分，可以从图4.2的一般场景屮得出的可用性场景的示例是“在正常操作期间，进程收到了一个未曾预料到的外部消息。该进程通知操作人员收到 了这.消息，并继续操作（没有停机）”。图4.3给出了所得到的这场景的各部分。
刺激源是重要的，因为不同的刺激源可能要求作出不同的响应。例如，在一个安全性场景中，会用不同的方式对待来自一个可信源的请求和一个来自不可信源的诮求。环境也 可以影响响应，因为如果系统已经过载，可能就会用不同的方式对待到达系统的某个事件。 受刺激的制品.作为一种需求，并不是非常重要。它通常都是系统，我们对其进行显式调 出，原因如下所述。
首先.许多需求都对系统的内部结构做了假设（例如，系统中的Web服务器出现了故 降）。其次，当我们在评估或设计方法中使用场景时，我们对场景制品进行精化，以能够 非常淸楚地了解系统被刺激的部分。最后，清楚了解响应值是非常重要的，因为这样可以 明确质量属性需求。因此，我们把响应度量作为场景的一部分。
可修改性场景。可修改性场景的一个样例是“开发人员希望改变用户界面，以使屏幕 的背设颜色为蓝色。这需要在设计时改变代码。需耍在3个小时内改变代码并对改变后的 代码进行测试，行为中将不会出现有副作用的变化”。图4.4说明了这一样例场景（为了简 短起见，省略了几个微小的细节)
可以把具体场景的集合用作系统的质量属性需求。每个场景都足够具体，因此对设计 师是有意义的：响应的细节也具有足够的意义，因此可以测试系统是否实现了该响应。获 取需求时，我们一般组织对一般场景进行讨论（根据质量属性)：如果相同的场景由两个 不同的属性生成，那么，去除其中的一个属性。
对于每个厲性，我们都提供了个表，该表对质量属性场景中的每一个部分都给出了可 能的独立于系统的值。通过为每个元素选择一个值来生成一般的质量属性场景：通过从该 表的每一列选择一个或多个条目，然后使结果变得可读来生成具体场景，我们把它作为需求获取的一部分。例如，图4.4中的场景是根据表4.2中给出的可修改性场景生成的，但 对每个部分都稍微进行了修改，以使它们作为一个场景读起來更加流畅
具体场景在质设厲性需求规范中所扮演的角色与用例在功能需求规范中所扮演的角 色相同。
4.3.2生成质量属性场景
本章关注的是帮助设计师为系统生成有意义的质量属性需求。从押论上说，这应该是 在项目的滿求获取阶段完成的工作，但在实际中很少这样严格执行。在笫1承中曾经说过. 很少用.种规范的方式获取系统的质量属性需求并将其记录下来。我们通过生成具体的质量厲性场景来纠正这种情况。为了做到这一点，我们使用特定于质量属性的表来创建一般场景，并根据这些一般场景得出特定于系统的场景。典型情况下，并不创建所有可能的一般场景。可以把该表作为检査列表（而非明确的生成机制），以确保所有可能性都己考虑 在内„我们不担心生成了不适合某个属性的狹窄定义的场景——如果两个属性允许生成相同的质量属性需求，则很容易纠正冗余。然而，如果遗漏了重要的质量厲性需求，后果可 能会更严敢。
4.4实践中的质量属性场景
-般场欺提供了 -个生成大量一般的、独立于系统的、特定于质量属性的场景的框架。 每个场景都潜在地与正在考虑的系统相关，但这并不是必须的。为了使一般场景对某个特 定系统有用,必须使它们成为特定于系统的。
使.般场敖特定于系统意味着将该一般场景转换为针对特定系统的具体场筑。因此，
—般场景是“一个要求改变功能的请求到达，必须在一个指定的期间内，在开发过程的一个特定时间改变功能”。特定于系统的场景可能是“-个耍求在菡于Web的系统中增加新 浏览器支持的谪求到达，必须在2周内进行该改变”。此外，一个一般场景可能会有许多 特定子系统的场規。必须支持-个新浏览器的系统可能还必须支持一个新的介质类型。
现在，我们讨论6个最常见也是最重要的系统质量属性，目的有两个：确定质量厲性 团体所使用的概念：提供一个为该属性生成一般场景的方法。
4.4.1可用性
可用性与系统故陣及其相关后果有关。当系统不再提供其规范中所说明的服务时，就
出现了系统故陣。系统的用户（人或其他系统）可以观察到此类故陣。图4.3给出了可用 性的一般场景的示例。
可用性所关注的方面包括：如何检测系统故障，系统故障发生的频度，出现故障时会 发生什么情况，允许系统有多长时间非正常运行，什么时候可以安全地出现故障。如何防止故障的发生以及发生故障时要求进行哪种通知。
需要区分故障和错误。如果不进行纠正，错误有可能会变成故陷。也就是说，系统的 用户可以观察到故陴.怛看不到错误。当可以观察到错误时，它实际上已经变成了故障。 例如，错误可能是为某个计算选择了错误的算法，结果会导致引发系统故陣的误算。
系统出现故障后一个重要的相关概念就是修复该系统所需的时间。由于用户可以观 察到系统故障，因此，修复时间就是从出现故障到用户看不到故陣的时间。这可能是很短 的响应时间延迟，也可能是某人飞到秘鲁偏僻的山上修理一个采矿机部件所需要的时间 (该示例是由负贵修复采矿机引擎中的软件的人提供的）。
错误和故陣之间的区别为讨论自动修复策略提供了可能。也就足说，如果执行了包含一个错误的代码.但系统能够在用户未观察到该错误的情况下从错误屮恢复过来，那么， 就没有发生故陴。
系统的可用性是系统正常运行的时间比例。一般将系统可用性定义为：
从这个公式中我们得到了像99.9%的可用性、0.1 %的故障率这样的概念。
在计算可用性时，通常不考虑预定的停机时间（即停止服务），因为根据定义是“不需要”系统的。这就异致会出现这种情况：系统停止运行，用户等待系统提供服务.但因 为停机时间是预定的，因此不计入故障时间，也就不会影响可用性的数值。
可用性的一般场景。从这些因素考虑，可以了解可用性场设的各个部分，如图4.2所示。
• 刺激源。我们对错误或故障的内部和外部迹象加以区分，因为所期塑的系统响应 可能是不同的。在所给出的例子中，未曾预料到的消息来自系统外部。
•刺激.可能会发生如下某类错误。
• 疏忽..组件未能对某个输入作出响应。
• 崩溃 组件不断遭受疏忽的错误。
• 时间 绀件作出了响应，但作出响应的时间太早或太迟。
• 响应。组件用一个不正确的值作出了响应。
在图4.3中.刺激就是到达了一条未曾预料到的消息。这是时间错误的-个例子。生 成该消息的组件在一个非期望的时间生成了消息。
• 制品。这指定了要求具有极髙可用性的资源.如处理器、通信通道、进程或存储。
• 环境，当出现错误或故障时.系统的状态也会影响期望的系统响应。例如.如果 系统已经看到了一些错误，正在以非正常模式运行，邡么，可能希望完全关掉系 统。然而，如果这是观察到的第一个错误，那么，可能更希望响应时间或功能的 降级。在我们的例子中，系统在正常运行。
• 响应。在出现系统故障时.有很多可能的反应，包括记录故陣、通知选择的用户 或其他系统、切换到降级模式（容量较小或功能较少）、关闭外部系统或在修复 期间变得不可用。在我们的例子中，系统应该通知操作人员有条未曾预料到的 消息.并继续正常运行。
• 响应度置。响应度最可以指定可用性百分比，或者它可以指定修复时间，系统必 须可用的总时间以及系统必须可用的持续时间。在图4.3中，出现了未曾预料到 的消息后，没有停机时间。
表4.1给出了可用性场景的每个部分的可能的值。
4.4.2可修改性
可修改性是有关变更的成本问题。它提出了两个关注点。
(1)可以修改什么（制品〉？可以修改系统的任何方面，最常见的就是系统计算的
功能、系统存在的平台（硬件、操作系统和中间件等）、系统运行的环境（它必须与之互 操作的系统.它用于与其他部分进行通信的协议，等等）、系统所展示的质最属性（其性 能、可靠性、甚至包括将来的可修改性）以及其容量（所支持的用户数量、同时发生的操 作的数量，等等）。系统的某些部分（如用户界面或平台）可以分离出来，它们很容易发 生变化.我们将对其进行单独讨论。平台种类的变化还被称为可移植性。这些变化可能是 增加、删除或修改这些方面中的任何一个。
(2)何时进行变更以及由谁进行变更（环境）？过去最常见的是修改源代码。也就 是说，开发人员必须修改代码，对修改后的代码进行测试，然后将其部署在新版本中。然 而.现在不仅仅是何时变更的问题，而且还有由谁进行变更的问题。最终用户改变屏保很明显就是改变了系统的一个方面。同样明显的是，它与改变系统并不属于同-一类，因此可 以通过Web而非在一台机器上使用它-可以在编译期间（使用编译时切换）、构建期间（通 过选择库）、配置设置期间（通过一系列手段，包括参数设置）或执行期间（通过参数设 置）改变实现（通过修改源代码）。变更还可以由开发人员、最终用户成系统符理员进行。
指定了某个变更后，必须设计、实现、测试和部署新的实现-所有这些行动都需要时 间和资金，而这.荇都是可以度量的。
一旦指定了某个变更后，就必须设计、实现、测试和部署新的实现。所有这些活动都 需要时间和资金，可以对它们进行度最。
可修改性的一般场景。从这些考虑事项中我们可以看出可修改性的一般场景的各个部 分。图4.4给出了 一个示例：“开发人员想改变用户界面.这就需要在设计时改变代码， 并需耍在3小时内改变代码并对改变后的代码进行测试，行为中不会产生有副作用的变 化。”
• 刺激源.，这一部分规定了谁来进行改变——幵发人员、系统管理员或最终用户。 很显然.必须有一台机器供系统管理员或最终用户修改系统使用，但这是一个很 常见的事惝。在图4.4中，修改工作是由开发人员进行的。
• 刺激 这一部分指定了要进行的改变。改变可以是增加功能、修改现有功能或删 除功能。还可以改变系统的质量——使其响应更快，提高其可用性，等等。还可 以改变系统的容量。一个很常见的要求是提高同一时间所能承受用户的数量。在 我们的例了中，刺激就是请求进行修改，可以是修改功能，质量或容最。
变体是一个与软件产品线相关的概念（参见第14車)。当考虑变体时，一个因素就是必须指定给定变体的次数。与偶尔所做的改变相比，必须频繁进行的改 变对响应度量的要求更苛刻。
• 制品。这一部分指定了要对什么进行改变——系统的功能、平台、用户界面、环 境或与之互操作的另个系统。图4.4中修改的是用户界面。
• 环境,，这_部分指定了什么时候可以进行改变——设计时、编译时、构建时、启 动时或运行时。在我们的例子中.修改是在设H•时进行的。
• 响应。进行改变的任何人都必须理解如何改变，然后进行改变、测试和部署。在 我们的例子中，进行修改并没有产生副作用。
• 响应度量。所有可能的响应都需要时间和资金，因此，时间和成本是最期望使用 的度量指标。然而，时间并不总是可以预测的，因此经常使用不太理想的度量指 标，如改变的范围（受影响的模块的数据）。在我们的例+中，完成更改的时间 应该在3个小时内。
表4.2给出了可修改性场讶的每部分的可能的值。