The document proposes a graphical notation called BPMN+ for modeling business processes. It aims to be graphical and easy to use while also having formal semantics and being operational/executable. Key goals include being expressive, capable of distributed programming, and compatible with the existing BPMN standard. The notation is based on a Service Component Model and uses concepts like services, properties, and concurrent data objects. It also defines synchronization patterns like simultaneous, sequence, and alternative to model relationships between process steps.

1. A Graphical Notation for
Business Process Modeling
(BPMN+): Proposition
Ang Chen
SMV Seminar Vercorin
19.09.2008

2. Goals of the Language

3. Goals of the Language
• Graphical, easy to use, with formal
semantics

4. Goals of the Language
• Graphical, easy to use, with formal
semantics
• Operational, executable

5. Goals of the Language
• Graphical, easy to use, with formal
semantics
• Operational, executable
• Expressive

6. Goals of the Language
• Graphical, easy to use, with formal
semantics
• Operational, executable
• Expressive
• Can be used for distributed programming

7. Goals of the Language
• Graphical, easy to use, with formal
semantics
• Operational, executable
• Expressive
• Can be used for distributed programming
• BPMN compatible, executable BPMN

8. Service Component
Model (SCM)

9. Service Component
Model (SCM)
Properties
Provided
Services
Required
Services
SCM (References)
Component has
Services and
Properties

10. Service Component
Model (SCM)
Properties
Provided
Services
Required
Services
SCM (References)
SCM
SCM
Component has
Services and SCM
Properties

11. Service Component
Model (SCM)

12. Service Component
Model (SCM)
• Service: required/provided, synchronous/
asynchronous

13. Service Component
Model (SCM)
• Service: required/provided, synchronous/
asynchronous
• Property: concurrent data objects which hold
shared values between the process
instances, representing the observable
states of SCM

14. Service Signature

15. Service Signature
Method with 3
parameters
m(ParaType1, ParaType2, ParaType3)

16. Service Signature
Method with 3
parameters
m(ParaType1, ParaType2, ParaType3)
Output Event with
g(ParaType1, ParaType2, ParaType3)
3 parameters

17. Service Signature
Method with 3
parameters
m(ParaType1, ParaType2, ParaType3)
Output Event with
g(ParaType1, ParaType2, ParaType3)
3 parameters
Method with return
values (NEW!!)
m(?ReturnType1, ParaType2, ParaType3)

18. Component Services

19. Component Services
provided Service required
service Component service

20. Component Services
provided Service required
service Component service
provided Service required
service Component service

21. Component Services
provided Service required
service Component service
provided Service required
service Component service
Open
provided required
Service service
service
Component

22. Concurrent Data Objects
(example)

23. Concurrent Data Objects
(example)
atomic register
return(ret)
write(val)
read
read arc

24. Concurrent Data Objects
(example)
atomic register atomic register
read(?ret) write(val)
return(ret)
write(val)
read
read arc

25. Concurrent Data Objects
(example)
atomic register atomic register
read(?ret) write(val)
return(ret)
write(val)
read
read arc
compare and swap (CAS) atomic register
operation on register read write(val)
ret==old::CAS(old, new) with
read(?ret)..write(new) ..

26. Synchronizations

27. Synchronizations
simultaneous
//
//

28. Synchronizations
simultaneous
sequence
// ..
// ..

29. Synchronizations
simultaneous
sequence alternative
// .. +
// .. +

30. Synchronizations
simultaneous
sequence alternative
// .. +
// .. +
// and + are commutative

31. Synchronizations

32. Synchronizations
• T1//T2=T2//T1

33. Synchronizations
• T1//T2=T2//T1
• T1⊕T2=T2⊕T1

34. Synchronizations
• T1//T2=T2//T1
• T1⊕T2=T2⊕T1
• T1//T2//T3=T1//(T2//T3)=(T1//T2)//T3

35. Synchronizations
• T1//T2=T2//T1
• T1⊕T2=T2⊕T1
• T1//T2//T3=T1//(T2//T3)=(T1//T2)//T3
• T1⊕T2⊕T3=T1⊕(T2⊕T3)=(T1⊕T2)⊕T3

36. Synchronizations
• T1//T2=T2//T1
• T1⊕T2=T2⊕T1
• T1//T2//T3=T1//(T2//T3)=(T1//T2)//T3
• T1⊕T2⊕T3=T1⊕(T2⊕T3)=(T1⊕T2)⊕T3
• T1..T2..T3=T1..(T2..T3)=(T1..T2)..T3

37. DataFlow Modeling
with Synchronization

38. DataFlow Modeling
with Synchronization
modeling synchronous calls between methods/functions

39. DataFlow Modeling
with Synchronization
m2(y) m2(?x)
m1(?x,y) // m1(?x,y) ..
m3(?x) m3(x, y)
m2(?x) m2(?x)
m1(?x,y) + m1(?x+y) //
m3(?x, y) m3(?y)
modeling synchronous calls between methods/functions

40. Functional Computing

41. Functional Computing
f(0)=0
f(1)=1
f(x)=f(x-1)+f(x-2)

42. Functional Computing
x-1 x>1
?r,x f(?r,x)=f(x-1)+f(x-2)
f(0)=0
f(?r,x) ?r,x
f(1)=1 +
f(x)=f(x-1)+f(x-2) x x==0
x-2 f(0)=0
x
x==1
f(x)=1

