shown. Therefore, this technique can only show a partial behaviour. The same can be said about sequence diagrams. Even the simple behaviour of the agent, depicted as a state diagram in Fig. 7.39, is not easily represented by a sequence diagram. For example, the sequence diagram says that the agent expects the response on Req3 to come before the response on Req2, while the state diagram shows that the agent accepts responses in any order. Sequence diagrams also tend to be voluminous (for realistic objects: ten to hundreds of pages, interconnected by page references). Though we are not con- cerned with the waste of paper or memory space, the fact that a diagram extends over many pages makes behaviour difficult to understand. On the other hand, state diagrams can be constructed as a hierarchy of diagrams by using some type of EFSM technique (see sect. 7.5.2), which considerably improves intelligibility. Since sequence diagrams are not state oriented, they are ambiguous regarding in which state a depicted event is accepted. Since behaviour specification in AML relies completely on the specification of states, sequence diagrams cannot be used as design specifications. Thus, only the state diagram technique is supported by AML notations. Sequence diagrams can always be generated from a service net- work by a suitable AML tool. Note, however, that the tool user must interact with the tool to define states that will be represented in the sequence diagram. The behaviour of a service object depends on the behaviour that is associated with all primitive services on which the object depends. To describe primitive serv- ice behaviour is therefore the key to describing the behaviour of a service network. Figure 7.40 exemplifies this. partial partial Object instances instantiate partial partial Object types usedForDescribing BehaviourOf describes Behaviour Primitive Description refers Service for an S3 Specification provider port for S3 Fig. 7.40 All behaviours are based on primitive services At the top is a small service netwo