modelverse/techreport/general/related_work.tex

\chapter{Related work}
Our specification builds on the work from several topics.
We identify the following topics: self-describable environments, action languages, and (meta-)modelling tools.
We touch upon all of these, as we create a modelling tool, which can describe itself using an action language.

In this chapter, we will go over these different topics, and relate back to our work.

\section{Self-describable}
The idea of having a self-describable programming language is not new.
Squeak~\cite{Squeak}, for example, is a Smalltalk interpreter written in Smalltalk.
For execution, there are two options:
either the Smalltalk code is executed from within a running interpreter, or the interpreter is translated to a different programming language, which can be compiled.
The former approach offers self-modifiability at run-time, whereas the latter offers increased performance.
The translator only works on a subset of Smalltalk though, which closely maps to C (the target language of the translation).
It is possible to combine both approaches: first write and debug using the interpreter-in-interpreter approach, and afterwards translate that same code to a different programming language.
The combination is actually the main motivation for their work: it is possible to create code in Smalltalk, a high-level language, and debug it with all provided tools, and afterwards generate C, a low-level language, and profit from its performance.

A similar project is PyPy~\cite{PyPy}, a Python interpreter written in Python.
The Python code that is used for the definition is again a subset of valid Python code, called RPython, which again gets mapped to C.
Their main motivation is performance: by raising the level of abstraction from C to RPython, it becomes far easier to implement advanced interpreters (\textit{e.g.}, including a JIT compiler).

Going over to the modelling world, there is already some work done on a self-describable meta-modelling environment.
One such tools is XMF~\cite{XMF-mosaic}, which is a self-describable kernel for multi-level modelling.
Its kernel conforms to itself, though it cannot modify itself due to the lack of side-effects to functions.
While it offers a foundation for multi-level modelling, it does not include an explicitly modelled action language.

In the Modelverse, we also want to explicitly model the MvK component.
But as the MvK can hold all kinds of models, the MvK should be able to manipulate (another instance of) itself.
This would mean that the MvK is explicitly modelled in the Modelverse, and therefore is present in the MvS.
As such, an instance of the MvK can modify its own model in the same way as this was possible with Squeak.

All tools provide an extensive model library, which is written in the language they implement.
This is certainly the case for Smalltalk, where basically everything is a library, even primitive data structures such as integers.
Tools can provide a minimal foundation, possibly hardcoded, with all other parts building upon this core.
For example in PyPy, most libraries are implemented in pure Python code, whereas in CPython (the reference implementation), these are coded in C for efficiency reasons.
The Modelverse is similar in this aspect, as it only has a minimal base of hardcoded operations, to which everything should be mapped.
While this limits performance (since some operations require multiple primitive instructions), the amount of fixed components is minimized and thus the amount of modifiable code is maximized.
Furthermore, it offers users insight into the working of the tool, without resorting to the kernel manual.
Finally, new implementations of the kernel only require the reimplementation of the minimal core, with the complete library being reused as-is.

\section{Action language}
Several action languages are already in use today, to allow models with associated behaviour.
We describe some of these languages:

\begin{itemize}
\item fUML~\cite{fUML} (foundational UML) is a frequently used language, often in combination with alf~\cite{alf}.
It is referenced as the assembly language of MDA~\cite{AssemblyLanguage}, as many other languages get mapped to it.
Work has been done to extend the library of fUML with external services, such as Java libraries~\cite{JavaUML,xMOF}.
It is a quite elaborate language though, making it difficult to create a minimal core out of it.
In its turn, this decreases the power of self-modifiability: a lot of constructs are built-in, and therefore their semantics cannot be changed.
\item txtUML~\cite{txtUML} (textual executable translatable UML) provides a mere interface for the user, where all code gets translated to Java.
This has the advantage that existing tools, such as Java debuggers, can be reused.
However, the question is as to whether existing general purpose debuggers are at the right level of abstraction, as they do not provide tracability information.
Mapping to Java has the additional problem that it is not completely platform independent, as there would be a need for a Java interpreter at the platform.
Additionally, Java is not explicitly modelled and therefore we would not be able to model everything explicitly.
\item EOL~\cite{EOL} (Epsilon Object Language) is a language commonly used for model management purposes.
Several closely related languages are also specialized for specific purposes, such as ECL (Epsilon Comparison Language), EML (Epsilon Merging Language), and EGL (Epsilon Generation Language).
While it has wide support, and is based on the familiar Object Constraint Language (OCL), there is a lack of a complete metamodel.
As the code is purely textual, and not explicitly modelled, it is impossible to combine with strict metamodelling, where level-crossing links (or accesses) are disallowed.
Again, the language in itself is fairly large, making it difficult to implement a simple, minimal core.
\item Kermeta~\cite{Kermeta} probably comes closest to the Modelverse.
Their action language is explicitly modelled, and there is the possibility for both graphical and textual editting of action language constructs.
However, they are limited in the use of strict, static typing and strict metamodelling, which is a potential problem in combination with model management operations.
\end{itemize}

