AND-Join

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

Short Description

An AND-Join Operator is a subtype of an AND Operator.
It is responsible for merging an AND-Split control flow from at least two branches, when the tokens of the previously activated branches converge.[1]
That is why AND-Join has multiple incoming arcs and just one outgoing arc:
C_aj = {c ∈ C | l(c) = and ∧ |cout| = 1}. [2]

An AND-join waits to get the control flow on all its incoming arcs before allowing the control flow to continue on its outgoing arc. That means all processing steps for incoming connections must be completed so that the processing steps that follow the rule can be performed.[2][3][4]

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.
• [*4] Mendling: Event Driven Process Chains - Metrics for Process Models, Volume 6 of the series Lecture Notes in Business Information Processing, 2009, pp. 17-57.