软件体系结构描述语言ADL综述_bycs

软件体系结构描述语言ADL综述

Advancement of Architecture Description Language (ADL) 引言

60年代的软件危机使得人们重新开始重视软件工程的研究。最初人们选择了“算法+数据结构=程序”的设计模式。但随着软件系统的规模和复杂性越来越大，传统的设计模式已经不能适应要求。同时为了保证软件质量，提高软件的可靠性、可重用行和可维护性，软件设计的核心逐渐转向对系统的总体结构即软件体系结构(Software Architecture)的设计和规范。这类方法主要着眼于软件系统的全局组织形式，在更高层次上把握系统各组件之间的内在联系。并从全局的，整体的角度去理解和分析整个系统的行为和特性，有助于解决当前开发复杂的大型软件所存在的困难。

研究软件体系结构的首要问题是如何描述软件体系结构。目前已有很多表现形式和方法表法、模块连接语言、软构件描述法和体系结构描述语言ADL等。而其中ADL作为形式化的表示软件体系结构的工具呈现出强大的生命力。它提供了规范化的体系结构描述，同时是对软件体系结构进行求精、验证、演化和分析的前提与基础。目前已经成为软件体系结构方向的研究热点。实践工作者将这些ADL应用于实践中，获得了成功。同时，我们应注意到不同的ADL所支持的抽象能力及其提供的分析能力变化很大，学术领域目前对ADL的定义尚未取得一致。

一、软件体系结构的概述

由于对软件体系结构的研究和应用刚刚兴起，许多专家学者从不同的角度和侧面对软件体系结构进行刻画，因此，目前软件体系结构还没有一个标准定义。这里给出一个目前学术领域广泛接受的定义。(D.Garlan＆M Shaw，1993)软件体系结构是软件设计过程中的一个层次，在计算过程中的算法设计和数据结构之上，处理总体系统结构设计和描述方面的一些问题。包括总体组织与全局控制结构、通讯协议、同步、数据存取、设计元素的功能分配，物理分布，设计元素的复台，设计方案的选择、评估和实现等。

二、软件体系结构描述语言ADL的概述

2.1对ADL的不同理解

当前在学术界对ADL 的定义尚未取得一致下面的定义大多来源于自身对某种ADL语言的开发所得到的体会。尽管它们不免有以偏概全之赚，但还是为我们了解ADL提供了有价值的信息。

(1)在文[1]中，Tracz定义一个ADL包含4“C”：组件(components) ，

连接子(connectors)，配置(configurations)，约束(constraint s)。

(2)根据其UniCon的经历，Shaw 与同事列出了ADI 应该展示的属

性如下：1)组件建模的能力，带属性断言、接口、实现；2)连接子建模的能力，带协议、属性断言与实现；3)抽象与封装；4)类型与类型检查；

5)适应分析工具的能力

(3)在文[2]中，将ADL划分为4个组成部分：组件，连接子，配置、

支持工具。其中，组件、连接子、配置构成了ADL的体系结构描述特性。

而支持工具则为软件体系结构设计者提供必要的帮助。

(4)在文[3]中，Luckham 与Vera在研究Rapide的基础上提出．ADL

应该满足以下要求：1)组件抽象；2)通信抽象；3)通信完整性，要求在结果实现中，只有在一个体系结构中相联结的组件可以通信；4)动态体系结构建模的能力 5)分层复合；6)相关性．或者是行为与体系结构间关联(映射)的能力；7)组件建模的能力，带属性断言、接口、实现；8)连接子建模的能力，带协议、属性断言与实现；9)抽象与封装； 10)类型与类型检

查；11)适应分析工具的能力。

2.2ADL的定义

从上述一小节我们可以看出，学术领域对ADL的理解还存在着分歧。我们认为：ADL是这样一种形式化语言，它在底层语义模型的支持下，为软件系统的概念体系结构建模提供了．具体语法与概念框架。基于底层语义的工具为体系结构的表示、分析、进化、细化、设计过程等提供支持。其三个基本构成元素是：1)组件——计算或数据存储单元；2)连接子——用于组件问交互建模的体系结构构造块及其支配这些交互的规则{3)体系结构配置——描述体系结构的组件与连接于的连接图。

2.3 ADL应具备的特点

2.3.1为了精确描述软件体系结构，ADL首先应有一个形式化理论基础，如Pet“网、状态图、z、 CSP”等。有了形式化理论基础，才能对所描述的系统进行分析和验证。如Wright用CSP进行描述、Rapide采用偏序事件集合等。

