University Parking Reservation System (UPRS)

University Parking Reservation System (UPRS)

This application will help find the closest parking garage and indicate whether

it has any free parking spots. So you won’t have to run around finding a parking

spot, especially when you are running late for a lecture.

Salient Features:

1. You don’t have to physically check if a parking space is available or not

2. Locks a parking spot (for limited time duration) exclusively for you.

3. Indicates which parking spot is empty within a parking garage.

4. All this information will be received via SMS. (Optional)

Table of Contents
Phase – I 3
1. Description of the Business Information System 3
2. Functionalities of the System 3
3. UML Diagrams for the System 5
3.1 Context Diagram 5
3.2 Use Case Diagrams 6
3.2.1 Fully Dressed description of the Use-Cases 8
3.3 Class Diagram 11
3.4 Activity Diagram 12
3.5 Sequence Diagram 16
4. Limitations of the Existing System 19

Phase – I

1. Description of the Business Information System
The existing system aims at providing the information about the parking lots in the vicinity of the user, thereby saving time and hassles of finding a parking lot. Once into the application, a user can view all the parking lots which are near to his current location, on Google maps platform. Using the information provided to him on Google maps, he can then direct himself to the nearest suitable parking lot using the navigation feature.
As an additional feature and as a way to utilize crowd-sourcing, a user can mark a parking lot as available, when he leaves that parking lot. This information will prove helpful to other users, as they can see which lots are available. Other users can then redirect themselves to the nearest available ones.
This information system utilizes crowd-sourcing by tracking user inputs for the benefit of others. The users can avail live information provided by others to decide which parking lot they should head to, thus saving time and hassles for everyone else.

2. Functionalities of the System
2.1 The user opens the application and gets logged-in the application system via Google authorization.

2.2 The system allows the user to look at all the nearby parking lots on Google maps platform, which are marked as available by other users.

2.3 The system allows the user to mark the parking lot which he has just left, as an available parking lot. This information will benefit other users, as they will be able to view available parking lots as mentioned in point 2.

3. UML Diagrams for the System
3.1 Context Diagram
A context diagram defines the boundaries of a system and its environment, showing the entities that it interacts with. This diagram represents all external entities that may interact with the system.

Fig 3.1.1 – Context Diagram of the existing system
This system interacts with two other external systems, Google Maps API, and Google Authorization and Authentication Services. In the Fig 3.1.1 above, the business entity ‘Open-Spot’, is placed at the center of the diagram. The other two entities with which it is interacting are placed on either side of it.

3.2 Use Case Diagrams
Use case diagrams show the interactions between a system and its environment. A use case diagram portrays the different types of users of a system and the various ways that they interact with the system.
Use Cases Description –
1. Authentication and Authorization – The system should be able to authenticate and authorize the user using Google Authentication and Authorization Services. The system should automatically provide the user’s google account credentials when the system is opened.
2. View Parking Lot Info – The user checks the parking lots’ information. The system shows a google map screen with his current location, and nearby parking lots which are available. An available parking lot is the lot which has an open space, marked by other users.
3. Mark a Parking Lot as Available – Whenever a user leaves a parking lot, he can mark the parking lot on the maps, as ‘available’ (which means that a space is open in the parking lot which he has just left).This information will be used by other users, who are looking for parking lots.

Fig 3.2.1 – Use Case Diagram for the existing system
3.2.1 Fully Dressed description of the Use-Cases

UC-1 – Authentication and Authorization
Initiating Actor – Any user who has an Android Smartphone.
Actor’s Goal – To get authenticated and authorized to be able to use the app.
Preconditions – User must have the app downloaded and installed on his smartphone.
Post conditions – The user is authenticated and authorized by Google Authentication and Authorization Services.
Flow of events for Main Success Scenario –
1. The user goes one the internet and downloads the app.
2. The user opens the app and the app automatically takes credentials from the user’s google account and sends it for authorization to Google Authentication and Authorization Services.
3. If the credentials are correct the user can view the home screen of the system.
Flow of events for Alternate Scenario –
1. The user opens the app and the app automatically takes credentials from the user’s google account and sends it for authorization.
2. The user does not get authenticated or authorized, and system redirects the user to login again.

UC-2 – View Parking Lot Info
Initiating Actor – Any user who has an Android Smartphone.
Actor’s Goal – To view the nearby parking lots on Google Maps platform.
Preconditions – User has the app installed on his smartphone, and he opens the app to view nearby parking lots. He is already authenticated and authorized by the system.
Post conditions – The app shows nearby parking lots on google maps.
Flow of events for Main Success Scenario –
1. The user opens the app to view nearby parking lots.
2. The app sends current location of that user to the system. The system then finds out nearby locations of parking lots which are available, as marked by other users, and sends the information to the app, for users to view.

UC-3 – Mark a Parking Lot as Available
Initiating Actor – Any user who has an Android Smartphone.
Actor’s Goal – To mark the parking lot, which he has just left, as an available parking lot for other users.
Participating Actors – Other Users
Preconditions – User has the app installed on his smartphone, and he opens the app to view nearby parking lots. He is already authenticated and authorized by the system.
Post conditions – The app shows nearby parking lots on google maps, including the parking lot which he is leaving.
Flow of events for Main Success Scenario –
1. The user opens the app to view nearby parking lots.
2. The app sends current location of that user to the system. The system will show all the nearby parking lots, including the one which he has just left. The system will also show his current location.
3. The user can then touch the screen on the maps, for the parking lot which he has just left, to mark it as available. This means that, since he has just left a spot in parking lot, a spot is open. This information can then be used by other users.
4. The newly marked available parking lot will be shown in a different color from the rest of the lots.

