Process Modeling Notations and Workflow Patterns

TL;DR: This paper reviews how two graphical process modeling notations, tShe BPMN Business Process Diagram from the Business Process Management Initiative (BPMI), and the UML 2.0 Activity Diagramfrom the Object Management Group (OMG), can represent the workflow patterns.

Abstract: The research work of Wil van der Aalst, Arthur ter Hofstede, Bartek Kiepuszewski, and Alistair Barros has resulted in the identification of 21 patterns that describe the behavior of business processes. This paper reviews how two graphical process modeling notations, tShe BPMN Business Process Diagram from the Business Process Management Initiative (BPMI), and the UML 2.0 Activity Diagram from the Object Management Group (OMG), can represent the workflow patterns. The solutions of the two notations are compared for technical ability to represent the patterns as well as their readability. INTRODUCTION The research work of Wil van der Aalst, Arthur ter Hofstede, Bartek Kiepuszewski, and Alistair Barros has resulted in the identification of 21 patterns that describe the behavior of business processes. The rationale for the development of the patterns was to describe the potential capabilities that a workflow server may have during the performance of business processes. The patterns range from very simple to very complex and cover the behaviors that can be captured within most business process models. The researchers have developed a web site that contains descriptions and examples of these patterns, plus supporting papers and evaluations of how workflow products support the patterns. The purpose of this paper is to examine how two modeling notations, the BPMN Business Process Diagram from BPMI, and the UML 2.0 Activity Diagram from the OMG, can graphically represent the workflow patterns. For each of pattern, there will be a comparison of the two notations about how well they handled the pattern. The focus of the comparison will be both technical and how visually intuitive each notation represents the pattern. BASIC CONTROL PATTERNS The first five patterns are fairly simple examples of process behavior. They define the basic modeling patterns of business processes. WORKFLOW PATTERN: SEQUENCE The Sequence pattern is defined as being an ordered series of activities, with one activity starting after a previous activity has completed. The WfMC defines this behavior as a “Sequential Routing.” Business Process Diagram A Business Process Diagram defines this pattern as a series of activities connected by Sequence Flow (see Figure 1). The direction of the Sequence Flow arrowheads determines the order of the Sequence. The behavior of this pattern can be described by the use of a conceptual “Token” that travels down a Sequence Flow from the source object to the target object—as shown by the directionality of the arrows. For this pattern, when an activity completes, a Token will travel through the Sequence Flow from that activity to the next activity in the Sequence. There is no conditionality or any other type of control put upon the Token. In BPMN, any control placed upon the flow of Tokens will be indicated by a diamond shape, with either a Gateway object or a conditional Sequence Flow. Examples of the flow control will be seen in the other workflow patterns. Tokens will be used to describe the behavior of the patterns covered in this paper. 1 http://tmitwww.tm.tue.nl/research/patterns/patterns.htm 2 The Workflow Management Coalition Terminology & Glossary (1999) BPTrends March, 2004 Process Modeling Notations and Workflow Patterns Copyright Steven A. White (2004) All rights reserved www.bptrends.com 2 Figure 1: WP #1: Sequence—Business Process Diagram Activity Diagram The UML Activity Diagram defines this pattern as a series of activities connected by control flow (see Figure 2). The direction of the control flow arrowheads determines the order of the Sequence. As with the Business Process Diagram, when an activity completes, a Token will travel through the control flow from that activity to the next activity in the Sequence. Figure 2: WP #1: Sequence—Activity Diagram Comparison There is no major difference between BPMN and UML in diagramming the Sequence pattern. Both notations use rounded rectangles to notate activities. The exact degree of rounding for the corners of the rectangles is up to the modeler or tool vendor. Both use solid, directed lines to show the direction of flow. However, the arrowheads are different between the two standards. UML uses a line arrowhead for control flow and standard object flow, while BPMN uses a solid arrowhead for its Sequence Flow. UML does use a solid arrowhead, but this is used for streaming object flow edges—which means that multiple object Tokens can enter the activity without generating new instances of that activity. This type of behavior handled through Association links in BPMN (refer to the respective UML and BPMN specifications for more details on these types of behaviors). The arrowhead differences will apply to all the patterns described below. WORKFLOW PATTERN: PARALLEL SPLIT The Parallel Split pattern is defined as being a mechanism that will allow activities to be performed concurrently, rather than serially. A single path through the process is split into two or more paths so that two or more activities will start at the same time. The WfMC defines this behavior as an “AND-Split.” Business Process Diagram A BPMN Business Process Diagram provides three mechanisms for creating the Parallel Split pattern. The first mechanism allows that a flow object can have two or more outgoing Sequence Flow (see Figure 3). A special flow control object is not required to fork the path, since it is considered uncontrolled flow; that is, flow will proceed down each path without any dependencies or conditions—i.e., there is no Gateway that controls the flow. A Token will be generated for each of the outgoing Sequence Flow. Forking Sequence Flow can be generated from a Task, SubProcess, or a Start Event. Figure 3: WP #2: Parallel Split—Business Process Diagram, Version 1 The second mechanism uses a Parallel Gateway (A diamond with a plus sign internal marker—see Figure 4). For situations as shown in Figure 4, a Gateway is not required, since the same behavior can be created through multiple outgoing Sequence Flow, as shown in Figure 3. However, some modelers and modeling tools may use a forking Gateway as a “best practice.” After the Token arrives at the Gateway, there will be a Token immediately sent down each of the outgoing Sequence Flow. BPTrends March, 2004 Process Modeling Notations and Workflow Patterns Copyright Steven A. White (2004) All rights reserved www.bptrends.com 3 There are other situations where the Parallel Gateway would be required, such as a Parallel Split that follows an Exclusive Choice (see Figure 10 for an example of an Exclusive Choice). Figure 4: WP #2: Parallel Split—Business Process Diagram, Version 2 A third mechanism can be used to create the Parallel Split pattern. If a Process or a Sub-Process does not have a Start Event, which is optional, then any activity that does not have any incoming Sequence Flow will start when the Sub-Process starts. A Token will be provided for each of the starting activities. The general idea is that the modeler can create a “parallel box,” as seen in Figure 5, and create a parallel situation with a compact and visually distinct technique. Figure 5: WP #2: Parallel Split—Business Process Diagram, Version 3 Activity Diagram The UML Activity Diagram uses a fork node to create a set of parallel paths (a vertical or horizontal bar—see Figure 6). The bar shown in the figure indicates that all outgoing control flow from the bar will create a set of parallel flows. A Token will be generated for each of the outgoing control flow. The target activities for each of those flows will be available to start at the same time. Figure 6: WP #2: Parallel Split—Activity Diagram Comparison The mechanisms for providing the Parallel Split pattern are different between the two notations. BPMN provides much simpler mechanisms with the multiple outgoing Sequence Flow and the “parallel box.” If a control object is required or desired, then a parallel Gateway is available. UML requires that a graphical object, a fork node, create the Parallel Split. In general, the approach for controlling flow is different between the two notations. BPMN employs a single shape, a diamond, to represent any control or constraint on the flow of Tokens between activities. Internal markers indicate the exact type of control (e.g., alternative or parallel splits). The diamond shape was chosen since it is widely recognized as a decision object in flow charting. The BPMN approach provides for a smaller set of core modeling objects. UML employs two different types of objects (a diamond and a bar) to represent control of Token flow. This provides a easier distinguishing between the two basic types of control (alternative and parallel), but when more complex control is required, such as a N out of M Join or a Synchronizing Merge, which contain both alternative an parallel behavior, then the distinction becomes less clear. BPTrends March, 2004 Process Modeling Notations and Workflow Patterns Copyright Steven A. White (2004) All rights reserved www.bptrends.com 4 WORKFLOW PATTERN: SYNCHRONIZATION The Synchronization pattern combines the paths that were generated by a Parallel Split pattern. The final set of activities within the flows must be completed before the process can continue. This is the “synchronization” of the parallel paths. The WfMC defines this behavior as an “AND-Join.” Business Process Diagram In BPMN, there are two mechanisms for the Synchronization pattern. The first mechanism involves the use of a Parallel Gateway (see Figure 7). This Gateway also functions for the Parallel Split pattern (see Figure 4), and can perform both functions simultaneously. The Gateway will accept multiple incoming Sequence Flow and wait for a Token to arrive from each flow before a single Token will continue past the Gateway. This mechanism is used for both of the first two types of Parallel Split patterns (see Figure 3 and Figure 4). A Gateway must be used in this case since the flow of