An Example Application of a Multi-Level Concrete Syntax Specification with Copy-and-Complete Semantics

Abstract

-This paper describes an example application of the Topology Type Language (TTL) to define visualizations for conceptual models with multiple type levels. Based on a multilevel example model about the domain of bicycle products, a formal specification for a diagram visualization is developed which visually displays characteristics of bicycles and their components according to the domain model. The result is an example specification of a diagram visualization that incorporates characteristics of model elements from different type-levels of a domain-specific conceptual multi-level model into one consistent visualization specification that can be reused to visualize entities on different abstraction levels in the domain model. Index Terms-Multi-Level Modeling, Domain-Specific Modeling Language, Diagram, Topology, Visualization, Concrete Syntax B. A Visual Language for Specifying Complex Model Representations

I. A VISUAL FORMALISM FOR SPECIFYING VISUALIZATIONS

A. Visual Model Representations as Building Blocks of Information Systems

Conceptual models are known as essential means for describing and constructing information systems. Expressing conceptual aspects of information systems, such as involved entities, operations, relationships, etc., is widely regarded as an appropriate construction technique to design and implement supporting software systems.

User interfaces (UIs) allow human users to operate software systems. Unlike the known importance of conceptual modeling of information systems, however, the modeling of user interfaces is far lesser developed. Contemporary concrete syntax declaration languages for conceptual model representation are typically either restricted to text-based structures that make model content accessible to humans [ 20 ], [ 13 ], or are limited to a small set of visual means, which mostly are graphbased diagrams [ 8 ], [ 21 ] in which graphical symbols that represent entities are interconnected with lines that show relationships. Other kinds of visual representations have to be specified using primitive implementation-level techniques with programming languages or visual instance editors that provide no abstractions with regard to efficient representation and re-usability of model representations [ 14 ], [ 15 ].

The research presented in this article demonstrates initial parts of a specification mechanism for visual representation of conceptual model content that aims to provide a higher-level declaration mechanism for concrete model syntax. The presentation focuses on an example application, that demonstrates parts of the language without offering a complete description of all language features.

The remainder of Section I introduces selected language features of the approach, which are subsequently applied in Section II to an example that specifies a visual representation for a given conceptual model about the bicycle product domain. Other scientific work which is related to the presented considerations is considered in Sect. III, and a conclusion in Sect. IV summarizes the discussed ideas.

The Topology Type Language (TTL) is being developed to serve the purpose of specifying visualizations of diverse kinds for models. It is intended to describe model representations of various visual forms, such as diagrams or graphical user interfaces, together with corresponding human interactions. Especially, the TTL is being developed as an advanced specification formalism for concrete syntaxes of domain-specific modeling languages. Among others, it offers three central characteristics which go beyond the state-of-the-art of conventional concrete syntax specification mechanisms: 1) The description of a visualization happens entirely independent from a model, i. e., the visualization can be defined without restrictions imposed by the meta-model of the visualized language. 2) The specification mechanism can refer to meta-models with multiple type levels. It describes a notion of instantiating topology types in multiple refinement steps which can be mapped to the conceptual type-level hierarchy of a multi-level meta-model. 3) The approach provides a visual formalism to describe topologies. Although the description of topologies is an abstraction over a visualization and does not describe the visualization itself, the use of a visual language to specify topologies appears appropriate as it promises a higher level of cognitive efficiency and advanced easeof-use than a textual formalism.

The term “topology” has been chosen as part of the name to indicate a level of conceptual abstraction, which on the one hand uses visual constructs that express meaning with spatial patterns and locations, and on the other hand does not denote the resulting visualization itself, but a reflective abstraction about it.

Figure 1 shows an example TTL model which will further be introduced in the use case demonstration in Section II.

