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 described. In addition, the actual work conducted during business processes has to be characterized, i.e., 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.
An activity model describes a set of similar activity instances, analogously to a process model describing a set of process instances with the same structure. 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 insurance
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. The states
that an activity instance adopts during its lifetime are described as follows:
when it is created it enters the init state. By the enabled 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, the terminate state transition transfers it to the terminated state. When an activity instance is in the terminated or the
skipped state, then it is closed.
The state transition diagram representing the complex behaviour of activity 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 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 the ready state. If during the execution of a process instance certain activity instances are currently not available for execution, they can be disabled. Activity instances that are initialized, disabled, or enabled are in the not started state. Once an activity instance is ready, it can be started, entering the running 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, 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.
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.
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.
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 activity 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 an initialize event in the event diagram. An enable state transition brings the activity instance in the ready state; this state transition is represented by an enable event. An activity instance in the ready state can be started, represented by the begin state transition. Finally, the terminate 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.
No comments:
Post a Comment