CMSC 435
SO FTWA RE E NGIN EERI NG
TE R P N A V D A T A B A S E A P I
PROJEC T DE F INITION REPORT
AU T HO RS : S TE PH EN F IO RE LL I, J OH N SI LB ER HO LZ , LE E ST EA RN S, D RE W TA YM AN
VE R SI ON : 1 . 1
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Terpnav Database API Project Definition Report - Software Engineering | CMSC 435, Study Guides, Projects, Research of Software Engineering
Material Type: Project; Class: Software Engineering; Subject: Computer Science; University: University of Maryland; Term: Unknown 1989;
Typology: Study Guides, Projects, Research
Pre 2010
1 / 11
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Terpnav Database API Project Definition Report - Software Engineering | CMSC 435 and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity!
CMSC SOFTWARE ENGINEERING
T E R P N A V D A T A B A S E A P I
PROJECT DEFINITION REPORT
A U T HO R S : S T E P H E N F I O R E L L I , J O H N S I L B E R H O L Z , L E E S T E A R N S , D RE W T A Y M A N V E R S I O N : 1. 1
CONTENTS
- PROJECT DEFINITION REPORT..................................................................................................
- READERSHIP.....................................................................................................................................
- OBJECTIVES OF THE PDR.............................................................................................................
- PROJECT CONTEXT........................................................................................................................
- PROJECT PURPOSE AND BENEFITS...........................................................................................
- PURPOSE..................................................................................................................................................
- PROJECT SCOPE AND CONSTRAINTS.......................................................................................
- SCOPE.....................................................................................................................................................
- CONSTRAINTS...........................................................................................................................................
- PROJECT OBJECTIVES...................................................................................................................
- PROJECT MODEL.............................................................................................................................
- PROJECT MILESTONE PLAN......................................................................................................
- ORGANIZATIONAL STRUCTURE..............................................................................................
- ORGANIZATIONAL BOUNDARIES AND INTERFACES.........................................................
- MONITORING AND CONTROLLING MECHANISMS.............................................................
- RISK ANALYSIS..............................................................................................................................
- OBJECT DESIGN AND MODELING............................................................................................
- CODE DEVELOPMENT..................................................................................................................
- DATABASE IMPROVEMENTS.....................................................................................................
P R O J E C T B A C K G R O U N D
P R O J E C T C O N T E X T
PROJECT CONTEXT
TerpNav is already an existing and functioning project. Previous software engineering students developed the project in an ad-hoc manner. The TerpNav software is based off of the open- source project Open Street Map and was extended by students to support additional features such as routing and events. Currently, a number of current efforts are under way to extend the functionality of the TerpNav. These projects will utilize the new API currently being developed to implement their changes. The User Interface Group in particular has expressed interest in utilizing the new API to implement planned additions to the interface of the TerpNav project.
P R O J E C T D E F I N I T I O N
P R O J E C T P U R P O S E , S C O P E A ND O B J E C T I V E S
PROJECT PURPOSE AND BENEFITS
PURPOSE
Currently large portions of the underlying TerpNav code are messy and unorganized. The goal of this project is to create an API to provide a clean, structured, and centralized interface for one of the major databases used in the project: the Features database. This will allow current and future TerpNav developers to easily access the database and provide greater project scalability.
PROJECT SCOPE AND CONSTRAINTS
SCOPE
The Features database and code in the TerpNav project provide an extension on the map data provided by the Open Street Map project (and stored in the OSM-UMD database). The Features database stores more complete information about, for instance, buildings, events, and exclusion areas. Currently all access to this Features database data is implemented through PHP with MySQL statements hard-coded into the program. The software lacks a single unifying paradigm to connect it to the database. As such there are several inconsistencies with regard to function parameters and database efficiency. Furthermore, database authentication, session maintenance, and input verification are implemented in an inconsistent manner and spread throughout the code. Our group will provide an object-oriented framework for Features database access. Additionally, we will implement database query functionality based off this new framework.
CONSTRAINTS
Any modifications to the codebase must be backwards compatible with the current TerpNav implementation. As such no change should prevent future downloads from the Open Street Map database or create incompatibilities with other TerpNav features.
PROJECT OBJECTIVES
The goal of this project is to create a reimplementation of the current functionality of the TerpNav “Features” codebase. An API will be created that provides all needed access to the Features database including insertion, modification, and deletion of data stored in the database. The API should be documented and internally consistent. Furthermore the Features database should be extended as necessary to improve performance and allow for additional features.
Then, the group will sketch out and provide initial documentation for an object-oriented approach to encapsulate the current functionality of the “Features” codebase and additional functionality required by the UI team. This will include each API function call the group will support. The object oriented design for data structures returned from the API has been selected due to its ability to clarify the code base without providing too much additional coding complexity. The concept of class inheritance in PHP will allow this sort of paradigm. The API will typically be required to return items of interest within a bounding box subject to a series of constraints; these items of interest, which can be buildings, notes, avoidance areas, or events, will all be generically considered part of the Incident class. Then each separate object type will extend the Incident class and provide information specific to the type of object. A plan for this object-oriented model for the new API is provided below. #loc : Point #id : int Incident
- range : int «implementation class» Avoidance «extends»
- desc : string
- locid : int
- isError : bool
- title : string
- range : int «implementation class» Message - start : string
- end : string
- name : string
- desc : string
- bldgId : int
- url : string
- locid : int «implementation class» Event «extends» «extends»
- fullName : string
- shortName : string
- abbr : string
- dept : string
- img : string
- isHandi : bool
- number : string
- url : string «implementation class» Building «extends» +Building = 0 +Event = 1 +Message = 2 +Avoidance = 4 +Error = 8 +Note = 16 «enumeration» IncidentType +FullName = 0 +ShortName = 1 +Abbr = 2 +Dept = 3 +Img = 4 +HandiFlag = 5 «enumeration» BMDType Prior to development, a SVN repository will need to be set up on the development machine to allow multiple groups to access the same code. In particular if our team implements our code in
the same code base as the UI team from the start, this will ease the difficulty of merging code at the end of the project. Finally, the team will be ready to write the API and its backing code. As a first step, function stubs providing basic error checking and returning as basic data as possible will be implemented. For instance, a function to return all incidents within a bounding box might check the validity of the bounds of the box and return an empty array of incidents. Getting these stubs checked into subversion early will allow the UI team to write code that compiles and uses our functions, even if those functions do not yet return the correct values. The next step will be actually implementing the API so it does return the correct values. The function stubs will be replaced one by one with actual implementations, and each implementation will be tested with some basic unit tests before being checked into subversion. In so doing the team will ensure stability within the TerpNav codebase. The last implementation step, which is not critical to the group’s success in the API project, will be to optimize the performance of the new API. This may include refactoring of the Features database or optimization of the queries on the database. At this point all queries of that database will be in the same part of the code base, so changes will be kept to the implementation backing our API. Care will be taken to not destabilize API operation, as this will be one of the last steps in the project and the Maps team as a whole will likely be moving to final acceptance testing at this point. Though unit testing as discussed above will be implemented as the group implements specific functions for the API, acceptance testing will be run to ensure the quality of the data returned from the API. PROJECT MILESTONE PLAN By 10/19/08: Finish setting up development machine with copy of TerpNav code and data (ALREADY COMPLETED) By 11/4/08: Establish and document API required by UI team (ALREADY COMPLETED) By 11/11/08: Establish and document API needed By 11/11/08: Set up SVN repository with all TerpNav code on development machine By 11/13/08: Commit via SVN the function stubs for each function provided by the API By 11/18/08: Commit via SVN all functions provided by the API. Each function will have been tested via unit test. By 11/20/08: Complete API performance optimization By 11/20/08: Complete acceptance tests of API
M A N A G E R I A L P R O C E S S
M O N I T O R I N G A N D C O N T R O L L I N G M E C H A N I S M S , R I S K A N A L Y S I S
MONITORING AND CONTROLLING MECHANISMS
The timeliness of the final product delivery will be ensured by maintaining the product milestone plan proposed in this plan. The team will internally ensure this milestone plan is followed. Externally, the team’s progress will be monitored via weekly presentations of progress done by the team in the class meeting.
RISK ANALYSIS
The primary risk associated with this project is that the changes made to the code will cause the existing program to malfunction or to stop working entirely. This risk is especially prevalent because the API centralizes all access to the Features database; any fault in the code may be exercised any number of times by different functions calling the same API function. This risk will be minimized by extensive unit and acceptance testing of the API code. Another risk stems from the use of a development machine that will likely be different from the production machine the final code will run on. First, initial efforts have already proved it’s difficult to copy the existing data from the production machine to a development machine; a risk might be that some files are lost or that some state is not properly copied. Next, the copy back to the production machine may cause a working implementation on the development machine to no longer work. We will try to minimize these risks via testing on the production machine before actually using the implementation as the current TerpNav map.
T E C H N I C A L P R O C E S S
M E T H O D S , T O O L S A N D T E C H N I Q U E S
OBJECT DESIGN AND MODELING
Microsoft VISIO will be used to model all objects and their relations. The diagrams produced in it will be used throughout development to facilitate understanding of our object oriented design between current and future developers working on the TerpNav project. The designs will be maintained throughout the project, and will be included in both internal documentation and in reports like this.
CODE DEVELOPMENT
The existing PHP code files will be modified and improved, while additional PHP files will be developed to implement new API functionality. PHP code will be developed in text editors and tested on a server running Apache 2.2.9 and PHP 5.2.6.
DATABASE IMPROVEMENTS
Database queries will be visualized in Microsoft Access, and any changes to the database structure or data will be made using MySQL scripts. Database stored procedures will be developed to simplify common queries and to improve efficiency. Tests will be run both qualitatively and quantitatively to determine methods to improve database efficiency. Any changes will be made to the backup database first, and only once development has been completed and tested extensively will a script be run to update the current database.