Outline Class Diagrams for RoboTracker, v0.7.5

The following diagrams describe, without a paranoid attention to accuracy, implementation details for RoboTracker version 0.7.5. Some day, I will create sequence diagrams and use cases and all sorts of other lovely uml diagrams. These diagrams were produced "post-facto" - hence, they were not used in generating the design. The design methodology attempts to follow the ideas of "Test-Driven Development" although I haven't done this before so the results might be curious ...

Thanks to the makers of ArgoUML for enabling the creation of these diagrams, and to the makers of The GIMP so that I could capture them (it would be great if I could save pictures from ArgoUML, but then I wouldn't have a reason to use The GIMP, so maybe it wouldn't be so great ...)


TopLevel:

This diagram shows the top-level interfaces representing user objects (task, story, taskswitch). Each object has a single UniqueID. All objects except "RootNode" implement "Persisted"; RootNode doesn't need to, because it is never persisted. "Story" and "Task" implement "NamedNode", but "TaskSwitch" doesn't. Story and Task objects participate in a hierarchy, and have names. A TaskSwitch is simply an association between a Task and a moment in time.

ApplicationObject:

The "Application" object is a container for each of the major system objects: Factory, Persister, Reporter objects, and the BeanShell Interpreter. Factory defines all relevant methods for creating or finding objects; Persister simply provides hooks for other parts of the system to listen to create or update events; Reporter objects create reports, evidently; and the BeanShell is used to run functional-test scripts. If it is ever necessary to create demonstration scripts or to use complex user startup scripts, the BeanShell will be useful in those contexts also. Using BeanShell for functional testing appears to be simpler and more flexible than using other libraries designed for Swing GUI testing. In most cases, these libraries are script-based too, except their script languages are more restrictive.

PersistenceSystem:

This diagram shows the provided implementations for Factory and Persister (SQLFactory and SQLPersister, respectively). "PersistedTreeNode" provides a partial implementation of "NamedNode"; some details are left to subclasses ("SQLStory" and "SQLTask"). PersistedTreeNode is an abstract class; however if I mark it abstract the italic font used to denote abstraction is unreadable. So I'm telling you here instead. The naming is unfortunate for two reasons: firstly, "PersistedTreeNode" doesn't actually do any persisting, it only provides implementation for parent/child relationships, and getters and setters for "id" and "name" properties. Secondly, everything else in the package has SQL prefixed to its name, which is a little annoying. Suggestions for an alternative naming scheme will be listened to :))

TaskImplementation:

This diagram shows the SQLTask class, as well as the MockTask class, which is part of the testing framework.

StoryImplementation:

This diagram shows the SQLStory class, as well as the MockStory class, which is part of the testing framework.

TaskSwitchImplementation:

This diagram shows the SQLTaskSwitch class, as well as the MockTaskSwitch class, which is part of the testing framework.

ReportSystem:

This diagram shows the reporting system. It's not quite accurate (there isn't actually an interface called "Reporter"; the class "AbstractReporter" is really called "Reporter"). But these aren't the only inaccuracies on this page, so not to worry. The Application object maintains a list of Reporter objects; the ReportDialog presets a list of all known Reporter objects to the user who can then select the kinds of report required. A Reporter is a relatively simple object - it expects a Factory to be provided to its init() method, and then it provides text to the caller of its "report" method. The "report" method takes three parameters - the set of Tasks on which to report, a start date, and an end date. A Reporter also has a "name" method, so it can be identified to the user. With a small modification, the reporting system can be made fully pluggable; after such a modification, all the user would need do is provide Reporter implementations on the classpath and add the classnames to the list maintained by the "Application".

todo:
  • testing system;
  • swing GUI