249.软件体系结构起源和发展

 

1.软件体系结构的定义

　　软件体系结构尚处在发展期，对于其定义，目前学术界尚未形成统一意见，不同学者有不同的看法。以下介绍并分析几个具有代表性的定义。

 

　　定义1  IEEE610. 12—1990软件工程标准词汇中的定义

　　体系结构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织以及指导上述内容设计与演化的原理，即

　　软件体系结构={构件，连接件，环境，原理}

 

　　定义2  Booch&Rumbaugh&Jacobson的定义

　　体系结构是一系列重要决策的集合，这些决策与以下内容相关：软件的组织、构成系统的结构元素及其接口的选择，这些元素在相互协作中明确表现出的行为、这些结构元素和行为元素进一步组合构成的更大规模的子系统，和引导这一组织(包括这些元素及其接口、它们的协作、它们的组合)的体系结构风格，即

　　　软件体系结构={组织，元素，子系统，风格}

 

　　定义3  Bass的定义

　　程序或计算系统的软件体系结构是系统的一个或多个结构，包括软件构件、构件的外部可视属性和构件之间的关系。这个定义有以下含义：首先，体系结构定义了构件，描述了构件间如何交互，这意味着体系结构略去了那些仅与某构件自身有关的信息。同时，这个定义明确指出系统可以包含多个结构，但没有其中的哪一个可以被称为是体系结构。这个定义还意味着每一个软件系统都有一个体系结构，因为每个软件系统都是由若干构件及其之间的关系构成的。此外，只要一个构件的行为可以被其他构件观察或辨明，这个构件就是体系结构的一部分。 

　　这里的外部可视属性，是指其他构件认为该构件所具备的特征，如所提供的服务、具有的性能特点、错误处理机制、共享资源的用法等。需要注意的是，此定义中，特意未指明什么是构件，什么是关系。构件既可以是对象，也可以是进程，还可以是函数库或是数据库。

 

　　定义4  Shaw的定义

　　在第一届软件系统体系结构国际研讨会上，Mary Shaw对于当时术语使用的混乱情况予以了澄清：不同学者的软件体系结构定义之间并不相互抵触，在回答什么是软件体系结构这样的问题时，也并没有根本的冲突。实际上，它们代表了软件体系结构研究者对于体系结构研究重点的一系列不同看法。在会上，Shaw对当时的各种观点做了如下的分类。

(1) 结构模型：结构模型认为，软件体系结构由构件、构件之间的连接和一些其他方面组成。这些方面包括如下几类：

　　· 配置，风格；

　　· 约束，语义；

　　· 分析，属性；

　　· 原理，需求。

 

(2) 框架模型：框架模型的观点与结构模型相似，但其重点在于整个系统的连贯结构(这种结构通常是唯一的)，这与重视其组成恰好相反。框架模型常以某种特定领域或某类问题为目标。

 

(3) 动态模型：动态模型强调系统的行为质量。“动态”可以有多种含义。它可以是指整个系统配置的变化，也可以是指禁止预先激活了的通信或交互，还可以是指计算中表现出的动态特性，如改变数据的值。

 

(4) 过程模型：过程模型关注系统结构的构建及其步骤和过程。在这一观点下，体系结构是所进行的一系列过程的结果。

 

 

　　定义5  Garlan&Shaw的模型

　　　软件体系结构={构件，连接件，约束}

　　(1) 构件(Component)可以是一组代码，如程序的模块，也可以是一个独立的程序，如数据库服务器。构件是相关对象的集合，运行后实现某计算逻辑。它们或是结构相关或是逻辑相关。构件相对独立，仅通过接口与外部相互作用，可作为独立单元嵌入到不同应用系统中。构件的定制和规范化对于实现构件的重用有重要意义。



　　(2) 连接件(Connector)可以是过程调用、管道、远程过程调用等，用于表示构件之间的相互作用，它把不同的构件连接起来构成体系结构的一部分。连接件也是一组对象。它一般表现为框架式对象或转换式对象(调用远程构件资源)，例如“桩”、“代理”对象等。

　　(3) 约束(Constrain)一般为对象连接时的规则，或指明构件连接的姿态和条件。例如，上层构件可要求下层构件的服务，反之不行；两个对象不得以递归方式发送消息；代码复制迁移的一致性约束；在什么条件下此种连接无效等。主要针对连接件的一些约束规则。

 

 

　　定义6  Perry&Wolf的模型

　　软件体系结构是一组具有特定形式的体系结构元素(Elements)。这组元素分为3类：负责完成数据加工的处理元素(Processing Elements)、被加工的数据元素(Data Elements)和用于把体系结构的不同部分组合连接到一起的连接元素(Connecting Elements)。软件体系结构形式由专有特性和关系组成。专有特性用于限制软件体系结构元素的选择，关系用于限制软件体系结构元素组合的拓扑结构。在多个体系结构方案中选择合适的体系结构方案往往基于一组准则，即

　　　软件体系结构={元素，形式，准则}

 

 

　　定义7  Garlan&Perry的定义

　　1995年，David Garlan和Dewne Perry在IEEE软件工程学报上所做的特约评论中提出：软件体系结构是一个程序或系统各构件的结构、它们的相互关系以及进行设计的原则和指导方针，这些原则和方针随时间变化而变化。

 

　　定义8  Boehm的模型

　　软件体系结构包括系统构件、连接件、约束的集合，反映不同人员需求的集合，以及准则的集合。其中，这些准则能够说明由构件、连接件和约束所定义的系统在实现时是如何满足系统不同人员需求的，即

　　　软件体系结构={构件，连接件，约束，不同人员的需求，准则}

　　比较上述体系结构定义，可以发现：尽管各种定义都从不同的角度关注软件体系结构，研究对象各有侧重，但其核心内容都是软件的系统结构，并且都蕴含构件、构件之间的关系、构件和连接件之间的关系等实体。

 

