Metrics and Visualization Lab Session

The purpose of these exercises is to stimulate discussion about the properties of a well-structured object-oriented design. This session stimulates you to pose hypotheses about the validity of the current design with respect to system evolution, and to formulate and visualize properties to support the verification of these hypotheses. Therefore, consider the tools used in this session as the providers of data required to build up an argument for a system report or action plan.

Context

You are facing a software system representing a code style checker. You hypothesize that the system can be reengineered in order to prepare the implementation of a new version of the Java language with new language constructs. This requires that Checkstyle adds additional checks, including checks for documentation such as Javadoc.

In this session, we will use metrics and visualization for two purposes:

Initial Understanding – Collecting information to make the trade-off between reusing the system and starting from scratch.
Redistributing Responsibilities – Collecting information to help in redistributing responsibilities.

(Note: OORP - p.xx refers to a page in the book "Object-Oriented Reengineering Patterns".
OOMP- p.xx refers to a page in the book “Object-Oriented Metrics in Practice”.)

Tools Used

CodeScene - *no* installation necessary, but it requires a GitHub account. This tool integration with GitHub allows it to visualize your repositories.
inFusion (or inCode the eclipse plugin) (OLD local version) (new link)

The version of inFusion you have in the lab machines has two issues:

the menu can be displayed in the wrong way. This issue hinders you from running the analysis. The workaround is to extract the file results using the command line:

Enter in the directory with iFusion and digit:

./inFusionC -lang java -path [path where your project is located] -result myProjectResult.result

once the file is generated, just open it running the program in the normal way.

The files containing the quality models refer to the wrong path. The solution is to update them:

Windows > Preferences > Quality Model.

Update the path (e.g. /home/uauser/inFusion/plugins/com.intooitus.resources.infusion_1.8.0.201403311210/res/quality/QM-C.quality )

Codecity (only on Windows or Mac only possible on Linux after installing VisualWorks for Smalltalk). A preview of its functionalities can be found here.
JsCity is an implementation of CodeCity to analyze JavaScript code.
Softwarenaut (only on Windows or Mac). This system does not require Eclipse. A preview of its functionalities can be found here. The tool can be download here. An alternative is the Creole Eclipse Plugin (only works on really old versions of Eclipse). It is pretty unstable.
Eclipse Metrics. We won't use this plugin. However, the interested user may use this plugin to extract the raw metrics. These metrics are the ones extracted (and combined) by inFusion for its analysis.
Moose. We won't use this tool in the course. However, it provides a powerful platform for software analytics.

For ease of use, we have a precompiled version of Checkstyle loaded into an old working environment of Eclipse (including the Creole plugin and a local version of the inFusion tool) for Linux. You can use the old version of Eclipse to try Creole. However, due to compiling problems, you may want to edit CheckStyle with Eclipse Mars.

Introduction

Visit the CodeScene website and look at the Showcases examples. Get acquainted with the interface, and browse the statistics.

Next, visit the CodeCity website. You can see there are no interactive demos. Visit the JsCity website and look at the examples.

What did you think of these visualization tools? Can you extract important information about the visualized project from them?

Initial Understanding (OORP – p. 65)

The Overview Pyramid (OOMP – p. 24)

The overview pyramid of an object-oriented system includes metrics that reflect three main aspects: Size and Complexity, Coupling and Inheritance.

Use inFusion to create an Overview Pyramid of the system.

Try to understand what these numbers represent. What information can we derive from the overview pyramid?

Study the Exceptional Entities (OORP – p. 84)

You want to achieve an overall impression of the design quality and identify potential design problems. This information should provide arguments for deciding on whether the goal of adapting Checkstyle is attainable.

Class Size (OORP – p. 88)

Verify how system functionality is distributed across the system’s class decomposition. Analyze the size and complexity of classes in the design to detect anomalies.

Using inFusion sort all classes of package com.puppycrawl.tools.checkstyle.checks.usage.transmogrify according to the metrics

Lines Of Code, Number Of Attributes and Methods.

Do you understand how the class is distributed by inFusion inside the package?

You can analyze the same metrics using CodeCity.

Given the class GeneratedJavaRecognizer, which approach would reduce its size?

Class Inheritance (OORP – p. 89 & OOMP – p.34)

Verify the extent to which reuse has been built into the design. Analyze the inheritance hierarchies to reflect on this issue.

Use inFusion to get the System Complexity View. Explore the resulting view to find the class ClassDef and then analyze its inheritance map.
Who are its ancestors, descendants, and siblings?
What represents the color of the rectangles?

Redistribute Responsibilities (OORP- p. 187)

Split Up God Class (OORP – p. 208 & OOMP – p.80)

Identify and Study the god classes. Analyze how these could be split up into a number of smaller, cohesive classes.

inFusion has a feature to identify god classes. Are these the same as the ones we identified with CodeCity? If not, why not? How does CodeCity detect god classes?

Argue whether the identified entities are indeed design problems. Analyze what operations these god classes perform, and discuss how you would split such a class.

Move Behaviour Close to Data (OORP – p. 190 & OOMP – p. 88)

You want to strengthen encapsulation by moving behavior from indirect clients to the class containing the data it operates on. This requires the identification of data containers (or data classes).

inFusion has a feature to identify data classes. How does inFusion detect data classes?

Argue whether all identified entities are indeed design problems (e.g. ClassCouplingCheckTestInput).

Experiment with inFusion to analyze how these data containers are used.

Discussion & Conclusion

We have used metrics and visualization for both Initial Understanding and Redistributing Responsibilities, thereby demonstrating their potential support to the reengineering process.

Did the metrics and visualization tools used in this lab session provide you with the information you needed to fulfill the goals of the different Reengineering Patterns? Set up an argument about the issues concerning the use of such tools: when would you use them, when wouldn’t you? Can you envision other usages of these tools in other phases in the Reengineering Lifecycle?