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 Task Types

N

Process with Task Types

Source: OMG (2011) Business Process Model and Notation v2.0, Document Number: 2011-01-03

Gateway Types

N

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