| <html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>3.3.1. 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. Behavioural Specification of Graph Transformation Rules"><link rel="prev" href="sec_GTRuleBehaviour.html" title="3.3. Behavioural Specification of Graph Transformation Rules"><link rel="next" href="sec_PostconditionSpec.html" title="3.3.2. 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. 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> </td><th align="center" width="60%">3.3. Behavioural Specification of Graph Transformation Rules</th><td align="right" width="20%"> <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. 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. 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. Entity">entity</a>, | |
| a <a href="def_Relation.html" title="2.2.2. Relation">relation</a>, <a href="def_ContainmentConstraint.html" title="2.1.9. Containment Constraint">containment constraints</a> and | |
| (non-recursive) <a href="def_PatternComposition.html" title="2.1.5. 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> </td><td align="center" width="20%"><a accesskey="u" href="sec_GTRuleBehaviour.html">Up</a></td><td align="right" width="40%"> <a accesskey="n" href="sec_PostconditionSpec.html">Next</a></td></tr><tr><td valign="top" align="left" width="40%">3.3. Behavioural Specification of Graph Transformation Rules </td><td align="center" width="20%"><a accesskey="h" href="index.html">Home</a></td><td valign="top" align="right" width="40%"> 3.3.2. Complete behavioral specification of postcondition patterns</td></tr></table></div></body></html> |