sting service networks. The last case implies that existing state diagrams for ports and objects must be modified. Modifications of this kind can comprise anything from introducing sev- eral new operations, change of operation class (e.g. from an unconfirmed to a con- firmed operation, or from a user-initiated to a provider-initiated operation), change of the parameter set of an ASP, or just change of the value range of some parameter in an ASP. It must therefore be possible to modify state diagrams in a controlled way. When the initial state diagram is constructed, the designer knows in which states it is safe to add new transitions and which states can handle new functional requirements. This knowledge should be specified by classifying those states as extensions or feature states. The importance of this aspect of system management also motivates a special symbol for feature states. Feature states should always be resource states, since allowing features to be handled in transient states (i.e. active states and pending states) is an unnecessary complication to the behaviour of the system. It is also quite common that features imply that new resources are added to the resource system, and that they are in some way related to states of existing resources. This implies that a feature is made available to the user by a transition from an existing resource state to an added resource state. Figure 7.52 gives an example of how functional extensions may be modelled by using feature states. sriA-suspendReq() T-setTimeOrd(T2) sriA-suspendCnf(ref) AnotInCall AandEinCall Asuspended The Suspension service: Based on service: BasicCall Initiated in state: AandElnCall sriA-resumeOrd(ref) Terminated in states: AandEInCall or AnotInCall New operations are: suspendREQ and resumeOrd New state is: Asuspended T-timeOutRepCnf() New transitions are: AandElnCall-Asuspended, sriE-servRelRepCnf(crE,cause) Asuspended-AandEInCall, cspc-discOrd(con15) Asuspended-AnotinCall Fig. 7.52 Modifications to a state diagram are done in feature state