2.4为什么说软件构架非常重要

 

第1章讨论了构架对企业的重要性。本章将从技术的角度重点讨论构架的重要性。软 件构架之所以重要，主要有以下3个基本原因：

 

(1)涉众之间的交流。软件构架是种常见的对系统的抽象，绝大多数（如果不足 全部的话）系统的涉众都以此作为彼此理解、协商、达成共识或相互沟通的基础。

 

(2)早期设计决策。软件构架是所幵发系统的最早设计决策的体现，而这些早期决 策对系统的后续开发、部署和维护具有重要影响。这也是能够对所幵发系统进行分析的最 早时间点。

 

(3)可传递的系统抽象  软件构架是关于系统构造及系统各元素工作机制的相对较 小、却又能突出反映问题的模型。这种模型可以在多个系统之间传递.特别是可以应用到 具有相似质量厲性和功能需求的系统中，并能够促进大规模的重用。

 

下面我们将详细讨论这些要点。

 

2.4.1构架是涉众进行交流的手段

 

软件系统的涉众——客户、用户、项目经理、程序员、测试人员等分别关注系统 的不同特征.而这些特征都受构架影响。例如，用户关心的是系统的可靠性和可用性：客 户关心的是构架能够在规定时间内实现，并且开支不超山预货；项目经理关心的是如果按 此构架进行开发.能否保证各小组的任务在很大程度上都独立完成.各部分的交互方式是 否规范、可控：而设计师所关心的则是实现构架的所有这些目标的策略。

 

构架提供了一种共同语言，有关各方可借助它表达和协商各自的需求并理性地找到 解决方案，即使对大型、复杂系统的开发也是如此（参见下面的引文“按下这个按钮将会 怎样”)。如果没有这样一种语言，要想充分理解大型系统并理智地做出对系统质量和易用 性都具有重要影响的早期决策将十分困难。构架分析不仅依赖于而且促进了这个层次上的 交流.第3部分将对此进行讨论。

 

 

事实上，用户确实也需要构架.在上面所给的例子中，提出问題的那位听众耐着性-听完了关于系统功能、操作.用户界面及测试的讲解。尽管他已经疲倦，想回家休息了 俾这是第一张使他意识到自己有些地方还不大清楚的关于构架的幻灯片.多次参加构架"i 审的经验告诉我、从一个新的角度对系统进行考察将使人耳目一也很容易发现一些新的问题，对于系统的用户来说，构架就是一个新的角度。 用户提出的问趙都是行为方面的 在第11章的引文“他们的解决方案无效”中，我们将介绍另外一次构架评估的情况.在那次评估会上，与系统将会怎么做相比，用户代表对系统将会做什么更感兴趣，这是很自然的 在参加这次评估会之前，用户与软件开发公司的联系都是通过经销商进行的.也就是说. 这位构架设计师是用户直接接融到的第一位有关此系统的专家，他们当然不会掛过这样的提问机会.

 

 

当然，认真.透彻的需求规范会使这种情况得到改善.但由于各种原因，并不总是能 够创建或得到这样的需求规范而如果没有好的需求规范，构架的规范就会引发类似问題、 澄清某些模糊认识.认识到这一点要比不愿看到这种情况的出现更为明智•在第丨丨章我们 将指出，构架评估的一个优点就是澄清需求并划分其优先级。

 

有时，这样的评估将揭露出不合理的需求，这样的话就要重新察看一下其效用树.这 种铎调系统需求与构架相协调的评估将会使年轻的设计师在总体评估会上做出合理的解 释，从而避免出现上文所说的炮尬情况。另一方面，用户代表也不会因提问时机不当而感 到难堪，当然，如果愿意，他尽可去投资房地产。

 

2.4.2构架是早期设计决策的体现

 

软件构架体现了对系统做出的最早的设计决策。这些早期决策的正确性最难保证，而 且在随后的幵发过程中也最难改变，它们的影响也最为深远。

 

构架明确了对系统实现的约束条件。如果系统实现遵循构架设计中所做出的关于系统 结构的决策，则系统实现将能够体现出构架的特色。这就是说，在具体实现时必须按照构 架的设计.将系统分成若干个元素，各元素必须按照设定的方式进行交互，而且每个元素也必须具有构架中所规定的外部特征。

 

