 port does not accept any external event, unless the port accepts interruptions. An active state defines what the object is doing, i.e. focuses on the ongoing activity. If the object works more or less autonomously through a sequence of activities, its behaviour is best described as transitions between active states. When the port is in a reactive state, it expects new external events. A reactive state focuses on what the object will accept next. If the object needs to be guided through a sequence of activities by a sequence of external events, or if the object needs a response to a previous event before it can proceed, states are reactive states. Figure 7.48 give an example (see also Sects. 6.2.4 and 6.2.6 in the case study). user-port behaviour provider-port behaviour Fig. 7.48 Active and reactive states in service relations When the provider in a service relation is in a resource state (RS), the user is in an active state. If the user initiates an Order event, they immediately enter another active state (since no response is expected). If, however, they initiate a Request event, they enter a pending state (P), which is a reactive state. If the user simultane- ously initiates Requests to several objects, they enter a synchronization state. They stays in a synchronization state until only one Request is pending. Active states might also be needed on the provider side, if the user is to have the possibility to interrupt ongoing activities (by initiating destructive operation requests). Interrupt states (I) are then associated to active states, see Fig. 7.49. user-port behaviour provider-port behaviour Fig. 7.49 Using interrupt states to allow activities to be interrupted 7 Concepts and Notations for Process Control Systems Modelling Interrupt states are also needed to model how users handle all kinds of provider- initiated operations, see Fig. 7.50. Replnit user-port behaviour Replnit provider-port behaviour Fig. 7.50 Interrupt states are used for all kinds of provider-initiated operations Note that a behaviour d