BPMN with UML Virtual Training

<slideshow style="nobleprog" headingmark="⌘" incmark="…" scaled="false" font="Trebuchet MS" >

title

Understanding Business Process Modeling with BPMN 2.0

author

Bernard Szlachta

</slideshow>

Course Objectives⌘

Objective

This training course aims at helping business analysts to learn to model efficiently their business processes using BPMN as well as resources that are handled by their activities. Being conducted by an agile enterprise framework, business analysts learn during this course how to use appropriate BPMN notations and business extensions of UML in order to deal with their "business requirements" and coherently drive underlying design level activities.

Course Duration

14 hours (2 days for 7 hours including breaks)

Introduction ⌘

Total Quality Management (TQM) ⌘

• (1950s) William Edwards Deming an American engineer, statistician, and management consultant
• Inspiration for the Japanese post-war economic miracle (from the ashes of war to the second most powerful economy in the world in less than a decade)
• TQM Principles:
  • Focus on work processes
  • Analysis of variability
  • Management by fact
  • Learning and continuous improvement

Business Process Reengineering (BPR)⌘

• (1990s) Aimed to help organizations fundamentally rethink how they do their work in order to dramatically improve customer service, cut operational costs, and become world-class competitors
• The scope of radical BPR is to reshape the way that entire organization does business
• Michael Hammer: "Most of the work being done does not add any value for customers, and this work should be removed."
• BPR was a way to dehumanize the work place, increase managerial control, and to reduce of the work force (downsizing)

Six Sigma⌘

• (1986) Six Sigma is a set of techniques and tools for process improvement.
• It seeks to improve the quality output of process by identifying and removing the causes of defects (errors) and minimizing variability in manufacturing and business processes.

Business process management (BPM)⌘

• Processes are the fundamental building blocks that have been hidden; now they must be made visible, explicit and transparent to all stakeholders, so they can be improved and optimized

The Process Perspective⌘

The Business Process Perspective means:

• thinking in terms of big picture, in terms of the process not the software
• designing and documenting business processes (easier to find your role and how it fits into the big picture)
• continuous process improvement
• process-centric organization responsive to market requirements

Process Management⌘

Process management is the application of knowledge, skills, tools, techniques and systems to define, visualize, measure, control, report and improve processes with the goal to meet customer requirements profitably.

Process Modeling Analysis & Design⌘

BPM Lifecycle⌘

Marlon Dumas, Fundamentals of Business Process Management

BPM Lifecycle⌘

• The first question is "What business processes are we intending to improve?"
• The initial phase is called process identification - start by at identifying the processes that are relevant to the problem, delimiting the scope of these processes, and identifying relations between these processes (e.g. one process being part of another process)
• Process architecture takes the form of a collection of processes and links between these processes representing different types of relation.
• “You can’t control what you can’t measure”. Before starting to analyze any process in detail, it is important to clearly define the process performance measures (metrics) that will be used to determine whether a process is in “good shape” or in “bad shape”.

BPM Lifecycle⌘

• Having understood the as-is process in detail, the next step is to identify and analyze the issues in the process.
• Process Analysts collect information about the time spent in each task of the process: the amount of time that process participants spend actually doing work or waiting for something to happen.
• Process redesign is to identify and analyze potential solutions for the issues.
• Process implementation may involve organizational change management and process automation.
• "Every good process eventually becomes a bad process" - the process needs to be monitored, managing a process requires a continuous effort.

Stakeholders in the BPM Lifecycle⌘

Management Team CEO, COO, CIO, CFO, HR director	Chief Executive Officer (CEO) responsible for the overall business success of the company.
Process Owner	Responsible for the efficient and effective operation of a given process.
Process Participants	Human actors who perform the activities of a business process on a day-to-day basis.
Process Analysts	Conduct process identification, discovery, analysis and redesign activities. They coordinate process implementation as well as process monitoring and controlling.
System Engineers	Involved in process redesign and implementation. They interact with process analysts to capture system requirements.

