%\vspace{-0.4cm}
\section{Specifying the transformation with TGGs and JTL}\label{sec:approaches}
%\vspace{-0.2cm}

This section introduces the TGGs and the JTL approaches and how the \emph{UML2RDBMS} transformation is specified by means of them\footnote{In this paper the details about the whole implementation are not described due to space restrictions. The interested reader can access the full implementation of all the approaches at http://jtl.di.univaq.it/download.php}. The TGGs transformation specification is given with the EMorF notation, which can be considered as a general abstract syntax for the approach. Whereas, the JTL transformation is specified by means of its own textual syntax.

%\vspace{-0.3cm}
\subsection{TGGs}\label{sec:tgg}
%\vspace{-0.1cm}

TGGs as introduced by Sch\"urr \cite{S94,KS06} belong to the class of graph transformations, and it is considered as a natural framework for specifying bidirectional model transformations.

Formally, a \emph{triple graph grammar} $TGG := (TG,R)$ consists of a \emph{type graph triple} $TG$ and a finite set $R$ of rules, where $TG$ is a triple of connected type graphs denoted as $TG = TG_{S}  \leftarrow TG_{C} \rightarrow TG_{T}$, while a rule $r = (LHS , RHS)$ can be considered as a graph rewriting rule composed by a left-hand side $LHS$ and a right-side $RHS$.
Exploiting the similarities between graph schemata and metamodels, graph and models, in TGGs the three graph schemata represent the source and the target metamodels, and the correspondence metamodel, which keeps track of the links between the source and the target elements. TGG specifies consistent mappings between elements of the source and the target metamodels. A TGG rule is applied whenever a match of $LHS$ occurs in a model $m$, yielding to a new model $m'$ where the elements of $m$ bound to $LHS$ are replaced by $RHS$. 

TGG rules are used to generate the related TGG language, thus the class of consistent triple graphs (i.e. source, correspondence and target). Moreover, starting from their specification, \emph{operational forward} and \emph{backward} rules for implementing bidirectional model transformations are automatically derived.  


\begin{figure}[h]
  \center
  \includegraphics[width=14.5cm]{figures/regolaTGGs2.png}
  \caption{TGGs rule in EMorF notation}
  \label{fig:TGGsrule}
 %\vspace{-0.2cm}
\end{figure}
 %\vspace{-0.3cm}
 
 
Within the available tools for TGGs, eMoflon \footnote{www.moflon.org} has been widely considered as the reference one. It is able to deal with both batch and incremental model transformation \cite{LAVS12} and it is realised as a set of two plug-ins: one add-in for the Enterprise Architect (EA) tool  \footnote{www.sparxsystems.com} and one plug-in for EMF. The usage of eMoflon is basically a two-steps-chain: the rule specification inside EA, and the transformation execution inside EMF. 
Another emerging TGGs tool, developed from the FUJABA creators, is EMorF \footnote{www.emorf.org} which is an Eclipse Modelling Framework (EMF) tool and offers, perhaps, an easier way to manage TGGs avoiding tools chains.  
%TGGs rules can also contain constrains and assignments on the elements attributes to help the elements to be matched and to constraint the execution direction, respectively. TGGs rules may also have a top-part which represents the precondition of the rules themselves.
%EMorF is an Eclipse Modelling Framework (EMF) emerging tool for TGGs. 
It allows the modeller to graphically specify a model transformation between a source and target models conforming to some EMF metamodels. The TGG rules within a transformation scenario are specified by a set of \emph{.emorf\_diagram} files and grouped in a single \emph{.emorf} file: this file is actually a metamodel with the \emph{.emorf\_diagram} files as elements. Once the rules are successfully specified, the transformation can be launched in forward, reverse or mapping mode. 

%\subsubsection{EMorF}

\vspace{0.5cm}

Figure \ref{fig:TGGsrule} depicts a TGG rule in EMorF notation; it represents one of the rules specifying the mapping between \emph{Attribute} and \emph{Column} described in Section \ref{sec:bidirectionality}. Intuitively, a TGG rule specifies consistent mapping between elements of the source and target metamodels, e.g. in Figure \ref{fig:TGGsrule} the metaclass {\tt\small Attribute} of the source domain is mapped in the metaclass {\tt\small Column} of the target domain. The separation of the metamodels is given by vertically splitting the rule in three areas. The top-part of the rule represents the pre-condition, whose elements are marked with the modifier \emph{$<<$bind$>>$}; all the other elements marked with the modifier \emph{$<<$create$>>$} compose the body of the rule.
In the bottom part four OCL expressions are visible: they are used to constraint the rule behaviour, i.e. \emph{$<<$constraint$>>$}, or to specify the value of some model element properties, i.e. \emph{$<<$assignment$>>$}.


 
According to the transformation, the rule generates two columns for each primary attribute of a parent persistent class: one in the table generated from the parent class and one in the table generated from the child class. Additionally the columns are marked as primary key of the respective tables. 
Being more precise, the body of the rule is executed whenever the precondition is satisfied, thus each time two classes, {\tt\small c1} and {\tt\small c2}, related by a parent relation {\tt\small parent}, map the corresponding tables, {\tt\small t1} and {\tt\small t2}; consequently, 
each primary attribute {\tt\small a1} of the parent class, is transformed in two columns, {\tt\small c1} and {\tt\small c2}, one for each table considered in the precondition; moreover the name of the columns is specified according to the OCL assignments on the target-domain side of the rule. 
The whole specification of the transformation is a set of nine rules.

%{\bf EMoflon}

%\romina{Inserire descrizione/specifica in emoflon}
%; we specified all the mappings described in Section \ref{sec:bidirectionality} even if some of this required more then just one rule.

%\vspace{-0.3cm}
\subsection{JTL}\label{sec:jtl}
%\vspace{-0.1cm}

JTL is a constraint-based model transformation language specifically tailored to support bidirectionality. The implementation relies on the Answer Set Programming (ASP) \cite{GL88}, which is a form of declarative programming oriented towards difficult (primarily NP-hard) search problems and based on the stable model (answer set) semantics of logic programming.


\begin{lstlisting}[style=ASP,language=ASPencoding,numbers=left,mathescape,caption=Fragment of the UML2RDBMS transformation in JTL, captionpos=b,  label={lst:jtl_transf}]
transformation uml2rdbms(uml:UML, rdbms:RDBMS) {
	...
	relation AttributeToColumn {
		an, at : String;
		enforce domain uml c:Class { 
			attrs = attr: Attribute { name = an, parent = c, is_primary = false }
		};  
		enforce domain rdbms t:Table { 
			cols = col: Column { name = an, parent = t } 
		};
	}					
	top relation SuperAttributeToColumn{
		enforce domain uml c: Class {
			parent = sc: Class { }
		};
		enforce domain rdbms t: Table {
		};
		when {{ ClassToTable(c, t); } or { SuperAttributeToColumn(cc, t); cc = c.parentOf; }}
		where { AttributeToColumn(sc, t); }
	}
}
\end{lstlisting}
%\vspace{-0.1cm}


JTL adopts a QVT-R like syntax and allows a declarative specification of relationships between MOF models. The language supports object pattern matching, and implicitly creates trace instances to record what occurred during a transformation execution. A transformation between candidate models is specified as a set of \emph{relation}s that must hold for the transformation to be successful: in particular, it is defined by two \emph{domain}s and includes a pair of \emph{when} and \emph{where} predicates which specify the pre- and post- conditions that must be satisfied by the elements of the candidate models.
A transformation can be invoked for \emph{enforcement} or as \emph{checkonly}. When invoked for enforcement, it is executed in a particular direction by selecting one of the candidate models as the target. %The execution of the transformation proceeds by first checking whether the relations hold, and for relations for which the check fails, attempting to make the relations hold by creating, deleting, or modifying only the target model, thus enforcing the relationship. 
A transformation can also be invoked in bidirectional mode by marking as enforcement both domain directions.%), unidirectional mode (by marking as checkonly one of the domain directions) or checkonly mode (by marking as checkonly both domain directions). 
%Furthermore, the framework provides support for the trace information mechanisms.



