Matthew's Design Study

Revision as of 04:03, 28 July 2009

For my design study, I am going to be working to improve the design of my COSC460 project. The project is a plug-in for Eclipse designed to provide a tool for visualising software metrics directly onto source code. The plug-in is written in Java and is approximately 5K LOC.

Existing Code Base

This system is my first attempt at developing this system. At first glance it appears fairly logical; however, some more serious OOD issues lurk beneath the surface...

Initial development. Please note some of the composition/dependency connections are wrong.

Initial development with functional groupings.

Design Discussion/Overview

In this section I will briefly discuss each of the current components and their roles. Please note that these functional groupings do not directly correspond to existing packages.

• Plugin: This Singleton class provides a launcher for the Eclipse plugin. It provides all of the initial driving calls to instantiate the underlying document monitor and listeners.
• Document Monitor: This package provides handling of Java files in the editor, keeping track of those that have been loaded and also as a location to retrieve updated metrics data. Generally, this class relies on Singletons to keep track of the open files.
• Editor Listeners: These classes listen to the Eclipse editor, in most cases this is effectively the current document's buffer. Each change of state is reported to the EditorListener class.
• The Model: This set of packages provides a representation of the stored data. A MetricDocument contains all of the metrics, mappings and displays for a single Java file. There can be multiple

metrics represented using multiple mappings in any one document, and each of these may have multiple MetricSections, which represent the an actual appearance of the metric in the editor.

• Display & Editor Manipulation: This set of classes deal with the current Eclipse editor and provide the functionality to add adornments to the editor. A wide variety of these adornments exist,

they are backed up with appropriate Shape and Color managers.

• API: These classes provides an Observer interface where external 'Providers' can listen for and then as necessary provide metrics information as requested.
• Serialisation: This package allows metrics data to be provided and/or converted via a defined XML format.
• Eclipse View: These classes provide a view that allows users to alter which metric visualizations are currently active and which displays are being used for each.

Existing Usage of OOD Features & Techniques

Areas of Greatest Concern

• API: Is the architectural model appropriate? Is the use of the Observer pattern correct here?
• Model: Are there any possible improvements?
• String Manipulation: Is there any way to avoid the current String manipulation in Mapping Properties?
• Display Strategies: Is there any way of simplifying this hierarchy? Are the current methods of instantiation appropriate?
• Eclipse View: Dynamic updating of data is a concern here.
• File Instances: Is the current design the most sound way of dealing with Eclipse's editor model (i.e. multiple files, with multiple views).
• Alternative Languages: What can be done to make the system more modular and appropriate for multiple languages?

First Design