=Paper=
{{Paper
|id=Vol-2019/flexmde_2
|storemode=property
|title=Explicitly Modelling the Type/Instance Relation
|pdfUrl=https://ceur-ws.org/Vol-2019/flexmde_2.pdf
|volume=Vol-2019
|authors=Yentl Van Tendeloo,Hans Vangheluwe
|dblpUrl=https://dblp.org/rec/conf/models/TendelooV17
}}
==Explicitly Modelling the Type/Instance Relation==
https://ceur-ws.org/Vol-2019/flexmde_2.pdf
Explicitly Modelling the Type/Instance Relation
Yentl Van Tendeloo Hans Vangheluwe
University of Antwerp, Belgium University of Antwerp, Belgium
Email: Yentl.VanTendeloo@uantwerpen.be Flanders Make vzw, Belgium
McGill University, Canada
Email: Hans.Vangheluwe@uantwerpen.be
Abstract—The various meta-modelling tools in existence today The remainder of this paper is organized as follows. Sec-
all have differences in their conformance relations, either in- tion II specifies the two types of variations and provides ex-
tentional or accidental. This results in incompatibilities between amples. Section III presents our explicitly modelled approach.
tools, where a model cannot simply be exchanged as-is: the
meta-meta-model and semantics likely differ. Current tools are Section IV describes our implementation. Section V presents
inflexible in this regard, making their models grafted on the tool related work. Section VI concludes the paper and presents
implementation. In this paper, we distinguish between syntactical future work.
and semantical differences between tools, both resulting in non-
exchangable models. We propose to explicitly model the meta- II. T YPES OF VARIATION
meta-model (addressing syntactical differences) and its seman-
tics (addressing semantical differences). This allows meta-meta- Semantically meaningful model exchange is hindered by
models and semantics to be added and manipulated at runtime, tool incompatibilities. Even similar tools, by the same authors,
making our approach flexible for new tools as well. Models and are often incompatible: AToMPM [1] and AToM3 [2]; We-
languages from different tools can then be meaningfully stored bGME [3] and GME [4]; DPF [5] and WebDPF [6]. Even
in a single tool, retaining syntax and semantics. We provide a different versions of the same tool can be incompatible, either
prototype implementation: the Modelverse.
intentionally [7], or accidentally due to minor implementation
I. I NTRODUCTION changes or bugs.
To concretize the problem, we focus on two tools throughout
A plethora of meta-modelling tools currently exist, many the remainder of the paper: AToMPM [1] and Metadepth [8].
with their own meta-circular level and associated conformance For both tools, we describe some (hardcoded) differences to
semantics. Due to these intentional or accidental differences, illustrate the problem. We present minimal example languages
inconsistencies between tools arise: all models, including and models for both syntactical and semantical differences.
languages, become grafted on the tool’s implementation. With We consider two types of variations: syntactical and seman-
the growing importance of tool interoperability, for example tical variations.
in collaboration and model repositories, this might turn into a
problem: while the model can be exchanged, the inherent tool A. Syntactical Variations
semantics cannot. First are syntactical variations, caused by a different abstract
These limitations are caused by variations between tools, in syntax of the meta-language. Such changes can automatically
which we distinguish two types: syntactical and semantical. be detected, as a model would rely on unknown constructs.
Syntactical variations result in non-exchangable models, and We show two examples: one with a feature of AToMPM that
semantical variations cause unexpected behaviour with suc- Metadepth does not support, and one that is the other way
cessfully exchanged models. A simple example is multiple around.
inheritance. Syntactically, some tools do not support this, The first example language, in Figure 1a, uses a specific
making them unable to receive models from tools which do kind of association: the containment relation, as supported by
support multiple inheritance. Semantically, some tools handle AToMPM. It resembles an ordinary association, but indicates
the resolution order of multiple inheritance differently, thereby that the source element is a container for the target element.
altering the set of allowed instances. Its primary use is for visual representation, though it is also
In this paper, we address this problem by explicitly mod- used as implicit constraint: containment cycles are not allowed.
elling the syntax and semantics, usually built into the tool. Instances of class A can contain instances of the class B, and
Apart from documentation, new syntax and semantics can be the other way around. Figure 1b shows an example instance
loaded on-demand, without altering the tool itself. As such, a of this language, where a contains b, but also the other way
single tool is able to store and operate semantically meaningful around. Conceptually, this does not make any sense. With a
models of different tools, given that explicit models are containment relation, this is automatically flagged as an error
present. Models now become grafted on another model, which and the model does not conform. In Metadepth, which does
can just as well be exchanged, instead of being grafted on the not support a containment relation, this same language cannot
tool implementation. Additionally, the created models can be be loaded; the association type “containment” is unknown. As
used as documentation of the syntax and semantics of the tool. such, the model cannot be exchanged either, as it depends on
contains expressiveness (i.e., they can be used to express the same
A B language), but the language must be represented differently.
contains As such, languages, and therefore models, cannot be easily
(a) AToMPM meta-model. exchanged without a conversion at the abstract syntax level.
B. Semantical Variations
a:A b:B Second are semantical variations, caused by a difference
in the implementation of the conformance check, which
(b) Invalid instance.
provides the semantics for the abstract syntax of the meta-
language. Clearly, just calling an association “containment” or
an attribute “multiplicity” does not automatically give it the
A B correct semantics: it needs to be defined somewhere. Semantic
$noLoop([A2B,B2A])$ differences are indetectable when models are exchanged, as
(c) Metadepth meta-model.
they structurally conform.
Note that we consider the semantics of the meta-modelling
Fig. 1: First example language: use of containment links. language (i.e., what does a given meta-model mean), and not
the semantics of the modelling language (i.e., what does a
A [2]
given model mean). The former is mostly hardcoded in the
tool, whereas the latter is domain-specific and implemented
using, for example, model transformations.
(a) Metadepth meta-model.
The third and final example language, in Figure 3a, uses
multiple inheritance, as supported by both AToMPM and
Metadepth. An example of such a language is shown in
a1:A Figure 3a, where the class C inherits from both A and B. Both
A and B define the same attribute but with different types. It
is unclear which of the two is selected for C, which inherits
(b) Invalid instance.
from both. The semantics attached to multiple inheritance,
responsible for the choice, is hardcoded in both tools and left
A undocumented. Only experimentation is therefore possible to
figure out what it means, resulting in Figure 3b for AToMPM
$allInstances("A").size() == 2$ and Figure 3c for Metadepth. As the set of conforming
(c) AToMPM meta-model. instances differs, for the same language, both tools attach
Fig. 2: Second example language: use of node multiplicities. different semantics to the language. AToMPM seems to resolve
the earliest created inheritance link, whereas Metadepth seems
to lexicographically sort the class names and picks the first
the language. It is possible to mimic the containment relation match.
in Metadepth by defining the containment relation as a normal While the example difference here is likely intentional,
association, which has an additional constraint that does not many other differences exist that are likely accidental (e.g.,
allow loops. A semantically equivalent meta-model is shown bugs or ommissions). For example, AToMPM does not check
in Figure 1c. the type of attributes, and Metadepth cannot connect edges
The second example language, in Figure 2a, uses multi- when inheritance is involved, nor can it have attributes with
plicities on a class, as supported by Metadepth. The lower specific keyworded names (e.g., “id”). Notwithstanding the
and upper cardinality is defined as an integer attribute on the source of the difference, the semantic differences make model
class. Its primary use is to restrict the number of instances of exchange meaningless. And when the tool semantics is altered
this specific type: the number of instances must be within this (e.g., an intentional change, a bugfix, or a newly introduced
range. The class A requires that there are exactly two instances bug), it is possible that a previously conforming model sud-
of A in every model conforming to it. Figure 2b shows an denly becomes invalid, or that a previously invalid model
example instance, where only one instance of A is present. suddenly becomes valid.
With the class multiplicities, this is automatically flagged
as an error and the model does not conform. In AToMPM, C. Problem Scope
which does not support class multiplicities, this same language The previously introduced problems are often irrelevant
cannot be loaded: the attribute “multiplicity” is unknown. It for users of a single tool. As such, we do not propose
is possible to mimic multiplicities in AToMPM by defining a to alter existing (meta-)modelling tools, though it might be
global constraint, which checks the number of instances of A. useful to have sufficient documentation. The true problem lies
A semantically equivalent meta-model is shown in Figure 2c. elsewhere, with tools that explicitly have to communicate with
In both example languages, the tools are equivalent in their many different tools: model repositories.
(M3SEM ). It is this aspect of the tool that we will also model
A B explicitly in our approach.
As both M3AS and M3SEM are explicitly modelled in our
d : int d : string approach, it becomes possible to (1) alter them at runtime
(e.g., optimizations, refactorings); (2) create and use new ones
at runtime (e.g., support a new tool, bugfixes); and (3) have
multiple of them simultaneously (e.g., models from different
C tools loaded in a single tool).
A. Meta-meta-model (M AS ) 3
(a) Metamodel.
The meta-meta-model M3AS defines the concepts that can
be used when defining a new language, or meta-model. It has
two primary purposes. First, it can serve as documentation
c1:C c2:C for language engineers: what is the name of attributes, what
d=1 d = "a" constraints can be added, whether multiple inheritance is sup-
ported, and so on. Second, it is required for several operations
(b) AToMPM instances.
that need an explicit meta-model. For example RAMifica-
tion [9], used to create a new language to express model
transformation rules by Relaxing, Augmenting, and Modifying
c1:C c2:C the existing language. Differences in M3AS lead to syntactical
d=1 d = "a" differences between tools, which can be automatically detected
by comparing two M3AS models.
(c) Metadepth instances.
The M3AS of AToMPM is shown in Figure 4, modelled
Fig. 3: Third example language: use of multiple inheritance. explicitly using Entity-Relation Diagrams. It shows the various
attributes that can be set on a class, such as “attributes”
to define new attributes, and “name”. Perhaps surprisingly,
The primary purpose of model repositories is model storage attributes have no dedicated entity, in contrast to other ap-
and exchange. It makes sense that they want to maximize proaches, such as EMF.
the set of supported tools, thereby maximizing the available
models. Model repositories, however, have to understand the B. Meta-Language Semantics (M SEM ) 3
models they are managing, as otherwise they would be reduced The meta-language semantics M3SEM defines the semantics
to a mere file server. When working with models from different of concepts defined in M3AS . It takes a model and its meta-
tools, and possibly exchanging them between these tools, it model as input, and determines whether the model conforms
becomes important to take these syntactical and semantical to the meta-model. Its primary purpose is in determining
variations into account. whether a model is valid with respect to a given language
specification (i.e., check conformance). Differences in M3SEM
III. E XPLICIT T YPE /I NSTANCE R ELATIONS lead to semantical differences between the tools, which are
Varying abstract syntax and semantics at the meta-language difficult to detect automatically. Indeed, we would need to
level were identified as the root of the problem. Current verify if two models for M3SEM behave exactly the same in
tools acknowledge that an explicit meta-model is required to every possible context.
create a flexible modelling tool, in which the language can Due to space restrictions, we only show a snippet of the
be altered. They do not, however, take this one level up the conformance algorithm of Metadepth, pertaining to the mul-
meta-modelling hierarchy: the language used to create new tiplicity checks of classes in Algorithm 1. This pseudo-code
languages, the meta-language, is hardcoded in the tool. Being can be modelled in an explicitly modelled action language.
hardcoded, the problem becomes even worse: they are not
flexible either, as the hardcoded aspects cannot be altered in Algorithm 1 M3SEM snippet for the cardinality check.
any way. For this reason, we propose to explicitly model both for all class ∈ allInstances(M3, Class) do
the meta-language’s abstract syntax and semantics, and make assert allInstances(M2, class) ≥ class.lower cardinality
this fully flexible at runtime. assert allInstances(M2, class) ≤ class.upper cardinality
Some aspects of current tools are already modelled explic- end for
itly. We distinguish three layers, as commonly agreed upon:
M1 (model level), M2 (language level, or meta-model), and M3 IV. I MPLEMENTATION
(meta-language level, or meta-meta-model). For Metadepth,
As a proof of concept, we implemented this approach in our
both M1 (M1AS ) and M2 (M2AS , M2SEM ) are explicitly mod-
prototype tool: the Modelverse1 [10], [11]. We describe the
elled. In AToMPM, the syntax of M3 (M3AS ) is additionally
explicitly modelled. Both tools hardcode the semantics of M3 1 https://msdl.uantwerpen.be/git/yentl/modelverse.git
Association
Class GlobalConstraint GlobalAction
name name name
attributes event event
constraints code code
actions
cardinalities
abstract
Inheritance
Fig. 4: AToMPM’s M3AS , taken directly from AToMPM itself.
basics of the Modelverse, and present our implementation of been studied, it has remained hardcoded in various tools.
this approach in our prototype tool. We show that our approach Research up to now has mostly focussed on defining different
can indeed handle different types of M3AS and M3SEM in the levels of conformance [15] and new types of conformance,
same tool, making it compatible with multiple tools. We do not such as relaxed [16] or partial [17]. Nonetheless, they are
consider technical challenges, such as how to export a model hardcoded and partially inflexible as well: tools cannot be ex-
and load it again in our tool. tended with additional conformance relations, nor can existing
The Modelverse, in essence, consists of an explicitly mod- conformance relations be inspected or manipulated.
elled action language interpreter, combined with an action Updates to the hardcoded syntax and semantics, such as
language implementation of all meta-modelling behaviour. As UML, have resulted in (often unnecessary) breakage of con-
such, not only the conformance aspects are modelled explicitly, formance [7]. As such, old models cannot be loaded in newer
but all other aspects as well, such as model instantiation, model versions of the same tool, if tools update their implementation
transformation, and model management in general. The action of the UML. But whereas a model might still load in a
language semantics has been explicitly modelled as well [12]. newer version of the UML, nothing guarantees that the same
When defining a new conformance relation, this is therefore a semantics are used in its evaluation.
model in the Modelverse and an extension to the Modelverse In the multi-level modelling community, many aspects of
at the same time. conformance are still being investigated, specifically for newly
The interrelations between all models, such as conformance introduced physical attributes. For example, the “potency”
relations, are also modelled explicitly. For each conformance attribute has various meanings, though in all tools it is typed
relation, the link is specified by the source model (instance), as a natural number [18]. All identified semantics were im-
target model (meta-model), and conformance semantics. As plemented side by side in Metadepth, and users could toggle
such, a model can conform to the same meta-model through between them on a case-by-case basis. While this certainly
multiple conformance semantics, or to different meta-models gives great freedom, it creates yet another specification of the
using the same conformance semantics, or to different meta- semantics: a union of existing ones. Future definitions might
models using different conformance semantics. yet again require changes to this specification, potentially
Using this explicitly modelled approach, the Modelverse breaking conformance.
is able to offer the same results for the conformance checks
When models are exchanged, the first thoughts are of the
as either AToMPM or Metadepth, or any other tool, for that
technological problems: how to transfer the data from one
matter. An overview of how these explicitly modelled interre-
tool to another. Various serialization formats were conceived
lations are stored, is shown in Figure 5, which itself represents
for this problem, such as XMI and JSON. Nonetheless, they
a model in the Modelverse. While L1 and L2 can only be
limit themselves to transfering data only, not the actual model.
created in AToMPM and Metadepth, respectively, L3 is a valid
Essentially, M2AS is exchanged, but M3AS and M3SEM are not.
language in both. Nonetheless, both tools attach a different
As such, models can be exchanged, assuming that both tools
semantics to L3, as seen in the two different instances: M3 and
M4. Both conformance semantics are also explicitly modelled, implement the same M3AS and M3SEM . Should they differ, the
as shown at the right. These are again typed by something, in exchanged data becomes semantically meaningless.
this case using a conformance relation defined specifically for This brings us to model repositories, which, using this
the Modelverse, though also explicitly modelled. This could approach, often resort to semantically meaningless model
just as well have been any other previously defined semantics. exchange. For example, ReMoDD [19], being as general as
possible, sacrifices model semantics: uploaded models have
V. R ELATED W ORK only marginally more semantics than arbitrary files. Advanced
The conformance relation plays a crucial role in Model operations, which rely on the semantics of these models, are
Driven Development (MDE) [13], [14]. But while it has often not supported. Another solution, as taken by MDEForge [20],
MMMAToMPM MMMMetaDepth MMMModelverse
Action
L1 L3 L2 Language
M1 M3 M4 M2 SEMAToMPM SEMMetaDepth SEMModelverse
Fig. 5: Overview of languages, models, and relations in the Modelverse.
is to restrict exchanged models to its own M3AS and M3SEM . a variability model of all differences encountered in various
This allows them to actually use the models, for example for M3AS and M3SEM implementations, of which each tool imple-
model transformations [21], though they do so by limiting the mentation is (theoretically) a specific configuration. Finally,
set of supported tools. this approach is ideally suited for semantically meaningfull
A posteriori typing [22] has been proposed as a way to have model exchange between two existing tools: the unifying tool,
multiple types for a single model. But whereas our approach using our approach, would be able to perform the translation
does not consider any conformance relation as special, a automatically.
posteriori typing starts from a special relation: the constructive
type. The constructive type is the type used to instantiate the ACKNOWLEDGMENTS
model, and cannot be changed. All other types, discovered on-
the-fly, are completely flexible. Even though multiple meta- This work was partly funded by a PhD fellowships from
models can be found for a single model, all conformance the Research Foundation - Flanders (FWO). This research
relations must use the same M3AS and M3SEM . As such, was partially supported by Flanders Make vzw, the strategic
only M2AS can change, and not M3AS nor M3SEM , though research centre for the manufacturing industry.
this provides sufficient knowledge to reuse operations between
different meta-models. Concepts [23] serve a similar purpose, R EFERENCES
but also with similar restrictions: there is only freedom at
[1] E. Syriani, H. Vangheluwe, R. Mannadiar, C. Hansen, S. Van Mierlo,
M2AS . and H. Ergin, “AToMPM: A web-based modeling environment,” in
Joint Proceedings of MODELS’13 Invited Talks, Demonstration Session,
VI. C ONCLUSIONS AND F UTURE W ORK Poster Session, and ACM Student Research Competition, 2013, pp. 21–
We have presented the problem of combining multiple 25.
[2] J. de Lara and H. Vangheluwe, “AToM3: A tool for multi-formalism
(meta-)modelling tools, each with their own meta-meta-model and meta-modelling,” in International Conference on Fundamental
syntax and semantics. This problem is particularly relevant Approaches to Software Engineering, 2002, pp. 174–188.
in the context of model repositories, where the collaboration [3] M. Maróti, T. Kecskés, R. Kereskényi, B. Broll, P. Völgyesi, L. Jurácz,
T. Levendovszky, and A. Lédeczi, “Next generation (meta)modeling:
between multiple tools is the primary requirement. web- and cloud-based collaborative tool infrastructure,” in Proceedings
We proposed to explicitly model all aspects of the confor- of the Workshop on Multi-Paradigm Modeling (MPM), 2014, pp. 41 –
mance relation: its abstract syntax and semantics. Using our 60.
[4] A. Ledeczi, M. Maroti, A. Bakay, and G. Karsai, “The Generic Modeling
approach, we have shown that we can achieve full flexibility. A Environment,” in Proceedings of International Symposium on Intelligent
single tool was able to store, in a semantically meaningful way, Signal Processing (WISP), 2001.
models with the same semantics as other tools. Furthermore, [5] Y. Lamo, X. Wang, F. Mantz, W. MacCaull, and A. Rutle, “DPF
Workbench: A diagrammatic multi-layer domain specific (meta-) mod-
a single model can conform using multiple such semantics, elling environment,” Computer and Information Science, Studies in
potentially to different abstract syntax definitions as well. Computational Intelligence, vol. 429, pp. 37–52, 2012.
A prototype implementation of this approach was presented [6] F. Rabbi, Y. Lamo, I. C. Yu, and L. M. Kristensen, “WebDPF: A
web-based metamodelling and model transformation environment,” in
in the Modelverse, our explicitly modelled meta-modelling Proceedings of the 4th International Conference on Model-Driven
environment. The Modelverse was able to handle multiple Engineering and Software Development, 2016, pp. 87–98.
models, meta-models, and also meta-meta-models, all with [7] T. Degueule, B. Combemale, A. Blouin, O. Barais, and J.-M. Jézéquel,
their own associated semantics. At runtime, new conformance “Safe model polymorphism for flexible modeling,” Computer Lan-
guages, Systems & Structures, vol. 49, pp. 176–195, 2017.
semantics models could be uploaded, and existing ones could [8] J. de Lara and E. Guerra, “Deep meta-modelling with MetaDepth,” in
be modified. Proceedings of the TOOLS EUROPE Conference, 2010, pp. 1 – 20.
In future work, we plan to investigate the influence of the [9] T. Kühne, G. Mezei, E. Syriani, H. Vangheluwe, and M. Wimmer,
“Explicit transformation modeling,” in Proceedings of the International
conformance relation on other modelling operations as well, Conference on Model Driven Engineering Languages and Systems
such as the allInstances operation. Also, we intend to create (MoDELS), 2009, pp. 240 – 255.
[10] Y. Van Tendeloo, “Foundations of a multi-paradigm modelling tool,” in
Proceedings of the ACM Student Research Competition at MODELS
2015 co-located with the ACM/IEEE 18th International Conference
MODELS 2015, 2015, pp. 52 – 57.
[11] Y. Van Tendeloo and H. Vangheluwe, “The Modelverse: A tool for
multi-paradigm modelling and simulation,” in Proceedings of the Winter
Simulation Conference, 2017, (accepted).
[12] Y. Van Tendeloo, B. Barroca, S. Van Mierlo, and H. Vangheluwe,
“Modelverse specification,” University of Antwerp, Tech. Rep., 2017.
[13] Z. Theisz and G. Mezei, “An algebraic instantiation technique illustrated
by multilevel design patterns,” in Proceedings of the 2nd International
Workshop on Multi-Level Modelling, 2015, pp. 53–62.
[14] C. Atkinson and T. Kühne, “Concepts for comparing modeling tool
architectures,” in Proceedings of the International Conference on Model
Driven Engineering Languages and Systems (MoDELS), 2005, pp. 398–
413.
[15] B. Kennel, “A unified framework for multi-level modeling,” Ph.D.
dissertation, University of Mannheim, 2012.
[16] R. Salay and M. Chechik, “Supporting agility in MDE through modeling
language relaxation,” in Proceedings of the Workshop on Extreme
Modeling, 2013, pp. 21 – 30.
[17] J.-S. Sottet and N. Biri, “JSMF: a Javascript flexible modelling frame-
work,” in Proceedings of the 2nd Workshop on Flexible Model Driven
Engineering, 2016, pp. 42–51.
[18] A. Rossini, J. de Lara, E. Guerra, A. Rutle, and U. Wolter, “A
formalisation of deep metamodelling,” Formal Aspects of Computing
(Springer), vol. 26, no. 6, pp. 1115–1152, 2014.
[19] R. France, J. Biemand, and B. H. C. Cheng, “Repository for model
driven development,” in Proceedings of the International Conference on
Model Driven Engineering Languages and Systems (MoDELS), 2006,
pp. 311 – 317.
[20] F. Basciani, J. Di Rocco, D. Di Ruscio, A. Di Salle, L. Iovino, and
A. Pierantonio, “MDEForge: an extensible web-based modeling plat-
form,” in Proceedings of the Workshop on Model-Driven Engineering
on and for the Cloud (CloudMDE), 2014, pp. 66 – 75.
[21] J. Di Rucco, D. Di Ruscio, A. Pierantoini, J. Sánchez Cuadrado,
J. de Lara, and E. Guerra, “Using ATL transformation services in
the MDEForge collaborative modeling platform,” in Proceedings of the
International Conference on Model Transformation (ICMT), 2016.
[22] J. de Lara, E. Guerra, and J. Sánchez Cuadrado, “A-posteriori typing for
model-driven engineering,” in Proceedings of the International Confer-
ence on Model Driven Engineering Languages and Systems (MoDELS),
2015, pp. 156 – 165.
[23] J. de Lara and E. Guerra, “Generic meta-modelling with concepts, tem-
plates and mixin layers,” in Proceedings of the International Conference
on Model Driven Engineering Languages and Systems (MoDELS), 2010,
pp. 16 – 30.