2.3.2作为一种描述语言，ADL应具有严谨的语法和语义。描述能力应足够强，至少应能描述的基本构件如组件、连接件及有关配置规范。同时，为了更好的应用，一种ADL，应有相应的支持工具，支持工具的能力直接反映了该ADL的可使用程度和范围。

2.3.3 描述软件体系结构的一个很重要的目的是为了便于软件开发者的理解和交流，因此，ADL描述应简单易懂，最好有图表辅助理解。对于同一个体系结构，不同的软件开发者需要从不同的抽象层次上理解，这就要求

ADL能描述不同抽象程度的软件体系结构。

2.3.4分析作为软件体系结构求精、验证的基础，是一般ADL不可缺少的一种功能分析有静态分析和动态分析，如Wright基于CSP能对单个组件或连接件进行静态死锁分析、Rapide 基于偏序事件集合(partially ordered event sets)可进行动态分析。

2.3.5其他有关设计ADL应注意的问题，还有可扩展性、演化和重用等。

三、常见ADL的介绍与比较

3.1常见ADL的介绍

ADL是当前软件开发和设计方法学中一种发展很快的软件体系结构描述方法，目前，已经有几十种常见的AD L。其中已经开发和使用的常见ADL有Wright、Unieon、C2、Aesop、Rapide、Darwin、SADL等。这里我们对Unicon、C2 SADL、ACME、XADL四种给出介绍和比较。

3.1.1 Unicon

UniCon简介

UniCon是由CMU和SEI设计的一个体系结构描述语言.该语言关注软件体系结构的结构化特性,将系统(本身也是一个复合构件)描述为构件和连接子的配置,其中构件表示计算或者数据,而连接子表示构件之间的交互.每个构件的接口都对外提供一些演员(player).构件通过这些演员与外界发生交互.与构件类似,一个连接子的协议对外提供一些角色(role),连接子通过这些角色来调解构件之间的交互.在UniCon建立连接

通过演员与角色的关联,最终就可以建立整个系统各个部分之间的配置.最新版本的UniCon不仅支持类似于上例的管道-过滤器系统,还支持使用过程调用和共享数据的模块交互系统,基于RPC调用的分布式系统,根据各种实时要求共享处理器的进程以及基于SQL命令的数据库访问.

UniCon的提出是为了达到如下目的:

1.解决系统描述和组装的实际问题,为实际工具提供一个原型;

2.为各种连接机制提供一个一致的访问方式；

3.帮助软件设计师区分不同的构件类型和连接子类型并验证构件和连接子配置的正确性；

4.支持图形化和文本化符号以及二者之间的互换；

5.兼容现存的用常见的编程语言编写的构件(这些构件并不需要特定于UniCon)；

6.尽可能的将运行时开销降到最低；

以下将具体介绍UniCon中构件和连接子的定义.

UniCon中的构件

UniCon中的构件定义包括规约部分和实现部分.

构件的规约称为构件的接口(interface).接口定义了构件所能进行的计算以及使用构件必须遵循的约束.构件的接口包含三类信息:

1.构件类型:构件类型表示构件提供的功能的类型,它限制了该构件所能定义的演员的数量,类型和规约.

2.特性:由属性和值组成的二元组,用于指定与构件整体相关的附加信息,例如断言,约束等.

3.演员:从构件外部可见的语义单元,构件通过演员与其它构件发生交互. 构件的实现有两种形式:

1.原子(primitive)实现:原子实现是一个指向存在于UniCon语言外部的文档链接,该文档包含了相应的构件实现.它可能是某种编程语言的源代码(目前UniCon工具集仅仅支持C语言的源代码),也可以是目标码,或者是包含目标码的Unix档案库文件,或者是二进制可执行文件,shell脚本,数据文件,C 语言的include文件等

2.复合(composite)实现:某个UniCon构件的复合实现是对其它已定义的构件和连接子的配置的描述,该实现包含三类信息:

1.片段(piece):用于构造某个配置的构件和连接子实例

2.配置信息:描述构件和连接子的关联

3.抽象信息:描述该构件的接口如何由其复合实现中的构件接口实现.

构件实现的语法如下:

UniCon中的连接子

连接子的定义也包含规约和实现两个部分,其中规约部分通过协议(protocol)进行描述.连接子的协议定义了构件之间允许产生的交互,并确保这些交互能够顺利进行.连接子的协议包含三类信息:

1.连接子类型:连接子类型表示连接子所能调解的构件之间的交互类型,它限制了连接子的角色的数量,类型和规约.

2.特性:由属性和值组成的二元组,用于指定和连接子整体相关的附加信息,例如断言,约束等(例如和时间和顺序相关的规则)

