Detailed Design Template.html

Fast Pass Parking

Detailed Design

COP 4331C, Fall 2014

Modification history:

Version	Date	Who	Comment
v1.0	10/19/2014	Ivan Lugo, Jason Braswell, Kyle Mera, Pedro Poveda	Design issues, Detailed design information,Trace of Requirements to Design
v1.1	10/23/2014	Alex Gordon, Kyle Mera	UML Diagrams/ Model Spreadsheet / Prototype Images / Trace of Requirements
v1.2	10/23/2014	Alex Gordon	Proof read and ready for submission

Team Name: Group 13 - Fast Pass Parking

Team Members:

Ivan Lugo: ivan.lugo@knights.ucf.edu
Jason Braswell: jason.braswell@knights.ucf.edu
Kyle Mera: kmera1@knights.ucf.edu
Pedro Poveda: pedropovedaq@knights.ucf.edu
Alex Gordon: alexgordon@knights.ucf.edu
Darin Doria: doria@knights.ucf.edu

Contents of this Document

Design Issues

Detailed Design Information

Trace of Requirements to Design

Design Issues:

Issue	Description
Reusability	The routes can be reused if we create an Android clone of the iOS app. They are general because they are simply GET and POST requests that can be performed from any web capable device. The web service api is not very reusable for other application designs because we did not create it with that goal in mind. For the iOS app, we did not create modules that could be easily reused in a different applications. Furthermore, a parking application is already specific to begin with, so reusability would be unlikely for that reason alone. Also, making the code reusable would have increased development time, and we did not want to risk not meeting deadlines. The storyboard we created for the app could be reused to create the Android clone however.
Maintainability	Since the app has two development teams, maintainability can be more difficult because a bug may be on the back-end, front-end, or both. Availability of developers from a specific team could be an issue. If there is a server crash, since the server is located on a team member’s personal laptop, only that team member could troubleshoot it. Likewise, iOS issues can only be worked on by people on the iOS team.
Testability	Testing the iOS app will be an issue because out of the 6 members in the team, 3 of them do not have iOS devices. Furthermore, the app will be tested on an iPhone 4s, 5, and 6. This means that not all hardware can be tested on. The missing hardware will have to be simulated through the various xcode simulators. The issue with this is that the simulator may not accurately reflect the behavior on the actual device.
Performance	The FPP platform is an iOS and network-connected system utilizing both mobile devices and hardline networked resources. Any interaction that the user has with the app must be smooth and non-intrusive. A user will be accessing the application for no more than 5-10 minutes at a time to find and pay for a parking lot. The device to web-service interactions must happen in the millisecond interactions that a user will be requesting to query and pay for parking lot passes. We have taken these use cases into account, and developed a strategy of data querying and downloading to allow a user to seamlessly pull lot information from our database. This will done by ‘chunking’ geolocated parking lots based on queries, and using those chunks to sort, display in a table, and render the locations of the parking lots in our system. As developers, we must also use as little resources as possible and minimize the amount of requests needed. On the back-end side, the developers have optimized the database models in order to minimize transmission time from client to server and vis-versa.
Portability	The app is being exclusively developed for iOS. By not developing on the Android platform we are risking losing a portion of our customer base. This can result in less revenue for our service.
Security	We need to maintain the security of user’s credit card information and other personal details. This requires us to get educated on how to encrypt relevant information. Since we are dealing with credit card information, using a third party service is the most secure way to store this data. This is important because we are liable for our user’s security.
Prototype Requirements	Client App- The user should be able to create an account, log in, select a parking lot, and pay for parking. Specifically, the initial system must have the minimum use case scenarios of account creation and sign in, parking lot search and selection, payment database persistence, lot timing controls, and fee management and display. Enterprise App- The client should be able to check parking passes. The enterprise application must incorporate the minimum use case scenarios of account sign in, license plate validation, and license plate fee assignment.
Technical Difficulties and Solutions	So far, the technical issues we have encountered have been relatively minimal in scope and difficulty. Most, if not all, have been related to the initial ramp time required for building these services and applications for the first time; no ‘fundamental understanding’ issues have been encountered. Although there is a high level issue that has occurred due to the way the work load has been distributed. The work load was distributed between a backend team and front end team. Therefore should one portion of the application requirements be finished before the other, those developers responsible for the early-completed deliverables would be unable to assist the complementary platform software development team. They would not be able to do this efficiently because the iOS platform is written solely in Objective C and uses a unique toolset to that of web services piped through NodeJS, MongoDB, et al. Therefore there would be a significant learning curve for either team if they were looking to assist the complementary platform software development team Web service difficulties have included having express.js issues in building web routes due to there being a lack of examples on the internet and creating the correct models for the mongoDB servers. These issues have been corrected since.
Design Trade Offs	Designing a front end specifically for iOS mobile devices means that mobile Android users cannot utilize the application for their device. The application can eventually be ported over to Android but the process will involve repeating a lot of code. Having multiple code bases causes maintainability issues because both code bases need to be updated before a release can be made.

