Download - BPDM Response Revised Submission 04-08-03
-
7/30/2019 BPDM Response Revised Submission 04-08-03
1/215
Business Process Definition Metamodel 1
bei/2004-08-03
Date : August 2nd 2004
Vers ion : 1.0.2
Revised Submission to BEI RFP bei/2003-01-06
Business Process Definition Metamodel
Submi t te r s :
International Business Machines
Adaptive
Borland
Data Access Technologies
EDS
88 Solutions
Suppor te rs :
-
7/30/2019 BPDM Response Revised Submission 04-08-03
2/215
2 Business Process Definition Metamodel
BEA Systems
BPMI.org
IDS Scheer
Intalio
Popkin Software
Unisys
-
7/30/2019 BPDM Response Revised Submission 04-08-03
3/215
Business Process Definition Metamodel 3
Par t I I n t r o d u ct i o n
Tab le o f con ten t s
TABLE OF CONTENTS 3
COPYRIGHT WAIVER 67
SUBMISSION CONTACTS 78
OVERVIEW OF SUBMISSION 910
Guide to the material in this submission 1011
Overall design rationale 1112
Statement of proof of concept 1213
Change History 1213
RESPONSE TO RFP REQUIREMENTS 1415
Mandatory Requirements 1415
Optional Requirements 1920
Issues to be discussed 2021
SCOPE OF THE SUBMISSION 2425
Proposed Conformance Criteria 2627
Proposed Normative References 2728
Proposed List of Terms and Definitions 2728
Proposed List of Symbols 2930
BUSINESS PROCESS DEFINITION METAMODEL 2930
Concepts and Overview 3031
-
7/30/2019 BPDM Response Revised Submission 04-08-03
4/215
4 Business Process Definition Metamodel
Conceptual Metamodel Overview 4847
Identified Subset of the UML 49
Semantics 50
Examples & Discussion 62
APPENDIX A: A UML PROFILE FOR BPD WITH A MAPPING TO BPEL4WS 7069
Model-driven business integration 7170
UML profile 7372
Defining a business process 7473
Dependency management 8180
External packages 8584
Data types and interfaces 8786
Properties and correlations 9392
Protocols 9998
Process, state, and ports 103102
Data handling 110109
Basic activities 116115
Activity coordination 128127
Error handling 138137
Example Marketplace 144143
Example Loan approval 147146
Quick reference 158157
UML Profile Definitions 170
APPENDIX B: MAPPING THE BPD METAMODEL TO BPEL4WS 171
BPD metamodel to BPEL4WS Mapping 171
APPENDIX C: MAPPING EDOC TO BPD PROFILE 177
APPENDIX D: MAPPING BPMN TO BPD PROFILE 178
-
7/30/2019 BPDM Response Revised Submission 04-08-03
5/215
Business Process Definition Metamodel 5
Examples & Discussion 215216
Examples & Discussion 215216
-
7/30/2019 BPDM Response Revised Submission 04-08-03
6/215
6 Business Process Definition Metamodel
COPYRI GHT W AI VER
Copyright 2003 International Business Machines, Adaptive, BEA Systems, Borland, BPMI, Data Access technologies, EDS, Unisys and88 Solutions.
International Business Machines Adaptive, BEA Systems, Borland, BPMI, Data Access technologies, EDS, Unisys and 88 Solutions
hereby grant to the Object Management Group, Inc. a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute thisdocument and to modify this document and distribute copies of the modified version.
IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of thisdocument does not give you any license to these patents.
Each of the copyright holders listed above has agreed that no person shall be deemed to have infringed the copyright in the included
material of any such copyright holder by reason of having used the specification set forth herein or having conformed to any computer
software to the specification.
NOTI CE
The information contained in this document is subject to change without notice.
The material in this document details an Object Management Group specification in accordance with the license and notices set forthon this page. This document does not represent a commitment to implement any portion of this specification in any companies'
products.
WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE, THE OBJECT MANAGEMENT GROUP,INTERNATIONAL BUSINESS MACHINES AND BEA SYSTEMS MAKE NO WARRANTY OF ANY KIND WITH REGARDS TO THIS MATERIAL
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
The aforementioned copyright holders shall not be liable for errors contained herein or for incidental or consequential damages inconnection with the furnishing, performance, or use of this material.
The copyright holders listed above acknowledge that the Object Management Group (acting itself or through its designees) is and shall
at all times be the sole entity that may authorize developers, suppliers and sellers of computer software to use certification marks,
trademarks or other special designations to indicate compliance with these materials. This document contains information which is
protected by copyright. All Rights Reserved. No part of this work covered by copyright herein may be reproduced or used in any formor by any means-graphic, electronic or mechanical, including photocopying, recording, taping, or information storage and retrievalsystems-without permission of the copyright owner.
RESTRICTED RIGHTS LEGEND. Use, duplication, or disclosure by government is subject to restrictions as set forth in subdivision (c)
(1) (ii) of the Right in Technical Data and Computer Software Clause at DFARS 252.227.7013.
-
7/30/2019 BPDM Response Revised Submission 04-08-03
7/215
Business Process Definition Metamodel 7
OMG and Object Management are registered trademarks of the Object Management Group, Inc. Object Request Broker, UML, Unified
Modeling Language, the UML Cube Logo, MDA, Model Driven Architecture, OMG IDL, ORB CORBA, CORBAfacilities, and CORBAservices
are trademarks of the Object Management Group,
Sub m ission Cont act s
The primary contact person for this submission is Sridhar Iyengar (IBM), any feedback on this submission can be sent to any of thesubmission contacts.
I BM
Jim AmsdenJoachim Frank
Tracy Gardner
Pablo Irassar
Sridhar Iyengar ([email protected])Simon JohnstonStephen White
A d a p t i v e
Pete Rivett ([email protected])
BEA Sys t em sEd Cobb ([email protected])
Yaron Goland
Bor landKarl Frank ([email protected])Randy Miller
BPMI
Layna Fischer ([email protected])
Data Access Techn o log ies
Cory B. Casanave ([email protected])
-
7/30/2019 BPDM Response Revised Submission 04-08-03
8/215
8 Business Process Definition Metamodel
EDS
Fred Cummins ([email protected])
I DS Scheer
Georg Simon ([email protected])
I n t a l i o
Ashish Agrawal ([email protected])
Po p k i n So f t w a r eMartin Owen ([email protected])
Un isys
Sumeet Malhotra ([email protected])
8 8 So l u t i o n s
Manfred Koethe ([email protected])
-
7/30/2019 BPDM Response Revised Submission 04-08-03
9/215
Business Process Definition Metamodel 9
Overv iew o f Subm iss ion
This document provides a more detailed response to the Business Process Definition Metamodel Request for Proposals. This is the firstrevised submission, and although far more complete than the initial submission it is expected that a further revision will be needed to
complete the definition.
In addition to responses to each of the requirements set out in the RFP, a description of the objectives of the submission is included to
further specify the intent of this submission.
The primary objective of this submission is to provide an abstract model for the definition of business processes either as a stand-alone activity or in the context of a broader business modeling program. This metamodel is positioned both in terms of its role within
the broader context of business modeling as well as in the context of the OMG Model Driven Architecture (MDA) initiative.
We also provide appendices that demonstrate how this metamodel may be used by tools with alternative graphical notations (bymapping the Business Process Modeling Notation, or BPMN, to this metamodel). The UML 2.0 is a perfectly adequate metamodel forcapturing business models and specifically business process definitions; however it is clear that only a subset of UML2 used in
particular ways is useful and so our work is in the form of a constrained subset of the UML. We expect that future revisions will expand
this support by encompassing the work of existing business modeling notations as well as demonstrating the use of the UML notation
for business modeling.
We also demonstrate how this metamodel can be used to generate platform-specific process languages, specifically the BusinessProcess Execution Language for Web Services (BPEL4WS). These mappings act as a validation of the model by ensuring that
metamodel fits the needs of business modelers, and that developed models can be automated and deployed.
Finally, the UML profile introduced in the submission is documented and demonstrated by example; however more detail will be
Business Process Definition Metamodel
Information ResourceProcess
BPMN
Mapped to
Mapped to
UML 2.0 Other
BPEL4WSJ2EE Other
-
7/30/2019 BPDM Response Revised Submission 04-08-03
10/215
10 Business Process Definition Metamodel
provided in a revised submission.
Gu i d e t o t h e m a t e r i a l i n t h i s s u b m i s si o n
The metamodel documented in this submission provides a common language, for describing business processes in an implementation
independent manner. This is not to say that the models are abstract from execution details, on the contrary it is our aim to describe
executable processes, these models are intended to be abstract from the detailed implementation (platform) mechanisms. This shared
subset of UML 2.0 also acts as an agreed base for translation to such implementations where required. The adopted UML 2.0superstructure metamodel provides much of what is required for the definition of business processes.
The following semantics are not present in UML 2.0 and are introduced in the Business Process Definition Metamodel:
?? Resource modeling (deferred until later submission)
?? Access control (deferred until later submission)
?? Compensation
?? Annotations for simulation (deferred until later submission)
?? Correlation (routing of incoming requests to the appropriate process instance, deferred until later submission)
?? Observation (audit/monitoring, deferred until later submission)
The specification of the exact UML 2.0 subset in the area of PIM and alternate PSM models is still under development but will becompleted in a revised submission.
The submission contains the following specification details.
UML 2 .0 Pro f i le fo r BPD
The metamodel proposed here is specified as a UML 2.0 profile because, although a specialized notation for Business Process Definitionmay be preferable for some scenarios, there is also value in enabling generic UML tools to both author and consume business models.It will be important for some of the identified roles because they would be transforming from the business models into IT models, such
as transformations from business information models into data models.
UML 1 .5 Pro f i le fo r BPEL4WS
-
7/30/2019 BPDM Response Revised Submission 04-08-03
11/215
Business Process Definition Metamodel 11
An existing UML 1.5 profile for automated business processes with a mapping to BPEL4WS is included in Appendix A. This profile will
be updated to meet the requirements of this RFP. The mapping has been implemented and provides a proof of concept for mapping
from a UML-based business process definition language to a specific execution language.
The audience for this model is primarily technical information technology staff realizing processes in runtime software. The profile actsas a UML-based visualization for a language which has no standardized or described graphical notation.
Mapp ing f r om BPD Me tam ode l to BPEL4WS
This identifies a mapping from this profile directly to BPEL4WS.
The audience for the BPD metamodel is business users more concerned with the capture of the business semantics of their processesthan the details of a runtime implementation. This mapping provides a route from the business-level model directly to a runtime
model.
Mappin g f rom EDOC to BPD Metam ode l
This demonstrates that the set of concepts and model elements developed by EDOC are similarly available when using the BPDMetamodel. In this case by mapping from the EDOC profiles to the BPD profile an automated mapping could be developed by a tool
vendor to translate user developed models from EDOC to BPD.
Mapp ing f r om BPMN to BPD Me tamode l
It is also important to understand that the UML notation however is frequently seen as daunting or too technical for businessanalysts and so we expect and encourage others to provide alternate notations for the subset of the UML that we propose here.
One of the submission goals is to make the UML notation less daunting to the business user, primarily by understanding existing
notations. This will be further addressed in later submissions.
In the case of the BPD metamodel we will provide an example mapping from the BPMN notation to the subset of UML we haveidentified. This would provide tool vendors the opportunity to support users requiring a BPMN graphical notation using the standardizedsemantic metamodel we present here.
Overa l l design r a t i ona le
-
7/30/2019 BPDM Response Revised Submission 04-08-03
12/215
12 Business Process Definition Metamodel
This submission does not require any changes to the UML 2.0 metamodel though it may make recommendations for improvements to
future versions of UML for better support of this standard. Where possible the submission does not introduce new elements to the UML
language, but identifies a subset of the UML that can be used to describe business process models. However, where concepts need to
be disambiguated a profile is provided to introduce a small set of stereotypes.
This metamodel does address automated business processes, through transformations to process automation languages such as
BPEL4WS. It is also the goal of this profile to model processes that are not intended for automation in this way processes that aresolely implemented through collaborating people.
St a t e m e n t o f p r o o f o f c on c ep t
Substantial parts of the metamodel presented here are based directly on the metamodel underlying products in development at IBM.WebSphere Business Integration (WBI) Modeler1 is a platform-independent business process modeling tool that also provides atransformation to a runtime language (MQSeries Workflow FDML).
IBM is in the process of updating this product line and at the same time integrating with the product lines from the Rational brand.
This update includes a new metamodel, moving from a proprietary base to one based directly upon UML2 and including the experiencefrom Rational in applying the UML to business modeling. This submission describes a subset of the metamodel for that product, someareas are altered to reflect the fact that only a subset has been taken and some associations are therefore not available.
In the area of translation to automated business process languages with the mapping from UML to BPEL4WS; IBM has made a version
of tools to implement this mapping available on the IBM alphaWorks web site 2. This technology can generate BPEL4WS from UML
models in either IBM Rational Rose or IBM Rational XDE. In the future this mapping will be used to define the transformation of modelsfrom the platform- independent WBI Modeler into BPEL4WS.
Chan ge H is tory
Revision Date Comments
2.0.0 August 2004 Revised Submission.?? Introduced Concepts and Overview section based
on an updated version of the whitepaper?? Updated the mapping to BPMN
1.0.2 January 2004 Revised Submission.
1http://www.ibm.com/software/integration/wbimodeler/
2http://www.alphaworks.ibm.com/tech/ettk
-
7/30/2019 BPDM Response Revised Submission 04-08-03
13/215
Business Process Definition Metamodel 13
?? Included new co-submitters including BPMI.org.
?? Reorganized to better follow the standard
submission structure.
?? Updated references and included the BR SIG
business modeling white paper.
?? Introduced the stereotype Document to the
profile, describing its relation to Entity.
0.9.1 December 2003 Working Group draft for Revised Submission.
Added Unisys as supporter, correctly placed BEA as
supporter rather than submitter.Added introductory section on principles.
Renamed the modeling view Policyto be Governance in line with the expanded definition
in the IBM Business Rules Submission.Process and Entity now use the meta class Class
(StructuredClass) instead of Component.Updated the diagrams in the examples.Added initial section on organization.
Included Appendix on mapping from EDOC to BPD.Included updated BPMN mapping.
0.9 August 2003 Initial Submission
-
7/30/2019 BPDM Response Revised Submission 04-08-03
14/215
14 Business Process Definition Metamodel
Response to RFP Requ i r em ent s
M a n d a t o r y Re q u i r e m e n t s
Mandatory Requirement Resolution
6 . 5 . 1 R equ i r ed M e t am ode l
Responses to this RFP shall provide a
metamodel forming an abstract
language for t he expression of business
process definitions.
Proposals shall depict the solicited
metamodel using UML.
This proposal reuses a subset of the UML 2.0
metamodel and extends UML 2.0 with aBusiness Process Definition package.
UML 1.5 and UML 2.0 profiles of themetamodel are also provided to enable tometamodel to be used with current and future
vanilla UML tools.
6 . 5 . 2 M et am ode l Com pa t i b i l i t y
Proposals shall use the appropriate
elements of existing metamodelsincluding, UML, EDOC, MOF and OCL.
We observe that much of the modeling
capability introduced in EDOC is now directly
supported in UML 2.0. This proposal thereforebuilds directly on UML 2.0.
OCL can be used with this proposal wherever a
side-effect free expression language is
required.
We observe that there is an overlap between
the concepts required to fully specifyexecutable business processes and the
concepts required for service-oriented
architecture. We recommend that SOA is
covered in a separate RFP which is compatiblewith this one.
An appendix to this document describes therelationship between this specification and
EDOC.
6.5 .3 MOF Com pl ian ce The metamodel introduced by this proposal is
-
7/30/2019 BPDM Response Revised Submission 04-08-03
15/215
Business Process Definition Metamodel 15
Mandatory Requirement Resolution
The resulting metamodel shall be MOF-
compliant.
MOF-compliant as it is currently a subset and
profile of UML2 and not a separate metamodel.
6 . 5 . 4 Pr oc edu r a l and r u le - bas ed
f l o w o f c o n t r o l
Proposals shall provide for specificationof process flow based on control flowfrom completed activities to activities
to be initiated as well as initiation of
activities based on rules or pre-conditions.
Comment: We assume this meansActivityNode in the UML 2.0 sense
rather than Activity and is therefore
referring to control flow within a
process.
Comment: The term precondition
should not be used here as it refers tosomething that is not side-effect free.
This proposal supports procedural control flowby reusing the activity and action modeling
elements of UML 2.0.
This proposal will support the initiation ofcontrol based on an expression becoming true
through UML 2.0 AcceptEventActions with
ChangeTriggers and TimeTriggers. The latterprovides the ability to initiate control based onpolicies such as start this process at 11:00amon a Friday.
6 . 5 . 5 Speci f i c a t i on o f Ac t i v i t y
Per fo rmers
Proposals shall provide for thespecification of selection criteria for
performers and resources, includinghuman performers, applications,passive resources and sub-processes.,
The basis for selection shall include
a) Specific resource identity
b) Resource attr ibutes
c) Relationships wit h other
assigned resources
d) Relationships to subj ect mat ter
Tasks may have associated resourcerequirements which are expressed in OCL.
Yes. Resource typesare classifiers that haveinstances with identity. Instance specifications
pinpointing a particular resource may beassociated with a task.
Yes. Resources can have attributes.
Yes. The deployed resources of a process willbe accessible to resource queries.
Example will be included
Yes. Resource requirements can refer toprocess variables, task input objects andconstants.
-
7/30/2019 BPDM Response Revised Submission 04-08-03
16/215
16 Business Process Definition Metamodel
Mandatory Requirement Resolution
e) Combinations of the above. Example will be included
Yes.
6 . 5 . 6 As y nc h r onous and C onc u r r en t
Execut ion
Proposals shall provide mechanisms forspecifying concurrent execution of
activities:
a) A process model shall be able todefine when multiple,
concurrent activit ies are
init iated.
b) A process model shall be able to
define when an activity or
completion of a process depend
on the completion of multiple,
concurrent activit ies. This shall
include init iation of an activity
based on completion of n of m
concurrent activit ies (where n
< = m ).
c) Business processes shall be able
to inv oke processes that
execute asynchronously.
d) The model shall support
specification of t he publication
of events and m essages for
asynchronous delivery.
e) The model shall support receiptof messages from a collaborator
and subscription to events.
Messages and events shall be
received as asynchronous inputs
Yes. The control flow semantics of UML 2.0activities are adopted by the profile.
UML 2.0 join specs provide the abilities to
specify complex joins within a processinstance.
This is the normal case with the implicitcreation semantics adopted by this proposal.
The case where a business process isinstantiated with a synchronous call andcompletes on return is simply a special case.
Synchronous and asynchronous sending ofmessages is supported as in UML 2.0. Point-to-
point and broadcast semantics are supported.
Asynchronous receipt of messages/events is
supported as in UML 2.0.
-
7/30/2019 BPDM Response Revised Submission 04-08-03
17/215
Business Process Definition Metamodel 17
Mandatory Requirement Resolution
to a receiving activity executing
concurrently with other activit ies
in th e process.
6 . 5 . 7 Spec i f i c a t i on o f i n i t i a t i on and
t e r m i n a t i o n
Proposals shall provide modeling
constructs for specifying wh en and how
activit ies and pr ocesses can be in it iated
and terminated:a) Pre or post conditions
Comment: Preconditions andpostconditions in UML do not
alter runtime semantics.
Perhaps this is intended to allow
when conditions that emit atoken when an expressionbecomes true.
Actions for initialization and termination
with consideration of actions required
for abnormal termination, including theinitiation of compensating processes.
b) Propagation of term ination to
active activit ies and sub-
processes.
Initiation and termination of processes is
implicit rather than explicit from the point ofview of a client of the process. This decouplesthe service requester and service provider and
facilitates scenarios where the first of a number
of events will lead to a new instance with the
subsequent events being routed to the existinginstance. Routing event s to existing instances
requires correlation, w hich will be int roduced in
extension of UML 2.0.
Routing not currently described in this revision
a) Supported through UML 2.0AcceptEventActions withChangeTriggers.
b) Initialisation of processes and tasks is
implicit. Exception handling is supportedas defined in UML 2.0. UML 2.0 does notinclude compensation. This proposal
adopts the BPEL4WS semantics forcompensation within a process.
c) UML 2.0 ActivityFinalNodes andException semantics are supported. Thenotion of subprocesses requires a notion
of composition which is providedthrough UML 2.0 composite structures.
Note, we differentiate between embedded sub-processes (StructuredActivityNode) andinvoked/shareable sub-process which are
Activities.
6 . 5. 8 C ho r eog r aph y Supported. Choreography is expressed using
collaborations with roles. The types of the roles
-
7/30/2019 BPDM Response Revised Submission 04-08-03
18/215
18 Business Process Definition Metamodel
Mandatory Requirement Resolution
Proposals shall provide for the
specification of the signals andexchanges performed betweenprocesses to achieve collaboration as
described in 6.2.5.
specify the interfaces provided and required by
the roles. Permissible choreographies arespecified using activity graphs.
Example to be included, specifically to
demonstrate the notion of global processes
6 . 5 . 9 Aud i t Log Gene r a t i on
Proposals shall include provisions in the
metamodel to allow the specification ofbusiness logic related audit log records.
This part of t he metam odel shall
provide for t he specification of:
a) The content of the log record in
relation to t he process definit ion
b) The timing of the log record
emission
Supported. Audit log message types must
include identification and time properties. An
audit action adds identification and timeinformation and sends such events to a logicalaudit service. Audit messages can containproperties that will be populated with
expressions that have access to process
variables.
A MOF identifier is included in the log to enablethe event to be interpreted in the context ofthe business process definition. Information to
identify the process instance is also added.
(Details TBD.)
The audit action automatically adds the currenttime to audit messages.
This is not currently described in this revision
6 . 5 . 10 D i s t r i bu t ed Ex ec u t i on
Proposals shall ensure that the form of
definition does not preclude distributedexecution.
Supported. No assumption is made thatpartners (including sub-components) are in thesame namespace or at the same physical
location. No support is provided for distributingan individual process instance sub-components should be introduced where this is
required.
6 . 5 . 11 P r oc es s D ef i n i t i on im po r t
and ex po r t
Proposals shall support XMI export andimport for exchange of process
Supported. XMI is the default import/exportformat.
At this time there are no metamodel extensio ns
-
7/30/2019 BPDM Response Revised Submission 04-08-03
19/215
Business Process Definition Metamodel 19
Mandatory Requirement Resolution
definitions. and so standard XMI should be sufficient.
6 . 5 .12 N on - N o r m a t i v e N o t a t i on
M app ings
As a proof of concept, proposals shall
provide non-normative m appings to
two recognized business process
modeling languages, e.g.:
BPEL4WS
XPDL
(See section 6.4 for a non- exclusive list
of references to relevant specifications)
A mapping to BPEL4WS is provided.
Reverse mappings from one or more legacyworkflow languages will also be included.
Mappings to other execution languages can bedefined as required.
6 . 5 . 13 Com pa t i b l e Ve r s ions o f
Ex is t i ng Spec i f i ca t ion s
The final, revised submission shall be
based on the most recently adoptedversion of related specifications (e.g.,UML and MOF) that is adopted three
months prior to the final revised
submission deadline for this RFP.
Yes. The final, revised submission will be based
on the most recently adopted versions of
standards, as required.
A profile for UML 1.x will also be provided asthe marketplace will not move completely toUML 2.0 immediately.
Op t i o n a l Re q u i r e m en t s
Optional Requirement Resolution
6 . 6 . 1 Add i t i on a l Non - N o r m a t i v e
M app ings
Proposals may provide additional
mappings to recognized languages for
business process definition,complementing the list of mandatory
mappings requested in 6.5.12.
To be decided.
-
7/30/2019 BPDM Response Revised Submission 04-08-03
20/215
20 Business Process Definition Metamodel
6 . 6 . 2 Add i t i ona l Ex ec u t i on
Cons t ra in t s
Proposals may provide for the ability to
model additional execution constraints,
like maximum duration of a process or
activity execution. For these additional
constraints the behavior of constraint
violation should be modeled and its
effect on the pr ocess enactment
described.
None identified at this stage.
I ssues to be d i scussed
Issue to be discussed Discussion
6 . 7 . 1 R ela t i ons h ip t o ex i s t i ng U M L
m e t a m o d e l
Proposals shall discuss the relationship
of m odel elements used for business
process modeling to the existing UML
metamodel to demonstrate consistency
with the UML metamodel.
This proposal reuses the modeling elements
introduced in UML 2.0. Where appropriate
concepts are not directly supported extensionsin keeping with UML 2.0 are introduced.
UML 2.0 Uses Cases may be used fordocumenting the external view and business
value of business processes.
UML 2.0 Activities and Actions are used for the
business process definitions andchoreographies.
UML 2.0 Collaborations and Roles are used to
specify interaction patterns between partners.
UML 2.0 Templates are used to permit the use
of templates in business process definitions.
UML 2.0 Composite Structures and Activities
are used to represent composite businessprocesses.
6.7 .2 Re la t ionsh ip t o Re la ted UML A mapping from EDOC to BPD is included as
-
7/30/2019 BPDM Response Revised Submission 04-08-03
21/215
Business Process Definition Metamodel 21
Pr o f i l es , M e t am ode l s and N o t a t i ons
Proposals shall discuss how business
process definitions may be incorporatedwith or complement other UML profiles,metamodels and notations for
specification of business systems,particularly the UML Profile for EDOC.
an appendix.
6 . 7 . 3 M app ing t o Ex i s t i ng Bus ines s
Pr oc ess no t a t i ons and U M L
N o t a t i on
Proposals shall discuss how theproposed metamodel may be mapped
to existing process definition notations
as a demonstration of completenessand compatibility.
Currently the submission includes a mapping
from an existing business modelling notation(BPMN) to the metamodel defined.
UML 1.5 and UML 2.0 profiles corresponding tothe BPD metamodel are a part of this
submission. Instances of the profile can be
expressed using UML Notation with stereotypekeywords or icons. While a tailored notationmay be preferable, this option is available for
creating business process definitions using
generic UML 1.5 and UML 2.0 tools.
6.7 .4 Resource Mode l
Proposals shall describe assumptionsregarding an associated resourcemodel.
An associated resource model must provide thedomain for resource requirement specifications
(6.5.5). We will propose a resource model forthe definition of individual, bulk, resource
types, and roles, which represent a resource'scapability to perform tasks. Roles may bescoped, to account for the dependency of such
capabilities on subject matter.
This is not currently described in this revision
6 . 7 . 5 Re la t i ons h ips w i t h r e l a t ed
OMG spec i f i ca t ion ac t iv i t ies .
Proposals shall discuss how thespecifications relate to the specification
development efforts currently underway as noted in Section 6.4.3.
UML 2.0
Covered above.
Business Process Runtime Interfaces
MOF 2.0 Versioning
MOF 2.0 Queries/Views/Transformation
MOF 2.0 Q/V/T is under definition at the timeof writing. The final expression of mappings
-
7/30/2019 BPDM Response Revised Submission 04-08-03
22/215
22 Business Process Definition Metamodel
from this profile to execution languages willuse the QVT formalism assuming that QVT is
sufficiently complete at that time.
CWM Provides a detailed metamodel fordescribing data and information, this should be
supported as an alternate way to describe BPDinformation models.
There is an existing Organizational StructureRFP that should supersede the organization
model presented in this submission.
The Business Rules RFPs should be able todescribe constraints on processes models.
6.7 .6 Cons is ten cy checks
Proposals shall discuss how the
specification supports consistency
checks, particularly between
choreography specifications and a
business process that part icipates in
the choreography.
The proposal defines the conditions under
which an executable process can be said torealize a role in a choreography.
6 . 7 . 7 Ac c es s Con t r o l
Proposals shall discuss how access
authorization for process data,
artifacts, activities in a process, andprocess enactment may be based on
process roles of individuals associatedwith a specific process instance.
Supported. Access control will be consistentwith Resource specification.
6 . 7 . 8 W eb s e r v i c es and
c o l l abo r a t i on s uppo r t
Proposals shall discuss how thespecification supports the definition of
business processes and choreography
for web services and other
collaborations including therelationships with messages,documents, interface specifications,
This proposal adopts an approach that isconsistent with a service-oriented architecture
and can therefore be mapped to web servicestechnologies.
This proposal will not provide a UML profile for
service-oriented architecture but will introduce
modeling elements as required.
If a standard SOA profile is available in a
-
7/30/2019 BPDM Response Revised Submission 04-08-03
23/215
Business Process Definition Metamodel 23
participant roles, signatures andmessage exchanges.
suitable timeframe then this proposal willdepend on it.
-
7/30/2019 BPDM Response Revised Submission 04-08-03
24/215
24 Business Process Definition Metamodel
Par t I I Subm ission Det a i l s
Scope o f th e sub m ission
This submission looks at the problem of business process definition in context. In the following sections we will describe the problem of
business process definition as a part of a broader activity business modeling. Business modeling is, as the diagram belowdemonstrates, comprised of a set of related disciplines. In many cases an organization is only focused on certain of these areas, for
example business strategy is an area of particular interest right now.
In terms of this submission the scope is restricted to the areas of Process, Automation and Resurces. However it is clear that noprocess model can be complete without addressing information and organization and this submission will present default models in this
area.
?? St ra tegy ; encompasses business goals, strategic objectives and can be used to measure business performance. Note, not inthe scope of this submission.
?? Governance ; includes the modeling of regulatory concerns, policies and rules.
?? I n f o r m a t i o n ; high-level modeling of information sources and includes modeling of business artifacts, such as documents,products, parts, assemblies, etc.
?? Organ iza t ion ; the ability to capture organizational structure. An organization's responsibility (for tasks) and ownership (ofresources) can only be specified in conjunction with other models (Resource, Process). The main purpose of an Organization
Model is to define organizational units (such as companies, project teams, departments, etc.) and their interrelationships. Withthis in place, Resources, Tasks, etc. can then be referenced, and the underlying semantics may defined as ownership of,responsibility for, etc.
-
7/30/2019 BPDM Response Revised Submission 04-08-03
25/215
-
7/30/2019 BPDM Response Revised Submission 04-08-03
26/215
26 Business Process Definition Metamodel
?? Co r p o r a t e De v e lo p e r responsible for the development and deployment of business applications and business components.
These developers tend to be less skilled in the details of the software platform, and rightly so, their job is to deploy businessvalue through these applications, not know the latest JDK version.
?? D a t a/ I n f o r m a t i o n A r ch i t e ct responsible for the development of data models and a stakeholder in interchange models for
information integration.
The following table reflects the roles (Author, Secondary author, Reviewer) that these actors play in the development of the models
defined in the framework above. This table is organized such that those stakeholders requiring a more abstract/less detailed view areat the top and those requiring less abstraction and/or more detail are at the bottom. We have also highlighted the columnsrepresenting the models relevant to this submission.
Information
Organization
Resource
Process
Automation
Strategy
Governance
Simulation
Financial
Observation
Executives R R R R R
End User R R R
Business Analyst A A R A A A R A
Process Specialist S S A S A R A
Solution Architect R S R A R R
Corporate Developer
Operations Management
Data/Information Architect R
It is our intent to propose a set of views, their contents and a mapping to the MDA framework here. This will be provided in a later
revision.
Proposed Con fo r m ance Cr i t e r i a
At this time no conformance criteria have been identified.
-
7/30/2019 BPDM Response Revised Submission 04-08-03
27/215
Business Process Definition Metamodel 27
Pr o p o s e d N o r m a t i v e Re f e r e n c es
Unified Modeling Language: Infrastructure version 2.0 (ptc/03-09-15), January 2003, OMG
Unified Modeling Language: Superstructure version 2.0 (ptc/03-08-02), April 2003, OMG
Business Process Modeling Notation Working Draft (0.9), BPMI.org
Business Process Modeling Notation Working Draft (1.0), August 25th 2003, BPMI.org
BPEL4WS 1.1 http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/
UML Profile for Enterprise Distributed Object Computing Specification (ptc/02-02-05), February 2002
Rational UML Profile for Business Modeling
Unified Modeling Language: OCL 2.0 (ptc/03-08-08), August 2003
Architecture of Business Modeling (br/03-11-01), OMG
Pr o p o s e d L is t o f T er m s a n d D e f i n i t i o n s
Au t om a t ed P r oc ess
A Process that is automated, at least in some part, by a software application or process runtime (such as the WebSphere ProcessChoreographer). An automated process by definition is an executable process.
Bus iness Document
A Business Document models exactly what you would expect a paper document. As such it has no identity (in the Object sense), no
behavior and no state.
Choreography
In implementing a value chain processes communicate between each other. These inter-process communications have to be governedwith a contract that defines the set of messages and the sequencing of messages. This contract is known as the choreography, or
global process.
Executab le Process
A Process that has executable semantics, though this need not be automated as it may be executed solely by people within anorganization.
Managed Process
-
7/30/2019 BPDM Response Revised Submission 04-08-03
28/215
28 Business Process Definition Metamodel
The processes described as part of a choreography define, in effect, an interface (sometimes termed an abstract process) which has to
be implemented by some actual process, these implemented processes are the managed processes. A managed process by definition
is an executable process.
Par tner Process
The processes described as part of a choreography are often termed partner processes.
Resource
TBD
Role
TBD
-
7/30/2019 BPDM Response Revised Submission 04-08-03
29/215
Business Process Definition Metamodel 29
The following diagram demonstrates the different process notions; the abstract processes Buyer and Seller are partners in a
choreography called Ordering. Two companies agree to implement the choreography and so two managed processes are required.
My Company uses a software automation package to automate the Buyer process whereas Your Company simply executes the Seller
process with an efficient sales force of trained staff.
Proposed L i s t o f Sym bo ls
Currently there are no symbols defined as part of this submission. The appendix mapping BPMN to BPD does however introduce analternate notation.
Bus iness Pro cess Def in i t i on Met am ode l
The adopted UML 2.0 superstructure metamodel provides much of what is required for the definition of business processes. The
following sections identify the subset of UML 2.0 appropriate for business process definition.
The model deals with descriptions of business processes at a level abstract from any implementation technology, even where thatimplementation technology may be humans executing a purely manual process. This does not imply that the model cannot and does
not describe executable processes, simply that it makes no assumptions about the form of the execution. It is certainly true that
current notations such as IDEF0 make no assumptions about the implementation of a process, and neither does the most commonly
Ordering
(Choreography)
Buyer
(Partner)
Seller
(Partner)
My Company Your Company
Buyer(Managed, Automated)
Seller(Managed, Executable)
-
7/30/2019 BPDM Response Revised Submission 04-08-03
30/215
30 Business Process Definition Metamodel
used notation, boxes-and-lines. In our case we simply intend to specify a common subset of the standard UML 2.0 superstructure that
can be used to support this level of modeling.
It is worth noting that although the subset of the UML we have identified would provide the user a level of completeness that wouldallow them to specify and execute the complex business models there is no specific requirement that they do so. It is not usually thecase that models specified at this level of abstraction are complete, it is not a requirement that they be complete.
Concep ts and Overv iew
This section introduces BPDM concepts though an example. It also introduces notations that allow to view a process model at varyinglevels of detail, while maintaining consistency with the underlying model and semantics. A formal definition of the metamodel and its
relationship with UML 2.0 will be provided in a further revised submission.
I n t r o d u c t i o n
Business processes are "behavioral building blocks" of a business: They describe the activities a business performs in pursuing its
objectives. They can be broken down into subordinate processes and eventually tasks that are considered atomic. Business processesdo not exist in isolation. In implementing a value chain business processes interact with partners, and these interactions may cross
organizational boundaries.
We therefore model two aspects of a business process: its internal behavior, using a flow model, and its external interactions, using
collaborations and associated protocol specifications. The first view is that of the process execution environment, the second view is
required to connect processes with other components in a service-oriented architecture.
In introducing the modelling concepts, we will use the following example:
A producer of electronics assemblies implements a "Just-in-Time Manufacturing" process: Incoming customer orders areevaluated based on the available manufacturing capacity and the parts inventory: If suffic ient quantities for all parts are
on stock and assembly line time slots are available, an order confirmation is returned to the customer, the assembliesare produced, and finally delivered together with an invoice. If assembly line capacity is not available, the order is
declined. If manufacturing capacity is available but some parts are not, replenishment orders are first issued topreferred suppliers, including a deadline that leaves enough time for production. For parts that the preferred suppliercannot deliver within the allotted time frame, an auction is launched accepting bids from suppliers in the open market. If
all parts can be procured before the production start deadline, the order is confirmed and the assemblies are produced,delivered, and invoiced. Otherwise, the order is rejected.
The internal view(or behavioral view) of a process shows "how it is performed", at the level of detail that the modeler knows orchooses to reveal: it is modeled as a partially ordered set of tasks. Figure 1Figure 1 shows a simple, control-flow only, internal view of
-
7/30/2019 BPDM Response Revised Submission 04-08-03
31/215
Business Process Definition Metamodel 31
the Just-in-Time Manufacturin gprocess.3 The meaning of symbols used in the diagram, and their implied semantics, 4 will be defined in
chapter 0 "Operational Processes (Modeling Process Behavior) ".
3 The notation employed in this paper is not normative, but was chosen to provide a clear illustration of the modelling concepts we
would like to support. In particular, it is not the standard notation of UML 2.0.
4 Please note that while our process definitions have well-defined semantics, and hence are executable in principle, this does not implythat they are automated. On the other hand, they may be refined to the level of detail required by an execution engine, for complete
or partial automation.
-
7/30/2019 BPDM Response Revised Submission 04-08-03
32/215
32 Business Process Definition Metamodel
Just-In-Time-Manufacturing
check
Readiness
determine ifmanufacturing
capacity andall parts are
available
createConfirmation
manufacturing
capacity available,some parts must
be procured
insufficientmanufacturing
capacity
not all partsprocured
A
all parts
procured
manufacturing
capacity andall parts are
available
A
confirmOrder>Confirmation
to customer
produce
Assemblies
createInvoice
to parts
to invoice
create
Rejection
partsProcurement
+
takeOrder
receiveOrder
fromc
ustomer
declineOrder
sendRejection
tocustomer
andterminate
returnShipment
sendShipment
tocustomer
andterminate
Figure 1: Just-in-Time Manufacturing Process (internal / behavioral view)
The externalview (or collaborative view) of a process shows "how it interacts". It specifies the partner roles that a process expects tocollaborate with, and their interaction protocol. A high-level collaborative view of the Just- in-Time Manufacturingprocess is shown inFigure 2Figure 2. The detailed interaction sequences associated with the collaborations (Order Fulfillment, Parts Provisioning and Open
Auction) are not shown in this overview diagram, but will be introduced in chapter 0 "Process Components".
-
7/30/2019 BPDM Response Revised Submission 04-08-03
33/215
Business Process Definition Metamodel 33
Just-in-Time-Manufacturing
: Order
: Shipment
: Rejection
(Customer)
Order Fulfillment
: Confirmation(Supplier)
Parts Provisioning
(Bidder)Open Auction
Figure 2: Just-in-Time Manufacturing process (external / collaborative view)
Process Components
To enable business processes to collaborate with partners it is important for them to be defined in a composable fashion. To this end,we apply the paradigm of service-oriented architecture to business process modeling: We treat a business process as a definition of abehavioral component5 that connects to and interacts with other components (its partners). The internal behavior of a process then
includes tasks that conduct the corresponding partner communications.
A complete solution is modeled as a network of interconnected components interacting via long-running conversations. 6 The same
process can appear in multiple solutions and can be connected to different partners in each case, as long as the "partner roles" theyprovide match those required by the process. The partner interaction protocol is described using the concept of "collaborations".Partner roles and collaborations are introduced in the following sections.
5 The term component is used in this paper to denote the view of a process as a encapsulated behavioral element that can be
connected with other such elements. Connections represent communication channels amongst these. Please note that this is notexactly the "Component" class of UML 2.0.
6 Strictly speaking, instantiations of these components interact via long-running conversations; see section 0 "Process Life-Cycle and
Inter-Process Communication" for a more in-depth description.
-
7/30/2019 BPDM Response Revised Submission 04-08-03
34/215
34 Business Process Definition Metamodel
The Just- in-Time Manufacturingprocess engages in three collaborations with partners: order fulfillment (with customers), parts
provisioning (with suppliers), and open auction (with bidders). This is shown in Figure 2Figure 2. In the following sections we
demonstrate how to model the external view of the process, including its partner dependencies and collaboration protocols.
I NTERFACES
The component view of a process states its dependencies on its partners through "interfaces", which define the points of interactionbetween the process and components external to the process. The partners be realized inside or outside thesame organization. In our
Just- in-Time Manufacturingexample, the manufacturing process collaborates with three partner roles: the customer who sends anorder and must receive a response, a set of preferred suppliers who may provide parts, and potentially bidders participating in an open
market auction.7
A graphical view of this is shown in Figure 2Figure 2 where interfaces are show an open boxes containing a list of input messages
(those accepted by the process) and output messages (those sent by the process). Interfaces must be connected to matchinginterfaces on partner components in order to obtain a complete solution.
COLLABORATI ONS
[Remainder of this section omitted in this version. Update required.]
Opera t i ona l Processes ( Mode l in g Process Behavio r )
In this chapter, we describe the fundamentals of modeling process behavior. Just as the preceding chapter on the component view of
processes, this makes intensive use of concepts found in UML 2.0
TASKS AND BLOCKS
The behavioral view of a business process describes the sequencing, input, output, and resource requirements of business tasks.
7 Note that in Figure 1Figure 1 process steps communicating with the customer are shown, while communication with other partnerswhich would become apparent as one refines the procure part from preferred supplierand run auct iontaskshas not been modelled
explicitly.
-
7/30/2019 BPDM Response Revised Submission 04-08-03
35/215
Business Process Definition Metamodel 35
Tasks are the basic units of work in a business process. Tasks may be executed by humans or automated, and some may involve
partner communication.
Tasks can be structured into Blocks (revealing subordinate steps to some level of detail). An example of a block is the procure partstask in Figure 1Figure 1. An unblock is atomic from the modeler's point of view, who at some point decides to not further refine its
description.8
TASK I NPUT PI NS AND OUTPUT PI NS
Business tasks may have several input pins(representing alternative ways to provide input and spawn a new execution) and several
output pins(representing alternative outcomes). In Figure 1Figure 1, input pins and output pins are omitted and can be inferred fromincoming and outgoing flows (arrows).
Each task execution consumes an input object from exactly one input pin and produces an output object on exactly one output pin
For example, the check if manufacturing capacity and part s availabletask, which represents a three-way decision, has three possibleoutput pins, whose conditions are indicated in parentheses.
A task can be triggered via any one of its input pins, and upon termination provides output through any one of its output pins.
TASK I NPUT AND OUTPUT
Input pins are typed to indicate the objects that they can accept, output pins are typed to indicate the objects that they produce.Object types can be composite. We will now refine the Just- in-Time Manufacturin gprocess shown in Figure 1Figure 1 by defining each
task's input pins and output pins and specifying the of input and output items. The resulting picture is shown in Figure 3Figure 3.
The chevron arrows on the task boundaries denote input pins and output pins. (Input pins point towards the centre of the task, output
pins point away from the centre.)
Adding object flow detail to the Just -in-Time Manufacturin gprocess will result in the picture presented in Figure 3Figure 3. Some of the
features shown have not been discussed so far:
o The triangles labeled "A" are continuation symbols, providing a convenient way to show where flow continues and
avoid diagram clutter. They are a notational convenience and don't introduce any additional semantics.
8 Few tasks, if any, are really atomic. For automated tasks, machine instructions could be considered the atomic level, but even thosemay be realized as "micro programs". For human tasks, one could consider an action like "sign contract" atomic, but upon closerinspection this involves finding a pen, opening it, pointing it to the paper, moving it, ... Atomicity of a task always depends on the
modeller's view point
-
7/30/2019 BPDM Response Revised Submission 04-08-03
36/215
36 Business Process Definition Metamodel
o The cylinders represent repositories for tasks to deposit input / output items. Please refer to section 0 "Repositories"
for additional detail.
o Outcomes marked by small, upright triangles (for example, the "some part unavailable" output set of procure parts)denote exceptions or faults. When one of these is reached, compensation may be triggered for the task that endedabnormally. See section 0 "Exceptions and Compensation" for additional detail.
o Task inputs and outputs always have multiplicity 1 so no multiplicity needs to be specified. Types of the form Object[n] can be used to indicate the passing of collections. Repositories must be used to mediate between pins that take
individual objects and pins that take multiple objects.9
o Flows between pins may map individual parts of the output type to individual parts of the input type. For example,the flow from produce assembliesto the Shipment message has the annotation from items to parts indicating that
the items part of the Assemblies type should be placed in the parts part of the Shipment type.
o The "available" outcomes of the procure part from preferred supplierand run auctiontasks are not wired to any
follow-on tasks, because there is no immediate follow-on activity after a part was successfully procured (see section0 "Block Termination" for further discussion).
9 This approach is based on customer feedback and the complexities of combining pin multiplicity with complex control flow andcomposite inputs and outputs.
-
7/30/2019 BPDM Response Revised Submission 04-08-03
37/215
Business Process Definition Metamodel 37
Just-in-Time-Manufacturing
checkavailability
--
determine ifmanufacturing
capacity andall parts are
available
order: Order
order:Order
needParts: Requisition [1..n]
createConfirmation
noWay -- insufficient
manufacturing capacity create
Rejection
ord:Order
rej:Rejection
notAllProcured
AallProcured
order: Order
readyToGo
A
order:Order
confirmOrder
to customer
c:Confirmation
c:Confirmation
produce
Assemblies
create
Invoice
order: Order
ord:
Order
in:
Order
inv:
Invoice
out:
Assemblies
from items
to parts
to invoice
Shipment
parts: Assembly [n]
invoice: Invoice
Assemblies
items: Assembly [n]
parts
procurement
+
order: Order
Orderfrom
Customer
Rejection
toCustomer
isterminating
Shipment
toCustomer
isterminating
{remove}
{copy}
order-
Confirmed
{copy}
{copy}
Confirmation
to customer
getRequisitions:
Requisition[1..n]
Figure 3: Just-in-Time Manufacturing process, after adding task input / output detail
TASK LI FECYCLE
An execution of a task is started when one of its input sets (entry points) receives the input (tokens) it needs.
When execution ends, a task provides output at one of its output sets, which represent the task's alternative exit points or outcomes.Unblocks end "whenever they are done" and the events or time by which this happens are not modeled. Modeling the termination of a
block is described in section 0 "Block Termination".
The procure part from preferred suppliertask in Figure 3Figure 3 has no multiplicity specified for its input and thus will accept part
requisitions only one at a time. If more than one part is out of stock, multiple concurrent executions of this task will be started. (The
-
7/30/2019 BPDM Response Revised Submission 04-08-03
38/215
38 Business Process Definition Metamodel
procure partstask represents all procurement activity on behalf of a manufacturing process; it can take any number of part
requisitions and is instantiated only once.)
Note that there is a hierarchy of task executions: Several procurement tasks from preferred suppliers and several auctions may be inprogress within a single procure partsblock. When the latter terminates, all nested procurement tasks and auctions still in progresswill be terminated as well.
BLOCK TERMINATI ON
A block completes when one of its output pins has a complete object, recall that an output pin may have a composite type and the
parts may be provided via multiple flows. Note that an incoming control flow can always be used to prevent early termination.A block may also have a single output pin that does not have any incoming flows (from inside the block). This is the default output pin
and is triggered when all activity has completed inside the block (there are no remaining tokens to trigger further behavior).
In Figure 3Figure 3 the default outcome of the procure partsblock ("all parts available") thus occurs when all executions of the nestedprocurement tasks have ended and no token has reached the output marked "some part unavailable". If the latter happensindicating
that an auction has failed to obtain a part that was unavailable from the preferred supplierthe procure partsblock and allsubordinate procurement activities will be terminated. This outcome is also marked as a fault, which causes it to trigger compensation
for nested procurement tasks that have successfully completed. (See chapter 0 "Exceptions and Compensation".)
Note that the output from the "available" outcomes ofprocure part from preferred supplierand run auct ion is not required. The defaultoutcome ofprocure partswill fire and signal that all parts could be procured, when all procurement activity inside it has ended; there
is no need to "collect and count" tokens reporting individual purchases.
FLOW CONTROL
The semantics of input pins and output pins can be used to model AND and OR conditions for inbound and outbound flow.
Consequently, explicit flow control constructs, such as decision, merge, fork, join, can usually be avoided. In Figure 1Figure 1 and
Figure 3Figure 3, for example, the check if m anufacturing capacity and parts availabletask represents a decision, characterized by its
three alternative outcomes; the create order confirmationand send rejection to customer tasks merge their inbound control flows (twoentry points and two corresponding input sets are modeled), while the send shipment to customer task joins its two inbound flows(only one entry point / input set has been specified); note that the matching fork is provided by the output set of send confirmation to
customer.
-
7/30/2019 BPDM Response Revised Submission 04-08-03
39/215
Business Process Definition Metamodel 39
If needed, however, the "classic" decision, merge, fork, and join elements can be modeled explicitly using special-purpose tasks. 10 A
summary of patterns for modeling flow control is presented in Figure 4Figure 4. The first row shows the standard control elements
using the notation of UML 2. The second row shows them using task with input pins and output pins to achieve the same result. 11
... ? ... ... ...
?
Decision Merge Fork Join
Figure 4: Summary of task notation for common flow controls
Note that these approaches can be combined to build tasks with complex input and output flows.
LOOPS
Loops in business processes are usually required to iterate over a set of objects. This is usually modeled by sending individual tokensrepresenting these objects to the task processing them. (As explained in section 0 "Task Lifecycle", multiple executions of a task may
10 This approach is also supported by the observation that decisions in real-world processes require time and effort; the same is true
for "forks" (for example, someone makes copies and distributes them); similarly, a join may be realized by a person tracking thecompletion of several concurrent tasks and triggering subsequent steps only when all are done [...] In all cases, these "control steps"
take time and resourcesand thus can be considered tasks.
11 Control and object flow can be routed in the same manner. For control flow the incoming and outgoing flows would be dashed.
-
7/30/2019 BPDM Response Revised Submission 04-08-03
40/215
40 Business Process Definition Metamodel
run concurrently, unless they compete for a shared resource that enforces serialization.) Loops can also be constructed explicitly by
"routing back" control or object flow after a decision.12 Note that it needs to be mergedinto the flow where it rejoins (e.g., enter a task
that is being re-executed via a different entry point) in order to avoid a dead-lock situation.
REPOSI TORI ES
In Figure 3Figure 3, a repository for orders is shown at different places in the diagram (note that the cylinder symbols represent"proxies" or "access points" to a single repository). Orders are stored by the receive order from customer task, and retrieved at later
stages in the flow. The {copy} annotation indicates that the order's content is read, but it remains in the repository for access byfurther tasks (a copy is made and passed out). The {remove} annotation indicates the order's removal from the repository. Task
inputs connected to a repository access it ("pull tokens") when all other inputs in the same input set have received the tokens they
require. The create order confirmationtask in Figure 3Figure 3, for example, will read the order content from the repository wheneither of its two input sets receives a control token (the object input is shared). 13
Repositories are defined for objects of a given type and have a given capacity, which may be unlimited (the default capacity is 1).Tasks deposit tokens by routing them from an output to the repository, and retrieve them by connecting the repository to one of their
inputs.
Deposit operations can either replace the previous content of the repository or add to it. Retrieve operations can either copy or remove
the repository's content. The type of task inputs or outputs connected to a repository must match the type of objects stored in it, andtheir multiplicity range determines how many tokens are stored or retrieved at a time (task inputs retrieve at least their minimummultiplicity, and then take as many tokens as available, up to their maximum multiplicity).
Repositories whose capacity is larger than 1 always keep their tokens in an ordered collection; tokens can be added and removed at its
beginning or its end, which allows to model stack or queue behavior. More selective retrieval algorithms (queries) can be modeled by
adding a boolean constraint to the retrieving input set; it may involve the content of other task input that is present when tokenretrieval is triggered.
12 Note that we do not restrict task interconnection in a process in any way, permitting arbitrary flow graphs. Tokens will move along
the object and control flows that the model defines, tasks will be instantiated whenever one of their input sets has received its required
set of tokens. It is the modeller's responsibility to ensure that this results in the intended behavior.
13 Replicating the object input in two (disjoint) input sets instead of sharing it would have had the same effect, but would have resultedin additional diagram clutter as well as the need to merge the object flows emerging from these two inputs if one ever wanted to
model the internal behavior of the create order confirmationtask.
-
7/30/2019 BPDM Response Revised Submission 04-08-03
41/215
Business Process Definition Metamodel 41
Repositories shown within a process (like the one for orders in Figure 3Figure 3) represent temporary storage whose life time is a
single process execution. They are also called process variables. Repositories can also be defined outside of any process context and
then represent permanent datastores, which different process executions can use to share and asynchronously exchange items.
Clearly, if several concurrent tasks try to remove tokens from a repository they may enter in competition and race conditions mayresult.
PROCESS LI FE- CYCLE AN D I NTER- PROCESS COMMUNICATI ON
An execution of a process is started when a "receive" task that has no incoming flow is targeted by inbound communication, and the
incoming request is not correlated with an existing process execution. A shorthand for a receive that can occur at the start of a processis to have object flow from a message (on the boundary of the process) to the next task(s). This approach is used in the Just-in-Time-
Manufacturing example for the initial receive of an Order object through the Customer Interface.
Correlation is discussed in section 0 "Addressing Process Executions (Correlation)".
A process execution is terminated either explicitly on reaching an End node (bullseye) or sending a terminating message (a send via a
message marked as terminating), or implicitly after all token flow and executions of nested tasks have ended. Note that this isanalogous to the termination of a block, explained in section 0 "Block Termination" above. Just like initial receive tasks, terminating
tasks must not be nested within blocks.
The receive order from customertask in Figure 1Figure 1 and Figure 3Figure 3 is an example of an initial receive task. The Just- in-
Time Manufacturingprocess does not contain a terminating task, but ends implicitly after execution of all subordinate tasks has
finished.
The next section describes how requests are routed to a process component, which acts like a "factory" and request broker for its
executions.
PARTNER SELECTION ( ROUTI NG)
[Omitted in this version. Requires updating.]
ADDRESSI NG PROCESS EXECUTI ONS ( CORRELATI ON)
Implicit correlation is the direction of a "response" to a receive task within the process execution that sent the original request. Explicitcorrelation is the routing of an unsolicited request to one or more ongoing executions of a process.
We discuss implicit correlation first. With the component interaction model introduced in chapter 0 "Process Components", whereprocesses exchange unidirectional signals whose sequencing is governed by a collaborative process (protocol), request-response
-
7/30/2019 BPDM Response Revised Submission 04-08-03
42/215
42 Business Process Definition Metamodel
correlation must be generalized: The first exchange between two process executions that establishes a collaboration (it must be an
initial request according to the collaboration's protocol) implicitly "binds" two executions threads to the collaboration instance. They
may be represented by executions of the process proper or nested sub-processes. Further execution threads, of potentially other
partners, may join as the collaboration proceeds. All messages issued by these executions in accordance with the collaborationprotocol will be routed to the "partner" executions bound in this way, until the collaborative process has ended. 14 15 Clearly, aninstance of an operational process may participate in several collaborations at the same time.16
To explain explicit correlation, we revisit the Just- in-Time Manufacturingprocess. Note that multiple open auctions may be running
concurrently on behalf of a single manufacturing process. They represent ongoing negotiations for different parts, which bidders must
be able to address individually.
Therefore, the actual auction should be modeled as an independent process that is controlledby the manufacturing process on whose
behalf it was launched. This is shown in Figure 5Figure 5, where we assume that the manufacturing process plays the requester role (arefinement ofrun auctionwould show the pertinent communication tasks).
In the Procurement Auction operational process, in the lower half of Figure 5Figure 5, only the communication tasks are shown. Thethree receiver tasks have the following correlation predicates:
?? The receive part requisit ion from requestertask has no correlation predicate and is the receiver of the initial requestin the Auction Control collaboration protocol. Input received here will spawn a new Pocurement Auction execution.
14 Design issue: In order to enable protocol tracking, a send task needs to specify more information than the partner and type of signal
exchanged ("send X to Y") because the same signal may be permitted in different branches of a collaborative process, and without
additional information it will be impossible to tell which branch was takenwhich undermines protocol tracking.
15 We may be able to avoid "reply tokens" by agreeing that all communication task instances that are spawned by these executionthreads and map to an abstract process of an ongoing collaboration (that is, all potential past and future senders / receivers
participating in the conversation) remain bound to the message exchange prescribed the collaboration protocol, and blocked for any
other communication, until the collaboration instance is finished.
16 Work is needed to precisely define the mapping of "execution threads" in interacting operational processes to a collaboration
instance; ultimately, we must ensure that the question "which instanceof a receive task will get a particular instanceof an inboundsignal" can always be answered. One can easily conceive process models where this is all but clear (e.g. by spawning several receive
tasks after sending).
-
7/30/2019 BPDM Response Revised Submission 04-08-03
43/215
Business Process Definition Metamodel 43
?? The receive bid from biddertask has a correlation predicate that matches the part number of an incoming bid with
the one of the requisition that initially spawned the auction. Incoming bids will thus be routed to the auction for that
part.
?? The receive termination signal from requester task matches an order number supplied as part of the terminationsignal with the order number of the requisition. The termination signal thus targets all auctions that are in progress
procuring parts for a particular order.
ProcurementAuction
receivepart requisitionfrom requester
receive
termination signalfrom requester
sendresult
to requester
receivebid
from bidder
PartRequisition
TerminationSignal
Result
Procurement Auction
(Bidder) Bidding
requisition
.....
(no correlation)
bid.partNo =requisition.partNumber
terminationSignal.orderNumber =requisition.orderNumber
:Bid
: Part Requisition
:Termination Signal
:Result
(Requester) Auction Control
Figure 5: Correlation example
In general, a correlation predicate may be associated with individual receive tasks (compare Figure 5Figure 5). Whenever such a task
becomes the target of an inbound request, the predicate is evaluated for all of its existing instantiations. If it evaluates to true for
-
7/30/2019 BPDM Response Revised Submission 04-08-03
44/215
44 Business Process Definition Metamodel
exactly one of them, then this task instance will get the inbound request. Otherwise, the user-defined settings for "no correlation
matches" and "multiple correlation matches" determine what happens, as specified in the following table:
At t r ibu t e Set t ing Ef fec t
create new
instance
a new process execution is
started and receives therequest (not for receivetasks defined within a
nested sub-process)
raise
exception
a "no correlation matches"
exception is raised
no c o r r e la t i on m a t c hes
(applies if there is no execution for which the correlation predicate evaluates totrue)
ignore the request is ignored
deliver to all the request is delivered to
all process executions forwhich the correlation
predicate is true
deliver to
any
the request is delivered to
one (arbitrarily chosen)process execution forwhich the correlation
predicate is true
raiseexception
a "multiple correlationmatches" exception israised
m u l t i p l e c o r r e l a t i o n m a t c h es
(applies if there is more than one execution for which the correlation predicate
evaluates to true)
ignore the request is ignored
In the example in Figure 5Figure 5, the no correlation matches setting is "ignore" for the task receiving the termination signals, and"raise exception" for the task receiving the bids. The reason is that termination signals can safely be ignored if no auction is found to
be terminated, while invalid bids should cause an exception notification back to the bidder. The multiple correlation matches settingsfor the two tasks are "deliver to all" and "raise exception", respectively.
EXCEPTI ONS AND COMPENSATION
EXCEPTI ONS
-
7/30/2019 BPDM Response Revised Submission 04-08-03
45/215
Business Process Definition Metamodel 45
A task can have one or more exception output sets. Completion via an exception output set indicates an undesired or "fault" outcome:
the task did not complete normally and has not successfully performed its work. The "some part unavailable" outcome of the procure
parts task in Figure 3Figure 3 is an example.
Declaring an output set an exception can be purely informational. When used in conjuncation with compensation, however, additionalsemantics apply, as discussed in the following section.
COMPENSATI ON
[Omitted from this version. Required updating.]
Model l ing Resources RESOURCES
The most straightforward description of a business task is a sentence: Jill approves the order. John delivers the package. etc. Thesesentences have subjects (Jill, John), verbs (approves, delivers), and objects (the order, the package). In business process definitions,we use tasks to describe the "verbs", items to describe the "objects", and resources to describe the "subjects" or actors. In addition,
actors sometimes need collaborators or tools to accomplish a task, which are also modelled as resources.
We differentiate between individual resources, which are discernible and have an identity, and bulk resources, which are provided andused in some quantity. A human worker or employee is a special kind of individual resource, other kinds would be a truck, asledgehammer, a slide projector, a conference room, or a computer system. Examples for bulk resources would be fuel, floor space,
budget, cement, or memory.
Resources, both individual and bulk, are typed (have user-definable attributes) but have three fundamental properties in common:
?? qualificationsthe set of roles they can fulfill
?? availabilitythe set of time slots during which they can be deployed
?? costthe cost of using them, which may depend on usage time and quantity (for bulk resources)
In business process models we allow modelling resource types (e.g., Employee) as well as instances (e.g., John Doe).
ROLES
A role describes a functional capability, which tasks require and resources provide. A rescue task, for example, may require someonein the role of a pilot, something in the role of an "aircraft", and someone in the role of a physician; different people or items may be
qualified to fulfill these roles.
-
7/30/2019 BPDM Response Revised Submission 04-08-03
46/215
46 Business Process Definition Metamodel
Oftentimes roles are further qualified by properties of the task at hand: a pilot may have to be licensed for a specific type of airplane,
an expense approver role be further qualified by the amount to be approved and the type of expense request. We use the notion of
"role scope" to describe such instance-dependent restrictions or "down-scoping" of a fundamental qualification which a role represents.
Tasks requiring a role may define a required scope (pilot to fly a B-59 airplane; approver for a $21,000 group travel request, etc.), andresources declare the scope for roles they can play (airplanes they are trained to fly; expense requests they are authorized to approve,etc.).
Roles are different from resource types, although the two are often used interchangeably in everyday language: a "team leader" role
may be fulfilled by a corporate employee, a contractor, or a summer student. Each of these resources may be qualified for the role,
but they have different resource types (some have employee serial numbers, other don't ...)
RESOURCE REQUI REMENTS
Tasks have three ways to specify their resource requirements:
?? require a specific resourceexamples: Dr. William H Smith; the manager of the request submitter
?? require a resource of a specific type, potentially subject to constraints
examples: an employee of dept D27X; a conference room that can seat 20
?? require a role to be fulfilled, potentially specify scope valuesexamples: a pilot for a B-59 airplane; an approver for a $21k travel expense
Furthermore, resource requirement specifications sometimes need to refer to resources used in a preceding task ("... the same userthat performed this preceding step"). This is accomplished by modelling special-purpose task outputs, which emit object tokens
representing the resources employed after task execution has finished. Subsequent tasks may use the information carried by thesetokens to formulate their resource requirements in terms of the resources used by their predecessors.
FM Cred i t Exam ple
Quick Reference
-
7/30/2019 BPDM Response Revised Submission 04-08-03
47/215
Business Process Definition Metamodel 47
-
7/30/2019 BPDM Response Revised Submission 04-08-03
48/215
48 Business Process Definition Metamodel
Concep tu a l Me tam ode l Overv iew
This section will be updated after discussions at the August 2004 (Montreal) OMG meeting.
This submission has identified a core set of concepts shared among a number of tools and methodologies PIM level and that represent
what we believe to be an agreeable set of terms among the identified audience. We have taken this set of concepts and mapped themto UML 2.0 and developed a profile for UML 2.0 that can be used to model business process definitions well. This profile does identify arequired subset of the UML 2.0 metamodel, but does not explicitly remove anything from the metamodel, thus leaving the full
expressiveness of the UML open to users, tool developers and methodologists. We have also not added new metamodel level elements
and so the end user does not have to learn a new UML and tool vendors should be able to implement the profile without major re-
engineering efforts.
The following is a conceptual model of the concerns addressed by this specification. It acts as an overview and a framework which the
detailed specification completes.
Worker Organization
PartyProcess0..*+subProcesses0..*
Role0..*0..*
+performedBy
0..*0..*Task
0..*0..* 0..10..*
+performedBy
0..10..*
Entity
+producesOrConsumes
Event
+generatesOrReceives
0..1+identifies
0..1Constrainable Rule
0..* 0..*0..* 0..*
CompensationTransaction
0..1+compensatingTask
0..1
Automated
The concepts themselves are relatively simple; we start with a process itself, it is a container for state and behavior and has anexternally visible interface, a set of operations and receptions that it responds to. Once these behaviors are invoked the process may
contain sub-processes (for partitioning model behavior and reusing process classes) and tasks. Tasks may invoke behavior on othertasks and sub-processes in the processes or invoke behavior or send events that are received by processes outside the scope of their
own parent process. Tasks may also identify themselves as having transactional semantics, i.e. an atomic completion of all enclosed
behavior; to support this we also provide compensation activities that can explicitly model the behavior required to undo a completedtransaction in the event of failure in some other part of the process.
In our view the notion of a role is a functional need of a task to be fulfilled by a resource. An organization can be responsible for the
completion of a task by providing a resource owned by the organization to fulfilling the resource need of the task. Obviously tasks are
carried out by people or automated systems. Frequently, these are grouped within organizational structures, such as companies,
-
7/30/2019 BPDM Response Revised Submission 04-08-03
49/215
Business Process Definition Metamodel 49
departments, or project teams. To model this we have a Resource model capturing the human and non-human resources in a
business, their qualifications (expressed as the roles they can fulfill), their availability (for example, working hours), and cost
structure. An Organization model serves to group resources, reflecting their employment or ownership. Resource requirements of
process activities are often modeled as roles for which an activity requires resources in order to execute. Alternatively, resourcerequirements may be modeled directly (requesting a specific resource instance) or by specifying a resource type (any instance of thistype will do). Partitions may be used to declare resource requirements, or organizations providing the necessary resources (human
and/or non-). Therefore, when a partition represents a role, this means that this role must be played by some resource in order for
each task in the partition to execute; when it represents a resource (instance), or a resource type, this means that a specific resource,
or any resource of the given type is required; when it represents an organization, this means that this organization is responsible forthe tasks within the partition.
Note, we expect responses to recent RFPs for a complete organization model to supersede this subset of our model.
The UML also provides for the modeling of data flows within processes by using ObjectFlows within and between the activities, we
simply require that these object flows are movements of business entities or business objects, rather than arbitrary data. The UML alsoallows us to model the sending and receiving of events, thus allowing us to decouple processes from each other and also to respond tointernal events in an easy to understand manner.
Finally, many business systems employ business rules technologies to allow them to deploy systems that can be responsive byparameterizing business logic so that changes in environment or policy do not require application or process rewrites but can be
accomplished through the changing of rules. We provide a description of the places where such rules can be expected, existing RFPsare addressing the need to model business rule