Business Process Definition MetaModel (BPDM)

Transcription

1 OMG Document bmi/ Business Process Definition MetaModel (BPDM) (Revised submission) September 4, 2006 In Response to: Business Process Definition Metamodel RFP (OMG Document bei/ ) Submitted by Adaptive Axway Software Borland Software Data Access EDS Lombardi Software MEGA International Unisys

2 Supported by: U.S. National Institute of Standards and Technology (NIST)

3 Copyright 2006 Adaptive Axway Software Borland Data Access EDS Lombardi Software MEGA International Unisys Each of the entities listed above: (i) grants to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version, and (ii) grants to each member of the OMG a nonexclusive, royalty-free, paid up, worldwide license to make up to fifty (50) copies of this document for internal review purposes only and not for distribution, and (iii) 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 any OMG specification that may be based hereon or having conformed any computer software to such specification. NOTICE: The information contained in this document is subject to change without notice. The material in this document details a submission to the Object Management Group for evaluation in accordance with the license and notices set forth on this page. This document does not represent a commitment to implement any portion of this specification by the submitter. WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE, THE OBJECT MANAGEMENT GROUP AND THE COMPANIES LISTED ABOVE MAKE NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL INCLUDING, BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. The Object Management Group and the companies listed above shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance or use of this material. OMG and UML are registered trademarks of the Object Management Group, Inc.

4 Table of Contents OMG Document bmi/ Submitted by... Table of Contents... 4 Introduction Submitting Companies Supporting Organizations....3 Submission Contacts Status of the Document Guide to the Submission Design Rationale Proof of Concept Change History Responses to RFP Requirements Mandatory Requirements Optional Requirements Issues to be Discussed Overview Process Service Protocol Relation of Process and Service Protocol Course and Composition Specification Overview Composition Model Composition Selection Composite Generalization... 43

5 5.2.5 Individual Part Part conformance Part Connection Part Connection as Part Part Group Selection List Selector Typed Part Course Model Course Model Conditions And Join And Split Compound Condition Condition Conditionnable Element Conjunction Course Disjunction Final Step Initial Step Opaque Condtion Or Join Step Succession Succession Condition switch Xor Split Service Model... 56

6 5.4. Core Emerging Service Protocol Processing Behavior Service Boundary Service Delivery Service Interaction Service Interaction Flow Service Interaction Message (BPMN) Service Interactive Part Service Interactive Part Binding Service Protocol Service Role Typed Behavioral Part Notation samples Activity Model Core ActionNodes Performer Role Transaction & Publish/Subscribe Listeners Activity Actor Artifact Control Flow Artifact Flow Artifact Interactive Part Cancel Clock Condition Evaluation Listener Condition Happening Control Flow Cycle Happening... 73

7 5.5.7 Duration Happening Embeddded Process Execution Exception Holder Listener PerformerRole Process Process Termination Processing Listener Processor Role Publisher Role Realization Simple Activity Sub-Process Activity Terminate Time Happening Time Listener TimeDate Happening Transaction Notation samples Class Hierarchies Process Hierarchy Flow Hierarchy Happening Hierarchy Interactive Part Hierarchy Step Hierarchy BPMN to BPDM Mapping Abstract Mapping Table UML Profile... 95

8 8 Proof of Concept Language Mappings BPEL mapping WS-CDL mapping Compliance Levels BPDM Full Compliance BPDM Collaboration Protocol Compliance BPDM Orchestration Process Compliance Appendix A: Glossary... 0

9 Introduction This section presents information regarding the RFP response. Submitting organizations Supporting organizations Submission contacts Status of this document Guide to the submission Design rationale Proof of concept Change history

10 . Submitting Companies The following companies are formal submitting members of OMG: Adaptive Axway Software Borland Software Data Access EDS Lombardi Software MEGA International Unisys

11 .2 Supporting Organizations The following organizations have contributed to the development of this specification but are not formal submitters: NIST (National Institute of Standards and Technology), US Government

12 .3 Submission Contacts Pete Rivett Adaptive Bernard Debauche Axway Software Karl Frank Borland Software Fred Cummins EDS Cory Casanave Data Access Petko Chobantonov Lombardi Software Antoine Lonjon MEGA International Vitaly Khusidman Unisys Ed Barkmeyer NIST edbark@nist.gov

13 .4 Status of the Document This document is a draft specification for review and comment by OMG members. Submitters will be seeking a revised submission date to complete further work on this specification.

14 .5 Guide to the Submission The submission is organized into the following sections: Those sections are normative that are indicated as such, below. Section, Introduction information related to the RFP response. Section 2, Responses to specific RFP requirements Section 3, Overview provides a general understanding of the specification (normative) Section 4, Metamodel specification details of the metamodel specification (normative) Section 5, BPMN mapping (normative) Section 6, UML profile (normative) Section 7, Proof of concept mappings describes mappings of the metamodel to example languages Section 8, Compliance points (normative) Appendix Glossary of terms

