=Paper=
{{Paper
|id=Vol-2019/multi_8
|storemode=property
|title=An Example Application of a Multi-level Concrete Syntax Specification with Copy-and-Complete Semantics
|pdfUrl=https://ceur-ws.org/Vol-2019/multi_8.pdf
|volume=Vol-2019
|authors=Jens Gulden
|dblpUrl=https://dblp.org/rec/conf/models/Gulden17
}}
==An Example Application of a Multi-level Concrete Syntax Specification with Copy-and-Complete Semantics==
https://ceur-ws.org/Vol-2019/multi_8.pdf
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