Final Report

seasoningalluringData Management

Nov 29, 2012 (4 years and 8 months ago)

273 views









Railroad Car Library Modification System




For:





Team Members:


Tim Geiger

Joe Hunsaker

Kevin Kocher

David May



Faculty Advisor:


Dr. Juliet Hurtig







Date: April 26, 2002




Page
1


Table of Contents



I. Abstract

................................
................................
................................
................................
.....

2

II. Introduction

................................
................................
................................
............................

2

Background

................................
................................
................................
................................
.

2

General Failure Problems

................................
................................
................................
............

3

Design Constraints

................................
................................
................................
......................

4

III. Discussion

................................
................................
................................
.............................

5

Design R
esearch

................................
................................
................................
..........................

5

Software Specifications

................................
................................
................................
..........

5

Database Background Information

................................
................................
.....................

5

Server

Side Scripting Languages
................................
................................
........................

6

Design Decisions

................................
................................
................................
.........................

8

Specification

................................
................................
................................
...........................

8

User Tools

................................
................................
................................
...............................

9

Project Plan and Execution

................................
................................
................................
.......

10

Project Gantt Chart

................................
................................
................................
...............

10

1. Design Phase

................................
................................
................................
................

11

a. Database Table Creation

................................
................................
..........................

11

b. Create Text File and Database Conversion Program

................................
...............

12

c. Web
-
based Car Library Editor Creation

................................
................................
..

12

2. Design Verification

................................
................................
................................
......

13

3. Documentation

................................
................................
................................
.............

15

Problems Encountered

................................
................................
................................
..........

15

IV. Future Development

................................
................................
................................
.........

16

User Interface Improvements
................................
................................
................................

16

Performance Improvements

................................
................................
................................
..

17

V. Conclusion

................................
................................
................................
............................

17

VI. Bibliography

................................
................................
................................
.......................

19




Page
2

I. Abstract


Sal
ient Systems, Inc. is a company located in Dublin, Ohio that maintains an extensive
railroad train car library system that is used in the detection of damaged wheels on train cars.
Currently, Salient’s library is stored in a text file and has to be edited

manually with a standard
text editor. As the car library grows, the text file becomes increasingly difficult to edit. Car
libraries have grown include over 150 cars and are no longer feasible to edit by hand. The
Railroad Car Library Modification Syste
m was proposed to Salient Systems as a solution to these
editing problems. This system incorporates a database driven web
-
based car library management
application. The new system will allow new car additions and old car modifications to be
performed in a

matter of minutes and it will check for duplicate car entries. Also the capability of
allowing clients to edit their own car libraries will now be possible, where before only Salient
employees could edit this data.

II. Introduction

Background

Salient

Systems, Inc., is a company based in Dublin, OH that primarily specializes in the
business of monitoring and detecting defective wheels on railroad cars. In order to detect wheel
defects on cars, strain gages are located on railroad tracks at remote locat
ions throughout the
world’s railroad systems. Signals from the gages are monitored with on
-
site microprocessor
systems and the final reports are transmitted via telephone lines to Salient’s customers. This
collection of remote hardware and software is mar
keted as a WILD system (Wheel Impact Load
Detector). In order to locate a particular railroad car that possesses a defective wheel, the number
and types of cars in the train sequence must be identified. The identification process involves
comparisons of st
andard car footprints in a library with measured values taken from the strain
gages on the railroad track. The footprints are comprised of axle and span spacings, as depicted in
Figure 1. This car library is stored in a text file and eventually compiled in
to a dynamically
loaded module. The module is uploaded to the remote WILD systems each time a change is made
in the library. Salient’s customers are located on six continents; therefore there are several car
libraries, each focusing primarily on one contin
ent’s car footprints.







Page
3













General Failure Problems


Salient’s current train car library is comprised of a text file that is manually edited and
modified whenever a change is needed. This file consists of multiple dat
a fields for each different
type of railroad car that passes over Salient’s sensors. The original design from the 1980’s has not
scaled well over time, and as a result the text file has become complex and tedious to modify.
This has allowed duplicate and o
verlapping data to be present in the text file, causing erroneous
vehicle identification to occur.

