Difference between revisions of "OR-Join"
From EPC Standard
or_join>DRahenbrock |
m (1 revision imported) |
(No difference)
|
Latest revision as of 14:27, 15 January 2021
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.