IM264: Object-Oriented Concepts

Course Enrolment System

For this project I have attempted to implement a system for managing a course enrolment database, as suggested in the coursework-brief provided.

Commercial Off-The-Shelf Systems

Certain features of the required system make this a suitable candidate for a COTS (Commercial Off-The-Shelf) based system. A COTS-based system (or CBS) is constructed using commercially available software components as modules of the system. This reduces the time and effort required to implement a system, thereby extending the scope of a project that is subject to restrictions on time and/or budget. It also takes advantage of the wealth of high-quality commercial software that has now accumulated in the marketplace. Nowadays, it is no longer cost-effective to implement commonly used systems from scratch. An off-the-shelf product which has been tried and tested in the marketplace is likely to do the job equally well, if not better.

The aspects of the enrolment system that employ COTS components are described below.

1. User-Interface.

The system must present various displays to the user and must process the user's input. It would be a fairly straightforward task to implement some sort of user-interface for the system from scratch. However, developments in user-interface technology have resulted in some very sophisticated commercial user-interface systems with advanced capabilities. The recent explosion in the popularity of the World-Wide-Web has fuelled the development of web-browsers from various companies (Netscape and Microsoft in particular) to the extent that they can now be reliably used as network-based user-interfaces capable of delivering entire applications (applets) to a user across a network.

The advantage a network-based system is that it can be stored at a central location and delivered to a user as and when required. This is useful for the course enrolment system as the application can be stored on the main computer-system of the college or training company and called-up on a terminal or networked PC when a student wishes to enrol, or when the enrolment clerk needs to inspect the database. The enrolment system has thus been implemented as a Java v1.1 applet that can be retrieved and executed by a web-browser such as Netscape 4 or Internet Explorer 4, two very popular web-browsers.

2. Data Storage

The system needs to maintain a database of students, courses, payments and so on. Again, it would be possible to implement an application-specific database which would meet the system requirements. It makes sense, however, to employ one of the many commercial database systems on the market (Oracle, Ingres etc), especially since they can be accessed across a network by any system that can 'talk their language'.

The Sun Java Development Kit provides 'JDBC' (aka Java DataBase Connectivity) which allows a Java program to 'talk' in the language of databases. All a program basically needs to do is create a connection to any relational database server, transmit a string of Structured Query Language (SQL) mumbo jumbo and then read back the results. Since Java hides the platform-dependencies of the different database systems, the Java code is independent of the particular database system used and any of the widely available databases would be suitable for use in the course enrolment system.

Implementation

Two methods of implementing the course enrolment system were initially considered.

HTML -> CGI

One way to implement this system would be to use a simple HTML form to provide a user-interface to a CGI program written in C or Pascal or a scripting language such as Perl. Apart from the fact that such a system would make no use of any object-oriented technologies, there is also a significant security risk when sending sensitive information across a network using an HTML form, since the information is sent in an un-encrypted text format. For this reason, the HTML-CGI method is not appropriate to the task of transmitting payment information for this system.

Java -> Database System

A Java applet has more control over the way information is transmitted and can connect with a database system directly, by-passing the insecure HTTP system. It also has more control over the user's display and can respond to input without the need to refer to a server. Implementing the course enrolment system as an applet would therefore seem to be a sensible idea.

Enrolment Database

The first step in this implementation was to design a database to hold the required information. This could be implemented using any relational database system. The following lines of SQL code would create the tables required for the Enrolment database.

CREATE TABLE Course
 ( code CHAR(8), title CHAR(40), maxEnrol INTEGER );

CREATE TABLE Student
 ( id INTEGER, course CHAR(8), name CHAR(40),
   tel CHAR(40), fax CHAR(40), email CHAR(40) );

CREATE TABLE Cheque
( id INTEGER, number CHAR(40) );

CREATE TABLE CreditCard
( id INTEGER, number CHAR(19), expiry CHAR(5), name CHAR(40) );

CREATE TABLE PurchaseOrder
( id INTEGER, number CHAR(40), company CHAR(40), name CHAR(40), tel CHAR(40) );

User-Interface

The next step was to consider the layout of the user-interface of the applet with regard to the functionality required for the system. As suggested in the coursework brief, three displays were designed for the enroling student and three displays for the enrolment clerk.

Student Displays:     1. Select Course
                      2. Input Student Details
                      3. Completed Application Form

Clerk Displays:       1. Select Course
                      2. Enrolment Status
                      3. Unpaid Balances

Classes and Components

A number of classes, sub-classes and interfaces combine to construct the graphical user-interface components for this system. As the program developed, common features of different parts of the system were identified and new super-classes were created to represent them, thereby avoiding too much repetition of code in similar classes. The code was analysed using the Together/Enterprise development environment, which clearly revealed the connectivity of the components and helped to identify problems and inconsistencies in the structure of the system. After much tweaking and adjusting in the Java AWT, a display-layout was arrived at which remains reasonably consistent across different operating platforms (Netscape & Explorer, Windows & Unix/Linux).

Database Gateway

The final stage of the implementation was to integrate the user-interface with the database system. A 'database-gateway' class was created to handle all such interactions for the system. It contains a group of static methods which can be called from any part of the program to execute certain database query or update commands using a given set of parameters. It also contains a set of static attributes which define the database structure assumed by the program (query strings, column- headings, etc). By collecting these database-specific items into a single class, the rest of the program is insulated from any changes in the structure of the database.

Critical Appraisal

The implementation more or less fulfills the requirements of the system specification. One feature of the specification that was ommitted from the implementation was the transmission of an enrolment summary by e-mail to both the student and the clerk. This was because the author failed to find a way to get an applet to send a single e-mail, let alone two. A possible solution might be to use a CGI program as an agent to contact a mail-server, but, as noted above, transmitting the summary by un-encrypted HTTP would compromise the security of the system.

Another problem encountered during the development was that the applet and its web-browser environment did not always behave quite as expected. For example, removing a TextField component from the display and later restoring it causes side-effects which required the addition of extra code to tidy-up the display. There were also some difficulty getting the browser to provide a print-out of the final summary. This illustrates the importance of careful and thorough evaluation of potential software components when developing a COTS-based system.

Go To: IM264: Object-Oriented Concepts