　　定义9 国内

　　根据国内普遍认可的看法，可以将体系结构定义为构件、连接件和约束。软件体系结构指可预制和可重构的软件框架结构。构件是可预制和可重用的软件部件，是组成体系结构的基本计算单元或数据存储单元；连接件也是可预制和可重用的构件部件，是构件之间的连接单元；构件和连接件之间的关系用约束来描述。这样就可以把软件体系结构写成：

　　　体系结构(Architecture)=构件(Components)+连接件(Connectors)+约束(Constraints)

　　除了构件、连接件和约束这3个最基本的组成元素，软件体系结构还包括端口(Port)和角色(Role)两种元素。构件作为一个封装的实体，仅通过其接口与外部环境交互，而构件的接口由一组端口组成，每个端口表示了构件和外部环境的交互点。连接件作为建模软件体系结构的主要实体，同样也有接口。连接件的接口由一组角色组成，连接的每个角色定义了该连接表示的交互的参与者。图2-1形式化地描述了软件体系结构的基本概念。

 

 图2-1  软件体系结构的基本概念

 

 

　　其中：

　　软件体系结构∷= 软件体系模型 | 体系结构风格

　　软件体系模型∷= { 构件，连接件，约束 }

　　构件∷= { 端口1，端口2，…，端口ｎ }

　　连接件∷= { 角色１，角色２，…，角色m  }

　　约束∷= { (端口i，角色j)，… }

　　体系结构风格∷= { 管道-过滤器，层次系统，客户/服务器，…，解释器 }

 

　　下面，我们对构件、连接件、约束这3个基本概念作进一步的解释。

 

　　1．构件

　　一般认为，构件是指具有一定功能、可明确辨识的软件单位，并且具备以下特点：语义完整、语法正确、有可重用价值。这就意味着，在结构上，构件是语义描述、通信接口和实现代码的复合体。更具体地说，可以把构件视为用于实现某种计算逻辑的相关对象的集合，这些对象或是结构相关或是逻辑相关。在体系结构中，构件可以有不同的粒度。一个构件可以小到只有一个过程，也可以大到包含一个应用程序。它可以包括函数、例程、对象、二进制对象、类库、数据包等。

　　构件内部包含了多种属性，如端口、类型、语义、约束、演化、非功能属性等。端口是构件与外部世界交互的一组接口。构件端口说明了构件提供哪些服务(消息、操作、变量)。它定义了构件能够提交的计算委托及其用途上的约束。构件类型是实现构件重用的手段。构件类型保证了构件自身能够在体系结构的描述中多次实例化。

　　从抽象程度来看，构件是对一组类的组合进行封装，并代表完成一个或多个功能的特定服务，也为用户提供了多个接口。构件之间是相对独立的。构件隐藏其具体实现，只通过接口提供服务。如果不用指定的接口与之通信，则外界不会对它的运行造成任何影响。因此，构件可以作为独立单元被应用于不同的体系结构和软件系统中，实现构件的重用。构件的使用与它的开发也是独立的。

 

　　2.连接件

　　连接件是用来建立构件间的交互以及支配这些交互规则的体系结构构造模块。构件之间的交互包括消息或信号量的传递，功能或方法调用，数据的传送和转换，构件之间的同步关系、依赖关系等。在最简单的情况下，构件之间可以直接完成交互，这时体系结构中的连接件就退化为直接连接。在比较复杂的情况下，构件间交互的处理和维持都需要连接件来实现。常见的连接件有管道(在管道-过滤器结构中)、通信协议或通信机制(在客户/服务器结构中)等。

　　连接件的接口由它与所连接构件之间的一组交互点构成，这些交互点称做角色。角色代表了所连接构件的作用和地位，并体现了连接所具有的方向性。因此，角色存在主动和被动、请求和响应之分。

　　体系结构级的通信需要有复杂协议来表达，为了抽象这些协议并使之能够重用，可以将连接件构造为类型。

　　连接件的主要特性有可扩展性、互操作性、动态连接性和请求响应特性。连接件的可扩展性是连接件允许动态改变被关联构件的集合和交互关系的性质。互操作性指的是被连接的构件通过连接件对其他构件进行直接或间接操作的能力。动态连接性是对连接的动态约束，即连接件对于不同的所连接构件实施不同的动态处理方法的能力。请求响应特性包括响应的并发性和时序性。在并行和并发系统中，多个构件有可能并行或并发地提出交互请求，这就要求连接件能够正确协调这些交互请求之间的逻辑关系和时序关系。

　　对于构件而言，连接件是构件的黏合剂，是构件交互的实现。连接件和构件的区别主要在于它们在体系结构中承担着不同的作用。连接件也是一组对象。它把不同的构件连接起来，形成体系结构的一部分，一般表现为框架式对象或转换式对象(调用远程构件资源)。

 

　　3．约束(配置)

　　体系结构的约束描述了体系结构配置和拓扑的要求，确定了体系结构的构件与连接件的连接关系。它是基于规则和参数配置的。体系结构约束提供限制以确定构件是否正确连接、接口是否匹配、连接件构成的通信是否正确，并说明实现所要求行为的组合语义。

　　体系结构往往用于大型的、生存期长的软件系统的描述。为了更好地在一个较高的抽象层上理解系统的分析和设计，同时为了方便系统开发者、使用者等多种有关人员之间的交流，需要简单的、可理解的语法来配置结构化(拓扑的)信息。理想的情况是从约束说明中澄清系统结构，即不需研究构件与连接件就能使构件系统的各种参与者理解系统。

 

 

 

 

 

 2.软件体系结构的研究意义

　　软件体系结构是软件系统的高级抽象，往往体现了系统开发中最早做出的决策。它体现了根本性的系统设计思路，对系统起着最为深远的影响。体系结构在明确了系统的各个组成部分的同时，也限定了各部分间的交互方式。这将进一步影响到开发资源的配置和开发团队的组织等其他方方面面的开发活动，并影响着最终的软件产品质量。 

