An Example Application of a Multi-Level Concrete Syntax Specification with Copy-and-Complete Semantics Jens Gulden Information Systems and Enterprise Modeling University of Duisburg-Essen Essen, Germany jens.gulden@uni-due.de Abstract—This paper describes an example application of The research presented in this article demonstrates initial the Topology Type Language (TTL) to define visualizations for parts of a specification mechanism for visual representation of conceptual models with multiple type levels. Based on a multi- conceptual model content that aims to provide a higher-level level example model about the domain of bicycle products, a formal specification for a diagram visualization is developed declaration mechanism for concrete model syntax. The pre- which visually displays characteristics of bicycles and their sentation focuses on an example application, that demonstrates components according to the domain model. parts of the language without offering a complete description The result is an example specification of a diagram visual- of all language features. ization that incorporates characteristics of model elements from The remainder of Section I introduces selected language different type-levels of a domain-specific conceptual multi-level model into one consistent visualization specification that can be features of the approach, which are subsequently applied in reused to visualize entities on different abstraction levels in the Section II to an example that specifies a visual representation domain model. for a given conceptual model about the bicycle product do- Index Terms—Multi-Level Modeling, Domain-Specific Model- main. Other scientific work which is related to the presented ing Language, Diagram, Topology, Visualization, Concrete Syntax considerations is considered in Sect. III, and a conclusion in Sect. IV summarizes the discussed ideas. I. A V ISUAL F ORMALISM FOR S PECIFYING B. A Visual Language for Specifying Complex Model Repre- V ISUALIZATIONS sentations A. Visual Model Representations as Building Blocks of Infor- The Topology Type Language (TTL) is being developed to mation Systems serve the purpose of specifying visualizations of diverse kinds Conceptual models are known as essential means for de- for models. It is intended to describe model representations of scribing and constructing information systems. Expressing various visual forms, such as diagrams or graphical user inter- conceptual aspects of information systems, such as involved faces, together with corresponding human interactions. Espe- entities, operations, relationships, etc., is widely regarded as cially, the TTL is being developed as an advanced specification an appropriate construction technique to design and implement formalism for concrete syntaxes of domain-specific modeling supporting software systems. languages. Among others, it offers three central characteristics User interfaces (UIs) allow human users to operate software which go beyond the state-of-the-art of conventional concrete systems. Unlike the known importance of conceptual modeling syntax specification mechanisms: of information systems, however, the modeling of user inter- 1) The description of a visualization happens entirely in- faces is far lesser developed. Contemporary concrete syntax dependent from a model, i. e., the visualization can be declaration languages for conceptual model representation are defined without restrictions imposed by the meta-model typically either restricted to text-based structures that make of the visualized language. model content accessible to humans [20], [13], or are limited 2) The specification mechanism can refer to meta-models to a small set of visual means, which mostly are graph- with multiple type levels. It describes a notion of instan- based diagrams [8], [21] in which graphical symbols that tiating topology types in multiple refinement steps which represent entities are interconnected with lines that show can be mapped to the conceptual type-level hierarchy of relationships. Other kinds of visual representations have to a multi-level meta-model. be specified using primitive implementation-level techniques 3) The approach provides a visual formalism to describe with programming languages or visual instance editors that topologies. Although the description of topologies is an provide no abstractions with regard to efficient representation abstraction over a visualization and does not describe and re-usability of model representations [14], [15]. the visualization itself, the use of a visual language to specify topologies appears appropriate as it promises a As a consequence, it turns out to be necessary for a higher level of cognitive efficiency and advanced ease- specification mechanism for model visualizations, to introduce of-use than a textual formalism. a layer with intermediary specification concepts, which serves The term “topology” has been chosen as part of the name to decouple the structure of the described visualizations from to indicate a level of conceptual abstraction, which on the one the structure of the meta-model that is underlying to the hand uses visual constructs that express meaning with spatial (domain-specific) conceptual language the concepts of which patterns and locations, and on the other hand does not denote are visualized. The approach provided with the TTL does the resulting visualization itself, but a reflective abstraction so by abstracting visualizations to topologies, which can about it. initially be described without any references to a modeling language and its instances, and only at a later stage during the Figure 1 shows an example TTL model which will further specification of the visualization are bound to concrete model be introduced in the use case demonstration in Section II. 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. Fig. 1: Example visualization specification for a bike product Following such a copy-and-complete procedure, the trans- type formation from abstract to concrete topology type descriptions happens in an n-step transformation process, in which under- specified parts of the topology type description are completed Some central considerations that have guided the develop- step by step, until no more underspecified parts exist. Figures ment of the TTL are briefly described in the following. 1 and 7–9 show the example copy-and-complete procedure 1) Decoupling Visualization Description from Conceptual that is applied to create the topology type description for the Description: It is a major shortcoming of existing approaches example domain model. 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 graph- possible 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 Fig. 3: Notation of a Locator element (middle circle) with devices. The wide range of realization options for renderers Locator Links to two areas (dashed lines) 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 tion of a topology as abstract, and a fully specified topology as distinguished by different colors of the dashed area borders. concrete which can serve as input to a renderer, can be broken The definition of available types is indicated by small squares down to individual Areas. An Area which is not yet fully in the top section of the parent area. specified to serve as input to a renderer is considered abstract, Figure 2 shows Area notation elements nested inside each while an Area which provides all necessary information to be other, with the parent area defining two distinct types, that are rendered is concrete. applied to the nested areas. 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 Con- ceptual 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 con- figured renderer both processes children Areas and Conceptual Fig. 2: Notation of Area elements Relations. In the special case that a Renderer which has no parameters at all is assigned (e. g., a visual decorator), an Area Further details on the specification of Areas are out of the is also considered to be concrete. scope of this paper and will also be discussed elsewhere. The notation of Conceptual Relations and Conceptual Rela- 2) Locator: A Locator serves the purpose to formally de- tion Specifications is shown in Fig. 4. scribe 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 (a) (b) relations. One possibility is to recur to a 2D spatial version Allen’s interval algebra, as it is elaborated in [22], which list Fig. 4: Notation of the Conceptual Relation element inside all possible kinds of spatial relations that bodies can have on an Area element, (a) abstract requirement, (b) filled in with a diagram plane, e. g., overlapping, touching containing, etc. concrete Conceptual Relation Specification The spatial placement of a Locator inside an area and in relation to its connected areas, as it appears in a TTL diagram, 4) Completion Step: Abstract Areas can be assigned with is a pure visual hint for the topology modeler that may or Completion Step tags, that allow to specify a minimum and / or may not visually resemble the actual placement the Locator is maximum number of concretization steps, until the Abstract expressing. Area either has be made concrete, or optionally is removed. For the purposes of the example presented in Section II, a In general, Completion Step tags allow to specify any finite simple notion of locators that specify an absolute distance and sequence of modes that subsequent concretization steps have direction between two connected areas is sufficient. to conform to. The visual notation of a Locator is exemplified in Fig. 3. The three distinguishable modes of how to perform a single 3) Abstract Areas versus Concrete Areas: In order to pro- completion step on an Abstract Area are: vide a notion of instantiability of abstract topology types to • Preserve: the Abstract Area is not completed and remains concrete ones, the notion of regarding an incomplete specifica- abstract in the current completion step • Optional: the Abstract Area may be completed, remain, created with the multi-level modeling language FMMLx [10], or be deleted in the current completion step originally as a contribution to the MULTI 2017 Challenge [4]. • Complete: the Abstract Area must be completed with The model is composed of four type levels. The top- a concrete topology description, either by assigning a most level, indicated by entities with red header backgrounds, renderer to the area, describe a sub-topology in the area, models the general idea of a bicycle, by defining the basic or by referencing another area which is concrete components a bicycle is made of. These are BikeFrame, Figure 5 shows the notation of Completion Step tags as BikeFork, BikeHandlebar, and BikeWheel. The fact that an a sequence of differently drawn small circles in the upper entire bicycle is composed of these parts is expressed by the right top part of an area symbol, together with a brief legend use of a composite pattern, which provides the abstract class explaining the three different modes of appearances of the Component from which the individual part entities inherit, circles. 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, Fig. 5: Notation of Completion Step tags (shown as circles in which are particularly intended to be used for RacingBikes. the upper-right corner of an area) On the third level, a refined notion of bicycle kinds from the above level is intended to be modeled. The example demon- The sequence of Completion Step tags, from left to right, strates this by introducing the bicycle kinds ProRaceBike and represents the upcoming concretization steps that the topology ProRaceFrame on this level. type description will undergo. The very next step is configured Finally, the lowest level shown in the example model by the left-most Completion Step tag in the sequence. When a contains bicycle product types as they could appear in the topology type description is transformed to a next concretion catalog of a bicycle vendor. The example model contains the step, all Areas get copied, and the left-most Completion Step product types ChallengerA2XL, which is a ProRaceBike, and tag is removed from the sequence in any of the areas. the RocketA1XL bicycle frame as an instance of ProRace- Frame. From these product type, concrete instances of physical The ability to impose constraints on anticipated future bicycle entities can be instantiated, which would resemble the concretization steps provides a mechanism which stands in notion of concrete bicycles such as “Peter’s yellow racing analogy to the specification of intrinsic features in a multi- bike”. Instances of this kind are considered to be created level modeling language [10]. This means, the sequence of during runtime use of the model, and are not included in the concretization steps can be defined along the instantiation example. levels of entities from a multi-level conceptual domain model. The model in the TTL shown in Fig. 1 is the result Using Completion Step tags, the demand for when to fill of a multi-step transformation from a more general TTL in Conceptual Relation specifications can be delayed in a model to a concrete visualization description for “Pro Racing controlled way. A topology type definition can make use of Bikes”. The procedure of the transformation is described in the this to define Conceptual Relations on the basis of intrinsic following, starting with the initial TTL model shown in Fig. 7 attributes on higher levels of conceptual abstractions in the that generally describes the notion of any bike visualization domain model, for which the concrete values will later be without a connection to concrete data to be rendered. derived from slot values of entities on lower levels. This makes the TTL a visualization specification approach that integrates A. Initial Topology Type Model the description of visualizations for conceptual entities on The TTL model in Fig. 7 provides a general description different levels of conceptual abstractions into one unified of what a visualization of a bike product could be composed specification mechanism for model visualizations. It allows of. The description is independent from any binding to model for an efficient declaration of concrete syntaxes for domain- content yet, but by specifying several empty Conceptual Rela- specific type models, together with concrete syntaxes for their tionship elements in its area elements, it already suggests what instance models across multiple type levels. domain characteristics should influence a resulting rendered visualization. The Completion Step elements in the upper-right corners of II. E XAMPLE A PPLICATION OF A B IKE P RODUCT each area part suggest how to further complete this topology V ISUALIZATION BASED ON A M ULTI -L EVEL C ONCEPTUAL type description in the next concretization step. The outer D OMAIN M ODEL “Bike” area specifies a single further Completion Step, which The example domain model that conceptually describes the demands to concretize this area specification in the next bicycle product domain is displayed in Fig. 6. It has been subsequent step. The other areas each define three subsequent Fig. 7: Example visualization specification for the generic Fig. 8: Example visualization specification distinguishing the notion of a bike, as modeled on the highest abstraction level notion of general types of bikes (racing/mountain/city), as in the domain model modeled on the second-highest abstraction level in the domain model concretization steps, with the first demanding to leave the area untouched in the next step. description in Fig. 8 and enhances it in order to visualize specific characteristics of racing bikes described in the domain B. First concretization step model. To do so, additional Conceptual Relations are added to As a consequence, in the next step the outer “Bike” area is the “Frame” area which represent the domain fact that the made concrete by filling in the previously empty Conceptual frames of racing bikes are described by three lengths values. Relation element “background” with a binding that provides Adding further Conceptual Relations is possible, because the input data from the visualized model as input for the renderer Conretization Step specifications for the current step allows that is configured for the “Bike” area. In case of the example optional modification to the area. The resulting topology type at hand, this could mean that either based on the class name description after this step is displayed in Fig. 9. of a bike entity to be displayed, or as a result of combining the suitedForToughTerrains and suitedForRaces slot values, a D. Third concretization step suitable name for a background image is calculated. E. g., a The remaining Concretization Step elements in the model in renderer could be configured which displays a background Fig. 9 all demand for a completion of the yet underspecified image of a mountain scenery for mountain bikes, a street areas. As a consequence, the final modifications to the model scenery for city bikes, and a racing track for racing bikes. in the third concretization step consist of filling in the empty There are diverse options for realizing such a binding on the Conceptual Relation placeholders with bindings to concrete implementation level, further details are not discussed here. input value that can be derived from domain model entities on Figure 8 shows the topology model after the first concretion abstraction level 1. According to the declarations of intrinsic step has been performed. attributes in the domain model, this is the level where the If at this point also renderers are attached to the other information is present that distinguishes visual characteristics areas, which could render a generic visualization of the of different bike products. respective elements they are to display even without concrete Figure 1 shows the resulting concrete renderable topology input values (e. g., by using pre-defined default values as type description for “Pro Racing Bikes”, as described in the long as the Conceptual Relations for the respective area are domain model. not fully specified), then the visualization description could already be used for rendering a generic, product-independent, III. R ELATED W ORK visualization of a bike. Specifying concrete syntaxes for visual diagram languages is pivotal to the design of domain-specific languages (DSLs). C. Second concretization step As a consequence, most of the DSL creation approaches To provide a further refinement of the visualization speci- and tools available offer means for defining concrete diagram fication, the next concretization step reuses the topology type syntaxes. Three well known representatives of the category 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 lan- guage. 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 specifica- tion mechanism for visualizations offers a formalism that incorporates the notion of graph homomorphisms and type homomorphisms to check the conformance of a visualizations Fig. 9: Example visualization specification incorporating char- across multiple type levels. However, the expressiveness of the acteristics of “Pro Racing Bikes”, as modeled on level 2 in the visualizations themselves is fairly limited, and the specification domain model formalism is restricted to graph-based diagrams only, like many of contemporary concrete syntax specification mecha- nisms. of meta-modeling environments which offer support in vi- In XM ODELER [5], [6], conceptual multi-level modeling ca- sual language creation are M ETA E DIT + [16], the E CLIPSE pabilities are combined with a non-visual specification mecha- G RAPHICAL M ODELING F RAMEWORK (GMF) [8], and S IR - nism for model representation and interaction called XT OOLS. IUS [7]. These tooling environments offer mechanisms to While this approach gives flexibility over specifying model specify conceptual features of a domain, e. g., with a meta- representations of various types, which are not necessarily model, together with functionality to define visual represen- restricted to graph diagrams, the current version of XT OOLS tations for the domain concepts. M ETA E DIT + includes a does not specifically take into account multi-level capabilities simple graphical icon editor that allows to paint graphical of the underlying conceptual models. symbols to represent domain concepts. GMF also supports The M ELANEE [1] domain-specific language workbench is the definition of graphical symbols composed out of drawing a representative of a multi-level modeling environment, which primitives, however, the specification of the symbols happens incorporates a visual language design approach that allows to non-visually in a tree-view editor. S IRIUS also uses a tree- take into account multiple type levels. The approach makes view configuration editor for all parameters of its diagram use of an aspect-oriented declaration mechanism, by which definitions, with the significant difference to GMF that the parts of a visualization specification can be equipped with concrete syntax definition is interpreted at run-time without join-points for elements that are to be specified or modified the need for code generation. Any changes that are made to later in a refined version of the visualization [12]. This way, a S IRIUS diagram definition become immediately visible in a basic characteristics of reusability and refinement of existing corresponding editor. visualizations for more specific type levels are made available. The general approach in these tools is to enhance the The visual paradigm of the diagrams languages that can be conceptual description in the meta-model with additional infor- defined, however, remains limited to a be represented by a set mation about the visualization that gets attached to the meta- of graph-nodes and corresponding line connectors. model elements. This happens either by directly attaching Despite the prominent role of diagram languages in In- information about how to visualize a concept in the meta- formation Systems, theoretic research about concrete syntax model (e. g., by the use of annotations), or by employing a specification is just about to be established as a relevant mapping model that externally attaches additional information perspective on the core objectives of the discipline. Considera- to meta-model elements. In both cases, one has to be aware tions about the “Physics of Notation” [21] provide one source that a direct annotation of meta-model elements limits the in Information Systems science that summarizes fundamental range of possible visualizations to describe, as the meta-model principles of designing visual diagram languages. Diverse structure pre-forms the possible structure of visualizations points of critique have been brought forward against the [14], [15]. None of the approaches embedded in existing narrow perspective taken in by [21]. Especially the potential tools has been developed from the very beginning based for leveraging the capabilities of the human visual perception on theoretical considerations about the demands towards an apparatus, which allows for fast, parallel, and scalable cogni- tive processing of visual pattern structures, is not sufficiently [8] Eclipse Foundation. Graphical modeling framework (gmf). http://www. taken into account [26], [27]. eclipse.org/modeling/gmf/. [9] Stephen Few. Information Dashboard Design: The Effective Visual Beyond the Information Systems discipline, a wider range Communication of Data. O’Reilly, Sebastopol, CA, 2006. of scientific contributions about information visualization can [10] Ulrich Frank. Multi-level modeling - toward a new paradigm of be found. Classical work about diagrams from before the age conceptual modeling and information systems design. Business & Information Systems Engineering (BISE), 6(3), 2014. of computers has been contributed by [2], [24], [25]. More re- [11] Ulrich Frank and Stefan Strecker. Beyond erp systems: An outline of cent work about the effectiveness of interactive visualizations self-referential enterprise systems. Technical Report 31, ICB Institute originates from fields such as interaction design and journalism for Computer Science and Business Information Systems, University of Duisburg-Essen, Essen, April 2009. [3], [17], [19], [23], or information dashboard design [9]. The [12] Ralph Gerbig. Deep, seamless, multi-format, multi-notation definition research demand for incorporating the perspective on cognitive and use of domain-specific languages, 2017. efficiency into Information Systems research has been pointed [13] Hans Grönniger, Holger Krahn, Bernhard Rumpe, Martin Schindler, and Steven Völkel. Textbased modeling. CoRR, abs/1409.6623, 2014. out as well [14], [15]. [14] Jens Gulden and Hajo A. Reijers. Toward advanced visualization techniques for conceptual modeling. In Janis Grabis and Kurt Sandkuhl, IV. C ONCLUSION editors, Proceedings of the CAiSE Forum 2015 Stockholm, Sweden, June 8-12, 2015, CEUR Workshop Proceedings. CEUR, 2015. The example developed in this paper has given an impres- [15] Jens Gulden, Dirk van der Linden, and Banu Aysolmaz. Requirements sion of how a visual formalism for specifying visualization for research on visualizations in information systems engineering. In Proceedings of the ENASE Conference 2016, April 27-28 2016, Rome, types that can represent model content on multiple levels of 2016. abstraction can work. Core elements of the visual Topology [16] Steven Kelly and Juha-Pekka Tolvanen. Domain Specific Modeling: Type Language (TTL) have been introduced, without, however, enabling full code-generation. Wiley, 2008. [17] Andy Kirk. Data Visualization: a successful design process. Packt going too much into details to keep the example description Publishing, Birmingham, 2012. appropriately compact. [18] Yngve Lamo, Xiaoliang Wang, Florian Mantz, Wendy MacCaull, and The TTL integrates the description of visualizations for con- Adrian Rutle. DPF Workbench: A Diagrammatic Multi-Layer Domain Specific (Meta-)Modelling Environment, pages 37–52. Springer Berlin ceptual entities on different levels of conceptual abstractions Heidelberg, Berlin, Heidelberg, 2012. into one unified specification. This allows for an efficient reuse [19] Isabel Meirelles. Design for Information. Rockport Publishers, Beverly of existing concrete syntaxes, and makes it possible to specify (MA), 2013. [20] Bernhard Merkle. Textual modeling tools: Overview and comparison visual languages for domain-specific type models as well as of language workbenches. In Proceedings of the ACM International their instance models across multiple levels in the same place. Conference Companion on Object Oriented Programming Systems Lan- Other aspects of the TTL with respect to its applicability guages and Applications Companion, OOPSLA ’10, pages 139–148, New York, NY, USA, 2010. ACM. to presentation and interaction schemes beyond mere diagram [21] Daniel L. Moody. The “physics” of notations: Toward a scientific visualizations, toward describing entire applications’ user in- basis for constructing visual notations in software engineering. IEEE terface presentation and interactions, will be part of future Transactions on Software Engineering, 35(6):756–779, 11/12 2009. [22] Mohammad Nabil, John Shepherd, and Anne H. H. Ngu. 2D projection work. The TTL might as well be suited for use in self- interval relationships: A symbolic representation of spatial relationships, referential enterprise system scenarios [11], where dynami- pages 292–309. Springer Berlin Heidelberg, Berlin, Heidelberg, 1995. cally configurable views on instance models serve both as tools [23] Robert Spence. Information Visualization (2nd edition). Prentice Hall, Upper Saddle River, 2007. for control and analysis. The TTL could play a role in such a [24] E. R. Tufte. The Visual Display of Quantitative Information. Graphics setting by providing a visual specification mechanism which Press, Cheshire, Connecticut, 1983. allows to define instance visualizations at run-time based on [25] E. R. Tufte. Envisioning Information. Graphics Press, Cheshire, Connecticut, 1990. existing reusable specifications of type-level visualizations. [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 Inter- R EFERENCES national Workshop on, pages 9–12. IEEE, 2015. [27] Dirk van der Linden, Anna Zamansky, and Irit Hadar. A framework [1] Colin Atkinson and Ralph Gerbig. Flexible deep modeling with melanee. for improving the verifiability of visual notation design grounded in the In Stefanie Betz Ulrich Reimer, editor, Modellierung 2016, 2.-4. März physics of notations. In Proceedings of the 25th IEEE International 2016, Karlsruhe - Workshopband, volume 255, pages 117–122, Bonn, Requirements Engineering Conference (RE 2017), Lisboa, Portugal, 2016. Gesellschaft für Informatik. 2017. [2] J. Bertin. Semiology of Graphics: Diagrams, Networks, Maps. Walter [28] Bernhard Volz and Stefan Jablonski. Omme – a flexible modeling de Gruyter, Berlin, 1974. environment. In Proceedings of the SPLASH 2010 Workshop on Flexible [3] Alberto Cairo. The Functional Art. Voices That Matter. Pearson Modeling Tools, Reno, Nevada, USA, 2010. 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/. Fig. 6: Example Conceptual Model of a Bike Product Domain