Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Modeling and Validating BPMN Diagrams

10,609 views

Published on

BPMN 2009 Workshop @ CEC09 conference (IEEE Conference on Commerce and enterprise Computing)

Published in: Business, Technology

Modeling and Validating BPMN Diagrams

  1. 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. 2. Contents Cloud 2/38
  3. 3. Agenda BPMN 1.1 and 2.0 Analysis Our BPMN Metamodel Proposal The XML Linearization Referential Integrity Concluding Remarks 3/38
  4. 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. 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. 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. 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. 8. Sketch of BPMN 1.1 Metamodel 7/38
  9. 9. Different Hierarchical Structures Comparison 8/38
  10. 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. 11. Sketch of BPMN 2.0 UML – (B)IOS Proposal 10/38
  12. 12. Sketch of BPMN 2.0 UML – BPMN-S Proposal 11/38
  13. 13. Sketch of BPMN 2.0 UML – Final Submission 12/38
  14. 14. BPMN 2.0 – The CORE UML Class Diagram Example 13/38
  15. 15. BPMN 2.0 – The Package Diagram Example 14/38
  16. 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. 17. Sketch of our BPMN 1.1 Metamodel Proposal 16/38
  18. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 38. Wrong BPMN Diagram red: clear (model) errors – orange: hidden (XML) errors 30/38
  39. 39. Parsing the XML Document 31/38
  40. 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. 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. 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. 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. 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. 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. 46. Thank you. Questions? July 20, 1969 – 22.56 EDT 38/38

×