Receive Request
Store Request
Send Request Ack
SendQuote
ReceiveOrder
ReceiveCancel Prepare
Request Analysis
Request Analysis
Fig. 3.7.Related business processes, detailled view
decomposition. Activities are functions of the finest granularity; they are the building blocks of operational business processes.
When a business process is started, the business functions that it contains need to be executed. Therefore, each activity in a business process requires an implementation. The implementation of an activity can be based on function- ality provided by information systems, such as registering a new customer or reserving a flight. However, an activity implementation can also be provided by a knowledge worker without using information systems.
Definition 3.1 A functional decomposition of coarse-grained business func- tions to fine-granular activities defines thefunctional perspectiveof a business
process.
Value System
Value Chain
Supplier Value Chain
Enterprise Value Chain
Consumer Value Chain
*
*
Business Function 1
*
OrderManagement 1
*
GetOrder CheckOrder
Business Process 1
1..*
AnalyzeOrder
SimpleCheck
AdvCheck
Activity 1
*
Activity Implementation 1
*
AnalyzeOrder
AnalyzeOrder Component
AnalyzeOrder SimpleCheck AdvCheck Marketing and
Sales Operations
Enterprise Value Chain
Fig. 3.8. Levels of business process management. From value systems to activity implementations
activity instance layer corresponds to M0. Figure 3.9 shows the relationships between business functions, activity models, and activity instances.
An activity model describes a set of similar activity instances, analogously to a process model describing a set of process instances with the same struc-
Business Function 1
*
OrderManagement
GetOrder CheckOrder
AnalyzeOrder SimpleCheck AdvCheck Activity Model
1 1..*
Activity Instance 1 0..*
AnalyzeOrder (Smith, 123212)
SimpleCheck (Smith, 123212)
AdvCheck (Smith, 123212) MOF
M0 MOF
M1
Fig. 3.9.Activity models and activity instances
ture. While process models are typically expressed in graph-like notations (to be investigated in detail in the next chapter), activity models can be expressed in different forms, for instance, by plain text or by some formal specification or references to software components that implement them.
Activity instances represent the actual work conducted during business processes, the actual units of work. To make this discussion more concrete, assume a process instance that represents the processing of an insurance claim by Clara Smith on the damage amount of US $2000, submitted November 11, 2006. Let EnterClaim(Clara Smith, 2000, 11-11-2006) represent the activity instance responsible for entering the claim in the software systems of the in- surance company. When the company receives the claim, a process instance is started. Within this process instance, the activity instance EnterClaim(Clara Smith, 2000, 11-11-2006) is started. When the claim is entered in the system, this activity instance terminates.
Each activity instance during its lifetime is in different states. These states and the respective state transitions can be represented by a state transition diagram. A simple state transition diagram is shown in Figure 3.10. The states that an activity instance adopts during its lifetime are described as follows:
when it is created it enters theinit state. By theenabled state transition the activity instance can enter theready state.
If a particular activity instance is not required, then the activity instance can be skipped, represented by a skip state transition from the not started state to the skipped state. From the ready state, the activity instance can use the begin state transition to enter the running state. When the activity instance has completed its work, theterminatestate transition transfers it to
not started closed
init ready running terminated
initialize enable begin terminate
skip
skipped
Fig. 3.10. State transition diagram for activity instances
theterminated state. When an activity instance is in the terminated or the skipped state, then it isclosed.
While the state transition diagram shown in Figure 3.10 properly repre- sents the states of most activity instances in business processes, in real-world settings, activity instances are likely to expose a more complex behaviour.
Reasons for this complex behaviour include disabling and enabling activities, suspending running activities, and skipping or undoing activities. The re- spective state transition diagram is shown in Figure 3.11. It provides a more detailed view on the states of activity instances.
The state transition diagram representing the complex behaviour of ac- tivity instances is a refinement of the state transition diagram representing their simple behaviour. All state transitions possible in the simple diagram are also possible in the complex state transition diagram. The activity in- stance is initiated, and it enters the ready state before entering the running state. Finally, the activity instance terminates. However, the substates of the termination state are not represented. The simple diagram does not provide different states for successful and unsuccessful termination.
When an activity instance can be started, it enters theready state. If dur- ing the execution of a process instance certain activity instances are currently not available for execution, they can bedisabled. Activity instances that are initialized, disabled, orenabled are in the not started state. Once an activity instance isready, it can bestarted, entering therunningstate. Running activ- ities can be temporarily suspended, to be resumed later. An activity instance can terminate either successfully or in failure. Terminated activity instances can beundone, using compensation or transactional recovery techniques.
Based on the description of the behaviour of an activity instance, the ques- tion now arises on how to capture the actual behaviour of a concrete activity instance, i.e., on how to specify the trace of states and state transitions that the activity instance went through. In this section, events and event orderings are introduced to properly represent the essence of activity instances.
The basic idea of using events for representing activity instances is quite simple: each state transition of an activity instance is represented by an event.
init ready
disabled
suspended not started
not running running
closed open
succeeded
failed terminated
undone
skipped cancelled
Fig. 3.11.State transition diagram for activity instances, detailed version
These events have a temporal ordering. Based on the state transition diagram for activity instances, each activity instance can be represented by a totally ordered set of events. For the representation of activity instances by events, the simple state transition diagram shown in Figure 3.10 suffices.
Definition 3.2 LetAMbe a set of activity models andAIbe a set of activity instances. Anactivity instance i= (Ei, <i)∈AI based on an activity model I∈AM is defined by a totally ordered set of eventsEi such that either
• activity instanceiis executed, in which caseEi⊆ {ii, ei, bi, ti}, referencing the occurrence of state transitionsinitialize,enable,begin, andterminate, respectively, and an event ordering<i⊆ {(ii, ei),(ei, bi),(bi, ti)}, or
• activity instance i is skipped, in which case Ei ⊆ {ii, ei, si}, referencing the occurrence of state transitionsinitialize,enable, andskip, and an event ordering<i⊆ {(ii, si),(ii, ei),(ei, si)}.
The function model:AI 7→AM maps each activity instance to its activity
model, i.e.,model(i) =I
We define the event set of an activity instance as a subset of the complete event set,Ei ⊆ {ii, ei, bi, ti}, since during the execution of an activity instance the events occur one after the other. Therefore, any prefix of the totally ordered event set characterizes a valid state of an activity instance.
If, for instance, an activity instance i has entered the running state, it is characterized by i = (Ei, <i) such that Ei = {ii, ei, bi} and <i= {(ii, ei),(ei, bi)}. In this case,Ei ⊆ {ii, ei, bi, ti}and<i⊆ {(ii, ei),(ei, bi),(bi, ti)}, satisfying the definition.
Note that an activity instance can be skipped if it is in the init or ready state. As a result, theenable event might or might not be in the event set of a skipped activity instance.
The causal ordering of events indicated by this definition can be graphically represented by event diagrams. In event diagrams, time proceeds from left to right, and events are shown as bullets. The causal relationships of events are represented by directed arcs.
Due to the nature of event diagrams, they form directed acyclic graphs, where the nodes are events and the edges reflect causal ordering between events. An event diagram for a particular activity instance is shown in Fig- ure 3.12.
initialize enable begin terminate
init ready running terminated
(a)
initialize skip
init skipped
(b)
Fig. 3.12.Event diagram for (a) executed activity instance and (b) skipped activity instance
In the event diagram shown in part (a) of that figure, an activity instance that is properly executed is shown, while (b) shows the events of a skipped ac- tivity instance. To illustrate the relationship between state transition diagrams and event diagrams, each state transition ito the state transition diagram is associated with an event in the respective event diagram.
The activity instance starts with a state transition to the init state. This state transition is represented by aninitialize event in the event diagram. An enable state transition brings the activity instance in the ready state; this state transition is represented by anenable event. An activity instance in the ready state can be started, represented by thebegin state transition. Finally, theterminate state transition completes the activity instance.
Events are points in time, i.e., events do not take time. The time interval in which an activity instance is in one state is delimited by two events, the event representing the state transition to enter the state and the event representing
the state transition to leave the state. For example, the time interval in which the activity instance is in the running state is delimited by the begin and terminate events.
The ordering of events of multiple activity instances in the context of a business process instance is an important instrument to capturing the execu- tion semantics of business processes, as will be discussed in Chapter 4.