软件体系结构描述语言ADL.docx
《软件体系结构描述语言ADL.docx》由会员分享，可在线阅读，更多相关《软件体系结构描述语言ADL.docx（25页珍藏版）》请在冰豆网上搜索。
软件体系结构描述语言ADL
2011-5-28
大作业参考资料：
1.试就一种常用软件体系结构说明其概念、结构模型与应用领域，并结合该体系结构的应用，用一种ADL来描述该体系结构。
2.结合某一应用，编写一个XML文档，并将其与一个XMLScheme对应起来，最后用一种方法来解析该XML文件。
3.登录Oracle网站，学习JavaFX的使用方法，编写一个小型JavaFX应用。
（选作）
4.通过网络学习Flex，用Flex编写一个应用程序。
（选作）
5.给出三种常用的Java设计模式，并用Java语言给出其实现的实例。
电子稿文件名格式：
学号+姓名+软件体系结构期末作业.DOC
窗体顶端
窗体底端
软件体系结构描述语言（ADL）
要点浏览
本章将对学术界常见的体系结构描述语言进行介绍.由于研究流派不同,各种ADL的设计和能力也不尽相同.本章选取五种比较典型的ADL作为代表,希望能让读者了解主流ADL的基本能力,主要功能和应用范围.为了让读者对各种ADL有一个更为清晰的认识,本章最后还对这五种典型的ADL进行了比较全面的比较.
通过本章的学习,您将能:
了解主流ADL的语法和语义
掌握主流ADL的特点
区分主流ADL的不同
总体介绍
任何一个软件系统都有结构,在系统开发过程中的分析设计阶段,通过考察系统的结构,可以对系统的开发和实现提供良好的基础.系统的结构往往体现为系统的各个部分之间的配置.对于描述软件系统配置的表示法的研究由来已久.早在1975年,DeRemer和Kron就设计了模块互连语言（ModuleInterconnectionLanguage,MIL）用于描述结构化的基于模块的程序.在MIL中,模块可能需要导入/导出各种资源.所谓的"资源"就是命名元素,例如类型定义,常量,变量,函数等.MIL的编译器通过进行模块间的类型检查来保证系统的完整性,常见的检查包括:
某个模块要使用的资源是否已经被其它模块提供了,资源的类型是否匹配,一个模块的实现是否确实提供了其规约中声明的资源,一个模块是否有权访问它要使用的资源等.
早期的MIL要求不同模块的开发人员在开发前先达成很多一致.例如:
能够根据简单的名字匹配来发现模块之间的交互,所有的模块都是用同一种语言开发的,所有的模块在组装系统时都可用,模块的接口描述了与之进行交互的其它模块……进一步的研究逐步弱化了这些限制.例如Darwin允许模块在运行时动态的实例化并进行绑定;Polygen允许不同的模块用不同的编程语言进行开发.各种软件配置的表示法逐渐成熟,它们既能描述静态也能描述动态的结构化的分布式系统.
MIL的关注点是模块及其之间的互连.随着系统复杂度的提高,人们发现模块之间的交互逐步变得复杂.研究人员对模块之间交互的重视导致了"连接子"（connector）这个概念的诞生,它主要用于描述软件系统的各个组成部分（component）即构件之间的交互关系.从而软件系统的结构可以自然的用构件,连接子及其之间的配置进行描述.将连接子作为与构件同等重要的一阶实体进行处理,是因为如果不将构件之间的交互显式的进行描述,将会带来一些问题,包括:
难以将构件之间的交互信息局部化,从而导致难以识别系统中的连接,并且难以复用连接机制
构件之间的关系难以进行抽象,从而阻碍对整个系统结构的理解
由于构件的实现和交互信息绑定在一起,对不同构件的使用往往会因为交互机制的不兼容而产生严重的集成问题.
支持构件,连接子及其配置的描述语言就是如今所说的体系结构描述语言（ArchitectureDescriptionLanguage,ADL）.UniCon就是最早出现的一种体系结构描述语言.此外,典型的ADL还包括:
Rapide:
一种事件驱动的ADL,它以体系结构定义作为开发框架,支持基于构件的开发.该语言提供了建模,分析,仿真和代码生成的能力,但是没有将连接子显式地表示为一阶实体.
Wright:
其主要特点是将CSP用于软件体系结构的描述,从而完成对体系结构描述的某些形式化推理（包括相容性检查和死锁检查等）.但它仅仅是一个设计规约语言,只能用于描述,无法支持系统生成,同时CSP的使用也是比较困难的事情.
Acme:
支持ADL之间的映射及工具集成的体系结构互交换语言.其目标是作为体系结构设计的一个共同的互交换格式,以便将现有的各种ADL在这个框架下统一起来;而它本身也可以看作是一种ADL.
xArch:
一种基于XML的ADL.它使用XML定义了描述体系结构的核心元素,可以用来简单的描述软件体系结构,也可以作为设计其它ADL的基础,或者用作体系结构描述描述语言的互交换机制.
xADL2.0:
以xArch为基础的基于XML的ADL.除了xArch的核心元素,xADL2.0还提供了对系统运行时刻和设计时刻的元素的建模支持,类似版本,选项和变量等更高级的配置管理观念,以及对产品家族的体系结构的建模支持.此外,xADL2.0还利用XML的可扩展性简化了新的ADL的设计及其相应工具的开发过程.
各种ADL的出现为描述软件系统的结构提供了一种形式化的描述方法,而不是容易引起歧异的线框图.这种精确的描述也使得设计人员能够在系统开发的早期阶段对系统结构进行高层的分析和验证,从而有助于提高软件开发质量,降低开发成本.
以下我们将着重介绍五种ADL:
UniCon,Darwin,C2SADL,Acme和xADL.
常见的体系结构描述语言
UniCon（UniversalConnector）
UniCon简介
UniCon是由CMU和SEI设计的一个体系结构描述语言.该语言关注软件体系结构的结构化特性,将系统（本身也是一个复合构件）描述为构件和连接子的配置,其中构件表示计算或者数据,而连接子表示构件之间的交互.每个构件的接口都对外提供一些演员（player）.构件通过这些演员与外界发生交互.与构件类似,一个连接子的协议对外提供一些角色（role）,连接子通过这些角色来调解构件之间的交互.图-1是用UniCon的图形化编辑器生成的示意图.
UniCon概念的示意图
图-1中有两个构件,构件A和构件B,它们都是Unix中的过滤器.这两个构件都有三个演员,用三角形表示.左边的演员表示输入流"standardin",右边的演员是输出流"standardour"和"standarderror".两个构件之间是一个连接子,它是Unix下的管道.这个连接子有两个角色:
悬垂在左边的表示管道的入口（source）,右边的表示管道的出口（sink）.
在上图中,构件和连接子之间还没有交互.为了在构件之间建立连接,演员必须和某个角色关联起来.如图-2所示.
在UniCon建立连接
通过演员与角色的关联,最终就可以建立整个系统各个部分之间的配置.最新版本的UniCon不仅支持类似于上例的管道-过滤器系统,还支持使用过程调用和共享数据的模块交互系统,基于RPC调用的分布式系统,根据各种实时要求共享处理器的进程以及基于SQL命令的数据库访问.
UniCon的提出是为了达到如下目的:
解决系统描述和组装的实际问题,为实际工具提供一个原型;
为各种连接机制提供一个一致的访问方式
帮助软件设计师区分不同的构件类型和连接子类型并验证构件和连接子配置的正确性
支持图形化和文本化符号以及二者之间的互换
兼容现存的用常见的编程语言编写的构件（这些构件并不需要特定于UniCon）
尽可能的将运行时开销降到最低
以下将具体介绍UniCon中构件和连接子的定义.
UniCon中的构件
UniCon中的构件定义包括规约部分和实现部分.
构件的规约称为构件的接口（interface）.接口定义了构件所能进行的计算以及使用构件必须遵循的约束.构件的接口包含三类信息:
构件类型:
构件类型表示构件提供的功能的类型,它限制了该构件所能定义的演员的数量,类型和规约.
特性:
由属性和值组成的二元组,用于指定与构件整体相关的附加信息,例如断言,约束等.
演员:
从构件外部可见的语义单元,构件通过演员与其它构件发生交互.
其语法如下:
构件的实现有两种形式:
原子（primitive）实现:
原子实现是一个指向存在于UniCon语言外部的文档链接,该文档包含了相应的构件实现.它可能是某种编程语言的源代码（目前UniCon工具集仅仅支持C语言的源代码）,也可以是目标码,或者是包含目标码的Unix档案库文件,或者是二进制可执行文件,shell脚本,数据文件,C语言的include文件等
复合（composite）实现:
某个UniCon构件的复合实现是对其它已定义的构件和连接子的配置的描述,该实现包含三类信息:
片段（piece）:
用于构造某个配置的构件和连接子实例
配置信息:
描述构件和连接子的关联
抽象信息:
描述该构件的接口如何由其复合实现中的构件接口实现.
构件实现的语法如下:
UniCon中的连接子
连接子的定义也包含规约和实现两个部分,其中规约部分通过协议（protocol）进行描述.连接子的协议定义了构件之间允许产生的交互,并确保这些交互能够顺利进行.连接子的协议包含三类信息:
连接子类型:
连接子类型表示连接子所能调解的构件之间的交互类型,它限制了连接子的角色的数量,类型和规约.
特性:
由属性和值组成的二元组,用于指定和连接子整体相关的附加信息,例如断言,约束等（例如和时间和顺序相关的规则）
角色:
从连接子外部可见的语义单元,通过角色连接子对构件的交互进行调解.角色通过与演员发生关联,从而形成系统的连接,它定义了参与连接的演员的需求与责任.
连接子的实现是UniCon内置的,即UniCon只支持连接子的原子实现,它本身不提供用户自定义连接子实现的机制.
连接子的定义的语法如下（从中也可以看出UniCon目前支持的连接子实现的类型）:
UniCon是最早的体系结构描述语言之一.从上述介绍可以看出,UniCon强调将系统划分为构件后,用适当的连接子将其组装起来构成一个完整的系统.构件和连接子之间是松耦合关系.UniCon备受诟病的一点是它只支持预定义的连接子,并且不支持复合连接子.为了解决这个问题,相关研究人员在UniCon的基础上对其进行了增强.增强后的UniCon称为UniCon-2.UniCon-2提供了一个比较灵活的类型系统,并且引入了责任（duty）这个概念用于描述演员,角色等与属性的关系.某个系统配置的责任还可以用于描述体系结构风格.由于UniCon-2允许用户引入新类型,为了便于对与新类型相关的约束进行检查,UniCon-2采用了一种开放的编译器结构以便于增加相应的检测方法.
Darwin
Darwin简介
Darwin最初是一个分布式系统配置语言,引入软件体系结构研究后,Darwin成为一个体系结构描述语言.作为一个ADL,Darwin对软件系统的静态结构的描述和UniCon非常相似,不过Darwin中引入了一些特有的构造（construct）使之便于描述系统的动态特性.此外,Darwin使用π演算作为其形式化基础,因此使用Darwin描述的体系结构模型能够进行一些高层的模型检测,例如是否存在死锁等.
Darwin的建模能力和特点
使用Darwin描述的软件系统配置主要由构件及构件之间的绑定（binding）组成.
Darwin中的构件是用服务（service）进行定义的,一个构件既能对外提供一些服务,也能请求外部的服务.所有的服务名的作用范围仅限于定义这些服务的构件,亦即构件的定义本身并不需要了解全局的服务名.因此Darwin中的构件是上下文独立的（contextindependent）,这有助于构件的复用,并能简化维护阶段对构件的替换工作.构件的服务由服务类型进行区分,但是Darwin本身并不解释服务类型信息.服务类型信息要么由低层的形式化行为规约进行解释,要么用于表示底层分布式平台所支持的通信机制（例如在Regis系统中,类型信息就可以直接用于选择正确的通信代码）.图-3是一个过滤器构件的定义,其中服务的类型信息就是尖括号内的内容.
Darwin中的构件
Darwin中的绑定就是构件的provide服务和require服务之间的链接.只有provide服务类型和require服务类型相互匹配,相应的绑定才是合法的.由于Darwin本身只管理服务类型,并不对其进行解释,因此必须由提供服务类型的系统来判断服务是否匹配（不过在Darwin目前的工具集中,仅仅简单的通过名字是否相同来判断服务是否匹配）.为了灵活的对构件进行绑定,Darwin中提供了一些特有的关键字,例如forall,when等.下述代码是图-4例子的Darwin描述,其中流水线的长度是由其参数动态决定的,forall,when等也体现了Darwin这种ADL对动态性的支持.
Darwin对动态结构的支持主要来自于延迟实例化（lazyinstantiation）和直接动态实例化（directdynamicinstantiation）这两种技术.延迟实例化是指只有当用户试图访问某个服务时,提供该服务的构件才被实例化.将延迟实例化与递归结合起来就能描述几乎不受限制的结构,其局限性是不能描述循环绑定的结构.直接动态实例化则允许系统结构随意的发生演化,这需要底层π演算的相关支持.具体细节以及与π演算相关的内容请参看相关文献.
可变长度的流水线（Pipeline）
用Darwin描述的客户服务期系统
使用构件和绑定就能定义Darwin中的复合构件以及一个系统.事实上,Darwin描述的系统就是一个层次式结构化的复合构件.下述代码就是图-5所示的客户服务器系统的Darwin描述.注意:
其中的System构件就是最终的系统.
Darwin的设计面向的是分布式软件,因此它对系统动态性的支持可以说是天生的.从抽象的角度来看,Darwin中的构件及其之间的绑定其实独立于具体的构件交互机制,因此理论上Darwin也能用于描述传统的程序结构.
虽然Darwin能很好的描述系统的动态特性,但是Darwin中并没有显式的连接子概念,因此使用Darwin进行复杂系统设计时关注的主要还是构件;当然这似乎并不会削弱其表达能力.
C2SADL
C2SADL是UCI设计的一种基于消息传递的体系结构描述语言,主要用于描述符合C2风格的软件系统的体系结构.
C2风格
C2风格是一种基于构件和消息的体系结构风格,主要是应用于带有图形用户接口（GUI）的应用系统,但也能用于其它类型的应用.这种风格要求构件之间通过消息交换进行通信.因此每个C2构件和C2连接子都有一个top接口和一个bottom接口,其中top接口定义了该构件所能接收的应答消息和向上发出的请求消息,而bottom接口定义了该构件能够进行应答的请求消息及其向下发出的应答.所有消息都以连接子为桥梁在构件之间进行传递.这种风格的体系结构将系统中的构件用连接子划分为不同层次,如图-4所示.
C2风格的体系结构:
可视化堆栈（Stack）
C2概念的图例
C2风格的核心在于构件之间的"有限可见性",即处于系统中某个层次的构件只能"看到"上层的构件,而不清楚下层到底是什么构件在与之进行通信.具体表现在如下所述的构件之间的通信规则（即系统的组装规则）:
构件的top接口只可能与某一个连接子的bottom接口相连
构件的bottom接口只可能与某一个连接子的top接口相连
与连接子相连的构件或者连接子没有数量限制
两个连接子相连时,只能是其中一个的bottom接口与另一个的top接口相连
C2SADL
C2SADL目前还只是一个原型语言,其相应的支撑工具还在开发中.该语言包含三个部分:
接口定义符号（IDN,interfacedefinitionnotation）:
是C2中的构件接口的规约.如下所示是一个堆栈（Stack）构件的C2IDN.
体系结构描述符号（ADN,architecturedescriptionnotation）:
是C2体系结构的声明性规约.例如图-4所示例子的相应描述如下:
体系结构构造符号（ACN,architectureconstructionnotation）:
主要用于表达体系结构的动态变化,例如如果要在运行时删除堆栈的一种可视化表示方式,可以用ACN进行如下描述:
C2SADL中的连接子本质上是一种消息总线,复合这种结构的应用系统往往具有比较良好的灵活性和可扩展性.不过由于C2SADL还没有针对大型实际系统进行建模和使用,因此对使用该结构所可能导致的性能问题还不是很明确.
Acme
Acme简介
Acme是CMU的Acme项目的产物.该项目始于1995年,目的是为了研究一个公共的语言,使之能在不同的体系结构设计工具之间作为体系结构描述信息互换的桥梁.目前Acme及其开发工具包AcmeLib提供了一个通用的,可扩展的基础框架用于描述,表示,生成以及分析系统的软件体系结构.而作为桥梁作用的Acme,由于必须具备大多数ADL共有的概念,因此它本身也是一个ADL,并且是一个相对而言比较简单的通用的ADL.
Acme的建模元素和特点
Acme的主要特点表现为:
采用七个基本的体系结构设计元素作为体系结构的本体（architecturalontology）,如图-6,图-7所示.
采用灵活的标注机制支持使用外部语言定义的非结构化信息
使用类型机制对常见的可复用的软件体系结构俗语和风格进行抽象描述
使用开放的语义框架对体系结构描述进行推理
Acme的设计元素
Acme的设计元素
以下对Acme所采用的设计元素进行简要介绍.这七个设计元素是:
构件（components）:
系统中的计算元素和数据存储.直观的说,就是线框图中的框.典型的构件有:
客户端,服务器,数据库,黑板,过滤器等.
连接子（connectors）:
构件之间的交互.直观的说,就是线框图中的线.典型的连接子有:
过程调用,事件广播,客户和服务器之间的协议等.
系统（systems）:
构件和连接子的配置.
端口（ports）:
构件通过端口与外界发生交互.一个构件可以有多个不同类型的端口,每个端口都是一个接口的集合,例如一系列需要以特定顺序调用的过程.
角色（roles）:
连接子通过角色与外界发生交互.角色定义了构件之间交互的参与者.
表示（representations）:
构件或者连接子内部结构的描述.通过"表示"这个概念,系统的体系结构就具有了层次结构.同时,"表示"这个概念可以用于描述体系结构实体的多个视图（但是Acme本身并不处理视图之间的对应关系）,如图-7所示.
表示的映射（rep-maps）:
将构件或者连接子的内部"表示"与外部接口进行映射.
简单的客户端-服务器系统
以下是一个简单的客户端-服务器系统（图-8）的Acme描述.
Acme本质上是一些ADL的建模元素的"最大公约数",因此它能作为不同ADL及其支撑工具之间用于信息交换的语言.这是Acme的最大作用,当然这也使得它只能成为一个建模能力一般的ADL,例如Acme中就没有相应的机制用于对构件或者系统行为进行描述或者规约.相关研究者正在考虑在Acme中引入类似于Wright中使用的CSP的形式化语言来解决这个问题.当然,作为一个通用的交换语言,Acme的能力及其可扩展性也不是无限的.例如Acme的扩展仅限于在七个基本设计元素的基础上进行,并且Acme中缺乏用于描述属性及其数据格式的元语言.无论如何,Acme是第一个ADL之间的互交换语言,它的出现使得不同的ADL支持工具之间有可能进行体系结构描述信息的交流.
xADL
xADL简介
xADL是UCI设计的一个基于xml的ADL,最新版本是xADL2.0.其建模元素都是使用xmlschema进行定义的.xADL除了提供ADL中常见的建模元素外,还对产品家族的描述提供了一些支持,例如体系结构版本等.这是xADL的一个独特之处.此外,xADL本身设计成一个模块化语言,因此具有良好的可扩展性.
xADL建模元素和特点
作为一个ADL,xADL也定义了常见ADL中的建模元素,包括构件,连接子,构件的接口,配置等,其中构件和连接子都具有内部结构.由于xADL的模块化特性,使得用xADL描述的体系结构看起来就像是一些相互独立的结构的集合.例如下述代码就是用xADL描述的一个客户-服务器结构（图-11）（由于空间有限,下述简写代码没有遵循xml的格式!
）
用xADL描述的客户-服务器系统
除了上述常见的体系结构建模元素,xADL还提供了一些特有的建模元素用于支持产品家族的建模,这些元素包括:
选项（Option）:
允许体系结构描述中的一些构件或者连接子在某些情况下是可选的,即不一定存在.
变体（Variant）:
类似于编程语言中的联合（Union）.将某些构件或者连接子指定为变体,意味着这些元素在某些情况下可以被实例化为不同类型的元素.
版本（Version）:
用于描述构件,连接子和接口的版本树.这样就可以在同一个体系结构模型中使用同一类型元素的不同版本.
结构差异（StructuralDiffering）:
用于描述两个xADL结构的差异.
产品线体系结构差异（Product-LineArchitectureDiffering）:
用于描述产品线中两个体系结构的差异.
上述建模元素在xADL中根据抽象层次分为两类,一类是运行时概念,包括构件实例,连接子实例,接口实例,链接实例等;还有一类是运行时概念,包括构件,连接子,接口,链接等（这些都是类型的概念）
xADL的另一个特点在于其灵活的可扩展性.其可扩展性本质上来源于xml以及schema的可扩展性,例如可以通过schema的include机制来实现继承等.
当然,从上述介绍中也可以看出,xADL也提供了体系结构建模的基本元素,并且用于定义xADL的xmlschema是独立于其它ADL的,因此xADL也可以用于ADL之间的转换.已有研究人员已经给出了从C2,Acme等ADL到xADL的映射规则.
xADL相比UniCon等ADL来说属于第二代的ADL.其xml基础使其具有良好的可扩展性,并且由于xml格式文本的易交换性使得xADL能比较容易的集成不同的支持工具.但是由于xml格式的冗长,因此对xADL的使用需要有一定的工具支持.
体系结构描述语言分类框架
根据对ADL的研究,Medvidovic和Taylor于2000年提出了一个用于对ADL进行分类和比较的一般框架,如表1所示.该框架认为一个ADL必须明确的对构件,连接子和它们的配置进行建模;为了保证体系结构描述有明确的语义还必须对构件的接口进行建模.此外,为了保证可用性和有用性,它也必须为基于体系结构的开发和演化提供工具支持.除了上述必需的建模元素外,不同的方法由于关注点的不同,可能会关注不同的体系结构特性,比如系统组装的风格,某个应用领域的特征以及分布,并发,安全和吞吐量等属性.
体系结构描述语言
体系结构建模特性
构件
接口,类型,语义,约束,演化,非功能属性
连接子
接口,类型,语义,约束,演化,非功能属性
体系结构配置
易理解性,组装性,精化和追踪性,异构性,可量测性,演化,动态性,约束,非功能属性
工具支持
主动规约,多视图,分析,精化,实现生成,动态性
ADL的分类与比较框架,黑体字表示必须建模的元素
如上所述,构成体系结构描述的三要素是:
构件,连接子和体系结构配置.因此,一个ADL应该提供至少这三种元素的显式描述.是否同时描述了这三种元素,也可以作为判断一个描述语言是否是一个体系结构描述语言的依据.为了能够对体系结构的一些信息进行推理,也要求A
升级会员 