BrettWardsDesignStudy

For my design study I chose to work on the client part of my 324 project last year. The topic was a metrics collection plugin for Eclipse, and my groups design used a server + client design, but the client "design" was somewhat hacked together.

As the client was an Eclipse plugin, a number of the classes are generated by Eclipse. These have mostly been left out of the UML diagrams, as they will remain unchanged among versions.

The final version from last year can be downloaded from Google Code, with the eclipse-plugin folder being the client I was working on.

Intro

The aim of the project was to create an Eclipse plug-in that took in data from various usage metrics, and then allowed users to see and access the data in a number of ways. The client-side, however, just dealt with collecting the metrics, and sending them to the server (as well as dumping it to a local log, for usage when not connected to a server).

At the end of the year, several data points could be collected from the plug-in, including:

• What programs had been in focus over a session, and for how long (aka, a focus tracker)
• What time (if any) a user had been away from their keyboard.
• Debugger usage tracking - including launch times, and markers on where breakpoints were put.
• Ratings metrics via a thumbs up/thumbs down view, allowing a user to rate a class up or down depending on their opinion.
• Generic messaging, allowing a user to comment on code or whatnot anonymously.

The Eclipse Plugin

The client plug-in consisted of two packages: actions and views. Actions consisted of 12 classes, and 3 views were created. Other classes exist within the Googlecode repository, but were from earlier iterations (in some cases classes were renamed) and thus have not been included in this study.

Focus is on the Actions part of the interface, although mention of connections to the Views parts will probably be brought up.

Analysis of Current Code

The UML diagram shows roughly where the design was at at the end of last year. Note some of the connections in the diagram may be slightly incorrect.

- diagram 1 goes here - - diagram 2 goes here -

Notes on the initial design:

• The User class was somewhat the central class of the design, controlling a lot of the functionality whether it be metrics, or server-oriented. It was instantiated by Eclipse when either MetricsActions buttons were activated (which could only be done once).
• The MetricsActions classes were the classes instantiated by Eclipse when the plugin was activated. These were activated by buttons on the interface. Because of how Eclipse did this, we never found a way to make them one class with 2 different constructors.
• FocusTracker was a singleton class that kept track of all focus changes over a session, each change having it's own Timer. These were kept in a Map that contained the name of the item (eg, java class) brought into focus, and an arraylist of Timers related to items by that name.
• The User had a Log, which outputted

Notes

• UML diagrams currently not uploaded