Design for AerWeb's site

• The first describes the functioning of particular servlets. For the sake of simplicity, it is assumed that all servlets will output the standard HTML template, along with the relevant (dependant on user type) Main Menu. The page describes where the servlet can be accessed from, who can access it, the input parameters it takes, the output it gives and the pseudo code to carry out its function.
• The second type show HTML forms which can be outputted by the servlets (links appear in the servlets' pseudo code where this happens). Is includes a description of any JavaScript validation which is necessary




General Policy Notes

Notes on database construction: It has been attempted to normalise the database design as much as possible. One important effect of this is the distinction between 'Routes' and 'Flights'.
- A 'Flight' is a particular instance of an aircraft travelling along a Route at a particular time and date. Tickets are booked on Flights.
- A 'Route' is the path that aircraft takes between two airports. Active routes are routes which will have flights running on them in the future (and therefore which customers are permitted to search for Flights on), whereas inactive routes remain in the database for historical and data-integrity reasons, since flights in the past may have travelled on those routes. These, however, are not searched when a customer looks for tickets.
- Complex Routes are routes which are made up of individual Routes (e.g. a complex Route from Dublin to Amsterdam may involve travelling on the Dublin to Stansted Route, followed by the Stansted to Amsterdam Route). The individual routes making up a Complex Route are stored in the 'Route Parts' table. Complex Routes are generated by the Route Plan servlet. The AerWeb site will allow users to book Flights along Complex Routes where the flight along at least one Route Part is operated by AerWeb. Other legs may be flown by Ryanair.

Notes on editing data: Managers have the opportunity to add, edit and remove many items of information in/to the database. In some cases, however, this is not allowed:
- Managers cannot add or delete operators: There are currently two operators in the system, AerWeb and Ryanair. AerWeb flight details are stored in the database, whereas Ryanair data must be taken from their website. Specific code will deal with each operator. For this reason, since large code rewrites would be needed, managers cannot add, edit or remove operators from the database.
- City data is uneditable, as the prospect of a city changing its name is far too remote. The only way a city can be added to the database is through adding an airport. Although a 'city' field also appears in the 'hotels' table, we cannot recommend a hotel in a city we don't fly to, therefore managers can't add a new city for a hotel.
- Only the name of an airport can be edited. Airports do not (generally!!) move from city to city, so managers should not be allowed effectively create new airports by editing the entries for old ones. For data-integrity purposes, airports also cannot be deleted. If an airport closes down for any reason, its inactivity will be represented by all routes to and from it being inactive. In order for managers to view information on past Flights and Routes, the airport's data must remain in the database.
- Managers also cannot edit the data for a Flight. Customers will have booked seats on the flight on the premise that it will depart from a particular airport at a particular time and arrive at another particular airport at a particular time. If incorrect details have been entered when the flight was added to the form, it should rather be cancelled (so that any customers who may have booked seats on it receive an email) and a new flight entered into the database. For the same reasons, Routes are also ineditable. A Route cannot be deleted from the database if any Flights have previously flown on it. Routes which are added by mistake can be deleted before any flights are scheduled.
- Managers have full editing rights of Customer Details. It would be possible that a customer may wish to have their information changed and telephone or email to have this done.

Note on session tracking: Every servlet will make an entry into the 'sessions' database table to record the session id, username (if available), url and timestamp.
In addition, any searches a user makes are recorded separately in the 'searches' table, to track the flights a user would normally be interested in. Notes on security: <<Back to Main Menu


- Credit card numbers are never displayed on the screen, except when being typed in by the user. Whenever a user buys a ticket, they will be given a list of any credit cards they've saved. The details available will be card type, card holder and expiry date.
- Passwords are never displayed on the screen, sent to the browser or saved in a session. The only time the password variable is even requested from the database is on login.