• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

Some details about my solution

Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Section Max Actual Points Points
General Con: 100 90
Documentation: 70 65
OOD: 30 30
GUI: 40 31
Locking: 80 80
Data Store: 40 40
Network Server: 40 30
Total: 400 366

Some details about my solution

Urlybird 1.3.3.

The application is three-tier.

First, I have a class Record around the String[]
instances which are used by the DBMain methods and represents a occupancy.
Using a wrapper is a simple way to remember and manage the relevant
information associated with a occupancy.


The class Data acts as the facade to the back-end tier.
The class Data is the back end's backbone. There are several instances of Data, one for each client. This is the easiest way I found out to be able to tell whether a record has been locked by the current Data instance or not.
I just associate a record with a locker (a Data instance).
The Data class methods do not lock or unlock a record. Lock / unlock methods in the Data class are called by the DataFacade, the wrapper around Data.
The lock / unlock / isLocked methods delegate to the LockManager, delete / update / read delegate record access to the class RecordManager.
Update and delete will throw an exception if you are trying to perform the operation on a record which is not locked.
The create method is synchronized on the Data class, so that only one thread
is allowed to try and create a new record at any given time.

LockManager helps implement the lock , unlock and isLocked methods in the Data class. Internally, in lock manager, that happens through a Map.
The Map instance maps an Integer (the record number) to the Data
object which is holding the abstract lock (locker), if there is any.
LockManager is a singleton and is referenced by the Data class.

The RecordManager singleton manages access to the file. Its methods are synchronized. RecordManager contains two caches. One cache (recordCache) contains the records which are read from the file, the other the list of currently deleted records.


The DataFacade interface is the interface which exposes business methods to the client

The DataFacade interface provides the business methods that the gui needs at this stage. The client needs to book, unbook, and search for records.
The gui should not deal with locking and data consistency issues,
this is done inside of the DataFacade implementations.

The DataAdapter is a local implementation of DataFacade which wraps an instance of the Data object.
The RemoteDataFacade interface extends Remote and DataFacade
The RemoteDataFacadeImpl class extends DataAdapter, and implements RemoteDataFacade. It is exported through UnicastRemoteObject.export. I chose to make RemoteDataFacadeImpl a subclass of DataAdapter because it "is" a remote DataAdapter.

The RemoteFacadePool is the other Remote object. It manages a pool of RemoteDataFacade object. A client talks to the RemoteFacadePool on the server and tries to get a RemoteDataFacadeImpl from its virtual pool.
If none is available, a TooManyConnectionsException will be thrown.


DataFacadeBridge hides the connection and the implementation details of DataFacade, so that the GuiController does not need to know if it is running locally or connecting remotely.
It just asks the DataFacadeBridge to give him an instance of DataFacade.

GuiController works as a mediator between the view, the bridge to the DataFacade implementation and the model.
RoomTableModel is the model containing the actual data about the occupancies.

View is the proxy to the View. View is implemented by
MainWindow. View exposes the methods that the controller
needs to interact with the user.
Having View as an interface provides flexibility if the Gui ever needs to be reprogrammed.

MainWindow implements View as a JFrame with a Menu, a ToolBar, and four panels. Two JSplitPanes are used to separate the panels.

The MainWindow's constructor is passed the following parameters :
- The title
- The TableModel for the JTable
- An ActionGroup instance, which is a wrapper class containing the Actions and the Listeners that have to be associated with the widgets inside MainWindow

All actions and listeners have a reference
to the controller. The GuiController has a reference to a DataFacadeBridge, to a View and to a RoomTableModel. The View does not know about the controller.
[ March 19, 2005: Message edited by: Diego Amicabile ]
Ranch Hand
Posts: 329
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
well done and thanks for details
author and jackaroo
Posts: 12200
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi everyone,

There is another topic in the Sun Certification Results forum where you can post congratulatory messages to Diego.

I recommend we keep this thread for discussions regarding Diego's details.

Regards, Andrew
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    Bookmark Topic Watch Topic
  • New Topic