%\vspace{-0.4cm}
\section{Scenario}\label{sec:bidirectionality}
%\vspace{-0.2cm}

Bidirectional model transformations brings some not obvious issues mainly addressable to the non-injectivity and the non-totality of transformations as well as its own expressivity~\cite{HLR08}. To better illustrate such difficulties, hereafter we will consider a non-bijective class diagram to relational data base (\emph{UML2RDBMS}) benchmark scenario ~\cite{CFHLST09,HLR08}. A simplified version of the UML and RDBMS metamodels are depicted in Figure \ref{fig:UMLmm} and Figure \ref{fig:RDBMSmm}, respectively. Only persistent classes are mapped to correspondent tables and their attributes to columns in the tables, including inherited attributes. In order to preserve all the information of the source diagram attributes of non-persistent classes have to be distributed over those tables stemming from persistent classes which access non-persistent ones. 
%Accordingly to the specification of the \emph{UML2RDBMS} transformation, each package is mapped in a corresponding schema, each persistent class is mapped to the correspondent table and its attributes to columns in the table, including inherited attributes. If an attribute is marked as primary, then the corresponding column will be transformed as primary key of the related table. Non-persistent classes are not mapped to tables. However, one of the main requirements of the transformation is to preserve all the information of the source diagram. That means attributes of non-persistent classes have to be distributed over those tables stemming from persistent classes which access non-persistent ones.

 

%\begin{figure}[t]
%  \centering
%  \subfigure[]{\label{fig:UMLmm}\includegraphics[width=5.3cm]{figures/UMLmm.jpg}}
%  \subfigure[]{\label{fig:RDBMSmm}\includegraphics[width=5.1cm]{figures/RDBMSmm.jpg}}
%  \caption{Simplified UML (a) and RDBMS (b) metamodels}
%  \label{fig:metamodels}
%  %\vspace{-1cm}
%\end{figure} 

  



%commento lo scenario biettivo
%\subsubsection{A bijective scenario:}
%
%For instance, the application of the UML2RDBMS transformation to the class diagram in Figure \ref{fig:UMLm} generates the target model depicted in Figure \ref{fig:RDBMSm}. Precisely, the package \emph{university} is mapped in the corresponding table \emph{university}, the class \emph{employer} induces the generation of the corresponding table \emph{employer} while the attributes \emph{name} and \emph{department} are mapped to the corresponding columns; finally the column \emph{name} is marked as primary key of the table \emph{department}. 
%
%
%\begin{figure}[ht]
%  \centering
%  \subfigure[]{\label{fig:UMLm}\includegraphics[width=5.70cm]{figures/UMLm.jpg}}
%  \subfigure[]{\label{fig:RDBMSm}\includegraphics[width=5.70cm]{figures/RDBMSm.jpg}}
%  \caption{A sample UML model (a) and the correspondent RDBMS model (b)}
%  \label{fig:models}
%  %\vspace{-1cm}
%\end{figure}
%
%This scenario involves bijective mappings in which the forward transformation is an injective function, and the backward transformation is the corresponding inverse. In fact, by re-applying the UML2RDBMS transformation to the model depicted in Figure \ref{fig:RDBMSm} the class diagram in Figure \ref{fig:UMLm} is generated without ambiguity.
Although trivial, the scenario shows how intrinsic characteristics of bidirectional transformations may cause side effects when transforming models in forward and backward directions and, especially, when propagating changes in a round-trip process. This is illustrated by means of the following scenario configurations.

%\vspace{-0.3cm} 
\subsection{Scenario configuration 1}
%\vspace{-0.1cm}

   
Dealing with bidirectional transformations the invertibility of the function may be frustrating when the transformation is not bijective, which causes ambiguities when trying to map back corresponding target.
   
%is guaranteed by its bijectivity, i.e., by re-applying the transformation from the generated target model, the source model is generated without ambiguity. However, in general, in bidirectional languages, the forward transformation can be an arbitrary function and not necessarily bijective. 


\floatsetup[figure]{style=plain,subcapbesideposition=top}
\begin{figure}[ht]
  \centering
  \sidesubfloat[]{\label{fig:UMLmm}\includegraphics[width=6.4cm]{figures/UMLmm.jpg}}
  \quad%
  \sidesubfloat[]{\label{fig:RDBMSmm}\includegraphics[width=6.2cm]{figures/RDBMSmm.jpg}}%
  \caption{Simplified UML (a) and RDBMS (b) metamodels}\label{fig:metamodels}
  %\vspace{-0.3cm}
