rmation management problem (to the left in Fig. 1.15). However, it has limitations: the DBMS will only manage the IEs and the IE relations fragment and con, i.e. not the communication relations (comm) in the system, which are all hidden inside the fragments. From a model designer and model user point of view, a model management sys- tem approach (the MMS to the right in Fig. 1.15) seems much more attractive, since, obviously, by fragmenting the system model in a product structure, it becomes difficult to understand the system as whole. Unless there is an agreed- upon modelling language, the model management system must understand the communication relations in the model. When all the possible kinds of systems and modelling languages are considered, this complicates things and increases the costs for information management. This is (more or less) the situation for the domain of software systems, as mentioned earlier, but is not expected for domain-specific sys- items. The solution for these systems is instead to develop a generic tool that can be used as a compiler-compiler (or "meta-tool") for creating domain-specific model management tools. 1 Introduction to Systems Modelling Another reason for preference of the product structure management approach in the industry is that it originates from the time when computers were not used for information management. Historically, system model fragments were handled manually in the form of documents. To organize documents in a hierarchical struc- ture was then the most efficient way to handle the information. When companies started to use computers for information management (about 25 years ago), it was quite natural to just computerize an existing paradigm. Computerized product structure management systems are therefore well established and understood in the industry, and represent large investments in both knowledge and in mature tools and processes (which has a great value in itself). They also serve their purpose quite well in special in systems provisioning activities