Browsing a Project

Zooming on a specific project leads to the dashboard of the project page. 

The Dashboard

This is the entry point on each projects. It gives a synthetic view on the project. The dashboard is divided in widgets.

1. General information

Three widgets display standard metrics

Next to each measure, will appear a tendency for the measure.

When a measure appears in color, it means than a warning (orange) or error (red) threshold has been reached. Passing the mouse over the measure will give some more information on the alert.

Clicking a on any measure opens the Measures Drilldown, zooming on the measure chosen.

2. The Rules Compliance Index (RCI)

The RCI is a second-level metric calculated by Sonar. It gives a ratio between weighted violations and the number of lines of code.



Clicking on one of the severities or on the the total number of violations opens the Violations Drilldown.
To understand how the RCI is calculated, check the Rules Compliance Index section.

3. Design & Architecture

When talking about architecture the first priority is to remove cycles between packages by cutting undesired dependencies.

Then two major Object Oriented metrics (see Chidamber & Kemerer) can be used to hunt classes having for instance too many responsibilities (LCOM4).

4. The project Treemap

The Project Treemap is very similar to the Home Page - Filters Treemap. It simply displays information at the project level. The Treemap is a generic component that adapts depending on the structure of the project: modules, packages and classes.

The Treemap will show the components that are at level 1, regardless of the type. The Treemap allows to drill down into any component to get a view on the component.

6. The Events

The Events section is used to highlight events occurring during the lifetime of the project. There are two families of events :

• manual : it is possible to add manual events and to create categories of events. See the Manage events for more details
• automated : a mechanism exists in Sonar to pick automatically events and record them. This is the case for version events (picked when the version changes in the pom.xml) and for alert events that are triggered when a threshold has been reached.

Measures Drilldown

Wherever in a project, it is always possible to access the Measures Drilldown by clicking on a measure.



You then see the component structure : hierarchy is represented from left (higher) to right (lower). At the top of each list appears the component that has the most the "measure that was selected".

An optimisation mechanism is in place whereby Sonar does not display what is called "best values". Best values are for qualitative measures when there is no issue. For example 0% duplication is a best value.

By clicking on a class, this will show the source code of the class. See The resource viewer for more details. 

Violations Drilldown

Wherever in a project, it is always possible to access the Violations Drilldown through the left menu.



The top section is used to select the scope of violation : priority, category, specific rule.

The bottom section represents hierarchy from left (higher) to right (lower). At the top of each list appears the component that violates the most the scope selected.

By clicking on a class, this will show the source code of the class. See The resource viewer for more details.

Since Sonar 2.5, a new service has been added to the violations drilldown to view the violations that were created during a period. Configuration of this service is documented here. This service will only show added violations, not deleted ones.

To activate this service, pick the desired period in the drop down list "Time changes..."

To determine the creation date of a violation, during each Sonar analysis, Sonar executes the following algorithm :

• For each violation, if there was a violation on the same rule, with the same line number and with the same hash (but not necessarily with the same message) -> MATCH
• For each violation, if there was a violation on the same rule, with the same message and with the same hash (but not necessarily with the same line) -> MATCH
• For each violation, if there was a violation on the same rule, with the same message and with the same line number (but not necessarily with the same hash) -> MATCH

In any other case, the violation is a new one.

Coverage Clouds

Wherever in a project, it is always possible to access the Coverage Clouds through the left menu. This brings to a page where it is possible to choose one of two tabs :

• The top risk tab : the size represents the average complexy by method in the class. The color represents the code coverage or the Rules Compliance Index (drop down on the top right)
• The quick wins tab : the size represents the lines of code in the class. The color represents the code coverage or the Rules Compliance Index (drop down on the top right)

By clicking on a class, a third tab will open, showing the source code of the class. See The resource viewer for more details.

Hotspots

Wherever in a project, it is always possible to access the Hotspots through the left menu. This brings to a page where several widgets appear, each of them showing the top 5 of most... or top 5 of less... This is a way to get a picture of where to start from in a project.

Since Sonar 2.12, some new "Hotspots" widgets are available and can be added to any dashboard to get exactly the content of this "Hotspots" page and even more. Indeed, with the new widgets, it's possible to get the hotspots according to any metric like for instance the files with the highest number of untested branches.

Components

Wherever in a project, it is always possible to access the Components through the left menu. This brings to a page similar to the home page, where lines represent the components of level n-1

Design / DSM

The DSM (Dependency Structure Matrix) is a compact way to represent and navigate across dependencies between components. According to the navigation level, those components can be Maven modules, packages or files :

Row selection

A row can be selected by clicking on the component name :

Colors meaning

Colors are used to help visualize row dependencies at a glance :

Which means that green components depend on blue components which depends on orange components. Here is a simple example on commons collections project :

Cell selection

A cell can be selected by clicking on the number of file dependencies :

DSM sorting and cycles

Find usages for dependencies

The detail of a dependency is not available between Maven modules.

Zoom into a component to get dependencies between sub-components

Managing libraries

From a technical point of view, a software is rarely just a bunch of source code files. By reusing work of the community, any development team can benefit from very robust and mature libraries while focusing on valuable business core. So when code quality matters, dependencies on the community libraries also matters.

Here are several common use cases :

• A given version of a library shouldn't be used as this version is well known to contain critical bugs
• Need to understand which transitive dependencies can explain why a software depends on a library
• A library should not be used any more as the commercial contract has been broken with the company
• ...

Since Sonar 2.1, two new services "Libraries" and "Dependencies" allow to request Sonar in order to cover those use cases (Those services are currently available only for Java Maven projects).

Libraries of a project

Once a project has been selected, this "Libraries" service allows to easily visualize the dependency tree of the project. An optional dynamic filter is available to filter libraries by name to quickly navigate through transitive dependencies :

Here is the meaning of each icon :

Dependencies between projects and libraries

Navigating through the dependencies of a project is useful but the ability to work on all projects in order for instance to know which one depends on library "dummy" version "x.y.z" is also very valuable. The "Dependencies" service allows to do such thing :