%Features for bidirectionality as evaluation framework
\section{Evaluation criteria}\label{sec:features}





\begin{figure}[ht]
  \center
  \includegraphics[width=8cm]{figures/features.png}
  \caption{Features of bidirectional tools}
  \label{fig:features}
  %\vspace{-1cm}
\end{figure}



\subsection{Reverse}\label{sec:reverse}

There are two main approaches for realizing bidirectional transformations: (i) by programming forward and backward transformations in any convenient unidirectional language, i.e., the backward transformation is given by user (see the entry \emph{given} in Table \ref{}) or (ii) by using a bidirectional transformation language where every program describes both a forward and a backward transformation simultaneously (see the entry \emph{computed} in Table \ref{}). 

A major advantage of the latter approach is that the consistency of the transformations can be guaranteed by construction. Otherwise, an approach which requires the reverse transformation to be given by the user is cumbersome and error-prone; in fact, the designer need to manually ensuring the consistency. The user also has to guarantee that the given reverse behaves like the mathematical inversion, i.e., it has to be guaranteed that $f = f \circ f-1 \circ f$. If this property cannot be guaranteed, no synchronisation is possible \cite{HLR08}.




\subsection{Source/Target relationship}\label{sec:relationship}

The difficulty faced with bidirectional transformation is the often neglected fact that transformations in general are %neither total 
\emph{non injective}. %In other words, %there are concepts in the source model that do not have a correspondence in the target model and vice versa. Also, there may be several source models being mapped to one and the same target model.
%Bidirectionality in model transformations raises not obvious issues mainly related to intrinsic characteristics of model transformations, which are in general \emph{not bijective}. 
Going in more details, a bidirectional model transformation is \emph{bijective} if the consistency relation is a bijection, which means that for any model there exists a unique corresponding model which is consistent with it. It is a strong condition since it requires two models to be isomorphic (i.e., the same information represented in different ways). %It implies that it is impossible to define a bijective bidirectional transformation between two sets of models which have different cardinalities \cite{landscape}.  

The ability to specify non-injective transformations is a not obvious characteristic required in the current bidirectional transformation languages. %On the one hand, as soon as modifications to the target model of a transformation are allowed and they are not propagated back to the source, each time the source model is manipulated a complete target re-generation is needed, thus overwriting the modifications operated on the target. On the other hand, 
In fact, if the transformation is non-injective, when applying a transformation to a pair of models which are inconsistent, there can be more than one way in which consistency could be restored. As a consequence, the \emph{correctness} \cite{S09} of a transformation may fail whenever more than one way to propagate the changes exists.

From the best of our knowledges, there exist two approaches to cope non-injectivity. On the one  hand, additional constraints can be added during the implementation of the transformation in order to avoid ambiguities. It means that the mappings are made bijective, in the sense that there can be only one way (encoded in the transformation code) to restore the consistency relation (see the entry \emph{selected solution} in Table \ref{}). On the other hand, the transformation is able to generate all the feasible solutions according with the consistency relation (see the entry \emph{multiple solutions} in Table \ref{}).   

%Current bidirectional approaches typically deal with non-injectivity by 
%requiring the mapping to be bijective by adding additional constraints, which have to be known beforehand the transformation implementation. 
%This means that in order to have bidirectionality the transformation (or the involved sub-portion of it) must be bijective, in the sense that there can be only one way (encoded in the transformation code) to restore the consistency relation (i.e., a selected solution). 

%However, there exist scenarios in which the mapping can not be made unequivocal until all the potential solutions are available. In other words, there are cases where the constraints to make the mapping bijective are unknown or cannot be formalized and thus it is important to deal with non-injectivity by managing the availability of multiple solutions. 


\subsection{Transformation domain}\label{}

Transformations in general are \emph{partial}, i.e. there are concepts in the source model that do not have a correspondence in the target model and vice versa. This may occurs when, for instance, only the relevant concepts of the source models are mapped toward the corresponding target elements~\cite{HLR08}, or even if the involved metamodels may have different expressive power. 

Considering a transformation as a function, the partiality correspond to a \emph{not surjective} function (i.e., the image does not fill the whole codomain). By running the transformation in the backward direction, elements which not have a counterpart may be lost.
 
A bidirectional approach may be able to deal with a partial domain in two different way: by modifying the transformation with mappings involving the neglected elements (see \emph{forced mapping} in Table \ref{}) or by implementing a dedicated support to maintain all the informations from both the domains. 

%In case of partial transformations, it is possible to operate manipulations on the target model taking it away from the domain of the transformation, or to add new target elements requiring a source metamodel extension in order to be coherently back propagated. 

\subsection{Tracing}\label{}

The issues related to the above mentioned features can arise problems when trying to perform tranformations in both the directions. Some of these difficulties can be alleviated by managing \emph{tracing information} \romina{reference}
which is concerned with the mechanisms for recording different aspects of transformation execution. In particular, trace links between source and target model elements may be created and maintained to contribute to the resolution of some ambiguities (see \emph{} in Table \ref{}). Furthermore, also the information lost in the current execution of the transformation may be stored  (see \emph{} in Table \ref{}). In particular, trace elements should be generated each time a model element is discarded by the mapping and need to be stored in order to be regenerated during the backward transformation. 



