s of events, we can conclude that there must exist service objects that perform operations and service objects that request operations. Service objects both perform operations and request operations from other service objects. Furthermore, there is a difference between an operation and the events that are used to trigger an operation and report its outcome. Operations are functions that must be implemented and allocated in service objects. Events are means for com- munication. Also, for a particular operation, there may exist more than one event to specify (in this case we used two: a Request event and a Confirm event). The set of event types that are associated with a particular operation belong to the specifica- tion of the operation, since it defines the dialogue between service objects for that particular operation. 2.3 Architectural Principles The following scenario explains the service object concept in SM&AML: assume that I had to perform step 4 in a reverse engineering process on an imple- mented legacy system that uses some form of asynchronous event-communication. I would then proceed as follows: First, I would perform disintegration steps 2-3 as follows: I would regard the components of the legacy system as logical nodes. I would assume that each component contained at least one abstract machine. By analysing the interac- tions between components, I would identify all parameters that act as discrimi- nation identifiers (Did), from which I conclude how many abstract machines exist in each component. I would then identify the communication events between those abstract machines. When the analysis was completed, I would have identified a number of abstract protocols. For each abstract protocol, I would group events that belong together, in the sense that they refer the same operation. I would divide the set of operations identified by this process into subsets SO that all operations in a subset were performed by one side in the abstract protocol. I would associate each subset to a service object of the ab