The Business Process Modeling Notation - CiteSeerX

Chapter 1

The Business Process Modeling Notation Gero Decker, Remco Dijkman, Marlon Dumas, and Luciano Garc´ıa-Bañuelos

1.1 Introduction Business processes may be analyzed and designed at different levels of abstraction. In this respect, it is common to distinguish between business process models intended for business analysis and improvement, and those intended for automation by means, for example, of a workflow engine such as YAWL. At the business analysis level, stakeholders focus on strategic and tactical issues such as cost, risks, resource utilization, and other non-functional aspects of process models. At the automation level, stakeholders are interested in making their models executable, which entails the need to provide detailed specifications of data types, data extraction and conversion steps, application bindings, resource allocation and distribution policies, among others. The requirements for process modeling notations at these two levels of abstraction are significantly different. This in turn has resulted in different languages being advocated at the business analysis level and at the execution level. Common languages used at the business analysis level include flowcharts, UML activity diagrams, the Business Process Modeling Notation (BPMN) and Event-driven Process Chains (EPCs). In this chapter, we consider BPMN, and specifically, version 1.0 of the BPMN standard specification. In general, the main purpose of BPMN models is to facilitate communication between domain analysts and to support decision-making based on techniques such as cost analysis, scenario analysis and simulation. However, BPMN models are also used as a basis for specifying software system requirements, and in such cases, they are handed over to software developers. This handover raises the following question: How can developers fully exploit BPMN process models produced by domain analysts? One way to achieve a seamless handover is by transforming, either manually or automatically, business proces models obtained from business analysis (for example BPMN models) into “equivalent” process models defined in an executable language,

1

2

Gero Decker, Remco Dijkman, Marlon Dumas, and Luciano Garc´ıa-Bañuelos

such as YAWL. Accordingly, this chapter will discuss relationships between BPMN and YAWL, and will show how BPMN models can be transformed to YAWL nets. The remainder of this chapter is organized as follows. Section 1.2 introduces the Business Process Modeling Notation (BPMN). Section 1.3 explains the transformation from BPMN models to YAWL nets and section 1.4 presents the tool support that was developed to automate the transformation.

1.2 BPMN This section explains BPMN by example, distinguishing control-flow, data manipulation, resource management and exception handling aspects. The presentation of BPMN is meant to be didactical rather than exhaustive.

1.2.1 Control-flow In BPMN, a process model is represented as a Business Process Diagram (BPD). With reference to the running example of the book, Figure 1.1 depicts a BPD corresponding to a freight-in-transit process. This BPD consists of nodes of three types: events (represented as circles), activities (represented as rectangles) and gateways (represented as diamonds). Events denote things that happen at a particular point in time, activities denote work that needs to be performed, and gateways serve to route the flow of control along the branches of the BPD. Nodes are connected by means of directed edges called sequence flows. A sequence flow basically says that the flow of control can pass from the source node to the target node. Freight in Transit

more Trackpoints Issue Trackpoint Notice

Log Trackpoint Order Entry

Create Acceptance Certificate

Freight delivered

24 hours

Initiate Shipment Status Inquiry

Fig. 1.1 Example of a business process model in BPMN

1 The Business Process Modeling Notation

3

There are three types of gateways in BPMN: XOR gateways (represented by an ‘X’), AND gateways (represented by a ‘+’) and OR gateways (represented by an ‘O’). Moreover, a gateway is said to be a split gateway if it has multiple outgoing flows or a join gateway if it has multiple incoming flows. It may happen that a gateway is both a split and a join gateway, but this essentially means that there are two gateways in a single one. If we put together the distinction between the three types of gateways (XOR, AND, OR) and the distinction between split and join gateways, we obtain six different types of gateways: XOR-split, XOR-join, ANDsplit, AND-join, OR-split and OR-join.1 These six types of gateways are similar to the decorators in YAWL. Like in YAWL, an XOR-split is a decision point. Based on the evaluation conditions, the flow of control will go to exactly one of the outgoing flows of the XORsplit. For example, Figure 1.1 has one XOR-split gateway. One of the flows going out of this gateway is labelled with the condition more trackpoints are needed, while the other outgoing flow is the default flow, denoted by a stripe through the flow. The default flow is taken if the condition(s) attached to the other conditional flow(s) is/are not fulfilled – in this example the default flow is taken if the condition more trackpoints are needed is not fulfilled. An XOR-join on the other hand merges two incoming branches into a single one. Figure 1.1 features an XOR-join just before task Issue Trackpoint Notice which merges two incoming paths. An AND-split splits one thread of execution into two or more parallel threads. For example, the AND-split on the left-hand-side of Figure 1.1 starts two threads in parallel. These threads then join in an AND-join just before task Create Acceptance Certificate. The AND-join is a synchronization point – it waits for both threads to complete. The OR-split (which we do not exemplify) is a hybrid between the XOR-split and the AND-split, allowing a split into any number of outgoing flows instead of one (XOR-split) or all (AND-split). Similarly, the OR-join is a hybrid between an XOR-join and an AND-join, synchronizing all flows that have the control. These constructs correspond to those of OR-split and OR-join decorators in YAWL. Unlike YAWL however, the exact semantics of the OR-join in BPMN is underspecified in the standard specification. There is also another type of gateway in BPMN called “complex gateway”, which is not discussed in this chapter. Finally, BPMN introduces a type of split gateway that corresponds to the “Deferred Choice” workflow pattern. This is called the “event-based exclusive gateway”. The event-based exclusive gateway is similar to the XOR-split (which is also called data-based exclusive gateway in BPMN). However, instead of the choice being driven by conditions (which are evaluated based on data), the choice is driven by two or more events, such that the choice for an outgoing flow is made when the event on that outgoing flow occurs. Concretely, an event-based exclusive gateway is represented using a star symbol. Figure 1.1 features an event-based exclusive 1

