1 Review of Existing View-Based Modelling Approaches

To evaluate existing view-based DSML approaches we conducted a systematic review based on the method proposed by Kitchenham [7]. The review was performed by two researchers, i.e., Goldschmidt and Becker. Where, due to time constraints Becker was responsible for the evaluation of one approach whereas Goldschmidt evaluated the other approaches. The findings where cross-verified by both researchers. However, to ensure that our findings were valid we consulted an additional, external DSML expert who has extensive experience in three of the six evaluated approaches and considerable knowledge about the remainder of the approaches.

Research Questions: The research questions addressed by this study are:

What is the current state of view-based modelling in DSMLs?
How explicit are view-based aspects supported in existing DSML frameworks?
Where are gaps in research concerning view-based DSMLs?

Search Process & Inclusion/Exclusion Criteria: The selection process for the frameworks to be evaluated in this review was based on the following criteria:

The search was based on three electronic databases, i.e.,ACM DigitalLibrary IEEEXplore, SpringerLink as well as references given by DSML experts. The search strategy was based on the keywords “domain-specific”, “modelling”, “language”, “view-based”, “view-oriented”, “views” and framework. The search was conducted in several steps within December 2010 and January 2011. The search covered the years 2006 to 2010.
Domain specific modelling includes approaches stemming from several different research areas. Therefore, we included DSML approaches coming from different areas, e.g., meta-case tools, compiler-based language engineering as well as general model-driven engineering.
Approaches for which a tool or framework was available were included. This ensured that approaches only having a theoretical or very prototypical character were excluded.
For being recognised as view-based DSML framework it should be possible to define new or use existing metamodels and create multiple concrete syntaxes for them.

Quality Assessment: The quality, or better the extent to which view-based modelling is supported, of the evaluated approaches was based on the properties for view types and views described in the paper. For the view type properties the score was 1 for each “y” in the columns and 0 for each “n”, respectively. The same applies for the respective view properties. For the properties overlapping, persistency and editability as well as the conservation property each entry gets a score of 0.5 (e.g., a cell having the value “sel./lay.” would get a score of 0.5 0.5 1). The update strategy is considered a purely informative property.

Data Collection & Data Analysis: For each of the defined properties the we collected the data to which extent the property is supported by the approach. We analysed the extent to which the evaluated approaches support the view-based properties by carefully reading research papers as well as existing user documentation of the approach. Finally, we modelled a small view-based DSML example in each of the approaches to validate our findings. We analysed the results of the data collection by tabulating the data according to the previously defined properties.

1.1 Overview on Selected DSML approaches

First, we give a short introduction to the evaluated DSML approaches evaluated in this paper. Tables 1 and 2 show which features of view types as well as views the different approaches support. Based on these tables, we discuss the most prominent features of each approach in the respective paragraph.

GMF: The Graphical Modelling Framework (GMF) [3], which is part of the Eclipse Modelling Project provides means for creating graphical modelling languages based on Ecore metamodels. Modelling languages created with GMF are by construction view-based. Language engineers may specify which elements of a metamodel should be editable through a specific diagram. This allows for projectional as well as selectionally partial view types. As view type definitions are external to the underlying metamodel, overlapping view types are possible. GMF creates views as non-intrusive, annotating models and thus allows for persistent, overlapping views. Depending on the preference of the language engineer and/or the modeller views (or parts of them) may be selective and holistic (called canonical in GMF).

MetaEdit+: MetaEdit+ [6] is a commercial tool for creating graphical domain specific modelling languages. Support for the integration of multiple languages has also been investigated using this approach [9]. This also enables the approach for multi view type modelling, as different languages may cover different parts of an interconnected, common metamodel. Also, different representations of the same type of element are supported. Thus, elements may occur in the same view using the different representions. Additionally, selectional partiality is supported.

Another key feature of MetaEdit+ is its support for model evolution. As domain specific languages tend to evolve faster than general purpose languages also the support for evolving instances of such languages is inevitable to use the language in a productive environment. Therefore, MetaEdit+ features ways to ensure a seamless migration between different versions of the language.

