Revision as of 04:03, 26 September 2010 (view source) James Ashford (Talk | contribs) m (→Design Maxims Followed) ← Older edit		Revision as of 07:45, 26 September 2010 (view source) James Ashford (Talk | contribs) m (→Third Attempt) Newer edit →
Line 290:		Line 290:
	=== Design Patterns Used ===		=== Design Patterns Used ===
−	[[Observer]] - Events System	+	[[Observer]] - Events System... [[Tell don't ask]] - slightly different...
	[[Composite]] - Variable / ObjectVariable		[[Composite]] - Variable / ObjectVariable

---

Revision as of 07:45, 26 September 2010

Contents 1 My Project 1.1 Management 1.2 Event Handler 2 Design Study 2.1 Requirements 2.2 Constraints 2.3 Initial Design 2.4 UML Diagram 2.4.1 Description of Classes 2.4.2 Inherited Classes 2.5 Design Critique 2.5.1 Initial Design 2.6 Maxims Violated 2.7 First Attempt Design Improvements 2.7.1 PseudoBreakpoint Factory 2.7.2 Events (BreakpointDataEvent / BreakpointChangeEvent) 2.7.3 Variables / BreakpointEvent 2.8 Second Attempt 2.8.1 What I don't like so far... 3 Files 3.1 Third Attempt 3.1.1 Class Descriptions 3.1.2 Design Patterns Used 3.1.3 Design Maxims Followed 3.1.4 Design Maxims Considered 3.1.5 Design Maxims Violated 3.1.6 The Interesting(??) 3.2 Installation

My Project

As part of my honours project, I am developing a plug-in to Eclipse to help illustrate how the state of software changes during runtime. My design study will focus of the data collection subsystem of my project.

Data collection works by inserting a data collection point (also known as a Pseudo Breakpoint) into a line of code in your document. Every time the application hits this data collection point, a copy of all variables in scope (local, instance and static variables) are recorded and the program resumes. At the conclusion of runtime, the user can review what happened and generate visualisations.

There are two main areas in the data collection subsystem namely:

1. Management (inserting / deleting of data collection points etc)

2. Event Handler (whenever the data collection point is encountered)

Management

The management area of this project is related to the creation, deletion, insertion and management of the data collection points. These data collection points are known as Pseudo Breakpoints within the project. A data collection point is a thinly disguised breakpoint which is handled along side normal Java breakpoints.

Main activities:

• Creates Pseudo Breakpoints
• Manages the Pseudo Breakpoint
• Adds the extension to the Eclipse editor (so the user can toggle the Pseudo Breakpoints on/off

Event Handler

The event handler controls all the data collection events within the system.

Main activities:

• Handles events when the Pseudo Breakpoint is 'hit'
• Variable datastore (when the breakpoint is hit a copy of all inscope variables are stored in a datastore)

Event Handler Process Flow:

1. Event Handler is notified that a breakpoint has been hit

2. Event Handler checks to see if it was a PseudoBreakpoint

3. If so, do data collection

4. Event Handler checks to see if there was another breakpoint also hit (a normal breakpoint)

5. If so, suspend application (so normal breakpoint activity can occur)

6. Else resume program

Design Study

Requirements

1. Maintainability - Easily add new features (such as different data sources etc)
2. Extensible - Add additional programming languages (such as PHP etc) easily

Constraints

As this is an Eclipse plug-in, our design must fit the Eclipse model.

Initial Design

One Word: horrible.

UML Diagram

Description of Classes

debugassist:

• Activator (extends AbtractUIPlugin) - Activator class which is run when the Plugin is loaded
• DebugAssistLogic (implements DataUpdateBreakpointClient, DataUpdateEventClient) - Provides some basic functions to clean up breakpoint data, contains 2 clients which are activated when a breakpoint is inserted/updated/remove and when a breakpoint is 'hit'

debugassist.datasource:

• DataBreakpointStore - Stores all the pseudo breakpoints in a HashSet.
• DataEventStoreTime - Store all the data when a breakpoint is hit.

debugassit.events:

• DataUpdateBreakpointClient - An interface which needs to be implemented if you wish to listen to Breakpoint Events (i.e. when a breakpoint is added/removed etc)
• DataUpdateBreakpointListener - The service which handles Breakpoint listener clients (where clients subscribe to events etc)
• DataUpdateEventClient - An interface which needs to be implemented if you wish to listen to Breakpoint Data Events (i.e. when a breakpoint is encountered by the debugger).
• DataUpdateEventListener - The service which handles Breakpoint data listener clients (where clients subscribe to events)

debugassist.handlers:

• BreakpointAddRemoveEventHandler (implements IBreakpointListener) - handles the breakpoint events from Eclipse (i.e. when a breakpoint is added / removed from Eclipse) - and notifies DataUpdateBreakpointListener.
• DebugEventHandler (implements IDebugEventSetListener) - Handles the breakpoint hit events from Eclipse (i.e. when a breakpoint is hit within Eclipse) - this performs data collection (collects all variables in scope), and notifies DataUpdateEventListener.
• EclipseDebuggerEventListenerManager - Attaches BreakpointAddRemoveEventHandler and DebugEventHandler to Eclipse.

debugassist.model:

• BreakpointEvent - A model for whenever a breakpoint is hit by the debugger (stores time, variables)
• ModelGenerator - A utility class for converting IVariable (Eclipse type) to Variable (our model type)
• Variable - A model for a Variable

debugassist.pseudobreakpoint

• AddRemovePseudoBreakPointHandler (extends AbstractRulerActionDelegate) - Pseudobreakpoint handler type - so users can right click in Eclipse to add/remove a breakpoint.
• PseudoBreakpointImpl (extends JavaLineBreakpoint) - The breakpoint used to represent our Pseudobreakpoint. It is actually just a JavaBreakpoint with a different type and icon so the DebugEventHandler knows which breakpoints to collect.

Inherited Classes

A few classes are extended and implemented in this project

AbstractUIPlugin - An abstract class providing some basic functionality required to create an plugin in Eclipse. AbstractUIPlugin Javadoc

IBreakpointListener - An interface used by classes that require notification when breakpoints are added and removed IBreakpointListener Javadoc

IDebugEventSetListener - An interface used by classes that require notification when Debugger Events occur IDebugEventSetListener Javadoc

AbstractRulerActionDelegate - An abstract class to allow contributions to the vertical ruler's context menu in the text editor. AbstractRulerActionDelegate Javadoc

JavaLineBreakpoint - A class which provides the Java Line Breakpoint Implementation (required to insert a breakpoint into the JVM)

Design Critique

Initial Design

Quick notes:

• The current package design is inconsistant with poor names.
• DebugAssistLogic doesn't seem to do much, needs a reorg - most functions could be placed in Activator
• DebugEventHandler handles the Breakpoint data events. This is a clear violation of [Separation of concerns] - which it really should be a DataUpdateEventListener
• DataUpdateEventListener & DataUpdateBreakpointListener SHOULD be the ones themselves which handle the Eclipse events (the debugassist.handlers are unnecessary)
• The names of the classes need to be changed
• ModelGenerator should be fixed (I'm not sure I actually need it???)
• The Pseudobreakpoint classes should be fixed up - It's directly extending the Javabreakpoint class!!!!
• Many classes are singleton - perhaps this should be reorganised?
• It currently is hard-coded to support JavaBreakpoint only - make it more extensible!

There was no initial design - it all evolved out of prototyping - which is why the DebugEventHandler handles the breakpoint events.

Maxims Violated

Avoid inheritance for implementation My PseudoBreakpoint class directly inherits the Javabreakpoint class so that it can interact with the JVM. This effectively stops any other programming language from using our plugin.

[Separation of concerns] DebugEventHandler handles the Breakpoint data events as well as being an Event Listener.

Beware singletons There is a number of singleton classes in here including: ... .. .... Perhaps this could be refactored into a single class?

Single responsibility principle PsuedoBreakpoint class doing too much.

Program to the interface not the implementation Everything uses the direct class (no interfaces used) - Again, this limits our project to Java.

Software reuse DataUpdateBreakpointListener and DataUpdateEventListener both have the same code to handle the adding and removal of listener classes.

Model the real world Not really.

First Attempt Design Improvements

Things seem more organised now:

• Class names have become clearer (PsuedoBreakpointRulerActionDelegate & PseudoBreakpointRulerAction should be clearer than AddRemovePsuedoBreakpointHandler & PseudoBreakpointImpl)
• PseudoBreakpoint Factory
• Events Improved
• Model Generator & Handlers removed

PseudoBreakpoint Factory

Previously the PseudoBreakpoint class was a extension of the JavaBreakpoint class. In order to support other programming languages (in the future) I created a Factory Method to return the appropriate Breakpoint class to insert into the virtual machine.

• PseudoBreakpoint (extends IBreakpoint) - A placeholder type for our PseudoBreakpoint
• PseudoBreakpointCreator - Determines which sort of Breakpoint to create and returns the generic PseudoBreakpoint
• PseudoBreakpointPython / PseudoBreakpointJava (implements PseudoBreakpoint) - an extension of the Java/Python breakpoint class.

Events (BreakpointDataEvent / BreakpointChangeEvent)

Observer - My original design was kind-of an Observer pattern (but poorly implemented - both classes had the same code for adding/removing observers (Don't repeat yourself)). As Java's Observer pattern does not suport generics, I decided to create my own. A generic abstract class 'Subject' handles subscribers.

• Subject - Abstract class to handle observers attaching/detaching to the event handler
• DataUpdateEventObserver (was DataUpdateEventClient) - Essentially the same, but now with a proper name
• DataUpdateBreakpointObserver (was DataUpdateBreakpointClient) - Essentially the same, but now with a proper name
• BreakpointDataEvent [extends Subject, Implements IDebugEventSetListener (Eclipse)] (was DataUpdateEventListener) - Handles Breakpoint Data Events (i.e. when a breakpoint is 'hit') from the Eclipse Debugger directly and notifies subscribed observers
• BreakpointChangeEvent [extends Subject, Implements IBreakpointListener (Eclipse)] (was DataUpdateEventListener) - Handles Breakpoint Add/Remove Events from the Eclipse directly and notifies subscribes observers and the DataBreakpointStore (I think I need to modify this)

Variables / BreakpointEvent

I removed the model generator - it is now all handled within the BreakpointEvent class.

Second Attempt

What I don't like so far...

• DataBreakpointStore is called by the BreakpointChangeEvent class. It should subscribe to the event rather than being directly called
  • Thinking about this further, it is even required? We are essentially keeping a copy of all the breakpoints when we could just query the underlying Eclipse model.
• Still too many singletons. Is this necessary?
  • Perhaps this could be done with a God Class? Or would this be bad?
• I'm not sure I like my 'custom' Observer pattern.
• Cleaning up my PseudoBreakpointRulerActionDelegate / PseudoBreakpointRulerAction - (heaps of unused stub methods)
• Activator class is used to attach the BreakpointEventDataStore instance to BreakpointDataEvent event system.

Files

Media:debugassist-swe_init.zip - The initial design.

Third Attempt

Quick notes:

• Redesigned variable section (major changes here)
  • Abstract class Variable (contains most of a variable definition)
  • PrimitiveVariable class (contains data about primitive variables)
  • ObjectVariable class (contains data about objects)
• Fixed PseudoBreakpointRulerActionDelegate classes - now using a subclass instead of the interface
• Removed the last Singleton pattern from BreakpointEventDataStore
  • Turns out that it wasn't even necessary
  • It is now all handled by the Activator class (which handles the creation of the plugin)
• Removed DataBreakpointStore. We didn't really need it - as we can query the underlying model if we ever need it.
• Slight rename of classes...
  • BreakpointEventData is now called BreakpointDataEvent (the same as BreakpointDataEventStore)
• Collections implementations are now hidden (most generic type possible0
• Collections are now returns as unmodifiable (where applicable)

Class Descriptions

Package	Class Name	Description	Public Attributes	Public Methods
debugassist (root)	class Activator (Extends AbstractUIPlugin)	This class launches the entire plugin. It is instantiated by Eclipse itself, and operates in a similar way to a singleton. It contains the logic to attach all the event handlers to Eclipse.	None	class Activator() - public constructor (required by Eclipse); start(BundleContext context) - starts and launches the plugin (and attaches event handlers); stop(BundleContext context) - destroys instance, removes event handlers; static Activator getDefault() - Returns the current instance of the running plugin; static ImageDescriptor getImageDescriptor(String path) - Returns the image descriptor for the image file.
debugassist.datasource	BreakpointEventDataStore (implements DataUpdateEventObserver)	This class stores the of BreakpointEvents as they occur.	None	ArrayList<BreakpointEvent> getAllBreakpointEvents() - returns the data store; clearEvents() - removes all items from the data store; updateModelRequired(String frameName, String threadName, IVariable[] variables) - A method from the DataUpdateEventObserver interface - it is called whenever a Pseudobreakpoint is hit.
debugassist.events	abstract class Subject<T>	Provides basic functionality to add and remove observers.	None	attach(T child) - adds a child who requires notification when something changes; detach(T child) - removes the child from notification;
debugassist.events	interface DataUpdateEventObserver	Any class which wishes to be notified whenever a Pseudobreakpoint is hit must implement this interface.	None	updateModelRequired(String frameName, String threadName, IVariable[] variables) - Whenever a Pseudobreakpoint is hit, this method will be called - containing the frame name, thread name, and an array of IVariables (An Eclipse model type)
debugassist.events	class BreakpointEventData extends Subject<DataUpdateEventObserver> implements IDebugEventSetListener	Handles all Eclipse breakpoint data events (like when a breakpoint is hit by the debugger), and passes relevant information (only pseudobreakpoint info) onto the observers.	None	handleDebugEvents(DebugEvent[] events) - Required by IDebugEventSetListener interface, is called whenever any breakpoint is hit in Eclipse. Our implementation determines if the breakpoint was a pseudo breakpoint, and if so, notifies all the attached observers. dispose() - basic dispose operation to remove all children from collection.
debugassist.model	abstract class Variable implements Comparable<Variable>	Provides an abstract presentation of a variable. There is also a private class ModelGenerator which converts an IVariable array (the Eclipse type) to our Variable array.	None	String getData() - returns a String representation of the data; String getType() - returns a String of the type; String getName() - returns a String of the name of the variable. getUpdateCount() - returns the number of changes that variable has had; updateData(String data) - updates the data field of the variable (and increments the update counter); compareTo(Variable o) - compares another variable against itself for sorting (based on the name of the variable).
debugassist.model	class PrimitiveVariable extends Variable	Represents a primitive variable (eg int)	None	boolean isLeaf() - always returns true (as will never have children); String toString() - Returns a string representation of the primitive; String getShortName() - returns a shortened version of the toString() method
debugassist.model	class ObjectVariable extends Variable	Represents an Object (which contains references to other Variables)	None	(The same as PrimitiveVariable) plus: Map<String, Variable> getReferences() - returns all the Variables which this variable refer to; void addReference(String name,Variable ref) - Adds an object to the collection
debugassist.pseudobreakpoint	interface PseudoBreakpoint extends ILineBreakpoint (Eclipse Model)	An interface to represent a breakpoint which will be used by Eclipse (for use in the text editor) and by the programming language (to actually insert a breakpoint into the VM)	None	None
debugassist.pseudobreakpoint	class PseudoBreakpointCreator	Contains a factory method to determine which kind of PseudoBreakpoint type to create depending on the programming language in use.	None	static PseudoBreakpoint factoryMethod(IResource resource, String typeName, int lineNumber) - Determines which PseudoBreakpoint type to create
debugassist.pseudobreakpoint	class PseudoBreakpointJava extends JavaLineBreakpoint (Internal Eclipse JDT breakpoint representation) implements PseudoBreakpoint	A class to represent a Pseudobreakpoint for Java.	None	public PseudoBreakpointJava(final IResource resource, final String typeName, final int lineNumber) - (constructor) - Creates a breakpoint representation, and marker (for use in the text editor); String getMarkerMessage(boolean conditionEnabled, String condition, int hitCount, int suspendPolicy, int lineNumber) - Modifies the name of the Pseudobreakpoint (for identification only);
debugassist.pseudobreakpoint	class PseudoBreakpointPython implements PseudoBreakpoint	A class to represent a Pseudobreakpoint for Python.	None	Incomplete
debugassist.pseudobreakpoint	class PseudoBreakpointRulerActionDelegate extends AbstractRulerActionDelegate	The delegate class used when the ruler menu action 'Add/Remove Pseudobreakpoint' is used	None	IAction createAction(ITextEditor editor,IVerticalRulerInfo rulerInfo) - Creates a new PseudoBreakpointRulerAction
debugassist.pseudobreakpoint	class PseudoBreakpointRulerAction extends Action (inner class of PseudoBreakpointRulerActionDelegate)	The class used when the ruler menu action 'Add/Remove Pseudobreakpoint' is used	None	PseudoBreakpointRulerAction(ITextEditor e, IVerticalRulerInfo r) - constructor - Creates the menu action; void runWithEvent(Event event) - the method which is called when the 'Add/Remove Pseudobreakpoint' menu item is used. Creates a Pseudobreakpoint and adds it to the Eclipse breakpoint manager or will delete the Pseudobreakpoint (if one already exists)

Design Patterns Used

Observer - Events System... Tell don't ask - slightly different...

Composite - Variable / ObjectVariable

Design Maxims Followed

Acyclic dependencies principle - There is no cycles between packages.

Don't expose mutable attributes - All collections have been modified so they are returned as unmodifiable collections. While it does not provide any additional security, it avoids the data collections from being accidentally modified.

Avoid equals - There is currently no equality test between objects. For example, variable objects are only created once and stored in a collection. Nothing else could ever be exactly the same (even if the variable contained the same name, type and value) - it would be a different collection time.

Getters and setters - All variables are hidden and only accessed by the minimum required getters and setters. For example, a variable can never change its name once constructed (so only a getter), but it can change its value (both getters and setters)

Single responsibility principle - Each class have a distinct and separate responsibility.

Hide your decision - Collections are hidden behind the most generic type possible (eg list etc).

Design Maxims Considered

Singleton - In the initial designs there was a lot of Singletons used (example here: .....). However, as the design progressed, it became obvious that this was not entirely necessary. Rather than have a Singleton for each of the classes, only a single singleton was required (in the Activator class). Whenever the plugin is loaded, the Activator class is loaded (this and that happens)... When the plugin is closed, Eclipse also tells the Activator class to shutdown (removing all references to all the other objects) - and thereby clearing the memory.

Design Maxims Violated

Big design up front - There has been three (documented) iterations of development. This project began out of prototyping and evolved into the current product, it was therefore impossible to complete a big design up front as I was unaware of what I would need down the track.

Avoid inheritance for implementation - PseudoBreakpointJava extends Eclipses Java Breakpoint implementation to provide our PseudoBreakpoint for the Java Language. It would have been significantly harder for our PseudoBreakpoint to re-implement our own Java Breakpoint.

Don't burn your base class - The class BreakpointEventData extends Subject to provide the observer functionality (also see Avoid inheritance for implementation). I cannot think of a situation where BreakpointEventData would need to subclass anything other than Subject (famous last words.) The current Java implementation of listeners is exactly the same as my design except I use generics (I'm not saying that Java was designed well!) The BreakpointEventData class only notifies other classes when breakpoint events occur.

The Interesting(??)

• Variable / ObjectVariable / PrimitiveVariable
  • Class Encapsulation: Is broken. Variables within the 'Variable' class are marked as protected so subclasses can access them.

Media:jra82_design3.jpg

Installation

1. Download & Install Eclipse 3.5.2 (with SDK)
2. Extract the zip file of my project
3. Run Eclipse
4. Click File -> Import -> Existing Projects into Workspace
5. Select root directory of extracted plugin
6. Click Finish
7. Create a new Run Configuration: 'Eclipse Application'