How to create a killer call graph for impact analysis

Sometimes you really want to cut through a code-base to discover all the functions that can get called in response to a specific function being invoked, with all the other code removed from the picture.

Or you might be coming at it bottom up – when you change a particular function, what is the subset of the code-base that can be affected? Or you might even want to ask the question from both ends – what are all the code items that could get called (or impacted) between 2 specific functions?

(Updated to reflect current Structure101 UI changes, plus video added at the end).

Here are the steps to get you that diagram.

1. Download and install the free trial of Structure101 Studio.
2. Start Structure101 Studio, file/new, and enter the minimal set of information. Mostly you are just pointing the wizard at your byte-code. Just make sure you set the “granularity” option to be “detailed”. When you have created the project you will see something like this (this is a Maven project (actually THE Maven code-base as it happens)):

   

   This is an LSM of your code-base, where as far as possible dependencies flow downward.

3. Assume you want a call tree starting at a function called getDownstreamProjects in a class called DefaultProjectDependencyGraph in the maven-core project. Drill down to this function by double-clicking on the relevant parent items:

   

4. Right click on the starting function, tag, used by selected, indirectly

   

5. This causes a subset of the model to be tagged with a blue dot. You can now filter the model so that only the tagged items are included by using the “filter in (isolate) tagged items” button on then main toolbar:

   

   Which gives you something like this:

   

   Which is a heavily filtered LSM model – notice there are now just 3 POM’s left, and if you drill into these, each contains just a subset of the packages and classes that are actually in the project. Drilling down in each of the POMs/packages/classes is feasible if there is not too much in the filtered LSM and gives something like this:

   

6. Now untag everything (just for tidiness really) using the relevant button on the main toolbar:
   
7. Select the class slice from the LSM window toolbar:
   
   This removes all the POM’s, Jars, and packages from the LSM, leaving just classes. If you expand each class (by double-clicking) you end up with something like this:

   

   Remember that you are only seeing code that is in the dependency closure of getDownstreamProjects, so for instance there are methods and fields inside those classes that are not shown. The 2 interfaces and 1 class are not expanded because they contain no child items – that is they contain no methods or fields that are indirectly used by getDownstreamProjects – and so are not expandable. If you’re not seeing all the dependencies, but want to see them, click the “show all dependencies button”

   

   (default is to show only dependencies on selected items)

8. You use the same principle to work upwards, to filter on items that may be impacted by a specific item. For example if you want to show only paths that start at getDownstreamProjects (the current filter) and end at Parent::groupId, then select groupId, tag/uses selected/indirectly, filter in tagged items, which gives this further reduced LSM:

   

9. You can add back some structural context by selecting the “leaf package” slice (same menu as the “outer class slice” earlier on):
   
   Which gives this (you might have to expand through the packages by double clicking on each):

   

   Or switch off slicing altogether (deselect the slice button) to show the complete paths of the subset of items:

   

That’s it!

Here’s a short (silent) video that shows the screen as I went through these steps: