软件构架概念的澄清      下面我们给出软件构架的确切定义： 某个软件或计算系统的软件构架是该系统的一个或多个结构，它们由软件元素、这些元素的外部可见属性以及这些元素之间的关系组成。 这里所说的某个元素的“外部可见属性”是指其他元素对该元素所做的假设，如它所提供的服务、性能特性、错误处理、共享资源的使用，等等。下面我们深入阐述一下该构架的含义。

1. 构架定义了软件元素。构架中包含了关于各元素应如何彼此相关的信息。也就是说，构架必须省略各元素中与其交互无关的某些信息。因此，构架首先是对系统的抽象，该抽象去除了不影响它们如何使用、其他元素如何使用以及如何与其他元素关联或交互的细节。在几乎所有的现代系统中，各元素是通过接口实现交互的，而这些接口又将各元素的细节划分为共有和私有两大类。根据这种划分，构架属于共有部分，而私有部分--即仅与内部具体实现有关的细节--是不属于构架的。
2. 该定义明确指出系统可能而且确实由多个结构组成，而且，其中任何一个结构并不能与构架等同。
3. 该定义意味着具有软件的每个计算系统都有一个软件构架，这是因为每个软件系统都可以看做是由若干个元素及其相互联系构成的。在最简单的情况下，我们可以把一个系统看做是一个元素。虽然仅有一个元素的构架没有多大价值，而且也不实用，但它符合我们的定义。每个系统都有构架，但这并不意味这任何人都知晓该构架的存在。或许当时参与设计某个系统的所有人员都已故去，文档已经不存在了（或者根本没有将其编成文档），源代码已经丢失（或根本就没发布过），我们所能得到的就是可执行的机器代码。这就是系统构架和对构架具体表述的区别。遗憾的是，构架可以独立于对构架的描述而存在，这也让我们更加认识到构架编档和构架重构的重要性。
4. 只要某个元素的行为可以从其他元素的角度观察到或区别开，这个元素的行为就是构架的内容。这是这种行为的存在，才使各元素的交互成为可能，而这种交互显然是构架的一部分。这是被当作构架的框线图其实根本就不是构架的另一个原因。它们只是框线图，提供了所展示的元素做什么的更多信息。 这并不是说在各种情况下都要对各元素的行为和性能给出精确的描述，但如果某个元素的行为对与之交互的另一个元素的代码编写有特定的要求，或者影响到整个系统的可接受性，则该行为就是软件构架的一部分。

     最后，我们所给的这个定义并不涉及对构架优劣的评价，这意味着构架将支持或阻止系统满足其行为、性能和生命期需求。我们并不把试错法--即任意选用一个构架，在该构架之上展开系统的开发，并期望得到理想的结果--当作为系统选择构架的最佳方法，因此，这就提出了构架评估和构架设计。

其他观点      大多数常见的定义的要点都是一致的--结构、元素以及元素之间的元素--但它们在细节上有很大不同，不能互换。对系统设计中内在的共性进行抽象是一种尝试，由此它必须说明各种活的、概念、方法、途径和结果。鉴于此，软件工程团体中存在其他构架定义：因为您很可能会遇到其中的一些定义，因此应该理解这些定义的含义并能够对其进行讨论。下面是几个最常见的定义。

• 构架是一种高层设计。与设计相关的其他任务并不是属于构架，如确定将要封装的重要数据结构。访问数据结构的接口肯定属于构架的范畴，但实际做出的选择却不是。
• 构架是系统的总体结构。 这个常见说法（不正确地）暗含的意思是系统只有一个结构。我们知道这种说法是错误的，如果有人持这种观点，不妨问问他所说的结构到底是什么。这种观点不仅仅具有教学上的重要性。后面我们将会看到，不同的结构提供了一个关键的工程设计平衡点，这些平衡点使系统中具有了导致系统成功或失败的质量属性。构架中结构的多样性位于概念的核心。
• 构架是一个软件或系统的组件、组件之间的相互关系以及管理其设计和演变的原理和方针的结构。 任何系统都有一个构架，并且可以独立于设计或演变该构架的过程的知识对其进行探索和分析。
• 构架是组件和连接器。  连接器是指系统运行时为传送控制和数据信息而采用的机制。因此，该定义主要强调了系统运行时的构架。

