Project

2 iTiger CATbus Tracking System: Analysis and Design

April 22, 2010 MGT 866 Long, Strickland, Stubblefield, Tian, Turner, Wolfe

iTiger CATbus Tracking System: Analysis and Design

Table of Contents
SECTION 1: EXECUTIVE SUMMARY...................................................................................................3 SECTION 2: USE CASES ..........................................................................................................................4 2.1: USE CASE DIAGRAMS ....................................................................................................................................... 4 2.2: USE CASE NARRATIVES ................................................................................................................................... 6 SECTION 3: SYSTEM PROCESS REQUIREMENTS...........................................................................7 3.1: DATA MODELS AND DESCRIPTIONS .............................................................................................................. 7 3.2: LOGIC MODELS .................................................................................................................................................. 9 3.3: GAP ANALYSIS ................................................................................................................................................... 9 SECTION 4: SYSTEM DATA REQUIREMENTS .................................................................................9 4.1: ENTITIES ......................................................................................................................................................... 10 4.2: ATTRIBUTES ................................................................................................................................................... 11 4.3: RELATIONSHIPS ............................................................................................................................................. 12 4.4: DATABASE DESIGN MODEL ......................................................................................................................... 12 SECTION 5: INTERFACE DESIGN ..................................................................................................... 13 5.1: TECHNICAL STAFF ......................................................................................................................................... 13 5.2: CATBUS PASSENGERS .................................................................................................................................. 13 5.3: SCREEN DESIGNS ........................................................................................................................................... 14 SECTION 6: SYSTEM ARCHITECTURE ........................................................................................... 15 6.1: CLIENT SERVER MODELS ............................................................................................................................. 16 6.2: DISTRIBUTED FUNCTIONALITY ................................................................................................................... 16 SECTION 7: IMPLEMENTATION PLAN .......................................................................................... 17 7.1: CODING ............................................................................................................................................................ 17 7.2: TESTING .......................................................................................................................................................... 17 7.3: INSTALLATION (ROLLOUT).......................................................................................................................... 18 7.4: DOCUMENTATION .......................................................................................................................................... 20 7.5: TRAINING ........................................................................................................................................................ 20 7.6: SUPPORT ......................................................................................................................................................... 21 SECTION 8: CONCLUSIONS AND RECOMMENDATIONS ........................................................... 21

iTiger CATbus Tracking System: Analysis and Design

Section 1: Executive Summary

The iTiger CATbus Tracking System is a proposed systems development project to create and install a GPS tracking system for the Clemson Area Transit buses. The business case and project feasibility were previously determined. To ensure an effective and timely implementation of this project, the scope of the project has been limited to ensuring the front-end capabilities of the system. By this, we mean the capabilities that the system needs to effectively operate and interact with its main users, such as bus drivers and CATbus riders. For the system to be effective, it must, however, include any requirements needed by the system technicians, those who will be maintaining, updating, upgrading, or changing both the front and back end systems. Thus, the developed documentation supports this stated initiative. This report covers the proposed use scenarios of the system and the process and logic models that support those system requirements. The system logic and processes are then translated into a data structure or a database model. The system interface requirements and the proposed system architecture are then developed. Finally, a brief description of how the team plans to implement and support the project concludes the documentation.

iTiger CATbus Tracking System: Analysis and Design

Section 2: Use Cases

2.1: Use Case Diagrams

Figure 2.1: iTiger CATbus Tracking System Use Case

iTiger CATbus Tracking System: Analysis and Design

Figure 2.2: Generate CATbus Location Map Use Case

iTiger CATbus Tracking System: Analysis and Design

2.2: Use Case Narratives