The semantics is given in terms of ASP. The \emph{transformation engine} is written in the ASP language and consisting of bidirectional rules able to interpret the correspondences among elements and execute the transformation. 
Then the ASP solver finds and generates, in a single execution, all the possible models which are consistent with the transformation rules by a deductive process. 
A JTL program (as well as models and metamodels) is automatically translated into an ASP program. In order to understand how a model transformation is derived in ASP, we define a transformation $T_{ASP} := (\Sigma,R,C)$ which consists of a signature $\Sigma$ specifying the input and output types of the transformation, a set of relations $R$, which describe correspondences among element types of the source and target metamodels, and a set of constraints $C$, which specify restrictions on the given relations. Relations between element types are derived from the relations of the JTL transformation, whereas constraints translate: (i) the model patterns that must be matched by the model elements of the domain and (ii) pre- and post-conditions that must be respected. 



The overall architecture of the JTL framework has been implemented as a set of plug-ins of the Eclipse framework and mainly exploits the Eclipse Modelling Framework (EMF)\footnote{http://www.eclipse.org/modeling/emf/}.%~\cite{EMF}% and the ATLAS Model Management Architecture (AMMA)~\cite{AMMA}. 
It makes use of the \emph{DLV solver}~\footnote{http://www.dlvsystem.com/} (which has been wrapped and integrated in the overall environment) to execute transformations in both forward and backward directions.
%execution engine consisting of bidirectional rules able to interpret the correspondences among elements and execute the transformation. Relations and constraints are obtained from the given JTL specification, whereas the execution engine is always the same as described in the next section.


%The JTL transformations are automatically transformed into ASP programs. Such a semantic anchoring has been implemented in terms of an ATL~\cite{JK05} transformation defined on the JTL and ASP metamodels. Also the source and target metamodels of the considered transformation are automatically encoded in ASP and managed by the engine during the execution of the considered transformation and to generate the output models. 

%The invertibility of transformations is obtained by means of trace information that connects source and target elements; in this way, during the transformation process, the relationships between models that are created by
%the transformation executions can be stored to preserve mapping information in a permanent way. Furthermore, all the source elements lost during the forward transformation execution (for example, due to the different expressive power of the metamodels) are stored in order to be generated again in the backward transformation execution.





Listing~\ref{lst:jtl_transf} depicts a fragment of the \emph{UML2RDBMS} transformation, which is expressed in the textual concrete syntax of JTL and applied on models given by means of their Ecore representation within the EMF framework.
In particular, the following relations are defined: \emph{a)} %\emph{Class2Table}, which relates classes and tables in the two different metamodels, \emph{b)} 
\emph{Attribute2Column}, which relates attibutes and columns in the two different metamodels and \emph{b)} \emph{SuperAttribute2Column}, which relates attributes of the parent class to columns of the corresponding child table. The \emph{when} and  \emph{where} clause specify conditions on the relation. In particular, the when clause in Line {\tt\small 18} allow to navigate the parent classes of each attribute, then the where clause in Line {\tt\small 19} generates the correspondent columns. 
These relations are bidirectional, in fact both the contained domains are specified with the construct \emph{enforce}. 