As a consequence, it turns out to be necessary for a specification mechanism for model visualizations, to introduce a layer with intermediary specification concepts, which serves to decouple the structure of the described visualizations from the structure of the meta-model that is underlying to the (domain-specific) conceptual language the concepts of which are visualized. The approach provided with the TTL does so by abstracting visualizations to topologies, which can initially be described without any references to a modeling language and its instances, and only at a later stage during the specification of the visualization are bound to concrete model instances. This binding happens by specifying conceptual relations that query content from model instances and may feed back modified content into the model. A default way to specify conceptual relations can be realized by incorporating an existing expression language into the TTL specification approach.

2) Instantiation by Copy-and-Complete Semantics: The

specification language supports a notion of Abstract Areas versus Concrete Areas, and in addition allows to specify a sequence of Completion Steps that constrain how an Abstract Area is supposed to be transformed to a Concrete Area, in order to make it visually renderable. Among other linkages to multi-layer or multi-step application contexts, these constructs in combination allow to reflect a notion of topology types which over multiple levels of abstractions get instantiated to a concrete topology. As this procedure is applied to a visual formalism, it makes sense to describe the differences between types and instances in terms of missing versus provided elements, which is why an operational copy-and-complete semantics seems appropriate to describe a visual type system.

Following such a copy-and-complete procedure, the transformation from abstract to concrete topology type descriptions happens in an n-step transformation process, in which underspecified parts of the topology type description are completed step by step, until no more underspecified parts exist. Figures 1 and 7–9 show the example copy-and-complete procedure that is applied to create the topology type description for the example domain model.

Some central considerations that have guided the development of the TTL are briefly described in the following.

1) Decoupling Visualization Description from Conceptual

Description: It is a major shortcoming of existing approaches such as the Eclipse Graphical Modeling Framework (GMF) [ 8 ], that the use of different types of conceptual elements C. Language Elements can pre-determine the visual structure and composition of the Those language elements of the TTL that are used in the graphical syntax. Some line connectors, or nesting elements example in Section II are briefly explained in the following. inside each other, can only be used in combination with 1) Area: The Area concept is the central model element fixed meta-model concepts. For example, a visual nesting, to specify topologies. It provides the fundamental structure in which elements are placed inside an outer element, re- element to describe visualizations. Areas are assumed to have quires the meta-model to contain a composition relationship a spatial extension and can be nested into each other. Every between the nested concepts. To the contrary, the use of line- area has a location that may be relative to other areas, and connectors demands for non-containment associations between to its parent area (if it exists). Areas are notated by slightly the classes of the connected elements in the meta-model. Such rounded squares with a dashed line border (see Fig.2). connectors thus cannot be used to visualize associations that Areas provide templates for renderers. Areas do not define are considered to be compositions from a conceptual point of their visual appearances by themselves, but they provide space view – although the decision whether to model a relationship for renderers to work in. Renderers use the topology type as an association or as a composition may be contingent in description and bound values from the domain model as input the modeled domain, and should not influence the shape of to actually display visualizations on top of a concrete graphpossible visualizations that can be specified as concrete syntax. ics rendering technology. From a conceptual point of view, renderers can be implemented using any arbitrary technology, e. g., they can be created directly as program code. Different renderers may be responsible for displaying the same topology type description via different document formats, or on different devices. The wide range of realization options for renderers is not in the main focus of this paper and will further be discussed elsewhere.

An area can be associated with a type. Visually, types are distinguished by different colors of the dashed area borders.

The definition of available types is indicated by small squares in the top section of the parent area.

Figure 2 shows Area notation elements nested inside each other, with the parent area defining two distinct types, that are applied to the nested areas.

Further details on the specification of Areas are out of the scope of this paper and will also be discussed elsewhere.

2) Locator: A Locator serves the purpose to formally describe spatial relationships between Areas. The visual presence of a Locator, that connects two or more areas with each other, semantically only means that there is an explicit statement on how the respective areas are related to each other. The actual kind of spatial relationship is non-visually specified via the properties-sheet of the Locator. There are multiple options to actually implement a formal description scheme for spatial relations. One possibility is to recur to a 2D spatial version Allen’s interval algebra, as it is elaborated in [ 22 ], which list all possible kinds of spatial relations that bodies can have on a diagram plane, e. g., overlapping, touching containing, etc.

