摘要

本文的目的是为软件体系结构的建立奠定基础。我们首先通过吸引几个已经确立的体系结构规程来开发软件体系结构的直觉。基于这种直觉，我们提出了一个软件架构模型，它由三个部分组成:元素、形式和原理。元素是处理、数据或连接元素。表单是根据元素(即元素上的约束)的属性和元素之间的关系来定义的。就系统约束而言，ratio-nale提供了体系结构的底层基础，这些约束通常来自于系统需求。我们在体系结构和体系结构样式的上下文中讨论了模型的组成，并给出了一个扩展示例来说明一些重要的体系结构和样式注意事项。最后，我们提出了软件架构方法的一些原则，总结了我们的贡献，并将我们的方法与其他当前工作联系起来。

1.介绍

软件设计在20世纪70年代受到了研究人员的极大关注。本研究针对20世纪60年代[5]首次提出的开发大型软件系统的独特问题。研究的前提是设计是一项独立于实现的活动，需要特殊的注意事项、技术和工具[3,9,17]。这种软件设计研究的成果现在已经开始作为计算机辅助软件工程(CASE)工具[7]进入市场。

在20世纪80年代，软件工程研究的焦点从软件设计转向将设计和设计过程集成到软件过程及其管理的更广泛的环境中。这种集成的结果之一是，为软件设计开发的许多符号和技术已经被实现语言所吸收。例如，考虑一下支持\大型编程的概念。这种集成往往模糊(如果不是混淆的话)设计和实现之间的区别。

20世纪80年代，我们描述和分析软件系统的能力也有了很大的进步。我们在这里指的是诸如形式描述技术和类型的诡辩概念之类的东西，它们使我们能够更客观地对软件系统进行推理。例如，我们能够更直观地推断\一致性“和\不一致性”，我们能够讨论\类型一致性“1而不仅仅是\类型等价”。

我们相信，20世纪90年代将是软件架构的十年。我们使用术语\架构“，在对比\设计”，以唤起概念的codification，抽象，标准，正式培训(软件架构师)，和风格。虽然已经有一些工作在德宁特定软件架构(例如,[19日22]),甚至一些工作在发展中一般支持开发架构的过程(尤其是萨拉[8]),是时候重新审视架构的作用在这一大背景下的软件过程,软件过程管理、以及元帅(marshal)已经开发出来的各种新技术。

作为一门主要学科，我们期望从软件体系结构的出现中获得的一些好处是:
1)体系结构作为满足需求的框架;
2)架构作为设计的技术基础，作为成本估算和过程管理的管理基础;
3)架构作为复用的一种映射基础;
4)架构作为依赖和一致性分析的基础。

因此，我们研究的主要对象是支持软件架构规范的开发和使用。本文旨在为今后软件体系结构的研究奠定基础。

在第2节中，我们首先在诸如硬件、网络和构建体系结构等已确立的规程的背景下，开发关于软件体系结构的直觉，建立软件体系结构的上下文，并为我们的方法提供动机。

在第3节中，我们提出了软件体系结构和软件体系结构风格的模型和描述。接下来，

在第4节中，我们将讨论一个容易理解的示例，以引出软件体系结构的一些重要方面，并描述软件体系结构表示法的需求。

在第5节中，我们详细介绍了我们的软件架构方法的两个主要原则。

在第六章中，我们总结了本文的主要观点，并结合相关工作进行了总结。

2.直觉、情境和动机（Intuition, Context, and Motivation）

在介绍我们的软件架构模型之前，我们先来看看它的哲学基础:
1)通过与现有学科的类比来发展对软件架构的直觉;
2)提出多层次产品范式下的软件体系结构协议书;
3)为软件架构作为一门独立的学科提供一些动力。

2.1培养对软件架构的直觉

有趣的是，我们没有命名软件架构。我们有一些直觉，认为有不同种类的软件架构，但是我们没有将它们形式化，或者制度化。我们的主张是，当前的事件状态之所以存在，是因为软件架构太多了，而不是因为太少了。在这一节中，我们将介绍几个架构学科，以便开发我们对软件架构的直觉。我们关注硬件和网络架构，因为它们在理论上被认为是软件架构的思想来源;我们关注建筑是因为它是经典的“建筑学科”。

2.1.1计算机硬件架构