构架模式、参考模型和参考构架      在框线骨架和已经填充了关于系统的所有适当信息的构架之间，有很多中间阶段。每个阶段都是执行一组构架决策的结果。其中的一些中间阶段是非常重要的。要讨论构架结构前，我们先给出以下3个定义：

1. 构架模式是对元素和关系类型以及一组对其使用方式的限制的描述。可以把构架模式看作是对构架的一组制约条件--即对各元素类型及其交互模式的限制条件，而这些制约条件就确定了一组或一系列能满足它们的构架。   模式最有用的一个方面就是它们展示了已知的质量。这就是为什么设计师选择某个特定的模式，而不是随机选择模式的原因。一些模式代表了性能问题的已知解决方案，一些模式使用于高安全性系统，还有一些模式成功应用在了高可用性系统中。选择构架模式通常是设计师做出的第一个主要的设计决策。   术语构架样式的使用也非常广泛，它用于描述相同的概念。
2. 参考模型是一种考虑数据流的功能划分。参考模型是对已知问题的标准分解，分解所得的各个部分相互协作，构成问题的解决方案。产生于实践经验的参考模型是熟知某个领域的体现。
3. 参考构架是映射到软件元素（它们相互协作，共同实现在参考模型中定义的功能）及元素之间数据流上的参考模型。参考模型实现了功能划分，而参考构架则将这种功能划分与系统分解对应起来。这种对应可能（但不一定必须）是一一映射。一个软件元素可以实现某个功能的一部分，也可以实现若干个功能。  参考模型、构架模式和参考构架都不是构架，但它们都是捕获构架元素的有用的概念。这三者都是早期设计决策的产物。图2.2给出了这些设计元素之间的关系。  人们经常拿构架这个词与该词的其他用法进行类比，他们对这些用法有更多认识。他们经常将构架与某些物理结构或物理分布联系在一起。建筑设计师在设计大楼时必须要考虑方便性、美观、光照、可维护性等方面的要求。软件设计师在设计中也必须考虑并发性、可移植性、可修改性、易用性、安全性等因素，并且要在这些需求之间进行适当的权衡。

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

