CN102968332A

CN102968332A - 识别和解决基于原子合并冲突的复杂模型合并冲突的系统和/或方法

Info

Publication number: CN102968332A
Application number: CN 201210030834
Authority: CN
Inventors: 尤尔根·格雷斯
Original assignee: Software AG
Current assignee: Software AG
Priority date: 2011-02-10
Filing date: 2012-02-10
Publication date: 2013-03-13
Also published as: US9128804B2; US20120210294A1; EP2487582A1

Abstract

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

Description

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

技术领域

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

背景技术

模型可能被认为用于描述复杂应用辅件(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中的不同类别(对、组或个)的对象：

1，如果对象a_i∈A以及对象b_j∈B通过map_AB(i.e.，(a_i，b_j)∈map_AB)鉴定为相同的，而且没有其他的关于a_i或b_j的实体存在于

并且如果a_i和b_j与合并方法相关的所有属性相一致(例如，特定属性等)，那么a_i和b_j称为等价的。如果a_i和b_j在部分它们合并相关的属性中不同，这些对象是改变的。

2，对象a_i∈A(或者b_j∈B)同时不存在对象b_j∈B(或者a_i∈A)，那么

(或者

)被称为A的附加值(或B的附加值)。

3，如果对象a_i∈A以及对象b_j∈B通过map_AB(i.e.，(a_i，b_j)∈map_AB)鉴定为相同的，而且没有其他的关于a_i或b_j的实体存在于

这些对象是冲突的。

通过这些信息，现在利用合并方法生成一个连贯的结果模型C。当处理相同的对象比较琐碎时，对于其他类型的对象，需要做出决定是否并且如何接受这些对象到结果模型C中。这些决定依赖于模型C的预期目标、冲突(conflicts)的详细资料以及生成的A和B的内容等等。这些考虑显示了模型合并必然为一项人为作业，其中只有一些琐碎的作业能够安全地自动操作。因此，一般的，需要人为决定取自A和B中的那些元素和属性到结果模型C中。通过下面详细的描述可以更清楚的显示，一些实施例描述的有关提高的技术能够为用户完成这个作业做支持，例如，在ARIS模型变换分量的环境下。

ARIS模型变换分量允许公开描述一种类型的模型如何被变换成一种不同(或有时相同的)模型类型的语义相关的模型。图1显示了这种变换的一个实例。在图1中，使用事件过程链(EPC)元模型设计的业务流程被转换成业务流程建模符号(BPMN)元模型中的等同过程。这种转换被称为EPC-to-BPMN转换。当面向商业的用户是使用EPC元模型以获取是(或应该是)在一个组织中进行处理的业务流程时，BPMN也作为覆盖更多技术领域的元模型和符号。使用EPC-to-BPMN转换，通过EPC形成的BPMN被作为丰富过程的业务视图的开始点，以及技术资料从根本上使过程在适合的运行环境例如作业流程管理系统(WfMS)中被执行。

该转换的描述通过所谓的转换模式(transformation patterns)定义，限定了原始模型的一个或一组元素如何转换成目标模型的相应元素。特别地，申请号为No.61/071,255，名称为“描述标记之间的模型转换的图示发展规律的系统和方法”的美国申请专利公开了ARIS模型转换和描述转换模式的图示方式。

在模型转换中，经常发生这样的情况：通过一个转换时期而产生一个原始转换的模型T后，原始模型S被业务用户改变，从而生成改进的原始模型S’。图2显示了这种情况。在BPMN技术层上，为了得到这些改变，可以再次简单的转换S’，从而获得一个新的转换模型T’。但是，同时，业务工程师可能改进原始的BPMN模型T并利用技术信息对其进行扩展，从而获得该机改进的BPMN模型T’。在这种情况下，不可能简单的将T”代替T’而使业务层改变为技术层，因为这样做会面临由技术用户在最初的地方获得的T”而丢失一些或所有的改变。直到T’或T”能够整个被丢弃以及只有发生从Y”到T’的改变时，需要一种方式使通过合并这两个模型T’和T”而将T’和T”中的独立变化组合成一个单一连续的合并模型T_M。在这个合并过程中，T’(从改进的原始模型S’转换成的模型)作为新转换模型，而T”作为合并目标模型。

图2展示了原始模型和转换模型的独立改进有关的冲突。更具体的，在图2的实施例中，用户增加一个函数F3到过程中作为F2的一个(专用的)替代，从而形成S’。在原来的转换模型T中，过程工程师增加一个额外的作业F2b以形成T”。例如，F2b可以代表一个从技术立场上重要的作业，但不需要反映到业务层上。当现在转换S’以获得T’，可以看到T’和T”不同且需要执行一个合并以获得一个尽可能反映出两个模型中的改变的结果。

如上所述的一般模型合并的问题，为了能够成功合并模型T’和T”，需要提供一种方式以识别出为合并目的而视为“相同的”元素，例如，获取map_T‘T”的方式。转换它本身可能在所有生成的元素中设置“轨迹(trace)”信息，而不是使用模糊的方法如根据各个对象的属性(例如名字和类型等)猜测不同的对象，或者甚至完全留给用户去识别一对相同的对象。转换模型中的每一个元素t_i可能包含这种轨迹(trace)信息，此外，模型S中的原始元素有关的信息需对生成t_i负责，生成t_i也涉及转换模式，等等。如果两个对象t’∈T’和t”∈T”的轨迹信息和一些其他属性在一定程度上相一致，那么这两个对象被认为是相同的(并因此会在数组map_T’T”被发现)。尽管精确的执行资料可能会改变，轨迹信息允许获得map_T’T’。

在现有技术的ARIS模型转换范围内的模型合并实施中，将S’转换成T’以及将T’与合并目标模型T”进行合并是一个不可或缺的过程。用户挑选一个原始模型和一个合并目标模型，然后引入一个单一模型以表示T’和T”之间的冲突。图3显示了一个用户界面图示并使用这个单一模型执行交互冲突方案，而这个单一模型表示为冲突模型T_C。在冲突模型中，用户可解决剩余的冲突并生成最后的合并模型T_M。这些冲突可以通过图形符号来显示并邻近冲突元素。这些符号有时候表示为元素的“合并状态”。

通过上述的转换轨迹信息以获得map_T’T’，下面介绍如何生成冲突模型。

生成的结果中仅仅出现一次的成对相同的或改变的元素a∈T’和b∈T”，如图3实例所示的函数F1和F2，开始和结束事件，分道与堆栈。这些元素没有冲突或者与冲突有关的“合并状态”。可理解在当前的实施中，S’中发生的任何属性变化可简单地写入存在的对象中，从而原始模型静静的改写目标中的任何属性变化。因此，在ARIS模型转换的合并目的下，相同的以及改变的对象(如上所述)等同处理。

出现在T’中而不存在T”中的元素(根据map_T’T’)被增加到冲突模型中并标记合并状态为“通过转换增加”(或者“在出处增加”)，该标记用相邻这些元素的绿色加号表示。在图3的实例中，显示了从新的XOR规则生成的BPMN关口，从新的函数F3生成的作业F3以及新的“End2”结束事件和它们之间的所有连接。另外，作业F2与结束事件“End”之间的连接用“通过转换增加”标记。虽然从S到S’的相应的连接并没有发生改变，这种合并状态的原因为当流程人员插入F2b时，T”中对应的连接已经被删除。在完美的情况下，这种连接的实际合并状态会被“在目标中删除”。然而，合并无法区别出这两种状态。也就是，为了正确的标记出这种连接为“在目标中删除”，有必要保存T’的整个改变历史。

如果元素存在T’中而不存在T”中，能够区别出上述两种状态。如果通过原始的)转换生成元素t(根据t中存在的轨迹信息而决定)，那意味着原始模型S’通过一种方式已经改变，对应t的一个对象不再由当前的转换生成。因此，向冲突模型加入并标记为合并状态“通过转换删除”，该标记用红色减号表示。在图3的实例中，由于从S到S’的转换中，EPC中相应的连接已经被流程用户删除，所以需要标记出原始T中F1与F2之间并在生成T”时被流程人员保留的连接，因为T’中不再存在该连接。如果人为加入元素t到通过轨迹信息的缺失而被识别的T”中，也需要将该元素t增加到冲突模型中并标记为合并状态“在目标中增加”，该标记由蓝色加号表示。在图3的实例中，展示了函数F2b和事件连接。