有几种不同的硬件架构方法，它们的区别在于所强调的硬件方面。RISC机器是一种强调指令集是重要特征的硬件架构的组成部分。流水线机器和多处理器机器是硬件架构的例子，它们强调硬件架构块的组合。
在我们考虑软件体系结构时，第二个面向硬件体系结构的方法有两个重要的有趣特性:

• there are a relatively small number of design ele-ments;
  设计元素相对较少;
• scale is achieved by replication of these design ele-ments.
  规模是通过复制这些设计元素来实现的。

这与软件架构形成了对比，在软件架构中，可能的设计元素非常多。此外，规模不是通过复制设计元素来实现的，而是通过添加更多不同的设计元素来实现的。然而，也有一些相似之处:我们经常以类似于上面提到的硬件架构的方式组织和调用软件架构。例如，我们创建多进程软件系统并使用流水线处理。

因此，本讨论的重要观点是，这两种体系结构之间存在根本和重要的差异。由于这些差异，我们经常以类似硬件的术语表示软件架构，这多少有些讽刺。

2.1.2 网络体系结构

网络架构是通过将网络的设计元素抽象为节点和连接，并通过命名这两个元素之间的关系来实现的。因此，我们以星网、环网和曼哈顿街网络作为命名网络架构的例子。

关于网络架构的两个有趣的架构点是:

• there are two components nodes and connections;
  有两个组件 节点和连接;
• there are only a few topologies that are considered
  只有少数拓扑被考虑

当然，我们可以在软件架构中抽象到类似的层次，例如流程和集成流程通信。然而，与其考虑一些拓扑，还不如考虑非常多的可能拓扑，而且这些拓扑通常没有名称。此外，我们强调大小方面的差异，从拓扑的节点和连接。相反，我们考虑的问题是进程的位置(例如，分布式架构)或进程间通信的类型(例如，消息传递架构)。

因此，尽管我们可以从一个类似的抽象层次来看待架构元素，但是我们并没有从使用网络作为软件架构的类比中得到太多好处。

2.1.3 建筑结构

经典的架构领域为软件架构提供了一些更有趣的见解。虽然两者的主题相当不同，但是在构建体系结构时，有许多有趣的体系结构点可以为软件体系结构提供建议:

• multiple views;
  多个视图;
• architectural styles;
  建筑风格;
• style and engineering;
  风格和工程;
• style and materials;
  风格和材料;

建筑建筑师通过许多不同的观点与客户一起工作，这些观点强调了建筑的某些特定方面。例如，立面图和平面图分别给出了外部视图和自上而下的视图。立面视图可以通过背景图甚至比例模型来补充，为客户提供建筑在其背景下的外观。对于建造者来说，建筑师提供了相同的楼层平面图和额外的结构视图，这些视图提供了关于各种显式设计考虑(如电线、管道、供暖和空调)的大量细节。

类似地，软件架构师需要为不同的用途和用户提供不同的软件架构视图。目前我们只有一个观点:实现。在真正意义上，实现就像一个构建器详细视图，也就是说，就像一个没有外壳的建筑，其中所有的细节都是可见的。从系统的各个细节抽象出系统的设计和构造是非常困难的。(以巴黎蓬皮杜中心为例。)

从描述性和说明性的角度来看，体系结构风格的概念特别有用。建筑风格是设计元素和形式安排的一种具体的规定。从规定上说，风格限制了设计元素的种类和它们的正式安排。也就是说，建筑风格既限制了设计元素，又限制了设计元素之间的形式关系。类似地，我们将发现这是软件架构中最有用的概念。

最重要的是工程原则和建筑风格(当然还有建筑本身)之间的关系。例如，在剑桥大学国王学院的礼拜堂里，从罗马式工程学院(romanesque engineering)传来的光线和通风的垂直型风格让人感觉不到。从罗马式的厚重到垂直的轻盈，需要不同的工程原理。这不仅仅是美学问题。这种工程原理与软件体系结构之间的关系也是非常重要的。

最后，建筑风格与材料之间的关系至关重要。这些材料具有某些特性，可用于提供特定的样式。人们可以将结构与材料的美学用途结合起来，例如都铎式房屋的柱梁结构。然而，人们不会用木桩和木梁建造摩天大楼。设计元素的材料方面为建筑提供了美学和工程基础。同样，这种关系在软件架构中是至关重要的。

