I used eclipse with "checkstyle" and "findbugs" plugins. I wrote extensive junit tests which were invaluable and I can't emphasise enough the importantance of these.
I think I dropped points on the GUI because of an issue when I used JFormattedTextField to validate the customerID (as an 8 digit number) - the text field did not reinitialise properly. Other than that, I kept the gui very simple. I coded for the 48hr in the GUI. The search/getall functionality got all the records in the database.
I used a semaphore's to handle the locking (1 write and 20 reads). Each client had its own Data instance (to ensure that only the client that locked a record could unlock it). Locking was the responsibilty of a LockManager. It also handled the acquiring/releasing of the read/write semaphores.
I am not sure what I dropped points on the data store - I implemented equals() and hashCode() on my value object.
I used the following books:
Head First Object-oriented Analysis and Design Head First Design Patterns SCJD Exam with J2SE 5 Writing Effective Use Cases Effective Java
Congratulations. Can you please tell us more about the findbugs plug-in.I am also interested to know more about the JUnit tests you wrote and for which part of the system you used them?? [ April 09, 2007: Message edited by: Khaled Mahmoud ]
findbugs is an eclipse plugin which looks for bugs in java code - a very useful tool for code reviews. i used it to as a sanity check before submission. findbugs eclipse plugin
intially i wrote a prototype app with no design and no junit test. this decision cost me about 1-2 months in terms of debugging and constantly changing my design code. after a break of 6 months (i moved house), i decided to go back to the project from first principles. i looked at the instructions and formulated a set of requirements. from these i derrived my use cases (i used a freeware app called usecase maker. i then used noun analysis on the use cases to derrive the class names and verb analysis to get the operations.
i wrote junit tests for class except for the GUI (although you could use JFCUnit). i wrote 1 junit test per method in my DBMain interface. i made these junit tests as extensive as possible - testing boundary conditions, null parameters, exception handling - basically everything i could think of that would break. i created ant scripts to run these tests. once i had these in place, i found that i had the freedom to refactor knowing that i would detect any bugs introduced.
i wrote tests for each non-gui class written - some were more detailed than others - the RMI junits simply got the object from the registry and run a query.
i found testing the multithreading side difficult. i used a code sample i found in these forum's to run multiple threads and tailored it a bit.
i must admit, the best testing was done when i managed to rope in my work collegues (with the promise of buying them cream cakes!). i got them to concentrate on booking the same record simulataneously. this found a bug (a result from cut & paste from the prototype code) in my code that i am certain would have resulted in a failure. if you can prove that simultaneous booking the same record results in expected behaviour (i.e. one client books the record, the other receives are alert warning the user the record is already booked) then you can safely say the multithreading aspect works.