任一个元素只要包含上述三个合并状态中的一个，均表示为一个原子冲突。

图4为一个简单的冲突表格实例，表格中的冲突模型下方陈列了冲突模型的所有动态冲突。“插入(inserted)”对应“通过转换增加”，“删除(deleted)”对应“通过转换删除”，以及“改变(changed)”对应“在目标模型中增加”。图4实例表格还包括了在冲突模型中看不到的关于模型元素的附属原子冲突，例如“属于(belongs to)”连接。“属于(belongs to)”连接作为包含关系(containerconnection)的一个实例。在ARIS模型中使用包含关系以将一个对象和该对象的包含对象进行连接(例如，连接一个作业和它包含的分道，连接一个分道和它包含的堆栈等等)，因此将对象表达为包含的一部分，而不是仅仅依靠对象的大小和位置去表达该包含关系。

通过图4所示的实例表格，用户可以分别地接受或拒绝各个原子冲突。当接受“通过转换增加”或“在目标模型中增加”的一个冲突时，保留对应的模型元素并移除合并状态，从而显示冲突已经被解决。当拒绝这样一个冲突时，删除模型元素。当接受“通过转换删除”的一个冲突时，删除该元素；而当拒绝它时，保留该元素并移除合并状态。

除了ARIS模型转换部件提供当前的合并功能外，ARIS还提供了一种基于XML的输入输出方式以传送不同ARIS数据库之间的ARIS模型，从而包括ARIS模型合并部件。例如，在DB X中生成模型M，并将模型M输出到一个文档以及输入到DB Y中。假设在X中模型M现在改变，获取一个改进的模型M’，同时，在DB Y中的原始输入模型M也独立改变，获取一个模型M”。M’再次输出到一个XML文档中并输入到DB Y中。由于M’和M”为同一个模型的不同形式(通过相同的识别器于模型和所有模型元素进行识别的事实)，必须执行模型合并。当输入M’时，用户在冲突的情况下选择是模型M’(设置为“原始覆盖目标”)还是模型M”(设置为“保留目标”)胜出。这些设置根据对象、连接和模型设置不同。然而，这种合并没有提供选择控制如何解决独立的冲突，且不是交互式的。

电子事务进程分析(BPA)套件提供了一种在处理BPEL模型的情况下的模型合并功能(命名为“过程差异”)。这种合并功能不是使用单一冲突模型作为ARIS模型转换的合并，但同时将两个模型进行合并且突出两个模型之间的差异。根据对两个模型的差异的选择，在屏幕的第三部分显示合并模型的当前状态。通过Oracle BPA合并部件识别的实际差异密切对应于上述的通过ARIS转换合并功能识别的“原子差异”。

本申请的发明者发现，个人选择和认为接受或拒绝无法合并的模型元素(例如在其他模型中没有对应元素以及因此存在合并状态)需要大量劳动力而且容易出错，尤其当模型很多而且具有很多差异时。例如，带有不同合并状态的对象，且对象实际为A或B的一个巨大改变的结果，那么对象在不完全的合并模型中相互远离，从而导致很难连续发现和解决这些对象。

IBMRationalSoftwareArchitect(IRSA)是一种建立在Eclipse平台上的集成开发环境(IDE)。在自由的Eclipse平台的基本功能之上，增加装置以建模软件设计辅件(artifact)，其使用元模型的UML家族的图示。继承于Eclipse，还提供了一种基本的基于文本的文档比照。然而，如上所述，对手头任务，复杂的设计辅件(artifact)如模型的对比基于文本表示一般不准确的。因此，IRSA提供一种模型对比和合并功能。

在ARIS中，术语“模型(model)”基本与“图示(diagram)”同义。然而，在IRSA中，“模型model”包括整个系列的图示(diagram)和所有模型元素，而不管这些元素是否在模型中实际出现。因此，一个IRSA模型大致可以比喻为一个ARIS数据库。

在IRSA对比/合并功能中，利用拆分视图展示两个模型进行对比/合并，类似于Oracle BPA合并部件所提供的。根据模型它们本身的内部结构，这些模型通过图形表示或树形表示进行展示。为了了解这种树形，必须知道IRSA中的UML模型通过Eclipse建模架构(EMF)实施。这里，包含关系扮演一个关键的角色。例如，在UML模型以及一些通过EMF实施的其他类型的模型中，包含结构扮演一个关键的角色。例如，一个UML类图中包含多个类。也就是，表示类的模型元素通过一个包含关系与表示模型“根基”的模型元素进行连接。类似地，类的属性、领域和操作均包含在对应的类中，而操作的参数也包含在元素中以表示操作，等等。

通过IRSA识别的实际差异也大致相应于通过上述的ARIS模型转换合并功能的“原子冲突”，但是也可能存在一些差异如一个元素的属性或其他性能的变化与ARIS合并功能无关。IRSA不是简单的提供一个“单调的”列表显示所有模型元素进行增加、删除或者一个模型的两种形式之间进行比较的改变，而是基于“结构差异”表格中的包含结构“组合”(groups)原子变化。这里，通过树形结构展示了每一个变化，其中一个点表示各自的“母体(parent)”或“容器(container)”。例如，假设在UML 2中表示容器(container)模型的hw1包括“hello world”类，相应地，也包括第一、第二属性和第一、第二操作。在IRSA中，从container模型hw1中删除“hello world”类，增加第一、第二类“Class1”和“Class2”到图形“Diagram1”和container模型hw1中，并通过重命名“Diagram1”为“ClassesDiag”的方式开始一个改变操作，表示如下：

现在IRSA根据这些包含结构进行组合个别的原子变化，这样，不是简单的提供一个“单调的”列表显示所有模型元素进行增加、删除或者一个模型的两种形式之间进行比较的改变，而是基于它们各自的母体/包含(parent/container)元素进行组合。然后，这些原子冲突可能根据任意等级水平而个别的或“每一个容器(container)”的方式被接受。在实际模型合并过程中，用户可以在每个差异或通过包含关系生成的组合上执行“接受”和“拒绝”操作。

如上显示，从总体上来看，由于模型合并的特性以及合并模型的变化需求，模型合并是一个人为过程。任何的全自动“发射后不管(fire and forget)”解决方案总是要为一些需求定义明确的(因此不能是大概的)使用案例进行优化，否则无法获得最大的利用率。因此需要提供一种带实际相关的模型合并工具，即提供一种用户交互界面以允许用户对比进行合并的模型和解决冲突。

很不幸，现有解决方案很复杂，而且基于原子冲突的水平上的冲突解决很容易出错。现有技术的交互式合并方式的普遍不足是识别合并的两个模型之间的“原子冲突”的能力有限。忽略这些差异中使用的实际样式(例如，ARIS转换合并下的整合“原子冲突”，Oracle BPA提供的“分解屏幕(split screen)”等等)，这些方法的共同问题是即使合并模型之间的差异数量相对适中，用户很快就会被这些数量打败。如图3实例中的冲突模型以及图4中对应的原子冲突表格显示，即使相对很少的改变也能导致大量的原子冲突，从而需要用户的个人关注。对于每一个这样的元素，用户需要决定做什么(例如，将它移除、将它接受到合并结果中以及接受改进后的它等等)，因此需要用户十分关注并注意错误。