资源分配方面的决策也制约着系统实现。这些决策对从亊各元素开发的实现人员来说可能是不可见的。这呰限制条件使将各方关心的问题分离开成为可能，从而使管理者能够 做出科学的决策，最大限度地利用人才和计算资源。各元素的开发者对自己所从亊的幵发 任务的耍求必须十分淸楚，但没有必要了解在构架上所做的权衡。相反，构架设计师未必 要精通算法设计或编程语言的各个方面.但必须能够做出构架上的合理权衡。

 

构架决定了开发组织的组织结构。构架不仅规定了所开发的软件系统的结构，而且也 影响着项目开发组的结构（正如在第1章所讲到的，有时会影响到整个组织的结构)。开 发大型系统时，常见的任务划分方法是将系统的不同部分交由不同的小组去完成，这就是 所谓的系统的工作分解结构。因为系统的构架中包含了对系统的最高层次的分解，因而一 般被作为工作分解结构的基础。这反过来也规定了计划、调度及预算的单元，组内交流的 渠道，配置控制和文件系统的组织，集成与测试计划和规程，甚至提出了对一些琐事的要 求（如组织内部网的方式和开发小组出去野餐的次数〉。各开发小组根据构架中各主要元 素的接口规范进行交流.，一旦进入维护阶段，维护活动也会反映出软件的结构，常由不同 的小组分别负责各具体部分的维护。

 

建立工作分解结构的一个副作用是：它限定了软件构架的某些方面。如果已经将某个 子系统的开发交由某个小组完成，则该小组会对将此任务分派给其他小组提出异议。如果 这种责任划分已经用合同的形式确定下来，则改变任务分配的代价可能是昂贵的。对分配 到各小组的任务的进展情况的跟踪也要困难得多。

 

因此，一旦对构架达成一致，不管是由于管理上的还是商业上的原因，想要对它进行 修改.几乎都是不可能的。这也是为什么在确定某个大型系统的构架之前必须进行全面分 析的原因之一。

 

构架阻止或支持系统的质量属性的实现。系统能否具有所期望（或要求）的质量属性

 

主要是由其构架决定的。第5章将详细讨论构架和质量属性之间的关系，现在仅需牢记以 下几点：

 

•    如果您的系统要求高性能，就需要管理元素基于时间的行为以及元素间通信的频 率和数据。

 

•    如果可修改性很重要，就需要给元素分配责任，以使对系统的修改不会产生很大 的影响。

 

•    如果系统必须非常安全，就需要管理和保护元素间的通信以及允许哪些元素访问 哪些信息。可能还需要在构架中引入专门的元素（如受信的内核）。

 

•   如果您认为系统需要可扩充性，就必须仔细定位资源的使用，以有利于引入容量 更高的更换组件.

•   如果项目需要交付系统的增量式子集，就必须仔细管理组件间的使用。

 

•   如果希塑可以在其他系统中重用该系统的元素，就需要限制元素间的耦合.以便 提取元素时，它能发挥作用，且不会与当前环境有过多依赖。

 

这些和其他质量厲性策略都与构架有很大关系。然而，仅靠构架也无法保证系统功能 和质量厲性的实现.现解这一点非常重要。下游设计或实现决策水平的低下往往会削弱--个本来完美的构架。在生命期所有阶段做出的决策——从高层的设计到低层的编码和实现 —都影响着系统的质量。所以，质量问题并非完全由构架决定。要保证系统的高质量， 具有完美的构架是必要的.但并不充分。

 

通过研究构架来预测系统质量。能否在系统开发和部署前就知道做出了适当的构架决 策（也就是系统是杏将表现出所期望的质量属性）？如果答案是否定的，则构架的选择就 是-项令人颇感无助的工作——用其他办法选择构架和随机选择-个构架没有什么两样。 所幸的是，仅仅依靠对构架的评估来预测系统未来的质量属性是可能的„ 一些构架评估技 巧（如第11章讲述的构架权衡分析方法）可使我们自上而下地对按某软件构架开发出来 的软件产品的质量属性做出比较准确的预测。

 

