Concrete Syntax: A Multi-paradigm Modelling...

Concrete Syntax: A Multi-paradigm ModellingApproach

Yentl Van TendelooUniversity of Antwerp

Antwerp, [email protected]

Simon Van MierloUniversity of Antwerp


Bart MeyersUniversity of Antwerp

Antwerp, BelgiumFlanders Make vzw

[email protected]

Hans VangheluweUniversity of Antwerp


Flanders Make vzwBelgium

McGill UniversityMontreal, [email protected]

AbstractDomain-Specific Modelling Languages (DSLs) allow domainexperts to create models using abstractions they are mostfamiliar with. A DSL’s syntax is specified in two parts: the ab-stract syntax defines the language’s concepts and their allowedcombinations, and the concrete syntax defines how those con-cepts are presented to the user (typically using a graphicalor textual notation). However important concrete syntax isfor the usability of the language, current modelling tools of-fer limited possibilities for defining the mapping betweenabstract and concrete syntax. Often, the language designeris restricted to defining a single icon representation of eachconcept, which is then rendered to the user in a (fixed) graph-ical interface. This paper presents a framework that explicitlymodels the bi-directional mapping between the abstract andconcrete syntax, thereby making these restrictions easy toovercome. It is more flexible and allows, amongst others,for a model to be represented in multiple front-ends, usingmultiple representation formats, and multiple mappings. Ourapproach is evaluated with an implementation in our proto-type tool, the Modelverse, and by applying it on an examplelanguage.

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies are notmade or distributed for profit or commercial advantage and that copies bearthis notice and the full citation on the first page. Copyrights for componentsof this work owned by others than ACM must be honored. Abstracting withcredit is permitted. To copy otherwise, or republish, to post on servers or toredistribute to lists, requires prior specific permission and/or a fee. Requestpermissions from [email protected]’17, October 23–24, 2017, Vancouver, Canada© 2017 Association for Computing Machinery.ACM ISBN 978-1-4503-5525-4/17/10. . . $15.00https://doi.org/10.1145/3136014.3136017

CCS Concepts • Software and its engineering → Domainspecific languages; Integrated and visual development envi-ronments; • Computing methodologies → Model develop-ment and analysis;

Keywords Concrete Syntax, Abstract Syntax, Visual, Plot-ting, Simulation, Model Transformation

ACM Reference Format:Yentl Van Tendeloo, Simon Van Mierlo, Bart Meyers, and HansVangheluwe. 2017. Concrete Syntax: A Multi-paradigm ModellingApproach. In Proceedings of 2017 ACM SIGPLAN InternationalConference on Software Language Engineering (SLE’17). ACM,New York, NY, USA, 12 pages.https://doi.org/10.1145/3136014.3136017

1 IntroductionDomain-Specific Modelling Languages (DSLs) are definedby their abstract and concrete syntax [13, 24]. The abstractsyntax defines the concepts of the language, which can beinstantiated and used as the building blocks of models. Forexample, the abstract syntax of UML Class Diagrams definesconcepts such as Class, Association, and Attributes. The con-crete syntax defines the visualization, or rendering, of theseabstract syntax concepts. For example, the concrete syntax ofUML Class Diagrams defines the mapping of a Class instanceto a rectangle with the name of the class on top and a list ofall attributes below it. Significant restrictions exist in currenttools for the definition of concrete syntax, thereby restrict-ing the language engineer, who is responsible for creatinglanguages that are intuitive to use for domain experts.

Code-based solutions (i.e., tool plugins) are now oftenused to implement advanced concrete syntax functionality.While feasible, the creation of plugins is not always for thefaint-hearted [18], as it relies on tool details (e.g., API) and

https://doi.org/10.1145/3136014.3136017

https://doi.org/10.1145/3136014.3136017

SLE’17, October 23–24, 2017, Vancouver, Canada Yentl Van Tendeloo et al.

advanced functionality becomes non-intuitive to express. Ad-ditionally, creating the concrete syntax is part of the job ofthe language engineer, who is not necessarily an expert intool plugin creation. To address these problems, we present adifferent angle of attack, where we apply the Multi-ParadigmModelling (MPM) [27] approach to concrete syntax. MPMfacilitates the analysis, transformation, simulation, optimi-sation, documentation, evolution, integration, platform inde-pendence, and code synthesis of artefacts. Explicit modellingof complex systems includes the explicit modelling of mod-elling languages; in MPM, they often become part of thesoftware development cycle (cfr. domain-specific languages).This means that abstract syntax, semantics, and concrete syn-tax need to be modelled explicitly. We identify several limi-tations in the concrete syntax of state-of-the-art approaches,which can now only be done by creating (coded, language-specific) plugins. All these limitations become easy to solveusing our MPM-based approach, without the need for plugins.

We identify five common limitations: (1) A single front-end (or visualization tool) is provided, which is largely awareof the concepts of (meta-)modelling. Existing visualizationlibraries therefore require a lot of additional code, as these(meta-)modelling concepts need to be introduced. (2) A sin-gle representation is used for all languages, such as oneconsisting of rectangles and lines, often arranged in a graph-like manner. While these can be used as primitives for manytypes of visualization, some models are ideally expressedusing a plot, or completely different modes of perceptual-ization. Note the use of the term perceptualization, as wedo not wish to limit ourselves to visual representations ofmodels, but want to include, for example, text and soundas well. (3) A single mapping to the representation is used,such as to UML Object Diagrams, which can be used for all(graph-based) models, but is seldom the most appropriate.Even when a domain-specific concrete syntax is defined, itis often restricted to only one such mapping. (4) No extraconcrete syntax operations are available, such as domain-specific lay-outing [7], which aids users in understanding themodel. As these algorithms are domain-specific, they mustbe part of the specification of the domain-specific language.(5) A one-to-many mapping between abstract syntax and thevisualized model is used, as an icon definition is used. Whilethis often suffices, many-to-many mappings offer additionalpossibilities to the language engineer.

The remainder of this paper is organised as follows. Sec-tion 2 presents an example domain-specific language, motivat-ing the need for a flexible concrete syntax. Section 3 presentsour framework, describing the different phases. Section 4presents the flexibility that we achieve with our approach,linking back to the motivating example. Section 5 evaluatesour approach using a prototype implementation. Section 6discusses identified shortcomings and further extensions ofour approach. Section 7 presents related work. Section 8 con-cludes the paper.

ICBlockBlock

Addition Multiplication Derivation

Negation Inversion Integration

Constant

value : Float

Probename : String

Delay

LinkInitialCondition

Figure 1. Causal Block Diagrams metamodel.

