Business functions provide a high-level, coarse-grained representation of the work conducted by enterprises. Activities can be found in the leaves of the functional decomposition. This section investigates how activities can be de- scribed. In addition, the actual work conducted during business processes has to be characterized, that is, activity instances have to be characterized.
Note that activity models represent the M1 layer of the Meta Object Facility, while the activity instance layer corresponds to M0. Figure3.8shows the rela- tionships between business functions, activity models, and activity instances.
Notice that there are activity instances for case (Smith, 123212) for all three activity models, even though either a simple check or an advanced check is required. This aspect will be discussed shortly.
Fig. 3.8. 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- 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 respective software system of the insurance company. When the company receives the claim, a process instance is started. Within this process instance, the activity instance Enter- Claim(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 for activity instances is shown in Figure3.9. The states that an activity instance adopts during its lifetime are
Fig. 3.9.State transition diagram for activity instances
described as follows. When it is created it enters the initstate; by theenable state transition the activity instance can enter the ready 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, theterminate state transition transfers it to the terminated 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.9 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 Figure3.10. 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 instance is initiated, and it enters theready state before entering therunning state. If it turns out that an activity instance that is not started is not required then it enters the skipped state.
Fig. 3.10. State transition diagram for activity instances, detailed version
But the detailed state transition diagram shown in Figure 3.10 allows more complex behaviour of activity instances. When an activity instance can be activated, it enters the ready state. If during the execution of a process instance certain activity instances are currently not available for execution, they can bedisabled. Activity instances that are in theinit,disabled, orready state are also in thenot started state. Once an activity instance isready, it can be started, entering therunning state. Running activities can be temporarily suspended, to be resumed later. An activity instance can terminate either successfully or in failure. Terminated activity instances can be undone, using compensation or transactional recovery techniques.
Based on the description of the behaviour of an activity instance, the question now arises on how to capture the actual behaviour of a concrete activity instance, that is, 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.
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.9suffices.
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 →AM maps each activity instance to its activity
model, that is, 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- ure3.11.
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 in 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
Fig. 3.11.Event diagram for (a) executed activity instance and (b) skipped activity instance
ready state can be started, represented by the begin state transition. Finally, theterminate state transition completes the activity instance.
Events are points in time, that is, 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.