3.角色:从连接子外部可见的语义单元,通过角色连接子对构件的交互进行调解.角色通过与演员发生关联,从而形成系统的连接,它定义了参与连接的演员的需求与责任.

连接子的实现是UniCon内置的,即UniCon只支持连接子的原子实现,它本身不提供用户自定义连接子实现的机制.

连接子的定义的语法如下(从中也可以看出UniCon目前支持的连接子实现的类型):

UniCon是最早的体系结构描述语言之一.从上述介绍可以看出,UniCon强调将系统划分为构件后,用适当的连接子将其组装起来构成一个完整的系统.构件和连接子之间是松耦合关系.UniCon备受诟病的一点是它只支持预定义的连接子,并且不支持复合连接子.为了解决这个问题,相关研究人员在UniCon的基础上对其进行了增强.增强后的UniCon称为UniCon-2.UniCon-2提供了一个比较灵活的类型系统,并且引入了责任(duty)这个概念用于描述演员,角色等与属性的关系.某个系统配置的责任还可以用于描述体系结构风格.由于UniCon-2允许用户引入新类型,为了便于对与新类型相关的约束进行检查,UniCon-2采用了一种开放的编译器结构以便于增加相应的检测方法.

3.1.2 C2 SADL

C2 SADL是UCI设计的一种基于消息传递的体系结构描述语言,主要用于描述符合C2风格的软件系统的体系结构.

C2风格

C2风格是一种基于构件和消息的体系结构风格,主要是应用于带有图形用户接口(GUI)的应用系统,但也能用于其它类型的应用.这种风格要求构件之间通过消息交换进行通信.因此每个C2构件和C2连接子都有一个top接口和一个bottom接口,其中top接口定义了该构件所能接收的应答消息和向上发出的请求消息,而bottom接口定义了该构件能够进行应答的请求消息及其向下发出的应答.所有消息都以连接子为桥梁在构件之间进行传递.这种风格的体系结构将系统中的构件用连接子划分为不同层次,.

C2风格的体系结构:可视化堆栈(Stack)

C2风格的核心在于构件之间的"有限可见性",即处于系统中某个层次的构件只能"看到"上层的构件,而不清楚下层到底是什么构件在与之进行通信.具体表现在如下所述的构件之间的通信规则(即系统的组装规则):

1.构件的top接口只可能与某一个连接子的bottom接口相连

2.构件的bottom接口只可能与某一个连接子的top接口相连

3.与连接子相连的构件或者连接子没有数量限制

4.两个连接子相连时,只能是其中一个的bottom接口与另一个的top接口相连

C2 SADL

C2 SADL目前还只是一个原型语言,其相应的支撑工具还在开发中.该语言包含三个部分:

接口定义符号(IDN, interface definition notation):是C2中的构件接口的规约.如下所示是一个堆栈(Stack)构件的C2 IDN.

体系结构描述符号(ADN,architecture description notation):是C2体系结构的声明性规约.

体系结构构造符号(ACN,architecture construction notation):主要用于表达体系结构的动态变化,例如如果要在运行时删除堆栈的一种可视化表示方式,可以用ACN进行如下描述:

C2 SADL中的连接子本质上是一种消息总线,复合这种结构的应用系统往往具有比较良好的灵活性和可扩展性.不过由于C2 SADL还没有针对大型实际系统进行建模和使用,因此对使用该结构所可能导致的性能问题还不是很明确.

3.1.3基于XML消息的体系结构描述语言XADL

体系结构描述语言XADL的基础是一种基于消息的体系结构模型, 即构件通过端口接收请求消息和发送响应消息构件之间通过端口的连接进行消息交换, 从而组合为复合构件或应用系统因此, 中包含了对构件接口的描述和对系统组合的描述,第1.1节和1.2节分别介绍了这两部分内容, 第1.3节给出了完整的例子.

3.1.3.1构件借口描述

在XADL中构件通过端口接收和发送消息,端口，分为输入端口和输出端口,分别用来接收请求消息和发送响应消息。我们用关键字inports和ouports定义端口。在构件组合过程中只有在不同输入、输出方向的端口之间才能进行连接。

端口除了具有方向之外,还必须指明其所允许的消息类型一个端口上可以允许多个不同的消息类型。为了使系统具有良好的可扩展性,采用XML来描述消息, 因此在接口描述中,我们采用文档类型定义（DTD）表示消息类型,并把DTD作为定义消息类型的关键字。

实际上,端口及其所允许的消息类型定义了接口的基调, 描述了构件与外界所能交换的消息的类型和方向。我们把某个端口上某个消息的出现称为一个事件, 而把由端口和其所允许的消息类型所组成的二元组定义为事件类型：事件：e=