2 Motivating ExampleTo show the need for more flexibility in concrete syntax defini-tions, we use the Causal Block Diagrams (CBD) language [2]as a running example. While this language can be createdand used in current tools, its concrete syntax can not easilybe implemented as we would like. For an optimal interactionbetween the modeller and the model, several extensions toconcrete syntax are proposed next. The previously mentionedrestrictions are now elaborated on in the context of this moti-vating example: the CBD language. Note that our contributionlies in the explicitly modelled framework for concrete syntax,and not in the extensions offered for this specific domainspecific language.

2.1 Causal Block DiagramsThe CBD language is a simple yet realistic language, oftenused to model complex mathematical equations. The languageconsists of a set of blocks which can have inputs and outputs.Connections between these blocks carry a signal, which theblocks manipulate. The types of blocks include simple blocks,such as addition blocks, but also more advanced blocks, suchas integration blocks. The CBD metamodel, shown in Fig-ure 1, lists all possible blocks and their configuration.

An example instance of the language, with an often usedconcrete syntax, is shown in Figure 2. The example models amass suspended by a vertical spring. We consider two forces:the gravitational force and the restoring force of the spring.The set of equations is shown in Equation 1.⎧⎪⎪⎪⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎪⎪⎪⎩

𝐹spring = 𝑘 · 𝑦𝐹gravity = 𝑚 · 𝑔𝐹net = 𝐹gravity − 𝐹spring

𝑎 = 𝐹net

𝑚𝑑𝑣𝑑𝑡 = 𝑎𝑑𝑦𝑑𝑡 = 𝑣

(1)

The semantic domain of CBDs is a trace language whoseinstances contain the values incoming in the various probeblocks, paired with the simulation time at which the valuewas recorded. An appropriate perceptualization of a real valuechanging over time is a plot, as shown in Figure 3. From thisfigure, the evolution of the value throughout time becomesimmediately obvious. In our case, there are two plots: for thevelocity of the mass (𝑣) and the current position (𝑦).

Concrete Syntax: A Multi-paradigm Modelling Approach SLE’17, October 23–24, 2017, Vancouver, Canada

y0

v0

k X

m X ∫ ∫1x

g X +- v y

Figure 2. Example Causal Block Diagrams model of a masssuspended on a vertical spring.

0 5 10 15 20t (s)

10

0

10

v (

cm/s

)

Spring Velocity

0 5 10 15 20t (s)

0

10

20

y (

cm)

Spring Extension

Figure 3. Plotted trace of the CBD model in Figure 2, with𝑘 = 1, 𝑚 = 1kg , 𝑦0 = 20cm , 𝑣0 = 1 cm

𝑠 , and 𝑔 = 10 cm𝑠2 .

2.2 Existing LimitationsAs previously introduced, many limitations currently exist inthe perceptualization and rendering of models. For each ofthese limitations, we present a potential requirement of theCBD concrete syntax, and how current tools fail to adequatelyaddress them. In our related work section, we further discussspecific tools and the techniques they use.

2.2.1 Multiple GUIsWhen modelling CBDs, different users might have differentpreferences in how they interact with their model. Some usersprefer an online browser-based application, requiring no in-stallation nor local code execution, while other users preferan offline application which executes locally. Nonetheless,the model should be visualized in (almost) the same way,similar to how it is shown in Figure 2. As these users want tocollaborate, they should share the same back-end, while theirfront-ends are different.

Although many (meta-)modelling tools explicitly make thedistinction between a back-end and front-end, or expose amodelling API, the distinction between front-end and back-end is often not as expected. Most of the time, the front-ends still need to be aware of most meta-modelling concepts,as they receive the abstract syntax model, the metamodel,

(0; 20.0)

(0.1; 20.1)(0.2; 20.1)(0.3; 20.0)

(0.4; 19.8)

(0.5; 19.5)

y(0; 1.0)

(0.1; 0.0)

(0.2; -1.01)(0.3; -2.02)

(0.4; -3.02)

(0.5; -4.0)

v

Figure 4. Graphical representation of the trace in Figure 3.

y0

v0

k ∏

g ∏ ∑ v y-x

m ∏x-1 1s

1s

Figure 5. Same model as in Figure 2, but with other icons.

and a concrete syntax definition. Changes to the model arethen performed in the front-end, and only the abstract syntaxchanges are propagated to the back-end. Multiple front-endstherefore duplicate this modelling code, while it should onlybe concerned with the binding to the platform (e.g., TkInter).

2.2.2 Multiple Perceptualization FormatsVisualizing CBDs is completely different from visualizingtheir semantics. The semantics of a CBD, expressed as atrace of its signals, is ideally shown as a plot, instead of agraph-like structure. A possible rendering of a trace with thesame perceptualization format as the CBD model is shownin Figure 4. Clearly, the trace is better visualized as a plot,previously shown in Figure 3: the plot immediately shows theoscillating behaviour, which cannot easily be derived fromthe set of tuples. Similarly, some modellers prefer text over agraphical representation [16], though all representations havetheir limitations [10].

While different front-ends exist today, most are restricted toa graph-like or text-only representation of the models. Otherperceptualizations, such as plotting or sonification, reasonabout different concepts, such as datapoints (for plots) ormusic notes (for sonification), instead of graphical primitives.

2.2.3 Multiple MappingsThe ideal visualization of a CBD model depends on the do-main expert looking at it, even when the visualization is rela-tively similar (e.g., both block-based). Some elements mighthave a different icon attached to them, depending on thebackground of the user. For example, users with a Simulink®

background are familiar with the symbols 1/𝑠 for an integra-tor, and Σ for an addition block. Other users might preferthe symbols

∫and +, respectively. A visualization with an

alternative set of icons is shown in Figure 5.


k

g

my0v0

X

X

+

X

∫-

1x

v

∫

y

Figure 6. Circle lay-out version of the model in Figure 2.

Even though many tools nowadays support the definitionof custom icons for a language, there is often only one pos-sible visualization attached to it. As such, when a differentvisualization is required, the complete model, including ab-stract syntax, must be copied. While some tools allow forworkarounds, such as defining both icons and only show-ing one, depending on a configuration option, this is not anelegant solution.

2.2.4 Lay-OutingThe ideal lay-out of CBD elements is closely related to itsdataflow. If the flow goes left-to-right, with the exceptionof feedback loops (e.g., Figure 2), the semantics is easier tointerpret than if the position seems random, as in a circle lay-out [17] (e.g., Figure 6).. The flow of the data, and thereforethe ideal lay-out, is specific to CBDs, as it depends on thetopological sort of the dependency tree [2]. This is specificto CBDs and should therefore not be hard-coded in either theback-end or front-end: it should be defined and maintainedby the language engineer.