因此，我们在构建体系结构时发现了一些关于软件体系结构的基本观点:需要多个视图来强调和理解体系结构的不同方面;风格是一种令人信服的重要的法典（codification）形式，既可用于描述，也可用于规定;而工程原理和材料性能在发展和支撑一种颗粒建筑和建筑风格中具有根本的重要性。

2.2架构的上下文(the context of architecture)

在讨论我们进行软件架构说明的动机之前，我们假定在整个软件产品的上下文中对架构进行了描述。请注意，我们并不是在暗示创建此产品的特定流程的任何内容，当然，我们的视图中可能包含有关该流程的暗示。我们的目的主要是为体系结构提供一个环境，在这个环境中可以被认为是一个相当标准的软件产品。

我们将软件产品的不同部分划分为对该部分重要的事物的种类，在该层次上重要的实体的种类，它们的属性和关系，以及在该层次上相关的决策和评估标准的种类:

• 要求是有关确定资讯、处理，以及该等资讯和处理的特点，是系统使用者所需要的;
• 体系结构涉及档案结构元素的选择、它们之间的相互作用，以及对这些元素的约束和它们之间的相互作用，这些元素是提供满足需求并作为设计基础的框架所必需的;
• 设计是指设计元素及其算法和程序的模块化和详细接口，以及支持体系结构和满足需求所需的数据类型;
• 实现涉及满足设计、体系结构和需求的算法和数据类型的表示。

某一特定产品的不同部分绝不是如此简单的表征。模型、抽象、转换和表示的可能选择是连续的。我们将这个连续体简化为四个独立的部分，主要是为了直观地了解体系结构如何与软件系统的需求和设计相关联。

需要注意的是，有一些开发范式我们的描述并不适用于|，例如在AI研究中经常发现的探索性编程范式。然而，我们的描述代表了在产品软件创建中使用的各种开发和演进范式，并且描述了一个重要的、迄今为止被低估的软件产品[15]的一部分。

2.3架构规范的动机(motivation for Architectural Specifications)

有许多因素导致了软件的高成本。两个重要的因素是软件架构是演进和定制的。（evolution and customization）

系统不断发展并适应新的用途，就像建筑物随着时间的推移而变化并适应新的用途一样。演化的一个经常伴随的特性是系统|的脆性增加，即对变化的阻力增加，或者至少对优雅地变化[5]的阻力增加。这部分是由于两个建筑问题:建筑侵蚀和建筑漂移。建筑的侵蚀是由于对建筑结构的破坏。这些违规行为往往会导致系统问题的增加，并导致系统|的脆性增加，例如，拆除承重墙往往会导致灾难性的结果。建筑的漂移是由于对建筑的不敏感造成的。这种不敏感更容易导致不适应，而不是灾难，并导致形式缺乏连贯性和清晰度，从而更容易违反现在变得更加模糊的架构。

定制是软件架构中的一个重要因素，这并不是因为它会导致问题，而是因为它所预言的架构成熟度的缺乏。在构建软件系统时，我们仍然处于为每个新体系结构重新创建每个设计元素的阶段。我们还没有达到一个标准的阶段，我们有一套标准的建筑风格，伴随着它们的设计元素和正式的安排。每个系统在本质上都是一个新的建筑，一种新的建筑风格。无处不在的定制的出现表明，对编码的需求是普遍存在的 -----也就是说，需要为各种体系结构样式提供体系结构模板。对于具有特定风格的系统的标准部分，架构师可以从一组已知的和可理解的元素中进行选择，并以适合所需体系结构的方式使用它们。对体系结构元素使用标准模板之后，架构师就可以将精力集中在那些定制非常重要的元素上。

考虑到我们对架构的描述和激励问题，有许多事情我们想要能够用架构规范来做：

• 规定所需级别|的架构约束，即指示所需的限制性或许可性，确定所需级别的概括性或特殊性，指出什么是必需品，什么是奢侈品，并指出相关性和绝对性的程度。我们希望一种支持最小约束原则的方法“能够只表达体系结构中在系统描述的体系结构级别上需要的那些约束”。这与当前的实践是一个重要的背离，当前的实践不是指定约束，而是提供包含这些期望约束的特定解决方案。
• 美学与工程分离------也就是说，要从“什么是\演讲”中准确地说出什么是\承重。这种分离使我们能够避免导致体系结构侵蚀的各种更改。
• 以适当的方式表达体系结构的不同方面，也就是说，在适当的视图中描述体系结构的不同部分。
• 执行依赖和一致性分析-------即确定体系结构、需求和设计之间的相互依赖关系;确定体系结构各个部分之间的相互依赖关系;确定建筑风格之间、风格与建筑之间、建筑元素之间的一致性或缺乏一致性。

