regular system design process, thus the models captured separately in the different DSMLs need to be kept consistent all the time.
To provide a high degree of coordination between different DSMLs, language engineering frame-works (like Tiger [EEHT05], GME with GReAT [KASS03], VMTS [LLMC04], EuGENia [KRA+10, KPP08]) are complemented withmodel transformationfeatures to map models of a source DSML into a target DSML in a consistent way. However, a consistent, incremental and bidirectional synchro-nization between different modeling languages is still a challenging problem.
In this work, we propose a novel approach formulti-domain modeling and integration. First, we propose (in Section 3.3.2) light-weight techniques for integrating multiple domain-specific model-ing languages into a consistent system model in addition to traditional model transformation based domain integration. Using these techniques, integration of DSMLs can be specified very easily com-pared with designing a complex model transformation for the same problem in many cases.
Our approach supports the multi-domain integration of DSMLs in the following ways: (i) sub-typingbetween metamodel elements of two DSMLs, which is an extension of the UML profiling mechanism for an arbitrary host DSML (not only UML); (ii)multiple instantiation (typing)where a model element may be typed over multiple domain metamodels; and (iii) traditionalmodel transfor-mationsas provided by the Viatra2 transformation framework. For all these solutions, the models of the different DSMLs can be edited separately by the domain engineers, however, the underlying system model is kept synchronized. While these different techniques have been proposed previously in a UML context, generalizing them in a DSM context is the main contribution of this work.
Our techniques have been implemented in the ViatraDSM framework (Section 3.4), built on top of the metamodeling and model transformations of Viatra2.
Domain integration Complex systems are usually modeled from different perspectives, for exam-ple, UML offers several diagram types for software design, e.g. class and deployment diagrams for structural modeling, activity and sequence diagrams for dynamic behaviour etc. Thus the separa-tion of concerns is essential in maintaining the clarity and accuracy of complex models. The various modeling perspectives should be linked together in the underlying system model in a consistent way.
This means, in simple terms, that if something is changed in one of the modeling domains (e.g. a method name is changed in a UML class diagram), this change has to be automatically reflected in all other modeling domains (e.g. by changing the name in all sequence diagrams as well). Thus,domain integrationmeans retaining the advantages offered by various domain-specific tools, and providing automated support for generating a global and coherent system model from small domain-specific submodels1.
The traditional approach to domain integration is to use separate domain-specific tools for var-ious source domains and importtheir output into the target domain (see Section 3.3.2.1). This is generally unidirectional, i.e. if a change in the target domain should be reflected in the source do-main, the only option is to manually figure out what needs to be changed in the source domain and edit the models manually, or to write a second transformation.
These off-line (import/export based) transformational integration approaches can be slow, es-pecially for large models, even if automated tool support is available. A lightweight solution is to integrate all (meta)models into a single language, and use stereotype annotation (tagging) to assign model elements to various domains (Figure 3.6). This approach is used by the profiling mechanism of
1The problem of domain integration is frequently referred to as view integration, especially, in the UML terminology.
By our terminology of domain integration, we would like to emphasize that the same problem exists in DSM frameworks as well, although no direct support is provided in most of general purpose DSM tools.
3.3. DOMAIN INTEGRATION TECHNIQUES 41
UML. Whilst some tool support exists for defining and applying UML profiles, this technique lacks certain advantages offered by flexible domain-specific editors as it is remarkably easy to construct ill-formed models with inappropriate stereotypes.
<<A>>
<<A,B>> <<B>>
Editor for Domain A Editor for Domain B
Multi-domain Editor for Domains A,B
Figure 3.6: Integrated multi-domain modeling
However, the metamodels in standard UML Profiles already incorporate deep knowledge of a do-main gathered from top dodo-main experts, which is required for constructing editors and languages for that domain. Unfortunately, these existing metamodels are frequently ignored when constructing a new language in a DSM framework. In our upcoming example, we demonstrate that the metamodels of UML profiles are highly reusable when constructing domain-specific languages.
3.3.2 Overview of domain integration techniques
We discuss three techniques for multi-domain modeling integration based on (i)subtypingbetween metamodel elements of two languages, which is an extension of the UML profiling mechanism for arbitrary host languages (and not only UML); (ii) multiple instantiation (typing)where a model el-ement may be typed over multiple domain metamodels; and (iii) traditionalmodel transformations. In all these cases, the models of the different DSMLs can be constructed separately by the domain engineers, however, the underlying system model is kept integrated automatically by appropriate mechanisms.
3.3.2.1 Transformation-based integration
Transformation-based domain integration (Figure 3.7) means that models from different domains are mapped to each other by model transformation techniques (see Chapter 4 for more details on this technology). In the general case, such a transformation takes a valid model of the source domain, and produces its counterpart in the target domain. The equivalence of the source and target models are ideally ensured by the (formal) verification of the transformation.
The transformation-based integration technique is the most generic approach to multi-domain modeling. Moreover, bidirectional translations are also possible in certain cases. However, for com-plex models, regenerating the whole target model after a small change in the source model can sig-nificantly slow down the design. Therefore, the main challenge of this approach is to provide support forincrementaltransformations which are more efficient by avoiding the recalculation of previously known and valid facts (e.g. avoiding the regeneration of those parts of the target model which are not
DSM Core metamodel
Domain A metamodel Domain B metamodel
Domain A models
Domain B models XForm
Domain A models generated from Domain B models
Figure 3.7: Transformation-based integration
affected by the change in the source model). Such transformations are best run in an event-driven fashion, i.e. transparently processing and propagating changes in the background while the user is editing the model.
While incremental transformations are of immense importance in the QVT standard [QVT03], graph transformation-based approaches provide much better support for integrating multiple do-mains or views as reported in [AK06, JJ06, GdL04, VV04a]. Chapters 5, 6 and 7 of this thesis describe event-driven incremental transformations and their applications in domain-specific modeling in de-tail.
3.3.2.2 Metamodel-level integration by subtyping
However, in many cases, the transformation-based approach can be considered too heavyweight concerning the amount of work required for specifying the links between two domains. This is particularly true when the source and the target domain metamodels are structurallysimilar. This similarity can be expressed with a (partial) supertypeOfrelation between the domain metamodels (Figure 3.8).
This technique is a generalization of UML profiling mechanism for an arbitrary host domain. In Figure 3.8, elementtagging means the assignment of an additional supertype to the source domain metamodel’s certain elements. This is possible if the underlying metamodeling framework supports multiple inheritance.
3.3.2.3 Model-level integration by multiple instantiation
The model-level integration approach (see Figure 3.9) requires that a class in target domain can be assigned explicitly as a type for a model element in the source domain. This assignment can be carried out by user interaction or automatically.
The key difference between the model- and metamodel-level approaches is that by mapping meta-models it is ensured thatall(most) model instances will be mapped onto the target domain, while model-level mapping is more customizable in the sense that the user decides what to project. A major requirement for model-level domain integration against the underlying metamodeling frame-work is a support for multiple instantiation, i.e. to allow to assign a type from each domain to an instance-level model element.