15 2 Design Rationale The primary objective of BPDM (Business Process Definition Metamodel) is to provide business analysts with a technology-independent representation of business processes that can be exchanged between vendor products. BPEL has been used to some extent to accomplish such exchanges, but BPEL has been extended by individual product vendors to provide a full representation of business processes, and thus it no longer qualifies as a standard for exchange Historically, business process models are specific to vendor products and business processes have been automated within individual departments of an enterprise. Today, business processes must be integrated across the enterprise and its partners. It is unlikely that a single vendor product will be used to implement executable business processes across a large enterprise or industry. BPDM is a robust representation of business process modeling concepts. As a MOF-based metamodel, it is accompanied by an XMI standard format for model exchange. BPDM is consistent with the MDA (Model Driven Architecture) approach in providing a representation that separates implementation choices to other stages of system design. BPDM process models can be implemented by people exchanging paper documents, or may be automated or a combination of both. It provides a base from which more implementation-specific information make be added, for example, with stereotypes for manual and automated processes. BPDM can be used as a metamodel for the Business Process Modeling Notation (BPMN), a popular standard graphical representation of business processes. Support for BPMN ensures that BPDM represents business process modeling concepts that are widely accepted. As a metamodel for BPMN, it provides a standard for exchange of BPMN models using XMI, and a standard interpretation of the diagrams. This satisfies a significant user demand for tool interchange and interoperability. BPMN, however, does not provide a complete representation of business process models, particularly with the emergence of automation of e-commerce and service-oriented architecture (SOA). Traditional process models represent processes within a closed environment, usually a department within an enterprise, often called orchestration. With the advent of e-commerce and SOA, automated processes are expected to interact across organizational and enterprise boundaries. Processes in different organizations are expected to interact in defined ways, often called choreography, to achieve mutually beneficial results. While an abstract view of a business process that involves multiple participants may be represented much the same as an internal business process, specification of choreography, an agreed-upon pattern of exchange of messages between participants, requires a somewhat different representation. BPDM includes a representation of choreography, and the linkage to validate that the internal processes of a participant are in compliance with choreography. The interactions between independent processes may become extensive and complex. Particularly in e- commerce exchanges, there may be multiple participants involved in different aspects of a complex transaction. BPDM provides for the reuse of choreography specifications so that a large complex choreography can be composed from more specific, validated choreographies that define more limited transactions. BPDM is effectively a new modeling language. It is designed to represent concepts of concern to business analysts. As such, it differs somewhat from the process representations of languages designed for other communities or specification of processes to be executed on particular technology platforms. At the same time, an effort has been made to conceptually align with existing OMG specifications (specifically UML and EDOC). BPDM is not simply an extension or profile of UML or EDOC, because it is targeted to a different community of users, and it is important that the model elements only incorporate concepts and relationships that are relevant to business process modeling. To include extraneous aspects would increase the difficulty of implementation of the language by business process tool vendors, and hinder the continuing evolution of modeling in this domain. Nevertheless, certain UML Infrastructure packages have been incorporated directly, to avoid duplication.

16 2. Proof of Concept These specifications are based on understanding of the metamodels of existing business process modeling solutions and business process execution languages such as BPEL (Business Process Execution Language). Collaboration Languages such as WS-CDL and ebbp have also been taken under consideration. The metamodel specifically supports the BPMN graphical notation.

17 2.2 Change History August 2003 January 2004 Initial submission Revised submission March 2005 Revised submission 2 Clarification of the business modeling context Alignment with UML 2.0 information flow model Clarification of the role based approach for process interaction. Clarification of the business modeling context Remove UML 2.0 alignment Flow Model Process Model November 2005 Revised submission 3 May 2006 Initial Submission 2 : Introduction of the composition model Introduction of the Process Behavior model Introduction of the Community Process model Introduction of the course model Introduction of the happening model September 2006 Revised Submission 2. New Overview section Finalized Service Model Finalized Activity Model

18 3 Responses to RFP Requirements The following tables provide a cross-reference between the requirements as stated in the Request for Proposals and the corresponding responses provided by this submission.

19 3. Mandatory Requirements Requirement 6.5.: Required Metamodel Responses to this RFP shall provide a metamodel forming an abstract language for the expression of business process definitions. Resolution The specification is a MOF metamodel expressed in UML. It defines a technology-independent representation of business processes for use by business analysts to define robust business process definitions from a business perspective. Proposals shall depict the solicited metamodel using UML : Metamodel Compatibility Proposals shall use the appropriate elements of existing metamodels including, UML, EDOC, MOF and OCL : MOF Compliance The UML Infrastructure Basic package and Expressions package have been incorporated in the specification. Implementers may use OCL as the constraint language notation. The specification does not make further use of existing metamodels in order to avoid unnecessary complexity that would be a barrier to market acceptance. The specification is fully MOF-compliant. The resulting metamodel shall be MOF-compliant : Procedural and Rule-Based Flow of Control Proposals shall provide for specification of process flow based on control flow from completed activities to activities to be initiated as well as initiation of activities based on rules or preconditions : Specification of Activity Performers Proposals shall provide for the specification of selection criteria for performers and resources, including human performers, applications, passive resources and sub-processes. The basis for selection shall include Specific resource identity Resource attributes Succession constraints allow for expression of control flow; however, rule-based process execution involves a different paradigm that may not be well suited to this metamodel. Rule-based process modeling should be considered for a future RFP. The specification includes the representation of roles with constraints on the selection of participants for those roles. Further definition of resource selection criteria is left for the specification of resource management facilities that would assign appropriate resources on request at runtime. Implementations of BPDM should consider incorporating resource management facilities to support modeling activities in order to ensure consistency of the constraint criteria with resource attributes. Relationships with other assigned resources Relationships to subject matter Combinations of the above : Asynchronous and Concurrent Execution Most of these requirements are addressed in the current specification. These requirements are

20 Proposals shall provide mechanisms for specifying concurrent execution of activities: expected to all be addressed with final reconciliation with the BPMN notation semantics. A process model shall be able to define when multiple, concurrent activities are initiated. A process model shall be able to define when an activity or completion of a process depends on the completion of multiple, concurrent activities. This shall include initiation of an activity based on completion of n of m concurrent activities (where n <= m). Business processes shall be able to invoke processes that execute asynchronously. The model shall support specification of the publication of events and messages for asynchronous delivery. The model shall support receipt of messages from a collaborator and subscription to events. Messages and events shall be received as asynchronous inputs to a receiving activity executing concurrently with other activities in the process : Specification of Initiation and Termination Proposals shall provide modeling constructs for specifying when and how activities and processes can be initiated and terminated: Pre or post conditions In general, these requirements are addressed at a business modeling level consistent with the semantics of BPMN, so the intent is captured in the model, not the mechanism of implementation. Pre and post conditions are not explicitly addressed. Actions for initialization and termination with consideration of actions required for abnormal termination, including the initiation of compensating processes. Propagation of termination to active activities and sub-processes : Choreography Proposals shall provide for the specification of the signals and exchanges performed between processes to achieve collaboration as described in : Audit Log Generation The concept of choreography is represented by protocols. [To be defined] Proposals shall include provisions in the metamodel to allow the specification of business logic related audit log records. This part of the metamodel shall provide for the specification of: The content of the log record in relation to the

