The quality of the final product in an IT project greatly depends on the quality of created source code. Low-quality code is prone to bugs and hard to understand, while its analysis and development is difficult and time-consuming. In this article, Rados³aw presents Hammurapi tool and its the most relevant feature.

The quality of the final product in an IT project greatly depends on the quality of created source code. Low-quality code is prone to bugs and hard to understand, while its analysis and development is difficult and time-consuming. All these drawbacks translate directly into time required to construct an IT system and costs generated during the development process. What is more, according to T. Gilb and D. Graham - authors of the book Software Inspection - the cost of detecting and fixing a bug at the time of coding is several to several hundred times lower than after the implementation phase has been completed [1].

Having said all this, how can we improve quality of our source code? A frequently recommended solution here is to introduce formal code analysis, meaning that the written code goes through a stage of verification, in which another member of the project analyses its quality and reports possible issues or suggestions of improvements. Michael Fagan - the "father" of inspection - believes that applying this approach it is possible to detect as much as 80% of bugs in the software [2]. However, few software development companies decide to introduce inspection as a constant component of the development process; the main reasons here are an increase of production time and additional cost associated with "non-productive" engagement of programmers. What is more, an increase of quality of the source code is not guaranteed - it depends on human factors, such as knowledge, experience and diligence of the inspector. As a result, a question arises: how to organise inspection of code so that we can both take advantage of possibilities it offers and minimise the time required by its preparation and execution? Good programming practises, rules of compliance with standards and coding conventions or detection of common programming bugs can be implemented in a validating program, thus leading us to the concept of automated inspection of code.

As it turns out, we have at our disposal several really well-performing programs for automated inspection of code. One of such programs is jest Hammurapi, whose usage and capabilities as applied to a practical example I would like to present in this article. We shall also ponder how to efficiently deploy this tool on the development process.

Hammurapi

The name Hammurapi comes from a Babylonian king - also known as Hammurabi - who made himself famous as a creator of one of the first codes, the aim of which was to unify and systematise existing law.

The present-day Hammurapi is a tool for execution of automated inspection of Java program code. Following the example of 282 rules of Hammurabi's code, we are offered over 120 Java classes, the so-called inspectors, which can, at three levels (source code, packages, repository of Java files), state whether the analysed source code contains violations of commonly accepted standards of coding.

How Does Hammurapi Work?

The tool begins its operation by building a repository consisting of processed Java source files. In the next step, this code is - in the form of logical structures - made available to inspector, where it is subject to their analyses.

The main functionality of Hammurapi is based on three components: Inspectors, Listeners and Waivers.

Inspectors

Within its field of responsibility during the code analysis process, an inspector reports:

• Violations - when code is found which doesn't adhere to standards,

• Warnings - when there are problems analysing the code,

• Annotations - additional information included in the report, e.g. the number of licences used within the project,

• Metrics - values calculated using defined rules, representing properties of code - e.g. its complexity, degree of documenting etc.…

Additionally, an inspector makes it possible to filter analysed elements through other inspectors. This lets us define which e.g. methods, classes or packages shouldn't be analysed at all.

A list of Hammurapi's built-in inspectors (along with their descriptions, signatures and severities) can be found at http://www.hammurapi.biz/hammurapi-biz/ef/xmenu/products/hammurapi/inspectors/java/basic/inspectors.html. An example description of an inspector is shown in Figure 1.

Figure 1. An example description of the "Empty catch block" inspector

Definition and configuration of inspectors takes place in descriptors - XML files which are read in before the analysis has started. It is possible here to use several files for this purpose, each of which can be available at a specified path or URL. We will practise definition of inspectors further in the article.

Listeners

Notifications from inspectors are passed to defined Listener objects, which then process them - e.g. for reporting purposes. Hammurapi comes with an Output Listener which can generate reports in html or xml format. It is possible to write additional Listeners.

Waivers

A very important part of Hammurapi's architecture are the Waivers. A Waiver is responsible for waiving certain or all violations reported by an inspector. At the same time, it can serve two functions:

• allow the particular violation to exist indefinitely, when it's unjustified for instance,

  or

• let that violation appear for the time being, thus giving one time to correct the problem

Violations are reported, that means we have information about when and why a violation was waived. Definition of waivers will be presented further into the article.

Connections before the elements discussed here are illustrated by Diagram 1.

Diagram 1. The code analysis process in Hammurapi

sum:

0 €

» Library of the Month
» Workshop
» Software Engineering
» Programming Tools
» Interview
» High quality and
secure programming
» Reverse Engineering
» Portable GUI
» Artificial intelligence