e who will be involved in later phases (in Fig. 1.2 called "System modelling, early phase") or can be learned by reading an appropriate, well maintained language description. The common lan- guage is used to provide a formal system model; "formal" in the sense that its inter- pretation by one who understands the language would be the same. To produce the model might require a (conceptual) translation activity. This translation might be performed by people from the very early phase activity, but it could as well be done by system engineers with modelling as a speciality. We will also assume that the language that is used is domain-specific for the type of system of concern, and that it is expressive and intuitive enough to be embraced by most people who work on the project. Otherwise, there will be resistance both by those having to do the translation, and by those who must utilize and maintain the formal model. The lifetime of the formal model will be longer than that of an informal model. It will be the basis for refinements in pre-design phases, both structural and func- 1.3 System Abstractions tional, with many people involved. The model might also survive beyond the project, which means that it might have to be rigorously maintained during the life- time of the system concept over many years. This requires some language-based tools for editing and configuration control of the model. For this reason, the model- ling language must be formal. Eventually, the early phase activity may end by a decision to move forward with designing products, i.e. software and hardware (the project could also be ended, if a feasibility study shows that it is not a good idea to proceed). In design, specific implementation-oriented tools are used, which require that the formal model becomes translated (or compiled) into the modelling (or design language) of those tools. Although this translation could be a conceptual (manual) one as well, there are obviously some extra process qualities to be gained if the model is also inter- preta