CS 7336 - Web Application Development Spring 2026

1    Problem Description

Airports around the world handle several thousands of bags every day.  Even in most mod- ernized airports, bags are expected to be handled manually at some points and so there are chances for missed bags, misplaced bags, and delays in loading or delivery.  This project aims at developing a web-based application to resolve some of the issues, if not all, mentioned above. For simplicity, we consider only one airport and only departure activities.

2    Entities

The following entities are involved in this project:

2.1    Bag

● Bag ID (unique; 6-digit integer)

● Ticket number (10-digit integer)

● Location (one of the following)

–  Check-in counter (Terminal and counter number)

–  Gate (Terminal and gate number)

– Loaded (Airlines abbreviation - 2 letters and 4-digit flight number)

2.2    Flight

● Airlines (Airlines abbreviation - 2 letters and 4-digit flight number)

● Gate (Terminal and gate number)

● List of ticket numbers  (empty  to start with;  updated  as  and  when passengers  are added)

2.3    Passenger

● Firstname

● Lastname

● Identification (6-digit number - may represent passport number, driver license number, ...)

● Ticket number (10-digit integer)

● Flight (Airlines abbreviation - 2 letters and 4-digit flight number)

● Status (Not-checked-in, Checked-in, Boarded)

2.4    Airline staf

● Firstname

● Lastname

● Email address

● Phone number

● Airlines (Airlines abbreviation - 2 letters)

●  Username

●  Password

2.5    Gate staf

● Firstname

● Lastname

● Email address

● Phone number

● Airlines (Airlines abbreviation - 2 letters)

●  Username

●  Password

2.6    Ground staf

● Firstname

● Lastname

● Email address

● Phone number

●  Username

●  Password

2.7    Administrator

●  Username

●  Password

3    Functionalities performed by various users

3.1    Administrator

● Login

● Logout

● Add a flight

– The airlines information will serve as the unique identification of the flight.

● Remove a flight from the system

– When a plane leaves the airport, the flight information and information of all passengers in the plane will be removed from the system.

● View all flights

● Add a passenger to the system (equivalent to purchasing a ticket)

–  Make sure that the passenger has only one entry in the system.  That is, a pas- senger cannot have two diferent tickets.

–  Make sure that the flight is already added to the system.

●  Remove a passenger from the system

–  The passenger will be removed from the system when the plane he/she boarded leaves (i.e., when the flight is removed from the system).

● View all passengers

● Add a new staf member

–  Check the “Entities” section on input details for a particular type of staf member. Username and password for a new staf member should be auto-generated by the system (see the section on “General requirements”).

● Remove a staf member

● View staf members details (categorized)

3.2    Airline staf

● Login

● Logout

●  Check-in a passenger

–  Ensure that both the passenger and the flight already exist in the system.

–  Update the status of the passenger.

–  Create an entry for each bag the passenger check-in.  Notice that a passenger may not have any bags to check-in.

3.3    Gate staf

● Login

● Logout

●  Board a passenger

–  Ensure that the passenger is checked in.

–  Ensure that all bags checked in by the passenger are at the gate.

–  Update the status of the passenger.

● Inform administrator when all passengers boarded the plane, all bags are loaded and the plane is ready to leave.

–  Ensure that all bags of all passengers are loaded.

3.4    Ground staf

● Login

● Logout

● Change location of a bag from “Check-in counter” to “Gate” when the bag arrives at the gate.

● Load bags onto the plane.

–  Ensure that passenger is boarded already.

– Update the location of the bag.

4    A typical (normal) scenario

● Administrator will add flight information first and then add passengers to the flight.

● Passenger checks in with zero or more bags.  Notice that passenger does not have an account in the system and so this operation is performed by an airlines staf on behalf of the passenger.

● Ground staf changes the location of the bag after it arrives at the gate.

● Passenger boards the plane.  Again, this operation is performed by Gate staf on behalf of the passenger.

● Ground staf loads the bags.

● Gate staf verifies that all passengers board the plane and informs administrator so that the plane is ready for departure.

● Administrator removes the plane and its passengers from the system.

5    General Requirements

The following rules must be implemented throughout the project:

● Passwords should never be displayed, nor should be visible when stored in the database. This requires that passwords must be encrypted/masked at all times.

● Usernames, except administrator’s username, should have a minimum of two characters followed by two digits.

●  Passwords should have

–  a minimum of six characters

–  at least one Uppercase letter

–  at least one lowercase letter

–  at least one number

● Administrator account is expected to be hard-coded and hence available at the time of launching the product.

● While  adding  a  new  user,  username  and  password  of the  new  user  must  be  auto- generated by the system.  This information should be sent to the user via email.  Every new user must change the password after initial login.

● Every user should be able to change their password at any time.

● Every user input must be validated. For example, ticket numbers must be exactly 10

digits long. Email addresses should be in the correct format (minimally [email protected]). Phone numbers must be 10 digits long with the first digit not a zero.  Names (both

first and last names) must have a minimum of two letters.

● The outcome of every task should be demonstrated through the user interface.  For example, while adding a user account, there must be a confirmation message displayed on the user interface.  The user should not be required to open the database to check whether a new account has been created.

● Any action that removes an entry from the database must be preceded by a dialog to confirm with the user. For example, while removing a passenger, the dialog “Are you sure you want to remove the passenger with the name “XXXXXX”?” must be displayed on the user interface.  Only after getting confirmation from the user, the passenger should be removed. This process ensures protection against accidental deletions.

● Though not strictly required, it should be possible that all diferent types of users login and operate concurrently.

● Airline staf members and Gate staf members can only view information about their airlines only and hence perform operations related to their air- lines only.  However, ground staf members can perform operations related to any airlines.

●  Message boards

Since there will be more than one staf member in each category, some in- formation shared by all the members within the same category should be available in a common place.  For example, any staf from the same airlines should be able to view the passengers of all flights from the same airlines.

Any bag returned because of security violations should be viewable to any staf member of the airlines.  In order to facilitate such common communica- tion, there should be a message board for each type of user (one for airlines staf, one for gate staf and one for ground staf). Though it may be better for a separate message board for each airlines, it will make the project more complicated and so we could use one message board for each type of user.