While current tools often implement generic lay-out algo-rithms, such as circle and spring lay-out, they have no supportfor lay-out algorithms provided by the language itself (i.e.,domain-specific lay-out algorithms). Lay-outing can be gen-eralized as a “post-processing operation” on the renderedmodel, where the visualized model is reordered. There is thusa need to define algorithms on the rendered model, whichshould ideally be included in the concrete syntax model.

2.2.5 Many-to-many Mapping and ParsingWhile we have previously allowed for multiple mappings,thereby allowing for a single element to be visualized in multi-ple ways, the modeller might have additional preferences. Forexample, CBDs are sometimes visualized with a conjoinedaddition/subtraction block (e.g., in Ptolemy/Kepler [1]): asingle block has an addition and subtraction port, where allsignals are summed, but the signals on the subtraction port

y0

v0

m ∫ ∫X

÷

kX

÷

gv y

+

-X

÷

Figure 7. Alternative representation of the model in Figure 2,now using a more complex mapping.

are negated first. This is syntactic sugar for a single additionblock, with negation blocks for each input on the subtractionport, as shown in Figure 7. Whichever representation is useddepends on the domain expert, though we want the abstractsyntax to be identical, independent of the used representation.

While this problem seems highly related to the multiplemappings problem, it is fundamentally different: the con-joined addition/subtraction block is a single concrete syntaxelement with multiple abstract syntax elements underlying it.Indeed, each connection to the subtraction port has a (hidden)negator block in the abstract syntax. While it is possible tochange the abstract syntax, this would create problems forthe other operations, where the negation block is explicitlypresent. The problem is therefore the restriction of many toolsto a one-to-many mapping: a single abstract syntax element isrendered by several concrete syntax elements, independentlyof other abstract syntax elements. A possible workaround isthe introduction of an intermediate language, which expandsor collapses the addition/subtraction block, though such an in-termediate language causes additional consistency problems.

3 Explicitly Modelling Concrete SyntaxWe now present our multi-paradigm modelling approach toconcrete syntax, where we explicitly model all aspects.

Our approach makes a clear distinction between the re-sponsibilities of the back-end and front-end. The back-endis responsible for all (meta-)modelling related concepts, in-cluding how models are perceptualized and comprehended.The front-end is responsible only for how this perceptiblemodel is rendered using a specific platform, such as TkInter.Instead of transferring the abstract syntax of the model (usingdomain-specific concepts, such as Constant), the back-endtransforms this model to the MMRender language (which usesperceptualization concepts, such as Ellipse).

Our approach is centered around four activities, as shownin Figure 8: Perceptualization, Rendering, Recognition, andComprehension. Our approach is independent of how theseactivities are implemented (e.g., in code, using model trans-formations, or manually).


MMAS MMRender

MAS MRender

MMCL

comprehend

perceptualize

BACK-END

<<AS operations>>

FRONT-END

AddBlock

AddConnectionMMRender

MRendertransfer render

recognize

implements

platform

Figure 8. Overview of the approach.

In the remainder of this section, we elaborate on each stepof our approach, where we link to a minimal example inthe context of CBDs, shown in Figure 9. We start at the topleft in the figure, with M𝐴𝑆 . M𝐴𝑆 is first (1) perceptualized,resulting in an MRender. For example, instances of the Constantclass are translated to a Group containing an Ellipse andText instance. This MRender is (2) transferred to the front-endin some way, which is independent of our approach. In theexample, a JSON serialization of the source model is shown.The front-end has a copy of MRender, which is (3) rendered forthat specific platform. For example, all instances of Ellipseare iterated over, and a create oval TkInter function isinvoked. The TkInter front-end listens to user events (e.g.,mouse clicks), thereby (4) altering the rendered model. Forexample, the text entry “1” is altered to “2”. Such changesare (5) recognized (e.g., via callbacks), resulting to changeson MRender. For example, the Text instance has its attributetext updated to “2”. Changes are (2) transferred to the back-end again, this can be incremental or overwrite the completemodel. Finally, the new MRender is (6) comprehended, therebychanging M𝐴𝑆 . For example, the changed text results in anupdate to the value of the constant block. Each of these stepsis further elaborated on next.

3.1 PerceptualizationThe first step to our approach is perceptualization, where amodel in a domain-specific language MM𝐴𝑆 is mapped to aperceptualization language MMRender. This defines how themodel is presented to the user. For each language that wewant to visualize, it is important to define a perceptualizationactivity, which is the concrete syntax definition.

This activity needs to map to an MMRender, which definesthe mode of presentation to the user. MMRender defines the plat-form primitives that can be used, such as Ellipse, Rectangle,and Line. In our example we focus on graphical languages, asthis is easiest to present on paper, and therefore our MMRender

is defined as in Figure 10. Note that this MMRender is not yetlinked to any specific platform, such as TkInter or ScalableVector Graphics (SVG). The used concepts are generic tomany graphical visualization libraries.

Our approach is not restricted to any specific MMRender,although we demonstrate our approach using a metamodelfor graphical visualization. It is straightforward to come upwith different MMRender specifications, such as one for plots(e.g., for signal traces), text (e.g., for action language), oreven sound (e.g., for music sheets [19]). We envision a smalllibrary of different kinds of MMRender to capture all neces-sary perceptualizations. Of course, a front-end should also bedefined which can render models in that language.

Traceability can be constructed between M𝐴𝑆 and MRender,to be used for incremental perceptualization, where we onlyperceptualize elements in M𝐴𝑆 that have no associated ele-ments in MRender yet. This is the reason for the loop in Figure 8,where perceptualization takes in both M𝐴𝑆 and the currentMRender. It remains up to the language engineer whether ornot to use incremental perceptualization.

In our example, we transform the single CBD instance ofConstant to instances of Group, Ellipse, and Text, conformingto the MMRender metamodel in Figure 10. This defines howconstant blocks are to be presented to the user: as a group ofan ellipse and some text. We defined this activity using modeltransformations. An example model transformation rule isshown in Figure 11, which creates a Group, Ellipse, and Textinstance for each Constant element that not yet has an asso-ciated group. The values of their attributes are hidden due tospace restrictions, but are mostly trivial (e.g., the colour of theellipse and value of the text). In a model transformation rule,the Left-Hand Side (LHS) pattern is matched in the model,and is replaced by the Right-Hand Side (RHS), unless theNegative Application Condition (NAC, shown in the dashedrectangle) also matches. The (purple) numerical annotationslink elements in the LHS to elements in the RHS.

3.2 Model TransferAs there is an explicit difference between the back-end and thefront-end, there needs to be a way to transfer the models. Wewant this to be as general as possible, as both the back-end andfront-end could be physically distributed and implementedin different programming languages. In our example, themodel is serialized using JSON, and transferred over networksockets. Nonetheless, our approach is independent of theimplementation details of model transfer, and we therefore donot elaborate on this aspect. It is only important that an exactcopy of MRender is present on both the back-end and front-end;this can be achieved in many different ways.

