Actions

OR-Join

From EPC Standard

Revision as of 16:39, 25 March 2017 by or_join>DRahenbrock
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


OR-Join
Graphical Notation
There is no image yet, do you want to upload one?
IsSubClassOf IsSubClassOf::OR 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: OR-Join | ?Is a | Intro=The OR-Join is a }}. {{#show: OR-Join | ?contains | Intro=It contains }}. {{#show: OR-Join | ?hasSuccessor | Intro=Possible succeeding element(s) is/are  }}. {{#show: OR-Join | ?hasPredecessor | Intro=Previous element(s) can be }}. {{#show: OR-Join | ?hasIncomingControlFlow | Intro=The cardinalities are  | Outro= (incoming)}} {{#show: OR-Join | ?hasOutgoingControlFlow | Intro=and  | Outro= (outgoing) respectively }}. {{#show: OR-Join | ?refersTo | Intro=The OR-Join refers to }}. {{#show: OR-Join | ?attachedTo | Intro=The OR-Join is attached to a }}.


Short Description

An OR-Join Operator is a subtype of an OR 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 OR-Join could have multiple incoming arcs and just one outgoing arc:
Coj = {c ∈ C | l(c) = or ∧ |cout| = 1}. [2]


An OR-Join waits for an arriving token on each of its incoming arcs, propagates it to the outgoing arc and activates its successor. In contrast to a XOR-Join the OR-Join must wait until all tokens have arrived. The decision whether more tokens can arrive on the incoming arcs cannot be made locally at the OR-Join, it depends on the behavior of the corresponding OR-Split.
E.g. when the split has sent three tokens on different outgoing arcs, the join has to wait for exactly these three tokens to arrive in order to continue the process.[3] Therefore, the semantics of the OR-Join connector is called non-local.[1]

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] V. Gruhn and R. Laue, “What business process modelers can learn from programmers,” Sci. Comput. Program., vol. 65, no. 1, pp. 4–13, 2007.