modelverse/techreport/conformance_bottom/3.5-conformancebottom.tex

\section{Explicit Modelling of Physical Conformance}
\label{sec:conformancebottom}
Recall that relying on the physical conformance relation was the cause of the problems we have previously observed.
The theoretical limitation, preventing explicit modelling of these algorithms, were the limitations imposed by strict metamodelling: a model cannot span multiple levels.
These problems let to the obfuscation of tool semantics, and the strong reliance on implementation details for all algorithms.

\subsection{Moving Away from Physical Conformance}
As all problems seem to be situated in the physical conformance dimension, the most direct solution would be to do away with this dimension completely.
This is, however, not possible, as each model still requires a physical representation in memory, as well as model management operations defined over it.

The closest we can get, is shifting away many responsibilities of the (hidden) physical conformance dimension, into the (explicitly modelled) linguistic conformance dimension.
There is a natural relation between both physical and linguistic conformance, as both are related to the structure of the model.

To do this, we define a new metamodel, which is identical to the (implicit) metamodel of the implementation layer.
This metamodel, however, is defined in the linguistic dimension, thus making it explicit.
For clarity in our discussion, we call this metamodel $\mathit{LTM}_\perp$, shown in Figure~\ref{fig:LTM_bottom}.
It can be seen that it is a metamodel for basic graphs, where nodes might have values.
These possible values are \textit{Type} (the type of any value type, including itself), \textit{Action} (the type for all action language constructs, such as \textit{While}, \textit{If}, and \textit{FunctionCall}.), \textit{Integer}, \textit{Float}, \textit{Boolean}, and \textit{String}.
Additionaly, edges are a subclass of nodes, meaning that they can have incoming and outgoing edges themself.
Since every element is a subclass of \textit{Node}, an edge can start and end at any element, including itself.
As this is only at the conceptual level, it was done to make reasoning about edges from edges conceptually clearer.
The leftmost association from \textit{Node} to itself represents the type of inheritance relations: since inheritance relations are also explicitly modelled~\cite{MultiConformance}, they require their own metamodel.
And since the $\mathit{LTM}_\perp$ should be self-describing, it contains this type too.

Since any model conforms to the (often implicit) physical metamodel in the physical dimension, they should also, by definition, conform linguistically to $\mathit{LTM}_\perp$.
We call this new linguistic conformance to $\mathit{LTM}_\perp$ $\mathit{conformance}_\perp$.
While it is actually the same as conformance in the physical dimension, we shift this to the linguistic dimension to offer it to the users.
Thanks to the possibility for multiple metamodels for a single metamodel~\cite{MultiConformance}, it is possible for the model to be typed by multiple linguistic metamodels: $\mathit{LTM}_\perp$, and the original linguistic metamodel(s).
Figure~\ref{fig:moving_ltm} shows the 1-to-1 mapping of the Physical Type Model (PTM) to the linguistic dimension.
As each element necessarily conforms to the PTM, it will also, by definition, conform to the new $\mathit{LTM}_\perp$.

\begin{figure}
    \centering
    \includegraphics[width=0.8\columnwidth]{figures/LTM_bottom.pdf}
    \caption{$LTM_\perp$, allowing for any element to connect to any other element.}
    \label{fig:LTM_bottom}
\end{figure}

\begin{figure}
    \centering
    \includegraphics[width=\columnwidth]{figures/moving_ltm.pdf}
    \caption{$LTM_\perp$ added in the linguistic dimension, which is identical to the one in the physical dimension.}
    \label{fig:moving_ltm}
\end{figure}

\subsection{Coping with Strict Metamodelling}
By lifting the physical conformance relation up to the linguistic conformance dimension, we achieve a way of explicitly modelling, albeit indirectly, in the physical dimension.
Users are therefore able to, using their normal linguistic modelling tools, alter the physical dimension.
The physical representation of the model is thus seen as an instance a linguistic metamodel.

While the tool still complies to strict metamodelling in the linguistic dimension, $\mathit{LTM}_\perp$ is taken so general, that the complete metamodelling hierarchy can be expressed as a direct instance of it.
This effectively flattens the original metamodelling hierarchy into a single level: $\mathit{LTM}_\perp$ at the metamodelling level, and everything else at the modelling level.
In this single model level, which is only a different view on the same model, strict metamodelling does not restrict anything, even links between different levels (of the original hierarchy).
Figure~\ref{fig:different_hierarchies} represents the two possible views on the modelling hierarchy: either through the usual conformance relation (Figure~\ref{fig:different_hierarchies_A}), or the new $\mathit{conformance}_\perp$ relation (Figure~\ref{fig:different_hierarchies_B}).

