QVT 1.4 RTF Avatar
  1. OMG Issue

QVT14 — QVTr: checkonly confusion

  • Key: QVT14-66
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The descriptions regarding checkonly and enforce are incomplete and the examples are misleading.

    When a domain is selected as a target, there are three execution possibilities.

    • the target is enforced - created/replaced/updated/...
    • the target is checked - compared
    • the target selection is illegal - an unsupported direction

    The illegal state is never described, but is at the heart of a unidirectional transformation for which, as in RelToCore, the source-only domain has no checkonly/enforce and the target-only domain has enforce.

    In contrast almost all of the UML2RDBMS examples have the uml domain marked as checkonly, which requires that an execution from RDBMS to check a pre-existing UML is permissible. This requires that the transformation is genuinely bidirectional although by using checkonly rather than enforce the programmer has unhelpfully prohibited the to-UML result from being persisted.

    It is doubtful that checkonly has any value at all as a concrete syntax / abstract syntax annotation. Surely a plausible output domain is always enforce; it is the way in which the transformation is invoked that configures whether the enforce creates/replaces/updates/compares/checks... ? Perhaps it is the redundancy of checkonly that has led to the misunderstandings exemplified by the UML2RDBMS example that checkonly marks the input of a unidirectional relation.

    Actions required:

    • describe the third illegal target state
    • change UML2RDBMS examples to genuinely unidirectional
    • provide a bidirectional example
    • deprecate checkonly
  • Reported: QVT 1.3 — Mon, 14 Oct 2019 07:33 GMT
  • Updated: Mon, 14 Oct 2019 07:42 GMT