Foundations of a Multi-Paradigm Modelling Tool Yentl Van Tendeloo University of Antwerp Email: Yentl.VanTendeloo@uantwerpen.be Abstract—None of the current plethora of meta-modelling to the required links between the different models. Each of tools includes a complete, explicit model of themselves. Such a these models are possibly in different formalism, using multi- model, a precise specification of the tool’s syntax and semantics, ple levels of abstraction, and have multiple simultaneous views. allows for introspection and self-modifiability. These features Such consistency links should also be modelled explicitly, enhance model debug-ability, make it easier to decompose the tool which introduces the need for properly typing them. for distributed execution, and allow for reasoning about correct- ness and performance. In this paper, we present the foundations Our contribution is the specification of the foundations of of the Modelverse, a self-modifiable environment for Multi- a self-modifiable, multi-paradigm modelling environment: the Paradigm Modelling (supporting multi-formalism and multi- Modelverse. We start by eliciting the requirements we find abstraction modelling as well as explicitly modelled processes). essential to such an environment, resulting in three high-level We identify a set of requirements, which we believe are vital to features to be fulfilled by our specification, and thus by all a modern Multi-Paradigm Modelling tool. These requirements implementations of the Modelverse. The presented foundations then are mapped to the features which our specification will describe a class of Modelverse realizations, which satisfy our support: self-modifiability, formalization, and multiple notions of identified set of requirements. conformance between models and meta-models. We state our identified requirements, and our proposed I. I NTRODUCTION features for such a tool in Section II. Section III then defines To deal with the increasing complexity and size of the the semantics and both the interface of the tool and its systems that we build, both physical, software and combina- components are defined. Section IV introduces the distinction tions thereof, Multi-Paradigm Modelling (MPM) [1] promotes between several conformance dimensions along with the notion the explicit modelling of all aspects of system development of linguistic conformance. Section V presents related work. using the most appropriate abstraction(s) and the most appro- Conclusions are given in Section VI, which also presents how priate formalism(s). It adresses and integrates three orthogonal these features will be used in future work. research dimensions: model abstraction, concerned with the (refinement, generalization, . . . ) relationships between models II. R EQUIREMENTS at different levels of abstraction; multi-formalism modelling, We start by identifying a set of requirements for our concerned with the coupling of and transformation between foundations, which we deem to be important for any MPM models described in different formalisms; and the explicit mod- tool. Where appropriate, we reference this requirement back elling of the (multi-user, collaborative, multi-domain) model to other tools which support this feature, or to the publication management processes. that explains its importance to MPM. A crucial feature is user collaboration, with every user • Forever running: the Modelverse should always be possibly from a different domain, collaborating from different able to continue running. As such, exceptional situta- locations, at different times. This is usually adressed by tions should be dealt with. Examples are a crashing presenting the modelling tool as a service, which ideally program due to division by 0 or to numerical overflow runs forever, requiring online self-updating to guarantee high and non-terminating simulations. Also, modifications availability. to the behaviour, for example to fix bugs, or to Most current modelling tools do not directly support use as introduce new features, should not require a restart. An a service, or they do not allow online self-updating, through exception are changes to the minimal (static) kernel, self-modification. Self-modification requires a description of which defines the action language semantics. itself, preferably in the form of a model, to allow explicitly • Model Everything Explicitly: every element in the modelling of the modification transformations. As such, a Modelverse needs to be explicitly modelled, using the complete model of the modelling tool, and all of its features, most appropriate formalism, resulting in higher ana- needs to be present within the tool itself, and be expressed lyzability and formality. This expands to the execution in the most appropriate formalism(s). Besides including the of action code, for which the execution context should operational semantics of its execution, including model man- be explicitly modelled, increasing debugability. The agement operations, and thus allowing for self-modification, importance of modelling every aspect of a system was the execution context should also be included. This allows identified in [1]. debugging through direct inspection of the execution data (or • Multi-View: the Modelverse should support different trace, if an appropriate trace model is used). views on the same model, for example hiding or Collaboration between users with different expertise poses aggregating parts of a model to create a different view. challenges for consistency management of shared models, due Multi-view is frequently used when multiple users are involved, coming from different domains, such as INSERT INTO `nodes` VALUES (1) in [2]. MMCL INSERT INTO `nodes` • Multi-Abstraction: the Modelverse should be able to VALUES (2) INSERT INTO `edges` reason at different levels of abstraction. This is one of PetriNet VALUES (3, 1, 2) ... the requirements for an MPM tool [1]. aPetriNet • Multi-Formalism: the Modelverse should support combining multiple formalisms. This is one of the Interface Kernel State User Logical Representation requirements for an MPM tool [1]. • Multi-User: the Modelverse should be able to serve Modelverse multiple users simultaneously, guaranteeing some de- Fig. 1: Overview of the Modelverse architecture gree of fairness between different users. Multiple users are supported in two orthogonal dimensions: either through the support of multiple concurrent interfaces, ◦ Multi-Abstraction is supported because differ- and through multiple users for a single interface. It is ent metamodels can signify different levels of one of the main features of WebGME [3], and is also abstraction. supported in other tools such as like AToMPM [4]. ◦ Multi-Formalism is supported through the ap- plication of different conformance relations • Interoperability: the Modelverse might have several for each part of the model seperately. Inter- implementations, though all should be able to inter- formalism links are supported by conforming operate, as they have to modify the same conceptual to a special physical conformance relation, graph. WebGME [3] is again an example for this. In which is closely tied to the Physical Type WebGME too, a distinction is made between different Model (see the next section). internal components. • FTG+PM: the Modelverse should have an explicit III. T HE M ODELVERSE FTG+PM [5]. First, it should contain an automatically An architectural overview of the Modelverse is presented in generated Formalism Transformation Graph, describ- Fig. 1. The Modelverse consists of two main components: the ing the different formalisms present in the Modelverse, Modelverse State (MvS) and the Modelverse Kernel (MvK). and the relationships (i.e., transformations) between They share a common concept to reason about the data they them. Second, process Process Models should also be are manipulating, which is a conceptual graph representation. present in the Modelverse, to prescribe the behaviour Different Modelverse Interfaces (MvI), capable of communi- of the use of the Modelverse. This is one of the cation with the Modelverse, exist outside of the Modelverse. requirements for an MPM tool [1]. In the MvI, the user is presented with a graphical or To satisfy these requirements, we propose three main textual front-end to the Modelverse, matching the needs of features of the Modelverse, which will be discussed in the that particular user. Several implementations of the MvI can remainder of this paper. be used concurrently. The MvI translates all user operations, • Formalisation: all parts of the Modelverse should be in whatever way it accepts, to operations which the MvK formalized to establish the semantics of each compo- understands. As this is the only interface to the end-user, the nent. This fulfills the following requirements: MvI is concerned with usability. The MvK considers models ◦ Interoperability is achieved because all compo- at the logical level, where it can reason about conformance nents will implement the same interface, with relations and enforce them through syntax-directed editing. As exactly the same semantics. we clearly distinguish between the MvK and the MvS, the ◦ Multi-User is achieved because all interleaving MvK does not know how the model is physically represented. semantics are formalized, resulting in deter- The MvK is therefore concerned with the semantics, and the ministic behaviour, even in the presence of execution of models. At the lowest level, the MvS receives multiple users. operations on the conceptual graph, and maps them to the representational level, where it is actually stored. The MvS • Self-modifiability: the Modelverse should contain a is solely concerned with the physical representation of the model of itself, and should be able to alter it, result- conceptual graph, and offers a uniform interface, independent ing in changed behaviour. This fulfills the following of how it is stored internally. requirements: We will first elaborate on the conceptual graph represen- ◦ Forever Running is achieved because updates tation, which is used as the base representation of all models. to the Modelverse can happen on-the-fly. Afterwards, we describe how the MvS maps models in this ◦ Model Everything is achieved because to be graph, to an actual implementation. Finally, the MvK defines self-modifiable through model operations, the the semantics of the models present in the MvS, by defining Modelverse should be modelled in itself. transformation rules that specify how the state evolves. • Multi-conformance: a single model should be able to conform to multiple meta-models simultaneously. A. Conceptual graph This supports the following requirements: Conceptually, all data in the Modelverse is stored in the ◦ Multi-View is supported by having each view form of a graph, as defined below. This graph can hold a as a different conformance relation, which can primitive value in a node, and both nodes and edges can be be coupled to a specific concrete syntax. connected using edges. All elements (node or edge) can be accessed using a unique identifier. An actual implementation username can store the graph in different physical representations (e.g., using a relational database or triplestore). This allows for ’input’ ’last_input’ ’output’ ’last_output’ ’frame’ more specialized implementations, depending on the problem domain, while still being interoperable. ’symbols’ ’IP’ evalstack’ ’phase’ ’returnvalue’ We define a graph G, element of G (the set of all possible states of the Modelverse). A graph consists of nodes (NG ), possibly with values (in U) defined on them (NV,G ), and edges Fig. 2: Graph to match as execution context. (EG , identifiers in EIDS ,G ). Edges may connect both nodes and edges. Nodes and edges have a unique identifier, with Informally, it extends the set of edges with a new edge, which IDS G being the set of all identifiers. When constructing an gets an identifier that was not yet used. edge, it is required that both the source and target already Cedge : G × IDS × IDS → G × EIDS exist before the construction of the edge. This guarantees, by construction, that all edges are (eventually) rooted in nodes, Cedge (G, i1 , i2 ) = (G0 , i3 ) and that no infinite recursion is possible when iterating over G = hN, E, NV i the graph. 0 G = hN, E ∪ {ei }, NV i G = hNG , EG , NV,G i ∈ G ei = (i1 , i3 , i2 ) 6∈ E ni ∈ NG ⊆ IDS G i3 6∈ IDS G ej ∈ EG ⊆ IDS G × IDS G × IDS G C. Modelverse Kernel NV,G : NG → U We will now consider the Modelverse Kernel (MvK), EIDS ,G = {b|(a, b, c) ∈ EG } which is responsible for the execution of action code. As NG ∩ EIDS ,G = ∅ everything is modelled explicitly, the execution context will NG ∪ EIDS ,G = IDS G be part of the MvS. Graph transformations are used to define ∀ei , ej ∈ E : ei = (a, b, c), ej = (d, e, f ), (b = e) ⇒ (ei = ej ) the semantics of our action language, which can be mapped to a series of MvS operations as previously defined. We use a With U defining the set of all possible types: U = I ∪ F ∪ concrete syntax which shows positive matches in solid black S ∪ B ∪ A ∪ Σtype . We define the following primitive types, lines, negative matches in dotted red lines, delete matches in for which the MvS needs to provide native support: Integer dashed blue lines, and create matches in thick green lines. (I) as the set of integers; Float (F) as the set of floating point The well-formedness of the execution context can be numbers; String (S) as the set of all ordered combinations checked using graph matching. Action code semantics are de- of ASCII characters; Boolean (B) as either True or False; fined using graph transformations, transforming the execution Action (A) as an action language construct, used to define the context. semantics later on; and Type (Σtype ) as the set of all supported We define the execution context of the MvK, using graph types. As none of these sets overlap, it is possible to infer the matching. The execution context contains all execution data, type of the provided data. Note the distinction between U and which is required for the MvK to implement the semantics of Σtype : U represents the type of data, whereas Σtype represents arbitrary formalisms. If the number of matches is not exactly, a kind of meta-type of which all types are instances. the execution context is malformed and deterministic execution (which we currently require) is impossible. {If , While, Assign, Call , Break , A= A structure is matched as presented in Fig. 2. At the top of Continue, Return, Input, Output, Define} the structure sits the Modelverse root node, which is a known ∀i, j ∈ {I, F, S, B, A, Σtype } : i 6= j ⇒ i ∩ j = ∅ node. From this root node, there is a link to all user root nodes, {IntType, FloatType, StringType, containing the name of the user. From the user root, links point Σtype = BooleanType, ActionType, TypeType} to the explicitly modelled input and output queue, which are used by the user to interact with the Modelverse. There is also B. Modelverse State a link to the currently active execution frame, which contains We now define the interface that all compliant modelling all data necessary for execution. tools should implement. Our interface is defined on the pre- With the execution semantics and state completely defined viously defined graph, though the implementation will depend in the Modelverse, the final remaining step is implementing on the data structure used. operations in the action code itself. These operations are then The MvS implements several atomic functions, which are able to perform modifications on the MvS, with as a special to be used as the primitive Create, Read, Update, and Delete case modifying their own definition. As such, we achieve (CRUD) operations on the conceptual graph. Effectively, the self-modifiability. Self-modifiability as required for debugging MvS can be seen as a graph library, implementing an interface functionality, such as modifying variables, is supported by to our conceptual graph. Apart from defining only primitive explicitly storing the execution context. CRUD operations, several composite operations are provided What remains for our formalization is the semantics of each to allow for more efficient execution. of the action language constructs. For each construct, defined All CRUD operations are formalized as operations on the in A, the required modifications of the execution context need conceptual graph. A representative specification is the create to be defined using graph transformations. edge operation Cedge , for which the semantics is defined next. We give the transformation rules for a While instruction ’phase’ MMCLα MMCLβ ’cond’ ’phase’ ’init’ username ’frame’ ’evalstack’ ’IP’ ... LTMβ ’prev’ ’returnvalue’ ’inst’ While True ’body’ ’phase’ Fβ ’evalstack’ ’init’ LTMα LCO ON NF LC ’IP’ α Fig. 3: Evaluate the body by moving the instruction pointer LTM⊥ LCONF m PCONF PTM ⊥ (IP) and pushing the while instruction back on the evaluation LINGUISTIC PHYSICAL stack. Fig. 4: Different conformance relations in Fig. 3, showing its semantics. The instruction pointer is moved to the body of the While construct, on the condition the number of distinct conformance relations can vary, each that the returnvalue is True. Reevaluation of the while construct model must have a (physical) conformance mapping to the is scheduled to happen when the body is completely executed, Physical Type Model (PTM), to physically represent the model. by putting this instruction on the evaluation stack. It will also have a (linguistic) conformance mapping to the Linguistic Type Model (LTM), which is basically a meta- These graph transformation rules are defined such that model of our conceptual graph, using conformance⊥ . Thanks there should always be exactly one possible match. If no to this additional conformance relation, to which everything matches can be found, this indicates that the execution context, conforms, the user gains access to the physical level in an the current action language primitive, or both, are invalid. explicitly modelled way. If multiple matches are found, non-determinism is possible, which is disallowed. A. Conformance⊥ In the presence of multiple users, interleaving is necessary As all our data is (conceptually) represented using a graph, between them to guarantee fairness. This prevents uninterrupt- the graph instance can also be interpreted as a linguistic able loops at the lowest level, as each basic transformation rule instance of a graph metamodel. Because all operations con- is guaranteed to terminate. strain the result to be a well-formed graph, all models in the Note that we do not define the semantics of model manage- Modelverse conform to this metamodel by construction. Since ment operations at this level. As this is the static core of the every model in the Modelverse is conceptually representable Modelverse Kernel, its semantics is fixed and cannot be altered as a graph, everything can be flattened to a single level, dynamically. Model management operations are implemented conforming to the graph formalism. Within this level, all on top of this minimal layer. It is then possible to modify operations and links between elements are non-level crossing, their semantics at runtime, to access their explicitly modelled and can therefore be correctly typed. Links that are normally semantics from within the Modelverse, and to support different level-crossing, or inter-formalism, can now be correctly typed versions simultaneously. without violating strict metamodelling constraints. We have now achieved formalisation, as all action code models can now be given semantics by mapping them to B. ConformanceL operations on the MvS. Beyond this built-in conformance relation, which is always IV. C ONFORMANCE satisfied, users can define multiple linguistic conformance By allowing a single model to conform to multiple relations as well. Each of these conformance relations, given metamodels, using multiple distinct conformance relations, them satisfying the conditions mentioned by [7], induces meta- we can combine strict metamodelling with explicitly model levels, which can vary according to the selected conformance management operations. The conceptual graph, representing relation. Linguistic conformance cannot be guaranteed at all, the model, is thus interpreted depending on the metamodel/- and requires checking whenever either the model or the conformance relation being used. Examples of metamodels metamodel change, to ensure it is enforced. are a problem-domain specific metamodel (e.g., a Petri Net Because a conformanceL view is only a specific view on a metamodel), and a more physically oriented metamodel (e.g., model, a single model can conform to multiple metamodels. A a Graph metamodel). With the domain-specific metamodel, conforms function is defined to determine linguistic confor- users can work using a domain-specific language, and are mance.. It takes two graphs – a model and a metamodel, which therefore maximally constrained (i.e., syntax-directed editing). are both subgraphs of the conceptual graph – and a mapping With the graph metamodel, users are unconstrained as there is between them, returning a boolean whether this typing is valid no interpretation given to the graph (i.e., free-hand editing). or not. This mapping encapsulates all typing information, thus Even with the graph metamodel, however, the modelling typing is completely separated from the model and metamodel, environment still enforces conformance, but just with a very allowing for maximal flexibility. loose metamodel. Depending on the metamodel, different level This definition of the typing relation, of which there might hierarchies are constructed due to a different interpretation of be multiple, makes us achieve multi-conformance. the conceptual graph. Fig. 4 presents different notions of conformance that can V. R ELATED WORK be devised using the Modelverse. The use of two different Current meta-modelling tools support our identified high- dimensions is based on the dimensions identified in [6]. While level requirements to a varying degree. We now explore the current state of the art for the three different features, and how switching between different notions of conformance allows us other approaches support these. to see everything at a single level, as a direct instance of the Most of the recent meta-modelling tools are not, or only top level model, as done by XMF-Mosaic [18]. partially, formalized. While most tools formalize their internal Multi-conformance is also used in the application of lan- data structure and its operations, they frequently ignore the guage relaxation [19], as required for transformations [20]. action language. Tools such as AToMPM [4] or JavaUML[8], Enterprise Architecture Frameworks (EAF), such as the simply re-use a general purpose programming language. While Zachman framework [21], make explicit the notion of multiple this enhances reusability of currently existing tools, therefore users, multiple views, distributed architecture, and interaction solving the problem of lacking tools [8], this often results in a between different tools. As all artefacts are be supported in the mismatch between desired and offered functionality [9]. While Modelverse, instances of this framework can also be created. it is debatable whether the language is formal or not, it is not Ultimately, an EAF can be used for the Modelverse itself, explicitly modelled, making self-hosting difficult. during the process of bootstrapping. A plethora of popular action languages exist, such as While we technically allow multi-level modelling thanks to txtUML [10], xMOF [11], EOL [12], or ALF [13]. They are our conformance functions, it is not at the same level as more not modelled explicitly at the required level. While they do specialised tools such as Melanie [22] or MetaDepth [23], for offer formal semantics, instances are again not represented example as we do not support potency [7] directly. explicitly as models, but merely in the form of normal programming languages. Closest to our action language is VI. C ONCLUSION Kermeta [9], where the action language is explicitly modelled We described the Modelverse, a self-modifiable multi- and action code is also represented as a model to be executed. paradigm modelling tool. Several requirements were presented The execution context is not explicitly represented though, nor which served as our guideline while making decisions on the how the action language constructs modify it. specification. Three high-level requirements were identified: A common example of a self-modifiability programming formalisation, self-modifiability, and multi-conformance. environment is Squeak [14], a Smalltalk interpreter written in By mapping all operations, up to the highest level, back to Smalltalk [15]. Here, self-modifiability allows the program- operations on our conceptual graph, we achieved the formal- ming environment to update itself, modifying its behaviour. isation requirement. Doing so, we allow for scalability (more To obtain self-modifiability, one requirement is that a model efficient implementations can be combined), interoperability of the currently executing program is present in itself, such (components can be switched out), and multi-user (interleav- that it can be modified. This model cannot simply be executed ings fully defined). as-is though, as there still needs to be a mapping to the Self-modifiability was achieved through the explicit mod- physical level. In Squeak, there are two options: either the elling of all operations in the provided action language itself. interpreter is run within a running (binary) interpreter, or the Additionally, the complete execution context was explicitly interpreter is translated to a binary form. If the interpreter modelled and represented in the Modelverse itself. This allows is itself interpreted, it can modify its behaviour at run-time, us to satisfy the forever running (updates can happen on-the- and detailed insight is given in the running interpreter. If the fly) and model everything (explicitly modelled operations and interpreter is translated to a binary form, the main advantage execution) requirements. is that the level of abstraction is raised: the interpreter can be written in a high-level, interpreted language, instead of Finally, we showed how multiple conformance relations writing the interpreter in a low-level, compiled language. Both can be valid at the same time, offering multi-conformance. approaches can be combined, by first writing and debugging This helps satisfy the multi-view (each view is just a different the interpreter in a known interpreter, as it is in Squeak, after conformance relation) and multi-formalism (inter-formalism which it is bootstrapped. links are well-typed) requirements. Similarly to Smalltalk, we present a minimal static core, In future work, we plan to further exploit the power we with all more advanced operations built on top of that core. gained through our three high-level requirements: Everything, except for this static core, can be viewed as a 1) Formalisation allows for different implementations, normal program (model), and can be modified at runtime. with different characteristics, such as performance. Self-modifiability is completely different from self-hosting This formalisation futher allows us to support parallel or bootstrapping (e.g., writing a C compiler in C, and later and distributed implementations. on compile it with itself), which is fairly common. For self- 2) Self-modifiability allows for self-describability, mak- modifiability, it is required that the executing program has ing it possible for the Modelverse to contain a model access to its own behaviour, and is able to change it at run-time. of itself. Such models can range from performance While not impossible for compiled programs, it is significantly models, to models that can be used for code syn- easier for interpreted programs due to their increased intro- thesis. Self-modifiability also increases debugability spection capabilities. Most interpreters, however, are not self- of the action language, as explicitly modelled debug- hosted due to the possibly significant performance overhead. gers [24] can be written, which are able to inspect and Notable exceptions to this are Squeak [14] and PyPy [16], modify the execution stack of the code under study. which are written in Smalltalk and Python, respectively. 3) Multi-conformance allows the creation of links be- The notion of multi-conformance is a middle ground tween different models and metamodels. Such func- between level-agnostic modelling [17] and strict metamod- tionality is of critical importance for operations re- elling [7]. While we still comply with strict metamodelling, lating to consistency management, where multiple models might have relations between them. ACKNOWLEDGMENT [12] D. S. Kolovos, R. F. Paige, and F. A. Polack, “The Epsilon Object This work was partly funded by a PhD fellowship from the Language (EOL),” in Model Driven Architecture Foundations and Applications, ser. Lecture Notes in Computer Science, A. Rensink and Research Foundation - Flanders (FWO). J. Warmer, Eds. Springer Berlin Heidelberg, 2006, vol. 4066, pp. 128–142. [Online]. Available: http://dx.doi.org/10.1007/11787044 11 R EFERENCES [13] “OMG ALF,” http://www.omg.org/spec/ALF/, 2013. [1] P. J. Mosterman and H. Vangheluwe, “Computer Automated Multi- [14] D. Ingalls, T. Kaehler, J. Maloney, S. Wallace, and A. Kay, “Back Paradigm Modeling: An Introduction,” Simulation: Transactions of the to the Future: The Story of Squeak, a Practical Smalltalk Written Society for Modeling and Simulation International, vol. 80, no. 9, in Itself,” in Proceedings of the 12th ACM SIGPLAN Conference on pp. 433–450, 2004, special Issue: Grand Challenges for Modeling and Object-oriented Programming, Systems, Languages, and Applications, Simulation. ser. OOPSLA ’97. New York, NY, USA: ACM, 1997, pp. 318–326. [2] A. Finkelstein and H. Fuks, “Multiparty specification,” SIGSOFT [Online]. Available: http://doi.acm.org/10.1145/263698.263754 Software Engineering Notes, vol. 14, no. 3, pp. 185–195, Apr. 1989. [15] A. Goldberg and D. Robson, Smalltalk-80: The Language and Its Imple- [Online]. Available: http://doi.acm.org/10.1145/75200.75228 mentation. Boston, MA, USA: Addison-Wesley Longman Publishing [3] M. Maróti, R. Kereskényi, T. Kecskés, P. Völgyesi, and Co., Inc., 1983. Ákos Lédeczi, “Online Collaborative Environment for Designing [16] A. Rigo and S. Pedroni, “PyPy’s Approach to Virtual Machine Complex Computational Systems,” Procedia Computer Science, Construction,” in Companion to the 21st ACM SIGPLAN Symposium on vol. 29, no. 0, pp. 2432 – 2441, 2014, 2014 International Object-oriented Programming Systems, Languages, and Applications, Conference on Computational Science. [Online]. Available: ser. OOPSLA ’06. New York, NY, USA: ACM, 2006, pp. 944–953. http://www.sciencedirect.com/science/article/pii/S1877050914004049 [Online]. Available: http://doi.acm.org/10.1145/1176617.1176753 [4] E. Syriani, H. Vangheluwe, R. Mannadiar, C. Hansen, S. Van Mierlo, [17] B. Henderson-Sellers, T. Clark, and C. Gonzalez-Perez, “On the search and H. Ergin, “AToMPM: A Web-based Modeling Environment,” in for a Level-Agnostic Modelling Language,” Lecture Notes in Computer MODELS’13 Demonstrations, 2013. Science, vol. 7908, pp. 240–255, 2013. [5] L. Lucio, S. Mustafiz, J. Denil, H. Vangheluwe, and [18] T. Clark, C. Gonzalez-Perez, and B. Henderson-Sellers, “A Foundation M. Jukss, “FTG+PM: An Integrated Framework for Investigating for Multi-Level Modelling,” in MULTI 2014 Multi-Level Modelling Model Transformation Chains,” in SDL 2013: Model-Driven Workshop Proceedings, 2014, pp. 43–52. Dependability Engineering, ser. Lecture Notes in Computer Science. Springer, 2013, vol. 7916, pp. 182–202. [Online]. Available: [19] R. Salay and M. Chechik, “Supporting agility in MDE through modeling http://dx.doi.org/10.1007/978-3-642-38911-5 11 language relaxation,” in Proceedings of the Workshop on Extreme Modeling co-located with ACM/IEEE 16th International Conference on [6] C. Atkinson and T. Kühne, “Rearchitecting the UML infrastructure,” Model Driven Engineering Languages & Systems (MoDELS 2013)., ACM Trans. Model. Comput. Simul., vol. 12, no. 4, pp. 290–321, Oct. 2013, pp. 20–27. 2002. [Online]. Available: http://doi.acm.org/10.1145/643120.643123 [20] T. Kühne, G. Mezei, E. Syriani, H. Vangheluwe, and M. Wimmer, [7] T. Kühne, “Matters of (Meta-)Modeling,” Software and System Model- “Explicit transformation modeling,” in Models in Software Engineering, ing, vol. 5, pp. 369–385, 2006. ser. Lecture Notes in Computer Science. Springer Berlin Heidelberg, [8] P. Neubauer, T. Mayerhofer, and G. Kappel, “Towards integrating 2010, vol. 6002, pp. 240–255. modeling and programming languages: The case of UML and Java,” ser. [21] J. Zachman, “A framework for information systems architecture,” IBM Proceedings of the 2nd International Workshop on the Globalization of Systems Journal, vol. 26, no. 3, pp. 276–292, 1987. Modeling Languages, 2014, pp. 23–32. [22] C. Atkinson and R. Gerbig, “Melanie: Multi-level Modeling and [9] P.-A. Muller, F. Fleurey, and J.-M. Jézéquel, “Weaving Ontology Engineering Environment,” in Proceedings of the 2Nd Executability into Object-oriented Meta-languages,” in Proceedings International Master Class on Model-Driven Engineering: Modeling of the 8th International Conference on Model Driven Wizards, ser. MW ’12. Innsbruck, Austria: ACM, 2012, pp. 7:1–7:2. Engineering Languages and Systems, ser. MoDELS’05. Berlin, [Online]. Available: http://doi.acm.org/10.1145/2448076.2448083 Heidelberg: Springer-Verlag, 2005, pp. 264–278. [Online]. Available: http://dx.doi.org/10.1007/11557432 19 [23] J. de Lara and E. Guerra, “Deep Meta-Modelling with MetaDepth,” in Proceedings of TOOLS, Lecture Notes in Computer Science vol. 6141. [10] G. Déva, G. F. Kovács, and A. Ancsin, “Textual, executable, translatable Springer, 2010, pp. 1–20. UML,” ser. 14th International Workshop on OCL and Textual Modeling Applications and Case Studies, 2014, pp. 3–12. [24] S. Van Mierlo, Y. Van Tendeloo, B. Barroca, S. Mustafiz, and H. Vangheluwe, “Explicit modelling of a Parallel DEVS experimen- [11] T. Mayerhofer, P. Langer, M. Wimmer, and G. Kappel, “xMOF: Exe- tation environment,” in Proceedings of the Symposium on Theory of cutable DSMLs Based on fUML,” in Software Language Engineering, Modeling & Simulation - DEVS Integrative, ser. DEVS ’15. Society ser. Lecture Notes in Computer Science, M. Erwig, R. Paige, and for Computer Simulation International, 2015, pp. 860–867. E. Van Wyk, Eds. Springer International Publishing, 2013, vol. 8225, pp. 56–75.