Note that, thanks to our approach, only models in theMMRender language must be transferred, potentially allowingfor additional optimizations in the serialization.

3.3 RenderingWhen the MRender arrives at the front-end, it needs to be pre-sented to the user. This is done by mapping the concepts ofMRender to the platform operations responsible for the pre-sentation. As such, the front-end’s interface is described in


MRENDERMAS

MRENDERMAS

:Constant

value = 1

[{"type": "Group", "x": 30, "y": 0, "__asid": "__100", "__id": "__200",},{"type": "Text", "x": 3, "y": 2, "lineWidth": 1, "lineColour": "Black", "text": "1", "__asid": "__101", "__id": "__201",},...]

:Group

x = 30y = 0

:Text

x = 3y = 2lineWidth = 1lineColour = "Black"text = "1"

:Ellipse

x = 0y = 0lineWidth = 1lineColour = "Black"fillColour = "LightYellow"width = 10height = 10

:Group

x = 30y = 0

:Text


:Ellipse


1

2

:Group

x = 30y = 0

:Text


:Ellipse


[{"type": "Group", "x": 30, "y": 0, "__asid": "__100", "__id": "__200",},{"type": "Text", "x": 3, "y": 2, "lineWidth": 1, "lineColour": "Black", "text": "2", "__asid": "__101", "__id": "__201",},...]

:Group

x = 30y = 0

:Text


:Ellipse


:Constant

value = 2

(1) perceptualize (2) transfer(3) render

(4) alter

(5) recognize(6) comprehend (2) transfer

back-end front-endcommunication

Figure 9. Overview of the approach with an example for CBDs.

GraphicalElement

x : Naturaly : Natural

Group

contains

LineElement

lineWidth : NaturallineColour : String

Shape

fillColour : Stringwidth : Naturalheight : Natural

Rectangle

Ellipse

SVG

data : String

Text

text : String

Figure

width : Naturalheight : Natural

targetX : NaturaltargetY : Naturalarrowhead : True

Line

Figure 10. 𝑀𝑀𝑟𝑒𝑛𝑑𝑒𝑟 for graphical visualization.

Ellipse

Text4

5

6

7

Constant

Group

1

2

3

Group

Constant1

2

3

Constant1

Figure 11. Example rule for CBD perceptualization.

a platform-independent way using MMRender. It is thus im-portant that the front-end and back-end agree on the sameMMRender. Rendering can be seen as a transformation fromconcepts in MMRender to concepts in the platform.

While our approach explicitly represents both MRender andMMRender in the front-end, this does not necessarily have to bethe case. For example, the front-end could just iterate over the

JSON serialization it gets in, directly invoking platform func-tions. And even while the models are not explicitly present inthe front-end, the front-end still makes implicit use of thesemodels and the back-end ensures well-formedness.

In our example, the front-end maps concepts such as El-lipse to the create oval TkInter function, also translatingthe attributes to arguments for that function. The complex-ity of the mapping on how close the concepts of MMRender

match those of the platform. For example, if a platform doesnot support rectangles, elements of the Rectangle class haveto be mapped internally to four seperate lines (or whateveroperation the platform provides).

3.4 AlteringSome front-ends allow altering the rendered model in someway. Straightforward examples are moving around elements,changing their size, and so on. Such changes occur in theplatform, and are based on platform events (e.g., button press,mouse move, mouse click), which need to be mapped tomodel operations. As the detection of such events is highlyplatform-dependent, and can be considered an implementa-tion detail, we do not elaborate on this. For our approach, itis only important that the rendered model can be altered, aswe are independent of how these changes actually occur.

Even though simple operations are common, altering themodel can happen in any way, for example through sketch in-terpretation [3, 15], where sketches are recognized as changesin the platform (e.g., a drawing of a circle is mapped to theTkInter circle concept).


3.5 RecognitionWhen changes are made to the rendered model, these changeshave to be propagated to the MRender, as this is the commonexchange format between back-end and front-end. While thismapping is often trivial, it depends on the match betweenMMRender and the platform concepts. For example, for a trivialmapping, moving a rectangle in the platform merely maps tomoving that same rectangle element in MRender. For a complexmapping, however, the rectangle might be a set of lines in theplatform, where moving one of these lines affects the threeother lines as well.

Recognition does not attach semantics to the change. In-deed, changing the value of the text merely alters the textvalue, and the associated constant block still has the value 1.As such, recognition is limited to syntactical changes.

In our example, the mapping is trivial: updating the textvalue in the platform merely requires us to update the textattribute of the Text instance in MRender.

3.6 ComprehensionComprehension maps changes on MRender back to changeson M𝐴𝑆 . As such, it attaches semantics to the change thatwas made. Note that this operation often makes use of thetracability information that was previously created duringperceptualization, as it needs to map between both formalisms.Therefore, comprehension can make use of the original M𝐴𝑆 ,being the reason for the loop in the overview figure.

Often, a front-end only allow syntactical changes that haveno influence on semantics. For example, moving an elementof a topological formalism changes the x and y attributesin MRender, though it has no effect on the semantics of themodel. In many cases, therefore, comprehension is skippedcompletely. Nonetheless, it is an essential activity in the con-text of free-hand editors, where all changes are made purelyin concrete syntax.

The distinction between recognition and comprehension isimportant. For example, recognition recognizes when a rec-tangle is dragged to a different location (changing its x and yattributes), and comprehension comprehends that this impliescontainment (creating a Containment link). In contrast to per-ceptualization, comprehension might fail if the user createsa structure that cannot be comprehended (i.e., a parsing er-ror). While we are sure that the modified MRender conforms toMMRender, it does not necessarily represent a comprehensiblemodel (e.g., a circle has no meaning in CBDs without a textvalue in it).

In our example, comprehension maps the text value of theText element back to the value of the Constant block. Note thatthis is one of the only changes on concrete syntax that wouldhave any semantical effect. For example, altering the x and yattributes of any of these elements would have no semanticaleffect, as CBDs are a topological formalism. When the Textelement is deleted altogether, comprehension fails.

MMAS MMRender

MAS MRender

MMCLBACK-END

<<AS operations>>

FRONT-END

AddBlock


MRendertransfer render

recognize

implements

MMRender

MRender

transfer

render

recognize

implements

<<AS operations>>

platform1

platform2

comprehend

perceptualize

Figure 12. Approach with multiple GUI front-ends.

4 Degrees of FlexibilityWith our approach explained, we present how this approachaddresses the various restrictions of existing tools. For eachrestriction, we explain how our approach is flexible enoughto support it, applied to our motivating example.