　　在大型软件系统中，软件体系结构是决定系统能否顺利实现的关键因素之一，不当的体系结构会给整个系统带来灾难性的后果。

 

　　良好的体系结构对于软件系统的重要意义在软件生命周期中的各个阶段都有体现，这主要有如下4个方面。

　　1．对系统分析的意义

　　在系统分析阶段，软件体系结构发挥着巨大作用。

　　一方面，借助于软件体系结构进行描述，可以使问题得以进一步抽象，使整个系统更易于被系统分析设计人员把握，更清晰地认识系统，完善对系统的理解。除此之外，体系结构对于系统分析带来的优势还体现在，它为系统分析设计人员提供了新的思路。比如，在更高层次上进行系统一致性检查、使用成熟的软件体系结构风格等。

　　另一方面，它能够帮助软件系统的各有关权益方(客户、用户、项目管理人员、设计开发人员以及测试人员等)形成统一认识，互相交流。交流是软件开发的重要组成部分。在软件开发活动中，各有关权益方承担着不同角色，关注同一软件系统不同的侧面，这要求他们要从不同的角度交流对共同面对的软件系统的认识。 

　　例如，用户关心系统是否满足可用性及可靠性需求；客户关心此结构能否按期按预算实现；管理人员担心在经费支出和进度条件下，按此体系结构能否使开发组成员在一定程度上独立开发，并有条不紊地有序地交互；开发人员关心达到全部目的的策略。体系结构代表了系统的公共的高层次的抽象，是大家都关心的一个重要因素。它作为项目参与人员共同使用的语言，还具有很强的描述能力，起到了难以替代的沟通作用。系统的大部分有关人员(即使不是全部)能把它作为建立互相理解的基础，通过体系结构的概念、术语和规范，设计者与用户之间、设计者之间等各方面相关人员可以更好地彼此理解。

 

　　2.对软件开发的意义

　　软件体系结构代表了系统早期的设计决策。与开发、设计、编码或运行服务及维护阶段相比，早期设计决策的处理难度最大，对系统的生命期的影响也最大。同时，软件体系结构也难于改变，会对整个系统开发活动造成深远影响。

　　软件体系结构是系统实现的基本约束，即系统的后继开发工作要遵循体系结构所描述的设计决策。每个构件或连接件必须满足体系结构规格说明中指定的功能、语义和接口，并且按体系结构配置中所规定的方式完成交互。这样，构件或连接件的开发人员在体系结构给定的约束下进行工作，他们既不关心其他构件或连接件的开发，也不会对其产生影响。而体系结构设计者也不必设计算法或精通编程语言。

　　软件体系结构决定了开发和维护项目的组织活动。软件体系结构也会反映到开发工作的分解，以及项目的人员组织。项目组成员还要使用构件的接口规格说明相互交流。即使到了维护期，项目维护人员的组织形式也常常要依据特定的软件体系结构成分来安排。此外，对于项目组新成员，可以用软件体系结构作为培训基础或高层次的系统概述，使他们迅速、准确地认识系统和自己的任务，快速进入开发角色。

　　软件体系结构对于软件质量控制有重要意义。软件质量特性可分为两类：第一类是可以通过运行软件并观察其效果来度量的特性，如功能、性能、安全性及可靠性等；第二类是指那些无法通过观察系统来度量，只能通过观察开发活动或维护活动来考察的特性，包括各种可维护性问题，如可适应性、可移植性、可重用性等(例如，可重用性依赖于系统中的构件与其他构件的联系情况)。软件体系结构在很大程度上确定了系统是否能达到其需求的质量特性。 

　　使用软件体系结构的一些评估技术(如SAAM)，对软件体系结构加以分析，能够对软件的某些质量特性加以预测。但同时，也必须认识到，好的软件体系结构是成功的必要条件，但不是充分条件。仅重视软件体系结构并不能保证系统所要求的功能和质量——低劣的设计及实现都会损害整个体系结构。

 

　　3．对软件重用的意义

　　重用是提高软件开发效率、保证软件质量的重要手段。软件开发经历了从机器语言、汇编语言、结构化程序设计语言、面向对象程序设计语言、形式化(非形式化)规格说明语言(如体系结构描述语言)的发展过程，越来越适合开发人员的思维活动模型，代码重用的级别也在不断地提升。体系结构技术的研究，使软件重用从代码重用发展到设计重用和过程重用，实现多层次的软件重用。

　　构件的重用是体系结构良好的软件系统最基本的一点。面向体系结构的开发方法常常注意构件的组合与装配，而不一定把编程作为主要活动。有效地利用标准构件，或是识别并重用系统内部的构件，或是购买第三方构件，只要这些构件与当前体系结构相容，都能减少开发中的重复劳动和系统中的重复代码。体系结构起了组织产品的构件、接口及运行的作用。这里要着重指出的是标准构件的应用。应用标准构件库的关键在于要能够从整体上对库中构件进行把握。一旦做到了这点，就可以快速、灵活地在构件库中选择出合适的构件应用到系统中去；反之，构件的选取就只能通过反复地浏览来寻找，这实际上影响到了体系结构所带来的优势，造成了不必要的资源浪费。

　　体系结构良好的软件系统中，不仅构件库能够重用，还可以在更高层次上实现软件子系统乃至软件系统框架的重用。软件体系结构级的重用意味着体系结构的决策能在具有相似需求的多个系统中发生影响，这比代码级的重用要有更大的好处。通过对体系结构的抽象可以使设计者能够对一些实践证明有效的体系结构构件进行重用，从而提高设计效率和可靠性。在设计过程中我们常常会发现，对一个体系结构构件稍加抽象，就可以将它应用到其他设计中去，这样会大大降低设计的复杂度。 

