Community
Participate
Working Groups
This example involves a hierarchical copy with constraining keys resulting in partial assignments on the RHS. Problem 1: (see Bug 512532) the UMLMM::Type Key is for an abstract class and so cannot apply to the derived UMLMM::Class that are actually copied. If it did, what would happen if there was a conflictingly named DataType. Problem 2: the UMLMM::Class copies do not mention a "name" so why is the name copied? Without a name are the results all null-named? Problem 3: the hierarchical copy creates a trace for each copied Parameter, and so for each Operation and so for each Class. Multiple Operations are avoided by the Operation key. Multiple Classes are not, so a legitimate execution creates a new Class,Operation,Parameter for each original Parameter.
Problem 1: derived keys solved on Bug 512532. The explicit UMLMM::Type{name} key, is also an implicit UMLMM::Class{name} key. Problem 2: The implicit UMLMM::Class{name} key should diagnose the omission of its "name" part in the source. (The omitted key parts could be deduced and so implicitly present, but the subsequent correlation of implicit parts seems incredibly dangerous and confusing. The ModelMorf source must be wrong.) Problem 3: Once we have a fully configured UMLMM::Class key the hierarchical trace should be adequate. --- The multi-level hierarchy of this example is quite compact, but the single trace across the hierarchy is inefficient. The execution loops over all Parameters and builds ancestry with appropriate re-use. Is there an optimization whereby the multiple key-correlated levels are partitioned into multiple QVTc mappings? Perhaps this is part of RelToCore anyway. It would explain why RelToCore assumes only one key per mapping.
Problem 4: Uses includes on input side. Bug no opposite navigation edge so too many heads. 1,2,3,4 can be fixed, but Problem 5: The ModelMorf write-up describes the example as in-place, which solves the problem of how a Type reference is copied. But if we try to support in-place as a scheduling variety of copy, how does a copy work. If the Type is external it gets re-used. If internal it must be mapped to its copy. Needs some kind of when fall-back. Maybe optional parameters but very clunky.
No. Once we read this as in-place it's quite simple. The input is a four deep iteration: cc,ac,aco,acop The output re-uses cc. Far from being a problem this is differential semantics. "cc" locates an input location at which a fully enumerated clone is created. The keys should therefore be a gratuitous irrelevance. The failure to re-specify cc.name is irrelevant because it's in-place differential re-use. BUT. There is no very obvious declaration that identifies the use of differential in-place semantics. Is the consequence of re-use of a variable name too obscure/hazardous? Adding a "copies uml1" to the uml2 domain declaration seems to be a major aid to readability and WFR power. --- What is needed to allow the in-place definition to also be a copy definition? a) we need an 'Element' copies 'Element' non-top relation that implicitly deep copies. b) we need a root 'dummy' copies 'dummy' top relation that overrides 'Element' copies 'Element' and so implicitly deep copies the 'dummy' root. c) we need the existing class tweak top relation to be a non-top relation that overrides 'Element' copies 'Element' and so refines the class copy.