21 process definition The timing of the log record emission 6.5.0: Distributed Execution Proposals shall ensure that the form of definition does not preclude distributed execution. 6.5.: Process Definition Import and Export The approach does not preclude distributed computing implementations, and allows for representation of different degrees of coupling where this is a business concern. An XMI specification is included. Proposals shall support XMI export and import for exchange of process definitions : Non-Normative Notation Mappings As a proof of concept, proposals shall provide nonnormative mappings to two recognized business process modeling languages, e.g.: [a mapping to BPMN is included, a mapping to BPEL is intended.] BPEL4WS XPDL : Compatible Versions of Existing Specifications The specification is compliant with UML 2.0 and MOF 2.0. The final, revised submission shall be based on the most recently adopted version of related specifications (e.g., UML and MOF) that is adopted three months prior to the final revised submission deadline for this RFP.

22 3.2 Optional Requirements Requirement 6.6.: Additional Non-Normative Mappings Resolution [potential mapping to a UML profile] Proposals may provide additional mappings to recognized languages for business process definition, complementing the list of mandatory mappings requested in : Additional Execution Constraints [not currently addressed] 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 affect on the process enactment described.

23 3.3 Issues to be Discussed Issue to be discussed 6.7.: Relationship to Existing UML Metamodel Proposals shall discuss the relationship of model elements used for business process modeling to the existing UML metamodel to demonstrate consistency with the UML metamodel : Relationship to Existing UML Profiles, Metamodels and Notations Proposals shall discuss how business process definitions may be incorporated with or complement other UML profiles, metamodels and notations for specification of business systems, particularly the UML Profile for EDOC : Mapping to Existing Business Process Notations and UML Notation Proposals shall discuss how the proposed metamodel may be mapped to existing process definition notations as a demonstration of completeness and compatibility : Resource Model Proposals shall describe assumptions regarding an associated resource model : Relationships with Related OMG Specification Activities Proposals shall discuss how the specifications relate to the specification development efforts currently under way as noted in Section Resolution The metamodel incorporates the UML Infrastructure Basic package and Expressions package. More extensive re-use of UML would make the BPDM metamodel more complex creating a barrier to acceptance by vendors focused on business process modeling. Submitters have strived to avoid gratuitous inconsistencies with the conceptual representation of processes in UML. Concepts represented in UML activity diagrams and EDOC have been incorporated into the BPDM metamodel. A complete mapping to BPMN is included and BPMN is intended to be the primary graphical representation for BPDM models. Roles are expected to include constraint expressions for selection of appropriate participants. UML 2.0 was used as the basis for BPDM packages and concepts OCL notation may be used for BPDM constraint expressions. BPRI is still under development but is intended to complement BPDM. Requirements identified by BPRI submitters are being considered in the BPDM specification. MOF Versioning does not have any direct impact on BPDM. MOF QVT is expected to be the appropriate language for specification of BPDM transformation SBVR provides for the definition of business rules that will be relevant to business processes. Integration of business rules into business processes will likely be the subject of a future RFP. OSM is still under development but is intended to

24 complement BPDM for selection of human participants as in approval activities. SYSML includes process representation from UML and addresses a different community of users. A transformation to SYSML process representation may be appropriate for a subsequent RFP. SPEM addresses a different community of users and concerns : Consistency Checks Proposals shall discuss how the specification supports consistency checks, particularly between choreography specifications and a business process that participates in the choreography : Access Control Proposals shall discuss how access authorization for process data, artifacts, activities in a process, and process enactment may be based on process roles of individuals associated with a specific process instance : Web Services and Collaboration Support Proposals shall discuss how the specification supports the definition of business processes and choreography for web services and other collaborations including the relationships with messages, documents, interface specifications, participant roles, signatures and message exchanges. BPDM provides for the binding of a choreography specification to an internal process specification. This binding supports the ability of a tool to analyze the consistency of the sequence of exchanges defined by the choreography with the messages sent and received by the participant s internal process. Access authorization is outside the scope of this specification. The security system should address authorization of individuals to perform specific process roles. The specification provides for full representation and integration of processes and protocols (choreographies) at a business level of abstraction. Specification of message and document formats is by reference. A BPDM model, along with referenced message and document specifications, is sufficient to generate web services interface specifications (WSDL).

25 4 Overview This section is an overview of the BPD metamodel. One of its primary purposes is the unification of orchestration and choreography. Most other models and file formats for these are defined separately, sometimes at different standards bodies, and consequently lack the cohesion necessary to smoothly transition from one to the other. This transition is critical to support for the shifting boundaries between organizations, as departments and divisions move across companies, and companies focus on their core competencies. BPDM facilitates this by identifying the common elements of orchestration and choreography to facilitate moving between them. BPDM uses the terms process and service protocol instead of orchestration and choreography, because the common terms have many meanings and connotations not necessary for business analysts. For example, orchestration often suggests centrally-controlled workflow implementations, even though the diagrams depicting it could also be implemented in a decentralized fashion. Similarly, choreography usually suggests a decentralized SOA-style implementation, even though diagrams and models used for choreography could also be implemented under centralized coordination. BPDM does not commit to a particular implementation or coordination architecture, because business analysts are not usually concerned with that. The section begins with the concrete model elements, introducing the abstractions common between them as needed. This has the benefit of starting with more familiar concepts, but the disadvantage of hiding the motivation for the unifying abstractions. In particular, this section begins with Process ( orchestration ) then addresses Service Protocol ( choreography ), so the abstractions introduced and specialized in Process only see their full purpose when reaching the specializations in Service Protocol. Section 4.4 describes the abstractions introduced in the rest of the section. Instances of the BPD metamodel (user models) are specifications of what the modeler would like to happen in the processes and protocols as they actually occur. Occurrences of a process or protocol specification happen between particular points in time, and are supposed to conform to their specification. Specifications themselves do not occur in time (though the development of them does). The relation of a process or protocol specification to its desired occurrences is the semantics of BPDM; however, BPDM does not specify how it is ensured that the occurrences of a process or protocol obey their specification. The notation used in this section is an informal, non normative adaptation of BPMN just for explaining BPDM. It is not for tool support and sometimes conflicts with BPMN. In cases where the semantic implied by the notation conflicts with the semantics of BPMN, the semantics of BPDM should be assumed.

