The behaviour of a graph transformation rule can be divided into two distinct phases.
The precondition pattern defines a condition which needs to be satisfied in order to successfully apply the GT rule (called also as left-hand side pattern - LHS). This is carried out by graph pattern matching, which collects all the matches of the precondition pattern.
Parameters of the precondition pattern can be bound or unbound before the execution of this part. After successful graph pattern matching, all parameters of the precondition pattern become bound.
If graph pattern matching fails then the GT rule is free of side-effects, (i.e. neither the postcondition nor the action part is executed). Furthermore, the GT rule reports a failure towards its caller environment (which can still mask this failure as in case of forall rule).
The postcondition pattern (right-hand side pattern - RHS) describes declaratively what conditions should hold as a result of applying the GT rule. In general, a GT rule calculates the difference of the postcondition and precondition for one or more matches in an atomic step.
When invoking a GT rule from a choose rule, then the rule is applied on a single match, while in case of a forall rule, all matches of the precondition pattern are processed in a pseudo-parallel way independently from each other.
The postcondition may prescribe four different operations on the model space.
Preservation.
If an input parameter of the postcondition also appears in the pattern itself, then the matching model
element is preserved. This behavior is denoted by
keep(X).
Deletion.
If an input parameter of the postcondition does not appear in the postcondition pattern itself then the
matching model element is deleted. In such a case, the
undef
value will be assigned to the parameter, thus it becomes unbound. This behavior is denoted by
deleteEntity(X)
or
deleteRelation(X).
Creation.
If a variable which appears in the body of the postcondition pattern is an output parameter of the
postcondition, then a new model element is created, and the variable is bound to this new model element.
This behavior is denoted by
newEntity(X))
or
newRelation(R, A, B))
(in the latter case,
A
is the source and
B
is the target of that relation).
Move.
If a
containment constraint
is defined for an entity in the postcondition pattern, then the entity is moved to as a child of the new
container entity. This behavior is denoted by
move(X, Par)
where
keep(Par)
is the new container entity.
After pattern matching and the resolution of the postcondition pattern is carried out, a GT rule will execute a sequence of additional actions defined as ordinary ASM rules.
All parameters of both the precondition and the postcondition can be used in the action part, but internal pattern variables (i.e. those that does not appear as a parameter of the pattern) are not visible in the action part. Naturally, all parameters of the GT rule itself can also be used in the action part.
After these general rules, a detailed description follows on the specificities of resolving the postcondition pattern.