首页 / 专利库 / 专利权 / 实施例 / 用于支持在模型到模型的转换中的部分往返的选择性变化转播技术

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

阅读:643发布:2023-03-12

专利汇可以提供用于支持在模型到模型的转换中的部分往返的选择性变化转播技术专利检索,专利查询,专利分析的服务。并且本 发明 特定的示例 实施例 涉及用于支持在模型到模型的转换中的部分往返的选择性变化转播技术。在特定的示例实施例中,可行性检查被执行以确定是否能对对象进行传送操作。如果对象通过启动检测,则比如,通过在面向业务的(例如,EPC)模型中创建对象;更新允许成功合并的技术(例如,BPMN)对象的相关内部属性,可选择地改正技术模型中用户引入的错误;并将上拉对象与它们的环境正确地连接,执行传送操作。该连接被执行以便对象较优地表现为用于合并的当前的面向业务模型。根据特定的示例实施例,连接可能被确定使得不论传送做出的顺序或次序,结果将是相同的。,下面是用于支持在模型到模型的转换中的部分往返的选择性变化转播技术专利的具体信息内容。

1.一种将在第一计算机表征模型内发生的改变传送到第二个第一计算机表征的方法,该方法包括:
接收对应于对所述第一模型的至少一个改变的输入,所述至少一个改变表明在所述第一模型中的至少一个对象已经被增加、修改和/或删除;
接收将对所述第一模型做出的至少一个改变传送到所述第二模型的指令;通过至少一个处理器,执行至少一个对应的改变传送动作,以使得对所述第一模型做出的至少一个改变视情况被全部或部分传送到所述第二模型,在执行后,以实现所述第一模型和第二模型之间的一致性,当执行时,所述至少一个改变传送动作包括如下指令:
确定是否所述至少一个改变传送动作能够被应用于所述至少一个改变,以及当确定所述至少一个改变传送动作能够被应用于所述改变时,将所述至少一个对象链接到所述第二模型中的至少另一个对象,
其中,每个所述的改变传送动作对应于一个或更多的对应的转换模式或规则,并且包括可由所述至少一个处理器执行以在相反方向实施各自的转换模式或规则的程序逻辑,其中,所述第一模型是面向技术的模型并且所述第二模型是对应的面向业务的模型,反之亦然。
2.根据权利要求1所述的方法,其中,所述第一模型是流程和/或业务要求的技术模型,所述第二模型是流程和/或业务要求的面向业务的模型。
3.根据权利要求1或2所述的方法,其中对于增加在所述第一模型中的一个对象,所述链接包括:
(a)在所述第二模型中创建一个或更多的对应的元素;
(b)寻找与增加在所述第一模型中的所述对象邻近的、没有合并状态冲突的边界对象;
(c)对于所述第一模型中的每个边界对象,在第二模型中识别对应的边界对象;以及(d)对于从增加在所述第一模型中的对象到在所述第一模型中的边界对象的每个路径:
当沿着这条路径有一个或多个对象时,
增加一个从增加在所述第一模型中的对象到各自的边界对象的直接连接,设定所述直接连接的合并状态以指示它被增加在所述第一模型中,以及
在所述第二模型中创建一个或更多的对应的连接;
否则:从现有的单一连接中移除处于目标合并状态的一个增加的直接连接并在所述第二模型中增加一个或更多的对应的连接。
4.根据权利要求3所述的方法,其中所述寻找包括沿直接路径穿过所述第一模型。
5.根据权利要求3或4所述的方法,其中在所述第一模型中的连接不被调整并且在所述第二模型中的连接不在步骤(d)之前被创建。
6.根据权利要求3-5中的任一项所述的方法,进一步包括在步骤(d)之前:
移除所述第一模型中的、连接在所述第一模型的两个或更多的边界对象之间的任何对象组;以及
识别并删除所述第二模型中的对应的结构。
7.根据权利要求3-6中的任一项所述的方法,其中,增加从增加在所述第一模型中的对象到各自的边界对象的直接连接,和设定所述直接连接的合并状态以指出它被增加在所述第一模型中,都是在冲突解决期间被执行的。
8.根据权利要求1-7中的任一项所述的方法,进一步包括为所述第一模型中的每个与传送有关的元素建立追踪信息。
9.根据权利要求8所述的方法,其中对于在转换的模型中的每个元素,所述追踪信息包括与其创建有关的关于转换规则的信息和/或负责其创建的源元素。
10.根据权利要求1-7中的任一项所述的方法,其中,所述链接包括创建追踪信息以建立在所述第一模型中的所述至少一个对象和在所述第二模型中的所述至少另一个对象之间的通信。
11.根据权利要求1-10中的任一项所述的方法,其中,所述确定所述至少一个改变传送动作是否可以被用于所述至少一个改变包含多个可行性检查。
12.根据权利要求1-11中的任一项所述的方法,进一步包括当确定所述至少一个改变传送动作不能被用于所述改变时,返回关于为什么所述改变传送动作不能被应用的一个或更多理由的列表。
13.根据权利要求1-12中的任一项所述的方法,其中通过多个改变传送动作,多个对象被增加、改变、和/或删除。
14.根据权利要求13所述的方法,其中所述链接是确定性的,从而使得不管改变传送动作被执行的顺序如何,都将获得相同的合成模型。
15.根据权利要求1-14中的任一项所述的方法,其中所述第一模型根据BPMN模型被建模和/或所述第二模型根据EPC模型被建模。
16.根据权利要求1-15中的任一项所述的方法,其中,多个改变传送动作被提供以传送BPMN元素的增加、修改和/或删除。
17.根据权利要求17所述的方法,其中可被增加、修改和/或删除的BPMN元素包括抽象任务、人工任务或服务任务。
18.根据权利要求1-17中的任一项所述的方法,其中所述转换模式或规则对应于用于从所述第二模型创建所述第一模型的指令,所述指令是示例性模式、人工转换步骤或硬编码命令规则的任意适当的组合。
19.一种非暂态计算机可读存储介质,实体存储如下指令:当通过计算机建模系统的至少一个处理器实施时,执行根据权利要求1-18的任意一项所述的方法。
20.一种建模系统,被配置为可使用户将在第一计算机表征的模型中做出的改变传送到第二计算机表征的模型,所述系统包括处理资源,所述处理资源包含至少一个处理器和至少一个存储器,所述处理资源被编程为:
接受对应至少一个用户指定的对所述第一模型的改变的输入,所述至少一个改变表明在所述第一模型中的至少一个对象已经被增加、修改和/或删除;
接收将对所述第一模型做出的至少一个改变传送到所述第二模型的指令;以及执行从一组可执行的程序逻辑包中选择的至少一个程序逻辑包,为了有选择地使得与对所述第一模型做出的所述至少一个改变相关的一些或所有变更被传送到所述第二模型,从而使得所述第一模型和第二模型至少在受所述传送影响的一个或更多区域中相互一致,所述至少一个程序逻辑包被编程为:
确定是否所述至少一个程序逻辑包能够被应用于所述至少一个改变,以及当所述至少一个程序逻辑包确定能够被应用于所述改变时,将所述至少一个对象链接到所述第二模型中的至少另一个的对象,
其中,每个程序逻辑包对应于根据执行可选择地在相反方向应用的至少一个各自的转换模式或规则,以及
其中,所述第一模型是转换的目标和传送的来源,并且所述第二模型是转换的来源和传送的目标。
21.根据权利要求20所述的系统,其中所述处理资源被配置为通过执行指令将至少一个对象链接到所述第二模型中的至少另一个对象,所述指令包括:
(a)在第二模型中创建一个对应于在所述第一模型中增加的对象的元素;
(b)寻找与增加在所述第一模型中的对象邻近的、没有合并状态冲突的边界对象;
(c)对于所述第一模型中的每个边界对象,在第二模型中识别对应的边界对象;以及(d)对于从增加在所述第一模型中的对象到在所述第一模型中的边界对象的每个路径:
当沿着这条路径有一个或多个对象时,
增加一个从增加在所述第一模型中的对象到各自的边界对象的直接连接,设定所述直接连接的合并状态以指示它被增加在所述第二模型中,以及
在所述第二模型中创建一个对应的连接;
否则:从现有的单一连接中移除处于目标合并状态的一个增加的直接连接并在所述第二模型中增加一个对应的连接。
22.根据权利要求21所述的系统,其中所述处理资源被配置为沿直接路径穿过所述第一模型。
23.根据权利要求21或22所述的系统,其中在所述第一模型中的连接不被调整并且在所述第二模型中的连接不在步骤(d)之前被创建。
24.根据权利要求21-23所述的系统,其中所述处理资源被配置为,在步骤(d)之前:
移除所述第一模型中的、连接在所述第一模型的两个或更多的边界对象之间的任何对象组;以及
识别并删除所述第二模型中的对应的结构。
25.根据权利要求20-24中的任一项所述的系统,其中,所述确定所述至少一个程序逻辑包是否可以被用于所述至少一个改变包含多个可行性检查。
26.根据权利要求20-25中的任一项所述的系统,进一步包括用户界面,并且当程序逻辑包确定不能被应用时,通过其呈现给用户关于为什么程序逻辑包不能被应用的一个或更多理由的列表。
27.根据权利要求26所述的系统,其中所述用户界面被配置为接收用以说明阻止程序逻辑包被使用的问题怎样被解决的用户输入。
28.根据权利要求20-27中的任一项所述的系统,其中通过多个程序逻辑包,多个对象被增加、改变和/或删除。
29.根据权利要求28所述的系统,其中处理资源被配置为在进行链接时执行确定性算法,从而使得不管程序逻辑包被执行的顺序,都将获得相同的合成模型。
30.一种可选择地将在第一计算机表征的模型中做出的改变通过建模系统传送到第二计算机表征的模型的方法,所述建模系统包括包含至少一个处理器的处理资源,所述方法包括:
接收将对所述第一模型做出的至少一个改变传送到所述第二模型的指令,所述改变对应于被增加在所述第一模型中的一个对象;以及
通过至少一个处理器,执行至少一个对应的改变传送动作,以使得对所述第一模型做出的至少一个改变被传送到所述第二模型,其中所述至少一个对应的改变传送动作按如下步骤来实施:
执行可行性检查以确定所述至少一个改变传送动作是否能被应用于所述至少一个改变,以及
当所述可行性检查指示所述至少一个改变传送动作能被应用于所述改变时,将所述至少一个对象连接到所述第二模型中的至少另一个对象,
其中,通过至少以下步骤,与处理资源有关的所述连接被实施:
1st
(a)查找正被传送的所述第一模型对象o 的第一模型侧边界元素,包括:
1st
(i)存储开始于o 的所有出站直接路径并且将增加在第一模型中的连接归到出站路out out out
径的列表中,path ={path 1,...,path n},
1st 1st 1st
(ii)定义用于出站路径的结束对象的多重集succ ={s 1,...,s n},该多重集是到
1st
o 的第一模型后继,
1st
(iii)存储开始于o 的所有进站直接路径,并且将在第一模型中增加的连接(以相反in in in
的方向)归到入站路径的列表中,path ={path 1,...,path m},(iv)定义用于入站路径的
1st 1st 1st 1st
开始对象的多重集pred ={p 1,...,p n},该多重集是到o 的第一模型前驱,以及
1st 1st 1st
(v)定义所述第一模型前驱和后继的并集succ ∪pred =border ,该并集是第一模型边界对象的集合;
2nd 2nd 2nd
(b)使用追踪信息来查找与所述第一模型前驱pred ={p 1,...,p n}和后继
2nd 2nd 2nd
succ ={s 1,...,s n}对应的第二模型中的元素,以及
2nd 2nd 2nd 2nd
(c)对于每个p i∈pred (or每个s k∈succ ):
2nd 2nd 2nd 2nd 2nd 1st
(i)在第二模型中创建从p i到o (或从o 到s k)的连接,其中o 是o 的第二模型对应对象。
31.根据权利要求30的方法,其中步骤(c)进一步包括:
2nd 2nd in in out
(ii)如 果 对 应 于p i(s k) 的 路 径path i的 长 度length(path i)(path k out
length(path k))是1:
移除所述第一模型中的该路径的单一连接的增加在第一模型中的合并状态,
1sti 1st 1st 1st
否则在所述第一模型中创建从p 到o (或从o 到s k)的连接并将其合并状态设定为增加在第二模型中。
32.根据权利要求31的方法,进一步包括,在步骤(b)和(c)之间,确定所述对应的改
1st 1st 1st 1st
变传送动作是否在冲突解决期间被执行,如果是,对于具有p i∈pred 和s k∈succ
1st 1st 1st 1st 1st 1st 1st
的每个对(p i,s k),存在从p i到s k的连接cxn (或从s k到p i),其合并状态被
1st 2nd 2nd 2nd 2nd
增加在第二模型中,删除该连接cxn ,并从在第二模型中从p i到s k(或从s k到p i)
2nd
中删除cxn1st对应的第二模型中的连接cxn 。
33.根据权利要求31或32所述的方法,其中仅仅当改变传送正在被执行且仍有未决的合并冲突时,步骤(c)(i)和(c)(ii)被执行。
34.根据权利要求31或32所述的方法,其中仅仅当改变传送正在被执行且在被传送的所述改变上仍有未决的合并冲突时,步骤(c)(i)和(c)(ii)被执行。
35.根据权利要求29-32中的任一项所述的方法,其中所述第一模型是所述转换的初始目标和传送的来源,所述第二模型是所述转换的初始来源和传送的目标。
36.一种将在第一计算机表征的模型中做出的改变传送到第二计算机表征的模型的计算机实现方法,该方法包括:
接收对应于对所述第一模型的至少一个改变的输入,所述至少一个改变指示在所述第一模型中的至少一个对象已经被增加和/或修改;
执行至少一个可行性检查以确定是否所述至少一个改变能被传送到所述第二模型;以及如果是,
将所述至少一个改变传送到所述第二模型,其中,所述传送包括根据至少一个转换模式或规则将所述至少一个对象连接到所述第二模型中的至少另一个对象。
37.根据权利要求36所述的方法,其中所述至少一个可行性检查包括根据已经在所述第一模型中增加和/修改的所述至少一个对象,滤除改变传送动作的集合,从而使得只有改变传送动作的一个子集可用于所述传送。
38.根据权利要求36或37所述的方法,其中所述传送包括执行多个改变传送动作,其中至少一个可行性检查包括禁止所述至少一个改变传送动作,如果该改变传送动作在传送的过程中已经被使用。
39.根据权利要求36-38所述的方法,其中至少一个可行性检查包括执行一致性检验以检测所述传送是否将在所述第一和/或第二模型中创建不一致的情形。
40.根据权利要求36-39中的任一项所述的方法,进一步包括:
接收将对所述第一模型做出的至少一个改变传送到所述第二模型的指令;以及执行至少一个对应的改变传送动作以将所述至少一个改变传送到所述第二模型。
41.根据权利要求36-40中的任一项所述的方法,其中所述传送进一步包括改正在第一模型中用户引入的错误。
42.根据权利要求36-41中的任一项所述的方法,其中所述第一模型是流程和/或业务要求的技术模型,所述第二模型是流程和/或业务要求的面向业务的模型。
43.一种建模系统,用于将在第一计算机表征的模型中做出的改变传送到第二计算机表征的模型,其中,所述建模系统包括被配置为执行根据权利要求36-42中任一项所述的方法的至少一个处理器。

