I am one of the silent observer of the group. I benefited lot from this forum. When I stuck, answers from this forum energized and get me going. Glad I didn't give up. Thanks for everyone in this forum.
Here's the breakdown of my URLyBIRD 1.3.3:
Section Summary: Section Max Actual Points Points
General Con: 100 95
Documentation: 70 70
OOD: 30 30
GUI: 40 28
Locking: 80 80
Data Store: 40 40
Network Server: 40 40
Total: 400 383
I think I lost some points in GUI, because I didn't make the entering and deleting customerId user-intuitive. Besides I didn't make special effort to make it pretty.
Here's my approach:
- 3 layered architecture
- used RMI for network communication (Reason: extensibility, reduced coding and testing, multi-threading, thread pooling)
- Support for provided Database Schema only. However used a Singleton class to load the DBSchema information. Not hard-coded.
Checked magic number version before accepting a input db file.
- Added several Runtime Exceptions in addition to DBMain interface defined exceptions.
- Several edge conditions are checked (no write permission for a file, given input db file doesn't exist, invalid magic number in db file,
network server not running, network client error handling when network server not running)
- Layered exception handling. Nicely abstracted low-level exceptions with nice user-friendly messages and re-thrown to high level exception. Added log messages, if I happened to suppress exceptions.
- Made the application configurable. For instance implemented 48 - hour rule in Business Layer (Used Business Delegate and Service Locator J2EE patter). However user given option to turn it on or off at their will.
- Extreme measure has been taken not to hard-code anything. Even 48-hours rule can be configurable to a 36 hours rule if needed. In addition GUI label texts are read from application constants class.
- Used about 10 design patterns in my projects. Everyone knows about what pattern to use at what layer. If someone has specific questions please reply to this post.
- Extensive unit testing has been done to test Locking. I used the unit test provided within the forum. But I had to fix several bugs before able to use it. Let me know if someone need my version.
- Also I have working version of ant script that packages the application, as requested by SUN. I highly recommend future test takers to use it because it prevents manual errors. You are free to make any changes within the project and the build script will consistently build project. Also unit test within the build script verifies the correctness of the submission. This is is great. Thanks to the contributing author.
- Documentation. I have to reaffirm again, this is as important as your code. Take extra time to check for spelling, clarity and please make sure you documented all assumptions you have made. It took me at least 12-16 hours to document. So please give enough time to prepare.
Last but not least, please take time to prepare for the follow-up exam. It gives second opportunity to impress the examiner. Also you have another chance to add stuff you forgot to mention in your choices.txt.
Here's the list of question that you should at least be prepared to answer:
Describe your record-searching approach.
Describe your record-locking approach.
Describe how your certification project handles errors.
Describe whether you extended or modified the supplied classes, and include a justification of that choice.
Describe what you did with deprecated methods in the supplied classes.
Describe how you used design patterns.
Describe your choice between RMI and sockets, and include a justification of that choice.
Describe your network server and how you used it in your solution.
Describe how you designed the GUI, especially the JTable component.
Describe how your GUI handles events.
Describe how your GUI communicates with the database.
Describe how your design uses multithreading.
Describe how your design addresses future modifications.