Summary - VLE - University of Leeds

i
Summary
This project identified the need for, developed and evaluated, a constructive tool for navigation around
the campus of the University of Leeds.
Evaluation of a wide range of route finding methods recognised key characteristics for a successful tool.
Combined with attributes potential users identified as valuable, requirements were constructed. The
proposed application, termed the Route Finder, was developed with the integration of several
technologies including MySQL, JDBC and Java servlets.
The essential and majority of desirable
requirements were met, with the additional extension to these requirements also realised.
Skills introduced in the School of Computing modules System Specification and Design, Object Oriented
Programming and Introduction to Computer Graphics will have the opportunity to be enhanced.
ii
Acknowledgments
Firstly, I would like to thank my supervisor, Keith Hobley, for his continued support and guidance
throughout this project. Thanks also goes to Joseph Chacko, a former colleague, for his invaluable advice
and encouragement. Finally, I would like to thank my five testers and any one else who has helped me in
any way.
iii
Contents
SUMMARY
ACKNOWLEDGMENTS
CONTENTS
1
I
II
III
INTRODUCTION
1
1.1
THE PROBLEM
1
1.2
AIM
1
2
BACKGROUND RESEARCH
2
2.1
CURRENT AIDS TO NAVIGATION
2
2.2
HUMAN COMPUTER INTERACTION
8
2.3
USER NEEDS
9
2.4
USER PROFILE
11
2.5
PROCESS MODEL
11
2.6
USER REQUIREMENTS
12
2.7
TECHNOLOGIES
13
3
DESIGN
18
3.1
INTERFACE
18
3.2
DATABASE
21
4
IMPLEMENTATION
22
4.1
SCHEDULE
22
4.2
MYSQL
22
4.3
TOMCAT
23
4.4
SERVLETS
25
iv
4.5
JDBC
27
4.6
SHORTEST PATH ALGORITHM
30
4.7
INTERFACE
33
4.8
DYNAMIC IMAGE
34
4.9
ADMINISTRATION
41
5
TESTING
42
6
EVALUATION
43
6.1
LESSONS LEARNED
46
7
FUTURE WORK
48
8
CONCLUSION
49
9
GLOSSARY OF TERMS
50
10
REFERENCES
51
APPENDIX A PERSONAL REFLECTION
53
APPENDIX B CAMPUS MAPS
53
APPENDIX C USER REQUIREMENTS
55
APPENDIX D SCHEDULE
59
1
1
Introduction
1.1
The Problem
From observations around the campus, it can be noted that many newcomers to the Un iversity of Leeds
have a challenging task of finding their way around. This is especially evident during the first few weeks
of a new academic year, as many first year students inquire for directions to buildings, “How do you get
to the E C Stoner building?” the author was asked. Students and visitors can also be seen standing next to
the public maps situated around campus, looking bemused. From personal experience as a new student
and currently, as an existing student, the author also identifies difficulties in locating unfamiliar buildings.
A prime example of current University members finding the position of a particular location to be a little
tricky to uncover is when Computing lectures are given in Chemistry lecture theatre F.
1.2
Aim
This assignment aims to develop a navigational tool to assist with unfamiliar journeys around the campus
of the University of Leeds. Intended users include new and existing members of the University as well as
visitors. The project aims to offer a functional solution that
navigation.
is more effective than present aids to
2
2
Background Research
This section aims to review current aids to navigation. A greater understanding of the issues involved in
route finding is sought. The identification of important components for communicating routes to users
will contribute to the specification of the proposed system.
Alberts [1] explains, “The advent of affordable automobiles spawned a new trend in American Culture:
the road trip. Motorists.. quickly tired of stopping every few miles to ask directions; out of their troubles,
came the first road maps,”. Many people today would almost certainly use some sort of a map when
travelling to places they have never visited before. A few people were asked how they would find their
way to places they did not know how to get to, replies included
A to Zs as they were colour coded and displayed road names
road atlases “because I can see where things are”, in conjunction with Multimap “to form a
mental picture of the route before setting off”.
In fact, without such a reference for even a part of the journey, the task may prove to be quite difficult.
Without any form of assistance e.g. road signs, directions from a passer
impossible. A road network without any
-by etc, the task may be near
road signs or road names would today seem unimaginable.
Therefore we can surmise that route finding requires some form of assistance.
2.1
Current Aids to Navigation
2.1.1 University Resources
To assist in route finding around campus, the resources provided by the
University of Leeds can be
divided into three categories.
Internet Based
An online map of the campus resides on the University of Leeds website [2]. The image that is used, see
Appendix B, is more of an artistic representation of the campus, rather th
an a plan view, making it
difficult to identify buildings and pathways.
Quadrants of the map can be zoomed in on, allowing the user to discover the name of the building and
departments contained within it, by clicking on a number. The level of detail re
quired to actually
construct a route between two locations can be obtained from these quadrants, however, only a small
3
section of the campus is viewable in each quadrant and to put together a route to a location in a different
quadrant is not straightforwa rd. It is difficult to see where the paths and buildings from one quadrant
follow on to the next quadrant. The overall map can be viewed with various labels: car parks; University
campus residences; concert halls, lecture theatres and exhibition halls; p
laces to eat. The labelling
however, is not sufficient, for example the concert halls, lecture theatres and exhibition halls map does
not label the Roger Stevens Building, a building that contains over 20 lecture theatres and where many
lectures are held every day.
Assistance from individual departmental websites includes online maps of the campus in relation to the
department, some with “Useful Locations” highlighted. The School of Geography [3] and the School of
Mathematics [4] maps are examples of c lear representations of the campus, labelling “Useful Locations”.
Other departments link to the map on the University of Leeds website [2].
The plentiful supply of online directions and maps on how to reach the University from other parts of the
country, for example [2] and [4], support the observation that people need some sort of direction or
reference when travelling a new route. Indeed many institutions, for example other universities [5], [6],
companies, etc provide this information on their websites. When posed with the question of ‘How would
you find your way to a given building in the University of Leeds as a visitor?’ a none University of Leeds
member stated “I would definitely use the Internet to get directions on how to reach the University and to
print off campus maps ”.
Paper Based
A University of Leeds Pocket Guide is available and although the navigational information supplied
within this is very similar to that on the University of Leeds website map [2], the map does displays a
clear representation of the campus.
Another hardcopy map, offered by The Library, labels "Useful Locations" and "Library Locations". This
map also highlights a pedestrian route between the Library Locations, valuable if libraries where the
desired locations to be travelled between. Similar types of maps include computer cluster maps and
eating area maps.
Quite often departments include a map of the campus in starter packs given to new students. One first
year student explained the map did not help when t ravelling to different locations, “..only a few buildings
4
were labelled and the map was black and white”. In order to achieve the task, the student asked a passer by for directions.
Finally, students can look to the public maps situated around campus. T he maps only display the section
of the campus they are situated in, making it impossible to find a destination outside of that section.
Although colour coded, the maps do not display which sections are adjacent to the current one. Having
spoken to stude nts who have used this aid for navigation it has become apparent that this method is not
very effective for the task.
People Based
A quick and popular strategy to obtaining a route to a location, as previously mentioned, is to ask another
person. Thi s may be a perfectly successful solution, offering specific directions to the users destination,
providing:
The individual questioned has the knowledge to supply the solution,
“[this method] was not very helpful as the person didn’t know where Baines Wing was.” – first
year student.
The individual questioned has time to supply the solution.
There is an individual in the near vicinity, to question.
However, problems could arise if the instructions are not noted down and forgotten, the instructions are
misinterpreted, or human error leads to an incorrect route being supplied or taken.
From the resources available from the University, the following attributes can be deduced as being
important for a practical map: sufficient labelling of departments and
buildings; complete labelling of
places of interest; a clear plan view of the whole of the campus; making information available over the
Internet; some form of colour coding; reliability; sufficient information. These will be expanded on in the
User Requi rements section. Only the ‘People Based’ strategy offers directions between specific
locations.
2.1.2 Internet Resources
With the rise of the Internet, web based navigation tools have sprung up as an alternative and addition to
road maps. Many websites fall in to this category, possessing some common elements, a few examples
follow.
5
Multimap.com [7] provides a large number of services. The homepage displays clickable image maps of
the areas the user can search, along with a text box for the input of a locatio n for a map to be displayed
and a list of other services offered. These services comprise of aerial photos, historic photos, textual
directions, a plan of the London underground, a downloadable Internet browser search button, various
wireless methods for using Multimap.com, a variety of services for businesses, a text weather service, a
hotel finder and a map ordering service. Additionally, as part of the myMultimap account, users can
email maps and save places and routes previously found. To search for
a particular route between two
locations, two text boxes are supplied for the user to specify the locations; each must then be verified
before a route can be found. Two possible routes are attainable, the quickest and the shortest.
Information detailing the specific route takes the form of a map, containing both locations, and a set of
instructions for the route. With each step of the instructions an associated distance is given with the
option of viewing a close up map of the particular location referre
d to. As the steps increase an
accumulated distance and time is also given, with a total distance and time for the whole journey. Option
of close up of destination and origin, and reverse route, exist.
MapQuest [8] is another wide -ranging website, agai n allowing text box user input for the delivery of a
map. As well as having the option to obtain driving directions for North America and Europe, users can
plan road trips including accommodation and eating facilities en route and search MapQuest’s Yellow
Pages. Additional services include map buying, wireless options, pre -planned road trips, saving routes,
aerial photos, world atlas, travel deals, road atlas and a newsletter. MapQuest uses text boxes and list
boxes for the “From” and “To” locations when
finding a route but offers “Places of Interest” (such as
airports) as options for the locations. Route information consists of a set of textual directions with a
distance for each step, a total journey time and distance along with two maps. The first ma p is similar to
that supplied by Multimap.com [7], displaying both locations, however the user can zoom in and out and
pan in four directions. The second map is a close up of the destination, with road name level of detail.
Actions the user can take from this page are printing, saving, emailing, downloading the route to a PDA
and requesting reverse directions.
The Automobile Association Limited (the AA) [9] and the RAC [10] provide similar route finding
services as the previous websites discussed. They both have in common the following elements: allowing
users to specify start and end locations, presenting a map with zooming and panning options, giving a set
of textual directions and a total distance and time and an option for a reverse route.
6
Maps of locations in the United Kingdom are the main offering from Streetmap.co.uk [11]. This is a
much smaller site with only a few services. The method of emailing the map asks the user to copy and
paste the given link, which contains the exact parameters for that map.
Tony Quinn’s VR Leeds [12] and the City Centre Maps provided by Leeds City Council [13] are
interactive maps of Leeds city centre. VR Leeds supplies plentiful “360
° panoramic tours of the city”
[12], while the City Centre Maps are clickable maps linking to websites of particular buildings of interest,
for example the Central Library.
The following components can be deduced as being valuable in an Internet based navigational tool for
roads: clickable image maps, text boxes or list boxes for
specifying locations; maps; useful locations in
the form of accommodation, eating areas, airports etc; aerial photographs, wireless services; map
purchasing; emailing routes; saving routes; downloading routes to PDAs; road trips; directions between
locations, including quickest/shortest routes, maps, close up maps, instructions, total distance, total time
and reverse route; links to additional useful information.
Although the resources may not be useful in finding buildings around the University of Leeds c
ampus,
they do support key elements a route finding device should contain.
2.1.3 Other Route Finders
A Route Finder offered by the Australian bus company ACTION [14], allows the user to select two
locations to travel between with the use of list boxes. Various routes are offered together with a map of
the route in PDF format, to enhance the print out, if desired. There is an option of selecting different
times frames to travel between. The Toronto Transit Commission [15] provides almost the same route
finding service for its buses.
Handheld electronic devices are convenient when on the move and navigational software has been
developed to take advantage of this. TomTom Route Planner [16] offers a specific route from A to B,
either the shortest or the quickest . “It gives you full travel instructions in text and graphics”[16]. The
product is available for Europe and the USA. PocketStreetmap, by Streetmap [17] is not much more than
an electronic map for PDAs. The similar AutoRoute 2002, by Microsoft [18], also
directions and highlights places of interest.
offers, driving
7
Elements of significance in this section include: selection of locations to go between using list boxes;
presentation of a map; printing considerations; time frames; PDA software; specific routes between origin
and destination; shortest or quickest route; text and graphics; directions; places of interest.
2.1.4 Past Projects
Figure 1 reviews previous similar final year projects. The Suggested Improvements heading is a
culmination of what the testers
and the authors of the projects believed could enhance the existing
application and the development of it.
Table 1:Review of similar past projects.
Project
Brief Description
Suggested Improvements
An Internet Tour of the
School of Computer Studies*
at the University of Leeds
[19].
Walk through of the School of
Computing as the user clicks arrows
and pictures are displayed. Route
finder program included.
Leeds University as a 3D
world [20].
Three-dimensional visualisation of
the University.
A Route Finder Application
for Windows [21].
Virtual Reality Walkthrough
of University Department
[22].
Route finder for motorists.
Platform independent database
e.g. MySQL.
Improved interface.
Automated tour.
Routes without stairs.
“Would be good if you could
select a place from a list and have
the computer take you there via
the quickest route”.
Improve speed of algorithm.
Guided tour of the School of
Computing using snapshots of the
department.
Integrate route finder with the
tour.
Inclusion of useful buildings e.g.
Edward Boyle Library.
A VRML V2.0 Campus map
[23].
Virtual reality campus map.
Route finder.
*The School of Computer Studies was the former name for the School of Computing.
It can be seen that attempts so far have portraye
d three -dimensional views of the campus and either
displayed some sections of it, or taken the user on a virtual tour. The impression gained is that the
assignments were geared towards visitors of the University, who would most probably not be familiar
with what the buildings or departments look like before visiting. As a new student of the University of
Leeds, during initial trips to the campus the student would have become aware of some of the important
buildings on site, for example the Parkinson Build ing, therefore would have a greater need for directions
to certain parts of the University than a need to be acquainted with the appearance of buildings; indeed
this can be achieved en route. “I took the route I knew from the Open Day”
- how a first year student
found their parent department on their first day at the University. Also previous applications have
8
allowed users to view buildings whilst sitting in front of a computer; not a very practical aid if the user
wishes to use the tool mid journey.
Advantageous attributes therefore, for a route finding aid include: a good interface; automated tours; a
route finder; alternative routes; selection of locations to travel between; a search facility; snapshots of
buildings; inclusion of useful locations.
2.1.5 Conclusion
Many factors need to be taken into consideration when creating something that will be of practical use
and an improvement on existing methods for navigation around campus. Several elements have
continued to recur, leading to the conclusion that
they are significant in route finding. These will be
covered in more detail in the following chapter.
2.2
Human Computer Interaction
Functional and practical are the intentions for the Route Finder. Widespread availability is only part of
the equation. A ‘g ood’ interface to the system necessitates careful thought and concentration in the
design. It is important to know what the task is and who the users are, with this knowledge and a few
guidelines, the best interface can be attained.
Shneiderman [24] identifies five human factors that interface designers aim to optimise.
Time to learn – how long it takes the user to acquire the skills to achieve the task.
Speed of performance – how long it takes the user to achieve the task.
Rate of errors by users – the nature and number of errors the user makes; they should be managed
effectively.
Retention over time – how much does the user remember from previous usage.
Subjective satisfaction – how much the user liked using the different elements.
However, due to the trade offs that exist with these factors, compromises have to be made. Nevertheless,
guidelines can be obtained from these when designing the Route Finder interface.
A key feature to obtaining an easily understood interface is to ensure that it is consistent throughout. This
can be achieved in a number of ways, for example retaining the same style (font, colour, etc) on every
screen of the interface, for elements with the same meanings. As “…users often lack sufficient expertise
to benefit from all the f acilities provided [by computers]”[24], another principal feature is to provide the
9
user with meaningful feedback on their actions. This allows the user to learn how to operate the system
by confirming intended operations and warning about unintended ones
. For display of information
Shneiderman [24] suggests no more than four font sizes, three fonts and four different colours, with more
being used occasionally. The system must also be reliable and act according to how is specified, “…one
experience with misleading data or unexpected results will undermine for a long time a person’s
willingness to use a system.” [24]. “designers also must pay attention to ensuring privacy, security and
data integrity”[24], this will be discussed further in the report.
All these considerations need to be addressed along with the most powerful one of, the simpler the design,
the more straight forward it is for the user to see beyond the interface and achieve the desired task.
2.3
User Needs
“In order to be able to produce a suitable system for the end-user, the software development team needs to
know what the user really wants and needs.”[24]. This has served as the motivation for the discussions so
far and will continue to do so until the User Requirements have been established.
The proposed system aims to provide for the following types of user:
New student - requires detailed directions
Visitor - requires detailed directions
Existing student - requires less detail to useful locations
Researching into existing methods of
route finding is an undoubtedly valuable task in discovering
important elements for a good solution. However, best method of learning what to provide for the user, is
by asking them. Varying types of users means varying knowledge of the campus, leading
to varying
requirements. A representative of each type of user was interviewed, a first year student who has been at
the University of Leeds for six months, a visitor who has travelled to many University campuses on
business and a finalist. The interview
ees identified a number of attributes they considered would
formulate an effective online map, set of textual directions and overall route finder.
10
Table 2: User's suggestions on the attributes for an effective map, directions and general route finder.
Map
New
Student
Visitor
Existing
Student
Simple.
Colour coding.
Integration if divided into
sections.
Sufficient labelling.
Interactive.
Labelling of roads
encompassing campus.
Labelling of all entrances
and car parks.
Labelling of one-way routes.
Lots of names.
Not too cluttered.
Overview and detail of
difficult parts.
A plan, containing all the
major information required.
Should not look too
cluttered or messy - you
need to be able to spot
where you're going easily
and quickly.
Zooming facility.
Set of textual
Directions
Bullet points.
Not too vague.
Identification of
landmarks such as
courtyards.
Concise and to the
point.
Use landmarks and
put them in a stepby-step manner.
Detail e.g., "the first
turning on the right
just after the
purple bush".
Route Finder
Time.
Distance.
Room numbers.
Print facility.
Specify start and end points.
Option to go via another building.
Show exact route to be taken.
Numbers on image corresponding
to directions.
Avoid places you cannot walk or
drive (depending on mode of
transport).
Links to websites about the city.
Print facility.
Ability to state where to start and
end.
Links to other useful websites.
Alternative routes.
Landmarks to work with.
While some of the user needs are common between the users, others are subjective to each type of user;
development will therefore need to reflect this.
For any system there will be an administrator. The administrator will need to be able to easily understand
how the system works and how to make changes , therefore an application for the administrator would
make this job much easier. The code needs to be maintainable and portable as the platform the
administrator may use is unknown. An application that is rendered useless if it cannot be installed is
pointless.
Development will take place on the Windows Millennium Edition operating system and therefore
products used in development will be compatible. As eventually the application will be demonstrated on
either the Windows 2000 system in the School of Computing, the application and the software required to
11
run it will aim to be as platform independent as possible. This is also an advantage for the administrator,
as discussed in 2.3 User Needs.
2.4
User Profile
If the proposed Route Finder is to provide the most beneficial solution to the problem, it is important that
it be made easily accessible. A technology that all students can make use of is the Internet. This may not
be true for all visitors, however as this communication medium is becoming wide spread it can be
assumed that the majority of visitors would be able to access the Internet relatively easily. As an Internet
application, access can be gained using any compu
ter, therefore platform, with a web browser and
Internet connection.
All students of the University have an ISS account, as a result they will have access to the software
available on those machines. Visitors may or may not have access to the Internet. Existing students will
also be able to make use of their ISS account or any other computer accounts they own. Web browsers
installed on the ISS computers are Internet Explorer and Netscape Navigator, it is assumed that all users
will have access to one of these. It is also assumed that the user will have basic Internet knowledge.
Other devices a web browser can be installed on include PDAs and WAP enabled mobile phones. It will
be assumed that the majority of proposed users will not be using these devic es at present, although in the
future this will inevitably change.
2.5
Process Model
The Route Finder will offer a simple, but effective solution to the problem. The processes involved in
using the system therefore, will be straight forward and are represented in Figure 1.
Specify origin
Specify
destination
View map &
directions
Additional
options
Figure 1: Representation of user Process Model.
The user will be able to specify a desired origin and destination. The system will take this input and
determine a route for the journey. A map of the campus and a set of textual directions will be returned to
the user. Options, which have not been determined yet, will be made available and the user can take
whatever action they desire, with the consequent response resulting from the system.
12
2.6
User Requirements
Numerous important attributes have been identified for a good route finding utility. Several of these
become irrelevant, or would not be of much value, in a solution to the identified problem and will
therefore be disregarded from
the requirements. For example, aerial photographs would not be
appropriate as the user would not be able to view sufficient detail in order determine paths or even
buildings. Zooming options is another example; if a route is to be determined from the ma
p, the map
must be at such a level of detail in order for he user to view road names, a zoom facility on this kind of
map would be worthless as no more detail can be gained.
The proposed system contains no personal or confidential information that necessitates privacy or security
to be provided for the user. Therefore these issues will not be incorporated as requirements. However
extensions to this project may incorporate such information, like a user profile, in which case safety
measures would be need to be incorporated.
The User Requirements have been divided into essential and desirable features, and extensions. They
can be viewed in Appendix C. The essential features will allow the user to specify two locations to travel
between, determine a r oute between them, and present the user with a map of the campus and a set of
directions detailing the path to be traversed. The desirable features not only improve on these, but expand
the capabilities of the Route Finder application to allow for ease of use, as discussed in Human Computer
Interaction 2.2, and provide convenient information for route finding. For example, the route found will
be the shortest route according to the data in the database, de partments will be labelled as users may not
know which building they require to get to a particular department, the application will be available over
the Internet to cater for widespread access, and an option to calculate a reverse route will exist. The
extensions would enhance the Route Finder considerably and the majority are far beyond the scope of the
project, for example finding a route between any two points on the map, a keyword search for the
locations to be travelled between and a login provision
with a quick search alternative. Time is the
limiting factor. Delivery of the essential features will provide a solution to solve the problem. The User
Requirements will form the basis for the evaluation criteria.
13
2.7
Technologies
2.7.1 Development Tool Review
As the application is required to be web based, a tool that develops such software is needed. Possibilities
can be assessed against several criteria. Firstly, the Route Finder should necessitate minimum effort from
the user, promoting quicker, easier access to the relevant information; for example a software plug-in may
deter the user. Text and graphics allow the presentation of directions and a map, therefore the tool needs
to support the incorporation and possible manipulation of images. To allow the application to be installed
on a variety of platforms, the tool needs to produce easily portable software.
“Portability refers to the potential to convert data and to share user interfaces across multiple software and
hardware environments.”[24]
This statement refers to interfaces of systems, however can be equally significant to the system itself.
To ease the pain of maintaining the software, the code produced should require as little trouble as possible
to understand and modify. To make best use of the time for this assignment, a tool the author has some
experience of is preferred, and finally the tool needs to be accessed in some way to be utilized.
A comparison of candidate technologies is detailed in Table 3.
14
Table 3: Review of Technologies.
OpenGL
CGI
Java Applets
Java Servlets
Flash
Description
Graphics
Application
Programming
Interface
(API) [25].
Common
Gateway
Interface.
Uses scripts to
deliver HTML
pages.
Client side
programs,
embedded in web
pages [26], [27].
Server side
programs,
produce
HTML [26],
[27].
Specialist
web design
product,
offers
scripting and
server side
connections.
[28]
Image support
Text Support
Learning
Curve
Good.
No.
Intermediate –
author is
taking the
Advanced
Graphics
module
(SI31).
Intermediate.
Yes.
Steep – little
experience.
Poor/Intermediate.
Yes.
Intermediate –
some Java
experience, author
has studied Object
Oriented
Programming
(SO21).
Good.
Yes.
Steep – no
experience.
Free.
Requires
installation of the
language used for
scripts.
Free.
Good. Can use
Java Virtual
Machine of any
platform.
Difficult to write
and maintain
scripts [29].
Knowledge of a
scripting language
required.
Web browser.
Requires
knowledge of
Java.
Intermediate.
Yes.
Intermediate;
some Java
experience
from Object
Oriented
Programming
module
(SO21).
Free.
Good. Can
use Java
Virtual
Machine of
any platform.
Requires
knowledge of
Java.
Free.
Bad. Requires
platform
specific
libraries and
recompilation.
Maintainability Knowledge of
OpenGL
required – not
as common as
other
languages.
OpenGL
User Software
Libraries.
Requirements
Cost
Portability
Speed
Other
Poor.
Used mainly
in game
development.
Web browser with
Specific version
of Java.
Poor/Intermediate. Poor.
Popular.
Expensive.
Unknown.
Flash and
knowledge
of Flash is
required.
Web
browser.
Flash plugin.
Intermediate.
Intermediate.
Intermediate
OpenGL
Although being a powerful tool for graphics applications, it would be impossible to incorporate textual
information with OpenGL and as thi
s is a requirement for the project, this tool is unsuitable. The
OpenGL Programming Guide [25] is an extremely good source if the reader wishes to uncover more
about this API.
15
Common Gateway Interface (CGI) scripting
“The ability of Perl to cope with t ext has made it a popular language to write CGI programs. It's easy to
build dynamic HTML -pages with Perl. You can use Perl to access a database, to read environment
variables and much more.” [30]. However, a new process is started for every request to the script, leading
to inefficiency, especially if the number of users is great and no opportunity exists to store information
between requests, in the program.
Java Applets
Although Java is famous for its portability, as the byte code can be transported to any machine which has
the Java Runtime Environment (JRE) installed on it, Java applets run in the Java Virtual Machine of the
web browser and hence rely on the web browser’s current version of Java. This has caused many
incompatibility problems in the p ast, “in fact; you can’t rely on a Web browser supporting Java at
all!”[26]. Thinking In Java [26] presents a user -friendly approach to learning the language and is well
recommended by the author.
Java Servlets
These have the same portability advantage as Java applets. Eckel [26] suggests, “..on the Web the safest
approach is to handle all processing on the server side and deliver plain HTML to the client.”. As
Servlets produce HTML and “... may perform any task needed.” [31], incompatibilities with u
ser
software will be minimised as simply a web browser is required to view the output. Unlike CGI scripts,
the same instance of the servlet is used for repeat requests, reducing the processing time and offering the
chance of storage within the program. T his option seems appealing. The Sun website [27], producers of
Java, offers a great deal of valuable information on the language and includes many straightforward
tutorials.
Flash
Users would require the Flash plug -in and as the majority of students wil l be using the route finder from
their University of Leeds computer accounts, space is limited and they may not even be able to install the
plug-in. More information can be obtained on this product from Macromedia’s homepage [28], the
producers of Flash.
To conclude the tool review, it can be seen that the Java Servlet technology would be the best
development tool for this project.
16
To assist in the development of the system, an Integrated Development Environment (IDE) would provide
great assistance. With
a built in compiler, debugger, syntax highlighting and code completion
development could be rapidly speeded up. However only limited experience has been had with an IDE
and a slight learning cure will exist if this method is chosen. Products such as Jbu
ilder, Visual Age for
Java and NetBeans are possibilities for Java programming.
2.7.2 Servlets
First a little about Java. Java programs exist as classes, these can be thought of as types. Objects of
classes are created, they are therefore of the type of the class. Methods can then be called on the object.
A servlet is a Java program that resides on a web server and produces dynamic HTML in response to
requests, typically made via a web browser. Servlets have the potential to be very powerful, as being Java
programs, they can not only access all the functionality provided by the language, but benefit from its
platform independence as well. In order to run a servlet, deployment into a servlet container is required.
An example of a request is when a user enters
some text into a text box on a web page and clicks the
‘submit’ or ‘go’ button. The web server, which is integrated with servlet container, manages requests. If
a servlet is being requested, it forwards the request to the servlet container. The servlet
container then
invokes the appropriate servlet passing it the parameters from the web page. A single method of the
servlet accepts and deals with the request. After the necessary functionality has been executed, a response
is constructed and sent back to the web browser in the form of HTML.
Figure 2 shows the processes
allowing the web browser to relate to the servlets.
Servlet Container
response
response
Web Server
Servlet
Servlet
request
Web Browser
request
Figure 2: Interaction involved when accessing servlets.
The init() and destroy() methods of a servlet are life cycle methods. init() creates an instance of a servlet,
while destroy() destroys that instance. These methods are only
called once in the life of a particular
servlet; when the servlet is installed, or the servlet container starts up from a shutdown, and when the
servlet is uninstalled, or the servlet container shuts down, respectively.
One of the fundamental attribute s of servlets is that because the servlet remains loaded in the servlet
container throughout its life time, it can store data between requests; a significant feature lacking in CGI
17
programming where data must be written to a database if it is to be stored. This also means the servlet is
not reliant on a specific database and therefore platform dependence again is avoided. Servlet
programming is discussed in Section 4.4 Servlets.
18
3
Design
Development will take place on the Windows Millennium Edition operating system and therefore
products used in development will be compatible. As eventually the application will be demonstrated on
either the Windows 2000 or Red Hat Linux operating system, the application and the software required to
run it will aim to be as platform independent as possible. This is also an advantage for the administrator,
as discussed in Section 2.3 User Needs.
Java servlets are a server side technology therefore the architecture for the system will be based on the
client-server model. This means the servlet will be installed and running on a machine in a particular
place (the server) and the users will be able to access the Route Finder via a web browser, on a machine
elsewhere (the client). Any alterations that may need to be made to the application therefore, will be
made on the server side of the system and will not require alterations to the client, the machine the user is
using, especially as servlets produce HTML so do not require software additional to a web browser.
As mentioned previously, the time restrictions of this project inhibit the development of a syste
m that
presents all elements desirable in a product of this sort. However, a system that provides a tool of more
practical assistance than current methods of navigation, and is constructed of small, independent software
components, is aimed for. This wil l produce a solution to the problem. It will also allow for simple
maintenance and extendibility, both of which will be necessary in the future.
3.1
Interface
As uncovered in Section
2.2 Human Computer Interaction , the interface design requires intelligent
thought. The requirements have been determined and with knowledge about the intended users and what
they want to do, the web pages can be designed successfully.
3.1.1 Structure
As the system is simple, only two web pages are required. A page for selection of the start and
end location, and a page for the presentation of the results. This structure was chosen because the
first page requires action to be taken and as it is, the subsequent page can inform the user of what
they achieved.
A link on the second page, back to the previous page, will exist, allowing the user to re -select the
locations if they made a mistake, or find a different route.
19
3.1.2 Layout
The main heading on the web page will indicate the function o
f that page. Sub headings will
provide instructions for the user. Heading functionality provided by HTML will be utilized.
The pages will be divided into two sections, vertically. All the information other than the map
will be on the left hand side, wit h the map on the right. This is to allow the user to continually
refer to the map whilst making choices and reading the directions. It will also serve to break up
the page rather than display all the text, then the map or vice versa, and requiring the us
er to
scroll down to view sufficient information.
Additional options such as finding the reverse route will be displayed after the body of the
directions. This seems an obvious position as they provide extra functionality following the main
task of finding a route.
To avoid too much information cluttering up the web site, access to the particular department or
building website will be discretely placed in the sub heading of the third page as a hyperlink
under the name of the selected buildings, before t he route directions are displayed. An example
sentence might look like: To go from the Sports Hall to the Careers Centre:
The same layout will be used for every page, maintaining consistency.
3.1.3 Location Selection
List boxes will be used to allow the specification of locations to be travelled between. Many advantages
can be gained from this.
Errors made by the user are limited as they are only allowed to make valid choices; only locations
that can be travelled between, using the Route Finder, i.e., the locations in the database, will
allowed to be selected.
Users will be able to view all the possible locations they can select, avoiding random guessing
which may occur with text box input.
As no typing is required, the effort the user has to exert to achieve their task is minimised,
decreasing the speed of performance mentioned in 2.2 Human Computer Interaction.
3.1.4 Directions
The aim will be to provide directions that are relevant, to the point, refer to landmarks and can be
easily understood by all users.
A certain amount of detail is required to achieve success. The user’s environment at particular
points will be described, including what they should be able to see in front of them.
20
It is important to incorporate information from the map so users have a visual aid to continually
refer to.
The author’s experience of being a student at the University of Leeds can offer some value to the
directions that will be written for the users. They will be written to be semi-formal, cater for both
students and visitors. Where directions are described in detail for new students and visitors,
names of the buildings en route are als o included to allow existing students to skip ahead where
necessary.
Insight into writing directions of this nature will be gained by exploring directions provided by
other route finders such as MapQuest [8], discussed in Section 2.1.2 Internet Resources.
The directions will be displayed as a number of steps, making them more readable as, “lengthy,
linear texts are not pleasant for users”[24].
3.1.5 Map
A map that shows a clear plan of the campus will be used. J
ust enough colour will be used to
differentiate between buildings, paths, car parks etc.
Names of roads around the campus will be labelled together with the major entrances to the
campus.
The clickable image functionality will require some method to attr
act the user to click on a
particular location. This will be achieved by having a common colour for the buildings the user
can select and incorporating a symbol the user can click, onto the buildings. The symbol will
take the form of a target – a circle with a smaller filled circle of a different colour inside. It is
anticipated the user will easily notice these and make the appropriate association.
When a location has been selected, the target on that building will be highlighted, by changing
into a filled circle of a different colour, again aiding differentiation. “visual representation of the
objects of interest provides a convenient environment for showing changes explicitly.” [24]. This
method additionally attempts to cater for colour
-blind users, as not only the colour, but the
symbol also, changes.
The size of the target and the highlighted circle will both be the same, remaining the same
throughout the map, aiming to ensure consistency to give a simple message to the user.
To provide informat ion about the building, for example the departments contained within it, the
clickable buildings will display pop up boxes when they are hovered over. A less cluttered map
will be the result. Not all users will require this information, making the descri bed functionality
ideal for occasional, on demand display.
21
Only buildings existing in the database will be emphasized and clickable. This will endeavour to
reduce confusion and mistakes by the user.
With the detailed interface design the time to lea rn, speed of performance, rate of errors and retention
over time hope to be optimised, see Section 2.2 Human Computer Interaction.
3.2
Database
As the author had not studied the subject of databases, learning and practicing the subject cut into the time
of the project. Teorey [32] provided a useful insight. In the proposed system, there are buildings to be
travelled between, known from now on as locations. To get between them, paths have to be traversed.
These are the two main elements in the Route Finder, therefore will be the Entities. There will be
potentially many Paths from one Location and potentially many Paths to one Location. Therefore the
following ER diagram can be constructed.
start
Location
Path
end
Figure 3: ER diagram.
The tables in 1st Normal Form will look like:
Location == { name, xpos, ypos }
Path == { start*, end*, length, description }
where * = Foreign Key and ___ = Primary Key. 2 nd Normal Form is satisfied by these tables as the keys
identified are everything required to uniquely identify a row. As there are no dependencies on none
candidate key attributes, the 3
rd
Normal Form is easily satisfied. Paths exist directly between two
locations, a route will be made of several paths. As this is dynamic storage is saved and the database will
be easier to maintain.
22
4
Implementation
4.1
Schedule
Appendix D shows the original schedule for the project. It reflects the initial milestones set, in order to
produce a solution to the problem . However, during early stages of the schedule, a better understanding
of the work entailed in using the technologies had come about and a subsequent breakdown of the
development milestones resulted in modifications to the schedule. The following tasks w ere identified to
complete the Route Finder application.
Installation and basic knowledge of technologies.
Database analysis and design.
Update of servlet to incorporate route finding calculations and clickable image maps.
Draft chapter in progress.
Update of servlet to incorporate propagation of location highlighting.
Update of servlet to return map with lines joining locations.
These are in the order in which they will be embarked upon to achieve the solution. Increasing
functionality will be added to the application with the implementation of each task. The steps involved in
the development of the ‘administrator application’ will be determined when a sufficient ‘user application’
has been built. The existence of an administrator application would gr
eatly promote simpler user
application development, especially for data entry. However, the creation of the user application is the
principal objective in solving the problem and will therefore take priority in the timescale.
4.2
MySQL
The MySQL website [3 3] makes available to download, past and present versions of the product, along
with upgrades. Version 3.23.47 was the most stable release at the time of installation and configuration.
The supplied documentation proved to be an invaluable reference to l earning how to utilize the database
management system. An online copy of the latest version can be viewed from the website [33]. An
introductory tutorial allows quick database and table creation and access.
Following the design of the database required
in the Route Finder system, the subsequent Structured
Query Language (SQL) command created the location table in the routefinder database.
23
create table location(name varchar(30), description varchar(255), xpos
integer(4), ypos(integer(4));
From examples in the tutorial, the types chosen for the data were sufficient for initial purposes. Data
types in the location table were
varchar for the name and description and
coordinates. The path table was created in the same way. Entering all dat
integer for the
a into a text file allowed the
tables to be populated with a few simple steps which read the file. These were repeated every time the
table needed updating, which was a much simpler method of updating the database with many entries.
During a later stag e in development, the discovery of data not being displayed in its entirety lead to the
modification of the original tables. The original data types for long textual descriptions were varchar.
An investigation into this type revealed the maximum string l
ength that could be stored was 225
characters, not enough for our requirements. As the text data type allows up to 2^6 characters, this was
the next size up. Even though it exceeded our needs, it replaced the
varchar data type in both tables.
The altera tion simply required the execution of one command, without the loss of any information or
reloading the table. MySQL proved easy to use.
Additional columns were also added to the location table at a later stage, for the storage of URLs and
departmental or building information, as discussed later.
4.3
Tomcat
Jakarta Tomcat is a servlet container, the “official Reference Implementation for the Java Servlet ..
technology”[34]. Tomcat version 3.3 was chosen for the implementation of this project. It was not the
latest version, Tomcat 4.0, but was decided upon due to the number of predecessors with the same
architecture, and therefore an increased potential for available documentation, if required. Tomcat 3.3
implements the Java Servlet 2.2 Specification [35], which was subsequently used.
Comprehensive documentation was also delivered with this product, again, assisting with installation, the
time consuming process of configuration, and utilisation of the technology. Due to the number of specific
technical terms incorporated into the literature, particular difficulty was experienced with the process of
deployment of a servlet into the servlet container.
24
The Application Development manual found in the documentation [34], recommends a precise directory
structure for organising code during development. Directories
etc/, lib/, src/, web/, and files build.bat
and build.xml, should exist under the principal directory for developing the application. The
directory should contain the file web.xml, the Deploymen
etc/
t Descriptor. This file provides the servlet
container with all the information it requires about the servlets to be deployed. All JARs (Java Archive
Files) should be placed in lib/, whilst all Java source files need to be contained in src/. Files available for
the user to view via a web browser should be contained in
web/; these will include HTML and image
files. build.xml and build.bat need to be placed in the principal directory. These files are used in the
compilation of the code, utilising the bui
ld tool Ant. build.xml defines the necessary steps for
compilation, similar to a Makefile, whilst build.bat processes build.xml and executes Ant according to the
targets specified to it, similar to the Make command. Jakarta provide a simple version of bo th these files,
for individual customisation.
A sample Deployment Descriptor (web.xml file) was also provided, however tailoring this file was far
more complicated. The majority of asisstance to achieve this was contained in the Java Servlet 2.2
Specification [35]. An extract follows.
<!-The servlet element contains the declarative data of a servlet.
-->
<!ELEMENT servlet (icon?, servlet -name, display -name?, description?, (servlet class|jsp-file), init-param*, load-on-startup?, security-roleref*)>
<!-The servlet-name element contains the canonical name of the servlet.
-->
<!ELEMENT servlet-name (#PCDATA)>
<!-The servlet-mapping element defines a mapping between a servlet
and a url pattern
-->
<!ELEMENT servlet-mapping (servlet-name, url-pattern)>
From this, the simplest web.xml file to deploy the Route Finder application contained the text that
follows, it was expanded later in development as necessary.
25
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
"http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
<web-app>
<servlet>
<servlet-name>RouteFinderServlet</servlet-name>
<servlet-class>RouteFinder</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>RouteFinderServlet</servlet-name>
<url-pattern>/RouteFinder</url-pattern>
</servlet-mapping>
</web-app>
The first declaration is mandatory for all Deployment Descriptors. The servlet name identifies the servlet
in this file and must be used when defining other attributes of that servlet, as demonstrated by the servletmapping declaration. The url -pattern is the final part of the complete URL to access the servlet. The
penultimate part, named the context path, is defined in build.xml and added to the location a
nd port
number of the host machine. For the Route Finder application, the host is the local machine, on port
8080, the context path is routefinderapp and the registered URL for the servlet is /RouteFinder, therefore
http://localhost:8080/routefinderapp/RouteFinder will access the servlet.
During the initial stages of configuration, specifying the exact name in the right place in the various files
and keeping track of each one was extremely important to successful deployment of the application. A
note by Jakarta [34] sympathises with the difficulty experienced with the Deployment Descriptor, “Over
time, it is expected that development tools will be provided that create and edit the deploymen t descriptor
for you.”. As configuration was achieved and the steps for developing an application for deployment into
Tomcat had been repeated, concentration could now be focused upon the creation of the application to
solve the problem.
4.4
Servlets
There may be some Java specific terms in this section, please refer to the online documentation for the
Java Development Kit, from the Sun website [27] for more information, or a Java book like [26].
The classes of the servlet API are contained in the servlet.jar file available from the Sun website [27]. It
is necessary to make this file viewable by the Java Virtual Machine, used to run Java programs, for
26
example, by specifying its location in the system path environment variable. Thinking in Java [26] and
the Sun website [27] provided guidance to writing servlets. One of the first servlets created was Test
which created two listboxes.
import java.io.*;
import javax.servlet.*; // Contains servlet classes
import javax.servlet.http.*; // Contains HTTP servlet classes
// All servlet classes extend the HttpServlet abstract class
public class Test extends HttpServlet {
String select = "Please Select..";
public void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
// set content type and other response header fields first
response.setContentType("text/html");
PrintWriter out = response.getWriter();
// then write the data of the response to the output stream
out.println("<title>Test Application</title>" + "<body bgcolor=FFFFFF>");
out.println("<h2>listboxes </h2>");
out.println("<FORM METHOD=POST ACTION=\"testurl\"> ");
// create listboxes
selectLocation("start", out);
selectLocation("end", out);
out.println("<INPUT TYPE=submit VALUE=\"Go get route!\"> </FORM>");
// close the output stream and send to browser
out.close();
}
public void selectLocation(String location, PrintWriter method_out) {
method_out.println("<P><b>" + location + "</B> location");
method_out.println("<SELECT NAME=" + location + ">");
method_out.println("<OPTION>Parkinson");
method_out.println("<OPTION>Union");
method_out.println("<OPTION>Roger Stevens");
method_out.println("</SELECT>");
}
}
And produced the web page shown in Figure 4.
Figure 4: Output from servlet Test.
27
This simple servlet rapidly evolved into an application containing several classes, not only for the
functionality required for the Route Finder, but also to provide an enhanced structure to the application as
the quantity of code grew. The main servlet that initially deals with the request was named RouteFinder.
Many individual components, for example the implementation of
the shortest path algorithm, were
required to create the Route Finder application, these are discussed in the remainder of the chapter. When
a new component was to be introduced, it would initially take the form of a small independent piece of
code. This would be tested and when it was fully functioning, would be adapted to fit into the existing
servlet. This approach proved to be beneficial for many reasons: focus on the specific task, without the
additional burden of how it should be implemented in a s
ervlet, was allowed, therefore the component
could be independently tested and functioning before integration into the application; difficulties arising
during integration could be easily distinguished from any attributed to the actual functioning of the
component.
4.5
JDBC
Java Database Connectivity is an interface allowing Java programs to access data from databases. In
order to utilise this a database vendor specific driver is required. MySQL [33] recommend compatible
drivers. After considerable search ing and download attempts, the version of the mm driver successfully
downloaded from http://mmmysql.sourceforge.net/ was mmmysql -2.0.1-bin.jar. Positioning of this file
into the lib/ directory mentioned previously in
4.3 Tomcat, allows the driver to be ported with the
application and therefore, independent of the Tomcat installation.
The driver needs to be loaded by the Java program in order to obtain a connection to the database and
subsequent data access and manipulation. Unfortunately due to the implementation of the driver, this task
became driver specific and would subsequently need amendment if a different driver was to be used. The
Connection object is used to create Statement objects, upon which, database queries can be made. The
following code illustrates methods to obtain a Connection object and a Statement object.
private static Connection connection;
/**
* method to load the JDBC driver
* @return the connection object
*/
private static Connection getConnection() {
if (connection == null) {
try {
// "The newInstance() call is a work around for some broken Java
implementations" - mmmysql driver author
Class.forName(JDBC_DRIVER).newInstance();
connection = DriverManager.getConnection(CONNECTION_URL);
}
28
catch (Exception e) {
log(e);
}
}
return connection;
}
/**
* method to create an SQL Statement object
* @return the statement object
*/
private static Statement getStatement() {
Statement result = null;
try {
result = getConnection().createStatement();
}
catch (Exception e) {
log(e);
}
return result;
}
The following global fields were created in order to allow minimal changes when one of the values
changed. Only one line of code would require editing as the remainder of the program uses the field
names to access the values. For example if the name of the database changed, the administrator would
simply need to change the DATABASE field and the update would complete.
private static final
private static final
private static final
private static final
private static final
private static final
+ " ORDER BY name";
String
String
String
String
String
String
JDBC_DRIVER = "org.gjt.mm.mysql.Driver";
CONNECTION_URL = "jdbc:mysql://localhost/routefinder";
DATABASE = "routefinder.";
LOCATION_TABLE = DATABASE + "location";
PATH_TABLE = DATABASE + "path";
GET_LOCATION_NAMES = "SELECT name from " + LOCATION_TABLE
Queries, written in SQL, were also implemented as g lobal fields, as seen by GET_LOCATION_NAMES ,
again to allow painless modification and reuse of the query wherever required. The
getLocations()
method which follows, makes use of that particular query to obtain all the locations contained in the
database in alphabetical order. On executing a query, a
ResultSet object is returned, containing the
data. This needs to be extracted and placed into a more specific, usable object, in this case, an
ArrayList object. ArrayList was chosen as it is an efficient co ntainer for collections of elements, of
an unknown size. This data was used to populate the list boxes on the web page for selection of start and
end locations by the user.
private static ArrayList locations = null;
/**
* get all the locations from the database table
* @return location names
*/
public static ArrayList getLocations() {
if (locations == null) {
locations = new ArrayList();
try {
ResultSet r = getStatement().executeQuery(GET_LOCATION_NAMES);
while (r.next()) {
locations.add(r.getString(1));
29
}
}
catch (Exception e) {
log(e);
}
}
return (ArrayList) locations.clone();
}
It was soon realised that the exact query may not be known beforehand, i.e. until the user had input some
data. JDBC caters for this situation with Prepared Statements. Similar to Statements, however, a number
of variables can be omitted from the query, denoted by a ‘?’ and filled in once they are known, before the
query is executed. The example which follows, retrieves the path description between two locations only
established when the user has selected them.
private static final String GET_PATH_DESCRIPTION = "SELECT description FROM path
WHERE start = ? AND end = ?";
private static PreparedStatement pathDescriptionStatement = null;
/**
* get a description of a particular path
* @param origin the starting location
* @param destination the end location
* @return a string containing the description, or null if the path not found
*/
public static String getPathDescription(String origin, String destination) {
String result;
try {
if (pathDescriptionStatement == null) {
pathDescriptionStatement =
getConnection().prepareStatement(GET_PATH_DESCRIPTION);
}
// set values for start and end locations
pathDescriptionStatement.setString(1, origin);
pathDescriptionStatement.setString(2, destination);
ResultSet rs = pathDescriptionStatement.executeQuery();
rs.next();
result = rs.getString(1);
}
catch (Exception e) {
log(e);
result = null;
}
return result;
}
Shortest Path Algorithm
reorder the priority queue.
update the current known shortest distance to v from s to be the shorter distance
current known shortest distance to u from s plus the distance between u and v)
If the current known shortest distance to v from s is greater than (the distance of the
for every vertex adjacent to u, which will be called v,
take the top vertex from it, this will be known as u,
While the priority queue still contains vertices
Fill the priority queue with the all vertices and order it.
except s itself, which is set to 0.
set the shortest distance to it from s to be infinity
For every vertex in the graph
distance from the origin to the required desti nation was found, computation terminated. This occurred if the vertex denoting the destination was
A successful implementation of this algorithm was eventually coded and tailored to the needs of the Route Finder. Firstly, when the shortest
for(each v in V){
dist[v] = INF;
dist[s] = 0;
}
PriorityQueue PQ = new PriorityQueue();
// insert all vertices in PQ,
// in reverse order of dist[]
// values
while (! PQ.isempty()){
u = PQ.dequeue();
for(each v in PQ adjacent to u){
if(dist[v] > (dist[u]+weight(u,v)){
dist[v] = (dist[u]+weight(u,v));
}
}
PQ.reorder();
}
return dist;
queue.
vertices, ordered according to the current known shortest distance to the vertex from s, the vertex with the shortest distance is at the front of the
vertex in the set of all vertices V. dist[v] is the shortest distance to v from s. INF denotes infinity. The priority queue PQ contains unvisited
graph from one vertex, the starting vertex s. The pseudo code is shown in the box on the left, with more description in the box on the right. v is a
comprehendible explanation with readable pseudo code was difficult, but found at [36]. The algorithm finds the shortest route to all vertices in the
Being a well known shortest path algorithm, many resources can be found which describe how Dijkstra's algorithm works. However, unearthing a
4.6
30
allowed to be obtained.
/**
* method that implements Dijkstra's algorithm to get the route
* @return locations in the route, in the order they are visited
*/
public ArrayList getRoute() {
ArrayList result = null;
// set up hashtable - will contain all other Vertices with
// the current shortest distance from the start location
Hashtable shortestDistances = new Hashtable();
// set up priority queue - will contain Vertices
PriorityQueue pq = new PriorityQueue();
// convenient iterator
Iterator locations;
try {
// get the locations
locations = Database.getLocations().iterator();
// for all the locations, populate priority queue
// and shortest distance hashtable
while (locations.hasNext()) {
String name = (String) locations.next();
// create a vertex
Vertex vertex = new Vertex(origin, name);
// populate shortest distance hashtable
shortestDistances.put(name, vertex);
// populate priority queue
pq.enqueue(vertex);
} // at this point, all vertices previousVertex are null except for the start Vertex
// if the priority queue does not contain the destination then we have found the shortest
// distance to it. so, while the priority queue is not empty and contains the de stination
// dequeue a vertex u from the priority queue
// for each location adjacent to it v (provided they are in the priority queue)
//
recompute distances as follows:
//
if ((the current shortest distance to u from s (the start)
//
+ the distance to v from u) is less than
//
the current shortest distance to v from s)
which actually determines the shortest route. The method implementing Dijkstra's algorithm is shown below.
These were returned in an ArrayList for further processing. A PriorityQueue class and a Vertex class were required, along with the Route class
therefore using a recursive method to obtain this attribute of each vertex , all the vertices contained in the route were
the short est distance was not the only information determined. Each vertex has the previous vertex from which it is reached, as an attribute,
no longer in the priority queue, or the priority queue was empty. No unnecessary processing, therefore time is allowed to be taken up. Secondly,
31
}
}
catch (Exception E) {
System.out.println("Error in getRoute()");
E.printStackTrace(System.out);
}
return result;
//
update the current shortest distance to v from s to have the smaller value
while ((!pq.isEmpty()) && (pq.contains(destination ))) {
Vertex dequeued = pq.dequeue();
// get all the locations adjacent to the current vertex and the distance between them
Map adjacentLocations = Database.getAdjacentLocations(dequeued.getName());
locations = adjacentLocations.keySet().iterator();
// for each location adjacent to the dequeued Vertex
while (locations.hasNext()) {
String location = (String) locations.next();
// provided the location is in the priority queue
if (pq.contains(location)) {
// get the Vertices from the shortest distance hashtable
Vertex u = (Vertex) shortestDistances.get(dequeued.getName());
Vertex v = (Vertex) shortestDistances.get(location);
// get the distance from u to v
Float weight = (Float) adjacentLocations.get(location);
// recompute the distances
if (u.getDistance() + weight.floatValue() < v.getDistance()) {
// update v
v.setRoute(u, u.getDistance() + weight.floatValu e());
shortestDistances.put(location, v);
}// end if s->u + u->v < s->v
}// end if priority queue contains the adjacent location
}// end while there are more adjacent locations
}// end while there are Vertices in the piority queue and priority queue contains destination
// get the destination Vertex
Vertex theEnd = (Vertex) shortestDistances.get(destination);
// get the locations contained in the route
result = theEnd.getRoute();
32
33
4.7
Interface
The use of clickable image maps handle user errors by not allowing them to occur in the first place; only
valid selections are permi tted. For effective error handling of this sort, the original design required
modification. If only valid selections can be made, a location must not be available as an origin and a
destination at the same time. The original design allowed this and initi ally a suitable error message was
displayed in this eventuality. However the improved structure of including an additional web page was
considered. The first page would allow selection of an origin. Once selected, a second page would allow
selection of a destination, excluding the origin from the choices. The final page would remain the same
and display the route. By breaking down the selection process, user feedback could now be provided
individually for both selections. This could additionally be ach ieved visually, as the origin could now be
highlighted before the destination selection. This feedback and error avoidance is now easier to attain.
Page 1 can be seen in Figure 5 and pages 2 and 3 can be seen in Figure 6 and Figure 7 respectively.
Figure 5: Page 1, no locations have been selected.
34
On every page, except page 1, exist links back to the previous page and the first page, allowing the user to
undo their last action as well as start again. The hyperlinked text stating the origin and destination can be
seen at the top of the left half of page 3. Where applicable this links to the department website or another
relevant website, such as the Library website for the Brotherton Library location. The reverse route can
be calculated with one click, from page 3 and links to additional useful information were added at the end
of the essential information, reflecting their priority. Important notes to the user were displayed towards
the top of both pages 1 and 2, again to reflect their priority and to “Reduce short term memory load” [24].
4.8
Dynamic Image
A functioning piece of code, independent of the servlet could not be achieved for the dynamically
generated image which would produce the map. The image is to be output to the web browser from the
servlet, therefore the task of dynamically generating images in servlets was tackled as a whole, as
opposed to the individual implementation followed by integration into the servlet.
The map of the campus created by the School of Geography at the University of Leeds [3] and used on a
number of departmental websites, possesses most of the identified attributes of a good map. A version of
this image formed the basis for the map in the Route Finder, it was edited, then enhanced with additional
information and functionality.
The image needed to be manipulated. This meant loading in the image file and drawing on it before
sending it to the web browser. It was d iscovered that there was no straightforward means to do this in
servlets. An example from [37] demonstrated the process of creating an image from scratch and
outputting it using a servlet. This method utilised the Abstract Windowing Toolkit (java.awt) pa
ckage,
provided as standard with the Java Development Kit, please refer to the JavaDoc for more information on
the classes [27]. A BufferedImage object was used to create a Graphics2D object, which could be used to
draw on. The Graphics2D object was then converted to the JPEG image file format and sent to the web
browser. No method was allowed to load an existing image to be manipulated, but this example did use
servlets; the main servlet invoked a second servlet to generate the image. A search for crea
ting a
BufferedImage object from a file, lead to a Java tutorial [38]. Here an Image object is created from an
image file. The BufferedImage class is a subclass of the Image class.
Image img = Toolkit.getDefaultToolkit().getImage("picture.jpg");
35
The height and width of this Image object allowed the construction of a BufferedImage object.
int width = img.getWidth(this);
int height = img.getHeight(this);
BufferedImage bi = new BufferedImage(width, height,
BufferedImage.TYPE_INT_RGB);
From this, again a Graphics2D object is created, allowing the image to be maniplated.
Graphics2D g = bi.createGraphics();
g.drawImage(img, 0, 0, null);
This example allowed an existing image to be loaded and manipulated, therefore, together with the first
example’s servlet capabilities [37], an image could now potentially be loaded from a file, drawn on and
sent to the web browser. Unfortunately a complication existed. The
getWidth() and getHeight()
methods in the second example [38], belong to the java.awt.Compo nent class. This means objects can
only use these methods if their class is a subclass of Component. Subclasses of Component include
Button, Canvas and Label, classes mainly used in applications that create their own output window, such
as applets. Serv lets however use the web browser for their output, so no objects of these subclasses are
necessary. Therefore it was necessary to make the class for the dynamic image a subclass of Component.
A servlet named TweakImage was created for invocation from the
main servlet, RouteFinder. Within
TweakImage it was necessary to create another class, termed an Inner class in Java and named MyImage.
MyImage could then become a subclass of Component. TweakImage creates an instance of MyImage
and calls the inherited height and width methods. The Servlet and Inner class declarations are shown
below.
/**
* servlet that loads a specified image and alters it according to
* parameters passed in
*/
public class TweakImage extends HttpServlet {
public void doGet(
...
/**
* a class to represent an image
*/
static class MyImage extends java.awt.Component {
The extends keyword can be read as, ‘is a subclass of ’.
The image servlet is invoked by passing the
registered servlet URL , as described in section 4.3 Tomcat, to the HTML <IMG> tag in the web page that
is sent to the web browser.
36
Parameters can be passed to servlets in the URL used to invoke them. This technique has been used to
identify which locations the user has selected. For example the URL
http://localhost:8080/routefinderapp/RouteFinder?start=Business+School
is used to invoke the Route Finder servlet when the starting location has been selected as the Business
School.
Propagation of coordinates to the image servlet, determine where the drawing is to take place on the
image. The URL used to invoke the TweakImage servlet is generated dynamically depending upon user
input and the web page that is being displayed at the time. Methods to draw a circle to mark the locations
contained in the Route Finder, to draw a circle to highlight the locations selected, and to draw lines
between two locations, were coded as part of the MyImage class. The RouteFinder servlet determines the
page the user wishes to access and creates the appropriate URL for the image. If the user selects a
location to start from, the coordinates of that location are obtained from the database and concatenated to
the HIGHLIGHT field together with a radius, forming part of the URL.
final String HIGHLIGHT = "&highlight=";
x = Database.getXCoord(start);
y = Database.getYCoord(start);
// highlight start location
imgsrc += HIGHLIGHT + x + "," + y + "," + RADIUS;
This will lead to the highlight of the selected loc ation and the marking of all other locations available for
selection. The <IMG> tag will therefore look like:
<IMG SRC="TweakImage?url=campus.jpg&highlight=90,286,7&mark=496,306,7&….">
The image produced is shown in Figure 6.
37
Figure 6: Page 2, starting location has been selected.
38
When both locations have been selected, page 3 is to be output, so the following code executes.
page = PAGE3;
x = Database.getXCoord(end);
y = Database.getYCoord(end);
// highlight end location
imgsrc += HIGHLIGHT + x + "," + y + "," + RADIUS;
// update locations
locations.remove(locations.indexOf(end));
// make end location not clickable
mapsrc += " <AREA SHAPE=\"CIRCLE\" COORDS=\"" + x + "," + y + "," + AREA_RADIUS
+ "\" ALT=\"" + end + Database.getLocationDescription(end) + "\"
NOHREF></AREA>\n";
// get the locations cotained in the route
ArrayList list = new Route(start, end).getRoute();
if (list != null) {
Iterator route = list.iterator();
// if there are still locations in the list
if (route.hasNext()) {
// make the first location the current one
String current = (String) route.next();
// while there are locations in the list
while (route.hasNext()) {
// get the next location
String next = (String) route.next();
// draw a line between current and next
imgsrc += LINE + Database.getXCoord(current) + "," +
Database.getYCoord(current) + "," + Database.getXCoord(next) + "," +
Database.getYCoord(next);
// update current
current = next;
} // end while
} // end if route.hasNext
} // end if list is not null
// mark remaining locations
This dynamically generates the following URL for the invocation of the TweakImage servlet.
"TweakImage?url=campus.jpg&highlight=90,286,7&highlight=530,309,7&line=90,286,338,404&line=338,404,433
,331&line=433,331,487,383&line=487,383,530,309&mark=496,306,7&mark=229,445,7&mark=485,665,7&mark=
443,508,7&mark=414,459,7&mark=270,298,7&mark=433,331,7&mark=487,383,7&mark=415,567,7&mark=484,6
28,7&mark=338,404,7&mark=354,716,7"
Using these ‘highlight’, ‘line’ and ‘mark’ parameters the TweakImage servlet uses the MyImage Inner
class methods to highlight the selected locations, draw lines to join all locations that make up the route,
and mark all other locations in the Route Finder. An extract of the TweakImage code can be seen below.
The lines are drawn before the circles, for neatness. The image produced is shown in Figure 7.
MyImage img = new MyImage(url);
// draw the lines first, so that the circles (if any) go on top of them
img.drawLines(request.getParameterValues("line"));
img.markCircles(request.getParameterValues("mark"));
img.highlightCircles(request.getParameterValues("highlight"));
// send to browser
img.send(response);
39
Figure 7: Page 3, both locations have been selected.
Interactive Map
A clickable image map can be created using HTML. This too was generated dynamically, depending
upon the location/s that had been selected at the time . If no locations had been selected, i.e. page 1 was
being displayed, all the locations were available to click. The clickable areas of the map coincided with
the circles used to mark the buildings. When a starting location had been selected it was remo ved from
the clickable circles, as well as highlighted, in yellow. On page 3, as seen in Figure 7, the route has been
determined therefore, no locations are clickable. An extract of the code that produces the HTML for the
clickable image maps is given below.
mapsrc += " <AREA SHAPE=\"CIRCLE\" COORDS=\"" + x + "," + y + " " + AREA_RADIUS
+ "\" ALT=\"" + location + Database.getLocationDescription(location) + "\" ";
Sample HTML generated by this code looks like:
40
<MAP NAME="imagemap">
<AREA SHAPE="CIRCLE" COORDS="496,306 9" ALT="Brotherton Library Art and Social Sciences;
Education; Special Collections" HREF="RouteFinder?start=Brotherton+Library"></AREA>
<AREA SHAPE="CIRCLE" COORDS="90,286 9" ALT="Business School Institute for Corporate Learning,
International Institute for Banking and Financial Services, Centre for Research in Credit Management, Centre for
International Business (CIBUL) - Maurice Keyworth Building"
HREF="RouteFinder?start=Business+School"></AREA>
….
</MAP>
<IMG SRC="TweakImage?url=campus.jpg&mark=496,306,7&mark=90,286,7&….>
The ALT values in the above HTML
allow pop up boxes to appear when the
user hovers over the circles with the
mouse. An example can be seen on
the right, when the mouse is hovering
over th e Business School. These pop
up boxes exist for all locations in the
Route Finder on every page. The
information supplied is stored in the
location database and was taken from
the University of Leeds website [2].
As the images displayed on the web pages are dynamically created, they are not stored anywhere. Only
the image of the original map of the campus from the School of Geography is stored.
During the development of the dynamic image, many calls were being made to the database and JDBC
code was contained in many of the classes. To provide better and neater structure of the code, a database
class was created to deal with all the calls to the database. It was not intended that an object of this class
be created, as only one object would be needed,
as there was only one database, therefore a hidden
constructor was implemented and all methods and fields became static. This does not follow object
oriented (OO) principles, however in this case OO would lead to unnecessary objects making the
application more complicated, therefore slower, and more difficult to maintain.
41
4.9
Administration
“The software should be maintainable…it should be written and documented so that changes can be made
without undue costs.” [39]. This has been a predominant factor throug hout this project. Not only as it is
good software engineering practice to develop easily maintainable and extendible software, but also as
this project has uncovered the very basics of how the solution could be realised. This means it requires
additional data and functionality to become a more useful tool. This consequently requires the people
carrying out this task to easily understand the logic behind the code as well as make changes simply. All
the code has been commented sufficiently and to ensure
it was, JavaDoc commenting was used
throughout. This form of documentation is standard to Java programs and provided with any Java classes
obtained from Sun [27]. The JavaDoc for the Route Finder is included in Appendix E.
The quality of the user appli
cation, the Route Finder, could have been compromised in order to
additionally achieve an administrator application. However, this would have created two low quality
applications, and as a result neither would have been of much benefit for the persons in
volved.
Concentration was therefore directed towards the user application, the Route Finder, which was the
principal deliverable in solving the problem. Utilisation of the administrator application would have
greatly enhanced the development of the user application. Facilities to add new locations to the database,
click on the map to select the buildings to be included in the Route Finder, select any point on the map etc
would be provided and as a result quicker and easier development of the Route Finder
could have taken
place.
The HTML that is output from the servlet was coded so that a neat HTML file could be created, helping
users or administrators who wish to view the source.
42
5
Testing
As far as possible, components of the application were built and tested individually before becoming part
of the servlet, the image generation being the exception. Errors in logic therefore were determined early
on. The servlet was also tested, to a reasonable level, after each integration. The text editor initiallyused
was GVim as it provided syntax highlighting, for ease of use, and the author had had previous experience
with this tool. This then allowed development to commence sooner. However as the quantity of code
grew it became increasingly difficult to debug the code. An IDE was then sought. Eclipse was a recent
offering by IBM that was freely available and highly recommended by a former colleague. As
compilation occurs every time the code is saved, simple programming errors were almost immediately
corrected and the debug facility proved most beneficial with the TweakImage servlet.
Section 2.2 Human Computer Interaction mentioned five factors Shneiderman [24] deemed important.
The last was subjective satisfaction, “how much did users like using various aspects of the system?” [24].
Five testers were questioned on their opinions of the map, the directions, and the Route Finder in general.
Many positive responses were received about the map; the testers fo
und it clear, liked the clickable
functionality and the joining of the locations. However suggested improvements included drawing of the
lines along the exact route to be traversed, and the labelling of buildings on the hard copy of the map.
The directions were praised for being clear and to the point; most of the testers realised they were being
pointed to the entrance of every building along the route and although they thought it was a little
unnatural, they accepted this. The exception though would ha ve liked to see a clear statement informing
the user that the directions go to every location making up the route. Overall Route Finder feedback was
equally positive and negative. Some testers indicated they would just use the directions instead of the
map, however one pointed out they would have taken a wrong turning if they did
not have the map, the
others liked the availability of a hard copy map. Three testers would have liked to select the origin and
destination from the same page, “instead of [the
list box] changing function between pages”. More
locations in the Route Finder would have liked to be seen, along with buildings certain departments were
situated in and room numbers. A first year tester also suggested the inclusion of accommodation for
exams. From observing the testers within two minutes all had found a route. They seemed to enjoy
clicking, some started this before reading the notes on how to use the Route Finder. The visual
information after each step kept the testers interested and a general “wow” was uttered on the presentation
of page 3, and when the pop up boxes were discovered. Not all of the testers discovered the disguised
hyperlink and were eventually pointed towards it, resulting in positive response.
43
The testers were existing University of Leeds members, two being first year students. Some of the testers
were the same people questioned at the beginning of the project who had identified weaknesses in the
current aids to navigation. Each tester took a different route, of a different length, in different sections of
the campus, in an aim test widely. None of the testers were visitors so knew the locations near to the
main entrance to the University. All the testers said they would use this route finding aid if they were
aware of it and it contained more locations that could be selected. The testing is by no means complete.
Visitors and first year students in their first few weeks need to become testers. All routes and
combinations of routes need to be tested by all types of user. Concurrency testing also needs to be carried
out to gain insight into how the software and tools that support it cope with multiple users at the same
time.
6
Evaluation
A number of requirements were identified after research into relevant navigat ional tools, see Section 2.6
User Requirements. These now form the basis to evaluate the produced system against.
All the essential features were implemented. The user has two means to specify their desired origin and
destination, list boxes and a clickable image map. A route is calculated between the two locations and a
set of textual directions describe how the route is to be traversed. A map of the campus is also displayed.
The majority of the desirable features have also been implemented. The map shows a clear plan view of
the campus allowing all paths and buildings to be seen. The map was aimed to be simple, so the existing
numbers from the original image were re moved and the locations available for selection were denoted
with a target like circle. The inclusion of pop up boxes which displayed the name of the building and the
departments or offices contained within it was to keep this information off the map unle
ss a user was
actually interested in it. In this case the user could hover over the buildings before selection, or select the
location using the list boxes, view the highlighted location on the map and then over the building to see
the information. Therefore the map was kept simple enough for the users to select their locations quickly
and easily. The map provided subtle colour coding which distinguished between buildings not in the
Route Finder, car parks etc and paths. A more prominent colour was used
for buildings in the Route
Finder to attract the user’s attention as well as for the joining lines. The pop up boxes provided labelling
of buildings, but only on the interactive map. This requirement was therefore only met to a certain extent.
To provi de labelling on the hard copy of the map, additional functionality could be incorporated to
produce an image which explicitly labels the buildings that make up the route, before the image is printed.
This would not take too much time to implement. The po
p up boxes also provide for the labelling of
44
departments where applicable. This information can be viewed before any selection is made, offering
assistance to those users who may not know which building they require to get to a particular department.
The map used clearly displays roads, car parks and entrances to assist users travelling by car. As already
discussed the clickable image map allows specification of locations. This promotes ease of use as the
user can visualise the campus and click on their origin and destination, as well as user error reduction, or
in this case elimination. One of the testers, a first year student at the University of Leeds, was previously
a professional software tester and commented on the fact that he could not “break it”.
Labelling of useful locations did not go beyond the Parkinson Building which was included on the
original map. A less cluttered map was aimed for, and thought to be of a higher priority than labelling
useful locations, to allow the user to see the ma p clearly and be able to make choices. All the directions
include relevant names of locations as they are passed on the route, therefore compensate to an extent for
the deficiency in labelling. Labelling of places of interest such as eating areas has als
o not been
implemented, this was given lower priority than the User Requirements that have been implemented.
Calculation of the shortest distance between the two locations was implemented, using the effective
Dijkstra's Shortest Path Algorithm. The algorithm was tailored to the needs of the Route Finder so all the
locations in between the origin and the destination could be determined, in order to construct the textual
directions and line joining; excess computation was also omitted. The Route Finder i
s an Internet
application that can successfully be used via Internet Explorer and Netscape Navigator, with no additional
software. However, the pop up boxes are not fully functioning in Netscape Navigator at present.
The directions provide enough detail for the user to easily determine their next step, without being too
long winded. The testers confirmed this. Highlight of landmarks has been achieved, both on the map,
with the existing image displaying a picture of the Parkinson Building, labelling St G eorge’s Field, etc,
and in the directions, which provide detail of smaller landmarks like the fountain. The directions are
conveniently broken down into steps, corresponding to direct paths between two locations.
An email option was not added due to ti me constraints, however users can still email the routes via other
means such as copying and pasting the URL of that particular route or more inconveniently saving the
web page and emailing the files. An estimation of a couple of days is given to implemen
functionality. The reverse route can be found by the simple click of a button.
t this
45
As the shortest path was calculated using coordinates of the locations on the map, these could not be
displayed as actual distances. Some form of scaling would need t o be done and the coordinates would
need to be measured from the entrances of the buildings and not the centre, as implemented at present.
However a more realistic walking distance measurement could only be obtained from the actual route the
user is inten ded to traverse, at present, the distances between two locations are determined as a straight
line connecting the centres of the buildings. If the improved walking distance measurement is obtained, it
would provide better data for the route finding algori thm, which could change the route the Route Finder
determines, especially as walking around buildings would take longer than the current ‘fly directly to the
centre of the next building’. For now, the note highlighting the fact that no journey should take
longer
than 15 minutes, should suffice and would still allow the Route Finder to be a useful aid.
The user can print the web page detailing the route, using the web browsers capabilities. Unfortunately,
neither web browser permits full printing of the width of the image. For the testing, the layout of the final
web page was changed before printing, to allow the majority of the image to be printed. To overcome
this another servlet could be invoked to reduce the size of the image and send it to the print er. Relevant
additional resources are linked to from every page of the Route Finder, including links to websites of
selected locations where valid. The interface has fulfilled the requirements. The information in the
database is presently accurate, howe ver change could occur at any time and to ease the pain of updating,
the administrator application would need to be developed; time restrictions meant this could not be
achieved.
One of the extensions was implemented in order to provide greater assistance
to the user than the
desirable features not yet created. Lines join not only the origin and destination, but also the locations
contained in the calculated route. This helps the user to visual their actual route. Unfortunately the lines
do not take bui ldings into account, something intelligent path finding would do [40], so do not show the
route detailed in the directions. A way around this could be to include ‘way points’ on the map, these
would simply be junctions or points along walk ways to allow t he lines to be drawn around the buildings.
The administrator application would have made this task much simpler.
To summarise, as discussed, the Route Finder meets all the essential features, 17 out of 24 of the desirable
features fully, four partially a nd failed to meet three. It also meets to a reasonable level one of the
extensions.
If Current Aids to Navigation are to be evaluated then they must serve as some sort of aid
to the problem. As some of these re sources cannot provide information about the campus they must be
not be evaluated. The University Resources attempt to solve the problem and were therefore evaluated.
46
The map of the campus on the University of Leed s website [2] scores one out of five for the essential
features as no specific directions are given, and seven for the desirable features, mainly due to the
extensive labels. No extensions are met. Maps provided by other departments score even less as
although clear plan views of the campus are supplied, not much more information is given. The
University of Leeds Pocket Guide obtains one of the essentials and ten of the desirable features, again due
to the extensive labelling, but also the clear, colour plan of the whole campus. The Library map scores
less and the maps provided by departments total an even smaller amount as they supply even less
information. The public maps around the campus meet up to three of the desirable features and one of the
essential, while the People based method scores between two and five of the requirements. The Route
Finder therefore offers a better solution to the problem according to the evaluation criteria which were
justified in Section 2 Background Research.
6.1
Lessons Learned
The Route Finder was originally to be ported to a Windows 2000 machines in the School of Computing
for demonstration. Unfortunately a different version of Tomcat had to be installed on this machine,
Tomcat 4.0. This version has a completely different architecture to the previous versions which were all
similar to each other. A lot of effort was put into reading the documentation for this version and
determining the exact differences and requirements needed to port from Tomcat 3.3 to Tomcat 4. There
was no easy method if development was to continue to take place on this machine, as was required. A
complete application could be ported, but would not allow modification. A new method of deployment
had been introduced which Support suggested should be used, instead of providing root level access in
order to stop and start the servlet container, the method currently used. Many consultations with Support
lead to steps being taken in the right direction, for example the Ant build tool required installation, the
path needed to set on more than one machine, access higher up the directory structure was repeatedly
required, etc. As this time was not being spent on actually producing the Route Finder, an alternative
method for demonstration was decided upon and this one abandoned. The pursuit would have been
advantageous though as the Route Finder could then be accessed via any browser as the permissions of
the potential host allowed this. This could be achieved in a couple of days maximum.
6.1.1 Eclipse
As mentioned previously Eclipse is an IDE. Creating well commented code was encouraged by Eclipse
as pop up boxes provide the JavaDoc comments for the field, method, class being h overed over. All the
code has been commented in the style of JavaDoc. This allows a simple command to be executed at the
47
command prompt, to give a structured API for the Route Finder. This is included in Appendix E and
easily allows the relationships be tween the classes to be viewed, along with the role each field, method
and class play in the application. All packages are displayed with their fully qualified names. JavaDoc is
created by an executable provided with the JDK and therefore produces a standard format of output for all
applications. Therefore Java programmer should easily be able to understand and modify the application.
The JavaDoc for the classes used to create the Route Finder were found to be invaluable.
48
7
Future Work
Most of the work entailed can seen in section 6 Evaluation.
One of the ways to make the application more usable without adding functionality, is by populating the
database with more locations. This would additionally r
equire the image to be manipulated using a
software package to colour the buildings that were added. The administrator application would have
allowed this task to be carried out with ease.
Initially the calculation of the distance between two locations w
as carried out manually and the data
entered into the database. This was updated so a class could carry out the calculation. This could be the
beginning of the administrator application and could quite easily be extended into a servlet for this
purpose.
The printing facility is also an important need for improvement.
The extensions identified in the
User Requirements section would increase the functionality of the
application greatly some of these could be a separate project in themselves.
Additional future work includes:
Providing routes to the different entrances of the buildings and not just the main entrance.
An increased level of detail to eventually allow departments and room numbers, being of greater benefit
to existing students and staff.
Improved quality of line joining, so it actually reflects the route taken.
Alternative routes, such as routes for disabled people and cylists, as well as routes during busy times of
the day.
If the Route Finder becomes too complicated, a user manual may be required.
49
8
Conclusion
Although many improvements could be made on Route Finder so that it could actually be used as a
product the project has brought together the basics of what is required. The code has deliberately been
written so tha t it is easily understood and extendable in the hope that it will be improved on as it could
very easily become a valuable resource to the identified users.
50
9
Glossary of Terms
PDA – Personal Digital Assistant. A term used to describe small, handheld computers, for example those
based on Microsoft’s Pocket PC and those manufactured by Palm.
Route Finder – The proposed solution to the navigational problem around the campus of the University
of Leeds. an origin and destination will be taken as input to the system and the shortest route between the
two locations will be found. Presented to the user will be a map of the campus showing the building in
the route and a set of textual directions describing the route.
Route - Constructed of paths.
IDE - Integrated Development Environment, for example, Eclipse, NetBeans and Visual Age for Java.
Platform – Processor make/operating system.
API – Application Programming Interface. Allows the user to understand the classes in the program.
Path – Connects two locations directly.
Clickable image map - Image with areas that can be clicked, taking the user to different URLs.
List box – Input box with choices to be selected from.
Text box – Allows keyboard input from the user.
Hyperlink – Clickable text.
Driver – Software to allow integration between other software.
Method – Function or procedure in Java.
JavaDoc – API for Java applications.
Gvim – A text editor.
51
10
References
[1] Alberts, M, (3rd February 2002) Road Map Collectors Association, URL:
http://www.roadmaps.org/home.html [13th April 2002]
[2] University of Leeds, Campus Map, URL:http://www.leeds.ac.uk/campus_map/campus.htm [29th
March 2002]
[3] http://www.geog.leeds.ac.uk/images/campusweb.gif [4th April 2002]
[4] School of Mathematics, (14 November 2001) Directions and Contacts School of Mathematics,
URL:http://www.amsta.leeds.ac.uk/school/contacts/index.html [4th April 2002]
[5] Corporate Web Team, (March 2001) The University of Birmingham - Location Information and
Maps, URL: http://www.location.bham.ac.uk/directions.htm [13th April 2002]
[6] The Editors, (12 March 2002) University of Southampton - How to get to the University,
URL:http://www.soton.ac.uk/~indexes/maps/ [13th April 2002]
[7] Multimap.com, URL:http://www.multimap.com/ [4th April 2002]
[8] MapQuest, URL:http://www.mapquest.com/ [27th March 2002]
[9] The AA: Breakdown cover, driving school, insurance and travel news, URL:http://www.theaa.com/
[4th April 2002]
[10] RAC Motoring Services, RAC European Route Planner http://www.rac.co.uk [4th April 2002]
[11] Streetmap.co.uk, URL:http://www.streetmap.co.uk/ [4th April 2002]
[12] Quinn, T, (5th April 2002) Tony Quinn’s VR Leeds, URL:http://www.vrleeds.co.uk/ [5th April 2002]
[13] Leeds City Council (17th January 2000) City Centre Maps
URL:http://www.leeds.gov.uk/tourinfo/locate/citymaps/centre/city_map.html [5th April 2002]
[14] ACTION, (4th April 2002) ACTION - <<DISCOVER THE PLUSES OF BUSES!>>, URL:
http://www.action.act.gov.au/default.cfm [14th April 2002]
[15] The Toronto Transit Commission Route Schedules,
URL:http://www.city.toronto.on.ca/ttc/schedules/index.htm [14th April 2002]
[16] TomTom Route Planner Europe, URL:http://www.palmtop.nl/palm/routeeur.html [15th April 2002]
[17] Welcome to pocketstreetmap.com, URL: http://pocketstreetmap.com/ [15th April 2002]
[18] Microsoft Corporation (8th January 2002) Microsoft AutoRoute,
URL:http://www.microsoft.com/autoroute/ [15th April 2002]
[19] Joesbury, A, (2001) An Internet Tour of the School of Computer Studies at the University of Leeds,
School of Computer Studies
[20] Brown, A, (2001) Leeds University as a 3D world, School of Computer Studies
[21] Hinchcliffe, M, (1996) A Route Finder Application for Windows, School of Computer Studies
52
[22] Chauhan, A, (2001) Virtual Reality Walkthrough of University Department, School of Computer
Studies
[23] Kirk, A, (1997) A VRML V2.0 Campus Map, School of Computer Studies
[24] Shneiderman, B, (1998) Designing the User Interface: Strategies for Effective Human-Computer
Interaction, 3rd Edition, Addison-Wesley, (chapters 1,2,7,16)
[25] Architecture Review Board [et al] (1997) OpenGL Programming Guide, Addison-Wesley
[26] Eckel, B, (2000) Thinking in Java 2nd Edition, URL: www.BruceEckel.com, Planet PDF
[27] http://www.java.sun.com [28th April 2002]
[28] http://www.macromedia.com [16th December 2001]
[29] http://www.spiderpro.com/bu/bujavm004.html [16th December 2001]
[30] http://www.spiderpro.com/bu/buprli.html [16th December 2001]
[31] http://www.ecst.csuchico.edu/~gmurray/presents/servlets.html [16th December 2001]
[32] Teorey, TJ, (1999) Database Modelling and Design 3rd Edition, Morgan Kaufmann Publishers, Inc
[33] MySQL URL:http://www.mysql.org [15th February 2002]
[34] The Jakarta Site – Apache Tomcat, URL: http://jakarta.apache.org/tomcat/ [3rd February 2002]
[35] Sun Microsystems, (1999) Java Servlet Specification, v2.2,
URL:ftp://213.244.188.40/pub/servlet/22final-182874/servlet2_2-spec.pdf [15th December 2001]
[36] (November 2001) URL:http://www.cs.nott.ac.uk/~nza/G5BADS/slides17.pdf [15th April 2002]
[37] Creating Dynamic Images with Java Servlets, http://www.drbob42.com/jbuilder/img_srvl.htm [21st
March 2002]
[38] Solving Common Graphics2D Problems http://java.sun.com/docs/books/tutorial/2d/problems/ [21st
March 2002]
[39] Sommerville, I, (1992) Software Engineering 4th Edition, Addison-Wesley
[40] Liu, B, (1996) Intelligent Route Finding: Combining Knowledge, Cases and An Efficient Search
Algorithm, John Wiley & Sons, Ltd
53
Appendix A Personal Reflection
The project proved to be a completely different experience from any coursework previously undertaken.
It was a one person project which almost certainl y means it would have been limited, in terms of ideas
and skills. However, it felt like quite an achievement to initially undercover a problem and work at
providing a solution, even though I had no idea of how the solution would materialise.
Many new ski lls were gained even though they proved hard to acquire. Not much experience with
seeking out the correct products for installations for a particular operating system, along with the
installation and configuration process had previously been had. This pro ved to be quite difficult but skills
increased with the number of products used. I did however find the use of an internet connection at home
to be invaluable, not only for product downloads but also for solving problems that other people had
previously experienced.
The problems with porting the application between different versions of Tomcat proved to be a setback. If
this was to be done again I would insist upon the installation of the same version I was using, Tomcat 3.3,
on the School of computing machines.
I had never used Java to manipulate images and thought it would provide a better facility than I found.
Next time I would look into the quality of the image support for the exact tools I was using.
Overall I did surprise myself with how my idea could actually be created into a useful application, and am
pleased with the outcome.
54
Appendix B Campus Maps
55
Appendix C User Requirements
Essential Features
1. Provision for specification of origin.
Allow the user to input a building to travel from.
2. Provision for specification of destination.
Allow the user to specify a building to travel to.
3. Calculation of a route between the specified locations.
Determine a route between the given origin and destination.
4. Display of directions.
Present a set of textual directions which describe the route to be traversed in order to reach the destination
from the origin.
5. Display of map.
Present a map of the campus.
Desirable Features
6. Clear plan view of the whole campus.
This will allow the user to see exactly how the campus is laid out. They should be able to easily depict
where buildings are situated in relation to other locations and where pathways exist.
7. Simple map.
There should not be too much information or detail on the map. This may distract the user from
determining their desired location quickly and easily.
8. Colour coded map.
Colour should be used appropriately, making distinctions between those areas where buildings exist and
those where they do not. Too much colour can be confusing, but no colour can be a hindrance.
9. Label buildings.
There should be some method to identify the names of buildings. This will assist the user on the journey
as they pass the buildings.
10. Label departments.
There should be some method to identify the departments contained within buildings, where applicable.
Users may not necessarily know which building they require to get to a particular department.
11. Label roads, car parks, and entrances.
Roads around the campus should be clearly labelled, together with all visitor car parks and entrances to
the campus. This will assist users travelling by car.
56
12. Interactive/clickable map.
Allow the user to select their required start and end locations. As used by many of the Internet Resources
2.1.2 this selection method will offer an attractive visual alternative, as well as reducing the chances of a
user making an error.
13. Label useful locations.
There should be some method to identify useful locations such as the Parkinson Building and the Union
Building.
14. Label places of interest.
There should be some method to identify places of interest such as eating areas.
15. Shortest route calculated.
The route determined should be the shortest route possible according to the data in the database.
16. Available over the Internet.
This will allow wide ranging accessibility of the application, ensuring the majority, if not al
l, of the
intended users will be reached. The application should be compatible with Microsoft Internet Explorer
and Netscape Navigator as these are the two most widely used web browsers [].
17. Concise directions.
The directions should be brief and to the
point. Readability maybe reduced if a lot of unnecessary
information is provided.
18. Directions should not be too vague.
Sufficient detail should be provided so the user is clear as to which path to follow.
19. Highlighting of landmarks.
Prominent features around campus should be brought to the users attention, allowing easy identification
of position in relation to other locations, start location and end location.
20. Broken up text for directions.
Text detailing the directions of the route will be more readable if it is in sections rather than in one big
block.
21. Email route option.
Provision for email of the map and directions.
22. Save route option.
Provision for storing the map and directions, in order for them to be retrieved at a later date. Thi
s will
save the user a little time when wishing to find the same directions again.
23. Reverse route calculation.
Calculation of reverse route should be a simpler process for the user than the calculation of the initial
route.
57
24. Total route distance.
An estimation of the distance of the route will inform the user of how far they must travel.
25. Total route time depending on mode of transport.
An estimation of how long the route will take, dependent upon method of transport, will allow the user to
arrange time of travel appropriately.
26. Print option.
Provision for printing of map and directions will allow portability of the information for an individual
route.
27. Links to useful websites.
Provide access to other resources which will be of some interest to the user, for example maps of the city
centre.
28. Good interface.
Provide an interface that allows the user to find a route easily and is aesthetically pleasing.
29. Reliable information.
Provide information that is accurate, this requires the applica
tion to be easily administered and
maintainable.
30. Administrator application.
Extensions
31. Draw lines joining buildings on the map.
Draw lines on the map which join the buildings to be travelled between
32. Numbers on map corresponding to directions.
Some form of distinct correspondence between the textual directions and map, would allow the user to
distinguish which parts of the map related to which parts of the directions.
32. Downloads to PDAs.
34. Room numbers.
35. Wireless services.
36. Routes via other locations.
37. Alternative route.
38. Security.
39. Login/logout.
40. Quick search.
41. User profiles with standard options set by default.
42. Specialised Routes – e.g. Cycling / Disabled (ramps, lifts, different entrances)
58
43. Routes between any two points on the map, not just certain locations.
44. Keyword search for locations.
59
Appendix D Schedule
The original schedule
Dec-28th
January
28th January
4th February
Exam and Revision Period.
Background Research complete.
Mid-Project report comm ents considered and appropriate action taken. Prototype
simple application.
Design application and database.
11th February
18th February
25th February
4th March
11th March
18th March
25th March
1st April
8th April
15th April
22nd April
29th April
1st May
Develop Student Application.
Develop Maintainer Application.
Test, Amend, Deploy, Test, Amend.
Start final report write up.
Revise for exams.
Final report almost complete.
Submit final report.
Revised schedule
11th February
18th February
25th February
4th March
11th March
18th March
25th March
1st April
8th April
15th April
22nd April
Installation and basic knowledge of technologies.
Database analysis and design.
Development of servlet to specify locations and present map of the campus with
directions.
Implement route finding calculations.
Update of servlet to incorporate route finding calculations and clickable image maps.
Draft chapter in progress.
Update of servlet to incorporate propagation of location highlighting.
Update of servlet to return map with lines joining locations.
Allow for slippage.
Hand in draft chapter.
Development of administrator application.
Progress meeting.
Allow for slippage.
Break.
Test, Amend, Deploy, Test, Amend. Write report.
Write report.
Revise for exams.
60
Appendix E JavaDoc