As we did not code our approach, many of these degreesof flexibility are just the creation of a new model, in whichmeta-modelling tools are specialized. The presented degreesof flexibility can therefore be explained at a high level ofabstraction, without going into implementation details. Thiswould not be the case for a plugin-based approach, for exam-ple, as we would have to rely on tool-specific API calls.

4.1 Multiple GUIsThe first restriction was related to having multiple front-ends,possibly implemented in different implementation languages,though all with similar semantics. We addressed this prob-lem by presenting the MMRender model as the “interface” formodel rendering: all front-ends must accept the same set ofmodels. As long as the back-end and front-end agree on acertain MMRender, specified in the back-end, all front-ends thatimplement it are supported. In contrast to other tools, wherethe front-end is offered some kind of fixed modelling API onabstract syntax, our front-end only receives a serialized model,in a known format, which it must render as-is: all processinghas already been done. The back-end is completely indepen-dent of the front-end and, subsequently, the platform used forrendering. This is shown in Figure 12, where the same MRender

and MMRender is used for two different front-ends, renderingthe same representation of the model.

For CBDs, we implemented a front-end in Python/TkInterand JavaScript/SVG. Both are similar in use and visualiza-tion, though their underlying mapping to the platform drasti-cally differs. There is still much freedom left in the front-end,specifically for elements not defined in MMRender, such as thesupported operations (e.g., zooming, scaling) and interactionwith the user (e.g., mouse-driven, keyboard-driven).


MMAS

MMCLBACK-END

<<AS operations>>

FRONT-END

AddBlock

AddConnection

MRenderMAS MRendertransfer render

recognize

implements

MRender

render

recognize

implements

MRendertransfer

MMRenderGraph MMRender

Graph

Graph Graph

Plot Plot

PlotPlotMMRender MMRender

(t0; v0)

(t1; v1)

(t2; v2)

platform1

platform2

comprehend

perceptualize

comprehend

perceptualize

Figure 13. Approach with multiple MMRender models.

4.2 Multiple Perceptualization FormatsAs our approach explicitly models MMRender, it is possible tohave several variants of it, each defining a different format.Each front-end merely needs to ensure that its MMRender iscomprehended by the back-end, and can from then on vi-sualize models in that language. A different MMRender oftenrequires a different front-end, though this is not required.For example, a TkInter front-end can visualize a text-onlyMMRender as a TkInter text widget.

Figure 13 shows this in the context of our CBD example,where we have two rendering formats: one for graphical mod-els (MMGraph

Render), and one for plots (MMPlotRender). Each MMRender

has its own front-end. Both front-ends are connected to thesame back-end and share the same models and API to thesemodels. Through this API, a graphical front-end receives amodel conforming to MMGraph

Render, and the plotting front-endreceives a model conforming to MMPlot

Render.

4.3 Multiple PerceptualizationsSince the mapping from MM𝐴𝑆 to MMRender is explicitlymodelled, it is possible to change it, or have multiple. Anymapping is fine, as long as it generates a valid instance ofMMRender, and can therefore be rendered. These mappings cantarget different versions of MMRender, as was already shownin the previous point, but can also go to the same MMRender.

Figure 14 shows this in the context of our CBD example,where we have two mappings to the same MMRender. Onedefines the integration block icon as a rectangle with 1/𝑠 in it(MMV1

Render), whereas the other defines it using a triangle andthe

∫symbol in it (MMV2

Render). Both mappings are equallycorrect and can be used interchangeably: all changes on onerepresentation are automatically mimicked on the other repre-sentations, as they share the same M𝐴𝑆 .

4.4 Lay-outingLay-outing is an additional operation executed after perceptu-alization, as we need to operate on the current visualization.

MMAS MMRender

MMCLBACK-END

<<AS operations>>

FRONT-END

AddBlock


MAStransfer render

recognize

implements

MRender

render

recognize

MRendertransfer

V1

V2 V2

MRenderV1 MRender

platformcomprehend

perceptualize

comprehend

perceptualize

Figure 14. Approach with multiple mappers to the sameMMRender. The same tool is used for both models, thoughdifferent instances.

Therefore, it is often shifted to the front-end completely. Inour approach, the perceptualized model is available in theback-end, where the lay-outing can happen using, for exam-ple, model transformations. This not only makes it possibleto share the same lay-out algorithms between front-ends, butalso allows domain-specific lay-outing algorithms. For prac-tical reasons, the lay-out algorithm, and any other pre- orpost-processing operations, are implemented as part of theperceptualization phase.

For our CBD example, we can implement a new domain-specific lay-out algorithm as part of the perceptualization.When new elements are added, users can add them whereverthey want, but they will automatically be placed at the ideallocation in the CBD model. With lay-outing happening at theback-end, all users sharing the same perceptualized modelwill also see the lay-out propagated.

4.5 Many-to-Many PerceptualizationAs our mapping for the perceptualization and comprehensionis any kind of operation, we can use any executable languageto define it in. In contrast to icon definitions, we can mapmultiple abstract syntax elements to multiple concrete syntaxelements, as the mapping itself is generic. This can be usedduring perceptualization to create complex rules that cannotbe expressed with the usual icon definitions: multiple abstractsyntax elements are condensed into a single icon. Thanks tothe use of traceability links in our approach, from MRender toM𝐴𝑆 , it is also possible to incrementally update the concretesyntax, by linking previously rendered elements.

For our CBD example, we are able to utilize model trans-formations to map elements from the source language (M𝐴𝑆)to elements in the target language(MRender). In general, modeltransformation language are not limited to a one-to-manymapping, in contrast to most icon definition languages.


5 EvaluationWe now evaluate our framework based on an implementationin our prototype tool: the Modelverse1 [25, 26].

5.1 Research QuestionsWe distill our motivating example into five research questions:

1. R1: Can new front-ends be implemented fast?2. R2: Can models be perceptualized in different ways?3. R3: Can multiple perceptualizations be defined?4. R4: Can domain-specific lay-outing be defined?5. R5: Can many-to-many perceptualizations be defined?

5.2 ResultsR1: Lightweight Front-ends We have implemented twoseparate front-ends, for two different platforms: TkInter andMatplotlib, both using Python. The Matplotlib front-end onlyvisualizes the model and does not offer any manipulation op-erations. The TkInter front-end includes basic concrete syntaxoperations, such as moving around elements, and basic ab-stract syntax operations, such as modifying attributes. Eachfront-end was implemented by a different developer, familiarwith the platform. Each individual front-end took less thanone day to implement up to the point where they could vi-sualize the models, exactly as received from the back-end.Each front-end has a small code base: approximately 250lines of Python code for the front-end with Matplotlib, and350 lines for the front-end with TkInter. For both front-ends,no (meta-)modelling information had to be coded, exceptfor the implementation of MMRender. This can be consideredfast for front-end development, which usually takes a sig-nificant amount of time. In our case, perceptualization wasonly defined once in the back-end, instead of once for eachfront-end.

