n fails. The user must take some action SO that the state returns to some known state. In the diagram it is assumed that the operation recover returns the service state to A. 7.4 Elements of Interactions op1 is atomic: op1 is notAtomic: op1Req op1Req op1 pending op1 pending op1Ref op1 Cnf op1Cnf op1Ref unknown op1 done op1 done recoverCnf recoverReq (recoverPending) Fig. 7.34 The ATOMIC property: how atomic and notAtomic operations affect state diagrams The DESTR property defines whether an operation may be destructive on a pre- vious operation that is not yet responded to. A typical example is when an object requests a connection and then requests a disconnect before the previous request is responded to. If a destructive operation is initiated, the provider should try to inhibit or undo the previous operation. Figure 7.35 shows how the DESTR prop- erty affects state diagrams for a provider port (compare to Fig. 6.17). For an object to be able to handle destructive properties, it must handle interrupts. To use destructive operations is only meaningful if the operation that is interrupted is a modifier, notAtomic and asynch. disconnect is destruct: disconnect is notDestr: notConnected notConnected connectReq connectReq disconnectOrd interupt state connectCnf(...) activity state Connected pre: noProblem iie: interrupt connectCnf(...) disconnectOrd Connected Fig. 7.35 The DESTR property: how destruct and notDestr operations affect state diagrams The purpose of declaring these properties is to support behaviour specification and to define requirements on operation handling (the OPH function) in the abstract machines in which service objects are allocated. Properties are declared under the heading PROPERTIES in operation specifications, see Fig. 7.36, which shows an extended version of the operation specification from Fig. 7.27. Only property values that are not default values must be declared. 7 Concepts and Notations for Process Control Systems Modelling Operation specification for callnfo: OPERATION callnfo PROPERT