INFS 5108
Organisational Transformation
and Business Process Modelling
Module 2
Events
• While a task is “do something” in a process, an event is “something that happens”, which affects the flow of a process
• Three main types of events: – Start event: indicates where a process will start
– End event: indicates where a path of a process will end
– Intermediate event: indicates where something happens between the start and end of a process
• An event may have a trigger, e.g. message, timer, error, signal, etc, or their combinations (multiple)
• A trigger is indicated by an icon inside the circle(s)
e.g. a message triggered start event, called a Message Start Event
• If an event has no trigger, then it is called a none event, e.g. None Start Event
4
Events
For now, we only look at
the 8 level 1 events,
including: • Start: none, message, timer,
and multiple
• End: none, message,
terminate, multiple
5
Start Events
• Indicates where and how a process or subprocess starts.
• Normally a process or subprocess only has one start event
• Four level 1 start events:
– None: no trigger
• Started manually by a performer, or process trigger is unspecified
• The only start event allowed for a subprocess
• Usually is not labelled
6
Start Events (cont’d)
– Message: started upon receipt of a message from outside the process
• Should be labelled with the message receive action, e.g. Receive XYZ
• Should draw the message flow and label the message flow with the name of
the message
7
Start Events (cont’d)
– Timer: started upon expiry of timer, schedule
• Labelled with time/scheduling information
– Multiple: there are multiple ways of triggering the process, and only
one of them is required to start the process
8
Start Events (cont’d)
A note on Multiple Start Event:
• When a Multiple Start Event is used, no matter which trigger is
received, the path out of the start event is the same.
• However, we may have the situation where the path out of the start
event depends on the trigger, i.e. different activities will be carried out
for different triggers.
• In this case, we cannot use a Multiple Start Event use more than
one (simple) start event – but remember that this is only allowed for a
top-level model, cannot be done in a subprocess model.
9
End Events
• Indicates the end of a path in a process or subprocess
• The icon inside the end circle (if any) indicates the result signal thrown when the end event is reached.
• Four level 1 end events: – None
• No result signal is thrown when the end state is reached
• Labelled with the end state, e.g. Order complete
• AND-join is implied at a None End Event
Parallel paths are allowed to end in separate
end events, but they do not represent distinct
end states, because the whole process is not
completed until all the parallel paths reach
their end states. Therefore, if the end states
are all None End Events, better to merge them
into one None End State, but in this case, you
don’t have to use an AND-join, because it is
implied at a None End Event
10
End Events (cont’d)
– Message: a message is sent (thrown) upon reaching this end event
Note: the message is sent for each activation of a Message End Event, which means if merge parallel paths directly into a Message End Event, the message is sent multiple times. So if you only want the message to be sent once, then must use an AND-join to merge the parallel paths before the Message End Event. different from using a None End Event to merge parallel paths
11
End Events (cont’d)
– Terminate: immediately ends the whole process or subprocess, even if
other parallel paths are still running
• If a Terminate End Event is reached in a subprocess, only the subprocess
is terminated, not its parent-level process
12
End Events (cont’d)
– Multiple: multiple consequences of ending the process when a Multiple
End Event is reached. All of them will occur, e.g., there might be
multiple messages sent.
13
Data and Data Flow
• Data Object
– Represents information/document
– Labelled with name and state (optional)
– Similar to a process-local variable
– Non-persistent
• Data Store
– Persistent storage
– Represents a single unit of information, instead of the database as a whole
• Data Flow
– Passing of information between process elements
– Dotted line, with V at the end
14
Data and Data Flow (cont’d)
• A Data Flow associated with a Data Object represents a
mapping (copy or a transformation) between the Data Object
and the output/input data of the connected activity
• A Data Flow associated with a Data Store represents a
database query (when the Data Flow is directed to the
activity) or a database update (when the Data Flow is
directed to the Data Store as in the above example) 15
Documentation & Text Annotations
• Documentation
– In the BPMN XML, most BPMN constructs each contains a
documentation element.
– Can add information to such an XML component as much as you wish
– No graphical representation
• Text Annotation
– Graphical representation
– Linked to process element via association (dotted) line
– For documentation only (artefacts), do not affect process flow
16
Method Outline
• Hierarchical top-down modelling style
• Represent model as linked process diagrams on distinct levels hierarchical
• Begin with understanding the end-to-end process as a whole, identifying its major steps in a high-level map, them model them as a top-level process diagram (that fits on a single page !)
• Then going down to define and model the process logic of a parent-level activity in a child-level diagram, revealing as much detail as required for your purpose.
• Top-down helps in understanding the process as a whole before considering the details at lower levels – Bottom-up method runs risk of getting bogged down in unnecessary
details
• Add (implementation) details incrementally at lower levels
17
End States of Activities
• Each activity has a well-defined start and end
• How did its execution end?
– Completed successfully?
– Exception occurred? Cancelled? Escalated? …
• How many to distinguish depends on model
– Distinguish as many as you need for gateways and exception handling
• If an activity is a task, its end state is implicit
– May be indicated by the label of the gateway following the task: “Credit
OK?”, “Credit OK”, “Credit Not OK”
• If an activity is a subprocess
– Model and label its end states in the child-level model explicitly
– This helps with achieving top-down traceability
18
Method – the Steps to Follow
1. Determine process scope
2. Build a high-level map
3. Create a top-level BPMN diagram
4. Expand composite activities into child-level diagrams
5. Add message flows
6. Repeat 4 and 5 for subprocesses
19
Style Rules
1. Use icons and labels to make the process logic clear from
the printed diagram.
2. Make models hierarchical, fitting each process level on one
page.
35
Style Rules
3. Use a black-box pool to represent the Customer or other external
requester or service provider.
4. Begin customer-facing processes with a Message Start Event receiving a
message flow from the Customer pool.
36
Style Rules
5. Model internal organisational units as lanes within a single
process pool, not as separate pools. Separate pools imply
independent processes.
37
Style Rules
6. Label process pool with the name of a process. Label black-
box pool with a participant role or business entity.
7. Indicate success and exception end states of a process or
subprocess with separate end events, and label them to
indicate the end states.
38
Style Rules
8. Label activities VERB-NOUN, e.g. use “Check credit” (for
action), instead of “Credit check” (function) or “Credit Ok”
(state)
9. Use start event trigger in top-level process to indicate how
the process starts.
– If a process is initiated by an external request, use a Message Start
Event and label it with something like “Receive <message flow
name>”.
– If a process is a scheduled process, use a Timer Start Event
– Use a None Start Event if the process is started manually by a
performer. Do not need to label the None Start Event
39
Style Rules
10. If a subprocess is followed by a gateway labelled as a
question, the subprocess should have more than one end
event, and one of them should match the gateway label.
40
Style Rules
11.Show message flow with all Message events.
12.Match message flows in parent- and child-level diagrams.
13. Child-level diagram
14.
Parent-level diagram
41
Style Rules
13. Label message flows directly with the name of the message.
14. Two end events in a process level should not have the same name.
42
Style Rules
15. Two activities in a process model should not have the same name.
16. A subprocess should have a single None Start Event.
43
Style Rules
17. A process pool in child-level diagram (if drawn) should be labelled with
name of the top-level process, not the name of the subprocess
18. In a hierarchical model, a child-level diagram may not contain any top-
level processes.
19. Don't use an XOR gateway to merge alternative paths, unless into
another gateway. Just connect the sequence flows directly.
20. Don't use an AND gateway to join parallel paths into a None End Event.
A join is always implied at a None End Event.
44
Style Rules (BPMN 2.0 Rules)
21. A sequence flow may not cross a pool (process) boundary.
22. A sequence flow may not cross a subprocess boundary
45
Style Rules (BPMN 2.0 Rules)
23. A message flow may not connect nodes in the same pool.
24. A sequence flow may only connect to an activity, gateway, or event, and
both ends must be properly connected.
25. A message flow may only connect to an activity, Message (or Multiple)
event, or black-box pool, and both ends must be properly connected.
46
References
47
1. Bruce Silver. BPMN Method and Style with BPMN Implementer’s Guide. 2nd Edition.
Cody-Cassidy Press, 2011.
2. Thomas Allweyer. BPMN 2.0 – Introduction to the Standard for Business Process
Modeling. Norderstedt : Books on Demand GmbH, 2010.
3. OMG. Business Process Model and Notation (BPMN), Version 2.0, January 2011. URL:
http://www.omg.org/spec/BPMN/2.0/
Note: Most materials, including the BPMN diagrams used in this set of slides are taken from
Reference 1, and some diagrams are from the other two references.
BPMN: modelling constructs,
method and style – Level 2
48
Outline
• More notation:
– Intermediate events
– Repeated activities
– Transactions
– Splitting and merging
• Level 2 modelling rules
– The BPMN (official) rules
– The style rules by Bruce Silver
49
Complex Process Control
• So far, a process is started when a start event occurs, and
each step in the process is triggered by the completion of the
preceding step
• Realistic processes require more:
– Pause and wait for an event
– Interrupt running activities
– Handle exceptions
– Send messages between process entities
– Rollback effects of parts of a process
• Level 2 modelling constructs (i.e. those in the analytic
subclass) and the Level 2 method & style rules address the
modelling of more complicated process behaviour
50
Event
• Level 1 events are either
start or end events (those
highlighted in grey)
• Level 2 emphasises
intermediate events,
those with double rings, occurring after the start of a
process level and before the
end
• We will focus on the
intermediate events
highlighted in green
• Will also look at those in
yellow, later
51
Intermediate Event - Introduction
• Row headers on the left
table show the “Types” of
the Level 2 intermediate
events we are looking at:
– Message, Timer & Error
– Cancel & Compensation
• Column headers show the
“Triggered Behaviour” of
the event:
– Throwing
– Catching
• (non-boundary) catching
• boundary catching
– Interrupting
– Non-interrupting
52
Intermediate Event - Introduction
• Two classes of triggered behaviour:
– Throwing:
• Filled trigger symbol inside the double ring
• The event generates the trigger (i.e. throws the trigger out)
• Throwing Message Event: throws a message
– Catching: Hollow or unfilled trigger symbol inside the double ring
Used in two situations:
1. (Non-boundary) catching event:
With Catching Message or Timer Event, the event waits for the trigger signal,
message arrival or timer expiry
53
Intermediate Event - Introduction
2. Boundary catching event:
• Drawn on the boundary of an activity
• No incoming sequence flow, and must have one and only one outgoing
exception flow
• While the associated activity is running, the process listens, for the trigger signal
• If the trigger occurs before the activity is completed, the exception flow is started;
if the activity is completed without the occurrence of the trigger, the exception
flow is ignored
• Two kinds of boundary catching event:
− Interrupting • The associated activity or normal flow
is terminated (interrupted) when the
trigger (Message, Timer, or Error)
occurs
• Process follows the exception flow
immediately
− Non-interrupting • The associated activity or normal flow
continues when the trigger (Message
or Timer) occurs
• Exception flow started in parallel
immediately
• Represented using dashed double ring
54
Intermediate Event – Timer Event
• All intermediate Timer events are catching events
• A non-boundary Timer Catching Event represents a time delay, i.e.
“wait for <a time period>” or “wait until <a time point>”
– Examples:
1. Check for uploaded data every 10 minutes until available
2. After payment has been approved, issue check on the 15th or 30th of each month.
• Does NOT represent “wait for something to happen” – that would
be a message event
• Does NOT represent “how long an activity takes” 55
Intermediate Event – Timer Event
• A boundary Timer event can be considered as a “countdown timer” with a
pre-set value, either a duration or a (future) time point
• The “timer” is started when the associated activity is started; and is
stopped when the pre-set duration or time point is passed
• The “timer”, when stops, immediately triggers the exception flow.
• The normal flow:
• As a non-interrupting Timer event does not terminate the associated
activity, it may occur multiple times before the associated activity is
completed. In the above example, may label the Timer event with “every 4
hour” to model that the manager is notified every four hour before the
“Perform service” activity is completed.
− Continues if the event is non-interrupting − Stops if the event is interrupting
XOR-join AND-join
56
Intermediate Event – Timer Event
• How to model a timer that is set up for more than one activity ?
• Put these activities together as a subprocess, and attach a Timer
event to the subprocess
57
Intermediate Event – Timer Event
• Timer Event or Gateway ?
The scenario: the wireless carrier’s add feature process Adding the features is supposed to be done within one hour. If it is expected to
take more than an hour, customer is notified with the expected completion time.
Model 1: using a gateway
Model 2: using a boundary Non-Interrupting Timer Event
Question: Does the customer notification occur at the same time in the two
models ? Why ?
Intermediate Event – Message Event (Throwing)
• Non-boundary Throwing Message Event, upon occurring, sends a
message, then the sequence flow continues.
• Send task does the same thing
• Previously we saw examples with messages being sent from a black-box
pool, or a (normal) activity and we said that “Message flows only express
possibility of communication”
• To model that a message is definitely sent, we use Throwing Message
Event or Send task
• Send task and Throwing Message Event are roughly equivalent, upon
occurring, a message is sent. However, subtle differences exist:
– Send task, as an activity, has a performer, but the Throwing Message Event does not
have a performer
– Can do things to Send task as to a normal task, such as adding a marker to indicate it is
to be done multiple times, or adding to the task an error boundary event, but cannot do
these to an event.
59
• Do not use a Send task to represent communication within a process:
• Use lanes to imply the downstream work forwarding
• If want to model the forwarding explicitly, add a forwarding task (a User
task) and data passing:
60
Intermediate Event – Message Event (Throwing)
Intermediate Event – Message Event (Non-boundary Catching)
• A non-boundary Catching Message Event waits for a message,
and immediately resumes when the message is received.
• Receive Task is roughly equivalent to Catching Message Event.
• Subtle differences exist between Receive task and Catching
Message Event, similar to those between Send task and Throwing
Message Event
61
Intermediate Event – Message Event, Example
62
• A more practical model, with Event Gateway waits for
response from Customer or timeout, whichever occurs first
• Like the XOR gateway, event gateway represents exclusive
choice.
• However, XOR gateway is data-based, i.e. the choice is made
based on process data; Event gateway makes choices based
on the occurrence of events, which event occurs first is chosen
Intermediate Event – Message Event & Event Gateway
63
Intermediate Event – Message Event (Boundary Catching)
• The two message events we’ve just seen, (catching and throwing,
are non-boundary events. With these two message events, the
process is paused to wait for the message to be received (catching
message event) or sent out (throwing message event)
• BPMN also has boundary message events, for which the process
is NOT paused waiting for messages, instead, the process listens
for a message while running normally.
• Two kinds of boundary message events:
64
− Non-interrupting: the normal flow
continues when the message is received.
− Interrupting: the normal flow stops
when the boundary message event is
triggered, i.e. the message is
received.
Intermediate Event – Message Event (Boundary Catching)
• The same message may be received during the execution of
different activities, and lead to different or same exception flows
65
Intermediate Event – Message Event (Boundary Catching)
• If the exception flows are the same for a number of sequential
activities, it is a good idea to include these activities in one
subprocess, and attach only one boundary message event to the
subprocess, instead of one to each of the activities
66
Intermediate Event – Error Event
• Boundary Error Event:
– Represents the exception end exit from the activity
– Boundary Error Event is always interrupting
– Equivalent to the testing using an XOR gateway
– When attached to a subprocess, the subprocess must contain a same named
Error End Event, as well as the corresponding interrupting boundary error
event(s)
67
Intermediate Event – Cancel & Compensation Events, and Transaction
68
• A boundary catching Cancel Event:
– is indicated by an “X” inside the double circle
– is triggered when the associated transaction fails before its completion
– is always interrupting, that is:
• when the transaction is cancelled, all completed activities within the
transaction that have defined compensating activities are undone by running
the linked compensating activities
• after all the compensating activities within the transaction are completed, the
exception flow is started
• A transaction:
– is represented as a subprocess with a double border
– its component activities must:
• be all completed successfully, or
• if the transaction fails to complete, all completed component activities must be
undone to let the transaction roll back to its original state
Intermediate Event – Cancel & Compensation Events, and Transaction
69
• A boundary catching compensation event:
– is indicated by a “rewind” symbol inside the double circle
– is used to link its associated activity to a compensating activity, which is indicated by
a “rewind” symbol inside the activity rectangle
– is triggered only after the associated activity is completed successfully and the
enclosing transaction is cancelled.
– if at the moment when the transaction is cancelled, the associated activity has not be
started, or is still running, or the associated activity itself fails to complete, the linked
compensating activity is not executed
Cancel end event
boundary catching
compensation event
Linked compensating activity
(for undoing Book air)
Expanded transaction
subprocess
Loop Activity
• Indicated by the circular arrow marker
• Represents sequential repetitions of an activity
1. The activity is executed once for the first time
2. The loop condition, a boolean data expression, is evaluated
3. When the condition is satisfied, perform the task again and go back to step 2. Such
iterations (steps 2 & 3) can continue infinitely, or if the limit of number of iterations has
been setup in advance, stop the looping when the limit is reached.
4. When the condition is not satisfied, exit from the loop activity
• A more compact way to represent loops than the gateway loopback.
• Loop activity hides the loop condition (but the gateway representation
does not), so it is recommended to add a text annotation to a loop activity
to indicate the condition (see the example above)
70
Multi-Instance Activity
• Indicated by the 3-bar marker
• Represents parallel repetitions of an activity
• The number of repetition is known beforehand. This is different from a
loop activity, for which the exact number of repetitions is not known
beforehand.
• Normally used to represent that for a list of items, the activity is done for
each of the items in the list.
• Example:
• Equivalent to the AND gateway representation:
note: all instances of activity A have to be
completed before the sequence flow
can move ahead
71
Using Repeated Activities
• What is the problem
with the model on the
right ?
• A valid but impractical correction
• A more practical model
72
• Imagine an ordering process where order data are collected
and processed in batches of 50.
Would you be satisfied with the model below ?
Post order batch
Receive
Order
Fulfil order
Multiple Pools for Instance Alignment
• It is better to use multiple pools linked by a data store
Multiple Pools for Instance Alignment O
rd e
r p
ro c
e s
s
Multiple Pools for Instance Alignment
Advanced Process Splitting and Merging – OR Gateway
• When used for flow splitting,
– can activate one or more gates (outgoing flows)
– Each gate has a boolean condition, and the conditions of all the gates are independent
of each other (this is different from the XOR, with which only one gate can be true)
– A gate is activated if its boolean condition is evaluated to be true
– If we want to model that a gate is always activated, label it with “Always”
Example 1:
Example 2:
76
Advanced Process Splitting and Merging – OR Gateway
• Also known as inclusive OR gateway
• When used for flow merging,
– Waits for and joins (i.e. synchronises) all activated incoming sequence flows, and
ignores all the incoming flows that are not activated
is the same as:
– In the example below, although the AND-split is unconditional, i.e. it activates both
outgoing flows, when the exception flow is enabled by the boundary error event, the
normal flow of “Conduct financial review” is “dead”. In this case, we must use an
inclusive OR gateway to ignore the “dead” flow. If an AND-join was used, the AND-join
will never get enabled, thus the whole process gets into a deadlock here.
77
Advanced Process Splitting and Merging – Conditional Sequence Flow
• Used to represent conditionally enabled sequence flows
– Conditional sequence flows can only be the outgoing flows of an activity, they can
NOT be the outgoing flows of gateways
– A conditional sequence flow is activated if the condition is evaluated to be true
– Do not use conditional sequence flows to represent exclusive choice, use XOR
gateway instead
78
Advanced Process Splitting and Merging – Conditional Sequence Flow
• To merge conditional sequence flows, use an OR gateway, or a none
End event if suitable (see the example on previous slide)
• In the following example:
– If an AND-join was used, we may get a deadlock
– If an XOR-join was used, the model would represent that the task “Conduct final
review” is to be carried out multiple times when more than one conditional
sequence flows are enabled.
79
Advanced Process Splitting and Merging – Modelling Discriminator Pattern with Complex Gateway
• A complex gateway are used for some user defined behaviour other
than that described by AND, OR, XOR gateways
• Complex gateway can be used to model the discriminator pattern
• When multiple activities running in parallel, a discriminator lets the
sequence flow go ahead when any of the parallel activities is
completed.
80
Complex
gateway
Level 2 Rules - BPMN (Official) Rules
Sequence Flow
1. A sequence flow must connect to a flow node (activity, gateway, or event) at both ends. Neither
end may be unconnected.
2. All flow nodes other than start events, boundary events, and catching Link events must have an
incoming sequence flow, if the process level includes any start or end events.
[Exceptions, not part of the Level 2 palette: compensating activity, event subprocess.]
3. All flow nodes other than end events and throwing Link events must have an outgoing sequence
flow, if the process level includes any start or end events.
[Exceptions, not part of the Level 2 palette: compensating activity, event subprocess.]
4. A sequence flow may not cross a pool (process) boundary.
5. A sequence flow may not cross a process level (subprocess) boundary.
6. A conditional sequence flow may not be used if it is the only outgoing sequence flow.
7. Sequence flow out of a parallel gateway or event gateway may not be conditional.
[Note: On sequence flows out of gateways, conditional is an invisible attribute; the conditional
tail marker is suppressed on sequence flows out of gateways.]
8. An activity or gateway may have at most one default flow.
Level 2 Rules - BPMN (Official) Rules
Message Flow
9. A message flow may not connect nodes in the same process (pool).
10. The source of a message flow must be either a Message or Multiple end event or throwing
intermediate event; an activity; or a black-box pool.
11. The target of a message flow must be either a Message or Multiple start event, catching
intermediate event, or boundary event; an activity; or a black-box pool.
[Exceptions, not part of the Level 2 palette: event subprocess Message or Multiple start
event.]
12. Both ends of a message flow require a valid connection. Neither end may be unconnected.
Level 2 Rules - BPMN (Official) Rules
Start Event
13. A start event may not have an incoming sequence flow.
14. A start event may not have an outgoing message flow.
15. A start event with incoming message flow must have a Message or Multiple trigger.
16. A start event may not have an Error trigger.
[Exceptions, not part of Level 2 palette: event subprocess start event].
17. A start event in a subprocess must have a None trigger.
[Exceptions, not part of Level 2 palette: event subprocess start event].
End Event
18. An end event may not have outgoing sequence flow.
19. An end event may not have incoming message flow.
20. An end event with outgoing message flow must have Message or Multiple result.
Level 2 Rules - BPMN (Official) Rules
Boundary Event
21. A boundary event must have exactly one outgoing sequence flow.
[Exception, not part of the Level 2 palette: Compensation.]
22. A boundary event trigger may include only Message, Timer, Signal, Error, Escalation,
Conditional, or Multiple.
[Exceptions, not part of Level 2 palette: Cancel, Compensation, Multiple-Parallel.]
23. A boundary event may not have incoming sequence flow.
24. An Error boundary event on a subprocess requires a matching Error throw event.
25. An Error boundary event may not be non-interrupting.
26. An Escalation boundary event on a subprocess requires a matching Escalation throw event.
Level 2 Rules - BPMN (Official) Rules
Throwing or Catching Intermediate Event
27. An intermediate event with incoming message flow must be catching type with Message or
Multiple trigger.
28. An intermediate event with outgoing message flow must be throwing type with Message or
Multiple trigger.
29. A throwing intermediate event result may include only Message, Signal, Escalation, Link, or
Multiple. [Exceptions, not part of Level 2 palette: Compensation.]
30. A catching intermediate event trigger may include only Message, Signal, Timer, Link,
Conditional, or Multiple.
31. A throwing Link event may not have outgoing sequence flow.
32. A catching Link event may not have incoming sequence flow.
Level 2 Rules - BPMN Rules
Gateway
33. A gateway may not have incoming message flow.
34. A gateway may not have outgoing message flow.
35. A splitting gateway must have more than one gate.
36. Gates of an event gateway may include only a catching intermediate event or Receive task.
Process (Pool)
37. A process must contain at least one activity.
38. Elements of at most one process may be contained in a single pool.
39. A pool may not contain another pool. If a child-level subprocess expansion is enclosed in a
pool, that pool must reference the same participant and its associated process as the parent
level.
Level 2 Style Rules
87
Labeling
1. An activity should be labeled, ideally VERB-NOUN.
2. Two activities in the same process should not have the same name, unless they are both call
activities.
3. A triggered start event should be labeled to indicate the trigger condition.
a. A Message start event should be labeled "Receive [message name]".
b. A Timer start event should be labeled to indicate the process schedule.
c. A Signal start event should be labeled to indicate the Signal name.
d. A Conditional start event should be labeled to indicate the trigger condition.
4. A boundary event should be labeled.
5. The label of an Error boundary event on a subprocess should match the label of a child-level
Error end event.
6. The label of an Escalation boundary event on a subprocess should match the label of a child-
level throwing Escalation event.
Level 2 Style Rules
88
Labeling (cont’d)
7. A throwing intermediate event should be labeled.
8. A catching intermediate event should be labeled.
9. Paired Link events should have matching labels.
10. Throwing and catching events corresponding to the same Signal event definition should
have matching labels, if they occur in the same BPMN model.
11. An end event should be labeled with the name of the end state.
12. A splitting XOR gateway should have at most one unlabeled gate.
13. A splitting XOR or inclusive gateway should be labeled if any of its gates are unlabeled.
14. The label of a child-level diagram (page) should match the name of the subprocess.
Level 2 Style Rules
89
End Event
15. Two end events in a process level should not have the same name. If they signify the same
end state, combine them; otherwise give them distinct names.
16. If a subprocess is followed by a yes/no gateway, at least one end event of the subprocess
should be labeled to match the gateway label.
Subprocess Expansion
17. Only one start event should be used in a subprocess, unless it is a parallel box.
18. A child-level expansion should not be enclosed in an expanded subprocess shape if parent and
child process levels are represented by separate diagrams.
Level 2 Style Rules
90
Message Flow
19. A message flow should be labeled directly with the name of the message.
20. A Send task should have an outgoing message flow.
21. A Receive task should have an incoming message flow.
22. A Message start event should have an incoming message flow.
23. A catching Message event should have incoming message flow.
24. A throwing Message event should have outgoing message flow.
25. A message flow from a collapsed subprocess should be replicated in the child-level diagram.
26. A message flow to a collapsed subprocess should be replicated in the child-level diagram.
27. An incoming message flow in child-level diagram should be replicated in the parent level.
28. An outgoing message flow in child-level diagram should be replicated in the parent level.
References
91
1. Bruce Silver. BPMN Method and Style with BPMN Implementer’s Guide. 2nd Edition.
Cody-Cassidy Press, 2011.
2. OMG. Business Process Model and Notation (BPMN), Version 2.0, January 2011. URL:
http://www.omg.org/spec/BPMN/2.0/
Note: Most materials, including the BPMN diagrams used in this set of slides are taken from
Reference 1.
Readings
92
1. (Optional) OMG. BPMN 2.0 by Example. June 2010. URL:
http://www.omg.org/spec/BPMN/20100601/10-06-02.pdf Notes:
a. The examples included in this document can be found at: http://www.omg.org/spec/BPMN/2.0/examples/ZIP
b. Some of the modelling constructs used in those examples are not covered by the course. You may need to refer
to BPMN 2.0 spec to find out more details about them. The spec document is available
from:http://www.omg.org/spec/BPMN/2.0/
Copyright Regulations
COMMONWEALTH OF AUSTRALIA
Copyright Regulations 1969
WARNING
This material has been reproduced and communicated to you
by or on behalf of University of South Australia pursuant to
Part VB of the Copyright Act 1968 (the Act).
The material in this communication may be subject to copyright
under the Act. Any further reproduction or communication of
this material by you may be the subject of copyright
protection under the Act.
Do not remove this notice.
93
Poor Fair Good Marks Comments
Instructions Followed (2marks) x 1
Detail of narrative (5marks) x 3
Use of plain English (2marks) x 1
BPD reflects process (5marks) x 3
Full & correct use of BPMN 2.0 symbols and notation (10marks) x 6
Originality of business strategy and solution (5marks) x 3
TOTAL MARKS 17 /30
INFS 5108 Business Process Modelling
Assignment #2 Marks and Feedback
© 2013 MID GmbH
www.mid.de
BPMN 2.0 - Business Process Model and Notation Innovator for Business Analysts
Find more information about the Innovator for Business Analysts and business process modeling with BPMN 2.0!
Events
Start Event
End Event
Intermediate Event
caught thrown
Escalation
Conditional
Error
Timer
Message
Terminate
Link
Signal
Cancel
None
Compensation
Multiple
Parallel Multiple
Caught
Interm ediate Event
Start Event
Start Event
Start Event
Event Connected
Event Connected
Throw n
End Event
order invitation cards
inquire by phone
create invitation
delete participant
confirm participant
cancel invitation
cancelation
cr ea
te in
vi ta
ti on
plan event
14 days
cancelation
commitment
event canceled termination
continuation
canceled
confirmed
not available
continuation
10 invitation cards still remain
invitation
Events: represent all incidents within a process. An event may be used as a start, intermediate, interrupting and end event.
Interm ediate Event
Interrupting Boundary
N on-Interrupting Boundary
Interrupting Subprocess-
Non-Interrupting Subprocess-
Conditional Flow
Sequence Flow
Massage Flow
Shows the flow of messages between two participants. It can start or end at a participant or at any element of the process. It always goes beyond participant borders.
Shows the flow in a process. The sequence flow cannot cross a pool boundary but can switch between lanes.
Association
Is mainly used as data association for modeling data flows. For modeling compensations it is used as compensation association.
A means to attach a condition to a sequence flow that does not belong to a gateway.
Is traversed if none of the conditions after a gateway is true.
Default Flow
Edges and connectors Collaboration: describes the interaction between participants (in this example: customer, company and supplier).
Process: describes the flow of activities in an organization (in this ex- ample: quote creation).
Lane: represents the responsibilities within a process like involved roles or systems (in this example: clerk and approver).
Processes and Collaborations
Supplier
cu st
om er
re qu
es t
fo r
qu ot
e
approve quote
A pp
ro ve
r
create quote
complete quoteCl
er k
co m
pa ny
qu ot
e cr
ea ti
on
Co lla bo
ra tio
n
quote requested quote created
quote requested quote created
request quote
query answer
Artifacts
Groups help to structure ele- ments and do not influence the process flow.
Text annotations enable to capture important additional information.
GroupsText annotation
create quote
send quote
quote sent
price list
qu ot
e cr
ea ti
on
customer information
Text annotations may contain additional information
Task: represents a single step in a process or a work unit.
User Task: is executed by a user with the as- sistance of a software application.
Service Task: is performed automatically. From a technical point of view, it is a call of a service operation.
Business Rule Task: provides a mechanism for the process to provide input to a busi- ness process engine.
Manual Task: is expected to be performed without the aid of any business process execution engine or any application.
Activities
Script Task: is executed by a business pro- cess engine.
Call Activity Global Task: identifies a point in the process where a global task is used. Activation of a call activity trans- fers control to the called task.
Call Activity Subprocesses: is an independent process that can be called from various processes.
Receive Task: receives messages and com- plies with the semantics of an intermediate event for messages caught.
Send Task: sends messages and complies with the semantics of an intermediate event for messages thrown.
Event-based subprocess: is started by an external event. It does not have any incoming or outgoing sequence flows.
Subprocess: is a graphical object within a process but it also can be „opened up“ to show a lower-level process. It is not an independent process and may not be devided in different lanes.
Transactions: are subprocesses which require special actions to be taken in case of failure or hazard.
Ad-hoc Subprocess: do not impose a sequence on its contained activities. The sequence and number of performances of the ac- tivities is up to those persons or resources doing the work.
save contact information
delete account information
save account information
create account
Tr an
sa cti on
error when saving
roll back error when saving
cancel
inform customer
perform measurement
monitor response time
process request on 1st levelP
ro ce
ss in
g s
u p
p o
rt re
q u
es t
loop condition: no sultion had yet been found
correct defect
check quality
find cause
identify reason of failure
inform customer
Pe rf
o rm
in g
d ef
ec t
co rr
ec ti
o n
s
reason of failure
reason of failure
defect correction failed
defect correction failed
defect corrected
prepare main course
buy ingredients
set the table
polish cutlery
prepare dessert
prepare starter
prepare dinner
A d-
ho c
Su bp
ro ce
ss
invite friends
Ad-hoc: whether and how often an activity is performed is left to the discretion of the per- son responsible.
This activity implies a subprocess.
Loop: repeats the performance as long as the loop condition is met.
Multi-Instance Parallel: multiple, simultane- ous execution for a number of objects.
Multi-Instance Sequential: multiple, sequen- tial execution for a number of objects.
Compensation: undoes steps which have al- ready been successfully completed.
Markers for Tasks and Subprocesses
Compensation Association occurs outside the normal sequence flow and connects a com- pensation event with a compensation activity at a roll back.
Data Object
Data Store (Reference)
Data Output
Data Input
A data object represents data which is relevant for the process. They can only be referenced inside the process.
Data Inputs represent data which has to be passed to a process or subprocess from the outside i.e. the calling process for further processing.
Analogous to the data input the data output repre- sents data which is returned from the process or subprocess to the calling process.
Using a data store (reference) instead of a data object emphasizes that the data used is persistant rather than transient data and that it is accessible from dif- ferent processes rather than having a local scope.
Data Data Association List of data objects
Name [state]
Name [state]
Name [state]
Name [state]
Name [state]
Name [state]
Name [state]
Data associations model the flow of data including data transformations.
create order
acquire quote data
order creation
archive order
acquire quote
create order
quotation processing
send order
order database
quotation itemsquote
quote received
order
orderquotation items
Instantiation
Instantation: is mainly relevant in the process automation realized by gateways and events.
The occurence of the first events instantiates the process. All other paths of the event-based exclusiv gateways are no longer valid.
revise quote
send order
create order
send quote
cancel quote
q u
o ta
ti o
n p
ro ce
ss in
g
customer answer
deadline
quote accepted
quote declined
order sent
quote sent
The occurence of the first event instantiates the process. The process may only terminate normally if further events occured.
Multiple- Start Event
Parallel Multiple- Start Event
The process can be instantiated through different events. All events have to occur so that the process can be instantiated.
settle travel expenses
p er
fo rm
tr
av el
e xp
en se
a cc
ou n
tin g
travel expense accounting received
15th of the month
perform defect correction
co rr
ec t
d ef
ec t
request defect correction defect correction declined
defect correction reported
settle travel expenses
p er
fo rm
tr av
el e
xp en
se s
ac co
un tin
g
15th of the month travel expenses
accounting received
Event-Based - Exclusive
Event-Based - Parallel
all paths are taken
Gateways
data-based exclusive (either OR)
parallel (AND)
inclusive (OR/AND)
event-based exclusive
complex
event-based: the flow is forwarded to the path whose events occured first.
Gateways are used to control how the process flows through sequence flows as they converge and diverge within a process.
only one path can be taken
one path is taken depending on the first occuring event
decline quote
inform customer
accept quote
check quote
quote ok
quote incorrect
exclusive: exactly one path is taken
select music
buy drinks
buy food
plan event
invite friends
process answer
complete process
submit quote
answer
14 days
determine customer‘s wish
inform customer
book room
order drinks
drinks desired
room desired
inclusive: more than one path can be taken
none, one or more paths can be taken
can be used to model complex synchronization behavior
parallel: all paths are taken
Business Rule Task
Multi-Instance Sequential
Event-based subprocess
Service Task
La ne
1 (s
ub or
di na
te )
Call Activity Subprocess
Manual Task
Call Activity Global Task
Send Task
Script Task
Subprocess (with loop feature)
La ne
2 (s
ub or
di na
te )
La ne
(s up
er io
r)
Pa rti
ci pa
nt /P
oo l (
W hi
te B
ox )
Pr oc
es s
Participant/Pool (Black Box)
Co lla
bo ra
tio n
Text annotation as loop condition
escalation intermediate event
timer intermediate event
termination end event
parallel gateway
list [state1, state 2]
message end event
data object [state]
failure boundary event (interrupting)
signal intermediate event
event based gateway
standard answer
exception answer
deadline
message start event
data store [state 1, state 2]
data store [end state]
link intermediate event
failure end event
escalation start event (non-interrupting)
exclusive gateway
multiple end event
link intermediate event
inclusive gateway
condition
otherwise (default)
condition
condition
message (trigger)
message (trigger)
message (trigger)
message (trigger)
message (trigger)
INFS 5108
Business Process Modelling
BPMN 1
Benefits of BPM
1. Align Operations with Business Strategy
Implementing a business strategy or a new business model
requires changes in the operations and in how people
perform their work. This can be affected only by
operationalizing the business changes to the actual business
processes, business rules and decisions that are made on a
day to day basis by all the people in the organization.
Singh D (UD) 5 Key Benefits of Business Process Modeling
www.modernanalyst.com/Resources/Articles/tabid/115/ID/1728/5-Key-Benefits-of-Business-Process-Modeling.aspx
Accessed 7/5/16
Link Align Implement Enable
N
Benefits of BPM
2. Improve Process Communication
One area that distinguishes successful businesses and
teams is that they have a very clear idea of what they are
supposed to do, how they are supposed to do it and what is
the exact role of every team member. Clear communication
of the operational processes is critical to facilitate a smooth
functioning of a team.
Singh D (UD) 5 Key Benefits of Business Process Modeling
www.modernanalyst.com/Resources/Articles/tabid/115/ID/1728/5-Key-Benefits-of-Business-Process-Modeling.aspx
Accessed 7/5/16
Language Training Communicate Turnover
Documentation
N
Benefits of BPM
3. Increase Control and Consistency
Organizations and companies that succeed are ones that
ensure their business processes and rules are well designed
and that they are consistently applied the same way every
single time. This process control and consistency is key for
success in organizations ranging from fast-food chains to
hospitals to NASA Space Shuttle operations
Singh D (UD) 5 Key Benefits of Business Process Modeling
www.modernanalyst.com/Resources/Articles/tabid/115/ID/1728/5-Key-Benefits-of-Business-Process-Modeling.aspx
Accessed 7/5/16
Formalise Execute Exceptions No guesswork
Compliance
N
Benefits of BPM
4. Improve Operational Efficiencies
In today's business environment, every business and every
manager wants to ensure that they are achieving the best
possible results with the resources available to them. There is
no room for inefficiencies and wastage.
Singh D (UD) 5 Key Benefits of Business Process Modeling
www.modernanalyst.com/Resources/Articles/tabid/115/ID/1728/5-Key-Benefits-of-Business-Process-Modeling.aspx
Accessed 7/5/16
Optimise Productive Prototype Reduced risks
Better utilisation
N
Benefits of BPM
5. Gain Competitive Advantage
All the benefits mentioned above lead to a significant competitive
advantage for an organization that has invested the time and effort
to document, simulate and improve its business processes.
Studies of many wildly successful companies has often shown that
their success was not due to better ideas or better business
models but because they invested significantly in business process
modeling to constantly refine and improve their processes. A slight
improvement in one activity here and another one there leads to an
overall better process and as that process is executed repeatedly
in the day-to-day running of the business it makes an organization
much more efficient and better than its competitors
Singh D (UD) 5 Key Benefits of Business Process Modeling
www.modernanalyst.com/Resources/Articles/tabid/115/ID/1728/5-Key-Benefits-of-Business-Process-Modeling.aspx
Accessed 7/5/16
N
• A process model can be assessed in terms of its:
– Syntactic quality
• All components in the model are built by following the syntax and
vocabulary of the modelling language
• Syntactic quality is the basis for the other categories of model qualities
– Semantic quality
• The model makes true statements on the real world they aim to capture,
either for existing processes (as is) or future processes (to be).
• In other words, the model is:
– valid: all statements in the model are correct and relevant to the problem;
– Complete: the model contains all relevant statements that would be correct
– Pragmatic quality
• The model can be understood by people
What is a Good Model ?
• Syntactic qualities can be checked without knowing the
real-word processes, as we check the model to see:
– If the correct types of modelling elements are used and if they
are correctly connected
– If the model can terminate properly
• Use verification techniques/tools in the design of
process models to ensure Syntactic quality
Check and Ensure Syntactic Quality
8
• Checking a model’s semantic quality (i.e. model validation) can only
be done by
– knowing the meaning of the modelling constructs
– understanding the domain in question
– knowing the exact purpose of the process model
• Simulation:
– presents the formal behaviour of a model to users in an intuitive way,
which can help assessing the semantic quality of a model
– provides insights into the performance of the process being modelled
• Paraphrasation:
– Translates the model back to natural language
– To make a process model understandable to somebody who is not
familiar with modelling (but familiar with the domain and purpose of the
modelling)
• Approaches such as process mining and natural language processing
can help with creating models that accurately capture reality
Check and Ensure Semantic Quality
9
• The 7PMG is aimed at directing process modellers to create
understandable models that are less prone to errors.
– G1: Use as few elements in the model as possible
– G2: Minimize the routing paths per element
– G3: Use one start and one end event
– G4: Model as structured as possible
– G5: Avoid OR routing elements
– G6: Use verb-object activity labels
– G7: Decompose a model with more than 50 elements
The Seven Modelling Guidelines for
Ensuring Pragmatic Quality
10
What is BPMN ?
• Business Process Modeling Notation or
Business Process Model and Notation ?
• The goals of BPMN (from BPMN 2.0 Spec):
“The primary goal of BPMN is to provide a notation that is readily
understandable by all business users, from the business analysts that create
the initial drafts of the processes, to the technical developers responsible for
implementing the technology that will perform those processes, and finally,
to the business people who will manage and monitor those processes. Thus,
BPMN creates a standardized bridge for the gap between the business
process design and process implementation.”
“Another goal, but no less important, is to ensure that XML languages
designed for the execution of business processes, such as WSBPEL (Web
Services Business Process Execution Language), can be visualized with a
business-oriented notation.”
11
OMG
History
12
• Started by BPMI, Business Process Modeling Initiative, a consortium
with mainly software companies
− Initially a graphical notation for process descriptions expressed in
Business Process Modeling Language (BPML).
− BPML is comparable to BPEL, i.e. process definitions expressed using
BPML can be executed by a BPMS.
• First version (1.0) produced in 2004 by BPMI
• BPMI merged into OMG in 2005
• OMG adopted BPMN 1.0 in 2006
• Version 1.1. in 2008, minor updates to graphical representation
• Version 1.2 in 2009, a bug fix, not much changed from version 1.1
• Version 2.0 in Jan. 2011
BPMN 1.0
(BPMI) BPMN 1.0 BPMN 1.1 BPMN 1.2 BPMN 2.0
History
• BPMN2.0
− Extends the graphic notation of version 1.2 by various model
constructs and a few new model types
− More importantly, a metamodel has been created to
1. formally define the semantics of the graphical notation
2. become the basis for developing BPMN’s own standardised XML
exchange format for transferring a BPMN model from one tool to another
3. Include extra language constructs that cannot be represented in graphic
models such that execution related information can be specified.
– Rules for transforming BPMN models into an executable BPEL
format
– Enhanced definition of executable processes in principle it is now
possible to directly executed detailed BPMN models, but still many
problems in practice
13
Business vs. Executable Models
• Business models:
– Focus on the comprehension of the basic process flow, so the usage
of too many details are avoided.
– For example, conditions of a decision are rather expressed in plain
text than in logic terms; exceptions and rare cases are quite often
not modelled in detail, but explained by notes and description.
• Executable models: – Contain sufficient details such that the models can be directly processed by
a BPMS engine, instead of converting to a computer program for execution
by a human being.
– The details in an executable model include:
• Process variables
• Task input and output data, and their mappings to variables
• Task performer assignment logic
• Conditional expressions
• Event definitions
• Messages
14
Business vs. Executable Models
• Apart from providing an official XML interchange format
for process models, another key goal of BPMN 2.0 to
make BPMN models executable in process engine
• Done by standardizing the representation of execution
related details in XML
• In terms of implementation of BPMN executable models,
two possible options for BPMS vendors:
– Implement their BPMS engine so that it can directly execute
BPMN models
– Use BPMN 2.0 model as an interchange format, i.e. each BPMS
has its own proprietary execution model, but the tool can
export/import execution-related details using BMPN 2.0 XML
15
Focus/Scope of BPMN
• As a multi-vendor standard, BPMN is a negotiated
agreement among many competing interests must
narrow its scope to do a smaller number of things well
instead of trying to cover everything
• The focus of BPMN is process logic, including the
order of activities, when they happen, and under what
conditions.
• A BPMN model does not describe how an activity is
performed or why
• A BPMN model:
– state what happens inside an activity (what the activity is may be
indicated by activity labels)
– really specify who performs an activity (maybe indicated by
activity labels and/or swimlanes)
16
BPMN Conformance
• Four types of conformance specified in BPMN2.0 – Process Modeling Conformance
– Process Execution Conformance
– BPEL Process Execution Conformance
– Choreography Modeling Conformance
• Software (BPMN tools) can claim compliance or
conformance with BPMN 2.0 if and only if the software
fully matches the applicable compliance points as stated
in the specification.
• A tool is said to have Complete Conformance if it
satisfies the requirements of all four types of
conformance
17
BPMN Conformance (cont’d)
• Three subclasses within Process Modelling Conformance – Descriptive (Level 1): visible elements for high-level modelling.
Essentially the shapes and symbols carried over from traditional
flowcharts
– Analytic (Level 2): Descriptive plus complex patterns, e.g. exceptions,
looping, complex gateways, signals, …
– Executable (Level 3): Analytic + information for execution specified using
the XML elements of BPMN.
• This course mainly concerns about process modelling using the
constructs within subclasses/levels 1 & 2, i.e. we focus on non-
executable processes modelling and rely on information visible in the
diagram only.
• For each of the two subclasses/levels, will look at: – the modelling constructs, called Palettes in the course
– the method & style to follow in order to create good BPMN models
18
Some important definitions
• Process: a sequence of tasks, decisions and events using
inputs with an aim an input and output. A complex process
can be broken down into groups of tasks and decision called
a Sub-process.
• Sub-process: a sequence of tasks, decisions and events
using inputs with an aim an input and output with a parent
process
• Task: the definitive part of a process that describes an
activity
• Decision: a change in the process sequence flow
• Procedure: a sequence of actions or instructions to be
followed in order to accomplish a task. • Source: Sherry, K (2012) Business Process Modelling with BPMN, Admaks.
20
Process Model Perspectives
• Process model, also known as process definition, or
case type, which may consist of: – a network of activities and their relationships,
– criteria to indicate the start and termination of the process
– information about the individual activities, such as performers,
associated IT applications and data, etc.
– references to sub-processes, separately defined
• There are 3 perspectives of a process definition: – Control-flow (or process) perspective: activities and the
ordering of their execution – Data perspective: how data is utilised during the process – Resource perspective: which work is offered to, allocated to and
managed by process participants
BPMN basic types of sub-models
• Processes (Orchestration), including:
– Private non-executable (internal) Business Processes
– Private executable (internal) Business Processes
– Public Processes
• Choreographies
• Collaborations, which can include Processes and/or
Choreographies
Source: OMG (2011) Business Process Model and Notation v2.0, Document Number: 2011-01-03 N
Before you start
Document process in narrative form capturing the details that
are required to produce a business process model.
Key headings are:
• Description
• Tasks
• Trigger(s)
• Inputs
• Outputs
• Business Rules
• Interfaces
Example
Assemble Components and Test
Description
This process accepts the order requirements, checks the parts
availability, produces a work order and proceeds to assemble
the product. After the product is tested it is moved to packaging
and shipping.
N.B: If parts are not available, then the required parts are
ordered. Testing could reveal bad components and therefore
new components must be ordered.
Example (continued)
Tasks
Check requirements and create a work order
Check order against inventory
Create delivery schedule
Assemble products
Create a new parts list order
Receive new parts
Test product
Deliver products to packaging
Example Continued
Trigger
Customer order requirements
Inputs
Order requirements document
Outputs
Computer products
Work order (completed)
Customer delivery schedule
Example (concluded)
Business rules
The computer products will be assembled and tested within 10
working days.
Customer is sent a product delivery schedule within two working
days of receiving the order requirements.
Customer is informed of any delays to the delivery schedule
within one (1) working day.
Interfaces
Customer
Parts supplier
Task
Task Sequence Flow
Process Flow
Activity
Start
Event
End
Event Sequence
Flow
Event (Trigger) Activity (Task) Sequence Flow
Process with Task Types
Source: OMG (2011) Business Process Model and Notation v2.0, Document Number: 2011-01-03
Example – Order Process with Exception Paths
XOR Gateway
32
• Two end events: Order failed and Order complete
• Three distinct paths from beginning to the end
Exclusive Gateway
• A diverging exclusive gateway (XOR-split) is used to create alternative
paths, i.e. only one of its outgoing sequence flows is enabled in a given
instance
• A converging exclusive gateway (XOR-join) is used to merge alternative
paths. For a given instance, each enabled incoming sequence flow is
routed through the gateway without synchronisation.
• In a BPMN diagram, the XOR-join diamond may be omitted.
Example:
Notes: With the above diagram, the XOR-split is not redundant because we need to model that only one option is taken after “Review claim”
Active if any
incoming
flow is
enabled
33
Exclusive Gateway
• An exclusive gateway does not “make” a decision
• Making a decision is an action, which needs to be
modelled using a task.
• An exclusive gateway just tests a data condition, which
should be the outcome of the “decision” task
34
XOR Gateway
Source: Sherry, K (2012) Business Process Modelling with BPMN, Admaks.
Parallel Gateway
Source: OMG (2011) Business Process Model and Notation v2.0, Document Number: 2011-01-03
Fork (Split) Join
N
Parallel Gateway
• A diverging parallel gateway (AND-split) creates parallel paths
without checking any conditions, and each outgoing sequence flow
is enabled upon execution of the gateway.
• A converging parallel gateway (AND-join) will wait for all incoming
flows before triggering the flow through its outgoing sequence flows.
• In a BPMN diagram, the AND-split diamond may be omitted.
Example:
37
Example – Parallel Split and Join
AND-split
38
• No need to label AND-splits or joins (nor the sequence flows
connecting them) as the labels do not add new information
• BPMN does not require all the paths out of an AND-split to be merged
in a downstream AND-join. These parallel paths may lead to separate
end events, in this case, each parallel must reach an end event before
the process level is completed.
AND-join
Parallel Gateway
• A diverging parallel gateway (AND-split) creates parallel paths
without checking any conditions, and each outgoing sequence flow
is enabled upon execution of the gateway.
• A converging parallel gateway (AND-join) will wait for all incoming
flows before triggering the flow through its outgoing sequence flows.
• In a BPMN diagram, the AND-split diamond may be omitted.
Example:
NOT
redundant
39
Parallel Gateway Summary
Fork or Split Join
Inclusive Gateways
Merging Gateway
Decision Gateway No decision
First input that
arrives allows
the process flow
to continue.
Outcome of
Task
determines
the path for
flow to
continue.
Inclusive Gateway Example
Event Gateway
Source: OMG (2011) Business Process Model and Notation v2.0, Document Number: 2011-01-03 N
• Is always followed by catching events or receive tasks.
• Sequence flow is routed to the subsequent event/task
which happens first.
Swimlanes
Swimlanes (continued)
Swimlanes (Continued)
Swimlanes and Black Boxes

Get help from top-rated tutors in any subject.
Efficiently complete your homework and academic assignments by getting help from the experts at homeworkarchive.com