Decision	Risks
To have two development teams: back-end development team and iOS development team. This was done in order to create a complete mobile application.	The risks behind this decision are a lack of communication between teams. It also creates risks in maintainability of the code.
We will develop exclusively for iOS for version 1. This was done in order to focus on a target market that is more likely to enter their credit card information.	By not developing on Android we are risking losing a portion of our customer base. Developers will also have to learn Objective C.
We will develop the server with node.js, express.js and mongo DB. This decision was made from an academic standpoint. The group has worked with SQL databases before and were interested in implementing a NoSQL database to expand their knowledge base.	It may take longer than desired to get familiar with the node, express, and mongo DB architectures before the developers are productive.
We will develop two apps, a user app and an enterprise app. This decision was made because parking lot owners/ attendants will have to check the validity of digital parking passes. Enterprise users will want their own application instead of one that is accessible by the public.	The development of a second app may increase development time significantly.

Detailed Design Information:

Class Diagram - User Model

The user class diagram represents the User and it’s associated models.

Class Diagram - Enterprise Model

The enterprise class diagram represents the Client and it’s associated models.

Sequence Diagram - User Application:

The user will have the ability to create an account and log in. Once the user is logged in they will have multiple options in what they can do from the main menu. The user will be able to update their profile information. This includes all information that the user entered when they first created an account. The user will also be able to search the map for parking lots. The available parking lots will aggregate to the location of where the user places the map. Lastly, the user can choose a location and pay for a virtual parking pass. Once the user does this, their balance and current parking passes will be updated.

Fast Pass Parking Sequence - Page 1.png

Sequence Diagram - Enterprise Mode:

Each enterprise user will have the ability to create an account and log in. Once the enterprise user is logged in they will be able to validate whether people are using FPP’s services or not. For people that are using the service, the parking attendant will be able to check if the user’s parking pass has time left on it or not.

Fast Pass Parking Sequence Enterprise - Page 1.png

Acitivity Diagram - User Mode:

The main function of Fast Pass Parking is to be able to find parking locations and purchases tickets (virtual parking passes) for that location. The activity diagram below explains how a user will be able to perform this function.

Activity Diagram - Enterprise Mode:

The main function of the enterprise edition of Fast Pass Parking is for parking attendants to be able to check if cars in the parking lot are users of Fast Pass Parking. If the owner of the car is a user, then the parking attendant will be able to check their virtual parking pass to see if they need to be ticketed or not. The activity diagram below explains how a parking attendant will be able to perform this function.

Activity Enterprise User FPP - New Page.png

Http Routes Spreadsheet

This spreadsheet represents the http routes that can be used to make requests to the server. It defines the requests to make to the server and the expected responses. This document was helpful during development as it allowed the team members to split up portions of the work. It is also helpful in the testing phase as it provides a reference to the available data.

Prototype Images:

Create Account / Sign In Screen:

From the create account / sign in screen the user has the option to create an account or sign into a current account.

When a user logs into their account they will type their username/email address into the top text field. This will appear as plain text. The user will then enter their password. The password text field will be masked so onlookers cannot easily look at a user’s password.

Create Account - User Information:

Once the user presses the create account button they will be sent to a screen where they can enter their user information. The user will enter their information and press next. Cancel will take the user back to the create account / log in screen.

Create Account - Vehicle Information:

Once the user presses the next button on the screen where they entered their user information, they will be sent to a screen where they can enter their vehicle information. The user will enter their information and press next. The back button will take the user back to the previous screen.

Create Account - Credit Card Information:

Once the user presses the next button on the screen where they entered their vehicle information, they will be sent to a screen where they can enter their credit card information. The user can enter their credit card information in two ways. The user can either scan their card or enter their information manually. The user will enter or scan their information and press next to complete their account set up . The back button will take the user back to the previous screen.

Lot Selection Screen - Main View

When a user signs in, they are greeted by a map that displays their current location, and nearby parking lots. A polygon and a pin are placed in the map that represent the parking lot areas. There is an accompanying list for the map that mirrors those nearby parking lots. The polygons, pins, and the table rows may all be selected to navigate in to the individual Lot Detail Screens.

Lot Selection Screen - Lot Details