3.3 Class Diagram
Class Diagram is a type of static structure diagram that describes the structure of a system by showing the system’s classes, their attributes, operations (or methods), and the relationships among objects.

Fig. 3.3.1 – Class Diagram for the existing system
We have a LoginPage class which stores all the information about the user, his account id, password and name.
We have a HomePage class which implements the Google Maps Platform, to show the maps on the screen. This class is also responsible for taking inputs from the user and shows him the parking lots on the screen.
The Google API classes (GoogleAccountAuthorization and GoogleMapAPI) are third party classes implemented by Google. Our system interacts with them to retrieve information from these classes.

3.4 Activity Diagram
Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency. They are intended to model both computational and organizational processes.

Fig. 3.4.1 – Full Activity Diagram for the existing System
The Activity Diagram above represents the business process of the whole system. This activity diagram explains the full functioning of the system with all the features and the courses of direction taken by the system.

Fig. 3.4.2 – Activity Diagram for Authentication and Authorization
The above activity diagram shows the steps taken by the system to authenticate and authorize a user on an android smartphone system. As soon as a user opens the app, the app sends the Google account credentials to the Google Authentication and Authorization services. This API verifies a user and sends the information back to the system. If the credentials are verified the user can see the home screen, else he is requested to login again with correct credentials.

Fig. 3.4.3 – Activity Diagram for Viewing Parking Lot Information
The activity diagram shown above displays the steps taken by the system after the user has been authorized and authenticated. The user is then taken to the home screen where the app takes his current location (latitude, longitude) and sends it to Google Maps API, requesting it to send the information about nearby parking lots. The information received is then shown on the home screen of the user.

Fig 3.4.4 – Activity Diagram for Marking a Lot as Available
This activity diagram shows the activities of the system when a user tries to exit a parking lot and tries to mark it as available so that other users can see it. When a user marks a lot as ‘Available’, the system sends a request to Google Maps API, which stores this information and shows it to other users.

3.5 Sequence Diagram
A Sequence diagram is an interaction diagram that shows how processes operate with one another and in what order. A sequence diagram shows object interactions arranged in time sequence. It depicts the objects and classes involved in the scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the scenario.

Fig. 3.5.1 – Sequence Diagram for Authorization and Authentication
This sequence diagram explains the sequence of events when the system tries to authenticate and authorize a user using Google Authorization and Authentication services.
Actor: User
Classes: App Screen, Google Authorization and Authentication Service
User triggers the open the application in his smartphone. The app automatically takes the users google account credentials and call the login(UID) method.
The LoginPage class will then call Authorize() method of Google API to authorize if the user is authorize and authentic.
The Google API will return the authorization and authentication flags. If the flags are OK, the user is then taken to HomePage screen. Else, he is asked to provide correct credentials.

Fig. 3.5.2 – Sequence Diagram of View Parking Lot Info
The above sequence diagram illustrates the sequence of events for viewing the parking lot information for a user who is already authorized.
After authorization, the user lands on the HomePage Screen and viewParkingLotInfo(UID) method is automatically triggered. The HomePage class automatically calls getParkingLotInfo(UID) method of GoogleMapAPI.
The GoogleMapAPI returns the locations of the parking lots nearby to the user, based on the current location of the user. The information is then shown to the user on the screen.

Fig. 3.5.3 – Sequence Diagram of Mark a Parking Lot as Available
This sequence diagram shows the sequence of events when a user is exiting a parking lot, and he is trying to mark that lot as ‘Available’.
The user touches the location of the parking lot he is exiting.
The App screen takes the input from markParkingLot(UID, location) and then automatically calls insertInfo() method of GoogleMapAPI, which marks that a parking lot has one more slot open.
This information is then shown to other users who are trying to find available parking lots.

4. Limitations of the Existing System

4.1.1. In the existing system, a user who is leaving a parking lot can mark that lot as empty using ‘Mark a Lot’, for the benefit of others. The limitation here is that marking-a-lot is not a mandatory feature. So, if certain number of users doesn’t mark a lot, the system will show false information to other users.
4.1.2. A user can mark any lot as an empty one, even if he has not checked-in into that parking lot.
4.1.3. Looking at the map and at the empty-marked parking lots on the map, does not give enough information to the users. It does not give information about how many spots are empty in a particular parking lot.
4.1.4. If a user is at a farther distance from a particular parking lot, he cannot be sure just by looking at this existing system, that the parking lot will be empty by the time he reaches there.
4.1.5. If a user wants to go to a particular lot, and he is at some distance from the lot, he cannot reserve a spot for himself in advance.

Members –
Agrawal Nalin
Bagga Payal
Iyer Prashant
Kakarla Dinesh
Tiwari Deepika
Tripathi Piyush

Leave a Reply

Your email address will not be published / Required fields are marked *