软件工件模型合并：QVT关系冲突解决与可追溯性在类图集成中的应用

理论计算机科学电子笔记166（2007）5-26www.elsevier.com/locate/entcs形式化模型合并在类图集成ArturBorona t1Jo s'eA'. 汽车销售2IsidroRamos3Patricio Letelier 4瓦伦西亚理工大学信息系统与计算系西班牙巴伦西亚摘要软件工件的集成存在于软件工程领域的许多场景中：面向对象建模，关系数据库，XML模式，本体，面向方面编程等。在模型管理中，软件工件被视为可以通过泛型操作符进行操作的模型，这些操作符是独立于使用它们的上下文指定其中一个操作符是Merge，它支持模型的自动集成通过应用此操作符实现的合并模型的解决方案比在软件工程领域的许多上下文中普遍存在的ad-hoc解决方案更抽象和可重用。在本文中，我们提出了我们的通用模型合并的自动化方法，从实用的角度来看，通过使用QVT关系语言的软件工件之间的冲突解决和可追溯性提供支持我们专注于我们的操作符Merge的定义，并将其应用于类图集成。关键词：模型驱动工程，模型管理，模型合并，冲突解决，QVT关系。1引言模型驱动开发哲学[15]认为模型是软件开发过程中的主要资产。模型收集在高抽象级别上描述信息系统的信息，这允许在生成式编程技术之后以自动化的方式开发应用程序[12]。在这个过程中，模型构成了软件工件，这些软件工件经历了来自问题空间的细化（在那里它们捕获了应用程序的需求1电子邮件地址：aboronat@dsic.upv.es2电子邮件：pcarsi@dsic.upv.es3电子邮件：iramos@dsic.upv.es4电子邮件地址：letelier@dsic.upv.es1571-0661 © 2006 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2006.06.0136A. Boronat等人理论计算机科学电子笔记166（2007）5到解决方案空间（在那里他们指定设计、开发和部署 最终软件产品）。在此细化过程中，将若干任务应用于模型，例如转换和集成任务。这些任务可以从模型人的角度来执行。模型管理在[2]中被提出作为一种通过通用操作符处理软件工件的方法，这些操作符不依赖于元模型，而是通过处理模型之间的映射。这类运算符将模型作为一等公民来处理，通过避免在编程级别上工作来提高抽象级别，并提高解决方案的可重用性基于我们在正式模型转换和数据迁移方面的经验[8]，我们正在研究模型驱动开发环境中模型管理趋势的应用。我们已经开发了一个框架，称为MOMENT（MOdelmanageMENT）[25]，它嵌入到Eclipse平台中，并通过Eclipse建模框架（EMF）[14]提供了一组通用操作符来处理模型。定义的一些简单操作符是：两个模型之间的并集、交集和差，应用QVT变换将一组模型转换 复数运算符可以由其他运算符的合成来定义。在本文中，我们提出的操作合并的时刻框架从实用的角度来看。模型管理方法的基本形式是Maude [11]。我们应用它作为一种新的解决方案，在用例驱动的软件开发过程中的UML类图本文的结构如下：第二部分介绍了一个案例研究，作为本文其余部分的一个例子;第3节描述了我们的交易方法- 通过工业建模工具与模型进行交互，还介绍了操作符Merge的通用语义;第4节介绍了 操作符Merge到UML元模型;第5节解释了第六节讨论了一些相关的工作;第七节总结了我们方法的优点2案例研究：使用部分类图进行用例分析基于UML的软件开发方法提出了一种过程是用例驱动的方法[17，18]。这意味着所有工件（包括分析和设计模型，其实现和相关的测试规范）都有来自用例的可追溯性链接。这些工件通过几个转换步骤进行细化。从用例模型获得分析模型可能是实现完全自动化的机会最小的转换。用例模型必须牺牲精确性，以促进可读性和验证，因此用例分析主要是手动活动。当用例模型有许多用例时，管理每个用例和结果类图中相应元素之间的可追溯性可以 困难的任务在这个场景中，处理每个用例似乎是合理的A. Boronat等人理论计算机科学电子笔记166（2007）57Fig. 1.用例模型。图二、与相应用例关联的部分模型并注册它的部分类图（这是表示分析模型的结果类图的一部分）。关于可追溯性，这个策略是一个实用的解决方案，但是当多个团队成员并行处理不同的用例时，部分模型之间的不一致或冲突经常出现，这必须在获得集成模型时解决我们提出了一个案例研究，说明了我们的运营商合并可以有效地处理上述建立所需的需求我们提出了一个系统的一部分在我们的示例中，我们将关注图1所示的用例模型的片段。执行元系统管理员管理用户帐户。作者向会议提交论文PCChair向PCMembers分配意见。每一份提交的材料都由几个PCMember使用审查表格进行评估。完成所有评审后，PCChair根据评审表中的评估对提交的材料进行排名。由于可以发表的论文数量有限8A. Boronat等人理论计算机科学电子笔记166（2007）5在提交的意见书中，并考虑到既定的排名，一些意见书被选中，其余的被拒绝。然后，通过电子邮件通知所有作者，并附上其提交的审查表格。图2显示了支持相应用例所需功能3Merge运算符的泛型语义在模型驱动开发的上下文中，模型由描述某些物理的、抽象的或假设的现实的元素集合组成。 在定义过程中，模型、抽象和分类是需要考虑的准则。元模型只是建模语言的一个模型。它定义了模型族在我们的框架中，元模型被视为代数规范，其中 定义模型管理操作符，以便它们可以应用于符合元模型的所有模型。在下面的部分中，我们将描述将Merge模型应用于符合特定元模型的模型的通用基础设施，并且我们将重点关注Merge操作符的通用语义更详细地说。3.1MaudeMaude [11]是一种高性能的重写语言和系统，支持等式和重写逻辑规范和编程。合并运算符在Maude功能模块5中有详细说明。功能模块通过隶属度方程理论描述数据类型和对数据类型的操作。在数学上，这样的理论可以被描述为一对（E，EA），其中：是指定类型结构（排序，子排序，种类和重载运算符）的签名; E是函数模块中声明的等式和成员关系的集合; A是为不同的运算符声明的等式属性（结合性、交换性等）的集合。计算是等式演绎的形式，其中等式从左到右用作简化规则，规则是Church-Rosser和终止。3.2QVT关系语言模型合并过程涉及可以被视为模型转换过程的组合任务，其中要合并的两个输入模型也是模型转换的输入。 合并操作符在MOMENT框架中以通用的方式定义，但它也可以由特定领域的专家用户专门化。为了在我们的方法中提供对可扩展性的支持，我们选择了标准的QVT关系语言[23]。在QVT关系语言中，模型转换是在几个元模型中定义的，这些元模型被称为转换的域一个QVT transfor-[5]在附录A中，我们附上了用于定义算子和方程的符号。我们参考[10]以了解更多细节。A. Boronat等人理论计算机科学电子笔记166（2007）59----形式参数说明参数传递MM态射形式参数包含pTRIVMERGE{X：：TRIV}诱导h通过态射参数化规格说明实际参数规格SigMM合并{MM}p'实际参数包含值规范图3.第三章。 MERGE {X：：TRIV}参数化模块的参数传递图。信息由QVT关系构成，QVT关系成为声明性转换规则。QVT关系指定了不同候选模型的模型元素之间必须保持的关系。转换的方向是在通过选择特定域作为目标来调用它时定义的。如果目标域在QVT转换中被定义为可执行的，则执行转换。如果目标域被定义为checkonly，则只执行检查。 我们的方法中使用了这两种类型的转换，我们将在下面的部分中进行解释。3.3合并操作符的通用基础结构合并运算符在参数化理论MERGE X：：TRIV中被指定。该理论还扩展了其他理论，为OCL [7]和QVT关系语言[6]提供支持。当Merge操作符的语义被专门化时，OCL和QVT分别是执行查询6和模型转换的 标 准 语言 。图3表示了参数化机制，它显示了如何将Merge操作符应用于MOMENT框架中的不同元模型。 在以下各节将解释图中所涉及的元件3.3.1形式参数TRIV是形式参数的代数规范，在Maude中称为理论。TRIV理论仅由一种类型构成：TRIV是Elt类型.结束。3.3.2实际参数一个名为SigMM的签名提供了一个特定元模型的构造函数，它被指定为通过代数项来表示模型。SigMM规范构成了MERGE X：：TRIV模块的实际参数，并为元模型中定义的每个类型提供了一个构造函数，以及元模型中出现的类型之间的继承层次结构例如，我们考虑Ecore元模型[9]作为UML类图元模型的实现。在Ecore元模型中，6在这种情况下，我们使用OCL作为查询语言，如QVT标准所推荐的。10A. Boronat等人理论计算机科学电子笔记166（2007）5------- -它定义了一个类、一个属性、一个操作等等。该签名是从元模型自动生成的，考虑到可能出现在元模型中的以下元素：非抽象类，通过代数构造器表示，其参数是属性（简单数据类型）和引用（标识符的集合）;以及类层次结构，通过子排序关系表示。在为Ecore元模型7生成的签名中，类EClass通过ecore-EClass排序表示，其构造函数是：opString * nameString * instanceClassNameString * instanceClassString * defaultValue布尔 * 摘要Bool * 接口OrderedSet{QID}* eAnnotationsOrderedSet{QID}* ePackage. . . ->ecore-EClass [ctor].所有生成的排序都是一个人工排序的子排序，在本例中称为在Maude的隶属方程式逻辑中，排序通过子排序关系被分组为等价类，称为类。通过向所有其他排序添加一个超级排序，我们将所有排序折叠成相同的种类，以便属于签名的排序（表示类）的所有术语（表示类实例）可以用作集合中的元素。由EMF元模型生成的签名构成模块MERGE X：：TRIV的实际参数。此任务由Ecore模型的MOMENT3.3.3参数化模块MERGE{ X：：TRIV}一个名为MERGE X：：TRIV的参数化模块，它为Merge操作符提供了通用规范。在MOMENT中，合并运算符使用Maude代数语言公理化地定义。Maude允许我们以抽象、模块化和可扩展的方式指定运算符，以便我们可以从通用和可重用的角度定义其语义。合并运算符的具体说明在3.4.4节和附录B中解释MERGE X：：TRIV模块还提供了将模型指定为一组元素所需的构造函数，通过扩展我们对OCL的代数规范[7]。为了理解我们如何将模型表示为集合，我们将介绍对集合的底层OCL支持。在OCL提供的四种集合类型中，Set是包含有效OCL类型实例的集合，其中顺序无关，不允许重复元素。为了表示一组无序的元素，我们引入了Magma X排序。这种排序的构造函数具有符号因此，与整数一起工作此外，我们可以说，7为Ecore元模型生成的整个签名附在附录B中。A. Boronat等人理论计算机科学电子笔记166（2007）511- -- -}{--“1，2，3”和“3，2，1”表示以交换和关联属性为模的同一组元素。在我们的OCL规范中指定Set类型的Maude代码如下：(i) 对Magma {X}进行排序。(ii) subsortX$Elt Magma {X}[ctor].(vii) op、 ：Magma{X}Magma{X}->Magma{X}[ctor asphyroid：empty-magma].(viii) 操作集合{ }：岩浆{X}->集合{X}[ctor]。(ix) opempty-set：->Set {X}[ctor].(x) eqSet {empty-magma}= empty-set。岩浆X类的术语被用来定义集合（第（viii）行）。排序集合X可以被认为是一个抽象概念，因为它没有特定的构造函数。等式（x）保证了空集的相容性，因为包含空元素组（empty-magma）的集合也是空集。3.3.4MM视图为每个Maude简单数据类型定义了一个视图，以处理简单数据类型的集合。例如，为了处理整数集合，定义了以下视图：view Int from TRIV to INT是对Elt toInt排序。恩代夫此视图用于将MERGE{X：：TRIV}模块实例化为MERGE{Int}。这样，下面的示例就是一个有效的整数集合：Set{1，2，3}。MM视图是将TRIV形式参数的元素与SigMM实际参数的元素相为了将模型表示为集合，我们通过MM视图将为元模型（例如ecoreNode）生成的超级排序映射到TRIV理论的排序Elt。例如：从TRIV到sigecore是对Elt到ecoreNode排序。结束 。因此，我们可以使用构成SigMM理论的构造函数来定义表示相应类实例的术语。例如，Set（ecore- EClass 'a“EClass””false false empty-orderedset。. .）是仅包含称为“EClass”的类的模型的表示。3.3.5实例化的模块SpMM一个名为SpMM的模块实例化了参数化模块MERGE X：：TRIV，它通过MM视图将SigMM作为实际参数传递。在实例化过程中，Merge操作符被定制为元模型的构造，由SigMM表示。12A. Boronat等人理论计算机科学电子笔记166（2007）5--这提供了指定符合以下标准的模型所需的构造函数 作为一组元素，如上所述。这一事实还提供了Merge操作符，可以自动应用于符合此元模型的模型。为了能够操纵UML模型，它们必须被表示为SpMM代数规范的项，即表示类实例的项的集合（通过从元模型的类在SpMM模块中，合并运算符的指定也可以通过以特别和更准确的方式简单地向合并运算符添加新公理来指定为元模型，利用两个互补的观点：通用基础设施和特定领域的知识。这些特征将在第4节和第5节中进一步阐述3.3.6包含态射p和p在图3中，p和p'是包含态射，表明形式参数-参数化规格中包含参数规格，值规格中包含实际参数规格。h态射是通过使用MM参数传递态射将参数化模块的元素与合并MM值指定的3.4Merge运算符的泛型语义Merge操作符将两个模型作为输入并生成第三个模型。 如果A和B是特定元模型代数规范中的模型（表示为项），对它们应用Merge运算符会产生模型C， A的成员和B的成员的集合，即A和B的集合。 考虑到模型中不允许重复，因此并集是不相交的。为了定义Merge操作符的语义，我们需要引入三个概念：等价关系、冲突解决策略和刷新一种构造。3.4.1等价关系语义等价关系是在属于不同模型但属于同一元模型的元素之间定义的。这种关系由运算符Equals体现。声明操作符Equals如下：操作等于：设置{X}设置{X}设置{X}设置{X}->布尔。其中第一个参数是要比较的第一个模型，可能只包含一个元素;第二个参数是包含第一个参数的整个模型作为子集;第三参数是要比较的第二模型，并且它也可以仅包含一个元素;第四模型表示第二输入模型，并且包含第三参数作为子集。第二个和第四个论点是必要的，因为我们将所有理论定义为隶属方程逻辑中的函数模块。因此，内存状态的概念在此上下文中并不存在A. Boronat等人理论计算机科学电子笔记166（2007）513关于我们、并且这些参数允许在整个输入模型的结构中导航，以便检查等价关系是否成立。Equals操作的泛型语义与语法等价一致。Equals运算的公式说明如下：变量N：X$ Elt.vars模型1模型1b模型2模型2b：集合{X}。变量M1 M2：岩浆{X}。eqEquals（Set {N，M1}，Model1，Set {N，M2}，Model2）= Equals（Set {M1}，Model1，Set {M2}，Model2）。eqEquals（empty-set，Model1，empty-set，Model2）= true。eqEquals（Model1，Model1b，Model2，Model2b）= false[owise].其中，排序X$Elt表示模型的元素（集合X），集合X是集合集合的通用排序，MagmaX是表示集合的元素组的排序。 第一个等式指出，如果元素N（第一个参数）也存在于第二个模型（第三个参数）中，它们是等价的（这个方程 递归地应用于模型1和模型2的所有元素）;第二个等式构成递归的基本情况;第三个等式允许指示模型1或模型2中的元素何时不等价。这种通用语义可以通过考虑特定元模型结构的QVT只检查关系来丰富。 这在第4节中有更详细的解释。3.4.2冲突解决策略在模型合并过程中，当两个软件工件（每个属于不同的模型）被认为是等价的时，必须删除其中一个。它们的语法差异使人们对哪一个应该是合并元素的语法结构产生了疑问。在这里，冲突解决策略开始发挥作用。 冲突解决策略由操作符Resolve提供，其通用语义由首选模型策略组成。当合并操作符应用于两个模型时，必须选择一个作为首选。这样，当两组元素（属于不同的模型）由于Equals操作而相等时，尽管它们在语法上不同，但首选模型的元素优先。Resolve操作符的签名如下：操作解决：集合{X}集合{X}集合{X}->元组{X，TraceabilityMetamodel，TraceabilityMetamodel}。其中，第一个参数是要合并的第一个模型，它只包含一个元素;第二个参数是包含第一个参数的整个模型作为子集;第三个参数是要合并的第二个模型，并且它也只包含一个元素;第四个模型表示第二个完整模型，并且包含第三个参数作为子集。运算符的第二个参数（合并运算符的第一个输入模型）被作为首选模型。Resolve运算符的一般语义如下：eq解析（集合{N1}，模型1b，集合{N2}，模型2b）=（设置{刷新（N1，模型1b，模型2b）}GenerateTrace（N1，N1）、14A. Boronat等人理论计算机科学电子笔记166（2007）5GenerateTrace（N2，N1））[owise]。其中Resolve运算符生成三个元素的元组。 在这个tuple中：第一个元素是合并元素，与第一个模型的元素一致第二个结果是在源元素N1和结果元素之间生成的迹线（该轨迹属于在第一模型和所得到的合并模型之间生成的轨迹模型）;第三个导致在源元素N2和结果元素N1之间的迹线（该迹线属于在第二个模型和第二个模型之间生成的迹线模型）。 产生的合并模型）。Resolve操作符的语义也可以通过强制的QVT关系为特定的元模型定制。此功能在第4节中有更详细的解释。3.4.3茶点需要刷新将非重复元素复制到合并模型中 如果我们在案例研究中合并模型B和C ， 并 将 模 型 B 作 为 首 选 模 型 ， 则 模 型 C 的 类 PCMember 由 于 模 型 C 的 类Submission已被模型B的类Submission所取代，因此指向模型C的类Submission的引用不再有效。因此，必须更新这一参考资料。特定元模型构造项的更新由操作符Refresh实现。3.4.4合并运算符Merge操作符将符合相同元模型的两个模型作为输入。Merge运算符的输出是合并模型和两个迹线模型，这两个迹线模型将输入模型的元素与输出合并模型的元素相关联。因此，这些由Merge操作符自动生成的跟踪为保持输入模型和新合并模型之间的可追溯性提供了全面支持。操作符的声明如下：操作合并：集合{X}集合{X}->元组{X，TraceabilityMetamodel，TraceabilityMetamodel}。Merge操作符使用为元模型定义的等价关系来检测两个输入模型之间的重复元素当发现两个只属于一个模型的元素（在另一个模型中没有重复）将被刷新并直接复制到合并的模型中。合并运算符的方程说明见附录C。A. Boronat等人理论计算机科学电子笔记166（2007）515{}{}4要合并的Ecore元模型的特定语义Uml类图在本节中，我们简要地描述了用户如何向Merge操作符添加特定的语义来集成UML类图，这些类图是通过Ecore元模型在EMF中实现的。 为了实现这一目标，用户只需为运算符Equals和Resolve添加特定公理。这是通过使用QVT关系语言实现的。4.1等价关系专门化要定义模型元素之间的等价关系，用户可以在仅检查模式下使用QVT关系语言。在此上下文中只接受具有两个域的checkonly转换。 在我们的方法中，这两个域必须引用相同的元模型。例如，两个域都是Ecore元模型，用户可以在需要时为元模型中出现的每个类添加QVT关系。这样的QVT关系充当必须保持在两个Ecore模型的元素之上的等价关系。这些QVT关系也用于合并过程中，以检查两个元素是否相等，从而消除重复。在这个例子中，下面的关系可以被定义为：如果两个类属于同一个包，并且它们具有相同的名称8，则它们是相同的：类等价className：String;checkonly domainecoreDomain1 c1：EClass{ePackage = p1：EClass，name=className}的情况;checkonly domainecoreDomain2 c2：EClass{ePackage = p2：EClass，name=className}的情况;当EPackageEquivalence（p1，p2）;}}其中EPackageEquivalence是在同一转换中定义的另一个QVT关系，描述两个EPackage实例何时是等价的（例如，通过名称）。在我们的方法中，这种等价性可能涉及两个模型的几个实例，如上面的例子，其中EClass实例和EPackage实例用于检查两个类是否等价。然后将由这类只检查QVT关系构成的只检查QVT变换编译成Equals算子的方程。运算符Equals的特定语义是通过从QVT Relations转换编译获得的。对于该示例的QVT关系获得的等式如下：ceq等于（集合{N1，M2}，模型1，集合{N2，M2}模型2）=[8]我们选择这些标准作为例子。然而，它们可以由用户定制为特定的没有什么能阻止我们向模型的元素添加语义注释，并使用这些信息来确定哪些元素是相等的。{16A. Boronat等人理论计算机科学电子笔记166（2007）5关于我们如果（（（N1.name）==（N2.name））和（等于（(N1：：ePackage（Model1））->asSet，Model1，（N2：：ePackage（Model2））->asSet，Model2）））然后相等（集合M1、模型1、集合M2、模型2）其他假fiif（N1：：oclIsTypeOf（？ ”EClass”;和（N2：：oclIsTypeOf（？ ”EClass” ; Model2))其中表达式（N1：：ePackage（Model1））允许从类N1和（N1：：oclIsTypeOf（？“EClass”; Model 1））检查元素N1是否是类EClass的实例。在合并过程中，这个等式允许检查部分模型B和C的Submission类是否在checkonly QVT Transformation中，可以使用OCL表达式来定义helper函数，以操作和比较名称，并导航相应模型的结构。例如，可以用这种方式轻松实现同义词库函数，以指示模型A中User类的userid属性等效于模型D中PCMember类的login属性。因此，用户只需要知道标准的QVT关系语言和特定领域的知识，因为我们的方法中使用的底层形式主义仍然是完全隐藏的。4.2冲突解决策略专业化认证为了细化合并操作符，冲突解决策略也可以被专门化。在合并过程中，当Merge运算符找到两个重复项时，应将它们集成。这种集成涉及转换过程，其中可以考虑两个副本的信息来定义合并的模型。因此，可以使用强制QVT变换来细化冲突解决策略，就像使用仅检查QVT变换来细化通用等价关系一样。一个额外的等式完成了Resolve操作符的通用语义，以便专门用于特定的元模型：eq解析（集合{N1}，模型1b，集合{N2}，模型2b）=ModelGen（merge ;？集合{N1}？Model 1b？设置{N2}？模型2b）。在此等式中，Resolve运算符调用ModelGen运算符，该运算符执行模型转换，其等式语义通过编译QVT转换自动获得，QVT转换先前由领域专家用户定义。 一种QVT变换，用于定义 特定冲突解决策略具有三个域。所有这些都引用了所研究的元模型（在我们的示例中是Ecore）。 前两个域被定义为checkonly，它们只查询Merge操作符的两个输入模型。第三个域被定义为强制，它是产生合并元素的域。在案例研究中，当我们将模型B的Submission类与A. Boronat等人理论计算机科学电子笔记166（2007）517{}{}{}提交模型C时，我们要整合各自的属性、引用和操作。以下QVT关系旨在执行此任务：String：String;checkonly domainecoreDomain1 c1：EClass{ePackage = p1：EPackage，name = className}的情况;checkonly domainecoreDomain2 c2：EClass{ePackage = p2：EPackage，name = className}的情况;执行域ecoreDomain3 c3：EClass{ePackage = p3：EPackage，name = className}的情况;当ePackageMerging（p1，p2，p3）;}其中，EAttributeMerging（c1，c2，c3）; EReferenceMerging（c1，c2，c3）;EOperationMerging（c1，c2，c3）;}}其中，在when子句中调用的EPackageMergingQVT关系确保两个EClass实例的容器包必须相等，以便将当前关系应用于类。在where子句中调用的QVT关系通过合并它们的属性、引用和操作来确保合并过程继续进行用户定义以专门化冲突解决策略的强制QVT变换被自动编译成ModelGen等式9。ModelGen10是体现MOMENT框架中的模型转换的操作符，并由Resolve操作符调用。上述QVT关系的编译为ModelGen运算符生成以下QVT方程ceqModelGen（EClassMerging ;？ 集合{N1，M1}？ 模型1？ 集合{N2，M2}？ 型号2）=（设置{新（“EClass”）：： ePackage<（ModelGenRule（EPackageMerging;？ ((N1：：ePackage（Model1））->asSet）？Model1？ ((N2：：ePackage（Model2））->asSet）？Model2））：： name}->包括（p1（ModelGenRule（EAttributeMerging;？ 集合{N1}？ 模型1？ 设置{N2}？ 模型2）））->包括（p1（ModelGenRule（EReferenceMerging;？ 集合{N1}？ 模型1？ 设置{N2}？ 模型2）））->包括（p1（ModelGenRule（EOperationMerging;9实际上，该方程是为ModelGenRule运算符生成的，它表示整个转换的一个转换规则。为了清楚起见，我们在本文{18A. Boronat等人理论计算机科学电子笔记166（2007）5中跳过了这个细节。10关于MOMENT框架中ModelGen操作符和模型转换过程的更多信息可以在[6]中找到。A. Boronat等人理论计算机科学电子笔记166（2007）519？ 集合{N1}？ 模型1？ 设置{N2}？ 模型2）））->包括（p1（ModelGenRule（EClassMerging;？ 集合{M1}？ 模型1？ 设置{M2}？ 模型2）））->装饰、第一道模型计算、第二道模型计算）if（N1：：ecore-EClass）和（N2：：ecore-EClass）。在这个等式中：运算符-表示赋值操作;表达式New（“EClass”）创建EClass类的一个新的空实例;分配给引用ePackage的值是将包含合并类的结果包（通过EPackageMerging 转 换 规 则 获 得 ） ; 前 三 个 包 含 允 许 将 转 换 规 则EAttributeMerging、EReferenceMerging和EOperationMerging的输出添加到最终结果11 12 ;最终包含允许通过递归地将EClassMerging关系应用于SetM 1和SetM 2的其余EClass实例来<该等式返回一个三元组，其中第一个分量表示合并模型的元素，第二个分量表示将第一个输入模型与合并模型相关联的跟踪模型的轨迹，第三个分量表示将第二个输入模型与合并模型相关联的跟踪模型的轨迹。在该示例中，已跳过迹线的生成。这个过程包括创建一个新的跟踪，其中domain属性引用输入元素，range属性引用新生成的元素13。5合并过程在本节中，我们将介绍用于整合案例研究中的五个部分类图的合并过程。下面的四个步骤如表1所示，其中merge操作符的第一个参数是首选参数。 在此表中，第一列表示步骤编号;第二列显示Merge操作符的调用;第三列描述了在合并步骤中出现的一些主要冲突;第四列表示包含冲突元素的部分模型;后者表示通过Resolve操作符解决冲突。在合并过程的每一步之后，自动生成两个映射模型。这些映射通过注册应用于源部分模型的元素的转换，并将它们与合并模型的元素相关联，从而提供对可追溯性的全面支持。 在MOMENT框架中，提供了一组操作符来双向导航映射[5]：从部分模型到合并模型（为从11由于ModelGenRule的返回值是一个三元组，p1获得第一个组件，它是一个包含合并模型元素的集合[12]在这些关系中，我们假设在第5节的合并过程中考虑了继承的语义[13]为了进一步研究我们在MOMENT框架中提供的可追溯性及其适用性，我们参考[5]20A. Boronat等人理论计算机科学电子笔记166（2007）5模型融合冲突模型决议1=合并（B，C）属性的多重性关键字（类提交）。B -CMultiplicity [1.. 5]（首选型号）2=合并（D，E）3致敬作者（类提交）（模型）=3.2. 接受的属性类型（类提交）E -B类型Boolean（首选型号）合并（DE，BC）3.3. 多方面的合作，D - C多样性1..一比一...1类之间的关系，Sion和PCMember（首选型号）4=合并（A，BCDE）属性userid（类User）和属性login（类PCMember）通过同义词词典识别为相同。A -D继承的特性通过操作符Resolve 的 EClass 公 理来实现。表1类图合并过程的步骤图四、为案例研究生成合并模型合并模型的特定用例，以及保留应用于后者的更改）;或从合并模型到部分类图（提供支持以更新特定用例）。此外，这样的映射被认为是模型，以便通用模型管理操作符也可以应用于它们。在图4中，我们显示了步骤4产生的合并模型。尽管用户描述了特定元模型的Merge操作符的语义，但由于模型合并是完全自动化的，因此合并后的模型中可能存在一些不需要的结果，这些结果应该得到修复。在这幅图中，这类元素用一 条 断 续 线 突 出 显 示 。 因 此 ， 来 自 部 分 模 型 D 的 定 向 关 联 应 该 被 删 除 ，Submission和PCMember类之间现有关联的多重性应该用部分模型C中出现的多重性来更新在这种情况下，用户可以选择打开合并后的模型来查看和更新它。合并后的模型可以从Eclipse平台中集成的可视化编辑器中进行操作。尽管合并模型可能会被修改，但由Merge运算符生成的跟踪可以通过以下方式进行更新 其他模型管理操作符，如Match操作符。该操作符通过考虑用于细化跟踪模型的仅检查QVT转换，在符合相同元模型的两个模型之间推断跟踪模型。A. Boronat等人理论计算机科学电子笔记166（2007）521Equals运算符的语义14.6相关工作在[22]中，提出了几种模型合并的方法。 合并操作符是在[3]中提出并进一步发展的模型管理操作符[4]后来。 该Merge操作符的规范是根据命令式算法提供的，因此Merge操作符由混合控制逻辑和功能的复杂算法来体现。 虽然运算符独立于任何元模型，但它依赖于外部运算符来检查特定元模型的约束。因此，它可能会生成不一致的模型，并需要一个辅助运算符才能正常工作。 此外，如[4]所示，算法可以根据元模型而改变。 在MOMENT中，Merge操作符对于任何元模型都是完全可重用的。为了考虑新的元模型，可以通过简单地将公理添加到它们各自的语义定义中来定制操作符Equals和Resolve另一种从模型管理的角度提供合并操作符的方法在[24]中通过使用图论提出。Merge运算符是通过产生式规则来定义的。在操作方法和基于图的方法中，Merge操作符都接收映射模型作为输入。这个模型指出了模型元素之间的关系，合并。这些映射必须手动定义，或者可以通过使用启发式函数[20]或历史信息[19]的运算符Match来推断。 我们的合并操作符不依赖于映射，因为等价关系在同一元模型的元素之间，通过QVT Rela定义。 语言，在更高的抽象层次上。这两种模型管理方法的另一个不方便之处是它们没有集成到任何可视化建模环境中。因此，它们不能像MOMENT框架通过Eclipse平台所能做的那样用于模型驱动的开发过程。Generic Model Weaver AMW [13]是一个允许定义ATLAS模型管理架构中EMF模型之间的映射模型（称为编织模型）的工具。AMW提供了一个基本的织入元模型，可以扩展到允许定义复杂的映射。这些映射通常由用户定义，尽管它们可以通过语法学来推断，如[20]。当织入元模型可以更改时，此工具构成了一个很好的解决方案。它 还提供了合并运算符的基础，其理由是在两个模型之间定义的编织模型可以用作可以获得合并模型的模型转换的输入（如[13]中所述）。在MOMENT中，模型编织由模型管理操作符自动生成，可追溯性模型，并且可以由其他操作员操纵[5]。在[1]中提出了一个有趣的基于操作的三路合并实现允许这种合并的联合模型建立在14复杂模型管理操作符和跟踪模型导航的定义超出了本文的范围。我们参考[5]以了解更多细节。22A. Boronat等人理论计算机科学电子笔记166（2007）5差分算子差异运算符基于这样的假设：参与模型的所有元素必须具有唯一标识符。这个操作符使用标识符来检查两个元素是否相同。我们的合并操作器是一个基于状态的15双向合并的实现，因此它不需要一个共同的基础模型，以合并两个不同的模型。在我们的方法中，运算符Equals允许以简单的方式定义复杂的等价关系。在模型管理领域中，三方合并可以被指定为一个复杂的操作符，如[4]所述更具体地说，对于案例研究中提出的问题，UML CASE工具允许将用例及其相应的部分类图安排到同一个包中。然而，没有提供从局部类图中获取全局类图的选项。RationalRoseModelIntegration [16]是一个工具，它提供了一个特别的解决方案来合并UML模型，基本上通过使用元素的名称来确定等价性，