Overview

The Hotel Management System is implemented as two stand-alone Java applications capable of running over a network.

The server application loads all of the previous data into memory upon start up and waits for instructions from the client application. The client application consists of the graphical user interface and is event driven. Messages are sent to the server as commands that are then executed and return data displayed to the user via the interface. Updated/new data is stored in the memory by the server application.

Upon termination of the client application, the server stores all of the current data stored in the system to disk to keep a permanent record. This data is retrieved when the application is run again.

Since the system must "know" the current date and time, the multi-threading feature of Java is used to create a date/time object that continually updates the system's date and time. This is also displayed on the user interface at all times.


Networking

The networking side of the application was implemented by using the port/socket model of a network and was coded to represent this.

Firstly, the server application sets up a socket and then listens for the client application to connect :


System.out.println("  Waiting For Connection.......");

ServerSocket listener = new ServerSocket(INPORT);
Socket s = listener.accept();
System.out.println(" Connected To Client");

INPORT is a constant used to assign the port number to be used. This is set as port number 5000.

The client application then sets up a socket to connect to the server application :


Socket t = new Socket(server, OUTPORT);

Again OUTPORT is a constant used to assign the port number.

Input and output between both the server and client applications is achieved by use of two different port number - one for each direction of data transfer - port numbers 5000 and 5050. Input and output can be achieved by associating ObjectInputStream and ObjectOutputStream with the desired input and output streams of the socket :


ObIn = new ObjectInputStream(s.getInputStream());

ObOut = new ObjectOutputStream(s.getOutputStream());
(Server application)


ObOut = new ObjectOutputStream(t.getOutputStream());
ObIn = new ObjectInputStream(t.getInputStream());
(Client application)

Once this structure has been initiated, transfer of data between the server and client applications as user-defined objects is relatively straight-forward by use of the standard java.io package.

Objects can be written out to the network by the use of the writeObject() method :


ObOut.writeObject(r);

A similar method is used to read in objects using the readObject() method, but the object read must be cast to the correct object type using the cast operator :


c = (Customer) ObIn.readObject();

When the applications terminate, the socket is simply closed using the close() method :


t.close();


Data Types

Several different data types are used within the system. These provide an efficient method of storing complex data in an easily accessible way.

The hotel management system implements its own defined classes to represent real world objects that form an integral part of the hotel. Customers, rooms, table, bookings and bills all have their own associated classes. Each class has its own attributes and several constructors to enable instances of these classes to store information about the hotel and the future state of the hotel.

Hash tables are used throughout to keep a record of the data within the system. They provide a useful method of storing and retrieving instances of classes. Each object has a corresponding unique key that is used to access it from the hash table. This key can be made from the object itself making each object individual, but not allowing for duplicates of objects since they reference the same place within the hash table.


Algorithms

Several interesting algorithms are used within the coding of the Hotel Management System, but by far the most interesting one is the following :


FileOutputStream ostream = new FileOutputStream(CUSTOMERDATAFILE);

ObjectOutputStream fout = new ObjectOutputStream(ostream);

for (Enumeration e = ht_customer.keys(); e.hasMoreElements();)
{
Object name = (Object) e.nextElement();
fout.writeObject((Customer) ht_customer.get(name.toString()));
}

fout.close();

This is used in the closing down routine of the server application to search through the hash tables storing all of the information about the state of the hotel and then save that information to a file.

The algorithm makes use of an enumeration to sequentially step through each record within the hash table. If a record exists, it is written out to the file and the next record is then checked. This is a good algorithm because it accesses the objects stored in the hash table without knowing their unique keys, yet does not take much code. All of the objects will be accessed by the enumeration until there are no more objects remaining unchecked, and the file will then be closed. This could not be possible without the use of the enumeration interface.

Another interesting piece of code is used to allow the objects associated with the hotel to be transmitted over the network :


public class Customer implements Serializable {}

The serializable interface allows objects to be serialised so that they can be sent over a network structure. This makes use of the readObject and writeObject methods. Any class that needs to be sent over the network must implement the Serializable interface, otherwise an error may occur.

When objects are read in from the network, they need to be cast to the correct object type so that the classes fields can be restored correctly. This can cause problems if objects of different type are being sent and their type is not known in advance. To overcome this, a class ObjectType has been implemented which is sent across the network before any other object is sent. This allows the server/client application to determine the incoming object type before is reaches the application so that it can be cast to the correct class type.

The class ObjectType has two fields, both of which are strings. The first represents the type of the following object to be read in. The second string provides arguments for the application so that it knows how to process the incoming object. This class was implemented to aid in the transmission of objects over the network to reduce errors encountered by the system.


User Interface

The graphical user interface consists of six panes that can be accessed by means of tabs situated at the top of the window (figure 5.1). These panes contain all of the information about each aspect of the system and are linked together so that all of the information about a particular customer's stay can be accessed.


Figure 5.1 : A screenshot showing the tabbed panes of the display window

Figure 5.1 : A screenshot showing the tabbed panes of the display window.


Controls situated on the panes, along with the mouse-driven menus contribute to the overall control of the system.

Every system function can be accessed from this user interface which acts as a front end to the system with which the user interacts. This interface is part of the client application that communicates with the main server application when any actions are taken.


Testing

Testing has been done on both the server and the client applications to a basic level. Run time errors have been checked wherever possible and caught using the "try�catch" structure.

When any external file is accessed, either for input or output, error checking has been added in case the file cannot be found. If this is so, the file is either assumed to not have existed before, or another file is created.

When network errors occur, the connection is closed and all data is saved to file. Since this is done at the server end, the amount of data which can be lost is minimal and amounts to only one record's worth (if it cannot be sent to the server from the client application).

The majority of error checking involves the graphical user interface (eg. checking that the date entered is a valid date). This is implemented within the client application before any communication with the server application commences.

The system has been designed to be fully Year 2000 compliant and works fine with any date (but is set to work only with dates before 31st December, 2100 - this can easily be modified).