事件类型示:E=

换句话说,事件类型的集合定义了接口的基调,与传统的IDL不同的是,在XML 的接口描述中, 除了定义接口基调外, 还将对事件之间的次序约束关系进行描

述。我们采用有限状态自动机来进行次序约束关系的刻画。有限状态自动机由一组状态和一组迁移构成。自动机在某个状态下会响应某个类型的事件,并转移到另外的状态：

:->

自动机的定义由关键字Constraints引导, 包含状态的定义和迁移的定义, 分别以states和Transitions为关键字,在自动机的状态中,有一个起始状态和一个或多个终结状态,分别用init和final来标注。

3.1.3.2系统组合描述

在XADL中, 不仅支持对构件接口的描述,还支持对构件组合关系的描述。构件之间通过端口的连接进行系统组合,只有方向相反和消息类型相同的端口才能进行连接。在参与某个连接的端口中, 不允许存在属于同一个构件的两个端口支持一对多的连接,对于输出端口来说,其上的消息将被同时输出到所有与其相连的输入端口上；而对于输入端口来说, 同一时刻最多只能有一个与其相连的输出端口上的消息被输入到该端口上。对于具有连接关系的输入端口A和输出端口B 来说, 以下的约束成立：事件和事件为同时发生,其中X是满足两个端口上的消息类型的XML消息。我们称这种约束为连接约束。

构件接口描述定义了构件的类型,而在系统组合描述中,我们首先要定义构件实例构件实例的定义以Instances为关键字，一个系统中可以包含同一构件类型的多个实例。构件端口之间的链接关系用关键字to表示，具有一下的形式：C1.p1 to C2.p4 或 C1.p1 to C2.p3,C3.p4.

其中C1，C2和C3分别为构件实例，而p1,p3和p4分别为各个构件的端口。

3.1.4 Acme

Acme是一种体系结构互换语言，支持体系结构的规格说明在不同的ADL之间转换。Acme可作为体系结构设计工具的通用交换格式，也可以作为开发闲的体系结构设计和分析工具的基础。

Acme有如下主要特点：

1.用7种基本的设计元素来表示软件体系结构：

2.提供了一种灵活的注释机制，支持把体系结构和用子语言表示的非结构化信息结合起来，这些子语言是外部定义的；

3.提供了一种类型机制，用于抽象出共同的、可重用的体系结构用法和风格；

4.提供了一个开放的语义框架，用于体系结构的描述的推理。

Acme语言和Acme工具开发库有以下三种基本功能：

1.体系结构的相互交互。

通过提供一种体系结构设计的交换格式，ACME允许各种开发工具与其它补

充工具协同工作。这样，使用ACME的设计师与使用其它ADL设计师相比，就多了很多可供选择的开发工具。

2.为新的体系结构设计和分析工具提供了可扩展的基础。

许多体系结构设计和分析工具需要一个用于描述、存储、操纵体系结构设计的表示法。但开发好的表示法往往需要很高的时间和经济成本。使用ACME可以有效减少这方面的成本，因为可以用它提供的语言和用于工具开发的函数库作为基础。使用ACME还使得所开发的工具能够有更好的通用性，因为它可以与其它使用ACME格式的工具交流设计，协作开发。

3.体系结构描述。

ACME本身是一个很好的开发语言。尽管不是适合于所有的应用系统，ACME 体系结构描述语言能够让开发者很好地认识体系结构建模，提供了一个相对容易的对简单软件系统的描述方法。

Acme体系结构设计元素类型：

ACME的核心概念以7种类型的实体为基础：构件、连接件、系统、端口、角色、表述和表述图(rep-maps, representation map的缩写)。在这7个类型里，最基本的体系结构描述元素是构件、连接件和系统。（图1）

图1 一个Acme描述元素

1.构件——代表系统中基本的计算元素和数据存储。

直观上看，在用方框和连线表示的体系结构图中，它们对应的就是方框。典型的构件有客户、服务器、过滤器、对象、黑板、数据库等。

2.连接件——代表构件之间的交互。

它是构件之间通信和交互活动的媒介，像“胶水”一样把构件联系成为一个体系结构。直观上看，它们对应方框—连线图中的连线。连接件的例子包括简单的交互形式，如管道、过程调用、事件广播等。但连接件也可以表示更复杂的交互，如客户/服务器协议或数据库和应用程序之间的SQL连接。

3.系统——代表构件和连接件的配置。

4.构件的接口定义为端口(Port)的集合。

每个端口表示构件与它外部环境的一个交互点。通过使用不同类型的端口，一个构件能提供多个接口。一个端口可以表示很简单的接口，也可以表示复杂接口，如必须按某种指定顺序被调用的过程集合，或一个事件广播交互点。

