Martins Design Study

Overview of Patchwork Metrics

My design study is based on the Patchwork Metrics Eclipse plugin. This is a plugin for gathering (and reporting) process metrics, which are measurements such as time spent programming, time away from keyboard, amount of code written, and other useful metrics. This data could be useful for seeing development trends, and which development practices work well for a company.

Patchwork metrics has two parts: the metrics gatherer (which gathers raw information from Eclipse) and a reporting interface. In this design study, I aim to redesign the reporting interface to fit the OO wisdom described in COSC 427.

Metrics Gatherer

The metrics gatherer of Patchwork Metrics works in the background as the user is working with Eclipse. Once Patchwork Metrics is installed as an Eclipse plugin, it gathers raw data such as the amount of time spent in a certain editor or view, and the amount of code written in a session. This data is all stored for later analysis.

For the purposes of this study, however, the metrics gatherer was left out of the application, and replaced instead with a Mock objects. Instead of using using real metrics, the Mock objects produce hard-coded, fake metrics. This was done because it is technically difficult to get the metrics gatherer to work. The reporting interface and the metrics gatherer are very loosely coupled, so this approach is justified.

Reporting Interface

The reporting interface of Patchwork Metrics allows the user to analyse metrics gathered by the metrics gatherer. For example, the user can view reports (in the form of graphs) which summarize the metrics gathered over a certain time range. An example of this is given in a use case in the following section

Use Cases

These are the use cases which drove the design changes I made.

Use Wizard to Create Report

The user can use a menu option or button to show a wizard (made of different pages) which allows them to create a report. There should be an option for creating any type of report mentioned above (in Categorization of Metrics).