3.软件架构模型

在第2节中，我们使用构建体系结构的领域来提供一些关于软件体系结构可能是什么的洞见。建筑结构的概念，我们呼吁的是标准的定义:艺术或科学的建筑:特别是设计和建设的哈比斯结构“[11]。也许与我们的需要更相关的是一个次要的概念:\统一或连贯的形式或结构“[11]”。这就是建筑的感觉------提供一个统一或连贯的形式或结构|，这注入了我们的软件档案结构模型。

我们首先介绍了我们的软件架构模型，介绍了软件架构风格的概念，并讨论了处理、数据和连接器视图之间的相互依赖关系。

3.1模型

通过与建筑体系结构的类比，我们提出了软件体系结构的如下模型:

软件架构=元素、形式、基本原理 (Elements, Form, Rationale)

也就是说，软件体系结构是一组具有特定形式的体系结构(或者，如果您愿意，也可以称为设计)元素。

我们区分了三种不同类型的架构元素:

• 处理元素
• 数据元素
• 连接元素

处理元素是那些支持对数据元素进行转换的组件;
数据元素是那些包含使用和转换的信息的元素;
连接的元素(有时可能是处理元素，也可能是数据元素，或者两者兼而有之)是将体系结构的不同部分粘合在一起的粘合剂。
例如，过程调用、共享数据和消息是连接用于将“体系结构元素”粘合在一起的元素的不同示例。

以水球为例，它隐喻了不同类别的元素:游泳者是处理元素，球是数据元素，水是主要的连接元素(粘合剂)。进一步考虑水球、马球和足球的相似之处。它们都有一个类似的\架构“但是在\胶水中有差别”------也就是说，它们具有相似的元素、形状和形式，但迪尔主要是在它们所处的环境中，以及在元素连接在一起的方式中发挥作用。下面我们将看到，这些连接的元素在区分一个建筑与另一个建筑的过程中发挥着基础性的作用，并可能对一个特殊建筑或建筑风格的特征产生重要影响。

建筑形式由加权属性和关系组成。权重表示两种情况之一:要么是属性的重要性，要么是关系的重要性，要么是在备选方案中进行选择的必要性，其中一些方案可能比其他方案更受青睐。使用加权来表示重要性，使架构师能够区分“承重”和“装饰”的形式方面;使用权重来指示可选方案使架构师能够约束选择，同时为必须满足和实现体系结构的设计人员提供一定程度的自由度。

属性用于约束存档结构元素|的选择，也就是说，属性用于将对元素的约束去除到架构师希望的程度。除非另有说明，否则属性不受所需的最小约束-----也就是说，对于属性所定义的约束，默认情况是:“架构师没有约束的东西可以采用设计者或实现者希望的任何形式”。

关系用于约束架构元素的“位置”也就是说，它们限制了不同元素如何交互，以及它们如何在体系结构中相互组织。与属性一样，关系不受所需的最小约束，除非另有说明。

架构的一个基础的、但完整的部分是在定义架构时所做的各种选择的基本原理。基本原理捕获了选择体系结构风格、元素和表单的动机。在建筑建筑学中，基本原理解释了激励建筑师的潜在哲学美学。在软件体系结构中，基本原理是解释系统约束的满足程度。这些约束由基本功能方面到各种非功能方面的考虑决定，如经济[4]、性能[2]和可靠性[13]。

3.2 架构风格

如果说建筑是一种形式化的组织，那么建筑风格就是从各种具体的建筑中抽象出元素和形式化的方面。与特定的体系结构相比，体系结构风格的约束更少，也更不完整。例如，我们可以讨论分布式样式或多进程样式。在这些情况下，我们只关注特定体系结构的某些方面:处理元素和硬件处理器之间的关系，以及元素上的约束。

考虑到这种对架构和架构风格的定义，在架构风格停止的地方和架构开始的地方之间并没有严格的分界线。我们有一个连续体，其中一个人的建筑可能是另一个人的建筑风格。它是架构还是样式在某种意义上取决于使用。例如，我们在2.3节中建议将架构样式用作架构上的约束。假设我们希望架构规格仅受架构师所希望的级别的约束，那么很容易发生的情况是，一个人的架构可能比另一个人的架构风格受到的约束要少。