According to the proposed approach, the designer task is limited to specifying relational model transformations in JTL syntax and to applying them on models and metamodels defined as EMF entities within the Eclipse framework. 



%top relation ClassToTable {
%		cn, an: String;
%		enforce domain uml c:Class {
%			is_persistent=true, 
%			name=cn, 
%			attrs = attr: Attribute {name=an}
%		};
%		enforce domain rdbms t:Table {
%			name=cn,
%			cols=col: Column {name=an}
%		};
%		where { AttributeToColumn(c, t); }
%		}
		





%In Listing~\ref{lst:jtl_transf} we report a fragment of the \emph{UML2RDBMS} transformation specified in JTL. In particular, the following relations are defined: \emph{a)} %\emph{Class2Table}, which relates classes and tables in the two different metamodels, \emph{b)} 
%\emph{Attribute2Column}, which relates attibutes and columns in the two different metamodels and \emph{b)} \emph{SuperAttribute2Column}, which relates attributes of the parent class to columns of the corresponding child table. The \emph{when} and  \emph{where} clauses specify conditions on the relation. In particular, the when clause in Line 18-21 allows to navigate the parent classes of each attribute and then the where clause in Line 22-24 generates the correspondent columns. These relations are bidirectional, in fact both the contained domains are specified with the construct \emph{enforce}. 
%%Furthermore, the \emph{checkonly} and \emph{enforce} constructs are also provided. A JTL relation is considered bidirectional when both the contained domains are specified with the construct \emph{enforce}. 

