基于Atlas语言实现模型转换技术的研究

冉 川,王 普,李亚芬

摘 要:OMG提出一种软件开发新方法:模型驱动架构MDA。这里在MDA基本思想的基础上,侧重模型转换技术,分析Atlas转换方法的特征和优缺点,并进行改进设计,增加模型验证环节。最后,通过一个例子说明如何应用提出的改进方法,在一定程度上证明它的可行性。

关键词:MDA;Atlas;模型转换;Web应用开发

中图分类号:TP311文献标识码:A

文章编号:1004-373X(2009)20-126-05

Research of Model Transformation Method Based on Atlas

RAN Chuan,WANG Pu,LI Yafen

(College of Electronic Information & Control Engineering,Beijing University of Technology,Beijing,100124,China)

Abstract:OMG has proposed a kind of new method of software development named Model Driven Architecture (MDA).Based on concepts about model transformation technology,merits and drawbacks of features of the Atlas are analysed,and improving design by adding models validation step.How to use the proposed method through an example,its feasibility and utility in a certain extent are proved.

Keywords:MDA;Atlas;model transformation;Web application development

0 引 言

MDA(Model Driven Architecture)是OMG(Object Management Group)于2001年发布的软件开发过程中的模型组织管理框架。在MDA中,定义了PIM(平台无关模型)和PSM(平台相关模型)及其转换规范[1]。其中,模型转换定义了不同模型元素的对应关系,是实现MDA的关键环节。

模型是系统的抽象,它比实现系统更容易获取、理解和计算[2]。人们试图准确地建立模型之间、模型与系统之间的关系,使模型在系统开发过程中起到实质性的作用。

1 模型转换流程

在MDA中主要包含三种模型转换,即PIM到PIM的转换,PIM到PSM的转换,PSM到代码的转换。

如以开发Web信息发布系统为例,在MDA框架下模型转换系统首先将按照用户输入的需求建立一个系统级的PIM模型,系统级模型包括Web系统的相关信息(如包含信息发布、用户管理等模块),之后是一系列细化PIM模型的工作,将系统级的PIM模型分化成若干个模块级的PIM模型,再转化为操作级的PIM模型。最终可以将细化后的模型分为两类:一类是表示系统静态结构的模型,这类模型可以表示为UML的类图,反应Web系统的静态特征;一类是描述系统业务操作等动态结构的模型,这一类模型可以表示为UML的用例图,反映Web系统的动态特征。

下一步要进行PIM到PSM模型的转换工作,模型转换系统按照对应的转换规则,分别将PIM静态结构模型转换为PSM静态结构模型,将PIM动态结构模型转换为PSM动态结构模型。PSM静态结构模型为生成Web系统中数据访问层和持久层以及数据库提供关键字段和属性值,PSM动态结构模型为生成Web系统中业务逻辑层提供关键字段和属性值,Web系统中的视图层的关键字段和属性值将由这两类模型共同提供。

在模型转换中,最后将对应特定平台的PSM模型输入代码生成器,通过部署和发布,用户将得到所需要的Web系统。在这三种模型转换中,PIM到PIM转换目的是是细化用户需求,将一个大模型分解成若干的小模型;PSM到代码的转换,主要由代码生成器完成。这两种模型间变换比较具体,因此比较容易实现,在此将重点集中在PIM到PSM的转换。

2 基于Atlas模型转换设计

当前MDA还属于一种早期的有待发展技术,其模型转换方法也有很多,例如:手动转换方法(程序员使用可以访问和操作模型的API对源模型进行转换,从而得到目标模型的方法)、基于规则的模型转换[3]、基于模板的代码生成技术(如AndroMDA等方法)、基于关系代数的模型转换[4](将“模型转换”表达为一个二元关系或者一组二元关系)、基于元模型间映射的模型转换[2]、基于模式的模型转换[5,6](使用设计模式定义转换规则,从而得到更加符合设计的目标模型)等。这里所使用的是基于Atlas模型转换框架的一种改进方法,对其进行分析并展开实现研究。

2.1 Atlas模型转换框架与语言

Atlas是属于开源的项目,单向的混合型(描述性和命令行并存)模型转换语言,使用OCL来描述约束,描述规则的能力较好,易于应用。