构架使推理判断和控制更改更简单。一般来说，软件系统的成本大约有80%是花费在 初次部署之后，即维护阶段，这一事实正曰益引起软件幵发团体的重视。根据这样一个统 计结果，我们可以断定：所开发的系统大部分都处在这阶段。许多（如果不是大多数） 程序员或设计师从来没有进行过新的开发一而仅是在已有代码的基础上工作。在整个生 命期内.软件系统在不断发生变化：这种变化是经常发生的，而且耍付出较高代价。

 

每个构架都将可能的更改划分为3类：本地的、非本地的和构架上的。本地更改只需 修改某一个元素就可以实现。非本地更改的实现则需对多个元素进行修改，但并不改动构 架。构架的更改会影响各元素之间交互的基本方式——即构架模式--并很可能要求系统 做全面的修改。显然，仅做本地更改是最理想的。所以，一个富有生命力的构架应该是这 样的：最有可能发生的更改也是最容易进行的更改。

 

确定何时必须更改、以什么方式更改风险最小、估计所提出的更改方案的可能影响以 及合理安排所提出的更改的实施顺序和优先级.都要求对系统的各软件元素的关系、性能 和行为有全面的了解-这都是设计师应做的工作。在构架层次上所做的椎理判断能够为制 定更改决策提供必要的洞察力。

 

构架有助于循序渐进的原型设计。一旦确定了构架，就可以对其进行分析，并将其原 型构造为一个骨架系统。这从两个方面协助开发过程的顺利进行：

 

(1)在产品生命期的早期就能得到一个可执行的系统。随着原型中的各部分逐渐被 真实系统各部分的最终实现所代替，原型的这种真实性将越来越明显地体现出来。原型的 各组成部分可能与系统的最终实现有较大差异.也可能能够比较過真地处理和产生数据。

 

(2)使系统在早期可执行的一个特例就是在产品生命期的早期确定潜在的性能问题

 

上述这两个方面都将降低项目开发的风险。如果所用的构架是若干相关构架中的一 个，则构建原型框架的成本就可以分摊到多个系统上。

 

可以通过构架进行更准确的成本和进度估计。成本和进度估计是一个重要的管理工具，它能够使管理人员获得必要的资源并了解项目开发中是否遇到了困难，与了解整个系 统相比，了解系统的某些部分本质上可以使成本估计更加准确。正如我们已经说过的，项 目的组织结构基于它的构架。与项目经理相比，每个小组都能够对其所开发的部分进行更准确的估计，并且在使估计成为现实的过程中，拥有更强烈的主人翁责任感。第二，构架 的最初定义意味着已经评审了系统的需求，从某种意义上来说，已经对需求进行了验证。对系统范围了解的越多，估计就会越准确。

 

2.4.3构架是可传递、可重用的模型

 

在整个生命期中，重用得越早，收益就越大。代码的重用能带来极大的便利.而在构 架层次上的重用则为具有类似需求的系统开发提供了有利的手段。不仅可以实现代码的重用，还可以实现决定构架选用的系统需求及构建构架的经验的重用。如果构架决策能够在 多个系统中得到使用，则也可以获得上面讲到的早期决策所带来的所有好处。

 

产品线共享一个公共的构架。软件产品线或家族是一组软件密集型系统，这些系统共 享一个公共的、可管理的特性集，满足了特定市场或任务的具体需耍，是按照规定的方式 根据一组公共的核心资产开发的。在这些核心资产中，主要部分就是设计用来处理整个家 族需耍的构架。产品线设计师通过制定在早期适用于整个家族的设计决策，以及在后期仅 适用于单个成员的其他决策，来选择-个满足产品线的所有预想成员的构架（或一个紧密 相关的构架家族）。该构架定义了对产品线的所有成员来说，什么是固定的，什么是可变 的。对多系统开发来说，软件产品线是一种强大的开发方法，它可以在上市时间、成本、 生产率和产品质量方面实现极大的回报。构架的强大源于范例的核心。与其他资本投资类 似，产品线的构架将成为开发组织的核心资产。第14章对软件产品线进行了分析’第15 章和第17章给出了产品线的案例分析。

 