• There is a menu option in Eclipse called "Patchwork Metrics Report".
• User clicks that button.
• A "Wizard" (http://en.wikipedia.org/wiki/Wizard_%28software%29) is shown. The user navigates through the wizard and chooses the type of report they want to generate and set its parameters. The image below gives and example.

• Once the user finishes the dialog, the results are displayed in a graphical format (a chart or graph). The image below gives an example.

The user can set all the necessary parameters for the report, including:

• Date range. This will specify the starting and ending date for the data to be gathered and analyzed. For example, a user might only be interested in analysing the time period for one week, or one month.
• Modules included in analysis. The user should be able to view metrics for any combination of modules, or all modules.
• Developers included in analysis. The user should be able to include data from any combination of developers.

Divide Metrics into Categories and Subcategories

Metrics should be divided into orderly categories and subcategories. Let's pretend you are viewing an "Activity Report", which specifies what activities a developer has been doing, and for how long. You notice they have spent a lot of time testing. You wonder how long they spent writing tests and how much time they spent running tests. Therefore, the category "testing" could consist of the sub-categories "writing tests" and "running tests". If you want to drill down on the testing section of the chart, you should be able to click on that section in the graph, and see a new small graph showing the times "writing tests" and "running tests".

Extend to Create New Report Types

At the moment, the metrics which Patchwork Metrics reports on are divided into three main categories:

• Activity (which activity the developer is performing). This could include testing, developing, designing, and other activities.
• View (how much time the developer spends viewing different classes).
• Class (metrics specific to each class, such as "how often was the class edited?", or "what is the cyclomatic complexity of this class?").

A third-party developer should be able to add a new report type (and a wizard for this report) without modifying the existing codebase (following the Open closed principle). At the moment there are three types of report, which are "class report", "activity report" and "view report". Each of these reports use data from the metrics gatherer in a different way.

However, other developers may want to create new types of reports. For example, a "method report" could show how often each method in a class or software project has been modified. This would require gathering a different set of data from the data gatherer than the pre-existing report types. So there should be an easy way for other developers to create new report types, with their own strategies for gathering metrics from the metrics gatherer.

Export Report Results to XML Format

The results of reports should be exportable to XML format. Users can then use the exported XML files to import the metrics into external tools for further analysis. Ideally, this should be extensible enough so that a third-party developer can add a new type of file format for the report to be exported to (depending on the external analysis tools which they plan to use). (Sounds like the Visitor pattern).

Edit existing report (from GUI)

Once the report has been displayed in graphical format, there should be controls which allow the parameters for the report to be changed. As these parameters are changed, the report details should be recalculated and the display updated. (Sounds like the Observer pattern).

For example, the report could be shown as a chart. The developer decides to narrow the date range for the report. They should be able to do this using the GUI interface, instead of having to run a wizard again.

Initial Design

A diagram of the initial design of the reporting interface is shown below. This was the current design at the end of COSC 325 (the course for which Patchwork Metrics was created for). An explanation of the elements in the diagram and the overall design is given below the diagram itself.

Classes

This section describes the classes used in the design.

• Report: Contains the data for the report, as well as the parameters. This includes the starting and ending date for the report data, as well as the calcluated metrics for this date range.

• ReportWizard: Represents the Wizard which the user goes through to create the report. This includes the pages and and navigation details for them. However, in the initial design it contained only one page.

• ReportWizardPage: This is one page of the wizard. The user will set the parameters using GUI-based controls (such as a calendar widget for setting the start and end dates). The settings made by the user should be reflected in the resulting report.

Flaws

There is no division of metrics into categories.

The ReportWizard class only contains one ReportWizardPage. It should allow for a set or list of pages, and not just one. Again, we ran out of time to remedy this before the final release. In the improved design, I changed the field from a single page to a list of pages instead.

The ReportWizard class and ReportWizardPage class both have an association with (contain) the Report object, making changes to it. It could be argued that they are playing the role of a controller, but I believe the situation can be improved. There should be much looser coupling between the Wizard classes and the Report class.

There is currently no mechanism for exporting the report data to XML.

The showChart() method of the Report class has a terrible Switch statement smell. It branches off into three different methods which do essentially the same thing: createActivityChartData(), createViewChartData() and createClassChartData(). This suggests that Report should be an abstract class and that subclasses should override this type of method. The original code looked something like this:

if(chartType.equals("activity report")) storageLayerDataSet = createActivityChartData(getStartDate().getTime(), getEndDate().getTime());
else if(chartType.equals("class activity")) storageLayerDataSet = createClassChartData(getStartDate().getTime(), getEndDate().getTime());
else if(chartType.equals("view activity"))storageLayerDataSet = createViewChartData(getStartDate().getTime(), getEndDate().getTime());
else return;

The interface works, but is not very extensible. For instance, it would be difficult for other developers to to create new types of reports or new views and layouts without modifying the existing codebase. This violates to Open closed principle.

There is no separation of model and view. Report, for example, has a method called showChart(), which is what a GUI would typically do. showChart() is a method which should belong to the view and not the model.

Improved Design

A diagram of the improved design of the reporting interface is shown below.

Design Flaws Fixed

The getReportChartTypes() or the Report class creates and returns a set. Perhaps this should be made a static set or an Enum used instead. Perhaps it could even be abstracted into a Strategy. We can see there are 3 types of reports: activity, class, and view.

Report had three methods which operate in parallel: createActivityChartData(), createViewChartData(), and createClassChartData(). There could be an "Activity Report", a "View Report", or a "Class Report". However, this was initially chunked together in one large class called "Report". In the inital design, In the improved design, this has been replaced with an abstract method createChartData() in the Report Class. The subclasses of Report now implement this method, getting rid of the Switch statement smell. This follows the Replace Conditional with Polymorphism Refactoring principle.

To enforce Separation of concerns, I moved the "view" functions (such as showChart()) out of the Report class and into the ReportGUI class. This is in order to separate the view from the model.

New Features Introduced

In the initial design, several of the use cases presented in the first section were not completed. In the improved design, the use cases were more conformed to as follows.

• Wizard for generating reports. Done
• Users can select date range for analysis. Done
• User can select modules included in in analysis. Not Done
• Developers included in analysis. Not Done

I added a set of Category objects to the Report class to track the categories shown. Added appropriate methods to enforce the Law of Demeter.

There a menu bar with a single menu item, which will set the starting date of the report to 01 January 2010. This is simply a proof of concept of the Observer pattern used to update the Report from the ReportGUI, and could potentially be extended further.

As mentioned in the use cases section, a Category should be able to consist of multiple sub-categories. To enable this, I created the Category class, using a Composite design pattern.

The new design also allows different Wizard implementations to be used. For the purposes of this study, I had to use a different Wizard framework than the one which was used in the initial design. Therefore, I created the IWizard Interface to allow both implementations to be used. JFaceWizard and NetbeansWizard are the classes which implement this interface.

There is now support for exporting a report to a file. This is provided by the abstract class ReportExporter, and an example implementation called TextReportExporter is given. The Visitor pattern has been used for this, with Report as the receiver, ReportExporter as the abstract visitor, and TextReportExporter as a concrete visitor.

Mock API

Note that a "mock API" was used for the metrics gatherer module in the improved design, as noted in the overview section. This is because it was technically very challenging to get the real metrics gatherer to work, and the focus of this project was on the reporting interface. I did not have the time to test the improved reporting interface design with the real metrics gatherer API, but I assume that it would work well.

Discussion

The design project was to improve the reporting interface for the "Team Patchwork Reporting Application". This was completed by using a variety of design patterns, as noted above. A few classes were renamed (such as "Activity Report" to "Report").

Conflicting Forces

There were some conflicting forces in the design.

• Simplicity of design vs. extensibility. This is visible especially with the Wizard adaptors / containers. There are two containers, one for each type Wizard GUI library. This is extensible, but it is hard to make both conform to a common interface. It is tempting to wrap calls to the specific API inside the container classes. For instance, if the JFace wizard had an API call named FaceScreen(), which the Netbeans Wizard API did not, then what should be done with the IWizard interface? Should we include the function, and implement a null override in NetBeansWizard? Or should we not include the method in IWizard, and sacrifice some cool functionality?

• Separation of concerns vs. convenience / simplicity : This is visible in the ReportGUI / Report relationship. ReportGUI is rather tightly coupled to Report, acting as sort-of a controller and observer at the same time. This could be more tightly coupled (convenience) or less tightly coupled (separation of concerns).

• In the Category class, there is some confusion...