　　例如，我们在某个设计中采用了管道-过滤器风格，当我们将系统映射到Unix系统中时，我们就会发现Unix系统已经为我们提供了功能丰富的管道-过滤器功能，这样我们就可以充分利用Unix系统提供的这些构件来简化我们的设计和开发。当前，针对特定领域的体系结构，人们开展了许多研究和实践工作。这在某种意义上也是一种重用。软件重用的层次越高，所带来的收益也就越大。某些情况下，重用的设计方案本身也许不是最适合该系统的，但是从整体上权衡，通过重用带来的成本节约和质量提供能够让重用变得非常值得。

　　软件体系结构有利于形成完整的软件生产线。1976年Parnas提出了发展软件族的软件生产线。软件族的软件生产线成功的关键问题是设计决策的次序问题，要求对于最容易发生变动的决策应当尽量放在最迟作出。事实上，软件族的软件生产线代表了早期决策的总和，将影响软件族的软件生产线的全体成员。可以说，体系结构在一定程度上限制了设计选择的范围或内容。要认识到这种决策对于每一个部分来说不一定是最优，但其优点一般可以补偿失去的特定领域优化的损失。

 

 

　　4．对系统演化的意义

　　对软件系统的演化过程中，维护人员需要不断地进行调整、修改、增加新的功能或构件等工作。通常情况下，软件系统的开发成本中，有80%是在初次投入使用之后产生的。因此，解决好系统演化阶段的开发问题具有重要意义。

　　软件体系结构决定着系统构件的划分和交互方式。一方面，在设计系统的体系结构之初，就应当充分考虑到将来可能的系统演化；另一方面，在进行系统演化阶段的开发时，由于体系结构充分地刻画了当前系统，清晰地描述了构件及其相互关系和整个系统的框架，所以应当充分利用。

　　以现有体系结构为基础，把握需要进行的系统变动，在系统范围内综合考虑，有助于确定系统维护的最优方案，更好地控制软件质量和维护成本。软件为主的系统总是存在着“利用软件作为增加或修改系统总体功能的工具”的倾向。重要的是要决定何时进行改动，确定哪种改动风险最小，评估改动的后果，仲裁改动的顺序及优先级。所有这些都需要深入地洞察系统各部分的关系、相互依存关系、性能及行为特性。而在软件体系结构这一级进行讨论，就能提供这种观察力，更重要的是软件体系结构可以把可能发生的变动分为3类：局部的、非局部的和体系结构级的。 

　　局部的是指只要修改单个构件本身；非局部的是指要修改几个构件，但不影响基础体系结构的变动；而体系结构级是指会影响各部分的相互关系，甚至要改动整个系统。显然，局部改动应是最经常发生的，也是最容易进行的。软件体系结构承担了“保证最经常发生的变动是最容易进行的”这一重任。

 

 

3.软件体系结构的发展历程

　　软件工程作为一门独立的学科，其发展已逾30年。无论从应用规模还是从技术水平看，计算机软件产业所经历的发展都是迅猛的。这体现在诸多方面。首先，软件系统的应用领域从实验室渗透到了人类社会的各个角落。最初的软件是以穿孔纸带或卡片的形式出现在实验室和机房中用于科学计算的；而在今天的人类社会中，各种软件系统运行在从手持设备(如手机)到大型机(如进行天气预报的服务器)的各种规模和用途的信息处理设备上。其次，软件系统的规模也迅速增长。 

　　从微机不断跃增的内存配置就可以明显看出这一点。1981年，IBM公司推出的第一台PC机的配置是16 KB的内存；2003年，主流PC机的内存配置是256 MB；2008年，主流PC机的内存配置是2 GB。此外，随着计算机产业的发展，软件成本也在增长。20世纪50年代，软件成本在整个计算机系统成本中所占的比例为10%～20%。到20世纪60年代中期，软件成本在计算机系统中所占的比例已经增长到50%左右。相反，计算机硬件价格随着技术进步和生产规模扩大却在不断下降。软件成本在计算机系统中所占的比例越来越大。 

　　下面是一组来自美国空军计算机系统的数据：1955年，软件费用约占总费用的18%，1970年达到60%，1975年达到72%，1980年达到80%，1985年达到85%左右。

　　在软件应用规模和应用领域迅速扩大的同时，软件开发技术也在发生着根本性的变革。软件规模的迅速增长使得软件开发成为了一项过去难以想象的系统工程。根据微软公司公布的数据， Windows 2000开发过程中测试用代码行数超过1000万行，测试兼容性的应用软件数量约1000种，应用软件测试中所使用的脚本程序约6500种，每月备份的数据约88 TB，每晚模拟打印数量约25万页，每周刻录CD约12 000盘。

　　在此过程中，软件体系结构也经历了与之相对应的一系列变革，由最初的模糊概念发展成为一门日益成熟的技术。下面我们分阶段进行讨论。

 

 

3.1  “无体系结构”设计阶段

　　1946年，随着具有里程碑意义的ENIAC机的问世，软件行业开始在美国和欧洲的实验室出现。1955～1965年间，运算速度越来越快、价格越来越低的新计算机不断涌现。这期间的软件多数应用于学术界，或者是政府、军队及私人公司。但是，由于当时的计算机硬件向着专用方向发展，科学与商业领域使用完全不同的机器硬件。不断地针对不同计算机编写软件让软件工作人员应接不暇，反复地开发相同或类似的软件使得软件研究者开始着手处理软件的移植问题，即设法使一种机器的汇编语言程序能够自动移植到另一台机器上去。但研究人员很快发现这难以实现，大量复杂代码仍必须由程序员进行改写。

　　在这样的背景下，高级语言应运而生。FORTRAN语言诞生于20世纪50年代中期，是最早发布的高级语言；50年代后期，COBOL语言出现；60年代早期，ALGOL语言出现。而在当时，高级语言不能被程序编制人员所接受，他们认为真正的程序员应使用汇编语言。

