Development Phase
Summary
Development phase is nearing completion. The authors hopes to have the first version ready by Monday, ready for testing with undergraduates. Again, if anyone is interested in testing this tool please e-mail the author (use the contact form above).
User Interface and Swing
The author has learnt Swing concurrently with developing the interface. There was a reasonably steep learning curve to overcome as a WYSIWYG IDE wasn't used to implement the GUI. Instead, the author has used Eclipse which is a fantastic IDE for Java.
Note that the toolbar and the (blank) menu bar have yet to be implemented. The bottom right hand area of whitespace is reserved for some shortcut buttons and a preview window of the rule selected in the top right.
Back End
The backend is all but complete; small bugs are being ironed out as the GUI is developed. This is because the GUI is being built to fit around the "back office" aspect of the project. Inspired by the MVC model, the back end will be almost entirely seperate from the front end in the sense that someone wishing to re-write the GUI will theoretically be able to.
Rule Compiler
The rule compiler is fully implemented in JavaCC and is ready to be included in the final release of the project, save for documentation (see below).
Documentation
Documentation has yet to begin. Code is commented in such a way that the author can document the code at a later stage. It is expected that a full JavaDoc of the project will be available should anyone wish to develop or extend the project.
Methodology
Following design work over Christmas, the development has been conducted in a code-and-test manner, similar to the XP methodology.
23 Feb 2006 01:20
| 
Comments (3)
| 
Report a problem
Loading…
Chris May
{pedant} If it was similar to XP it would be test and code not code and test. XP says "Write no functionality until there's a failing unit test for it".
But I get what you mean. Plus, if you're going down the XP route you could aways write "No documentation will be produced, similar to the XP methodology" and save yourself a few hours of boring javadoc-ing :-)
23 Feb 2006, 08:17
How do you test something that you have not yet coded…?
Anyway, unfortunately I suspect that Javadoc-ing is a requirement :)
23 Feb 2006, 09:49
Chris May
You write the test, which won't compile. Then you write a stub implementation which allows the test to compile but doesn't actually do anything (so the test fails). Then you write just enough code to make the test pass. Then you think about what's still missing, and write another test. Iterate until you have an application.
Chapter 18 of 'XP Explained' outlines the process, but Kent Beck's Test Driven Development: By Example is a better reference.
Personally I find this approach to be sometimes very useful, but mostly a PIA. We tried doing XP in elab on a couple of smallish projects, but eventually switched to the less rigourous Crystal Clear which I find to be a bit more 'humane'.
23 Feb 2006, 10:38
Add a comment
You are not allowed to comment on this entry as it has restricted commenting permissions.