Ownership of Processes⌘

• Developing roles and responsibilities for process is often difficult.
• It commonly begins with the question of ownership and responsibility as an organization begins to understand the value of process and implement actions to manage those processes.
• Assignment of process ownership is one of the indicators of an increasing level of process maturity.

Process Owner Responsibilities⌘

The Process Owner is responsible for the governance of process performance and process change — and specifically:

• Defines the process mission, vision, tactics, goals, objectives, KPIs (Key Performance Indicators), and the measures that are aligned with the organization strategies.
• Monitors and reports process performance against KPIs and health versus plans.
• Synchronizes process improvement plans with other process owners within the value chain and other interfacing processes.
• Ensures appropriate process designs, including the correct business requirements.
• Defines and sponsors business process change and capability investments, which continuously increase the maturity of the process and sustain each level of maturity.

Process Owner Skills & Capabilities⌘

BPMN Elements⌘

The five basic categories of elements ⌘

1. Flow Objects
2. Data Objects
3. Connecting Objects
4. Swimlanes
5. Artifacts

Flow Objects ⌘

Flow Objects are the main graphical elements to define the behavior of a Business Process

1. Events
2. Activities
3. Gateways

Data ⌘

1. Data Objects
2. Data Inputs
3. Data Outputs
4. Data Stores

Connecting Objects ⌘

There are four ways of connecting the Flow Objects to each other or other information

1. Sequence Flows
2. Message Flows
3. Associations
4. Data Associations

Swimlanes ⌘

1. Pools
2. Lanes

Artifacts ⌘

Artifacts are used to provide additional information about the Process

1. Group
2. Text Annotation

Business Process Management Systems (BPMS)⌘

BPMS Key Drivers and Objectives 1⌘

• Lower Business Costs and Increased Efficiency
  • BPM products support the automation of repetitive steps, integrating application systems as needed, and supporting complex decision-making. As a result, they provide a platform upon which firms can lower their fundamental operating costs while enhancing the value delivered.
• Increased Adaptability, Flexibility, and Nimbleness (agility)
  • Effective BPM infrastructure will allow the firm to develop new products and services far more quickly than was previously possible.
• Lower Cost of Systems Development and Support
  • Modern BPM products provide increased developer productivity, significantly lowering the cost of systems development.

BPMS Key Drivers and Objectives 2⌘

• Lower Systems Implementation Risks
  • By modeling an entire process and then making incremental, evolutionary changes, managers are able to introduce change with lower risk.
• Better Governance and Compliance
  • BPM technology can control the ways in which decisions are made and modifications to the process are introduced ensuring compliance and effective governance.
• Better Customer Service
  • BPMS provides the glue to tie together disparate channels of customer interaction.

Processing Modeling⌘

• This is the area where the effective capabilities of the product are most apparent – it is where the semantics of the vendor’s interpretation of process are made visible.
• A key issue here is the degree of accessibility of the environment and the amount of IT specialist support required.

The BPM Technology Continuum⌘

Derek Miers and Paul Harmon, Introduction to Evaluating BPMS Suites, Figure 3

• If you start with a language like Java, you can build any kind of BPM system you want. But it takes a lot of work, using only a language, to build a system.
• As you move from left to right, the products become more structured and provide more ready-made components, making it easier and faster to develop finished applications.

The BPM Stack⌘

The BPM Stack⌘

Each layer sits on top of a lower level, using technologies defined at the lower level while adding additional utilities to integrate the levels below, to provide a more general functionality.

Business Process⌘

BPMN 2.0 Spec:

A Process describes a sequence or flow of Activities 
in an organization with the objective of carrying out work.

Process Logic⌘

by Bruce Silver

• Process Logic (Process Model) is a complete map of all the paths from the triggering event to any defined end state.
• Process Model is more than documentation of one instance of the process.
• Process logic is usually hidden.

Conformance⌘

Software based on spec

• software developed only partially matching compliance/conformance

Modeling Conformance

• Process modeling
• Choreography modeling

