In this integration scenario, two different workflow languages are investigated and related to each other.
Both languages are similar but some concepts are explicit in one language and implicit in the other.
The main interesting aspect of the example is that both models are graphs with a recursive structure.
In the diagram below, a (simplified) BPMN model is shown in abstract syntax (as a typed graph) to the left with a corresponding (also simplified) use case flow model to the right.
BPMN flows consist basically of Tasks connected with SequenceFlow elements. A diverging ParallelGateway is used to split a sequential flow into multiple "threads", which are explicitly synchronized back together with a converging ParallelGateway.
Use case flows are a bit more compact. NormalSteps correspond to SequenceFlow + Task combinations (indicated with the black rectangles and dashed arrows in the diagram), and certain things are a bit more implicit. There is for example no element explicitly synchronising parallel flows (they just end and wait for the slowest thread).
Another difference is that the use case flow model has a "container" for each flow segment. In the example the BasicFlow element is the container for the main thread, while new ParallelFlow containers are "invoked" to contain the parallel threads resulting from the main thread. This containment is indicated with red dashed rectangles in the diagram.
Note that there can be arbitrary parallel flows in both models (so not necessarily binary as in the example), and that the flow structure is recursive (so there can be arbitrary levels of splitting and synchronization).
Consistency is relatively straightforward and is already indicated in the example. NormalSteps correspond to SequenceFlow + Task combinations, pairs of diverging ParallelGateway and converging ParallelGateway correspond to ParallelSteps invoking ParallelFlows. The containers in the use case flow model do not really have a direct counterpart in BPMN.
In this simple version (there are standards for both metamodels and these are much more complex), the consistency relation is bijective, meaning that one BPMN model corresponds to exactly one use case flow.
Interestingly, the transformation is nonetheless at least non-trivial, due to the recursive nature of the models and having to keep track of e.g. all the flow containers.
Properties [optional section]
Variants [optional section]
Both metamodels have been extended by auxiliary edges (all edges starting with a double underscore such as the __conv edge between diverging and converging ParallelGateways) to enable the supplied TGG-based solution.
So a (potentially more challenging) variant would be to do without these edges.
If there is interest in this example, the contributing authors can be contacted to supply further features of both metamodels (this is only a small excerpt).
References [optional section]
The synchronization scenario is motivated and explained in more detail in:
Abilov M., Marx Gómez, J., Mora, M, Mahmoud, T. (in print) Towards an Incremental Bidirectional Partial Model Synchronization between Organizational and Functional Requirements Models. In Model Driven Requirements Engineering Workshop. Ottawa, Canada.
Anthony Anjorin, Marat Abilov
Artefacts [optional section]
A virtual machine hosted on Share is available with a workspace containing both (Ecore) metamodels, the concrete example used above, and a TGG formalizing the consistency relation as a set of rules: