Setting up Sonargraph on your Project

Over the years we implemented many different methods to set up Sonargraph for your project. Some of them are now quite outdated and are only kept in the tool for compatibility reasons. This article is meant to help you with your initial setup and chose the most effective method for your particular circumstances. There is one section for each language supported by Sonargraph.

General Recommendations

Sonargraph maintains a folder for each software system, that contains a description of your project, the locations of source folders (and class folders for Java), your architecture model and all other parts of a Sonargraph quality model. We call this folder the Sonargraph system folder. It only contains text files (mostly XML) and should ideally be placed in the root directory of your VCS (version control system) repository. You also should add this folder to your VCS, since the Sonargraph model will evolve together with your software system. This will allow you to share one Sonargraph model with all the developers working on your project.

Each Sonargraph software system contains at least one module. Modules usually correspond to the modules or sub-projects in your IDE.

How to initially create this folder for your project is the subject of this article. The folder should have the name of your software system and always ends with ‘.sonargraph’.

Read More

Using ccspy for C/C++ Project Setup

Analyzing C/C++ projects with Sonargraph is always a bit more difficult due to the huge variety of different compilers and environments. We recently added a new import wizard that should simplify the process.

For a successful analysis of a C/C++ projects Sonargraph must be able to emulate the compiler you are using and also needs to know which source files are part of the project and the compiler options used for each source file, mostly the -I options for include directories and the -D options which influence conditional compilation.

The first part is solved by a so called “compiler definition”. Sonargraph comes with predefined compiler definitions depending on your platform. If your compiler is not among them you can always create a new compiler definition (menu File / New / Configuration). You can also manage your compiler definitions in the Sonargraph preferences. The main job of a compiler definition is to define the location of implicit include directories (for standard headers like stdio.h) and to define all predefined macros of your compiler platform.

Read More

Recently Added Usability Improvements

During the last months we released a couple of major features in Sonargraph that allowed easier interaction like the ‘Architectural View’ and improved the interpretation of results like the ‘System Diff’, ‘Quality Gates’ or ‘Issue Ranking’.  We have described the power of these features in individual blog posts.

Some implemented improvements are less obvious, but nevertheless can have a big impact while working with Sonargraph.

This blog post highlights four hidden gems that the casual Sonargraph user might not know about:

  1. Improved issue to resolution matching
  2. Filtering in tables
  3. Visualizing cycle croups in Exploration view
  4. Passing selection between Sonargraph and Eclipse IDE
Read More

Identify the Most Relevant Issues to Fix

Using Sonargraph to analyse a large code base usually reveals a lot of issues. The “System Diff” helps to keep the quality level by highlighting new and worsened issues as described in a previous blog post. But up to now there has been no recommendation about which of the already existing issues should be fixed first.
The new “Ranking” view available in Sonargraph 11.5 does exactly that and this blog post describes how it works.

Read More

Efficiently Track the Quality of a Code Base

Sonargraph offers a wide range of checks for different aspects of software quality: Architecture, metric thresholds, cyclic dependencies, duplicate code, etc.
When Sonargraph gets introduced for software projects that have been developed a couple of years, chances are high that hundred’s of issues are reported. But getting flooded with issues and sifting through them at regular intervals is neither efficient nor really helpful. Instead, you want to get a quick overview whether or not the quality is going into the right direction.

And this is where quality gates come into the game: they allow focussing on the information important to you.

This blog post details how this functionality is implemented in Sonargraph.

Read More

Implementing Additional Metrics Using the Sonargraph Script API

With the Sonargraph 9.10 release, we added support for two additional OO-metrics “Depth of Inheritance” and “Number of Children” as described by Chidamber and Kemerer. Sonargraph provides a powerful Script API that allows implementing new metrics as Groovy scripts and I needed surprisingly little amount of code for the implementation. This blog post will explain the scripts’ code and the used Sonargraph Script API in detail.

Read More

Finding Distributed Packages/Namespaces with the Sonargraph Scripting Engine

Today I will show how to make use of a very powerful, yet underutilized capability of Sonargraph-Architect. By writing simple Groovy scripts you are able to create your own code checkers or define your own metrics. Many of our most useful scripts are just about 50 lines of code and therefore not a big effort to create. As an example we will develop a script that finds packages (Java) or name spaces (C#, C++) that occur in more than one module.

The scripting engine of Sonargraph is based on our scripting API. Most scripts are based on the visitor pattern. Using this pattern a script can traverse specific elements of Sonargraph’s software system model, which is basically a very big tree data structure. At the root there is the software system node, which is accessible by a globally available instance of class CoreAccess, called “coreAccess”. This specific instance is language agnostic, i.e. it can be used for scripts that support all programming languages supported by Sonargraph. When creating a script you decide wether it will be language specific or language agnostic. Language specific scripts have access to more detailed language specific data and will use different root objects like “javaAccess” or “csharpAccess”.
Read More

Managing the “not so visible” dependencies in your Java code

In modern object-oriented languages, inheritance is massively used with its pros and cons. Moreover, languages such as Java offer simple inheritance but also allow classes to implement an arbitrary number of interfaces. With inheritance and interface implementation comes one additional ingredient that is naturally expected: method overriding. When a software evolves, you end up with hierarchies involving multiple classes and interfaces with methods definitions and implementations and then, the classes that are part of this hierarchy will be used by some other classes. In this context, it is difficult if not impossible to have control by hand over the usages or overriding classes of methods we would be interested in. Hereafter, I will present this problem in more detail with a very concrete and yet complex enough example, as well as some tools that can empower software architects and developers to gain more control over their code. Read More