Theory matters in BPM more than it does in most practical software fields. Theoreticians and practitioners tend to ignore each other's work, but in BPM, practitioners are keenly interested inand indeed, actively hypeacademic conceptions such as the pi-calculus, the Petri net, and, to a lesser extent, the state machine.
The pi-calculus, developed by Scottish mathematician Robin Milner in the 1990s, is an algebraic system for building processes that communicate with each other on channels. Each process has a control flow that supports sequential, conditional, or concurrent control flow.
Pi-calculus processes are written as sets of equations using a particular syntax. The examples developed in this chapter capture the most common elements.
According to pi-calculus convention, when one process sends information to another, it includes the name of the channel to be used for the other process to respond. This name is variable; it can change in response to changing conditions. Channel change is referred to as mobility.
The pi-calculus is thought to be an underpinning of process languages XLANG, BPML, WSCI, and WS-CDL, though leading BPM commentator van der Aalst thinks the connection is mostly hype.
The classical Petri net was developed by the mathematician Carl Adam Petri in the 1960s. A Petri net is a process; its main constructs are places (stopping points in the process, but NOT states), transitions (events that drive process movement), tokens, and arcs (connecting transition to place or place to transition).
Understanding the flow of control in a Petri net requires tracing the movement of tokens through the net. The rules of the classical net are simple: a transition can fire only if each of its input places (places that link to it) has at least one token; and when a transition fires, a token from each input place is moved to each output place (place that is linked to from the transition).
The "state" of a Petri net is the tally of tokens in each place.
The classical Petri net has been extended with color (guards and conditional branching) and hierarchy (subnets).
Petri nets are good at describing control flow semantics. The group headed by van der Aalst (known as the P4) has developed theory around process pattern flow semantics and the Petri net.
The Petri net has influenced WSFL, BPMN, and BPEL.
The state machine has a rich history, with key contributions by Turing, Moore, Mealy, and Harel. The UML state diagram is based on Harel model, which in turn is a fusion of the classical Mealy and Moore approaches with extensions for hierarchy and concurrency.
Compared with flow charts, the state machine is a clearer and more compact way to represent a business process. Flow charts are procedural, whereas state machines are declarative. As the complexity of a process increases, changes to the state machine are manageable, but the flow chart becomes unwieldy.
The state machine is the behavior of an entity. It consists of a set of states and a set of transitions.
The UML activity diagram is a both a flowcharting technique (and a good one at that, as White's analysis of its support for common process patterns shows) and a special kind of state machine whose activities are states and interactivity links triggerless transitions. Simon's paper charges that this notion is a bastardization of the idea of state machine.
The state machine has less direct influence on BPM standards than the pi-calculus and the Petri net. The activity diagram has surprisingly little influence at all on BPM.
