Wow, I did not expect to receive a perfect score on my
SCJD assignment! While I was working on my solution I know that I looked at the results of others here to see what they did right, what improvements could have been made, etc. so it is now my turn to give back to the community here. I spent about seven days designing and developing the application and then three days reviewing it, adding to my choices.txt file, writing the manual, and making sure that I had all my files in the correct location. Be sure to read the requirements carefully!
The resources I used were this forum (most helpful) and I remember reading through the CD included with the
SCJP book by Sierra and Bates. It took six weeks to get results.
Section Summary:
General Con: 100 100
Documentation: 70 70
OOD: 30 30
GUI: 40 40
Locking: 80 80
Data Store: 40 40
Network Server: 40 40
Total: 400 400
Perfect Score - Excellent job.
Design
I chose a three-tier design with a database layer, a business logic layer, and a GUI layer. The database layer had an interface to interact with the raw flatfile format and abstract it in terms of records. The class that implemented that interface made it specific for the URLyBird record format I was given. Higher up in the database layer, I had classes that implemented my DBMain interface (provided by Sun) and a RemoteDBMain interface (defined by me - it was basically a copy of DBMain but its methods threw RemoteExceptions). There was also a lock management class here that maintained the integrity of the database with respect to concurrency concerns. 1300 lines.
The business logic layer had a ReservationManager interface that exposed the methods that I would use in the GUI. The implementing classes where LocalReservationManager and RemoteReservationManager, which used a DBMain and RemoteDBMain as data accessors, respectively. The notion of records was also abstracted into Reservations. 950 lines.
At the top, the GUI layer had an abstract frame that displayed most of the information. It had two subclasses - one for local mode and one for remote mode. These would create the appropriate ReservationManager type and also do a little bit of customization (e.g. the remote mode frame would display the server host and port). 1400 lines (Swing sucks).
More about the GUI
It seems that people have typically received scores of 32/40 on the GUI so I'll elaborate on this point. My GUI was very simple. I had a JMenuBar that had only an Exit option, my JTable was very simple and did not allow for reordering of columns (however, since it was very easy to enable row-sorting, I turned that on). In fact my code for the JTable was super simple - every time I got new data from the database, I would create a completely new table model, populate it with the new data, and swap the JTable's models, leaving the old one to be GC'd.
I really didn't have anything fancy. The nicest features I had were that I loaded the native LAF and instead of clicking Search to execute a query, you could press Enter inside of my search fields. No progress bars, connection states, etc. I did remember to save the server IP, server port, and database file location within the suncertify.properties file. (Some of these properties wouldn't be changed, depending on the context.) The Properties class was great for this.
In a nutshell, be sure to handle all of the error cases, and try to have just a few features that are easy to use.
Locking and thread-safety
I thought that this part was easy but I had done some OS kernel work a few months before working on my SCJD project, which probably helped. In short, there are two levels where concurrency can bite you. The first is at the data storage level. If two concurrent requests to write to the database end up writing to the same location you're going to be in trouble. (On a side note, I did reuse record numbers of deleted records. Think of record slots like slots in a CPU cache, page table, database buffer, etc.) A higher level problem exists with the reservation management. This is why the DBMain interface provides locking and unlocking methods. Again, this is similar to recurring themes in computer science, like pinning.
Miscellaneous
My user's manual was a simple HTML document which let me link to other parts within the document from a table of contents. Some CSS made it look nice.I JavaDoc'd every method and class, even if they were private. My comments were solid, for lack of a better word. There weren't too many one-sentence comments, and I also made sure to fill in all the @param, @return, and @throws tags. This is probably why my line count is high.In my JavaDoc I included a UML class diagram (basically a bunch of boxes representing my classes and their relationships). I spent about an hour with NetBeans reverse-engineering my final source into a UML diagram and then fiddling with it to hide all of the class methods and clean things up into a decent-sized image.I was thorough during my written exam. I feel that writing concisely and with clear English (I took my exam in the US) would only make it easier for the reader to understand my points. This applies to the JavaDoc comments, choices.txt, and user's manual as well.
And thanks for posting comments on your solution. These are quite helpful to those of us still working on the assignment.