说明书全文

用于支持在模型到模型的转换中的部分往返的选择性变化

转播技术

技术领域

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

背景技术

[0002] 一个“模型”通常以正式的形式描述一个或更多复杂的应用构件(例如,业务流程、数据结构、软件系统的结构和行为,或其他技术和/或业务组件等)。一个模型可以使用建模基元和/或定义明确的“抽象语言”的规定,其通常指元模型。一些通常的元模型是建模语言(例如,UML类图、UML协作图)的统一建模语言UML族,业务流程建模标记BPMN元模型、建模语言(EPC、VAC、FAD等)的集成的信息系统体系结构ARIS族、实体关系(元)模型(ERM)、关联(元)模型等。元模型作为抽象语言,可能被认为是建模元素的集合,其可被用于或“实例化”为描述实际的模型。例如,在UML类图中,建模元素包括类、关联、属性等,然而在关系模型中的模型元素包括关系和它们的属性。这些建模元素可能以多种定义明确的方式被设置,以建立可能表示复杂的业务和/或技术流程或其他事件流的形式模型。
[0003] 元模型原则上独立于具体的符号,因此可能被认为是如上所述的“抽象语言”。例如,元模型可能只定义语言概念和为元模型本身而使用它们形成有效模型的规则。然而用元模型进行实际建模时,需要抽象的符号。比如,元模型的符号包括表示UML类的具有三个“分区”的图框,用于表示ERM中的实体和关系的标记的矩形和方,等。
[0004] 许多元模型的共同特点是相应的模型可以表示为包含节点和边缘的图形,所述节点和边缘可共同被成为图形的“元素”。处理不同“种类”的模型的计算机系统(例如,所谓的模型管理系统)经常使用某种图形模型作为各种各样的模型的内部表征。
[0005] 模型合并涉及从两个模型A和B创建单一的合并的合成模型C(其中A、B和C可以以相同的元模型表达),可能描述应用构件的相同的或重叠的集合(例如,相同的软件系统、相同的业务流程等),但有区别地描述这些构件。比如,A和B可能是相同的源模型的独立修改的两个版本。如另一个例子,A和B可能描述一个应用域的共享一些重叠部分的不同方面。
[0006] 期望运行合并功能递送不包含冗余的合并模型C。也就是说,期望确保出现在A和B两者中的所有模型元素最多在合并模型C中出现一次。根据C的确切目的,通常期望保存在A或B中的所有元素。这样做可以帮助减少信息从输入模型丢失的可能性。然而,这不是合并的一般要求。也将期望使合并的模型C一致并且完整,例如,从而符合它的各自的元模型的条件。
[0007] 由于模型是某种图形,当在例如版本控制系统中做出时,模型合并相比文本文件的更普通(并且通常是line-wise)的合并是不同的挑战。模型的基于文本的合并理论上是可能的,如果它们各自的元模型具有文本(例如,基于可扩展标示语言XML的)符号。但是,基于文本的合并工具不是处理模型合并的固有的工具。比如,大多数文本表征不适合人工直接使用,并只打算作为存储格式或用于模型互换。特别地,(线性)文本表征通常与非线性的相当不同,模型本身的类似图形的结构使得它直接用这些表征工作是很难的并且是累赘的。第二,甚至模型的小的变化能引起它的本文表征的重大变化,使得难于区分模型级别的实际变化和仅仅涉及文本表征的句法变化。因此,基于文本的工具不完全适合于模型合并。
[0008] 当设计合并两个模型A和B的合并系统时,提供函数从A和B分别识别元素对ai和bj,其被认为是相同的(或至少在成功合并操作后的元素应当只在生成的合并模型C中出现一次)。“相同的”元素对在此被讨论作为一个映射关系mapAB:A x B。
[0009] 将理解到mapAB,作为一个关系,既不需要内射函数,也不需要满射函数。通常,来自A的模型元素不需要在B中有相对元素,反之亦然,并且来自A的元素ai并可能在B中有许多“相同”的元素bi1,…,bin,并且反之亦然。在文义上,从两个模型A和B生成这样的映射mapAB的技术被称作模式或模型匹配技术。在其他场景中,这样的映射mapAB也可能从创建模型A和B的流程被生成。
[0010] 基于mapAB的内容,可能从A和B中识别不同类别的多对、多组或单独的对象等:
[0011] 如 果 两 个 对 象ai∈A 和bj ∈B通 过 mapAB被 识 别 为 相 同 的(例 如,(ai,bj)∈mapAB),并且如果没有其他的包含存在于mapAB中的ai或bj的条目a 并且如果ai和bj在所有的有关合并方法的属性(例如,特定的属性等)上达成一致,那么ai和bj可以被称作为相等的。如果ai和bj在一些合并相关的属性上不同,这些对象可以被看作已经被改变。
[0012] 对象ai∈A(bj∈B,分别地)不存在对象bj∈B(ai∈A,respectively),使得可能被认为增加到A中(增加到B中,分别地)。
[0013] 如果两个对象ai∈A和bj∈B被映射mapAB(例如,(ai,bj)∈mapAB)识别为相同的,并且如果包含ai或bj的其他的条目存在于mapAB中((ax s.t.(ax,bj)∈mapAB)∨(by s.t.(ai,by)∈mapAB)),这些对象可能被认为是冲突的。
[0014] 通过这个信息,合并方法可以创建一致的合成模型C。然而相同的对象的处理看似是简单的,情况是必须为所有其他种类的对象做出决定,是否和怎样接收它们进入所述合成模型C。比如,这些决定可能取决于C的预期目的,冲突的细节,在其中创建A和B的上下文等。这些难点说明当前的模型合并必然是人工人物,只有特定的不重要的人物可以安全地自动化。这也表明,通常一个人工必须决定那些元素和哪些属性从A取得和哪些从B取得而包含在结果C中。
[0015] 由本发明的受让人提供的所述集成的信息系统体系结构ARIS模型转换组件允许用户声明描述一种类型的模型可怎样被转换为一种不同的(或有时也是相同的)模型类型的语义上相关的模型。这样的转变的一个例子如图1所示。在图1中,使用业务流程链(EPC)元模型建模的业务流程被转换为在“业务流程模型和符号”(BPMN)元模型中的相等的流程。这个转换可能被称为EPC-2-BPMN转换。虽然所述EPC元模型可能意在被面向业务的用户使用以捕获业务流程,当它们在一个组织中被处理或应当被处理,BPMN是也包含更多技术方面的元模型和符号。使用所述EPC-2-BPMN转换,一个BPMN可能从一个EPC创建,所述EPC被用作以技术细节丰富流程的业务视图的起始点,最后使得所述流程可通过如工作流管理系统(WfMS)的适当的运行时环境被执行。然而,本发明不限于业务流程的建模,而很可能用于其他的场景,比如,复杂技术产品的系统工程。比如,汽车的发展流程现在主要基于模型。在这个场景中,各种汽车构件典型地在系统范围的级别上被建模,定义主要的机械构件,比如底盘、引擎和动传动机构,还有电气/电子组件,比如雨量传感器、限速器,嵌入流程和相关的软件。而且,当开发流程继续,单独的汽车组件本身由越来越多的具体的技术模型定义,最后形成在不同抽象层次上但仍强烈相关的各种技术组件模型。
[0016] 通过所谓的转换模式或规则给出转换的描述,其说明元模型类型的单独的元素或元素组怎样被转化为目标模型类型的相应的元素。ARIS模型转换,尤其是描述转换模式的图示方式在美国公开号为2009/0265684的专利中被详细描述,其全部内容在此通过引用被并入本申请中。转换模式包括源模式、目标模式和映射。所述源模式可被理解为在(多个)输入模型上的图示查询,所述(多个)输入模型描述要查找和转换的元模型的结构。符合由源模式描述的结构的输入模型的每个区域可以被认为是用于这个规则的一个匹配。转换模型的目标模式描述将要为每个匹配创建什么目标模型类型的元素和结构。为每个匹配在合成模型创建的所述结构可被称为一个片段。当然,转换模型或规则可能以其他方式被定义,比如,通过硬编码特定的函数。
[0017] 使用规则的映射部分,开发者可以图示地定义匹配源模式的源模型元素的属性和性能将怎样被转换为目标模型元素的属性和性能。通过在映射中设置附加的运算符并将它们相应地连接,复杂映射的创建可以图示地做出,例如,不用克服处理复杂的表达式语法,因为它被发现在其他的模型转换语言中。
[0018] 在下文说明几个简化的转换规则的例子。图2是将函数转换为抽象任务的示例模式。在图2的左上方的规则“函数到抽象任务”的源模式只包括EPC函数。右方现实的目标模式说明这样的结构将被转换为BPMN抽象任务对象,其被放置在一个道中,所述道被放置在一个池对象中。在该图的下部显示的映射表明抽象任务对象携带与匹配的源函数相同的名称,并且将要被放置进人工任务的道被称为“缺省道”。
[0019] 图3是将具有组织单元的函数转换为人工任务的示例模式。在图3中显示的规则“具有组织单元的函数到人工任务”可以被认为是图2中的规则“函数到抽象任务”的特殊情况。如上所述,源模式包括EPC函数,但在这个示例中的函数与组织单元连接。注意到不直接描述主流程流而是邻近主流程流的元素设置的对象(比如该例子中的组织单元元素)可能非正式地被称为卫星对象。图3中所述目标模式似乎与图2的示例规则的目标模式非常相似。但是,替代创建抽象任务,将创建人工任务。而且,替代将任务设置到“缺省道”,所述道现在根据源组织单元元素被命名。
[0020] 转换规则可能有的复杂程度可能十分大。比如,图4是基于EPC元素的特定集群(constellation)创建特别种类的任务的另一个示例规则。在图4中,与业务服务连接的EPC函数被转换为BPMN服务任务。从图4可看出,该规则的源模式和目标模式包括分配的模型。在这个例子中,源模型匹配必须存在于业务服务的分配的模型。在该模型中,更详细地描述业务服务的附加的软件服务类型对象必须存在。在这个例子中,如图4的左下所示,该对象本身必须再次通过第二源侧分配被详细描述。该规则将匹配并创建相应的服务任务只有这个确切的结构被找到,并且分配的模型将被设置在服务任务,所述模型根据由源模式匹配的分配保持关于服务任务的附加信息。
[0021] 对于创建不同类型任务的不同的EPC函数的集群(constellations)和卫星对象,可能存在类似的特殊化。附加的规则指出怎样将EPC模型的其他元素,如事件和规则转换为BPMN中的对应的元素,所述EPC-2-BPMN转换能将也在技术级别上相关的EPC模型的所有元素转化为语义上相等的BPMN模型。
[0022] 在EPC-2-BPMN转换的设计中的一个挑战涉及歧义的处理。比如,考虑连接到业务服务和组织单元两者的一个函数。在这种情形下,两种模式“具有组织单元的函数到人工任务”和“具有业务服务的函数到服务任务”将匹配,但在它们的结果中将不同(如,符号类型、放置入一个道中等)。解决这个问题的一个可能性涉及使转换中的模式优先(例如,在这种情况下优先创建服务任务)。另一个选择涉及设计相同的源模型元素可以“竞争”的模式,以这样的方式竞争:只有确切地它们中的一个明确地与给定的函数匹配,它们才是可应用的。根据前一种方法,模糊的示例函数将被转换为人工任务,因为人工任务模式具有更高优先级。
[0023] 业务流程管理(BPM)的目标是捕获、分析并优化并改进企业怎样执行它们的流程,并且为在日常业务中更有效地实行流程,试图提供IT支持。BPM的一个方面涉及引入控制流程执行的工作流管理系统(WfMS),所述流程关于由人工执行的活动(例如,随着IT支持的变化的程度)和完全以自动方式并可能在软件和/或其他技术系统的帮助下执行的活动。在传统的人工方式中,BPM开始于专家分析一个组织当前怎样执行它的业务流程。这个分析的结果以多种方式被捕获,非正式地如要求文档,或以半正式的符号如上述的EPC。在选择优化步骤后,这些业务中心的流程描述被映射到最终可被WfMS执行的技术流程描述。作为这个实施步骤的一部分,没有被业务流程描述捕获的方面可能通过识别并连接流程需要的信息系统等被填充(filled in)。作为一个完全人工开发的任务,这个方法是既慢又昂贵的。
[0024] 但是,模型-2-执行(Model-2-execution,M2E)的目的是通过使业务中心流程描述到可执行的、技术条件的转换的部分自动化来减少BPMN的巨大的人工开发工作。从而M2E的一个方面涉及例如,通过用模型-2-模型(model-2-model)转换替代大部分人工工作,将模型驱动开发(MDD)的概念调节到BPM领域。上文引入的所述EPC-2-BPMN转换可以被用作模型-2-执行方法中的转换。在MDD术语中,EPC-2-BPMN转换可以被理解为从不捕获与具有IT系统的实现相关的方面的计算独立模型(CIM)到平台独立模型(PIM)的转换。PIM可能包括与所述实现相关的方面,尽管但是可能仍独立于使用的具体的实现技术(例如,在BPM的情况下,使用的具体的工作流管理系统,或WfMS怎样与其他要求的IT系统通信等)。
[0025] 通常在模型驱动开发中的模型转换的环境中,并且当它通过M2E方法实行时尤其也在用于BPM的MDD中,如图5所示,这个情况经常出现在在通过转换运行创建初始转换的模型T后,源模型S被业务用户改变,形成修改的源模型S’。为了将这些变化传送给技术BPMN层,可能再次转换S’,形成新的转换模型T’。但是,同时,流程引擎可能已经修改了原BPMN模型T并且用技术信息将其扩增,那种方式形成修改的BPMN模型T”。在这种情况下,简单的以T’替换T”以使得业务级别改变为技术级别是不合适的,因为这将丢失形成T”的通过技术用户做出的所有变化。除非T’或T”能够作为一个整体被丢弃并且仅来自T’或T”的改变可以考虑到结果中,T’和T”中的独立的变化可能需要通过合并这两个模型T’和T”结合为单一的、一致的合并的模型TM。在这个合并流程中,T’(例如,从变换修改的源模型S’产生的模型)可能被称为新的转换的模型,并且T”可能被称为合并的目标模型。
[0026] 在图5的例子中,业务用户将函数F3增加到所述流程,作为F2的(独有的)替代选择以创建S’。在原转换的模型T中,流程引擎增加附加的任务F2b以创建T”。F2b可能表示需要从技术立场考虑,但不需要考虑业务层级的任务。当S’现在被转换以获得T’,可以看出T’与T”不同并且可能需要执行合并以获得尽可能好地反映在两个模型中的变化的结果。
[0027] 如上所讨论的技术(例如与总的模型合并问题相关的技术)能够成功合并两个模型T’和T”,为了合并的目的提供一种方式识别将被认为“相同”的元素,例如获得mapT’T”的方式。替代使用内在模糊的方法,比如,基于它们的性能(例如,名称、类型等)猜测相同的(例如,可合并的)对象对,或甚至完全将相同的对象对的识别留给用户,转换本身可能在它创建的所有元素上放置“追踪”信息。
[0028] 该追踪信息可能包括在其他事件之间的转换的模型中的每个元素ti,关于哪些转变规则包含在ti的创建中的信息,“负责”创建ti的模型s中的源元素的识别符(identities)(例如,由帮助创建ti的不同的变换规则的源模式匹配的那些源模型元素)等。如果两个对象t’∈T’,t”∈T”在它们的追踪信息和一些附加性能上的相符性达到足够的程度,它们可以被认为是同等的。然而这可能首先看起来是违背常理的,这个合并的语义可能是有用的,在实践中,模型趋向于有许多性能(例如,类型、符号、属性,比如姓名等)等同的对象,并且这些对象最后转化为也是等同的合成模型对象。这样,如果它们的源模型元素的识别符没有用作识别标准,可能不能disambignute这些等同的(但不相同的)合成模型元素并且从而可能不能执行适当的非模糊合并。而且,通过经由源对象识别合并,也可能在合并的适当的非模糊合并。而且,通过经由源对象识别合并,也可能在合并的过程中传送性能(例如,EPC对象的重命名)的变化。如果合并决定基于性能并且如果这些性能在源模型或目标模型上被修改,对象不能被合并。
[0029] 在ARIS模型变换的范围中的模型合并的存在的实施方式中,将S’变换为T’并且将T’与目标模型T”合并是一个整的流程。用户可以挑选源模型、合并的目标模型,并且可能出现表明T’和T”之间冲突的单一模型,以下如图6所示。该模型可能被称为冲突模型TC。在冲突模型中,用户可以解决剩余的冲突以创建最终的合并模型TM。比如,冲突可能指临近冲突元素的图标(icon)。这些图标也可能被称为相应元素的“合并状态”。
[0030] 由于映射T’T”通过如上讨论的变换的追踪信息获取,冲突模型可能从以如下方式被创建:
[0031] 相同或被改变的元素对a∈T’和b∈T”只在结果中显示一次,如函数F1和F2,开始和结束事件,在该例子中的道和池。这些元素没有冲突或与它们相关的“合并状态”。注意到在S’中发生的属性改变可能被写入现有的对象,例如,源模型默默地重写在目标中的任何属性改变。这样,为了在ARIS模型变换中的合并的目的,同等的或被改变的对象可能被相同地处理。
[0032] 在T’中找到但在T”中没有对应元素的元素(根据映射T’T”)被增加到冲突模型并且以合并状态“通过变换增加”(或“在源中增加”)标记,通过与这些元素相邻的绿色加号指示。在这个例子中,可以看出从新的XOR规则创建的BPMN网关,任务F3从新的函数F3创建,并且新的“结束2”结束事件这样标记,因为是它们之间的所有连接。而且,任务F2和结束事件“结束”之间的连接以“通过变换增加”标记。这可能看起来不直观,因为相应的连接没有从S到S’被改变。但是,当F2b通过流程工程师插入时,T”中相应的连接已经被删除。在理想的场景中,该连接的实际的合并状态可能必须在目标中被删除”。但是,这个合并可能不能区分这两种情况。为了能够将这个连接正确地标记为“在目标中删除”。可以需要保持T’的完全改变的历史,这可能是困难的或不可能的或只是不值得大小、空间、复杂性、可能的流程链等之间的开销。
[0033] 对于在T”中找到的但在T’中没有对应元素的元素,可能被区分为两种情况。如果这样的元素t通过(原始)变换被创建(可以基于在t上的追踪信息的出现而确定),这可能表明源模型S’已经以这样一种方式被改变,对应于t的对象不再由当前变换创建。结果,这可能被添加到冲突模型并以合并状态“通过变换删除”标记。例如,如通过红色负号。在这个例子中,在原始模型T中的F1和F2之间的连接。在这个例子中,F1和F2之间的连接在原始T中并且当创建的T”被这样标记,通过业务工程师被保留,因为连接不再存在于T’中,由于当从S进行到S’,在EPC中的对应的连接已经被业务用户删除。
[0034] 如果一个元素t被人工增加到T”,其能够被追踪信息的出现识别,它也可能被增加到冲突模型并且如蓝色加号指示的合并状态“增加到目标中”。在这个例子中,函数F2b和内部连接被这样标记。
[0035] 具有三个合并状态中的一个的每个对象一起可以被称为一个原子冲突。
[0036] 通过用户界面,用户可以单独接受或拒绝单个的原子冲突。当接收一个“通过变换添加”或“在目标模型中添加”冲突,对应的模型元素被保存并且合并的状态被移除,以表明冲突已经被解决。当拒绝这样一个冲突,模型元素被删除。当接受一个“通过变换删除的”冲突,所迷元素被删除。当拒绝它,该元素被保存并且合并状态被移除。
[0037] 当可能通过单独地接受或拒绝原子冲突处理合并冲突的解决方案,这个方法不是非常便利并且有时可能使用户遇到ARIS中的模型表达的内部细节。潜在复杂的技术细节可能被呈现给业务用户,不需要理解的业务方面可能被呈现给用户等。为了使得合并冲突的解决方案更容易,本发明的受让人引入了高级别冲突的概念。基于这种考虑,可能使用如上所述的在合并过程中获取的基本信息,比如,包括对象的不同的合并状态(同等的,添加到A/B中,冲突等)和在被合并的模型中的它们的集群,以识别高级别合并冲突。
[0038] 替代让用户在原子(atomic)元素的级别上解决合并冲突(例如,具有非空合并状态的对象和连接),高级合并冲突可能捕捉在更大范围(例如,可能覆盖一个冲突中的大量模型元素)和大部分时间上合并的模型之间的不同点的语义,允许用户容易并且快速地在单一操作中解决它们。这种使得冲突解决更简单并更方便的方法被详细描述在美国申请号为13/024,646,在2011年2月10日提交的专利申请中,其全部内容在此通过引用被并入本发明中。
[0039] 合并视图是一个工具,帮助使得交互合并的任务对于用户更容易,尤其对于较大的模型。如以下的图7中所显示,它并排显示源模型和冲突模型。然后它允许用户简单地通过选择用户感兴趣的元素,来查找右边显示的在目标模型中的每个元素怎样对应于左边显示的在源模型中的元素(反之亦然)。如图7显示的EPC功能F1和它对应的BPMN任务,如果在源模型中的一个元素被选择了,在目标模型中的对应的元素被选择,反之亦然。除选择对应的元素外,各自的其他的视图的检视区被自动滚动到选择的元素,当与因太大而不适合在一个屏幕上的模型工作时,这是一个较优的特征。通过合并的视图显示的相应的信息来源于上文讨论的变换追踪信息。
[0040] 通常,源模型元素和目标模型元素之间的关系可能具有高达多对多的任何基数,例如,使得每个源(目标)元素在目标(源)侧可能具有零个、一个或许多对应的元素。如上所述,受让人已经提供在ARIS模型变换组件中的合并函数(包括被美国申请号为13/024,646的专利包含的复杂冲突检测)。此外,通过本发明的受让人提供的ARIS模型合并组件与ARIS工作,其提供用于在不同的ARIS数据库之间转移ARIS模型的基于XML的输入和输出模型。比如,模型M可能在数据库DB X中被创建,被输出到一个文件,并且输入到数据库DB Y。假设模型M现在在X中被改变,形成修改的模型M’,并且同时,原输入的模型M也独立地在数据库DB Y中被改变,形成模型M”。M’现在再次输出到一个XML文件中,并且输入到数据库DB Y中。因为M’和M”是相同的模型的不同的版本(可以通过模型和它的模型元素上的独有的识别符识别的事实),一个模型合并可能需要被执行。当输入M’,用户可以选择模型M’(设定“源重写目标”)或模型M”(设定“目标保留”)将在冲突的情况下占优势。这些设定可以为对象、连接、模型等被不同地设定。然而,这个合并技术不能对怎样解决个别的冲突提供选择性的控制。在这个意义上,它不是交互的。它进一步不允许用户进行从模型M’回到模型M”的改变的选择。
[0041] 大量计算机辅助软件工程(CASE)工具要求模型驱动开发MDD支持的可变的等级。然而,除了一些“便利的”特征外,实际的申请行为典型地必须通过手动执行,例如,通过“填写”空的方法模块组或增加并详述模型中没有完全具体化的方面。其他的人工工作包括前述的即开即用的特性的定制(如定制默认对象序列化以便它符合现有的存储格式或数据库模式)。
[0042] 在用于软件工程的往返工程中,从模型生成的构件通常不是其他的模型,而是程序代码(例如,结构化文本)。而且,在软件工程领域中的往返工程方法的一般的普通的假定通常是在平台相关模型PSM级别上执行的所有的改变,并且其能够以用于应该被传送的个人信息管理PIM的建模语言表现。因此,在M2E中,传送一个改变是用户在具体案例的基础上通过包含的构件的语义引导的有意识的选择。
[0043] 软件工程环境中的往返工程引起的另一个问题是能够用专用的模型元素(例如,包含关联或聚合关联)明确表示的许多方面被映射到目标编程语言(例如,对象引用)的相同基础的元素。因此,通常很难基于代码识别建模的这些方面并且适当地将它们传送回模型级别。
[0044] ARIS模型变换的函数和讨论的交互合并允许通过接收后拒绝BPMN模型中的改变来解决合并冲突,不论它们起因于EPC中的改变或起因于BPMN模型本身中的直接的改变。举个例子,关于图8,其显示了一个非常简单的合并场景。EPC S被首先转变为对应的BPMN模型T。此处,流程工程师通过删除从任务F1到结束事件的连接作出技术改变,增加新的任务“添加在BPMN中的F2”,并且将它与F1和结束事件连接,从而创建修改的转换的BPMN模型T”。
[0045] 在并行流程中,业务用户通过在开始事件和函数F1之间插入另一个函数F0对EPC做出业务改变,形成修改的源模型S’。如果S’将要不合并被转换,将获取新的转换的模型T’。如果T’或T”被作为新的BPMN模型,流程工程师或业务用户的改变将分别被丢失。为了避免这样的场景,交互合并技术可能被用于使并行改变一致。通过合并T’和T”,产生冲突模型TC。在这个模型中,以上讨论的高级合并冲突检测识别两个高级冲突,也就是,F0的增加,并且开始事件和F1之间的直接连接的删除被识别为“在源中替换”的冲突。这个冲突要么被接受(引起在冲突模型中的用红色负号标记的直接连接的移除并保留F0和它附带的连接并且移除它们的绿色加号合并状态)要么被拒绝(其引起F0和它的连接的删除,并且从开始事件和F1之间的连接移除红色减号合并标记)。
[0046] 详细显示在图9的左侧的第二高级“在目标中替换”冲突(其说明解决“在目标中替换”高级冲突的选择)由通过流程工程师将新任务“添加在BPMN中的F2”添加到BPMN模型而引起。如图9的右上部所示,如果这个高级冲突被接受,新添加的任务和它附带的连接被保留在结果中,它们的蓝色加号合并状态被移除,并且从F1到结束事件的绿色加号连接被移除。如图9的右下部所示,如果所述高级别冲突被拒绝,从F1到结束事件的连接被保留,它的绿色加号合并状态被移除,并且新任务“在BPMN中添加的F2”和它附带的连接被移除。
[0047] 虽然高级冲突的概念使得用户更容易解决通过在BPMN模型中增加一个元素引起的合并冲突,但这个冲突解决方案只影响BPMN模型。EPC被留下未被改变。虽然在那些情况下这是期望的结果,其中在BPMN模型中的添加和改变只表示对我们的流程的业务视图没有影响的技术细节(例如,不要求EPC源模型的改变),但有许多种情况,事实上要求具有在BPMN模型中做出的个别的(但不需要所有的)在EPC上被影响的改变,因为它们事实上与业务用户相关。这样,该当前的方法不支持人工执行从技术BPMN级别到EPC级别传送这样的改变的交互合并。但是,如下所解释的,人工解决这些问题具有许多缺点。
[0048] 用人工传送,用户必须以一种方式改变EPC,即改变后新的转变结果给出如当前在BPMN中提供的相同的结果,或使得已经被传送到EPC的在BPMN中做出的改变表现为好似它们已经在源EPC模型中“被那样建模”。
[0049] 图10说明执行交互合并的用户怎样能够人工执行如图8的例子中的抽象任务“在BPMN中添加的F2”(以下被称为F2BPMN)的BPMN侧的添加的传送。此处,用户在EPC F2EPC中创建一个类似命名的函数并将其与在BPMN模型T”中怎样将F2BPMN与它的环境相连联系起来。这个人工传送的结果被显示在如EPC S”的图10的左上部。用户基本创建了一种情形,以便对应的变换模式(在这里将是我们在上文图2中引入的“函数到抽象任务”模式)匹配并且在下一个转换运行中将创建由于这里做出的人工改变而在BPMN模型中存在的相同的情形。
[0050] 这样的人工方法的缺点涉及有关用户的努力。虽然在这个简单的例子中它看起来是明确的,不过一旦许多改变必须被传送给EPC,这个方法可能迅速成为重复的、费时的,并且易出错的任务。
[0051] 此外,恰当的传送不总是如这个例子中是简单并且明显的,其中只涉及只在EPC中的单一对象的创建和连接。比如,考虑到与图4相关的讨论的“具有业务服务到服务任务的函数”的变换规则。如果期望传送被增加到BPMN模型的服务任务以便这个规则现在匹配一个十分复杂的对象结构(包括许多指定的模型),将必须正确地创建。为了正确地做出,可能需要具有我们的EPC-2-BPMN转换的语义的非常详细的理解,这不能总是从用户执行交互合并合理地期望。正确和一致的模型传送的问题在上述的系统工程环境中是同样地严重。比如,在一辆汽车的车辆部件的不同的技术模型之间存在强相互关系,因为车辆部件典型地具有多个交互作用点(例如,考虑由基于软件的速度限制器和紧急破坏组件共享的基于光学或雷达的距离感应器组件)。这样的强相互关系和其它的特性交互可使得在不同的模型级别之间的模型元素的正确的并一致的传送十分困难。
[0052] 即使人工努力和要求的关于转换的内部知识被认为是可接受的,这样的人工改变传送也可能有技术限制。仍然引用图10中示例的人工传送,如果S”被再次转换,将创建通过F2EPC的变换创建的包含任务“在BPMN中添加的F2”(F2EPC’)的新的合成模型T”’。乍看起来,这个模型看上去与修改的转换的BPMN模型T”相同,其中用户人工添加新的业务相关的任务F2BPMN。结果,可能很希望如果这两个模型将被合并为将不显示关于任务“在BPMN中添加的F2”的冲突,并且人工改变传送是成功的。但是,如我们上述讨论的,转换的嵌入合并函数不依靠如对象类型、符号或一对对象的名称以确定是否它们是可合并的,但替代地使用转换的内部追踪信息。如上所解释的,该追踪信息包括转换的每个结果对象,有助于转换结果的创建的元模型对象的设定和包含在它的创建中的转换模式。结果,如果用户必须执行S”到T”转换增加合并,通过从人工增加的EPC函数F2EPC转换创建的抽象任务F2BPMN’可能不能与直接增加到BPMN的抽象任务F2BPMN合并,因为它们在它们的追踪信息不一致,因为F2BPMN’表明它来源于F2EPC,然而F2BPMN没有表明任何源对象,因为它起初没有通过转换创建。因此将产生如在图10的底部显示的冲突模型TC,其包含抽象任务F2BPMN和F2BPMN’。
[0053] 所述高级“在目标中替换”冲突将被解决,并且可能保留通过转换来自EPC的任务F2BPMN’(用绿色加号标记为“在源中添加”)或来自BPMN的任务F2BPMN(用蓝色加号标记为“在目标中添加”)。但是,这样做仍将不提供想要的结果。如果通过拒绝“在目标中替换”冲突保留F2BPMN’,将产生在EPC和BPMN模型中的对象之间的正确的对应,但是将丢失流程工程师可能已经放到丢弃的F2BPMN中的任何附加的技术细节(例如,设定技术属性或用关于调用的服务等的信息增加分配)。在另一方面,如果F2BPMN代替的被保留,该技术信息将被保存,但在F2BPMN和F2EPC之间没有正确的对应。不仅这两个对象将不显示为在合并的视图中对应,而且在未来的合并操作中对F2EPC的改变(例如,重命名)将不传送到F2BPMN。
[0054] 上述讨论的例子处理对于目标模型是新的的模型元素的传送。另一个通常在MDD场景中需要的普通类型的传送不仅包括新元素的增加,还包括对现有的目标模型元素的增加、限定或其他改变,其通过在源模型中的对应的改变被反映,所述现有的目标模型元素通过从源模型中的元素转换被创建。在图11显示的例子中,通过由于没有任何“卫星”对象的简单的EPC函数的转换创建的抽象任务F1被流程工程师改善为服务任务。通过任务调用的服务被指定在分配给服务任务的附加的模型中。
[0055] 如图11的底部显示的,如果转换和合并操作没有被执行,合并冲突将产生,不因为追踪信息不同,而因为对象偏离符号类型(抽象任务对比服务任务)和分配的数量和类型(不分配对比函数分配图表)。此外,如果发现BPMN侧的改变与业务用户不相关,可能解决这个冲突。如前所述,这将以不能传送EPC中的F1的任何重命名等为代价而达到。但是,如果认为或需要EPC反映该变化,可能执行如在以下图12中显示的BPMN侧的改变的人工传送。为了使得EPC函数F1被转化为看起来像流程工程师在BPMN模型中创建的服务任务,可能增加在图12的右上部显示的分配的模型的集合和相关的对象,那个方式帮助确定F1现在成功地被图4中的转换规则“具有业务服务的函数到服务任务”的源模式匹配。这个例子帮助说明一旦尝试传送包含更复杂的模式的改变,涉及的努力和需要快速“使其正确的知识”在实践中是禁止的。如果人工修改的EPC被再次转换并与BPMN模型合并,如前的类似的情形将产生。也就是,如上的前述例子中讨论的,虽然两者将看起来相同,但两个来自T”’和T”的服务任务F1将不能与为了正确建立合并视图的函数的所有否定结果和F1EPC到F1BPMN的改变的未来的自动传送成功合并。
[0056] 到现在为止,已经讨论了人工传送(BPMN)目标模型到(EPC)源模型中的添加或改变的问题。如上所示,这通常将是已经描述的包含在用于任何情况但除了最不重要的情况的任务中的人工努力,和与模型合并决定两个对象是否可合并的方法相关的该人工方法的限制。除添加和改变外,与删除有关的第三种修改操作可能在目标模型上被执行。
[0057] 图13显示一个用于在BPMN侧删除的例子:流程工程师移除人工任务对象“F2”和“网桥”,通过在F2的以前的前面的人工任务“F1”和以前的后续结束事件“结束”之间增加直接的连接创建在流程流中的间隙。如该图的底部附近所示,如果转换和合并操作现在被再次执行,将在产生的冲突模型TC中生成“在目标中替换”的高级冲突。接受这个冲突(接受F2的替换和它的具有单一边的两个关联边)将引起在左下部显示的结果,而拒绝它将保持如该图的右下部显示的原转换结果。
[0058] 如图14中所示,如果在技术BPMN级别上的改变现在考虑与业务级别有关,删除能够再次被传送。此处,EPC根据BPMN级别上的改变被改变,这样函数“F2”和它邻近的“Otto”组织单元对象的发生被移除。如果修改的源模型现在被转换,结果将在结构上与在源侧修改的原BPMN模型相同。如果转换和合并操作再次被执行,结果(不论在合并中的冲突)将取决于使用的合并方法(或获得映射关系mapAB的方式)的细节。如图14的底部的左侧所示,如果合并方法考虑两个连接可合并,如果它们的开始和结束对象是可合并的,没有合并冲突将产生。
[0059] 但是,如果合并方法使用上述讨论的基于同一性的可合并性决定,不仅决定对象的可合并性,还有连接的可合并性,可能产生如图16的右下部显示的冲突。在这些情况下,正如前面讨论的添加和修改操作,在技术级别到业务级别上的人工传送和改变将是不可能的,因为用户将需要操作内部追踪信息等。
[0060] 这样,将理解到在本领域中需要帮助支持用户管理模型转换和/或合并的技术,和/或帮助克服当尝试转换和/或合并模型时产生的以上描述的和/或其它的问题的方法。在基于模型的系统工程的领域的技术人员将理解到这些问题同样与上述使用用例有关,包括复杂的技术产品的制造、制造设备的基于模型的控制和业务流程的建模。