\end{figure}
  %\vspace{-0.74cm} 


\floatsetup[figure]{style=plain,subcapbesideposition=top}
\begin{figure}[ht]
  \centering
  \sidesubfloat[]{\label{fig:UMLm2}\includegraphics[width=11cm]{figures/uml1.pdf}}
  \quad%
  \sidesubfloat[]{\label{fig:RDBMSm2}\includegraphics[width=7cm]{figures/rdbms1.pdf}}%
  \caption{The UML model (a) and the correspondent RDBMS model (b)}
  \label{fig:models2}
  %\vspace{-0.3cm}
\end{figure}
  %\vspace{-0.38cm}
  
%\begin{figure}[ht]
%  \centering
%  \subfigure[]{\label{fig:UMLm2}\includegraphics[width=5.70cm]{figures/UMLm.jpg}}
%  \subfigure[]{\label{fig:RDBMSm2}\includegraphics[width=5.70cm]{figures/RDBMSm.jpg}}
%  \caption{The UML model (a) and the correspondent RDBMS model (b)}
%  \label{fig:models2}
%  %\vspace{-1cm}
%\end{figure}

In order to illustrate the difficulties which may occur, Figure \ref{fig:UMLm2} shows a UML model. In particular, the package {\tt\small university} is composed of an inheritance hierarchy of classes. The persistent class {\tt\small professor}, with attribute {\tt\small number\_of\_publications}, inherits from the persistent class {\tt\small employer}, with attribute {\tt\small department}. The parent class {\tt\small worker} is not persistent and contains the attribute {\tt\small working\_address}. Finally, the top parent non-persistent class {\tt\small person} has the attribute {\tt\small name}. 

Applying the \emph{UML2RDBMS} transformation to the class diagrams depicted in Figure \ref{fig:UMLm2}, the schema in Figure \ref{fig:RDBMSm2} is obtained. In particular, the inheritance hierarchy of non-persistent classes {\tt\small person} and {\tt\small worker} and persistent class {\tt\small employer} is flattened as a single table {\tt\small employer} that has columns for all the fields of the various classes. In general, attributes of the parent classes induce the corresponding columns in both the parent and child classes, then the table {\tt\small professor} inherits all the attributes of the table {\tt\small employer}. It gives rise to non-injective mappings. 

Furthermore, in order to obtain the original source model from the target, the transformation should be able to preserve all the information of the UML model: i.e., non-persistent classes have to be generated again and attributes have to be restored in the original classes.

% spostare dopo -- Some of these problems can be alleviated by managing \emph{tracing information} of the transformation executions: like this each generated element can be linked with the corresponding source and contribute to the resolution of some of the ambiguities. They can be exploited later on to trace back the changes. Nonetheless, as showed in the next scenario, traceability links between source and target elements is a necessary but not sufficient condition to support bidirectionality, since for instance elements discarded by the mapping may not appear in the traces, as well as new elements added on the target side.

%\vspace{-0.3cm}
\subsection{Scenario configuration 2}
%\vspace{-0.1cm}

It is common that manual changes might be performed by designers on the generated models in order to resolve unforeseen requirements or limited expressiveness of the involved metamodels. %By taking into account the running example, any  manual modifications of the generated RDBMS model should be back propagated and eventually reflected in the source UML model. Such modifications might induce several ambiguities which need to be managed. 

For example, let us suppose that the generated model is manually modified as depicted in Figure~\ref{fig:RDBMSm3}. 
The first change involves a new column {\tt\small email} which has been added in the table {\tt \small employer}. This gives place to an interesting situation since such modifications can be reflected to the source model in Figure~\ref{fig:UMLm2} in three alternative ways: the attribute (corresponding to the manually added column) can be associated with the class {\tt \small employer} or with each of parent classes {\tt \small worker} and  {\tt \small person}, as in Figure~\ref{fig:UMLm3}. Consequently, more than one source model correctly propagating the changes exist.

\floatsetup[figure]{style=plain,subcapbesideposition=top}
\begin{figure}[ht]
  \centering
  \sidesubfloat[]{\label{fig:RDBMSm3}\includegraphics[width=7cm]{figures/rdbms2.pdf}}
  \quad%
  \sidesubfloat[]{\label{fig:UMLm3}\includegraphics[width=11cm]{figures/uml2.pdf}}%
  \caption{The modified RDBMS model (a) and the correspondent UML model (b)}
  \label{fig:models3}
  %\vspace{-0.3cm}
