Programming

2. Structure of AToM³ Models

• metaModelName: a string which contains the name of the meta-model.
• root: a pointer to the first object created in the model.
• listNodes: a dictionary, indexed by the allowed node types (strings), which contains lists of the current nodes in the model.
• nodeTypes: a list of strings with the allowed node types.
• mergedASG: a list with other ASG objects which have been merged with the current one. This happens when several meta-models are opened at the same time.

• merge : merges the given ASG with the current one.
• unMerge: separates the given ASG from the current one, if they were previously merged.
• hasMetaModel: returns 1 if metaModel (a string) is one of the meta-models that are loaded.
• open: Method to open an ATOM3 instance to edit the entities.
• nodeWithLabel: returns a node with the graph grammar label 'label' (a number). This method is used frecuently in Actions in graph grammar rules.
• invalid: Extends the ASGNode method invalid to check whether the graph grammar labels are all diferent, in the case that this graph is a LHS or RHS of a graph grammar rule (see section 6).

2.1. Example

If you click on Generate Code, several Python files are generated:

• One of them is ASG_myTest.py. You can see that the ASG_myTest class inherits from ASG and ATOM3Type, and that the open method has been overriden. AToM³ Types will be explained in section 4.
• Other of the Python files that is generated is called <meta-model-name>_MM.py, in our case myTest_MM.py. To make this file a little more interesting, we have created in the meta-model a relationhip 'aRel' which connects 'aTest' entities. When the meta-model myTest is loaded, the functions defined in this file are indeed added to the ATOM3 class methods. You can observe that a method is generated to fill the ConnectivityMap and CardinalityTable dictionaries (these are explained in the ATOM3 class section, but basically they provide ATOM3 with the information about how entities can be connected). There are also some methods to create new objects (in our case aTest and aRel objects), which are called createNew<object>. These methods have all the same signature, for example:

def createNewaTest(self, wherex, wherey, screenCoordinates = 1):

where wherex and wherey are the coordinates where the object is to be created. If they are already converted into canvas coordinated, then the screenCoordinates parameter must be 0, else it must be 1.

In this same file there's another method (fillTypesInformation) which is used to provide ATOM3 with the allowed types that can be used when the meta-model is loaded. More about this in the ATOM3 class section.

A Python file which contains a model of the user interface to be loaded with the formalism. This file is named in our case myTest.py. Indeed this file can be loaded in AToM³ as a model (it's a model in the Buttons formalism) or as a meta-model (and then the model in the Buttons formalism will get interpreted by AToM³ , which will create the actual buttons in the user interface). By default the Buttons model is populated with a button for each object defined in the meta-model (in our case two buttons: one to create aTest objects and another to create aRel objects). If you open myTest.py as a model, and you inspect the Python code that is executed when the Button is pressed you will see that there are invokations to the methods created in myTest_MM.py : createNewaTest() and createNewaRel(). You can of course modify this Buttons model to add new buttons, or delete those you don't want, but beware!: if you save this model with the same name, and later you re-generate code for the meta-model, you'll loose your changes, as this file will get overwritten. So if you are going modify your meta-model later, save the modified Buttons model with another name!. In section Debugging and common programming patterns, we'll show some examples of creating buttons to execute graph grammars.