Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » M2M (model-to-model transformation) » what QVT for Eclipse has done to me (and questions for Quentin Glineur)
what QVT for Eclipse has done to me (and questions for Quentin Glineur) [message #66842] Wed, 28 November 2007 16:13 Go to next message
Miguel Garcia is currently offline Miguel GarciaFriend
Messages: 77
Registered: July 2009
Member
Hi,

I'm trying to get the picture around the state of QVT in Eclipse, so far
I've managed to put the following evidence together:

a) the latest and greatest spec by the OMG on QVT is the one from July 2007,
i.e.
http://www.omg.org/cgi-bin/apps/doc?ptc/07-07-07.pdf
(although most information on the Net still point the previous version,
which dates back to 2005).


b) the spec defines two user-level languages for defining transformations
(QVT-Operational and QVT-Relations), with a third lower-level language
(QVT-Core) also described (as well as the mapping from QVT-Relations to
QVT-Core, a mapping of interest to tool implemenetors as opposed to users)

c) A text editor, parser, and interpreter for QVT-Operational has been
contributed by Borland, and can be found in CVS:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.m2m/org .eclipse.m2m.qvt.oml/?root=Modeling_Project
If one also reads the documentation of a commercial product (Together, which
also supports QVT-Operational),
http://techpubs.borland.com/together/2007/EN/Together.pdf
http://techpubs.borland.com/together/2007/EN/TogetherDSLTool kit.pdf
then one can get started writing .qvto files. So far so good. The text
editor is cool: it supports hyperlinks (from usages to declarations) and
other goodies.

d) About QVT-Relations, there is a long textual example in the spec itself
(to transform an AST from QVT-Relations into QVT-Core, again of interest to
tool implementors but not users). Am I missing some tutorial out there? Wow,
getting users started with that will need a lot of consultants ...

Next, I start searching for an engine and/or editor. Ed Willink mentions on
this list (Oct 18th, 2007) that a text editor for (among others)
QVT-Relations is available as part of UMLX, as well as .ecore models for the
ASTs of QVT-Relations (and other languages, I'm just excerpting here what
touches upon QVT-Relations).

So what's left is the engine. I find in the proposal of M2M (
http://www.eclipse.org/proposals/m2m/ ) the following:

------- start of quote -------
An exemplary implementation will be for the QVT Core language, using EMF as
implementation of Essential MOF and the OCL implementation from the OCL
subproject. The main deliverable for this part of the project will be an
execution engine that supports transformations.

The engine will execute the Core language in either interpreted or compiled
form. Following Core, the M2M project will provide an implementation of the
QVT Relations language, based on the QVT Core execution engine, EMF and OCL.
For both languages full language support will be delivered.
------- end of quote -------

Then I get to know from Quentin's messages dated Oct. 16th and 22nd that a
contribution of a QVT-Relations compiler is planned, targeting not QVT-Core
but the ATL Virtual Machine. Quentin also mentions on Oct. 5th that
bidirectional transformations will be supported, as well as incrementality.

Phew! The above summary may be long but I hope it saves time to others.

And still, after all that information gathering, I have some questions!
Quentin, could you give your thoughts on the following?

a) Are you going to support the syntax of QVT-Relations as of ptc/07-07-07 ?

b) Will the engine translate into QVT-core or into ATL (or into both)? In
broad brushes, what is the architecture of your engine?

c) I run a very informal experiment with two colleagues and found out that
different interpretations on the QVT spec were not uncommon. Will some doc
from your side take stands on your interpretation, or just let us discover
that in the source code?

OK, I admit I'm a bit disillusioned as to how come it takes so much effort
just to decipher QVT (Don't take it personally, I know it's not anyone's
fault in particular)

To me, the greatest roadblock to the widespread use of QVT-Relations is not
so much the lack of a reference implementation as it is the lack of
technical documentation ... the "First Order Logic" scribblings in the spec
just leave me at lost ... I don't know why the FOL syntax there is different
from the one in textbooks ... ;-)


Miguel




