Issue 13054: MOF-QVT 1.0: 7.11.3.6 (and 7.11.1.1) BlackBox operation signature difficulties (qvt-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Uncategorized Issue Severity: Summary: In 7.11.3.6 (and 7.8) the ordering of parameters is implied but not explicit. Presumably the first is the output (enforced direction) so: package QVTBase context TypedModel def: allUsedPackage() : Set(EMOF::Package) = self.dependsOn.allUsedPackage()->asSet()->union(self.usedPackage) endpackage package QVTRelation context RelationImplementation inv RootNodeIsBoundToRootVariable : self.inDirectionOf.allUsedPackage()->includes(self.impl.ownedParameter->at(1).type._package) endpackage This is not satisfied by almost the last line of RelToCore in 10.3: enforce domain core me:OclExpression{} implementedby CopyOclExpession(re, me); which seems to have output second. ----------------------------------------------------- More significantly CopyOclExpession(re, me) is not meaningful as a black box signature, since it is a static function and EMOF has no way to define static functions. Perhaps it is a query, for which the declaration was omitted from the example. If this is the case, it should be made clear that black box operations must be declared internally as queries and bound externally to static operations of the transformation. This semantic clumsiness could be resolved, if, within a transformation, relation, domain or query, self is bound to a transformation instance. Queries would then be normal non-static operations of the transformation (class) and the implementedBy operation call would be a normal implicit call via self of a non-static transformation operation or query. (A RelationCallExp would also deviate less from OCL than it currently does.) This would also allow a transformation to extend a Utility class that provided the required black box operations. Since queries and relations are declarative, it is not obvious that there need be any prohibition on the content of an extended Class; if the Class has properties, these cannot mutate during a query or relation match, so the properties are ok; they might even permit useful behavioural tailoring. For instance an 'inherited' Boolean mangledNames property could influence the mapping of names between input and output. The RelToCore example can then be mended by declaring that: RelToCore(...) extends utils::CopyUtilities and externally binding the utils model name to a package that has a CopyUtilities class with suitable a CopyOclExpession operation. Resolution: 7.11.3.6 (and 7.11.1.1) BlackBox operation signature difficulties In 7.11.3.6 (and 7.8) the ordering of parameters is implied but not explicit. Presumably the first is the output (enforced direction) so: package QVTBase context TypedModel def: allUsedPackage() : Set(EMOF::Package) = self.dependsOn.allUsedPackage()>asSet()>union(self.usedPackage) endpackage package QVTRelation context RelationImplementation inv RootNodeIsBoundToRootVariable : self.inDirectionOf.allUsedPackage()>includes(self.impl.ownedParameter>at(1).type._package) endpackage This is not satisfied by almost the last line of RelToCore in 10.3: enforce domain core me:OclExpression{} implementedby CopyOclExpession(re, me); which seems to have output second. ----------------------------------------------------- More significantly CopyOclExpession(re, me) is not meaningful as a black box signature, since it is a static function and EMOF has no way to define static functions. Perhaps it is a query, for which the declaration was omitted from the example. If this is the case, it should be made clear that black box operations must be declared internally as queries and bound externally to static operations of the transformation. This semantic clumsiness could be resolved, if, within a transformation,relation, domain or query, self is bound to a transformation instance. Queries would then be normal non-static operations of the transformation (class) and the implementedBy operation call would be a normal implicit call via self of a non-static transformation operation or query. (A RelationCallExp would also deviate less from OCL than it currently does.) This would also allow a transformation to extend a Utility class that provided the required black box operations. Since queries and relations are declarative, it is not obvious that there need be any prohibition on the content of an extended Class; if the Class has properties, these cannot mutate during a query or relation match, so the properties are ok; they might even permit useful behavioural tailoring. For instance an 'inherited' Boolean mangledNames property could influence the mapping of names between input and output. The RelToCore example can then be mended by declaring that: RelToCore(...) extends utils::CopyUtilities and externally binding the utils model name to a package that has a CopyUtilities class with suitable a CopyOclExpession operation. Discussion Binding self to a Transformation instance may conflict with self as the context in a query. Much safer to bind this; just like QVTo. Using this as the source of an OperationCallExp of a query eliminates an incompatibility with OCL. But there is no need bloat every RelationCallExp with an extra VariableExp for this. Any enhancement here needs prototyping. Revised Text: Actions taken: October 31, 2008: received issue December 22, 2015: Deferred March 29, 2016: closed issue Discussion: I would like to see a working implementation of this before resolving. Disposition: Deferred End of Annotations:===== te: Fri, 31 Oct 2008 14:20:04 +0000 From: Ed Willink User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) To: issues@omg.org Subject: MOF-QVT 1.0: 7.11.3.6 (and 7.11.1.1) BlackBox operation signature difficulties X-Plusnet-Relay: d03b6b7f815efa923c3347d48549ef3d In 7.11.3.6 (and 7.8) the ordering of parameters is implied but not explicit. Presumably the first is the output (enforced direction) so: package QVTBase context TypedModel def: allUsedPackage() : Set(EMOF::Package) = self.dependsOn.allUsedPackage()->asSet()->union(self.usedPackage) endpackage package QVTRelation context RelationImplementation inv RootNodeIsBoundToRootVariable : self.inDirectionOf.allUsedPackage()->includes(self.impl.ownedParameter->at(1).type._package) endpackage This is not satisfied by almost the last line of RelToCore in 10.3: enforce domain core me:OclExpression{} implementedby CopyOclExpession(re, me); which seems to have output second. ----------------------------------------------------- More significantly CopyOclExpession(re, me) is not meaningful as a black box signature, since it is a static function and EMOF has no way to define static functions. Perhaps it is a query, for which the declaration was omitted from the example. If this is the case, it should be made clear that black box operations must be declared internally as queries and bound externally to static operations of the transformation. This semantic clumsiness could be resolved, if, within a transformation, relation, domain or query, self is bound to a transformation instance. Queries would then be normal non-static operations of the transformation (class) and the implementedBy operation call would be a normal implicit call via self of a non-static transformation operation or query. (A RelationCallExp would also deviate less from OCL than it currently does.) This would also allow a transformation to extend a Utility class that provided the required black box operations. Since queries and relations are declarative, it is not obvious that there need be any prohibition on the content of an extended Class; if the Class has properties, these cannot mutate during a query or relation match, so the properties are ok; they might even permit useful behavioural tailoring. For instance an 'inherited' Boolean mangledNames property could influence the mapping of names between input and output. The RelToCore example can then be mended by declaring that: RelToCore(...) extends utils::CopyUtilities and externally binding the utils model name to a package that has a CopyUtilities class with suitable a CopyOclExpession operation.