<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>3.3.1.&nbsp;Restrictions of model elements used in postcondition patterns</title><link href="style.css" rel="stylesheet" type="text/css"><meta content="DocBook XSL Stylesheets V1.72.0" name="generator"><link rel="start" href="index.html" title="The VIATRA2 Model Transformation Framework"><link rel="up" href="sec_GTRuleBehaviour.html" title="3.3.&nbsp;Behavioural Specification of Graph Transformation Rules"><link rel="prev" href="sec_GTRuleBehaviour.html" title="3.3.&nbsp;Behavioural Specification of Graph Transformation Rules"><link rel="next" href="sec_PostconditionSpec.html" title="3.3.2.&nbsp;Complete behavioral specification of postcondition patterns"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">3.3.1.&nbsp;Restrictions of model elements used in postcondition patterns</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="sec_GTRuleBehaviour.html">Prev</a>&nbsp;</td><th align="center" width="60%">3.3.&nbsp;Behavioural Specification of Graph Transformation Rules</th><td align="right" width="20%">&nbsp;<a accesskey="n" href="sec_PostconditionSpec.html">Next</a></td></tr></table><hr></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="sec_PostconditionRestriction"></a>3.3.1.&nbsp;Restrictions of model elements used in postcondition patterns</h4></div></div></div><p>
Compared to the precondition <a href="def_PatternBody.html" title="2.1.2.&nbsp;Pattern Body">pattern body</a> 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. 
</p><div class="itemizedlist"><ul type="disc"><li><p>
				<span class="emphasis"><em>Relationship definitions</em></span>
				(i.e.	<code class="computeroutput">supertypeOf</code>,
				<code class="computeroutput">subtypeOf</code>,
				<code class="computeroutput">instanceOf</code>,
				<code class="computeroutput">typeOf</code>). 
				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.
			</p></li><li><p>
				<span class="emphasis"><em>Negative patterns</em></span>;
			</p></li><li><p>
				<span class="emphasis"><em>OR patterns</em></span>;
			</p></li><li><p>
				<span class="emphasis"><em>Recursive pattern composition</em></span>;
			</p></li><li><p>
				<span class="emphasis"><em>Pattern variable assignments</em></span>;
			</p></li><li><p>
				<span class="emphasis"><em>Check conditions</em></span>;
			</p></li></ul></div><p>
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. 
</p><p>
In other terms, the postcondition pattern may contain an <a href="def_Entity.html" title="2.2.1.&nbsp;Entity">entity</a>, 
a <a href="def_Relation.html" title="2.2.2.&nbsp;Relation">relation</a>, <a href="def_ContainmentConstraint.html" title="2.1.9.&nbsp;Containment Constraint">containment constraints</a> and 
(non-recursive) <a href="def_PatternComposition.html" title="2.1.5.&nbsp;Pattern Composition">pattern composition</a>. 
</p><p>
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 <code class="computeroutput">X </code>is a priori ground. 
</p><pre class="programlisting">
entity(X); 
entity(Y) in X; 
</pre><p>
However, in case of postcondition patterns, both entity <code class="computeroutput">X </code>and <code class="computeroutput">Y </code>can be 
unbound, i.e. they are created within the same step, and <code class="computeroutput">X </code>can be set as the 
parent of <code class="computeroutput">Y </code>. 
</p><p>
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. 
</p><p>
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). 
</p></div><div class="navfooter"><hr><table summary="Navigation footer" width="100%"><tr><td align="left" width="40%"><a accesskey="p" href="sec_GTRuleBehaviour.html">Prev</a>&nbsp;</td><td align="center" width="20%"><a accesskey="u" href="sec_GTRuleBehaviour.html">Up</a></td><td align="right" width="40%">&nbsp;<a accesskey="n" href="sec_PostconditionSpec.html">Next</a></td></tr><tr><td valign="top" align="left" width="40%">3.3.&nbsp;Behavioural Specification of Graph Transformation Rules&nbsp;</td><td align="center" width="20%"><a accesskey="h" href="index.html">Home</a></td><td valign="top" align="right" width="40%">&nbsp;3.3.2.&nbsp;Complete behavioral specification of postcondition patterns</td></tr></table></div></body></html>