系统开发可以使用大型的、由其他组织开发的元素。以前的软件范例总是将编程作为 最根本的任务.把编写了多少行代码作为衡量项目进展情况的依据。基于构架的幵发则更 强调对各元素的组合或装配，而这些元素很可能已分别甚至是完全独化地开发实现了。由 于构架定义了可以集成到系统中的元素.因此，这种组合是可能的。构架从元素与环境的 交互、对控制的接收和释放、所能使用或产生的数据、访问数据的方式、通信方式以及用 于通信和资源共享的协议等方面对可能做的更换（或添加）做了种种约定。

 

元素结构、接口和操作概念的组织是构架的一个重要方面。互换性是这种组织的最重

要的原则。1793年.Eli Whitney遵循零件可互换的原则制造了大批设的火枪，成为工业 化生产的前奏。而在能够保证物埋测量的可靠性之前，这想法令人生畏。现在，在软件 开发领域，如果不能对抽象做出严格的界定，这种结构上的互换性同样是具有重要意义但 又令人生畏的。

 

商业组件、子系统、兼容的通信接口都是基于互换性原则的。然而，在这种通过组合 进行的软件开发中，还有不少其他问题有待解决。如果准备装入或重用的组件是按照相互冲突的构架假设开发的子系统.则装配工作将会非常复杂，这会增加功能集成所需要的工 作量,，David Garlan和其同事用“构架不匹配”来描述这种情况,

 

少就是多：限制选择范围是值得的„随着所积累的构架模式和设计模式越来越多.我 们将会越来越淸楚地认识到：虽然计算机程序可以以近乎无限的方式来组合，怛涉及到程 序的协调和交互时，有意识地限制在一定范围内选择将使我们受益匪浅。也就足说，我们 希望使所构造系统的设计尽可能简单。这种方法的优势包括：重用程度更商、更易于理解 和交流的简单规范的设计、更为透彻的分析、更短的选择时间、更强的可互操作性。

 

软件设计的特性来自于构架模式的选择。那些更适用于某个特定问题的构架模式将改 善设计方案的实现.这可能通过更轻松地在相互冲突的设计要求之间进行权衡、提高对设计 环境的认识和/或使需求描述中的不一致性更为突出等方式体现出来。

 

系统构架与软件构架

 

在过去的5到10年中，我们在很多场合对软件构架进行了讨论.每次总会有人提出如 下问趙：为什么谈论软件构架？系统构架是否同软件构架一样重要？或者说软件构架和系 统构架之间的区别是什么？

 

实际上，下面我们将会看到，它们之间几乎没有差别、但我们经常谈论软件构架，因 为我们想强调设计师所做出的关于总体产品质量的软件决策的关彼特性.

 

在创建软件构架时，通常很少考虑系统.例如，如果您想让构架具有很高的性能，就 需要了解该系统将运行的硬件平台的物理特性（CPU速度.内存、磁盘存取速度）以及该 系统将与之交互的任何设备的特性（传统的I/O设备、传感器和激励器），您通常还会关注 网络的特性（主要是带宽）.如果您希望构架具有很高的可靠性，也需要关注硬件，在这 种情况下就是关心其故障率和冗余处理或网络设备的可用性.如此等等，不一而足„设计 师很少考虑硬件.

 

因此，设计软件构架时，大概需要考虑整个系统的硬件和软件，否則就是蛮千„当

仅规定了系统的一部分时，任何一个工程师都不可能预测系统的特性.

但我们主要谈论的仍然是软件构架而非系统构架。这是为什么呢_?因为大多数设计师 在牧件方面都可以做出选择，而在硬件方面則没有这种自由。这并不是说不需要做出硬件

选择，而是这可能已经不在设计师的控制范围之内（例如，创建需要在与Internet相连的任 何客户机上运行的系统)，或由其他因素规定（由于经济原因.法律问題或需要符合标准)； 或者它们很可能会随着时间的推移发生变化.

 

基于上述原因，我们认为把重点放在构架的软件部分是合理的，因为这是制定最基本 决策的地方，在这里软件设计师有很大的自由，并且有很大的成功或失敗的可能.

