Source: Model Driven Solutions ( Ed Willink)
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.
- 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