Microsoft DSL Tools Microsoft introduced the DSL tools [2] for creating graphical DSLs1 as an extension to Visual Studio. The DSL tools allow for the separate creation of metamodel and view syntax which allows to create view-based modelling languages.

Furthermore, the view type definition enables language engineers to create multiple representations of the same metamodel element, thus allowing for intra but also inter view type overlaps. Concerning the scope, Microsofts tool only allows projectional partiality. On view level, the framework supports, both, selectional as well as holistic views or view parts.

MPS: The JetBrains Meta Programming System (MPS) [1] is an approach for the creation of Java-based, textual modelling languages. MPS provides the possibility to internally map the language to Java where it can then be executed just like an internal DSL. However, MPS also allows to define a mapping to other base languages. The biggest difference to most other textual modelling language approaches is that MPS persists a kind of Abstract Syntax Tree (AST) of the language’s instances instead of persisting the concrete syntax representation as text file. The editors manipulating the AST are projectional editors that create the textual representation on the fly. For upcoming versions also graphical representations will be supported and it is planned to have persistable concrete syntax representations for this case.

The use of the AST as the main underlying model allows for the use of multiple, alternative concrete representations of a model. These representations may also project only a certain part of the underlying model to the concrete syntax, thus MPS supports view type partiality to a large extent. However, on view level, manual selectiveness is not supported, hence all views show a holistic representation of the respective part of a model. The projections created based on the AST are not persisted, thus MPS does not support custom formatting.

Spoofax: Spoofax [5] is a language workbench based on scannerless parser generator Stratego/SDF. Due to the scannerless parsing mechanism it features extensive support for modularisation of languages. Furthermore, Spoofax provides rules for type systems as well as scoping and name resolving.

Based on the Stratego language, Spoofax uses concrete object syntax for writing code transformations. This kind of rules can also be used to pretty print a created model in a different view type. These rules also define view properties such as holistic/selectiveness or the update strategy. However, explicit support for view-based modelling, is not given in this approach. There will be still one main view type, i.e., the textual one that needs to be complete. Other, additional view types then may be partial and also have a different representation.

Xtext: Xtext [4], originally part of the openArchitectureWare project, is now the official textual modelling approach of the Eclipse Modelling Project. Its primary use case is the integrated definition of concrete and abstract syntax based on a grammar-like specification. Additionally existing metamodels may be imported and and enriched with a view type definition. Using the latter option, Xtext allows for the definition of projectionally partial view types as well as inter view type overlaps. However, Xtext does not allow to declare selectional partiality in the view type definition. The rules defined in a view type are decoupled from the metamodel classes for which they are responsible. Therefore, a language engineer may define different syntax elements for the same class allowing for intra view type overlaps. Xtext stores the model based on its concrete syntax representation, i.e., as text file. As there is no separation between view persistence and model persistence, hence no support for selectional views is given. Thus, this approach also disallows overlapping views.

1.2 Results

Tables 1 and 2 present the results of the review which we discuss according to our research questions.

Classification According to View Type Features: Table 1 shows to which extent the approaches described above fulfil the view type properties. The columns show if an approach supports projectional partiality, selectional partiality and extending in its view type definitions. Furthermore, the table includes an evaluation of the capability for allowing inter as well as intra view type overlaps.

Name projectionalselectionalextending layout intra/inter viewScore
partiality partiality type overlap

GMF y y n graph./tab. intra/inter 3
MetaEdit+ y y y graph./tab./matrix. intra/inter 4
MS DSL y n n graph./tab. intra/inter 2
MPS y n y text./graph./tab. intra 2.5
Spoofax y n n text./tab. inter 1.5
XText y n n text./tab. n 1

Table 1: View type features supported by different DSL tools.

Classification According to View Features: Table 2 denotes which DSML approach supports which property on the view level. For example, a modelling approach may support additive and deletion selectiveness, which lets a modeller decide manually which elements a view should include as well as if deleted elements are automatically removed from the view or not.

Furthermore, the table includes the editor capabilities of each framework. This includes for example, whether an approach employs a deferred or immediate update approach for updating the underlying model as well as the level of consistency conservation that is supported.

