Chapter Three

Building the Till Link

3.0 Introduction

This chapter covers the development of both programs; the Till Link software and the front end software. This includes the various problems encountered with the solutions to these problems, and also issues of both maintainability and usability are discussed.

3.1 The Till Link software

This program consists of 6 classes: Till_Link, SerialParameters, AlertDialog, PortRequestedDialog, SerialConnection, and SerialConnectionException.

Till_Link class - this is the main class in the software, it creates the visual interface, gets the parameters needed to successfully access the serial ports, opens the serial ports and sets the various text boxes in the interface.
SerialParameters class - this class stores the parameters for the serial ports.
AlertDialog class - this class creates a general error message dialog box to alert the user to any problems.
PortRequestedDialog class - this class creates an error message dialog box specifically to inform the user that the serial port being used has been requested by another program and asks if the user wishes to release the serial port.
SerialConnection class - this class creates an input stream and an output stream connected to the requested serial port. It also creates a server socket (TCP) with an input and output stream. This server socket waits for a connection from another program (the "front end" program). This data is then redirected through the serial port until a specific control character is sent from the "front end" program. The class then stops sending data to the serial port and listens at the serial port for any data being sent back. This data is then sent to the "front end" program via the server socket until a specific control character is send from the device connected to the serial port. When this occurs the class goes back to listening to the server socket and sending data received through the serial port. This continues until the Till_Link software is stopped.
SerialConnectionException class - this class creates an error message detailing the problem that had occurred.

This is how the classes relate to one another: relationships diagram

3.2 Problems and Solutions

The most complex and critical problem with changing the SerialDemo software to the Till_Link software was the changing of the data flow. The SerialDemo software was asynchronous whereas the Till_Link software was synchronous.

Having two Boolean variables solved the problem:

boolean sendingData = true;
boolean stopLink = false;

The stopLink variable was set to false and would only be set to true by a control character sent from the "front end" software. When stopLink was set to true, the Till_Link software was then terminated:

System.exit(0);

The sendingData variable initialised to true and would be changed by a control character, again, sent by the "front end" software. While sendingData was true the Till_Link software would take the data from the server socket as a stream and send it in a stream to the Comm Port:

inputDataBuffer.append((char)newInputData);
os.write(newInputData);

Then sendingData was set to false by the control variable (EBCDIC value 4):

if(newInputData = = 4){
sendingData = false;
os.write(newInputData);
break;
}

The program would then listen for data coming from the Comm Port and send the data to the "front end" program:

newOutputData = is.read();
…
outputDataBuffer.append((char)newOutputData);
output.write(newOutputData);

When a control character signals the end of the data being sent from the Gilbarco TMS-15, the variable sendingData is reset to true:

if (newOutputData = = 4) {
sendingData = true;
…
break;
}

This causes the Till_Link program to listen for data from the "front end" program and send it to the Comm Port again.

This solution, because it is uses control characters to change the flow of the data, is a poor one because one control character is specific to the till. This goes against the original plan to have the data link as a generic object that can be used by any program and any device attached to the Comm Port.

The best solution to this problem would have created a generic object that could be used by any program and device. This could have been achieved by having a second network socket between the "front end" program and the Till_Link. This second connection could have sent the control data and told the Till_Link program which way it was sending data. This would have eliminated the need to use tokens within the sent data and would have placed all control in the one "front end" program.

3.3 The "front end" software

The "front end" software consisting of the TMS15_frame, TMS15_AboutDialog and TMS15_QuitDialog classes creates the user interface and sends data via a TCP socket to the Till_Link software and receives any data sent to it from the Till_Link software.

TMS15_QuitDialog class - this class creates a dialog box asking if the user wants to quit the program. It is a standard creation of a Visual Café GUI project.
TMS15_AboutDialog class - this class creates a dialog box that tells the user about the software. This is also a standard creation of Visual Café within a GUI project.
TMS15_frame - this class creates the user interface and holds the data for the conversion between EBCDIC and ASCII and vice versa. When this software is run, a TCP connection is made to the Till_Link software. Then the data required to log onto the Gilbarco TMS-15 is converted from ASCII to EBCDIC and sent to the Till_Link software. The final character sent to the Till_Link software, is the control character needed to change the direction of communication. Data is then received from the Till_Link software and this is converted from EBCDIC to ASCII and displayed.

3.4 Problems and Solutions

The biggest problem with TMS15 was that of converting the ASCII to EBCDIC and vice versa. This was impeded when the conversion table supplied by Source Computing Ltd. did not work. When tested manually, the ASCII character when changed to EBCDIC, was not the same when converted back from EBCDIC to ASCII.

This finally was shown to be an error in the headings of the table, the column labelled ASCII was EBCDIC and the column labelled EBCDIC was ASCII!

In the "front end" software, there are two variable arrays:

final static int ASCII [] = {…};
final static int EBCDIC [] = {…};

These arrays held character values and the conversion of a character occurred by finding its value in the array, noting the position and sending the character stored in the same position in the other array.

This is the section of code for sending data to the till:

String s = new String("452079");
for (int i = 0; i < s.length(); i++){
  // gets value of the character at a position in the string
  ch = new Character((char)s.charAt(i));
  // sets the value of conversion to the value of that character
  conversion = ch.charValue();
  // goes through the ascii array finding the value of the conversion and
  // sending the value at the equivelent position in the ebcdic array
  for(int count = 0; count < ASCII.length; count++){
    if(ASCII[count] == conversion){
      // writes the ebcdic to the stream
      output.write((char)EBCDIC[count]);
      // jumps out and looks at the next value in the string being sent
      break;
    }
  }
}

The use of an array index and a direct lookup was ruled out although this would have been quicker than using a search to locate the value. The table for the conversion (in the Appendices) can be seen to have multiples of the same value. Due to this and the problem in creating an array index based on the table which would work. It was better to use something that was a known quantity.

The smaller problems were:

The PC using the programs had to have a name (or IP address) for the networking to run and having to start two programs was not a tidy method.
Running the software using the Java Runtime Environment (JRE) was harder than anticipated because the Till_Link program was not finding the Comm Ports. This was discovered to be a hardware problem with the Comm Ports and nothing to do with the JRE.

3.5 Conclusions

The ideal solution using Java™ networking would have been to use two socket connections from the "back office" software to the Till_Link software. One connection would send and receive the data and the other would tell the Till_Link software the direction to send the data and whether to close the program.

This solution would be completely generic and would allow any device to be attached to the Comm Ports and the "front end" software would have total control.

The ideal solution without using Java™ networking would have been the original concept of having one "back office" program that sent data to and received data from the Gilbarco TMS-15. The ability to reuse the Till_Link software without amendments, by plugging in a different till and using different "front end" software was not possible. This was because the software was working in a synchronous manner and control characters had to be sent to control the flow of the data.

A class which functioned as the till link included within the "back office" software (a different class for each till) would have been a neater and smaller solution. This would have enabled a specific class for the required device to be included in the "back office" software before it was compiled.

The conversions between character types and the reversing of the data flow from "back office" side to Comm Port worked well and could be reused, if another program was to be written.

Back to Contents

Best viewed in

Mozilla Firefox