\end{figure}

%\floatsetup[figure]{style=plain,subcapbesideposition=top}
%\begin{figure}[ht]
%  \centering
%  \sidesubfloat[]{\label{fig:RDBMSm3}\includegraphics[width=6cm]{figures/rdbms2.pdf}}
%  \quad%
%  \sidesubfloat[]{\label{fig:UMLm3}\includegraphics[width=5.70cm]{figures/uml2.pdf}}%
%  \caption{A modified RDBMS model (a) and the correspondent UML models (b)}
%  \label{fig:models3}
%     \vspace{-0.3cm}
%\end{figure}

%\begin{figure}[ht]
%  \centering
%  \subfigure[]{\label{fig:RDBMSm3}\includegraphics[width=5.70cm]{figures/RDBMSm2.jpg}}
%  \subfigure[]{\label{fig:UMLm3}\includegraphics[width=5.70cm]{figures/UMLm2.pdf}}
%  \caption{A modified RDBMS model (a) and the correspondent UML models (b)}
%  \label{fig:models3}
%  %\vspace{-1cm}
%\end{figure}

Intuitively, each time a UML model is mapped to the correspondent RDBMS model a loss of information may cause ambiguities when trying to map back corresponding target revisions. %As said, some of these problems can be alleviated by managing traceability information. Nonetheless, mantaining trace link between source and target elements is a necessary but not sufficient condition to support bidirectionality, since for instance elements discarded by the mapping may not appear in the traces, as well as new elements added on the target side. 
For instance, if the designer of the RDBMS model in Figure~\ref{fig:models3}a wants to specify the location of the tables (that is whether the data of a given table is retrieved from remote or local resources) the considered model has to be improved and the {\tt\small isLocal} attribute of the metaclass {\tt\small Table} has to be considered as shown in the new version of the RDBMS model in Figure~\ref{fig:models3}a. Because of the limited expressive power of the considered UML metamodel which does not support this annotation, such a  revision does not have counterparts in the UML model in Figure~\ref{fig:models3}b.

%\smallskip
%By taking into account the difficulties raised in the previous example, in the next section we introduce a set of features of bidirectional transformation languages which are considered in this work as evaluation criteria. %Furthermore, we discuss which ones represent the requirements a language should meet to fully achieve its potential.

%\vspace{-0.4cm}
\section{Evaluation features}\label{sec:evaluation}
%\vspace{-0.2cm}

In this section we identify and describe a set of pragmatic features which we use to characterize the considered bidirectional model transformation approaches. The relevance to address bidirectional requirements has been acknowledged in the literature. In particular, by relying on the classification of model transformation approaches in~\cite{CH06}, the definitions given in~\cite{HLR08} and the requirements and issues provided in \cite{S09}, we have selected a number of features, which are considered relevant for evaluating bidirectional approaches, preserving the opportunity to extend this set. In this work we focus mainly only on those features which are differently supported by the considered approaches.

\subsection{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 (we refer this case with \emph{given}) or (ii) by using a bidirectional transformation language where each program describes both a forward and a backward transformation simultaneously (we refer this case with \emph{computed}). 
A major advantage of the latter approach is that the consistency of the transformations can be guaranteed by construction. Contrariwise, an approach requiring the reverse transformation to be given by the user is cumbersome and error-prone; in fact, the designer needs to manually ensure the consistency. The user  has to guarantee also 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, synchronization possibilities are reduced~\cite{HLR08}.



%In this respect EMorF strictly follows the TGGs theory. Also in Moflon the reverse is computed.


\subsection{Non-injective source/target relationship}

The difficulty faced with bidirectional transformation is the often neglected fact that transformations are \emph{non-injective} in general. 
%neither total 
%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 (like the addition of the column {\tt\small email} in Figure \ref{fig:models3}). 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.


%
The ability to specify non-injective transformations is a not obvious characteristic.
Considering the \emph{correctness} property as defined in~\cite{S09}, given two models the bidirectional transformation must ensure the consistency relation  between them when applying the transformation both in forward and backward directions.
However, the correctness of a transformation may fail whenever more than one source model (not exactly the original one) may be obtained from the generated target. In case of changes, 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 (like the addition of the column {\tt\small email} in Figure \ref{fig:models3}). In this case, in order to guarantee correctness, each source model propagating the changes may be transformed into the original target model via the forward transformation without additional side effects \cite{CDEP10}.
%

 

To deal with this kind of situations there are at least two kinds of techniques. In particular, additional constraints can be added during the implementation of the transformation in order to avoid ambiguities. In other words, the mappings are made injective, in the sense that there can be only one way (encoded in the transformation code) to restore the consistency relation (\emph{programmatic solution}). Alternatively, depending on the adopted tool, the transformation is able to generate all the feasible solutions according to the consistency relation embodied in the specified transformation (\emph{multiple solutions}).



\subsection{Partial domain coverage}

%As we can see from the Table XXX both the analysed implementations are able to deal with the same class of partial transformation. 
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 co-domain of the function). By running the transformation in the backward direction, elements which do not have a counterpart may be lost (e.g., see the non-persistent classes in Figure \ref{fig:models2}, and the added property {\tt\small isLocal} in Figure \ref{fig:models3}).
A bidirectional approach can be able to deal with a partial coverage of the transformation domains in two different way: by modifying the transformation with mappings involving the neglected elements (\emph{forced mapping}) or by implementing a \emph{dedicated support} to maintain and re-generate elements which are outside the transformation domain.