1. 涉众之间的交流。   软件构架是一种常见的对系统的抽象，绝大多数（如果不是全部的话）系统的涉众都以此作为彼此理解、协商、达成共识或相互沟通的基础。
2. 早期设计决策。  软件构架是所开发系统的最早设计决策的体现，而这些早期决策对系统的后续开发、部署和维护具有重要影响。这也是能够对所开发系统进行分析的最早时间点。
3. 可传递的系统抽象。   软件构架是关于系统构造及系统各元素工作机制的相对较小、却又能突出反映问题的模型。这种模型可以在多个系统之间传递，特别是可以应用刀具有相似质量属性和功能需求的系统中，并能促进大规模的重用。  

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

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

  构架是早期设计决策的体现      构架明确了对系统实现的约束条件。如果系统实现遵循构架设计中所做出的关于系统结构的决策，则系统实现将能够体现出构架的特色。

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

  构架决定了开发组织的组织结构。因为系统的构架中包含了对系统的最高层次的分解，因而一般被作为工作分解结构的基础；这反过来也规定了计划、调度及预算的单元，组内交流的渠道，配置控制和文件系统的组织，集成与测试计划和规程，甚至提出了对一些琐事的要求。各开发小组根据构架中各主要元素的接口规范进行交流。一旦进入维护阶段，维护活动也会反映出软件的结构，常由不同的小组分别负责各具体部分的维护。

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

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

  构架阻止或支持系统的质量属性的实现。  系统能否具有所期望的质量属性主要是由其构架决定的。第5章将详细讨论构架和质量属性之间的关系，现在仅需牢记以下几点：

  • 如果您的系统要求高性能，就需要管理元素基于时间的行为以及元素间通信的频率和数量。
  • 如果可修改性很重要，就需要给元素分配责任，以使对系统的修改不会产生很大的影响。
  • 如果系统必须非常安全，就需要管理和保护元素间的通信以及允许哪些元素访问哪些信息。可能还需要在构架中引入专门的元素（如受信的内核）
  • 如果您认为系统需要可扩展性，就必须仔细定位资源的使用，以有利于引入容量更高的更换组件。
  • 如果项目需要交付系统的增量式子集，就必须仔细管理组件间的使用。
  • 如果希望可以在其他系统中重要该系统的元素，就需要限制元素间的耦合，以便提取元素时，它能发挥作用，且不会与当前环境有过多依赖。

      这些和其他质量属性策略都与构架有很大关系。然而，仅靠构架也无法保证系统功能和质量属性的实现，理解这一点非常重要。

  通过研究构架来预测系统质量。能否在系统开发和部署前就知道做出了适当的构架决策（也就是系统是否将表现出所期望的质量属性）？ 所幸的是，仅仅依靠对构架的评估来预测系统未来的质量属性是可能的。

  构架使推理判断和控制更改更简单。每个构架都将可能的更改划分为3类：本地的、非本地的和构架上的。本地更改只需修改某一个元素就可以实现。非本地更改的实现则需对多个元素进行修改，但并不改动构架。构架的更改会影响各元素之间交互的基本方式--即构架模式--并很可能要求系统做全面的修改。显然，仅做本地更改是最理想的。所以，一个富有生命力的构架应该是这样的：最有可能发生的更改也是最容易进行的更改。    构架有助于循序渐进的原型设计。一旦确定了构架，就可以对其进行分析，并将其原型构造为一个骨架系统。这从两个方面协助开发过程的顺利进行：

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

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

  构架是可传递、可重用的模型       在整个生命期中，重要的越早，收益就越大。代码的重用能带来极大的便利，而在构架层次上的重用则为具有类似需求的系统开发提供了有利的手段。不仅可以实现代码的重用，还可以实现决定构架选用的系统需求及构建构架的经验的重用。如果构架决策能够在多个系统中得到重用，则也可以获得上面讲到的早期决策所带来的所有好处。     产品线共享一个公共的构架。   软件产品线或家族是一组软件密集型系统，这些系统共享一个公共的、可管理性的特性集，满足了待定市场或任务的具体需要，是 按照规定的方式根据一组公共的核心资产开发的。在这些核心资产中，主要部分就是设计用来处理整个家族需要的构架。产品线设计师通过制定在早期适用与整个家族的设计决策，以及在后期仅适用于单个成员的其他决策，来选择一个满足产品线的所有预想成员的构架。该构架定义了对产品线的所有成员来说，什么是固定的，什么是可变的。对多系统开发来说，软件产品线是一种强大的开发方法，它可以在上市时间、成本、生产率和产品质量方面实现极大的回报。构架的强大源于范例的核心。与其他资本投资类似，产品线的构架将成为开发组织的核心资产。    系统开发可以使用大型的、由其他组织开发的元素。以前的软件范例总是将编程作为最根本的任务，把编写了多少行代码作为衡量项目进展情况的依据。基于构架的开发则更强调对各元素的组合或装配，而这些元素很可能已分别甚至是完全独立地开发实现了。由于构架定义了可以集成到系统中的元素，因此，这种组合是可能的。构架从元素与环境的交互、对控制的接收和释放、所能使用或产生的数据、访问数据的方式、通信方式以及用于通信和资源共享的协议等方面对可能做的更换做了种种约定。   元素结构、接口和操作概念的组织是构架的一个重要方面。互换性是这种组织的最重要的原则。   商业组件、子系统、兼容的通信接口都是基于互换性原则的。      少就是多：限制选择范围是值得的。随着所积累的构架模式和设计模式越来越多，我们将会越来越清楚地认识到：虽然计算机程序可以以近乎无限的方式来组合，但涉及到程序的协调和交互时，有意识地限制在一定范围内选择将使我们受益匪浅。也就是说，我们希望使所构建系统的设计尽可能简单。这种方法的优势包括：重用程度更高、更易于理解和交流的简单规范的设计、更为透彻的分析、更短的选择时间、更强的可互操作性。       软件设计的特性来自于构架模式的选择。那些更适用于某个特定问题的构架模式将改善设计方案的实现，这可能通过更轻松地在相冲突的设计要求之间进行权衡、提高对设计环境的人认识和/或使需求描述中的不一致性更为突出等方式体现出来。    系统构架与软件构架。在过去的5到10年中，我们在很多场合对软件构架进行了讨论。每次总会有人提出如下问题：为什么谈论软件构架？系统构架是否同软件构架一样重要？或者说软件构架和系统构架之间的区别是什么？    在创建软件构架时，通常很少考虑系统。  如果您想让构架具有很高的性能，就需要了解该系统将运行的硬件平台的物理特性以及该系统将与之交互的任何设备的特性，您通常还会关注网络的特性。如果您需要构架具有很高的可靠性，也需要关注硬件，在这种情况下就是关心其故障率和冗余处理或网络设备的可用性。如此等等，不一而足。设计师很少考虑硬件。    因此，设计软件构架时，大概需要考虑整个系统--硬件和软件，否则就是蛮干。当仅规定了系统的一部分时，任何一个工程师都不可能预测系统的特性。    但我们主要谈论的仍然是软件构架而非系统构架。这是为什么呢？因为大多数设计师在软件方面都可以做出选择，而在硬件方面则没有这种自由。  构架使基于模板的开发成为可能。构架体现了关于元素交互方式的设计决策。这些决策虽然是每个元素的实现中体现出来的，但却能够局部化，只需编写一次即可。可以在某处用模板将元素间的交互机制描述清楚。  构架可以做为培训的基础。 在对项目新成员介绍所开发的系统时间，可以首先介绍系统的结构，以及对组件之间如何交互从而实现系统需求的高层次的描述。我们曾经指出，软件构架的重要用途之一就是支持并促进各涉众之间的交流，这进一步印证了我们的观点。构架是一个公共的参考点。

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

   在讨论构架表示时，我们将使用相关术语结构和视图。视图是构架元素的内聚集的表示，由系统涉众编写和阅读。它由一个元素集的表示和元素之间的关系组成。结构是元素本身的集合，它们存在于软件或硬件中。   大体上可将构架分为3组，这取决于它们所展示的元素的主要特性。  大体上可将构架结构分为3组，这取决于它们所展示的元素的主要特性。

