The Processing Object Lifecycle

As already stated in section 1.1.1, the state of an object is defined by the value of its attributes at a moment in time. The sequence of states on an object define its lifecycle. Nevertheless, not all variations on attribute values produce an important transition in the lifecycle. That is why we talk about main states or supra states and sub-states.

A Processing object lifecycle is made up of the following main states: Unconfigured, Ready, and Running (see figure 4.4). While in the Unconfigured state the Processing object is waiting to be configured; in the Ready state it can be reconfigured or started; in the Running state, once the Processing object has been configured and started, the actual process can be executed; finally the Processing object can be stopped in order to start the cycle again.

Figure 4.4: DSPOOM Processing state diagram

The messages that can be sent to a Processing object in order to change its state are: Configure, Start, Do and Stop. Any of these operations has a generic part and a concrete part that is coupled to the concrete Processing class. The generic part of the operation is in charge of controlling the state transitions and life life cycle invariants. It is reasonable to think that the use of the Template Method design pattern (see [Gamma et al., 1995]) will offer an optimum solution to this situation, implementing the commonalities in the abstract Processing class and delegating any particular issues to the concrete classes. We will now see how all these state transitions affect a general Processing object.

The Processing object can only respond to the Configure message if it is in the Unconfigured or Ready states. In any case if the configuration that is passed is well-formed and valid the Processing object will enter the Ready state, else it will stay or go to the Unconfigured state. In this configuration process different internal operations may take place:

1. Initialization of the configuration variables, member variables that contain parameters that are not supposed to change during the execution phase.
2. Initialization of internal tables that need to be allocated taking into account some configuration parameter such as the size.

The Start message will only be acknowledged if the object is in the Ready state and will produce a transition to the Running state. In this transition, two activities are to take place:

1. Asserting that the Configuration process has taken place and left the Processing object in a valid concrete Ready state.
2. Initialization of execution variables. Execution member variables are defined as those that are bound to change during execution and they include items such as internal counters, timers or memories. These execution variables also include input and output controls.

A Processing object can only respond to the Do message and therefore process when it is in the Running state. During this phase the Processing object can only receive this message and any other communication must be done through the control mechanism. In this state we can identify two other sub-states: Idle and Processing. In the Processing state the object is actually performing the computations as a response to a Do call while in the Idle state the object has already handed control to the Flow Control and is waiting to be called again.

Finally, the Stop operation will make a Running processing object enter the Configured state. In this transition, memory can be deallocated and execution variables reset.

It is interesting to note that this lifecycle is a variation/enhancement of the lifecycle of a process in the Simula language. In [Dahl and Nygaard, 1966] it was stated that a process could be in one of four possible states: (1) active, (2) suspended (3) passive and (4) terminated. On the other hand, in section 2.2 we commented how Ptolemy, as many other frameworks, distinguishes three execution phases: set-up, run and wrap-up. Note that in our case these three phases are also explicit, with the Configure operation making most of the set-up operations, the Start operation finishing up the set-up and making the transition to the run phase where the Do operation is called, and the Stop operation in charge of the wrap-up.