Introduction
In the previous chapter, I introduced you to my goals, the project, and the tools I will use during my Java learning adventure. In this chapter, I'll extract and try to understand the user requirements in the problem statement. In addition, I will produce a use case diagram to illustrate the interactions with the system.
The pre-release material
Let us read the document.
What have I learned?
The following is the key information I got from the scenario detailed in the document:
The organisation has 20 car parking spaces numbered 1 to 20
Parking spaces can be booked up to two weeks before the date they are needed
Visitors choose the booking date
To complete the booking, the visitors provide the licence number of the car to be parked and their name.
Parking spaces are allocated incrementally from space number 1 for that particular day.
All booking and visitor data MUST be stored.
Technical requirements
The document also outlines some technical requirements that the program MUST have.
The program must include appropriate prompts for the entry of data. Data must be validated on entry.
All outputs, including error messages, need to be set out clearly and understandably.
All variables, constants and other identifiers must have meaningful names.
Input validations
Let's go over the requirements in depth so that we can extract some validations for the data-collecting process. These validations, I believe, will aid in the definition of some of our test cases.
Validation 1
Students at the IGCSE level were required to use the date as a number between 1 and 14 inclusive. The visitor chooses a number from this range for the day they wish to make a reservation. The program would then validate whether the selected day is in this range. For me to learn the ins and outs of the Java date library, I will instead utilise the real calendar date (e.g. 30-01-2023). My initial validation will answer each of the following questions:
Is the date well formatted e.g. “dd-MM-yyyy”?
Is the date before the present day?
Is the date after 2 weeks from the present day?
Error messages:
“Invalid date format”
“Booking date: <selected date> can not be before the current date: <today>. Please choose another day.”
“Bookings can only be made within 14 days from the current date: <today>. Please choose another day.”
Validation 2
The system must verify that all of the reservations for the two weeks have been fulfilled and that no parking spaces are available from the present day up to the following 14 days. How do we perform this check? Let's do a little maths. First, we must determine how many bookings can be made during the two weeks.
Therefore, if there are 280 bookings in total, we inform the user that there are no free spaces for the next two weeks. The visitor can return on another day or if the fifteenth day from the present day is a good day for them, they will be automatically scheduled by the system on the next day.
Error messages:
- “There are no free parking spaces up to <current day + 14>. Can we schedule your booking on <current day + 15>?”
Did I say automatically scheduled? You heard right, we have a new feature. Let's call it task 4.
Validation 3
At this stage, validation 2 has passed; the total number of bookings is less than 280. We have free parking spaces on one or some of the days. The visitor has chosen a valid booking date, but there may not be any available parking spaces on that day. To validate this, the number of bookings on the selected date will be counted by the system. If the count is equal to twenty, there are no free parking spaces available, and the visitor must choose another date or better yet, the system displays all the dates to choose from where there are free parking spaces i.e. the days where the total parking space count is less than twenty.
Error messages:
- "No free parking space on this particular day: <selected date>"
Did you notice something? We have a new feature again! Let’s call it task 5.
Validation 4
The visitor's name and vehicle license number are correct only if they are not blank. I'll keep this validation as simple as possible.
Error messages:
“name and licence number can not be empty”
“address is required” (new visitor attribute)
Validation 5
I will add a dummy payment feature. The visitor uses one of the payment methods that the system supports and the payment goes through otherwise the booking will not be made.
Error messages:
“Invalid payment method”
"Payment process failed. Please try again later."
Use case diagram
Based on the extracted information I came up with this use case diagram.
Conclusion
The booking hours for each day are not considered in the problem statement. It only discusses 20 reservations on each day, not their schedule or the durations of daily parking. I'll follow these simple guidelines to make learning exciting! It would be interesting to have this scheduling feature in the future.
If you continue reading, you will discover that each task in the next three sessions adds a new function to the application. Let's stop here! Since this post was extremely wordy, we'll skip over tasks 2 and 3 for the time being and move on to the next learning objective.
Throughout this journey, I would appreciate any feedback on my work so that both I and other readers can improve. Every time I learn new facts that I would have missed while designing the system, I will update this post.