\section{Introduction}\label{sec:introduction}
\noindent


  
%\alessio{bidirectionality : the mutual influence of two domains one on another without a predetermined causality or with exchangeable cause and effect.} 
%\alf{The change propagation problem [13] has been defined as follows: given a set of primary changes that have been made to software, what additional, secondary, changes are needed to maintain consistency within the system? Change propagation has been proposed as a mechanism to help manage and automate model evolution.}
In Model-Driven Engineering (MDE)~\cite{MDE} model transformations are considered as the gluing mechanism between the different abstraction layers and viewpoints by which a system is described~\cite{Bezivin05,SK03}. 
%Their employment includes mapping models to other models to focus on particular features of the system, operate some analysis, simulate/validate a given application, not excluding the operation of keeping them synchronized or in a consistent state. 
Given the variety of scenarios in which they can be employed, each transformation problem can demand for different characteristics making the expectation of a single approach suitable for all contexts not realistic.

%%Bidirectionality and change propagation issues come out as soon as modifications to the target model of a transformation are allowed. Tipically, given a set of primary changes that have been made to software, additional, secondary, changes are needed to maintain consistency within the system~\cite{Stevens07}. In this context, change propagation may help manage and automate model evolution~\cite{XSHT09}.
%In fact, in typical scenarios each time the source model is manipulated a complete target re-generation is needed.

Often it is assumed that during development only the source model of a transformation undergoes modifications, however in practice it is necessary for developers to modify both the source and the target models of a transformation. %and propagate changes in both directions~\cite{Stevens07,XSHT09}. 
In this context, bidirectional transformations play a key role in dealing with scenarios such as change propagation, synchronization and consistency management whenever changes occurring on some model have to be propagated over the others.

%in maintaining both the consistency and the synchronization of two (or more) related sources of information \cite{CFHLST09}.
 
 
 %There are two main approaches for realizing bidirectional transformations: by programming forward and backward transformations in any convenient unidirectional language and manually ensuring they are consistent; or by using a bidirectional transformation language where every program describes both a forward and a backward transformation simultaneously. A major advantage of the latter approach is that the consistency of the transformations can be guaranteed by construction.
%%The relevance of bidirectionality in model transformations has been acknowledged already in 2005 by the Object Management Group (OMG) by including a bidirectional language in their Query View Transformation (QVT)\footnote{http://www.omg.org/spec/QVT/1.1}.%~\cite{QVT-Final}. 
%Moreover, 
A number of approaches and languages have been proposed due to the intrinsic complexity of bidirectionality.~Each one of those languages is characterized by a set of specific properties pertaining to a particular applicative domain~\cite{CH06,Stevens07}. %In this respect,~\cite{Stevens07} organizes the existing bidirectional transformation solutions in different categories by distinguishing approaches based on QVT-R, graph transformation techniques, constraint-based languages, and XML-based options, to mention a few.  
Unfortunately, the existing approaches are affected
by the intrinsic characteristics of model transformations, that have been only partially considered by research; in general, transformations are \emph{not injective}~\cite{Witkop05}, in fact, each time a change occurs there is no guarantee to obtain a unique reverse
result.~Furthermore, transformations are \emph{not total}, i.e. only the relevant concepts of the source models are mapped toward the corresponding target elements~\cite{HLR08}. 

%Unfortunately, the existing bidirectional approaches are affected by the intrinsic characteristics of model transformations, which are in general \emph{non  bijective}~\cite{Witkop05}. In fact, each time a change occurs on a  generated model there is no guarantee to obtain a unique reverse result, as for instance when a single change in a target model might semantically correspond to a family of related changes in more than one source model. Furthermore, transformations are \emph{not total}, i.e. only the relevant concepts of the source models are mapped toward the corresponding target elements ~\cite{HLR08}. It means that target models can be manually modified in such a way they are not reachable anymore by any forward transformation.




%\medskip
The contribution of this work is: 
(i) to identify a set of pragmatic features characterizing bidirectional model transformations %by analysing existing work in literature \cite{CH06,HLR08} and the behaviour of existing approaches, 
and (ii) to validate them against two bidirectional approaches, such as
the Triple Graph Grammars (TGGs)~\cite{S94}, a bidirectional approaches based on graph grammars and the Janus Transformation Language (JTL)~\cite{CDEP10}, a constraint-based bidirectional language. 

The UML2RDBMS transformation scenario
%and It has been realized by specifying the \emph{UML2RDBMS} bidirectional transformation by means of the considered approaches. We take into account a different version as the \emph{UML2RDBMS} banchmark is proposed in the literature, i.e., with the non isomorphic source (UML) and target (RDBMS) modeling languages. In order to apply the approaches to specific contexts concerning bidirectionality and change propagation, we implement the transformation by means of selected tools: in particular, we consider the EMorF and (partially) the MOFLON tools (both implementing TGGs) and the JTL framework. 
consisting of two different configurations is implemented by means of the selected approaches for understanding the practicality of bidirectional transformations with respect to the elicited features. At the same time an evaluation of the implementations is provided highlighting differences and similarity between the approaches and giving a cue to identify their possible applications. 
We take into account a different version as the transformation is proposed in the literature, i.e., with the non isomorphic source (UML) and target (RDBMS) modeling languages. In order to apply the approaches to specific contexts concerning bidirectionality and change propagation, we implement the transformation by means of selected tools: in particular, we consider the EMorF and the eMoflon tools (both implementing TGGs) and the JTL framework. On the one hand, TGGs are a formally founded bidirectional language relying on multiple implementations, while JTL is a promising approach actively researched. On the other hand, they both consider intrinsic characteristics affecting bidirectionality. 

%\davide{Perche soli questi due ? Va detto qualcosa sul perche ci focializziamo solo su questi nel paper.}
%The identification of these features has been inspired by existing work in literature \cite{CH06,HLR08} and refined by analyzing how existing approaches deal with bidirectionality, even in case of changes occurring on models. 

%Secondly, the analysis refers to two bidirectional languages: (i) the Triple Graph Grammars (TGGs)~\cite{S94}, a bidirectional approaches based on graph grammars and (ii) the Janus Transformation Language (JTL)~\cite{CDEP10}, a constraint-based bidirectional language. %Analizing two of the existing languages, with respect of the selected features, has as objective to characterize the approaches by understanding differences and similarity between them and, possibly, identify their typical applications.


%As key aspects to these contexts, the selected features are utilized as evaluation framework in the comparison of the analyzed approaches.


The structure of the paper is as follows: Section~\ref{sec:bidirectionality} presents the \emph{UML2RDBMS} scenario, while Section \ref{sec:evaluation} introduces our set of features for bidirectional approaches. Section~\ref{sec:approaches} describes the TGGs and JTL approaches and shows how the transformations are specified, while Section~\ref{sec:comparison} execute them on the considered transformation and discusses the selected features of the considered bidirectional approaches. Furthermore, Section~\ref{sec:related} provides an overview of related works in the area. Finally, Section~\ref{sec:conclusion} draws the conclusions and presents future works.