Atlas转换框架较为主流[7],如图1所示。其中源模型符合元模型a,目标模型符合元模型b。元模型a和元模型b都符合惟一的元元模型。模型转换实例,它也是一种模型,它符合模型转换的元模型。模型转换的元模型也符合惟一的元元模型。

图1 Atlas转换框架

一个完整的Atlas模型转换程序,需要四个文件:元模型a、元模型b、源模型、模型转换实例。通过转换生成的目标是目标模型。

2.2 Atlas模型转换的优劣与补充

除了功能相对较强和用户较广之外,Atlas语言的语法相对简单容易理解,使用较方便,对于编程人员来说容易应用。此外,Atlas使用者不需要很强的数学功底,编程人员上手应用相对较容易。

Atlas也存在一些不足。MDA技术初衷就是尽量使开发过程自动化,减少开发人员工作量。目前Atlas在这方面还存在一些问题。由于功能单一,当模型复杂时需编写繁多转换规则,模型转换精确性还不高。由于转换过程是单向的,所以没有数据类型验证功能,模型转后前后数据一致性不能保证。

为了增强处理复杂模型系统的能力,通过下面两个办法改进现有转换模块。

首先,分析系统内各种模型,提高系统中模型的转换精度和完整性。针对系统静态结构模型,把有共同结构属性的模型进行提炼,设计具有普遍性的“抽象父类模型”;针对系统动态结构模型,对这些操作进行归纳和分类,总结出“抽象操作模型”,针对这些模型进行更进一步细化或者编写转换规则,最后把各种类的抽象模型整理集中在模型转换库,供转换框架调用。

其次,为了提高模型建立和转换的一致性,可以在模型转换的前后建立模型转换前置和后置检验环节。在操作中,在确定转换平台后,可以针对源模型和目标模型这两个文件进行操作。前置检验主要检查作为输入的源模型中指定字段是否符合转换规则的要求,在转换前进行检查,避免造成转换失败或者转换不完全;后置检验主要检查作为输出的目标模型中指定字段是否符合要求,与其他字段间是否满足设计需要,并且对于异常情况予以更正并告知用户。模型转化模块如图2所示。

图2 模型转换模块示意图

3 模型驱动开发Web应用系统

下面将通过Web应用实例具体的分析,说明在Atlas框架下进行模型转换所需的各种模型和转换规则的分析和设计思路。

3.1 源模型设计

源模型来自于用户需求,用户可以通过具备可视化开放功能的交互页面将需求提供给模型转换框架。

在作者研究的模型转换实例中,用户的需求将以形式化的文档,存储为XML文件格式。如图3所示,在文档中包含若干业务对象的属性特征和业务逻辑描述,在转换框架中,源模型经过转换规则处理最终会生成目标模型。

3.1.1 设计思路

通过人机交互页面获取用户需求,可以看作是系统按源模型结构对用户需求逐步细化的过程。通过逐步的模型定义和建立,分层次地将需求的粒度从大变小,同时将它们作为输入进行模型转换。

图3 源模型生成流程图

(1) 包含模块定义。这里指系统中明确的对象以及对其进行的操作集合。捕获用户Web应用需求,首先要明确在Web应用中都包含哪些对象,因为此后的操作都将和这些对象有关。如果是信息发布系统,它所包含的对象可能有栏目、文章、用户、部门等;如果是票务系统则可能包含剧场座位、演出场次等。一些基本常用的对象可以储存在Atlas库文件中,供用户选择,用户也可以在满足模型规范的范围内自定义模型。

(2) 模块功能定义。明确系统包含的对象之后,下一步就是明确与之相关的操作,使其构成一个完整的功能模块。在这一层,用户需要对操作进行定义,例如增加,删除,修改,查询,或者自定义操作名称。这一层的信息包含了系统内所有用户可以点击执行的操作集合。

(3) 操作功能定义。在这一层中,将对之前定义操作进行更详细的描述。经过分析,系统中的操作都是由数据库操作添加(Create)、查询(Query)、更新(Update)、删除(Delete)这些命令组成的,不同顺序的CRUD命令组合形成了不同的操作,因此这一层的工作是用形式化的格式将操作描述出来。当然由于参数和处理对象不同,本层中会允许执行内容不同CRUD命令存在。

(4) 详细操作定义。在这一层中将具体定义系统数据库操作的参数和返回值。例如,若之前定义过两个增加命令(add_one和add_all),在这一层里需要为这两个具体的数据库添加(Create)命令进行定义,明确这两个命令传递的参数和返回值,保证系统对数据库操作准确有效。

