Your SlideShare is downloading. ×

Extended Process Modeling

5,045
views

Published on

Introduction to Enterprise Architecture and modeling through graphical languages such as BPMN 2.0.

Introduction to Enterprise Architecture and modeling through graphical languages such as BPMN 2.0.

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,045
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
139
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Transcript

    • 1. Extended Process Modeling, Languages and Notations Nov 2010, Sylvain Astier, sastier@gmail.com
    • 2. Extended Process Modeling, Languages and Notations 1 The Need for Models 2 The Need for Languages 3 The Process Domain 4 Business Interactions Modeling 5 BPMN 2 Overview
    • 3. Extended Process Modeling, Languages and Notations 1 The Need for Models 2 The Need for Languages 3 The Process Domain 4 Business Interactions Modeling 5 BPMN 2 Overview
    • 4. 1 Why do we need models ? • A Model is a simple representation of the complex reality of a business.
    • 5. 1 Why do we need models ? • A Model is a simple representation of the complex reality of a business. • Models are created to simplify, abstract reality, and focus on a specific area of concern.
    • 6. 1 Why do we need models ? • A Model is a simple representation of the complex reality of a business. • Models are created to simplify, abstract reality, and focus on a specific area of concern. ➡ A Model is built for a purpose
    • 7. 1 Why do we need models ?
    • 8. 1 Why do we need models ? • Models are work products of Architecture
    • 9. 1 One question though .. Is this Architecture ? (Inspired from John Zachman)
    • 10. 1 This is not Architecture ! This is NOT Architecture, it is the result of Architecture, an instance created from a properly defined architecture. (Inspired from John Zachman)
    • 11. 1Is ThisArchitecture ? ! this is Architecture The Product is the Model
    • 12. 1 Architecture Definition
    • 13. 1 Architecture Definition • Architecture expresses the characteristics, structures, behaviors, and relationships that are common across a family of things. 
    • 14. 1 Architecture Definition • Architecture expresses the characteristics, structures, behaviors, and relationships that are common across a family of things.  • Design expresses in detail how a specific member of a family will be built. - Oliver Sims
    • 15. 1 Many Implementations can be built from a given Architecture • An Architecture can lead to different Implementations with different Designs.
    • 16. 1 Many Implementations can be built from a given Architecture • An Architecture can lead to different Implementations with different Designs.
    • 17. 1 Enterprise Architecture Definition “Enterprise Architecture is the total set of descriptive representations (models) relevant for describing an Enterprise, that is, the descriptive representations required to create (a coherent, optimal) Enterprise and required to serve as a baseline for changing the Enterprise once it is created.” -- John Zachman
    • 18. 1 Enterprise Architecture reaps two major benefits : Change Management
    • 19. 1 Enterprise Architecture reaps two major benefits : Change Management • By maintaining the descriptive representations of the object of interest, you can run ‘what-if’ analysis.
    • 20. 1 Enterprise Architecture reaps two major benefits : Change Management • By maintaining the descriptive representations of the object of interest, you can run ‘what-if’ analysis. ➡Change is manageable as soon as you can study its impacts on models, before modifying their instances.
    • 21. 1 Enterprise Architecture reaps two major benefits : Change Management • By maintaining the descriptive representations of the object of interest, you can run ‘what-if’ analysis. ➡Change is manageable as soon as you can study its impacts on models, before modifying their instances. • You need the map of your own territory.
    • 22. 1 Enterprise Architecture reaps two major benefits : Integration Management
    • 23. 1 Enterprise Architecture reaps two major benefits : Integration Management • Architecture is about Separation of concerns
    • 24. 1 Enterprise Architecture reaps two major benefits : Integration Management • Architecture is about Separation of concerns ➡ Architecture is System thinking
    • 25. 1 Enterprise Architecture reaps two major benefits : Integration Management • Architecture is about Separation of concerns ➡ Architecture is System thinking • Enterprise Architecture is about engineering the enterprise and how enterprises integrate, not to build and run systems.
    • 26. 1 Enterprise Architecture reaps two major benefits : Integration Management • Architecture is about Separation of concerns ➡ Architecture is System thinking • Enterprise Architecture is about engineering the enterprise and how enterprises integrate, not to build and run systems. ➡ The system is the Enterprise
    • 27. 1 The Zachman EA Framework
    • 28. 1 The Zachman EA Framework WHAT ?
    • 29. 1 The Zachman EA Framework WHAT ? HOW ?
    • 30. 1 The Zachman EA Framework WHERE ? WHAT ? HOW ?
    • 31. 1 The Zachman EA Framework WHERE ? WHAT ? WHO ? HOW ?
    • 32. WHAT ?HOW ?WHERE ? 1 The Zachman EA FrameworkWHO ?WHEN ?
    • 33. WHAT ?HOW ?WHERE ? 1 The Zachman EA FrameworkWHO ?WHEN ?WHY ?
    • 34. 1 The Zachman EA Framework
    • 35. 1 The Zachman EA Framework Identification
    • 36. 1 The Zachman EA Framework Identification Definition
    • 37. 1 The Zachman EA Framework Identification Definition Representation
    • 38. 1 The Zachman EA Framework Identification Definition Representation Specification
    • 39. 1 The Zachman EA Framework Identification Definition Representation Specification Configuration
    • 40. 1 The Zachman EA Framework Identification Definition Representation Specification Configuration Instantiation
    • 41. 1 The Zachman EA Framework
    • 42. 1 The Zachman EA Framework
    • 43. 1 One question though .. Should everything be formalized ?
    • 44. 1 One question though .. Should everything be formalized ? • Some elements are well known and predictable: • E.g. the sequence 2; 4; 8; ?
    • 45. 1 One question though .. Should everything be formalized ? • Some elements are well known and predictable: • E.g. the sequence 2; 4; 8; ? • N=16 with the obvious model: ➡ N = N-1 * 2
    • 46. 1 One question though .. Should everything be formalized ? • Some elements are well known and predictable: • E.g. the sequence 2; 4; 8; ? • N=16 with the obvious model: ➡ N = N-1 * 2 • N=14 with the less obvious model: ➡ N = N -2 + N-1 + 2
    • 47. 1 One question though .. Should everything be formalized ?
    • 48. 1 One question though .. Should everything be formalized ? No; assumptions can be made knowing that: •They can lead to defects •Until a phenomenon is KNOWN it is ➡Not Predictable ➡Not Repeatable
    • 49. 1 One question though .. Should everything be formalized ? No; assumptions can be made knowing that: •They can lead to defects •Until a phenomenon is KNOWN it is ➡Not Predictable ➡Not Repeatable ARCHITECTURE is KNOWLEDGE
    • 50. Extended Process Modeling, Languages and Notations 1 The Need for Models 2 The Need for Languages 3 The Process Domain 4 Business Interactions Modeling 5 BPMN 2 Overview
    • 51. 2 Why do we need modeling languages ?
    • 52. 2 Why do we need modeling languages ? •Modeling allows efficiency in reading and understanding.
    • 53. 2 Why do we need modeling languages ? •Modeling allows efficiency in reading and understanding. •A standardized modeling language allows communication improvement, much the same way one becomes more literate through continuous practice of French or English
    • 54. 2 Why do we need modeling languages ? •Modeling allows efficiency in reading and understanding. •A standardized modeling language allows communication improvement, much the same way one becomes more literate through continuous practice of French or English • Skillful modeling drives the simplification of reality - and thereby abstraction.
    • 55. 2 Why do we need modeling languages ? •Modeling allows efficiency in reading and understanding. •A standardized modeling language allows communication improvement, much the same way one becomes more literate through continuous practice of French or English • Skillful modeling drives the simplification of reality - and thereby abstraction. •Improves efficiency, modeling allows one to learn from the Masters and reuse patterns.
    • 56. 2 Why do we need modeling languages ? •Modeling allows efficiency in reading and understanding. •A standardized modeling language allows communication improvement, much the same way one becomes more literate through continuous practice of French or English • Skillful modeling drives the simplification of reality - and thereby abstraction. •Improves efficiency, modeling allows one to learn from the Masters and reuse patterns. •Models constitute a body of knowledge from which one can elaborate on to create new architectures.
    • 57. 2 Why do we need modeling languages ?
    • 58. 2 Why do we need modeling languages ? • The goal of a modeling language is to enable the description of some domain of interest.
    • 59. 2 Why do we need modeling languages ? • The goal of a modeling language is to enable the description of some domain of interest. • The semantics of a language describe the meaning of its concepts in the domain of interest.
    • 60. 2 Why do we need modeling languages ? • The goal of a modeling language is to enable the description of some domain of interest. • The semantics of a language describe the meaning of its concepts in the domain of interest. ‣ We need Modeling Languages to express our concepts and their interactions in a specific domain of interest
    • 61. 2 Why do we need modeling languages ?
    • 62. 2 Why do we need modeling languages ? • The set of symbols that compose a language as well as the rules for forming valid combinations of these symbols constitute the language’s syntax.
    • 63. 2 Why do we need modeling languages ? • The set of symbols that compose a language as well as the rules for forming valid combinations of these symbols constitute the language’s syntax. • The syntax can be defined in terms of: • Linear sequences of characters • Pictorial signs
    • 64. 2 One question though .. What do they have in common ?
    • 65. 2 One question though .. What do they have in common ? ➡ They are SIGNS, pictograms used to designate a concept
    • 66. 2 Signs, Objects and Concepts
    • 67. 2 Signs, Objects and Concepts • A Sign is an object that is used as a representation of something else.
    • 68. 2 Signs, Objects and Concepts • A Sign is an object that is used as a representation of something else. • An Object is an observable and identifiable individual thing.
    • 69. 2 Signs, Objects and Concepts • A Sign is an object that is used as a representation of something else. • An Object is an observable and identifiable individual thing. • A Concept is always a Concept of a Type.
    • 70. 2 Signs, Objects and Concepts • Relationship:
    • 71. 2 Signs, Objects and Concepts • Relationship: • Designation : a Sign designates a Concept
    • 72. 2 Signs, Objects and Concepts • Relationship: • Designation : a Sign designates a Concept ‣ Left Curve
    • 73. 2 Signs, Objects and Concepts • Relationship: • Designation : a Sign designates a Concept ‣ Left Curve • Denotation: a Sign denotes an Object
    • 74. 2 Signs, Objects and Concepts • Relationship: • Designation : a Sign designates a Concept ‣ Left Curve • Denotation: a Sign denotes an Object ‣ This indicates that there’s going to be a :
    • 75. 2 Signs, Objects and Concepts • Relationship: • Designation : a Sign designates a Concept ‣ Left Curve • Denotation: a Sign denotes an Object ‣ This indicates that there’s going to be a : • Reference: a Concept refers to an Object
    • 76. 2 Signs, Objects and Concepts • Relationship: • Designation : a Sign designates a Concept ‣ Left Curve • Denotation: a Sign denotes an Object ‣ This indicates that there’s going to be a : • Reference: a Concept refers to an Object ‣ There’s a Left Curve ahead
    • 77. 2 The meaning triangle (Ulmann’s triangle)
    • 78. 2 The Ontological Parallelogram
    • 79. 2 Modeling Languages
    • 80. 2 Modeling Languages • Lexical Layer: the set of primitive modeling elements
    • 81. 2 Modeling Languages • Lexical Layer: the set of primitive modeling elements • Abstract Syntax: how to compose these elements, defined in terms of a metamodel
    • 82. 2 Modeling Languages Evaluation
    • 83. 2 Modeling Languages Evaluation • The Domain Appropriateness of a language is a measure of the adequacy of a language to express phenomenon in a given domain.
    • 84. 2 Modeling Languages Evaluation • The Domain Appropriateness of a language is a measure of the adequacy of a language to express phenomenon in a given domain. • The Comprehensibility Appropriateness refers to how easy it is to understand model phenomenon from their expression in a given language.
    • 85. Extended Process Modeling, Languages and Notations 1 The Need for Models 2 The Need for Languages 3 The Process Domain 4 Business Interactions Modeling 5 BPMN 2 Overview
    • 86. 3 Domain Specific Languages for Processes
    • 87. 3 Domain Specific Languages for Processes • The main evaluation criteria for a language are:
    • 88. 3 Domain Specific Languages for Processes • The main evaluation criteria for a language are: • Domain Appropriateness
    • 89. 3 Domain Specific Languages for Processes • The main evaluation criteria for a language are: • Domain Appropriateness • Comprehensibility Appropriateness
    • 90. 3 Domain Specific Languages for Processes • The main evaluation criteria for a language are: • Domain Appropriateness • Comprehensibility Appropriateness • A language appropriateness is determined by its suitability to a domain, while the comprehensibility is determined by its users
    • 91. 3 What is the “Process Domain” : Enterprise Architecture • Architecture is useful at many levels:
    • 92. 3 What is the “Process Domain” : Enterprise Architecture • Architecture is useful at many levels: • Sub-Components
    • 93. 3 What is the “Process Domain” : Enterprise Architecture • Architecture is useful at many levels: • Sub-Components • Components
    • 94. 3 What is the “Process Domain” : Enterprise Architecture • Architecture is useful at many levels: • Sub-Components • Components • Organization
    • 95. 3 What is the “Process Domain” : Enterprise Architecture • Architecture is useful at many levels: • Sub-Components • Components “The Enterprise is the SYSTEM” • Organization - Zachman
    • 96. 3 What is the “Process Domain” : Enterprise Architecture • Architecture is useful at many levels: • Sub-Components • Components “The Enterprise is the SYSTEM” • Organization - Zachman • Extended Organization
    • 97. 3 What is the “Process Domain” : Enterprise Architecture • Architecture is useful at many levels: • Sub-Components • Components “The Enterprise is the SYSTEM” • Organization - Zachman • Extended Organization The Business Interaction Network is the SYSTEM
    • 98. 3 What is the “Process Domain” : Enterprise Architecture • Architecture is useful at many levels: • Sub-Components • Components “The Enterprise is the SYSTEM” • Organization - Zachman • Extended Organization The Business Interaction Network is the SYSTEM Architecture is FRACTAL
    • 99. 3 From Silos to Services 1/4 • Functional Silos • Transversal Business Processes • Service Oriented Organization
    • 100. 3 From Silos to Services 2/4
    • 101. 3 From Silos to Services 2/4 • A Service Unit produces value from a set of capabilities.
    • 102. 3 From Silos to Services 2/4 • A Service Unit produces value from a set of capabilities. • Some capabilities are exposed as a service, hence made available to the outside world.
    • 103. 3 From Silos to Services 3/4 Transversal Business Process
    • 104. 3 From Silos to Services 4/4
    • 105. 3 From Silos to Services 4/4 • Capabilities can be factorized and made available to other Organization Units
    • 106. 3 Different kinds of Processes
    • 107. 3 Different kinds of Processes Process describing a flow of “Interactions”
    • 108. 3 Different kinds of Processes Process describing a flow of “Interactions” Process describing a flow of “activities”
    • 109. 3 Orchestration Processes in a Service Unit
    • 110. 3 Different Process Aspects (source BPMN 2.0)
    • 111. 3 Different Process Aspects • Orchestration: A sequence or flow of Activities in an organization with the objective of carrying out work. (source BPMN 2.0)
    • 112. 3 Different Process Aspects • Orchestration: A sequence or flow of Activities in an organization with the objective of carrying out work. • Collaboration: Collaboration is the act of sending messages between any two Participants. (source BPMN 2.0)
    • 113. 3 Different Process Aspects • Orchestration: A sequence or flow of Activities in an organization with the objective of carrying out work. • Collaboration: Collaboration is the act of sending messages between any two Participants. • Conversation: It represents a set of Message Flows grouped together based on a concept and/or a CorrelationKey. (source BPMN 2.0)
    • 114. 3 Different Process Aspects • Orchestration: A sequence or flow of Activities in an organization with the objective of carrying out work. • Collaboration: Collaboration is the act of sending messages between any two Participants. • Conversation: It represents a set of Message Flows grouped together based on a concept and/or a CorrelationKey. • Choreography: An ordered sequence of B2B message exchanges between two or more Participants. (source BPMN 2.0)
    • 115. 3 Some of the available Process Modeling Standards Languages are not equals when it comes to Domain and Comprehensibility Appropriateness
    • 116. 3 One question though .. In wish cases would you use BPMN ?
    • 117. 3 One question though .. BPMN
    • 118. 3 One question though .. BPMN UML
    • 119. 3 One question though .. BPMN BPEL BPEL 4 People
    • 120. 3 One question though .. BPMN BPEL BPEL 4 People
    • 121. 3 One question though .. BMM BPMN SBVR UML
    • 122. Extended Process Modeling, Languages and Notations 1 The Need for Models 2 The Need for Languages 3 The Process Domain 4 Business Interactions Modeling 5 BPMN 2 Overview
    • 123. 4 Sequence of interactions between Organization Units
    • 124. 4 Sequence of interactions between Organization Units • Interactions are sets of exchanges between participants
    • 125. 4 Sequence of interactions between Organization Units • Interactions are sets of exchanges between participants • Interactions need to be properly defined (Service Level Agreements)
    • 126. 4 Sequence of interactions between Organization Units
    • 127. 4 Sequence of interactions between Organization Units • Set of Interactions define the rules of engagement between several participants.
    • 128. 4 Sequence of interactions between Organization Units • Set of Interactions define the rules of engagement between several participants. • Hence, Choreography modeling is key to integration of organization units in the context of a value production network.
    • 129. 4 Interactions enforced by an Orchestration Model
    • 130. 4 Interactions defined by a Choreography Model
    • 131. 4 Interactions defined by a Choreography Model
    • 132. 4 Informal (not BPMN) description of a set of interactions
    • 133. 4 Informal (not BPMN) description of a set of interactions
    • 134. 4 One question though .. Is the following notation adapted to its purpose ?
    • 135. 4 One question though ..
    • 136. 4 One question though .. ➡ A BPMN 2 Choreography expresses the roles of participants as well as the sequences of their interactions
    • 137. 4 Choreography Model
    • 138. 4 So, the Domain Specific Languages for Business Interactions • Includes : • Orchestrations • Collaboration (and Conversations) • Choreographies
    • 139. 4 So, the Domain Specific Languages for Business Interactions • Includes : • Orchestrations • Collaboration (and Conversations) • Choreographies They are different, intertwined, views of a same beast
    • 140. 4 Different domains also impact the “Process Domain”
    • 141. 4 Assuming a Role in a global Business Interaction Network • Formal Definition of the global set of Business Interactions : • Sub set of interest in regard to ‘Role 2’ :
    • 142. 4 Each participant must fulfill his role • Interactions expected from ‘Role 2’ : • ‘Role 2’ fulfillment :
    • 143. Extended Process Modeling, Languages and Notations 1 The Need for Models 2 The Need for Languages 3 The Process Domain 4 Business Interactions Modeling 5 BPMN 2 Overview
    • 144. 5 Business Process Model and Notation • An Object Management Group specification • Years of developments • 70+ implementations (BPMN 1.X, 2.0) • Created by a consortium of 47 organizations including Analysts, Strategists, Software vendors • Axway • Global 360, Inc. • Hewlett-Packard • International Business Machines • Oracle • U.S. National Institute of Standards and Technology • SAP • ..
    • 145. 5 Different types of Diagrams • Orchestrations • Collaborations (and Conversations) • Choreographies
    • 146. 5 Example of an Orchestration
    • 147. 5 Example of a Collaboration
    • 148. 5 Example of a Conversation
    • 149. 5 Example of a Choreography
    • 150. 5 Orchestration and Conversation
    • 151. 5 Orchestration and Choreographies
    • 152. 5 Event Handling
    • 153. 5 Do not Panic ! • BPMN includes 100+ classes • BPMN is extendable • e.g. DoDAF added 30+ classes • BPMN is Easy ! • Most users only need a very small subset of BPMN (Inspired from Column2.com)
    • 154. 5 How much BPMN 1.1 do you need ?
    • 155. 5 How much BPMN 1.1 do you need ?
    • 156. 5 How much BPMN 1.1 do you need ? The amount of BPMN used depends on the purpose of the model
    • 157. 5 How much BPMN 1.1 do you need ?
    • 158. 5 How much BPMN 1.1 do you need ? The amount of BPMN used depends on the purpose of the model
    • 159. 5 BPMN Models Standardization <?xml version="1.0" encoding="UTF-8"?> <definitions id="Definition" targetNamespace="http://www.example.org/UserTaskExample" typeLanguage="http://www.w3.org/2001/XMLSchema" expressionLanguage="http://www.w3.org/1999/XPath" xmlns=http://www.w3.org/2001/XMLSchema xmlns=”http://www.omg.org/spec/BPMN/20100524/MODEL” xmlns:tns="http://www.example.org/UserTaskExample"> <resource id="regionalManager" name="Regional Manager"> <resourceParameter id="buyerName" isRequired="true" name="Buyer Name" type="xsd:string"/> <resourceParameter id="region" isRequired="false" name="Region" type="xsd:string"/> </resource> <resource id="departmentalReviewer" name="Departmental Reviewer"> <resourceParameter id="buyerName" isRequired="true" name="Buyer Name" type="xsd:string"/> </resource> <collaboration id="BuyerCollaboration" name="Buyer Collaboration"> <participant id="BuyerParticipant" name="Buyer" processRef="BuyerProcess"/> </collaboration> <!-- Process definition --> <process id="BuyerProcess" name="Buyer Process"> <laneSet id="BuyerLaneSet"> <lane id="BuyerLane"> <flowNodeRef>StartProcess</flowNodeRef> <flowNodeRef>QuotationHandling</flowNodeRef> <flowNodeRef>ApproveOrder</flowNodeRef> <flowNodeRef>OrderApprovedDecision</flowNodeRef> <flowNodeRef>TerminateProcess</flowNodeRef> <flowNodeRef>OrderAndShipment</flowNodeRef> <flowNodeRef>OrderHandling</flowNodeRef> <flowNodeRef>ShipmentHandling</flowNodeRef> <flowNodeRef>OrderAndShipmentMerge</flowNodeRef> <flowNodeRef>ReviewOrder</flowNodeRef> <flowNodeRef>EndProcess</flowNodeRef> </lane> </laneSet> <startEvent id="StartProcess"/> <sequenceFlow sourceRef="StartProcess" targetRef="QuotationHandling"/> <task id="QuotationHandling" name="Quotation Handling"/> <sequenceFlow sourceRef="QuotationHandling" targetRef="ApproveOrder"/> <userTask id="ApproveOrder" name="ApproveOrder"> <potentialOwner> <resourceRef>tns:regionalManager</resourceRef> <resourceParameterBinding parameterRef="tns:buyerName"> <formalExpression> getDataInput(order)/address/name </formalExpression> </resourceParameterBinding> <resourceParameterBinding parameterRef="tns:region"> <formalExpression> getDataInput(order)/address/country </formalExpression> </resourceParameterBinding> </potentialOwner> </userTask> <sequenceFlow sourceRef="ApproveOrder" targetRef="OrderApprovedDecision"/> <exclusiveGateway id="OrderApprovedDecision" gatewayDirection="Diverging"/> <sequenceFlow sourceRef="OrderApprovedDecision" targetRef="OrderAndShipment"> <conditionExpression>
    • 160. 5 BPMN Models Standardization <?xml version="1.0" encoding="UTF-8"?> <definitions id="Definition" targetNamespace="http://www.example.org/UserTaskExample" typeLanguage="http://www.w3.org/2001/XMLSchema" expressionLanguage="http://www.w3.org/1999/XPath" xmlns=http://www.w3.org/2001/XMLSchema xmlns=”http://www.omg.org/spec/BPMN/20100524/MODEL” xmlns:tns="http://www.example.org/UserTaskExample"> <resource id="regionalManager" name="Regional Manager"> <resourceParameter id="buyerName" isRequired="true" name="Buyer Name" type="xsd:string"/> <resourceParameter id="region" isRequired="false" name="Region" type="xsd:string"/> </resource> <resource id="departmentalReviewer" name="Departmental Reviewer"> <resourceParameter id="buyerName" isRequired="true" name="Buyer Name" type="xsd:string"/> </resource> <collaboration id="BuyerCollaboration" name="Buyer Collaboration"> <participant id="BuyerParticipant" name="Buyer" processRef="BuyerProcess"/> </collaboration> <!-- Process definition --> <process id="BuyerProcess" name="Buyer Process"> <laneSet id="BuyerLaneSet"> ➡ Serialization format is part of the Standard ! <lane id="BuyerLane"> <flowNodeRef>StartProcess</flowNodeRef> <flowNodeRef>QuotationHandling</flowNodeRef> <flowNodeRef>ApproveOrder</flowNodeRef> <flowNodeRef>OrderApprovedDecision</flowNodeRef> <flowNodeRef>TerminateProcess</flowNodeRef> <flowNodeRef>OrderAndShipment</flowNodeRef> <flowNodeRef>OrderHandling</flowNodeRef> <flowNodeRef>ShipmentHandling</flowNodeRef> <flowNodeRef>OrderAndShipmentMerge</flowNodeRef> <flowNodeRef>ReviewOrder</flowNodeRef> <flowNodeRef>EndProcess</flowNodeRef> </lane> </laneSet> <startEvent id="StartProcess"/> <sequenceFlow sourceRef="StartProcess" targetRef="QuotationHandling"/> <task id="QuotationHandling" name="Quotation Handling"/> <sequenceFlow sourceRef="QuotationHandling" targetRef="ApproveOrder"/> <userTask id="ApproveOrder" name="ApproveOrder"> <potentialOwner> <resourceRef>tns:regionalManager</resourceRef> <resourceParameterBinding parameterRef="tns:buyerName"> <formalExpression> getDataInput(order)/address/name </formalExpression> </resourceParameterBinding> <resourceParameterBinding parameterRef="tns:region"> <formalExpression> getDataInput(order)/address/country </formalExpression> </resourceParameterBinding> </potentialOwner> </userTask> <sequenceFlow sourceRef="ApproveOrder" targetRef="OrderApprovedDecision"/> <exclusiveGateway id="OrderApprovedDecision" gatewayDirection="Diverging"/> <sequenceFlow sourceRef="OrderApprovedDecision" targetRef="OrderAndShipment"> <conditionExpression>
    • 161. 4 One question though .. Is it important that BPMN 2 defines its serialization format?
    • 162. Extended Process Modeling, Languages and Notations Conclusion

    ×