rvice relation are invisible to the other object. Activities can therefore be observed only indirectly (through result events). In case no result event is generated, the other object can- not know anything about what activity has been performed. To annotate a transi- tion with an activity statement is therefore optional, and makes sense only in case the diagram is going to be used for simulation (in which case, the annota- tion should refer some executable code). The behaviour described by the diagram depends on which operations are defined for S1 (the three operations servREQ, userServRelORD and nwServReIC_REP are assumed), and on the state definitions that are part of the state space defined by the service resource model (TNW in this case). The states in the provider state diagram in Fig. 6.16 are reactive states of type EFSM states. EFSM states are sets of resource states. All reactive states represent a situation where the object is waiting for some- thing to happen, e.g. waiting for the other object to respond to a previous event, or waiting for a service request from the other object. That is, from the other object's point of view, the object is not active. A resource state is a reactive state that can be described as a unique instance of the service resource model. Very few state symbols in a realistic state diagram represent a unique resource state. Most state symbols are extended finite state machine states, EFSM states. Defining EFSM states is almost always necessary, in order to keep the 6.2 A Service Network Modelling Case number of state symbols in a state diagram down to a reasonable number. While a resource state defines one specific state out of all possible states that can be deduced from the service resource model (here the TNW), an EFSM state defines a subset of states in this state space. Normally, a particular transition can be allowed in many resource states, as e.g. the transition that is triggered by the servReq(...) in the state diagram for the provider side in Fig. 6.16. This tran- sitio