5.连接件的接口可以用角色(Role)来定义。

连接件的每一个角色定义了连接件所代表的交互中的一个参与方。二重连接件有两个角色，如RPC连接件的Caller和Callee，或管道连接件的reading和writing，或消息发送连接件的sender和receiver角色。其他类型的连接件的角色可能多于两个。例如，事件广播连接件，可能有一个事件播报角色和任意数目的事件接收角色。

Acme的属性：

Acme并不明确定义属性的含义，但是它支持对属性含义的共享使用。其属性由名字、可选类型和值构成。对7种设计实体里的任何一种都可以添加注释。为了使不同的ADL都能够使用属性所表达的信息，这些ADL对于属性应该有共同的理解。当前已经有一些属性子语言被开发出来。其中之一是用来规定在使用图形化的体系结构描述编辑工具时的可视化属性，还有一个子语言用于描述体系结构上的临时约束。

Acme语言引入模板机制。

1.它是一种类型化、参数化的宏，用于对反复出现的模式做规格说明。

2.在应用或初始化这些模式时，只要给它们提供适当类型的参数就可以了。

3.模板定义了句法结构，可以被扩展到需要生成新的声明的位置。

4.它们非常灵活，可以像在构件和连接件中一样定义它们的联结。

Acme开放语义框架：

Acme主要考虑的是体系结构的构造，因此并不包含体系结构的计算语义，而是依靠一个开放的语义框架。这个框架提供了基本的结构语义，它用构建属性的方式，允许特定的ADL把体系结构和运行时的行为结合起来。这个框架还提供了从语言的结构外观到基于关系和约束的逻辑形式的直接映射。在这个框架里，ACME规格说明表示一个由此推导出的逻辑谓词，称为它的指示规则。

3.2常见ADL的比较

四、现有软件体系结构描述语言ADL的不足

4.1大部分ADL领域相关且互不兼容

目前提出的众多的ADL及它们的支持工具，都是独立的形式存在的，且描述语法互不兼容，同时又有许多共同的特征，这使设计人员很难选择一种合适的ADL，若设计特定领域的软件体系结构又需要从头开始描述，不利于对不同领域的体系结构进行分析。大部分ADL是领域相关的，不利于对不同领域的体系结构进行分析。一些ADL在某些方面大同小异，有很多冗余的部分。

4.2支持工具有效性和可用性差

现有的ADL伴生的支持工具有效性和可用性较差，在多视图、细化与回溯、跨体系结构层一致性检查等方面有很多不足的地方。甚至一些ADL还没有可用的支持工具。严重阻碍了这些ADL的广泛应用。

五、软件体系结构描述语言ADL的进一步研究方向

现有的ADL中，开发的焦点一般都集中在增强语言的分析能力与系统生

成上。体系结构毕竟只是达到目的手段，开发者能够推断目的系统的信息比仅仅为体系结构的提供信息要珍贵得多。能够快速开发出系统或管理最终产品质量才是ADL的真正目的。ADL经历了数量上的井喷期后，今后的研究工作重点将放在ADL共性研究与语言互换、与其它产品集成．提高支持工具的有效性等方面。

5.1 各种ADLS 之间的信息交换。

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

5.2ADL描述的信息与其它生命周期产品的集成

体系结构描述是整十软件生命周期的一十环节，ADL如伺能够承上启下将是十分重要的研究课题。一方面，要研究体系结构描述向其它文档转移，男一方面．要研究如何利用需求分析成果来直接生成系统的体系结构说明。

5.3加强对进化的研究

目前的ADL有些可以实现组件与连接子的进化，但这样的进化能力是有限的其一．是因为这样的进化大多是通过子类型来实现的。其二，系统级的进化能力才是最终目的。系统级的进化必然涉及到系统族问题，对连方面的研究也将促进领域工程的发展。

5.4提高支持工具的有效性

尽管现有的ADL都提供了支持工具集，但将这些ADL与工具应用于实际系统开发中的成功范例还很有限。支持工具的可用性与有效性较差。严重地阻碍了这些ADL的广泛应用。支持工具须在多视图、细化与回溯、跨体系结构层一致性检查等方面进一步加强。

参考文献

1. Wolf A L.succeddings of the Second International software Architecture Workshop(ISAW-2).ACM sigsoft Software Engineering Note.1997(Jan):42~56

2. Medvidovic N.A Classification and Comparison Framework for Software Architecttzre Description Languages February 1996

3.Luckham D C,Vera J An Event-Based Architecure Definition Language.IEEE Trans on SE 1995(sep.) 717~734