To modify the text file, a Salient employee has to manually search through the text file.
This proves to be tedious since there are hundreds of car specifi
cations in the text file that must be
compared to the new car to be entered. The main problem arises by having cars with similar
dimensions and overlapping wheel base tolerances. If a similar car is overlooked and the new car
is added with the same dimensi
ons, then the WILD software will not know which car to choose.
This causes an inaccurate report to be generated.

The car library has been in use for approximately 11 years. During this time a few
revisions have been made, but the format has remained a tex
t file. Until recently, the failure of the
system has been very low, almost nonexistent. However, there are simply too many cars in the
text file to continue editing in a text editor. With each car added, the time needed to edit the file
grows significant
ly. There are also multiple text files that contain different cars depending on
which part of the world the monitoring system is located.



Figure 1: Railroad Car Diagram


Axle

Spacing


Axle

Spacing

Span Spacing

Figure 1: Train Car Dimensional Data




Page
4

Design Constraints


Salient has not attempted to create a different method of editing the text file. The current
sys
tem has accomplished its task for many years. At first the text file was small and easy to
manage, but now the file is too large. Presently, customers must call Salient to perform additions
and modifications. Employees knowledgeable with the text file form
at and the potential problem
of railroad car overlap must perform this change. Therefore, a new system needs to be created to
make editing car library information easier, quicker, and more reliable. As part of the
requirements set forth by Salient, a user

interface with logic to prevent human errors was to be
developed.


Possible interface designs were presented to Salient. The two best solutions included a
standalone executable program to run on a client machine or a web
-
based version to run on a web
se
rver. The standalone executable would allow a Salient employee to run the program on a
particular machine and edit the train car data. This would restrict clients who did not have a copy
of the executable from performing modifications. The web
-
based soluti
on would be more flexible
in allowing outside users to modify the data; the web application could be hosted on a Salient
web server and allow anyone with an Internet connection and the proper username and password
to edit or view the data in the database.
In this situation, measures must be taken to prevent
erroneous data being entered into the system by inexperienced users. Depending on the login
name provided, two versions of the interface can be displayed. The administrative version would
allow Salient (
and others with an administrative username) to have more options and control of
editing the data. The standard user version would impose more restrictions on the data that can be
modified.

After a discussion with Salient’s management, it was determined tha
t a database with a
web
-
capable programming environment is needed. This will alleviate Salient employees from
making each and every change to the text file. It will also help with the marketing of their
product by making it easier for customers to remotel
y edit the file. Customers can add the railroad
cars they need without fear of corrupting the file beyond repair by allowing for backups of older
working versions.




Page
5

III. Discussion

Design Research

Software Specifications


The software specifications requir
e a web server and database that can perform successful
data transfer. The web server must support a programming language capable of data retrieval
from a database and display HTML. The operating system can be Windows, Linux, FreeBSD,
Mac, or any other OS
that supports the required web server and database server specifications.
However, upon discussion with Salient, they specified that the server on which the web
-
application would be hosted is running FreeBSD with an Apache web server.

Database Background I
nformation


Research was conducted on available database packages that could potentially perform
the tasks required. From brainstorming sessions and web research, seven contenders emerged:
Microsoft Access, Sybase Systems Sybase Database, Oracle, Microsoft

SQL Server, IBM DB/2,
MySQL, and PostgreSQL.

Sybase, Oracle, MS SQL Server, and IBM DB/2 are all commercial database packages
used in a variety of large
-
scale applications. Each has their specific performance benefits and
unique features, but for the scop
e of this document, they will be grouped into one category:
Commercial Databases. This is done for a variety of reasons, the most prevalent being that their
feature sets are all very similar (they all support standard relational database features such as
s
tored procedures, views, etc.). These commercial databases (with the exception of Microsoft
SQL Server) are available on a variety of platforms including Windows NT, Solaris, and Linux.


As expected, the cost of the commercial packages, both financial cost

and computing
power, is immense. For example, a license for Oracle can cost as much as $50,000 and require a
powerful server. Microsoft Access is not a free software package, but it is affordable by most
small businesses and can run on standard off
-
the
-
sh
elf hardware. Both MySQL and PostgreSQL
are open
-
source relational database engines available for a multitude of operating systems, and
come at no financial cost to the user.


Database engine performance was also examined. The commercial packages are all v
ery
comparable and are designed to handle a large load at one time. Microsoft Access is designed
more for a single task at any given time and is generally not compared with other packages for
performance. MySQL and PostgreSQL both scale differently, and in