Execution Conformance

• Process Execution
• BPEL Process Execution

Tool can comply only to one of the above or any subset of them.

Sub-models within an end-to-end BPMN model ⌘

1. Processes (Orchestration)
   • Private non-executable (internal) BP
   • Private executable (internal) BP
   • Public Processes
2. Choreographies
3. Collaborations (can include Processes and Choreographies
   • Conversations

BPMN and WSBPEL ⌘

• WSBPEL can organize complex Business Processes in a complex, disjointed, and unintuitive format that is handled very well by a software system (or a computer programmer)
• WSBPEL is hard to understand by the business analysts and managers

BPMN 2.0 compared to BPMN 1.2 ⌘

• Formalizes the execution semantics for all BPMN elements
• Defines an extensibility mechanism
• Refines Event composition and correlation
• Extends the definition of human interactions
• Defines a Choreography model

BPMN Sub-models ⌘

1. Orchestration
   • Private non-executable (internal) Business Processes
   • Private executable (internal) Business Processes
   • Public Processes
2. Choreographies
3. Collaborations, which can include Processes and/or Choreographies
   • A view of Conversations

Private (Internal) Business Process⌘

• Internal to a specific organization
• Other names:
  • Workflow
  • BPM Processes
  • Orchestration of services
• Can be executable and non-executable
• Contained within a single Pool
• The flow of Messages can cross the Pool boundary to show the interactions that exist between separate private Business Processes

Public Process ⌘

• Represents the interactions between a private Business Process and another Process or Participant
• Only those Activities that are used to communicate to the other Participant(s) are included in the public Process
• All other “internal” Activities of the private Business Process are not shown
• Public Process shows to the outside world the Message Flows and the order of those Message Flows that are needed to interact with that Process
• Public Processes can be modeled separately or within a Collaboration to show the flow of Messages between the public Process Activities and other Participants
• Called “abstract” in BPMN 1.2.
• Public Process is orchestrated by the private processes (as oppose to Collaboration)

Collaboration⌘

• Depicts the interactions between two or more business entities
• Contains two or more Pools
• Can be shown as two or more public Processes communicating with each other
• The corresponding internal (executable) Processes are likely to have much more Activity and detail than what is shown in the public Processes.

Choreography⌘

• Definition of the expected behavior
• B procedural contract between interacting Participants
• A self-contained Choreography have no Pools or Orchestration
• Choreography exists between Pools (or Participants)
• The Choreography Activities are interactions that represent a set (1 or more) of Message exchanges, which involves two or more Participants
• There is no central controller, responsible entity or observer of the Process

Conversation ⌘

• The Conversation diagram is a particular usage of and an informal description of a Collaboration diagram
• Pools of a Conversation usually do not contain a Process and a Choreography is usually not placed in between the Pools of a Conversation diagram
• A Conversation is the logical relation of Message exchanges
• Message exchanges are related to each other and reflect distinct business scenarios
• Conversation Diagram Provides a “bird’s eye” perspective of the different Conversations that relate to the domain

Levels of BPMN Process Modeling⌘

by Bruce Silver - Three Levels of Process Modeling with BPMN, BPMS Watch, April 2008

• Descriptive modeling
  • Abstract, high-level, simple to communicate across the organization
  • Requires understanding of fundamental concepts such as pools and lanes, tasks and subprocesses and sequence flow, not the complexities of BPMN's various flow control and event patterns
• Analytical modeling
  • More details, showing all the steps, including the exception paths required to analyze process performance using simulation or to create details requirements for an IT implementation. Requires understanding of BPMN's various decisions and merge patterns, event and exception handling patterns. Hierarchical representation of the end to end business process
• Executable modeling
  • BPMN is a part of the executable process implementation. Imposes many validation constraints.
  • Modeling at this level is somewhat vendor tool-dependent.

Descriptive modeling⌘

BPMN Activity⌘

An Activity

• is work that is performed within a Business Process
• can be atomic or non-atomic (compound)
• represent points in a Process flow where work is performed
• is executable element of a BPMN process

Types of Activities⌘

• Task
  • an atomic Activity within a Process flow
  • is used when the work in the Process cannot be broken down to a finer level of detail
• Sub-Process
  • compound activity
    • Event Sub-Process
    • Transaction
    • Ad-Hoc
• Call Activity
  • allows the inclusion of re-usable Tasks and Processes in the diagram

Types of Sub-Processes⌘

Sequence Flow⌘

A Sequence Flow is used to show the order that Activities will be performed in a Process.

Token ⌘

• Token traverses the Sequence Flows and passes through the elements in the Process
• A token is a theoretical concept that is used as an aid to define the behavior of a Process that is being performed
• The behavior of Process elements can be defined by describing how they interact with a token as it “traverses” the structure of the Process.
• A token does NOT traverse a Message Flow

Sequence Flow Splitting⌘

• Conditional flow - sequence flow with a condition that is evaluated to determine whether or not the sequence flow will be used
• Default flow - used only if all the other outgoing conditional flows are not true

Basic BPMN Flow Objects⌘

Quiz⌘

BPMN Elements Quiz

BPMN_2.0_Elements_Quiz1

BPMN General Quiz

BPMN_2.0_Introduction#Quiz_.E3.80.82

BPMN Concepts for Analysts ⌘

Gateways ⌘

Gateways are used to control splitting and merging of sequence flows. do not represent ‘work’ being done are considered to have zero effect on the operational measures of the process (cost, time, etc.). two types of gateways: converge and diverge are optional

Exclusive Gateway ⌘

        

XOR Gateway

• A diverging Exclusive Gateway (Decision) is used to create alternative paths within a Process flow
• Only one of the paths can be taken, this means the gateway is exclusive
• A Decision can be thought of as a question that is asked at a particular point in the Process
• The question has a defined set of alternative answers
• Each answer is associated with a condition Expression that is associated with a Gateway’s outgoing Sequence Flows

Exclusive Gateway Example⌘

or

Merging (exclusive)⌘

Parallel Gateway ⌘

AND Gateway

• A Parallel Gateway is used to create or synchronize (combine) parallel flows
• A Parallel Gateway creates parallel paths without checking any conditions; each outgoing Sequence Flow receives a token upon execution of this Gateway
• For incoming flows, the Parallel Gateway will wait for all incoming flows before triggering the flow through its outgoing Sequence Flows

Parallel Gateway Example 1⌘

or

Parallel Gateway Example 2⌘

• Demonstration - splitting and merging

Inclusive Gateway ⌘

OR Gateway

• A diverging Inclusive Gateway (Inclusive Decision) can be used to create alternative but also parallel paths within a Process flow
• Unlike the Exclusive Gateway, all condition Expressions are evaluated
• The true evaluation of one condition Expression does not exclude the evaluation of other condition Expressions
• All Sequence Flows with a true evaluation will be traversed by a token
• Since each path is considered to be independent, all combinations of the paths MAY be taken, from zero to all
• However, it should be designed so that at least one path is taken.

Inclusive Gateway Example 1⌘

Inclusive Gateway Example 2⌘

Gateways Quiz ⌘

BPMN_2.0_Gateways_Quiz

Events ⌘

An Event is something that “happens” during the course of a Process.

• Events affect the flow of the Process and usually have a cause or an impact. The term “event” is general enough to cover many things in a Process.
• The start of an Activity, the end of an Activity, the change of state of a document, a Message that arrives, etc., all could be considered Events

• Types of events:
  1. Start Events - indicate where a particular Process will start
  2. Intermediate Events - indicate where something happens (an Event) somewhere between the start and end of a Process
     • Boundary Intermediate Events - attached to the boundary of an Activity
  3. End Events - indicate where a Process will end

Events Example⌘

None Events⌘

• None Event does not have a defined trigger or result.
• The Event MUST be displayed without a marker
• None Start Event starts the process and generates new token
• None End Event ends a particular flow and consumes the token

Pool and Participant⌘

• The pool shape represents a participant.
• A Lane is a sub-partition within within a Pool.
• Lanes are used to organize and categorize Activities.
• The meaning of the Lanes is up to the modeler.
• Lanes are often used for such things as internal roles (e.g., Manager, Associate), systems (e.g., an enterprise application), an internal department (e.g., shipping, finance),

Message Flows ⌘

• A Message Flow is used to show the flow of Messages between two Participants that are prepared to send and receive them.
• A Message Flow MUST connect two separate Pools. They connect either to the Pool boundary or to Flow Objects within the Pool boundary. They MUST NOT connect two objects within the same Pool.

Demonstration ⌘

• Pool, Lane, Blackbox

4 Basic Message Events ⌘

Four basic message event types.

Message Events Example⌘

Timer Events ⌘

• Expresses a time gap in processing or a wait for a period of time.
• Start Timer – start on specific date (Monday at 9am, etc..)
• Intermediate Timer - a specific time-date or a specific cycle (e.g., every Monday at 9am)
• If used in the main flow it acts as a delay mechanism

Timer Example 1⌘

Timer Example 2⌘

Interrupting vs. Non-Interrupting⌘

Event-Based Exclusive Gateway⌘

• The Event-Based Gateway represents a branching point in the Process where the alternative paths that follow the Gateway are based on Events that occur
• This is opposed to the evaluation of Expressions using Process data (as with an Exclusive or Inclusive Gateway which are Data Based)
• A specific Event, usually the receipt of a Message, determines the path that will be taken
• Basically, the decision is made by another Participant, based on data that is not visible to Process, thus, requiring the use of the Event-Based Gateway.

Example⌘

• A company is waiting for a response from a customer they will perform one set of Activities if the customer responds “Yes” and another set of Activities if the customer responds “No.”
• The customer’s response determines which path is taken
• The identity of the Message determines which path is taken
• That is, the “Yes” Message and the “No” Message are different Messages

Example⌘

• The receipt of the Message can be modeled with an Intermediate Event with a Message trigger or a Receive Task
• In addition to Messages, other triggers for Intermediate Events can be used, such as Timers

or

Event-Based Gateway Starts a Process⌘

Artifacts ⌘

Artifacts are used to provide additional information about the Process

1. Group
2. Text Annotation

Group ⌘

• Provides a visual mechanism to group elements of a diagram informally.
• Group can be used for documentation or analysis purposes.
• Groups do not affect the flow of the Process.

Text Annotation ⌘

• Is a mechanism for a modeler to provide additional information for the reader of a BPMN Diagram
• The Text Annotation object can be connected to a specific object on the Diagram with an Association
• Does not affect the flow of the Process

Types of Tasks ⌘

Receive Task ⌘

• Waits for a Message to arrive from an external Participant
• Once the Message has been received, the Task is completed

• Starts the process
• MUST NOT have any incoming Sequence Flow
• Instantiate attribute MUST be set to true

Send Task ⌘

• Sends a Message to an external Participant.
• Once the Message has been sent, the Task is completed.

Service Task ⌘

• uses some sort of service, which could be a Web service or an automated application.

User Task ⌘

• A typical “workflow” Task where a human performer performs the Task with the assistance of a software application
• Examples:
  • Phone operator updates customer record
  • User changes his password

Manual Task ⌘

• Is expected to be performed without the aid of any business process execution engine or any application
• Example:
  • A telephone technician installing a telephone at a customer location

Business Rule Task ⌘

• Provides a mechanism for the Process to provide input to a Business Rules Engine and to get the output of calculations that the Business Rules Engine might provide

Script Task ⌘

• Is executed by a business process engine
• The modeler or implementer defines a script in a language that the engine can interpret
• When the Task is ready to start, the engine will execute the script
• When the script is completed, the Task will also be completed.

Asynchronous Communication - tasks⌘

Asynchronous Communication - events⌘

Synchronous Communication ⌘

Parallel Event-Based Gateway⌘

• All events must occur before a process can start

Complex Gateway⌘

• The Complex Gateway can be used to model complex synchronization behavior
• For example, it could specify that tokens on three out of five incoming Sequence Flows are needed to activate the Gateway.

Data Modeling⌘

• Data modeling is used to describe physical or information items that are created, manipulated, and used during the execution of a Process.
• Data can be modeled using: Data Objects, Data Inputs, Data Outputs, Data Stores, Data Associations, ....

Data Objects⌘

• The primary construct for modeling data within the Process flow.
• Data Associations are used to move data between Data Objects.
• Tokens do not flow along a Data Association.

Data Input, Data Output⌘

• Activities and Processes often need data in order to execute.
• In addition they can produce data during or as a result of execution.
• Data requirements are captured as Data Inputs.
• Data that is produced is captured using Data Outputs.

Data Store⌘

• A DataStore provides a mechanism for Activities to get or update stored information that will persist beyond the scope of the Process.
• Represents a single unit of information (e.g. database record)

Link Events⌘

• A Link is a mechanism for connecting two sections of a Process.
• Link Events can be used to avoid long Sequence Flow lines.
• The use of Link Events is limited to a single Process level (i.e., they cannot link a parent Process with a Sub-Process or one pool to another pool).
• There can be multiple source Link Events, but there can only be one target Link Event.

Link Events Example ⌘

Link Events as Off-Page Connector⌘

Signal Events⌘

• A Signal is for general communication within and across Process levels, across Pools, and between Business Process Diagrams.
• A BPMN Signal is similar to a signal flare that shot into the sky for anyone who might be interested to notice and then react. Thus, there is a source of the Signal, but no specific intended target.

Signal Event Example 1⌘

Signal Event Example 2⌘

Error Events⌘

• An Error is generated when there is a critical problem in the processing of an Activity or when the execution of an Operation failed
• An Error indicates that a named Error should be generated.
• Process can't wait for an error or raise an error in intermediate event (only in Boundary Intermediate)
• Process can't be instantiated using error event (only in Event Sub-Process)

Error Events Example 1⌘

Error Events Example 2⌘

Error Events Example 3⌘

Escalation Events⌘

• An Escalation identifies a business situation that a Process might need to react to.
• In contrast to an Error, an Escalation by default is assumed to not abort the Activity to which the boundary Event is attached.

Escalation Example⌘

Compensation⌘

• Compensation is undoing steps that were already successfully completed, because their results and possibly side effects are no longer desired and need to be reversed.
• If an Activity is still active, it cannot be compensated, but rather needs to be canceled.
• Compensation is not an error handling
• A compensation handler performs the steps necessary to reverse the effects of an Activity.

Compensation handler⌘

• A compensation handler connected via a boundary Event can only perform “black-box” compensation of the original Activity.
• Compensation Activity is connected to the boundary Event through an Association.
• The Compensation Activity can be either a Task or a Sub-Process, has a marker to show that it is used for compensation only and is outside the normal flow of the Process.

Compensation Using Event Sub-Process⌘

A Compensation Event Sub-Process can access data that is part of its parent, and can recursively trigger compensation for Activities contained in its parent.

Transaction⌘

• Is a specialized type of Sub-Process that will have a special behavior that is controlled through a transaction protocol.
• Transaction verifies if all of the participants have successfully completed their end of the transaction or have been restored to the equivalent of their original state.
• ACID model describes transactions:
  • Atomic - transaction is "all or nothing": if one part of the transaction fails, the entire transaction fails, and the system state is left unchanged.
  • Consistent - any transaction will bring the system from one valid state to another.
  • Isolated - concurrent execution of transactions results in a system state that would be obtained if transactions were executed serially, i.e. one after the other.
  • Durable - once a transaction has been committed, it will remain so, even in the event of power loss, crashes, or errors.

Transaction in BPMN⌘

Three basic outcomes of a Transaction:

• Success
• Cancel
• Error

Collapsed Transaction Sub-Process⌘

Cancel Events⌘

• Cancel Events are only used in the context of modeling Transaction Sub-Processes
• Activities indicated by sequence flow from cancel event will be executed after transaction is rolled back

Loops and multi-instance⌘

Standard Loop ⌘

• The Activity will loop as long as the boolean loopCondition is true
• The condition is evaluated for every loop iteration, and MAY be evaluated at the beginning or at the end of the iteration (testBefore = true or testBefore = false)
• In addition, a numeric cap can be optionally specified - loopMaximum
• Loop activity instances are sequentially executed - one after another.
• Loop Activity is similar to DO WHILE loop.

Multi-Instance Activity⌘

Multi-Instance parallel

Multi-Instance sequential

• The instances MAY execute in parallel or MAY be sequential.
• Multi-Instance Activities are used with collection of items
• Multi-Instance Activity is similar to FOR EACH loop

Multi-Instance Activity Example⌘

Global Task and Global Process⌘

• A Global Task is a reusable, atomic Task definition that can be called from within any Process by a Call Activity.
• A Global Task is not defined within a Process, but is callable element.

• The types of Global Tasks are only a subset of standard Tasks types: GlobalUserTask, GlobalManualTask, GlobalScriptTask, and GlobalBusinessRuleTask
• A Global Process can be called from another Process.
  • Question: Do you know any example of non-global process?

Call Activity⌘

• A Call Activity is a type of Activity that identifies a point in the Process where a global Process or a Global Task is used.

Events Quiz ⌘

BPMN_2.0_Events_Quiz

Artifacts Quiz ⌘

BPMN_2.0_Artifacts_Quiz

Process, Collaboration, Choreography and
Conversation in BPMN 2.0⌘

Process - again⌘

A Process describes a sequence or flow of Activities
in an organization with the objective of carrying out work.

• Process is depicted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and Sequence Flows that define finite execution semantics.
• BPMN uses the term Process specifically to mean a set of flow elements
• It uses the terms Collaboration and Choreography when modeling the interaction between Processes

Types of BPMN Processes ⌘

There are three basic types of BPMN Processes (Orchestrations):

• Private Non-executable (internal) Business Processes
• Private Executable (internal) Business Processes

• Public Processes

Collaboration⌘

• Collaboration is a collection of Participants shown as Pools, their interactions as shown by Message Flows, and MAY include Processes within the Pools and/or Choreographies between the Pools
• A Choreography is an extended type of Collaboration

Choreography⌘

• A Choreography defines the sequence of interactions between Participants (Pools).
• Choreographies exist outside of or in between Pools.
• Choreography does not exist in a single Pool. Each step in the Choreography involves two or more Participants.
• A Choreography does not have a central control mechanism.

Choreography Example 1⌘

Choreography Task⌘

• A Choreography Task is an atomic Activity in a Choreography Process.
• It represents an Interaction, which is one or two Message exchanges between two Participants.

Choreography Task with a Message⌘

Two-way Choreography Task⌘

Sequence Flow⌘

Gateways⌘

• Interactions between Participants can happen in sequence, in parallel, or through exclusive selection.
• Exclusive, Inclusive, Parallel, Event-based and Complex Gateways can be used with some constraints (because the lack of a central mechanism to maintain data visibility, and no central evaluation)

Exclusive Gateway Example⌘

Choreography Example 2 from spec⌘

Business Process Model and Notation (BPMN), Version 2.0, pages 318-319

Choreography Example 2 from spec⌘

Conversations⌘

• The Conversation diagram is particular usage of a Collaboration diagram (simplified version of Collaboration)
• Pools usually are empty.
• A Conversation is a logical grouping of Message exchanges

Conversation Example⌘

Workflow Patterns ⌘

Workflow (Control Flow) Patterns ⌘

1. Basic Control-Flow Patterns
2. Advanced branch and join patterns
3. Structural Patters
4. Multiple instances patterns
5. State-based patterns
6. Cancellation patterns

Workflow (Control Flow) Patterns ⌘

1. Basic Control-Flow Patterns
   • Sequence
   • Parallel Split
   • Synchronization
   • Exclusive Choice
   • Simple Merge
2. Advanced branch and join patterns
   • Multi-Choice
   • Structured Synchronizing Merge
   • Multi-Merge
   • Structured Discriminator)
