as they are in most other specification languages). The basic element that is modeled in AMLs is an abstract machine (AM). Abstract machines are representations of resident functional elements in a system, i.e., candidates for being implementation elements in a system (e.g., a SW unit or a system of such units). The model below shows an abstract machine system. Peer relation: AM1 and AM3 are both providers and users in the relation User-provider relation: AM3 is the user, AM2 the provider in the relation Since every AM is a state machine, the depicted system as a whole is a state machine as well. The model tells which machines can communicate with each other. The relation between two machines is described by an abstract protocol in terms of event interactions. Both user-provider and peer relations may exist (more about that later). As mentioned, the basic invocation element is the event, which is an instance of an ASP. An ASP describes a type of an asynchronous invocation, which means that the communication between two AMs can be described as a sequence of events, generated by one AM and detected by the other (since these invocations are not messages, we talk about "generating" and "detecting" instead of "sending" and "receiving"). The basic difference between a message type and an ASP is that the specifica- tion of a message type describes just a structured data type, but says nothing about how the receiver will react upon message reception (normally described separately in (often) lengthy natural-language descriptions in protocol specification). The ASP on the other hand tells what the detector is supposed to do by defining an operation and adding parameter values that are relevant to the referred operation. Thus, ASP communication is operation-oriented. The syntactical description of an ASP in AMLs follows practices in most methods. For example, if one AM (AM1, see the previous figure) wants the other (AM2) to "create a connection" and return a confirmation of that action, AM1 will generate a connectRequest(ad