Domain-specific modeling languages (DSMLs) are promising clear advantages over GPML. The diagram below shows small excerpts of diagrams that represent models of IT infrastructures. At first sight, the difference between the diagram on the left (DSML) and the diagram on the right (GPML) may seem to be limited to the notation. However, that is not the case. The DSML offers domain-specific concepts, that is, domain-specific knowledge. The GPML offers not much more than the knowledge that there are objects that can be classified.
Therefore, DSML promise to promote modelling productivity and model integrity. However, the design of a DSML is facing a substantial design conflict: the more specific a DSML is, the better it will be suited for a particular domain. However, at the same time, it will be difficult to reuse a very specific DSML in another domain. Therefore, its economies of scale would be unsatisfactory. This conflict between range of reuse and productivity gain cannot be relaxed in the traditional paradigm. Multi-level DSMLs allow for reusing more general DSMLs, thus contributing to economies of scale, and at the same time, they may include very specific DSMLs that boost productivity in a certain domain.
Common Representation of Models and Code
Unfortunately, the generation of software from conceptual models will usually create a challenge. In many cases, models are not sufficient to generate a complete system. Therefore, the generated code has to be extended manually. If the model gets changed afterwards, the re-generation of code is likely to corrupt the existing manual extensions. There are sophisticated approaches to synchronize code and models. However, in most cases they are not entirely satisfactory. Instead of focusing on more advanced synchronization, it makes sense to ask why there is need to generate code from models. The need to synchronize code and models is mainly caused by the fact that current programming language allow only for objects on M1 to have a state. Therefore, model editors need to represent classes (or meta-classes) respectively as objects on M1, which cannot be further instantiated. Multi-level language engineering allows for representing models in a tool at the level where they conceptually belong. For example, a class on M1 is represented as a class (which is an object at the same time) on M1. Hence, there is no need to separate the representation of code from the representation of models. Therefore, it is possible to either modify a system on the preferred level of abstraction, code or model, and the corresponding counterpart will be updated implicitly.