4. Design

Figure 4.1.1

The client user program will take direct input from the user through the keyboard and mouse.

Communication will take place between the client and the server, to allow retrieval of any information necessary so that the user can access the viewers, and ultimately the actual data of the database.

There is a local cache of previously used viewers, so that the same viewer does not need to be downloaded more than once.

There are issues involved with the client user program, relating to the versioning of downloaded viewers. A mechanism needs to be implemented to allow viewers that are currently in the cache, to be updated as necessary. A version number and last updated date should suffice.

Other issues relate to communication with the server, which needs to be controlled so that information is not mixed up by sending multiple commands at any one time.

Figure 4.1.2

The server program will take direct input from the user through the keyboard and mouse to allow it to be started. Once started, it will read data from the template database and viewers, and communicate with any attached clients, with the only other user input being needed to stop the program when all users have disconnected.

Figure 4.1.3

The tool will take direct input from the user through the keyboard and mouse.

It will read in viewer data from local files as necessary, and read meta-data from the data databases. Templates for each object, along with any options necessary, will be stored within the template database.

The data and template databases may be stored locally, or externally, as the JDBC mechanism will work with either.

Each package has one or more public classes that can be accessed from outside the package and a standard naming convention is followed throughout. All classes within a package that contain methods have their names prefixed with ADBV. Any classes that only store data, and as such, do not need any methods, do not have the ADBV prefix.

This package contains the classes needed for the Client program. The class ADBVClient can be executed to start the Client program. This package also contains the public interface ADBVViewerInterface, which must be implemented by all viewer applications.

ADBVClient

This is the main client class to be executed. It creates a user interface, with which the user can select the server with which to connect. It contains functions to allow some of other client classes to access the cache and retrieve current information about server connection information.

ADBVClientCache

This class contains all of the information about cached viewers. The details about each viewer are stored in instances of the CacheInfo class (see below).

ADBVClientClassLoader

This class contains functions to allow creation of a specific Java class from an array of bytes.

ADBVClientClassThread

This class contains three main functions that can be accessed by an external viewer. These form part of the ADBV API, which is explained in more detail in the User Documentation presented in Appendix 3. One version of this class will be created for every viewer loaded, to act as an interface between the selection window (ADBVClientWindow) and the viewer itself. ADBVclassClosing should be called by all viewers when they are closed by the user so that ADBV will not try and stop them itself. ADBVgetConnection allows creation of a java.sql.Connection object to the database containing a specific table and using a specific user name and password if necessary. ADBVgetTblName returns the table which was selected to start this viewer (e.g. this is useful if one viewer is used for more than one table, as the Default Viewer is). println can be used by the viewer as well, to allow a message to be displayed in the main client window. The other functions allow the calling ADBVClientWindow to communicate with each class thread, such as to stop it. Each thread is also given a unique identifier to allow it to be distinguished from other threads easily.

ADBVClientWindow

This class creates the window that will be the focus of the user. It allows them to select a table for viewing and start up the related viewer. Many of these public functions are called from ADBVClientClassThreads. Some just pass on the call to the related ADBVClient to do the actual processing. Other functions allow the calling ADBVClient to communicate directly with this selection window.

ADBVDefaultViewer

This class implements the ADBVViewerInterface defined below, and just displays whatever table is necessary using a standard list view type display. The file ADBV.gui is also required for this class to be used successfully.

ADBVViewerInterface

This interface must be implemented by all viewer applications. It forms the basis for the ADBV API, which is explained in more detail in the User Documentation of Appendix 3. ADBVsetClient is called to allow the viewer to communicate directly with the client program. ADBVstartView is called when the class has been loaded and created, and after ADBVsetClient has been called. ADBVstopView is called by the client if the viewer has to be closed down automatically (e.g. if the user logs off from the server without closing down the viewer).

CacheInfo

This class is used by the ADBVClientCache class above to store details about each viewer currently in the local cache.

ClassInfo

This class is used by the ADBVClientWindow to store details about each of the currently executing viewers and the ADBVClientClassThread class associated with them.

TableStore

This class is used to store local information about each table that the client can view. Each table entry is then added into a Vector data structure.

