Community
Participate
Working Groups
Bug 515327 identifies a need to partition a non-top overriding relation tree to involve: three middle/trace hierarchies -- invocation required -- guard matches -- execution status two relation/mapping hierarchies -- guard/predicate evaluation => match/mis-match -- execution => success/fail This is necessary to use the simple QVTc all mappings are 'top' with adequate guards to enforce sequencing. The basic QVTr2QVTc synthesis is painful. The non-trivial processing to split guard/execution is too painful. ---- In QVTs, the simple pattern a:B{b1=b; b2=b} requires two pattern nodes for "a" and "b", and two navigation edges for "b1" and "b2". In QVTr a PropertyTemplateItem for each "b1" and "b2" is similar to a QVTs edge, but the containments for ObjectTemplateExp+VariableExp+Variable for each node is the source of the pain (and CollectionTemplateExp's have no corresponding 'edges'). In QVTs a shared variable has a node that is shared by its use as the end of many edges. In QVTr a shared variable has a distinct VariableExp and ObjectTemplateExp for each 'edge' end. ---- Choice: - carry on with QVTr2QVTc pain - introduce a graphical QVTrs (or QVTg) so that we do QVTr2QVTg2QVTs2QVTi... Disadvantages - non-trivial work to introduce a new QVTs-based model - impossible to support an OMG QVTr2QVTc formulation Advantages - expression terms are expanded to nodes - representation is normalized - trace can be synthesized later - no spurious guard/bottom intermediate contortions - QVTc's no mapping calls no longer applies ---- If we continue with QVTr2QVTc, the non-top overrides might be the 'last' problem, but more likely the failure to understand the complexities of expressions will bite. Contorting QVTr to QVTc semantics has cost a huge amount of time. It isn't going to get better. Time to change. ---- OMG QVTr2QVTc. A possible solution is to (re)define: - QVTr2QVTg (? bidirectionally) - QVTc2QVTg (bidirectionally) - UMLX2QVTg (bidirectionally) - QVTg2QVTs (? bidirectionally) - QVTg2trace but this requires that QVTg forms part of the QVT specification. The above could be implemented as yet more Java cutting; copying large amounts of similar code. But perhaps the tooling has reached a level where we can attempt QVTr2QVTg and QVTr2trace in QVTr subject to some severe idiomatic constraints: - e.g. overrides must be a family of non-failing leaf overrides of a never-invoked abstract 'interface'. - OCL expressions may exploit a 'blackbox'
(In reply to Ed Willink from comment #0) > - introduce a graphical QVTrs (or QVTg) so that we do QVTr2QVTg2QVTs2QVTi... What does QVTrs/QVTg offer? Surely we can jump revamp QVTm2QVTs as QVTr2QVTs. Once the ensuing QVTs2QVTs2QVTs2QVTs chain clarifies, an early QVTs might be richer than a later QVTs. That might then justify a QVTg.