26 4. Process Figure 4. shows the Process ( orchestration ) element, a specialization of Processing Behavior (the BPDM abstraction of orchestration and choreography ). It also shows the informal, non normative notation used for explanation in this specification. A process definition includes an element representing the environment of the process, Processing Behavior Service Boundary, for defining the interaction of the process with its environment. This is a special kind of Service Role owned by processing behaviors in general and inherited to processes in particular (it is also used in service protocols, see Figure 4.7). It is used in the process definition to represent anything outside the process that will provide artifacts to the process and accept them from it. Figure 4. also shows elements for representing the interaction of the process and its environment. The process itself is another distinguished role in the process, Processor Role (a self role). The interactions between the process and the environment are represented by Service Interaction Flow. It relates exactly two instances of Service Interactive Part, an abstraction for interacting parts of processing behaviors. Figure 4. shows two interactions, one incoming from the environment and one outgoing. Processing Behavior Service Interaction Flow sent interaction flow se rv ic e interaction flo w producer Service Interactive Part receive d interaction flow service interaction flow consumer Service Role owner processing behavior owned service role Processor Role 0.. processor role as process fulfilled service role Processing Behavior Service Boundary 0.. process as 0.. processor role Process Service Interaction Flow A Process The outside: Service Boundary Processor Role The process Figure 4.: Process and Service Interaction Flow

27 Figure 4.2 adds elements for representing the type of thing being provided or accepted by the interaction of a process and its environment. The type is inherited to Service Interaction Flow from its abstract super classes (Interactive Flow is an abstraction that has other specializations in processes for artifact flow, see Figure 4.4). The actual thing flowing will informally be called an artifact in this specification, which is required to be of the type of the service interaction flow. The notation is amended to indicate that the interaction involves an artifact (the document symbol inside the circle) which might be sent by a message (indicated by the circle surrounding the document), or by other means for making the artifact available to the environment or accepting an artifact from the environment. Figure 4.2 also adds elements for representing the order in which interactions are to occur. Service Interaction Flow is a kind of Process Step, an abstraction which enables its specializations to be constrained to occur before or after others, as represented by Succession. In Figure 4.2, the incoming interaction must be complete for the outgoing interaction to start. It is assumed the interaction occurs over time, like a sub process, which enables them to be ordered by Succession. TypedElement typedelement type 0.. Typ e Interactive Flow Processing Behavior Serv ice Interaction Flow sent interaction flow service interaction flow producer Service Interactive Part Service Interaction received interaction flow service interaction flow consumer Serv ice Role owner processing behavior owned service role Processor Role 0.. processor role as process Process Step previous next step Succession step fulfilled service role Processing Behavior Service Boundary 0.. process as 0.. processor role Pro cess Succession A Process Interactive Flow Type Succession Figure 4.2: Interaction Flow Type and Succession

28 Figure 4.3 shows how processes use other processes (flow lines not shown). It defines a process that uses the one defined in the previous figures. In this example, Activity 2 is Sub process Activity which means the process could potentially be reused in many other processes. Other activities might not identify a separate process to use (Simple Activity), or might identify one that is used only in a single other process, not shared among multiple processes (Embedded Activity). Another Process Activity Activity 2 Activity 3 Activity 5 Activity 4 A Process Process 0.. owner process Artifact Interactive Part Interactive Part Process Step Activity Simple Activity Sub-Process Activity Embeddded Activity processusage activitytype Processing Behavior Figure 4.3: Activity & Sub Process

29 Figure 4.4 adds elements to represent the order in which activities occur, Control Flow, a specialization of Succession (Succession applies to Activity as a specialization of Process Step). It also adds elements to represent artifacts provided and accepted between activities, Artifact Flow, which inherits the type of artifact from Interactive Flow (an abstraction shared with the interactions of a process with its environment, see Figure 4.2). Control Flow is specialized to Artifact Control Flow, for representing artifacts provided and accepted between activities that occur after one another. Another Process Activity Activity 2 Activity 3 Activity 5 Activity 4 Interactive Part Process owned artifact 0.. interactive part owner process Artifact Interactive Part Process Step artifact flow consumer artifact flow producer Activity triggering activity triggered activity received artifact flow Artifact Flow artifact flow receiver triggered control flow Control Flow triggering control flow Artifact Control Flow Succession Figure 4.4: Artifact Flow

30 Figure 4.5 shows how service interaction flows in a process definition bind to the artifact flows in a process that uses it. Interaction Flow Binding applies to the abstract Interaction Flow, which is specialized to Artifact Flow and Service Interaction Flow (see Figure 4.2). This enables the binding to apply between artifact flows and the interactions of a process with its environment. In Figure 4.5, the interactions of the process in Figure 4.2 are bound to the artifact flows around Activity 2. Another Process Activity Activity 2 Activity 3 Activity 5 Activity 4 Process Interactive Flow Binding A Process internal flow connection 0.. external flow connection source flow target flow Interactive Flow consumer received flow Interactiv e Part producer sent flow Artifact Flow Service Interaction Flow Artifact Control Flow Figure 4.5: Interactive Flow Binding

