CodeGraph

Dependency code visualizer

Introduction

codegraph is a source code dependency visualizer/explorer. It contains an X11 program to visualize code dependencies at different granularities, such as directory, package, module, class, field, etc... It represents dependencies with a hierarchical interactive matrix (or DSM), which you can use to identify code patterns.

The goal is mainly to help understand the software architecture of a project, that is the high-level organization of its code.

codegraph is also a source code indexer that can be used to generate different code databases (TAGS for Emacs/vi, light database for codemap, Prolog database for codequery). The code database is used by Scheck to find bugs, dead code, and other specific patterns.

How to use

Generate the marshall database

The visualization in codegraph and several other programs in this project depend on the indexed graph_code.marshall database. It contains information about the relationships between different entities in the source code being analyzed. See codegraph --help for further options.

# For a Java project
codegraph -lang java -build "path/to/source/code"

# PHP, but store the database in a separate directory
codegraph -lang php -build -o "path/to/database/folder" "path/to/source/code"

# Generate the TAGS for your editor and follow symlinks
codegraph -lang c -build -derived_data -symlinks "path/to/source/code"

View the design structure matrix

# This can print an annoying amount of irrelevant output, so mute the console
codegraph "path/to/graph_code.marshall" &>/dev/null

The viewer should look more-or-less like the screenshot below.

Understand the layout of the visualization

Code entities, such as directories, are setup across the rows and columns. The cell at the intersection between a specific row and column holds the dependencies between the two entities. These dependencies could be one module calling something in the other, a class inheritance between the two, a constant that is referenced in one file from the other, or one of several other dependencies.

For example, should flib use many functions in the standard library, there should a many positive count at the intersection of the PHP_STDLIB row and the flip column.

Interact with the design structure matrix

• Single click on a cell: Show a dialog explaining the dependencies marked by the number in the cell.
• Double click on a row header: Expand the row, showing dependencies of its subdirectories or descendants.
• Right click on a row header: Focus the matrix on only the entities that use that row.

Internals

The arguments are handled by main() within the entry-point file and the graph is generated by language specific files in folders that are named accordingly (e.g. lang_c, lang_java, lang_css); the java graph is built from an AST that's generated by files under lang_java/analyze/graph_code_java.ml, which itself is generated by lang_java/parsing/ast_java.ml).

The Graph is defined by graph_code/graph_code.ml which in turn uses commons2/graph.ml for interacting with the underlying ocamlgraph (which implements the DAG that's used by graph.ml). The operations to load, save, and iterate on the graphs are simple, and the code base is well annotated. Please have a look at the files and feel at home.