%\begin{figure}[t]
%\begin{lstlisting}[style=ASP,language=ASPencoding,numbers=left,mathescape,caption=Fragment of the \emph{UML2RDBMS} transformation in JTL, captionpos=b,  label={lst:jtl_transf}]
%transformation uml2rdbms(uml:UML, rdbms:RDBMS) {
	%...
	%relation AttributeToColumn {
		%an, at : String;
		%enforce domain uml c:Class { 
			%attrs = attr: Attribute { name = an, parent = c, is_primary = false }
		%};  
		%enforce domain rdbms t:Table { 
			%cols = col: Column { name = an, parent = t } 
		%};
	%}					
	%top relation SuperAttributeToColumn{
		%enforce domain uml c: Class {
			%parent = sc: Class { }
		%};
		%enforce domain rdbms t: Table {
		%};
		%when {
			%{ ClassToTable(c, t); } or    
			%{ SuperAttributeToColumn(cc, t); cc = c.parentOf; }
		%}
		%where {
			%AttributeToColumn(sc, t);
		%}
	%}
%}
%\end{lstlisting}
%\vspace{-.1cm}
%\end{figure}
%


%The JTL transformations are automatically transformed into ASP programs. Such a semantic anchoring has been implemented in terms of an ATL~\cite{JK05} transformation defined on the JTL and ASP metamodels. Also the source and target metamodels of the considered transformation are automatically encoded in ASP and managed by the engine during the execution of the considered transformation and to generate the output models. 

%The invertibility of transformations is obtained by means of trace information that connects source and target elements; in this way, during the transformation process, the relationships between models that are created by
%the transformation executions can be stored to preserve mapping information in a permanent way. Furthermore, all the source elements lost during the forward transformation execution (for example, due to the different expressive power of the metamodels) are stored in order to be generated again in the backward transformation execution.



%In Listing~\ref{lst:jtl_transf} we report a fragment of the \emph{UML2RDBMS} transformation, which is expressed in the textual concrete syntax of JTL and applyed on models given by means of their Ecore representation within the EMF framework.
%In particular, the following relations are defined: \emph{a)} %\emph{Class2Table}, which relates classes and tables in the two different metamodels, \emph{b)} 
%\emph{Attribute2Column}, which relates attibutes and columns in the two different metamodels and \emph{b)} \emph{SuperAttribute2Column}, which relates attributes of the parent class to columns of the corresponding child table. The \emph{when} and  \emph{where} clauses specify conditions on the relation. In particular, the when clause in Line 18-21 allows to navigate the parent classes of each attribute and then the where clause in Line 22-24 generates the correspondent columns. These relations are bidirectional, in fact both the contained domains are specified with the construct \emph{enforce}. 
%%Furthermore, the \emph{checkonly} and \emph{enforce} constructs are also provided. A JTL relation is considered bidirectional when both the contained domains are specified with the construct \emph{enforce}. 