31 Figure 4.6 shows how a process sends and receives notifications without specifying the specific sender or receiver, commonly called events. Publisher and Listener appear in processes capable of participating in artifact flows. There are many kinds of publishers and listeners; in particular, listeners can receive notifications of the beginning and ending of occurrences of other processes and protocols, of time conditions, and more general kinds of conditions. Figure 4.6 publishes a notice of wind danger by evaluating conditions as it listens for wind speed changes. One kind of producer of notifications is the cancelling of transactions, which group activities in a process and detects occurrences of the simple activity for cancelling transactions. Weather Service Figure 4.6: Publisher and Listener

32 4.2 Service Protocol Figure 4.7 shows a Service Protocol ( choreography ), a specialization of Process Behavior. It uses many of elements and informal, non normative notation introduced in Section Process (Service Protocol is a sibling of Process, see Section Process). The service roles Search Requester and Catalog Provider in this example will be filled by entities when they interact according to the Sales Service Protocol (Service Role is a generalization of Processing Behavior Service Boundary, see Figure 4.). Service roles are related by service interaction flows to show the parts of the protocol, and service interaction flows can be related by successions to show the order in which interactions occur. In this example, Search Requester provides an artifact representing a request for a catalog to Catalog Provider, who replies with the catalog. Catalog Service Protocol Catalog Request Service Protocol Service Interaction Flow Service Role Search Requester Catalog Provider Succession Catalog Succession Succession previous step Process Step next step TypedElement 0.. Type Processing Behavior Service Interaction Interactive Flo w owner processing behavior Serv ice Interaction Flow received interaction flow Service Interactive Part service interaction flow consumer sent interaction flow service interaction flow producer owned service role Service Role Service Protoco l Figure 4.7: Service Protocol

33 Figure 4.8 shows how protocols use other protocols. The protocol in Figure.7 is reused in a larger Catalog Sales Service Protocol, in the top service interaction in Figure.8. The reuse of a protocol is a Service Delivery, which is an service interaction that breaks down into the service roles and service interactions in the reused protocol (Service Delivery is a specialization of Servive Interaction. It is also a sibling of Interaction Flow, which does not use a another protocol, see Figure.7). A service delivery identifies the service protocol being reused. In Figure.8, the top service delivery reuses the Catalog Service Protocol, to order a catalog, and the bottom service delivery resuses Catalog Order Service Protocol, for placing an order from the catalog. The service roles in reused protocols are bound to the roles of the larger protocol by Service Interactive Part Binding. Service deliveries are also process steps, which enables the larger protocol to give the order in which the subprotocols should occur, using Succession (also see Figure.2 and Figure.4). Catalog Service Protocol Catalog Request Catalog Requester Catalog Provider Proc essing Behav ior Catalog owner processing behavior owner processing behavior Catalog Sales Service Protocol owned service role Service Role Service Protocol Catalog Sales Beneficiary Service Delivery of Catalog Service Protocol Service Delivery of Catalog Order Service Protocol Catalog Sales Provider P art Connection as Part owned service interaction Serv ice In teraction service delivery type 0.. service protocol usage Service Delivery Catalog Order Service Protocol Order from Catalog Buyer Seller involving interac tion involved interactive part 2.. Process Step Step Succession Service Interactive Part Part Connection played interac tive part binding context owned binding Service Interactive Part Binding player interactive part Product Figure 4.8: Service Delivery

34 4.3 Relation of Process and Service Protocol Figure 4.9 shows how activities are assigned to performer roles (Performer Role is a sibling of Service Role specialized from Service Interactive Part). The artifact flows between activities in separate performer roles can conform to reusable protocols, as shown in Figure 4.0 (a capability inherited from Interactive Part). The performers have their own processes through role realization (metamodel not shown), which must also conform to the protocol. Performer Role Another Process Performer Role Activity Activity 2 Activity 3 Activity 5 Activity 4 Proc ess Serv ice Interactive Part 0.. process as processor role 0.. processor role as process Processor Role PerformerRole activity performer performedactivity Activity delegating performer role delegated performer role Figure 4.9: Performer Role Another Process Performer Role Performer Role 2 Activity Activity 2 Activity 3 Service Delivery of Catalog Service Protocol Activity 5 Activity 4 Performer Role Realization Catalog Service Protocol Search Requester Catalog Provider Another Process

35 Figure 4.0: Performer Role Realization

36 4.4 Course and Composition The models so far rest on abstractions that pull together the concrete specializations used by business modelers. The abstractions provide consistency of modeling and semantics throughout BPDM by identifying commonalities among the various concrete classes, making them easier to understand and implement as compared to redundant representations for each special case. Constraints can be defined once on the abstract models, rather than restated in all the specializations, where they can become inconsistent with each other in a way that cannot be automatically detected. The abstractions also provide a level at which tools can traverse the models independently of whether they represent process or service protocols ( orchestration and choreography ). Figure 4. shows the first abstraction, the Course Model, which provides a unified representation of processes and service protocols, (Course, Step, and Succession). Courses have steps, which occur in sequences specified by successions. A process step is either an Activity (in a Process) or a Service Interaction (in a Protocol); see Sections 4. and 4.2. Sequencing in process and service protocols is unified by Succession, which can be constrained in various ways, such as the various kinds of splits and joins available in typical flow modeling languages. Courses are types to which their occurrences (instances) must conform. In particular, the occurrences of a course (process or service protocol) obey succession constraints of the course, and artifact / interaction flow constraints in processes and protocols. Typ e Composite Course Behavior owner course {subsets part whole[]} owner course {subsets connection whole[]} Processing Behavior {subsets composite part[]} owned step Step Part {subsets to[]} next step {subsets source connection[]} previous succession Part Connection Succession {subsets owned connection[]} owned Succession previous step {subsets from[]} next succession {subsets target connection[]} Process Step Service Interaction Activity Figure 4.: Course Model

