Domain-Specific Modeling needs multi-models

In previous articles I’ve mentioned a couple of times that a successful model-driven approach is based on a combination of MDE and DSLs. An MDE ( Model-Driven Engineering ) approach should define what models are needed, the modeling notations / languages and the processes (i.e. in what order should de models be defined and how are they transformed). So, DSLs are just part of MDE, they define how the models are notated: a DSL is a model language. Note: a model can be expressed in both a visual (DSVL) and a textual syntax.

When talking about different kind of models, people mostly think about models on different abstraction levels. For example the PIMs and PSMs of the Model-Driven Architecture ( MDA ). In such cases the idea is to move from the problem to the solution space by refining high level models into lower levels models, until an executable model (can be expressed in a programming language) is created. I like to use the term refining instead of transforming, because in most cases additional information is needed (e.g. a business process model expressed in BPMN, modeled from a user perspective, can’t be transformed into an executable model without adding information).

However, to accurately abstract complex systems one monolithic model in one modeling language isn’t sufficient. Besides the abstract/concrete dimension sketched above, we need the concept of multi-models.


Large and complex systems can be accurately abstracted by the use of multiple DSLs. In complex projects multiple DSLs are usually necessary in order to cope with different concerns. In other terms: multiple domain-specific models (DSMs), specified in different DSLs are needed to accurately abstract complex systems. Warmer and Kleppe [Warmer and Kleppe, 2006] also advocate the use of many small, loosely-coupled models, because they are easier to handle and improve readability in comparison with a single, monolithic model.

In literature multi-modeling is defined as the act of combining diverse models, which can be done in two ways [Brooks et al., 2008]:

  • Hierarchical multi-modeling: hierarchical compositions of distinct modeling styles are combined to take advantage of the unique capabilities and expressiveness of the distinct modeling styles.
  • Multi-view modeling: distinct and separate models of the same system are constructed to model different aspects of the system.

Multi-model challenges

If I refer to multi-modeling I mean multi-view modeling as defined above. While in multi-modeling a complete system is described using multiple interdependent DSMs, the integration of these DSMs is needed to synthesize the described system. This poses several research challenges [Denton et al., 2008]:

  • Capturing multi-model interdependencies: as the number of models, the complexity of their interactions, and/or the size of the system being modeled increases, it becomes extremely difficult to manually keep track of the interdependencies.
  • Maintaining multi-model consistency: to reach multi-model consistency, model changes must be propagated in order with respect to their interdependencies. While multiple modelers must be allowed to change their models simultaneously, the propagation of changes must be performed across compatible versions of the various models.
  • Semantic precision of inter-model data exchange: while the different models in a multi-model are interdependent it is necessary that they share or exchange data. The semantics of the data must be precisely known and understood by all models participating in the exchange. This requires that the models either be described in languages derived from the same metamodel, or that experts specify the relationships between elements of disparate metamodels.

Solutions in literature

In literature, several solutions to the problem of multi-model integration have been proposed:

Name-based references. Warmer and Kleppe [Warmer and Kleppe, 2008] suggest to connect models by referencing model elements by name from within other models. The drawback of this solution is that all semantics are delegated to the code generator, i.e. the actual integration happens at code level. On the model level it isn’t visible how two model elements are semantically related.

Weaving models. A model weaver allows to define and visualize correspondendences between elements in different models using an extensible weaving metamodel. The references between model elements are kept outside the models. This approach has two disadvantages, first the weaving model can only express the semantics of the links, it does not actually define the meaning of the corresponding language constructs. Second, a model weaver usually connect pairs of models and thus is not suited for an integration of a large number of DSLs [Brauer and Lochmann, 2007].

Model mappings. Mappings, or transformations, between models can be seen as models themselves, which describe the relationship between elements from the source and target model and allow to validate inter-model consistency constraints. However, a mapping specification expresses semantics of different DSL elements only implicitly and does not assign an explicit meaning to each language construct [Brauer and Lochmann, 2007].

Common upper ontology. Bruer and Lochmann [Brauer and Lochmann, 2007] stipulate that language integration must be based on ontological foundations, guided by a common upper ontology for software modeling languages. This allows to reuse fundamental relationships, constraints, and axioms when integrating a new DSL. The core idea of their approach is to address the insufficiencies of the previously mentioned approaches by using a semantic model connector, see Figure 1. Only the elements required for a semantic connection between participating models are mapped to ontology in the semantic connector. In other words: the interfaces of the different models are connected by mapping the elements of the metamodel (describing the DSL in which the model is expressed) to an ontology.

Integrating multiple DSLs using a semantic connector

As we see, current scientific research is focusing on integrating Domain-Specific Models (DSMs) specified in different DSLs on an ontological level. If we can tackle that problem adding new DSLs to a modeling space becomes much easier. However, just integrating DSMs on a syntactical level as proposed in the first approach (name-based references) does already a great job in making life a lot easier. With good tool support, a system can be successfully modeled using multiple DSMs specified in different DSLs, thereby gaining all the advantages of Domain-Specific Languages.

Structuring the modeling space

Besides researching how to integrate multiple DSMs defined in different DSLs, it is also important to structure the modeling space. As stated in a previous article this can be done using multiple modeling dimensions, for example the ones shown in Table 1.

DimensionPossible values
Abstract / concreteCIM, PIM, PSM
Subject areasOrder entry, customer portal, back-end administration, …
AspectsData, presentation, security, business rules, workflows, …
StakeholdersDomain expert, programmer

Table 1 – Example dimensions for an MDE project

