tem con- figuration, as a result of commands from system operators. The former is often referred to as the "traffic system", the latter as the "telecommunication manage- ment system". Typical levels of control (i.e. "echelons") in the traffic system are: on the top level, the system controls users service access. On the next lower level, the sys- tem controls the establishment of (often temporary) end-to-end connectivity for a certain type of information (often called a "teleservice", e.g. transfer of voice signals). On an even lower level, the system controls the establishment of bit- pipes (channels that are insensitive to the type of information). On the lowest level, it controls the resources of the system (switches, trunks and other types of devices), that take part in providing bit-pipe and teleservice connectivity. A similar control structure exists for the telecommunication management sys- Thus, the first major piece in the puzzle was found: One view of the general sys- tems model was the processing system paradigm. This view could easily be extended to comprise many other systems domains as well, as long as the utility aspect was clearly separated from the control aspect. For example, if we compare a telecom system with a fabric dyeing system (described in a case study in Selic et al. (1994)), construction of suitable process control systems requires the same type of competence and design methods, while the utility provided, and thereby the design of the resource systems, requires completely different competencies. The former provides teleservice connectivity using resources like switches, transmission lines and transcoders, while the latter provides dyed fabric using resources like dyeing tanks, fabrics, dyeing solutions and heat. Preface The 1980s were also when object orientation in software engineering became the most popular paradigm. Researchers, who were more interested in systems engineering than software engineering also saw its potential for modelling func- tional structures on the system level