%top relation ClassToTable {
%		cn, an: String;
%		enforce domain uml c:Class {
%			is_persistent=true, 
%			name=cn, 
%			attrs = attr: Attribute {name=an}
%		};
%		enforce domain rdbms t:Table {
%			name=cn,
%			cols=col: Column {name=an}
%		};
%		where { AttributeToColumn(c, t); }
%		}
		
% the designer task is limited to specifying relational model transformations in JTL syntax and to applying them on models and metamodels defined as EMF entities within the Eclipse framework. 

 
%According to the proposed approaches, the above described model transformations not allow to give a specific characterization. To this end, in the next section the specified model transformation are applied on models and metamodels within the considered frameworks.




%MOFLON \footnote{www.moflon.org}, which has been developed on the foundations of FUJABA \footnote{www.fujaba.de} , has been widely considered as the reference tool for the TGGs. Another emerging TGGs tool, developed from the FUJABA creators, is EMorF \footnote{www.emorf.org} which is realised as an Eclispe plug-in and offers, perhaps, an easier way to manage TGGs.  
%%Being spread between two tools, the effective usage of MOFLON has often affected by compatibility and versioning issues that make the chain time-consuming and hard to accomplish without a dedicated bug-support. 
%For our comparison we have decided to take in account EMorf for several reasons mainly addressable to a better reliability of the tool and the same computational power; nevertheless MOFLON, being previous realised, has been widely studied and discussed in literature \cite{MOFLON}.
%
%\vspace{0.2cm}
%\textbf{EMorF} - EMorF is an Eclipse Modelling Framework (EMF) emerging tool for TGGs. It allows the modeller to graphically specify a model transformation between a source and target models conforming to some EMF metamodels. The TGGs rules within a transformation scenario are specified by a set of \emph{.emorf\_diagram} files and grouped in a single \emph{.emorf} file: this file is actually a metamodel with the \emph{.emorf\_diagram} files as elements. Once the rules are successfully specified, the transformation can be launched: according to the TGGs theory we have three possible execution modes, which are the forward mode, the reverse mode and the mapping mode. 
%
%In  FigureXXX is depicted a TGGs rule which maps a persistent class to a table. The  EMorF editor is splitted in three parts to clearly separates the different metamodels of the rule, thus the source, the target and the correspondence.  An element of the rule can be marked as $<<create>>$ or $<<bind>>$ depending if it is involved in the transformation or if it belongs to the pre-condition of the rule, respectively. All the elements marked as $<<bind>>$ will be bind to bound elements in the models, instead the elements marked as $<<create>>$ will be, depending on the execution mode, created or bounded to unbound elements.  If the precondition is satisfied, the elements which belong to the LHS of the rule will be possibly matched to element in the source model and eventually replaced by the elements in the RHS; additionaly, OCL constrains can be added to express narrowing conditions. OCL can also be used to express assignments which complete the transformation: in FigureXXX we see an OCL assignment for the specification of the names.

%\subsubsection{MOFLON}\label{sec:moflon}
%
%Moflon has been considered for a long time the reference tool for dealing with TGGs in MDE. It is realised as a set of two plug-ins: one add-in for the Enterprise Architecture (EA) tool [6] and one plug-in for EMF. The usage of MOFLON is basically a two-steps-chain; a user who wants to define a bidirectional transformation scenario, has to specify the metamodels involved in the transformations and the transformations rules in EA, export the projects in EMF and there launch the transformation. The export operations from EA to EMF are done via the MOFLON add-in for EA, which basically translates the set of diagrams realised in EA as a set of JAVA customizable files in EMF. 
%Being spread between two tools, the effective usage of MOFLON has often affected by compatibility and versioning issues that make the chain time-consuming and hard to accomplish without a dedicated bug-support. 
%For our comparison we have decided to take in account EMorf for several reasons mainly addressable to a better reliability of the tool and the same computational power; nevertheless MOFLON, as previous realised, has been widely studied and discussed in literature [7].

