PATH

Technical Documentation

Version 1.00
 Revision History
Date Version Description Author
2009-26-01 1.0 Final MO
PATH Version: 1.00
Technical Documentation Date: 2009-26-01

Table of Contents
1. Introduction 5
1.1 Purpose of this document 5
1.2 Intended Audience 5
1.3 Scope 5
1.4 Definitions and acronyms 5
1.4.1 Definitions 5
1.4.2 Acronyms and abbreviations 5

2. General overview 5
2.1 Technologies used 5
2.2 General functioning 6
2.3 Error handling 6

3. Technical requirement 6
3.1 Client requirement 6
3.2 Server Requirement 6
3.3 Google map API 6

4. PATH Source structure 6

5. Architecture 7
5.1 High Level Architecture 7
5.2 PATH Class Diagram 8
5.3 User search Sequence Diagram 9

6. References 10

Page 4
PATH Version: 1.00
Technical Documentation Date: 2009-26-01

1. Introduction

1.1 Purpose of this document

The purpose of this document is to give technical information about PATH design and
implementation.

1.2 Intended Audience

The intended audiences are:

 Supervisors, to analyze the design and implementation of PATH.
 PATH team members.
 Future developers to extend or use some ideas of PATH project.

1.3 Scope

This document will describe the design and some technical issues of PATH project. Further
documents could be found on DSD web site.

1.4 Definitions and acronyms

1.4.1 Definitions

Keyword Definitions
Google MAP API API provided by Google to use Google maps

1.4.2 Acronyms and abbreviations

Acronym or
Definitions
abbreviation
PATH Public Advice Traveling Help
GIS Geographical Information System
UIL User Interface Layer
DAL Data Access Layer
BOL Business Object Layer

2. General overview

2.1 Technologies used

PATH is a web based application that depends on Google map API. We used MySQL, Eclipse, Apache
server, PHP and Google map API. Except from Google technology that we just have access to the API list, all
other technologies and component are open source.

Page 5
PATH Version: 1.00
Technical Documentation Date: 2009-26-01

2.2 General functioning

The following are the major system functionalities:

 Register user in PATH web site.
 Suggest the suitable advices for different routes or places according to user preferences.
 Store advices given by users.
 Store advice types entered by users.
 Manage advice entry conflicts.
 Allow Administrator to manage conflict parameters

The two last functionalities are not yet integrated to the system and partially implemented.

2.3 Error handling

As the architecture is three tires, exception handling was done on each layer separately. The layer that
was faced with an exception, raise a new exception to the upper layer if needed. The final layer which
is UIL decides the proper message to show to PATH users and with the current implementation, UIL
usually redirect the user to a special page that contains the proper message.
3. Technical requirement

3.1 Client requirement

As PATH is a web application it could be run on most of custom operating systems via a web browser.
We tested PATH with Chrome 1.0 and IE 7.0 and found no problem.

3.2 Server Requirement

The following technologies are required for PATH server.

 Mysql 5.1
 Apache 2.2.1
 PHP 5.2.8

3.3 Google map API

Google Maps allows was used to manipulate maps by adding waypoints, information markers, plan routes etc.
JavaScript was used to use Google map API. The Google Maps API provides utilities for manipulating the map
like loading waypoints and creating routes from waypoints. Google Maps currently supports driving and
walking directions. To use the Google Maps API one must sign up for an API key and we registered one key
for PATH web site. Google Maps API is free to use as long users are less than 50,000. The web site which is
for Google map key registration is http://code.google.com/apis/maps/signup.html. There are some documents
and samples of using Google map API that could be found in http://code.google.com/apis/maps/. Some special
very close related documents that are available for PHP, MYSQL and Google map API could be reached at
http://code.google.com/apis/maps/articles/phpsqlajax.html.

4. PATH Source structure