37 Figure 4.2 shows the second abstraction, the Composition Model, for connecting parts together into an organized whole. It also supports the decomposition of parts and connections into more detailed organized wholes by reusing composite types and relations. It generalizes the Course Model of Figure 4., with the steps in a course being the parts of a composite whole (activities in processes, service interactions in protocols). The succession constraints artifact / interaction flows are connections between parts of the composite process (the activities and interactions). Interaction that expand to more detailed protocols (Service Delivery, see Section 4.2) is achieved by treating connections as parts, Part Connection As Part. Figure 4.2: Composition Model

38 5 Specification This section presents the normative specification for business process definition metamodel. It begins with an overview of the BPDM metamodel structure followed by a description of each sub-package.

39 5. Overview BPDM holds all definitions common to process oriented models. It also establishes relationships between interaction processes, also called choreographies and activity based processes, also called orchestrations. Infrastructure Library Core Basic PrimitiveTypes Abstractions Expressions Business Process Definition MetaModel Composition Model Course Model Common Behavior Model Service Model Activity Model Package Business Process Definition MetaModel Comment BPDM holds all definitions common to process oriented models. It also establishes relationships between interaction processes, also called

40 choreographies and activity based processes, also called orchestrations. Composition Model Course Model Common Behavior Model Service Model Activity Model The composition model provides the principles and mechanisms for reuse and decomposition. It is based on the part/usage pattern where Types are used through intermediate objects called Parts. The Course Model describes common concepts used for all process oriented models. It describes the kinds of Parts that make a process object and its associated Part Connections. The Common Behavior Model includes elements shared by all process based models The Service Model includes all definitions that relates to service interactions and protocols The Activity Model includes all definitions concerning activities and performers Infrastructure Library Core InfrastructureLibrary package defines a reusable metalanguage kernel and a metamodel extension mechanism for UML. The metalanguage kernel can be used to specify a variety of metamodels, including UML, MOF, and CWM. In addition, the library defines a profiling extension mechanism that can be used to customize UML for different platforms and domains without supporting a complete metamodeling capability. The Core package is the central reusable part of the InfrastructureLibrary. Abstractions The Abstractions package of InfrastructureLibrary::Core is divided into a number of finer-grained packages to facilitate flexible reuse when creating metamodels. Expressions The Expressions package in the Abstractions package specifies the general metaclass supporting the specification of values, along with specializations for supporting structured expression trees and opaque, or uninterpreted, expressions. Various UML constructs require or use expressions, which are linguistic formulas that yield values when evaluated in a context PrimitiveTypes The PrimitiveTypes package of InfrastructureLibrary::Core contains a number of predefined types used when defining the abstract syntax of metamodels. Basic The Basic package of InfrastructureLibrary::Core provides a minimal class-based modeling language on top of which more complex languages can be built. It is intended for reuse by the Essential layer of the Meta-Object Facility (MOF). The metaclasses in Basic

41 are specified using four diagrams: Types, Classes, DataTypes, and Packages. Basic can be viewed as an instance of itself. More complex versions of the Basic constructs are defined in Constructs, which is intended for reuse by the Complete layer of MOF as well as the UML Superstructure.

42 5.2 Composition Model The composition model provides the principles and mechanisms for reuse and decomposition. It is based on the part/usage pattern where Types are used through intermediate objects called Parts Composition Generalization generalization specific Type general traced generalization Composite generalization trace Part conformance specification part conforming part Element part whole {subsets owner[0..]} {subsets ownedelement[]} composite part connection whole {subsets owner[0..]} {subsets ownedelement[]} owned connection Element Part {subsets connected part[2..]} to source connection {subsets part connection[]} Part Connection connected part 2.. part connection grouped part {subsets connected part[2..]} from target connection {subsets part connection[]} enclosing part group Typed Part Part Group Part Connection as Part type usage {subsets typedelement[]} {subsets type[0..]} parttype usage Type TypedElement 0.. type typedelement Selection Typed Part Selector Selection List selection rule selected part candidate Individual

43 5.2.3 Composite Namespace: Composition Model isabstract: Yes Generalization: Type A Composite is a Type that specifies relations between its parts. This structure is made of Parts and connections between Parts called Part Connection. Part can be the usage of a Composite for recursive structures. Associations composite part : Part [] {ownedelement} A composite part is a Part that is a structural element of a Composite owned connection : Part Connection [] {ownedelement} Generalization Namespace: Composition Model isabstract: Yes Associations general : Type [] generalization trace : Part conformance [] specific : Type [] Individual Namespace: Composition Model

44 isabstract: Part Namespace: Composition Model isabstract: Yes Generalization: Element A Part is an element of the structure of a Composite. A Part is typed by at most one Type. The kinds of suitable Types depend on the nature of the Composite. The range of possible Typed Parts for a Part may include more that one type. A Part without a Typed Part is a leaf Part. A Part with a Typed Part is a complex Part. Associations part connection : Part Connection [] part whole : Composite [] source connection : Part Connection [] target connection : Part Connection [] {owner} {part connection} {part connection} Part conformance Namespace: Composition Model isabstract: Associations

45 conforming part : Part [] specification part : Part [] traced generalization : Generalization [] Part Connection Namespace: Composition Model isabstract: Yes Generalization: Element A Part Connection is used to connect Parts of a Composite. Associations connected part : Part [2..] connection whole : Composite [] from : Part [] to : Part [] {owner} {connected part} {connected part} Part Connection as Part Namespace: Composition Model isabstract: Yes Generalization: Part Connection Part A Part Connection as Part is a Part Connection that is also a Part. This means it can be typed and be connected with other kind of Part Connection