Use Case Name Actors Description Flow of Events iTiger CATbus tracking system CATbus Riders CATbus users access the system via mobile device to view a map of buses and bus routes nearby to their location. Actor Action System Response Step 1: Use case is initiated when a Step 2: Retrieve user GPS location from member accesses the iTiger the users mobile device. CATbus application on their Step 3: Retrieve Real-Time GPS mobile phone. information from all CATbuses within a Step 6: Use case concludes when 10 mile radius of user. the member receives map of Step 4: Invoke extension use case CATbuses in their local area. Generate CATbus Location Map. Step 5: Send generated map information to user smartphone. Step 2: If user denies access to GPS Location, set user location as default value (center of Clemson Campus). Step 3: If user GPA Location is default value, GPS information from all CATbuses within a 15 mile radius of user. Users have smartphone mobile devices that have data plans and the iTiger CATbus application downloaded. None Majority of users will be Clemson area students, faculty, and staff. Generate CATbus Location Map Display CATbus Map Use Case Display CATbus Map accesses this use case to generate a map of CATbus locations surrounding a specified center location. Actor Action System Response Step 1: Use case is initiated when it Step 2: Retrieve rider GPS location and is called by iTiger CATbus tracking CATbus GPS locations from iTiger system use case. CATbus tracking system. Step 7: Use case concludes when Step 3: Read information tag from the iTiger CATbus tracking system CATbus GPS location to determine receives generated map associated route color. information. Step 4: Generate CATbus route map centered around rider GPS location. Step 5: Locate and place colored bus avatars on route map according to each bus location and associated route color. Step 6: iTiger system returns generated map information to iTiger CATbus tracking system use case. None Rider GPS location and CATbus GPS locations have already been determined. None CATbus route color is stored with CATbus GPS information.

Alternate Course

Preconditions Postconditions Assumptions Use Case Name Actors Description Flow of Events

Alternate Course Preconditions Postconditions Assumptions

iTiger CATbus Tracking System: Analysis and Design

Section 3: System Process Requirements

3.1: Data Models and Descriptions

Figure 3.1: Level 0 Data Flow Diagram The level- 0 DFD above demonstrates the system process at a high level. The systems will receive Bus Locations from the GPS Devices on the buses as well as both user requests to generate real-time maps and information regarding the nature of how the user is using the system (info. Regarding browser, IP Address, location, network, time of day, etc.). The system will generate maps and send them to the end-users network-linked device; moreover the system will generate maps displaying historical bus movements and data- tables regarding user information for the system administrators.

iTiger CATbus Tracking System: Analysis and Design

Figure 3.2 Level-1 Data Flow Diagram

The level-1 DFD above is slightly more granular in depicting the system process. First, the GPS device on the CATbus will send information wirelessly to a signal receiver, which will then route the signal to a device that interprets the signal. The bus location data (i.e. the interpreted GPS signal) will then be sent to both the map generator and the bus history data store. The system user will first send a request to the iTiger CATbus system to generate a map. The system will also collect the user information (location, IP Address, network, type of device, etc.). The user information will be use sent to the map template data store so that the correct map template can be sent to the map generator. Also, the rest of the user information (including location) will be sent the System User Information Store. The information in the System User Data Store can be sent to the System Administrator upon request (request not shown); furthermore, data stored in both the Map Templates data store and the Bus History data store are used to generate a historical playback of the bus map, which is then made available to the System Administrator.

iTiger CATbus Tracking System: Analysis and Design

3.2: Logic Models

There is not much logic modeling necessary in this system. One area where logic modeling is necessary, however, is in the decision of whether or not to use the system users GPS location. Ideally, the system would automatically use the user information to determine the users location, but occasionally system users do not authorize the use of their GPS data. The logic modeling (written in Structured English) is as follows: 1. For every System User request for a map generation: a. Ask whether the user will allow the use of their GPS information. i. If user allows, then use the GPS location gathered from user to select correct map template. ii. If user denies access to GPS information, then the system will present the user with a menu of map templates (Seneca, Clemson, Central, etc.). b. The system will generate the map that utilizes the map template specified by the system user.

3.3: Gap Analysis

The system, as is currently being modeled, does not include for the computing of and delivering of CATbus ETAs. Instead, we will be bringing to the system users a real-time map of the CATbus movements around the bus stop either nearest to them or of their choosing (as depicted in the logic modeling above). However, interest in the possible future phasing in of ETA computation and delivery capability has been expressed. Therefore, the system data structure should be built with the possible future implication of these capabilities in mind.