发明内容

[0061] 特定的示例实施例的一方面涉及用于传送(或上拉)在技术模型(例如,BPMN模型)到面向业务模型(例如,EPC模型)中做出的业务相关的改变。这样做可能减少并有时消除人工改变传送的需要。根据涉及避免冲突的特定的示例实施方式,例如,通过使得特定的改变的对象表现为,它们通过“上拉”EPC对象,通过改变合并需要的内部属性而被创建。可选地,BPMN模型可能被“修正”以便合并可能没有冲突。
[0062] 特定的示例实施方式的另一方面涉及从技术模型到面向业务模型的转换的选择性的、局部的倒置,或反之亦然。
[0063] 特定的示例实施方式的另一方面涉及包含可行性检查的上拉操作(例如,确定上拉是否能应用与选择的对象)和上拉执行。
[0064] 根据特定的示例实施方式,可行性检查可能被分为多个阶段。在第一个示例阶段,可能执行一个粗糙的检验以确定上拉操作是否有意义,可能返回一个布尔真/假值。在第二个示例阶段,可能执行更详细的检验以确定是否上拉真的可能被执行,可能返回一列通知用户为什么上拉不能被执行的结果。
[0065] 根据特定的示例实施方式,例如,上拉实施可能包括在面向业务(例如,EPC)模型中创建对象;更新技术(例如,BPMN)对象的允许成功合并的相关内部属性;在技术(例如,BPMN)模型中可选择地改正用户引入的错误;并适当地将上拉对象与它们的环境相联系。
[0066] 特定的示例实施方式的另一方面涉及将上拉对象与它们的环境关联,以便在传送后,对象表现为用于合并的当前的面向业务(例如,EPC)模型。根据特定的示例实施方式,连接可能是确定的,例如,使得结果将是相同的,不管传送在其中做出的顺序或序列。
[0067] 根据特定的示例实施方式,连接算法包括查找将要被传送的目标模型对象的目标侧后继和前驱元素(一起被称为边界元素);使用追踪信息查找对应于目标模型前驱和后继的源侧元素;可选择地删除边界生成的连接(例如,如果改变传送行为在冲突解决的过程中被执行);并创建到所述传送的对象和来自所述传送的对象的连接。
[0068] 特定的示例实施方式的又一方面涉及在一个模型中虽然内部不一致的传送改变。
[0069] 在特定的示例实施方式中,提供一种将在第一计算机表征模型内发生的改变传送到第二个第一计算机表征的方法。对应于对所述第一模型的至少一个改变的输入被接收,所述至少一个改变表明在第一模型中的至少一个对象已经被增加、修改和/或删除。将对所述第一模型做出的至少一个改变传送到所述第二模型的指令被接收。至少一个对应的改变传送动作(CPA)通过至少一个处理器被执行,以使得对所述第一模型做出的至少一个改变视情况被全部或部分传送到所述第二模型,在执行后,实现所述第一模型和第二模型之间的一致性。所述至少一个改变传送动作CPA包括指令:当执行时,包括:确定是否所述至少一个改变传送动作能够被应用于所述至少一个改变,以及当确定所述至少一个改变传送动作能够被应用于所述改变时,将所述至少一个对象链接到所述第二模型中的至少另一个对象。每个所述的改变传送动作CPA对应于一个或更多的对应的转换模式或规则,并且包括程序逻辑,所述程序逻辑可由至少一个处理器执行以在相反方向实施各自的转换模式或规则。所述第一模型是面向技术的模型并且所述第二模型是对应的面向业务模型,反之亦然。
[0070] 在特定的示例实施方式中,一种建模系统被配置为使得用户将在第一计算机表征的模型中做出的改变传送到第二计算机表征的模型。所述系统包括处理资源,所述处理资源包含至少一个处理器和至少一个存储器。所述处理资源被编程为:接受对应至少一个用户指定的对所述第一模型的改变的输入,所述至少一个改变表明在所述第一模型中的至少一个对象已经被增加、修改和/或删除;接收将对所述第一模型做出的至少一个改变传送到所述第二模型的指令;以及执行从一组可执行的程序逻辑包中选择的至少一个程序逻辑包,为了有选择地使得与对所述第一模型做出的至少一个改变相关的一些或所有变更被传送到所述第二模型,使得所述第一模型和第二模型至少在受所述传送影响的一个或更多区域中相互一致。所述至少一个程序逻辑包被编程为:确定是否所述至少一个程序逻辑包能够被应用于至少一个改变,以及什么时候确定所述至少一个程序逻辑包能够被应用于所述改变,将所述至少一个对象链接到所述第二模型中的至少一个其它的对象。每个程序逻辑包对应于根据执行可选择地在相反方向应用的至少一个各自的转换模式或规则。所述第一模型是转换的目标和传送的来源,并且所述第二模型是转换的来源和传送的目标。
[0071] 根据特定的示例实施方式,对应在所述第一模型中添加的对象,所述链接可能包括:(a)在第二模型中创建一个或更多的对应的元素;(b)寻找与增加在所述第一模型中的所述对象邻近的、没有合并状态冲突的边界对象;
[0072] (c)对于所述第一模型中的每个边界对象,在第二模型中识别对应的边界对象;以及(d)对于从在所述第一模型中增加的对象到在所述第一模型中的边界对象的每个路径:当有一个或多个对象沿着这条路径,增加从在所述第一模型中增加的对象到各自的边界对象的直接连接,设定所述直接连接的合并状态以指出它被增加在所述第一模型中,以及在所述第二模型中创建一个或更多的对应的连接;否则,从现有的单一连接中移除在目标合并状态中增加的(直接连接)并在所述第二模型中增加一个或更多的对应的连接。
[0073] 在特定的示例实施方式中,提供一种可选择地将在第一计算机表征的模型中发生的改变通过建模系统传送到第二计算机表征的模型的方法,所述建模系统包括包含至少一个处理器的处理源。将对所述第一模型做出的至少一个改变传送到所述第二模型的指示被接收,与和在所述第一模型中增加的对象对应的改变一起被传送。至少一个对应的改变传送动作(CPA)通过至少一个处理器被执行,以使得对所述第一模型做出的至少一个改变被传送到所述第二模型。所述至少一个相应的改变传送动作CPA被实施为:执行可行性检查以确定是否至少一个改变传送动作CPA能被应用于至少一个改变,和什么时候所述可行性检查指示所述至少一个改变传送动作CPA能被应用于一个改变,将所述至少一个对象与所述第二模型中的至少一个其它的对象连接。所述连接被实施,与处理资源有关,通过至少以下步骤:
[0074] (a)查找正被传送的所述第一模型对象o1st的第一模型侧边界元素,包括:
[0075] (i)存储开始于o1st的所有出站直接路径并且将在第一模型中增加的连接归到出out out out站路径的列表中,path ={path 1,…,path n},
[0076] (ii)定义用于出站路径的结束对象的多重集succ1st={s1st1,…,s1stn},该多重集1st
是到o 的第一模型后继,
[0077] (iii)存储开始于o1st的所有进站直接路径,并且将在第一模型中增加的连接(以in in in相反的方向)归到入站路径的列表中,path ={path 1,…,path m},
[0078] (iv)定义用于入站路径的开始对象的多重集pred1st={p1st1,…,p1stn},该多重集是1st
到o 的第一模型前驱,以及
[0079] (v)定义所述第一模型前驱和后继的并集succ1st∪pred1st=border1st,该并集是第一模型边界对象的集合;
[0080] (b)使用追踪信息查找与所述第一模型前驱pred2nd={p2nd1,…,p2ndn}和后继2nd 2nd 2nd
succ ={s 1,…,s n}对应的第二模型中的元素,以及
[0081] (c)对于每个p2ndi∈pred2nd(or每个s2ndk∈succ2nd):
[0082] (i)在第二模型中创建从p2ndi到o2nd(或从o2nd到s2ndk)的连接,其中o2nd是o1st的第二模型对应对象。
[0083] 根据特定的示例实施方式,(c)可能进一步包括:
[0084] (ii)如果路径pathini的长度length(pathini)(pathoutk length(pathoutk))对应于2nd 2nd
p i(s k)是1:
[0085] 移除所述第一模型中的该路径的单一连接的在第一模型中增加的合并状态,否则1st 1st 1st 1st
在所述第一模型中创建从p i到o (或从o 到s k)的连接并将其合并状态设定为在第二模型中增加。
[0086] 根据特定的示例实施方式,可能期望,在(b)和(c)之间,确定对应的改变传送动1st 1st 1st 1st
作CPA是否在冲突解决期间被执行,如果是,对于具有p i∈pred 和s k∈succ 的
1st 1st 1st 1st 1st 1st 1st
每个对(p i,s k),存在从p i到s k的连接cxn (或从s k到p i),其合并状态被增
2nd 2nd 2nd 2nd 1st
加在第二模型中,在第二模型中从p i到s k(或从s k到p i)删除该连接cxn 并删除
1st 2nd
cxn 对应的第二模型中的连接cxn 。
[0087] 在特定的示例实施方式中,提供一种将在第一计算机表征的模型中发生的改变传送到第二计算机表征的模型的计算机实现方法。对应于对第一模型的至少一个改变的输入被接收,所述至少一个改变指出在所述第一模型中的至少一个对象已经被增加和/或修改。至少一个可行性检查被执行以确定是否至少一个改变能被传送到所述第二模型;以及如果是,所述至少一个改变被传送到所述第二模型。所述传送包括根据至少一个转换模式或规则将所述至少一个对象与所述第二模型中的至少一个其它的对象连接。
[0088] 在特定的示例实施方式中,用于将在第一计算机表征的模型中发生的改变传送到第二计算机表征的模型的建模系统可能被提供以实现该方法。
[0089] 特定的示例实施方式也提供实体存储用于执行以上总结的和/或其它方法的指令非暂态计算机可读存储介质,和对应的计算机程序
[0090] 这些特征、方面、优点和示例的实施方式可能被分别使用和/或以多种结合应用以实现本发明的进一步的实施例。附图说明
[0091] 通过结合附图引用以下示例说明的实施例的详细描述,可以更好并更完全地理解这些和其它特征和优点,附图为:
[0092] 图1是示例的EPC-2-BPMN转换的示意图;
[0093] 图2是将函数转换为抽象任务的示例模式;
[0094] 图3是将具有组织单元的函数转换为人工任务的示例模式;
[0095] 图4是是基于EPC元素的特定集群(constellation)创建特别种类的任务的示例规则。
[0096] 图5显示怎样从源模型和转换模型的独立的修改产生冲突;
[0097] 图6是显示为用于执行交互冲突解决的用户界面范例的示例冲突模型;
[0098] 图7是示例的合并视图;
[0099] 图8显示具有高级别问题的冲突解决的例子;
[0100] 图9说明解决所述“在目标中替换”的高级别冲突的选择;
[0101] 图10说明执行交互合并的用户怎样能人工执行如图8的例子中的抽象任务“在BPMN中增加的F2”在BPMN侧增加的传送;
[0102] 图11显示由从转换对模型元素做出的BPMN侧改进引起的冲突;
[0103] 图12显示对EPC的BPMN侧的改进的人工传送的方法;
[0104] 图13是在技术级别上删除的例子,和形成的冲突模型;
[0105] 图14显示当人工传送删除操作时会发生什么;
[0106] 图15显示根据特定的示例实施例的新的元素变化传送动作(NCPA)和完善的变化传送动作(RCPA)的示例阶段。
[0107] 图16显示根据特定的示例实施例使得EPC中的歧义能够被检测为可行性检查中的一致性检验方面的一部分。
[0108] 图17建立在图8的例子上,根据特定的示例实施例,假定冲突已经被解决,并且包含在被增加到源模型的对象上应用抽象任务CPA。
[0109] 图18显示根据特定的示例实施例,当它们将被服务任务RCPA执行时,源模型的修改。
[0110] 图19显示根据特定的示例实施例追踪信息的更新;
[0111] 图20是根据特定的示例实施例,具有设置在目标模型中的改正动作的CPA的例子。
[0112] 图21显示根据特定的示例实施例,一组在目标中增加的元素,其中的一些应该被传送;以及
[0113] 图22A-22B建立在图21上,并提供表明特定的示例实施例的连接算法的说明性场景。

