jump to navigation

GSoC wrap up: Static Code Visualization in KDevelop August 21, 2009

Posted by Sandro Andrade in gsoc2009, planetkde-sandroandrade.

Ok, it’s time for a concluding post about three exciting months working in KDevelop project, devoted to the implementation of software visualization features that leverage program comprehension and software artifacts navigability. It’s an amazing subject field in which several different visual approaches have been proposed not merely as pretty pictures but mainly as a powerful mechanism for developer interaction with and understanding of software aspects related to static structure, run-time behaviour, and evolution of software systems.

It was a quite fruitful time for meeting people, enhancing hacking skills, and narrowing commitment to KDE and KDevelop communities. Me and other guys involved in KDE community in Brazil (Helio, Mauricio, Artur, Tomaz, Boaglio and others) are doing our best to enlarge the KDE presence in events such as FISL (International Forum on Free Software) and Latinoware (Latin-American Conference on Free Software) – by the way, we are drawing up a really amazing KDE program for Latinoware 2009.

But … going back to GSoC :), KDevelop is now endowed with a (to some extent) functional plugin for control flow graph generation, providing a set of configurable parameters for control flow granularity, clustered layouts, source code navigation, and graph exporting.

Let’s have a full list of implemented features:

  • Control flow visualization between methods, classes, and namespaces.
  • Navigation Control Flow Graph <-> Code Editor for nodes representing methods, classes, and namespaces (with graph locking option).
  • Integration Class Browser -> Control Flow Graph.
  • Clustering by class and/or namespace and/or project.
  • Support of multiple control flow graphs (toolviews) with optimized management.
  • Optional adjustment of maximum graph depth.
  • Drawing of incoming arcs (uses of a given method/class/namespace).
  • Use of folder names for classes aren’t declared under any namespace (as an alternative to “Global Namespace”).
  • Visualization of uses that make an edge, including navigation to Code Editor.
  • Optional use of short (unqualified) names for clustered graphs.
  • Menu extensions in Code Editor, Class Browser, and Project Manager.
  • Graph exporting for a given method, class or whole project (supported formats: png, jpg, gif, svg, dia, fig, pdf, and dot).
  • Graph zooming in/out and bird’s eye.

This is the general view of KDevelop’s Control Flow Graph plugin:


Overview of control flow graph plugin

Now, I’ll provide you some detailed information about such functionalities.

Control Flow Visualization between Methods, Classes, and Namespaces

Depending on user’s (developer) interests different control flow levels can be used to drive the graph generation. Commonly, an initial view of high level control flow depicts modules relationship and architectural structures, followed by a detailed visualization of interactions between classes and methods.

In the implemented plugin, the control flow mode buttons allow the user to choose the current control flow granularity (between methods, classes, or namespaces).


Control flow between methods


Control flow between classes


Control flow between modules

Navigation Control Flow Graph <-> Code Editor

The control flow graph plugin is intended to be used as an alternative tool for source code navigation and for this it should be sufficiently integrated to other KDevelop tools.

By clicking on a graph node the code editor is automatically updated to the corresponding definition or declaration (if definition isn’t available). This works for nodes representing methods, classes, and namespaces and a new graph exhibiting the control flow initiated at this new definition is automatically created.

Sometimes, it’s interesting to visualize the same graph while navigating to definitions related to graph nodes. This can be accomplished by locking the current graph.

Integration Class Browser -> Control Flow Graph

One major feature in KDevelop is the full integration between tools and keep this running for control flow graphs was one of the expected deliverables. By using KDevelop’s Class Browser to navigate to a given method both code editor and control flow graph are updated.


KDevelop’s Class Browser

Clustering by Class and/or Namespace and/or Project

The implemented clustering features allow the user to group graph nodes by class, namespace, and project – with any of possible combinations. This makes the plugin suitable to discover project boundaries and find class and modules relationships.


Clustering by class


Clustering by class and namespace


Clustering by class, namespace, and project

Support of Multiple Control Flow Graphs

By using multiple control flow graphs the user can keep different views of current project and switch them as needed, for example to have a toolview showing control flow between classes and another one for control flow between namespaces.


Multiple control flow graph views

Implementation was carefully done to support multiple toolviews while yet preserving acceptable response time.

Optional Adjustment of Maximum Graph Depth

For larger projects generating such control flow graphs can be time-consuming and wouldn’t provide any useful information to developer. In the implemented plugin, one should select the desired depth of control flow graph (or even choose don’t adjust any threshold). By setting a default value of 2, the user initially visualize a more constrained method/class/namespace neighborhood and afterwards can request a broader visualization (while aware of a slower graph generation).


A two levels graph


A three levels graph


A four levels graph


A five levels graph

Drawing of Incoming Arcs

Another quite important feature for program comprehension is find the uses for a given method/class/namespace. In control flow graph plugin, user can optionally make the graph display the current uses of the method/class/namespace that initiates the graph.


Showing the uses of Professor::collectExam()

Use of Folder Names

Usually source code is organized in a way where folder names represent modules, libraries and others software artifacts. By taking into account this structure when generating control flow graphs, some important source code information can be extracted, like the dependencies to Qt modules:


Graph showing dependencies to QtGui and QtSql modules

Visualization of Uses that Make an Edge

For clustered graphs edges usually represent many control flow between methods inside a class or classes inside a namespace. By right-clicking a given arc, the plugin exhibits the uses that make the arc and allow for the navigation to the specific use in Code Editor.


Graph showing the uses of a given arc

Optional Use of Short Names for Clustered Graphs

When using clustered graphs, containers inherently indicate scope and then node names can be reduced to the unqualified method/class names.


Graph with short (unqualified) names


Graph with long (qualified) names

Menu Extensions in Code Editor, Class Browser, and Project Manager

