Martins Design Study
(Created page.) |
(Added flaws.) |
||
| Line 17: | Line 17: | ||
A diagram of the initial design of the reporting interface is shown below. | A diagram of the initial design of the reporting interface is shown below. | ||
| − | + | [[Image:martins-original-diagram.png]] | |
=== Flaws === | === Flaws === | ||
The flaws in the initial design include the following: | The flaws in the initial design include the following: | ||
| + | |||
| + | * ActivityCategory is not linked to the report. | ||
| + | * The ActivityReportWizard class does not allow the containing of sub-forms. It is all packed into one huge form. This is inconvenient - it would be good to allow a wizard with multiple forms. It does allow for one page, but not many. | ||
| + | * The ActivityReportWizard class and ActivityReportWizardPage class both contain the ActivityReport object, making changes to it. This does not smell right! | ||
| + | * ActivityCategory is unused! This class is supposed to dictate which metrics appear in the report. | ||
| + | * ActivityCategory should perhaps be either a [[Composite]] or a [[Decorator]]. It is neither at the moment. | ||
== Improved Design == | == Improved Design == | ||
Revision as of 22:57, 27 July 2010
Contents |
Overview
My design study is about the reporting interface for my group (Team Patchwork's) Eclipse plugin which we designed last year. I wrote the reporting interface myself, but without using good OO design. Although it worked, it is a little bothersome to extend (I.E. to create new types of reports or new views an layouts. Hence, I decided to analyze and improve it somewhat.
Use Cases
The reporting interface would be used as follows:
- The user should be able to generate a report for any date range.
- The user should be able to generate a report for any metric defined by the plugin.
- The user should be able to edit an existing report, by changing the date range. The report display should update to reflect the new date range.
- The user should be able to add or remove metrics from an existing report. The report display should update to reflect the new date range.
- The user should be able to save a report as some sort of file (XML, CSV, anything will do, really).
Initial Design
A diagram of the initial design of the reporting interface is shown below.
Flaws
The flaws in the initial design include the following:
- ActivityCategory is not linked to the report.
- The ActivityReportWizard class does not allow the containing of sub-forms. It is all packed into one huge form. This is inconvenient - it would be good to allow a wizard with multiple forms. It does allow for one page, but not many.
- The ActivityReportWizard class and ActivityReportWizardPage class both contain the ActivityReport object, making changes to it. This does not smell right!
- ActivityCategory is unused! This class is supposed to dictate which metrics appear in the report.
- ActivityCategory should perhaps be either a Composite or a Decorator. It is neither at the moment.
Improved Design
A diagram of the improved design of the reporting interface is shown below.
TODO.
Patterns Used
In the improved version, I used the following design patterns:
TODO.
Discussion
The design project was to improve the reporting interface for the "Team Patchwork Reporting Application". TODO.