This package contains the classes needed for the Server program. The class ADBVServer can be executed to start the Server program. Once the server has been started, it starts listening for clients using a single ADBVServerListener thread. For every client that then connects, a new ADBVServerThread structure is created with which the new client can communicate directly.

ADBVServer

This is the main server class to be executed. It creates the user interface to allow connection to a template database, and starts a single ADBVServerListener thread to wait for clients wishing to connect.

ADBVServerListener

This class runs as a separate thread, to listen for clients wanting to connect to this server. Once a client is accepted, a new ADBVServerThread process is created and the client is directed to talk to that process directly. The clientsConnected function returns a boolean to say whether any clients are currently connected. The stopThread function is called by an ADBVServerThread when it wishes to be stopped (i.e. when its associated client disconnects). The stopListener function is called by the main ADBVServer class to stop this process from listening for any more clients.

ADBVServerThread

For each connected client, there is one instance of this class. Communication between the client and server is done through this instance, and all commands are picked up by the run method within the thread, which then passes any command arguments on to a separate function to execute the command.

TableStore

This class is used to store local information about each table contained in the template database. As with ADBVClient.TableStore, each table entry is then added into a Vector data structure.

This package contains the classes needed for the Tool program. The class ADBVTool can be executed to start the Tool program. The tool allows templates to be set up for one or more data databases within any one template database.

ADBVTool

This is the main Tool class to be executed. It creates the user interface to allow connection to any template database, or displaying of the editors necessary for editing templates and their associated viewers.

ADBVToolConnect

This class creates a window to allow selection of the data database to create templates about at any one time.

ADBVToolOptions

This class creates a window to allow updating of the options about the current template database.

ADBVToolTemplates

This class creates a window to allow editing of the templates contained in the current template database. On entry to the screen, the user is presented with the ADBVToolConnect window to make the initial data database connection.

ADBVToolViewers

This class creates a window to allow editing of the viewers to be used with the templates contained in the current template database.

ClassStore

This class stores a copy of all of the information about the viewers loaded into the current template database. This allows the information to be displayed quickly and simply, without having to query the template database every time the details need to be viewed.

TableStore

This class stores a copy of all of the information about the templates loaded into the current template database. This allows the information to be displayed quickly and simply, without having to query the template database every time the details need to be viewed.

ADBVButton

This class extends java.awt.Button to allow creation of buttons in a certain location on the screen and in a certain state with one single constructor call.

ADBVDDL

This class extends java.awt.Choice to allow creation of drop down lists in certain locations on the screen and in a certain state with one single constructor call.

ADBVLabel

This class extends java.awt.Label to allow creation of labels in certain locations on the screen and in a certain state with one single constructor call.

ADBVListBox

This class extends java.awt.List to allow creation of list boxes in certain locations on the screen with one single constructor call.

ADBVMsgBox

This class allows displaying of a message box with up to four lines of message and with three different button layouts - just an OK button; an OK and a Cancel button; a Yes and a No button. In each case, the runMsg function returns a value to specify which button was pressed by the user. This class is used throughout the three packages above to display error messages and questions to the user.

ADBVTextArea

This class extends java.awt.TextArea to allow creation of text areas in certain locations on the screen and in a certain state with one single constructor call.

ADBVTextField

This class extends java.awt.TextField to allow creation of text fields in certain locations on the screen and in a certain state with one single constructor call.

ADBVWAdapter

This class is used by all windows throughout the ADBV package. It extends the standard Java AWT window event handler allowing windows to be closed and, if necessary, notified that they are being closed.

ADBVWAdapterInterface

This interface is used by some of the windows in the ADBV package. The shuttingWindow function is called when the window is being closed, so that the related class can tidy up as necessary.

There is one external file, relating to the Client program, which is needed to store details about viewers in the local cache. This cache will store each class’ name, version and update date. To simplify reading and writing of the cache details, this file is just a flat text file, with one cache entry per line, with each of the three fields (class name, version, update date) separated by character 0.

To signify the end of the cache entries, a single ‘.’ on its own at the beginning of a new line will be placed at the end of the file.

