City Model

I got a nice Christmas gift.
I love it.

This is a Sonar plugin that has been developed by eXcentia, a spanish company located in the beautiful city of Valencia, that you already know if you are interested in sport events like America’s cup, Formula 1 or Moto GP racings and, last but not least, is also famously renowned for its … paella.

This Sonar extension, based on WebGL, is part of eXcentia’s framework QAlitaX. It provides a 3D visual representation of an application, using Sonar metrics to model it as a city. You can find it here on eXcentia web site.

Currently, it is available for Java source code, and here is an example from this same page, that perfectly describes how it works:

  • Packages are represented as a district.
  • Classes are represented as a building.

For each class:

  • The height of the building is the number of lines of the class.
  • The width of the building is the number of the methods of the class.
  • The colour of the building is the complexity.

Allright. Now, this is not only pretty and fun, this is also very useful.

Usually, when you have to make an assessment on an application, you will not have much information about it. Not that your customer does not want to provide you data, but because most of the times he cannot – why do you think he wants an assessment?

So the first thing you want to know about it is: what kind of beast are you facing? Is it a big huge monster application? Is it some tricky vicious bag of code with a lot of different complex tiny pieces? What you could do is to qualify the delivery, list all the files and take some notes like:

  • How much folders: gives an idea of the number of packages.
  • How much files, and which folders have the highest numbers, in order to identify as soon as possible the packages with a lot of classes and functionalities.

Now, I can get very easily these informations and more, without any pre-analysis investigation and, s’il vous plaît, as a 3D representation. Let’s take an example where you just have received code and no documentation.

Here is an application with 3 main folders: common, client and server. I just analyzed the first one, and instead of browsing directories, I point on any ‘district’ to get an idea of how many packages can be found into this folder, and how many classes into each package. In this example, we can see one package with an unique class that looks small and not complex, which Sonar confirms: only 5 methods in few lines of code and almost no complexity. I can also point to some unusual component like this one with a lot of setters and getters in several hundreds lines of code and no complexity. A component with a big data structure, easy to read, easy to maintain. QA team: test only values.
The big tower behind: lot of LOCs, another whole lot of a structure of data and accessors, but also complexity and… some critical and major defects. This one will go directly into action plan: 2 critical defects that could impact security, a lot of private fields to be replaced by constants, and some methods to be splitted into several ones in order to reduce complexity and improve readability and maintainability.

 

You think this one was a monster? Now, look at that. I have been adding the ‘client’ folder to the analysis and this is not exactly LittleTown.

See (on the left) how our first ‘common’ package looks small now.

 

 

 

An upper view helps me to get a look at the internal structure, the number and dimensions of classes and identify some components to investigate later.

Did I forget to mention that you can rotate the image in any direction?

 

And now, the whole enchilada with all the three parts of the application.

We finally added the ‘server’ directory to our analysis and now we have the full picture.

You can visually guess where you should investigate, no?

This last district bigger, higher, heavier.

 

And we can quickly spot some interesting classes.

The big red tower is the logical component of this thin green arrow which is its form. I am curious to know what functional entity is hiding behind.

Well, having a look at the source code into Sonar, this is the component representing the final user, around 8 000 lines of code and, look at that:

  • Most complex: more than 1 200 points of Cyclomatic Complexity.
  • With the most duplicated code.
  • And the most violations, including 4 blockers.

Yes, we got a champ.

The City Model plugin is not only really fun to play with, it is also extremely useful. Sonar takes around 10 mn to analyze the 150 kLOC and 500 classes of this Extranet application. Really quick.

Instead of having a couple of hours browsing through folders and taking notes, I go directly into incremental analysis and will conduct my exploration into a 3D representation of the source code.

I can spot immediately the different parts to investigate, the density of each package, the granularity of the components, which ones are more particularly interesting to verify. Sure, I will go into defects and a more precise evaluation later.

Now the City Model plugin gives me a very useful overview of the application and allow me to gain time and precision with a much more efficient pre-assessment investigation.

Very good job eXcentia. Very nice gift.

This post is also available in Leer este articulo en castellano and Lire cet article en français.

This entry was posted in Sonar 360 on by .

About Jean-Pierre FAYOLLE

Jean-Pierre Fayolle is the founder, manager and lead author of Qualilogy, blog about Application Quality, Cloud and Virtualization, and Solopreneurs. With a long experience as Technical Manager of different software vendors or services companies, Jean-Pierre is a recognized expert in implementating software platforms and architectures for big international companies.