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.