There are three main folders that represent three tiers architecture of the project. Figure 1
shows the files we had for implementation. PATH presentation layer contains 13 files. BOL contains
10 files and finally DAL includes two files. The average number of lines of code for each file is about
100. We used a big header file that include left side menu bar also upper menu bar. Also a common
Page 6
PATH Version: 1.00
Technical Documentation Date: 2009-26-01

footer was used for all PATH web pages.

Figure 1: File structure of PATH. It contains UI folder that is UIL layer and DAL that is Data access
layer and BSO that is Business Object layer.

5. Architecture

Architectural design consisted of high level architecture and detail design including sequence diagrams and
class diagrams.

5.1 High Level Architecture

Project design consisted of three tier architecture. It included User Interface Layer (UIL), Business Object Layer
(BOL) and Data Access Layer (DAL). The user can view the system through UIL. This layer was built using
HTML, PHP and JavaScript. There are just a few client side processes such as “Input Control” which are
implemented entirely in UIL.
All other processes are passed on to the BOL for processing. BOL was built using PHP. It contains business
modules and classes that take the appropriate decision and fetch the required data from Google Maps through
the Google Maps API and from PATH database through DAL. The interaction with Google API is through
Page 7
PATH Version: 1.00
Technical Documentation Date: 2009-26-01

JavaScript. The database is built with MySQL.

Figure 2 shows a high level architecture of PATH. As the users decide types of Advices, a Generic Type was
used to store different advice kinds.

Figure 2: High level architecture of PATH

5.2 PATH Class Diagram

The class diagram is briefly explained in this section. The three users of the system are Administrator, Manager
and User. All users are inherited from base user. Advices are stored in Advice and Advice Fields. This made the
project very flexible because there is no limitation for any changes that user want for any advice. Advice entries
are stored in advice profile. Here we save all changes needed happens for each advice in a special location. The
related class diagram is shown in .
The last entries for each location are the valid data. Administrator defines Conflict Threshold (CT) for advices.
If PATH notices so many changes (More than CT) for an advice entry, Conflict would occur and nothing more
could be saved from users. Managers then are able to review conflicts and decide the final values.

Page 8
PATH Version: 1.00
Technical Documentation Date: 2009-26-01

Figure 3: Simplified PATH Class Diagram

5.3 User search Sequence Diagram

This sequence diagram is depicting all the interactions between the layers that serve the user request. The user
can search for a route with search criteria entered. The system will interact with the Google API to get the map
as requested. The map then needs to be embedded with the advice that corresponds to the requested route.
PATH search engine will then fetch advices from the database and add them as flags on the map fetched with
the Google API. The final map is returned to the user.

Page 9
PATH Version: 1.00
Technical Documentation Date: 2009-26-01

Figure 4: Search route sequence diagram

6. References

 DSD official web site, BTW PATH team

 Colin Potts, Kenji Takahashi, Annie I.Anton, “Inquiry-Based Requirements Analysis”, Georgia
Institute of Technology, Nippon Telegraph and Technology Corp.
 Kousik Sankar R, Raman Venkat, “Total Requirements Control at Every Stage of Product
Development”, Philips Electronics India Limited.
 Anthony Finkelstein, Steve Easterbrook, Jeff Kramer & Bashar Nuseibeh, “Requirements Engineering
Through Viewpoints”, Department of Computing, Imperial College, 180 Queen’s Gate, London SW7
2BZ.
 Harry M. Sneed, Ancon GmbH, “Testing a Web Application”, Vienna, Austria & Budapest, Hungary
Page 17
 Google Maps API, “What is the Google Maps API”, Jan 2009;
http://code.Google.com/intl/sv/apis/maps/
 PHP, “Documentation”, Jan 2009; http://www.php.net/docs.php
 Sun, “MySQL 5.1 Reference Manual”, Jan 2009; http://dev.mysql.com/doc/refman/5.1/en/
 Apache, “HTTP Server Project”, Jan 2009; http://httpd.apache.org

Page 10