I'm quite far down the line with the FBN assignment and have researched quite a lot of books regarding some of the issues that I've come across within the requirements. The Habibi et al book has been very useful and has helped along the way on some of the topics regarding the certification.
The reason for this e-mail is to request a brainstorm on my current design to see whether or not there is anything missing that someone has come across during the submission or any other advice that would be helpful.
The system
pattern is based upon the MVC, as I find this quite flexible for future enhancements, encapsulating the three logical areas into behaviour based division.
Within the "view" package I have a GuiTableView class that basically displays the data extracted from "model" to the user and captures user interaction. The fine details of gui design is still being considered.
There is also an array of GuiViews so that the refreshGuiViews() method can be used to update any "views" implemented. At present, the FBN says that the database updating the ui is not required (although optional) but to make this model flexible for the future I have decided to include it.
Within the "controller" package I have a GuiTableController that basically captures events from the GuiTableView and interacts with the "model" via the DatabaseModel.
Within the "model" package I have the DatabaseModel, which basically is a facade in providing the GuiTableController (or any future controllers) with a class that handles the locking and unlocking of records. The DatabaseModel hides the true database from the controllers (by wrapping it via the DatabaseClient) and in doing so can easily be amended to become an adaptor and therefore a future database can be introduced with a little modification.
Within the "model" package is the "db" (original Sun) package that holds the three supplied classes; Data, DataInfo and FieldInfo. I've amended the Data class to include the three required new methods and introduced a DatabaseClient interface, including all public methods, so that the database itself is further hidden from the outside world. The DatabaseClient plays an important role as it is used by the DatabaseModel to interact with this variant of the database.
Also within the "model" package is the DatabaseConnector that programmatically creates a local or remote connection.
Within the "db" package, apart from the introduction of the DatabaseClient, the locking mechanism is based upon recording the record in question within a Vector. This is very similar to how Denny's DVDs works within the Habibi et al book. By the way, the Data class now implements the DatabaseClient interface.
Question: Are there other types of locking mechanism that can be used or preferred? I find this one very simple to use and easy to code.
The decision to use RMI was preferred over sockets and I've introduced a "remote" package to hold the RMI classes. The DatabaseClient is used again and the DatabaseRemote interface extends the DatabaseClient and Remote interfaces. The DatabaseImpl class implements the DatabaseRemote interface and also holds a reference to the Data class.
Going back to the DatabaseConnector, the getRemoteConnection returns a DatabaseClient that is an instance of DatabaseImpl, which in turn invokes methods on the Data class. The getLocalConnection returns a DatabaseClient that is an instance of the Data class.
I think I've covered everything as far as I am with the assignment. At first I thought that the introduction of the DatabaseModel was a bit of an overkill but it does separate the "model" from the actual database and therefore the "model" can interact with different databases depending upon the implementation. It looks so much easier to understand with a class diagram!!!
Is there anything I should know about the FBN assignment that could come back and haunt me?
Any comments would be helpful.