架构风格的重要之处在于，它封装了关于架构元素的重要决策，并强调了对元素及其关系的重要约束。风格的有用之处在于，我们可以使用它来约束体系结构和协调协作的架构师。此外，风格体现了那些有助于侵蚀和漂移的决策。强调风格作为对体系结构的约束提供了对体系结构某些方面的可见性，以便这些方面的违反和对它们的不敏感将更加明显。

3.3 处理/数据/连接器相互依存(process/data/connector interdependence)

如上所述，来自建筑体系结构的一个重要观点是多视图。软件架构中的三个重要视图是处理视图、数据视图和连接视图。我们注意到，如果提供了体系结构的流程视图，则结果的重点是处理元素的数据流，以及处理元素之间相对于数据元素的连接的某些方面。相反，如果提供了体系结构的数据视图，则结果的重点放在处理流上，但不像在流程视图中那样侧重于连接元素。虽然目前的共识似乎强调面向对象(即面向数据)的方法，但我们认为所有这三个视图在体系结构级别上都是必要和有用的。

我们非正式地认为，有一个进程和数据相互依存:

• 有一些属性可以区分数据的一种状态和另一种状态;
• 这些特性是由某些处理元素产生的某些转换的结果。

因此，这两种观点是相互交织的——至少在数据和处理的一些重要特征上，它们相互依赖。(有关流程和数据相互依赖的更一般讨论，请参见[10]。)

处理和数据在连接上的相互依赖关系更加明显:连接元素是在处理器之间移动数据的机制。由于数据上的这种活动，连接的元素必然具有数据元素所需的某些属性，其方式与处理元素具有数据元素所需的某些属性完全相同。

在架构层，我们需要所有三个视图，以及在它们之间自由轻松移动的能力。下一节中的示例将说明这种相互依赖关系，以及如何提供三个不同但重叠的视图。

4.例子

获得广泛接受的为数不多的软件体系结构样式之一是多相编译器。实际上，这是所有软件工程师都应该接受过培训的惟一风格。我们依靠这种熟悉程度来说明我们对软件架构及其描述所获得的一些见解。

在这一节中，我们来看两种多相风格的编译器架构:

• a compiler that is organized sequentially;
  按顺序组织的编译器;
• a compiler that is organized as a set of parallel pro-cesses connected by means of a shared internal rep-resentation.
  一种编译器，由一组并行进程组成，这些进程通过共享的内部表示连接在一起。

由于篇幅限制和表示目的，我们的示例有些简单和理想化，忽略了许多细节。此外，我们使用现有的表示法，因为它们便于说明;关于特殊建筑符号的建议超出了本文的范围。在每种情况下，我们都将重点放在从该特定示例派生出来的最有趣的架构考虑事项上。(当然，还存在其他多阶段编译器体系结构的例子，我们不主张对该体系结构的全面覆盖。)在研究这些示例之前，我们简要回顾一下它们的常见架构风格。

4.1多阶段架构风格（the mulit-phase architectural style）

我们的编译器简化模型分为五个阶段:词法分析、语法分析、语义分析、优化和代码生成。

词法分析作用于源文本中的字符，以产生用于语法分析的令牌。

句法分析产生的短语要么是修饰性短语，要么是使用性短语。

语义分析将使用短语与删除短语关联起来——程序元素(如标识符)的每次使用都与该元素的删除相关联，从而产生相关的短语。

优化会对相关短语产生注释，这些短语是在生成目标代码时使用的提示。

优化阶段被认为是这种风格的首选方面，但不是必需的。因此，多阶段风格识别以下架构元素:

processing elements:
lexer, parser, semantor, optimizer, and code generator;
处理元素:
词法分析程序、解析器、语义器、优化器和代码生成器;

data elements:
characters, tokens, phrases,
correlated phrases, annotated
phrases, and object code.
数据元素:
人物,令牌,短语,
相关的短语,注释
短语和目标代码。

注意，我们还没有形成连接元素。简单地说，这种样式并没有规定要使用哪些连接元素。当然，连接元素的选择对最终的架构有深远的影响，如下所示。