　　总的说来，20世纪70年代以前，尤其是在以ALGOL 68为代表的高级语言出现以前，软件开发基本上都是用汇编程序设计。尽管此阶段软件工作者开始逐渐形成模块编程的方法，但软件投入的资金和人力无法预测，软件完工的时间无法确定，软件的可靠性无法控制等问题开始表露出来，软件危机从此阶段开始出现。一个著名的例子是1962年7月美国飞往金星的火箭控制系统中的指令，“DO 5 I=1, 3”误写成“DO 5 I=1.3”，导致火箭偏离轨道，被迫炸毁。

　　因为此阶段系统规模较小，很少明确考虑软件体系结构，所以一般不存在软件系统的建模工作。

 

 

 3.2  萌芽阶段

　　在1968年NATO会议上，“软件工程”的概念首次被提出。自此，围绕软件项目，开展了有关开发模型、方法以及支持工具的研究。其主要成果有：提出了瀑布模型，开发了一些结构化程序设计语言(例如PASCAL语言、Ada语言)，结构化软件开发技术，并且围绕项目管理提出了费用估算、文档复审等方法和工具。

 　　结构化软件开发技术在20世纪70年代中后期出现，以PASCAL、COBOL等程序设计语言和关系数据库管理系统为标志，以强调数据结构、程序模块化结构为特征，采用自顶向下逐步求精的设计方法和单入口单出口的控制结构。随着结构化开发技术的出现与广泛应用，软件开发中出现了以数据流设计和控制流设计为主要任务的概要设计和详细设计。伴随着结构化软件技术而出现的软件工程方法(包括CASE工具)，使软件工作的范围从只考虑程序的编写扩展到从定义、编码、测试到使用、维护等活动的整个软件生命周期。

　　 总的说来，在此阶段，软件体系结构已经是系统开发中的一个明确概念。结构化程序中，由语句构成模块，模块的聚集和嵌套又构成层层调用的高层结构。这种程序(表达)结构和(计算的)逻辑结构的一致性形成了结构化程序的体系结构。

　　结构化程序设计时代程序规模不算大，同时，采用结构化程序设计方法进行自顶向下逐步求精的设计，并注意模块的耦合性，就可以得到相对良好的结构。因此，体系结构问题并不是当时软件开发中的主要问题，也就没有开展深入的研究工作。

 

 

 3.3  初级阶段

　　20世纪80年代初，面向对象开发技术逐渐兴起。随着面向对象技术成为研究的热点，出现了几十种支持软件开发的面向对象方法。其中，Booch、Coad/Yourdon、OMT和Jacobson的方法在面向对象软件开发界得到了广泛的认可。

　　面向对象开发技术以对象作为最基本的元素，将软件系统看成是离散的对象的集合。一个对象既包括数据，也包括行为。 

 　　面向对象方法都支持3种基本的活动：识别对象和类，描述对象和类之间的关系，以及通过描述每个类的功能定义对象的行为。对象技术的优点在于，它能让分析者、设计者及用户更清楚地表达概念，相互交流；同时，它作为描述、分析和建立软件文档的一种手段，大大提高了软件的易读性、可维护性、可重用性；使得从软件分析到软件设计的过渡非常自然，因此可显著降低软件开发成本。另外，面向对象技术中的继承、封装、多态性等机制，直接为软件重用提供了进一步的支持。在面向对象开发方法阶段，由于对象是对数据及其操作的封装，因而数据流设计与控制流设计统一为对象建模。 

 　　同时，面向对象方法还提出了一些其他的结构视图。如OMT方法提出了功能视图、对象视图和动态视图，Booch方法提出了类视图、对象视图、状态迁移图、交互作用图、模块图、进程图，UML则从功能模型、静态模型、动态模型、配置模型等方面描述应用系统的结构。

 　　从1994年开始，Booch、Rumbaugh和Jacobson三人经过共同努力，推出了统一建模语言UML(Unified Modeling Language)。它结合了Booch、OMT和Jacobson方法的优点，统一了符号体系，并从其他的方法和工程实践中吸收了许多经过实际检验的经验和技术。对象管理组织OMG于1997年11月正式采纳UML1.1作为建模语言规范，然后成立任务组不断修订。尽管UML取得了巨大成功，但仍然有一些批评意见。工业界的批评主要是，它的庞大和复杂使得多数用户难以实际应用或只能应用少许概念。学术界的批评则主要针对它在理论上的缺陷和错误，包括语言体系结构、语法、语义等方面的问题。

 　　随着抽象数据类型和面向对象技术的出现，体系结构研究逐渐得到重视。这是由以下因素决定的：对象的封装减低了模块间的耦合，为构件层次上的软件重用提供了可能；此外，类库的构造、分布式应用系统的设计等规模大、复杂性高的系统，也需要对体系结构进行研究。

 

3.4  高级阶段

　　20世纪90年代后，软件开发技术进入了基于构件的软件开发阶段。软件开发的目标是软件具备很强的自适应性、互操作性、可扩展性和可重用性，软件开发强调采用构件化技术和体系结构技术。

　　软件构件技术与面向对象技术有着重要的不同。面向对象技术中的软件重用主要是源代码形式的重用，这要求设计者在重用软件时必须理解其设计思路和编程风格。软件构件技术则实现了对软件的最终形式——可执行二进制码的重用。这样，构件的实现是完全与实现语言无关的。任何一种过程化语言，从Ada到C到Java到C#，均可用来开发构件，并且任何一种程序设计语言都可以直接或稍作修改后使用构件技术。一个软件可被切分成一些构件，这些构件可以单独开发、单独编译，甚至单独调试与测试。当完成了所有构件的开发，再对它们加以组合，就得到了完整的软件系统。在投入使用后，不同的构件还可以在不影响系统的其他部分的情况下，分别进行维护和升级。

