VMTS: 元建模环境和模型转换系统的系统方法(Unified Handling of Modeling and Transfo...

理论计算机科学电子笔记127（2005）65-75www.elsevier.com/locate/entcsVMTS中元建模环境和模型转换系统的系统方法Tiham'erLevendovszky1，La'szl'oLengyel2，GermanMezei3和Hassan Charaf4布达佩斯技术经济大学自动化与应用信息学系匈牙利布达佩斯摘要高度可配置的元建模环境和图变换技术已成功应用于软件系统建模等领域。在本文中，这两种方法的统一处理说明了可视化建模和转换系统的工具。 概述了n层元建模环境的概念以及相关的拓扑和属性问题。建立在元建模技术的模型转换的两种选择，即遍历和图重写的方法进行了阐述。在我们的实现中，所有上述机制使用元模型作为一个共同的形式主义，它可以被认为是一个统一的基础存储，创建和转换视觉语言。该方法的可行性说明了转换生成C/C++代码从UML状态图。关键词：元建模环境，基于元模型的转换，模型驱动的软件开发，软件工程工具1介绍可视化建模环境和模型转换是高度研究的领域，其中包括模型驱动建筑技术的愿景1电子邮件：tihamer. aut.bme.hu2电子邮件：laszlo. aut.bme.hu3电子邮件：german.mezei@ aut.bme.hu4电子邮件：hassan. aut.bme.hu1571-0661 © 2005 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2004.12.04066T. Levendovszky等人理论计算机科学电子笔记127（2005）65[1]由OMG发布。本文提出了一种基于元模型的建模环境和模型转换的系统方法VMTS说明了一种方法，在这种方法中，模型存储和模型转换可以被统一处理，而将它们联系在一起的是元模型的概念基于元建模构建的建模环境是高度可配置的（可视化）建模工具，允许提前指定约束。模型转换可用于模型和代码生成或修改模型。 最有前途的方向之一是创建通用的转换系统：最常用的UML处理器需要包含丰富的语义信息来指定转换规则，因为目前标准的UML具有简单英语的语义，不能形式化以帮助规则制定。正如VMTS中所示，元建模也可以作为模型转换方法的基础。VMTS的设计目标如下：它是基于元模型的存储和转换的统一方法的概念验证实现。UML遵从性是确保实际适用性的一个重要特性。它的基本形式主义是一个标记有向图，以方便创建的正式背景，并直接说明的实证结果。VMTS应用XML等标准技术，并强制分离关注点：表示、存储和验证模块已尽可能清晰地分离。VMTS已在.NET中使用C#实现，但这里关注的是语言和环境无关原则，仅假设XML支持和面向对象语言。本文致力于概念的简明讨论，而不描绘实现细节。更多信息（约束处理、实现细节、与MOF的比较、UML元模型）请参考[2]。2n层元建模环境建模环境必须面对变化的挑战（即使在标准UML中，例如比较UML v1.4和v2.0）和各种模型（UML序列图，类图和特征模型）。为了保存满足这些要求的开发工作，VMTS使用元模型来创建一个灵活的、视觉上可配置的建模环境。元建模是基于实例关系，即UML类图元素和UML对象图元素之间的关系。这意味着VMTS使用简化的UML类图作为元模型语言来定义模型（例如，T. Levendovszky等人理论计算机科学电子笔记127（2005）6567类图、状态图）。如果UML类图被实例化，则涉及三个层：UML对象图、UML类图和UML类图的元模型除此之外，VMTS中还有两层：只读元元模型，它指定了元建模语言，以及内部结构中的一层（这是一个标记有向图）。VMTS的模型存储部分称为支持继承的属性图体系结构（AGSI）. AGSI层的设计是为了让每个模型都可以成为其他模型的元模型，但是上面讨论的五个层在实际场景中已经足够了。图1给出了只读元模型（最底层）、状态图元模型（中间层）和一个示例状态图（最顶层）的概要。2.1拓扑考虑AGSI可以通过三个基本结构来处理图：（i）节点，（ii）有向边和（iii）分配给节点和边的标签。到目前为止，它将是一个有向标记图的存储结构，因此需要添加元建模支持。每个节点和边分别与其他节点和边保持双向连接：这就是类型-实例映射。这些映射不能形成一个循环，以便图形可以组织成层，每个层对应于一个建模层。 虽然这种结构能够 为了在标签中存储模型拓扑、属性和外观信息，现代建模语言和环境（包括UML）要求附加的概念：（i）模型应该通过包含层次结构来遍历：每个节点具有唯一的父节点，该父节点可能包含它和几个其他元素。基本上，这种结构比在树视图中显示模型更适合于更容易的遍历和更好的结构化存储。因此，这种结构不是一个支持视觉表示的概念，即使表示从中受益。对于包含层次结构，AGSI保持了父子双向映射。(ii)继承支持（从后代到祖先的定向映射，不能包含循环）是每个建模系统的自然需求，即使是在元模型级别。(iii)关联类是不常见的构造，因为类（关联类）连接到边（关联）的中间。虽然这种安排可以通过插入一个没有语义意义的伪节点来解决，但能够存储在规则的图形结构中，出于概念上的原因，我们决定也添加对这个模型元素的支持。所有上述功能都支持AGSI中的硬连线。此外，从拓扑角度来看，继承需要特殊处理：后代类型从其祖先类型继承关系类型，即后代类型的实例可以与类型的实例相邻68T. Levendovszky等人理论计算机科学电子笔记127（2005）65与 祖 先 类 型 相 邻 。 例 如 ， 在 图 1 中 ， 两 个 TransitionEndPoint 可 以 经 由Transition链路连接，因此两个State也可以以这种方式连接。AGSI的只读根元模型如图1所示。SystemNode和SystemRelationship由AGSI提供。这些是对应于标记有向图模型的节点和有向边元素的硬连线构造。元模型指定了一个抽象的TransitionEndPoint，它是所有可以通过定向转换（SynchronizationBar，State）连接的元素的基础。一个State可以包含零个或多个TransitionEndPoints。在最上层描述了一个简单的状态图，它要求一个两位数的代码。输入代码有5秒的时间限制，如果输入错误的字符，可以清除设备重新开始输入。一旦成功，受保护的门就会打开。来自UML 1.5标准的一个更复杂的案例研究也已经解决了，它在[2]中可用。Fig. 1. AGSI的元模型层次结构和一个示例状态图2.2属性问题在带标签的有向图模型中，属性存储在标签中。在AGSI中，标签是XML文档，属性是以类似于XML的格式表示的。如果属性数据结构被实例化，则存在两种类型的属性：（i）元属性，其可以被实例化，以及（ii）驻留在元模型元素中但不出现在实例化的模型元素中的属性。 典型的例子是UML类中的属性和方法。属性（例如x：integer）被实例化（例如x= 10），T. Levendovszky等人理论计算机科学电子笔记127（2005）6569但是方法（例如f（x：integer）：bool）不会出现在相应的对象中。在AGSI中，元属性被转换为XSD文件，XSD文件是存储实例级属性的XML文件的模式。这种方法非常灵活：添加、删除和更改属性需要更改XML文件，该文件可以在任何现代编程环境中轻松地由工具处理。图2展示了元状态-状态实例化链的XML文档以及可视化表示。然而，在前一节中讨论的功能存在与属性相关的问题后代继承祖先的属性，因此XML文件应该沿着层次结构合并，这样根元素具有最低优先级，如果在继承层次结构路径中的多个元素中指定了具有相同名称的属性，则最低后代具有最高优先级。抽象节点不能实例化。由于边（SystemRelationship）也可以有属性，AGSI不需要关联类来为边指定元属性，但是也支持此功能。当合并边时，存储在边中的属性具有比驻留在关联节点中的属性图二. AGSI中的属性实例化3模型转换考虑到软件应用，有两个重要的类别的转换标记有向图。其中最简单、最通用的方法是遍历法，另一种是图重写法70T. Levendovszky等人理论计算机科学电子笔记127（2005）65机制本节介绍了这些方法，并揭示了动机的另一个方面：应用这些已经发明的数学结果来创建基于元模型的转换方法的正式背景，以及关于元模型作为转换和建模形式主义的存在的现有结果的扩展。模型转换意味着将转换过程开始时可用的输入模型转换为输出模型。模型驱动架构（MDA）[1]给出了一个更严格的定义：输出模型应该描述与输入模型相同的系统。由于VMTS被设计为能够指定更通用的转换系统，而不仅仅是MDA模型编译器，因此我们在定义中省略了MDA的等价性警告。3.1遍历模型处理器转换模型的最简单方法是使用特定的编程语言遍历它们，并更改输入模型的适当部分遍历模型处理器（TMP）实现这种方法通常需要五个基本的图形操作：（i）创建节点，（ii）连接节点，（iii）删除节点，（iv）删除边和（v）设置标签。当然，这些操作可能会有所不同，但这些类别通常可以观察到。就模型转换而言，这些操作通常有特定的参数，例如节点创建需要创建节点的类型信息，而set label通常支持属性。VMTS遍历处理器中的模型及其元素是面向对象程序设计语言中的规则对象。创建一个具有特定类型的节点就是创建一个具有相应类型的对象;删除一个节点意味着销毁相关的对象;属性可以通过以相应属性名称命名的成员变量来设置。删除边意味着删除从一个对象到另一个对象的引用边创建可以通过在源对象的适当数组成员中添加对目标对象的引用来执行，反之亦然，如果它是双向边。为了在面向对象的编程语言中生成模型处理器，必须考虑两个模型级别：（i）当前层，我们想要遍历（这些将以编程语言中对象的形式出现）和（ii）当前层的元模型层，因为它将为对象提供类定义。对于每个元模型，生成器（TraversingProcessorWizard）自动创建框架和元模型特定的代码，以便程序员可以通过对象容器或通过以name属性命名的变量（引用）来遍历模型T. Levendovszky等人理论计算机科学电子笔记127（2005）6571的模型元素。例如，如果在建模环境中状态的名称是s，则使用实例化State类的名称创建编程语言对象。模型处理代码生成器是一种特殊的TMP，在实际中使用最多.在VMTS中，遍历处理器的框架生成总是包括代码生成部分：元模型层被视为UML类图，类从它生成。3.2可视化模型处理器可视化模型处理器（VMP）并没有取代TMP，而是提供了一种可视化的模型转换方法。在VMTS中，VMP使用图重写作为转换技术。基本上，图重写系统是一组将图实例转换为另一个图的规则。在图重写中，存在由左手边图（LHS）和右手边图（RHS）组成的产生式规则。触发图重写产生式规则包括三个步骤：（i）在宿主图中找到LHS的出现。这意味着宿主图的子图同构于LHS。这个子图称为match。(ii)从Redex图中移除在LHS中但不在RHS中的节点和边。(iii)将RHS中的节点和边粘贴到Redex，但不在LHS中。这种技术已成功地用于几个转换系统中，其中一些在第4节中指出。在模型转换系统中，主图是转换步骤的输入模型，其（LHS，RHS对）由输入模型元素组成。然而，VMTS采用了[3]中介绍的一种新方法，该方法根据元模型指定了重写规则（LHS和RHS）。因此，必须找到输入模型的一部分来实例化LHS，而不是找到LHS的直接发生。在本文中，我们不关心的顺序的转换步骤，但检查一个步骤。在这种简化的方法中，我们称输入模型为应用规则的模型，输出模型为结果的转化步骤。在VMTS中，LHS和RHS使用UML类图语法定义。构成基于元模型的LHS规范的结构是继承和多重性支持。继承支持类似于OO语言的自然类型兼容性：派生类总是可以传递到期望祖先类的地方。这意味着LHS中的类元素总是与输入模型中的后代类型相匹配。这在规则和抽象类型中启用了泛化。多重性支持是通过在关联端允许多重性值来实现的。LHS和元模型之间最重要的区别如下：（i）LHS需要连接（即，一72T. Levendovszky等人理论计算机科学电子笔记127（2005）65从任何类到任何类的路径必须存在，忽略关联类型），(ii)LHS的匹配是最大的，在某种意义上，实际匹配的多重性值（与关联匹配的链接数）是指定的多重性区间中最大的可能值，与匹配的其他部分不矛盾。它是一个局部构造，因此输入模型中的所有匹配都不会被找到并进行比较以实现最大的实际多重性，这仅意味着不能向匹配添加更多的链接，该匹配也是特定LHS的匹配图3描述了AGSI中的规则规范。该规则从状态图中创建Code-DOM树.CodeDOM是一种抽象的基于图的代码表示，.NET框架能够自动生成例如C++代码。我们使用Quantum Framework [4]库以及生成的代码来运行状态机。CodeDOM的概念是独立于平台的，相应的构造可以是例如Eclipse JDT Core的Java文档模型[5]。在为CodeDOM构建了元模型之后，将彻底应用图3中的重写规则。该规则将一个状态与所有由传出转换（如果有的话）所针对的状态一起，并生成相应的类声明，成员字段和带有参数和代码部分的方法。在规则中，只使用来自statechart meta和CodeDOM meta的元模型元素，并且为LHS找到实例并为RHS创建实例LHS的语义已经描述过了，但是处理RHS（触发规则）与属性转换问题有关：如果RHS中的边具有精确的多重性，那么相关的对象必须用属性填充;如果多重性值不是唯一确定的（如 *），则创建的属性集的数量决定要创建的对象。属性转换是由JavaScript脚本完成的。LHS元素可以与RHS元素具有所谓的因果关系。因果关系可以表示LHS元素的修改或删除，以及创建一个RHS元素。图3显示了状态图代码生成的因果关系。 JavaScript脚本可以访问匹配对象的属性到LHS元素，并为因果关系指向的RHS元素产生一组属性。这种方法已成功地应用于VMP状态图的代码生成中，并且在需要时，这种思想可以很容易地扩展（甚至扩展到比XSL更复杂的语言）。图4中的XSL片段显示了转换如何为Quantum Framework中的状态创建新方法。T. Levendovszky等人理论计算机科学电子笔记127（2005）6573图三. AGSI中的规则规范见图4。 为状态创建新方法的XSL代码段4相关工作VMTS介绍了一种新的方法，统一的元建模环境和模型转换的元模型为基础的共同形式主义。因为它是建立在两个领域现有系统中的研究和实验的基础上的。通用建模环境（Generic Modeling Environment，GME）是一个高度可配置的元建模工具，支持两层：元模型层和建模层。当元模型是已编辑模型时，GME可用于元模型编辑，并通过遍历处理过程（MetaInterpreter）将其转换为元模型层以供模型编辑使用。GME解释器类似于TMP。GME中的模型和元模型层不能像两层通用数据模型（UDM）[7]那样被统一处理，然而，元模型和模型层是用相同的数据结构实现的。这个概念已经在VMTS中推广到n层元建模环境。元对象设施（MOF）[8]定义了一个四层架构，但建模环境不在预期的使用场景中，因此没有为此提供指南NetBeans元数据存储库（MDR）[9]是一个符合MOF的存储库，允许开发人员通过Java元数据访问存储库74T. Levendovszky等人理论计算机科学电子笔记127（2005）65接口（JMI）和XMI，而不是显式转换支持。使用它的元模型独立的响应API，可以编写TMP。Eclipse建模框架（EMF）[5]是一个支持TMP的建模环境有许多图形转换系统，例如[10][11][12]，VMTS最受GReAT模型转换系统[13]（因果关系，参数传递）和PROGRES [14]（基数断言）的影响。5结论本文提出了一个统一的模型存储和转换设施的系统。将这些技术结合在一起的是基于元模型的规范。本文说明了这种系统统一地处理建模环境和转换系统的可行性。存储系统的可扩展性和可配置性是通过元建模实现的。已经说明了基于元建模技术构建的建模环境需要一些硬连接的构造：节点、边、标签（实际上是XML格式）、继承、包含层次结构和关联类。元模型的存在促进了模型元素映射到任何面向对象的编程语言的情况下，遍历模型处理器。视觉处理器在规则规范中使用元模型元素，确保统一处理强大的新颖构造和其他转换系统中应用的构造。由于它们的重叠，但不等同的应用领域，可视化和遍历模型处理器应该共存，作为不同目标的适当工具。已经表明，一种类型的实例化（UML类和对象图元素之间的实例化）足以构建一个n层元建模环境（与MOF相反），并且元模型可以以适合所有讨论目的的方式指定。如果开发人员熟悉UML（类图，对象图，OCL），那么使用相同的概念和语言来描述模型转换也是非常容易的。引用[1] MDA指南版本1.0.1，OMG，文档编号：omg/2003-06-01，2003年6月12日http://www.omg.org/docs/omg/03-06-01.pdf[2] 可视化建模与转换系统主页。http://avalon.aut.bme.hu/~tihamer/research/vmts/[3] 莱文多夫斯基·T G. Karsai，M. Maroti，A. Ledeczi，H. Charaf，[4] Samek M.，T. Levendovszky等人理论计算机科学电子笔记127（2005）6575[5] Budinsky F.， D. Steinberg，E.梅克斯河Ellersick，T.J. Grose，Addison-Wesley，2003年[6] Ledeczi A.，A. Bakay，M.Maroti，P.Volgyesi湾Nordstrom，J.洒吧，G。Karsai，[7] Magyari E.，A. Bakay，A.朗，T. Paka，A. Vizhanyo，A.阿格拉瓦尔湾Karsai，[8] OMG元对象工具http://www.omg.org。[9] NetBeans元数据存储库主页：http://mdr.netbeans.org/。[10] 好的，D。，“A uto m at e M o de l T r a ns for m at i on s for the A nalys is of I T Sys t em s“，P h.D. 2003年，[11] FUJABA（From Uml to Java And Back Again）主页：http://wwwcs.upb.de/cs/fujaba/。[12] 属性图语法系统（Attributed Graph Grammar System，AGG）：http://tfs.cs.tu-berlin.de/agg/网站。[13] Karsai G.，A. Agrawal，F. Shi，[14] Zu¨nd orfA. ，“G raph P atter n M a tch i n g in P R O G R E S“，G raph Grammar s and T heirApplications in Computer Science ， LNCS 1073 ， J. Cuny 等 人 （ 编 辑 ） ， Springer-Verlag ，（1996），454-468。