James Ashford Design Study
m (→James Ashford's Design Study) |
m (→My Project) |
||
| Line 1: | Line 1: | ||
= My Project = | = 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 = | = Design Study = | ||
The actual design study will go here. | The actual design study will go here. | ||
Revision as of 03:15, 19 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
The actual design study will go here.
