Contents:

• Overview
• Collaboration Policy
• Getting Started
• Your Task
• The Project Design
• Multithreaded Programming
• A Sample Airline Database
• Artifacts to Submit

Topic: Airline Reservation System
Related Reading: review asgn01 and asgn04
Due: Monday, 8 December 2008, 11:59pm

It is time to complete our Airline System software. What remains is to provide a front end for user interactions. To get you started, I am providing a jar file backend.jar that contains a working implementation of the entire backend system. You should rely upon my version (not the one you developed in an earlier assignment).

I am also providing you with source code that serves as a template for the front end project. In particular, I have already completed the entire front end for the initial login/registration dialog as well as the complete use-cases involving an Administrator account. Your job is to complete the design to support Customer interactions (with both text and graphical interfaces).

Collaboration Policy

For this assignment, you are allowed to work in groups of three. I presume that you will work with the same group that you did for the backend system (but please feel free to speak with me if there is reason for a change).

Please make sure you adhere to the policies on academic integrity in this regard.

We have placed a sample directory for use with eclipse on turing. You may copy it to the location of your choice using the command:

cp -R /Public/goldwasser/290/airline .

There are two drivers that provide main routines located in the testing package of the src directory.

While we have provided a working backend and working components of the front end that deal with login and administrator sessions, we have not provided any direct support for the Customer sessions. Your goal is to adapt our project to provide full support for the Customer sessions, in adherence with the use-cases that are outlined in the description of asgn01.

Based on the experience of the original assignments, I have created a new design for the system that all groups should use. The design is outlined in three forms:

• Revised UML overview

• Updated documentation for the backend package.
  Although the design is similar to that which was used for the previous version, we have made a few changes. This documentation matches the code that we are providing in backend.jar

• The initial initial frontend desing is embodied in the distributed source code. It adheres rigidly to the following restrictions:

  • The UserSession hierarchy is meant to control the overall flow of the user experience, implementing the varioususe-cases from the original design specifications.

    However, the UserSession subtypes should not provide any direct form of user interaction. All of the user interaction should be carried out through an object implementing the UI interface.

  • The UI interface has two completely independent implementations, TextUI and GraphicsUI. These classes are to manage the user interactions for the software. However, these classes should not have any dependence upon the backend system. The user sessions provide that control and the interface objects simply carry out the display of output or the gathering of input.

  • There is a subpackage frontend.util that provides some necessary enumerated types and simple record classes that are needed for communication between the UserSession level and the UI level.

A typical program using Java/Swing relies upon two separate threads. The "main thread" is the one that follows the flow of control starting with the main routine when an application is executed. A second thread known as the "event thread" is used to manage the graphical interface and for dispatching calls to the event handlers for those components. Additional threads can be created if desired.

The use of multiple threads brings up two challenges:

• Threads typically progress at independent paces. Additional care must be used if there is a need to coordinate the actions of those threads.

• Threads must be careful not to arbitrarily access or modify shared data without proper synchronization.

Both of these issues arise in the context of this assignment. The main thread of the user sessions have a somewhat linear flow of control. This is quite natural for the text-based interface, but somewhat awkward for a GUI version. At times, we need the main thread to wait for user interaction, yet those interactions are event-driven. Also, we need the two threads to share access to various pieces of data. At times we want the main thread to be able to effect a change on the graphical components, and we also need data from those components to be retrieved from within the main thread.

We use two approaches to manage these challenges. The rule for sharing Swing components is quite simple. Java recommends (but doesn't enforce) that Swing components be accessed only from the event thread. Conveniently, it provides a mechanism for one thread to schedule a job to be run at a later time by the event thread (via java.awt.EventQueue.invokeLater). As for the need to coordinate the progress of the two thrads, we rely upon the wait/notify behaviors inherent to the Java Object class. For this assignment, we can rely on a relatively simple model. We often want the main thread to be able to poll the GUI for a response, waiting indefinately until that response is available. We have encapsulated such a mechanism into a BlockingDialog class. We will discuss both of these issues during lectures.

By default, a new AirlineSystem has zero flights and zero customers, and a single Administrator account with username admin and password secret. From that starting point, you may build up a larger system by adding flights and customers.

The administrator menu also provides a mechansim for exporting the current system state to a file, or to import a previously saved system. As an example of a more populated system, we are providing an example of such a saved state named political.air. It provides a starting point with five flights and a varietly of customer reservations. That database includes three Customer accounts with the following credentials:

Please submit a single "jar" file that contains all relevant source code for your project. If using Eclipse, you can export your entire project to a Jar file through the "File/Export" menu option. Please make sure that you check the box to include source code in your jar; by default, only the compiled .class files are included.