modelverse/techreport/general/introduction.tex

\chapter{Introduction}
To deal with the increasing complexity and size of the systems, both physical and software and combinations thereof, that we build, Multi-Paradigm Modelling (MPM)~\cite{TSCS:GrandChallenge} promotes the explicit modelling of all aspects of system development.
It addresses and integrates three orthogonal research dimensions: model abstraction, concerned with the (refinement, generalization, \ldots) relationships between models at different levels of abstraction;
multi-formalism modelling, concerned with the coupling of and transformation between models described in different formalisms;
and the explicit modelling of the (multi-user, collaborative, multi-domain) model management processes.

User collaboration is usually solved by presenting the modelling tool as a service, which ideally would be constantly running, requiring online self-updating to guarantee high availability.

Most current modelling tools do not directly support usage 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 for explicit transformations.
As such, a \textit{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.
Besides including the operational semantics of its execution, including model management operations, and thus allowing for introspection, reflection, and self-modification, we should also include the execution context.
Thus allowing debugability through direct inspection of the execution data.

In the presence of multiple users, possibly collaborating from different locations, interoperability between the modelling tools is required.
Therefore, these tools need to agree on a common exchange format, with precisely defined semantics.
As such, all models need to be representable using this common exchange format, as done by most other tools.

Collaboration between users with different expertise raises challenges for consistency management of shared models, which would require links between the different models.
Each of these models possibly in different formalism, using multiple levels of abstraction, and with multiple simultaneous views.

Our contribution in this paper, is the specification of the foundations of a self-describable, multi-paradigm modelling environment: the Modelverse~\cite{MULTI}.
We start by eliciting the requirements we find essential to such an environment, which will later be used in our specification.
The presented foundations therefore describe a class of Modelverse realizations, which satisfy our identified set of requirements.
Conceptually, all information in the Modelverse is stored in a single graph, and model management operations transform this graph.
Parts of the graph also describe action constructs which, amongst others, can be used to define several linguistic conformance relations.

\section{Architecture}
An architectural overview of the Modelverse is presented in Fig.~\ref{fig:architecture}.
The Modelverse consists of two main components: the Modelverse State (MvS) and the Modelverse Kernel (MvK), with a communication layer in between.
Different Modelverse Interfaces (MvI), capable of communication with the Modelverse, exist outside of the Modelverse.

In the Modelverse Interface, the user has a graphical or textual front-end for the Modelverse, which is close to the problem domain.
The MvI translates all user operations to operations for the MvK to process.
The MvK considers models at the logical level, where it can reason about conformance relations and can enforce syntax-directed editing.
For communication with the MvS, a conceptual idea of what a model looks like physically is used: the Physical Type Model (PTM).
As we clearly distinguish between the MvK and the MvS, the MvK cannot know how the model is represented in hardware.
The PTM is therefore used as a common concept to reason about.
Finally, the MvS receives changes on this PTM and maps them to the representational level, where it is actually stored in hardware.

\begin{figure}
    \center
    \includegraphics[width=0.5\columnwidth]{images/Modelverse.pdf}
    \caption{Overview of the Modelverse architecture}
    \label{fig:architecture}
\end{figure}