This section presents details of the subsystems, data structures, file structures and testing design for the system.
It has been decided to name the system the Abstract Database Viewer (ADBV), due to its abstract nature of being able to work with almost any commercial database on almost any machine around the world.
This section presents the system flow diagrams for each of the client, server and tool programs within the package, along with descriptions of and any issues involved with each program
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.
ADBV is to be written using Java, and so the data structures involved are classes and interfaces, which are grouped together in packages.
The distribution of ADBV is to be in two separate versions - Administrative and Client.
To aid control of this distribution, four Java packages have been created. Each of the three programs (Client, Server and Tool) consists of a separate Java package named using the program name prefixed by ADBV (i.e. ADBVClient, ADBVServer, ADBVTool respectively). The other package contains classes used by the user interface of each of the three programs.
The following sub-sections contain simple descriptions of each package and the data structures contained within them.
For a more complete description of each public data structure (signified by ), the accompanying disk contains documentation produced directly from the source code using a program called JavaDoc. (See Appendix 2 for information about the accompanying disk.)
For developers of external viewers for ADBV, the user manual presented in Appendix 3 contains a more complete description of all the data structures that may be used.
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.
![]() |
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. |
![]() |
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). |
![]() |
This class contains functions to allow creation of a specific Java class from an array of bytes. |
![]() |
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. |
![]() |
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. |
![]() |
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. |
![]() |
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). |
![]() |
This class is used by the ADBVClientCache class above to store details about each viewer currently in the local cache. |
![]() |
This class is used by the ADBVClientWindow to store details about each of the currently executing viewers and the ADBVClientClassThread class associated with them. |
![]() |
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.
![]() |
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. |
![]() |
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. |
![]() |
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. |
![]() |
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.
![]() |
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. |
![]() |
This class creates a window to allow selection of the data database to create templates about at any one time. |
![]() |
This class creates a window to allow updating of the options about the current template database. |
![]() |
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. |
![]() |
This class creates a window to allow editing of the viewers to be used with the templates contained in the current template database. |
![]() |
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. |
![]() |
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. |
![]() |
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. |
![]() |
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. |
![]() |
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. |
![]() |
This class extends java.awt.List to allow creation of list boxes in certain locations on the screen with one single constructor call. |
![]() |
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. |
![]() |
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. |
![]() |
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. |
![]() |
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. |
![]() |
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.
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.
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):
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.
The following sub-sections present object diagrams for each of the Client, Server and Tool programs using the data structures defined above, linked together using the following interconnects:
Each of the programs is to be continuously tested during development, followed by a test of the complete system when finished. Any bugs will be fixed if possible and the programs and system tested again.