general, cannot handle the



Page
6

amount of load of a commercial package. Between these two systems, however, there are
significant performance differences.


MySQL is able to only handle approximately 40
-

50 concurrent connections before its
starts refusing con
nections and giving errors [1]. PostgreSQL, however is able to handle more
than 120 connections at once without a problem, although it does it nearly 2
-
3 times more slowly
than MySQL. PostgreSQL supports stored procedures unlike MySQL, but it has also repo
rtedly
had problems with unrecoverable table and data corruption, presenting a reliability issue.


Server Side Scripting Languages


Research shows that there is a multitude of server side scripting languages available.
These languages in combination with
a compatible web server facilitate web
-
capable
programming environments. Some languages are specific to certain operating systems, while
others work on virtually every platform on the market. Microsoft’s ASP, Sun Microsystems’
Java Servlets, PHP, Perl, a
nd standard CGI scripts (written in C, C++, etc) are the most popular,
and therefore the languages on which research was conducted.


Microsoft’s ASP technology (Active Server Pages) is widely used in many commercial
ventures for web commerce. The technolo
gy is well established and very well supported by
Microsoft. A special feature of ASPs is that they use MS’s Visual Basic (VB) programming
language as the “ASP” language, lessening the learning curve for programmers who are already
familiar with VB. ASP is

capable of connecting to a multitude of databases and quickly extract
information from them. One good advantage is that ASP can be embedded in HTML.
Unfortunately, a severe disadvantage to ASP is that it generally runs only on Microsoft’s IIS web
server
in a Windows environment. Consequently, financial cost is incurred by requiring a
Microsoft Windows Server license. There are third party packages available to allow the use of
ASP in a Unix environment, but they add additional cost.


Sun’s Java Servlets a
re also used by many businesses to conduct electronic commerce
over the Internet. Much like ASP uses Visual Basic, servlets are built on Java technology; a
programmer familiar with the Java language will also be familiar with servlets. Servlets also
share
many other aspects with ASP, such as speed, database connectivity, and support from Sun.
One primary difference is in cost and platform independence. Servlets, being built on Java
technology, will run on virtually any platform and operating system in exist
ence. Unlike ASP
though, servlets are harder to setup and get running. IIS has built
-
in support for ASP, whereas



Page
7

most web servers have to be configured to use servlets, and the Java Virtual Machine has to be
installed on the physical server alongside the
web server. Through the use of JSP (Java Server
Pages

an extension to servlets), this code can be embedded in standard HTML like ASP.


Another free server
-
side scripting language that was found is PHP (a recursive acronym
for PHP: Hypertext Preprocessor).
As the name suggests, PHP does have powerful text
processing capabilities and like ASP, is interpreted and able to connect to a variety of databases.
Also like these other languages, PHP is embeddable so that the web page can be created in a
visual editor,

and the proper functional calls can be inserted into the HTML code where
necessary. Since it is also interpreted by a standalone program and not compiled, the PHP code
can be written once and run on many different platforms. The PHP interpreter is availab
le for
most operating systems, and integrates well with a variety of web servers.


All of the above scripting languages are intended for the sole purpose of generating web
-
based content. However, essentially any programming language that can produce an exe
cutable
for a particular system can be used to communicate with a web server present on the same system
via the common gateway interface (CGI). The CGI allows for the creation of software for
database access and web page generation to be written in any fam
iliar language. However, code
for most languages can be platform specific and must be compiled to run on a particular operating
system and processor. Therefore the CGI approach is not platform independent. Also, since some
languages are not widely used for

web
-
based access, they do not currently have the ability to
communicate with many of the databases that are being considered. Poor performance is also a
consideration when using CGI
-
based approaches. Each time that a web page is requested (in a
CGI
-
based
environment), an independent process for that program is created, causing increased
operating system overhead and memory usage. Most languages written specifically for web
-
based
applications (like PHP) are able to integrate with the web server in such a ma
nner as to prevent
this problem.