——RK

 

构架使基于模板的开发成为可能。构架体现了关于元素交互方式的设计决策。这些决 策虽然是在每个元素的实现中体现出来的，但却能够局部化，只需编写一次即可。可以在 某处用模板将元素间的交互机制描述淸楚。例如，可以用模板实现对某元素存放结果的公 共区声明的编码或者对元素与系统可执行程序交互时所遵循的协议进行编码。第8窣将 讨论一个支持基于模板的开发的一组构架决策的例子。

 

构架可以作为培训的基础。在对项目新成员介绍所开发的系统时.可以首先介绍系统 的结构，以及对组件之间如何交互从而实现系统需求的高层次的描述-我们曾经指出.软 件构架的重要用途之一就是支持并促进各涉众之间的交流.这进-步印证了我们的观点。 构架是一个公共的参考点。

 

2.5构架结构和视图

 

神经科专门医师、整形医师、血液学家和皮肤科医生对人体结构有一个不同的视图。 眼科专家、心脏病专家和足病医生研究治疗的逛身体的某-部分。运动学家和精神病学家 关注的是整个人体行为的不同方面。尽管这些视图是不同的并且具有差异巨大的属性.但 它们都具有内在的相关性：它们共同描述了人体的结构。

 

软件也是如此。现代系统非常复杂，很难一下子领会它们。相反，在任何时刻，我们 只能把注意力放在软件系统的-个或儿个结构上。为了有意义地传达构架的信息，必须说 明此刻讨论哪个或哪些结构~一即采用的是构架的哪个视图。

 

在讨论构架表示时.我们将使用相关术语结构和视图、视图是构架元素的内聚集的表示，由系统涉众编写和阅读。它由一个元素集的表示和元素之间的关系绀成。结构是元素 本身的集合，它们存在于软件或硬件中。例如,模块结构是系统的模块和其组织的集合。 模块视图是该结构的表示，由某些系统涉众编档和使用。这些术语通常可互换使用，但在 此我们区别使用这些定义。

 

大体上可将构架结构分为3组，这取决于它们所展示的元素的主要特性。

 

• 模块结构。此处的元素是模块，它们是实现单元。模块表示一种考虑系统的基于

代码的方法。模块被分配功能责任区域。这不怎么强调所开发出来的软件如何在 运行时表现自己。模块结构能够使我们回答诸如此类的问题：分配给每个模块的 主要功能责任是什么？允许模块使用的其他软件元素是什么？它实际使用的其 他软件足什么？什么模块通过泛化或特化（也就是继承）关系与其他模块相关？

 

•    组件-连接器结构。此处的元素为运行时组件（它们是计箅的主要单元）和连接 器（它们是组件间通信的工具）。组件-连接器结构帮助回答了诸如此类的问题： 什么是主要的执行组件，它们如何交互？什么是主要的共亨数据存储？复制系统 的哪些部分？数据在系统中经过了哪些地方？系统的哪些部分可以并行运行？ 在系统执行时.其结构可能会发生怎样的变化？

 

•    分配结构,，分配结构展示了软件元素和创建并执行软件的一个或多个外部环境中 的元素之间的关系。它们回答了诸如此类的问题：每个软件元素在什么处理器上 执行？在开发、测试和系统构建期间，每个元素都存储在什么文件中？分配给开 发小组的软件元素是什么？

 

这3种结构与构架设计所涉及的3大类决策一致：

 

•系统如何被组织为一个代码单元集合（模块）的？

 

•系统如何被组织为一个具有运行时行为（组件）和交互（连接器）的元素集合的？

 

•系统如何与其环境中的非软件结构相关（也就是CPU、文件系统、网络和开发小 组等）？

 

2.5.1软件结构

图2.3展示了一些最常见和最有用的软件结构.下面的小节将对这些结构进行描述。

模块基于模块的结构包括如下内容。

 

