The document discusses modeling and validating BPMN diagrams. It proposes a simplified metamodel for BPMN 1.1 that addresses weaknesses in the original specification such as inconsistent hierarchical structure and lack of validation support. The proposed metamodel includes a self-validating XML serialization and automated checks to validate BPMN diagrams. It also discusses how the approach could be adapted for BPMN 2.0.

1. Modeling and Validating
BPMN Diagrams
Michele Chinosi, Alberto Trombetta
Universit` degli Studi dell’Insubria (Varese – Italy)
a
Dipartimento di Informatica e Comunicazione
michele.chinosi@uninsubria.it
BPMN 2009 Workshop
July 20, 2009, Vienna, Austria

2. Contents Cloud
2/38

3. Agenda
BPMN 1.1 and 2.0 Analysis
Our BPMN Metamodel Proposal
The XML Linearization
Referential Integrity
Concluding Remarks
3/38

4. Motivations
• need for easy usable models to test properties, to patch BPMN and
to add new features
• other proposals (as well as BPMN 2.0 submissions) are quite unclear
and too complex
• lack of validation support
• BPMN 1.1/1.2 comes without a native XSD
• methods to ensure diagrams correctness are manual and error-prone
4/38

5. Contributions
• simplified test-oriented version of the BPMN metamodel
• self-validating XML serialization for BPMN diagrams
• automated checks (using software tools)
• our approach could be abstracted from the specificities of BPMN
1.2 porting the base concepts also to BPMN 2.0
Last-Month Update
This work has been partially superseded by the recent BPMN 2.0 final
submission adoption by OMG. We will see a brief summary of major
changes at the end of this talk.
5/38

6. Contributions
• simplified test-oriented version of the BPMN metamodel
• self-validating XML serialization for BPMN diagrams
• automated checks (using software tools)
• our approach could be abstracted from the specificities of BPMN
1.2 porting the base concepts also to BPMN 2.0
Last-Month Update
This work has been partially superseded by the recent BPMN 2.0 final
submission adoption by OMG. We will see a brief summary of major
changes at the end of this talk.
5/38

7. BPMN 1.1 Weak Points Analysis
• weak hierarchical structure of the model
• BPD are strongly hierarchical
• elements placement inside the model does not reflect the expected
placement inside the diagram
• UML metamodel uses only generalization connections
• no valid/meaningful instances
• lack of distinctions between several elements and types definitions
• they are all elements (classes)
• Connections-by-Types
6/38

8. Sketch of BPMN 1.1 Metamodel
7/38

9. Different Hierarchical Structures Comparison
8/38

10. BPMN 2.0 Overview
(B)IOS
• (BEA), IBM, Oracle, SAP
• execution semantics formalization
• extensibility mechanism for both model and graphical extensions
• event composition and correlation refinement
• human interactions definition
• choreography model
BPMN-S
• Adaptive, Axway Software, HP, Lombardi Software, Fujitsu, et al.
• business level modeling
• checking compliance to choreography and rules
• process taxonomies
• execution interoperability
• model re-usability
9/38

11. Sketch of BPMN 2.0 UML – (B)IOS Proposal
10/38

12. Sketch of BPMN 2.0 UML – BPMN-S Proposal
11/38

13. Sketch of BPMN 2.0 UML – Final Submission
12/38

14. BPMN 2.0 – The CORE UML Class Diagram Example
13/38

15. BPMN 2.0 – The Package Diagram Example
14/38

16. Our BPMN 1.1 Metamodel Proposal
• top-down fashion methodology
• from BPD to all the other elements
• strongly hierarchical model
• reduces the Connections-by-Types and deletes all the missing
connections
• BPMN Supporting elements treated as types
• simpler model
• Connections-by-Semantics (UML compositions)
• every BPD can be described as one valid instance of the model
• right positioning of Connecting flow objects
15/38

17. Sketch of our BPMN 1.1 Metamodel Proposal
16/38

18. The XML Linearization
BPMN ⊃ WS-BPEL Still incomplete
⇒ BPMN 2.0 ⇒ and
BPMN = XPDL Complex
could be adapted to become
BPMN 1.1 → XML −−−−−−−−−−−
−−−−−−−−−−→ ⊆ BPMN 2.0
• Our linearization proposal could be useful to study diagram and/or
model properties and to make some tests, as well as to validate both
a model and its instances.
17/38

19. The XML Linearization
BPMN ⊃ WS-BPEL Still incomplete
⇒ BPMN 2.0 ⇒ and
BPMN = XPDL Complex
could be adapted to become
BPMN 1.1 → XML −−−−−−−−−−−
−−−−−−−−−−→ ⊆ BPMN 2.0
• Our linearization proposal could be useful to study diagram and/or
model properties and to make some tests, as well as to validate both
a model and its instances.
17/38

20. Detailed BPMN 1.1 Weak Points Analysis
Attributes default values
• BPMN defines mandatory attributes WITH default values
• XML-Schema does not permit this double assertion
if an attribute has the default clause defined, it takes the default
value even if it is not present at all
use=‘‘optional’’ + default=...
Process
• BPMN defines Processes as conceptual siblings of the BPD
• if a Pool shares a Process, then it has one or more Lanes
• all the other elements are referenced by the Process using their IDs
!! we don’t want a valid instance with Process as root element
∃ Process ⇒ ∃ Pool, but ∃ Pool ∃ Process
Process becomes child of Pool
18/38

21. Detailed BPMN 1.1 Weak Points Analysis
Attributes default values
• BPMN defines mandatory attributes WITH default values
• XML-Schema does not permit this double assertion
if an attribute has the default clause defined, it takes the default
value even if it is not present at all
use=‘‘optional’’ + default=...
Process
• BPMN defines Processes as conceptual siblings of the BPD
• if a Pool shares a Process, then it has one or more Lanes
• all the other elements are referenced by the Process using their IDs
!! we don’t want a valid instance with Process as root element
∃ Process ⇒ ∃ Pool, but ∃ Pool ∃ Process
Process becomes child of Pool
18/38

22. Detailed BPMN 1.1 Weak Points Analysis
Attributes default values
• BPMN defines mandatory attributes WITH default values
• XML-Schema does not permit this double assertion
if an attribute has the default clause defined, it takes the default
value even if it is not present at all
use=‘‘optional’’ + default=...
Process
• BPMN defines Processes as conceptual siblings of the BPD
• if a Pool shares a Process, then it has one or more Lanes
• all the other elements are referenced by the Process using their IDs
!! we don’t want a valid instance with Process as root element
∃ Process ⇒ ∃ Pool, but ∃ Pool ∃ Process
Process becomes child of Pool
18/38

23. Detailed BPMN 1.1 Weak Points Analysis
Attributes default values
• BPMN defines mandatory attributes WITH default values
• XML-Schema does not permit this double assertion
if an attribute has the default clause defined, it takes the default
value even if it is not present at all
use=‘‘optional’’ + default=...
Process
• BPMN defines Processes as conceptual siblings of the BPD
• if a Pool shares a Process, then it has one or more Lanes
• all the other elements are referenced by the Process using their IDs
!! we don’t want a valid instance with Process as root element
∃ Process ⇒ ∃ Pool, but ∃ Pool ∃ Process
Process becomes child of Pool
18/38

24. Detailed BPMN 1.1 Weak Points Analysis
Participant
• “A Pool represents a Participant”
Participant is child of Pool
Message
• “A Message is the object that is transmitted through a
MessageFlow”
Message is child of MessageFlow
19/38

25. Detailed BPMN 1.1 Weak Points Analysis
Participant
• “A Pool represents a Participant”
Participant is child of Pool
Message
• “A Message is the object that is transmitted through a
MessageFlow”
Message is child of MessageFlow
19/38

26. Detailed BPMN 1.1 Weak Points Analysis
Web Service
• WebService is required by many other elements
• BPMN defines WebService as a Supporting Element
Inside the BPMN to WS-BPEL mapping example the WebService is
defined inside the parent element
We chose to instantiate WebService every time it is needed
(xs:assert)
20/38

27. Send Task Definition
< xs : complexType name = " SendTaskType " > 1
< xs : complexContent > 2
< xs : extension base = " bpex : TaskType " > 3
< xs : sequence > 4
< xs : element name = " WebService " 5
type = " bpex : WebServi ceType " minOccurs = " 0 " > 6
< xs : assert test ="@I mp le m en ta t io n = ‘ Web Service ’"/ > 7
</ xs : element > 8
</ xs : sequence > 9
< xs : attribute name = " MessageRef " 10
type = " bpex : ObjectRef " use = " required " / > 11
< xs : attribute name = " Impl ementat ion " 12
default ="Web Service"> 13
< xs : simpleType > 14
... 15
Listing 1: An excerpt of the Send Task definition
21/38

28. Detailed BPMN 1.1 Weak Points Analysis
Events
• XPDL and WS-BPEL define for each Event type a different element
• complex XML tree
• BPMN defines only one Event ELEMENT with 3 FAMILIES and
many different TYPES
families and types are specifications and not different element
definitions
Start, Intermediate and End Event are children of Lane
(xs:assert)
we assign a different type based on the Trigger or Result
attributes values (xs:alternative)
22/38

29. Event Definition
< xs : complexType name = " LaneType " > 1
< xs : complexContent > 2
< xs : extension base = " bpex : C o m m o n S w i m l a n e T y p e " > 3
< xs : sequence > 4
< xs : element name = " StartEvent " 5
type = " bpex : StartEve ntType " 6
minOccurs = " 0 " maxOccurs = " unbounded " > 7
< xs : assert test = " @EventType = ’ Start ’ " / > 8
</ xs : element > 9
... 10
< xs : complexType name = " StartEve ntType " > 11
< xs : complexContent > 12
< xs : extension base = " bpex : EventType " > 13
< xs : sequence > 14
< xs : element name = " Trigger " 15
type = " bpex : C o m m o n E v e n t D e t a i l T y p e " 16
minOccurs = " 0 " maxOccurs = " unbounded " > 17
< xs : alternative test = " @ E v e n t D e t a i l T y p e = ’ None ’ " 18
type = " bpex : N o n e E v e n t D e t a i l T y p e " / > 19
< xs : alternative test = " @ E v e n t D e t a i l T y p e = ’ Message ’ " 20
type = " bpex : M e s s a g e E v e n t D e t a i l T y p e " / > 21
... 22
Listing 2: An excerpt of the Events definition
23/38

30. Detailed BPMN 1.1 Weak Points Analysis
Gateways
• Gateways can only be detailed in one of the five provided types
• there is only one element (Gateway) and five possible specifications
• the Gateway default type is chosen in 2 steps: Exclusive and then
Data-Based
we define only one element of type Gateway, child of Lane
we decide in a second time the Gateway type using
xs:alternative
the Gateway default type is chosen in 1 single step: Data-Based
Exclusive
24/38

31. Gateway Definition
< xs : element name = " Gateway " type = " bpex : C o m m o n G a t e w a y T y p e " 1
minOccurs = " 0 " maxOccurs = " unbounded " > 2
< xs : alternative 3
test = " @GatewayType = ’ Data - Based Exclusive ’ " 4
type = " bpex : D a t a B a s e d E x c l u s i v e G a t e w a y T y p e " / > 5
< xs : alternative 6
test = " @GatewayType = ’ Event - Based Exclusive ’ " 7
type = " bpex : E v e n t B a s e d E x c l u s i v e G a t e w a y T y p e " / > 8
< xs : alternative 9
test = " @GatewayType = ’ Inclusive ’ " 10
type = " bpex : I n c l u s i v e G a t e w a y T y p e " / > 11
... 12
Listing 3: An excerpt of the Gateways definition
25/38

32. Detailed BPMN 1.1 Weak Points Analysis
Sub-Processes
• Reusable: Activity which re-calls another Process
ProcessRef and DiagramRef
• Reference: it points to another already defined Sub-Process
SubProcessRef
• Embedded: it contains a process dependent from the parent process
the SubProcess elements are defined as Lane children and
referenced using the GraphicalElements attribute
26/38

33. Detailed BPMN 1.1 Weak Points Analysis
Artifacts
• one Artifact could be used across the whole BPD, using Associations
to reference elements
• they need only one place to be instantiated
Artifacts as BPD children
inside the XML they can be positioned everywhere
Transactions and Signals
• some elements need to be referenced from multiple objects and they
are instantiated every time they are requested: different IDs but the
same name
• the attribute TransactionId of type String serves as an “identifier
for the Transactions used within a diagram”
we extended the idea behind the TransactionId also to Signals
and other similar objects
27/38

34. Detailed BPMN 1.1 Weak Points Analysis
Artifacts
• one Artifact could be used across the whole BPD, using Associations
to reference elements
• they need only one place to be instantiated
Artifacts as BPD children
inside the XML they can be positioned everywhere
Transactions and Signals
• some elements need to be referenced from multiple objects and they
are instantiated every time they are requested: different IDs but the
same name
• the attribute TransactionId of type String serves as an “identifier
for the Transactions used within a diagram”
we extended the idea behind the TransactionId also to Signals
and other similar objects
27/38

35. Referential Integrity Using XPath
• The very old way: manual ID/IDRef references – strings, numbers,
NCNames, random generators, . . .
• The old way: xs:key and xs:keyref
• The new way: xs:assert and xs:alternative
xs:assert
• <xs:assert-test=‘‘XPathExpr’’ />
• limit: the XPath 2.0 expressions set
xs:alternative
• it permits to choose the type of an element according to the success
of a XPath 2.0 test
• useful for Events, Gateways, Activities
28/38

36. Referential Integrity Using XPath
• The very old way: manual ID/IDRef references – strings, numbers,
NCNames, random generators, . . .
• The old way: xs:key and xs:keyref
• The new way: xs:assert and xs:alternative
xs:assert
• <xs:assert-test=‘‘XPathExpr’’ />
• limit: the XPath 2.0 expressions set
xs:alternative
• it permits to choose the type of an element according to the success
of a XPath 2.0 test
• useful for Events, Gateways, Activities
28/38

37. Referential Integrity Verification
• Using our XML-Schema Model we are able to validate statically the
syntax as well as structural semantics rules of a BPD
• Using a set of XQuery/XPath interrogations on the XML instances
we can validate also most of the behavioral semantics rules of BPMN
• The use of XQuery/XPath let us verify business rules at code-gen
time and at run-time
29/38

38. Wrong BPMN Diagram
red: clear (model) errors – orange: hidden (XML) errors
30/38

39. Parsing the XML Document
31/38

40. Start Event Check
for $ pool in // Pool , 1
$ startevent in $ pool // StartEvent 2
return $ pool // SequenceFlow [ @b pe x :T ar ge t Re f = ← 3
$ startevent / @bpex:Id ]/ @bpex:Id 4
Listing 4: Rules verification using XPath/XQuery: Start Event
32/38

41. Events Number Check
for $ pool in // Pool , 1
$ numSE in count ($ pool // StartEvent ) , 2
$ numEE in count ($ pool // EndEvent ) 3
return if ($ numSE >0) then 4
if ($ numEE >0) then true () else false () 5
else 6
if ($ numEE =0) then true () else false () 7
Listing 5: Rules verification using XPath/XQuery: Events number
“If there is an End (Start) Event, then there MUST be at least one Start
(End) Event”
33/38

42. Instantiation Semantic Verification
for $ pool in // Pool , 1
$ startEvent in $ pool // StartEvent , 2
$ numSE in count ($ startEvent ) , 3
$ elements in $ pool / Lane /*[ name ()!= " StartEvent " ] 4
return 5
if ($ numSE >0) then 6
if ( every $ id in $ elements / @bpex:Id satisfies ← 7
$ id =$ pool / SequenceFlow / @ b pe x: T ar ge tR e f ) 8
then true () 9
else $ elements / @bpex:Id 10
else false () 11
Listing 6: Rules verification using XPath/XQuery: instantiation semantic
“If the Start Event is used, then there MUST NOT be other flow
elements that do not have incoming Sequence Flow”
34/38

43. Comparison with BPMN 2.0
BPMN 1.1/1.2 BPMN 2.0 Could our proposal be
still valid?
Metamodel Y Y With some changes to
be compliant to the
BPMN 2.0 metamodel
XSD N Y With some changes
Referential Int. Partially Partially Y
Execution N Y Y
To have a simplified core subset of both the BPMN metamodel and the
XML-Schema, compliant to BPMN specifications, is useful to test some
properties, to implement new features, to attempt new strategies, to
implement patches.
35/38

44. Conclusions
What we have talked about
BPMN 1.1 analysis
BPMN 2.0 metamodel overview
Our proposal for a BPMN simplified test-oriented metamodel
Our proposal for a BPMN XML serialization
Referential Integrity in BPMN: overview and new approach
Differences between BPMN 1.1 and BPMN 2.0
36/38

45. Further Works
We are deeply analyzing both the BPMN 2.0 metamodel and its XSD
to get some weaknesses
We aim to build a tough core subset of the BPMN 2.0 metamodel
deriving, as a consequence, a core subset of the XML-Schema
serialization
We aim to test some properties over this BPMN Core (maybe the same
Core as defined inside BPMN 2.0 specs) adding some new functionalities
like the validation support at code-gen time.
37/38

46. Thank you.
Questions?
July 20, 1969 – 22.56 EDT
38/38