eclipse-qvtd-bot
commented
17 hours ago By Ed Willink on May 17, 2016 07:28
QVTr2QVTc demonstrates that nested mappings can be avoided by using the invoker's trace class as part of the invoked guard, thereby expressing a strong called-from restriction. I think this can always work.
This does not necessarily mean that QVTi may not benefit from nested mappings. QVTi certainly lacks a good "if" construct for use in the mapping statements. This can be worked around by looping over an empty collection selection. This latter arises while attempting to define the missing Collection support for QVTr2QVTc with member and rest variables.
... A revisit of the QVTi 'imperative' control language is appropriate ...
However I cannot follow your bug description since I cannot tell what the "final version of CStateToState". I would expect it to be the qvtu that you claim cannot be translated to qvtm, but it has bidirectional behaviour so it is qvtc.
You need to attach a complete machine readable example or GIT branch.
| --- | --- | | Bugzilla Link | 493791 | | Status | RESOLVED WORKSFORME | | Importance | P3 normal | | Reported | May 17, 2016 06:50 EDT | | Modified | May 29, 2016 05:43 EDT | | Reporter | Horacio Hoyos |
Description
In the MTC from QVTc to QVTi the normalization step (u to m) flattens the mappings eliminating nested (local) mappings and hence in QVTi they where removed from the CS and AS. I have found a case for which flatenning can not be performed and hence QVTi requires nested mappings.
After debugging Modelmorf's HstmToStm I realized my translation to QVTc was flawed. After going over it, this is the final version of CStateToState:
map CStateToState in HstmToStm {\ hstm (fs1:State, ts1:State) {\ t1:Trans,\ ms1:State,\ ms2:State |\ t1.fromState = fs1;\ t1.toState = ts1;\ }\ enforce stm (ts2:State) {\ realize fs2:State,\ realize t2 : Trans |\ t2.fromState := fs2;\ t2.toState := ts2;\ }\ where (s2s1:HstateToState, s2s2:HstateToState |) {\ realize s2s : HstateToState,\ realize t2t : HtransToTrans |\ ms1 := s2s1.hstate;\ ms2 := s2s2.hstate;\ s2s.hstate := fs1;\ s2s.state := fs2;\ t2t.htrans := t1;\ t2t.trans := t2;\ }\ map {\ hstm(\ ms1 = fs1 or StateContainsState(fs1, ms1);\ ms2 = ts1 or StateContainsState(ts1, ms2);) {}\ where ( )\ {\ s2s.name := fs1.name;\ fs1.name := s2s.name;\ s2s.name := fs2.name;\ fs2.name := s2s.name;\ t2t.name := t1.name;\ t1.name := t2t.name;\ t2t.name := t2.name;\ t2.name := t2t.name;
}
Notice that ms1 and ms2 are actually local variables that we assign to the trace values of s2s1 and s2s2, hence they must be kept in the bottom pattern of the hstm domain. Since these variables are assigned values from the middle model, their assignments can not be changed to initializers. For these two reason, the predicates in the guard patttern of hstm domain in the nested mapping can not be moved to the guard of the parent hstm domain and the nested mappig must be kept on QVTi.
This would also affect evaluation, as nested mappings predicates should be tested in the check phase (befor the commit phase).