The RFG specific classes

Overview

The connection between OpenCAGE and the RFG-library is done by a couple of classes, which implement the Graph Interface (GIF). These classes lie under OpenCAGE.GIF.RFG and encapsulate all RFG specific details (e.g. OpenCAGE requests a tree of Node_Models, but the RFG only provides a graph, which can be a circular one). In the next sections the term "RFG Adapter" is used for the conglomerate of these classes, which implement the Graph Interface (GIF) for the RFG.

Figure 4-2. RFG Adapter / Implementation of Graph Interface (GIF) for RFG

RFG Adapter / Implementation of Graph Interface (GIF) for RFG

The top of the RFG Adapter represents a class RFG_View_Master_Node_Model. This class has no real equivalent in the RFG, look at it as a kind of virtual root node. From an instance of this class you can reach every node within the RFG.

A RFG view is represented by the class RFG_View_Node_Model, which is also directly derieved from the class Node_Model. Instances of this class can only be found as children of a RFG_View_Master_Node_Model. The children of a RFG_View_Node_Model can only be instances of the (abstract) class RFG_Node_Model.

RFG_Node_Model is an abstract class, which provides a basic interface to all nodes contained in a RFG_View_Node_Model. It derives from some intermediate classes from the class Node_Model. As concrete implementations there are RFG_Composite_Node_Models and RFG_Simple_Node_Models. The difference between them: A Composite may has children itself (RFG_Node_Models), the RFG_Simple_Node_Model is a leaf in the tree. Be aware: The naming has nothing to do with some names used internally by the RFG, especially a RFG_Composite_Node_Model does not mean, that an instance of this class represents a composite in terms of the RFG.

Edges

Figure 4-3. RFG Adapter / Implementation of Graph Interface (GIF) for RFG

RFG Adapter / Class hierarchy for edges

A RFG_Edge_Model derieves from Edge_Model and can only exists between objects of the class RFG_Node_Model. OpenCAGE would allow edges between views (under certain circumstances this is a nice feature), but the RFG does not support it.

Attention: Edges with only one connected node are also contained in the model, but they will not be displayed.

Building the tree

After opening the RFG file, the RFG_Model_Factory will create a RFG_View_Master_Node_Model and initialize it to this RFG. From the RFG_View_Master_Node_Model you can access all the views contained in this RFG.

A view itself looks only for all nodes on the top level. A node which has no outgoing part-of-edges is at this level. Nodes which have at least one outgoing part-of-edge (they point to the parent), cannot be at the first level.

All nodes and edges, which are hierarchically in the top layer of a view, will be read when opening the view. Objects contained in composite nodes, will be read when opening the composite node.

Getting Type information

The simplicity of the class-hierarchy is directly opposed to a enormous number of node and edge types within the RFG. Therefore the type information of the rfg objects cannot be stored directly in the adapter objects.

The abstract class Typed_Node_Model and Typed_Edge_Model, which are superclasses of all relevant adapter classes, provide a method to get to their appropriate type information. Every object can be asked for Type_Info, which is a generic interface to type informations.

How is the RFG Adapter affected by changes directly to the RFG?

Whenever an object of the RFG Adapter is created, an observer is registerd to the corresponding rfg object. If the rfg object is manipulated, created or deleted (e.g. by an action or an analysis), the observer sends "his" OpenCAGE counterpart a message, and then the OpenCAGE object will react in a corresponding way.

Note: Some rfg objects notify several OpenCAGE nodes, but these nodes normally react in a different way to the same message. For further details see RFG to OpenCAGE Model Events (the Section called RFG to OpenCAGE Model Events in Chapter 8).