46 5.2.0 Part Group Namespace: Composition Model isabstract: Yes Generalization: Part Associations grouped part : Part [] 5.2. Selection List Namespace: Composition Model isabstract: Generalization: Selector Associations candidate : Individual [] Selector Namespace: Composition Model isabstract: Yes

47 Associations selected part : Typed Part [] Typed Part Namespace: Composition Model isabstract: Yes Generalization: Part TypedElement A Typed Part is a type that is used for typing parts of a Composite. A Typed Part cannot be used directly as a part of a Composite. It must be "embedded" as a part in the context of a Composite. Associations parttype : Type [] {type} selection rule : Selector []

48 5.3 Course Model The Course Model describes common concepts used for all process oriented models. It describes the kinds of Parts that make a process object and its associated Part Connections Course Model Composite Course Part owner course {subsets part whole[]} owner course {subsets connection whole[]} {subsets composite part[]} owned step Step Suc cession Condition previous step {subsets from[]} {subsets triggered[]} next step {subsets to[]} {subsets trigger[]} succession condition {subsets compound condition[]} Initial Step Final Step Xor Split And Split And Join Or Join {subsets target connection[]} {subsets triggered fact[]} next succession {subsets source connection[]} {subsets triggering fact[]} previous succession.. {subsets involved condition[]} conditionned succession Part Connection {subsets owned connection[]} owned Succession Succession Conditions {subsets involved element[..]} involved condition Condition condition tree / condition root hook 0.. Element Conditionnable Element 0.. condition.. involved element compound condition Compound Condition Opaque Condtion case argument specified condition opage specification ValueSpecification Disjunction Conjunc tion switch {subsets ownedelement[]} condition specification specified condition {subsets owner[0..]}

49 5.3.3 And Join Namespace: Course Model isabstract: Generalization: Succession Condition And Split Namespace: Course Model isabstract: Generalization: Succession Condition act of selecting a path from one place to another Compound Condition Namespace: Course Model isabstract: Generalization: Condition Associations involved condition : Condition [] {involved element}

50 5.3.6 Condition Namespace: Course Model isabstract: Yes State, situation, fact that must exist for another state, situation, fact to exist Associations compound condition : Compound Condition [] condition root hook : Element [0..] involved element : Conditionnable Element [..] root step : Step [0..] root step : Step [0..] {condition root hook} Conditionnable Element Namespace: Course Model isabstract: Yes Generalization: Element Conjunction Namespace: Course Model isabstract: Generalization: Compound Condition

51 5.3.9 Course Namespace: Course Model isabstract: Yes Generalization: Composite A Course is an ordered Succession of Steps Merriam-webster unabridge dictionnary: Course 4 : an ordered continuing process, succession, sequence, or series following the course of the argument the course of history the course of the hearings Associations owned step : Step [] owned Succession : Succession [] {composite part} {owned connection} Disjunction Namespace: Course Model isabstract: Generalization: Compound Condition

52 5.3. Final Step Namespace: Course Model isabstract: Yes Generalization: Step A Final Step is a ConControlAction that that stops all flows in an Processing Behavior Initial Step Namespace: Course Model isabstract: Generalization: Step Opaque Condtion Namespace: Course Model isabstract: Generalization: Condition Associations opage specification : ValueSpecification [0..] switch : switch [0..]

53 5.3.4 Or Join Namespace: Course Model isabstract: Generalization: Succession Condition Step Namespace: Course Model isabstract: Yes Generalization: Part A Step is a stage or interval in a development or Course. Associations next condition tree : Condition [] next succession : Succession [] owner course : Course [] previous condition tree : Condition [] previous succession : Succession [] {condition tree} {target connection}{triggered fact} {part whole} {condition tree} {source connection}{triggering fact} Succession Namespace: Course Model isabstract: Yes

54 Generalization: Part Connection Condition Triggering A Succession is Part Connection that organizes Steps in series in the context of a Course Merriam-Webster: the act or process of following in order of time or place : a repeated following up of one by another Associations next step : Step [] owner course : Course [] previous step : Step [] {to}{trigger} {connection whole} {from}{triggered} Succession Condition Namespace: Course Model isabstract: Generalization: Compound Condition A Succession Condition is a constraint on the way Successions can be traversed between Steps Associations conditionned succession : Succession [..] {involved condition} switch Namespace: Course Model isabstract:

55 Generalization: Compound Condition Associations case argument : Opaque Condtion [] condition specification : ValueSpecification [] {ownedelement} Xor Split Namespace: Course Model isabstract: Generalization: Succession Condition

56 5.4 Service Model The Service Model includes all definitions that relates to service interactions and protocols 5.4. Core Processing Behavior processing behavior type {subsets parttype[]} owner processing behavior {subsets part whole[]} Service Protocol owner processing behavior {subsets part whole[]} Process Step Part Connection as Part Typed Behavioral Part processing behavior usage {subsets type usage[]} owned service interaction {subsets composite part[]} Service Interaction 0.. service delivery type {subsets parttype[]} Interactive Flow Service Interaction Flow involving interaction {subsets part connection[]} {subsets type usage[]} service protocol usage Service Delivery {subsets composite part[]} owned service role Service Role received interaction flow {subsets involving interaction[]} {subsets received flow[]} sent interaction flow {subsets involving interaction[]} {subsets sent flow[]} {subsets ownedelement[]} owned binding binding context {subsets involved interactive part[2..]} {subsets consumer[]} service interaction flow consumer Serv ice Interaction Message (BPMN) {subsets involved interactive part[2..]} {subsets producer[]} service interaction flow producer 2.. {subsets connected part[2..]} involved interactive part Serv ice Interactive Part Service Interactive Part Binding {subsets from[]} player interactive part Part Connection {subsets to[]} played interactive part 0.. fulfilled service role Processing Behavior Service Boundary Interactive Part Emerging Service Protocol Processing Behavior start service flow / end service flow / Service Interaction Flow intermediate input service flow / intermediate output service flow /