The Perl language is a powerful scripting language that is used in a variety of non
-
web
-
based applications, mostly due to its powerful text processing capabilities. Perl, like many of the
other languages above, is interpr
eted. The code is therefore platform independent in most
situations. With most web servers, Perl uses CGI for communication. On the Apache web server
it is possible (with the use of an Apache module) to interpret Perl code in such a manner as to
prevent th
e problems inherent with CGI access. Unlike PHP, Java Servlets, and ASP, however,
Perl code is not embeddable into HTML documents.





Page
8

Design Decisions


Once the research and gathering of information was complete, a formal solution had to be
decided upon. Th
e sections that follow discuss the selection of a database engine and scripting
language. Also presented is a list of features that were required to be included in the final
software.


Specification


Table 1 illustrates a decision matrix table displaying
all the databases researched to meet
the design constraints. One major requirement of the database must be data transfer capability to
a web
-
based application. A second requirement that Salient System proposed is that the database
system be of very minima
l cost, and no cost if possible. In search for a free database, however,
reliability and stability must not be compromised.

Each criteria was graded on a scale of 0


100, and then appropriately weighted due to its
importance in the overall design process.

Each grade is based on a subjective decision on how
well the features of each system (described above) met the constraints. For example, MySQL has
no financial cost, so it meets the low
-
cost criteria to the highest extent and receives a perfect score
of

100. MS Access is not free, but is affordable and thus receives a score of 50.

Table 1: Database Decision Matrix













Weight Factor:

30%


10%


10%


20%


30%




Cost

W

Features

W

Scalability

W

Platform
Independence

W

Reliability

W

TOTAL

Sybas
e

0

0

100

10

100

10

90

18

100

30

68

Oracle

0

0

100

10

100

10

90

18

100

30

68

MS
-
SQL

0

0

100

10

100

10

10

2

100

30

52

MS
-
Access

50

15

50

5

20

2

10

2

100

30

54

IBM DB/2

0

0

100

10

100

10

80

16

100

30

66

MySQL

100

30

70

7

70

7

100

20

100

30

94

PostgreSQ
L

100

30

80

8

70

7

100

20

70

21

86


As can be seen in the table above, MySQL scored eight points higher than its nearest
competitor, PostgreSQL. Due to the imperfect reliability score of PostgreSQL and the cost of the
commercial databases, MySQL was chos
en as the database of choice.




Page
9


A decision matrix for the scripting languages is given in Table 2. The key features
used to determine which language to use include: cost, ease of HTML integration,
database connectivity, and platform independence.


Table 2:
Scripting Language Decision Matrix











Weight Factor:


30%


30%


20%


20%




Cost

W

Ease of HTML
Integration

W

Database
Connectivity

W

Platform
Independence

W

TOTAL

ASP

10

3

100

30

20

4

10

2

39

Java Servlets

100

30

80

24

100

20

100

20

94

Perl

1
00

30

10

3

100

20

100

20

73

PHP

100

30

100

30

100

20

100

20

100

Other CGI

100

30

10

3

20

4

30

6

43


PHP received a score of 100 in the above table, six points higher than the comparable
alternative, Java Servlets. PHP was chosen over Servlets since thro
ughout the research conducted
on the languages, it was found that PHP integrates well and has specific functionality geared to
communicate specifically with the MySQL database selected above.


User Tools


The following list represents the user interface’s
key features. This list was created after a
conference meeting with Salient. Features included in the web application are:



User Administration

o

Restrict access to certain users

o

Add users

o

Remove users

o

Change password



Import/Export

o

Import data from text file

o

Export data to text file



Archival system

o

Ability to restore data from a backup

o

Ability to create a backup of current data



Units selection

o

Switch between British/SI units



Train Car browsing

o

Browse information already contained in system

o

Browse information i
n a “global” system (i.e. the train car library for the world)




Page
10



Data Entry

o

Enter data into system


Project Plan and Execution

Project Gantt Chart

A Gantt chart was used in the design for keeping the project on a timely schedule. As
shown in Table 3, the ori
ginal Gantt chart for this project consisted of three major tasks or phases:
Design, Verification, and Documentation. Actual execution of the project, however, slightly
deviated from this plan. Instead of devoting a given block of time for verification
and
documentation once the system was complete, these tasks were accomplished progressively as
each portion of the system was completed. Due to this change and unexpected complications
during development, the completion date was extended by two weeks to A
pril 22, 2002.


Table 3: Original Gantt Chart for Project