In order to provide a posteriori analysis of static software structure control flow graphs can be exported by acessing context menu options in Code Editor, Class Browser, and Project Manager.


Class Browser extension menu with “Export Class Control Flow Graph” option


Project Manager extension menu with “Export Project Control Flow Graph” option

Graph Exporting

Thanks to excellent Graphviz features all graphs can be exported in png, jpg, gif, svg, dia, fig, pdf, and dot formats. The current graph displayed in toolview can be exported by clicking on the export button or one could select a method, class, or project in Project Manager and Class Browser and then choose “Export (class/project) control flow graph”.

By deciding to export a control flow graph for a class or the whole project, the resulting graph is the union of graphs generated for each (method/class) contained in the given (class/project).

One really enjoyable part of this cool GSoC project was the hacking of KFileDialog to provide some exporting features:



I really hope KDE 4.4 provides some more developer-friendly way for accomplish this than:

(dynamic_cast<QBoxLayout *>(mainWidget()->layout()))->insertWidget(1, widget);


Graph Zooming In/Out and Bird’s Eye

Thanks to useful features present in KGraphviewer kpart, graphs can be zoomed in/out and a bird’s eye can optionally be enabled to provide a wider visualization while keeping the focus in a specific part of the control flow graph.

So, that’s all, there is much to improve and more interesting features and visualization paradigms to implement. Certainly this is just the beginning 🙂

Many thanks to Aleix Pol, David Nolden, Gaël, and Tomaz Canabrava for the valuable support during this great GSoC time.

See you,



1. pinotree - August 21, 2009

To put a custom widget in a file dialog, you have to manually construct a KFileDialog object (ie not using one of the static methods) and pass your widget as forth (last) parameter to the (only) constructor.

Nice work overall, just hoping it doesn’t get too crowded with many classes/relationships 😉

Sandro Andrade - August 23, 2009

Hi pinotree, yes that’s true but the custom widget is inserted *after* all widgets already present in KFileDialog and it seems there is some layouting problem. IMHO, it would be nice to insert the custom widget after the list of files as presented in the plugin.

I’m working on a better mechanism to handle many classes/relationships yet.


2. stelt - August 21, 2009

Looks awesome.

Given that SVG can make images interactive, animated, and accessible/searchable do you have any ideas for that within this project?

Sandro Andrade - August 23, 2009

Hi stelt, no specific ideas for SVG, it’s just a Graphviz export alternative. Any suggestion ? 🙂

3. illissius - August 21, 2009

I must admit, when reading previous blog entries I was like “well, there’s all these graphs and they’re quite pretty, yes, but what are they _good_ for?”; but if you can navigate by them, that suddenly sounds… highly useful. Great work.

A couple of usability-related thoughts (which I know probably weren’t the focus):

– What distinguishes “use folder names” from a clustering mode? Shouldn’t it belong there as a fourth option, or am I misunderstanding what it does?

– If you have class and namespace as two out of three options for both the control flow and clustering modes, I think the same icons should be used for both. (God knows I’d have no idea what the heck those flag icons might do just by looking at them; I’d guess it was something to do with priorities.)

– “Draw incoming arcs” is awfully arcane; a better name would be something like “Also visualize users of this element” or something.

Is this going to be committed to trunk?

Sandro Andrade - August 23, 2009

Hi illissius, “use folder names” is a configurable parameter for namespace-clustered graphs. It just uses folder names (such as QtGui, QtSql, and KDE libraries folder) as container instead of “Global Namespace”. The goal is to reflect the fisical organization of code in libraries. Yes, icons must be quite reviewed … I hope to have this is trunk soon.

4. Zeke - August 21, 2009

Many thanks to the developers :3. I have a question. When this is added. How much time will it take to generate these graphs?

Sandro Andrade - August 23, 2009

Hi Zeke, the goal is to provide a constrained default visualization for which generation can be executed on the fly. For more complete graphs use should expect slower graph generation.

5. Cláudio Gil - August 21, 2009

Very impressive work. Visualizations are normally complex beasts :-). Did KDevelop infrastructure support all the needed code introspection? Nevertheless, by now, it should be quite advanced. Can we type and see the visualization change automatically?

Sandro Andrade - August 23, 2009

Hi Cláudio Gil, KDevelop’s DU-chain provides lots of information about source code structure, there was no need for DU-chain enhancements in this particular project. And yes, changes to code are immediately reflected in control flow graph.

6. Hugo Parente - August 21, 2009

Great work! But IMHO kgraphview would draw graphs not so ugly…. but ok, this is a kgraphview problem… ugly graphs.

7. MK - August 22, 2009

Great work – looking forward using this in the latest kdevelop svn (is it already commited?).

tumaix - August 23, 2009

it’s in playground now, but yes, its in the repository

8. Gaël - August 23, 2009

@Hugo: well, kgraphviewer displays what you ask it to display. More precisely, what graphviz asks to display after layouting what you give to it. No more no less.

9. online stock trading advice - January 10, 2010

Your site was extremely interesting, especially since I was searching for thoughts on this subject last Thursday.

I’m Out! 🙂

10. Rodrigo Fernandes - April 5, 2010

First of all congratulations on a grat code visualization tool. Open source needs more analysis tools like this. I am however unable to find the plugin. I’m runing trunk kdevelop (and kdevplatform) but I can’t even find it when browsing the tree. No download or checkout repository link found. Could you help ?

Sandro Andrade - April 5, 2010

Hi Rodrigo,

Plugin is yet in playground 😦 you can try it from there. I’m still doing some debug and enhancements.

11. Amrita - May 1, 2011

Thank you for sharing your work 🙂 I wanted to know if your team thought of using VCG instead of Graphviz.
Do you know if Qt supports VCG ?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: