Domain Specific Visual Languages play a fundamental role in the development of model-driven software, as they allow more expression and ease of use when compared to a general purpose language. The increase in this type of visual languages and the inherent complexity as regards the development of graphical editors for them has, in recent years, led to the emergence of several tools that provide technical support for this task. Most of these tools are based on the use of models and increase the level of automation of software development, which are the basic principles of Model Driven Engineering. This post therefore reviews the main features, potential advantages and current limitations of the principal tools that exist for the development of graphical editors for DSLs.
Therefore, in order to attain a clear understanding of the state of the art as regards model-based tools for the development of graphical editors for DSLs, in this post we present the main results obtained after carrying out a systematic review.
The systematic review allowed us to collect the most relevant information of the primary studies, which allowed us to identify that the main model-based tools related to the generation of graphical editors are: DiaGen, EuGenia, GMF, Graphiti, MetaEdit+, Obeo Designer, Sirius and Tiger. However, it is noteworthy that during the search process of systematic review other tools for generating graphical editors were identified, but they are not model-based. Note also that this is indeed a never-ending task, since new tools appear every day.
Furthermore, we were also able to collect a set of criteria that are often mentioned or evaluated in the primary studies of the systematic review.These criteria, which are presented below, have allowed us to compare the tools involved in the review in a systematic manner:
Scope. One of the main issues to consider with regard to the tools in the field of software engineering is whether the tool is commercial or open source. We also indicate the type of license provided.
Framework. Frameworks are technological structures that can provide the basis for the organization and development of software. In the context of Model-Driven Software Development, Eclipse is the most widely used framework in general. Given this, it is interesting to identify whether the tool analyzed is isolated or runs on an existing framework.
Distinction between abstract and concrete syntax. The abstract syntax of a language describes the vocabulary employed for concepts provided by the language and how they may be combined to create models, while the concrete syntax provide a notation that facilitates the presentation and construction of models in the language. In order to avoid the problems related to the aggregation of information concerning the domain of the solution in the context of the problem domain, it is important to conceptually separate the abstract syntax and the concrete syntax in a modeling language. It is necessary to consider that an abstract syntax does not depend on a concrete syntax.
Abstract syntax. The first step toward the definition of a DSL is the specification of its metamodel. In this context, it is interesting to determine the type of metamodel that the tool analyzed uses to collect the abstract syntax of the language for which we wish to generate a graphical editor.
Concrete syntax. The concrete syntax provides a (graphical or textual) notation which facilitates the model representation. Given this, it is interesting to determine how the tool analyzed allows users to define the graphical or textual notation associated with each element of the metamodel of the DSL.
Editing capabilities. Once the editors have been generated, it is important to manipulate and modify the elements of the models that can be created with the editor developed in a simple, complete and functional manner. In this context, we analyze the options provided by the tool when editing the elements of the models.
Use of models. One of the objectives of MDE is to promote the use of models in all activities of software engineering, whereby a more appropriate level of abstraction is obtained than when using code. Given this, it is interesting to determine whether models are used in some of the graphical editor generation phases. It is also important to know the purpose of each of these models, and it is particularly interesting to determine the extent to which models are generally used by each of the tools analyzed.
Automation. In order to generate an editor in a manner that is transparent, efficient and quick for the user, it is important to obtain the editor or the intermediate stages automatically. At this point, it is interesting to determine the level of automation in the production of editors.
Usability. When analyzing this feature, it is interesting to identify the ease of use and learnability provided by the proposals studied in order to be able to perform all the steps required to achieve the development of a graphical editor that supports DSL. In this context, we identify whether the tools provide official documentation, wizards, guided tours, examples and/or any other assistance that will permit a more efficient use, ease of learning and, in general, greater satisfaction when using the tool.
Methodological Basis. When designing a visual notation it is important to consider the issues related to the quality of that notation. Several mechanisms with which to assess the quality of the metamodel that collects the abstract syntax can be employed for this purpose, but above all, there are different metrics with which to assess whether the graphical symbols, and the concrete syntax in general, can be correctly processed by the human mind. In this context, we analyze whether the tool follows or applies any kind of scientific theory, empirical evidence and/or any type of method to guide, derive or define visual notations.
Having analyzed the different proposals, and in order to provide a rapid overview of them, the table shows a summary of the comparative study according to the criteria defined above.
As will be observed in the summary of the comparative study, most of the proposals solve the problem of the conceptual separation of the metamodel (abstract syntax) and the design features that are attached to each of its elements (concrete syntax), without adding information related to the domain of the solution in the context of the problem domain. There are also proposals that automatically generate many of the intermediate phases during the process of generating an editor. However, most of these tools have to refine each intermediate phase through the use of mechanisms that are complex and unintuitive for the user.
Regarding the use of models, only a few of the tools use models in each of the editor-generation phases, which considerably facilitates the usability of the tool and allows the user to focus on the important aspects of the domain. Furthermore, in this work we have found that most of the proposals have been designed to be used in the Eclipse, which is one of the most popular frameworks in the software development community. This feature facilitates integration and interoperability with other software systems developed under Eclipse. Regarding the use of a scientific basis to design visual notations, we have identified that virtually no tool provides mechanisms with which to achieve this goal, and only a few of them provide the possible values of visual variables in a way that is orderly and intuitive for the user.
Furthermore, the values of the last row in the table represent the percentage of the maximum possible score for the qualitative criteria evaluated (ticks obtained / maximum possible ticks). As this data shows, the highest values are obtained for the usability (91.6%) and the use of models (87.5%) criteria, while it is worth noting that a very small value (12.5%) is obtained for the criterion related to the use of a methodological basis so as to take into account the quality of the visual notations generated. Given that, we can state that of the commercial tools, MetaEdit+ and Obeo Designer are the most complete proposals according to the characteristics evaluated in this work. Of the open source tools, Eugenia, GMF, Graphiti and Sirius can, meanwhile, be considered as the most complete and functional for the purpose of generating editors for DSL. And this may be understandable, considering that these four tools have technological bases in common, such as the fact that they use EMF.
Many of the proposals discussed in this post therefore have interesting features as regards generating graphical editors for DSL, although several of their features have room for improvement and refinement. In order to obtain tools that are able to create editors with a minimal difficulty and transparency for the user, it is important that these tools take into account aspects such as the use of frameworks that follow the standards of the software development community, the use of models in each phase of editor generation, the separation between abstract and concrete syntax, automation in the development process and the usability of the tool itself.
Finally, we have concluded that none of the tools follows a methodological basis in the process of construction of graphical editors that support DSLs, nor use a theoretical basis for assessing the quality of the visual notations generated, in order to guide to the user in the generation of visual notations that are easier to process by the human mind, without being limited to the classic geometric shapes like boxes and arrows.
Given the above, some of the limitations identified in this study have motivated the development of a new tool called CEViNEdit. We could talk about this tool in another post 😉
Beyond the results and conclusions obtained, it is important to note that a study of this type is a never-ending task since new tools appear every day. For this reason, one of our future goals is to periodically update this study in order to identify the state of the art of the tools that enable the generation of graphical editors from a domain model, and to continue development work on a new proposal that will take into account all aspects that can be improved based on the results obtained in this study.
Teaching Assistant at Rey Juan Carlos University. PhD in Information Systems Engineering. My research interests are mainly focused on Model-Driven Engineering and Domain-Specific Languages.
Thanks for this interesting and thorough article!
Have you ever tried to integrate this approach, and more especially the Semiotic Clarity, Visual Expressiveness, Graphic Economy factors in the existing Sirius editor? We give a lot of attention to the visual effectiveness, design and user experience of the editors built with our solution, a presentation on this very topic will be given at SiriusCon 2016 (Paris) in November (http://www.siriuscon.org/): “Tips & Tricks about Graphical Design”, feel free to join!
our research group has developed Collaboro, a tool to enable the collaborative development of DSLs. The approach is described in this blog here and we also presented a first prototype in an Eclipse DemoCamp in Nantes.
Our last advances in the tool incorporate, among others, the support to calculate metrics of the notation, including semiotic clarity, visual expressiveness, etc. We have published our results in a PeerJ paper that is about to appear (you can access the preprint here in the meanwhile)
We are now working in close collaboration with David Granada to integrate our two approaches to support the calculation of notation metrics in CEViNEdit. We hope to release our work soon.
I’m also aware of the talks at SiriusCon, they look pretty interesting! 🙂
I remember Collaboro! thanks for the link to the preprint !
We can have a chat to explore whether we can integrate some of the things we are working on in Sirius! (or evaluate current Sirius-based languages to see how well they score)
Thank you for providing the comparison.
You might be interested to read also other comparisons covering larger set of tools/DSL creation approaches using review criteria of their own:
Last and most importantly, I would like to emphasize that maintenance is typically 90% of all – so would it be possible to extend the systematic review to handle 1) language maintenance and refinement and 2) model maintenance/evolution once language changes? This way perhaps there would start to be bigger differences in the comparison too.