57 5.4.3 Processing Behavior Service Boundary Namespace: Service Model isabstract: Generalization: Service Role A Processing Behavior Service Boundary specifies the Service Role to which a Processing Behavior delivers its Service Service Delivery Namespace: Service Model isabstract: Generalization: Service Interaction A Service Delivery defines the involvement of at least two Service Interactive Parts in a complex interaction. The nature of this interaction is defined by a Service Protocol. As a Process Step a Service Delivery can be sequenced with Successions. Associations owned binding : Service Interactive Part Binding [] service delivery type : Service Protocol [0..] {ownedelement} {parttype} Service Interaction Namespace: Service Model isabstract: Yes

58 Generalization: Part Connection as Part Process Step A Service Interaction is the unit of communication that Service Interactive Parts use to coordinate each other. A Service Interaction can be either a simple interaction - Service Interaction Flow - or a complex interaction - Service Delivery. A Service Interaction is also a Process Step that can be sequenced with Succession to describe the choreography of interactions that occur between the involved Service Interactive Parts. Associations involved interactive part : Service Interactive Part [2..] owner processing behavior : Processing Behavior [] {connected part} {part whole} Service Interactive Part that benefits from the results of a Service Delivery that it has initiated though a joint action trigger Service Interaction Flow Namespace: Service Model isabstract: Generalization: Interactive Flow Service Interaction Typed Behavioral Part An Service Interaction Flow is an Interactive Flow that occurs between Service Interactive Parts. Service Interaction Flows are used to describes communications that occur at the boundaries of Processing Behaviors. A Service Interaction Flow is also a Process Step that can be sequenced with Succession to describe the choreography related to its Service Interactive Parts. Associations service interaction flow consumer : Service Interactive Part [] service interaction flow producer : Service Interactive Part [] {involved interactive part}{consumer} {involved interactive part}{producer}

59 5.4.7 Service Interaction Message (BPMN) Namespace: Service Model isabstract: Generalization: Service Interaction Flow Service Interactive Part Namespace: Service Model isabstract: Yes Generalization: Interactive Part Service Interactive Part is a kind of an Interactive Part that defines the capability to engage into Service Interactions. As such, it can exchange Service Interaction Flows with other Interactive Part or engage into Service Protocol with other Interactive Part is an abstract class. Associations involving interaction : Service Interaction [] received interaction flow : Service Interaction Flow [] sent interaction flow : Service Interaction Flow [] {part connection} {involving interaction}{received flow} {involving interaction}{sent flow} Service Interactive Part Binding Namespace: Service Model isabstract: No

60 Generalization: Part Connection A Service Interactive Part Binding is a kind of Part Connection. Service Interactive Part Bindings are used to connect Service Deliverys to Service Interactive Parts. A Service Interactive Part Binding also provides a binding between its Service Interactive Part and the player interactive part within the Process that types the connected Service Delivery. Associations binding context : Service Delivery [] played interactive part : Service Interactive Part [] player interactive part : Service Interactive Part [] {to} {from} Service Protocol Namespace: Service Model isabstract: Generalization: Processing Behavior A Service Protocol is a kind of Processing Behavior that defines a set interactions required to deliver a Service Service Role Namespace: Service Model isabstract: Generalization: Service Interactive Part

61 A Service Role is a concrete Service Interactive Part. It manifests an interaction point where Services are delivered by a Processing Behavior Associations owner processing behavior : Processing Behavior [] {part whole} Typed Behavioral Part Namespace: Service Model isabstract: Yes Associations processing behavior type : Processing Behavior [] {parttype} Notation samples Service Protocol Diagram

62 Catalog Sales - Service Protocol Diagram Service Delivery Service Role Catalog Sales Customer Catalog User Goods Receiver Order Placer Catalog Service Order Service Catalog Sales Retailer Catalog Provider Shipper Requester Order Handler Credit Charger Catalog Sales Customer On Order Placement DropShip Service Goods shipping Service Credit Service Shipper Shipping Prov ider Goods Shipper Succession Creditor Creditor Process Diagram

63 Service Delivery Catalog Sales Process Credit Agency - BradCo Credit Agency Creditor Customer - BradCo Customer Market Catalog Sales Buyer Goods receiver Catalog Sales Catalog Sales Retailer Retailer a c Shipper DropShip Vendor PerformerRole BradCo Sales Retailer Process Process Implementing the performer role Flow Protocol Order Placement - Flow Protocol Message Flow Order Placer Order Placement Goods Delivery Notification Order Rejection Message Flow Seller message flow sequence Succession Constraint Participant

64 Service Protocol Diagram Order Service - Service Protocol Diagram Order Placer Quotee Prospect Order Placer Inf o Provider Order Request Order Placement (Optional) after Order Request Succession Order Cancellation Service Role Order Form Completion Order Handler Quoter Order Quoter Info Requester Seller Service Delivery

65 5.5 Activity Model The Activity Model includes all definitions concerning activities and performers 5.5. Core Processing Behavior Process Happening process start specification specified started process owner process {subsets part whole[]} 0.. Serv ice Interactive Part {subsets composite part[]} Interactive Part owned artifact interactive part PerformerRole Artifact Interactive Part Serv ice Interactive Part activity performer performedactivity artifact flow consumer {subsets consumer[]} {subsets received flow[]} received artifact flow artifact flow producer {subsets producer[]} {subsets sent flow[]} artifact flow receiver TypedElement Activity Artifact Flow Holder Listener Publisher triggered activity triggering activity {subsets next step[]} {subsets previous step[]} Interactive Flow Process Step Succession Flow Binding Context {subsets previous succession[]} triggering control flow {subsets next succession[]} triggered control flow Control Flow Artifact Control Flow