• 模块结构。此处的元素是模块，它们是实现单元。模块表示一种考虑系统的基于代码的方法。模块被分配功能责任区域。这不怎么强调所开发出来的软件如何在运行时表现自己。模块结构能够使我们回答诸如此类的问题：分配给每个模块的主要功能责任是什么？允许模块使用的其他软件元素是什么？它实际使用的其他软件是什么？什么模块通过泛化或特化关系与其他模块相关？
• 组件-连接件结构。此处的元素为运行时组件（它们是计算的主要单元）和连接器（它们是组件间通信的工具）。组件-连接件结构能够使我们回答诸如此类的问题：什么是主要的执行组件，它们如何交互？什么是主要的共享数据存储？复制系统的哪些部分？数据在系统中经过了哪些地方？系统的哪些部分可以并行运行？在系统执行时，其结构可能会发生怎样的变化？
• 分配结构。分配结构展示了软件元素和创建并执行软件的一个或多个外部环境中的元素之间的关系。它们回答了诸如此类的问题：每个软件元素在什么处理器上执行？在开发、测试和系统构建期间，每个元素都存储在什么文件中？分配给开发小组的软件元素是什么？

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

• 系统如何被组织为一个代码单元集合的？
• 系统如何被组织为一个具有运行时行为（组件）和交互（连接器）的元素集合的？
• 系统如何与其环境中的非软件结构相关（也就是CPU、文件系统、网络和开发小组等）？

