James Ashford Design Study

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
m (My Project)
m (Design Study)
Line 29: Line 29:
  
 
= Design Study =
 
= Design Study =
The actual design study will go here.
+
 
 +
== Requirements ==
 +
# Maintainability - Easily add new features (such as different data sources etc)
 +
# 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 goes here
 +
 
 +
=== Description of Classes ===
 +
Class x - blah blah
 +
Class y - blah blah
 +
 
 +
== Design Critique ==
 +
This is wrong, that is wrong
 +
 
 +
== Design Improvements ==
 +
I've added this, i've removed this

Revision as of 22:37, 20 July 2010

Contents

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

A data collection point is a thinly disguised breakpoint which is handled along side normal Java breakpoints. The management side controls the creation and deletion of the data collection point.

Event Handler

Whenever a breakpoint is encountered, the following logic occurs:

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 goes here

Description of Classes

Class x - blah blah Class y - blah blah

Design Critique

This is wrong, that is wrong

Design Improvements

I've added this, i've removed this

Personal tools