Extended Process Modeling

5,279 views
5,186 views

Published on

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,279
On SlideShare
0
From Embeds
0
Number of Embeds
3,551
Actions
Shares
0
Downloads
148
Comments
0
Likes
1
Embeds 0
No embeds

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
  • Extended Process Modeling

    1. 1. Extended Process Modeling, Languages and Notations Nov 2010, Sylvain Astier, sastier@gmail.com
    2. 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. 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. 4. 1 Why do we need models ? • A Model is a simple representation of the complex reality of a business.
    5. 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. 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. 7. 1 Why do we need models ?
    8. 8. 1 Why do we need models ? • Models are work products of Architecture
    9. 9. 1 One question though .. Is this Architecture ? (Inspired from John Zachman)
    10. 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. 11. 1Is ThisArchitecture ? ! this is Architecture The Product is the Model
    12. 12. 1 Architecture Definition
    13. 13. 1 Architecture Definition • Architecture expresses the characteristics, structures, behaviors, and relationships that are common across a family of things. 
    14. 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. 15. 1 Many Implementations can be built from a given Architecture • An Architecture can lead to different Implementations with different Designs.
    16. 16. 1 Many Implementations can be built from a given Architecture • An Architecture can lead to different Implementations with different Designs.
    17. 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. 18. 1 Enterprise Architecture reaps two major benefits : Change Management
    19. 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. 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. 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. 22. 1 Enterprise Architecture reaps two major benefits : Integration Management
    23. 23. 1 Enterprise Architecture reaps two major benefits : Integration Management • Architecture is about Separation of concerns
    24. 24. 1 Enterprise Architecture reaps two major benefits : Integration Management • Architecture is about Separation of concerns ➡ Architecture is System thinking
    25. 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. 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. 27. 1 The Zachman EA Framework
    28. 28. 1 The Zachman EA Framework WHAT ?
    29. 29. 1 The Zachman EA Framework WHAT ? HOW ?
    30. 30. 1 The Zachman EA Framework WHERE ? WHAT ? HOW ?
    31. 31. 1 The Zachman EA Framework WHERE ? WHAT ? WHO ? HOW ?
    32. 32. WHAT ?HOW ?WHERE ? 1 The Zachman EA FrameworkWHO ?WHEN ?
    33. 33. WHAT ?HOW ?WHERE ? 1 The Zachman EA FrameworkWHO ?WHEN ?WHY ?
    34. 34. 1 The Zachman EA Framework
    35. 35. 1 The Zachman EA Framework Identification
    36. 36. 1 The Zachman EA Framework Identification Definition
    37. 37. 1 The Zachman EA Framework Identification Definition Representation
    38. 38. 1 The Zachman EA Framework Identification Definition Representation Specification
    39. 39. 1 The Zachman EA Framework Identification Definition Representation Specification Configuration
    40. 40. 1 The Zachman EA Framework Identification Definition Representation Specification Configuration Instantiation
    41. 41. 1 The Zachman EA Framework
    42. 42. 1 The Zachman EA Framework
    43. 43. 1 One question though .. Should everything be formalized ?
    44. 44. 1 One question though .. Should everything be formalized ? • Some elements are well known and predictable: • E.g. the sequence 2; 4; 8; ?
    45. 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. 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. 47. 1 One question though .. Should everything be formalized ?
    48. 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. 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. 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. 51. 2 Why do we need modeling languages ?
    52. 52. 2 Why do we need modeling languages ? •Modeling allows efficiency in reading and understanding.
    53. 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. 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. 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. 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. 57. 2 Why do we need modeling languages ?
    58. 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. 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. 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. 61. 2 Why do we need modeling languages ?
    62. 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. 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. 64. 2 One question though .. What do they have in common ?
    65. 65. 2 One question though .. What do they have in common ? ➡ They are SIGNS, pictograms used to designate a concept
    66. 66. 2 Signs, Objects and Concepts
    67. 67. 2 Signs, Objects and Concepts • A Sign is an object that is used as a representation of something else.
    68. 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. 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. 70. 2 Signs, Objects and Concepts • Relationship:
    71. 71. 2 Signs, Objects and Concepts • Relationship: • Designation : a Sign designates a Concept
    72. 72. 2 Signs, Objects and Concepts • Relationship: • Designation : a Sign designates a Concept ‣ Left Curve
    73. 73. 2 Signs, Objects and Concepts • Relationship: • Designation : a Sign designates a Concept ‣ Left Curve • Denotation: a Sign denotes an Object
    74. 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. 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. 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. 77. 2 The meaning triangle (Ulmann’s triangle)
    78. 78. 2 The Ontological Parallelogram
    79. 79. 2 Modeling Languages
    80. 80. 2 Modeling Languages • Lexical Layer: the set of primitive modeling elements
    81. 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. 82. 2 Modeling Languages Evaluation
    83. 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. 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. 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. 86. 3 Domain Specific Languages for Processes
    87. 87. 3 Domain Specific Languages for Processes • The main evaluation criteria for a language are:
    88. 88. 3 Domain Specific Languages for Processes • The main evaluation criteria for a language are: • Domain Appropriateness
    89. 89. 3 Domain Specific Languages for Processes • The main evaluation criteria for a language are: • Domain Appropriateness • Comprehensibility Appropriateness
    90. 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. 91. 3 What is the “Process Domain” : Enterprise Architecture • Architecture is useful at many levels:
    92. 92. 3 What is the “Process Domain” : Enterprise Architecture • Architecture is useful at many levels: • Sub-Components
    93. 93. 3 What is the “Process Domain” : Enterprise Architecture • Architecture is useful at many levels: • Sub-Components • Components
    94. 94. 3 What is the “Process Domain” : Enterprise Architecture • Architecture is useful at many levels: • Sub-Components • Components • Organization
    95. 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. 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. 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. 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. 99. 3 From Silos to Services 1/4 • Functional Silos • Transversal Business Processes • Service Oriented Organization
    100. 100. 3 From Silos to Services 2/4
    101. 101. 3 From Silos to Services 2/4 • A Service Unit produces value from a set of capabilities.
    102. 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. 103. 3 From Silos to Services 3/4 Transversal Business Process
    104. 104. 3 From Silos to Services 4/4
    105. 105. 3 From Silos to Services 4/4 • Capabilities can be factorized and made available to other Organization Units
    106. 106. 3 Different kinds of Processes
    107. 107. 3 Different kinds of Processes Process describing a flow of “Interactions”
    108. 108. 3 Different kinds of Processes Process describing a flow of “Interactions” Process describing a flow of “activities”
    109. 109. 3 Orchestration Processes in a Service Unit
    110. 110. 3 Different Process Aspects (source BPMN 2.0)
    111. 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. 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. 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. 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. 115. 3 Some of the available Process Modeling Standards Languages are not equals when it comes to Domain and Comprehensibility Appropriateness
    116. 116. 3 One question though .. In wish cases would you use BPMN ?
    117. 117. 3 One question though .. BPMN
    118. 118. 3 One question though .. BPMN UML
    119. 119. 3 One question though .. BPMN BPEL BPEL 4 People
    120. 120. 3 One question though .. BPMN BPEL BPEL 4 People
    121. 121. 3 One question though .. BMM BPMN SBVR UML
    122. 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. 123. 4 Sequence of interactions between Organization Units
    124. 124. 4 Sequence of interactions between Organization Units • Interactions are sets of exchanges between participants
    125. 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. 126. 4 Sequence of interactions between Organization Units
    127. 127. 4 Sequence of interactions between Organization Units • Set of Interactions define the rules of engagement between several participants.
    128. 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. 129. 4 Interactions enforced by an Orchestration Model
    130. 130. 4 Interactions defined by a Choreography Model
    131. 131. 4 Interactions defined by a Choreography Model
    132. 132. 4 Informal (not BPMN) description of a set of interactions
    133. 133. 4 Informal (not BPMN) description of a set of interactions
    134. 134. 4 One question though .. Is the following notation adapted to its purpose ?
    135. 135. 4 One question though ..
    136. 136. 4 One question though .. ➡ A BPMN 2 Choreography expresses the roles of participants as well as the sequences of their interactions
    137. 137. 4 Choreography Model
    138. 138. 4 So, the Domain Specific Languages for Business Interactions • Includes : • Orchestrations • Collaboration (and Conversations) • Choreographies
    139. 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. 140. 4 Different domains also impact the “Process Domain”
    141. 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. 142. 4 Each participant must fulfill his role • Interactions expected from ‘Role 2’ : • ‘Role 2’ fulfillment :
    143. 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. 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. 145. 5 Different types of Diagrams • Orchestrations • Collaborations (and Conversations) • Choreographies
    146. 146. 5 Example of an Orchestration
    147. 147. 5 Example of a Collaboration
    148. 148. 5 Example of a Conversation
    149. 149. 5 Example of a Choreography
    150. 150. 5 Orchestration and Conversation
    151. 151. 5 Orchestration and Choreographies
    152. 152. 5 Event Handling
    153. 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. 154. 5 How much BPMN 1.1 do you need ?
    155. 155. 5 How much BPMN 1.1 do you need ?
    156. 156. 5 How much BPMN 1.1 do you need ? The amount of BPMN used depends on the purpose of the model
    157. 157. 5 How much BPMN 1.1 do you need ?
    158. 158. 5 How much BPMN 1.1 do you need ? The amount of BPMN used depends on the purpose of the model
    159. 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. 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. 161. 4 One question though .. Is it important that BPMN 2 defines its serialization format?
    162. 162. Extended Process Modeling, Languages and Notations Conclusion

    ×