3. Structural Patters
   • Arbitrary Cycles
   • Implicit Termination
4. Multiple instances patterns
   • Multiple Instances without Synchronization
   • Multiple Instances with a priori Design-Time Knowledge
   • Multiple Instances with a priori Run-Time Knowledge
   • Multiple instances without a priori run-time knowledge
5. State-based patterns
   • Deferred Choice
   • Interleaved Parallel Routing
   • Milestone
6. Cancellation patterns
   • Cancel Activity
   • Cancel Case

New Control-Flow Patterns ⌘

1. Structured Loop
2. Recursion
3. Transient Trigger
4. Persistent Trigger
5. Cancel Region
6. Cancel Multiple Instance Activity
7. Complete Multiple Instance Activity
8. Blocking Discriminator
9. Cancelling Discriminator
10. Structured Partial Join
11. Blocking Partial Join
12. Cancelling Partial Join
13. Generalized AND-Join
14. Static Partial Join for Multiple Instances
15. Cancelling Partial Join for Multiple Instances
16. Dynamic Partial Join for Multiple Instances
17. Acyclic Synchronizing Merge
18. General Synchronizing Merge
19. Critical Section
20. Interleaved Routing
21. Thread Merge
22. Thread Split
23. Explicit Termination

Basic Patterns: Sequence ⌘

