ion modelling as well as explicitly modelled processes). We identify a set of requirements, which we believe are vital to a modern Multi-Paradigm Modelling tool. These requirements then are mapped to the features which our specification will support: self-modifiability, formalization, and multiple notions of conformance between models and meta-models.
To deal with the increasing complexity and size of the
systems that we build, both physical, software and
combinations thereof, Multi-Paradigm Modelling (MPM) [
A crucial feature is user collaboration, with every user possibly from a different domain, collaborating from different locations, at different times. This is usually adressed by presenting the modelling tool as a service, which ideally runs forever, requiring online self-updating to guarantee high availability.
Most current modelling tools do not directly support use as a service, or they do not allow online self-updating, through self-modification. Self-modification requires a description of itself, preferably in the form of a model, to allow explicitly modelling of the modification transformations. As such, a complete model of the modelling tool, and all of its features, needs to be present within the tool itself, and be expressed in the most appropriate formalism(s). Besides including the operational semantics of its execution, including model management operations, and thus allowing for self-modification, the execution context should also be included. This allows debugging through direct inspection of the execution data (or trace, if an appropriate trace model is used).
Collaboration between users with different expertise poses challenges for consistency management of shared models, due to the required links between the different models. Each of these models are possibly in different formalism, using multiple levels of abstraction, and have multiple simultaneous views. Such consistency links should also be modelled explicitly, which introduces the need for properly typing them.
Our contribution is the specification of the foundations of a self-modifiable, multi-paradigm modelling environment: the Modelverse. We start by eliciting the requirements we find essential to such an environment, resulting in three high-level features to be fulfilled by our specification, and thus by all implementations of the Modelverse. The presented foundations describe a class of Modelverse realizations, which satisfy our identified set of requirements.
We state our identified requirements, and our proposed features for such a tool in Section II. Section III then defines the semantics and both the interface of the tool and its components are defined. Section IV introduces the distinction between several conformance dimensions along with the notion of linguistic conformance. Section V presents related work. Conclusions are given in Section VI, which also presents how these features will be used in future work.
II.
We start by identifying a set of requirements for our foundations, which we deem to be important for any MPM tool. Where appropriate, we reference this requirement back to other tools which support this feature, or to the publication that explains its importance to MPM.
Forever running: the Modelverse should always be able to continue running. As such, exceptional situtations should be dealt with. Examples are a crashing program due to division by 0 or to numerical overflow and non-terminating simulations. Also, modifications to the behaviour, for example to fix bugs, or to introduce new features, should not require a restart. An exception are changes to the minimal (static) kernel, which defines the action language semantics.
Model Everything Explicitly: every element in the
Modelverse needs to be explicitly modelled, using the
most appropriate formalism, resulting in higher
analyzability and formality. This expands to the execution
of action code, for which the execution context should
be explicitly modelled, increasing debugability. The
importance of modelling every aspect of a system was
identified in [
Multi-View: the Modelverse should support different
views on the same model, for example hiding or
aggregating parts of a model to create a different view.
Multi-view is frequently used when multiple users
are involved, coming from different domains, such as
in [
Multi-Abstraction: the Modelverse should be able to
reason at different levels of abstraction. This is one of
the requirements for an MPM tool [
Multi-Formalism: the Modelverse should support
combining multiple formalisms. This is one of the
requirements for an MPM tool [
Multi-User: the Modelverse should be able to serve
multiple users simultaneously, guaranteeing some
degree of fairness between different users. Multiple users
are supported in two orthogonal dimensions: either
through the support of multiple concurrent interfaces,
and through multiple users for a single interface. It is
one of the main features of WebGME [
FTG+PM: the Modelverse should have an explicit
FTG+PM [
Formalisation: all parts of the Modelverse should be formalized to establish the semantics of each component. This fulfills the following requirements:
nents will implement the same interface, with exactly the same semantics.
Multi-User is achieved because all interleaving semantics are formalized, resulting in deterministic behaviour, even in the presence of multiple users.
Self-modifiability: the Modelverse should contain a model of itself, and should be able to alter it, resulting in changed behaviour. This fulfills the following requirements:
to the Modelverse can happen on-the-fly.
Model Everything is achieved because to be self-modifiable through model operations, the Modelverse should be modelled in itself.
Multi-conformance: a single model should be able to conform to multiple meta-models simultaneously. This supports the following requirements:
as a different conformance relation, which can be coupled to a specific concrete syntax.
To satisfy these requirements, we propose three main features of the Modelverse, which will be discussed in the remainder of this paper.
User PetriNet aPetriNet Kernel Logical INSERT INTO `nodes`
VALUES (1) INSERT INTO `nodes`
VALUES (2) INSERT INTO `edges` VALUES.(3, 1, 2) .
.
Representation Modelverse
ent metamodels can signify different levels of abstraction.
Multi-Formalism is supported through the application of different conformance relations for each part of the model seperately. Interformalism links are supported by conforming to a special physical conformance relation, which is closely tied to the Physical Type Model (see the next section).
An architectural overview of the Modelverse is presented in Fig. 1. The Modelverse consists of two main components: the Modelverse State (MvS) and the Modelverse Kernel (MvK). They share a common concept to reason about the data they are manipulating, which is a conceptual graph representation. Different Modelverse Interfaces (MvI), capable of communication with the Modelverse, exist outside of the Modelverse.
In the MvI, the user is presented with a graphical or textual front-end to the Modelverse, matching the needs of that particular user. Several implementations of the MvI can be used concurrently. The MvI translates all user operations, in whatever way it accepts, to operations which the MvK understands. As this is the only interface to the end-user, the MvI is concerned with usability. The MvK considers models at the logical level, where it can reason about conformance relations and enforce them through syntax-directed editing. As we clearly distinguish between the MvK and the MvS, the MvK does not know how the model is physically represented. The MvK is therefore concerned with the semantics, and the execution of models. At the lowest level, the MvS receives operations on the conceptual graph, and maps them to the representational level, where it is actually stored. The MvS is solely concerned with the physical representation of the conceptual graph, and offers a uniform interface, independent of how it is stored internally.
We will first elaborate on the conceptual graph representation, which is used as the base representation of all models. Afterwards, we describe how the MvS maps models in this graph, to an actual implementation. Finally, the MvK defines the semantics of the models present in the MvS, by defining transformation rules that specify how the state evolves.
Conceptually, all data in the Modelverse is stored in the form of a graph, as defined below. This graph can hold a primitive value in a node, and both nodes and edges can be connected using edges. All elements (node or edge) can be accessed using a unique identifier. An actual implementation can store the graph in different physical representations (e.g., using a relational database or triplestore). This allows for more specialized implementations, depending on the problem domain, while still being interoperable.
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 (EG, identifiers in EIDS;G). Edges may connect both nodes and edges. Nodes and edges have a unique identifier, with IDS G being the set of all identifiers. When constructing an edge, it is required that both the source and target already exist before the construction of the edge. This guarantees, by construction, that all edges are (eventually) rooted in nodes, and that no infinite recursion is possible when iterating over the graph.
ej 2 EG
G = hNG; EG; NV;Gi 2 G ni 2 NG
IDS G
IDS G
IDS G
NV;G : NG ! U EIDS;G = fbj(a; b; c) 2 EGg
NG \ EIDS;G = ; NG [ EIDS;G = IDS G
IDS G 8ei; ej 2 E : ei = (a; b; c); ej = (d; e; f ); (b = e) ) (ei = ej )
With U defining the set of all possible types: U = I [ F [ S [ B [ A [ type . We define the following primitive types, for which the MvS needs to provide native support: Integer (I) as the set of integers; Float (F) as the set of floating point numbers; String (S) as the set of all ordered combinations of ASCII characters; Boolean (B) as either True or False; Action (A) as an action language construct, used to define the semantics later on; and Type ( type) as the set of all supported types. As none of these sets overlap, it is possible to infer the type of the provided data. Note the distinction between U and type : U represents the type of data, whereas type represents a kind of meta-type of which all types are instances.
A = fIf ; While; Assign; Call ; Break ;
Continue; Return; Input ; Output ; De neg 8i; j 2 fI; F; S; B; A; type g : i 6= j ) i \ j = ;
fIntType; FloatType; StringType; type = BooleanType; ActionType; TypeTypeg
We now define the interface that all compliant modelling tools should implement. Our interface is defined on the previously defined graph, though the implementation will depend on the data structure used.
The MvS implements several atomic functions, which are to be used as the primitive Create, Read, Update, and Delete (CRUD) operations on the conceptual graph. Effectively, the MvS can be seen as a graph library, implementing an interface to our conceptual graph. Apart from defining only primitive CRUD operations, several composite operations are provided to allow for more efficient execution.
All CRUD operations are formalized as operations on the conceptual graph. A representative specification is the create edge operation Cedge , for which the semantics is defined next. ’input’ ’last_input’ ’output’ ’last_output’ ’frame’
’symbols’ ’IP’ evalstack’ ’phase’ ’returnvalue’
Informally, it extends the set of edges with a new edge, which gets an identifier that was not yet used.
Cedge : G
IDS
IDS ! G
EIDS Cedge (G; i1; i2) = (G0; i3)
G = hN; E; NV i G0 = hN; E [ feig; NV i
We will now consider the Modelverse Kernel (MvK), which is responsible for the execution of action code. As everything is modelled explicitly, the execution context will be part of the MvS. Graph transformations are used to define the semantics of our action language, which can be mapped to a series of MvS operations as previously defined. We use a concrete syntax which shows positive matches in solid black lines, negative matches in dotted red lines, delete matches in dashed blue lines, and create matches in thick green lines.
The well-formedness of the execution context can be checked using graph matching. Action code semantics are defined using graph transformations, transforming the execution context.
We define the execution context of the MvK, using graph matching. The execution context contains all execution data, which is required for the MvK to implement the semantics of arbitrary formalisms. If the number of matches is not exactly, the execution context is malformed and deterministic execution (which we currently require) is impossible.
A structure is matched as presented in Fig. 2. At the top of the structure sits the Modelverse root node, which is a known node. From this root node, there is a link to all user root nodes, containing the name of the user. From the user root, links point to the explicitly modelled input and output queue, which are used by the user to interact with the Modelverse. There is also a link to the currently active execution frame, which contains all data necessary for execution.
With the execution semantics and state completely defined in the Modelverse, the final remaining step is implementing operations in the action code itself. These operations are then able to perform modifications on the MvS, with as a special case modifying their own definition. As such, we achieve self-modifiability. Self-modifiability as required for debugging functionality, such as modifying variables, is supported by explicitly storing the execution context.
What remains for our formalization is the semantics of each of the action language constructs. For each construct, defined in A, the required modifications of the execution context need to be defined using graph transformations.
We give the transformation rules for a While instruction ’phase’ ’evalstack’ ’returnvalue’ ’init’
True ’evalstack’ ’IP’ ’prev’ ’IP’ ’inst’ ’phase’
While ’init’ ’body’ in Fig. 3, showing its semantics. The instruction pointer is moved to the body of the While construct, on the condition that the returnvalue is True. Reevaluation of the while construct is scheduled to happen when the body is completely executed, by putting this instruction on the evaluation stack.
These graph transformation rules are defined such that there should always be exactly one possible match. If no matches can be found, this indicates that the execution context, the current action language primitive, or both, are invalid. If multiple matches are found, non-determinism is possible, which is disallowed.
In the presence of multiple users, interleaving is necessary between them to guarantee fairness. This prevents uninterruptable loops at the lowest level, as each basic transformation rule is guaranteed to terminate.
Note that we do not define the semantics of model management operations at this level. As this is the static core of the Modelverse Kernel, its semantics is fixed and cannot be altered dynamically. Model management operations are implemented on top of this minimal layer. It is then possible to modify their semantics at runtime, to access their explicitly modelled semantics from within the Modelverse, and to support different versions simultaneously.
We have now achieved formalisation, as all action code models can now be given semantics by mapping them to operations on the MvS.
By allowing a single model to conform to multiple metamodels, using multiple distinct conformance relations, we can combine strict metamodelling with explicitly model management operations. The conceptual graph, representing the model, is thus interpreted depending on the metamodel/conformance relation being used. Examples of metamodels are a problem-domain specific metamodel (e.g., a Petri Net metamodel), and a more physically oriented metamodel (e.g., a Graph metamodel). With the domain-specific metamodel, users can work using a domain-specific language, and are therefore maximally constrained (i.e., syntax-directed editing). With the graph metamodel, users are unconstrained as there is no interpretation given to the graph (i.e., free-hand editing). Even with the graph metamodel, however, the modelling environment still enforces conformance, but just with a very loose metamodel. Depending on the metamodel, different level hierarchies are constructed due to a different interpretation of the conceptual graph.
Fig. 4 presents different notions of conformance that can
be devised using the Modelverse. The use of two different
dimensions is based on the dimensions identified in [
L LTM⊥ LINGUISTIC
LCONF⊥m PCONF
PTM PHYSICAL the number of distinct conformance relations can vary, each model must have a (physical) conformance mapping to the Physical Type Model (PTM), to physically represent the model. It will also have a (linguistic) conformance mapping to the Linguistic Type Model (LTM), which is basically a metamodel of our conceptual graph, using conformance?. Thanks to this additional conformance relation, to which everything conforms, the user gains access to the physical level in an explicitly modelled way.
A. Conformance?
As all our data is (conceptually) represented using a graph, the graph instance can also be interpreted as a linguistic instance of a graph metamodel. Because all operations constrain the result to be a well-formed graph, all models in the Modelverse conform to this metamodel by construction. Since every model in the Modelverse is conceptually representable as a graph, everything can be flattened to a single level, conforming to the graph formalism. Within this level, all operations and links between elements are non-level crossing, and can therefore be correctly typed. Links that are normally level-crossing, or inter-formalism, can now be correctly typed without violating strict metamodelling constraints.
Beyond this built-in conformance relation, which is always
satisfied, users can define multiple linguistic conformance
relations as well. Each of these conformance relations, given
them satisfying the conditions mentioned by [
Because a conformanceL view is only a specific view on a model, a single model can conform to multiple metamodels. A conforms function is defined to determine linguistic conformance.. It takes two graphs – a model and a metamodel, which are both subgraphs of the conceptual graph – and a mapping between them, returning a boolean whether this typing is valid or not. This mapping encapsulates all typing information, thus typing is completely separated from the model and metamodel, allowing for maximal flexibility.
This definition of the typing relation, of which there might be multiple, makes us achieve multi-conformance.
Current meta-modelling tools support our identified highlevel requirements to a varying degree. We now explore the current state of the art for the three different features, and how other approaches support these.
Most of the recent meta-modelling tools are not, or only
partially, formalized. While most tools formalize their internal
data structure and its operations, they frequently ignore the
action language. Tools such as AToMPM [
A plethora of popular action languages exist, such as
txtUML [
A common example of a self-modifiability programming
environment is Squeak [
Similarly to Smalltalk, we present a minimal static core, with all more advanced operations built on top of that core. Everything, except for this static core, can be viewed as a normal program (model), and can be modified at runtime.
Self-modifiability is completely different from self-hosting
or bootstrapping (e.g., writing a C compiler in C, and later
on compile it with itself), which is fairly common. For
selfmodifiability, it is required that the executing program has
access to its own behaviour, and is able to change it at run-time.
While not impossible for compiled programs, it is significantly
easier for interpreted programs due to their increased
introspection capabilities. Most interpreters, however, are not
selfhosted due to the possibly significant performance overhead.
Notable exceptions to this are Squeak [
The notion of multi-conformance is a middle ground
between level-agnostic modelling [
Multi-conformance is also used in the application of
language relaxation [
Enterprise Architecture Frameworks (EAF), such as the
Zachman framework [
While we technically allow multi-level modelling thanks to
our conformance functions, it is not at the same level as more
specialised tools such as Melanie [
We described the Modelverse, a self-modifiable multiparadigm modelling tool. Several requirements were presented which served as our guideline while making decisions on the specification. Three high-level requirements were identified: formalisation, self-modifiability, and multi-conformance.
By mapping all operations, up to the highest level, back to operations on our conceptual graph, we achieved the formalisation requirement. Doing so, we allow for scalability (more efficient implementations can be combined), interoperability (components can be switched out), and multi-user (interleavings fully defined).
Self-modifiability was achieved through the explicit modelling of all operations in the provided action language itself. Additionally, the complete execution context was explicitly modelled and represented in the Modelverse itself. This allows us to satisfy the forever running (updates can happen on-thefly) and model everything (explicitly modelled operations and execution) requirements.
Finally, we showed how multiple conformance relations can be valid at the same time, offering multi-conformance. This helps satisfy the multi-view (each view is just a different conformance relation) and multi-formalism (inter-formalism links are well-typed) requirements.
In future work, we plan to further exploit the power we gained through our three high-level requirements: 1) 2) 3)
Formalisation allows for different implementations, with different characteristics, such as performance. This formalisation futher allows us to support parallel and distributed implementations.
Self-modifiability allows for self-describability,
making it possible for the Modelverse to contain a model
of itself. Such models can range from performance
models, to models that can be used for code
synthesis. Self-modifiability also increases debugability
of the action language, as explicitly modelled
debuggers [
This work was partly funded by a PhD fellowship from the Research Foundation - Flanders (FWO).