Home » Archived » M2M (model-to-model transformation) » Bidirectional transformation
| | | |
Re: Bidirectional transformation [message #794980 is a reply to message #794703] |
Thu, 09 February 2012 23:27 |
Alan McMorran 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 |
Ed Willink Messages: 7670 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 |
Alan McMorran 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
|
|
| | |
Goto Forum:
Current Time: Tue Sep 24 14:35:00 GMT 2024
Powered by FUDForum. Page generated in 0.04166 seconds
|