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.
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:
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.