Skip to main content

Graph Views

DependencyAtlas can project the same snapshot at three different layers: method, file, and module. These are not separate analyses. They are different ways to ask questions about the same canonical graph.

Fast heuristic

If your question is about behavior, start with method.
If it is about repo structure, start with file.
If it is about architecture or subsystem boundaries, start with module.

Method View​

Use method view when you care about executable behavior.

It is the best view for questions like:

  • Which function calls this function?
  • Which internal helper does this method actually reach?
  • Which Base or package call sites are overload-related?
  • What changes if I narrow to one path or one search term?

Method view is usually where you end up when debugging one concrete behavior.

File View​

Use file view when you want a broad structural picture without losing all call information.

It is useful for questions like:

  • Which files talk to which other files?
  • Which files become central after projection?
  • Are calls mostly staying inside one file, or crossing file boundaries?
  • What happens to the graph if I scope to src/** or exclude a test area?

File view is often the fastest way to get orientation before drilling into methods.

Module View​

Use module view when you want the architectural story rather than the implementation story.

It is useful for questions like:

  • Which modules depend on which other modules?
  • Are cross-module calls flowing where you expect?
  • Which package or stdlib boundaries are crossed most often?
  • Does one module act like a hub or leak internal behavior everywhere?

Module view is especially helpful for package-level review and boundary discussion.

How the Same Snapshot Changes Across Layers​

The same method-level snapshot can look very different after projection:

  • method view preserves individual definitions and call sites
  • file view aggregates those calls to file endpoints
  • module view aggregates further to module endpoints and projected external module nodes

This is why a graph that looks noisy at method level can become very readable at file or module level.

Practical Workflow​

A good default workflow is:

  1. Start in module or file view to understand broad structure.
  2. Narrow with search or path scope.
  3. Switch to method view once you know which area deserves detailed call inspection.
  4. Turn on reachability when you want one bounded story rather than the whole visible graph.
Projection, not recomputation

Switching from method to file or module view does not rerun analysis. It projects and aggregates the same snapshot differently.