Package Level
The view at this level shows the numbers of Classes, Methods and Statements in the package. It also shows the Total and Average (per method) Cyclomatic complexity, the Total Halstead Effort and the two forms of the maintainability index. In addition there are five other metrics -

• InstabilityThis is an estimate of how susceptible the package is to change. It's values will always lie in the range 0 (not susceptible to change) to 1 (very susceptible to change). Values closer to zero are preferable. It is calculated by dividing FanOut by fanIn+FanOut for the package (see below).
• Fan In or Afferent Coupling (Ca)This is the number of packages that contain references to this pacakge. Only packages within the System are included in the calculation.
• Fan Out or Afferent Coupling (Ce)This is the number of packages that this package refers to. Only packages within the System are included in the calculation.
• AbstractnessThis indicates how abstract the package is. Its values range from 0 (completely concrete) to 1 (completely abstract). The more concrete a package is the more likely it is to change and therefore to have an effect on the packages that use it. It is calculated as the ratio of abstract and interface classes in the package to the total number of all classes in the package.
• DistanceThis measures the balance of a particular package between abstraction and instability. The term distance comes from the concept of a line being drawn between two points - the first representing minimum abstractness and maximum instability and the second representing maximum abstractness and minimum instability. The more balanced a package is the closer the value of the Distance metric is to zero.

System Level
The System is defined as all the Java classes that you selected for analysis by JHawk. The view at this level shows the numbers of Packages, Classes, Methods and Statements in the system. It also shows the Total and Average (per method) Cyclomatic complexity, the Total Halstead Effort and the two forms of the maintainability index.

Other Aspects
Metrics not only provide us with an insight into the quality of our code - some of them can give us clues about other aspects of our code. Performance and Maintenance are two of the aspects that we can consider.

Analysing for performance
In general problems with performance arise within methods that have loops of one sort or another or methods that are called from within these loops. An inefficency within a loop is magnified by the number of times that that loop is called. The sorts of inefficiency that one is looking for is instantiation or casting of data within loops that could be done outside the loop e.g. -

for (int i=0;i<max;i++) {
  int x= ((Integer) multiplier).intValue() * item[i];
}

this could safely be replaced by -

int x=0;
int multInt = ((Integer) multiplier).intValue();
for (int i=0;i<max;i++) {
  x= multInt * item[i];
}

Obviously searching through every method in a large system to find this kind of inefficiency is impracticable. JHawk can help you by re-ordering the results to order the methods by those containing the most loops or casts. If you have a source code license you can also modify the calculatedComplexity method to return a higher value for those methods that contain casts, loops and/or variable instantiations.

Analyzing for maintenance
The greatest influence on the maintainability of code is generally accepted to be the complexity of the code being maintained. Most complexity can be isolated at the method level but in some cases a combination of acceptably complex methods can create an overly complex class. The primary measures that can capture this are TCC, CBO, LCOM, RFC and UWCS.