qvt/docs/ICMT2013/abstract.tex - www.eclipse.org/mmt - Git at Google

 %=======================================================================
 % Copyright (c) 2012 The University of York and Willink Transformations.
 %
 % $Id: abstract.tex 4481 2013-02-12 14:15:46Z hhoyos@CS.YORK.AC.UK $
 %=======================================================================
 \begin{abstract}
 %using at least 70 and at most 150 words.
 %The early enthusiasm that led to the definition of the QVT specification for the standardization of model transformation languages subdued due to the lack of an industrial quality implementation.
 % 1)The early enthusiasm (2002) for model to model transformation languages led to eight submissions (2003) for an OMG standard (2007) comprising three languages; no commercial products have appeared (2013).


 % The problem is not the lack of an industrial quality.  The problem is that the lack of an industrtail quality implementation of the QVT languages has stopped QVT
 %The problem is that
 %Initial enthusiasm around the QVT specification has subdued and a hybrid declarative/imperative a commercial product is still missing and available implementations do not provide the complete set of QVT languages.

 The early enthusiasm, in 2002, for model to model transformation languages led to eight submissions for an OMG standard comprising three languages, yet no commercial products have appeared. The QVT Core language was intended as the foundation for QVT Relations but the available implementations have ignored the core language. Rather than ignoring the core language, we take the opposite approach and introduce three more core languages. Progressive program-to-program transformation through these core languages terminates in an easily implemented imperative language that supports declarative transformations.

 % Optionally add a fifth sentence being positive about progressing from ATL, sharing knowledge, tooling etc.

 %Initial enthusiasm around the QVT specification has subdued evidenced by the lack of a commercial product implementation; further, available implementations only provide support to QVTr (Relations) or QVTo (Operational Mappings). In fact, there are no QVTc (Core) implementations although the QVTc language was intended as the common foundation for QVTr and QVTo. To provide a complete QVT implementation that delivers the hybrid declarative/imperative facilities required by model transformations we expand the QVT alphabet to six languages. The additional languages are a semantic subset of QVTc; they bridge the semantic gap between highly declarative QVTr relations and a low level imperative operations. Additionally, they provide interchange points at different levels of abstraction that serve as interface points for other transformation languages, with the intention to promote knowledge sharing and collaboration.

 %Our additional core languages are semantic subsets of QVTc; they define important interchange points during the progressive program-to-program transformation from a highly declarative QVTr program via QVTc to a low level imperative program.


 % QVTc (Core) was intended as the common foundation for QVTr (Relational) and QVTo (Operational Mappings) and due to its simpler semantics
  %have not implemented the QVTc (Core) language. The lack of a QVTc implementation that can be used as an engine for QVTr (Relations) transformations
   %simpler semantics of QVTc, its implementation should be simpler and it can then be used semantics of the QVTr (Relations)
 %The simpler semantics of QVTc suggest that its implementation should be simpler In the QVT specification the QVTc language s  and QVTo (Operational Mappings) implementation

 %As Eclipse QVTo and Medini QVTr projects stall a set of QVT parallel initiatives emerge, such as ATL, Kermeta and ETL, that due to their lack of standardization fail to create and reuse common knowledge, increasing the engineering and development cost.
 %"As Eclipse QVTo and Medini QVTr projects stall a set of QVT parallel initiatives emerged, such as ATL, Kermeta and ETL, leading to fragmentation and duplication of effort in the Model Transformation community."
 % 2) The QVTc (Core) language was intended as the common foundation for QVTr (Relational) and QVTo (Operational Mappings); the available implementations ignore the core language.
 % This is aproblem becuase QVTc was inteded as the common fundation for QVTr and QVTo.


 % The simplest way to implement QVT, addressing the semantic complexity of bidirectional model transformations, is to augment the QVT alphabet so that a particular language provides suitability for a certain part of the complexity.
  %3) It is clear that the three language compromise between declarative and imperative approaches was insufficient and so we expand the QVT alphabet to six languages.


 % The implementation of the proposed subset of QVTc languages will allow QVTr transformations to be executed by providing the required semantics and offer standard interchange points for current and future model transformation language initiatives.
 %4) Our additional core languages are semantic subsets of QVTc; they define important interchange points during the progressive program-to-program transformation from a highly declarative QVTr program via QVTc to a low level imperative program.


 %Optionally add a fifth sentence being positive about progressing from ATL, sharing knowledge, tooling etc.


 \keywords{QVT, OCL, virtual machine, program transformation, declarative transformation, progressive transformation, transformation chain}
 \end{abstract}
	%=======================================================================
	% Copyright (c) 2012 The University of York and Willink Transformations.
	%
	% $Id: abstract.tex 4481 2013-02-12 14:15:46Z hhoyos@CS.YORK.AC.UK $
	%=======================================================================
	\begin{abstract}
	%using at least 70 and at most 150 words.
	%The early enthusiasm that led to the definition of the QVT specification for the standardization of model transformation languages subdued due to the lack of an industrial quality implementation.
	% 1)The early enthusiasm (2002) for model to model transformation languages led to eight submissions (2003) for an OMG standard (2007) comprising three languages; no commercial products have appeared (2013).


	% The problem is not the lack of an industrial quality. The problem is that the lack of an industrtail quality implementation of the QVT languages has stopped QVT
	%The problem is that
	%Initial enthusiasm around the QVT specification has subdued and a hybrid declarative/imperative a commercial product is still missing and available implementations do not provide the complete set of QVT languages.

	The early enthusiasm, in 2002, for model to model transformation languages led to eight submissions for an OMG standard comprising three languages, yet no commercial products have appeared. The QVT Core language was intended as the foundation for QVT Relations but the available implementations have ignored the core language. Rather than ignoring the core language, we take the opposite approach and introduce three more core languages. Progressive program-to-program transformation through these core languages terminates in an easily implemented imperative language that supports declarative transformations.

	% Optionally add a fifth sentence being positive about progressing from ATL, sharing knowledge, tooling etc.

	%Initial enthusiasm around the QVT specification has subdued evidenced by the lack of a commercial product implementation; further, available implementations only provide support to QVTr (Relations) or QVTo (Operational Mappings). In fact, there are no QVTc (Core) implementations although the QVTc language was intended as the common foundation for QVTr and QVTo. To provide a complete QVT implementation that delivers the hybrid declarative/imperative facilities required by model transformations we expand the QVT alphabet to six languages. The additional languages are a semantic subset of QVTc; they bridge the semantic gap between highly declarative QVTr relations and a low level imperative operations. Additionally, they provide interchange points at different levels of abstraction that serve as interface points for other transformation languages, with the intention to promote knowledge sharing and collaboration.

	%Our additional core languages are semantic subsets of QVTc; they define important interchange points during the progressive program-to-program transformation from a highly declarative QVTr program via QVTc to a low level imperative program.



	% QVTc (Core) was intended as the common foundation for QVTr (Relational) and QVTo (Operational Mappings) and due to its simpler semantics
	%have not implemented the QVTc (Core) language. The lack of a QVTc implementation that can be used as an engine for QVTr (Relations) transformations
	%simpler semantics of QVTc, its implementation should be simpler and it can then be used semantics of the QVTr (Relations)
	%The simpler semantics of QVTc suggest that its implementation should be simpler In the QVT specification the QVTc language s and QVTo (Operational Mappings) implementation

	%As Eclipse QVTo and Medini QVTr projects stall a set of QVT parallel initiatives emerge, such as ATL, Kermeta and ETL, that due to their lack of standardization fail to create and reuse common knowledge, increasing the engineering and development cost.
	%"As Eclipse QVTo and Medini QVTr projects stall a set of QVT parallel initiatives emerged, such as ATL, Kermeta and ETL, leading to fragmentation and duplication of effort in the Model Transformation community."
	% 2) The QVTc (Core) language was intended as the common foundation for QVTr (Relational) and QVTo (Operational Mappings); the available implementations ignore the core language.
	% This is aproblem becuase QVTc was inteded as the common fundation for QVTr and QVTo.


	% The simplest way to implement QVT, addressing the semantic complexity of bidirectional model transformations, is to augment the QVT alphabet so that a particular language provides suitability for a certain part of the complexity.
	%3) It is clear that the three language compromise between declarative and imperative approaches was insufficient and so we expand the QVT alphabet to six languages.


	% The implementation of the proposed subset of QVTc languages will allow QVTr transformations to be executed by providing the required semantics and offer standard interchange points for current and future model transformation language initiatives.
	%4) Our additional core languages are semantic subsets of QVTc; they define important interchange points during the progressive program-to-program transformation from a highly declarative QVTr program via QVTc to a low level imperative program.







	%Optionally add a fifth sentence being positive about progressing from ATL, sharing knowledge, tooling etc.


	\keywords{QVT, OCL, virtual machine, program transformation, declarative transformation, progressive transformation, transformation chain}
	\end{abstract}