•分解.这些单元是通过“是一个子模块”关系将彼此关联起来的模块，展示了如 何将较大的模块递归地分解为较小的模块，直到它们足够小，很容易理解为止。 该结构中的模块代表了设计中一个常见的起点，因为设汁师列举了软件的单元必 须做什么工作.并把每个项目分配给模块以进行随后的（更详细的）设计和最后 的实现。模块通常有关联的产品（也就是接口规范、 代码和测试计划等）。通过确保很可能会发生的变化最多只在几个小模块中，分解结构提供了很大.部分的 系统可更改性。通常将其用作开发项目的组织的基础，包括分解结构、其集成和 测试汁划。该结构中的单元通常具有特定于组织的名称。例如，某些美国防部 标准定义了计算机软件配置项目（Computer Software Configuration Item’ CSCI) 和计算机软件组件(Computer Software Component. CSC),它们是模块化分解的 单元。在第15章中，我们将看到系统功能分组和作为分解单元的系统功能。

 

•使用。这一重要但是结构经常被忽略的单元也是模块，或者是过程（在能够保证 更细粒度的情况下），或者是模块接口上的资源。这些单元通过“使用”关系彼 此相关。如果一个单元的正确性要求另一个单元提供正确版本的话（与占位程序 相对)，那么我们称第一个单元使用第二个单元。使用结构用于设计可以轻松扩 展以添加功能的系统，或从中可以轻松提取有用功能子集的系统。轻松提取工作 系统的子集的能力允许进行增量式幵发。增量式开发是一种强大的开发规范，第 17章将对其进行讨论。

 

•分层，当以一种特定的方式小心地控制该结构中的使用关系时，就出现了由层组 成的系统，在该系统中，一个层就是相关功能的一个一致的集合。在一个严格分 层的结构中.第n层可能仅使用第n-1层提供的服务。然而，在实际情况中这（以 及该结构限制的减少）可能会出现许多变体。通常把层设计为将下层的实现细节 对上面的层隐藏起来的抽象（虚拟机)，从而形成了可移植性。第3萆、第13章 和第15萆的案例分析中将讨论有关层的内容"

 

•类或泛化。该结构中的模块单元被称为类。关系足“继承自”成“是.个实例”。 可以根据该视图推断出类似行为或能力（也就是其:他类所继承的类）的集合，以 及通过划分子类所捕获的参数化的差别。类结构能够使我们对重用以及功能的增量式增加进行推断。

 

组件-连接器。这些结构包括如下内容。

 

•进程或通信进程  像所有的组件-连接器结构一样，该结构与基于模块的结构是正交的，它处理的是运行系统的动态方面。此处的单元为通过通信、同步和/或排除操作将彼此相连的进程或线程•在该结构中（而且在所有的组件-连接器结构 中）的关系是“附加”，展示了组件和连接器是如何连接在--起的。进程结构非 常瞰耍，它有助于设计系统的执行性能和可用性。

 

•并发。该组件-连接器结构能够使设计师确定并行的机会以及可能出现资源争用 的位S。单元是组件，连接器是“逻辑线程”。逻辑线程是一系列计算，可以将 这些计筘在稍后的设计过程中分配给申独的物埋线程。并发结构在设计的早期使 用，以确定管理与并发执行相关的问题的需求。

 

•共享数据或存储库。该结构由创建、存储和访问持久数据的组件和连接器组成。 如果实际上系统是根据一个或多个共享数据存储庳构述的.那么，该结构就适于 进行说明。它展示了运行时软件元素如何产生数据和使用数据，可以使用该结构 确保良好的性能和数据完整性。

 

•客户机-服务器如果系统被构建为-组彼此协作的客户机和服务器，那么，这 就足.个很好的进行说明的组件-连接器结构。组件是客户机和服务器，连接器 是协议以及它们共享来执行系统工作的消息。这对于关注点分离（支持可修改 性)、物玴分布和负载平衡（支持运行时性能）都是有用的。

 

分配》分配结构包括如下内容。

 

•部署部署结构展示了如何将软件分E给硬件处理和通信元素。元素是软件（从 组件-连接器的观点看通常是进程）、硬件实体（处理器）和通信路径。关系是“分 配给”和“移植到”，前者展示了软件元素所驻留的物理单元，后者的条件是分 配是动态的。该视图能够使工程设计人员对性能、数据完整性、可用性和安全性 进行推断。在分布式或并行系统中，我们尤其对部署结构感兴趣。

 

