Difference between revisions of "Atlas Schema"
BenHolland (Talk | contribs) |
BenHolland (Talk | contribs) |
||
| Line 1: | Line 1: | ||
| − | The way that <code>GraphElement</code> | + | The way that <code>GraphElement</code> objects are attributed and tagged and the way nodes are connected by edges in the Atlas index follows a strict rule set that forms the Atlas Schema. The rule set is influenced by the language the index is being created for (ex: Java, C, C++) and the way Atlas represents the language abstractions. For example, <code>call</code> edges only exist between two nodes that are both methods or from a callsite (control flow block) to a method. Adding a <code>call</code> relationship anywhere else in the graph would be confusing (and violate our schema!). Some edges are summaries of other more fine grain relationships. A <code>call</code> edge between two methods represents a summary of at least one control flow edge leaving the method to the target method. This summary relationship relative to its finer grain edges can be thought of as a hierarchy of edges. |
To see a list of all the Atlas nodes and edge types with their summary relationships you should refer to the official [[Extensible Common Software Graph]] documentation, which Atlas implements. | To see a list of all the Atlas nodes and edge types with their summary relationships you should refer to the official [[Extensible Common Software Graph]] documentation, which Atlas implements. | ||
Revision as of 18:28, 3 February 2015
The way that GraphElement objects are attributed and tagged and the way nodes are connected by edges in the Atlas index follows a strict rule set that forms the Atlas Schema. The rule set is influenced by the language the index is being created for (ex: Java, C, C++) and the way Atlas represents the language abstractions. For example, call edges only exist between two nodes that are both methods or from a callsite (control flow block) to a method. Adding a call relationship anywhere else in the graph would be confusing (and violate our schema!). Some edges are summaries of other more fine grain relationships. A call edge between two methods represents a summary of at least one control flow edge leaving the method to the target method. This summary relationship relative to its finer grain edges can be thought of as a hierarchy of edges.
To see a list of all the Atlas nodes and edge types with their summary relationships you should refer to the official Extensible Common Software Graph documentation, which Atlas implements.
In general the index currently contains:
- The major declarations (projects, types, packages, fields, methods), and associated relationships, such as the type hierarchy.
- A "summary" graph, which includes method and control-flow-granularity relationships, such as calls and reads/writes of fields, among other things. For example, if a method foo() calls bar() in 5 places, the method-granularity relationships will have a single CALL edge to represent that there exists at least one call from foo() to bar(). Similarly, the control-flow-granularity relationships will have a single CALL edge per control flow block.
- Control flow.
- Data flow.