R2: Different Perceptualizations Using the two previouslyimplemented front-ends, we have also shown the feasibilityof different perceptualizations. The first front-end providesa plot-based perceptualization of a trace model. In this per-ceptualization, the model is visualized as a graph, and alloperations, such as zooming, are provided natively by theMatplotlib platform. The second front-end provides a graphi-cal perceptualization of the original CBD and resulting tracemodel. In this perceptualization, we rely on the TkInter visu-alization primitives. The trace model can therefore be percep-tualized in two significantly different ways.

R3: Multiple Similar Perceptualizations Using the previ-ously implemented graphical front-end, with TkInter, we haveimplemented two different perceptualizations as model trans-formations. This front-end therefore has a drop-down menufor the model to show, and a drop-down menu for the avail-able perceptualizations. Both are automatically populated by

1https://msdl.uantwerpen.be/git/yentl/modelverse

querying the back-end. The same model can therefore bevisualized with two slightly different transformations.

R4: Domain-Specific Layouting We have implemented asimple lay-out algorithm in the perceptualization transfor-mation. Combined with the two different perceptualizationtransformations, we were able not only to alter the icons ofthe different concrete syntax elements, but also to changetheir relative position. As such, when switching from oneperceptualization to the other, the model not only changes itsicons, but the position of these icons changes as well.

R5: Many-to-many Perceptualization As our approach isbased on generic activities, it stands to reason that we cansupport many-to-many perceptualization. A simple many-to-many perceptualization was implemented, as presented be-fore in the motivating example. After the usual icon mapping,mapping an addition block to a rectangle with the additionsymbol in it, additional model transformation rules are addedto search for a negation block that is connected to the addi-tion block. When such a pattern is found, the concrete syntaxrepresentation of the negation block is removed, and the con-nection is redrawn to the negated input port of the additionblock. As such, a one-to-many mapping between M𝐴𝑆 andMRender is shown to be possible.

5.3 Threats to ValidityFor construct validity, our primary threat is the measuresused for R1. We used two measures: the time needed to de-velop the tool, and the number of lines of code. Developmenttime highly depends on the skill of the developer and the fa-miliarity with the used libraries. To minimize the time neededto get familiar with the libraries, developers were familiarwith the library they had to use up to the level that they hadno technical problems. The number of lines of code is not tooreliable to determine the difficulty of writing the front-end.The codebase of the two front-ends mostly consists of linearcode and does not include non-trivial algorithms. For exam-ple, out of the 250 lines of code for the plotting front-end,50 lines are dedicated to the translation of terminology (e.g.,“solid” line types in MMRender to “-” in Matplotlib).

For external validity, our primary threat is the applicationto only a single language (CBDs), with a single back-end(the Modelverse), and only a single implementation language(Python). Nonetheless, we believe that each of these is repre-sentative, and our approach does not depend on any of thesein particular.

For reliability, we note that we depend on the familiarity ofthe researchers with the used tools. As we have used our ownprototype tools, we knew all details relevant to the applicationof our approach. Lack of documentation about these toolsmight hinder other researchers from implementing the samefunctionality in this tool. Another threat to reliability is thesmall amount of experiments that were conducted.


6 DiscussionWe briefly present three directions in which our work is cur-rently still limited, but can be further extended: performance,GUI interaction and concrete syntax definitions.

6.1 PerformancePerformance has not been discussed up to now, as it is not oneof the concerns that we want to tackle. Nonetheless, concretesyntax can only be deemed usable if it is also sufficientlyefficient to use: model perceptualization and comprehensionrequire a relatively low latency, as otherwise the interfacedoes not seem responsive, leading to user frustration. Modeltransformations are the crucial factor in our approach: bench-marking our approach would actually be benchmarking theunderlying model transformation engine. Many model trans-formation optimizations have been discussed in the literature,such as incrementality [22], distributed queries [21], or scopediscovery [11]. Our approach itself is independent of theunderlying model transformation algorithm.

6.2 GUI InteractionUp to now, the behaviour of the front-end was considered as ablack box. While we did term its operations as rendering andrecognition, nothing is said about how this happens. Manydifferences are possible here as well, which can ideally bedomain-specific. For example, what operations does a mod-eller have to do to delete an element? Must an element be leftclicked and then the delete key pressed, or is there a buttonto do this? Depending on the domain, any of these modes ofinteraction might be more natural to the user.

The behaviour of the GUI, and in particular its interac-tion with the user, should ideally also be explicitly modelled,similar to the concrete syntax. This timed, reactive, and possi-bly concurrent behaviour is best described by a specializedformalism, such as SCCD [23].

6.3 Concrete Syntax DefinitionWhile our proposed framework offers a lot of flexibility tolanguage engineers, defining a concrete syntax mapping is notas easy as an icon definition. To increase usability, we proposean additional language, the MM𝐶𝑆 , which is a language forconcrete syntax definitions. A concrete syntax definition isa DSL for the definition of concrete syntax. An exampleis an icon definition language. Instances in this language,termed M𝐶𝑆 , can be used to generate the perceptualizationand comprehension model transformation. So while we usethe full-blown infrastructure, it becomes possible to use asimilar workflow as before, if so desired. This is shown inFigure 15, where we show that both model transformationsare generated from M𝐶𝑆 . MM𝐶𝑆 is also tightly related to bothMM𝐴𝑆 and MMRender, as it uses concepts from both. Again,we are not restricted to a single MM𝐶𝑆 , as it is possible

MMAS MMRender

MMCL

MAScomprehend

perceptualizeMRender

V1

MMCS

MCS

Figure 15. Concrete Syntax definition to automatically gen-erate the perceptualization and comprehension operations.

to define and use several, all of which define DSLs for thedomain of concrete syntax definitions.

7 Related WorkMost (visual) modelling environments support customizingthe concrete syntax of modelling languages. We considera number of representative examples and explore to whichextent they support the features listed in the previous sections.Without exception, these tools hardcode MMRender, meaningthat even when they offer some degrees of flexibility, it isconstrained to a specific type of perceptualization.

AToMPM [20] is a graphical meta-modelling environment,implemented in Javascript/SVG. It allows language engineersto develop their languages’ abstract syntax using a class-diagram language. For the concrete syntax, an icon definitionlanguage is provided. The language engineer has to create anicon for each class, and a link for each association. A class’icon and an association’s link define the graphical appearanceof the instances of that class or association; it can consist ofseveral graphical primitives such as rectangles, circles, andlines. The graphical primitives have a number of attributes,such as colour, size, font (for text), etc. The value of theseconcrete syntax attributes can depend on the value of abstractsyntax attributes: this can be defined in a mapper. Conversely,changes on the concrete syntax (e.g., dragging an icon) canbe parsed, which results in changes to the value of the ab-stract syntax attributes. AToMPM is restricted to one-to-manyperceptualization. Multiple concrete syntaxes can be definedfor the same abstract syntax definition; the front-end allowsto switch between different renderings of the same abstractsyntax model. Due to AToMPM’s client-server architecture,an alternative front-end could be developed using a differentplatform. Layout algorithms are not supported.

