modelverse/techreport/multi_conformance/5-related_work.tex

\section{Related Work}
\label{sec:related_work}
The problems we solve have already been partially addressed.
But while our approach solves several problems simultaneously, by taking a different view on the type/instance relation, other approaches are more conservative, in that they solve only one specific problem by making changes to the current state of the art.

The main motivator for our research was the credo ``model everything at the right level of abstraction, using the most appropriate formalism''~\cite{MPM}, as popularized in Multi-Paradigm Modelling (MPM).
Naturally, this applies to the system being modelled.
We, however, also apply this to the tool, which will be used for the modelling, as there would be no reason to consider the tool as a special entity for which this credo does not hold.
As a natural step then, the conformance algorithm was made explicitly modelled.
It is not only the credo which we take over from MPM, but we also create our tool to be used in an MPM setting.
For example, our notion of conformance could possibly be used for multi-view and multi-abstraction modelling.
Further research is required in this direction.

While the conformance relation has, to the best of our knowledge, always been hardcoded as foundational aspect of the tool, the type mapping has frequently been made explicit, certainly in theory.
For example, de Lara \textit{et al.}~\cite{FromTypesToTypeRequirements,GenericityForModelManagement} have explicitly defined type mappings (\textit{explicit bindings}) for their concepts, which are an alternative form of model typing~\cite{ConstraintBasedModelTypes}.
VPM~\cite{GenericAndMetaTransformations} made the \textit{instanceOf} links available just like any other element, thus avoiding hardcoded relations.
Our typing relation is actually a relation between models, similar to the relations defined for megamodelling (\textit{e.g.}, \cite{MMTF,MMINT}).
Kurtev \textit{et al.}~\cite{ModelBasedDSLFrameworks} proposes to define a model as a triple, containing the model, the metamodel, and the type mapping.
No mention is made, however, about making this relation depend on the conformance relation.
Zschaler~\cite{ConstraintBasedModelTypes} already proposed to make explicit all constraints on metamodels in the model type, rather than hiding them away in the matching relation.
We also believe that constraints should not be hidden in the matching relation, but instead of putting it in the model type, we make the matching relation explicit.

Models have also often been represented using a graph representation, for example in VMTS~\cite{VMTS}, or in the framework proposed by Kurtev \textit{et al.}~\cite{ModelBasedDSLFrameworks}.
Despite their mapping to graphs, they include special edges, such as an inheritance edge.
Such edges are not defined in general graph theory, and should therefore be avoided as it mixes parts of the structure (\textit{i.e.}, the actual graph) with the semantics (\textit{i.e.}, the system we represent with the graph).
In our approach, everything is stored as a graph, which purely defines the structure of the models.
Semantics is not given by this graph representation: it is given by the executable models, which are themselves models in our tool, represented as graphs.

Closest to our contribution is a-posteriori typing~\cite{APosterioriTyping}, where a single model element has one single (constructive) type, but possibly also a set of additional types which act as views on the model.
The constructive type is the one gained through instantiation, and is not modifiable, nor user-definable.
Additional types, however, are dynamically determined when used in a specific setting.
Whereas in our approach we explicitly model the conformance relation and the type mapping, a-posteriori typing is more of a kind of conditional typing, related to their implementation of concepts.
Elements are considered as instances of specific types only if some conditions are met, such as having a specific attribute with a value within a certain range.
Its primary use is for reuse of functions, as exemplified in their application on the petri net model.
In comparison, our approach offers more flexibility, as an element might be typed by multiple element (similar to a-posteriori typing), but also typed using multiple conformance relations.
Since conformance relations are explicitly modelled, there are no limitations as to what the modeller can model.

Similar to our work is also that of the Dynamic Multi-Layer Algebra~\cite{DMLA}, which also acknowledges the importance of bootstrapping the system and making the instantiation explicit.
But whereas the instantiation is explicitly mentioned in the paper and the algebra, there is no way for users to modify or extend it at run-time.

Retyping is offered by other tools, either through model transformations as in AToMPM~\cite{AToMPM} and MetaDepth~\cite{MetaDepth}, or by seperate operations as is the case in MMINT~\cite{MMINT}.
Instead of retyping, our approach has multiple types simultaneously, thus avoiding frequent type conversions at the cost of managing all type relations simultaneously.
Retyping is also possible, without the need for seperate operations, as the typing relation is just another model.

Related to multiple types for a single element, Nivel~\cite{Nivel} allowed for multiple classification.
In contrast to our approach, only a single kind of conformance relation was defined, which was directly encoded into their formalization and is thus a fundamental part of the tool.
Similarly, they hardcoded concepts like subtyping, reducing flexibility further.

Several hardcoded conformance relations were proposed, such as that of Nivel~\cite{Nivel} and by Guy \textit{et al.}~\cite{OnModelSubtyping}.
Each of these explicitly requires some attributes to be present, such as multiplicities.
In general, it is not guaranteed that the metamodel will even contain these notions, let alone that they have identical semantics.
By making the semantics of these elements explicit, users are certain about what the values mean, but additionally they can also opt for simpler type/instance relations, which don't take into account some of these restrictions.
Salay and Chechik~\cite{AgilityInMDE} raised the need for modification (relaxation) of the conformance relation to allow for agility.

In some way, de Lara \textit{et al.}~\cite{FromTypesToTypeRequirements} propose a different kind of conformance check, though still hardcoded: using requirements for elements instead of types provided during instantiation.
We believe that in our framework, this would just be a specific kind of conformance check, which can again be explicitly modelled and included for users.