modelverse/techreport/conformance_bottom/3-conformance.tex

\section{Types of Conformance}
\label{sec:conformance}
It was found out that there is not a single kind of type/instance relation, but actually multiple, to cope with the different kinds of relations~\cite{OCA}.
A distinction was made between conformance to the physical implementation, and to the linguistic metamodel.
This classification architecture was termed the Orthogonal Classification Architecture (OCA).
Other work~\cite{Bruno,Ken} has shown the presence of yet another type/instance relation, which links back to the semantics of the model.
Depending on which dimension is used, different type/instance hierarchies emerge, changing the implications of strict metamodelling.
Sadly, terminology is rather inconsistent in the literature, making it difficult to clearly communicate about the different dimensions.
This section serves to clear up the terminology we will use throughout this paper.

A concise example is shown of a simple petri net model, which conforms to three different metamodels with respect to these different conformance relations.

\subsection{Physical Conformance}
The low-level view on conformance is what we call \textit{physical conformance}.
This is the kind of conformance used by tool-developers and model management operations, as it does not impose many constraints.
It sits at the physical level, where it is responsible for how data is represented physically in memory.
Physical representation is unrelated to language engineering, and is completely managed by the implementation language of the tool.
Physical conformance, therefore, is checked by their respective compilers (\textit{e.g.}, GCC and Java compiler).

But since it is checked only by the compiler, no restrictions are placed upon the crossing of modelling levels.
Indeed, all models, metamodels, metametamodels, and so on, are similar at this level: they are data created by the user that can be manipulated by the tool.
Tool internals, as well as model management operations, are mostly implemented at this level, as it allows all possible modifications to the model.
Additionally, this level is efficient due to its close relation to the implementation, and use of advanced tools such as efficient compilers.
Since this is the lowest level of conformance, to which every model conforms by definition, all operations need to be applicable to all models.
Most of the time, the only common representation of all models is the data structure used to store them.
These operations thus alter the internal data structure directly, without any kind of domain-specific algorithm in between.

While these modifications are again efficient, and furthermore easy to implement for the tool developer, the strong link to the implementation is made obvious.
Porting all tool internals to a different tool doesn't only require porting between programming languages, but also between different internal data representations.
Changing implementation details, which should be transparent to the user, will have significant implications on these algorithms as well.

In our petri net example, this relates to how the petri net is stored in memory: with all elements being instances of a generic \textit{Class} defined by the implementation language.
This is shown in Figure~\ref{fig:pn_physical}: the model conforms to a simple graph representation, where places and transitions are represented as nodes, and the edge between them is mapped to the edge of a graph.
Depending on the implementation, a different physical metamodel can be used, for example that of an SQL database.
The metamodel is the same for every model, be it petri nets, class diagrams, object diagrams, statecharts, or even a domain-specific language.
The reason for this is simple: if the model doesn't conform to this metamodel, the tool has no way of representing it in memory.

\begin{figure}
    \centering
    \includegraphics[width=0.5\columnwidth]{figures/pn_physical.pdf}
    \caption{Physical conformance of a petri net model.}
    \label{fig:pn_physical}
\end{figure}

\subsection{Linguistic Conformance}
\textit{Linguistic conformance} is the traditional view on conformance, which is heavily used for domain specific modelling.
It is also the view offered to users: if a user creates a metamodel, and subsequently instantiates it, this is through linguistic conformance.
The relation defines whether or not a user-defined model is a valid instance of another user-defined (possibly by another user) metamodel.
Checks mostly have a structural notion (\textit{e.g.}, is a link between these entities allowed and are all required attributes present), though minor semantical constraints are also possible.
These semantical constraints are for example range checks on attributes (\textit{e.g.}, integer must be larger than 5), global restrictions on values of attributes (\textit{e.g.}, the sum of these two attributes needs to be greater than 10), or global restrictions on the structure (\textit{e.g.}, no loop possible for a certain association).
Whereas structural checks are easily implemented through the use of a metamodel, the additional semantic constraints are often implemented using some kind of executable language.
Constraints are written in constraint languages, such as OCL, but are sometimes already shifted to the implementation language (\textit{e.g.}, implemented in Python as in AToM$^3$~\cite{AToM3} and AToMPM~\cite{AToMPM}).

