INFS 5108

Panallo

2018SlidesBPMN-2.pdf

Home >Business & Finance homework help >Operations Management homework help >INFS 5108

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

Events

For now, we only look at

the 8 level 1 events,

including: • Start: none, message, timer,

and multiple

• End: none, message,

terminate, multiple

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

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

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

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.

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

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

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

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.

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

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

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

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

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

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.

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.

Style Rules

5. Model internal organisational units as lanes within a single

process pool, not as separate pools. Separate pools imply

independent processes.

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.

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

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.

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

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.

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.

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.

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

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.

References

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.

http://www.omg.org/spec/BPMN/2.0/

BPMN: modelling constructs,

method and style – Level 2

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

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

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

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

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

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

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

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

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.

• 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:

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

Intermediate Event – Message Event, Example

• 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

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:

− 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

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

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)

Intermediate Event – Cancel & Compensation Events, and Transaction

• 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

• 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)

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

Using Repeated Activities

• What is the problem

with the model on the

right ?

• A valid but impractical correction

• A more practical model

• 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

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:

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.

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

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.

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.

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

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

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

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

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

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.

http://www.omg.org/spec/BPMN/2.0/

Readings

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/

http://www.omg.org/spec/BPMN/20100601/10-06-02.pdf

http://www.omg.org/spec/BPMN/2.0/examples/ZIP

http://www.omg.org/spec/BPMN/2.0/

COMMONWEALTH OF AUSTRALIA

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.