We can identify two different design goals for action languages: operational semantics (examples in~\cite{UMLWithMeaning}), and model management operations (examples in~\cite{EOL}).
Both goals have very different requirements.
For the modelling of operational semantics, it is desired that the action language is also explicitly modelled, and therefore can directly reference the accessed values.
Furthermore, we want to have requirements that are similar to strict metamodelling, where the action language is only able to access elements at the same level.
It is therefore not possible to use such languages for the definition of model management operations: language constructs can only access a single level.
For the modelling of model management operations, most approaches take some distance from the model itself, causing the language to not be modelled explicitly.
This allows them to ignore strict metamodelling requirements, and access arbitrary elements from the model, even if they are at different levels.
While this allows for model management operations, it is not possible to model the language, and therefore also impossible to use model management operations on themself, breaking self-describability and self-modifiability.
While the definition of operational semantics is not impossible, there are no constraints on the modifications done to the model, which is a potentially dangerous operation.
Due to this discrepancy, both of which we want to support in the Modelverse, there is a need for two different views: one specifically designed to define operational semantics, and another one to define model management and other core functions.

Languages also come in different representations, with purely textual being a popular choice for action language due to the similarity with programming languages.
For the combination of behaviour and structure, however, we want a hybrid of these approaches: textual for the action language, but graphical for the structural metamodelling language~\cite{TamingMultiParadigm}.
As the action language model is also modelled explicitly, it is automatically possible to modify action language constructs with the graphical environment.
The Modelverse takes the same approach as~\cite{TamingMultiParadigm,Kermeta,JavaUML}, as all tools are purely graphical internally, but with a textual front-end that will generate the appropriate models automatically.

In terms of debugability, many tools at the moment support some kind of execution traces~\cite{OpenSourceTools}, which can aid in debuging.
Some, however, implement this through the use of an API that is exposed by the virtual machine that executes the code~\cite{RuntimeModelForFUML}.
While this is a possible way, it makes clear that the virtual machine holds parts of the state that are not present in the state that is stored.
Implying that the execution state is not explicitly modelled, and therefore not user-modifiable or debugable.
It furthermore also raises questions as to whether the provided API is sufficient for all goals the debugger tries to solve.
In the case of the Modelverse, no state whatsoever is stored in the virtual machine (the MvK), and everything is written to the MvS.
Debuggers can therefore simply access and modify the complete execution state as if it were a regular model.
Work based on traces, such as multi-dimensional trace files~\cite{TowardsScalableExecutionTraces}, can therefore be built on top of our provided execution state.

Finally, there is the formalisation aspect.
Most languages are formalised by mapping to either fUML or Java.
While this is a viable approach, this makes us dependent on the target language, reducing interoperability.
An approach that lies closer to our approach in the Modelverse, is the mapping to graph transformations, as is done by~\cite{DynamicMetaModelling}.
As the MvS is conceptually a graph, a mapping of behaviour to graph transformations seems ideal.

\section{(Meta-)Modelling tools}
The last aspect to look at, is the functionality of current meta-modelling tools, in relation to the Modelverse.

WebGME~\cite{WebGME} is a web-based tool, focussed on collaboration between multiple users.
It really focusses on the collaboration aspect by offering model-based version control.
Support for prototype-based inheritance distinguishes it from other tools.
While it is a powerful metamodelling tool, it does not support model transformations.
It is furthermore not possible to add in model transformations, as there is no minimal core on which transformations can be built.
The Modelverse doesn't support model transformations at the moment, either, but these will later be implemented on top of the minimal core that is present.
The architectural split between behaviour and storage was replicated in the Modelverse.
In contrast, the behavioural part, the MvK, will be completely modelled in the action language defined by the Modelverse.

AToMPM~\cite{AToMPM} is another web-based meta-modelling tool with support for model transformations.
While there is a notion of collaboration, this is not to the same degree as WebGME.
The Modelverse has no direct notion of collaboration build-in, as such operations need to be implemented on top of the minimal core.
The Modelverse doesn't include a default interface at the moment, as it only consists of the service.

Melanie~\cite{Melanie} is a graphical multi-level modelling tool.
It has support for automatic emendation (changes to a meta-level are automatically propagated to the lower levels), and transformations.
While it comes with a graphical environment, there is no support for multiple users.

MetaDepth~\cite{metaDepth} is another multi-level modelling tool.
It is purely textual, and therefore feels more familiar to programmers.
While it lacks transformations, constraints and operational semantics can be defined through the use of action language in the EOL formalism.
The Modelverse supports multi-level modelling by default, but mainly because there is no restriction on re-instantiation of previously instantiated elements.
Advanced features, like emendation, or even potency, are not supported by default.
Thanks to the minimal core, however, potency, or similar techniques, can be added in, as was done by XMF-Mosaic~\cite{XMF-mosaic}.

XMF-Mosaic~\cite{XMF-mosaic} is one of the only self-describable multi-level meta-modelling tools.
It is purely textual and there is no support for multiple users.
However, it is also based on a minimal kernel, which is self-describable.
The action language they use, EOL, is not self-describable though.
Internally, the Modelverse makes fairly similar decisions, as for the use of a single common metamodel.
While this is the only way of looking at the model in XMF-Mosaic, the Modelverse allows different conformance dimensions, of which one might actually be a \textit{real} conformance dimension.

Kermeta~\cite{Kermeta} is similar to the Modelverse.
It offers a hybrid syntax of graphical and textual, and also has a meta-model for the used action code.
There is, however, a strong focus on strict and static typing, which, combined with strict metamodelling, can become very constraining for model management operations.
Kermeta models many constructs explicitly: there is even a metamodel for primitive datatypes.
These primitive datatypes however, just come out of a (system) library, and are therefore not easily changable, or visible, by the user.

While all mentioned tools have their specific application (and research) domain, the Modelverse tries to combine features of all tools.
This is done through the use of the minimal core, on which the features of other tools can be built.