ID
Task Name
Duration
Start
Finish
Predecessors
1
Design Phase
54 days
Thu 11/22/01
Tue 2/5/02
2
Setup Development Database Server and Web Server
5 days
Thu 11/22/01
Wed 11/28/01
3
Learn PHP Programming Language
5 days
Thu 11/29/01
Wed 12/5/01
2
4
Database Table Creation
7 days
Thu 12/6/01
Fri 12/14/01
3
5
Implement Table Structure Needed f or Storage of Train Car Library
7 days
Thu 12/6/01
Fri 12/14/01
6
Create Text File and Database Conversion Program
10 days
Mon 12/17/01
Fri 12/28/01
4
7
Create Text File to Database Conversion Function
5 days
Mon 12/17/01
Fri 12/21/01
8
Create Database to Text File Conversion Function
5 days
Mon 12/24/01
Fri 12/28/01
7
9
Web Based Car Library Editor Creation
27 days
Mon 12/31/01
Tue 2/5/02
6
10
Create HTML Layout of User Interf ace
10 days
Mon 12/31/01
Fri 1/11/02
11
Create PHP Code to access Database
11 days
Mon 1/14/02
Mon 1/28/02
10
12
Possibly Create Log File f or Database Changes
6 days
Tue 1/29/02
Tue 2/5/02
11
13
Design Verification
12 days
Wed 2/6/02
Thu 2/21/02
1
14
Test Text File to Database Conversion Program
4 days
Wed 2/6/02
Mon 2/11/02
15
Test Database to Text File Conversion Program
4 days
Tue 2/12/02
Fri 2/15/02
14
16
Test Web Based Car Library Editor
4 days
Mon 2/18/02
Thu 2/21/02
15
17
Break
6 days
Fri 2/22/02
Fri 3/1/02
13
18
Documentation
26 days
Mon 3/4/02
Mon 4/8/02
17
19
Create Rough Draf t of Database Documentation
4 days
Mon 3/4/02
Thu 3/7/02
20
Create Rough Draf t of Text File to DataBase Conversion Program
4 days
Fri 3/8/02
Wed 3/13/02
19
21
Create Rough Draf t of DataBase to Text File Conversion Program
4 days
Thu 3/14/02
Tue 3/19/02
20
22
Create Rough Draf t of Web Based Car Library Editor
4 days
Wed 3/20/02
Mon 3/25/02
21
23
Revise all Rough Draf ts
5 days
Tue 3/26/02
Mon 4/1/02
22
24
Write Formal Documentation
5 days
Tue 4/2/02
Mon 4/8/02
23
T
F
S
S
M
Nov 18, '01
Nov 25, '01



Page
11

1. Design Phase



At the beginning of the main design phase, it was necessary to set up the software used to
develop and test the management system. Installations included the MySQL database server used
for storing the RR car library inf
ormation, a web server to host the system, and the PHP scripting
language for interfacing between the database and web server.

System development was performed using a MS Windows platform running the IIS web
server and MySQL database server. This platfor
m was chosen for its network file sharing and
ease of configuration for development purposes. A secondary UNIX
-
like server (MacOS X)
running the Apache web server and MySQL was also used for testing and verification on a
system that closely simulates the
future working environment of the application.



a. Database Table Creation



The database schema necessary for creating the train car library was designed using
standard relational database development methods. The tables were designed to effectively s
tore
in a database the information contained in a text file. See Listing B1 (Appendix B) for the final
database schema in SQL format. Below, major components of the database schema are explained
in detail.

During the initial design of the database tables
, it was found that a key field was
necessary to uniquely identify each individual train car. Since the original text file system did not
implement this feature, a method for unique identification within the database was devised.
Essentially, whenever an

import operation is performed or a car is added to the library, a number
is generated unique to that car and is stored in the database as an identification key.

To fulfill the requirement of the system to perform backup and restore operations on a
particu
lar library, each table in the database required for the storage of train car information had
to be duplicated. Whenever a change is made to information stored in the library, the data that
was changed is archived to the restore version of each particular

table and a date/time stamp is
appended. If a restore operation is requested, this date is analyzed and the appropriate
information is transferred back to the primary tables.






Page
12


b. Create Text File and Database Conversion Program