AToM3 [6], the predecessor of AToMPM, is implementedin Python/Tkinter. Model storage and visualization are tightlycoupled. Similar to AToMPM, visualization is defined usingan icon editor, though only one concrete syntax definition issupported for each language, as they are tightly interwoven.No comprehension from concrete to abstract syntax is sup-ported and perceptualization is limited to displaying the valueof an attribute in a text field. The language engineer can, how-ever, code actions that are triggered by events, such as editing


an object, moving it, selecting it, etc. These scripts can accessboth the abstract syntax and concrete syntax (Python) objects,though they are not governed by well-formedness rules: in-valid configurations can be reached. Some layout algorithmsare provided, such as circle layout and spring layout, thoughall of them are generic; domain-specific layout algorithmsare not supported. For AToM3, a multi-view component waspreviously introduced [5], though this was mostly focused onthe abstract syntax and associated semantics.

MetaEdit+ [12] is a commercial domain-specific meta-modelling environment. To define the abstract syntax of alanguage, a metamodel is created in the feature-rich GOPPRR(Graph-Object-Property-Port-Role-Relationship) language. Asymbol editor allows to customize the concrete syntax of thelanguage; again, each class is given a graphical representa-tion. Mapping is limited to text elements: their value can becomputed based on the abstract syntax of the model. Addi-tionally, graphical elements can be shown or hidden based ona condition on the abstract syntax of the model. MetaEdit+does not allow implementing custom layout algorithms. Nocomprehension is supported: the concrete syntax of the modelcannot influence its abstract syntax. While MetaEdit+ is acommercial, proprietary tool, it does implement a SOAP APIwith which external tools can query and modify the modelsstored in the tool. No access is given to the graphical infoof the models. Therefore, it is impossible to implement aminimal user interface with MetaEdit+ as a back-end, unlessperceptualization is implemented from scratch.

A number of frameworks exist that allow language engi-neers to create graphical user interfaces in Eclipse EMF2.GMF3 allows the generation of a modelling tool from a con-crete syntax definition, a perceptualization and a tool defini-tion, which are all explicitly modelled. Users can generatean editor as an Eclipse plug-in or as a Rich Client Platform(RCP) application. Reusing existing libraries, however, is notas straightforward. Sirius builds on GMF and aims to ease thedevelopment of modelling tools, while primarily focusing onmulti-view modelling [14]. Multiple concrete syntaxes for thesame abstract syntax are supported, for example by providingmultiple viewpoints depending on the level of abstraction.Papyrus [9] is a tool for modelling UML or SysML diagrams.Focusing on such standards, the tool allows users to specifytailored concrete syntax for their UML profile. All these EMFapproaches are based on the generation of a modelling tool.

In the domain of textual languages, abstract syntax andconcrete syntax are usually defined together by means ofa grammar. In this context, comprehension is equivalent toparsing. Any (general-purpose) text editor can be used as afront-end for free-hand editing. A parser is used to determinethe text’s conformance to the language. Nowadays, smarttext editors are used to parse the text dynamically during

2https://www.eclipse.org/emf3https://www.eclipse.org/modeling/gmp

editing, thereby supporting syntax highlighting, error detec-tion, auto-completion, etc. Xtext is a framework that sup-ports implementing textual DSLs and such smart editors [8].A DSL is defined by an Xtext grammar, from which it ispossible to parse an EMF-based abstract syntax tree by us-ing a generated ANTLR parser. A textual environment canbe generated, which includes syntax highlighting, error vi-sualization, content-assist, folding, jump-to-declaration andreverse-reference lookup across multiple files. Xtext supportsmultiple front-end frameworks, such as Eclipse, IntelliJ, andweb browser support, but the user is not expected to definesupport for his own framework. Xtext is defined for textuallanguages exclusively, unlike our approach.

Textual concrete syntax definition for DSLs is also sup-ported in MetaDepth, based on ANTLR [4]. In MetaDepth,concrete syntax and abstract syntax definition are separated,unlike typical approaches for textual syntax. There is no dedi-cated support for a user interface; instead, an external general-purpose text editor must be used.

Similar to our approach is Monto [18], which addressesthe problem of extending existing integrated developmentenvironments. But whereas their approach sticks to the sameapproach as before, and tries to make plugins easier to de-fine, our approach takes a radically different approach bymodelling all aspects explicitly. In our approach, plugins dis-appear, and effectively become just new models in the tool,which are used to augment the behaviour of the tool.

Projectional editing [28] is an alternative approach, wherethe abstract syntax, instead of the concrete syntax, is manipu-lated.

The overview of our approach bears similarity to the meg-amodel on parsing and unparsing [29], where 12 classes ofartefacts were identified, along with a set of transformationsbetween them. This overview is mostly oriented towards tex-tual languages. In contrast, our approach covers differenttypes of perceptualization: textual or graphical perceptual-ization is handled similarly in our approach. Related to this,our approach is capable of handling other perceptualizationstrategies as well, such as sonification, as long as there is anMMRender and supporting front-end.

8 ConclusionWe have shown several restrictions in current approaches toconcrete syntax, and in particular graphical concrete syntax.In this paper, we identified five restrictions with regard to their(graphical) concrete syntax, which we address by presentinga Multi-Paradigm Modelling (MPM) approach. With our ap-proach, the to-be-rendered model is represented in abstractsyntax as well, making it possible to do the perceptualizationwith model transformations. The generated model is trans-ferred to a compatible front-end, which merely renders theresult. Changes to the rendered model can be recognized andcomprehended to update the abstract syntax model.

https://www.eclipse.org/emf

https://www.eclipse.org/modeling/gmp


We have shown the various degrees of flexibility offeredby this approach, and described our implementation in theModelverse. The implementation was discussed, as well as itsperformance considerations and possible extensions such asa front-end interaction model and concrete syntax definitionlanguages.

Future work is possible in many directions. First, a front-end interaction model could be defined, which describes the(domain-specific) behaviour of the front-end. Second, a con-crete syntax definition language could be defined, which al-lows the automated generation of the required operations.Third, the link with textual languages, where the conceptsof parsing and unparsing are already well-known, could befurther explored.

AcknowledgmentsThis work was partly funded by PhD fellowships from theResearch Foundation - Flanders (FWO) and Agency for Inno-vation by Science and Technology in Flanders (IWT). Thisresearch was partially supported by Flanders Make vzw, thestrategic research centre for the manufacturing industry.