The spatial placement of a Locator inside an area and in relation to its connected areas, as it appears in a TTL diagram, is a pure visual hint for the topology modeler that may or may not visually resemble the actual placement the Locator is expressing.

For the purposes of the example presented in Section II, a simple notion of locators that specify an absolute distance and direction between two connected areas is sufficient.

The visual notation of a Locator is exemplified in Fig. 3.

3) Abstract Areas versus Concrete Areas: In order to pro

vide a notion of instantiability of abstract topology types to concrete ones, the notion of regarding an incomplete specification of a topology as abstract, and a fully specified topology as concrete which can serve as input to a renderer, can be broken down to individual Areas. An Area which is not yet fully specified to serve as input to a renderer is considered abstract, while an Area which provides all necessary information to be rendered is concrete.

There are three ways to make sure an Area can be rendered, i. e., to concretize an Abstract Area to a Concrete Area:

Children Areas are added (every Area that contains at least one child Area is considered to be concrete, because a default renderer can be applied that hands over the rendering of the nested areas to their respective renderers)

Conceptual Relation Specifications are added to all Conceptual Relation placeholders that an Area contains (Conceptual Relation Specifications bind elements from the data population of an area to parameters of renderers) An Area Reference to a Concrete Area is added, which has the effect that the referenced Area is used to replace the referencing one

The first two options can be combined, given that the configured renderer both processes children Areas and Conceptual Relations. In the special case that a Renderer which has no parameters at all is assigned (e. g., a visual decorator), an Area is also considered to be concrete.

The notation of Conceptual Relations and Conceptual Relation Specifications is shown in Fig. 4.

(a) (b) Fig. 4: Notation of the Conceptual Relation element inside an Area element, (a) abstract requirement, (b) filled in with concrete Conceptual Relation Specification

4) Completion Step: Abstract Areas can be assigned with Completion Step tags, that allow to specify a minimum and / or maximum number of concretization steps, until the Abstract Area either has be made concrete, or optionally is removed. In general, Completion Step tags allow to specify any finite sequence of modes that subsequent concretization steps have to conform to.

The three distinguishable modes of how to perform a single completion step on an Abstract Area are:

Preserve: the Abstract Area is not completed and remains abstract in the current completion step

Optional: the Abstract Area may be completed, remain,

or be deleted in the current completion step Complete: the Abstract Area must be completed with a concrete topology description, either by assigning a renderer to the area, describe a sub-topology in the area, or by referencing another area which is concrete

Fig. 5: Notation of Completion Step tags (shown as circles in the upper-right corner of an area)

The sequence of Completion Step tags, from left to right, represents the upcoming concretization steps that the topology type description will undergo. The very next step is configured by the left-most Completion Step tag in the sequence. When a topology type description is transformed to a next concretion step, all Areas get copied, and the left-most Completion Step tag is removed from the sequence in any of the areas.

The ability to impose constraints on anticipated future concretization steps provides a mechanism which stands in analogy to the specification of intrinsic features in a multilevel modeling language [ 10 ]. This means, the sequence of concretization steps can be defined along the instantiation levels of entities from a multi-level conceptual domain model. Using Completion Step tags, the demand for when to fill in Conceptual Relation specifications can be delayed in a controlled way. A topology type definition can make use of this to define Conceptual Relations on the basis of intrinsic attributes on higher levels of conceptual abstractions in the domain model, for which the concrete values will later be derived from slot values of entities on lower levels. This makes the TTL a visualization specification approach that integrates the description of visualizations for conceptual entities on different levels of conceptual abstractions into one unified specification mechanism for model visualizations. It allows for an efficient declaration of concrete syntaxes for domainspecific type models, together with concrete syntaxes for their instance models across multiple type levels.

II. EXAMPLE APPLICATION OF A BIKE PRODUCT

VISUALIZATION BASED ON A MULTI-LEVEL CONCEPTUAL

DOMAIN MODEL

The example domain model that conceptually describes the bicycle product domain is displayed in Fig. 6. It has been created with the multi-level modeling language FMMLx [ 10 ], originally as a contribution to the MULTI 2017 Challenge [ 4 ].

