Hi
No, I’m in fact using nested invocations. I have a chain of n refactoring “normalizations” with n-1 intermediate models. The chain should be easily extensible
to an arbitrary n. The single steps share a large amount of common “cloning” behavior, but I fact differ in some places. Below is an example based on ecore with a Main transformation invoking the nested T1,T2, and T3. These will basically clone the given ecore
model, but carry out certain semantics-preserving normalizations.
transformation Main(in
input: ecore,
out
output : ecore)
access T1,T2,T3;
modeltype ecore
uses
'http://www.eclipse.org/emf/2002/Ecore';
main() {
var intermediate1 = ecore.createEmptyModel();
var step1 =
new T1(input,
intermediate1);
step1.transform();
var intermediate2 = ecore.createEmptyModel();
var step2 =
new T2(intermediate1, intermediate2);
step2.transform();
var step3 =
new T3(intermediate2,
output);
step2.transform();
…
}
The reason why I’m using nested Transformation invocations are the intermediate models. They are created on-the-fly, passed on to the Transformation instantiation,
and populated by the transform() calls. Without nested invocations, I see no possibility of populating my intermediate models. QVTo seems to be restricted to fixed model parameters. No population of temporary models, no dynamic interchange of the model to
be populated.
After executing all the steps, I require traceability in order to detect the provenance of a particular output model element. I’m using a combination of OCL’s
closure(…) and QVTo’s invresolveone() for flexibility reasons: closure(invresolveone()) gives me the entire chain of corresponding elements across all the intermediate models. The implementation is independent of the number n of transformation invocations.
This works as long as all nested invocations propagate their trace data back to the accessing Main transformation.
Regards
Christopher
Von: qvto-dev-bounces@xxxxxxxxxxx [mailto:qvto-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Ed Willink
Gesendet: Donnerstag, 22. Oktober 2015 14:33
An: qvto-dev@xxxxxxxxxxx
Betreff: Re: [qvto-dev] Fwd: [omg] [QVT13] Ballot #5 is ready for review until Wed, 28 Oct 2015 04:00 GMT.
Hi
I think there must be a further misunderstnading.
I really cannot believe that you use nested Transformation invocations, surely just modularised mapping invocations?
A transformation invocation is a major activity requiring extent cloning; why would you want to do that unnececsarily?
Please post some representative code.
Regards
Ed
On 22/10/2015 12:59, Christopher Gerking wrote:
Hi
Misunderstanding, I see.
IMHO composition should not affect a transformation’s visible behavior. From the viewpoint of resolve() it shouldn’t make a difference whether a trace link was
recorded at the very same level or on a sublevel. Consequently I also consider transformation composition as some kind of a refactoring capability. I might have a huge transformation which uses resolve/invresolve in certain places. A refactoring could introduce
a nested sub-transformation, but then there must be a way to make the resolve/invresolve still work.
I prototyped something “better” (?) years ago for Eclipse QVTo, which does currently expose the nested trace:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=392153
My approach might be problematic, because it involves passing the trace data of the accessing transformation into the accessed transformation. Thus in fact there
is only one trace. But at least there are large-scale transformations relying on this practice very successfully.
Binding the trace to the transformation status is not really helpful, because in case of 100 chained sub-transformations I don’t want to invoke resolve(…) a hundred
times. Anyway, how to propagate the Status across multiple levels? If A accesses B and B accesses C, is there any possibility for A to resolve what has happened during C?
What’s the real reason against a default back-propagation of the trace data? Confidentiality? That’s usually not an issue when it comes to model transformation.
As long as the interplay between composition and traceability is unclear, any unfounded restrictions are inappropriate. As a QVTo user, I don’t want to decide between composition and traceability.
Regards
Christopher
Hi
I interpreted the trace of an 'accessed' transformation as the trace of mapping in Tx1 that is accessed during the execution of Tx2 as a consequence of Tx2 inheriting/extending Tx1 with access semantics; not as a consequence of Tx2 nesting/executing e.g. Tx1.transform().
The proposed QVT 1.3 resolution clearly includes all trace from 'inherited' mappings and excludes all 'nested' mappings.
I raised http://solitaire.omg.org/browse/QVT13-124 suggesting that the solution to 'nested' traces may be for the trace-data to form part of the Status which could be an optional additional first resolveXXX
argument.
...resolveIn(tx1Status, Tx1:::A::m);
Transformation::transform()/parallelTransform() support a nested invocation but the returned Status content is very limited.
Suggest 1: Reify TraceData/TraceRecord so that arbitrary OCL queries can be executed.
Suggest 2: Add a getTraceData() to Status and 'this'.
Suggest 3: Add an optional Status first argument to all resolve() methods to enable use on an invoked Transformation.
NB. Since a transformation invocation involves cloning, resolve() should hide the clones so that the caller sees only a single object space.
Suggest 4: TraceData/TraceRecord/Status/Transformation/Model should be / share share an abstraction with QVTc/QVTr.
If you care to prototype this suggestion, it can guide a resolution for QVT 1.4. The hidden cloning issue to support distributed parrallelTransform() needs careful attention.
Tracing only Mapping invocation/execution is indeed limiting. Adding a Transformation Invocation trace-record could be useful. Adding an Object construction trace record could also be useful. Perhaps even an Object mutation trace record to make sure your disk
fills up. Once again prototype something better and raise an issue.
Regards
Ed Willink
On 22/10/2015 09:26, Christopher Gerking wrote:
Hi
To be honest, I’m unhappy with the resolution of
QVT13-22.
The
QVT13-23
resolution implies that there is a trace record for every mapping execution, “but not those by transformation invocations”. That’s exactly what this issue is about. If there are no
trace records for mappings executed inside an accessed transformation, the entire trace of the accessed transformation gets lost after its termination. This reduces the possibilities for transformation composition: if I need full traceability, I can’t decompose
my transformation into subparts, and vice versa. However if I have a stepwise transformation with intermediate models, I’m actually dependent on “accessing” sub-transformations (intermediate models won’t work otherwise). I’m actually suffering from exactly
this dilemma with one of my transformations where I need full traceability.
I agree that, due to parallelTransform(), an accessed transformation shouldn’t reuse the trace data of the accessing transformation. But why is there no write-back
after the termination of transform() or parallelTransform() ? Exposing a trace is often useful and never hurts.
In any case, the resolution text is somewhat contradictive: there are trace records for accessed transformations, but not for transformation invocations. That’s
a contradiction, because an accessed transformation must always be invoked explicitly.
Kind regards
Christopher
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6172 / Virus Database: 4450/10869 - Release Date: 10/22/15