　　此阶段中，软件体系结构逐渐成为软件工程的重要研究领域，并最终作为一门学科得到了业界的普遍认同。在基于构件和体系结构的软件开发方法下，程序开发模式也相应地发生了根本变化。软件开发不再是“算法+数据结构”，而是“构件开发+基于体系结构的构件组装”。软件体系结构作为开发文档和中间产品，开始出现在软件过程中。有研究人员认为，“未来的年代将是研究软件体系结构的时代”。

 

3.5 综合　　

　　从软件技术的发展过程可以看出，在各个时期，软件体系结构的问题实际上总是存在的，但是它是随着软件系统的规模和复杂性的日益膨胀才逐渐表露、被人们发现和研究的。从最初的“无体系结构”设计到今天的基于体系结构的软件开发，软件体系结构技术大致经历了以下4个阶段：

• 　　(1) “无体系结构”设计阶段：开发主要采用汇编语言，规模一般较小。
• 　　(2) 萌芽阶段：主要采用结构化的开发技术。
• 　　(3) 初级阶段：主要采用面向对象的开发技术，从多种角度对系统建模(如UML)。
• 　　(4) 高级阶段：该阶段以Kruchten提出的“4+1”模型为标志。软件开发的中心是描述系统的高层抽象结构模型，相比之下，传统的软件结构更关心具体的建模细节。

　　软件体系结构技术仍存在诸多问题，如概念定义尚不统一、描述规范不能一致等。有研究人员认为在软件开发实践中软件体系结构尚不能发挥重要作用，软件体系结构技术仍有待研究、发展和完善。
　

 

4.软件体系结构的研究现状及发展方向

4.1 软件体系结构的研究现状

　　软件体系结构作为软件工程研究领域的一部分，已经取得了长足的发展，受到大多数软件系统设计和研究人员的重视。但当前，体系结构仍是一个处在不断发展中的新研究领域，许多定义还不够统一，归纳现有体系结构的研究活动，主要的讨论和研究大致集中在以下几个方面。　　

1．软件体系结构描述研究

　　构建软件体系结构的目的之一就是建立一个可供各种人员交流的平台，并且要具备系统架构级的可重用性。因此如何恰当、准确地对软件体系结构进行描述是至关重要的。这种描述应当能够为各种人员提供不同的视图以满足其不同的要求；同时，当要构建新的应用或对应用进行系统级更改时，这种描述应该能够快速提供可重用的系统架构视图或系统模块视图。这方面的研究包括软件体系结构描述语言、使用“4+1” 模型描述软件体系结构、使用UML描述软件体系结构等方面的研究。

　　1) 软件体系结构描述语言
　　现有的一些软件体系结构描述方法采用非形式化的方法，体系结构设计经常难以理解，难以对体系结构进行形式化分析和模拟，缺乏相应的支持工具帮助设计师完成设计工作。为了解决这个问题，用于描述和推理的形式化语言得以发展，这些语言就叫做体系结构描述语言(Architecture Description Language，ADL)，ADL寻求增加软件体系结构设计的可理解性和重用性。
　　ADL是这样一种语言，系统设计师可以利用它所提供的特性进行软件系统概念体系结构建模。ADL提供了具体的语法与刻画体系结构的概念框架。它使得系统开发者能够很好地描述他们设计的体系结构，以便与他人交流，能够用提供的工具对许多实例进行分析。
　　研究人员已经设计出了若干种ADL，典型的有Aesop、MetaH、C2、Rapide、SADL、UniCon和Wright等，尽管它们都描述软件体系结构，却有不同的特点：Aesop支持体系结构风格的应用；MetaH为设计者提供了关于实时电子控制软件系统的设计指导；C2支持基于消息传递风格的用户界面系统的描述；Rapide支持体系结构设计的模拟并提供了分析模拟结果的工具；SADL提供了关于体系结构加细的形式化基础；UniCon支持异构的构件和连接件类型，并提供了关于体系结构的高层编译器；Wright支持体系结构构件之间交互的说明和分析。
　　这些ADL及它们的支持工具、描述方法和形式各不相同，强调了体系结构不同的侧面，对体系结构的研究和应用起到了重要的作用，但也有负面的影响。每一种ADL都以独立的形式存在，描述语法不同且互不兼容。同时又有许多共同的特征，这使设计人员很难选择一种合适的ADL；大部分ADL都是领域相关的，不利于对不同领域的体系结构进行分析；一些ADL在某些方面大同小异，有很多冗余的部分。
　　针对这些不足，已出现一些交换语言，其目标是提供一个公共形式把各种语言综合起来，以此来综合不同的体系结构描述。ACME就是其中较有影响的一个，它的目标是抽取诸多ADL中与具体ADL无关的信息作为交换的依据，同时，允许并入相关信息作为保留的辅助信息。另外一个研究热点是开发基于XML的体系结构描述语言。XML是可扩展标记语言，它简单并易于实现，因此被工业界广泛使用。若能用XML来表示软件体系结构，必能极大推动软件体系结构领域的研究成果在软件产业界的应用。由于XML在体系结构描述上的许多优点，研究者们已经开发出了不同的基于XML的体系结构描述语言，如XADL1.0、XBA、XCOBA等。

　　2) 使用“4+1” 模型描述软件体系结构
　　按照一定的描述方法，用体系结构描述语言对体系结构进行说明的结果称为体系结构的表示，而将描述体系结构的过程称为体系结构构造。在体系结构描述方面，Kruchten提出的“4+1”模型是当前软件体系结构描述的一个经典范例，该模型由逻辑视图、开发视图、过程视图和物理视图组成，并通过场景将这4个视图有机地结合起来，比较细致地描述了需求和体系结构之间的关系。
　　“4+1”模型实际上使得有不同需求的人员能够得到他们对于软件体系结构想要了解的东西。系统工程师先从物理视图，然后从过程视图靠近体系结构。最终使用者、客户、数据专家从逻辑视图看体系结构；项目经理、软件配置人员从开发视图看体系结构。