Two functions were desi
gned in PHP to interact between the text files of the WILD
system and the database structure of the web application. One of these functions converts the
information contained in the text file into tables in the MySQL database. The other reads the
informa
tion contained within the database and writes it to a text file for processing by the WILD
system. Screenshots of the system interface to these functions can be seen in Appendix A:
System User Manual. Details of these functions as well as flow charts re
lating to their operation
can be seen in Appendix B.



c. Web
-
based Car Library Editor Creation

The entire user interface of the system was created with the use of a PHP template
program that allows the interface to remain separate from the data being dis
played. Each
component of the system is controlled via it’s own PHP script containing all necessary logic for
operation (including database access). This script parses a static HTML document template for
the particular function that contains the necessar
y formatting information, and inserts data where
necessary. Again, details of each system component can be seen in Appendix B. Information
detailing the use and navigation of the system is explained in Appendix A: System User Manual.
A flowchart detail
ing the high
-
level features of the application can be seen below in Figure 2.



















Display
Database
Edit Car
Search
Import Text
File
Export Text
File
Restore
Create New
Users
Change
Password
Create New
Group
System Features
Delete
Car
Add car
Main Page
(All Users)
Advanced
User

Figure 2: System

Features




Page
13

2. Design Verification

As with all software products, system testing and verification is critical for a stable,
useful product that meets the desired custome
r specifications. In this project, system testing was
performed to verify proper error handling, adequate system performance, platform/browser
independence, reliability, proper backup/restore functionality, and import/export structure.

System testing wa
s an ongoing process throughout the software development cycle.
First, a portion of the code would be written and testing of that particular segment would be
performed to verify proper functionality. Then, if a problem was found with a module in this
man
ner of testing, it was known exactly which portion of code was causing errors. Also, as each
individual portion of code was being pieced together, the combined system was again tested.
This process occurred until the entire system was completed, at which

point the overall system
was tested.

Throughout the development process, testing of the partially complete system was
performed on several different platforms using several different web browsers. This was done to
ensure compatibility of the system wit
h many different environments, as listed in Table 4.


Table 4: Test Platforms

Operating System

Browsers Tested

MS Windows XP, 2000, NT 4.0, 98SE

Internet Explorer 5.x, 6.x

Opera 5.x, 6.x

Netscape Navigator 4.x, 6.x

Mozilla 0.9x

Kmeleon 0.5x

Linux (ke
rnel 2.4 (Intel), X
-
windows
4.1.x)

Netscape Navigator 4.x

Mozilla 0.9x

Konqueror (KDE 2.x)

MacOS 10.1.x (PowerPC G3
-
400)

Internet Explorer 5.x


An initial design implementation was to use XML to assist with data transport to and
from the client web brow
ser. It was during one of the initial tests of multi
-
browser functionality
that it was found that only Internet Explorer 5.x and higher have the needed support to implement



Page
14

an XML based transfer. While this was the only major implementation issue found r
elated to
browser compatibility, other smaller user interface issues made themselves apparent.

For example, in Netscape 4.x it is required that the user click on certain buttons with the
mouse where it is possible to simply press enter on other browsers to

submit data. Another issue
found with this browser is that certain tables, text, and buttons are displayed improperly. Items
that are center justified in the other browsers appear left justified in this version of Netscape.
Since they are “look and fe
el” problems and do not affect the functionality of the overall system,
these problems still remain.

Experiments were also conducted to ensure proper functionality with the use of many
different internet connection speeds. It was found that the system per
forms adequately on all but
the slowest modem connections (less than 33.6 kb/s). Performance on broadband connections
(DSL, fixed
-
wireless, and local LAN) was found to be outstanding.

Since reliability of the system was one of the major design considerati
ons, much time
was spent on ensuring this feature. One concern in this area is periodic backups of the data in
case of hardware failures. Given that Salient performs regular system backups on the server, it
was unnecessary to test this situation. What w
as tested, however, was the ability of the system to
restore any modified information to a desired state before an improper modification was made.
Several sample train car libraries were created, and modifications performed to these libraries. A
restore
operation was performed on a particular library, and it was ensured the restored data
exactly matched the original.

