2. Structure of AToM3 Models
In AToM3, models are stored as a graphs. This graph is implemented
as a class that inherits from ASG,
which in its turn inherits from ASGNode.
The nodes in the graph are instances of classes that inherit from ASGNode.
The important attributes and methods of the ASG
class are shown in the following class diagram:
The attributes have the following meaning:
Figure 1: Structure of ASG objects.
The methods have the following meaning:
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
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
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
Following with the previous example,
suppose you have edited the model properties (accessible through the meny
Model|Edit Model Attributes) as follows:
Figure 2: Editing the model properties
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
ATOM3Type, and that the
method has been overriden. AToM3 Types will be explained in
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
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
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,
def createNewaTest(self, wherex, wherey, screenCoordinates
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
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 AToM3 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 AToM3
, 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()
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.
Maintained by Juan
de Lara. Last modified 22 July 2002.