James Ashford Design Study
m (→My Project) |
m (→Design Study) |
||
Line 29: | Line 29: | ||
= Design Study = | = Design Study = | ||
− | + | ||
+ | == 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
- 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