建筑风格的形式是通过加权属性和档案结构元素之间的关系来表达的。例如，优化器和没有标记的短语必须一起找到，但是它们都是首选元素，没有必要。另一个例子是，组成程序文本的字符、lexer生成的令牌和解析器生成的短语之间存在线性关系。具体来说，令牌由一系列字符组成，短语由一系列to-kens组成。然而，短语与相关短语之间存在非线性关系。这些关系如图1所示。作为一个nal示例，每个处理元素都有一组属性，这些属性消除了对这些元素的约束。例如，lexer将表示程序文本的字符作为输入，并生成一系列令牌作为输出。此外，令牌和字符之间存在必须由lexer保存的顺序对应关系。一个好的架构描述将捕获这些以及其他此类属性和关系。

让我们通过形式化地描述字符和令牌之间的关系以及描述lexer的顺序保存属性来说明这一点。我们从一个用序列和不相交子序列表示的数据视图开始描述。

image.png image.png image.png

从处理的角度来看，lexer现在被限制接受字符C序列，生成令牌T序列，并保持字符与令牌之间的顺序对应关系:

image.png

最后，值得注意的是连接器视图显示了应该放在体系结构样式上的其他约束。这些约束可以通过lexer和解析器之间的连接来说明。特别是，连接元素必须确保为解析器保留lexer生成的令牌，以便顺序保持完整，并且没有丢失、重复或虚假的添加。

4.2 连续的体系结构 Sequential Architecture

如果有一个“经典的”多阶段编译器体系结构，那么它就是一个顺序的体系结构，在这个体系结构中，每个阶段在下一个阶段开始之前完成其功能，在这个体系结构中，数据元素直接从一个处理元素传递到另一个处理元素。因此，我们添加了以下架构元素来描述整体风格:

image.png

此外，我们还使用了令牌来将标识符令牌的结构包含到一个名称表(NT)中，并对短语进行了优化，以便将其组织到一个抽象语法树(AST)中。短语之间的相关性会导致抽象语法图(ASG)和带注释的抽象语法图(AASG)中的优化。图2给出了顺序体系结构的处理视图，显示了通过系统的数据流。注意，从semantor到代码生成器有两条路径，只有一条路径通过优化器。这反映了在此体系结构中不需要单独的优化阶段这一事实。也就是说，满足此体系结构的设计不需要提供优化器。

为了说明处理和数据视图之间的相互依赖关系，让我们将正在创建和转换的数据作为一个整体来考虑。我们发现，数据视图最好由我们称为面向应用程序的属性的概念来捕获。面向应用程序的属性描述数据结构的状态，这些状态对于操作该结构的处理元素非常重要。它们可以用于控制处理顺序，帮助消除数据结构上处理元素的影响，甚至帮助消除处理元素实现这些影响所需的操作。
对于本例，(简化)面向应用程序的属性如下:

image.png image.png

再次注意，最后一个属性是首选的。虽然在本例中，面向应用程序的属性可能看起来很明显，而且几乎不重要，但是在下一个示例中，它们对于体系结构的描述以及确保设计和实现与该体系结构的一致性至关重要。

需要考虑的一个有趣问题是，为什么我们选择使用基于属性的方案来描述体系结构元素，而不是使用基于类型的方案。原因是这种模式,因为它们目前存在,本质上是只能够描述元素和应用方面的一个应用到另一个之间的关系(例如,子类型化和in-heritance[12]),在那个特定的元素与其他元素的关系(例如,奥罗斯[18]),和可以执行的操作的元素。它们不适合描述元素的特征，比如上面提到的面向应用程序的属性。例如，仅仅知道有一个与抽象语法图相关联的操作来将一个短语连接到另一个短语，并不能理解抽象语法图必须在代码生成器能够访问该图之前将所有短语关联起来。

另一方面，基于属性的方案可以很容易地捕获所有这些特征;元素的一个属性可以是与其关联的操作集。在这方面考虑增强类型模型似乎是合理的，我们认为这是未来工作中一个潜在的有趣领域。但是，我们注意到，如第2节所述，基于类型的方案已经在设计级别适当地使用。此外，我们注意到，面向应用程序的属性提供了一个很好的工具，用于驱动元素类型的一组操作的设计，或证明其适用性。

回到处理和数据视图之间的相互依赖关系，我们可以看到数据视图集中于描述每个数据结构时重要的特定面向应用程序的属性，而处理视图集中于每个处理元素的功能属性。这些观点实际上是互补的。事实上，如果我们描述数据视图(如图3所示)，并将其与图2所示的processing视图进行比较，那么对应关系就变得相当明显。