Section 4: System Data Requirements

To analyze the iTiger bus system data requirements, the first step is to clearly decide all the entities of the system. The iTiger bus system is comprised of five entities, including: users (students, faculty, and staff of Clemson University), access devices, CATbus drivers, buses, GPS locator devices, and web-based tracking portal.

iTiger CATbus Tracking System: Analysis and Design

4.1: Entities

1. User

2. Access Device

3. Web-based portal

4. GPS locator device

5. Buses

10

iTiger CATbus Tracking System: Analysis and Design

6. Driver

4.2: Attributes

1. Users (User_IP, AccessDevice_ID, User_Type) User_IP: primary key, each user has a unique IP address. AccessDevice_ID: foreign key. User_Type: defines the type of users, such as student, faculty, or staff. 2. AccessDevices (AccessDevice_ID, AccessDevice_Type, User_IP) AccessDevice_ID: primary key, each access device to the web portal has a identification number. User_IP: foreign key. AccessDevice_Type: defines the device type that the user users, for instance, desktop, laptop, or smartphone. 3. Drivers (Driver_ID, Bus_ID, GPS_ID, Driver_Name) Driver_ID: primary key, every CAT bus driver has a unique ID. Bus_ID: foreign key. Driver_Name: name of the driver. 4. Buses (Bus_ID, Driver_ID, GPS_ID, Bus_Location, Bus_Route) Bus_ID: primary key, each CAT bus has a identification number. Bus_Location: defines the location of the bus at each time point. Bus_Route: illustrates the route of the CAT bus. 5. GPSLocatorDevices (GPS_ID, Bus_ID, Bus_Location, Battery_Info) GPS_ID: primary key, each GPS device has a unique number. Bus_ID: foreign key. Battery_Info: information from GPS battery. 6. Web-based tracking portal(User_IP, AccessDevice_ID) User_IP: primary key, when a user visits the web-based tracking portal, the portal will identify the unique IP address. AccessDevice_ID: foreign key.

11

iTiger CATbus Tracking System: Analysis and Design

4.3: Relationships
1. Each use is capable of ranging from no access device to many different kinds of access devices. For instance, laptops, desktops, or smartphones may be points of access for and individual user; however, only one user can own each access device. 2. Each access device can access one web-based portal, which includes different bus route information. On the other side, each web-based portal could be accessed by zero to many access devices. 3. Every GPS device has one and only one web-based portal, and every portal includes the location information of only one GPS device. 4. Each GPS device can be installed on only one bus, and each bus can have only one GPS locator device. 5. Each driver can drive different routes and every bus can be driven by different drivers, thus, the relation between bus and driver would be many to many.

4.4: Database Design Model

Figure 4.1:Database Design Model of iTiger Bus Tracking System

12

iTiger CATbus Tracking System: Analysis and Design

Section 5: Interface Design

This section outlines how the stakeholders will interface with the CAT Tracker system and what the interface might look like. The devices on each bus will be hardwired to turn on when the bus engine is on so the bus drivers do not need the ability to interface with the system. The two primary users will be the technical staff and the CATbus passengers with compatible mobile devices.

5.1: Technical Staff

The technical staff are the people tasked with the operation and maintenance of the system. They will be doing this through the use of MySQL (MySQL is used for database management). Other applications are used such as JavaScript (in this case, client-side JavaScript is the programming language used to code the user interface, it will be implemented as part of the mobile web browsers), HTML (used for creating structured documents for text such as headings, lists, links, etc.), and CSS (Cascading Style Sheets, used to describe presentation semantics of a document written in HTML). The code will then be interpreted by the iTiger web server (using the middleware JSON) that generates the site. The technical backend staff will need to interface with the code and system itself to fix bugs, upgrade and update the software, replace hardware, and add or change bus, routes, and bus stops.

5.2: CATbus Passengers

