comprises a query (on the service resource model) and the parameter field of the 7.4 Elements of Interactions Confirm event contains an answer. For complex resource models, a suitable way to implement selector operations is therefore to use a query language, like SQL (Structured Query Language). To be able to use the operation concept for all types of operations, we add the operation type transformer. A transformer operation does not operate in a state- context, i.e. it does not refer to any service resource model. The Request event delivers some data in the parameter field that are analysed and returned in the Con- firm event. Typical transformer operations are text formatters, parsers, sorters, spelling checkers and data compressors. Typical transformer objects in telecom systems are routing analysers and encoders. Figure 7.32 visualizes how the EFFECT property affects state diagrams, in this case for a provider port. modifier: initiator: selector: sellWatchRef callnfoRef(...) callnfoCnf(...) any service state (watchExists) any service sellWatchReq chStateOrd(state) state act: succeeded sellWatchReq post: watchRemoved defined callnfoReq(time) callnfoReg(time) act: failed sellWatchCnf state pre: noWatch pre: watchExists noWatch Fig. 7.32 The EFFECT property: how modifier, initiator and selector operations affect state dia- grams The SYNCH property defines whether a user must wait for the response to a previous operation request before he can request another from the same object. If so, the operation is synchronous, otherwise it is asynchronous. Obviously, only operation classes that provide responses can be synchronous (all other classes are asynchronous by definition). Figure 7.33 shows how the SYNC property affects state diagrams, in this case for a user port. In the asynchronous case, the user requests the operations op1 and op2 simultaneously. In the synchronous case, they must wait for the response to op1Req, before they can initiate op2Req. The dia- gram also identifies a new type of state, called synchron