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.
• Once the user finishes the dialog, the results are displayed in a graphical format (a chart or graph).

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.

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.

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.

• Category: Represents one category of an activity report. A category can be "Testing", "Developing", "Designing" or other activities. This sounds like a candidate for a strategy (a strategy for gathering and calculating metrics from the raw metrics data). A category can be divided into multiple sub-categories (however, this is not the case in the initial design).

Flaws

The flaws in the initial design include the following:

There are some "support" classes which are not linked to any other classes. The classes include: Support, and ActivityCategory. Support was not used at all in the final release last year, so it is debatable whether it should still be in the codebase. I decided to get rid of it for the improved design. ActivityCategory another concern, as it is not linked to the report. This is because we ran out of time to include categories in the reports before the final release.

The ActivityReportWizard class only contains one ActivityReportWizardPage. 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 ActivityReportWizard class and ActivityReportWizardPage class both have an association with (contain) the ActivityReport 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.

An ActivityCategory should be able to consist of multiple sub-categories. For example, the category "testing" could consist of the sub-categories "writing tests" and "running tests". To enable this, in the improved version I changed ActivityCategory into a Composite. This relates to the use case mentioned above that a user should be able to "drill down" into the subcategories in an "Activity" report.

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

The showChart() method of the ActivityReport class has a terrible Switch statement smell. See the "appendix" for details.

There are three methods in the ActivityReport class which do essentially the same thing. These are called "createXXXChart" where "XXX" is the report type. This suggests that Report should be an abstract class and that subclasses should override this type of method.

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.

This resulted, initially, in three different types of reports. There could be an "Activity Report", a "View Report", or a "Class Report". However, this was initially chunked together in one large class called "ActivityReport". It would be better for it to be broken up so that Separation of concerns is followed.

Improved Design

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

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 ActivityCategory objects to the ActivityReport class to track the categories shown. Added appropriate methods to enforce the Law of Demeter.

To enforce Separation of concerns, I created a GUI class to handle the View of the report. This would allow updating the report internals and then updating display as well. Before, the only time that SetStartDate() and getEndDate() were called was in the save() method of the ActivityReportWizardPage class (which meant that after creating the report, the dates could not be changed). The ReportGUI class is an Observer of the Report class.

The getActivityReportChartTypes() or the ActivityReport 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.

At the moment, ActivityReport has three methods which operate in parallel: createActivityChartData(), createViewChartData(), and createClassChartData(). These should perhaps be absctracted into Factory Methods, and suggests that the Open closed principle is not being used. Anyone wanting to create a new type of report will have to edit the existing code. 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.

There are still more changes that could be considered. For example, perhaps different categories could be represented as a Decorator?

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).

• Separation of Model and View: This is noticeable in the ReportGui / Report and Wizard / Report relationships.

Appendix

The "showChart()" Method

public void showChart() {
       String title = "";
       if(chartType.equals("activity report"))
           title = (new StringBuilder(String.valueOf(title))).append("Activity Report for ").toString();
       if(chartType.equals("class activity"))
           title = (new StringBuilder(String.valueOf(title))).append("Class Report for ").toString();
       if(chartType.equals("view activity"))
           title = (new StringBuilder(String.valueOf(title))).append("View Report for ").toString();
       title = (new 
StringBuilder(String.valueOf(title))).append(System.getProperty("user.name")).append(
" from ").append(DateFormat.getDateInstance().format(getStartDate())).append(
" to ").append(DateFormat.getDateInstance().format(getEndDate())).toString();
       String windowTitle = "Patchwork Metrics report";
       String xAxisLabel = "Part";
       String yAxisLabel = "Time";
       DefaultCategoryDataset dataset = new DefaultCategoryDataset();
       GenericStorageObj storageLayerDataSet = null;
       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;
       String category;
       Integer timeSpent;
       for(Iterator iterator = storageLayerDataSet.getNestedObjects().iterator();
iterator.hasNext(); dataset.addValue(timeSpent, "Time Spent", category))
       {
           IStorableObj obj = (IStorableObj)iterator.next();
           GenericStorageObj tuple = (GenericStorageObj)obj;
           category = (String)tuple.getField("part").getValue();
           timeSpent = (Integer)tuple.getField("time").getValue();
       }
       org.jfree.chart.JFreeChart chart = ChartFactory.createBarChart(
title, xAxisLabel, yAxisLabel, dataset, PlotOrientation.VERTICAL, false, true, false);
       ChartFrame frame = new ChartFrame(windowTitle, chart);
       frame.pack();
       frame.setVisible(true);
}