[发明专利]识别和解决基于原子合并冲突的复杂模型合并冲突的系统和/或方法

说明书

技术领域

本发明实施例涉及一种交互式的模型合并系统和/或方法。更具体地，本发明实施例涉及利用在合并过程中获得的基本信息以帮助用户解决高级合并冲突。高级合并冲突的识别有助于获取在大范围内正在合并的模型之间的语义差别(例如，覆盖一个冲突中的可能大量的模型元素)和/或可能有助用于在减少操作的情况下轻易并快速地解决合并冲突，而不是留给用户基于原子元素(例如，对象和带非空合并状态的关系)的水平解决这些合并冲突。

背景技术

模型可能被认为用于描述复杂应用辅件(artifact)(例如，业务流程，数据结构，软件系统的结构和行为等)，其中复杂应用辅件(artifact)不是表现为非正式形式，而使用定义明确的抽象语言的建模基元和习惯，也就是，所谓的元模型。常见的元模型包括建模语言的UML家族(例如，UML类图，UML协作图等)、BPMN元模型、建模语言的ARIS家族(EPC、VAC和FAD等)、实体关系(元)模型(EPM)、关系(元)模型等。作为一种抽象语言的元模型，其本身是可以被使用或示例以描述实际模型的建模元素的集合。例如，UML类图的建模元素为类、关联和特性等，而关系模型中的建模元素为关系以及它们的属性。

原则上元模型不依赖于具体标记(这样因此被称为上述的“抽象语言”)，例如，被认为是只定义语言概念和形成元模型的有效模型的使用规则。当然，需要使用具体标记对元模型进行实际建模。例如，带三个“分区”的框表示UML类，在ERM中使用标记的矩形和方块表示实体和关系等等。

许多元模型的共同特征是其相应的模型可以表示为一个图形，该图形包括点和边，而点和边一起被认为是图形的“元素”。处理不同类型模型的软件系统(例如，所谓的模型管理系统)通常使用一些类型的图模型以作为所有的类型的模型的内在描述。

模型合并涉及从两个模型A和B中创建一个单一的合并结果模型C(其中，A和C表示为相同的元模型)，该合并结果模型C描述一系列相同或重叠的应用辅件(artifact)(例如，相同的软件系统，相同的业务流程等等)，但是或多或少有区别地描述这些辅件(artifact)。例如，A和B可能为相同的原始模型各自改良后的两种形式，否则无需准确描述具有重叠部分的应用领域的相同方面。

理想情况下，一个合并通常表达一个不带任何冗余的合并模型C，例如，均出现在A和B中的模型元素最多只在C中出现一次。依赖于C的准确目的，通常希望保留出现在A或B的所有元素(例如，为了不失去输入模型的任何信息)。然而，这通常不是一般要求。进一步的，希望使C前后一致且格式完整以满足其相应的元模型的所有约束条件。

由于模型一种图形，模型合并相比更为普遍(通常为线性测量)的对完成的文件文档的合并，更具不同的挑战，例如，在形式控制系统中。如果各自元模型存在文本的(例如，基于XML的)标记，那么基于文本的模型合并自然是可能的。然而，基于文本的合并工具并不是处理模型合并的本来工具。第一，大部分的文本表示被人们直接使用是不合适的，而相反需要作为存储格式和/或在模型交换中使用。特别的，(线性)的文本表示通常在非线性、模型本身的图状结构很不同，从而使直接使用这些表示很复杂。第二，即使模型很小的改变也会导致文本表示的巨大变化，从而使得很难区别模型水平的实际改变和文本表示需要的纯“语法”的改变。因此利用基于文本的工具进行模型合并是不适当的。

两个模型A和B的合并还涉及一种方法，用于识别分别来自A和B的一对元素a_i和b_j，其中，元素a_i和b_j视为相同的并经过成功的合并操作后仅仅一次出现在合成的模型C的那些元素。这里所使用的“相同的”一对元素通过映射关系map_AB：A x B而被提供。

可以理解map_AB作为一种关系，不需要是一个内射或满射甚至是一个这样的函数：一般的，A中的模型元素不一定在B中也出现，反之亦然；而A中的元素a_i可能在B中具有多个相同的元素b_j1，......b_jn，反之亦然。从两个模型A和B中形成的这样一个map_AB的方法有时候也被称为模式或模型匹配。在其他方面，这样一个map_AB也可能在生成模型A和B的过程中形成。

根据map_AB的内容，能够区分A和B中的不同类别(对、组或个)的对象：