Contrary to the physical conformance dimension, users can extend the linguistic conformance dimension by adding, modifying, or deleting metamodels.
As such, a model is not, by definition, always conforming to its provided metamodel.
This conformance relation is also not checked by the implementation language, but by the tool itself.
But whereas most programming languages are standardized and have a clear definition on what it means to conform, this is not always the case in the linguistic dimension.
Each tool has its own interpretation of what it means for models to conform to another model.
Making this relation explicit, and thus offering the user the choice, was the primary effort of our previous work~\cite{MultiConformance}.

It is also at this level that strict metamodelling comes into play: no links, except for the \textit{instanceOf} link, is allowed to cross the levels defined by this relation.
Tool users should ideally only be concerned with this dimension, as it offers support for domain-specific languages and makes use of all the features implemented by the tool (\textit{e.g.}, strict metamodelling, type checking, model transformations, and consistency management).

In our petri net example, this relates to the metamodel of petri nets which constrains the structure of the net.
Example constraints are that no direct link between places is possible (specified by the omission of an association from \textit{Place} to itself), and the number of tokens in a place needs to be positive (specified by a static semantics constraint).
This is shown in Figure~\ref{fig:pn_linguistic}, where each element conforms to a metamodel that is specific to the model.
Contrary to physical conformance, this metamodel is only valid for petri net instances.
At this level, it is impossible to create, for example, a link from the place instance to the place type, due to strict metamodelling.
There is also no mention of the implementation: this relation does not imply anything on how a place is represented in memory (\textit{e.g.}, as a node in a graph or as an ID in a SQL database).
It does, however, constrain the structure of the model.
The metamodel contains an association from \textit{Place} to \textit{Transition}, and vice versa, but no transition from \textit{Place} or \textit{Transition} to itself.
This constrains the instances more than was the case with physical conformance.
Furthermore, it is often this dimension of conformance that is used to specify concrete syntax.
Strictly speaking, the representation of the model in physical conformance would have to be the actual graph that is stored in memory.
We did not do this to prevent confusion.

\begin{figure}
    \centering
    \includegraphics[width=0.5\columnwidth]{figures/pn_linguistic.pdf}
    \caption{Linguistic conformance of a petri net model.}
    \label{fig:pn_linguistic}
\end{figure}

\subsection{Ontological Conformance}
The final conformance dimension is \textit{ontological conformance}, which relates purely to the semantics of the model.
It is also one of the views offered to users, but is not related to the structure of the model, only to the properties the model satisfies.
As it relates to semantics, execution of the model is required.
Depending on the property of interest, the algorithm executed varies from, for example, simulation (\textit{e.g.}, trace satisfies some property) to state space analysis (\textit{e.g.}, deadlocking system).

The algorithm to be executed often again relates back to the physical dimension, as this is where the implementation is defined in case the implementation language is used.

In our petri net example, this relates to the properties satisfied by the petri net, such as deadlocking, safety, or reachability.
Figure~\ref{fig:pn_ontological} represents a petri net without any tokens and not generators, so the petri net is clearly deadlocking and not live.
Ontologically speaking, the petri net thus conforms to the \textit{deadlocking} property and not to the \textit{live} property.
This concept is again broader than petri nets only, and might also be applicable to formalisms that have similar sementics or properties.
But while previous conformance relations focussed purely on static aspects of the model (\textit{i.e.}, structure and static semantics), this conformance dimension focusses exclusively on the semantics through execution.

\begin{figure}
    \centering
    \includegraphics[width=0.5\columnwidth]{figures/pn_ontological.pdf}
    \caption{Ontological conformance of a petri net model.}
    \label{fig:pn_ontological}
\end{figure}