		
%\vspace{-0.4cm}	
\section{Executing transformations in dedicated operational environments}\label{sec:comparison}
%\vspace{-0.1cm}	
%\subsection{Advantages and drawbacks of the considered solutions}\label{}

In this Section we discuss the execution of the \emph{UML2RDBMS} transformation specified by means of TGGs and JTL. To this end, the corresponding execution environments are considered and characterized with respect to highlighted features. In particular, we consider EMorF and eMoflon for TGGs, and the JTL framework for the JTL language. %Concerning eMoflon, even though it is widely considered the reference tool for TGGs, our experience in working with it has encountered some difficulties ascribable to the execution chain of the tool. However, we managed to characterize eMoflon together with EMorF and the JTL framework by exploiting the information available in literature and by establishing a close interaction with the eMoflon developers in order to ask some guidance for using the tool.



%\subsection{Executing the benchmark configurations}\label{sec:impl}




%Hereafter the transformation executions are showed by applying both the benchmarks to every tool.
%
%Considering these issues and the time constrains we could have not implement the transformation on Moflon; nevertheless, since a close collaboration with the Moflon developers and the study of existing literature, in the Section \ref{sec:evaluation} we propose a characterization of the tool with respect the highlighted features.

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

In this Section the UML2RDBMS transformation specified in the previous Section is executed in configuration 1 by means of EMorF, eMoflon and JTL framework.

\subsubsection{Scenario configuration 1: EMorF}

The models involved in the first scenario configuration are those in Figure~\ref{fig:models2}: the source UML model is basically a hierarchy of four classes: {\tt\small employer} and {\tt\small professor} are non-persistent in contrast with \code{person} and \code{worker} that are persistent. The forward execution of the transformation has unexpectedly generated the \emph{$RDBMS_1$} model in Figure~\ref{fig:emorf1} slightly different from the one depicted in Figure~\ref{fig:models2}:  the tables {\tt\small employer} and {\tt\small professor} instead of containing all the attributes inherited from all the parent classes, contain the column representing the owned attributes, and the {\tt\small working\_address} and {\tt\small number\_of\_publications} attributes, derived from the \code{person} and \code{worker} parent classes. From the best of our knowledge, this issue is due to the EMorF implementation, which is not strictly aligned with the TGGs theory and does not support transitive-closures. Theoretically, in TGGs, it could be possible to navigate a model for obtaining all the necessary bindings, by means of OCL constraints. An example of such a constraint might be: $c1 \rightarrow closure(parent) \rightarrow includes(c2)$,where  $c1$ represents  the child class and $c2$ the parent one.
However, the current implementation of EMorF does not support the multiple bindings for the elements marked as $<<$\emph{bind}$>>$ in the rule specification. An improvement of the EMorF engine could overcome this lack of expressiveness. 

\begin{figure}[ht]
  \center
  \includegraphics[width=14.8cm]{figures/ss2/conf1_emorf.png}
   \caption{Scenario configuration 1 - execution within EMorF}
  \label{fig:emorf1}
  %\vspace{-0.2cm}
\end{figure}
%\vspace{-0.2cm}

