与Linda Northrop共同撰
如果一个项目的系统构架（包括理论基础）尚未确定，就不应该进行此 系统的全面开发.只有对构架做出明确清楚的表述，才能使之在整个开 发和维护过程中加以充分利用.
-Barry Boehm [Boehm 95]
上-节阐述了构架在保证开发组织实现其商业目标方面所起的重要作用。构架的开发 需耍付出一定的成本（精心设计的成本），但它能使开发组织达到自己的系统目标并提高 其软件开发能力，这种回报是相当丰厚的。对开发组织而言.构架是一种极重要的资产 其作用超出所开发的项目本身。
本章我们将严格地从软件工程的角度对构架进行讨论，即除了第丨章中所讲到的企业 所获得的价值外.我们还将研究软件构架对项目开发的重要怠义。
2-1软件构架概念的澄清
阁2.1取自某水下声学模拟系统的系统描述，我们用它来说明最抽象的构架的概念。 实际上这种图在解释构架时经常使用。从该图中究竟可以得到哪些信息呢？
•系统由4个元素组成。
*其中的3个元素-即特征损失模型（MODP)、回响模型（MODR)和噪音模型
(MODN)-可能有更多的相似之处，而与第4个元素-即控制处理(CP)_
可能有较大差异.因为这3个元素在图中处于同一层次。
•该围是完全连通的，因而所有4个元素之间显然都有某种联系。
这就是构架吗？如果构架真的是由若干（这里是4个）组件及其之间的相互联系（这 里也表示出来了〉组成（很多关于构架的定义都是这样假设的），则用这样的图就足以表 述构架。但是，即使接受这样一个最原始的定义，从这样的图中仍然无法知晓哪些信息？
•这些元素的实质是什么？划分成这样的元素有何意义？它们是否能运行在不同的 处理器上？从运行时间上看，又是否相互独立？这些元素是由进程还是由程序组 成.或者是两者兼而有之？这些元素足否反映了开发项目任务的划分？它们是否 表示了运行时独立性？这些组件是对象、任务、函数、进程、分布式程序，还是 其他？
•元素的职责是什么？它们在系统中做什么？在系统中的功能是什么？
• 图中的这些连线代表什么意义？这些连接是表示这些元素相瓦通信、相互控制、 相互发送数据、相互利用、相互调用、保持同步、彼此之间共享一些信息隐藏秘 密，还是上述及其他关系的组合？这种相互通信又是借助什么机制实现的？在机 制之间流动的可能是什么信息？
• 各个元素在图中的分布表示什么意义？为什么CP单独在一个层次上？是不是CP可以调用其他元素而反之则不可？是不是仅仪因为受版面空间的限制而没有将这 4个元素排成一行？
我们必须提出上述问题，因为除非准确地知道元素是什么，知道它们如何协作来实现 系统的目的，否则这样的图就没有什么帮助，也没有必要认真分析它了。
2.1并不是某个软件构架的完整描述，至少它所描述的这个构架并不实用。顶多只 能说这种图是构架描述的开始。下面我们给出软件构架的确切定义：
某个软件或计算系统的软件构架是该系统的一个或多个结构，它们由软件元素、这些
元素的外部可见属性以及这些元素之间的关系组成.。
这里所说的某个元素的“外部可见属性"是指其他元素对该元素所做的假设，如它所 提供的服务、性能特征、错误处理、共享资源的使用，等等。下面我们深入阐述一下该构 架的含义。
首先，构架定义了软件元素。构架中包含了关于各元素应如何彼此相关的信息。也就 是说，构架必须省略各元素中与其交互无关的某呰信息。因此，构架首先是对系统的抽象， 该抽象去除了不影响它们如何使用、其他元素如何使用以及如何与其他元衮关联或交互的 细节。在几乎所有的现代系统中，各元素是通过接口实现交互的，而这些接口又将各元素 的细节划分为公有和私有两大类。根据这种划分.构架属于公有部分，而私有部分——即 仅与内部具体实现有关的细节一是不属于构架的。
第二，该定义明确指出系统可能而且确实由多个结构组成，而且，其中仟何一个结构 并不能与构架等同。例如，所有的大型项目都要被划分为实现单元；这些单元被分配具体 的贵任，它们通常是为编程小组分配仟务的基础。这种类型的元素既包括可以由其他实现 单元中的软件调用或访问的程序和数据，又包括私有的程序和数据。在大沏项目中，几乎 肯定会对这些元素进行细分，以交给更小的开发小组完成。这是在描述系统时经常使用的一种结构。这种结构侧重于对系统的功能进行划分并分配给实现小组，从这-点来说，它 是非常固定的。
其他结构更侧重于元素彼此之间在运行时交互，以执行系统功能的方式。假定该系统 被构建为一组并行进程。将在运行时存在的进程、以前描述的各种实现单元中的程序（它 们按顺序排成一列，形成每个进程）和进程间的同步关系组成了另一种通常用来描述系统 的结构。
是不是其中的某种结构就是构架呢？尽管这些结构传达了构架信息，但答案仍然是否定的。构架中包括这些结构，并且还可能包括其他结构。上述例子说明.既然构架可能包 括多个结构.就可能有多种元素（例如实现单元和进程)，各元素间的交互关系也可能有 多种（例如细划分和同步)，甚至还可能有多个上下文环境（例如开发时间和运行时间）。 在所给的定义中，我们特意未指明构架的各元素和相互关系的具体内容。软件的组件到底 是对象、进程、函数库、数据库还是商业产品？可以是其中的任何一个，也可以是其他内容。
第三， 该定义意味着具有软件的每个计算系统都有一个软件构架.这是因为每个软件 系统都可以看作是由若干个元素及其相互联系构成的。在最简单的情况下，我们可以把 一个系统看作是一个元素。虽然仅有一个元素的构架没有多大价值，而且也不实用，但它符 合我们的定义。每个系统都有构架，但这并不意味着任何人都知晓该构架的存在。或许当
时参与设计某个系统的所有人员都已故去，文档已经不存在了（或根本就没有将其编成文 档〉，源代码己经丢失（或根本就未发布过).我们所能得到的就是可执行的机器代码。这 就是系统构架和对构架具体表述的区别。遗憾的是.构架可以独立于对构架的描述而存在， 这也让我们更加认识到构架编档（将在第9章描述）和构架重构 （将在第10葶描述）的重要性。
第四，只耍某个元素的行为可以从其他元素的角度观察到或区别开，这个元素的行为 就是构架的内容。正是这种行为的存在，才使各元素的交互成为可能，而这种交互敁然是 构架的一部分。这是被当做构架的框线图其实根本就不是构架的另一个原因。它们只是框 线图，提供了所展示的元素做什么的更多信息。当看到这些框线图中某个框（数据库、图 形用户接口、可执行代码等）的名字时，读者很可能会设想相应元素的功能和行为。与框 线图相比，这种想象更接近于构架，但这种想象来自于读者的思维，依赖于某些在框线图 中并未表示出来的信息，这并不是说在各种情况下都要对各元索的行为和性能给出輔确的 描述，但如果某个元素的行为对与之交互的另一个元素的代码编写有特定的要求，或者影 响到整个系统的可接受性，则该行为就是软件构架的部分。
最后，我们所给的这个定义并不涉及对构架优劣的评价.这意味着构架将支持或阻止 系统满足其行为、性能和虫命期需求。我们并不把试错法——即任怠选用一个构架，在该 构架之上展开系统的开发.并期望得到理想的结果——当作为系统选杼构架的最佳方法， 因此，这就提出了构架评估（第11章）和构架设计（第7章）的重要性。
2.2其他观点
软件构架在不断发展.但它仍然是一个尚不成熟的学科；因此.它没有一个统-的、 公认的定义。另一方面，目前有很多关于软件构架的定义。大多数常见的定义的要点都是 -致的——结构、元素以及元素之间的关系——但它们在细节上有很大不同.不能互换。 通过研究设计人员所遵循的设计规范以及他们在开发实际系统时所采取的行动，对软 件构架的研究得以不断发展。对系统设计中内在的共性进行抽象是一种尝试。由此它必须 说明各种活动、概念、方法、途径和结果。鉴于此.软件工程团体中存在其他构架定义： 因为您很可能会遇到其中的一些定义，因此应该理解这些定义的含义外能够对其进行讨 论-下面是几个最常见的定义。
• 构架是一种高层设计。从马是哺乳动物这个意义上来说，这种说法是正确的I但 反过来说就不对了。与设计相关的其他任务并不是属于构架.如确定将要封装的 重耍的数据结构。访问数据结构的接口肯定属于构架的范畴，但实际做出的选择却不是。
•构架是系统的总体结构。这个常见说法（不正确地）暗含的意思是系统只有一个 结构。我们知道这种说法是错误的，如果有人持这种观点，不妨问问他所说的结 构到底指什么。这种观点不仅仅具有教学上的重要性。后面我们将会看到，不同的结构提供了 一个关键的工程设计平衡点，这些平衡点使系统中具有了导致系统 成功或失畋的质量属性。构架中结构的多样性位于概念的核心。
•构架是一个软件或系统的组件、组件之间的相互关系以及管理其设计和演变的原 理和方针的结构。这是许多以过程为中心的定义中的一种，其中包括诸如原理和 指导方针这样的辅助性信息。许多人声称构架中包含对涉众需要以及如何满足这 些需要的基本原理的陈述。我们也认为收集此类信息是基本的，它是一种很好的 专业实践。然而，从本质上说我们并不把它们作为构架的一部分。正如我们并不 把汽车所有者的手册作为汽车的一部分一样。任何系统都有一个构架，并且可以 独立于设计或演变该构架的过程的知识对其进行探索和分析。
•构架是组件和连接器.连接器是指系统运行时为传送控制和数据信息而采用的机 制。因此.该定义主要强调了系统运行时的构架。例如.UNIX管道就是.个连 接器。这使得非运行时构架结构（如以前讨论的静态划分为实现的责任单元）成 为第二类结构。它们不是第二类结构，它们对满足系统目标都至关重要-当提及 元素间的“关系”时，我们的目的是捕获运行时和非运行时这两个关系。
关于软件构架所做的各种讨论的实质就是对软件系统的结构问题的关注。尽管构架有 时用来衣示某种构架模式（如“客户机/服务器构架”)，有时用来表示某一研究领域（如 “一本关于构架的书”），但最常见的情况是用它来描述某个特定系统的结构特点。这也 正是我们试图在定义中所强调的。
2.3构架模式、参考模型和参考构架
在框线骨架和已经填充了关于系统的所有适当信息的构架之间，有很多中间阶段。每 个阶段都是执行一组构架决策的结果。其中的一些中间阶段是非常重要的。在讨论构架结 构前，我们先给出以下3个定义：
(1)构架模式是对元素和关系类型以及一组对其使用方式的限制的描述。可以把构
架模式揞作是对构架的一组制约条件-即对各元素类型及其交互模式的眼制条件。而这
些制约条件就确定了一组或一系列能满足它们的构架。例如，客户机/服务器就是一种常见 的构架模式。客户机和服务器分别对应于两种不同的元素类型，它们之间的协同是用服务
器与其各客户机通信时所遵守的协议来表述的。使用“客户机/服务器”这个名词仅意味着 存在多个客户机，对客户机本身并没有做出任何限制.也没有明确客户机或服务器各自的 功能（除了通倍协议中约定的之外)。按照这种（非正式的）定义，符合客户机/服务器模 式的构架很多，但它们各不相同。所以，构架模式并不等同于构架，但它传达了一些有价 值的系统信息，对构架（及系统）做出了必要的约束。第5章将详细讨论构架样式的相关 问题.，
模式最有用的一个方面就是它们展示了已知的质量属性。这就是为什么设计师选择某 个特定的模式.而不是随机选择模式的原因。一些模式代表了性能问题的已知解决方案， 一些模式适用于高安全性系统，还有一些模式成功应用在了髙可用性系统中。选择构架模 式通常是设汁师做出的第-个主要的设计决策。
术语构架样式的使用也非常广泛，它用于描述相同的概念。
(2)参考横型是一种考虑数据流的功能划分。参考模型是对已知问题的标准分解， 分解所得的各个部分相互协作，构成问题的解决方案。产生于实践经验的参考模型是熟知 某个领域的体现。你能说出编译器或数据库管理系统的标准部件吗？你能解释一下这些部 件是如何相互协作实现整体目标的吗？如果答案是肯定的，很可能你曾经学习过这些应用 的参考模型。
(3)参考构架是映射到软件元素（它们相互协作，共同实现在参考模型中定义的功
能）及元素之间数据流上的参考模型。参考模型实现了功能划分，而参考构架则将这种功
能划分与系统分解对应起来。这种对应可能（但不一定必须）是一一映射。一个软件元素 可以实现某个功能的一部分，也可以实现若干个功能。
参考模型、构架模式和参考构架都不是构架.但它们都是捕获构架元素的有用的概念。 这三者都是早期设计决策的产物。图2.2给出了这些设计元素之间的关系。
人们经常拿构架这个词与该词的其他用法进行类比，他们对这些用法有更多认识。他 们经常将构架与某些物理结构（建筑物、街道、硬件）或物理分布联系在.起。建筑设计 师在设计大楼时必须要考虑方便性、美观、光照、可维护性等方面的要求。软件设计师在
设计中也必须考虑并发性、可移植性、可修改性、易用性、安全性等因素，并且要在这些 需求之间进行适当的权衡。
建筑设计和软件设计之间的这种类比是不能深究的.否则我们将很快注意到它们之间 的明显差异。但这种类比确实能够帮我们认识到“观察者”的角度是重要的，并且结构随考察的目的不同而具有不同的含义。对软件构架定义的严格表述并不像我们对此概念真正 含义的考察那样重要。