•实现该结构展示了软件元素（通常是模块）是如何映射到系统开发、集成或配 置控制环境中的文件结构上。这对于开发活动和构建过程的管理非常关键。

 

•工作分配。该结构将实现和集成模块的责任分配给适当的开发小组。拥有作为构 架.部分的工作分配结构，可以使关于谁做该工作的决策具有管理上的和构架上 的两层含义变得很淸晰。设计师应该知道对每个小组的技术耍求。同样，在大规 模的多源分布式开发项目上，工作分配结构是调出功能公共的单元并把它们分配 给莱个小组的手段，而非让需要它们的每个人去实现。

 

表2.1对软件结构进行了总结。该表列出了每个结构中的元素及其关系的含义.并说 明了毎种结构可能会用于什么情况。

 

尽管我们通常从功能的角度理解某个系统的结构，但除了功能外，还奋必须在构架层 次上考虑的系统厲性.如物理分布、进程通信和同步。每种结构都提供了一个对某些相关质量厲性进行推断的方法。例如，必须对使用结构进行设计（而不仅仅是记录），以构建 -个可以轻松扩展或收缩的系统。进程结构设计用于消除死锁并减少瓶颈-模块分解结构 设计用于产生可修改的系统，等等。每种结构都为设计师提供了 一个考察系统的不同的角 度，并为设计权衡提供了不同的支点。

 

2.5.2将结构彼此关联在一起

 

在这些结构中，每种结构都提供了关于某一系统的不同的考察视角和设计句柄，而且 从各自的立场上看，甸个结构都是有用而且有效的。尽管这些结构提供了不同I的考察系统 的视角，但它们不是独立的。-个结构的元素与其他结构的元素相关，我们需要对这些关 系进行推断。例如，分解结构中的一个模块可以表现为组件-连接器结构中的一个或几个 组件.或一个组件的一部分，这反映了其运行时第二自我（alter ego)。-般而言，结构之 间的映射为多对多。

 

单个项目有时会把种结构作为主要结构，并在可能的情况下.根据该结构考虑和运 用其他结构。主要结构通常是模块分解.但并不总是如此。这是有充足理由的：它容易与组织的项目结构吻合。第4章所描述的场景对于使用一个给定的结构以及它与其他结构的 联系是有用的。例如，想要改变系统的客户机服务器结构的软件工程师需要考虑进程和 部署视图.因为客户机-服务器机制一般会涉及进程和线程，物理上的分布性则意味着可 能采用了不同于单机环境的控制机制。如果需要改变控制机制，则需要考虑模块分解或分 层视图.以确定变化的范围。

 

并不是所有的系统都霈要在构架上采用多种结构。系统越大，这些结构之间的差别就 越大：然而对于较小的系统，有少数几个结构通常即可满足要求。在有几个组件连接器 结构时，我们不是把每个结构都用上.一个即可满足要求。如果只有一个进程，那么，在 设计中显然没必要考虑进程结构。如果没有分布式的特征（也就足说，仅有一个处理器)， 那么，部署结构就没有什么价值，不需要做进一步考虑。

 

结构代表了构架的主要工程设计平衡点。单个结构赋予了它们处理一个或多个质量属 性的能力。它们代表了一个用于创建构架（在稍后将用于分析构架和向涉众解释构架）的 强大的关注点分离方法。在第9章我们将看到，对于构架编档的基础来说，设计师选择作 为工程平衡点的结构也是主要的候选者。

 

2.5.3选择哪些结构

 

我们己经简要描述了许多有用的构架结构，还有很多其他的构架结构。设计师应该使 用!哪些结构？设计师应该把哪些结构编成文档？当然.肯定不是使用所有的结构并把所有 的结构编成文档。

 

这方而有很多建议。1995年,Philippe Kruchten发表了一遍很有影响力的论文[Kruchtcn 95].在这篇论文中.他描述了由单独的结构组成的构架的概念，并建议把蜇点放在4种 结构上.为了验证这些结构彼此并不冲突，在实际应用中能够相互协作，他描述了一个满 足其需求的系统。Kruchten建议使用关键的用例进行检査。这一所谓的“4+1”方法变得 非常流行，现在已经成为Rational统一程的概念基础。

 