When a passenger accesses the system their screen will automatically center on the bus stop nearest their location if their mobile device has geolocation aware technology on it, if not or if the passenger desires to look up a stop different from the one they are currently closest to then a drop down menu will appear with a list of all routes in the system and then once a route is selected all the bus stops in the system for that route. The screen itself will be a map of the Clemson area with the routes in their appropriate colors overlaid on the roads and the bus stops clearly shown with the one currently selected denoted with a red marker. Buses will be denoted using a bus symbol or a black dot and the closest bus to the current stop will always be shown, if currently off screen then the bus icon will be at the edge of the screen from which it will enter. Students will have the option to zoom in or out and scroll in any direction. Other possible information that could be made available on the interface screen would be time until the next bus arrives and whether or not the bus is full.

13

iTiger CATbus Tracking System: Analysis and Design

5.3: Screen Designs

Figure 5.1: An Example of a route drop down menu for the passenger

Figure 5.2: An example of the interface screen for a passenger

14

iTiger CATbus Tracking System: Analysis and Design

Section 6: System Architecture

Figure 6.1: Overview of CAT Bus GPS Tracking System Architecture

Figure 6.1 depicts the architecture of the system at a high level. The GPS devices on the buses send bus telemetry data through the internet to a listening daemon in AT format. The listening daemon is a program that runs in background rather than under the direct control of a user. The daemon is interfaced with the DBMS through MySQL to update the bus telemetry data in the database. An Apache Web Server requests and retrieves bus telemetry

15

iTiger CATbus Tracking System: Analysis and Design

data. The web server sends user interface data through the internet that is retrieved by a browser (Client). This is done through XLMHttpRequest that is used inside a web browser scripting language (JavaScript) to send an HTTP request to the Apache web server. The web server also uses JSON as a middleware platform. This enables communication between different clients and servers by providing a common set of interfaces.

6.1: Client Server Models

Figure 6.2: Four-Tiered Architecture Model

6.2: Distributed Functionality

The three servers shown in Figure 6.2 are actually contained in a single case. The listening daemon may not be considered an application server because it is simply a program running in the background that retrieves telemetry data from the GPS devices via the internet and updates this data in the database. However, the listening daemon is a program with rules embedded in the system. The CAT bus tracking system is a 4-tiered architecture with web browsers (mobile and desktop) as the presentation layers or client, the Apache web server that hosts the web site and services that communicate through the web browsers, the database server does all data manipulation commands, a the listening daemon is constantly pushing data into the database.

This system would be considered a distributed data and application (4 tier) client/server solution. At the data level, the data is stored on the database server and the data

16

iTiger CATbus Tracking System: Analysis and Design

manipulation is executed on the database server. The application logic layer is executed on the application server (daemon). The presentation logic layer is handled by both the client (device capabilities and settings) as well as the web server and these communicate through the middleware. The user interface (presentation layer) is displayed on the client (mobile devices).

Section 7: Implementation Plan

This section describes how the iTiger CATbus location system will be implemented including: Coding, Testing, Installation (Rollout), Documentation, Training, and Support.

7.1: Coding

o Coding Hire graduate/undergraduate students to implement the coding using the data flow diagrams provided in Section 3 and any other useful material found in this document. o Coders should be familiar with JavaScript, HTML, CSS, and MySQL. Program Documentation See Documentation, Section 7.4

7.2: Testing

o Test scenarios (test plan) and test data Desk Checking coders will systematically test strings or segments of code as the code is being developed Unit (Module) coders will check individual modules using test data to ensure modules are operating properly, receiving correct inputs and producing correct outputs. Integration testing the way modules work together. As the modules and entire system are relatively small, module coupling will be tested systematically using test data samples to ensure proper function. System testing modules in the entire system to ensure they interact together. Following integration, the entire system as a whole will be tested using sample data that has been previously constructed to mimic real-world data input. Acceptance testing does system work in real world? Alpha testing

17

iTiger CATbus Tracking System: Analysis and Design

