XOR-Join

XOR-Join
Graphical Notation
There is no image yet, do you want to upload one?
IsSubClassOf	IsSubClassOf::XOR Operator
Successors	hasSuccessor::Function, hasSuccessor::Event, hasSuccessor::Operator, hasSuccessor::Process interface
Predecessors	hasPredecessor::Function, hasPredecessor::Event, hasPredecessor::Operator, hasPredecessor::Process interface
HasIncomingControlFlow	hasIncomingControlFlow::2, hasIncomingControlFlow::n
HasOutgoingControlFlow	hasOutgoingControlFlow::1
HasResource	hasResource::0
HasAttribute	hasAttribute::0
Edit the Properties

Brief Information

This is an autogenerated section!

You are not able to edit this information by hand, but by edit the Form (and therefore the properties) of this page. Please refer to the Edit the properties link at the bottom of the info box. {{#show: XOR-Join | ?Is a | Intro=The XOR-Join is a }}. {{#show: XOR-Join | ?contains | Intro=It contains }}. {{#show: XOR-Join | ?hasSuccessor | Intro=Possible succeeding element(s) is/are  }}. {{#show: XOR-Join | ?hasPredecessor | Intro=Previous element(s) can be }}. {{#show: XOR-Join | ?hasIncomingControlFlow | Intro=The cardinalities are  | Outro= (incoming)}} {{#show: XOR-Join | ?hasOutgoingControlFlow | Intro=and  | Outro= (outgoing) respectively }}. {{#show: XOR-Join | ?refersTo | Intro=The XOR-Join refers to }}. {{#show: XOR-Join | ?attachedTo | Intro=The XOR-Join is attached to a }}.

Short Description

An XOR-Join Operator is a subtype of an XOR Operator.
It is responsible for merging a split control flow, when the token(s) of the previously activated branch(es) converge.[1]
That is why XOR-Join has multiple incoming arcs and just one outgoing arc:
Cxj = {c ∈ C | l(c) = xor ∧ |cout| = 1} as the set of XOR-Join operators. [2]

An XOR-Join waits for an arriving token on one of its incoming arcs, which is then propagated to the outgoing arc and activates the successor. But for an XOR-Join there is an additional condition:
The XOR-Join must not activate its successor, if there is or there could arrive a token on one of the other incoming arcs. Whether it is possible that a token arrive on one of the other arcs or not depends on the overall behaviour of the EPC and cannot be checked locally.[3] Therefore, the semantics of the XOR-Join connector is called non-local. [1]

The non-local semantic is a central characteristic of a XOR Operator add leads to a tradeoff. [4] On the one hand the non-local semantic helps to simplify many models, but on the other hand it results in a lack of satisfactory formalization.[5] The non-local semantic is comprehensively discussed in the literature and there are different suggestions and approaches to overcome this problem.[5][6][7]

References

• [*1] N. Cuntz and E. Kindler, “On the Semantics of EPCs: Efficient Calculation and Simulation,” Bus. Process Manag., pp. 398–403, 2005.
• [*2] E. Kindler "On the semantics of EPCs: resolving the vicious circle", Data & Knowledge Engineering - Special issue: Business process management archive Volume 56 Issue 1, 2006, pp.23-40.
• [*3] Mendling: Event Driven Process Chains - Metrics for Process Models, Volume 6 of the series Lecture Notes in Business Information Processing, 2009, pp. 17-57.
• [*4] N. Cuntz, J. Freiheit, and E. Kindler, “On the Semantics of EPCs: Faster Calculation for EPCs with Small State Spaces,” Proc. Fourth Work. Event-Driven Process Chain. (WI-EPK 2005), pp. 7–23, 2005.
• [*5] E. Kindler, “On the semantics of EPCs: A vicious circle,” no. August, pp. 71–80, 2002.
• [*6] P. Rittgen, “Quo vadis EPK in ARIS? Ansätze zu syntaktischen Erweiterungen und einer formalen Semantik,” Wirtschaftsinformatik, vol. 42, no. 1, pp. 27–35, 2000.
• [*7] P. Langner, C. Schneider, and J. Wehler, “Petri Net Based Certification of Event-Driven Process Chains,” 19h Int. Conf. Appl. Theory Petri Nets, pp. 286–305, 1998.