　　3) 使用UML描述软件体系结构
　　Booch从UML的角度给出了一种由设计视图、过程视图、实现视图和部署视图，再加上一个用例视图构成的体系结构描述模型。Medividovic则总结了用UML描述体系结构的三种途径：不改变UML用法而直接对体系结构建模；利用UML支持的扩充机制扩展UML的元模型对体系结构建模概念的支持；对UML进行扩充，增加体系结构建模元素。本书第3章介绍了不改变UML用法而直接对体系结构建模的方法。UML的静态建模机制包括用例图、类图、对象图、包、构件图和部署图。UML的动态建模机制包括顺序图、协作图、状态图和活动图。可以使用UML对构件交互模式进行静态建模和动态建模。

　　2.软件体系结构设计研究

　　软件体系结构设计研究包括体系结构风格研究、体系结构设计原理、设计模式和设计方法研究。
　　1) 体系结构风格研究
　　体系结构设计研究的重点内容之一就是体系结构风格的研究。人们在开发不同系统时，会逐渐发现一类系统的体系结构上有许多共性，于是抽取出这些共性构成一些富有代表性和被广泛接受的体系结构风格。所以说体系结构风格是用来刻画具有相似结构和语义性质的一类系统族的。它定义一组构件、连接件的类型以及它们之间应该如何连接的约束。
　　一般来说，一个系统不一定只具有一种风格，在不同层次或抽象级别上，可具有多种风格。虽然系统组织方式可以是无穷的，但如果能用少量的风格类型表达出较多的系统组织方式，不仅可以缩短系统分析设计的时间，还能大大提高大规模软件重用的机会。
　　Garlan和Shaw给出了对通用体系结构风格的分类：数据流风格、调用/返回风格、独立构件风格、虚拟机风格和仓库风格。

　　2) 体系结构设计原理
　　参照软件工程、结构化程序设计和面向对象程序设计原理，结合软件体系结构设计本身的特点，可以总结出软件体系结构设计过程中用到的原理主要有以下几个：抽象、封装、信息隐藏、模块化、注意点分离、耦合和内聚、接口和实现分离、分而治之、层次化等。

　　3) 体系结构设计模式
　　设计模式的概念最早是由美国的一位叫做Christopher Alexander的建筑理论家提出来的，他试图找到一种结构化、可重用的方法，以在图纸上捕捉到建筑物的基本要素。后来被作为总结软件设计，特别是面向对象设计的实践和经验而提出。在几十年的软件设计研究和实践中，设计人员和程序员积累了大量的实际经验，发现并提出了大量在众多应用中普遍存在的软件结构和结构关系，模式被用于软件体系结构设计中。利用设计模式可以方便地重用成功的设计和结构。把已经证实的技术表示为设计模式，使它们更加容易被新系统的开发者所接受。设计模式帮助设计师选择可使系统重用的设计方案，避免选择危害到可重用性的方案。

　　4) 体系结构设计方法
　　生成一个满足软件需求的体系结构的过程即为体系结构设计。体系结构设计过程的本质在于：将系统分解成相应的组成成分(如构件、连接件)，并将这些成分重新组装成一个系统。常用的体系结构设计方法有4类，分别为制品驱动(artifact-driven)的方法，用例驱动(use-case-driven)的方法，模式驱动(pattern-driven)的方法和领域驱动(domain-driven)的方法。每种方法在过程的顺序上、在概念的特定内容上有所不同，但最后都生成对体系结构的描述。

　　3．基于体系结构的软件开发方法

　　本质上，软件体系结构是对软件需求的一种抽象解决方案。在引入了体系结构的软件开发中，应用系统的构造过程变为“问题定义→软件需求→软件体系结构→软件设计→软件实现”，可以认为软件体系结构架起了软件需求与软件设计之间的一座桥梁。而在由软件体系结构到实现的过程中，借助一定的中间件技术与软件总线技术，软件体系结构易于映射成相应的实现。Bass等人提出了一种基于体系结构的软件开发过程，该过程包括6个步骤：导出体系结构需求；设计体系结构；文档化体系结构；分析体系结构；实现体系结构；维护体系结构。对此在本书第5章中会进行介绍。
　　软件开发模型是跨越整个软件生存周期的系统开发、运行、维护所实施的全部工作和任务的结构框架，给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为3种类型：
　　(1) 以软件需求完全确定为前提的瀑布模型。
　　(2) 在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型等。
　　(3) 以形式化开发方法为基础的变换模型。
　　所有开发方法都是要解决需求与实现之间的差距。但是，这3种类型的软件开发模型都存在这样或那样的缺陷，不能很好地支持基于软件体系结构的开发过程。因此，研究人员在发展基于体系结构的软件开发模型方面做了一定的工作。
　　在基于构件和基于体系结构的软件开发逐渐成为主流的开发方法的情况下，已经出现了基于构件的软件工程。但是，对体系结构的描述、表示、设计和分析以及验证等内容的研究还相对不足，随着需求复杂化及其演化，切实可行的体系结构设计规则与方法将更为重要。

　　4．软件体系结构评估

　　软件体系结构的设计是整个软件开发过程中关键的一步。对于当今世界上庞大而复杂的系统来说，没有一个合适的体系结构而要有一个成功的软件设计几乎是不可想象的。不同类型的系统需要不同的体系结构，甚至一个系统的不同子系统也需要不同的体系结构。体系结构的选择是一个软件系统设计成败的关键。
　　但是，怎样才能知道为软件系统所选用的体系结构是否恰当？如何确保按照所选用的体系结构能顺利地开发出成功的软件产品呢？要回答这些问题，需要使用专门的方法对软件体系结构进行分析和评估。
　　常用的软件体系结构评估方法有软件体系结构分析方法(Software Architecture Analysis Method，SAAM)和体系结构权衡分析方法(Architecture Tradeoff Analysis Method，ATAM)。它们都是基于场景的软件体系结构评估方法，这类评估方法分析软件体系结构对场景也就是对系统的使用或修改活动的支持程度，从而判断该体系结构对这一场景所代表的质量需求的满足程度。例如，用一系列对软件的修改来反映易修改性方面的需求，用一系列攻击性操作来代表安全性方面的需求等。SAAM本质上是一个寻找受场景影响的体系结构元素的方法，而ATAM建立在SAAM基础上，关注对风险、非风险、敏感点和权衡点的识别。

