Visualize your code in KDevelop

Who of us hasn’t ever got lost when doing maintenance and evolution activities in highly complex software with hundreds of thousands of source code lines ? So, this is the first update on my GSoC project about static code visualization (in contrast with dynamic visualization – as in KCachegrind – and evolution visualization – for repository analysis) in KDevelop.

As I’ve mentioned before, the goal is to implement two well-known static visualization paradigms: control flow graphs and polymetric visualization. Control flow graphs should provide a direct, interactive and configurable visualization of control flow between functions, classes, and modules, whereas polymetric visualization aims at representing software metrics as easily assimilated visual pictograms. We think these features can enhance program comprehension and set the stage for advanced visualization mechanisms, such as architecture discovery and requirements tracking.

Cutting straight to the chase: in KDevelop, control flow graphs should visually represent DU-chain traversals from the function definition that contains the cursor and enable direct source code navigation and filtering facilities.

DU-chain traversals have been modelled as graphs by using Graphviz. The Graphviz’s algorithms for graph layout are used for spatial positioning of graph nodes and then the control flow graph is visualized in the KGraphViewer’s kpart.

This was my first attempt, yet limited to just one-level (direct) function call:

This time, with kpart integrated in KDevelop tool view and some configuration in Graphviz node attributes:

With a little bit of more work on my DUChainControlFlow class, we have multi-level control flow graphs from the function definition containing the cursor until the first definition-unavailable function (I know, this can be quite time-consuming for large projects. Keep reading :)).

By integrating some KGraphViewer’s kpart features with my KDevelop tool view we are able to zooming in/out/best-fit the control flow graph. Also graph nodes are colored according to its class/namespace.

My ultimate goal is to implement some features for DU-chain traversal configuration. Certainly we will have some (but not all :)) of the following:

• Definition of depth limit: by specifying the number of recursive analysis of function calls we will be able to constrain the visualization to a managed scope and have a first overview of control flow without have to wait for a depth-complete DU-chain traversal;
• DU-chain traversal filtering: it should be interesting to have some features for limiting the control flow graph generation to a specific class, module, directory, and/or project(s);
• Select control block granularity: we should be able to generate control flow graphs depicting control flow between functions, classes, and modules;
• Individual expansion of graph nodes: this will allow the user to get into the details of specific graph branches;
• Mapping of metrics to visual attributes: in a more sophisticated approach, software metrics such as function size, cyclomatic complexity etc could be mapped to visual attributes like node width, height, and color or even influence somehow the control flow graph layouting;
• Integration with debugging and profiling tools.

In the second part of my GSoC project I will implement the polymetric visualization, as presented here:

And, if time permits, what about class dependency visualization ?

Suggestions are welcome !!!

See you in the next GSoC update …