Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » M2M (model-to-model transformation) » Bidirectional transformation
Bidirectional transformation [message #794703] Thu, 09 February 2012 15:49 Go to next message
Michael Bob is currently offline Michael BobFriend
Messages: 29
Registered: February 2012
Junior Member
Hello,

I have the requirement to transform models in both directions. Or better: Currently, I only need the transformation from A to B. But, maybe in the future I also need B to A. So, my idea was to use a bidirectional transformation.

What is the currently best supported and implemented language for this issue? I have read that ATL is mature, however it is only uni-directional. Is there a good alternative?

Regards,

Michael

Re: Bidirectional transformation [message #794817 is a reply to message #794703] Thu, 09 February 2012 18:27 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

QVTr and QVTc are bidirectional. One day both will be supported by the
Eclipse QVTd project.

Today I know of no QVTc implementations.

For QVTr you can try Medini QVT or ModelMorf.

Regards

Ed Willink

On 09/02/2012 15:49, Michael Gebhart wrote:
> Hello,
>
> I have the requirement to transform models in both directions. Or
> better: Currently, I only need the transformation from A to B. But,
> maybe in the future I also need B to A. So, my idea was to use a
> bidirectional transformation.
>
> What is the currently best supported and implemented language for this
> issue? I have read that ATL is mature, however it is only
> uni-directional. Is there a good alternative?
>
> Regards,
>
> Michael
>
>
Re: Bidirectional transformation [message #794898 is a reply to message #794817] Thu, 09 February 2012 20:57 Go to previous messageGo to next message
Michael Bob is currently offline Michael BobFriend
Messages: 29
Registered: February 2012
Junior Member
Hi Ed,

thanks. Do you know, whether I can use it to transform between models based on XMI/Ecore and XSD?

Regards,

Michael
Re: Bidirectional transformation [message #794913 is a reply to message #794898] Thu, 09 February 2012 21:21 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

What is 'it'?

In Eclipse Modeling, all models are XMI. Almost everything uses Ecore.
Almost nothing uses XSD since XSD is imported as an Ecore source and
Ecore is much simpler, more uniform and generally better.

Regards

Ed Willink


On 09/02/2012 20:57, Michael Gebhart wrote:
> Hi Ed,
>
> thanks. Do you know, whether I can use it to transform between models
> based on XMI/Ecore and XSD?
>
> Regards,
>
> Michael
Re: Bidirectional transformation [message #794980 is a reply to message #794703] Thu, 09 February 2012 23:27 Go to previous messageGo to next message
Alan McMorran is currently offline Alan McMorranFriend
Messages: 55
Registered: July 2009
Member
> I have the requirement to transform models in both directions. Or
> better: Currently, I only need the transformation from A to B. But,
> maybe in the future I also need B to A. So, my idea was to use a
> bidirectional transformation.
>
> What is the currently best supported and implemented language for this
> issue? I have read that ATL is mature, however it is only
> uni-directional. Is there a good alternative?

We use QVTo within our application for bi-directional data
transformation, but in most cases, as it's not 1:1 mapping but usually
fairly complex 1:n or n:n mapping doing a reverse transform requires
manually writing a separate B:A transform.

What we have done though is make each transform run with an input,
output and mapping registry that keeps track of the mappings (which we
could probably do with the mapping trace, but I can't find a way to
access this programatically when the transform is run without the UI.
We also need fine-grained control over the mapping which we can do in
this way). This registry is required as often doing A->B is a lossy
transform and to do B->A we need to keep track of what the original
mapping was to ensure the elements map back correctly.

As an example of how we use this, we have a graphical editor within our
application that has its own, simple schematic model for defining
layout. We have a QVTo that maps elements in our complex application
data structure to this simple schematic model so we can build an
initial schematic. Then, any edits within the editor generate new
schematic elements that are then run back through an inverse QVTo
transform to produce the resulting output application data elements.

This process is highly iterative (as you'd expect when editing a
schematic) and the registry ensures that updates to a schematic element
are mapped correctly to the corresponding application element. (The
reason for doing this is that we support multiple application data
structures but we want the schematic editor to be agnostic to these and
work against its own model that maps well to the graphical elements).

If you're feeling adventurous and your transform is primarily 1:1
simple, lossless transformations, you could write some code to analyse
the QVTo code in its AST form and then derive the B:A transform from
this analysis. We're doing something similar with the AST to try and
auto-generate some documentation from QVTo, but that's primarily
because I'm lazy and I hate writing documentation :-)

Alan
Re: Bidirectional transformation [message #795215 is a reply to message #794980] Fri, 10 February 2012 07:52 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Alan

Might it not be easier to just have the four unidirectional
transformations (where AB is your 'mapping registry')

A+AB -> AB'
B+AB -> AB'
AB -> A
AB -> B

I'm interested that you use QVTo in a highly interactive scenario. Do
you have any speed issues? I avoided using QVTo for some of the
internals of OCL editing because I instinctively felt that speed would
be a problem.

Regards

Ed Willink

On 09/02/2012 23:27, Alan McMorran wrote:
>> I have the requirement to transform models in both directions. Or
>> better: Currently, I only need the transformation from A to B. But,
>> maybe in the future I also need B to A. So, my idea was to use a
>> bidirectional transformation.
>>
>> What is the currently best supported and implemented language for
>> this issue? I have read that ATL is mature, however it is only
>> uni-directional. Is there a good alternative?
>
> We use QVTo within our application for bi-directional data
> transformation, but in most cases, as it's not 1:1 mapping but usually
> fairly complex 1:n or n:n mapping doing a reverse transform requires
> manually writing a separate B:A transform.
>
> What we have done though is make each transform run with an input,
> output and mapping registry that keeps track of the mappings (which we
> could probably do with the mapping trace, but I can't find a way to
> access this programatically when the transform is run without the UI.
> We also need fine-grained control over the mapping which we can do in
> this way). This registry is required as often doing A->B is a lossy
> transform and to do B->A we need to keep track of what the original
> mapping was to ensure the elements map back correctly.
>
> As an example of how we use this, we have a graphical editor within
> our application that has its own, simple schematic model for defining
> layout. We have a QVTo that maps elements in our complex application
> data structure to this simple schematic model so we can build an
> initial schematic. Then, any edits within the editor generate new
> schematic elements that are then run back through an inverse QVTo
> transform to produce the resulting output application data elements.
>
> This process is highly iterative (as you'd expect when editing a
> schematic) and the registry ensures that updates to a schematic
> element are mapped correctly to the corresponding application element.
> (The reason for doing this is that we support multiple application
> data structures but we want the schematic editor to be agnostic to
> these and work against its own model that maps well to the graphical
> elements).
>
> If you're feeling adventurous and your transform is primarily 1:1
> simple, lossless transformations, you could write some code to analyse
> the QVTo code in its AST form and then derive the B:A transform from
> this analysis. We're doing something similar with the AST to try and
> auto-generate some documentation from QVTo, but that's primarily
> because I'm lazy and I hate writing documentation :-)
>
> Alan
>
Re: Bidirectional transformation [message #795783 is a reply to message #795215] Fri, 10 February 2012 23:15 Go to previous messageGo to next message
Alan McMorran is currently offline Alan McMorranFriend
Messages: 55
Registered: July 2009
Member
> Might it not be easier to just have the four unidirectional
> transformations (where AB is your 'mapping registry')
>
> A+AB -> AB'
> B+AB -> AB'
> AB -> A
> AB -> B

Well in reality AB is defined as a model with a Registry class that has
operations for getMapping, addMapping etc. which at the moment is
implemented in the back-end by some hash-maps etc. (primarily because
right now the registry exists only while the application is running but
I could swap it out for a persistent database - or CDO - driven
back-end or something that can be easily serialised). QVTo quite
happily calls these operations so it's not even a black box
implementation!

The registry is an inout parameter for the transform so it's:

A+AB -> AB' + B
B+AB -> AB' + A

So I could probably do it as you describe above, but this way the
transforms are mainly A -> B with the AB interaction nearly always
within the init() section (so it checks the registry, if an object has
already been mapped it grabs it rather than creating a new one).

> I'm interested that you use QVTo in a highly interactive scenario. Do
> you have any speed issues? I avoided using QVTo for some of the
> internals of OCL editing because I instinctively felt that speed would
> be a problem.

Well the initial initialisation can take some time with large data. As
an example (since everyone likes metrics!), I have a file that
represents a large suburban electrical network model (in the order of
about 115,000 objects) and I have to transform that into my
geographical editor model representation which produces about 7,000
sites (substations and customer locations), 3,500 lines and about
40,000 points split between them all (lines have multiple points for
routing for example). There's various other sub-objects underneath
that deal with icons and connectivity points, so in total the output
tree is 60,000 objects produced from the input of 115,000 (which is to
be expected as a lot of the network details don't need to be passed
through).

The source model is already loaded but the time taken from clicking
"Finish" in the wizard to having the browser window load up (it's
embedded within an Eclipse RCP) and show the map is ~30 seconds on my
Macbook Pro (2.5Ghz Core2Duo - getting a bit old these days :-).
That's the time taken to run the QVTo then produce JSON representations
of the data and for the browser to parse the JSON and render the map
view.

When editing with the browser, updates are pushed back and the QVTo is
run against only the objects that have changed, so that 115,000 object
transform is a one off, after that point it's maybe a few tens of
objects at most and the QVTo handles editing (by updating previously
edited object obtained from the mapping registry) and creation (if no
mapping exists the init creates the corresponding source model object
type).

These mappings run in sub-second times so it's not noticeable from a UI
point of view, it's just happily running transforms back and forth in
the background. If I were to transform the whole thing back and forth
every time a chance was made it would be awful, but as we're only
updating incrementally it works very well.

The biggest headache I had was wrapping the changes made by QVTo into
Commands that could then be hooked into the EditingDomain. My solution
is really a total hack as I use notifiers to track all changes to
existing objects and the resource; create commands for the changes
within the notifier and a stack of simple reverse operations; run
through the reverse operations to get the model back to its original
state then execute all the commands so the changes are then "re-done"
but within the Editing Domain. I will not claim this is anything other
than a hack, but I couldn't come up with any other way to alter objects
using QVTo that are open in other workbench editors.

Alan

> On 09/02/2012 23:27, Alan McMorran wrote:
>>> I have the requirement to transform models in both directions. Or
>>> better: Currently, I only need the transformation from A to B. But,
>>> maybe in the future I also need B to A. So, my idea was to use a
>>> bidirectional transformation.
>>>
>>> What is the currently best supported and implemented language for this
>>> issue? I have read that ATL is mature, however it is only
>>> uni-directional. Is there a good alternative?
>>
>> We use QVTo within our application for bi-directional data
>> transformation, but in most cases, as it's not 1:1 mapping but usually
>> fairly complex 1:n or n:n mapping doing a reverse transform requires
>> manually writing a separate B:A transform.
>>
>> What we have done though is make each transform run with an input,
>> output and mapping registry that keeps track of the mappings (which we
>> could probably do with the mapping trace, but I can't find a way to
>> access this programatically when the transform is run without the UI.
>> We also need fine-grained control over the mapping which we can do in
>> this way). This registry is required as often doing A->B is a lossy
>> transform and to do B->A we need to keep track of what the original
>> mapping was to ensure the elements map back correctly.
>>
>> As an example of how we use this, we have a graphical editor within our
>> application that has its own, simple schematic model for defining
>> layout. We have a QVTo that maps elements in our complex application
>> data structure to this simple schematic model so we can build an
>> initial schematic. Then, any edits within the editor generate new
>> schematic elements that are then run back through an inverse QVTo
>> transform to produce the resulting output application data elements.
>>
>> This process is highly iterative (as you'd expect when editing a
>> schematic) and the registry ensures that updates to a schematic element
>> are mapped correctly to the corresponding application element. (The
>> reason for doing this is that we support multiple application data
>> structures but we want the schematic editor to be agnostic to these and
>> work against its own model that maps well to the graphical elements).
>>
>> If you're feeling adventurous and your transform is primarily 1:1
>> simple, lossless transformations, you could write some code to analyse
>> the QVTo code in its AST form and then derive the B:A transform from
>> this analysis. We're doing something similar with the AST to try and
>> auto-generate some documentation from QVTo, but that's primarily
>> because I'm lazy and I hate writing documentation :-)
>>
>> Alan
Re: Bidirectional transformation [message #795983 is a reply to message #795783] Sat, 11 February 2012 07:15 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Alan

On 10/02/2012 23:15, Alan McMorran wrote:
> When editing with the browser, updates are pushed back and the QVTo is
> run against only the objects that have changed, so that 115,000 object
> transform is a one off, after that point it's maybe a few tens of
> objects at most and the QVTo handles editing (by updating previously
> edited object obtained from the mapping registry) and creation (if no
> mapping exists the init creates the corresponding source model object
> type).
>
> These mappings run in sub-second times so it's not noticeable from a
> UI point of view, it's just happily running transforms back and forth
> in the background. If I were to transform the whole thing back and
> forth every time a chance was made it would be awful, but as we're
> only updating incrementally it works very well.
Does that mean you are successfully running QVTo in an update mode? I
know it's in the specification, but not in a form that is intelligible.
QVTo's determination to run in append rather than create mode (on
Helios) discouraged me from even attempting to investigate an update mode.

Regards

Ed Willink
Re: Bidirectional transformation [message #796061 is a reply to message #795983] Sat, 11 February 2012 10:20 Go to previous message
Alan McMorran is currently offline Alan McMorranFriend
Messages: 55
Registered: July 2009
Member
> Does that mean you are successfully running QVTo in an update mode? I
> know it's in the specification, but not in a form that is intelligible.
> QVTo's determination to run in append rather than create mode (on
> Helios) discouraged me from even attempting to investigate an update
> mode.

I have it running in an update mode, but I have no idea (and sincerely
doubt) it is how the QVTo specification would do it. I'm essentially
using my registry to allow the init{} section of a mapping to gain
access to an existing EObject and then running the remainder of the
mapping on that rather than creating a new object.
Previous Topic:[QVTo] when condition in abstract mapping
Next Topic:3rd Biannual Eclipse/OMG Workshop on March 25
Goto Forum:
  


Current Time: Thu Mar 28 16:08:54 GMT 2024

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

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

Back to the top