The model is composed of four type levels. The topmost level, indicated by entities with red header backgrounds, models the general idea of a bicycle, by defining the basic components a bicycle is made of. These are BikeFrame, BikeFork, BikeHandlebar, and BikeWheel. The fact that an entire bicycle is composed of these parts is expressed by the use of a composite pattern, which provides the abstract class Component from which the individual part entities inherit, and the abstract class CompositeComponent, which is a parent class of Bike.

The second upper level, which consists of entities with a blue header background, introduces a type level which distinguishes between different kinds of bicycles, such as MountainBike, CityBike, or RacingBike in the example. It also provides some entity types that describe a refined notion of general bicycle parts, such as RacingFrame and RacingFork, which are particularly intended to be used for RacingBikes.

On the third level, a refined notion of bicycle kinds from the above level is intended to be modeled. The example demonstrates this by introducing the bicycle kinds ProRaceBike and ProRaceFrame on this level.

Finally, the lowest level shown in the example model contains bicycle product types as they could appear in the catalog of a bicycle vendor. The example model contains the product types ChallengerA2XL, which is a ProRaceBike, and the RocketA1XL bicycle frame as an instance of ProRaceFrame. From these product type, concrete instances of physical bicycle entities can be instantiated, which would resemble the notion of concrete bicycles such as “Peter’s yellow racing bike”. Instances of this kind are considered to be created during runtime use of the model, and are not included in the example.

The model in the TTL shown in Fig. 1 is the result of a multi-step transformation from a more general TTL model to a concrete visualization description for “Pro Racing Bikes”. The procedure of the transformation is described in the following, starting with the initial TTL model shown in Fig. 7 that generally describes the notion of any bike visualization without a connection to concrete data to be rendered.

A. Initial Topology Type Model

The TTL model in Fig. 7 provides a general description of what a visualization of a bike product could be composed of. The description is independent from any binding to model content yet, but by specifying several empty Conceptual Relationship elements in its area elements, it already suggests what domain characteristics should influence a resulting rendered visualization.

The Completion Step elements in the upper-right corners of each area part suggest how to further complete this topology type description in the next concretization step. The outer “Bike” area specifies a single further Completion Step, which demands to concretize this area specification in the next subsequent step. The other areas each define three subsequent Fig. 7: Example visualization specification for the generic notion of a bike, as modeled on the highest abstraction level in the domain model concretization steps, with the first demanding to leave the area untouched in the next step.

B. First concretization step

As a consequence, in the next step the outer “Bike” area is made concrete by filling in the previously empty Conceptual Relation element “background” with a binding that provides input data from the visualized model as input for the renderer that is configured for the “Bike” area. In case of the example at hand, this could mean that either based on the class name of a bike entity to be displayed, or as a result of combining the suitedForToughTerrains and suitedForRaces slot values, a suitable name for a background image is calculated. E. g., a renderer could be configured which displays a background image of a mountain scenery for mountain bikes, a street scenery for city bikes, and a racing track for racing bikes. There are diverse options for realizing such a binding on the implementation level, further details are not discussed here.

Figure 8 shows the topology model after the first concretion step has been performed.

If at this point also renderers are attached to the other areas, which could render a generic visualization of the respective elements they are to display even without concrete input values (e. g., by using pre-defined default values as long as the Conceptual Relations for the respective area are not fully specified), then the visualization description could already be used for rendering a generic, product-independent, visualization of a bike.

C. Second concretization step

To provide a further refinement of the visualization specification, the next concretization step reuses the topology type Fig. 8: Example visualization specification distinguishing the notion of general types of bikes (racing/mountain/city), as modeled on the second-highest abstraction level in the domain model description in Fig. 8 and enhances it in order to visualize specific characteristics of racing bikes described in the domain model. To do so, additional Conceptual Relations are added to the “Frame” area which represent the domain fact that the frames of racing bikes are described by three lengths values. Adding further Conceptual Relations is possible, because the Conretization Step specifications for the current step allows optional modification to the area. The resulting topology type description after this step is displayed in Fig. 9.