(5) 页面内容定义。为系统视图层的页面定义具体属性,包括页面处理的业务类型,包含的对象属性,提供的操作接口,显示的风格样式等信息。

3.1.2 源模型结构

依照上述设计思路,首先设计源模型对应的元模型a。在元模型a中,定义了源模型的组成结构,属性和相互联系。如以信息发布系统的栏目模块为例,如图4所示,可以看出源模型中定义了Column对象包含了一个type属性和Static对象和Action对象,同时明确了它属于Webpim对象。Static对象和Action对象分别对应用户需求的结构组成和功能操作两部分,具体需求在其中定义即可。

图4 元模型a片段

图5所示,是按元模型a定义规范得到的源模型。源模型储存为XML文件。文件中包含了系统内全部模块信息,每个模块信息又由表示对象的静态结构和表示操作的动态结构组成。这些信息由概括到具体,分层次将用户需求表示出来。在模型转换中编写的转换规则是以元模型a和元模型b的结构进行映射的,所以源模型必须依照元模型a的格式规范。否则在转换中就会出现所定义的转换条件和输入值不符合,发生异常错误的情况。

图5 源模型文档片段

3.2 目标模型设计

模型转换框架中,目标模型由源模型经转换规则处理后得到,将以形式化文档作为代码生成器的输入,储存为XML文件格式。

3.2.1 设计思路

不同于源模型,目标模型在转换规则处理后,其内容将按用户的需求或适合目标系统描述的层次结构,描述出其中的关键元素信息。目标模型具有如下特点:

(1) 目标模型与目标系统对应。目标模型设计根据的是目标系统,将目标系统中的关键信息元素整理集合成能表示目标系统内各层次结构关系、业务逻辑关系,形成目标系统的元模型b。经过转换规则定义元模型a与元模型b的映射关系[8],最后将由源模型生成目标模型。

(2) 保证系统顺利生成。为了保证不同技术背景用户的输入都能够生成出Web应用,并且保证生成的Web应用能够顺利运行。在目标模型中添加默认信息,这些默认信息将通过转换规则自动添加到目标模型中。

(3) 信息完整性。源模型中缺省的属性和值将被默认值取代或由系统自动生成,以确保模型完整性。另外,重复的部分也将被合并,避免出现模型缺失和冗余。

(4) 根据需要,计算得到模型数据。目标模型的一些属性值在源模型建立时还未产生,需要对源模型进行分析,通过计算和逻辑处理才能得到,这些属性值将保存在模型结构中指定对应的位置。

(5) 平台相关性。目标模型是平台相关的模型,将作为代码生成器的输入生成整个目标系统,因此在目标模型中,各种类型的对象除了相应的值以外还必须要有相应的平台类型与之对应。

3.2.2 目标模型结构

从设计思路出发,首先设计目标模型对应的元模型b。元模型b的设计要与目标系统的关键元素相符合。例如,目标系统采用MVC的架构设计,目标模型可以分为视图(View)、模型(Model)、控制(Control)三部分结构来表示目标系统,这样设计使目标模型与目标系统层次一致,可以更好地表示对应关键信息,如图6所示。

图6 元模型b片段

以此类推,如果目标系统采用SSH框架(Struts+Sping+Hibernate),目标模型也可分别对应这三个框架进行描述,最后组合成目标模型。

在确定元模型b之后,经过转换规则中定义的与元模型a的映射关系,就能从源模型得到目标模型。如图7所示,因为由转换规则映射得来,生成的目标模型的结构组成严格符合元模型b的规范定义,包含目标系统的结构层次和关键信息。之后,目标模型将作为代码生成器的输入,产生最后的目标系统。

图7 目标模型文档片段

3.3 转换规则设计

模型转换就是读取源模型,通过一组转换规则,将源模型转换为目标模型并输出的过程[9]。其中元模型a代表源模型,元模型b代表目标模型,在设计转换规则时首先需要保证能够实现目标系统;其次,要尽可能扩展转换规则内容,能够提高模型转换的粒度要求,以满足能够对表示系统细节特性的功能进行处理;最后,要保证源模型到目标模型的信息不会丢失或在用户不知情的情况下被覆盖。

如图8所示,源模型到目标模型的转换中,模型结构和模型数据都会发生变化。模型转换规则就是要为这些变化建立对应的映射关系。

