eclipse-qvtd-bot
commented
1 week ago By Ed Willink on May 21, 2016 07:03
A similar, but cubic, problem occurs for HierarchicalStateMachine2FlatStateMachine where the primary head is a Transition that navigates to a pair of hierarchical States from which a query (logically a closure) provides the secondary heads. There are two parts, a domain computation that may be too hard to analyze and then an iteration. Currently the iteration can be constrained by an ->includes constraint that the scheduler could recognize.
If the computation were embedded in the metamodel as a derived leafStates property we could write
hierarchicalTransition : Transition {\ fromState = : State {\ leafStates = : Set(State) { fromLeafState ++ }\ },\ toState = : State {\ leafStates = : Set(State) { toLeafState ++ }\ },
If the external derived property can be used, why not support contextual properties similar to QVTo so that the derived property can be added by the transformation?
If a PropertyTemplateItem can be a derived property, why not also a zero argument operation, or even a multi-argument operation?
| --- | --- | | Bugzilla Link | 492255 | | Status | NEW | | Importance | P3 normal | | Reported | Apr 22, 2016 10:34 EDT | | Modified | Aug 17, 2019 02:54 EDT | | See also | 510032, 506817 | | Reporter | Ed Willink |
Description
Currently multi-input mappings produce a multi-dimensional search and polynomial execution time.
The three 2-input mappings in UML2RDBMS are not arbitrary inputs. Instead one input is related by a 1:N relationship to the other so that the secondary input could be realized efficiently by a local loop with respect to the first.
Outline:
there is the root sub-region that is reachable from all inputs.
there are further sub-regions that are progressively reachable from fewer inputs.
ultimately there are sub-regions reachable only from a single input.
The sub-regions form a tree.
Between each parent and child sub-region there is often a unidirectional to-one navigation.
[The pathological case of the Cartesian product of two inputs has no such navigation.]
The inverse is presumably a 1:N navigation, so it should be possible to schedule the N-side sub-region as an N-fold loop with respect to the 1-side sub-region eliminating the secondary input for the N-side sub-region.
If some N-side iterations may fail through not-ready inputs, we must use an outer loop over per iteration instances so that no shared computations are lost unless cached in the shared instance.
If all iterations are safe, we may loop directly in a single function/instance.
Saety is only determinable after scheduling so this should be a late optimisation perhaps accompanying late-merging/