从这个例子中得出的重要架构考虑可以总结如下:

• 表单描述必须包含元素之间的关系和约束，包括相对权重和首选项;
• 目前基于类型的元素表征方案是不充分的;
• 处理和数据视图之间存在一种自然的相互依赖关系，可以提供对体系结构的补充描述。

image.png

4.3 并行处理，共享数据结构架构 Parallel Process, shared data structure architecture

假设性能是最重要的，比如希望尽可能优化编译器的速度。一种可能的解决方案是采用一种体系结构，该体系结构将处理元素视为由共享内部表示驱动的独立进程——也就是说，连接的元素是共享表示，每个处理元素执行即时评估。图4描述了该体系结构的pld和部分流程视图，显示了内部表示与lexer、解析器和语义器之间的关系。(在本例的其余部分中，我们只考虑这三个处理元素。)

该体系结构中共享内部表示的面向应用程序的属性要比前一个示例中给出的属性复杂得多，也有趣得多。特别是，一些处理元素正在检查内部表示的状态，并且是同时进行的。这意味着面向应用程序的属性必须提供处理元素之间的协调和同步。我们首先给出内部表示可能显示的基本属性:

请注意，这些属性暗示使用了令牌和短语，但是相关短语是累积的(请考虑“has-phrase”与“have-correlate -phrase”)。

由于处理元素的并行行为，必须显式地描述各种基本属性之间的相互关系。存在许多适合进行此类描述的表示法，包括并行路径表达式[6]、约束表达式[1]和petri网[16]。在这个例子中，我们使用并行路径表达式，其中逗号表示序列，加号表示一个或多个重复，星号表示零或多个重复，子表达式用括号括起来。同步点发生在面向应用程序的属性名称在不同的并行路径表达式中相同的地方。首先，给出了每个数据元素——令牌、短语和相关短语——的路径表达式:

image.png

因此，令牌被用来生成短语，短语之间相互关联，直到它们都被处理完。

到目前为止，我们给出的基本上是一个连接器视图(在本例中，也就是一个数据视图)。将注意力集中在processing视图上，我们可以描述每个处理元素如何转换内部表示，以及这些处理元素如何同步:

image.png

一个有趣的问题是这个体系结构如何与前一个体系结构相关联。事实上，将类似架构关联起来的能力是软件过程的一个重要方面;一个例子是“竞争性”架构的评估。当然，具有共同风格的架构捕获了关系的某些部分。但是，如果使用面向应用程序的属性，还可以说得更多。特别是，我们可以在不同的体系结构的属性之间画出相关性。下表显示了其中的一些相关性。

image.png

在这种情况下，相关性表示处理的共同点，例如，可以更好地理解处理元素的可重用性。

这个例子的要点可以总结为:

• 处理元素与前一架构基本相同，但具有不同的“控制点”属性;
• 该体系结构的形式比前一种更复杂——有更多面向应用的属性，这些属性需要更丰富的表示法来表示它们及其相互关系;
• 我们仍然从处理/数据/连接器视图的相互依赖中获益，尽管更加复杂;
• 面向应用程序的属性在关联类似的体系结构时很有用。

5.从软件架构中获得的一些好处

我们之前已经提到了在需求和设计的上下文中软件架构的使用。软件体系结构提供了满足系统需求的框架，为系统的设计和实现提供了技术和管理依据。我们还希望详细讨论两个好处:软件体系结构规范将使我们能够执行的分析类型和我们从软件体系结构方法中获得的重用类型。

5.1软件架构与分析

除了提供清晰和精确的文档外，规范的主要目的是提供文档的自动分析，并暴露各种各样的问题，否则这些问题将无法检测到。我们希望执行的分析主要有两类:一致性和依赖性分析。一致性发生在几个方面:体系结构和体系结构风格中的一致性、体系结构与需求的一致性以及设计与体系结构的一致性。就像Inscape[14]规范地自动管理接口规范和实现之间的相互依赖一样，我们也希望能够管理需求、体系结构和设计之间的相互依赖。

因此，我们希望至少提供和支持以下类型的分析:

• 架构风格约束的一致性;
• 架构风格满意度研究
• 架构约束的一致性;
• 设计对架构的满意度;
• 架构与设计、架构与需求之间依赖关系的建立;
• 确定体系结构或体系结构风格变化对设计和需求的影响，反之亦然。

