System requirements

Functional:

1. The parking lot system must manage how many spots are available, what types of spots are available, and which spots are currently being occupied
2. The system must allow floors and spots to be modified, added, or removed
3. The system must allow ticket booths upon entry/exit to be added or removed
4. each spot, floor, lot has a unique identifier for traceability
5. The system must issue a Parking ticket stub upon entry
6. The stub can be paid when exiting, at a stall, or online through a customer portal
7. Spots can have different types. It can be EV only, compact, regular, large, motorcycles
8. Management must be able to log on to the system to make changes to the system
9. The Parking Ticket must record entry/exit time and calculate the total cost
10. the total cost can be a hourly rate, or daily rate. If ticket is lost, it is the daily rate
11. Tickets can be prepaid, or corporate paid tickets
12. The ticket has a unique identifier
13. To ease traffic, an info booth showing drivers how many spots are free at each floor is needed

Non-Functional:

1. Scalability
2. System must be able to add/remove ticket booths at entrances/exist
3. System must be able to add/remove/modify parking spots and floors
4. System must issue a unique identifier to associate a spot,floor, lot, and the parking site itself.
5. The system may manage multiple parking lots across the country
6. Performance
7. Because of the indeterminstic nature of credit card processing and ticket issuance may occur simultaneously, requests made to the system must be multithreaded
8. System must be designed for periods of extremely high activity and periods of no activity.
9. rush hour/event venue
10. midnight - early morning
11. Security
12. The system has an online portal for customers and management. There needs to be a UserName + Password for each account and separate profile for customers and management
13. Management is able to make changes to the system. Pay rate, parking floor, spot adjustment
14. The customer can only pay for a ticket, view their account, update their personal information
15. Availability
16. System should run 24/7. If no management is logged on, may go to an automated response routine or someone at a call center to handle unforseen issues

Capacity estimation

1. The system must be malleable and scalable
2. There can be multiple different parking lots using the system across the country
3. Different stalls/booths across different lots may engage with the system to transact ticket transactions, pull up customer information, or modify internal components of the system itself(parking rate, spot/floor changes)
4. The system should employ multiple threads that handles properties of the system
5. Credit card processing. May be a thread for each parking lot
6. Ticket Issuance. The requirements will differ if the tickets are unique per lot or per the entire system
7. Per System would make traceability better, but will have issues coordinating large bursts of simultaneous transactions across multiple lots that it manages
8. Per Lot would make traceability on the onus of each manager of each lot. However, ticket transactions will be faster because each lot has its own transaction thread. LETS GO WITH THIS APPROACH
9. System must manage overhead of credit card processing id the processing is slower than usual. This part is unpredictable and there can be hundreds of transactions at a single given time
10. The biggest overhead is getting customers into the garage. Ticket issuance must have the utmost importance to speed up the flow of traffic going into the garage
11. This is because the entrance of the lot may be in a public street and it is unsafe and will drive away potential customers if there is a long line of vehicles waiting to enter the garage
12. System must be scalable to handle storage of transactions and if multiple lots will be added. It its not necessarily data heavy, but we have to consider +N loads of complexity. Where complexity is another lot to add

API design

---ParkingSpot---

ParkingSpot(){

// gets uniqueId to label new spot

// uniqueId allows us to find where the spot is

}

getParkingSpotType(&VehicleType, &uniqueID)

removeSpot()

modifySpot() // may modify its type

isOccupied()

---ParkingFloor---

ParkingFloor() {

// get uniqueId for floor

}

getFreeSpots(VehicleType)

getFreeSpots()

getParkingSpot(int uniqueId)

getDataforInfoPanel() // stringifies spots for info panel

RemoveFloor()

// has map containing all parking spots on floor

// has unique identifier for this parking floor

--Ticket--

getStatus() // paid? unpaid? Lost? corporate?

totalDue()

// has unique identifier to identify transaction

// has entry/exit time.

// Maybe customer info too

--Management--

LogOn(Username, Password)

getParkingLot() // returns reference

// Management has ability to make changes to the

// lot, floor, spot.

--TicketIssuance--

GetTicket()

// ticket issuance is handled by a separate thread that wakes up and only does getTicket requests

--Transaction--

doTransactionCard(Ticket)

doTransactionCash(Ticket)

// card transactions may be separate tasks handled by a thread pool. Each card company has its own transaction handler and some companies may be faster than others or offline and online. Each card transaction is a task handled concurrently

--ParkingLot---

getParkingFloor(id) //reference

getParkingSpot(id) // reference

addParkingBooth(&id)

removeParkingBooth(id)

modifyParkingRate(val)

addEntry(&id)

removeEntry(id)

addExit(&id)

removeExit(id)

updateInfoPanel()

Transact()

getParkingLotId()

--System--

// Has multiple ParkingLots

getParkingLot(id)

addParkingLot(&id)

removeParkingLot(id)

AddManagement()

RemoveManagement()

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

High-level design

The main uses for this sytem are customers and management

1. Users interact swith the system by..,
2. The user gets a ticket from a booth or stall
3. they can only provide a prepaid ticket to the system
4. The user can access the online portal to pay online
5. The user can pay for the ticket with cash or card at a booth or exit
6. Management interacts with the system by...
7. Modifying the lot they have access to
8. parking rate, spots, floors, entrances, exits
9. They have access to the online portal to make changes to customer accounts
10. Each ticket is stored in the system's database for traceability
11. The system compartmentalizes each lot.
12. Each lot has a unique identifier stored in the database that all lots share
13. Each lot has a unique identifier for a spot and floor. This is only unique to the lot
14. Payment is handled by a payment service component
15. The system handles issuing a ticket and processing the payment for the ticket

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Parking Lot

1. Each Parking Lot has a list of parking floors
2. Can modify any of the parking floor, or parking spot properties.
3. Has a list of lot entrances and exists that handles ticket issuance and payment processing
4. Contains a string displaying the total number of free spaces in total and each floor
5. Handles setting the total parking rate and daily rate

Parking Floor

1. Has a map of all parking spots.
2. std::map<int spotID, ParkingSpot>
3. Displays all free spots on each floor based on spot type

Parking Spot

1. Base class has unique identifier and spot type
2. Extended into the various parking spot types(EV, motorcycle, large, compact, regular)
3. Returns if its occupied or not

System

1. Each Parking Lot spawns a separate instance where individual queries are handled by that separate instance
2. Payment is handled in a thread pool where each separate payment request spread across 1 or more parking lots are consumed in a FIFO basis by n number of threads

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?