43. Functional Computing
x-1 x>1
?r,x f(?r,x)=f(x-1)+f(x-2)
f(0)=0
f(?r,x) ?r,x
f(1)=1 +
f(x)=f(x-1)+f(x-2) x x==0
x-2 f(0)=0
x
x==1
f(x)=1
Each transition can have:
1. signature (mandatory)
2. conditions on input parameters (contract?)
3. a function defined on input/output parameters

44. Functional Computing
x-1 x>1
?r,x f(?r,x)=f(x-1)+f(x-2)
f(0)=0
f(?r,x) ?r,x
f(1)=1 +
f(x)=f(x-1)+f(x-2) x x==0
x-2 f(0)=0
x
x==1
f(x)=1
Each transition can have:
1. signature (mandatory)
2. conditions on input parameters (contract?)
3. a function defined on input/output parameters
Transitions can use/produce values from/to places (side-effect)

45. Transition which
returns value
m1(?x) atomic register
0 Read arc is used

46. Transition which
returns value
m1(?x) atomic register
0 Read arc is used
after transition m1(?x), x=0

47. Enabling & Execution
Rules

48. Enabling & Execution
Rules
• Transitions are enabled when necessary resources are ready
(conditions satisfied)

49. Enabling & Execution
Rules
• Transitions are enabled when necessary resources are ready
(conditions satisfied)
• Transitions are executed when it is called explicitly, e.g.
synchronized with other transitions, or triggered by user

50. Enabling & Execution
Rules
• Transitions are enabled when necessary resources are ready
(conditions satisfied)
• Transitions are executed when it is called explicitly, e.g.
synchronized with other transitions, or triggered by user
• Transactions (synchronized transitions) are atomic and run
instantly

51. Enabling & Execution
Rules
• Transitions are enabled when necessary resources are ready
(conditions satisfied)
• Transitions are executed when it is called explicitly, e.g.
synchronized with other transitions, or triggered by user
• Transactions (synchronized transitions) are atomic and run
instantly
• Side-effects of transaction are found in the places, if there are

52. Enabling & Execution
Rules
• Transitions are enabled when necessary resources are ready
(conditions satisfied)
• Transitions are executed when it is called explicitly, e.g.
synchronized with other transitions, or triggered by user
• Transactions (synchronized transitions) are atomic and run
instantly
• Side-effects of transaction are found in the places, if there are
In general activity is asynchronous, i.e. output is not synchronized with input
synchronous activities can be abstracted as functions

53. Enabling & Execution
Rules
• Transitions are enabled when necessary resources are ready
(conditions satisfied)
• Transitions are executed when it is called explicitly, e.g.
synchronized with other transitions, or triggered by user
• Transactions (synchronized transitions) are atomic and run
instantly
• Side-effects of transaction are found in the places, if there are
trigger event
Simple Activity
In general activity is asynchronous, i.e. output is not synchronized with input
synchronous activities can be abstracted as functions

54. Basic BPEL Patterns
Simple Activity JOIN XOR
T
T +
// + F
F WHILE
SPLIT IF ELSE

55. Example: Credit
Variables
Approval
RequestT: request
RiskT: risk
ApprovalT: approval
Partners: customer, assessor, approver

56. Example: Credit
Variables
Approval
RequestT: request RequestT RiskT ApprovalT
String firstname String level String message
RiskT: risk String name
ApprovalT: approval int: amount
Partners: customer, assessor, approver

57. Example: Credit
Variables
Approval
RequestT: request RequestT RiskT ApprovalT
String firstname String level String message
RiskT: risk String name
ApprovalT: approval int: amount
Partners: customer, assessor, approver Receive
customer->request(request)
request>=1000
request.amount <1000
Approval
Assess
risk.level!="low" approval=approver->approve(request)
risk=assessor->check(request)
risk.level=="low"
SetMessage
approval.accept="yes"
Reply
customer->request(approval)

58. request(request)
Receive
Abstract
Flow
amount<1000 amount>=1000
Assess
risk not low
risk low
SetMessage Approval
Reply
request(approval)

59. request(request)
Receive
+
request.amount<1000 request.amount>=1000
request
Concretized Assess request
..
Flow check(?risk, request)
+
risk.level==low risk.level!=low
Approval
SetMessage
..
..
approve(?approval, request)
approval.accept="yes"
approval
approval
Reply
request(approval)

60. Summary

61. Summary
• Service Component Model (SCM): building
blocks for (business) process modeling
• Transition with return values
• Concurrent data objects for distributed
information management
• Synchronized transitions for functional
computing and Data-Flow modeling

62. Next Steps
• Complete formalized semantics of the
synchronizations on model-composition
• Relation with ID-Net, e.g. variable->ID
• Find a way to manage distributed relational
data with concurrent data objects, i.e. find
good atomic primitives

63. Wait-free
synchronization
• Maurice Herlihy, Digital Equipment Corporation. “Wait-Free
Synchronization”, ACM Transactions on Programming Languages
and Systems,Vol. 13, Issue 1, 1991. Won the Edsger W. Dijkstra
Prize in Distributed Computing 2003
• Maurice Herlihy. “Impossibility and universality results for wait-
free synchronization”. Annual ACM Symposium on Principles of
Distributed Computing, 1988
• They have significant impacts on the theory and practices of
distributed computing

64. Wait-free Hierarchy
Processes Concurrent Data Object & atomic primitives
1 read/write registers
2 test-and-set, swap, fetch-and-add, queue, stack
...
2n-2 n-register assignment
...
memory-to-memory move and swap, compare-
Unbounded
and-swap
an object is universal iff. it can solve consensus

65. Universal Objects
(Atomic Primitives)
• Most implemented in hardwares
(microprocessors)
• Compare and Swap
• Load-Link / Store-Conditional