«Tema: Developing applications from users to data, algorithms and tests and back again Project period: Synopsis: P3, Fall Term 2011 Projectgroup: This ...»
Airline Reservation System
By: Group SW306E11
Student Report Department of Computer Science
Selma Lagerlöfs Vej 300
Telephone: +45 9940 9940
Telefax: +45 9940 9798
Airline Reservation System
Developing applications from users to
data, algorithms and tests and back
P3, Fall Term 2011
This report describes the development of an SW306E11 Airline Reservation System. The intention of the system is to give costumers the ability to
search for ights between two airports. FurPartisipents:
thermore, the system also gives the user the Jakob Lynge Albertsen ability to book ights. The report also inJohan Sørensen cludes a system denition along with an analJonathen Bernstor Nielsen ysis of both the problem- and applicationTom Reinholdt Petersen domain. The implemented system fullls the Tommy Knudsen requirements described in the system requireSupervisor: ments.
Darius idlauskas Circulation: 7 Pagecount: 104 Appendix count and type: 6, Bibliography, Best-Path Algorithms, Protocol Specication, Process Analysis, Red Chair and a Danish Abstract.
Finished on 19th Dec 2011 The report content is freely available, but publication (with source), only after agreement with the authors.
4 of 104
Jakob Lynge Albertsen Johan Sørensen Jonathan Bernstor Nielsen Tom Reinholdt Petersen Tommy Knudsen 5 of 104 6 of 104 Contents Titlepage 3 Signatures
10 of 104 Part I Introduction 11 of 104 Introduction Many people are travelling with airplanes, either as means of daily transportation to and from work or when going on vacation, to mention a few. To make reservations for such travels, airline companies' websites holds the functionality for the user to book a travel himself. A functionality which these websites lacks out on, is the option for the user to set up specic requirements for a travel, such as; minimal travel time or travel distance. The purpose of this project is to develop an easy-to-use airline reservation system, which accommodates these functionalities. In addition, the system should also be of use for travel agencies. These should have the same functionalities in the system as the private users, but with the dierence of also having a minimum spanning tree at their disposal, thus enabling them a greater understanding of the ight network.
Based on methods in the book Object Oriented Analysis and Design  the report will present an analysis of the problem and application domain. These will be used as a basis for the solution of the problem. Another aspect of the system will be to have an easy-to-use interface, built on methods found in the book Designing Interactive Systems , which makes it possible for less experienced computer users to use it as well.
After a walkthrough of the system, there will be a conclusion to summarize the report in general. Following this the further development section presents ideas and functionalities which could or should be implemented in the system.
Included with the report is a cd containing the developed system, the source code of the developed system and the report.
15 of 104 Analysis To form an overview of what the system should interact with, a rich picture has been made and described, leading to system requirements and a system denition. The problem and application domain is then analysed to get a coherent model of the problem domain and a complete list of the system requirements and a complete list of functions.
2.1 Rich picture The rich pictures in gure 2.1 and gure 2.2 are used to determine the system requirements for the system.
Figure 2.1: Rich picture representing an overview of the system
Registered user The registered user has two booking options;
To use the Internet to connect to the developed system or to use a telephone to call the travel agency. In both cases, the customer has to dene an area of interest, where he would like to travel to. When a customer uses a telephone line or an Internet connection it must be properly functioning.
Travel agency A travel agent need the same set of tools as the registered user does. In this case, a minimum spanning tree would be an ideal additional tool, as a minimum spanning tree can give an agent a quick overview of how a specic airport connects to other airports.
Bank The bank is required to verify the data sent to the system from the user. The data containing account information, makes a wiring from the registered user to the service provider possible.
Airport The information to and from the airport is of great importance to the system, because if there is no exchange of information between the program and the airport, then neither the registered user nor the travel agency have any idea of the dierent ights.
The following is based on gure 2.2, a more detailed view of the system.
The developed system The system needs an easy to access interface for when individuals want to use it, therefore a requirement would be that the system needs to have an interface that can be accessed without prior knowledge. To make the user more aware of his actions a conrmation dialog has to be shown, when the user makes important choices. Furthermore, instantly updated data about ights is needed, and whether the ights are fully booked. This means that a data feed is required, allowing constant updates of data from the server.
Server The server is the nexus of the system. For it to function properly it must have a functioning internet connection and a connection to a database. Assuming the connection to the database is correctly established, requests to the database and the answers the database provide, is presumed to be correctly formatted.
Therefore, it can be interpreted correctly by the server and the database. This still does not account for system failures and therefore conicts between the server and the database may happen. The data feed is needed to get information about all ights from airports to the system, this data contains information about ight departure, arrival and destination, amongst others.
18 of 104 System requirements Figure 2.2: Rich picture representing a more detailed view of the system Database The database is where all relevant information is stored. It is also where the system sends all received data to. The database needs to be able to receive data, send it back when requested, and alter already existing data, if it is needed.
2.2 System requirements
The program must be able to meet the following requirements:
Booking Have a login system.
Be able for the registered users and travel agents to make or cancel a reservation.
If the registered user is about to pass a point of no return decision, there must be an explicit conrmation from the user.
Search The program should make a list of trips with a maximum of ve trips, which is found by the search function.
The possibility for the user, when searching for a ight, to choose the time of departure.
Find the shortest distance from one airport to another.
Find the least number of connections between two airports.
Give an error message if the user has made any kind of error.
2.3 System denition
Based on the system requirements and the rich picture described above, a system denition has been formulated:
An IT-system that is used for planning and advising on ight paths between airports in the U.S. with the main focus towards nding paths with dierent properties. The system must primarily be an advising tool, but secondly act as an airline reservation tool. The system must be based on non expensive hardware with widespread tools and support for the.Net framework. The system must be easy to use in dierent environments with users spanning from home users to travel agents.
Functionality Support for travel planning and advising.
Application domain Managing users, ights and reservations.
Conditions Developed in consultation with a supervisor.
Technology Inexpensive hardware supporting the.Net framework.
Objects Users, ights, airports and reservations.
Responsibility Tool for reliable ight booking and advising.
Table 2.1: The system denition with the FACTOR criteria
2.4 Problem domain In this section the problem domain will be analyzed, to produce a coherent model of the problem domain.
Relevant objects from the rich picture has been put into an event table. These objects interact with each other in certain circumstances, which are shown in table 2.2. An unregistered user should be able to register, login, search between ights and choose a ight. When the unregistered user has logged in or registered, he will be known as one of the other user classes. The system will be made for individuals and travel agents. They both need the ability to search, choose a ight, book ights, cancel ights and logout. The travel agent must also have to
ability to view the minimum spanning tree. The search event contains information about ights and airports. The book, cancel and view booked ight events contains information about the ight, airport and reservation. The minimum spanning tree contains information about ights and airports. The delay event become active if the ight is delayed in any way.
A class diagram has been created to show how each of the objects interact with the surrounding objects, shown in gure 2.3. In the left side of gure 2.3
there is a class Airport. This class represents information about an airport, e.g. the name of the airport and its position, among other things. Below airport, the class ight represents an airplane doing a single ight. A ight always contains information about two airports, the departure airport, and the destination airport, therefore they are connected in a 2:1 ratio. The airport can be associated with zero or more ights. Zero if the airport has no airplanes scheduled to land or take o. On the right side of gure 2.3 there is a class Person, a person can have a role (a specialization), as an unregistered user, registered user or a travel agent. Registered users and travel agents can reserve zero or more ights, whereas the unregistered user does not have any of these privileges. Each reservation can contain one or more ights, which are needed if the reservation contains connections.
2.4.1 Behaviour diagram of classes Figure 2.4 shows when an unregistered user opens the application. When the user opens the application, he can search among ights, but cannot book any 22 of 104 Problem domain of the ights found during the search. The unregistered user can at any point close the application. If the unregistered user chooses to login or register, he is considered a registered user. The unregistered user does not have any attributes, because the system does not know anything about this user type.
Figure 2.4: Unregistered user behaviour
Figure 2.5 shows when a registered user decides to use the developed system.
When the user has logged into the system, he will have dierent ways to interact with the system. The user can search for a ight, by choosing a few properties for it. The user can then select a ight that was found, and then book the ight.
Furthermore, the user can cancel a ight he has booked, if he do not want the ight anyway. The user can also choose to change his personal information that he has given to the system, or provide additional information. The user can at any point leave the system. The registered user have additional attributes in comparison to the unregistered user, this way, the system can identify the user. tlfnumber in the attributes is short for telephone number, this applies thoughout the rest of the report.
Figure 2.5: Registered user behaviour
As shown in gure 2.6 travel agents starts by opening the application. When they open the application, they need the same basic functionality as registered users, but they may additionally nd spanning trees useful. These spanning trees can show how costly it will be to travel from one location to several other locations. The travel agent-object ends when closing the application. The
The airport object shown in gure 2.7 starts by being open. Then the airport register ight arriving and ight taking o. The airport can also be closed, because of e.g. the weather, a disaster or a terrorist attack. The airport can be reopened when the threat has passed. The object ends if the airport e.g. goes bankrupt or are permanently closed. The object can end in both the open and the closed state. The airport have attributes that determines its' position and initials, amongst others.
Figure 2.7: Airport behaviour
The ight object shown in gure 2.8 starts being open for passengers. When the ight has enough passengers booked, its state changes to closed, then no more passengers can book the ight. The ight can be open again if someone cancels their ight. The ight can in both the open and closed state, take o or be cancelled in which case the object stops existing. Each ight has a lot of necessary attributes. These include what airline that owns the ight, which kind of plane is used and the departure and arrival airports and time. All of this information is needed to keep track of ights for airports and customers.
Meals determine if and what meals is served on the ight. Bookclass is the dierent classes the customer can book, e.g. rst class and economy class.
24 of 104 Problem domain
The reservation object shown in gure 2.9, is created when a reservation for a ight is made, and immediately added to the list of purchased ights.