Examples of models for the dimensions presented in Table 1 are:

  • A Computation Independent Model (CIM) of the workflows of
    the order entry part of the software artifact aimed at a domain expert.
  • A
    Platform Independent Model (PIM) of the data of the back-end
    administration part of the software artifact aimed at a domain expert.
  • A Platform Specific Model (PSM) of the security of the customer portal part of the software artifact aimed at a programmer.

The various dimensions at an intersection play an important role in the
choice for a modeling language for that particular model. By example,
the modeling language is influenced by the subject area, the
stakeholders and the level of abstraction. In this way languages can be true DSLs, i.e. they are small, specific, and tailored to their purpose users.

Looking at the example dimensions in Table 1 we see that the first dimension (abstract / concrete) is the one in which refinements and transformations take place. The other dimensions in this case are used to structure the modeling space at each of these abstraction levels. So, at each abstraction level (for example: CIM, PIM and PSM) we have a multi-model, consisting of models for each subject area and within a subject area a model for each system aspect.


Model-Driven Engineering needs:

  • A process to come from a model of the problem space (i.e. a business model) to a model of the solution space (i.e. an executable model of a software system). Such a process usually consists of several steps with models at different abstraction levels. Higher level models are refined until the executable model level has been reached. We can call this part of MDE the abstract-concrete dimension of the modeling space.
  • Multi-models. In real-life we have to deal with business problems leading to large and complex software systems. As explained in this article such systems need multiple Domain-Specific Models specified in different Domain-Specific Languages to reach the right level of abstraction. Each model described in the previous bullet point in practice is a multi-model. 
  • Domain-Specific Languages. For each model a notation is needed as much as possible tailored to the domain expert who’s going to specify that model. We’ve explained (in this and previous articles) how the modeling space can be structured to determine the needed DSLs.


J. B. Warmer and A. G. Kleppe. Building a flexible software factory using partial domain specific models. In Sixth OOPSLA Workshop onDomain-Specific Modeling (DSM’06), Portland, Oregon, USA, pages 15-22, Jyvaskyla, October 2006. University of Jyvaskyla.

Christopher Brooks, Thomas Huining Feng, Edward A. Lee, and Reinhard von Hanxleden. Multimodeling: A preliminary case study. Technical Report UCB/EECS-2008-7, EECS Department, University of California, Berkeley, Jan 2008.

Trip Denton, Edward Jones, Srini Srinivasan, Ken Owens, and Richard W. Buskens. Naomi – an experimental platform for multi-modeling. In Krzysztof Czarnecki, Ileana Ober, Jean-Michel Bruel, Axel Uhl, and Markus Völter, editors, Model Driven Engineering Languages and Systems, 11th International Conference, MoDELS 2008, Toulouse, France, September 28 – October 3, 2008. Proceedings, volume 5301 of Lecture Notes in Computer Science, pages 143-157. Springer, 2008.

Matthias Bräuer and Henrik Lochmann. Towards semantic integration of multiple domain-specific languages using ontological foundations. In Fourth International Workshop on Software Language Engineering, Nashville, USA, Grenoble, France, October 2007.

5 Comments Added

Join Discussion
  1. Steven Kelly November 4, 2008 | Reply

    The section on multi-modeling strategies misses the simplest and most powerful – which is also the most mature and best proven in practical use. Take a look at how MetaEdit+ does it: a metamodel element can be reused or referenced in several metamodels. Similarly, its instances can be reused or referenced across several models, either of the same or different metamodels. This solves (or avoids) the problems of update propagation, versioning, scalability and visibility of the approaches you mention.
    If an element in model Y should be the same as an element A in model X, you simply reuse A in Y. Since both X and Y point to A, any changes to A through either of them will be visible in both. Of course, sometimes you explicitly want to add a level of indirection between two elements: they are the same now, but maybe later you want to retarget one to point somewhere else. In this case you have an element B in model Y, which references element A now, but can later be changed to point somewhere else. Again, changes to A are of course visible in both X and Y, since there’s still only the one A.
    MetaEdit+ also supports the other model integration strategies that you mention, if one of them suits your needs better in a particular case. I’m always surprised though that other tools haven’t figured out the MetaEdit+ way – especially since it’s been there since 1995 and published in several papers back then. It always seemed so obvious to us that maybe we haven’t shouted enough about it since.

  2. Johan den Haan November 4, 2008 | Reply

    Hi Steven,
    Thanks for your reaction. The approach you mention is of course the most simple and practical one. We at Mendix also support this strategy in our tooling. However, with distributed editing of the models by multiple people, this approach also has drawbacks.
    With the indirection you mention I think this approach is the same as the name-base references mentioned in the article.

  3. Steven Kelly November 5, 2008 | Reply

    Hi Johan [somehow friendlier than “@Johan”!],
    Sure, you can’t easily do true reuse or reference if you have separate XML files per model and multiple modelers. MetaEdit+ has a multi-user repository, so there’s no problem.
    The indirection I mention (“element B in model Y references element A”) is done by direct reference, not name-based reference. Of course name-based references are possible too, and fine if that’s what you want, but direct reference is generally simpler and easier. You can see the difference if you change the name of A in model X: with name-based reference, model Y breaks as its B no longer points to anything in model X; with direct reference, model Y’s B still points to A (whose name change is also visible in Y).

  4. Rui Curado January 14, 2009 | Reply

    You may want to check a paper written by Anders Hessellund regarding domain-specific multimodeling. I’ve read part of it and it looks very good.
    Check it at the Model Driven Software Network you are now member:

  5. Johan den Haan January 14, 2009 | Reply

    Hi Rui,
    Thanks for the note. I’ve already seen part of Anders work at Models’08 (see, so I’m definitely going to read his Phd thesis.

Leave a Reply