D. Third concretization step

The remaining Concretization Step elements in the model in Fig. 9 all demand for a completion of the yet underspecified areas. As a consequence, the final modifications to the model in the third concretization step consist of filling in the empty Conceptual Relation placeholders with bindings to concrete input value that can be derived from domain model entities on abstraction level 1. According to the declarations of intrinsic attributes in the domain model, this is the level where the information is present that distinguishes visual characteristics of different bike products.

Figure 1 shows the resulting concrete renderable topology type description for “Pro Racing Bikes”, as described in the domain model.

III. RELATED WORK

Specifying concrete syntaxes for visual diagram languages is pivotal to the design of domain-specific languages (DSLs). As a consequence, most of the DSL creation approaches and tools available offer means for defining concrete diagram syntaxes. Three well known representatives of the category of meta-modeling environments which offer support in visual language creation are METAEDIT+ [ 16 ], the ECLIPSE GRAPHICAL MODELING FRAMEWORK (GMF) [ 8 ], and SIRIUS [ 7 ]. These tooling environments offer mechanisms to specify conceptual features of a domain, e. g., with a metamodel, together with functionality to define visual representations for the domain concepts. METAEDIT+ includes a simple graphical icon editor that allows to paint graphical symbols to represent domain concepts. GMF also supports the definition of graphical symbols composed out of drawing primitives, however, the specification of the symbols happens non-visually in a tree-view editor. SIRIUS also uses a treeview configuration editor for all parameters of its diagram definitions, with the significant difference to GMF that the concrete syntax definition is interpreted at run-time without the need for code generation. Any changes that are made to a SIRIUS diagram definition become immediately visible in a corresponding editor.

The general approach in these tools is to enhance the conceptual description in the meta-model with additional information about the visualization that gets attached to the metamodel elements. This happens either by directly attaching information about how to visualize a concept in the metamodel (e. g., by the use of annotations), or by employing a mapping model that externally attaches additional information to meta-model elements. In both cases, one has to be aware that a direct annotation of meta-model elements limits the range of possible visualizations to describe, as the meta-model structure pre-forms the possible structure of visualizations [ 14 ], [ 15 ]. None of the approaches embedded in existing tools has been developed from the very beginning based on theoretical considerations about the demands towards an optimal visualization specification mechanism. The TTL aims to overcome these limitations.

The specific task of defining visual representations for multi-level conceptual models has been addressed by a few contributions. The multi-level modeling environment OMME [ 28 ] combines conceptual multi-level modeling capabilities with the ability to visually specify a graph-based diagram language. This allows to define visual domain specific languages for multi-level models, however, the specification mechanism for the visual syntax does not specifically adhere to conceptual multi-level features, and thus does not provide reusability and extensibility of visual language specifications across multiple type levels in the underlying conceptual models.

The DPF workbench [ 18 ] also offers an integrated approach for multi-level modeling together with the specification of visual diagram representation of models. DPF’s specification mechanism for visualizations offers a formalism that incorporates the notion of graph homomorphisms and type homomorphisms to check the conformance of a visualizations across multiple type levels. However, the expressiveness of the visualizations themselves is fairly limited, and the specification formalism is restricted to graph-based diagrams only, like many of contemporary concrete syntax specification mechanisms.

In XMODELER [ 5 ], [ 6 ], conceptual multi-level modeling capabilities are combined with a non-visual specification mechanism for model representation and interaction called XTOOLS. While this approach gives flexibility over specifying model representations of various types, which are not necessarily restricted to graph diagrams, the current version of XTOOLS does not specifically take into account multi-level capabilities of the underlying conceptual models.

The MELANEE [ 1 ] domain-specific language workbench is a representative of a multi-level modeling environment, which incorporates a visual language design approach that allows to take into account multiple type levels. The approach makes use of an aspect-oriented declaration mechanism, by which parts of a visualization specification can be equipped with join-points for elements that are to be specified or modified later in a refined version of the visualization [ 12 ]. This way, basic characteristics of reusability and refinement of existing visualizations for more specific type levels are made available. The visual paradigm of the diagrams languages that can be defined, however, remains limited to a be represented by a set of graph-nodes and corresponding line connectors.