5.2架构及使用和重用的问题

提高设计人员和程序员生产力的一个重要方面是能够建立在其他人的努力之上——也就是说，使用和重用组件，不管它们是作为另一个系统的一部分还是作为标准组件目录的一部分。

构件的可重用性问题一直受到人们的关注。找到组件对于减少系统中工作和代码的重复可能很重要，但它不是有效使用标准化组件的主要问题。例如，在数学库中查找组件不是问题。主要问题是理解库中包含的概念。如果理解了这些组件，通常就可以在库中找到要使用的适当组件。如果它们不被理解，那么浏览只会在获得适当概念的同时有所帮助。

体系结构中的主要焦点是重要属性和关系的一致性——对体系结构、设计和系统实现所需的组件类型的约束。考虑到这是使用和重用的基础，架构师、设计人员或实现人员可能能够选择适当的体系结构元素、设计元素或实现的代码，以满足适当级别的特定约束。

此外，可以将以前实现的软件的各个部分分开，从中选择有用的部分。例如，来自另一个系统的组件的设计可能具有刚好满足特定体系结构元素的体系结构约束，但是实现受到约束，以便与其他系统约束相结合。解决方案是使用设计而不是实现。只有识别体系结构、设计和实现约束，并使用它们来满足体系结构、设计和实现的期望目标，这才可能实现。

重用组件的重要经验是，当组件的规范在体系结构级别受到的约束最少时，重用的可能性最大。实现级的组件重用通常太晚，因为实现元素常常包含太多约束。此外，在体系结构级别上考虑重用可能会导致开发走上一条不同的、同样有效的解决方案之路，但这条路会导致更大的重用。

6结论

在过去的几年里，我们一直致力于改进与大型、复杂的软件系统相关联的软件过程。我们已经开始相信软件架构可以在这个过程中扮演重要的角色，但是它既没有得到充分利用，也没有得到充分开发。我们已经开始通过建立对软件体系结构和体系结构风格的直觉和上下文来解决这种情况。我们已经制定了一个软件体系结构模型，它强调数据、处理和连接的体系结构元素，突出它们的关系和属性，并捕获对它们的实现或满足的约束。此外，我们已经开始描述架构描述技术及其支持基础设施的必要特征。在这样做的过程中，我们为未来的研究确定了一个方向，该方向应该确立软件架构的首要地位。

其他人已经开始关注软件架构。三个最相关的是Schwanke等人、zachman和Shaw。

Schwanke等人将架构定义为组件之间允许或允许的连接集。我们同意架构的这个方面很重要，但是我们认为架构不仅仅是组件和连接，正如我们在本文中演示的那样。

Zachman[23]使用构建体系结构的隐喻来构建信息系统的体系结构。他利用了不同体系结构文档的概念，提供了构建信息系统中各种文档应该是什么的视图。架构师是用户和系统构建者之间的中介。各种文档提供的各种视图的不同部分产品- - - - - -用户视图中,承包商的观点,等等。他的工作与我们的不同之处在于,他提出一个具体的建筑为一个特定的应用领域,而我们正试图定义学科的哲学基础,以确定的符号表达各种架构文档的规范,并决定如何使用这些文档在自动化方面。

Shaw[21]是最接近我们的。她采用编程语言设计器的观点，从各种系统中抽象组件类、组合方法和模式。这在某种程度上与我们分别对处理和数据元素、连接元素和体系结构样式的概念相对应。我们的工作与Shaw的工作的一个主要区别是，她采用了传统的基于类型的方法来描述架构，而我们采用了更具表现力的基于属性的方法。我们的方法似乎能够更好地更直接地捕捉加权属性和关系的概念。Shaw将现有体系结构的各种属性和关系抽象出来，并将它们包含在一组组件和组合类型中，这种方法显得相当有限。事实上，她正在寻求提供一组有用的架构元素，可以将它们混合和匹配来创建架构。Shaw的方法显然是一个重要而有用的方法，它在促进对基本和重要的建筑概念的理解方面起了很大的作用。另一方面，我们的方法强调了底层属性和关系的重要性，它们是一种更通用的机制，可以用来描述元素和组合的特定类型，从而提供了一个选择范围。

综上所述，我们经过以下推测:
也许软件系统的开发和演进如此缓慢的原因是我们培训了木匠和承包商（trainedcarpenters and contractors），而没有培训架构师。