具体实施方式

[0114] 在某些情况下,将需要从一个面向业务的流程描述(例如给定为EPC或其他模型)生成一个技术流程描述(如给定为BPMN或者其他的模型)。在某些情况下,这可能与模型转换框架相关而被执行(如ARIS模型转换框架),该框架考虑到声明指定关于如何从一种类型的模型转化为另外一种类型的语义上等同的模型的规则。
[0115] 一旦最初的BPMN或其他技术流程描述已经通过以一个合适的EPC-2-BPMN或其他转换方式转换EPC或其他面向业务的流程描述而被创建,面向业务的流程描述和技术流程描述便会彼此独立地发生改变。在交互合并的帮助下,可以再次变换已修改的面向业务流程描述并将其与已改变的技术模型合并。这样一来,在EPC或其他面向业务的流程描述的变化可能被适用于BPMN或技术模型级别而没有放弃对技术模式的改变,反之亦然。然而如果这些变化也与业务观点有关,则并不总是可能使得直接对BPMN或者技术模型做出的改变都能适用回EPC或者面向业务模型。
[0116] “某些特定的示例实施例的“上拉”方法允许用户有选择性地倒置的EPC-2-BPMN转换到改变的或添加BPMN级别的对象上,同时在EPC中创建相应的对象(或改变EPC中的现有对象,EPC的BPMN对应对象进行了修改,使他们现在的变化反映在BPMN模型)。对象可能被创建,以至于让他们稍后将与BPMN的对象成功融合和不发生冲突。然而新创建的对象的详细信息,有时可能是针对于的各自的使用案列,那些转化(因此在某些情况下,可以是硬编码的),允许包含上拉框架和算法恰当的把新的EPC对象和剩下的EPC连接起来并用通用的方法写入。值得注意的是,虽然在这个例子说明使用了一个特定的模型变换(EPC-2-BPMN)和使用方案,本文在此描述的技术是适用于任何种模型-2-模型转换,该种具有选择性往返方案应该受到支持。
[0117] 本发明的发明人已经意识到从一个转换合成模型(例如,以上示例的场景中的BPMN模型)到转换的源模型(例如,以上示例的场景中的EPC)的传送变化的问题,可以被理解为是合成模型的某些领域中的一个转换(例如,以上示例中epc-2-BPMN)的基本选择和部分倒装。以下讨论使用术语“EPC模型”和“源模型”(或“BPMN模型”和“目标模型”),便于参考。然而,将理解到其他建模语言可以用于源模型和或目标模型。将理解到一般的概念并不局限于这些特定的两个模型类型,甚至在业务流程建模领域。它也不必要这其中的一个模型代表一个“业务”和/或另一个“技术”视图的问题上来。自许多不同领域其他对模型类型可能出现。例如,一方面它可能有一个UML类图模型表示一个应用程序的数据结构,另一方面实体关系图表示一个用于存储应用程序数据的数据库模式的高级视图。取代转换EPC到BPMN模型,该流程有可能使用其他更专业的表述来表示流程,像针对于某个工作流管理系统的BPEL语言或各种各样的技术过程描述语言。另一个例子实施例是数据流,也可能有用,因为它已经完成,例如,所谓的ETL(提取-转换-装载)工具。在这里,用户可以使用一个常用图解和ETL工具特定语言来模拟一个数据库是如何从操作数据源加载数据。一个活跃的研究领域是描述这些数据流的常见语言的发展。再采用MDA范式到另一个域,这样的一个常见的数据流语言然后再被转换为不同的特定工具的语言,增加可移植性和减少供应商定的机会。这样一个常见的数据流语言的一个例子是运算符中心(operator-hub)模型,可以被转换成多种ETL语言(例如,IBM的InfoSphere DataStage,甲骨文的Warehouse Builder等等),或者甚至是等价的SQL DDL表达。考虑到文本语言,像SQL DDL作为一种“模式”是不明显的。然而,这样的文本语法的只是一个具体的语法概念,语言的底层概念(即,抽象语法或元模型)。你可以想象一个文本语法的图形表示法,比如,一个结构类似于抽象语法树。
[0118] 它也并不总是有必要更进一步由一个声明式模型转换创造出另一个模型。例如,它可能是从其他的使用标准,强制代码创建出一个模型。你可以想象这两个模型可以被手动构建和/或并行。基本上,对实例的任何一双模型类型,最初是通过一些手段而同步的,同步应该保持协调,在这方面是由于得利于本示例技术披露,只要有清晰的(但不一定是明确的)规则(这些实际执行的是否与我们的声明式模型转换,编程,或只有非正式的最佳实践一样),指定如何从一个模型的元素将其转化为其他的或者返回。
[0119] 虽然它可能乍一看似乎相对简单,取出图2到图4中简化了的模式,简单地交换源模式和目标模式的角色,并把它们应用在新的或变更的BPMN对象进行传送,这种方法通常是不可能的,因为许多个人模式和转换作为一个整体在一般——在数学术语——不是一个双射映像,在源模型类型(在此示例中的所有可能的EPC模型)和域目标模型的类型之间(在此示例中的所有可能的BPMN模型)。例如,许多EPC模型元素在BPMN没有直接的对应元素,因此不能转换的。其他EPC模型元素被有意识地从EPC-2-BPMN转换中忽视了,因为他们模拟的业务流程方面,被发现是与该过程无关的技术视角。进一步的,不同的EPC模型可以导出等价的BPMN模型(例如,如果他们只在没有转换的方面不同),如果他们涉及映射操作符,在示例模式中许多映射是不可逆的。例如,即使是一个普通的操作就像两个字符串串联在一般是不能恢复的。
[0120] 因为这些限制条件,为用户提供一个完全通用的方法来提供半自动支持执行变化传送并不认为可能的。特定的示例实施例因此提供一个现有的模型转换框架的扩展,允许明确定义的CPAS进行简单的创建和注册。这些操作可以被看作是提供的转换的定义的一个重要部分。一般来说,每个CPA直接对应于一个转换模式(或少量的模式)。例如,CPAs可以提供传送文摘任务,手动任务,或服务任务,这直接分别对应于示例图案图2-图4。其他BPMN元素也可以被传送包括,例如各种各样的网关,以及开始、结束和中间事件。要么在交互式合并(例如,作为解决合并冲突的部分),或冲突已经得到解决,用户可能有机会申请关于该冲突模式(或完全合并模型)元素的CPAs,已经添加、修改或在BPMN中删除的。
[0121] 为了简化下面的例子的讨论和表示,提出了一个演示场景,用户利用该演示场景首先解决在冲突模型中的所有冲突TC,然后开始合并模型TM传送。然而,正如上文所说,其他场景也是有可能的,例如,用户在交互式合并操作过程中解决融合冲突。
[0122] 一般来说,CPAs可以区分为三类基层分类单元。第一类允许目标模型元素的传送,被添加到新目标模型。这些CPAs可以认为是新元素的CPAs(NCPAs)。第二个类别元素的处理修改已经有一个相应的元素在EPC。这些CPAs可以认为是被重新定义的CPAs(RCPAs)。第三类允许用户在目标模型中传送元素的删除。这些CPAs可以被认为是被删除的CPAs(DCPAs)。
[0123] CPAs可以划分为不同的阶段,图15显示了根据示例实施例的NCPAs和RCPAs的示例的阶段。在图15可以看到,一些示例的阶段只与RCPAs有关,一些阶段在NCPAs和RCPAs之间存在差异。这些阶段将在后面进行更详细的讨论。
[0124] 一个CPA的可行性检查在某些案例实施例中可能包括多个组件。首先,并不是所有的CPAs注册需要提供给用户的任何目标模型对象。然而,一组注册的CAPs可能被过滤掉,只有那些对于一个给定的添加、修改或删除目标模型元素“有意义的”才对它有用。例如,该工具在做一个服务任务时可能不显示一个CPA,意味着手工任务传送。因此,在某些案例实施例中将理解可行性检查可能包括过滤组件。
[0125] 第二,某些案例实施例的可行性检查可能防止CPAs的再申请,例如,这样CPA就无法使用,除非在已经存在的源模型中可以创建CPA。这可能有助于减少用同一元素意外再申请注册CPA的可能性(如果不恰当地考虑,有时会导致在源模型不恰当的或不期望的元素重复)。在目标模型中它还可以用于防止CPAs使这些模型元素继续下去,这些目标模型由转化所创建,后来没有进行修正。这些示例可以被称作再运用预防。例如,在图8案例中的抽象任务F1。这个元素由EPC函数F1经过转换所创建,并没有利用BPMN模型进行修改。因此,一个用于抽象任务传送的CPA不会提供这样一个元素。
[0126] 在特定的示例实施例中,一个CPA的可行性检查可能包括一致性检查/冲突预防。这个示例可能涉及检查在源模型和目标模型中传送是否将创造一个不一致的情况。再引用一次图12的例子,但假定替代将抽象任务改善为服务任务,用户已经将通过由于与组织单元连接的EPC函数的变换创建的人工任务改变为服务任务,如图16所示。如果一个“服务任务”传送是允许的,这将产生一个EPC的函数,这些功能将连接到一个组织单元和一个业务服务。正如上面所讨论的,在这样一个冲突情况,EPC-2-BPMN转换将创建一个人工任务,而不是一个服务任务。传送将因此不能成功,导致了一个合并冲突,如图16所示。
[0127] 在特定的示例实施例中,可行性检查可以分为不同的级别。第一个示例级别可能只执行再运用预防和上面所讨论的过滤。任何CPA,通过这个检查会给予一个对象,然后被显示为用户可用的,由用户界面通过一定的方式进行处理。这种方式,它只能显示CPAs,用户期望通过一个合理的理解EPC元素是如何映射到BPMN(反之亦然)。同时,这种方法可以帮助减少意外或故意再申请CPA的可能性。
[0128] 第二个例子可行性检查可能执行额外一致性检查。没有通过检查的CPA不可能简单地对用户隐藏,而是可以提供一个原因列表,可以向用户反馈(例如,文本消息和/或图形化的迹象),通知用户是什么其他的“合理的”原因导致CPA不能应用于给定的情况。
[0129] 该方法可以帮助提供改进的用户体验,例如,与简单地使用户不明白为什么期望可用的CPA根本不能显示的情形相比。
[0130] 此外,在某些案例实施例中,而不是防止CPA的应用,一致性检查中发现的问题可以作为警告,不阻碍执行CPA而是通知用户可能的问题。报告的问题可以交互式地提供给用户,在一个可选的校正阶段这些问题可能要经过迭代纠正措施(更详细地描述如下)。
[0131] 现在将提供“抽象任务”,“服务任务”和“人工任务”如何启用检查的例子,例如,使用自然语言提供可能会检查条件的说明性的描述。如果一个条件的结果为真,接下来的条件将会检查;否则,检查将被认为失败了。在接下来描述的例子中,“B”指的是CPA企图实现检查的对象。
[0132] 应用于EPC的抽象任务传送的CPA在图10示例场景中时有用的,10例情况。下面的伪代码是抽象任务的一个示例:
[0133] 一级检测:
[0134] a)过滤
[0135] ●B的标志是抽象任务吗?
[0136] ●将B放到“缺省道”?
[0137] b)再申请阻止:
[0138] ●B在EPC中有对应的函数E吗?
[0139] 2)级别2检测:冲突阻止[这个例子省略]
[0140] 在图8中,过滤和再申请预防检查将适用于“在BPMN中补充的F2。“因此,CPA有效的显示给用户。更进一步,由于冲突预防检查对CPA来说是空的,因此它可以被应用。
[0141] 第二个示例传送与服务任务中任何一个BPMN任务的改善传送有关,如图12所示。下面的伪代码可能被用于一个“服务任务”RCPA的可行性检查。
[0142] 1)一级检查:
[0143] a)过滤
[0144] ●是B”服务任务”的符号?
[0145] b)重新申请阻止
[0146] ●B在EPC中有对应的函数E吗?
[0147] ●E还没有与业务服务对象相关联吗?
[0148] 2)2级检查:冲突预防
[0149] ●B被放置于缺省道吗?
[0150] ●B具有类型“函数分配图表”的分配A吗?
[0151] ●模型A包含一个相同对象定义B的事件F吗?它使用了函数符号吗?[0152] ●在模型A中,是否存在以连接类型“支持”与F连接的软件服务操作类型符号?[0153] ●在模型A中,是否存在以连接类型“支持”与F连接的软件服务型符号?[0154] ●E已经与一个组织单元相关联了吗?
[0155] 将理解到关于分配B的更正内容的大量详细检查和道更换可能会被纳入级别2检查。这样,即使程序工程师有一些建模“错误”,服务任务传送也是可以使用的,它就可以返回消息,如果级别2检查任何失误,通知用户如何纠正该问题。根据UI的细节,例如,这种反馈可以提供文本消息,有问题的对象信息和/或像是有问题的对象信息会用高亮度形式标出。
[0156] 在图12的示例传送场景中,对于前面的抽象任务F1,前抽象任务F1被改善成一个服务任务,CPA可以通过所有的1级和2级检查,而且可以在这种情形下应用。
[0157] 可行性检查的第三个例子考虑到了新增添的人工任务的传送。基于图3中“具有组织单元的函数到人工任务的”转换规则,对这样的传送可行性检查可能包括以下示例条件:
[0158] 1)1级检测:
[0159] a)过滤
[0160] ●是B人工任务的符号吗?
[0161] b)重新申请预防
[0162] ●B在EPC中已经不具有一个相对应的函数E吗?
[0163] 2)级别2检查:冲突预防
[0164] ●B有一个“函数分配图标”(FAD)类型的任务A吗?
[0165] ●A模型包含一个相同对象定义B的一个事件F吗,它使用函数符号吗?[0166] 在模型A中,是否存在一个组织单位对象OU以连接类型“通过执行”与F连接?[0167] B存入了一个对应的源侧对象是以OU为基础的相同定义下的事件的道吗?[0168] 利用之前的服务任务传送,在目标模型的2级检测中,,可能执行更详细的局势分析,例如,能够给用户提供文本、图形、和/或其他反馈,告诉他们为什么传送不能应用。
[0169] 像上面提到的,在某些案例实施例中CPA可以创建新资源或修改已经存在的源模型元素(s)。例如,每个CPA可以被视为一个倒转的转换模式。在这一点上,这些针对于CPA的源模型转换的细节被覆盖了。然而,一般能够被处理的阶段在下面讨论。
[0170] 关于用于“抽象任务”NCPA的源模型的修改,可能提供关于以上讨论的示例的抽象任务CPA的例子。这个例子通过可行性检查。图17继续图8留下的例子。为了图17的例子的目的,假设用户解决了冲突模型TC中的所有冲突(通过接受包含F0的“在源中替换”冲突和包含“在BPMN中增加的F2”的“在目标中替换的冲突”),形成成功合并的TM。然后用户决定已经被流程工程师增加的“在BPMN中增加的F2”与该流程的业务视图相关。已经通过了它的可行性检查,用户现在可以在这个对象上应用抽象任务改变传送动作CPA。结果,具有与这个任务相同名字的新的函数被创建并被放置在源模型中。将理解到这个新的函数还没有与EPC模型的其余部分连接。
[0171] 图18显示根据特定的示例实施例,当它们将被服务任务(被重新定义的改变传送动作)RCPA执行时,源模型的修改。如上所示,F1通过用于服务任务RCPA的可行性检查。在解决所述冲突后,所以用户可以应用它,引起EPC中新的业务服务事件的创建,其直接与已经存在的EPC函数F1连接。将理解到与上述例子相比,在新创建的元素和EPC的剩余部分之间的连接已经是这个流程的一部分,因为这个连接是“具有业务服务的函数到服务任务”模式的源模式的一部分,并且不是所述流程控制流的一般的再创建的一部分。此外,图
18中显示的分配的模型被创建,其对应于通过“从具有业务服务的函数到服务任务”模式匹配的结构。如图18所示,放置在这些分配中的所述软件服务类型和软件服务操作类型对象是用于在目标模型上的F1上的分配中的相同的对象定义的事件。
[0172] 如上所讨论的,也可能期望有时从技术级别到业务级别传送删除操作。此处,源模型修改可能包括仅仅删除在技术级别上对应于被删除的元素的元素。
[0173] 在实践中对人工改变传送设置的挑战的一方面是人工改变传送不是总能适当地更新目标模型元素的内部转换追踪信息。然而,在特定的示例实施例中,追踪信息的更新可能被执行作为应用一个改变传送动作的第三步。一旦各自的源模型元素已经被创建或更新,可能将目标模型元素设定为引用这些元素作为它们的源对象,例如,如图19所示,这个方法允许基于同一性的合并承继。创建的传送的目标模型元素的模式列表可能被进一步更新为包括各自的CPA对应的模式。除了用于时间存在的连接,可能在源模型和目标模型中获得一个状态,其正好应该由结构的转换创建。
[0174] 特定的示例实施例涉及源模型和目标模型中的建模错误和冲突的改正。与用CPA改变传送相关的挑战是为了传送的对象的合并适当地工作,通过在目标模型中人工编辑创建的情形(例如模型元素的增加或完善)应当是精确的,因为它后来将通过传送的元素的转换创建。在上述讨论的可行性检查中,假定这样的可行性检查将详细地检验以确保所有的条件都符合。但是,如果以这样严格的方式进行,多个CPA可能使它们的级别1或级别2的可行性检查失败,并且因此是不可用的或仅部分可用的,例如,在用户分别做出人工改正通过级别2检验报告的情形的传送之后。
[0175] 与特定的示例实施例相关的可用的替换方法包括允许CPA不仅仅修改源模型和更新追踪信息,还改正已经在目标模型中做出的次要的建模“错误”,其将阻止或降低成功合并的可能性。举例来说,再次考虑NCPA作为新增加的人工任务,其可行性检查已经在上文讨论。如果符号具有正确的类型,分配的模型存在并且具有正确的内容,并且任务已经被放置在可以应用CPA的组织单元的对应的道。
[0176] 但是,假定现在流程工程师忘了创建如图20的左部显示的分配(或内部的一些内容)或创建分配,但如相同的图的右部所示,意外地将新的人工任务放进缺省道,而不是将其放进用于组织单元的已经存在的道。如果可行性检查将仍允许人工任务CPA在这些情形的任一情形被执行,根据后来的合并操作的冲突将产生。
[0177] 代替不允许改变传送并只传递对应的错误消息,CPA将容易执行在两种情形下需要的改正动作,因为在这个例子中,用户的目的是清楚和明确的。也就是说,在这个例子中,将人工任务放置到非缺省道中或在分配中改正组织单元对象使得清楚谁(例如,哪个组织单元)执行该任务。如图20的底部所示,因此错误的道放置可以被改正,丢失的分配模型可以容易被创建等。
[0178] 在特定的示例实施例中,如果在BPMN模型中的建模问题不能自动地和/或以单一型式解决,改正动作也可以以交互型式进行。比如,如果用户在人工任务的分配中已经使用一个组织单元OU1,但将用于另一个组织单元OU2的人工任务放置在道中,在特定的情况下,改正动作可能促进用户输入关于怎样改正这个问题。
[0179] 在目前讨论的示例的CPA步骤中,在新创建的源模型元素和模型的其余元素之间的连接被已经创建,如果那些连接是CPA的对应转换规则的源模式的一个明确的部分。例如,其它的连接,例如那些表示EPC和BPMN流程等的控制流连接,目前还没有被处理。此外,在以上讨论的例子中,情形包括需要被传送的单一的在目标中增加的对象,或将改变传送到已经在源模型中存在的对象。因此,在上述例子中,附加的连接操作是不重要的或完全不需要的。
[0180] 但是,比起简单地处理被增加到目标模型的单一对象,当处理被增加到目标模型的整组对象时,传送的元素的连接变得更有挑战。如图21的例子所示。此处,用户不是增加一个对象,而是增加连接对象的整个结构(即,抽象任务“F1.1AIT”、网关“XOR AIT”、抽象任务“F1.2AIT”,加上这些元素相互之间的多个连接,并加到模型的余数)。当用户以任意的顺序单独传送这些新的目标模型元素时,特定的示例实施方式涉及适当地连接将被创建的新的源模型元素的算法。
[0181] 在特定的示例实施方式中,不管其中用户执行传送的序列(或在目标中增加的元素被有意识地选择不被传送),最后生成的源模型结构可能是相同的并正确反映目标模型中的连接结构。当执行改变传送动作CPA步骤冲突解决后,而在冲突解决过程中,特定示例实施例的连接算法可能进一步帮助确保从改变传送动作CPA产生的源和冲突模型状态本身是一致的,例如,目标模型的状态(例如在传送后)表现为源模型的当前的状态,仿佛它已经被转换并被合并。
[0182] 现在将提供一种用于在目标中添加的对象的示例连接算法。在以下的描述中,为了简便,源模型被称为src,并且目标模型被称为tgt。为了简便,将被传送的目标模型对象tgt src被称为o ,并且通过传送的步骤2创建的相应的源模型元素被称为o 。一般的连接算法进行如下:
[0183] 1.查找otgt的目标侧边界元素
[0184] a.查找开始于otgt的出站直接路径并只跟随在目标中增加的连接(例如,这些路径在没有在目标中增加的第一对象结束,例如,在源模型中具有相应的元素)。直接的路径是连接的任何序列,“在相同的方向的点和所有点”。这样的路径的长度是它的连接的数量,out out out由长度(路径)给出。这些路径的集合现在可以被称为path ={path 1,…,path n},并tgt tgt tgt tgt
且它们的结束对象的多重集可以被称为succ ={s 1,…,s n},作为o 的目标模型后继。
注意到通过使用用于路径的结束(或开始)节点的多重集,可能后来处理沿着多个路径分别对于每个路径到达的那些节点。当然,将理解在这些路径中的周期是不跟随的(例如,在一个路径中没有连接被使用两次)。
[0185] b.查找所有开始于otgt的进站直接路径并只跟随在目标中增加的连接(在相反的in in in方向)。这些路径的集合可能被称为path ={path 1,…,path m},并且它们的开始对象的tgt tgt tgt tgt
多重集可能被称为pred ={p 1,…,p n},作为o 的目标模型前驱。
[0186] c.用于otgt的集合的目标模型前驱和后继的并集succtgt∪predtgt=bordertgt可能被称为目标模型边界对象。
[0187] 2.使用追踪信息查找与所述目标模型前驱predsrc={psrc1,…,psrcn}和后继src src srcsucc ={s 1,…,s n}对应的源侧元素。
[0188] 3.可选择的:如果CPA在冲突解决过程中被执行:对于具有ptgti∈predtgt和tgt tgt tgt tgt tgt tgt tgt tgt tgts k∈succ 的每个对(p i,s k),存在从p i到s k的连接cxn (或从s k到p i),src src src src
其合并状态被增加在源模型中,在源模型中从p i到s k(或从s k到p i)删除该连接tgt tgt src
cxn 并删除cxn 对应的源模型中的连接cxn 。
[0189] 4.如果CPA在冲突解决过程中被执行,对于每个psrci∈predsrc(each src srcs k∈succ ):
[0190] a.在源模型中创建从psrci到osrc的(从osrc到ssrck)的连接。
[0191] b.如果路径pathini的长度length(pathini)(pathoutk length(pathoutk))对应于src srcp i(s k)是1:
[0192] 移除目标模型中的该路径的单一连接的在目标模型中增加的合并状态,[0193] 否则:
[0194] 在所述目标模型中创建从ptgti到otgt(或从otgt到stgtk)的连接并将其合并状态设定为在源模型中增加。
[0195] 将理解到可选择的步骤3有效地移除已经在目标模型中移除的连接(并且其通过转换和合并被重新增加并因此具有在源模型中增加的合并状态)并用连接的在目标中增加的对象的结构替换。对于连接前驱和后继对象的更复杂的在源中增加的结构,是否保留它们的决定可能留给用户。
[0196] 图22A-22B延续图21的例子。在这个例子中,传送的第一个元素是抽象任务“在tgt src tgt目标中增加的F1.1”=o 。在源模型中创建一个类似命名的函数o ,并且将在o 的追踪src
信息向o 更新(步骤2和3)后,可能应用连接算法。在这个示例例子中,连接算法运行如下:
[0197] 1.查找otgt=F1.1AIT的目标侧边缘元素
[0198] a.出站直接路径:pathout={pathout1=F1.1AIT→XOR AIT→F1.2AIT→F2,pathout2=F1.1AIT→XOR AIT→XOR}
[0199] →后继元素:succtgt={F2tgt,XORtgt}
[0200] b.进站直接路径:pathin={pathin1=F1.1AIT←F1a}
[0201] →前驱元素:predtgt={F1atgt}
[0202] 2.查找源侧边界元素:
[0203] succsrc={F2src,XORsrc}
[0204] predsrc={F1asrc}
[0205] 3.删除在源模型和目标模型中的前驱和后继之间的在源中增加的连接:删除EPC和BPMN中的连接F1a→F2
[0206] 4.创建/保持用于在源模型和目标模型中的路径的连接:
[0207] pathout1:在EPC和BPMN中创建连接F1.1AIT→F2,在BPMN中标记为在源中增加[0208] pathout2:在EPC和BPMN中创建连接F1.1AIT→XOR,在BPMN中标记为在源中增加[0209] pathin1:在EPC中创建连接F1a→F1.1AIT,从BPMN中现有的连接移除在目标中增加的标记
[0210] 如图22A-22B所示,源模型S’和冲突模型TC’被获得作为一个结果。从图22A-22B可看出,如果“F1.1AIT”总是源模型S’的一部分,如果只有F1.2AIT和XOR AIT被增加到目标模型,并且如果合并然后被执行,TC’在将会获得的确定的状态。
[0211] 作为下一个步骤,“抽象任务”传送在在目标中增加的抽象任务“F1.2AIT”上被执tgt src行(o =“F1.2AIT”),其引起源EPC中的函数o 的创建。示例的连接算法被再次应用以将该函数与模型的剩余连接:
[0212] 1.查找otgt=F1.2AIT的目标侧边界元素
[0213] a.出站直接路径:pathout={pathout1=F1.2AIT→F2}
[0214] →后继元素:succtgt={F2tgt}
[0215] b.进站直接路径:pathin={pathin1=F1.2AIT←XORAIT←F1.1AIT}
[0216] →前驱元素:predtgt={F1.1AITtgt}
[0217] 2.查找源侧边界元素:
[0218] succsrc={F2src}
[0219] predsrc={F1.1AITsrc}
[0220] 3.删除在源模型和目标模型中的前驱和后继之间的在源中增加的连接:
[0221] 删除EPC和BPMN中的连接F1.1AIT→F2
[0222] 4.创建/保持用于在源模型和目标模型中的路径的连接:
[0223] pathout1:在EPC中创建连接F1.2AIT→F2,从BPMN中的现有的连接移除在目标中增加的标记
[0224] pathin1:在EPC和BPMN中创建连接F1.1AIT→F1.2AIT,在BPMN中标记为在源中增加
[0225] 在图22A-22B中,该传送的结果被显示为源模型S”和冲突模型TC”。再次,S”和TC”处于这样的状态,好似初始信息已经用S”完成,用户只增加XOR AIT(和它附带的连接)到BPMN模型,然后执行该合并。
[0226] 网关“XORAIT”=osrc现在准备被传送。再次,步骤2和3创建对应的源模型对象tgt(一个EPC XOR网关=o )并且相应地设定追踪信息。所示连接算法再次被应用:
[0227] 1.查找otgt=XORAIT的目标侧边界元素
[0228] a.出站直接路径:pathout={pathout1=XORAIT→F1.2AI T,pathout2=XOR AIT→XOR}[0229] →后继元素:succtgt={F1.2AITtgt,XORtgt}
[0230] b.进站直接路径:pathin={pathin1=XORAIT←F1.1AIT}
[0231] →前驱元素:predtgt={F1.1AITtgt}
[0232] 2.查找源侧边界元素:
[0233] succsrc={F1.2AITsrc,XORsrc}
[0234] predsrc={F1.1AITsrc}
[0235] 3.删除在源模型和目标模型中的前驱和后继之间的在源中增加的连接:
[0236] 删除EPC和BPMN中的连接F1.1AIT→F2
[0237] 删除EPC和BPMN中的连接F1.1AIT→XOR
[0238] 4.创建/保持用于在源模型和目标模型中的路径的连接:
[0239] pathout1:在EPC中创建连接XORAIT→F1.2AIT,从BPMN中现有的连接移除在目标中增加的标记
[0240] pathout2:在EPC中创建连接XORAIT→XOR,从BPMN中现有的连接移除在目标中增加的标记
[0241] pathin1:在EPC中创建连接F1.1AIT→XORAIT,从BPMN中现有的连接移除在目标中增加的标记
[0242] 因此,获得完全解决的目标BPMN模型TC”’=TM,其中在目标中增加的所有的对象被成功传送到源EPC模型。
[0243] 现在提供表明特定的示例实施例的选择性的改变传送概念,以下的讨论提供该概念的一些通用的方面的说明实施例。因为可行性检查、源模型修改,和可选择的改正步骤有时可能对各个CPA是特定的,以下的讨论集中在特定的示例实施例的方法的更通用的方面,比如,连接算法。
[0244] 特定的示例实施例的通用的连接算法现在将以简化的、类似Java的伪代码语法解释。通过以下的伪代码片段,简化的对象模型被用于表示模型、对象和连接。也提供辅助函数的选择。其中这些辅助函数的语义不显然来自于它们的命名,在以下的片段中它们被非正式地解释。为了这些示例代码片段的目的,也假设原数据类型(例如,布尔、整数、字符串等)和抽象数据类型的数目(例如,列表、集合、映射、迭代器等)的典型集合可能被访问并用通常的(并且是自解释的)技术修改。为了清楚,从这些示例片段省略了如错误处理的方面,虽然特定的示例实施例可能确实包含遍及多个函数的错误处理。
[0245] 现在将提供用于模型和模型元素的示例的简单对象结构:
[0246] MergeState是一个单独的模型元素可以具有的所有可能的合并状态的一个列举。在这个例子中,提供值ADDED_IN_SRC(在示例附图中图示地用绿色加号表示)、DEL_IN_SRC(图示地用红色减号表示)和ADDED_IN_TGT(图示地用蓝色加号表示)。如果一个基本的合并方法传递附加的合并状态(例如,如果它能够将在转换模型中增加元素从在目标模型中删除它区分),在这个列举中,可能有附加的值。
[0247] 一个Element是模型Obj和连接(Cxn)共同的抽象超类。它可能包括以下方法:
[0248] MergeState getMergeState():如果有的话,返回元素Element的合并状态MergeState,否则为空null。
[0249] Boolean hasMergeState():如果元素有合并状态,返回真true,否则为假false。
[0250] ListgetNeighbors():返回这个元素Element相邻的多个元素Element的列表。如果该元素Element是一个连接Cxn,这个列表将保持连接Cxn的源和目标对象Obj(以任意的但是固定的顺序)。如果该元素Element是一个对象Obj,该列表将是该对象Obj的进站和出站连接Cxn的并集(以任意的但是固定的顺序)。
[0251] void delete():从所述模型移除该元素并断开与它的相邻元素的连接。
[0252] Obj是用于表示所有种类的模型对象的类(例如,在模型中的“节点”)。它的超类是元素Element。除从元素Element方法承继的方法外,还可能包括以下方法:
[0253] ListgetInboundCxns():返回将该对象Obj作为它们的目标对象的多个连接Cxn的列表。
[0254] ListgetOutboundCxns():返回将该对象Obj作为它们的源对象的多个连接Cxn的列表。
[0255] 连接Cxn是用于表示模型对象之间的关系的类。它的超类是元素Element。除从元素Element承继的方法外,它还可能包括以下方法:
[0256] Obj getSource():返回连接的源对象或起源。
[0257] Obj getTarget():返回连接的目标对象或终点。
[0258] 模型Model是对象的容器(并且间接上也用于模型中的对象之间的连接)。它可能包括以下方法:
[0259] ListgetAllModelObjs():返回模型中的所有对象(类型Obj)的可修改的列表。
[0260] ListgetAllModelElems():返回模型中的所有模型元素(类型Element)的列表,例如,当它们通过getAllModelObjs返回时为所有的对象Obj和这些对象Obj之间的所有连接Cxn。
[0261] ●路径Path是表示通过一个模型的路径(不需要是直接的)的类(例如,元素的一个序列,其中路径的每个2*i+1th(i=0,1,…n)元素是一个对象Obj并且其中每2*ith个元素是一个连接cxn,其源和目标对象(如果沿着相反方向的连接导航,则分别或者为目标和源)是在位置2*i-1和2*i+1的对象,其中相邻的连接共享一个共同的节点)。它可能包括以下方法:
[0262] Path(Obj startNode):具有长度为0的新路径的构造函数,在给定的开始节点startNode开始和结束。
[0263] Obj getFirst():返回路径的开始节点。
[0264] Obj getLast():返回路径的结束节点。
[0265] int length():返回路径中的连接的数量。如果getFirst()==getLast(),该路径的长度为0。
[0266] Iteratoriterator():返回将检查路径中的所有元素的迭代器,开始于开始节点并结束于结束节点。返回的第一个和每个奇数元素将是对象Obj,每个偶数元素将是连接Cxn。
[0267] append(Cxn cxn):添加给定的连接到路径。如果在调用append()之前,getLast()==cxn.getSource(),它将增加cxn.getTarget()到路径并使它为新的最后的元素,如果在调用append()之前,getLast()==cxn.getTarget(),此外,它将增加cxn.getTarget()到路径并使它为新的最后的元素,否则对添加的调用将出现例外。
[0268] prepend(Cxn cxn):把给定的连接放在路径的前面。如果在调用append()之前,getFirst()==cxn.getSource(),然后将把cxn.getTarget()放在路径的前面并且该方式使得它为新的第一元素,如果在调用append()之前,getFirst()==cxn.getTarget(),将把cxn.getSource()放在路径的前面并使得它为新的第一元素,否则调用前置将出现例外。
[0269] boolean contains(Element e):如果给定的元素e已经是路径的部分,返回真。
[0270] 在特定的示例实施例中,可能提供以下和/或其它辅助方法:
[0271] Boolean isRelevantCxn(Element e):如果给定的元素Element e具有类型连接Cxn并且其与路径的考虑相关,返回真。比如,从一个对象到它包含的对象的连接(例如从任务到它包含的道)与路径的部分的考虑不相关。
[0272] Obj getCorrespondingSourceObj(Obj targetObj):返回给定的合并模型对象Obj,它的“主要的”对应的源模型对象。
[0273] Element getCorrespondingSourceModelElement(ElementtargetModelElement):返回给定的目标模型元素targetModelElement,主要的对应的源模型元素。内部地,该方法可能使用我们上述讨论的转换追踪信息。
[0274] 现在将提供示例的伪代码查找进站和出站直接路径和边界对象。为了从在目标中增加的对象到不在目标中增加的对象Obj获取所有的直接路径,可单独沿在目标中增加的连接获取,可能使用以下的示例getBorderPaths方法。示例的方法接收(在目标中增加的)对象,在其上路径搜索开始作为第一个参数start。如果第二布尔boolean参数进站inbound被设定为真true,该方法将返回所有入站路径,否则为所有出站路径。
[0275]
[0276]
[0277] 该方法可能通过将仅保持开始节点(例如,应该被传送的对象)的长度为0的路径推入堆栈的顶部来进行。然后从所述堆栈一条路径在其它路径之后被取出,检查是否路径总是在边界节点(例如,具有对应的对象并且因此不在目标中增加的节点)结束。如果所述路径到达一个结束节点,所述路径被增加到结果路径的列表并不再进一步被考虑。否则,源于路径上的当前最后的元素的(入站或出站的,取决于入站inbound参数的设定)连接被用于创建多个新的路径,所述新的路径被增加到堆栈。通过检查是否通过这样的连接达到的节点总是路径的部分,不考虑循环路径。虽然这个例子用堆栈实施代码,其它的示例实施例可能用队列或诸如此类的实施相同或相似的函数。
[0278] 用入站路径和到边界对象的路径,在合并的模型中识别对应的前驱和后继对象可能被任务是不重要的任务,如以下例子所显示的getTargetModelSuccessors和getTargetModelPredecessors方法:
[0279]
[0280]
[0281] 为了获得对应于后继和前驱合并模型对象的源模型对象,可能分别在所有目标模型前驱或后继上应用getCorrespondingSourceModelElement辅助方法,例如,使用以下的伪代码片段:
[0282]
[0283] 在总体算法的特定示例实施例中,源模型边界对象在算法的其它步骤中(例如,并且从而不总是作为整体)被识别;因此,该方法不需要必须被包括。
[0284] 以下的示例伪代码可能被用于删除边界生成的连接的可选的步骤。比如,如果CPA在冲突解决时期被执行(例如,如果不是所有的冲突都已经被解决),可能使用以下的findBorderSpanningCxns方法查找所有在源模型中(重新)增加的连接,其直接连接传送的对象的后继和它的前驱中的一个(反之亦然):
[0285]
[0286] 对于通过该方法识别的每个连接cxntgt,对应的源模型连接cxnsrc被识别并且cxntgt和cxnsrc被删除,例如,使用以下的伪代码:
[0287]
[0288]
[0289] 这样,在特定的示例实施例中,可能移除已经用在目标中增加的结构替换的简单的连接。
[0290] 为了为每个路径创建在源模型和目标模型中的连接(或从现有的目标模型连接移除合并状态),以下的示例伪代码可能被使用:
[0291]
[0292]
[0293] 为了执行传送的在目标中增加的对象propagatedObj的完全重连接,以上描述的和/或以上讨论的其它方法可能被组合为以下示例的reconnectPropagatedObject方法:
[0294]
[0295] 将理解到在特定的示例实施例中的变换模式或规则可能对应用于从第二模型创建第一模型的指令,所述指令是示例模式、人工转换步骤、硬编码命令规则(imperative)和/或诸如此类的任何适当的组合。
[0296] 虽然特定的示例实施例已经描述为包含与抽象任务、人工任务和服务任务相关的增加、修改和/或删除,此处示例的技术可能应用于任何BPMN元素。比如,该列表可能包括任务元素,比如抽象任务、业务规则任务、人工任务、接收任务、脚本任务、服务任务、用户任务等。也可能包括比如开始、中间和/或结束事件元素的事件元素(例如,被获取和/或被丢弃的传统的开始事件、消息开始事件、部分多个开始事件、信号开始事件、定时器开始事件、中间事件、补充中间事件、条件中间事件、增加中间事件、链接中间事件、消息中间事件、多个中间事件、平行多个中间事件、信号中间事件,结束事件、补充结束事件、错误结束事件、增加事件、消息结束事件、多个结束事件、信号结束事件、终止结束事件和/或类似的)。这个列表可能也包括网关元素(比如,网关、复杂网关、基于事件的网关、排他型网关、包容型网关、示例的基于事件的网关、示例的平行基于事件的网关、平行网关,和/或类似的)。将理解到其它的对应的或不对应的元素可能被用于与包含非BPMN模型的示例实施例相关。
[0297] 将理解到如这里所使用的术语系统、子系统、服务、变成逻辑电路、和类似的可能作为软件、硬件固件和/或类似的任何合适的组合被执行。也将理解到这里的存储位置可能是磁盘驱动设备、存储位置、固态驱动器、CD-ROM、DVD、磁带备份、存储区域网(SAN)系统和/或任何其他合适的可触计算机可读存储介质。也将理解这里描述的技术可能通过使得至少一个处理器执行可能实体存储在非暂态计算机可读存储介质上的指令而完成。
[0298] 虽然本发明已经被描述为与在当前被认为最实用和较优的实施例相关,要理解本发明不限于公开的实施例,而相反,意在覆盖包含在附加的权利要求的精神实质和范围内的多种修改和同等设置。
高效检索全球专利

专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台,是提供专利分析,专利查询,专利检索等数据服务功能的知识产权数据服务商。

我们的产品包含105个国家的1.26亿组数据,免费查、免费专利分析。

申请试用

分析报告

专利汇分析报告产品可以对行业情报数据进行梳理分析,涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度,系统通过AI智能系统对图表进行解读,只需1分钟,一键生成行业专利分析报告。

申请试用

QQ群二维码
意见反馈