MOF Query/View/Transformation Avatar
  1. OMG Specification

MOF Query/View/Transformation — Open Issues

  • Acronym: QVT
  • Issues Count: 4
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

CLONE - current abstract syntax of ImperativeOCL introduces a couple of unclear situations

  • Key: QVT14-24
  • Legacy Issue Number: 13082
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Major Problem:
    (1) The current abstract syntax of ImperativeOCL introduces a couple of
    unclear situations. This may lead to incompatible QVT implementations.
    Further Problems:
    (2) Control flow constructs introduced by ImperativeOCL are redundant
    compared with existing conventional OCL constructs.
    (3) Several OCL equivalence rules break when ImperativeOCL is present.
    Detailed problem description:
    (1) The current abstract syntax of ImperativeOCL introduces a couple of
    unclear situations. This may lead to incompatible QVT implementations.
    In the abstract syntax, ImperativeOCL expressions / statements are
    inherited from OclExpression. Therefore, conventional OCL
    expressions may (and will) contain sub-expressions that are
    actually ImperativeOCL expressions.
    In conventional OCL, the interpretation of an expression under a
    given environment is a value. In ImperativeOCL, the interpretation
    of an expression is a value and a new environment
    (state,variables). This extended interpretation is not given for
    conventional OCL expressions, leading to undefined operational
    semantics of those expressions.
    Example: Given the following compute expression:
    compute(z:Boolean) {
    var x : Boolean := true
    var y : Boolean := true
    if ((x:=false) and (y:=false))

    { ... }

    z := y
    }
    What is the value of this expression: is it true or false (It
    depends on whether the 'and' operator is evaluated short-circuit
    or strict). The situation is similar for the evaluation of the
    other logical connectives, forAll, and exists when these
    expressions contain imperative sub-expressions.
    (2) Control flow constructs introduced by ImperativeOCL are redundant
    compared with existing conventional OCL constructs.
    Some of the new language features in ImperativeOCL such as forEach
    and the imperative conditional are not really necessary. Their
    effect can already be achieved using conventional OCL expressions:
    For example:
    company.employees->forEach(c)

    { c.salary := c.salary * 1.1}

    has the same effect as
    company.employees->iterate(c; r:OclAny=Undefined |
    c.salary := c.salary * 1.1
    )
    and
    if ( x < 0 )

    { x := 0 }

    else

    { x := 1 }

    endif is the same as
    if x < 0 then x := 0 else x := 1 endif
    (3) Several OCL equivalence rules break when ImperativeOCL is present.
    In conventional OCL, several equivalence rules well known from
    logic hold. Allowing OCL expression to contain imperative
    sub-expressions breaks these equivalence rules.
    Examples:
    let x=e1 in e2 equiv. e2

    { all occurences of x replaced by e1 }

    e1 and e2 equiv. e2 and e1
    These equivalences do not necessarily hold if e1 or e2 are allowed
    to have side-effects.
    Proposed solution:
    (A) - (The cheap solution.) State textually that conventional OCL
    expressions (as described in the OMG OCL spec.) are not
    allowed to have side effects unless used as part of a top
    level ImperativeOCL expression. Therefore, even in a system
    supporting ImperativeOCL, class invariants, and pre- and
    postconditions (e.g.) will not be allowed to contain
    ImperativeOCL sub-expressions.
    State explicitly that the redundant flow control statements
    have been introduced (solely) to write concise imperative
    programs and that the side-effect free forms of conditional
    evaluation ( 'if-then-else-endif' and 'iterate' ) shall not be
    used to program side-effects (instead, the ImperativeOCL forms
    shall be used).
    (B) - (Major rework.) Rework the abstract syntax to reuse OCL
    expressions by composition rather than by inheritance.
    Imperative expressions ( => rename to 'statements' ) then may
    contain sub-statements and OCL expressions; OCL expressions
    are reused unchanged from the OCL spec (no imperative
    sub-expressions, no side-effects).
    These issues have been discussed on the MoDELS 2008 OCL Workshop,
    more details can be found at
    http://www.fots.ua.ac.be/events/ocl2008/PDF/OCL2008_9.pdf

  • Reported: QVT 1.0 — Mon, 5 Oct 2015 17:32 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTr: working with stereotypes:

  • Key: QVT14-10
  • Legacy Issue Number: 13158
  • Status: open  
  • Source: Siegfried Nolte ( Siegfried Nolte)
  • Summary:

    QVT Relations and working with stereotypes: Is there something like a QVT-R standard library with methods on stereotypes in it? There is none in the specification; compare QVT-R, there are some methods. Are there some else options for accessing stereotypes with QVT-R?

  • Reported: QVT 1.0 — Mon, 15 Dec 2008 05:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTr: BlackBox operation signature difficulties

  • Key: QVT14-2
  • Legacy Issue Number: 13054
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • 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.

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

QVTr: Undefined semantics

  • Key: QVT14-1
  • Legacy Issue Number: 10936
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The whole Concrete Syntax section deserves a much more substantial description.

    In particular...

    The mechanism by which a package name is located is unresolved, perhaps deliberately,
    but the omission should be explicit.

    What constraints exist on forward referencing of names?

    Transformations and mappings could be ordered so that forward references are avoided,
    but large modules benefit from an alphabetical ordering of elements, so requiring
    a parser friendly order is not user friendly.

  • Reported: QVT 1.0 — Sun, 25 Mar 2007 04:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT