modelverse/techreport/conformance_bottom/4-example.tex

\section{Example}
\label{sec:example}
As a simple example of our approach, we present here the implementation of an instantiation model management operation.
The operation is invoked on an element in a metamodel that has to be instantiated, using the existing model to which the instantiation should be added.

Current tools implement this using code written in the implementation language and hardcoded in the tool, even though their tool supports a neutral language (\textit{e.g.}, OCL).
A normal neutral language is unfit for this purpose for several reasons:
\begin{enumerate}
\item Any representable model in the tool might become subject to instantiation, so we don't want to define the operation over the linguistic metamodel defined by the user.
      If we were to do this, only instances of that exact metamodel could ever be instantiated.
      Creating a new metamodel would also require users to reimplement all instantiation operations over and over again, to make them applicable to the model used.
      Most of the time, instantiation is very similar, so a default should be provided.
      By implementing this operation at the physical level, tools avoid this problem as they now work on the internal representation, which is identical for all models.
\item Instantiating a model element is an invasive operation, which can greatly disturb the linguistic dimension by, for example, breaking conformance to the linguistic metamodel.
      Implementing instantiation based on the linguistic metamodel, defined by the user, would therefore also be unwise, as conformance might break halfway through the operation, making the function not applicable anymore.
\item Strict metamodelling prevents users from crossing between levels.
      Even if the previous two problems were to be solved, a single model (the instantiation algorithm) cannot have links to both the model (to add the instantiated element), the metamodel (to read out the element to instantiate), and even the metametamodel (to find subtyping information).
\end{enumerate}

With our approach, each of these reasons is solved as follows:
\begin{enumerate}
\item Instead of shifting the algorithm to the physical dimension to get access to the physical representation, we shift the physical representation to the linguistic dimension as $\mathit{LTM}_\perp$.
      This way, the low-level representation of the model is also an explicit instance, for which each possible model conforms to one and the same metamodel: $\mathit{LTM}_\perp$.
      If the retyping operation is defined using $\mathit{conformance}_\perp$, it will be applicable to every possible model.
\item The type of a model is not visible in normal circumstances, as it is part of the conformance check.
      It is indeed even dangerous to change the type of a model, while operating on that specific type.
      By operating on a different type, however, of which it is known that the model will always conform to it, there are no risks involved at all.
      While it might be possible that some of the other previous conformance relations are broken (\textit{e.g.}, to a user-defined metamodel), $\mathit{conformance}_\perp$ is not invalidated by the operation as it holds by definition.
\item As previously shown, our approach just changes views to $\mathit{conformance}_\perp$, in which strict metamodelling is still valid, but it doesn't actually restrict anything, since every element is at the same level.
\end{enumerate}

The algorithm is related to how models are represented internally: all models are subgraphs of a single coherent graph.
This format of model representation is itself already level-crossing, as there are edges for both navigation and instantiation.
As it contains level-crossing links, it is an invalid model when viewed through an ordinary linguistic typing relation.
It is, however, viewable and even modifiable using $\mathit{conformance}_\perp$, as the model completely complies to $LTM_\perp$.

During the execution of the algorithm, the model is viewed not through the usual conformance relation, but through the $\mathit{conformance}_\perp$ relation.
As such, the model can be modified as if it were merely a graph, without any additional semantics or imposed restrictions.
Apart from just allowing any kind of structural change, inconsistencies in the usual conformance relation are also possible: cardinalities, multiplicities, potencies, and so on, can all be invalidated as their semantics is not checked at this level.
Operations defined by the user, using the normal linguistic conformance relation, will just reinterpret the graph to the usual linguistic dimension, thus again checking all additional constraints such as cardinalities.

We use this code to instantiate a new petri net place, as specified by the petri nets metamodel.
The example is visualized in Figure~\ref{fig:example}.
Figure~\ref{fig:example_A} indicates the problem with the instantiation algorithm: it accesses itself and three different modelling levels:
the model level to write out the instantiated model,
the metamodel level to read out the allowed attributes and all constraints,
and the metametamodel level to know about inheritance links and how to handle them.
Accessed elements are highlighted in the figure, indicating that the algorithm requires access (and thus, links) to all these levels.
It is therefore impossible to add it at either of these levels: adding it to one level would cause violations for the other levels.
By taking the $\mathit{conformance}_\perp$ view, the modelling hierarchy changes from Figure~\ref{fig:example_A} to Figure~\ref{fig:example_B}, in which there are no level-crossing links anymore.
In Figure~\ref{fig:example_B}, all access are again highlighted, but are now within the same level in the modelling hierarchy.
There is therefore no longer any violation of strict metamodelling.

\begin{figure*}
    \centering
    \begin{subfigure}{0.4\textwidth}
        \centering
        \includegraphics[width=\columnwidth]{figures/example_problem.pdf}
        \caption{Using normal conformance.}
        \label{fig:example_A}
    \end{subfigure}
    \begin{subfigure}{0.4\textwidth}
        \centering
        \includegraphics[width=\columnwidth]{figures/example_solution.pdf}
        \caption{Using $\mathit{conformance}_\perp$.}
        \label{fig:example_B}
    \end{subfigure}
    \caption{Two different ontological views on the same model. The elements accessed by the algorithm are shown in light blue. Only $\mathit{conformance}_\perp$ complies with strict metamodelling.}
    \label{fig:example}
\end{figure*}

The complete procedure is shown in Figure~\ref{fig:overview}:
first the $\mathit{conformance}_\perp$ view is taken on the model, where it is shown as a graph instead of a petri net model and metamodel.
Second, this graph is traversed and the requested changes are performed.
Finally, the modified graph model is again interpreted using the original conformance relation, where users use their own metamodel and corresponding type mapping to interpret the graph.

\begin{figure}
    \includegraphics[width=\columnwidth]{figures/overview.pdf}
    \caption{Overview of the complete procedure: (1) reinterpret the model as instance of $\mathit{LTM}_\perp$, (2) execute the algorithm on the graph representation, (3) reinterpret the model again using the initial metamodel. All steps happen on the background and the user only sees the composite operation.}
    \label{fig:overview}
\end{figure}