o Recovery Should the system be interrupted (power outage/surge, system recovery test, etc) the system could rediscover the system inputs and continue on in operation o Security System coding would only be accessible through an administrative portal that could be accessed by system administrators from various locations via web portals. o Stress - The system will be stressed prior to the first phase of rollout to allow for system user capacity estimates. The system would initially be tested with the first phase of the rollout to the select users. Should this proceed without difficulties the system would then be open for public download. See Phase Rollout in Section 7.3 o Performance The systems speed may be tested using various amounts of test data simulating multiple user requests. Prior to initial rollout, systems analysts and select users may test the system from multiple locations and request various data at the same time to determine performance/speed of the system under loads. These load simulations, given multiple data points, may allow for the system performance to be estimated under various conditions (i.e. # of users, data requested, etc.). Beta testing o The systems accuracy may also be checked by perhaps a chase vehicle following the buses with a GPS unit on-hand verifying accuracy. This may also be done by standing at bus stops and awaiting the buses arrival, measuring the time differential between the systems arrival time estimate and the actual arrival time. Adjustments may then be made, if necessary. o Results of program and system testing - TBD

7.3: Installation (Rollout)

o User guides will be constructed to clarify system layout, symbols and various features associated with the system user interface.

18

iTiger CATbus Tracking System: Analysis and Design

o o Brief CCIT on system configuration and provide orientation to CCIT employees for training them in system and user maintenance for future user advice. A user training plan will be put in place to allow first-time user the ability to download the applications and troubleshoot any specific download issues. These sessions will also include a user seminar training session where a facilitator will demonstrate the capabilities of the system and how to use the system with all of its features. o Installation and conversion plan Software and hardware installation schedule Phase I of Rollout - Single Location (Pilot) o o o o Select users from various user categories (students, professors, and frequent community users) 50-100 initial users Gain valuable feedback for improvement and debugging Track usage and system stability during usage to estimate system capacity and speed prior to full rollout. Allow for system data storage expansion and server space expansion should it be needed. Phase II of Rollout - Secondary rollout o Rollout to all users: allow application download from CU CCIT website and other distribution channels that have been previously determined. o o Enact training sessions and facilitate them with knowledgeable application users. Allow CCIT installation date and times, scheduled other installation assist locations (i.e. library, Martin help desk, etc) and dates.

19

iTiger CATbus Tracking System: Analysis and Design

7.4: Documentation
There are two audiences for requiring documentation: System Administrators and System Users. o System documentation - detailed design specifications External documentation structured diagrams and their supporting documentation are provided in the previous sections of this report. The documentation will be maintained/updated and stored with the system administrator. Internal documentation included in the code are comments describing particular lines purposes, variables and their descriptions, and module names and descriptions o User documentation Will include instructions on how to download the application and operations manuals. The manuals will contain a trouble shooting guide and

7.5: Training

o User training plan Classes and tutorials will be offered as discussed previously in Section 7.3, bullet three. Freshman orientation is suggested as an initial dispersion point for the system application. This will isolate system installation problems to scheduled times, should they arise and allow new users to attend the training/familiarity course for application training. o User training modules Training materials will include a user manual available on the CCIT website Tutorials, FAQs, and Tips will also be available for users on the CCIT website CU homepage announcement will be constructed and made available to the public, Help button/tab will be available in the application to provide users with a simplified description of use. Symbol legend will also be provided or something similar to a scroll-over tag where the user can scroll over a button and the description of the button will pop up.

20

iTiger CATbus Tracking System: Analysis and Design

Computer-based training aids can also be made available on the CCIT website

7.6: Support

o User support plan Help desks will be provided at both the main CCIT office in the Student Union and at the CCIT Martin Help desk, as well as, the Help Desk on the Cooper Library 5th floor, west side. Online help CCIT Website Bulletin Boards may display fliers stating training session dates, times, and locations Help menu will be available within the application

Section 8: Conclusions and Recommendations

The provided iTiger CATbus Tracking System documentation is an initial start to this system. This report is based upon the requirements of the system believed to be necessary by the iTiger project group. Currently, this represents the minimum functionality needed, but there will definitely be expansions to the system in the future. These expansions will include added functionality for the system users, as well as improvements to the back end system to provide abilities such as data analysis on typical CATbus routes. Thus, this system has been designed so as to allow for future additions and expansions.

21