 service network specifications are sometimes first provided in later design phases, while packaging and access issues (abstract network solutions) are dealt with in earlier phases. This is contradictory to the assumptions often made in design meth- ods that the designer always first specifies all services before he deals with integra- tion issues, such as packaging and access of service logic. Service objects and abstract machines both communicate by communication events, which means service object networks need not be specified before an abstract network can be developed. A typical case, where an abstract machine net- work solution may be addressed before any service networks are developed, is in a reverse engineering project, where you start by analysing an existing process con- trol system implementation (a "legacy system"). An abstract machine is a perfect abstraction for the functions of an existing product, since an abstract machine can 7.7 Concepts and Notations in Abstract Networks comprise any set of functions, and can have interfaces that are either user-provider or peer interfaces. You can be sure that most products you find in legacy systems use peer communication relations, and that they implement neither a single service object, nor define product interfaces in terms of separate primitive services. Prod- ucts might not even define operations, as is often the case when inter-product com- munication is based on some message-oriented connectivity service. To regard a product of a legacy system as an abstract machine is then a good starting point. From there you can analyse and identify operations and service objects that are implemented by the product. In forward engineering, however, both the service and the abstract networks should always be specified, no matter in what order. The only exception is when you intend to implement a service object network (or part of it) on a platform that supports object access and operation handling (like, e.g. CORBA platforms). In that case, abstract networks are not