Creating the FSA meta-model: Transitions


Please exit and reload AToM3. Open the FSA meta-model (FSA_ER_mdl.py) as a model. We are now going to add some functionalities to the "transition" relationship. First, we need to add some input/output variables since a transition takes an input and produce an output. Create two new strings (input/output) in the list of attributes:  

 

Right-click on "Ok" to confirm the new attributes. Now we will setup an appropriate appearance (including input/output) for the transition. Go in the "appearance" section of the transition properties screen. Select the "center" zone of the relationship and set its appearance to this:  

 

Now, remember that we wanted to have a certain control on the input/output the user enters. In order to do this, global lists of input and output will be added to the model attributes. Then, a constraint will scan the list to make sure that every inputs and every outputs are legal when the user use them on a transition. Consequently, the user will have to specify in advance what are the allowed inputs/outputs. This approach may look awkward, but it will force the FSA creator to think of a design before drawing the actual FSA. Also, the user can easily verify, by looking at the lists, that he is not choosing inputs/outputs he has already used. Now, the first step to create this feature is to add two lists in the global attributes:  

 

Next, we will add two constraints to the transition relationship that will check the inputs/outputs each time they are entered in an instance. Add an "inputvalid" constraint to the transistion's list of constraints and set the code to this:  

 

There are 3 things to set when you are editing a constraint: The language (now only available is python, ocl is not supported yet), the event (save, edit, etc) that triggers the execution of the constraint and finally the time the constraint is executed (pre or post condition). For example, in our case, *python* codes gets executed after (*post-condition*) we *edit* the current transition. If the constraint is not respected, we return a tuple (String message, variable that caused the error) else we return None. If we go over the python code line by line:  

Line 1  

   

Getting the input that is saved in the "input" variable of the current transition.  

Line 3  

   

Getting the model variable "input_alphabet" that contains the valid inputs.  

Line 4-5-6  

   

Scanning the list "input_alphabet" to find a match with "input". If a match is found, the constraint is respected, we return None. Else we return a tuple to confirm that the constraint was not respected. The tuple is {warning message as string, object to be highlighted or None}  

The code for the output constraint is quite similar:  

 

The next step is to set up the allowed number of connections between entities in the modeling environment, the cardinalities.