Proper operation of the import and export functions of the system was also ensured.
Using test “library” text files from Salient, data was
imported into the system as a new library.
The system’s export function was then used to generate a text file of this library, and a
comparison was made between the original and generated file to verify the data was identical.
This test library was also u
sed to verify proper functioning of other parts of the system, such as
the display library function. These functions were tested as each was completed, as explained
above. All functions where input is required from the user were also tested to ensure pr
oper error
handling in the event that invalid or unexpected data is submitted to the system.

What is explained above is the testing performed by the developers of the system. Upon
delivery to Salient, further testing will be performed with a larger amount

and variety of data,
possibly with test clients. This depth of testing was not possible before delivery due to time
limitations and unavailability of test data.




Page
15


3. Documentation

The product functionality was comprehensively documented to allow for use o
f the
system by Salient Systems’ employees and for future modifications and maintenance of the
system. Refer to Appendix A for the user manual, and Appendix B for the low
-
level design
document. Rough drafts of the various system software components were
written and
subsequently combined into this final report.


Problems Encountered

One problem came from the specification to identify overlapping cars within the library.
This helps to minimize the size of the library and enables Salient’s WILD system to mo
re
accurately identify vehicles from the raw sensor data. Currently, when a new railroad car is
manufactured, Salient employees must manually compare the new car’s footprint data with all
cars within the train car library to see if it is indeed unique in
its measurements. At first, we
thought this meant that Salient wanted to have absolutely no car overlaps within the library.
Code was written to identify all overlaps and surprisingly, it returned almost the entire database
back after several minutes of
querying. After further discussions with Salient, it was realized that
the overlapping of train car footprints is inevitable due to the tolerances assigned to the nominal
values. Thus, changes were made to the search routine. The user must first select
a footprint of a
car in question and then the software returns all cars already in the library that overlap that
footprint. This reduced the search time to an unnoticeable amount given a train car library of
about 150 cars.

Another problem encountered i
nvolved determining how to transmit data from the server
to the web browser. Initially, print statements were used within the PHP script to send hard
-
coded HTML to the browser for display. This proved to be very time consuming and difficult to
modify. I
t was found that the use of a structured markup language, such as XML, would ease
much of the labor associated with displaying variable length tables in the browser. Essentially,
raw data and a formatting template could be sent to the client browser that
would then use the
template to display the data.

As mentioned earlier an initial proof of concept meeting uncovered that only MS Internet
Explorer version 5.0 or higher could handle the use of structured markup languages. Since we
could not limit the use
r to a specific browser package, this solution was not acceptable. The final



Page
16

solution to the problem came in the form of a PHP program that parses a pre
-
created HTML
template and replaces special tags within the template with the variable data to be displ
ayed.

Multiple users proved to be the most difficult feature to implement. Initial
implementation used a user only based setup where users had logon privileges and access to
individual libraries. This proved to be difficult to administer, so the concept

of a group was
added. Each user was assigned to a group of users, and the entire group was given access to a set
of libraries. The group concept presented the ability to assign privileges to a group as a whole
with these rights propagating to the users
in that group.


IV. Future Development

Throughout the design process many suggestions were made on features that could be
integrated into the web application. Due to time constraints and software limitations, many of
these suggestions were not possible f
or this first version of the program. In the future, more time
may be allotted for further development of the application and improved tools may be available.
Specifically, improvements could be made in the area of the user interface and performance
aspe
cts of this project.



User Interface Improvements

Currently, navigation through the application requires the use of specialized links on each
web page. The browser’s back and forward buttons do not work properly due to information that
must be submitted

by the browser to the server each time a page is displayed. This behavior is
distracting to most users, but cannot be remedied at this time due to limitations in the available
web browsers. Hopefully future browser releases will alleviate this problem.

Another improvement that can be made to the user interface is the ability to select a
language other than English. Many of Salient’s customers reside in non
-
English speaking
countries. For ease of use to these customers, a version of the system in their
native language
would be beneficial. Implementation of this feature is technically possible with current software
but further development time is required.





Page
17

Performance Improvements

As mentioned previously, XML was suggested to be the basis for data trans
mittal from
the server to the client browser. Implemented in this manner, the server would only be required
to send a single formatting template to the browser and merely transmit the raw XML data to the
client where it would be assembled for on
-
screen vi
ewing. In the system that was developed, the
entire page is generated on the web server (an HTML page with data and formatting) and then
transferred to the client machine. This unnecessary transfer of formatting data could be
eliminated if client browser
s had the capability to properly handle XML data.