im. = immediate update strategy, de. = deferred update strategy;

Name selec- holis- overlap- persis- edit- conser- update bidirect-
tive tic ping tency ability vation strategy ionality

GMF y y intra/intersel./lay.sel./lay. 5 constr. im. y 1.5
MetaEdit+ y y2intra/intersel./lay.sel./lay. 5 constr. im. y 2
MS DSL tools y y intra/intersel./lay.sel./lay. 5 constr. im. y 1.5
MPS n y inter sel. sel. 2.5 constr. im. y 1.5
Spoofax n y inter sel./lay.sel./lay.3.5constr./model im./de. y 2
XText n y inter sel./lay.sel./lay.3.5constr./model de. y 2

Table 2: View features supported by different DSL tools.

RQ1 What is the current state of view-based modelling in DSMLs? For graphical DSMLs, view-based modelling resembles an intuitive way of working with models. For modellers, seeing a diagram as view which is a projection from the underlying model, is a good way of dealing with complexity. Therefore, most diagram types are partial view types omitting certain details. This detail is mostly editable through additional ways, such as form based editors. On view level, also selective as well as holistic views are common. This is also reflected by the current state of graphical DSL tools, where the average score for graphical tools is 8.3.

For textual DSMLs, view-based modelling is less common, the average score for this kind of approaches is only 6.6. Most approaches employ a one-to-one relationship between model and textual representations. Influenced from traditional language engineering the level of detail can only be influenced by import relations between those textual representations. Thus, there are currently only a few tools for textual DSMLs that explicitly support view-based modelling.

RQ2 How explicit are view-based aspects supported in existing DSML frameworks? In graphical DSML tools the view-based concept is explicitly supported to some extent. However, especially with respect to view type and view overlaps, often manual code or extensions to the framework are required. Additionally, checks for partiality and completeness are not offered by any of the graphical modelling tools.

Textual DSML approaches give even less support for explicit view type creation. Even the separation of metamodel and view type definition is often a secondary, only weakly supported option. Selectional textual modelling is completely missing in current DSML approaches.

RQ3 Where are gaps in research concerning view-based DSMLs? Especially if textual DSMLs are to be used in combination with graphical DSMLs, also textual languages require view-based modelling features. Scheidgen [8] proposed a first approach for embedding textual into graphical modelling. However, being only embedded, textual and graphical modelling is still not on an equal level.

Also, the advantages of view-based modelling when working with large, complex models involving multiple roles that work on the same model may be exploited by bringing view-based modelling to textual modelling languages.

As view support for textual DSMLs is still performed on a very implicit and weakly supported stage, we consider explicit view-based textual modelling a fundamental gap in research.


1.    JetBrains MPS. http://www.jetbrains.net/confluence/display/MPS/Welcome+to+JetBrains+MPS+Early+Access+Program.

2.    Steve Cook, Gareth Jones, Stuart Kent, and Alan Wills. Domain-specific development with visual studio dsl tools. Addison-Wesley Professional, first edition, 2007.

3.    Eclipse Foundation. Graphical Modeling Framework Homepage. http://www.eclipse.org/gmf/, 2007. Last retrieved 2008-07-06.

4.    Sven Efftinge. Xtext reference documentation. http://www.eclipse.org/gmt/oaw/doc/4.1/r80_xtextReference.pdf, 2006. Last retrieved 2008-07-06.

5.    Lennart Kats and Eelco Visser. The Spoofax language workbench. Rules for declarative specification of languages and IDEs. In Proceedings of OOPSLA, pages 444–463, 2010.

6.    S. Kelly and J-P. Tolvanen. Domain-Specific Modeling:Enabling Full Code Generation. Wiley-IEEE Society Press, 2008.

7.    Barbara Kitchenham. Procedures for performing systematic reviews. Technical report, Keele University, 2004.

8.    Markus Scheidgen. Textual modelling embedded into graphical modelling. In ECMDA-FA, pages 153–168, 2008.

9.    Juha-Pekka Tolvanen and Steven Kelly. Metaedit+: defining and using integrated domain-specific modeling languages. In Proceeding of OOPSLA ’09, pages 819–820, 2009.