[发明专利]用于支持在模型到模型的转换中的部分往返的选择性变化转播技术

说明书

技术领域

此处描述的特定的示例实施方式涉及用于支持在模型到模型的转换中的部分往返的选择性变化转播技术。更特别地，如果对象通过初始的启动检测，此处描述的特定的示例实施方式涉及执行传送操作。在特定的示例实施方式中，比如，通过在面向业务的（例如，EPC）模型中创建对象；更新允许成功合并的技术（例如，BPMN）对象的相关内部属性，可选择地改正技术模型中用户引入的错误；并将上拉对象与它们的环境正确地连接，来实施传送。

背景技术

一个“模型”通常以正式的形式描述一个或更多复杂的应用构件（例如，业务流程、数据结构、软件系统的结构和行为，或其他技术和/或业务组件等）。一个模型可以使用建模基元和/或定义明确的“抽象语言”的规定，其通常指元模型。一些通常的元模型是建模语言（例如，UML类图、UML协作图）的统一建模语言UML族，业务流程建模标记BPMN元模型、建模语言（EPC、VAC、FAD等）的集成的信息系统体系结构ARIS族、实体关系（元）模型(ERM)、关联（元）模型等。元模型作为抽象语言，可能被认为是建模元素的集合，其可被用于或“实例化”为描述实际的模型。例如，在UML类图中，建模元素包括类、关联、属性等，然而在关系模型中的模型元素包括关系和它们的属性。这些建模元素可能以多种定义明确的方式被设置，以建立可能表示复杂的业务和/或技术流程或其他事件流的形式模型。

元模型原则上独立于具体的符号，因此可能被认为是如上所述的“抽象语言”。例如，元模型可能只定义语言概念和为元模型本身而使用它们形成有效模型的规则。然而用元模型进行实际建模时，需要抽象的符号。比如，元模型的符号包括表示UML类的具有三个“分区”的图框，用于表示ERM中的实体和关系的标记的矩形和方块，等。

许多元模型的共同特点是相应的模型可以表示为包含节点和边缘的图形，所述节点和边缘可共同被成为图形的“元素”。处理不同“种类”的模型的计算机系统（例如，所谓的模型管理系统）经常使用某种图形模型作为各种各样的模型的内部表征。

模型合并涉及从两个模型A和B创建单一的合并的合成模型C（其中A、B和C可以以相同的元模型表达）,可能描述应用构件的相同的或重叠的集合（例如，相同的软件系统、相同的业务流程等），但有区别地描述这些构件。比如，A和B可能是相同的源模型的独立修改的两个版本。如另一个例子，A和B可能描述一个应用域的共享一些重叠部分的不同方面。

期望运行合并功能递送不包含冗余的合并模型C。也就是说，期望确保出现在A和B两者中的所有模型元素最多在合并模型C中出现一次。根据C的确切目的，通常期望保存在A或B中的所有元素。这样做可以帮助减少信息从输入模型丢失的可能性。然而，这不是合并的一般要求。也将期望使合并的模型C一致并且完整，例如，从而符合它的各自的元模型的条件。

由于模型是某种图形，当在例如版本控制系统中做出时，模型合并相比文本文件的更普通（并且通常是line-wise）的合并是不同的挑战。模型的基于文本的合并理论上是可能的，如果它们各自的元模型具有文本（例如，基于可扩展标示语言XML的）符号。但是，基于文本的合并工具不是处理模型合并的固有的工具。比如，大多数文本表征不适合人工直接使用，并只打算作为存储格式或用于模型互换。特别地，(线性)文本表征通常与非线性的相当不同，模型本身的类似图形的结构使得它直接用这些表征工作是很难的并且是累赘的。第二，甚至模型的小的变化能引起它的本文表征的重大变化，使得难于区分模型级别的实际变化和仅仅涉及文本表征的句法变化。因此，基于文本的工具不完全适合于模型合并。

当设计合并两个模型A和B的合并系统时，提供函数从A和B分别识别元素对ai和bj，其被认为是相同的（或至少在成功合并操作后的元素应当只在生成的合并模型C中出现一次）。“相同的”元素对在此被讨论作为一个映射关系mapAB:A x B。

将理解到mapAB，作为一个关系，既不需要内射函数，也不需要满射函数。通常，来自A的模型元素不需要在B中有相对元素，反之亦然，并且来自A的元素ai并可能在B中有许多“相同”的元素bi1，…,bin，并且反之亦然。在文义上，从两个模型A和B生成这样的映射mapAB的技术被称作模式或模型匹配技术。在其他场景中，这样的映射mapAB也可能从创建模型A和B的流程被生成。

基于mapAB的内容，可能从A和B中识别不同类别的多对、多组或单独的对象等：