d up. Note that an abstract object is always a provider and may also be a user of other objects. It can never, however, be a peer (only abstract machines can). Note also the difference between a provider interface (defines which operations the object can provide) and a user interface (defines which operations are actually used by the using object). Thus, the relations in an object structure are defined by user interfaces. From a using AM's point of view, an AO is something that is only visible by an object relation offered by another AM. This allows us to define a whole object structure as a network-wide AO (using the general substructure relation), as depicted below. Substructure relation The fact that an AO definition is not necessarily confined to a function in a sin- gle node is one of the features of AOs that distinguishes this concept from object- oriented approaches in other modeling and design languages. Abstract machine systems and object structures are the model types we use for behavior descriptions. Both AMs and AOs can be described as state machines, and SO can the system and the structure as a whole. An advantage with defining the functionality of AMs in terms of AOs is that the behavior description of an AM becomes simpler. This is because states that relate to operations on AOs are sepa- rated from states that relate to operations that create and delete AOs. The behavior description of an AM thereby becomes divided into one description that describes its object handling, and a number of (often rather simple) descriptions of the behav- ior of the object types that the AM offers. The behavior of an AO depends on how it reacts on events in all its interfaces. It therefore necessary, for each AO, to produce an interface specification for its provider interface. This specification will comprise all its operation specifica- tions, and, in addition, a state machine description for that interface (diagram or tabular). The behavior of an AO that depends on other AOs is then constructed by combining the sta