Compared to the precondition pattern body processed by the pattern matching engine, the body of postcondition pattern is allowed to use a restricted set of model elements. The following elements are not allowed to appear in the pattern body.
Relationship definitions
(i.e. supertypeOf,
subtypeOf,
instanceOf,
typeOf).
As a consequence, the manipulation of relationships can only be carried out in the action part of a
GT rule by ASM model manipulation rules.
Negative patterns;
OR patterns;
Recursive pattern composition;
Pattern variable assignments;
Check conditions;
If any of these forbidden constructs are used locally in the postcondition pattern, then the parser should issue an error message. However, in order to facilitate reuse of predefined patterns, if forbidden constructs appear in a predefined pattern used in the postcondition, then these constructs are ignored during execution, and a warning is issued at compile time.
In other terms, the postcondition pattern may contain an entity, a relation, containment constraints and (non-recursive) pattern composition.
The only part where the postcondition pattern is more permissive compared to the
precondition pattern is related to containment constraints. The following piece
of VTCL code is valid in the precondition only if X is a priori ground.
entity(X); entity(Y) in X;
However, in case of postcondition patterns, both entity X and Y can be
unbound, i.e. they are created within the same step, and X can be set as the
parent of Y .
In case of (non-recursive) pattern composition appearing in the postcondition, the behaviour is equivalent to as if we had a flattened pattern by copying and merging model elements from the subpatterns.
In the sequel, we assume that this flattening is already carried out, and we refer to any of these elements as part of the postcondition (and not only locally defined ones).