The BPMN specification uses alternative terms: XOR-splits are exclusive decision gateways, XOR-joins are exclusive merge gateways, OR-splits are inclusive decision gateways, OR-joins are inclusive merge gateways, AND-splits are parallel forking gateways and AND-joins are parallel joining gateways. Here, we adopt a simpler and more uniform terminology.

4


gateway. When the execution of the process arrives at this point (in other words – when a token arrives to this gateway), the execution of that thread stops until either the message event or the timer event occur. Whichever occurs first will determine which way the execution will proceed. If the timer event occurs first, a shipment status inquiry is initiated and the execution flow comes back to the event-based exclusive gateway. If the message signaling the freight delivery is received first, the execution flow proceeds along the sequence flow that leads to the AND-join. Note that in Figure 1.1, the event-based exclusive gateway is also a join, since it has two incoming flows. A token may arrive to this gateway from either of these incoming flows. Events are classified along two critera. Firstly, an event can be a start event, an end event or an intermediate event. The sample BPD contains a single start (leftmost element) and a single end event (rightmost element), and two intermediate events in the middle of the BPD. Secondly, events are classified according to their trigger. In this chapter, we consider four types of triggers: messages, timers, conditions and errors. A message event is represented using an envelope icon. Such an event is triggered by the receipt of a message, but can also be used to represent the event of sending a message. Figure 1.1 shows a message event that is triggered by the receipt of a message (presumably from a system located in the warehouse) representing the arrival of the freight. A timer event is represented using a clock icon. Figure 1.1 shows a timer event that is triggered when 24 hours have elapsed. A rule event is represented by an icon corresponding to a sheet of lined paper. It has a condition attached to it and the event is triggered when this condition becomes true. An error event is represented by a lightning icon. It is triggered when an error occurs, but it can also represent the event of throwing an error.2 The process model shown in Figure 1.1 is “flat”, meaning that all the activities in the model correspond to atomic units of work – also called atomic tasks in BPMN. BPMN also supports activities that correspond to the execution of entire sub-processes – like composite tasks in YAWL. Figure 1.2 shows a fragment of a BPD consisting of a number of sub-processes, one of which corresponds to the freight-in-transit process shown in Figure 1.1. Sub-processes are distinguished from atomic tasks using the + marker.

Payment + Ordering

Carrier Appointment

+

+

Freight Delivered Freight in Transit

+

+

Fig. 1.2 Example of a business process model in BPMN

2

Specifically, an end error event corresponds to throwing an error, while an intermediate error event corresponds to catching an error.


5

There are several types of sub-processes in BPMN, including embedded subprocess and independent sub-process. An embedded sub-process is part of the parent process, while an independent sub-process exists independently of the parent process. This chapter does not go into the details of these nuances and instead treats both embedded and independent sub-processes equally.

1.2.2 Data There are two ways in which the manipulation of data by processes and tasks can be specified in BPMN: by means of data objects and by means of properties. Data objects represent documents, data or other objects that are used in the process. They have a name and, optionally, a state. Data objects can be associated with activities, showing that they are input for (by an arrow pointing to that task) or output of that activity (by an arrow originating in that task). They can also be associated with flows, showing that they are transferred from one activity to another via that flow. Figure 1.3 illustrates these cases, annotating the business process diagram from Figure 1.1 with data objects. In the BPMN standard, data objects are used only informally for documentation purposes. Accoridng to the BPMN specification, they provide additional information for the reader of the BPMN Diagram, but do not directly affect the execution of the process. Therefore, data objects do not play any role when mapping BPMN to an executable workflow language. Indeed, in the mapping from BPMN to the Business Process Execution Language (BPEL) presented in an appendix of the BPMN specification, data objects are simply not mapped. Trackpoints

Freight in Transit

Trackpoint Notices

Trackpoint Order Entries Log

Acceptance Certificate

more Trackpoints Issue Trackpoint Notice

Log Trackpoint Order Entry

Create Acceptance Certificate

Freight delivered

24 hours

Initiate Shipment Status Inquiry

Fig. 1.3 Example of a business process model with data in BPMN

6


