Design Fest: Campus Dining System
Relic University (go Troglodytes!) has been using a pen-and-paper system to manage its dining services transactions for the last two centuries and has decided to update to a computerized model. Your task in this exercise to create a data model for the system. (A different team is responsible for the user interfaces.) Sketch out a class diagram representing the data model for this application based upon the description below. Be sure to include methods and fields where appropriate.
Overview of the Current Model
The current dining hall model involves a number of dining hall staff working at counters positioned at the entrance to the dining hall. Customers arrive and form lines to enter the dining hall. While in line, the customer either shows an ID card affiliated with an account or pays in cash for the visit.
If the staff member is shown an ID card, the customer’s account must be located in a reference book containing account information. A note is then made in the customer record book that this customer visited the dining hall. If the customer record book indicates that this customer’s account has run out of visits, the customer is instead denied access to the dining hall and may pay cash instead. If the staff member is provided cash (either initially or due to rejection via the customer record book), the money must be deposited into a box and the cash visitor must be noted in a separate location of the customer record book. All customer record book entries indicate the account of the customer that visited (or a note that the visitor paid cash) and the date that the customer visited the dining hall.
Accounts
The account reference book maintains information about each customer’s account. There are three primary types of Relic University dining hall accounts:
- Student accounts, which are paid according to a semesterly student plan.
- University employee accounts, which are paid on an ad-hoc basis as the employee sees fit.
- Organization accounts, which are controlled by organizations such as departments and also paid on an ad-hoc basis.
The account reference book contains a record of each account, the type of account, how much money is owed on the account, and the number of remaining meals on the account. Students and organizations are permitted to use meals from their accounts even if the accounts show a non-zero balance. University employees are required to pay any outstanding balance before using their meals and will not be admitted to the dining hall with a non-zero balance. Account balances may be paid by obtaining a form from the Accounting Office, filling it out, and mailing it along with a check to the dining hall. When the dining hall receives the check, it will be applied to the appropriate account’s balance.
Student Meal Plans
Student accounts are always associated with a meal plan. The meal plan is applied to the account at the beginning of each semester: the number of meals on the account is increased and the amount owed on the account is correspondingly increased. The different meal plans are:
- The Eat Here Plan, which costs $3500 per semester and provides 300 meals per semester.
- The Skip Breakfast Plan, which costs $2500 per semester and provides 200 meals per semester.
- The Eat Elsewhere Plan, which costs $100 per semester and provides 5 meals per semester.
All students must be enrolled in a meal plan.
Employee and Organization Accounts
Employees and organizations pay in an ad-hoc fashion for their meals: whenever the account needs more meals, payment is sent to the dining hall and the account is updated accordingly. Payment may be sent in the following increments:
- For $10, one meal is added to the account.
- For $60, ten meals are added to the account.
- For $200, forty meals are added to the account.
- For $900, two hundred meals are added to the account.
Dining Hall Staff
There are two types of dining hall staff involved in meal plan management: check-in staff and administrators. Check-in staff are permitted to access the account reference book and the customer record book, record visits to the dining hall, and receive payment from cash visitors. Administrators are capable of all of those actions and are also permitted to add payments to customers’ accounts.
Student Suggestions
The dining hall maintains a suggestion box in which customers can write comments and review the quality of the food (in terms of a number between one and five stars). At the end of each day, the suggestions must be examined and the ratings tallied.
Overview of the Desired Model
Although this system has served Relic University well for hundreds of years, the benefits of modernizing are many. First, lines are very long as customers must wait for check-in staff to make notes in the customer record book. Second, payment is slow as it must be processed by hand. Third, there are a number of affiliates on or near campus (coffee shops, restaurants, snack bars, etc.) at which customers must pay cash since it is impractical to allow those sites access to the customer record book. Finally, the suggestions in the suggestions box are often ill-formed (ratings outside of the one-to-five range, for instance) and the process of tallying, both for the rating as well as for the key suggestions, is quite tedious.
In addition to designing a data model for the above system, please include the following new features.
Meal Plan Changes
In addition to meals, each account will now include a balance of dining dollars. Those dining dollars can be spent at campus affiliates instead of cash. We would like to track each such transaction’s account, date, amount, and the affiliate at which it occurred. We would also like to modify the meal plans to include a number of dining dollars and let the non-meal-plan accounts deposit cash for use as dining dollars.
Suggestion Box Changes
Rather than a physical suggestion box, we would like to receive suggestions online. Validation on the part of the software should ensure that the provided rating is valid (and the digital nature of the suggestions should ensure that we don’t receive half of a stale donut in the suggestion box again). To prevent abuse of this service, suggestions will have to be matched with the account and date of the customer making the suggestion. This way, we can restrict the number of suggestions to one per visit.