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.

Multi-modeling

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.

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.

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.

Conclusion

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. megaplanet.org.