I am still playing with the City Model plugin for Sonar made by eXcentia.

For those who missed the previous episodes, you can find them here: City Model, City Model – New release, The ABC metric.

This plugin is really fun. And everyone finds fantastic a visual representation of the code in the form of a city. Going to the essential is important when you regularly assess the quality of applications.

So I thought to a few simple but common cases, where its use will prove invaluable. This will also give me the opportunity to demonstrate how easy it is to set up.

Critical City

A customer asks me an assessment of two applications. I dig a bit to know more precisely the ‘why’ of this audit. There may be several reasons, and I need to know a little more in order to accurately answer his request.

For example: he wants to outsource these two quite old applications, and before making a call for tenders, he would like to know what is their quality level. It’s actually a good idea, which will allow him to better judge the offers that he will be presented and precise maintenance costs. Currently, many providers are willing to do anything to get a contract. Estimate the technical debt on these applications will allow him to reject ‘low cost’, unrealistic offers.

Another case: the head of a development center is asked to take in charge the maintenance of an application. A rather complex one, at first sight: hundreds of thousands of lines of code, .NET proprietary frameworks, no documentation, etc. Enough to be a little bit suspicious. He would like to get some visibility on the quality of this application and the effort to be done before accepting. Or to get some information and good reasons to justify a refusal.

In fact, the customer whom I speak had some problems with one of these ‘low cost’ providers who develop these two applications. Delays, budgets exceeded, many bugs and unhappy users, some crisis situations, the image of the IT diminished … In fact, he is looking for some reasons to explain to his provider he no longer wants him.

Thus, I know how to go to the essential. Critical violations. Show him some good old critical bugs.

I set a Sonar code analysis from Jenkins. Very simple: Sonar – Jenkins plugin. The analysis was quickly done.

Then, I launched my favorite Sonar dashboard, as an Admin :

I entered into the configuration page of the widgets and I added a City Model Top widget of eXcentia.

Then, I changed the default values with the following parameters:

• title : Blocker
• topListLength : 5. I want to see the 5 most important ‘Blocker’ violations’.
• formula : {blocker_violations}.

In the ‘formula’ field, the Sonar metric corresponding to the highest violations, those that present as most risk for the users. Those that demonstrate that the outsourcer is producing code of the worst possible quality.

Then I add the widget City Model and change its settings.
The first field ‘heightExp’ contains a formula to define the height of each building depending on the size of each class, expressed in number of lines of code (LOC).

This measure uses a logarithmic function to avoid this size to grow too fast and therefore have a difference that would cause some ‘skyscrapers’ to be out of the visual field and other buildings to appear too tiny.

I will modify this formula for a different metric: the number of ‘violations’ of good practices, that is to say the number of defects encountered in the code.

Math.pow(Math.E – 0.25, Math.log({violations}))

The other parameters are:

• title : Blocker
• colorExp : num2col({blocker_violations}, 0, 1).
• widthExp : {functions}.

I want the buildings representing java classes to be displayed in red when there exists at least one critical ‘Blocker’ violation. So the formula ‘colorExp’ admits a very narrow range of values​​: green for 0 ‘blocker’, red when there is at least 1 blocking defect, measured by the metric {blocker_violations}.

The width of each building will be calculated according to the number of methods with the metric {functions}.

Save the settings. Here is what looks like my ‘critical City’:

Remember that you can zoom in the representation and rotate it horizontally or vertically, which will allow to identify more ‘Blocker’ classes.

This large green tower on the right has many defects but none critical. Other classes, even with a larger number of methods, have at least one blocking violation.

It is imperative to correct these defects before the application goes to test phase or, a fortiori, is installed in a production environment.

Navigating within the 3D modelization, one can encounter classes that would otherwise be undetectable due to their small size, in number of lines of code or methods or complexity, but which nevertheless have a blocking bug.

 

We can see in the lower left corner three small classes with only two methods and at least a blocking defect.

Now we also want to identify classes with a high number of critical or major defects. Here are the rules I agreed with the client:

1. One class is red if it has at least one ‘Blocker’ violation
2. One class is red if it has at least 4 ‘Critical’ violations. Otherwise, its color will go gradually from green to red depending on a scale of 1 to 4 of these violations.
3. Otherwise, the color of the class will be defined according to the number of ‘Major’ defects on a scale of 1 to 100.

If I put these three rules on a scale of 1 to 100:

• A blocking violation = 100.
• 4 critical violations = 100, 3 critical violations = 75, 2 critical violations = 50 et 1 critical violation = 25.
• Major violations are measured without multiplicative factor.

And final rule, the color of the building will be defined according to the highest of these values​​. For example:

• A class with 30 major violations without blocking or critical violation will have a color (from green to red) equal to 30 on a scale of 1 to 100.
• A class with 2 critical violations without blocking or major violation will have a color equal to 50 or 2 violations x 25.
• A class with 2 critical violations and 30 major violations will be worth 50 (the highest of the two values​​).
• A class with 2 critical violations and 60 major violations will be worth 60.

And here the formula corresponding to these rules:

num2col(Math.max(({blocker_violations}*100), ({critical_violations}*25), {major_violations}), 0, 100)

And the result:

Some classes with ‘Blockers’ also have a high number of major defects.

Conclusion

If you are an outsourcer, I think you could take advantage of these plugins. For example, let’s imagine you answer a call for tenders:

• Arrange a meeting with your potential customer and ask him to prepare some code extraction from the application that he wishes to outsource, if possible with the most defects.
• Analyze this code live during the meeting and show him the results. You can play with the settings according to the ‘top 10′ of each category of violations or whether you want a city more or less ‘red’.
• You can estimate with the customer the effort of correction of these defects or propose a refactoring of these classes.
• You can ask the client how this extraction is representative of the whole code and then assess the overall effort of the maintenance operation.

Your customer will certainly be impressed. Moreover, the measurements obtained are a basis of objective information that avoid the typical ‘customer-provider‘ confrontation in favor of a more constructive and realistic dialogue. Your customer will remember it when choosing the provider to whom it will entrust its applications.

Another example, use these plugins as part of a Quality Gate:

• Scan regularly your code with these plugins.
• Correct immediately any red class.
• Perform a final analysis before delivering a new version of the application or its modules and show the Sonar dashboard with the corresponding city to your customer.
• You can afford a few major flaws im case of emergency permits, provided that you agree to correct them later.

In any case, I recommend that you use these plugins for Sonar before your customer discovers them. Or that someone shows him.