It is important to note that the \emph{$RDBMS_1$} model in Figure~\ref{fig:emorf1} also differs from the expected one in Figure~\ref{fig:models2}.b for the name of some columns, which end with the {\tt\small “\_own”} suffix; such a naming convention has been needed in order not to loose the inheritance information on the attributes during the execution of the backward transformation. The backward transformation has been launched on the generated \emph{$RDBMS_1$} model, which has been assumed to be correct. Thanks to the adopted naming convention the transformation is able to properly restore the package {\tt\small university}, the classes {\tt\small employer} and {\tt\small professor}, and the  {\tt\small department} and {\tt\small number\_of\_publications} attributes, while it is not able to restore any information about the parent relations. Moreover, the non-persistent classes {\tt\small person} and {\tt\small worker}, since not existing in the RDBMS model, are not considered in the transformation and thus not re-generated in the backward execution (\emph{$UML'_1$} model in Figure \ref{fig:jtl1}). Conceptually, this is caused by the loss of information due to the non-surjectivity of the transformation that, being partial, does not involve all the source/target model concepts in the transformation itself. The naming convention, as other techniques, try to overcome this issue forcing the surjectivity of the transformation. It is important to note that, we presume a correct target UML model could be obtained introducing other naming conventions. Nevertheless such techniques, even if theoretically feasible, can be time consuming and error prone. 
%Others solutions to the non-surjectivity of a transformation – non-injectvity as well – could come from the usage of the tracing information, although, in this case, an improvement to the TGGs theory is required to force the tracing information to record also the non transformed concepts (it will be useless otherwise since the parent relation not being transformed would not be part of the trace information themselves).
Tracing mechanisms~\cite{PDKFPOZ11} might be employed to overcome all those issues due to non-bijectivity of the transformation: in such a case an improvement of the TGGs paradigm is required in order to manage the tracing instances used to record also elements which are discarded during the transformation execution.



%
%\begin{figure}[ht]
%  \centering
%  \sidesubfloat[]{\label{fig:emorfUML1}\includegraphics[width=4.6cm]{figures/ss/conf1_emorf/uml_configuration1_fw_emorf.png}}\quad%
%  \sidesubfloat[]{\label{fig:emorfRDBMS1}\includegraphics[width=4.6cm]{figures/ss/conf1_emorf/rdbms_configuration1_fw_emorf.png}}\quad%
%  \sidesubfloat[]{\label{fig:emorfUML11}\includegraphics[width=4.6cm]{figures/ss/conf1_emorf/uml_configuration1_bw_emorf.png}}%
%  \caption{The UML model (a) and the correspondent RDBMS model (b)}
%  \label{fig:emorf1}
%  %\vspace{-1cm}
%\end{figure}



\subsubsection{Scenario configuration 1: eMoflon}


The considered scenario configuration has been realized as a batch transformation and its result is depicted in Figure \ref{fig:emoflon1}. Despite both EMorF and eMoflon rely on the same model transformation approach, thus TGGs, the result of the execution maintain some differences due to the maturity of the tools.
More precisely, the forward transformation within eMoflon has produced the expected RDBMS model, i.e. the model in which the two persistent classes {\tt\small employer}, {\tt\small professor} are correctly transformed along with all the attributes in the hierarchy.
This was possible thanks to the usage of so called auxiliary rules and a runtime configuration mechanism. The former are normal unidirectional graph transformation rules which increase the expressiveness of the transformation (in our example they are used in order to perform the transitive closure). The latter is a mechanism which helps eMoflon to handle the non-determinism of a transformation, detecting any potential rule overlappings and asking to the user, i.e. at run-time, to solve ambiguities.
Considering the backward execution, the generated UML model, i.e. \emph{$UML'_1$} in Figure \ref{fig:emoflon1}, still differs from the expected one depicted in Figure~\ref{fig:models2} since it does not contain the two non-persistent classes \code{person} and \code{worker}. It is important to note that the kind of information loss deriving from the different expressiveness of the two metamodels remain untreated.

\begin{figure}[ht]
  \center
  \includegraphics[width=14.8cm]{figures/ss2/conf1_emoflon.jpg}
   \caption{Scenario configuration 1 - execution within eMoflon}
  \label{fig:emoflon1}
  %\vspace{-0.2cm}
\end{figure}
%\vspace{-0.2cm}


\subsubsection{Scenario configuration 1: JTL} 

%JTL is a bidirectional and change propagation transformation language available as Eclipse plug-in.
 The implementation of the scenario has started from the same pair of models shown in Figure~\ref{fig:models2}. Starting from the \emph{$UML_1$} model in Figure \ref{fig:jtl1}, the forward execution of the JTL transformation given in Listing~\ref{lst:jtl_transf} is able to produce exactly the expected target model (\emph{$RDBMS_1$} model in Figure \ref{fig:jtl1}), thus the tool is able to navigate all the parent hierarchy in the UML source model and to correctly generate all the columns in the RDBMS target model. In fact, JTL, by means of a series of recursive calls (e.g., in Line {\tt\small 18} of Listing \ref{lst:jtl_transf}), is able to perform the transitive closure.

%In contrast to EMorF, and TGGs in general, the JTL syntax is textual and QVT-like ; in Listing~\ref{lst:jtl_transf} a fragment of the transformation is reported. 
%
%Once completed the transformation specification, we can launch it; nevertheless, the source and target metamodels as well as the source and trace instance models have to be given as input parameters for the transformation itself.\davide{Perche si mette qui il ref alla specifica JTL ? Non dovrebbe stare nella sezione precedente ?}
%The execution of the forward transformation as produced exactly the expected target model, thus the tool was able to navigate all the parent hierarchy in the UML source model and to correctly generate all the columns in the RDBMS target model. In fact, JTL, by means of a series of recursive calls \romina{ref listing}, is capable to perform the transitive closure.

Even though the backward transformation is non-injective, the execution of the reverse transformation produces exactly the same \emph{$UML_1$} model from which we started the transformation chain. In this case the correctness of the transformation is ensured by the usage of the JTL trace mechanism, which also keeps track of the non-transformed elements (in the considered example, they are classes the {\tt\small person} and {\tt\small worker} together with the parents relations).

\begin{figure}[ht]
  \center
  \includegraphics[width=10cm]{figures/ss2/conf1_jtl.png}
   \caption{Scenario configuration 1 - execution within JTL framework}
  \label{fig:jtl1}
 %\vspace{-0.3cm}
\end{figure}
 %\vspace{-0.6cm}

%\begin{figure}[ht]
%  \centering
%  \sidesubfloat[]{\label{fig:jtlUML1}\includegraphics[width=4.6cm]{figures/ss/conf1_jtl/uml_conf1_jtl.png}}\quad%
%  \sidesubfloat[]{\label{fig:jtlRDBMS1}\includegraphics[width=4.6cm]{figures/ss/conf1_jtl/rdbms_conf1_jtl.png}}%
%  \caption{The UML model (a) and the correspondent RDBMS model (b)}
%  \label{fig:jtl1}
%  %\vspace{-1cm}
%\end{figure}


\subsection{Scenario configuration 2 } 

In this Section the UML2RDBMS transformation specified in the previous Section is executed in configuration 2 by means of EMorF, eMoflon and JTL framework.

\subsubsection{Scenario configuration 2: EMorF}

%The second scenario depicts what in MDE-lingo is usually called change-propagation scenario \romina{citare un lavoro che parla di change propagation}. %thus a scenario in which some modifications are done on the target model, after it has been generated from a previous forward transformation, and propagated on the source one. 
In this scenario configuration the models in Figure~\ref{fig:models3} are taken into account. Essentially, they represent an evolution of the original models, and they have been defined in order to evaluate the change propagation facilities of the considered transformation tools. The changes operated on the model in Figure~\ref{fig:models2}b give place to additional difficulties related 
to the adopted naming convention. In fact, a modeler might not be aware of all the modeling techniques used in the previous implementations and consequently could not be obvious that a column {\tt\small email} without the suffix {\tt\small "\_own"} should belong to the parent classes. 
%The transformation still suffers of all the issues discussed in the previous benchmark. 
It is interesting to note how the non-determinism introduced by the modifications is solved by considering the fixed solution encoded in the transformation rules. Being more precise, let us suppose that the modeler has introduced the column with the suffix {\tt\small  "\_own"}; according to the transformation, EMorF %- in this sense EMorF exactly behaves as stated in the TGGS theory - 
will generate a source model in which the column is transformed in the attribute of the class {\tt\small employer}. %\davide{Qui l'esempio non si capisce. Leggendo mi aspettavo di trovare un attributo con suffisso own in Fig.3 ma non ci sta !!!} 
Nevertheless there are still situations in which the non-determinism is not solved: let us consider the opposite case in which the column {\tt\small email} is introduced without any suffix (\emph{$RDBMS_2$} model in Figure \ref{fig:emorf2}), meaning that the column comes from a previous transformed hierarchy relation on the classes; in this case,  no attribute will be generated for that class. Unfortunately, this situation will bring to a non-determinism case in which the column could be transformed at least in two different ways, depending on which class will be considered to be the owner. In our implementation,  EMorF would not transform the column {\tt\small email} meaning that it has been considered to belong to one of the two non-persistent classes (\emph{$UML_2$} model in Figure \ref{fig:emorf2}). But again, which one of the two? The naming convention, as well as any forcing mechanism, practically introduces further and not obvious issues, generally increasing the complexity of the transformation itself. 

\begin{figure}[ht]
  \center
  \includegraphics[width=10cm]{figures/ss2/conf2_emorf.png}
   \caption{Scenario configuration 2 - execution within EMorF}
  \label{fig:emorf2}
  %\vspace{-0.3cm}
\end{figure}
%\vspace{-1cm}



%\begin{figure}[ht]
%  \centering
%  \sidesubfloat[]{\label{fig:emorfRDBMS2}\includegraphics[width=4.6cm]{figures/ss/conf2_emorf/rdbms_configuration2_emorf.png}}\quad%
%  \sidesubfloat[]{\label{fig:emorfUML2}\includegraphics[width=4.6cm]{figures/ss/conf2_emorf/uml_configuration2_emorf.png}}%
%  \caption{The UML model (a) and the correspondent RDBMS model (b)}
%  \label{fig:emorf2}
%  %\vspace{-1cm}
%\end{figure}

\begin{figure}[ht]
  \center
  \includegraphics[width=10cm]{figures/ss2/conf2_emoflon.jpg}
   \caption{Scenario configuration 2 - execution within eMoflon}
  \label{fig:emoflon2}
  %\vspace{-0.2cm}
\end{figure}
%\vspace{-0.2cm}


\subsubsection{Scenario configuration 2: eMoflon}

As aforesaid eMoflon is able to realize both batch and incremental transformations. The considered scenario configuration has been realized as an incremental transformation and the resulting models are those depicted in Figure \ref{fig:emoflon2}.
Within eMoflon, the changes introduced in this scenario configuration, i.e. the addition of the column {\tt\small email} and the involvement of the property {\tt\small isLocal}, can be overcome by exploiting the incrementality feature of the tool; nevertheless, the incremental algorithm requires the changes to be expressed as a set of  supported deltas. This is not only problematic for the end user, without appropriate tool support to create such deltas, but is also limited as, e.g., some deltas such as attribute changes are not yet directly supported.  Changing the {\tt\small isLocal} property, for instance, must be represented as a node deletion and creation delta.
Although eMoflon was able to correctly propagate back the change regarding the addition of the column {\tt\small email}, it was not able to produce all the three possible models consistent with that modification. Theoretically, it could be possible to exploit the configuration mechanism to handle this non-functional choice with a set of dedicated rules, supporting the possibility to chose at run-time, which model the user wants to be generated. Nevertheless, even with help from the eMoflon developers, it was not possible to model this freedom of choice in the TGG as required for the scenario configuration due to limited expressiveness.


\subsubsection{Scenario configuration 2: JTL} 


As previously mentioned, JTL is able to deal with non-injective situations by exploiting tracing information. However, considering the \emph{$RDBMS_2$} model in Figure \ref{fig:jtl2}, no trace information are available concerning the newly added element {\tt\small email}, thus the non-injectity has to be solved generating all the feasible solutions consistent with the target models and with the changes.
%After complete the metamodel and the RDBMS model update with the already discussed modification, the transformation has been launched again. As said, how JTL is able to cope with the non-injectivity when trace information are available; nevertheless in the change propagation scenario no trace information are available on the newly added changes, thus the non-injectity has to be solved generating all the feasible solutions consistent with the target models and with the changes. 
Being more precise, the transformation execution produces a set of three models: each one represents a different solution where the column {\tt \small email} is thought to come from each of the three different classes of the hierarchy. The ability to generate multiple solutions as result of a transformation come straight from the underlying ASP engine. 
%The involved models, the RDBMS model and the four UML models, are depicted in Figure XXX.
Please note that, even if the property {\tt \small is\_local} (see the \emph{$RDBMS_2$} model in Figure \ref{fig:jtl2}) is not directly involved in the transformation (thus not mapped in the UML metamodel/model), its correctness is ensured by means of tracing mechanism.% - even going form UML to RDBMS - as discussed above and detailed explained in the followings. 

\vspace{-0.3cm}
\begin{figure}[ht]
  \center
  \includegraphics[width=10cm]{figures/ss2/conf2_jtl.png}
   \caption{Scenario configuration 2 - execution within JTL framework}
  \label{fig:jtl2}
 % \vspace{-0.1cm}
\end{figure}
%\vspace{-0.4cm}

%\begin{figure}[ht]
%  \centering
%  \sidesubfloat[]{\label{fig:jtlRDBMS1}\includegraphics[width=4.6cm]{figures/ss/conf2_jtl/rdbms_configuration2_jtl.png}}\quad%
%  \sidesubfloat[]{\label{fig:jtlUML11}\includegraphics[width=4.6cm]{figures/ss/conf2_jtl/uml_all_configuration2_jtl.png}}%
%  \caption{The UML model (a) and the correspondent RDBMS model (b)}
%  \label{fig:emorf1}
%  %\vspace{-1cm}
%\end{figure}
%\vspace{-0.2cm}
\subsection{Summary of the evaluation} 


As shown in Table~\ref{tab:comparison}, all the considered implementations (EMorF, Moflon, and JTL framework) do not require the explicit definition of the backward transformation. In fact,  the reverse function is automatically computed by the tools themselves. 


%Although both EMorF and JTL framework are able to deal with transformations defined by non-injective relations, they differ in how they overcome the problem of the non-determinism.
EMorF and eMoflon are able to consider one solution at a time. In particular, in case of non-injective transformations,  the corresponding TGGs rules define an injective relation, by selecting and explicitly considering one solution among all the possible ones. Within EMorf, the transformation writer is forced to solve the non-determinism at design time, e.g., by exploiting naming conventions as done in the TGGs specification given in Figure \ref{fig:TGGsrule}. Whereas, eMoflon allows non-functional transformations and resolves multiple choices at runtime, perhaps demanding an human interaction. 
Contrariwise, in these cases the JTL framework, by relying on the ASP theory, is able to generate all the possible models. In this way developers can focus on the implementation of the transformation behaviour and can neglect the explicit management of non-injective cases (e.g., as done in the transformation given in Listing \ref{lst:jtl_transf}). 


The JTL framework offers a dedicated support, implemented by means of tracing mechanism, which permits to record all the information required to ensure the correctness of the transformation when an information loss occurs. This is shown, in the backward transformation implementation of (i) the first scenario configuration in Figure \ref{fig:jtl1}, when the JTL framework is able to re-generate the class hierarchy, including the two non-persistent classes {\tt\small person} and {\tt\small worker}, and (ii) the second scenario configuration in Figure \ref{fig:jtl2}, when the new property {\tt\small isLocal} is re-generated.
EMorF constrains the transformation with forced mappings which can be further added within the rule set: in such way the transformation is made total on the elements considered in the transformation. This aspect emerges, for example, in the first scenario within EMorF, when we had to develop further rules for the missing elements. As aforesaid, eMoflon can be used for batch transformations, typically with information loss, or for incremental transformations, where the old triple of models is incrementally modified to avoid information loss.




\begin{table}[ht]
 \footnotesize
  \begin{tabular}{|p{2.1cm}|p{1.3cm}|p{2.3cm}|p{2.3cm}|p{2.3cm}|p{2cm}|}
  \hline 
  & {\bf Reverse} & {\bf Source-target relationship} & {\bf Domain coverage} & {\bf Tracing} & {\bf Incrementality} \\
  \hline \hline 
  EMorF	 & Computed	& Non-injective relationships with programmatic solution at design time & Partial domain coverage with forced mapping	& Explicit trace links considering mapped source/target elements  & Batch transformations\\
  \hline 
  eMoflon & Computed & Non-injective relationships with programmatic solution at runtime& Partial domain coverage with dedicated support & Explicit trace links considering mapped source/target elements & Batch and incremental transformations\\
  \hline 
  JTL framework  & Computed	& Non-injective relationships with multiple solutions	& Partial domain coverage with dedicated support	& Explicit trace links considering mapped and discarded elements & Batch transformations\\
  \hline 
  \end{tabular}
  \caption{Summary of the evaluation}
  \label{tab:comparison}
  
\end{table}
%\vspace{-0.45cm}

EMorF, as eMoflon as well, creates trace links between the transformed elements. In particular, they only keep track of the elements involved in the transformation rules, but unfortunately this information is not used in further executions to solve ambiguities. EMorF is simply not incremental and only supports batch transformations. In this case one has to somehow resort to encoding the information (e.g., naming convention). Within eMoflon, incremental transformations are used to avoid information loss.

JTL framework records trace links between source and target elements and trace elements which are not transformed or directly invoked by the rules. In particular, it is used when restoring back the attributes in the original parent classes and the added property {\tt\small isLocal}. Actually, the JTL framework does not support incremental transformations.


%Caratteristiche come reverse o l'abilità di specificare non-bijective transformations sono caratteristiche che dipendono dai linguaggi di trasformazione e in particolare, sono fornite dagli approcci considerati. D'altro canto, i problemi nella gestione di determnati aspetti critici (perdita di infomazione, partiality, gestione della non-iniettività) non dipendono da limitazioni dei linguaggi (per esempio, non si tratta di limitazioni della teoria TGG o del linguaggio JTL), ma dipendendono dalle implementazioni esistenti e dal loro supporto fornito. 
This study reveals that the characteristics an approach is able to provide do not only depend on the transformation language, but some aspects are related on the operational environments and their implementations. In fact, characteristics as reversibility or the ability to specify non-bijective transformations strictly depend on the transformation languages (in particular, we showed that both the theory of TGGs and the JTL languages provide them). On the other hand, the highlighted issues in dealing with critical aspects (i.e., loss of information, partiality, non-injectivity) are not limitations of the languages, but often depend from some precise implementation choices as well as the maturity of the tools.


% % % % % %
%I disagree - as I tried to explain during our online meeting, TGGs can be used for batch transformations, typically with information loss, or for incremental transformations where the old triple of models is incrementally modified to avoid information loss.

%I guess EMorph is simply not (yet) incremental and only supports batch transformations. In this case one has to resort to encoding the information somehow (e.g. Naming conventions etc).  In general, however, incremental transformations are necessary to avoid information loss.

%The point here is that this is definitely not a limitation of the TGG theory and there are quite a few TGG tools out there that support incremental transformations.
% % % % % % %