References[1] Ilkay Altintas, Chad Berkley, Efrat Jaeger, Matthew Jones, Bertram

Ludascher, and Steve Mock. 2004. Kepler: an extensible system for de-sign and execution of scientific workflows. In Scientific and StatisticalDatabase Management. 423–424.

[2] Francois E. Cellier. 1991. Continuous System Modeling (first ed.).Springer-Verlag.

[3] Randall Davis. 2007. Magic Paper: Sketch-Understanding Research.Computer (2007), 34–41.

[4] Juan de Lara, Esther Guerra, and Jesus Sanchez Cuadrado. 2015. Model-driven engineering with domain-specific meta-modelling languages.Software and System Modeling 14, 1 (2015), 429–459.

[5] Juan de Lara, Esther Guerra, and Hans Vangheluwe. 2005. A multi-view component modelling language for systems design: Checkingconsistency and timing constraints. In Visual Modeling for SoftwareIntensive Systems. 27–34.

[6] Juan De Lara and Hans Vangheluwe. 2002. AToM3: A Tool for Multi-formalism and Meta-modelling. In International Conference on Funda-mental Approaches to Software Engineering. 174–188.

[7] Denis Dube. 2006. Graph Layout for Domain-Specific Modeling. Mas-ter’s thesis. McGill University.

[8] Moritz Eysholdt and Heiko Behrens. 2010. Xtext: implement yourlanguage faster than the quick and dirty way. In Companion to the 25thAnnual ACM SIGPLAN Conference on Object-Oriented Programming,Systems, Languages, and Applications (SPLASH/OOPSLA). 307–309.

[9] Sebastien Gerard. 2015. Once upon a Time, There Was Papyrus....In Proceedings of the 3rd International Conference on Model-DrivenEngineering and Software Development. IS–7.

[10] Hans Gronniger, Holger Krahn, Bernhard Rumpe, Martin Schindler,and Steven Volkel. 2007. Text-Based Modeling. In Proceedings of the4th International Workshop on Software Language Engineering.

[11] Maris Jukss, Clark Verbrugge, Maged Elaasar, and Hans Vangheluwe.2016. Scope in model transformations. Software & Systems Modeling(2016), 1–26.

[12] Steven Kelly and Juha-Pekka Tolvanen. 2008. Domain-specific model-ing: enabling full code generation. John Wiley & Sons.

[13] Anneke Kleppe. 2007. A language description is more than a meta-model. In Fourth International Workshop on Software Language Engi-neering.

[14] Frederic Madiot and Marc Paganelli. 2015. Eclipse Sirius Demonstra-tion. In Proceedings of the MoDELS 2015 Demo and Poster Session.9–11.

[15] Matt Notowidigdo and Robert C. Miller. 2004. Off-line Sketch Inter-pretation. In AAAI Fall Symposium on Making Pen-Based InteractionIntelligent and Natural. 120–126.

[16] Marian Petre. 1995. Why looking isn’t always seeing: Readership skillsand graphical programming. Commun. ACM 38, 6 (1995), 33–44.

[17] Janet M. Six and Ioannis G. Tollis. 1999. Circular Drawings of Bi-connected Graphs. In Algorithm Engineering and Experimentation.57–73.

[18] Anthony Sloane, Matthew Roberts, Scott Buckley, and Shaun Mus-cat. 2014. Monto: A Disintegrated Development Environment. InProceedings of the International Conference on Software LanguageEngineering. 211–220.

[19] Vasco Sousa and Eugene Syriani. 2015. An Expeditious Approachto Modeling IDE Interaction Design. In Joint Proceedings of the 3rdInternational Workshop on the Globalization Of Modeling Languagesand the 9th International Workshop on Multi-Paradigm Modeling. 52–61.

[20] Eugene Syriani, Hans Vangheluwe, Raphael Mannadiar, ConnerHansen, Simon Van Mierlo, and Huseyin Ergin. 2013. AToMPM:A Web-based Modeling Environment. In Joint Proceedings of MOD-ELS’13 Invited Talks, Demonstration Session, Poster Session, and ACMStudent Research Competition. 21–25.

[21] Gabor Szarnyas, Benedek Izso, Istvan Rath, Denes Harmath, GaborBergmann, and Daniel Varro. 2014. IncQuery-D: A distributed incre-mental model query framework in the cloud. In Proceedings of theInternational Conference on Model Driven Engineering Languagesand Systems (MoDELS). 653 – 669.

[22] Zoltan Ujhelyi, Gabor Bergmann, Abel Hegedus, Akos Horvath,Benedek Izso, Istvan Rath, Zoltan Szatmari, and Daniel Varro. 2015.EMF-IncQuery: An integrated development environment for live modelqueries. Science of Computer Programming 98, 1 (2015), 80–99.

[23] Simon Van Mierlo, Yentl Van Tendeloo, Bart Meyers, Joeri Exelmans,and Hans Vangheluwe. 2016. SCCD: SCXML Extended with ClassDiagrams. In Proceedings of the Workshop on Engineering InteractiveSystems with SCXML. 2:1–2:6.

[24] Simon Van Mierlo, Yentl Van Tendeloo, Bart Meyers, and HansVangheluwe. 2017. Domain-Specific Modelling for Human-ComputerInteraction. In The Handbook of Formal Methods in Human-ComputerInteraction. 435–463.

[25] Yentl Van Tendeloo. 2015. Foundations of a Multi-Paradigm Mod-elling Tool. In Proceedings of the ACM Student Research Competitionat MODELS 2015 co-located with the ACM/IEEE 18th InternationalConference MODELS 2015. 52 – 57.

[26] Yentl Van Tendeloo and Hans Vangheluwe. 2017. The Modelverse: atool for multi-paradigm modelling and simulation. In Proceedings ofthe Winter Simulation Conference. (accepted).

[27] Hans Vangheluwe, Juan de Lara, and Pieter J. Mosterman. 2002. AnIntroduction to Multi-Paradigm Modelling and Simulation. In Proceed-ings of the AIS’2002 Conference (AI, Simulation and Planning in HighAutonomy Systems). 9 – 20.

[28] Markus Voelter, Janet Siegmund, Thorsten Berger, and Bernd Kolb.2014. Towards User-Friendly Projectional Editors. In Proceedingsof the International Conference on Software Language Engineering.41–61.

[29] Vadim Zaytsev and Anya Helene Bagge. 2014. Parsing in a broadsense. In Proceedings of the International Conference on Model DrivenEngineering Languages and Systems (MoDELS). 50 – 67.

Concrete Syntax: A Multi-paradigm Modelling...

Documents

Transcript of Concrete Syntax: A Multi-paradigm Modelling...