AKA: Sequential routing, serial routing

Basic Patterns: Parallel Split ⌘

AKA: AND-split, parallel routing, parallel split, fork

Basic Patterns: Synchronization ⌘

AKA: AND-join, rendezvous, synchronizer

Basic Patterns: Exclusive Choice ⌘

AKA: XOR-split, exclusive OR-split, conditional routing, switch, decision, case statement

Basic Patterns: Simple Merge ⌘

AKA: XOR-join, exclusive OR-join, asynchronous join, merge.

Basic Patterns: Multi-Choice ⌘

AKA: Conditional routing, selection, OR-split, multiple choice.

Basic Patterns: Structured Synchronizing Merge ⌘

AKA: Synchronizing join, synchronizer.

Basic Patterns: Multi-Merge ⌘

AKA: None

Basic Patterns: Structured Discriminator ⌘

AKA: 1-out-of-M join.

Basic Patterns: WCP-10 Arbitrary Cycles ⌘

AKA: Unstructured loop, iteration, cycle.

Structural Patterns ⌘

Basic Patterns: Implicit Termination ⌘

AKA: None.

Basic Patterns: Multiple Instances without Synchronization ⌘

AKA: Multi threading without synchronization, spawn off facility.

Basic Patterns: Multiple Instances with a priori Design-Time Knowledge ⌘

AKA: None.

Basic Patterns: Multiple Instances with a priori Run-Time Knowledge ⌘

AKA: None.

Basic Patterns: Multiple instances without a priori run-time knowledge ⌘

AKA: None.

Basic Patterns: Deferred Choice ⌘

AKA: External choice, implicit choice, deferred XOR-split.

Basic Patterns: Interleaved Parallel Routing ⌘

AKA: None.

• A set of activities has a partial ordering defining the requirements with

respect to the order in which they must be executed

• Each activity in the set must be executed once and they can be completed in any order that accords with the partial order
• However, as an additional requirement, no two activities can be executed at

the same time (i.e. no two activities can be active for the same process instance at the same time)

Basic Patterns: Milestone ⌘

AKA: Test arc, deadline, state condition, withdraw message.

Basic Patterns: Cancel Activity ⌘

AKA: Withdraw activity.

Basic Patterns: Cancel Case ⌘

AKA: Withdraw case.

BPMN 2.0 Summary ⌘