Upon selection, the details for a parking lot are displayed to the user, along with a smaller map that focuses on the user’s selection. The image below reflects an early prototype of this display. This screen will show the parking lot’s rates, its address, and any other information that the lot owner would like to display that has been handled by and passed through our web service system.

Trace of Requirements to Design:

Functional Requirements

1.1 Create account - This is implemented on the UI login/registration page of both the user and the client application. There are accompanying web services on the HTTP server to facilitate requests to create new user accounts.The UI will access the User routes of the web server to accomplish this.
1.2 Log in - This is implemented on the UI login/registration page of both the user and client application. There are accompanying web services on the HTTP server for verifying username/password combinations. The UI will access the Login route to accomplish this.
1.3 Display parking lots - This is implemented on the UI of the user application. As soon as the user is logged in, a map will appear displaying the parking lots. There is a web service for retrieving nearby parking lot structures. The UI will access the ParkingLot route on the web server to accomplish this.
1.4 Select parking lot - This is implemented on the UI page that displays parking lots within the user application. The UI will access the ParkingLot route on the web server to accomplish this.
1.5 Select amount of time to park - This is implemented on the UI page of parking lot selection after a user selects a parking lot.
1.6 Purchase parking pass - This is implemented on the same UI component as time selection. Once confirmed, a web request will be sent to the server component route that accepts and stores the information. The UI will access the ParkingPass route on the web server to accomplish this.
1.7 Create parking lot - This is implemented on the UI component of the client application. The UI will access the ParkingLot route on the web server to accomplish this.

Interface Requirements

2.1 Retrieve data from hosted server - This is implemented every time there is a call to the database to retrieve information. This happens in multiple locations throughout the application, such as when a user logs in, creates an account, searches the map, changes profile information, and purchases a parking pass. Most of the functions on FPP are sending and retrieving data from the hosted server.

Physical Environment Requirements

3.1 Runs on iOS mobile devices when connected to the internet - The front end of the coding is being developed in Xcode 6 with Objective - C. Therefore the entire front end of the mobile application is implementing this requirement since the language that it is being written in will only run as an iOS application.

Users and Human Factors Requirements

4.1 Client is able to conduct parking lot checks - This is implemented in the enterprise mode of Fast Pass Parking. The parking attendant will be able to enter in a licence plate number or scan the licence plate to check if the car owner is a user of FPP. If they are, they can then determine whether they have a valid virtual parking pass or not.
4.2 User is able to purchase virtual parking pass - This is implemented in the parking lot detail screen in the user mode of FPP. This screen can be reached from the main screen that shows the map of all the parking lots that endorse FPP. After a user click on the parking lot that they want to view, a screen that shows the area of the parking lot that is endorsed by FPP and a button at the bottom of the screen that allows the user to purchase a virtual parking pass will appear.

Documentation Requirements

5.1 Documentation will be hosted on the group’s website - The implementation of this can be seen at http://www.cs.ucf.edu/courses/cop4331/fall2014/cop4331-13. Documentation for FPP is located under the project documentation tab on the website.

Data Requirements

6.1 Longitude and latitude of parking lots are precise - This is implemented visually in the main screen where the map is. This is further implemented when a user clicks into the parking lot that they want to choose. The user will be given a polygon mapping of the exact part of the parking lot that they are allowed to park in. The database is where the longitude and latitude of the parking lots are contained. The database models above show how they will be implemented in the database.

Resource Requirements

7.1 Server is hosted continuously - This is implemented on a linux server that is being run by one of the team members. This server is never turned off and routinely checked for server crashes to ensure that users will have the utmost of quality in their application.

Security Requirements

8.1 Protect the web server from being accessed without authentication - This is implemented by restricted access on the server. This protects the server from malicious activity because it adds another layer of security. For users to perform certain functions they must sign in with a username and password, which will deter malicious users. Malicious users do not want to have to work for access to enter a server, therefore they will find an easier target.
8.2 Protect the database - This is being implemented by encrypting important information in the database. User passwords are being encrypted so a user’s accounts will be safe from malicious attacks. Also, credit card information is planned to be stored with a third party, www.authenticate.net, since it is dangerous to hold credit card information on your own database.

Quality Assurance Requirements

9.1 Provide a reliable system - This has been implemented with the http routes thoroughly to make sure that there are no errors with getting and posting data from the database. Once the front end is completely connected with the back end, there will be more QA testing that will be need to be implemented. Our team makes sure to test our code at every major step along the way to make sure it works before moving on. Thus in the end, this gives the user a reliable system to work with.

Template created by G. Walton (GWalton@mail.ucf.edu) on October 8, 1999 and last modified on August 15, 2000

This page last modified by FastPassParking Team on October 23rd, 2014