Despite the prominent role of diagram languages in Information Systems, theoretic research about concrete syntax specification is just about to be established as a relevant perspective on the core objectives of the discipline. Considerations about the “Physics of Notation” [ 21 ] provide one source in Information Systems science that summarizes fundamental principles of designing visual diagram languages. Diverse points of critique have been brought forward against the narrow perspective taken in by [ 21 ]. Especially the potential for leveraging the capabilities of the human visual perception apparatus, which allows for fast, parallel, and scalable cognitive processing of visual pattern structures, is not sufficiently taken into account [ 26 ], [ 27 ].

Beyond the Information Systems discipline, a wider range of scientific contributions about information visualization can be found. Classical work about diagrams from before the age of computers has been contributed by [ 2 ], [ 24 ], [ 25 ]. More recent work about the effectiveness of interactive visualizations originates from fields such as interaction design and journalism [ 3 ], [ 17 ], [ 19 ], [ 23 ], or information dashboard design [ 9 ]. The research demand for incorporating the perspective on cognitive efficiency into Information Systems research has been pointed out as well [ 14 ], [ 15 ].

IV. CONCLUSION

The example developed in this paper has given an impression of how a visual formalism for specifying visualization types that can represent model content on multiple levels of abstraction can work. Core elements of the visual Topology Type Language (TTL) have been introduced, without, however, going too much into details to keep the example description appropriately compact.

The TTL integrates the description of visualizations for conceptual entities on different levels of conceptual abstractions into one unified specification. This allows for an efficient reuse of existing concrete syntaxes, and makes it possible to specify visual languages for domain-specific type models as well as their instance models across multiple levels in the same place.

Other aspects of the TTL with respect to its applicability to presentation and interaction schemes beyond mere diagram visualizations, toward describing entire applications’ user interface presentation and interactions, will be part of future work. The TTL might as well be suited for use in selfreferential enterprise system scenarios [ 11 ], where dynamically configurable views on instance models serve both as tools for control and analysis. The TTL could play a role in such a setting by providing a visual specification mechanism which allows to define instance visualizations at run-time based on existing reusable specifications of type-level visualizations.

Fig. 6: Example Conceptual Model of a Bike Product Domain

References

[1] Colin Atkinson and Ralph Gerbig . Flexible deep modeling with melanee . In Stefanie Betz Ulrich Reimer, editor, Modellierung 2016 , 2 .- 4 . Ma¨rz 2016 , Karlsruhe - Workshopband, volume 255 , pages 117 - 122 , Bonn, 2016 . Gesellschaft fu¨r Informatik.

[2] J. Bertin . Semiology of Graphics: Diagrams , Networks, Maps. Walter de Gruyter, Berlin, 1974 .

[3] Alberto Cairo . The Functional Art. Voices That Matter. Pearson Education , New York, 2010 .

[4] Tony Clark , Ulrich Frank, and Manuel Wimmer . The bicycle challenge of the multi 2017 workshop on the models 2017 conference , austin, texas, sept 17 - 22 , 2017 .

[5] Tony Clark , Paul Sammut, and James Willans. Applied Metamodelling: A Foundation For Language Driven Development . Ceteva, 2nd edition , 2008 .

[6] Tony Clark and James Willans . Software language engineering with XMF and XModeler . In Marjan Mernik, editor, Formal and Practical Aspects of Domain-Specific Languages: Recent Developments , pages 311 - 340 . IGI Global, 2012 .

[7] Eclipse Foundation . Eclipse sirius . https://eclipse.org/sirius/.

[8] Eclipse Foundation . Graphical modeling framework (gmf) . http://www. eclipse.org/modeling/gmf/.

[9] Stephen Few. Information Dashboard Design: The Effective Visual Communication of Data. O'Reilly , Sebastopol, CA, 2006 .