Lastly, when a request is made to display the database, the application returns the
information for each of the cars contained in the library. The system would still function in this
manner regardless of t
he library size (currently the largest database has only 150 cars), but a
significantly larger number causes very long transfer times to modem users. A possible solution
to this problem would be to limit the returned results to a user
-
specified number and

integrate
navigational links to allow the user to navigate through the result sets.


V. Conclusion

There are several factors that affect the design and implementation of the car library user
interface. Economics played an important role in choosing which

web server, database engine,
and programming language to use to develop the user interface. Salient explicitly stated they did
not desire to purchase a database server or web server. MySQL database server and Apache web
server were both approved by Sali
ent Systems since they both met their financial criteria. In
addition, Salient currently uses an Apache web server, and MySQL is being considered as the
database server of choice for all of their applications. Thus, Salient’s employees will have an
easie
r time maintaining and modifying this new car library interface in the future. Another aspect
of economics was the fact the Salient could market web access to train car library for customers
to manage their own car libraries.

Social factors, such as the u
se of SI and English units were also taken into consideration.
Countries from any continent could potentially use the web
-
based car library. Therefore, both
English and SI units for the dimensions of car specifications are included as an option for the
u
ser. Whenever dimensional data will be displayed, the interface includes a drop down menu to
select the system in which to display the data.




Page
18

An important political factor that affects design of a globally used interface is language.
The car library could

possibly include an option for selecting the desired language of the
interface. It was decided that implementing multiple languages was not feasible now due to
time constraints, but Salient Systems could possibly add this feature at a later date.

A fou
rth design consideration is sustainability. The user interface must be both reliable
and sustainable. An unstable program will cause many problems for both Salient and their
clients. Thorough system documentation (refer to Appendix B) will allow Salient

Employees to
further develop and support the system as issues and new features are envisioned. Trust and
credibility of the company was a major concern during development. To help build and maintain
these qualities, the code was organized in a modular f
ashion to increase reliability and allow
Salient to sustain and improve the system.

Car library backups are essential to ensure that a mistake made by a client entering false
specifications will be reversible. Therefore safety in design is an important co
nsideration when
data protection is absolutely essential. Without reliable car library data, the WILD system would
not function properly. Therefore, both automatic backup and manual restore processes were
implemented.

Finally, various tests were performe
d to verify proper operation across multiple
platforms. In general, the system is simple and intuitive requiring only a minimal number of
mouse clicks to view and edit
car libraries. Overall, the Railroad Car Library Modification
System is reliable and e
asy to use, and thus solves the original problem posed by Salient to
replace the text version of the train car library.






Page
19

VI. Bibliography


1.

Author: Tim

“MySQL and PostgreSQL Compared”

Internet:
http://www.phpbuilder.com/columns/tim20000705.php3?page=2


2.

“Common Gateway Interface”

Internet:
http://hoohoo.ncsa.uiuc.edu/cgi/intro.html


3.

Author: Martin Rennhackkamp

“An Analysis

Of The Strengths And Weaknesses Of The Big Six Database
Servers”

Internet:
http://www.dbmsmag.com/9611d52.html
,
DBMS Server Comparison
Supplement
, November 1996


4.

Author: Protima Banerjee

“Will open sou
rce databases ever have a major role in business
-
critical applications?”

Internet:
http://www.intelligententerprise.com/010918/414feat3_1.shtml


5.

Various Articles

Internet:
http://www.php.net/
,
Copyright © 2001 The PHP Group


6.

Various Pages

Internet:
http://www.mysql.org


7.

Various Pages

Internet:
http://www.postgresql.org


8.

Various Pages

Internet:
http://www.oracle.com


9.

Various Pages

Internet:
http://www.sybase.com


10.

Various Pages

Internet:
http://www
-
4.ibm.com/software/data/db2/


11.


Author:
Nancy Winnick Cluts


An ASP You Can Grasp: The ABCs of Active Server Pages”

Internet:
http://msdn.microsoft.com/library/default.asp?url=/library/en
-
us/dnasp/html/aspover.asp


12.


“Java Servlet Technology”

Internet:
http://java.su
n.com/products/servlet/?frontpage
-
javaplatform