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
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