• 软件结构      图2.3展示了一些最常见和最有用的软件结构。

   

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

  • 分解。   这些单元是通过“是一个子模块”关系将彼此关联起来的模块，展示了如何将较大的模块递归地分解为较小的模块，直到它们足够小，很容易理解为之。该结构中的模块代表了设计中一个常见的起点，因为设计师列举了软件的单元必须做什么工作，并把每个项目分配给模块以进行随后的设计和最后的实现。模块通常有关联的产品。通过确保很可能会发生的变化最多只在几个小模块中，分解结构提供了很大一部分的系统可更改性。通常将其用作开发项目的组织的基础，包括分解结构、其集和测试计划。该结构中的单元通常具有特定于组织的名称。
  • 使用。这一重要但是结构经常被忽略的单元也是模块，或者是过程，或者是模块接口上的资源。这些单元通过“使用”关系彼此相关。如果一个单元的正确性要求另一个单元提供正确版本的话，那么我们称第一个单元使用第二个单元。使用结构用于设计可以轻松扩展以添加功能的系统，或从中可以轻松提取有用功能子集的系统。轻松提取工作系统的子集的能力允许进行增量式开发。
  • 类或泛化。该结构中的模块单元被称为类。关系是“继承自”或“是一个实例”。可以根据该视图推断出类似行为或能力的集合，以及通过划分子类所捕获的参数化的差别。类结构能够使我们对重用以及功能的增量式增加进行推断。

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

  • 进程或通信进程。向所有组件-连接器结构一样，该结构与基于模块的结构是正交的，它处理的是运行系统的动态方面。此处的单元为通过通信、同步和/或排除操作将彼此相连的进程或线程。在该结构中（而且在所有组件-连接器结构中）的关系是“附加”，展示了组件和连接器是如何连接在一起的。进程结构非常重要，它有助于设计系统的执行性能和可用性。
  • 并发。该组件-连接器结构能够使设计师确定并行的机会以及可能出现资源争用的位置。单元是组件，连接器是“逻辑线程”。逻辑线程是一系列计算，可以将这些计算在稍后的设计过程中分配给单独的物理线程。并发结构在设计的早期使用，以确定管理与并发执行相关的问题的需求。
  • 共享数据或存储库。   该结构由创建、存储和访问持久数据的组件和连接器组成。如果实际上是系统是根据一个或多个共享数据存储库构建的，那么，该结构就适于进行说明。它展示了运行软件元素如何产生数据和使用数据，可以使用该结构确保良好的性能和数据完整性。
  • 客户机-服务器。如果系统被构建为一组彼此协作的客户机和服务器，那么，这就是一个很好的进行说明的组件--连接器结构。组件是客户机和服务器，连接器是协议以及它们共享来执行系统工作的消息。这对于关注点分离（支持可修改性）、物理分布和负载平衡（支持运行时性能）都是有用的。

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

  • 部署。部署结构展示了如何将软件分给硬件处理和通信元素。元素是软件（从组件-连接器的观点看通常是进程）、硬件实体（处理器）和通信路径。关系是“分配给”和“移植到”，前者展示了软件元素所驻留的物理单元，后者的条件是分配和动态的。该视图能够使工程设计人员对性能、数据完整性、可用性和安全性进行推断。在分布式或并行系统中，我们尤其对部署结构感兴趣。
  • 实现。该结构展示了软件元素（通常是模块）是如何映射刀系统开发、集成或配置控制环境中的文件结构上。这对于开发活动和构建过程的管理非常关键。
  • 工作分配。该结构将实现和集成模块的责任分配给适当的开发小组。拥有作为构架一部分的工作分配结构，可以使关于谁做工作的决策具有管理上的和构架上的两层含义变得清晰。设计师应该知道对每个小组的技术要求。同样，在大规模的多源分布式开发项目上，工作分配结构是调出功能公共的单元并把它们分配给某个小组的手段，而非让需要它们的每个人去实现。

        表2.1对软件结构进行了总结。该表列出了每个结构中的元素及其关系的含义，并说明了每种结构可能会用于什么情况。    尽管我们通常从功能的角度理解某个系统的结构，但除了功能外，还有必须在构架层次上考虑的系统属性，如物理分布、进程通信和同步。每种结构都提供了一个对某些相关质量属性进行推断的方法。进程结构设计用于消除死锁并减少瓶颈。模块分解结构设计用于产生可修改的系统，等等。每种结构都为设计师提供了一个考察系统的不同的角度，并为设计权衡提供了不同的支点。

  将结构彼此关联在一起       尽管这些结构提供了不同的考察系统的视角，但它们不是独立的。一个结构的元素与其他结构的元素相关，我们需要对这些关系进行推断。  单个项目有时会把一种结构作为主要结构，并在可能的情况下，根据该结构考虑和运用其他结构。主要结构通常是模块分解，但并不总是如此。这是有充足理由的：它容易与组织的项目结构吻合。    并不是所有的系统都需要在构架上采用多种结构。系统越大，这些结构之间的差别就越大；然而对于较小的系统，有少数几个结构通常即可满足要求。在有几个组件--连接器结构时，我们不是把每个结构都用上，一个即可满足要求。如果只有一个进程，那么，在设计中显然没必要考虑进程结构。如果没有分布式的特征（也就是说，仅有一个处理器），那么，部署结构就没有什么价值，不需要做进一步考虑。

         结构代表了构架的主要工程设计平衡点。单个结构赋予了它们处理一个或多个质量属性的能力。它们代表了一个用于创建构架的强大的关注点分离方法。

  选择哪些结构      设计师应该使用哪些结构？设计师应该把哪些结构编成文档？当然，肯定不是使用所有结构并把所有的结构编成文档。   这方面有很多建议。1995年，Philippe Kruchten发表了一篇很有影响力的论文【Kruchten95】。在这篇论文中，他描述了由单独的结构组成的构架的概念，并建议把重点放在4种结构上。为了验证这些结构彼此并不冲突，在实际应用中能够相互协作，他描述了一个满足其需求的系统。Kruchten95建议使用关键的用力进行检查。这一所谓的“4+1”方法变得非常流行，现在已经成为Rational统一过程的概念基础。

  • 逻辑的。元素为“关键的抽象”，在面向对象中表示为对象或对象类。这是一个模块视图。
  • 进程。该视图解决了功能的并发和分布问题。这是一个组件--连接器视图。
  • 开发。该视图展示了软件模块、库、子系统和开发单元的组织。它是一个分配视图，将软件映射到了开发环境中。
  • 物理的。该视图将其他元素映射到了处理和通信节点上，它是一个分配视图（有些人把它叫做部署视图）。

  几乎在Kruchten发表论文的同一时间，Soni , Nord 和 Hofmeister 共同发表了一篇非常有影响力的论文。在这篇论文中，它们报告了其所在的组织中的软件设计师在许多项目中使用的结构。它们的视图是概念上的模块互连、执行和代码。这些视图再一次清晰地映射刀模块、组件-连接器以及分配模型上。     设计师的职责之一就是理解各种结构如何帮助实现质量属性，然后选择能够最佳地提供这些质量属性的结构。

小结      本章给出了软件构架的定义，并介绍了参考模型、参考构架和构架模式的相关概念。本章也从早期研究对系统的认识、构架对各涉众相互沟通的影响以及作为一种可重用资产的价值等方面，解释了构架在软件工程领域的重要意义。