--
Miguel Garcia miguel.garcia@tuhh.de
Institute for Software Systems (STS), E-16
Technische Universitaet Hamburg-Harburg
Harburger Schlossstr. 20, 21073 Hamburg Fax: (+49)40-42878-2515
http://www.sts.tu-harburg.de/~mi.garcia
Re: what QVT for Eclipse has done to me (and questions for Quentin Glineur) [message #66846 is a reply to message #66842] Wed, 28 November 2007 18:58 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: quentin.glineur.obeo.fr

This is a multi-part message in MIME format.
--------------090002030907010708020506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

answer follows up

Miguel Garcia a
Re: what QVT for Eclipse has done to me (and questions for Quentin Glineur) [message #68588 is a reply to message #66846] Mon, 10 December 2007 21:23 Go to previous messageGo to next message
Steffen Becker is currently offline Steffen BeckerFriend
Messages: 31
Registered: July 2009
Member
Hi,

> By the way, I hope beeing able to commit the first release of the
> compiler within this week! I will look foward to your feed back!
Any news on the compiler? I also would like to test it and give feedback...


Cheers,
Steffen
Re: what QVT for Eclipse has done to me (and questions for Quentin Glineur) [message #68761 is a reply to message #66846] Tue, 11 December 2007 13:59 Go to previous message
Eclipse UserFriend
Originally posted by: research.opencanarias.com

Hello!

In response to the survey conducted by Miguel Garcia concering the state
of QVT in Eclipse (sorry if I am late), I just write here to
contribute my grain of salt. I am a PhD student who has been developing a
lightweight but comprehensive Low-Level Model Transformation Language and
engine built upon Eclipse and EMF for almost three years. It is already
quite mature, and Open Canarias, the company I work for as a researcher in
this field, plans to publish it under the EPL in the near future. I will
try to press hard so it is not later than February 2008. :D

The original goal was nothing less than to support QVT, but from an
indirect approach, so work did not end up wasted up by potential
drastic changes in the final specification. Hence the low level approach,
which allows us to support other model transformation languages outside
the QVT suite, such as ATL, RubyTL, or presumably any other.

The first QVT language we have tackled has been Operational Mappings (OM).
Adolfo, a colleague of mine has been working on producing an OM editor
based upon the OCL plug-in. As a result of this work many interesting
discussions have taken place in the news between Adolfo and Christian
Damus, who is responsible of the OCL project for Eclipse, and
bugs have been opened. I cannot tell the differences between the already
mentioned QVT Operational Mappings editors (Dr. Ed Willink's and the one
contributed by Borland) with this one. Perhaps Adolfo could shed some
light in this regard.

But to the point: once an Operational Mappings model has been obtained, it
is translated into the low-level language, ATC, which is mentioned in
http://www.eclipse.org/gmt/amw/usecases/softwareproductline/

The transformation OM2ATC is written itself in ATC, and it is quite
advanced at this moment. It supports most of the main features of
Operational Mappings and a great deal of the OCL Standard Library.
The only major thing that I recall that still needs some thought are
intermediate constructs.

From here on, other research resources will be applied to support new
languages. Another QVT-related line of work which we have recently started
is the support of QVT Core with the long-term goal of supporting Relations
as well. In this regard, another Open Canarias fellow, Victor Roldan, is
currently in communications with Ed Willink. One thing is clear at this
time, we won't spend efforts into creating yet another Core editor,
so we will surely reuse his. Again, the resulting models from Core textual
instances are expected to be translated somehow into ATC. It is unclear at
this point which strategies will be followed to map Core into ATC. ATC is
imperative, as ATL-VM is, and it does not have any declarative constructs
in its instruction set.

And here ends everything that has already been done that can be of interest
to Miguel's QVT state in Eclipse. Hope this has not bored you. If you are
interested in trying this technology, my boss says that he has some
non-disclosure agreement documents ready or something like that (just in
order to protect our technology in the meantime), but I'd recommend you
that you wait a little bit until the project is finally released, which
will be announced in the news.

We couldn't agree more about the problems and difficulties that
ambiguities present in the QVT specification cause to our progress. The
last comment of Miguel's about FOL formalisms to describe the Relations
semantics has touched me. I really hope somebody comes up with a
document/tutorial which enlightens us all in a straightforward fashion and
eradicates (most of) all the loose ends that currently have us puzzled.

A lot of discussion and energies have been wasted internally trying to
figure out the true spirit of the standard. And it is impossible to
determine if we've made the right decisions all of the time. In this
sense, we are eager to contribute to discussions and motivate progress
into the deep understanding of the whole QVT specification. Feel free to
contact us!

Cheers!

Victor Sanchez

On Wed, 28 Nov 2007 19:58:16 +0100, Quentin Glineur wrote:

> Hi,
>
> answer follows up
>
> Miguel Garcia a écrit :
>> Hi,
>>
>> I'm trying to get the picture around the state of QVT in Eclipse, so far
>> I've managed to put the following evidence together:
>>
>> a) the latest and greatest spec by the OMG on QVT is the one from July 2007,
>> i.e.
>> http://www.omg.org/cgi-bin/apps/doc?ptc/07-07-07.pdf
>> (although most information on the Net still point the previous version,
>> which dates back to 2005).
>>
>>
>> b) the spec defines two user-level languages for defining transformations
>> (QVT-Operational and QVT-Relations), with a third lower-level language
>> (QVT-Core) also described (as well as the mapping from QVT-Relations to
>> QVT-Core, a mapping of interest to tool implemenetors as opposed to users)
>>
>> c) A text editor, parser, and interpreter for QVT-Operational has been
>> contributed by Borland, and can be found in CVS:
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.m2m/org .eclipse.m2m.qvt.oml/?root=Modeling_Project
>> If one also reads the documentation of a commercial product (Together, which
>> also supports QVT-Operational),
>> http://techpubs.borland.com/together/2007/EN/Together.pdf
>> http://techpubs.borland.com/together/2007/EN/TogetherDSLTool kit.pdf
>> then one can get started writing .qvto files. So far so good. The text
>> editor is cool: it supports hyperlinks (from usages to declarations) and
>> other goodies.
>>
>> d) About QVT-Relations, there is a long textual example in the spec itself
>> (to transform an AST from QVT-Relations into QVT-Core, again of interest to
>> tool implementors but not users). Am I missing some tutorial out there? Wow,
>> getting users started with that will need a lot of consultants ...
>>
>> Next, I start searching for an engine and/or editor. Ed Willink mentions on
>> this list (Oct 18th, 2007) that a text editor for (among others)
>> QVT-Relations is available as part of UMLX, as well as .ecore models for the
>> ASTs of QVT-Relations (and other languages, I'm just excerpting here what
>> touches upon QVT-Relations).
>>
>> So what's left is the engine. I find in the proposal of M2M (
>> http://www.eclipse.org/proposals/m2m/ ) the following:
>>
>> ------- start of quote -------
>> An exemplary implementation will be for the QVT Core language, using EMF as
>> implementation of Essential MOF and the OCL implementation from the OCL
>> subproject. The main deliverable for this part of the project will be an
>> execution engine that supports transformations.
>>
>> The engine will execute the Core language in either interpreted or compiled
>> form. Following Core, the M2M project will provide an implementation of the
>> QVT Relations language, based on the QVT Core execution engine, EMF and OCL.
>> For both languages full language support will be delivered.
>> ------- end of quote -------
>>
>> Then I get to know from Quentin's messages dated Oct. 16th and 22nd that a
>> contribution of a QVT-Relations compiler is planned, targeting not QVT-Core
>> but the ATL Virtual Machine. Quentin also mentions on Oct. 5th that
>> bidirectional transformations will be supported, as well as incrementality.
>>
>> Phew! The above summary may be long but I hope it saves time to others.
>>
>> And still, after all that information gathering, I have some questions!
>> Quentin, could you give your thoughts on the following?
>>
>> a) Are you going to support the syntax of QVT-Relations as of ptc/07-07-07 ?
>
> Yes ! As I started my work with the 05-11-01 version as a base of work,
> I switched to the 07-07-07 version in July to continue the implementation.
>
>
>> b) Will the engine translate into QVT-core or into ATL (or into both)? In
>> broad brushes, what is the architecture of your engine?
>
> In fact, none of those ones ;)
> As it was mentionned in our proposal:
> http://wiki.eclipse.org/images/9/9a/Declarative_QVT_componen t_proposal.pdf
> we are targetting the ATL *Virtual Machine*.
>
> This means that we will provide a compiler that will produce ATL VM byte
> code from a XMI version of the transformation. (Therefore, at first, the
> contribution will only match the XMI executable point of the "Relations"
> row in the figure 2.1 of the spec.)
>
> Then, a transformation will be launchable by providing the ATL VM with a
> compiled version of the transformation, the models on which it must run
> and the metamodels to handle them.
>
> The compiler is written in ACG (http://wiki.eclipse.org/ACG) which means
> that the compilation is also done by the ATL VM. For more informations
> about the architecture, I let you have a look at ATL architecture.
>
>> c) I run a very informal experiment with two colleagues and found out that
>> different interpretations on the QVT spec were not uncommon. Will some doc
>> from your side take stands on your interpretation, or just let us discover
>> that in the source code?
>
> This is a good question! I should maybe start a M2M vote to decide what
> the community prefer ;)
>
> In this situation I could answers several things:
> -I should only provide some compiled code and let you discover this
> black box thanks to reverse engineering means -> I don't think this is a
> solution way within the framework of an Eclipse product
> -I should provide all the documentation you could ever fancy along the
> most astonishing code you will ever see: No questions will remain and I
> we shall fix all the flaws of the spec by ourselves -> I don't think
> this is feasible in a reasonable amount of time...
>
> As a matter a of fact, I foretell the future to be slightly different.
> We shall simply follow the Eclipse Development Process principle:
> http://www.eclipse.org/projects/dev_process/development_proc ess.php
> In consequence, for the quality culture, we shall of course provide some
> good documentation and explanation on our work. And for the openness, we
> shall handle exchanges with the community and maybe with the spec
> mainteners (as please remember that the specification is still in a beta
> version.)
>
>> OK, I admit I'm a bit disillusioned as to how come it takes so much effort
>> just to decipher QVT (Don't take it personally, I know it's not anyone's
>> fault in particular)
>
> That is right, the specification has quite a high price of entrance
> (intellectualy speaking) but I am convinced of its potential. I hope
> this will improve, with our without us!
>
> In any case, let me tell you that I am very interested in an exchanging
> points of view and that I consider that your feed back about the
> specification interpretation could be valuable (So, don't ask what QVTR
> has done for you but what you have done for QVTR ;) )
>
>>
>> To me, the greatest roadblock to the widespread use of QVT-Relations is not
>> so much the lack of a reference implementation as it is the lack of
>> technical documentation ... the "First Order Logic" scribblings in the spec
>> just leave me at lost ... I don't know why the FOL syntax there is different
>> from the one in textbooks ... ;-)
>>
>> Miguel
>>
>>
>
> As we had considered our early work as a proof of concept, we have not
> let this stop us: And we now think to match a good quality for our
> contribution to come.
> I hope you will not get discouraged by the current status: you have got
> our lent hand to go in this direction.
>
> By the way, I hope beeing able to commit the first release of the
> compiler within this week! I will look foward to your feed back!
>
> Regards,
>
> Quentin GLINEUR
> begin:vcard
> fn:Quentin GLINEUR
> n:GLINEUR;Quentin
> org:Obeo - Model Driven Company;Research and Development
> adr;quoted-printable:;;2 rue Robert Schumann;Rez=C3=A9;;44400;France
> email;internet:quentin.glineur@obeo.fr
> title:MDA Consultant
> tel;work:+332 51 13 54 18
> x-mozilla-html:TRUE
> url:http://www.obeo.fr
> version:2.1
> end:vcard
Previous Topic:[ATL] Compatibility
Next Topic:[ATL] Problem occurs when I launch an execution.
Goto Forum:
  


Current Time: Sun Apr 11 02:22:30 GMT 2021

Powered by FUDForum. Page generated in 0.01705 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top