另外，模型通常包含模型元素而没有一个直接的图形表示能够服从于包括上述包含关系的原子冲突。由于这些元素的原子冲突需要由用户解决，那么，在一般的建模过程通常相对用户屏蔽的技术资料也会变得明显。例如，上述的IRSA的模型对比和合并功能，无法向非专业用户屏蔽(图示)图形如何内部表示的细节，相反暴露这些细节，无论合并下的模型树视图还是“结构差异”表格中。在后一种情况下，这些内部资料，尤其包含关系实际用于组合那些差异。

当这样一个组合中的原子冲突由于在同一个容器(container)中而相关时，不存在任何基于一个模型接一个模型的执行的高水平编辑操作的实际语义的分组。例如，当对上面显示的IRSA实例中同一分组中的两个类“Class 1”和“Class2”(因此在“结构差异”树形中拥有相同的母体parent点)进行增加操作，这两个增加操作总体上并不语义相关。尽管如此，它们能够彼此完全独立地被执行。与IRSA中利用模型和图形内部表示相似的一种方式，也标记了两个类“Class1”和“Class 2”增加到(重命名)图形中而不是增加到模型本身。这显示了这两个类本身实际上并不是新的，相反展示了将它们增加到图形中只是为已经存在模型的原始形式中的这两个类生成新的视图。然而，这个信息相对用户并不显著，相反根据不同的差异最好留给用户推测，因此需要对模型表示的内部工作有深入的了解。当IRSA的缺陷能够不同的目标用户组(软件工程师代替业务分析员)在某种程度上进行解析时，显示了在合并的过程中，IRSA无法帮助解决大量的语义相关的不同分组。

