QVT 1.4 RTF Avatar
  1. OMG Issue

QVT14 — QVTr: BlackBox operation signature difficulties

  • Key: QVT14-2
  • Legacy Issue Number: 13054
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    In (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)


    package QVTRelation

    context RelationImplementation
    inv RootNodeIsBoundToRootVariable : self.inDirectionOf.allUsedPackage()>includes(self.impl.ownedParameter>at(1).type._package)


    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.

  • Reported: QVT 1.0 — Fri, 31 Oct 2008 04:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT