t system relations are described for the directions indicated in Fig. 1.11 to guarantee maximum independence between system model types. sysnet model, fragment standardized (E.g. GSM) system status sysnet model responsible fragment requirements, applied system refines refDes fragment implemented (E.g. CME20 realizes system or CMS40) realDes fragment concrete Instance system iioDes System information element Fig. 1.11 The information structure for system models In order to provide an entry for each system model, there will exist one specific system IE for each system model. A system IE associates fragments of the system model by fragment relations, and the system relation elements by the IE relations refDes, realDes and iioDes respectively. The IE relations ref, real and iio between system IEs are simple references. These references constitute the backbone of the structure of system models. They can support questions to the model management system such as "which implemented systems exist for this applied system", or "from which implemented system is this concrete system instantiated". In addition to system models and system relation descriptions, other project-ori- ented attributes may be part of system IEs as well, e.g. information about system status, responsibility for the system model, system requirements and project plan- ning data. The only system IE that represents a concrete system is the lowest one. The oth- ers represent system abstractions. References between system IEs and systems are by name. To emphasize the distinction between system abstractions, it is important to select different names for the system IEs. For example, a well-known standard- ized system concept is GSM (a European standard for mobile networks). My com- 1 Introduction to Systems Modelling pany has two implemented system solutions to that standardized system, called CME20 and CMS40. 1.5.2 Fragmenting Sysnet Models Since we are dealing with complex systems where we can expect many modellers to work in parallel on a system model for a 