| <html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>3.3. Behavioural Specification of Graph Transformation Rules</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_GraphTransformations.html" title="3. Graph Transformation Rules"><link rel="prev" href="sec_GTParamPass.html" title="3.2. Parameter passing at Graph Transformation Rules"><link rel="next" href="sec_PostconditionRestriction.html" title="3.3.1. Restrictions of model elements used in 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. Behavioural Specification of Graph Transformation Rules</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="sec_GTParamPass.html">Prev</a> </td><th align="center" width="60%">3. Graph Transformation Rules</th><td align="right" width="20%"> <a accesskey="n" href="sec_PostconditionRestriction.html">Next</a></td></tr></table><hr></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="sec_GTRuleBehaviour"></a>3.3. Behavioural Specification of Graph Transformation Rules</h3></div></div></div><div class="toc"><dl><dt><span class="sect3"><a href="sec_PostconditionRestriction.html">3.3.1. Restrictions of model elements used in postcondition patterns</a></span></dt><dt><span class="sect3"><a href="sec_PostconditionSpec.html">3.3.2. Complete behavioral specification of postcondition patterns</a></span></dt><dt><span class="sect3"><a href="sec_ConflictHandling.html">3.3.3. Handling of conflicts</a></span></dt></dl></div><p> | |
| The behaviour of a graph transformation rule can be divided into two distinct | |
| phases. | |
| </p><div class="variablelist"><dl><dt><span class="term"><span class="strong"><strong>Precondition</strong></span></span></dt><dd><p> | |
| 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. | |
| </p><p> | |
| Parameters of the <span class="emphasis"><em>precondition pattern</em></span> can be bound or unbound before | |
| the execution of this part. After successful graph pattern matching, all | |
| parameters of the precondition pattern become bound. | |
| </p><p> | |
| 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 | |
| <a href="def_ForallRule.html" title="4.3.7. Forall Rule">forall rule</a>). | |
| </p></dd><dt><span class="term"><span class="strong"><strong>Postcondition</strong></span></span></dt><dd><p> | |
| 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. | |
| </p><p> | |
| When invoking a GT rule from a <a href="def_ChooseRule.html" title="4.3.6. Choose Rule">choose rule</a>, | |
| then the rule is applied on a single match, while in case of a | |
| <a href="def_ForallRule.html" title="4.3.7. Forall Rule">forall rule</a>, all matches of the precondition | |
| pattern are processed in a pseudo-parallel way independently from each | |
| other. | |
| </p><p> | |
| The postcondition may prescribe four different operations on the model space. | |
| </p><div class="itemizedlist"><ul type="disc"><li><p> | |
| <span class="emphasis"><em>Preservation.</em></span> | |
| 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 | |
| <code class="computeroutput">keep(X)</code>. | |
| </p></li><li><p> | |
| <span class="emphasis"><em>Deletion.</em></span> | |
| 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 | |
| <span class="emphasis"><em>undef</em></span> | |
| value will be assigned to the parameter, thus it becomes unbound. This behavior is denoted by | |
| <code class="computeroutput">deleteEntity(X)</code> | |
| or | |
| <code class="computeroutput">deleteRelation(X)</code>. | |
| </p></li><li><p> | |
| <span class="emphasis"><em>Creation.</em></span> | |
| 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 | |
| <code class="computeroutput">newEntity(X))</code> | |
| or | |
| <code class="computeroutput">newRelation(R, A, B))</code> | |
| (in the latter case, | |
| <code class="computeroutput">A</code> | |
| is the source and | |
| <code class="computeroutput">B</code> | |
| is the target of that relation). | |
| </p></li><li><p> | |
| <span class="emphasis"><em>Move.</em></span> | |
| If a | |
| <a href="def_ContainmentConstraint.html" title="2.1.9. Containment Constraint">containment constraint</a> | |
| 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 | |
| <code class="computeroutput">move(X, Par)</code> | |
| where | |
| <code class="computeroutput">keep(Par)</code> | |
| is the new container entity. | |
| </p></li></ul></div></dd><dt><span class="term"><span class="strong"><strong>Action</strong></span></span></dt><dd><p>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. | |
| </p><p> | |
| 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. | |
| </p></dd></dl></div><p> | |
| After these general rules, a detailed description follows on the specificities | |
| of resolving the postcondition pattern. | |
| </p></div><div class="navfooter"><hr><table summary="Navigation footer" width="100%"><tr><td align="left" width="40%"><a accesskey="p" href="sec_GTParamPass.html">Prev</a> </td><td align="center" width="20%"><a accesskey="u" href="sec_GraphTransformations.html">Up</a></td><td align="right" width="40%"> <a accesskey="n" href="sec_PostconditionRestriction.html">Next</a></td></tr><tr><td valign="top" align="left" width="40%">3.2. Parameter passing at 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.1. Restrictions of model elements used in postcondition patterns</td></tr></table></div></body></html> |