modelverse/techreport/conformance_bottom/2-background.tex

\section{Background}
\label{sec:background}
In this section, we briefly introduce the required concepts for the remainder of the paper.
As our contribution is focussed on moving away from the implementation layer, we present our previous work in doing so.
First, we discuss our explicitly modelled, neutral action language.
It is a simple procedural action language, but its constructs are explicitly stored as a model themself (\textit{i.e.}, an abstract syntax graph).
Second, we use this action language to explicitly model the type/instance relations, showing the benefits we gain from doing so.
This explicit type/instance relation offers us multiple possible typings for a single model, which sits at the core of our approach.

Each part will already briefly encounter the problems mentioned earlier in this paper.
Solutions to this were always rather ad-hoc, as our primary intention was on bootstrapping our tool: the Modelverse~\cite{MULTI_Modelverse}.
After the implementation of the enabling technology, presented in this section, we have come to an elegant solution, presented in this paper, to a recurring problem.

\subsection{Explicitly Modelled Action Language}
A first step in breaking free from the implementation layer, is by removing all code snippets in the implementation language that are scattered throughout the model.
Since we don't want to depend on a single implementation language, a neutral action language was defined.

While our action language serves a similar purpose as other neutral languages, like the OCL, its major difference is that it is explicitly modelled.
Whereas an OCL interpreter follows the OCL standard, a 262-page specification, issued by the OMG~\cite{OCL}, our action language is formalized at a much lower level.
Only a handful of low-level operations are supported, which are very similar to the primitive operations in any procedural language.
As we store models as graphs internally, action language models are also represented as a graph.
Semantics are formally defined through the use of graph transformations, defining a translation from one graph pattern (before execution of the instruction) to another (after execution of the instruction).
Our interpreter itself is therefore only a few hundred lines of code, to which a set of graph transformation rules are passed.
Only these few hundred lines of code are dependent on the underlying platform, and should be ported when porting the complete application.

Apart from explicitly modelling the semantics, this also makes sure that the execution state is explicitly modelled, as that too is modified by the graph transformation.
The major disadvantage, however, is performance, which is very low at the moment.

An example rule is shown in Figure~\ref{fig:rule}, where the graph transformation rule is shown for when a \texttt{while} element is to be executed with a condition that evaluates to \texttt{True}.
Note that not only the action language constructs are explicitly modelled, but also the complete execution context (\textit{i.e.}, execution stack) is explicitly represented in the Modelverse and is transformed according to these rules.

\begin{figure}
    \includegraphics[width=\columnwidth]{figures/rule.pdf}
    \caption{Rule to execute when a \texttt{while} is executed with a condition evaluating to \texttt{True}.}
    \label{fig:rule}
\end{figure}

It is our intention to create a library of operations, containing, for example, the operations defined by OCL, which is modeled using this minimal action language.
But while this is a noble plan, we quickly encounter the same problems that were raised in the beginning of this paper: strict metamodelling does not allow for models that span multiple levels.
An explicit model of, let's say, a conformance relation, needs access to both the type and instance level, as shown in Figure~\ref{fig:spanning_algorithm}.
We temporarily solved this problem by ignoring strict metamodelling requirements, such that we can bootstrap the tool anyhow.

The contribution of a new action language itself, is therefore not sufficient to address the problems raised at the start of this paper.
While some code snippets in models can be replaced with implementation-independent action code, such as OCL or even our own action language, this action language is not sufficient to model low-level operations that need to work across multiple levels in the modelling hierarchy.
Model management operations, in particular, frequently require cross-level access to the model.

\subsection{Explicitly Modelled Type/Instance Relations}
A next step in allowing for our contribution, is to explicitly model the type/instance relation between models.
By explicitly modelling the type/instance relation, we have shown that users gain more insight in tool semantics and can alter the semantics if desired.
This resulted in the possibility for multiple types of type/instance relations.
For example, a single model can be typed by multiple metamodels, possibly simply because they are different, but similar, metamodels, but maybe also because a less restrictive conformance check is being used.
As there is no common agreement on how restricted a conformance relation should be (\textit{e.g.}, should it take into account all of potency, cardinality, or multiplicity, and how should it behave if these are violated?)

We achieved this explicit semantics through explicit modelling of the type/instance relation, which constisted of several steps.

First, the metamodel was stripped to only contain structural restrictions.
As such, there were no longer any additional attributes that were undefined at the level above, such as potency, multiplicity, cardinalities, and so on.
Attributes with that name could be present though, if they were allowed by the metamodel, but they have no associated semantics, thus not restricting instances.

Second, type information from the model was split of into a seperate model.
A model was thus reduced to a mere graph, which structurally conformed to another graph (the metamodel).
The type information contained links between both graphs, indicating the type of each element in the model.
Due to this seperation, a model could possibly have multiple type mappings, together with multiple metamodels.
To determine whether a model was typed by another model, both models were required, but additionaly a mapping also needed to be present.

Third, all semantics was shifted to the instantiation and conformance checking algorithms, which make up the type/instance relation.
The instantiation algorithm checks all necessary constraints during instantiation, and, for example, prevents further instantiation if the potency has already reached zero.
Similarly, the conformance check checks both the structure, as defined by the graphs, the types, as defined by the type mapping, and the additional constraints imposed by giving semantics to special attributes like potency and cardinalities.
It is thus now the conformance algorithm which gives the semantics to these attributes, and no longer the tool internals, which are hidden from the user and non-modifiable.
To make the algorithms independent of the implementation, they are implemented using the previously defined neutral action language, which is explicitly modelled.

The most important aspect, in the context of this paper, is that it allows a single model to conform to multiple metamodels simultaneously, possibly even through different conformance checking algorithms.
This is shown in Figure~\ref{fig:multi_conformance}, where a single petri net model is shown (as a graph; in the middle) which conforms to two different metamodels: an ordinary place/transition net metamodel (top), and one extended with an inhibitor arc (bottom).
Additionally, minor differences exist between the two metamodels, such as different naming for the \textit{weight} of the transition.
When a users uses the model, it is thus required to pass the corresponding type mapping, of which there are now two.

\begin{figure}
    \centering
    \includegraphics[width=0.8\columnwidth]{figures/pn_multi_conformance.pdf}
    \caption{A single petri net model with multiple conforming metamodels, each through a different type mapping (excerpt).}
    \label{fig:multi_conformance}
\end{figure}

Note again that we encounter the problem of strict metamodelling here.
The conformance checking algorithm needs access to both the model and metamodel, thus crossing over multiple levels in the modelling hierarchy.
This problem was again alleviated by not caring too much about strict metamodelling, thus again moving away from normal modelling, and into a realm between the tool implementation and the actual models in the tool.
In this paper, we finally shift all parts from the implementation to the models in the tool.