Properties in BPMN can roughly be equated to variables in YAWL. They have a name and a type and can be associated with (sub-)processes and tasks (and data objects). In the BPMN standard properties are defined more precisely than data objects and they are proposed to be used for the purpose of defining transformations from BPMN to executable languages. Indeed, in the mapping from BPMN to BPEL presented in the BPMN specification, they are mapped to the data variables in BPEL. However, the drawback of properties is that they are not visible in the graphical notation of BPMN. To counter these drawbacks, properties and data objects can be used in combination: data objects to document the data aspect of the process and properties to precisely define the data variables that are used in the process. This is the approach we follow below. BPMN leaves the modeler with much freedom to model data and data manipulation. In particular it leaves the modeler with the freedom to choose the (textual) language in which property types and data manipulation are modeled. A benefit of this is that BPMN does not favor a particular workflow language for implementing BPMN models. Another benefit is that the modeler can now use BPMN to draw a model, without having to worry about the complexities of a data modeling language such as XQuery. However, a drawback of leaving freedom to choose a data modeling language is that it precludes a general mapping from BPMN to a workflow language, because such a general mapping would require the definition of a mapping from any data modeling language (including natural language) to the data modeling language used by the workflow system. Therefore, we will impose constraints in this chapter on what BPMN models we consider to be well-formed for mapping to YAWL. The YAWL-constrained version of BPMN that we consider, uses XQuery to model data and data manipulation (meaning that both the QueryLanguage and ExpressionLanguage attributes of the BPMN diagram must be set to XQuery). Properties of activities and processes must be used to represent data. Data types of properties must be specified in XML Schema. Assignments must be attached to activities in order to represent data manipulation and conditions on sequence flows must be used to represent conditional passing of control. Assignments and conditions must also be expressed in XQuery. Conditions with “ConditionType = None” are not accepted. Figure 1.4 shows an example, in which the details of the data objects from Figure 1.3 are added. Note that, while this figure uses XML to specify those details, this is done here only for the example, because the concrete syntax for specifying properties, conditions and assignments is not defined in BPMN. Figure 1.4 defines that the process Freight in Transit has the property trackpoints of type Trackpoints as well as some other properties. The trackpoints property corresponds to the Trackpoints data object that is shown in Figure 1.3. However, it is defined in more detail (assuming that the structure of the Trackpoints type is defined in an XML Schema elsewhere). Similarly, the task Issue Trackpoint Notice has some properties. This task also has some assignments. One assignment assigns the value of the trackpoints property of the Freight in Transit process to the trackpoints property of the task, when the task is started. Another assignment adds the trackpointNotice that is generated by the task (if one is generated at all) to the trackpointNotices of the


7

process. Finally, Figure 1.4 refines the condition more Trackpoints on one of the sequence flows from Figure 1.3. ... ... 1000

B

A C

6.

...

amount

A B

7.

C

References

1. J. Becker, M. Kugeler, and M. Rosemann. Process Management. A Guide for the Design of Business Processes. Springer, 2003. 2. R. Dijkman, M. Dumas, and C. Ouyang. Formal semantics and analysis of bpmn process models. Information and Software Technology, 50(12):1281–1294, 2008. 3. M. Dumas, A. Grosskopf, T. Hettel, and M.T. Wynn. Semantics of standard process models with or-joins. In Proceedings of the OTM Conferences 2007 (Part 1), volume 4803 of Lecture Notes in Computer Science, pages 41–58. Springer, 2007. 4. T. Andrews et al. Business process execution language for web services version 1.1, 2003. 5. Object Management Group. Unified modeling language (uml) superstructure. OMG Final Adopted Specification ptc/04-10-02, Object Management Group, 2002. 6. Object Management Group. Business process modeling notation (bpmn) version 1.0. OMG Final Adopted Specification dtc/06-02-01, Object Management Group, 2006. 7. G. Keller, M. Nüttgens, and A.-W. Scheer. Semantische prozessmodellierung auf der grundlage ereignisgesteuerter prozessketten (epk). Technical Report Heft 89, Institut für Wirtschaftsinformatik, Saarbrücken, Germany, 1992. (In German.). 8. C. Ouyang, W.M.P. van der Aalst, M. Dumas, A.H.M. ter Hofstede, and J. Mendling. From business process models to process-oriented software systems. ACM Transactions on Software Engineering Methodology, 19(1), January 2010. 9. J. Recker, M. Indulska, M. Rosemann, and P. Green. Do process modelling techniques get better? A comparative ontological analysis of BPMN. In Proceedings of the 16th Australasian Conference on Information Systems, Sydney, Australia, 2005. 10. P. Wohed, W.M.P. van der Aalst, M.Dumas, A.H.M. ter Hofstede, and N. Russell. On the suitability of bpmn for business process modelling. In Proceedings of the 4th International Conference on Business Process Management, volume 4102 of Lecture Notes in Computer Science, pages 161–176, 2006. 11. P.Y.H. Wong and J. Gibbons. A process semantics for bpmn. In Proceedings of 10th International Conference on Formal Engineering Methods, volume 5256 of Lecture Notes in Computer Science, pages 355–374, 2008.

23

Index

BPMN, 1–21 mapping to BPEL, 21

BPMN2YAWL, 19–20

25