•逻辑的  元素为“关键的抽象”，在面向对象中表示为对象或对象类。这是一个 模块视围。

 

•进程。该视图解决了功能的并发和分布问题。这是一个组件-连接器视图。

 

•开发。该视阁展示了软件模块、库、子系统和开发单元的组织。它是一个分配视 图.将软件映射到了开发环境中。

 

•物理的,该视图将其他元素映射到了处理和通信节点上，它也是一个分配视图（有 些人把它叫做部署视图）。

 

几乎在Kruchtcn发表论文的同一时间，Soni. Nord和Hofineistcr共同发农了另一篇非

常有影响力的论文[Soni 95】。在这篇论文中，他们报告了其所在组织中的软件设计师在许 多项H中使用的结构。他们的视图是概念上的模块互连、执行和代码。这些视图再一次淸 晰地映射到模块、组件-连接器以及分配模型上。

 

后来，其他作者又相继发表了多篇论文，因此有很多可用结构。当然，尽管大多数结 构实际上都存在于您正在构建的系统中，但不应该使用所有结构。相反，设计师的职责之 就是理解各种结构如何帮助实现质量属性，然后选择能够最佳地提供这些质量属性的结 构。第9章将在构架表述部分对此进行较为详细的描述。

2.6小 结

本章给出了软件构架的定义，并介绍了参考模型、参考构架和构架模式的相关概念。 本章也从旱期研究对系统的认识、构架对各涉众相互沟通的影响以及作为一种可重用资产 的价值等方面，解释了构架在软件工程领域的重要意义。我们将在后续审节中进-步讨论 这些问题。

 

我们所给出的构架定义明确指出系统是由多种结构构成的.并对其中最常见的一些结 构进行了解释.阐述了在设计过程中各种结构所起的权衡支点的作用。

 

下一章将给出本书中的第-•个案例分析，目的足说明在开发较为s杂的系统时，构架 的各种不同结构所起的重要作用。

2.7可进一步参阅的文献

 

David Pamas的开创性工作为现在的软件构架研究奠定了理论杣础（见下而的引文“构 架领域的似曾相识之感”)。想要进一步研究Pamas工作成果的读者应参阅Pamas关T•信息 隐藏的欺耍论文[Pamas 72]、关于程序族的论文[Pamas 76]、关于软件系统的内在结构 的论文[Pamas 74]和利用使用结构创建系统子集或超集的论文[Pamas 79]。所有这些论 文都收集在了饨重要的论文集[Hoffman 00]中。

 

软件构衆模式 Li经在 Pattern-Oriented Software i4/rA<7ec7«re[Buschmann 96, Schmidt 00] 中进行了广泛分类。

 

在工业开发项目中使用的构架视图的早期论文为[Soni 95]和[Kmchten95]。前一 篇论文已经被编辑成书[Hofmeister 00],该书给出了在开发和分析中使用的全|fi丨视图：后 者己发展成为Rationa丨统一过程，在网上和出版物上，有很多关于Rationa丨统过程的参 考资料。[KruchtenOO]就非常不错。

 

2.8讨论题

(I)我们经常将软件构架和建筑结构进行比较。这种比较有什么意义？在建筑结构上， 与软件构架的结构和视阁相对应的是什么？是模式吗？这种比较苻什么+足？在什么情 况下就不能再进行这种比较了？

 

:(2)参考构架和构架模式有什么区别？从组织规划和构架分析这两个方面看，两者有 何区别？

 

' (3)您的绀织中所用的构架是否注零了构架各视图（即结构及其关系）的区别？如果 注意到了，都是什么视图？如果没有注意到，原因是什么？

 

(4)你还熟悉软件构架的其他定义吗？如果有的话，按照我们提出的对构架定义的要 求考察•下这个定义：是否在抽象过程中舍弃了系统的-些信息但仍能为分析、决策制定 和降低风险提供可雅的信息越础？