modelverse/techreport/multi_conformance/4-example.tex

\section{Example Application: Subtyping Semantics}
\label{sec:example}
We now present the power of our approach through an example application.
Our example makes use of different notions of subtyping, which is closely related to the type/instance relation.
In this application, we mainly focus on determining wheter a model conforms to a metamodel.
A similar discussion is possible for instantiation, though here we assume that the model was already created one way or the other.
As current tools hardcode their conformance relations, users have no other option than to use the given type system.
We continue by showing how our tool, the \textit{Modelverse}~\cite{ACMSRC}, is able to cope with different kinds of type systems.
First, we briefly elaborate on the typing problem at hand.

\subsection{Subtyping}
Throughout the years, different kinds of subtyping relations have been defined and used.
Subtyping directly influences the conformance check: an instance of \textit{Class B} is also an instance of \textit{Class A}, if either \textit{B} is \textit{A}, or if \textit{B} is a subtype of \textit{A}.
The definition of \textit{subtype} varies between the different type systems.
We briefly present the two major classes of type systems: nominal and structural typing~\cite{Typing}.

\subsubsection{Nominal Typing}
The most commonly used kind of subtyping is nominal typing.
With nominal typing, subtypes must be explicitly declared, such that there can be no confusion or unexpected behaviour.
Most programming languages are implemented like this, with classes that can \textit{inherit} from one another.
If \textit{Class B} inherits from \textit{Class A}, all instances of \textit{B} will conform to both \textit{A} and \textit{B}.
Additionally, the structure of \textit{B} is automatically extended with all concepts of \textit{A}.
So if \textit{Class A} had an attribute \textit{a}, all instances of \textit{B} also have this attribute, in addition to all the attributes that were also provided by \textit{B}.

Nominal typing is most oftenly used in Object-Oriented General-Purpose Languages (GPL), such as C++, Python and Java.
Even then, subtle differences can be seen.
For example, C++ and Python allow for multiple inheritance (\textit{i.e.}, a single class can inherit from multiple classes), whereas Java restricts users to single inheritance (\textit{i.e.}, a single class can only inherit from one class).
Again, several variants exist in semantics: attribute resolution is different between C++ and Python, even though both have multiple inheritance.
Even worse, some versions of Python offer a different variant of multiple inheritance than other versions of the language.

Nominal typing is considered safer, as the typing information can be used both for typechecking, and at run-time.
Additionally, checking subtyping relations becomes almost trivial.

\subsubsection{Structural Typing}
At the other end of the spectrum lies structural typing, where subtypes are implicitly detected instead of explicitly defined.
A \textit{Class B} is considered to be a subtype of \textit{Class A} if each feature of \textit{A} is also present in \textit{B}.
Consequently, if \textit{A} and \textit{B} have exactly the same features, they will be considered equivalent, with all instances of \textit{A} being instances of \textit{B}, and vice versa.

Structural typing is used by languages such as OCaml, Go, and Haskell.
Now again, subtle differences exist, such as whether or not the name of the features need to be identical, in addition to the type.
Structural typing is considered more elegant than nominal subtyping, as it lies closer to type systems studied in the literature.

\subsection{Conformance Relation}
Current (meta-)modelling tools, and even programming language compilers, hardcode their type system, and the user has to oblige.
While the default type system is often a sane choice for the domain for which the tool was developed, situations will occur where the other choice might have been easier for the user.
Users have no choice though, as the semantics of the conformance relation is hardcoded.
Even worse, many modelling tools explicitly hardcode special \textit{instanceOf} and \textit{subtypeOf} links inside of their data structure.

With explicitly modelled type/instance relations, typings become modifiable by the user, possibly even automatically using model transformations.
In our case, it is further possible to create multiple conformance relations, one for each kind of type system, and use either, depending on the situation.
This makes it possible for an instance of \textit{Class B} to conform to \textit{Class A} with only one kind of conformance relation, but not the others.
Depending on the conformance relation chosen by the user (ideally, the one closest to the problem domain), the outcome of the conformance check and every related operation will vary.

\subsection{Modelverse}
In the Modelverse, users are required to specify which conformance relation they want to use, and where they want this type mapping model to be stored.
When a model is instantiated, an instantiation policy also needs to be provided.
Later on, when conformance is checked, the previously specified conformance relation is used.

Users still have to implement the conformance checks they wish to use, except if it is provided by default, or by other users.
For our example, a subtyping check for nominal typing will follow inheritance links when required, whereas a structural typing check will only look at the features of the class.

Note that, for the case of nominal typing, there are links with a special semantics.
In our approach, these links are just normal links, stored like any other link (\textit{i.e.}, as an edge).
The conformance check, however, knows the semantics of the links, and uses them appropriately.

An example is given next, resembling the class diagram given in Figure~\ref{fig:class_diagram}.
The semantics is clear for nominal typing: \textit{Class B} inherits from \textit{Class C}, and \textit{Class C} is completely different, but has (for whatever reason) a superset of the attributes of \textit{Class A}.
For structural typing, the inheritance link holds no semantics, and is considered just like any other association between classes.
As such, the instantiation algorithm creats instances of \textit{Class B} which only hold an attribute \textit{b}, and no attribute \textit{a}.
It follows that Figure~\ref{fig:object_diagram_nominal} and \ref{fig:object_diagram_structural} are the result of instantiation using nominal and structural subtyping, respectively.

\begin{figure}
    \centering
    \includegraphics[width=0.4\columnwidth]{figures/class_diagram.pdf}
    \caption{Class Diagram of the example.}
    \label{fig:class_diagram}

    \begin{subfigure}[b]{0.49\columnwidth}
        \centering
        \includegraphics[width=0.8\columnwidth]{figures/object_diagram_nominal.pdf}
        \caption{Using nominal subtyping.}
        \label{fig:object_diagram_nominal}
    \end{subfigure}
    \begin{subfigure}[b]{0.49\columnwidth}
        \centering
        \includegraphics[width=0.8\columnwidth]{figures/object_diagram_structural.pdf}
        \caption{Using structural subtyping.}
        \label{fig:object_diagram_structural}
    \end{subfigure}
    \caption{Object Diagram of the example.}
\end{figure}

The results of the conformance check for nominal and structural subtyping are shown in Table~\ref{table:conf_nominal} and Table~\ref{table:conf_structural} respectively.
As can be seen, results are very different, which could potentially alter the complete semantics of the model.
While we do not want to argue which one is the best, we offer the user the possibility to use either of these (or others), depending on what the user believes to be the closest match to the problem domain.

\begin{table}
    \normalsize
    \centering
    \begin{tabular}{l|c c c}
     conformsTo & A             & B             & C             \\
     \hline
     a : A      & \checkmark    &               &               \\
     b : B      & \checkmark    & \checkmark    &               \\
     c : C      &               &               & \checkmark    \\
    \end{tabular}
    \caption{Conformance check results for nominal subtyping.}
    \label{table:conf_nominal}
\end{table}

\begin{table}
    \normalsize
    \centering
    \begin{tabular}{l|c c c}
     conformsTo & A             & B             & C             \\
     \hline
     a : A      & \checkmark    &               &               \\
     b : B      &               & \checkmark    &               \\
     c : C      & \checkmark    &               & \checkmark    \\
    \end{tabular}
    \caption{Conformance check results for structural subtyping.}
    \label{table:conf_structural}
\end{table}

In the future, we plan to provide a sane default, similar to the conformance check found in most other tools.
This will simplify modelling and prevents users from the associated complexity if this functionality is not needed.