6.5.3.1. Views¶
C++ RFGs contain the same views as C RFGs (see Language Representation for C), since the C++ language model is an extended C model. C++ RFGs contain
a
Code Factsview,a
Moduleview,an
Environmentview,a
Callview,a
Declaration Factsview,a
Fileview, andan
Includeview.
Analyses might enrich the RFG with further views (e.g., a Dead / Alive view).
Code Facts View¶
The Code Facts view contains nodes and edges for the definitions of the
analyzed system. In C++ RFGs it additionally covers class hierarchies, member functions,
templates and their instantiations, and namespace structures, all of which extend the
corresponding C model.
Module View¶
The Module view contains the file and directory hierarchy of the system
under analysis. The leaves are nodes from the Code Facts view. It groups
source entities by the translation unit (module) in which they are defined.
Environment View¶
The Environment view contains the subset of nodes from the
Code Facts view that stem from the environment (libraries, system headers,
etc.) rather than from the source code directly under analysis.
Call View¶
The Call view contains the subset of the Code Facts view
consisting of the
Routine nodes and
Call edges. In C++ RFGs this includes member functions, constructors,
destructors, and function template instantiations. It is useful for detecting call
cycles in the program.
Declaration Facts View¶
The Declaration Facts view contains nodes and edges for the declarations
and definitions of the analyzed system. Unlike the Code Facts view, which
focuses on definitions, the Declaration Facts view also captures forward
declarations, making it suitable for architecture analyses that treat header-file
interfaces as class or module boundaries.
File View¶
The File view contains directory and file nodes representing the code files
of the analyzed project. Nested within a source file F are all nodes representing
source entities from the Declaration Facts view that are contained in F.
Include View¶
The Include view contains directory and file nodes. It illustrates how code
files are included in each other, reflecting the #include directive relationships
between translation units.
Note
For some analyses, you need a pair of views, one containing the dependency
information (i.e., the source dependency edges), one containing the hierarchy
information. You can choose between the pairs Code Facts/
Module and Declaration Facts/ File. Other
combinations of these views do not make sense in general.
Which pair you choose depends on what are the appropriate elements for the analysis.
If, e.g., your architecture depends on “modules” that can be used as a whole, choose the
Code Facts/Modulepair.If, on the other hand, your architecture depends on declarations that are made visible in header files (as some kind of interfaces), choose the
Declaration Facts/Filepair.If your architecture actively uses declarations for interfacing (e.g. “I state my need for some function that must be defined somewhere else”), also choose the
Declaration Facts/Filepair.