To allow storing of template information, two database tables are needed. In addition, an extra table to store options is also needed.

T_CLASSES

Table T_CLASSES is used to store information and data about the external viewers.

It is currently created using the following SQL statement:

      CREATE TABLE T_CLASSES (
        IDCLASS        INTEGER    NOT NULL DEFAULT 0 PRIMARY KEY,
        IDPARENTCLASS  INTEGER    NOT NULL DEFAULT 0,
        CLASSNAME      VARCHAR    (255),
        DESCRIPTION    VARCHAR    (255),
        COPYRIGHT      VARCHAR    (255),
        VERSION        INTEGER    NOT NULL DEFAULT 0,
        UPDATEDATE     DATE,
        CLASSFILENAME  VARCHAR    (255),
        CLASSLOADED    SMALLINT   NOT NULL DEFAULT 0,
        CLASSDATA      BLOB       (65536)
      )
      

IDCLASS stores a unique value for linking each table to a viewer.

IDPARENTCLASS stores a value to be used for linking classes together. This field is currently not used, but is included so that more than one class can be downloaded to create a viewer. The primary class will be the only one executed, and the others will be stored on the local file system so that they can be used by this primary class in the usual way.

CLASSNAME stores the name of the class to be loaded.

DESCRIPTION stores a description about this viewer.

COPYRIGHT stores copyright information about this viewer.

VERSION stores a version number for the viewer.

UPDATEDATE stores a date value signifying the last time that details about this viewer were changed.

CLASSFILENAME stores the location of where the viewer is stored on the local file system. This is currently not used, but is intended to allow databases that cannot store viewers within them to use local files instead.

CLASSLOADED contains a boolean value to signify whether or not a viewer is currently loaded into the CLASSDATA field.

CLASSDATA stores the actual Java application to be used as a viewer.

T_TABLE

Table T_TABLE is used to store the template information for each object.

It is currently created using the following SQL statement:

      CREATE TABLE T_TABLE (
        IDTABLE        INTEGER    NOT NULL DEFAULT 0 PRIMARY KEY,
        IDCLASS        INTEGER    NOT NULL DEFAULT 0,

        TABLENAME      VARCHAR    (255),
        DESCRIPTION    VARCHAR    (255),
        CON_CLASS      VARCHAR    (255),
        CON_URL        VARCHAR    (255),
        CON_USER       VARCHAR    (255),
        CON_PASSWORD   VARCHAR    (255),
        UPDATEDATE     DATE
      )
      

IDTABLE stores a unique value for each object for which a template is required.

IDCLASS contains a value for referring to the viewer to be used.

TABLENAME stores the name of the object this template to which is referring

DESCRIPTION stores a description about this object, which will be presented the client users.

CON_CLASS stores the class name of the driver to use for connecting to the data database containing this object.

CON_URL stores the URL of the database to use for connecting to the data database containing this object.

CON_USER stores the User Name for use when connecting to the data database containing this object.

CON_PASSWORD stores the Password for use when connecting to the data database containing this object.

UPDATEDATE stores a date value signifying the last time that details about this template were changed.

The two template tables (T_CLASSES and T_TABLES) are related by the IDCLASS field (Figure 4.3.1):

Figure 4.3.1

T_OPTIONS

Table T_OPTIONS is used to store details about options relating to the template database

It is currently created using the following SQL statement:

      CREATE TABLE T_OPTIONS (
        AUTO_STARTUP   SMALLINT   NOT NULL DEFAULT 0,
        PORT_NUMBER    INTEGER    NOT NULL DEFAULT 8205,
        HAS_TABLES     SMALLINT   NOT NULL DEFAULT 1
      )
      

AUTO_STARTUP stores a boolean value to signify whether or not the client program will automatically show the first template specified using its viewer, or allow the user to choose which tables to view.

PORT_NUMBER stores the value of the port number that the server program should listen for clients on

HAS_TABLES stores a boolean value that is used to show that the three tables (T_TABLES, T_CLASSES, T_OPTIONS) have been created. This value is checked each time that either the tool or the server programs connect to the template database.