|
|
Team Team
Members Alec Waichunas Caleb Cassady Donna St. Amour Frankie Fanelli
Date December 3rd, 2019 |
Table of Contents
3.2 Non-Functional Requirements 5
3.6 Parking Plus Architecture 12
5. Conclusion and Future Enhancements 14
The goal of this project is to develop a parking application that could be used as a management system for paid parking lots. The application needs to allow for the management of multiple parking lots and sections within the parking lots, as well as manage transactions as customers enter and exit the lot. During development, we aim to carefully design such a program using thorough and concise documentation within the agile design framework.
Parking lots can be a crowded and unruly place, especially if there is no system to manage incoming and outgoing cars. Some parking lot owners would like to even charge cars that come through their lot, and can be unnecessary to have a person manage it. A program to create an easy and fast system to assign and pay for parking could solve this problem.
We would like to produce an application capable of assigning and paying for a parking spot with ease. As some parking lots are hectic, and dealing with meters can be troublesome and can go unpaid for, a user will pull up to a payment station before entering the parking lot and reserve a spot. The payment will then be processed when they leave the parking lot. The owner of a parking lot can setup the system with ease, adding and removing parking sections to their liking. A transaction log will also be available for the parking lot owner to view who was processed by the program, and how much money they have acquired.
In this project using the Agile software development cycle is most beneficial for the team. Starting with weekly meetups we can determine the necessary objectives to get done and dividend the work up. Next the plan for the project is executed with the design and development of the project. Testing and evaluating the project can follow, and report and merge all changes that took place at the following meeting.
Functional requirements for the program are split into two categories: A.) requirements for customers and; B.) requirements for lot owners. All functional requirement IDs begin with FR, followed by A or B for the aforementioned categories, followed lastly by an indentifying number. The functional requirements are detailed here.
|
FRA1. Check-in system |
||
|
Goal: Save the time, credit card, and spot # when a vehicle has entered the lot. |
||
|
When a car enters the lot, we need to take in credit card and license plate numbers and issue a ticket. This system will save the time that they park so that when they leave the lot they get charged for the correct amount of time that they stayed in the lot. The issued ticket will identify which spot the customer should park in. |
||
|
Origin: Initial brainstorming |
||
|
Version: 1.0 |
Date: 9-26-18 |
Priority: 3 |
|
FRA2. Check-out system |
||
|
Goal: Charge the car-owner's credit card for the time in lot and mark the spot they were in as open. |
||
|
When the car leaves the lot, capture the ticket number again and see the time that they've been parked in the lot. Charge the card on file for that license plate and open the gate. |
||
|
Origin: Initial brainstorming |
||
|
Version: 1.0 |
Date: 9-26-18 |
Priority: 6 |
|
FRA3. Payment System |
||
|
Goal: Allow for payment with credit/debit cards |
||
|
When a car is entering the parking zone, they will have the ability to pay for their parking ticket using a credit or debit card. Their payment options will be for a standard (pay-per-hour) pass or for a monthly pass at a fixed rate. |
||
|
Origin: Initial brainstorming |
||
|
Version: 1.0 |
Date: 9-26-18 |
Priority: 9 |
|
FRB1. Transaction log |
||
|
Goal: Keep a log of all transactions made by customers parking in the lot. |
||
|
All transactions made for parking in the lot should be logged to a secure file. The data about a transaction should include the time the transaction was made, the payment method, the spot the customer was issued, the car's license plate number, and the duration of the park. |
||
|
Origin: Initial brainstorming |
||
|
Version: 1.0 |
Date: 9-26-18 |
Priority: 5 |
|
FRB2. Set transaction prices |
||
|
Goal: Allow lot owners to easily change the price to park/purchase a pass. |
||
|
Parking lot owners need the ability to set the price that they charge for people to park in the lot. This should at least include an option for the hourly parking rate as well as the flat charge price for the monthly parking pass. |
||
|
Origin: Initial brainstorming |
||
|
Version: 1.0 |
Date: 9-26-18 |
Priority: 8 |
|
FRB3. Saving and Loading Lot Info |
||
|
Goal: Lot information should be saved to a file. |
||
|
When the parking lot owner edits parking lot/lot section information, the new information should be saved to a file. The information should also be saved if the user exits the program unexpectedly. Whenever the program runs, it should check for the previously saved data and load it. |
||
|
Origin: Sprint 2 Feedback |
||
|
Version: 1.0 |
Date: 11-21-19 |
Priority: 3 |
Non-functional requirements are not split into categories, but follow a similar ID system using the NFR (non-functional requirement) label followed by an identifying number. The non-functional requirements are detailed here.
|
NFR1. Transaction Data Visibility |
||
|
Description: Transaction data should not be visible to customers, but rather only to those authorized to view the data (generally the lot owners.) |
||
|
Metric: How secure transaction data is. |
||
|
Origin: Initial brainstorming |
||
|
Version: 1.0 |
Date: 9-26-18 |
Priority: 4 |
|
NFR2. Credit Card Data |
||
|
Description: Credit card data should only be stored for the duration of the customer's park and should be discarded after the transaction has been successfully completed upon their leaving of the lot. |
||
|
Metric: Whether or not the data is deleted when no longer needed |
||
|
Origin: Initial brainstorming |
||
|
Version: 1.0 |
Date: 9-26-18 |
Priority: 10 |
|
NFR3. System Speed/Efficiency |
||
|
Description: System must be easy enough to process the user efficiently |
||
|
Metric: The speed of processing the user through the system |
||
|
Origin: Initial brainstorming |
||
|
Version: 1.0 |
Date: 9-26-18 |
Priority: 6 |
|
NFR4. Data Size |
||
|
Description: The system needs to be able to hold all data of a parking lot |
||
|
Metric: more storage space will have to be allocated |
||
|
Origin: Initial brainstorming |
||
|
Version: 1.0 |
Date: 9-26-18 |
Priority: 8 |
|
NFR5. Uptime |
||
|
Description: Down time status notification |
||
|
Metric: 100% system up time is required to keep it up and running year around |
||
|
Origin: Initial brainstorming |
||
|
Version: 1.0 |
Date: 9-26-18 |
Priority: 2 |
|
NFR6. Card Validity |
||
|
Description: Only valid cards should be accepted and used for payment. |
||
|
Metric: Whether or not invalid cards are allowed. |
||
|
Origin: Team Meeting |
||
|
Version: 1.0 |
Date: 11-21-19 |
Priority: 4 |
The project has a few actors that interacts with the system. The following use case diagram, shows how an actor should work alongside with the program.
The program will require a system of objects to communicate with each other, and be able to fulfill the requirements. The diagram below is what we engineered to accomplish this feat.
The use sequences visualize how the actors act on the system and how the system operates in the background. Below are the use cases for when the customers enters or leaves and when the parking lot owner operates the machine.
Customer Entering the Lot
Customer Exiting the Lot
Owner Operating the System
The parking plus architecture is a client-server model. Although it is being simulated using an XML file, this program acts as multiple clients (terminals present at lot entrances) and a server (the ticketmanager loading data on program start and processing transactions in a centralized location).
The diagram below shows these concepts in a more detailed, visual manner:
For the first sprint, we completed our initial project brainstorming and developed the first version of backend code. We decided to develop the program in Java as we wanted the resulting product to be deployable to any parking lot system, and the specific hardware used at every parking lot may differ greatly. This was also beneficial for our team, which was comprised of developers on MacOS, Windows, and Linux.
The initial brainstorming for the project included creating UML class diagrams for core components, use case diagrams, and documenting program requirements. We decided that the ideal implementation of our software should be for parking lots where there are gated entry/exit location(s), each with a terminal that allowed for checking in/out of the lot. In addition, the software would need to manage the number of available spots in each lot, calculate and complete transactions, and validate payment info (potentially with a bank or other reliable entity.)
With these details in mind, we programmed the first version of core program classes used to model parking lots and their sections. We also included a simple interface that could be used for terminal hardware such as the gate, card scanner, ticket/receipt printer, etc. During this sprint, we did not aim to produce any code for the functionality of the software; however, we did include within the main method a small amount of test code that ensured proper relationships between the classes we had created.
For the second sprint, our goal was to add the core functionality of the program on top of the backend that we had already developed. We began with a terminal-based check in/out system that read card info from the command line. This allowed us to begin testing card validation as well as the transaction system. While working towards the second sprint, we also created JUnit test classes to confirm the functionality of core system components. For information on these test cases, see section 4.4 below.
The next step was to create a user interface that allowed for the management of parking lot. We decided that this interface should also include a pseudo-terminal that mimicked the display that customers would see upon entering/exiting the lot. This user interface was created by using a 3-tab panel containing tabs for editing/managing the parking lots, entering/exiting the lot, and for viewing lot transaction data. Most UI functionality was completed before the second sprint, though data was not persistent (any edits/transactions would be lost upon exiting the program.)
For the third and final sprint, we focused on adding remaining functionality and improving on feedback we received when presenting our progress for sprint 2. This included data persistence (the ability to save and load edits to the parking lots; the ability to save/export transaction data.) We also removed the remaining command-line interaction by moving the card information entry and ticket ID entry to a pop-up window that appears whenever the "Enter Lot" and "Exit Lot" buttons are pressed on the pseudo customer terminal.
We used this sprint as an opportunity to refine our design documents and add two new requirements (FRB3 and NFR6.) We also added model of the architecture our program uses.
The core functionality of this program required that multiple core functionalities worked correctly. These functionalities include: credit card validation and processing, customers being able to enter and exit a lot, admins being able to create and edit parking lots and sections, tickets printing out with correct information, and transactions processing correctly for administrator bookkeeping. Using JUnit test cases we wrote individual tests for all of these functionalities so that the core functionalities were verified. These tests are all included in the GitHub repository (linked to at the bottom of the file).
Through this project we were able to learn a lot about the requirements that will be required in most tech jobs in the future. This project saw the whole development lifecycle (besides real world deployment, but that’s not quite feasible) and through this we were able to experience what we’ll probably be doing upon employment.
Future enhancements that could be made include:
- Updating the information storage to use a central database rather than local XML files
- Updating the UI to fit modern design principles
- Enhancing the security so that customers can’t access the admin terminal
Java 8 documentation:
https://docs.oracle.com/javase/8/docs/
Javax swing API documentation:
https://docs.oracle.com/javase/7/docs/api/javax/swing/package-summary.html
Mentor’s personal website:
https://www2.cs.siu.edu/~kahmed/
Github repository:
https://github.com/psychotix/parking