Depending on the used metamodel and conformance relation, strict metamodelling can thus be interpreted differently.
Note that this is still distinct from dropping strict metamodelling completely: strict metamodelling is still used throughout the complete environment, and still imposed on instances, even with the $\mathit{conformance}_\perp$ relation.
But the implications of strict metamodelling depend entirely on the metamodel: for normal linguistic metamodels, strict metamodelling is as it was originally designed, but for the special metamodel $\mathit{LTM}_\perp$, strict metamodelling does not constrain anything because every element is at the same level.

Coping with strict metamodelling alone does not solve all problems.
While the limitation of not being able to model executable models across levels was removed, these executable models still directly interact with the underlying data structure.
This is still a lingering aspect of the physical dimension, which we tackle next.

\begin{figure*}
    \centering
    \begin{subfigure}{0.3\textwidth}
        \centering
        \includegraphics[width=\textwidth]{figures/different_hierarchies_A.pdf}
        \caption{Petri nets metamodel}
        \label{fig:different_hierarchies_A}
    \end{subfigure}
    \begin{subfigure}{0.6\textwidth}
        \centering
        \includegraphics[width=\textwidth]{figures/different_hierarchies_B.pdf}
        \caption{$LTM_\perp$}
        \label{fig:different_hierarchies_B}
    \end{subfigure}
    \caption{Different modelling hierarchies for the model \textit{my\_PN}, as seen through two different linguistic views.}
    \label{fig:different_hierarchies}
\end{figure*}

\subsection{Abstracting Implementation Details}
The 1-to-1 mapping between the physical metamodel and $\mathit{LTM}_\perp$ made it possible to linguistically access the physical dimension.
But the physical dimension is still part of the implementation, and could therefore change in subsequent versions.
This would bring us to language evolution, as $\mathit{LTM}_\perp$, and possibly $\mathit{conformance}_\perp$, would also have to be updated, together with all saved models.
While some advances are made to language evolution in order to do these changes automatically, we don't want to expose users to these problems.

Users should therefore not be bothered with the internals of the tool, not even the physical data representation.
And while users do need access to a physical-like representation, it can certainly be a different one than that which was implemented, as long as there exists a mapping between them.
$\mathit{LTM}_\perp$ is thus merely a wrapper, or an abstraction of the actual data structure being used.
Modifications on instances of $\mathit{LTM}_\perp$ are mapped over to changes in the physical dimension, and vice versa.
This can be done by having the actually implemented data structure implement an interface as if it were conforming to $\mathit{LTM}_\perp$.
This requires a mapper between $LTM_\perp$ and the physical metamodel, which is similar to physical mappers~\cite{MULTI_Modelverse}.
Now, however, the mapping is only defined for a single metamodel, instead of for each metametamodel individually, greatly relieving users.
This is the mapping shown in Figure~\ref{fig:change_physical}.

Decoupling the implementation of algorithms from the actual internal data structure makes it possible to perform drastic changes internally (\textit{e.g.}, switching between database technologies), without any change whatsoever to the explicit models of model management operations, nor to $\mathit{LTM}_\perp$ or $\mathit{conformance}_\perp$.
Related to this, different tools can implement exactly the same algorithms, which were explicitly modelled, even if their implementation language and internal data structure is completely different.
They only need to agree on $\mathit{LTM}_\perp$ and the corresponding $\mathit{conformance}_\perp$, and an explicitly modelled action language to go along with it.
All other implementation choices become truely that: choices made in the implementation that don't affect functionality at all.

\begin{figure}
    \includegraphics[width=\columnwidth]{figures/change_physical.pdf}
    \caption{Changing the physical metamodel with something else, as long as there is still a mapping to $LTM_\perp$. SQL metamodel not expanded due to space constraints.}
    \label{fig:change_physical}
\end{figure}

\subsection{Overview}
%TODO elaborate
We now relate back to the problems we initially observed.
The strong reliance on the physical dimension were caused by both pragmatic reasons (\textit{i.e.}, developers are more familiar with programming languages) and theoretical limitations (\textit{i.e.}, strict metamodelling prevents a model from referencing two different levels).
While we can't do much about the pragmatic reasons, we have used multi-conformance to offer a different view on the model: instead of being an instance of a user-defined metamodel, it becomes an instance of $\mathit{LTM}_\perp$.
Using the $\mathit{conformance}_\perp$ relation, strict metamodelling does not constrain the user anymore because all model elements reside at the same level.

Similarly, the physical implementation and mapping to $\mathit{LTM}_\perp$ were decoupled from the linguistic metamodel, making it possible to alter the implementation without affecting $\mathit{LTM}_\perp$ or its instances at all.