%\subsection{Introduction to JTL}\label{sec:jtl}
%
%The Janus Transformation Language (JTL) is a constraint-based model transformation language speciﬁcally tailored to support bidirectionality. The implementation relies on the Answer Set Programming (ASP) [34], which is a form of declarative programming oriented towards difﬁcult (primarily NP-hard) search problems and based on the stable model (answer set) semantics of logic programming.
%
%JTL adopts a QVT-R like syntax \cite{QVT-Final}. It allows a declarative speciﬁcation of relationships between MOF models. The language supports object pattern matching, and implicitly creates trace instances to record what occurred during a transformation execution. A transformation between candidate models is speciﬁed as a set of relations that must hold for the transformation to be successful: in particular, it is deﬁned by two or more domains and includes a pair of when and where predicates which specify the conditions that must be satisﬁed by the elements of the candidate models.
%A transformation can be invoked for enforcement or as checkonly. When invoked for enforcement, it is executed in a particular direction by selecting one of the candidate models as the target. The execution of the transformation proceeds by first checking whether the relations hold, and for relations for which the check fails, attempting to make the relations hold by creating, deleting, or modifying only the target model, thus enforcing the relationship. 
%A transformation can also be invoked in bidirectional mode (by marking as enforcement both domain directions), unidirectional mode (by marking as checkonly one of the domain directions) or checkonly mode (by marking as checkonly both domain directions). 
%Furthermore, the framework provides support for the trace information mechanisms.

%JTL is able to deal with non-bijective transformations, i.e. it is capable of mapping a model into a set of models, 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. JTL provides support to non-bijectivity and its semantics assures that all the models are computed at once independently whether they represent the outcome of the backward or forward execution of the bidirectional transformation; 
%Furthermore, since generally transformations are not total, the generated target models can be manually modified in such a way they are not treachable anymore by any forward transformation. In this case, traceability information are employed to back propagate the changes from the modified targets by inferring the 	\emph{closest} model that approximates the ideal source one at best. 

%\vspace{0.2cm}
%\textbf{JF} - The overall architecture of the JTL framework has been implemented as a set of plug-ins of the Eclipse framework and mainly exploits the Eclipse Modelling Framework (EMF)~\cite{EMF} and the ATLAS Model Management Architecture (AMMA)~\cite{AMMA}. 
%
%Transformations are expressed in the textual concrete syntax of JTL and applyed on models given by means of their Ecore representation within the EMF framework. 
%The \emph{transformation engine} is written in the ASP language and makes use of the \emph{DLV solver}~\cite{DLV} (which has been wrapped and integrated in the overall environment) to execute transformations in both forward and backward directions. The JTL transformations are automatically transformed into ASP programs. Such a semantic anchoring has been implemented in terms of an ATL~\cite{JK05} transformation defined on the JTL and ASP metamodels. Also the source and target metamodels of the considered transformation are automatically encoded in ASP and managed by the engine during the execution of the considered transformation and to generate the output models. 

%The invertibility of transformations is obtained by means of trace information that connects source and target elements; in this way, during the transformation process, the relationships between models that are created by
%the transformation executions can be stored to preserve mapping information in a permanent way. Furthermore, all the source elements lost during the forward transformation execution (for example, due to the different expressive power of the metamodels) are stored in order to be generated again in the backward transformation execution.

%\subsection{Specifying the transformation with TGGs and JTL}\label{sec:tgg}
%
%\subsubsection{TGGs}
%\alessio{specifica informale tggs } 
%
%\subsubsection{JTL}
%\alessio{specifica informale tggs } 