Project 2: Airline-Reservation-System

• Students work in teams for this project.
  1. A team consists of three students.
  2. There are totally 54 students registered for this course (in two sections), hence 18 teams.
  3. The members of a team need not all be in the same section.

• Students form their own teams and inform me of the team membership (see below).
  1. A student may not be in more than one team.
  2. A student found to be in multiple teams will fail automatically.
  3. Therefore do not allow your name to be used without your permission.

• Please inform me of the names of your team members by Saturday 11/9/2019.
  1. If you do not inform me of your membership in a team by Saturday 11/9/2019, I will place you at random with other students who have also not entered into teams.

• Once a team is set, its membership may not be changed.
  1. You may not switch teams (e.g. halfway through the project, etc.).
  2. If any students drop out of the course, I will deal with the situation on a case-by-case basis.

2.1 GUI and data storage and coding

• This project requires a GUI (multiple screens).

• This project requires persistence across invocations.
  1. “Persistence across invocations” means that all the data must be saved and must be available if your team’s program is switched off and restarted.
  2. This can be implemented by storing the data in a database.
  3. Alternatively, your team may store the data in hash tables (text files).

• The details how “persistence across invocations” is implemented is up to your team.

• The program code (and database, if any) may be implemented using any language of your team’s choice.

2.2 Project description

• This project is to create an online reservation system for airlines (flight bookings).

• The project contains the following entities:
  1. Customers
  2. Search engine
  3. Airlines
  4. Airports

Customer

• A customer can make reservations for flights.
  1. A customer can go to a search engine (= GUI) to look up available airlines and flights and fares.
  2. Alternatively, a customer can go directly to the “web page” (= GUI) of an airline and make a reservation there.
  3. A customer can also cancel a reservation.

• A customer must have a password protected account.
  1. A customer can pull up a read-only GUI to display all his/her reservations.
  2. A customer is not allowed to see data for other customers.

Airline

• An airline must have a “web page” (= GUI) which displays all its flights and fares.
  1. An airline administrator can insert additional flights/fares and/or cancel flights.
  2. Customers can only read the flight/fares information but cannot edit it.

• Customers can make reservations (and cancel) using an airline’s “web page” (= GUI).

• Each flight has a max capacity (set by the airline administrator).
  1. If a flight is full, customers cannot make reservations for that flight.

• An airline must have a read-only GUI which displays all the reservations made by all the customers.
  1. This GUI can be read only by an airline administrator, not by customers.

• If a flight is cancelled, the accounts of all customers with bookings on that flight must be updated to indicate their reservation was cancelled.

Airport

• An airport must have a “arrivals information screen” (= GUI) which displays all the arriving flights and times by all the airlines operating at that airport.
  1. The GUI is public (no password required) and read-only.
  2. If an airline cancels a flight, a “cancelled” flight status must be displayed for that flight.
  3. Else display “on time” as the flight status.
  4. Therefore the GUI should have a timer to access information from the airline (database?) to check if the flight is cancelled, and the display should be updated to display changes.
• An airport must have a “departures information screen” (= GUI) which displays all the departing flights and times by all the airlines operating at that airport.
  1. The GUI is public (no password required) and read-only.
  2. If an airline cancels a flight, a “cancelled” flight status must be displayed for that flight.
  3. Else display “on time” as the flight status.
  4. Therefore the GUI should have a timer to access information from the airline (database?) to check if the flight is cancelled, and the display should be updated to display changes.
• There is no “airport administrator” in the sense that all the GUIs for an airport are public (no password required) and read-only.

Search engine

• Customers can go to a “search engine” (= GUI) to look up information for flights and fares.
• Customers input selection criteria your team thinks are relevant, and the search engine displays the results of the query.
• Customers can sort the display by fares or airline names.
• If a flight is full the display must say so.
• Customers can make flight reservations using the search engine.
• Your team decides if customers can cancel a booking using the search engine or if they must go to the airline GUI to cancel a booking.
• The search engine administrator can view all the reservations made by all the customers using the search engine.
  1. This GUI can be read only by the search engine administrator, not by customers and not by the airlines.
  2. The search engine administrator can only view reservations made using the search engine.
  3. The search engine administrator cannot view reservations that customers made using an airline’s GUI.