图8 模型转换规则说明

模型结构方面,源模型侧重表现用户需求,目标模型侧重表现所生成系统结构。建立模型的出发角度的不同,必然将造成模型结构的差异。目标模型中可以从源模型中继承一部分结构,但必然会产生新的结构,这些结构中的键值信息不能从源模型中直接获取,但对于目标模型作为代码生成器输入又是不能缺少的,因为不能被省略掉。

模型数据信息方面,源模型的数据直接来自于用户的需求,数据较繁杂,会出现信息冗余的情况,目标模型的数据因为要作为代码生成器的输入,因此数据更精简,且包含的信息量相对较多。所以在模型转换规则中,就必须加入对模型数据进行计算和逻辑处理的映射关系,配合存入对应的目标模型结构中。

在实验中,模型转换规则及语法主要运用Atlas语言和OCL语言,完成复杂条件下模型转换的规则设计。如图9所示是部分转换规则映射关系,定义了元模型a中表示静态和动态结构的属性、操作与元模型b中表示目标系统特点的各层关键信息的联系。

图9 模型转换规则映射关系(部分)

3.4 模型转换补充设计

用户需求数量的增长和细节功能的增多,模型转换中对应的模型数量也将随之变大,层次关联也将变得更复杂。为了完成复杂业务逻辑,一方面要允许包含层次更多、组合更灵活的源模型反映用户需求;另一方面,要建立结构更复杂、粒度更小、更精确的目标模型来表示系统的复杂行和完整性。因此,模型转换环节中,必须对模型自身进行更高的限制和控制。

模型转换可以分为规范、转换、约束、调整这四个步骤[10],为了减轻转换规则设计的负担,在转换前后灵活增加先验后验程序来对模型中重要的部分或转换规则中处理易于造成冗余的部分进行检验。如果在转换前需要对各模型的名称和包名进行检验,确保转换不会造成混淆,在转换后需要对重要字段的类型进行检验不会出现数据类型不匹配等问题。

需要说明的是,这些模型检验环节也可以在模型转换规则中定义。为了使转换层次更加明确、规则设计更清晰、便于维护,所以采用独立于转换规则的先验和后验环节的设计。此外,为了保证模型转换的平台无关性,检验环节可以通过Atlas语言和OCL语言定义实现。

4 结 语

在此首先对MDA技术的发展进行介绍。随后,介绍了MDA技术中一种模型转换框架即Atlas框架,简要分析Atlas模型转换语言的优势和不足。最后,以模型驱动角度对一个Web应用进行分析,阐释了模型转换中源模型、目标模型、转换规则的设计思路,并完成了设计。下一步工作,将重点集中在模型精度和准确度提升方面,使模型转换满足更细致具体的用户需求。

参考文献

[1]Miller J,Mukerji J.MDA Guide Version 1.0.1[ EB/ OL ].htt p://www.omg.org/docs/omg/03 - 06 - 01.pdf,2003 - 06 -12.

[2]David S Frankel.应用MDA[M].鲍志云,译.北京:人民邮电出版社,2003.

[3]张征,何克清,刘进.一种基于规则的模型转换方法[J].计算机应用研究,2005(10):16-19.

[4]Akehurst D H,Kent S.A Relational Approach to Defining Transformations in a Metamodel[A].The Unified Modeling Language 5th Int′l Conf.[C].2002.

[5]Sheena R Judson,Robert B France,Doris L Carver.Speci-fying Model Transformations at the Metamodel Level[J].Proc of the Workshop in Software Model Engineering,2003.

[6]方海棠,何克清,卓识,等.一个基于模式和动作语义的MDA实现方法[J].计算机工程,2004,30(4):67-69.

[7]Frankel S.Model Driven Architecture:Applying MDA to Enterprise Computing[M].Indianapol:John Witey and Sons,2003.

[8]Jean Bezivin,Hammoudi S,Lopes D,et al.Applying MDA Approach for Web Service Platform[A].IEEE International Enterprise Distributed Object Computing Conference[C].2004:58-70.

[9]Sendall S,Kozaczynski W.Model Transformation:The Heart and Soul of Model-Driven Software Development[J].IEEE Sofeware,2003,20(5):2-8.

[10]Stuard Kent.Model Driven Engineering[J].IFM,2002:286-298.