Together/J
A Review, Part Three

Metrics

A new feature for TJ3 is the ability to produce a wide variety of metrics for a model. For a new feature, TJ3 provides an impressive implementation. The most noticeable omission, however, is the ability to export the metrics produced in order to import them into an external tool, such as a spreadsheet. Given TJ3's overall excellent integration with other tools, we would expect this feature to be forthcoming because of its obvious utility.

To test the metrics feature we again used the CashSales model as an example. To produce the metrics you right click on a class diagram and select Quality Assurance / Metrics. This presents you with a dialog box for selecting the desired profile of metrics as seen in the following screenshot.

Although you could simply produce a report including all metrics (the default), this is not really productive since the array of available metrics is too broad, and you may actually find some to be rather specialized. Fortunately, TJ3's selection dialog provides concisely worded summaries of each metric, as well as suggestions regarding how to apply the metric. You will eventually want to learn the acronyms given for each metric since they are used as column headings on the metric report. Another omission we did notice is the inability to save a profile of metrics for later reuse. This is essential if you are managing a project and want to monitor the same set of metrics over the course of the development cycle.

Our selection of metrics was based on taking the perspective of a project manager looking to assess the amount of work to be done to implement each class, as well as the perspective of a system architect looking to determine the overall complexity of the model. Here's the list of metrics that we included in our profile:

For the result of applying this profile of metrics to the CashSales model, see the screenshot of the report produced by TJ3.

As seen in the screenshot, TJ3 produces a tabular report with metrics in the X-axis and classes and packages in the Y-axis. The actual production of the metrics is rather quick. Based on this speed, we are assuming that TJ3 is able to produce these metrics based on information it stores internally about the model. We believe this is an indicator of the richness of TJ3's internal meta-model.

So what can we deduce from the results? We chose to sort by NOO (Number of Operations) because this is a reasonable, first-order approximation of the complexity of a class. From the table it can be seen that the ProblemDomain package as a whole contains 67 operations. These operations are divided over the package's classes, as seen in the succeeding lines. The class CashSale has the most operations with 24; ProductDesc and ProductPrice follow with 17 and 16 respectively. So very quickly we get to see where the complexity lies.

Next we use LOC (Lines of Code) to get an idea of how much code is actually inside of all those operations. Lines of code gives a next-order approximation of how much code you have to sift through in order to understand what's going on in the classes. We can see that CashSale has proportionately a lot more code for the number of operations it supports. However, looking at CR (Ratio of Comments to Total Lines) we can see that CashSale appears to have proportionately less comments than ProductDesc and ProductPrice. This could indicate that we might have to spend more time understanding the actual code in CashSale to figure out what's going on, rather than in the other classes, where we might be able to rely more on the comments.

Note that we are taking advantage of the fact that this model is backed by fully-developed code in order to understand its complexity. Other measures of complexity would be employed if we were still in the analysis and design phases. One such interesting measure is CBO (Coupling Between Objects). As stated in TJ3's description of CBO, this metric "Counts the number of reference types that are used in field declarations, formal parameters, return types, throws declarations and local variables, and types from which field and method selections are made… The larger the number of couples, the higher the sensitivity to changes in other parts of the design, and therefore maintenance is more difficult." This measure may be calculated during the design phase, prior to writing any actual code by looking at the types used for attributes and in the definition of operations (return types, parameter types).

From our example we can see that CashSale has a measure of 9 for coupling, which means that it has a fairly high level of coupling. One type of deduction that might be made on further inspection is that this class is very subject to being affected by changes in these other classes. This is just a sample deduction and may in actuality not be true if most of the dependancies are in stable libraries (i.e. BigDecimal, Vector). You may also look at the measure NOIS (Number of Import Statements) as a means for assessing the degree of coupling. This measure is derived from the Java 'import' statement and in our example is 6 for CashSale. By looking at the class diagram, we see that CashSale is directly coupled with just the CashSaleDetail class and the interface IMakeCashSale. Examinining the code confirms that 6 of the 9 couplings are with classes from stable JDK libraries, leaving 3 couplings with elements in the model itself, the 3rd being with SaleDM, a data model class.

Finally, looking at WMPC1 (Weighted Methods per Class), we get a truer indication of the complexity of a class by summing the cyclomatic complexity of all the operations. Cyclomatic complexity is a closer measure of complexity because it looks at a flowgraph for each operation and counts the number of paths through such statements as 'if', 'for' and 'while' loops.

If you prefer to visualize metrics, TJ3 provides a simplistic graphing capability. To produce a graph you right click on a column heading for a metric and select the Bar Graph option. We've included a screenshot for the CBO (Coupling Between Objects) metric to give you an idea what the graphs look like. Included in the screenshots is a curious looking graph called a Kiviat Graph. When we figure it out, we'll let you know!

Ideally it would be nice if all the metrics were exported to a spreadsheet and the graphs were automatically created for each measure captured. Then all the results could be saved together and printed out as a packet.

Another important integration that we would expect to see in the future is the ability for TJ3 to share metrics with project management tools. This would allow a manager to identify areas which need greater resources and to quickly begin assigning resources to these areas.

For an excellent book that explains how to use metrics to manage object-oriented projects, see Mark Lorenz's Object Oriented Software Metrics.

For a good example of a project management tool based on OO metrics, see Optimize from The Object Factory.

Snapshot:

• Supports a wide range of O-O metrics.
• Descriptions of metrics are very helpful.
• Provides simple graphing capability.



• Doesn't provide ability to save a profile of selected metrics.
• Should provide ability to export metrics for import to other tools.

Screenshots:

• Select metrics to generate.
• Metrics for the CashSales model.
• Graph of CBO (Coupling Between Objects) metric.
• Kiviat Graph of Metrics