在交互式的合并过程中，由于原子冲突的个别接收或拒绝，以及模型元素的个别删除或保留，有可能形成无用的模型。一个实施例显示了如何发生这个并涉及“看不见的”包含关系，例如，属于作业与它们的分道之间的连接。假设存在一个对象的合并状态为“在目标中增加”并包含在一个容器(container中，如图3的实例中的函数F2b所示。从F2b到包含分道“Alice”之间的包含关系带有相同的合并状态。在人为的冲突解决过程中，用户可能接受在目标模型里增加F2b，但可能拒绝相应的包含关系(可能由于用户不知道在ARIS中如何表示包含关系)。缺少预防作用的合并工具会降低这种情况发生的可能性，并完全可能产生一个不连续的模型。

因此，可理解的，本技术领域的技术人员希望提供一种改进的交互式模型合并技术。

发明内容

本发明实施例的一个目的是提供一种解决模型合并冲突的方法，所述方法包括步骤：通过至少一个处理器合并第一模型和第二模型而形成一个冲突模型；通过至少一个处理器而探测出至少一个基于所述冲突模型的高级冲突，所述探测步骤发生在所述形成步骤之后；成列显示所述至少一个探测出的高级冲突列表和一个冲突模型的视觉再现，其中，每一所述高级冲突包括原子和/或其他高级冲突的组合，并被分类为：(a)包括多个原子冲突的简单高级冲突；或(b)包括至少一个其他高级冲突的复杂冲突；在显示所述列表和所述冲突模型的视觉再现后视觉再现，使用户能够解决至少一个探测出的高级冲突。在某些实施例中，所述第一模型为合并目标模型而所述第二模型为转换模型，所述转换模型通过向一个原始模型应用模型转换而生成。

在本发明的特定实施例中，提供了一种非短暂的计算机可读存储媒介，明白地存储如下指令：当由系统中的至少一个处理器进行存储指令处理时，执行如上所述的方法。

在本发明的特定实施例中，提供了一种解决模型合并冲突的系统，包括冲突模型生成器、探测器和用户界面。所述冲突模型生成器设置为基于合并的第一模型和第二模型而形成一个冲突模型，所述合并通过一个合并发动机而执行；

所述探测器设置为探测出至少部分基于所述合并发动机输出的冲突模型内的高级冲突；所述用户界面用于显示探测出的高级冲突列表和一个所述冲突模型的视觉再现，其中，每一所述高级冲突为一种预先定义的类型，包括构成冲突，其为：(a)包括多个原子冲突的简单高级冲突；或(b)包括至少一个其他高级冲突的复杂高级冲突。其中，所述用户界面进一步设置为用于接收用户的输入并使用户解决探测出的高级冲突。在某些实施例中，所述系统还包括一个模型生成器，用于接收用户的输入而使用户生成模型并为模型定义变换。

这些方面的实施例可以单独使用和/或形成不同组合以获得更多的实施例。

附图说明

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行更详细的描述，这些或其他的特征和优点将能够更好更完整的理解，在图中：

图1是为实例图，显示了业务流程建模中，使用事件过程链(EPC)元模型设计的业务流程被转换成业务流程建模符号(BPMN)元模型中的等同过程。

图2为示例图，展示了通过一个转换时期而产生一个原始转换的模型T后，原始模型S被业务用户改变，从而生成改进的原始模型S’；图2还展示了对转换模型T的同时存在的(也可能是不协调的或冲突的)改进以获得与T不同的T”，该T”在改进模型S’的转换过程中获得。

图3显示了一个用户界面图示中使用的冲突模型以执行交互冲突方案。

图4为一个冲突表格实例。

图5为根据本发明实施例的“相同状态的包含关系”的高级冲突的一个实例。

图6为根据本发明实施例的来自图3所示实例的冲突模型的“连接元素和相同类型的原子冲突的组合”的高级冲突的一个实例。

图8为根据图7所示的“简单的包含改变”的高级冲突的一个实例方案。

图9为根据本发明实施例的关于符号改变的“简单的符号改变”的高级冲突的一个实例。

图10为根据图7所示的“简单的符号改变”的高级冲突的一个实例方案。

图11为根据本发明实施例的“原始模型冲突的替换”的高级冲突的一个实例，也包括接受或拒绝该冲突的两种结果。

图12为根据本发明实施例的“目标模型的替换”的高级冲突的一个实例，也包括接受或拒绝该冲突的两种结果。

图13为包含改变的组合的实例。

图14为根据图11所示的识别““原始模型冲突的替换”的高级冲突的一个实例。

图15为流程图，展示了根据本发明实施例所描述的冲突解决技术如何实现整个转换和合并过程。

图16a～16c具体展示了根据本发明实施例所描述的冲突解决技术。

图17为根据图7所示的冲突的一个“IRSA-style”表现。

具体实施方式

在本发明的实施例中，提供一种交互式模型的合并技术。更具体地，在本发明的实施例中涉及一种例如基于ARIS模型转换的交互式的模型合并技术。优选地，本发明一些实施例使模型合并更方便(例如，参与更少的用户交互就可以达到预期的合并结果)和/或更安全(例如，降低在合并过程中无意产生的无用模型的可能性)。可理解，尽管本发明的实施例描述的背景和采用的实例为ARIS模型转换合并，本发明描述的技术方案可以实施到任何形式的交互式模型合并中。例如，本发明描述的技术方案可以应用到使用分解屏幕(split screen)视图(例如，类似于Oracle BPA套件中使用的)的交互式模型工具中。因此，本发明一些实施例可能包括集成冲突模型。

进一步的，本发明一些实施例使用合并过程中生成的基本信息以帮助用户解决高级合并冲突。例如，对象的不同合并状态包括，例如上述需要识别的(例如，相等的、改变的、在A/B里增加的以及冲突的等等)以及对正在合并的模型的构象或分组，均有助于识别高级合并冲突。高级合并冲突的识别有助于获取在大范围内合并的模型之间的语义差别(例如，覆盖一个冲突中的可能大量的模型元素)和/或可能有助用于在减少操作的情况下轻易并快速地解决合并冲突，而不是留给用户基于原子元素(例如，对象和带非空合并状态的关系)的水平解决这些合并冲突。

一般的，高级合并冲突可能分类成两个大类，分别为独立元模型的高级合并冲突和非独立元模型的高级合并冲突。首先，由于独立元模型的高级合并冲突不是涉及特定的一种模型元素，其适合为所有类型的元模型进行建模。然而，它们涉及常见领域，涉及建模系统的很多或者全部的元模型(例如，定义为使用相同的元-元模型的所有元模型)。其次，非独立元模型的高级合并冲突指定到特定的一种或多种模型元素。本发明讨论的实施例的实施主要是选择独立元模型类型的高级合并冲突，因为其具有更普遍的适用性。但是，可理解的，本发明所描述的技术方案可以应用到独立元模型的高级合并冲突和/或非独立元模型的高级合并冲突中。

在一些实施例中，在现有的ARIS模型转换交互式合并模块的范围内，在后续处理时对冲突模型T_C执行高级冲突识别步骤，例如，由于该冲突模型T_C是通过转换合并工具生成的。因此，在一些实施例中，高级冲突识别不会作为合并的整个部分而执行(例如，在确定模型元素的合并状态时)。本实施例的这种方式具有如下优点：首先，使现有的简单交互式合并功能实质上没有发生改变；其次，当对冲突模型T_C进行识别处理时，是基于模型元素的构象或分组以及它们各自的合并状态，相比对输入模型和连串带不同合并状态的对象进行直接处理要简单很多。

在合并过程中，用户可以通过高级冲突执行冲突解决方案。这允许用户只需要简单的接受或拒绝操作就可以解决涉及多个模型元素的冲突，而不是一一地察看大量的原子冲突并对每个进行接受或拒绝操作。然而，一些实施例提供了一种灵活性，就是不一定强制用户通过高级冲突解决冲突问题，而有时候可能通过生成一个“中间的某物(something inbetween)”而解决冲突，该“中间的某物(something inbetween)”可当接受或拒绝作为整个高级冲突时生成。因此，高级冲突为标准的冲突情况提供了一定程度上的便利，但是，例如对于“特定的情况”仍然无法阻止需要更多的繁琐或人为处理。

概念地，高级冲突可能被认为是一种包括一种类型或多种其他冲突的结构。这些其他冲突可能为原子冲突，或其他更简单的高级冲突。至少从理论上说，这种复杂冲突的嵌套可能是任意深入的。在任何情况下，高级冲突内包含的冲突可以分成两组，分别为子冲突和反向的子冲突。高级冲突的子冲突和反向的子冲突均由其组分而命名。当接受(或拒绝)一个高级冲突时，其子冲突也会被接受(或拒绝)，同时其反向的子冲突也会被接受(或拒绝)。另外，一个复杂的冲突可能设置隐藏其组成的冲突。这样不仅隐藏了复杂冲突的的细节，还能够预防用于单独处理冲突中的组分。这个特性对高级冲突是有利的，尤其是在生成模型时其主要的或其他的目标为降低模型不一致的可能性。

下面将详细介绍不同类型的高级冲突实例。这些高级冲突实例的类型分组为：(1)组分只包括原子冲突的简单高级冲突；或(b)组分包括其他非原子的(以及可能简单和/或复杂的)冲突的高级冲突。

第一种简单的高级冲突涉及图3实例中包含关系。明显的当一个对象包括一个原子冲突且该原子冲突包含在包含对象里(例如，分道上的一个BPMN作业)，其相对的包含关系会包含相同类型的原子冲突。处理这样一个被包含冲突的方式是有区别的，由于包含关系的冲突有点不符合逻辑且可能违背模型的完整性。这种高级冲突能够被应用并忽略涉及的原子冲突的实际类型，即被包含原子冲突和包含关系的原子冲突都是一样的。图5为根据本发明实施例的“相同状态的包含关系”的高级冲突的一个实例。在图5的实例中，原子冲突为“在转换中增加的”类型。这里，其他看不见的“属于(belongs to)”包含关系通过红色箭头指示出来，而这个冲突里的两个原子冲突是很明显的(例如，加号附近的厚框)。如果接受F3而拒绝该包含关系，该模型就会变成无用的。如果F3被拒绝，那么包含关系就会毫无保留地删除，因为包含关系没有了原始或目标对象是无法存在的。

为了向用户屏蔽这种普通类型的冲突并减少意外产生的无用模型的可能性，这些情况可能识别为“相同状态的包含关系”类型的高级冲突。增加到冲突中的两个原子冲突均作为子冲突，同时高级冲突设置为隐藏其组分，从而不承认(或至少阻止)单独处理冲突内的组分。

通过修改大量的原始模型或合并后的目标模型通常会出现冲突。理论上，通常的情况是具有相同类型的原子冲突的直接连接的元素的分组。“带同种类型的原子冲突的连接元素的分组”的高级冲突(简称为“分组冲突”)会将这个分组中的所有的原子冲突聚合到一个冲突中，从而允许用户方便地接受或拒绝整个分组。一个分组成员中的所有原子冲突被投入到一个高级冲突中，以作为高级冲突的子冲突，这样，如果高级冲突被接受(或拒绝)，其所有的组分也会被接受(或拒绝)。这种类型的高级冲突不会隐藏其组分，从而允许用户随意地对每个组成做出单独的接受/拒绝决定。复杂冲突的种类变化也和原子冲突的种类一样多。因此，在当前ARIS转换合并部件下，提供了作为“组合冲突”成员的三种子类型冲突，分别是“在转换中增加的”、“在转换中删除的”以及“在目标中增加的”。

对照一些基本应用实例，图6显示了图3例冲突模型的高层冲突中“同类型微冲突相连元素群”的例子。一个“同类型微冲突相连元素群”包含了显示在左边的“目标添加”的因素和显示在右边的“转化添加”的一组因素。

为避免该种繁琐类型的高层冲突，对于大小为1的群不必创建复杂冲突。因此，F2与“end”结束事件之间的“转换添加”单一连接，会同F1与F2之间的“转换删除“连接不会应用于创建群冲突。然而，如下文详细阐述，那些繁琐的群冲突可用于侦测更为复杂的高层冲突的场合。也可以发现，如果跨越容器连接的群没有创建，这种类型的高层冲突更为直观。例如，图3例的也具有”转换添加”状态的”Alice”通道，将不会添加到图6右加亮显示的群中。

有时，当为变换S’得到T’，修正的源模型S’会有一些变化，目标F将如前创建但终止于不同的容器。图7显示了此种情形应用的“简单存储器变换“高层冲突的例子。在原始源模型S中，同一组织单元”Alice“中分派了三个函数。结果，当为获得T模型转换EPC至BPMN时，函数创建的所有任务将终止于”Alice“的同一通道上。如果商业用户为获得修正源模型S’，添加新功能单元”Bob“并为其分配F2，新转换的模型T’将会使任务F2终止于”Bob“的新通道。当合并T’至未修正T，图7所示为所得到的冲突模型Tc。这里不可能合并T中的F2何T’的F2’，因为尽管事实上，当S转换为S’，F2未发生变化，但F2与F2’需显示在不同容器来阐明它们的不同。因此尽管只有一个元素改变其容器，冲突模型却包含了大量的微冲突。该问题也许会因命名微冲突具有误导性而更为严重。尽管事实上，F2，F1至F2的连接，以及F2至F3的连接在源模型中触及不到，它们显示为“转换添加”和“转换删除”，这对使用者相当有迷惑性。

为帮助使用者确定高层冲突的此种常见情形，不可能单独仅仅依赖于微冲突。而是针对当图TT’创建时目标不匹配的原因需要存储额外的信息。如果原因仅仅是容器的变化，两目标可以可以存为“几乎配对”对。当后处理冲突模型，就可能识别这种情形并创建一个包含了涉及原始任务F2的“转换删除”微项和涉及新任务F2’的新“转换添加”微项作为子冲突的“简单容器变换”高层冲突。如果组分之一的合并状态之前是“目标添加”的情形就更好，它可以被添加为反向子冲突。这有利于使用者认清在源模型中真正发生了什么，不管微合并状态可能会难以理解。使用者可以接受或否决高层冲突，使F2置于“Bob”或“Alice”通道中，对应地以图8附图阐述图7中的“简单容器变换”高层冲突的例子。

然而，当接受(或否决)这种复杂冲突，用户可以手动地接受(或否决)与F2连接的剩余微项。下文给出更为详细的说明这种问题的高层项例子。

一类类似于“简单容器变换”高层次冲突阐明的问题与符号变换相似。当建图时，两目标路径信息、容器、目标类型相同而符号类型不同，就认为不可合并。图9所示为该冲突的例子。在转换模型T’中，F1的符号由“用户目标”转为“子进程”，这是当一个任务需要在技术层次更为细致化采取的常见操作。结果，在冲突模型中，F1出现两次，每次以“用户目标”符号作为“转换添加”和“子进程”符号作为“转换删除”。当随着容器变化，此微小变化会引起许多微冲突，微冲突又会被某种非直观命名加重。与上述“简单容器变换”高层冲突相似，说明两个F1不相同的唯一原因就是建图T’T”时符号不同的信息会被存储下来。如前，该信息可以在后进程中使用并使得“简单符号变换”高层冲突可以被确定。这里，冲突包含了两个微冲突以两种形式的F1作为子冲突。这种也许更为合理命名的高层冲突允许用户更快确定从T到T’的转换中实际发生情况。图10显示了这种高层冲突如何可以被用于解析符号变换。例如接受冲突的情形，当子进程F1删除，F1的“用户目标”变量保留而其合并状态移除。而否决冲突的情形，用户任务F1删除，子进程F1保留且其合并状态移除。终于或始于F1变量的连接上的微冲突可以自动计算得到。下文叙述一种让微冲突更为便利处理的先进高层冲突。

如上文指出，可能有更为高级的元模型独立高层冲突。例如，“源模型替换”冲突是基于有群冲突相类似、有相反合并状态和相同基本编辑操作产生。为更好捕获“相类似”的概念，群的边界可以定义为可以被任何群元素直接获得的元素模型的集，除非其本身具有不同的合并状态或根本不具有合并状态。群控制外的边界可以定义为群的非容器连接边界元素。

例如，图3中F1与F2之间的“转换删除”连接是繁琐群冲突，这意味着其可以自我过滤，并不直接显示给用户。考虑到图6右所示的“转换添加”群冲突。该连接的边界元素就是目标F1、F2和通道Alice。容器之外的边界就是F1和F2。据此，一种“源模型替换”类型冲突可以定义为当群冲突具有相同容器元素外的边界集，且一组为”转换添加”类型而另一组为“转换删除”。保持例中的条件，就是“源模型替换”冲突。冲突中涉及的两组都添加进高层冲突作为子冲突，那么它们就随着高层冲突接受(或否决)而接受(或否决)。既然接受一个“转换添加”冲突意味着保留其相应元素，而接受一个“转换删除”冲突意味着删除其相应模型元素，因此接受(或否决)一个“源模型变换”高层冲突，将保持(或删除)所有“转换添加”元素，并且删除(或保持)所有“转换删除”元素。这允许用户便利地在修正源模型的片段中进行改变或者忽略。图11是“源模型冲突替换”高级高层冲突的例子，以及相应于具体应用实例接受或否决冲突的两种可能结果。因为该高层冲突的组分没有隐藏，用户可以自由地独立地接受或否决组分群冲突来创建一个介于接受或否决这两种极端之间的整合结果。

至少在概念上与“源模型替换“高层冲突类似的是”目标模型替换“高层冲突。区别就是群冲突中一组涉及到”转换添加“类型，另一组涉及到”目标模型添加“类型。如果两组的容器外边界相同，就有可能从T创建T”时，T中元素随着原始源模型变换而删除，而其它一些元素被替换。在例中，一个冲突与涉及目F2b和其连接的”目标添加“类型群冲突相关，另一方面，”转换添加“类型的复杂群冲突只与涉及F2到”结束“事件的连接相关。

当模型中有此种情形，“目标模型替换“高层冲突被创建时，”转换添加“类型的群冲突被加为反向子冲突，”目标模型添加“的群冲突被加为子冲突。这就有如下效应，当接受(或否决)”目标模型替换“冲突，其原始转换状态被忽略(或保持)，而在目标模型中手动创建的状态被保留(或忽略)。因此，用户可以快速的决定其中之一。这里，组分也没有隐藏，用户可以自由地，二选一的解析冲突，既可以是在群冲突层次，也可以使群冲突的微冲突层次。图12是是“目标模型替换”高级高层冲突的例子，以及相应于具体应用实例接受或否决冲突的两种可能结果。

使用高层冲突充实人工合并处理的概念与使得用户更容易通过识别如上所述的容器或标志改变正确地说明原子冲突的附加的信息。在简单的高层冲突中，连接涉及其改变的容器或标志将不会成为冲突的部分并且将仍然需要基于原子冲突层手工解决的那些元素。这个事件可能通过更高级的“容器改变的组”和“标志改变的组”进一步地被寻址。为说明这些种类的高层冲突，考虑图13中显示的示例。这里，组织单元负责函数F2和F3的执行，当从S走到S’，组织单元从Alice改变为Bob，导致现在相应的BPMN任务被放置在用于组织单元Bob的创建的新lane中。当基于前述元素决定事件的lane，将注意到结束事件也被移动到新lane。当合并该模型T”和模型T如它起因于转变获得的原始来源模型S，冲突模型Tc，如图13右方所示。当至今只考虑讨论的高层冲突，涉及F2，F3两者的变体的“在来源中替换”复杂的冲突结束事件，和它们之间的连接(图14中用红色强调的)是首次获得的。进一步获得三个“简单的改变的容器”冲突，一个针对每对F2任务，F3任务，和结束任务。两种高层冲突都不是相当满足，在单个“简单的改变的容器”事件的意义上更正确地影响发生在T和T”之间的语义。因此，如上所讨论的，解决这些冲突将使得连接的原子冲突被人工解决。另一方面，“来源中的替换”冲突，方便地允许原始的模型和来自S’的改变之间的决定，但不通知用户关于改变的细节。类似的情况可能发生在通过标志改变引起冲突的时候。

“容器改变的组”(或“标志改变的组”)的概念是基于任何的“替换换”高层冲突(例如，“来源中的替换”或“目标中的替换”)的概念(所有的它们的对象是“简单的容器改变”(或“简单的标志改变”)冲突的部分)将具有它们各自的与“容器改变的组”(或“标志改变的组”)替换的类型，从而捕捉两者精确的改变的语义并减少要求的人工作用的数量。

[0084]以上讨论的支持的高电平冲突列表不是所有可能的高电平冲突的综合的列表。将注意到它们相反帮助说明通过帮助识别基于原子合并状态的改变的更高层语义的后置处理步骤提供更便利的用户经验的总体概念。比如，当以上讨论的示例高层冲突独立于具体的元模型，它们仍然取决于建模平台的性能，比如，通过平台的元元模型使得自然地和建模的概念可用。在使用不同与ARIS的建模平台上，可能考虑附加种类的高电平冲突，以上讨论的冲突可能是不可用的等。确实，作为一个例子，“相同状态容器连接”高电平冲突可能是可用的，只要建模平台的元模型支持包含的概念。

现在将提供用于高电平冲突检测的伪代码示例。贯穿伪代码片段，简化了的对象模型用于代表模型、对象和连接，还有将要检测的合并事件。也提供示例协助函数的选择。为帮助清楚，在下面的说明中非正式地解释某些协助函数的语义。进一步假设有可能被类似于那些传统的技术的技术访问和修改的一组权威的简单的数据类型和许多抽象的数据类型(比如，列表和组)。

以下是可能用于有关特定示例实施方式中的模型和模型元件的示例的简单对象结构。

·MergeState是所有可能的单个模型元件可以具有的合并状态的列举。在这个例子中，设定值ADDED_IN_SRC_，DEL_IN_SRC，和ADDED_IN_TGT。如果基本的合并方法提供附加的合并状态(例如，如果它能够区分在变换模型中的元素的添加和在目标模型中它的删除)，附加的值可以加入这个列举。

·HighLvlIssueKind是所有当前支持的许多种高电平冲突的列举。在这个例子中，支持值SAME_STATE_CONT_CXN，GRP_ADDED_IN_SRC，GRP_ADDED_IN_TGT，GRP_DEL_IN_SRC，SMPL_CONT_CHANGE，SMPL_SYM_CHANGE，REPL_IN_SRC，REPL_IN_TGT，CONT_CHANGE，和SYM_CHANGE。

·元素是模型对象和连接(Cxn)的共同的抽象超类。它可能具有以下示例方法：

оMethod MergeState getMergeState()：如果它有1，返回元素的MergeState，否则null。

оMethod Boolean hasMergeState()：如果元素具有合并状态返回true，否则false。

оMethod List getNeighbors()：返回为该元素的邻元素的元素列表。如果该元素是Cxn，该列表将保存Cxn的来源和目标对象Object，如果该元素是Object，该列表将是该Object的进出Cxn的结合。

оMethod AtomicIssue getElementIssue()：如果它具有1，返回单一的该元素的AtomicIssue，例如，如果hasMergeState()返回真。

·Object是用于表示各种各样的模型对象的类(例如，在此讨论的模型中的“节点”)。它的超类是Element。除了从Element方法继承的方法，它可能具有以下方法：

оMethod List getInboundCxns()：返回有该Object作为多个Cxn的目标对象的Cxn列表。

оMethod List getOutboundCxns()：返回有该Object作为多个Cxn的来源对象的Cxn列表。

·Cxn是用于表示模型对象之间的关系的类。它的超类是Element。除了从Element方法继承的方法，它可能具有以下方法：

-Method Object getSource()：返回来源对象(它的原点)的连接。

-Method Object getTarget()：返回目标对象(它的终点)的连接。

-Method Boolean isContainerconnection()：如果连接将对象和它的容器对象连接，返回true，否则false。

·Model是可能具有以下方法的类：

оMethod List getAllModelObjs()：在模型内返回所有对象(类型Object)的列表。

оMethod List getAllModelElems()：在模型内返回所有模型元素(类型Element)的列表。

·Group是可能具有以下方法的类：

оMethod List getAllMembers()：为数量(member)Element的Group列表返回参考。

оMethod List getBorderElements()：为边缘Element的Group列表返回参考。

оMethod MergeState get MergeState()：获得用于Group的MergeState的方法(其按照定义与所有它的成员(member)的MergeState相同)。

оMethod void setMergeState(MergeState ms)：设定用于Group的MergeState的方法。

·Issue是用于表示各种各样的合并事项(issue)的抽象的超类。

·AtomicIssue是用于表示原子事项的类。它的超类是Issue且它可能具有以下方法：

оMethod setElement(Element e)，其允许模型元素通过该即将被设定的AtomicIssue寻址。

оMethod Element getElement()，其是相应的获得访问该元素的方法。

оMethod MergeState get MergeState()：返回该原子事项的相应的模块元素的合并状态。

·HighLvlIssue是用于表示各种各样的高电平(high-level)事项的类。它的超类是Issue且它可能具有以下方法：

оMethod List getIssue()：返回这个冲突的事项的列表。

оMethod List getInverseIssues()：返回这个冲突的相反事项的列表。

将注意到，类Issue，AtomicIssue，和HighLvlIssue形成不同的众所周知的复合设计模式，随着AtomicIssue成为树结构的叶元素，HighLvlIssue成为合成的或“内部节点”，且Issue成为组件(component)，或叶和内部节点共同的超类。一个不同点在于在此描述的示例结构是弱形式(weak form of)的合成(通常指“聚合”)，因为这里一个合成物可以是部分的多个其它合成物，例如，合成的结构不是树而是有向无环图(DAG)。

以下是可能用在有关特定示例实施方式中的示例辅助函数。

·Function HighLvlIssue createHighLvlIssue(HighLvlIssueKind k，ListsubIssues，List invSubIssues)：创建给定的HighLvlIssueKind k与给定的subIssues和相反的子事项(invSubissues)的新高电平事项并返回它。为了简单，假设给定的subIssues和invSubissues列表可能包含Issues或者二者择一地直接地包含具有合并状态的模块Element，在这种情况下，使用如由getElementIssue()方法给定的这些元素的AtomicIssue。

·Function Boolean isContainerCxn(Element e)：如果给定的Element e具有类型Cxn且是容器连接，返回true。

以下是依照特定示例实施方式用于检测简单高电平事项的示例函数。

以下函数可能用于检测“相同状态容器连接”高电平冲突：

以下结构和函数可能用于检测“组冲突”：

为检测“简单容器改变”(或“简单标志改变”)冲突，在创建mapT”T”过程中，

无论什么时候两个对象a∈T’和b∈T”被认为不是可合并的，只因为它们的容器(或标志)不同，

这个信息以某种方式保存且使它在高电平冲突检测期间以某种形式可用。在这个示例实施方案中，假定每个这样的“几乎匹配”的元素的对(a，b)存储在列表containerMismatch(或symbolMismatch)中且这些列表在高电平冲突检测过程中可用。以下示例函数可能用于特定的示例实施方式：

关于“来源中的复位(replacement)”，“目标中的复位”，“容器组改变”和“标志组改变”冲突的检测，为了简单，组冲突的嵌套被忽略，因为它们为并入替代冲突被检测且反而可能使用示例的组创建方法。替代冲突“升级”成为的“改变的容器组”和“改变的标志组”冲突可能合并入这个检测方法。可能在函数被调用以前进行如上所述的“简单容器改变”和“简单标志改变”冲突的检测。通过两个简单的协助方法，可能进行检验以决定是否所有的替代冲突的对象成员都是“简单容器改变”或者“简单标志改变”冲突的部分。如果是这种情况，相应地改变高电平事项的类型。这样，以下示例函数可能在特定的示例实施方式中执行：

为“结合(glue together)”上述不同的示例检测方法，可能从接收(或被通过)冲突模型的单一的函数调用一些或所有检测函数，和由于容器或标志不能匹配为参数不可合并的模型元素的列表。当高电平事项通过事项类型特定检测方法返回于单一列表中时，该技术收集高电平事项的列表，其可能由于检测程序被返回并传递给客户。客户显示它们(例如，以合适的用户界面)且允许用户检查所有的高电平事项并接受或拒绝它们，或替代地基于它们形成的冲突不同地处理它们。下面提供一个示例函数：

图15是根据特定示例实施方式表明在此描述的冲突解决技术怎样可能适用示例的整体转变和合并过程的示意流程图。在图15中，模型转变1502用于将来源模型1504转变为转变的模型1506。已经存在的作为部分转变组件的基本的合并功能1508用于合并转变的模型1506与合并目标模型1510(其是与模型转变1502从不同版本的相同的来源模型1504创建的模型)，产生(yielding)冲突模型1512。冲突模型1512是可能被成功合并的所有元素只显示一次的模型，显示在转变模型或合并目标模型中被加入或被删除的所有元素，且在此用合并状态属性指示改变的类型(加入来源中，加入目标中等)。接收这个冲突模型1512作为输入(与可能附加的信息一起，例如，关于“几乎匹配的”对象的对涉及检测标志或容器改变冲突，不同仅在于容器或标志)，高电平冲突事项检测1514然后应用在此描述的示例技术，产生一列高电平合并事项1516，其然后与冲突模型1512一起在显示器1518上显现给用户，允许用户通过接受或拒绝它们方便地解决高电平事项，或更深地研究需要或必要的事项(例如，原子事项)的细节。

虽然由于转变被用于获得两个正被合并的的模型(例如，图15中的转变模型1506和合并目标模型1510)，特定的示例实施方式与模型转变联系，但不同的实施方式可能独立于怎样创建两个将合并的模型运行。即，当相应的基本合并功能或其它技术能够识别在两个模型中那些元素是可合并的和那些不是时，可能应用在此描述的技术，产生如上所述的冲突模型，并识别相同或相似于那些在此讨论的不能被合并的那些元素的合并状态。

图16a-c表明根据示例实施方式，在此描述的冲突解决技术是怎样的，且从而类似于图15。但是，在图16a中，说明了来源模型1602a，还有目标模型1604b。来源和目标模型1602a和1602b包括函数F1，F1.5，和F2，按照该顺序，在开始和结束事件之间。虽然在图16a-c的示例方案中，来源模型1602a和目标模型1604b之间没有改变，将注意到这不是所有方案的要求。来源模型1602a和目标模型1604b在ARIS兼容的来源和目标显示1602b和1604b中分别出现，例如，以致起点和终点，和函数，位于单一的default swim lane内。

在图16a示例中，程序工程师1606(例如，在转变后)为来源模型表现1602b作特定的改变。更特别地，程序工程师1606删除函数F2和终点的联系，增加函数F2b，并增加函数F2和函数F2b之间和函数F2b和终点之间的联系。转变模块1608包括这些在循环区域内的改变。然而，如将注意到的，现在在转变模块1608，和目标模块1604及目标模块表现1604b之间有一个冲突。合并过程识别高电平冲突且在图像用户界面(GUI)1610中显示它们，其能使用户解决它们。

特别地，图16b显示根据特定示例实施方式的示例GUI1610。所述GUI1610显示冲突模块1612，连同高电平冲突1614的列表。所述列表1614包括冲突的名字，和引起冲突的改变类型，冲突的类型，和允许用户说明是否接受或拒绝改变的选择区域。更特别地，所述列表1614包括构成的“普通”/“标准”事件和相反的子事件。在列表1614中的示例构成事项1616a是起因于增加的连接元素的分组的复杂的冲突。该示例复杂冲突改变包括要解决的多项子事项。在列表1614中也提供相反构成事件1616b。这些事件1618a-c的至少某些的图像表现显示在冲突模块1612中。在任何情况下，用户可以按组或在更精确的子分类层上决定是否接受或拒绝改变。在图16b示例中，用户决定接受1620a事件1616a。该决定从而涉及所有“普通”/“标准”子事件，和相反子事件的丢弃1620b。在特定的示例实施方式中，这些改变可能通过按压应用决定按钮1622实行。将注意到可能在更详细的(granulated)(例如，原子)基础上做出接受/丢弃决定。另外，或者替代地，在特定的示例实施方式中，可能连续地接受/丢弃改变，例如，以致可能随时间“退回”或取消改变。

改变实行的结果显示在图16c中。如看到的，因为没有未解决的冲突要被寻址，列表1614’现在是空的。冲突模型1612’同样地清除了未解决的冲突的可视指示。该应用决定按钮1622’失去功能，将没有可用的改变用于执行。

特定的示例实施方式实行使用以图灵齐备编程语言编写的检测方法执行高电平事件的检测的方法。结果，用此处描述的技术，许多不同种类的高电平事件可能可检测(尤其如果不顾(set aside)性能考虑和比如代码维护方面)，假设需要的信息出现在冲突模型中且当从各自的基本合并方法输入通过任何附加的信息。在此出现的高电平事件的选择不应该被认为是所有可能的高电平冲突的限定的和/或完全的列表，而应该被看作是典型地需要解决的相当普遍遇到的一组事件。如将从上文注意到的，在此已经描述了独立于将被合并的模型的实际类型的高电平事件。

新使用例子和实践经验与初始原型可能在某些情况下帮助识别用于可能增加的相应的检测代码的新种类的高电平事件。使用检测代码的方法允许检测许多种(和可能所有的)高电平冲突，不管对于特定的使用例子或模型类型它怎样特殊。

编程的使用列举在冲突模型中什么情况构成特定种类的高电平冲突，较优地提供灵活性。可能在特定的示例实施方式中使用用于代码扩展性的普通的编程技术以将相应的扩展点提供给这里的示例技术，例如，允许不改变我们的代码增加新的检测函数。

虽然特定的示例实施方式能选择接受或拒绝检测的高电平事件，特定的示例实施方式可能提供“中间”选择。这样，虽然特定的示例实施方式可能涉及检查高电平事件的构成冲突的用户且可能基本上再次在原子冲突层结束，其可能需要通过接受或拒绝它们来解决，不同的实施方式可能在简单地接受/拒绝决定之外的开始提供更中间的或可定制的方法。

进一步，在特定的示例实施方式中，高电平事件的接受和拒绝可能被转化成在其构成事件(和相反构成事件)上的递归的接受(和拒绝)或拒绝(和接受)操作，在原子事件上引导接受或拒绝。这样，在此考虑设定原子事件，冲突解决可能涉及保留(和“取消标签”或移除合并状态)或删除包含在构成的原子冲突中的模型元素。

当然，可能为在此描述的技术增加新的多种原子事件，比如，包括元素属性的改变，其可能通过“德耳塔(delta)”合并状态表现且能达到(carry)原来的和新的属性值等。这里，接受将意味着新的值计入结果中，而拒绝它将保留旧的属性值。

无论如何，特定示例实施方式可能涉及从转变的模型取得元素(或元素特性和属性)或从合并目标模型取得的那些成为结果(但几乎任意的结合)。比如，可能不总是可能创建不出现在模型中的，或将模型元素性质的值改变为除了来自一个基于此处描述的技术被合并的模型的值的新的模型元素。为提供这样的功能，可以涉及一些形式的脚本(scripting)功能的增加，例如模型处理操作的片段(snippet)可能被加入高电平事件，如果该事件被接受(一个“接受脚本”)或被拒绝(“拒绝脚本”)，然后可以被执行。这样在此描述的有关不同实施方式的技术的扩展可能被执行。

虽然IRSA“结构区别”视图一开始看起来与通过如上所述的，此处描述的高电平事件形成的树结构，但IRSA的原子组成的区别是纯粹基于内部模型表现的(包含)结构。相反地，在此描述了该方法且ARIS总体上试图将此隐藏。为更好地说明区别，假设IRSA方法适用于ARIS环境并且组成了基于包含(containment)的原子合成事件。作为一个例子，考虑从图7的冲突模型。这里，如下图17所示，原子冲突将基于它们各自的容器元件分组。增加的任务“F2”和删除的任务“F2”将显示在树节点下，分别代表它们包含的lane Bob鲍勃和Alice爱丽丝。同样地，用于lane Bob鲍勃的“增加”事件本身将显示在用于(未命名的)库(pool)的树节点下。它们现在可能通过lane，或通过库(pool)各自被接受。但是这个简单的例子已经突出ITSA方法的限制，例如，当考虑添加任务“F2”给用于连接的原子事件和从用于连接的原子事件删除任务“F2”时。在ARIS中，连接本身不是实际上表现为被包含在容器中，甚至它们的来源和目标对象两者直接或间接地在同样的容器中。结果，所有涉及连接的事件被显示为表现模型的树节点的子元素。这是一种在ARIS中涉及连接的包含关系的自然的结果(或，相反，在其中缺乏)。同样的问题也发生在IRSA中。比如，对于UML联合，为这个论述的目的，其概略地对应于ARIS连接，当联合是不包含在它连接的任何一类中的独立的模型元素，相似的问题发生。

这样，如图17示例说明，然而IRSA方法使得可能接受或拒绝所有在容器分层结构的任意一层上的容器的不同点(且结果，当在根(root)容器上，如模型本身上实行它的时候，所有的立即改变)，该方法不考虑改变的实际语义，如它不对相关的事件适当地在语义上分组，更不用说给用户哪种操作被执行或可能被执行的任何指示。

较佳地，终端系统、子系统、服务器、可变成逻辑电路等等应结合软件、硬件、韧体等等来一起执行。且，此处所述的存储器应为硬件驱动器、记忆存储器、固态硬盘驱动器，CD-ROM、DVD、磁带后备器、存储区域网络系统的结合体或/及任何有形的计算机存储媒介。较佳地，所述技术与处理器协同执行存储在计算机存储介质中的命令。

以上所述是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本发明的保护范围。

Claims

1.一种解决模型合并冲突的方法，其特征在于，所述方法包括步骤：

通过至少一个处理器合并第一模型和第二模型而形成一个冲突模型；

通过至少一个处理器而探测出至少一个基于所述冲突模型的高级冲突，所述探测步骤发生在所述形成步骤之后；

显示所述至少一个探测出的高级冲突列表和一个冲突模型的视觉再现，其中，每一所述高级冲突包括原子和/或其他高级冲突的组合，并被分类为：(a)包括多个原子冲突的简单高级冲突；或(b)包括至少一个其他高级冲突的复杂冲突；以及

在显示所述列表和所述冲突模型的视觉再现后，，使用户能够解决至少一个探测出的高级冲突。

2.根据权利要求1所述的方法，其特征在于，所述第一模型为合并目标模型而所述第二模型为转换模型，所述转换模型通过向一个原始模型应用模型转换而生成。

3.根据权利要求1所述的方法，其特征在于，所述探测步骤是基于合并步骤过程中获得的信息。

4.根据权利要求3所述的方法，其特征在于，所述信息包括对象的合并状态，该合并状态包括所述对象是否是相等的、改变的、增加的或冲突的以及对象构象或分组。

5.根据权利要求1所述的方法，其特征在于，每一所述探测出的高级冲突在层级格式下是可显示的。

6.根据权利要求1所述的方法，其特征在于，至少若干类型探测出的高级冲突只有在探测出的高级冲突水平上是可解决的。

7.根据权利要求6所述的方法，其特征在于，至少若干探测出的高级冲突在相应的组成水平上可分解和解决。

8.根据权利要求1所述的方法，其特征在于，至少若干探测出的高级冲突在相应的组成水平上可分解和解决。

9.根据权利要求1所述的方法，其特征在于：

每一所述探测出的高级冲突包括一个参考类型；

简单类型的高级冲突包括：相同状态的包含关系，连接元素和相同类型的原子冲突的组合，简单的包含改变，简单类型的符号改变高级冲突；以及

复杂类型的高级冲突包括：原始模型的替换，目标模型的替换，包含改变的组合以及符号改变高级冲突的组合。

10.根据权利要求1所述的方法，其特征在于，每一所述模型基于一种ARIS建模语言。

11.根据权利要求1所述的方法，其特征在于，进一步包括步骤：决定和显示至少一个探测冲突对应的相反冲突。

12.一种非短暂的计算机可读存储媒介，明白地存储如下指令：当由系统中的至少一个处理器进行存储指令处理时，执行如权利要求1所述的方法。

13.一种解决模型合并冲突的系统，其特征在于，包括：

冲突模型生成器，设置为基于合并的第一模型和第二模型而形成一个冲突模型，所述合并通过一个合并发动机而执行；

探测器，设置为探测出至少部分基于所述合并发动机输出的冲突模型内的高级冲突；

用户界面，用于显示探测出的高级冲突列表和一个所述冲突模型的视觉再现，其中，每一所述高级冲突为一种预先定义的类型，包括构成冲突，其为：(a)包括多个原子冲突的简单高级冲突；或(b)包括至少一个其他高级冲突的复杂高级冲突；

其中，所述用户界面进一步设置为用于接收用户的输入并使用户解决探测出的高级冲突。

14.如权利要求13所述的系统，其特征在于，还包括一个模型生成器，其被编程用于接收用户的输入而使用户生成模型并为模型定义变换。

15.如权利要求14所述的系统，其特征在于，所述第一模型为合并目标模型而所述第二模型为转换模型，所述转换模型通过向一个原始模型应用模型转换而生成。

16.如权利要求13所述的系统，其特征在于，所述合并发动机被设置为存储包括对象的合并状态的信息，所述对象的合并状态包括所述对象是否是相等的、改变的、增加的或冲突的以及对象构象或分组。

17.如权利要求13所述的系统，其特征在于，至少若干探测出的高级冲突只有在探测出的高级冲突水平上是可解决的。

18.如权利要求13所述的系统，其特征在于，至少若干探测出的高级冲突在相应的组成水平上可分解和解决。

19.如权利要求18所述的系统，其特征在于：

每一所述探测出的高级冲突包括一个参考类型；

简单类型的高级冲突包括：相同状态的包含关系，连接元素和相同类型的原子冲突的组合，简单的包含改变，简单符号改变高级冲突类型；以及

复杂类型的高级冲突包括：原始模型的替换，目标模型的替换，包含改变的组合以及符号改变高级冲突类型的组合。

20.如权利要求13所述的系统，其特征在于：所述用户界面进一步设置为显示一个相反的子冲突或构成为至少一个对应的探测出的子冲突或构成。

21.一种解决模型合并冲突的方法，其特征在于，所述方法包括步骤：

通过至少一个处理器而探测出至少一个基于所述冲突模型的高级冲突，其中每一所述高级冲突包括至少一个原子和/或其他高级冲突；

使用户解决至少一个探测出的高级冲突。

22.根据权利要求21所述的方法，其特征在于，每一所述高级冲突被分类为：(a)包括多个原子冲突的简单高级冲突；或(b)包括至少一个其他高级冲突的复杂高级冲突。

23.根据权利要求21所述的方法，其特征在于，进一步包括：

显示至少一个探测出的高级冲突列表和一个冲突模型的视觉再现；

其中，使用户解决所述至少一个探测出的高级冲突发生在显示所述列表和所述冲突模型的视觉再现之后。

24.根据权利要求21所述的方法，其特征在于，所述探测步骤在所述形成步骤之后执行。

25.根据权利要求21所述的方法，其特征在于，所述探测步骤是基于合并步骤过程中获得的信息。

26.根据权利要求25所述的方法，其特征在于，所述信息包括对象的合并状态，所述对象的合并状态包括所述对象是否是相等的、改变的、增加的或冲突的以及对象构象或分组。

27.根据权利要求21所述的方法，其特征在于，至少若干类型探测出的高级冲突只有在探测出的高级冲突水平上是可自动解决的和/或在相应的组成水平上是可分解和解决的。

28.根据权利要求21所述的方法，其特征在于：

每一所述探测出的高级冲突包括一个参考类型；

29.根据权利要求21所述的方法，其特征在于，进一步包括步骤：决定和显示至少一个探测冲突对应的相反冲突。

30.一种解决模型合并冲突的系统，其特征在于，包括：

冲突模型生成器，设置为基于合并的第一模型和第二模型而形成一个冲突模型，

探测器，设置为探测出冲突模型内的高级冲突，其中每一所述高级冲突包括至少一个原子和/或其他高级冲突；

用户界面，被编程为用于接收用户的输入而使用户解决探测出的高级冲突。

31.如权利要求30所述的系统，其特征在于，每一所述高级冲突为预先定义的类型，包括构成冲突，其为：(a)包括多个原子冲突的简单高级冲突；或(b)包括至少一个其他高级冲突的复杂冲突。

32.如权利要求30所述的系统，其特征在于，所述用户界面进一步设置为显示至少一个探测出的高级冲突列表和所述冲突模型的视觉再现。

33.如权利要求30所述的系统，其特征在于，所述探测器设置为探测出至少部分基于所述合并发动机输出的冲突模型内的高级冲突。

34.如权利要求30所述的系统，其特征在于，所述第一模型和第二模型的合并通过一个合并发动机执行。