　　5．特定领域的体系结构框架

　　特定领域的应用通常具有相似的特征，如果能够充分挖掘系统所在领域的共同特征，提炼出领域的一般需求，抽象出领域模型，归纳总结出这类系统的软件开发方法，就能够指导领域内其他系统的开发，提高软件质量和开发效率、节省软件开发成本。正是基于这种考虑，人们在软件的理论研究和工程实践中，逐渐形成一种称之为特定领域的软件体系结构(Domain Specific Software Architecture，DSSA)的理论与工程方法，它对软件设计与开发过程具有一定参考和指导意义，已经成为软件体系结构研究的一个重要方向。
　　Rick Hayers-Roth和Will Tracz分别对DSSA给出了不同的定义，前者侧重于DSSA的特征，强调系统由构件组成，适用于特定领域，有利于开发成功应用程序的标准结构；后者侧重于DSSA的组成要素，指出DSSA应该包括领域模型、参考需求、参考体系结构、相应的支持环境或设施、实例化、细化或评估的方法与过程。两种DSSA定义都强调了参考体系结构的重要性。
　　特定领域的体系结构是将体系结构理论应用到具体领域的过程，常见的例子有：
　　(1) 用户界面工具和框架。可以为开发者提供可重用框架以及像菜单、对话框等可重用构件的集合。
　　(2) 编译器的标准分解。体系结构的重用能使语言编译系统的开发变得非常简单。
　　(3) 标准化的通信协议。通过在不同层次的抽象上提供服务，可实现跨平台的交互。

　　6．软件体系结构支持工具

　　几乎每种体系结构都有相应的支持工具，如UniCon、Aesop等体系结构支持环境，C2的支持环境ArchStudio，Acme的支持环境AcmeStudio，支持主动连接件的Tracer工具等。另外，还出现了很多支持体系结构的分析工具，如支持静态分析的工具、支持类型检查的工具、支持体系结构层次依赖分析的工具、支持体系结构动态特性仿真工具、体系结构性能仿真工具等。但与其他成熟的软件工程环境相比，体系结构设计的支持工具还很不成熟，难以实用化。本书通过两个较为著名的软件体系结构集成开发环境ArchStudio4和AcmeStudio，介绍软件体系结构集成开发环境的具体功能。

 

 

 

4.2 软件体系结构的发展方向　　

1．各种软件体系结构语言之间的信息互换　　

　　现有的各种软件体系结构描述语言大多是与领域相关的，所以不利于对不同领域体系结构的说明。但这些针对不同领域的软件体系结构描述语言在某些方面又大同小异，造成资源的冗余。其实，大多数软件体系结构描述语言具有一系列共同概念。如何用一种公共形式把各种语言综合起来，使得能够交换各种体系结构描述信息，将是今后软件体系结构研究和实践的重点之一。

2.设计工具和环境

　　软件体系结构设计作为软件工程的一部分，它的计算机辅助实现手段是相当重要的。应当开发出一些软件工具来实现体系结构的描述和分析，开发阶段转换工具可以实现阶段成果的自动转换，例如，把需求规格说明自动转换为构件等。目前关于这方面的研究成果很少，特别是可以应用到实际项目开发中的工具和环境就更少。

3．体系结构再工程问题

　　现在软件系统的规模变得越来越大，结构也越来越复杂，同时从头开始构建的大系统数量在急剧地减少，因而很多遗留系统正在被逐步地利用。从遗留系统软件代码和系统中抽取结构信息，经过描述、统一、抽象、一般化与实例化等处理，可总结出系统的体系结构。

 

5 本 章 小 结

　　本章首先介绍了软件体系结构的各种定义和基本概念，它们是本章的重点。考虑到定义的一般适用性和被广泛接受的程度，我们所提到的软件体系结构，都以定义5中的软件体系结构概念为基础。构件、连接件和约束(配置)等概念是软件体系结构最基本的元素。
　　接下来介绍了软件体系结构研究的意义，良好的体系结构对于软件系统的重要意义在软件生命周期中的各个阶段都有体现。
　　软件体系结构发展到现在共经历了4个发展阶段：“无体系结构”设计阶段、萌芽阶段、初级阶段和高级阶段，对每一阶段进行了简单介绍。归纳现有软件体系结构的研究活动，介绍了软件体系结构研究现状和发展方向。当前的体系结构研究主要集中在软件体系结构描述研究、设计研究、分析与评估、支持工具，基于体系结构的开发方法、特定领域的体系结构框架等方面。
　　软件体系结构技术目前仍存在诸多问题，如概念定义尚不统一、描述规范不能一致等。有研究人员认为在软件开发实践中软件体系结构尚不能发挥重要作用，软件体系结构技术仍有待研究、发展和完善。

　　1．为什么要研究软件体系结构？
　　1.根据软件体系结构的定义，你认为软件体系结构的模型应该由哪些部分组成？
　　3．软件体系结构的概念和建筑中的体系结构的概念相类似，二者有什么共同之处？这种类比对于我们认识和研究软件体系结构有何帮助？
　　4．结合自己曾参与开发的软件项目，思考构件、连接件和约束的概念，并用自己的语言描述构件、连接件和约束的特点，进一步论述构件、连接件和约束分别对于软件体系结构的重要意义。
　　5．查阅相关文献，比较各种软件体系结构定义，进一步讨论它们的联系和区别。