\subsection{Tracing}

Some of the difficulties arising from the forward and backward executions of transformations can be addressed by means of a dedicated management of \emph{tracing information}~\cite{PDKFPOZ11} which collect different aspects of transformation executions. 

%Tracing information collect different aspects of transformation executions
%> links between source and target model elements 
%> links between source and target elements considering also the elements discarded by the mapping

In particular, \emph{trace links} between source and target model elements may be created and maintained to contribute to the resolution of some ambiguities (for example, when restoring back the attributes in the original parent classes in Figure \ref{fig:models2}). Furthermore, links between source and target elements should also consider elements discarded by the mapping for recording the information lost in the current execution of the transformation, which need to be stored and regenerated during the backward transformation (for example, the added property {\tt\small isLocal} in Figure \ref{fig:models3}). 
%As visible from the Table XXX there are two aspects of the tracing we are interested in: the first is the storage location and the second is the kind of information recorded in the tracing instances.  The latter may be crucially important, as we saw above, when coping with non-bijective transformations. Although both approaches store the tracing information in a separate file they differ for the kind of information reordered in the tracing instances:

The relevance of these features emerges in those applications demanding the preservation of a coherent description of the whole system, when asynchronous changes occur on source or target model and need to be propagated in the opposite direction (e.g., consistency management, synchronization, change propagation, round-trip engineering).

Model synchronization (as intended in \cite{HLR08}) can be considered a functional transformation: two models are synchronised with respect to a transformation if applying it to the source model yields the relevant version of the target model (i.e., the source model is mapped to the subset of target elements involved in the transformation).
In contrast, the relevance to neglect functionality considering non-injective and non-surjective mappings arises when models have to be synchronized again if the target model changes. In this context, each particular applicative domain demands for different properties. For example, there exist scenarios in which having multiple solutions to a model transformation problem is a desired outcome. In other cases, developers may restrict transformations using programmatic solutions for efficiency reasons.

%In contrast, the RTE maps the source, target and the target changes to a new source model that when transformed produce the changed target model again. 

\subsection{Incrementality}
Incrementality refers to the ability to update existing target models based on changes in the source models, and vice versa \cite{CH06}. In particular, incremental transformations synchronize two models by propagating modifications such that information not covered by the transformation can be preserved and the computational effort can be minimized. In contrast, a classical batch transformation synchronizes two models taking a source model as input and computes the resulting target model from scratch, and vice versa \cite{GW09}. %citare wagner 

Incrementality is used in change propagation scenario in order to update existing target models based on changes in the source models. A subsequent execution with the same source models as in the previous execution has to detect that the needed target elements already exist. This detection can be achieved, for example, by using traceability links. When any of the source models are modified and the transformation is executed again, the necessary changes to the target are determined and applied. At the same time, the target elements may be preserved. In general, incremental transformations are able to avoid information loss ( for example, elements discarded by the mapping as depicted in the previous Section).

Incrementality is an important feature in model transformation that deserves a more extensive discussion. However, for the purposes of this work, technical details will not be processed and incrementality is discussed focusing on the benefits gained with regard to the considered issues . 
%Incrementality may be implemented by using model difference techniques able to compare pairs of models and detects changes. 


\vspace{0.5cm}

In the following sections, we present how the considered scenario is specified and executed by means of TGGs and JTL and discuss the evaluation of the approaches using the features defined in this section.