We are now going into the details of the first rule of the Graph Grammar Model which locate and simulate a transition state A ==> state B. We will also go over the common details of every rule, so please read this part before reading the next two rules! So, if you select "transition" and you click on "edit":  

Name  

The name of the rule that will be used to generate a file (rulename.py) to be used in the execution (Very important to specify!)

LSH/RHS: Left Hand Side/Right Hand Side  

The LHS option lead to an interface where it is possible to specify a pattern that will be matched by the Graph Grammar algorithm and replaced by the RHS pattern. For example, if you click on the LHS button:  

This is a normal FSA model like we designed in the beginning of this tutorial. You see that the meta-model of FSA is loaded on the left and that states are connected through transitions. However, where does the "current state" come from? You can consider this entity as being private. Indeed, it is included in the FSA meta-model but it was hided when the model environment was generated by ATOM3. You can easily understand that this entity is not useful to create a FSA so it does not need to be included in the modelying environment. However, we need, in simulation, a way to tell the user what state we are in at any moment in time. Hence, the "current state" was added temporarly to the interface of the modelying environment to create the Graph Grammar and removed afterwards. Also, you may notice that each element in the LHS is mapped to a number (GGlabel): An element in the LHS gets replaced by the element in the RHS that has the same GGLabel. For example, we could replace a FSA state by another state in the RHS and only change its data. However, If the one GGLabel that is present in the LHS is not present in the RHS, the object gets deleted. Lets check the attributes of the state with GGLabel 3:  

We see that every attributes of the FSA state are set "to any", this means that the algorithm will replace the pattern independently from the data of its elements. Every other elements of the LHS are similar to this one, so no screenshots are included. If we look at the RHS now (the properties of the FSA state with GCLabel 3 are also shown) :  

We notice that the only modification is the evolution of the "current state" to the next state. Every elements of the RHS keep the same GGLabel since we do not need to delete nodes to simulate FSA semantics. The properties screen tells us that the data from the LHS gets copied into the RHS for every elements of the LHS. In another context, we could have specified the attributes with python code. Now, what happens if the algorithm finds the pattern of the LHS, but the wrong input was entered in the list? We need a condition to prevent the pattern to be transformed!

Condition

A boolean expression that must be satisfied for the matched pattern in the LHS be transformed in the RHS. If you click on "condition" :  

Only the option "name" is used in the interface for the condition. The options "python code", "OCL", "edit", etc. are disabled for now. The objective of those lines of code is to check that the first input in the list match the input in the transition, for the transformation to the next state be legal. Lets describe the lines of code:

line 2: Return the node on the LHS with GGLabel(4), which is the transition between the to FSA states.

line 4: Get the input attribute from the transition.

line 5: if it exists (!= None), we compare it to the first element of the input list (current_input) and return the result.

But now, when does "current input" gets updated and the list truncated? We need an action section!

Action

An action that is performed after each pattern transformation from the LHS to the RHS.  

As of in the condition section, only the option "name" is usable in the menu on the top of the interface. Ok, if we describe the lines of code:

line 1: Get the input list that was entered by the user (This list gets created in the initial action section, see next step)

line 2: Removes the first element (we delete the element that was just used in the condition)

line 3: Update "inputs" with the new truncated list

line 4: Check if the list is not empty

line 5: Set the current_input to the next input

line 6/7: There is no more input, we set the current_input to "None"

line 9: We get the ouput attribute from the transition in the LHS

line 10: We get the list of output that will appear to the user

line 11/12: we append the next output to the list and update the variable

line 13: we show to the user the list of outputs