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

       The version of inFusion you have in the lab machines has two issues:
the menu' can be displayed in a wrong way. This issues hinders you from running the analysis. The workaround is to exctract 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 programm 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.
  • Softwarenaut (only on Windows or Mac). This system does not requires Eclipse. A preview of its functionalitiest 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 pluging to extract the raw metrics. These metrics are the ones extracted (and combined) by inFusion for its analysis. 

For ease of use, we have a precompiled version of Checkstyle loaded into a 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.

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. Analyse 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 are distribuited by inFusion inside the package?

  • You can analize 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. Analyse 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 represent 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. Analyse 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. Analyse 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 behaviour 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 analyse 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 fulfil 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?