[10] Ulrich Frank . Multi-level modeling - toward a new paradigm of conceptual modeling and information systems design . Business & Information Systems Engineering (BISE) , 6 ( 3 ), 2014 .

[11] Ulrich Frank and Stefan Strecker . Beyond erp systems: An outline of self-referential enterprise systems . Technical Report 31, ICB Institute for Computer Science and Business Information Systems , University of Duisburg-Essen, Essen, April 2009 .

[12] Ralph Gerbig . Deep, seamless, multi-format, multi-notation definition and use of domain-specific languages , 2017 .

[13] Hans Gro ¨nniger, Holger Krahn, Bernhard Rumpe, Martin Schindler, and Steven Vo¨lkel. Textbased modeling . CoRR, abs/1409.6623 , 2014 .

[14] Jens Gulden and Hajo A. Reijers . Toward advanced visualization techniques for conceptual modeling . In Janis Grabis and Kurt Sandkuhl , editors, Proceedings of the CAiSE Forum 2015 Stockholm, Sweden, June 8-12, 2015 , CEUR Workshop Proceedings . CEUR, 2015 .

[15] Jens Gulden , Dirk van der Linden, and Banu Aysolmaz . Requirements for research on visualizations in information systems engineering . In Proceedings of the ENASE Conference 2016 , April 27-28 2016 , Rome, 2016 .

[16] Steven Kelly and Juha-Pekka Tolvanen . Domain Specific Modeling: enabling full code-generation . Wiley, 2008 .

[17] Andy Kirk . Data Visualization: a successful design process . Packt Publishing, Birmingham , 2012 .

[18] Yngve Lamo , Xiaoliang Wang, Florian Mantz, Wendy MacCaull, and Adrian Rutle. DPF Workbench: A Diagrammatic Multi-Layer Domain Specific (Meta-)Modelling Environment, pages 37 - 52 . Springer Berlin Heidelberg, Berlin, Heidelberg, 2012 .

[19] Isabel Meirelles . Design for Information . Rockport Publishers, Beverly (MA), 2013 .

[20] Bernhard Merkle . Textual modeling tools: Overview and comparison of language workbenches . In Proceedings of the ACM International Conference Companion on Object Oriented Programming Systems Languages and Applications Companion , OOPSLA ' 10 , pages 139 - 148 , New York, NY, USA, 2010 . ACM.

[21] Daniel L. Moody. The “ physics” of notations: Toward a scientific basis for constructing visual notations in software engineering . IEEE Transactions on Software Engineering , 35 ( 6 ): 756 - 779 , 11 /12 2009.

[22] Mohammad Nabil , John Shepherd, and Anne H. H. Ngu . 2D projection interval relationships: A symbolic representation of spatial relationships , pages 292 - 309 . Springer Berlin Heidelberg, Berlin, Heidelberg, 1995 .

[23] Robert Spence . Information Visualization (2nd edition) . Prentice Hall, Upper Saddle River , 2007 .

[24] E. R. Tufte . The Visual Display of Quantitative Information . Graphics Press, Cheshire, Connecticut, 1983 .

[25] E. R. Tufte . Envisioning Information. Graphics Press, Cheshire, Connecticut, 1990 .

[26] Dirk Van Der Linden and Irit Hadar . Cognitive effectiveness of conceptual modeling languages: Examining professional modelers . In Empirical Requirements Engineering (EmpiRE) , 2015 IEEE Fifth International Workshop on , pages 9 - 12 . IEEE, 2015 .

[27] Dirk van der Linden , Anna Zamansky, and Irit Hadar . A framework for improving the verifiability of visual notation design grounded in the physics of notations . In Proceedings of the 25th IEEE International Requirements Engineering Conference (RE 2017 ), Lisboa, Portugal, 2017 .

[28] Bernhard Volz and Stefan Jablonski . Omme - a flexible modeling environment . In Proceedings of the SPLASH 2010 Workshop on Flexible Modeling Tools , Reno, Nevada, USA, 2010 .