ABSTRACT
With the advancement in technology in the filed of e-commerce, the problem with
information overload has been at its peak. Thus there should be some cognitive solution
to the problem at hand. The first and foremost solution to this problem would be a
‘recommender system’, which is information filtering technique aimed at presenting the
user with the most viable options based on certain reference characteristics. These
characteristics are learnt from either explicit or implicit feedback provided by the user.
But, past experiences show that that only a few numbers of users provide explicit
feedback. The current ‘Flight Reservation using recommendation system’ uses implicit
feedback to overcome the problem.
Flight reservation systems have been implemented for years, basically from manual to
computerized reservation system. The demand for fast and secure online Flight
reservation systems has been increasing day by day. The effective use of the latest
technology is the backbone for the design of a good system. The main objective of the
project is to provide the user with desired selection options, real-time information and
recommend the user of an itinerary that best fits his preferences, based on his previous
purchases. The preferences are stored as a case base for future personalized
recommendations.
TABLE OF CONTENTS
LIST OF FIGURES ............................................................................................................ 5
LIST OF TABLES .............................................................................................................. 6
ACKNOWLEDGEMENTS ................................................................................................ 7
1. INTRODUCTION .......................................................................................................... 8
1.1 THE FLIGHT RECOMMENDATION CLIENT ..................................................... 8
1.2 IMPLICIT FEEDBACK AND FEATURE WEIGHTING ...................................... 9
1.2.1 IMPLICIT FEEDBACK ........................................................................................ 9
1.2.2 FEATURE WEIGHTING...................................................................................... 9
1.3 FEATURES OF THE SYSTEM............................................................................... 9
1.4 INTENDED AUDIENCE ....................................................................................... 10
1.5 OVERALL STRUCTURE ..................................................................................... 10
2. RELATED WORK ....................................................................................................... 11
2.1 OTHER APPROACHES ........................................................................................ 11
2.2 COMPARISON WITH EXISTING METHODS ................................................... 11
3. FLIGHT RECOMMENDATION ALGORITHM ........................................................ 12
Pre conditions: ...................................................................................... 12
Post condition: ...................................................................................... 12
Algorithm: ............................................................................................. 12
Calculating the identities for the itinerary i. ......................................... 12
Conclusion: ........................................................................................... 14
4. IMPLEMENTATION ................................................................................................... 15
4.1 SYSTEM ARCHITECTURE ................................................................................. 15
Figure 4.1 – system architecture ............................................................................... 15
4.2 TECNOLOGIES USED ......................................................................................... 17
4.2.1 Microsoft Visual Studio.NET .......................................................................... 17
4.2.2 ASP.NET ......................................................................................................... 17
4.2.3 SQL Server 2000 .............................................................................................. 18
4.2.4 JavaScript ......................................................................................................... 18
1
4.2.5 Microsoft Visio ................................................................................................ 18
4.2.6 Visual Paradigm 6.0 for UML ......................................................................... 19
4.3 DATABASE SCHEMA ......................................................................................... 19
Figure 4.2: tblUserType ............................................................................................ 19
Figure 4.3: tblUser .................................................................................................... 19
Figure 4.4: tblAirways .............................................................................................. 20
Figure 4.5: tblAirport ................................................................................................ 20
Figure 4.6: tblFlightCodes ........................................................................................ 20
Figure 4.7: tblduration .............................................................................................. 21
Figure 4.8: tblitinerary .............................................................................................. 21
Figure 4.9: tblFlightDetails ....................................................................................... 22
Figure 4.10: tblTempPrefData .................................................................................. 22
Figure 4.11: tblPreferences ....................................................................................... 23
Figure 4.12: tblToTempResults ................................................................................ 24
Figure 4.13: tblFroTempResults ............................................................................... 24
Figure 4.14 – DATABASE SCHEMA ..................................................................... 26
spGetSearchResults............................................................................................... 27
spGetPurchases ..................................................................................................... 27
4.4 MODULES ............................................................................................................. 27
4.4.1 Search for flights .............................................................................................. 27
4.4.2 Get the results .................................................................................................. 28
4.4.3 Login/Confirm ................................................................................................. 28
4.4.4 View Purchase History..................................................................................... 29
4.5 FLOW CONTROL ................................................................................................. 29
4.5.1 User Flow Control ............................................................................................ 29
Figure 4.15 – User flow control ................................................................................ 30
4.6 DESIGN .................................................................................................................. 30
4.6.1 USE CASE DIAGRAMS ................................................................................ 30
Figure 4.16 – User side Use Case Diagram .............................................................. 31
4.6.2 ACTIVITY DIAGRAMS ................................................................................ 31
Figure 4.17 – Activity Diagram (Search for flight) .................................................. 32
2
Figure 4.18 – Activity Diagram (View Purchases) ................................................... 33
4.6.3 CLASS DIAGRAM ......................................................................................... 33
Figure 4.19 – Class Diagram..................................................................................... 33
4.6.4 SEQUENCE DIAGRAM................................................................................. 34
Figure 4.20 – User Sequence Diagram ..................................................................... 34
Figure 21 – User Sequence Diagram 2 ..................................................................... 35
Figure 4.22 – User Sequence Diagram 3 .................................................................. 36
4.7 SCREEN SHOTS ................................................................................................... 36
Figure 4.23 – Search Page......................................................................................... 37
Figure 4.24 – Results Page ........................................................................................ 38
Figure 4.25 – Login Page .......................................................................................... 39
Figure 4.26 – Confirm Page ...................................................................................... 40
5. TESTING ...................................................................................................................... 41
5.1 ANTS LOAD .......................................................................................................... 41
5.1.1 Testing using ANTS Load ............................................................................... 41
Features ................................................................................................................. 41
5.1.2 ANAYLSIS ...................................................................................................... 41
Figure 5.1 – Results .................................................................................................. 42
Figure 5.2 – Time to Connect ................................................................................... 42
Figure 5.3 – Time to get First Byte ........................................................................... 44
Figure 5.4 – Time to get Last Byte ........................................................................... 45
Figure 5.5 – Bytes Received ..................................................................................... 46
5.1.3 RESULTS ........................................................................................................ 46
5.2 Unit Testing ............................................................................................................ 46
5.2.1 Unit Testing Using Unite .NET ....................................................................... 47
Figure 5.6 – Test Results .......................................................................................... 47
Table 5.1 – Test Case Results ................................................................................... 48
5.2.2 ANALYSIS OF RESULTS ............................................................................. 49
6. FUTURE WORK .......................................................................................................... 50
6.1 EXTENSIONS ........................................................................................................ 50
7. CONCLUSION ............................................................................................................. 51
3
References And/Or Bibliography ..................................................................................... 52
4
LIST OF FIGURES
Error! No table of figures entries found.
5
LIST OF TABLES
Error! No table of figures entries found.
6
ACKNOWLEDGEMENTS
I would like to thank my major professor, Dr. Daniel Andresen, for his valuable
guidance and encouragement throughout this project.
I would also like to thank Dr. Scott Deloach and Dr. Neilsen for serving on my
committee and for their valuable suggestions.
I would like to give my word of thanks to Mrs. Doina for her generous support
and invaluable guidance with my project.
Finally, I would like to thank my family for their love and support. I’m grateful to
them for the confidence they had in me that I would prosper in my education in the US.
7
1. INTRODUCTION
The problem of information overload occurs when the user is provided with too
many options to choose from, most of which may not be what the user is looking for.
Hence an effective system would capture the user preferences from his previous purchase
history and use the same in recommending one on his next visit.
The user preferences are stored every time he makes a purchase. Explicit
feedback from the user could be one way of collecting these preferences. But, explicit
feedback often times may not be as effective, as it may result in boring the user and hence
increasing the user’s frustration level. But one way of working around this problem
would be to collect implicit feedback from the user by mining for information from the
data stored in the user profile.
The aim of this project is to use the .net framework in effectively creating an
online flight reservation system that provides the user with a friendly interface and is fast
and secure. The key aspect of the system being the ability to recommend the user, the
itineraries that best fit his selection, based on his purchase history. The system takes in
the user input and generates a list of itineraries that the user is free to select from
depending on his personal preference. The input essentially contains the source,
destination, and date of departure of journey. The inputs required are strongly imposed by
validating the required fields, which ensures the user selections are correct and prompt. A
sorted list of recommended results is then displayed dynamically by searching the
database for the entries that meet the input criterion. The system is developed using
ASP.NET with VB.NET and SQL SERVER 2000.
1.1 THE FLIGHT RECOMMENDATION CLIENT
The Flight recommendation client (FRC) is a recommender system that searches
for multiple airlines concurrently for flights on behalf of the user. It has a good web
8
interface the enables the user to search for flights. The FRC takes in the user input and
generates a set of itineraries that meet the input criterion. The result set usually consists
of a significant amount of flights. The user might get overwhelmed by the large number
of choices. Hence a recommender system is incorporated the sorts out the results set
based on the user’s purchase history. To make accurate recommendations, the FRC
should be able to learn the user preferences. So, the system stores information about the
user preferences, every time a purchases is made. It uses the stored preferences as the sort
criterion in the recommendation process. The FRC uses the feature weighting technique.
1.2 IMPLICIT FEEDBACK AND FEATURE WEIGHTING
1.2.1 IMPLICIT FEEDBACK
If the FRC is to make successful flight recommendations to a user, it must have a
grasp of that user's travel preferences. One of the problems with e-commerce in general is
that users tend to get bored or frustrated easily, therefore a successful recommender
should be able to learn preferences while minimizing the cognitive load placed on the
user. Thus implicit feedback is associated with gathering the feedback from the user,
without the user having to provide any explicit feedback. Explicitly gathered feedback is
associated with a high level of cognitive load and. Examples of this method would be
asking the user to assign weights or rank features in the order of importance, which the
user wouldn’t be really interested in doing. The FRC uses implicit feedback from users to
generate the data that capture their preferences.
1.2.2 FEATURE WEIGHTING
This method is associated with assigning weights to the features of a system.
Thus, describing the item to be recommended. The more the weight, the better the
chances of the item being recommended. In the FRC, the features are the user
preferences. In explicit feedback, the user would be assigning the weights to the features,
thus specifying his preferences. But, in implicit feedback, the weights are collected
depending on the user purchase history.
1.3 FEATURES OF THE SYSTEM
9
The system is developed using ASP.NET using VB.net and SQL Server 2000 as
back end. The FRC makes personal recommendations to users based on their purchase
history. The key features of the FRC include:
a) It makes personalized recommendation to each user
b) It collects implicit feedback from the user as opposed to explicit feedback
which is associated with a high cost of cognitive load placed on the user
c) Provides the user with the ability to sort the results based on his temporary
preferences.
1.4 INTENDED AUDIENCE
The FRC system aims at reducing the cognitive load on the user by making
recommendations based on implicit feedback. The recommendation process is not simply
specific to the flight reservation domain. It could be used in any domain that involves
making recommendations to users based on implicit feedback.
1.5 OVERALL STRUCTURE
1. The rest of the paper deals with the other approaches for developing this
project.
2. The implementation section describes the system architecture, the database
schema, the technologies used, flow control, Design of the project described using the
UML diagrams, and the screen shots.
3. The Testing section describes the testing tools used to test the performance of
the application and a detailed review of the results.
4. The Future work section discusses the advantages and shortcomings of the
current recommendation strategy. It also some further techniques that could be
investigated.
5. Finally, the Conclusion section concludes the report.
10
2. RELATED WORK
2.1 OTHER APPROACHES
A vast number of recommendation systems are being implemented using
collaborative filtering. The method of collaborative filtering could be based on implicit or
explicit feedback. But explicit feedback has its own disadvantages. In case of implicit
feedback, Collaborative filtering is the method of making automatic predictions
(filtering) about the interests of a user by collecting reference information from many
users (collaborating). The underlying assumption of collaborative filtering approach is
that those who agreed in the past tend to agree again in the future.
2.2 COMPARISON WITH EXISTING METHODS
11
3. FLIGHT RECOMMENDATION ALGORITHM
The Flight recommendation algorithm had been designed with the concept of
implicit feedback and Feature weights in mind. Calculations are made to compute the
total weight of each entry in the result set. The results are then sorted based on these
weights. The following is a detailed description of the algorithm.
Pre conditions:
The status of the user login is known. (If the user is logged in or not)
The user has entered the input
Post condition:
The results are sorted in the order of recommendation with the most
recommended result at the top and the least at the bottom.
Algorithm:
The set of flights that meet the user input criterion are fetched. Let’s call the
temporary unsorted result set Rtemp and the size of the result set ‘n’. The algorithm
needs to compute the value Rtemp (i, w) where (0 < i < = n) and w represents the weight.
Hence Rtemp (i, w) represents the weight w of an itinerary i in the result set Rtemp.
There are four attributes based on which the total weight can be calculated Price
P, Airline A, Time of the day T and stopover attribute S.
Rtemp (Pi), Rtemp (Ai), Rtemp (Ti) and Rtemp (Si) represent the value of price,
airline, time of day and stopover for the itinerary i respectively where (0 < i <= n).
Lets assume that for itinerary i, Pid, Aid, Tid, Sid represent the identities of the
values Rtemp(Pi), Rtemp(Ai), Rtemp(Ti) and Rtemp(Si) in the database.
Calculating the identities for the itinerary i.
Rtemp(Pi) is compared to the average of all the prices in the Rtemp to determine
the price identity Pid.
The average of n price in Rtemp, RtempPriceAvg is calculated using the
following expression.
12
RtempPriceAvg = ∑Rtemp(Pi) / n where n is the total number of itineraries in
Rtemp
and 0< i <= n
Aid is nothing but the value of Rtemp(Ai)
Tid is calculated based on the Rtemp(Ti)’s value range which is nothing but the
quarter of the day. For example if 0<= Rtemp(Ti) < 6, the Tid would be 1, since it is the
first quarter of the day.
Sid is the value of Rtemp(Si)
Now that we have the identities Pid Aid, Tid and Sid for the itinerary i in the
result set Rtemp,
The weight Rtemp (Pi, w), Rtemp (Ai, w), Rtemp (Ti, w), Rtemp (Si, w) of the
respective fields is attained from the database by counting the number of occurrences of
each identities Pid, Aid, Tid, Sid , for the User multiplied the current value of the
respective weight W(Pid), W(Aid), W(Tid), W(Sid) filed for the user.
The weights Rtemp (Pi, w) = count (Pid) * W (Pid)
Where count (Pid) is the number of total occurrences of the value Pid in the
database and W (Pid) is the current weight of the attribute Pid.
Similarly,
Rtemp (Ai, w) = count (Aid) * W (Aid)
Rtemp (Ti, w) = count (Tid) * W (Tid)
Rtemp (Si, w) = count (Sid) * W (Sid)
Now that we have all the values required, the total weight for the itinerary i is
computed by adding the obtained values
Rtemp (i, w) = Rtemp (Pi, w) + Rtemp (Ai, w) + Rtemp (Ti, w) + Rtemp (Si, w)
for 0 < i <= n
Thus the final result set Rfinal is obtained by sorting the result set Rtemp based
on the values of Rtemp (i, w) in the descending order.
13
Conclusion:
The above algorithm does a two phase computation of the sort parameter value
Rtemp (i, w). First, it takes the result set and calculates the identities. And then, checks
the database for the occurrences of these identities.
For simplicity purpose, the weights in the database represented by W (identity)
have been taken to be 1. The weight could be dynamically updated each time the user
makes a purchase. This would result in even better recommendations.
14
4. IMPLEMENTATION
4.1 SYSTEM ARCHITECTURE
A pictorial description of the system architecture for the Flight reservation system
is shown below. This has been designed using Microsoft Visio 2007.
Figure 4.1 – system architecture
SYSTEM ARCHITECTURE
USER
Front end ASP.NET, HTML and VB.NET
Middleware ASP.NET Framework, IIS SERVER
SQL SERVER 2000
DATABASE
15
The architecture of the entire system is shown in the figure 1. This project was
developed using ASP.NET and VB.net. The user starts at the Search page. He could do
the search for the Flights, with or without logging in. ASP.net and VB.net have been used
for the creation of the Forms and the implementation respectively, while SQL Server
2000 was used as the back end. The control flow between the pages is described in the
subsequent paragraphs.
The user starts at the Search page. He could login straight away or perform a
search, select an itinerary, confirm it and then login. Let’s look at the Flow control when
the user opts to search first. The user starts with selecting the criterion for search.
1. One-way or Roundtrip by selecting the respective radio button.
2. The Source and the destination for the journey are then selected from the
drop-down lists next to from and to respectively. Requirement validation has
been implemented to make sure that both the entries are selected and are not
the same.
3. Using the calendar control, the departure date and return date are selected. For
One-way, only the departure date is selected. Again, validation has been done
for the correct selection of dates in calendar control. The validation is done so
that, the user doesn’t select a date that is not valid, for example a date that is
before the current date. In case of Roundtrip, validation has been done so that
the return date is always later then the current date.
4. The user could select the optional preferences such as the number of adult
tickets, number of child tickets and the class of ticket, namely economy or
business.
5. Once the required fields are selected, the user clicks the Search button. The
Search results are fetched, the user is re-directed to the Results page.
6. In the Results page, the user is provided with a list of itineraries that meet the
selected criterion. The user could take a look at the detailed itinerary by
clicking on View Details, Which opens a new window with the complete
itinerary. Clicking on the Select button redirects the user to the Confirmation
page.
7. Once the user clicks the Confirm button, he is taken to the login page, where
16
he could login and confirm the itinerary. New users could register through the
Signup page.
8. After the user logs in and confirms his itinerary, he is redirected to the home
(Search) page.
4.2 TECNOLOGIES USED
4.2.1 Microsoft Visual Studio.NET
The Visual Studio.NET framework includes a unified set of objects available on
server and client platforms. It is the next generation of Microsoft's Visual Studio
platform. Visual Studio.NET provides developers with a full-service Integrated
Development Environment for building ASP.NET Web applications, XML Web
Services, desktop applications, mobile applications for the .NET framework. It supports
multiple languages- Visual C#.NET, VB.NET, Visual C++.NET and Visual J#.NET and
provides transparent development and debugging facilities across these languages in a
multi-language solution.
4.2.2 ASP.NET
ASP.NET is a set of web development technologies marketed by Microsoft.
Programmers can use this set of technologies to build web applications, Desktop
Applications and XML web services. Its main features are described in the following
paragraph.
It builds the real world applications in an easy manner. It gives a lot of flexibility
to choose the language you want to program in. It supports more than 25 .Net languages.
ASP.NET rich output caching can increase the performance to a great extent. If caching
is enabled, the page is executed once and the results of the web page are saved. This
makes the results easily available to the next user who requests this page. ASP.NET
makes it easy to call XML Web Services from the application and this allows
applications to communicate the data over the Internet regardless of the programming
language and OS.
17
4.2.3 SQL Server 2000
Microsoft SQL Server is a r75elational database management system produced by
Microsoft. It supports a superset of Structured Query Language SQL, the most common
database language. It is commonly used by businesses for small to medium sized
databases, and in the past 5 years large enterprise databases and competes with other
relational database products for this market segment.
4.2.4 JavaScript
JavaScript developed by Netscape is used to create dynamic web pages. It is
widely used. JavaScript can put dynamic text into a HTML page, react to events, read and
write HTML elements. It could be used to validate data.
JavaScript works with HTML in the following manner.
<html>
<head>
<title>JavaScript Page</title>
<script LANGUAGE=“JavaScript”>
<! -- actual JavaScript follows below
alert (“Welcome to the Test Site!”);
// ending the script -->
</script>
</head>
<body> Content of the Page </body>
</html>
I have used JavaScript confirmation alerts at all the required locations.
4.2.5 Microsoft Visio
Microsoft Visio is diagramming software for Microsoft Windows. It uses vector
graphics to create diagrams. Microsoft Office Visio 2007 makes it easy for IT and
business professionals to visualize, explore, and communicate complex information.
18
4.2.6 Visual Paradigm 6.0 for UML
Visual Paradigm for UML is a UML CASE Tool supporting latest version of
Unified Modeling Language (UML) and Business Process Modeling Notation (BPMN)
from Object Management Group (OMG). In addition to the UML modeling support, it
provides business process modeling, object-relational mapping generator for Java, .NET
and PHP.
4.3 DATABASE SCHEMA
There are 12 database tables used in the design of the FRC.
Figure 4.2: tblUserType
The tblUserType table has 2 entries to store the details about the user. The
UserTypeId is a unique id which identifies the type of the user, to determine if the user is
an admin (administrator) or a regular user.
Figure 4.3: tblUser
The tblUser stores the information about the Users that are registered. Every time
a new User is created, the information is updated into this table. The names of the
Columns are self-explanatory. The UsertypeId determines if the user is administrator or a
regular user.The UserId is a unique identifier assigned to each user to distinguish him
from other users registered.
19
Figure 4.4: tblAirways
The tblAirways stored the information about the airways in our current FRC.
Airway_cd stored the airline code and AirWayName stored the name of the provider.
Figure 4.5: tblAirport
tblAirport had 3 fields that store information about all the airports, that include the
airport code, airport name and the city of the airport. The Unique identifier Airport_Cd
the syste distinguish between the respective airports.
Figure 4.6: tblFlightCodes
The FRC has multiple flights with the same Flight number, but at the different
times of the day. Hence flights are distinguished using the unique identifier Code_Id. The
table tblFlightCodes stores the flight number, the source and destination of the flight, the
day of the week on which the flight runs between the respective airports and the
departure time.
20
Figure 4.7: tblduration
This table has been used to generate the tblFlightDetails along with the above
mentioned tables. It has the source, destination, airway and the time it takes to travel
between those two airports for the respective airways.
Figure 4.8: tblitinerary
The table tblitinerary keeps a record of all the purchases made in the FRC. It
stores the id of the user who made the purchase, the purchase date and the itinerary
selected. This table is joined with the tblFlightDetails table, while displaying the purchase
history of the user and is updated every time a purchase is made.
21
Figure 4.9: tblFlightDetails
This table is the one that holds all the pre-determined itineraries in the FRC. It
stores all the information necessary for each and every itinerary.
Figure 4.10: tblTempPrefData
22
This table is similar to the tblItinerary, except for it stores the data directly for use
in the tblPreferences. It is used for analyzing the correctness of the selections made and
the preferences stored.
Figure 4.11: tblPreferences
Table tblPreferences is the key table in the entire FRC that stores the information
used in the recommendation system. The respective weight for each preference is stored
in this table. The individual weights of the attributes are accessed and used while sorting
the result set for recommendation purposes.
23
Figure 4.12: tblToTempResults
The table tblToTempResults is dynamically filled on the fly, when a search is
performed. It stores the search results for the onward journey until the purchase session is
finished. The data is cleared once a purchase is confirmed.
Figure 4.13: tblFroTempResults
24
This table is similar to tblToTempResults, except for it holds the information for
the return journey.
25
Figure 4.14 – DATABASE SCHEMA
tblFlightDetails
tblAirways
PK
PK
tblUserType
AirWayName
FK4
FK1
tblAirport
PK
Airport_Cd
Airport_Name
Airport_City
tblFlightCodes
PK
FK1
FK2
FK3
FK2
Code_Id
Flight_No
From_Airport_Cd
To_Airport_Cd
Day_Of_Week
Airway_Cd
From_Hr
From_Min
tblDuration
Pref_Id
User_Id
To_Price
From_Price
To_Airway
From_Airway
Duration
tohasStopOver
frohasStopOver
toTimeOfDay
froTimeOfDay
PK
Duration_Id
FK1
FK2
FK3
Duration_Hr
Duration_Min
Duration
From_Airport_Cd
To_Airport_Cd
Airway_Cd
PK
Flight_No
Airway_Cd
Day_Of_Week
From_Airport_Cd
From_Hr
From_Min
From_Time
So_To_Hr
So_To_Min
So_To_Time
So_Airport_Cd
So_From_Hr
So_From_Min
So_From_Time
To_Hr
To_Min
To_Time
To_Airport_Cd
So_To_Day
So_From_Day
To_Day
hasStopOver
From_So_Fair
So_To_Fair
From_To_Fair
So_Flight_No
PK
User_Id
To_Flight_Id
Fro_Flight_Id
To_Airway_Cd
To_hasStopOver
To_Fare
Fro_Airway_Cd
Fro_hasStopOver
Fro_Fare
To_Avg_Fare
Fro_Avg_Fare
Total_Avg_Tripfare
to_Id
To_Flight_Id
To_Flight_No
To_Airway_Cd
To_hasStopOver
To_From_To_Fair
To_Depart_Airport
To_Depart_Time
To_Stopover_Arrv_Time
To_Stopover_Airport
To_Stopover_Flight_No
To_Stopover_Depart_Time
To_Arrive_Time
To_Arrive_Airport
To_Fair
Total_Sort_Param
Price_Param
Airway_Param
TimeOfDay_Param
Stopover_Param
tblFroTempResults
PK
Fro_Id
Fro_Flight_Id
Fro_Flight_No
Fro_Airway_Cd
Fro_hasStopOver
Fro_From_To_Fair
Fro_Depart_Airport
Fro_Depart_Time
Fro_Stopover_Arrv_Time
Fro_Stopover_Airport
Fro_Stopover_Flight_No
Fro_Stopover_Depart_Time
Fro_Arrive_Time
Fro_Arrive_Airport
Fro_Fair
Total_Sort_Param
Price_Param
Airway_Param
TimeOfDay_Param
Stopover_Param
26
UserTypeId
UserType
tblUser
PK
Pref_Id
tblToTempResults
PK
FK3
tblTempPrefData
tblPreferences
PK
Flight_Id
AirWay_Cd
tblItenary
PK
Itenary_Id
FK3
FK1
FK2
User_Id
To_Flight_Id
Fro_Flight_Id
Book_Date
Child_Number
Adult_Number
ClassType
UserId
UserName
Password
LastName
FirstName
UserTypeId
There are 6 stored procedures in the database. The names of the procedures are
self-explanatory.
spGetSearchResults
This Procedure does the key job of fetching the results from the tblFlightDetails.
The user input is stored in a hash table and sent as a parameter. It returns the set the
itineraries that meet the criterion.
spGetPurchases
This procedure joins the tblItinerary with the tblFlightDetails and returns the
purchase history.
The stored procedures spGetUser, spInsertItenary, spInsertTempPref,
spInsertUser does the job of fetching the user information, inserting the purchase record,
inserting the preferences made and inserting a new user respectively.
There are 3 functions fnConvertArriveTimeToChar, fnGetArriveTime,
fnGetNextDate in the database that does the job of formatting and calculating the date
and time.
4.4 MODULES
The modules involved in this application are
4.4.1 Search for flights
This is the module that involves the loading of Search page. The dropdown lists
are loaded with the airport names by accessing the tblAirport.
The user can click on the login or Signup and is redirected to the Login page or
Register page respectively. The user logs in, and the values are validated by testing
against the tblUser from the database. If the username and password combination are
correct, the user id redirected to the Search page and the logoff link is made visible.
The user goes to register page by clicking on signup from the Search page or the
Login page. The values entered are validated for correctness. Upon successful sign up,
the user is redirected to the search page. The new user is added to the tblUser table in the
database along with the information provided.
27
The user input is read from the search page. Required field validation is done to
make sure that the required input is entered. Data validation is done on the input to make
sure that the values entered meet the custom validation criterion. This includes, checking
to see, if the source and destination airports are the same. An alert is popped up to
advising the user to select different source and destination airports. This is done using
JavaScript. Similarly, Data-time validation is done in the calendar control. This assures
that the data selected is not before the current date. And for a roundtrip, it makes sure that
the return journey date is not before the onward journey date.
Once the validations are done, the search functionality is handled.
4.4.2 Get the results
This is the heart of the entire project where the results are sorted based on the
recommendations and displayed. The user clicks the Search button and the input is read.
The input is stored in a hash table and sent to the stored procedure “spGetSearchResults”
for processing. The results are fetched and stored to the tables, tblToTempResults and
tblFroTempResults for onward and return flights respectively. The contents of the tables
are processed and sorted based on the Preferences from the tblPreferences. The data is
then displayed in the Results page. The results are displayed in descending order of
recommendation level for the particular user. The flights can be further sorted based on
the user price and airline fields. The onward and return flights are selected by clicking on
the respective radio button for that itinerary.
4.4.3 Login/Confirm
The user selects the itineraries and confirms them by clicking on the Select button
in the Results page. This module checks is the user is logged in and takes the necessary
action.
1. If the user is logged in, he is directed to display itinerary / confirm page, where
the user confirms the selected itinerary.
2. If the user is not logged in, he will be directed to the login page, from where, upon
successful login, is directed to the confirm page.
3. If the user is not logged in and is a new user, he can register from the link to the
signup page on the login page. On successful signup, he is directed to confirm
28
page.
The session is maintained through the whole process and on successful
confirmation of the Itinerary; the user is taken to the search page. The preferences and the
itinerary are updated in the user profile and the temporary result set is cleared.
4.4.4 View Purchase History
The purchase history link appears when the user is logged in. This takes the user
id and fetched the purchase history by joining the tblitinerary with the tblFlightDetails.
The results are stored in a dataset and bound to the datagrid on the PurchaseHistory page.
4.5 FLOW CONTROL
4.5.1 User Flow Control
The figure 7 shows the user control flow in the FRC. The rectangle boxes
represent the source files which are .aspx pages in my project. The arrows represent the
flow between the .aspx pages. The user starts from the home page which is the
Search.aspx. At this point he can make three choices whether to go to Login, Signup or
the Results page. If the user goes to Login page or the signup page, he is directed to the
search page upon successful login or signup. After the user signs in, his session is
maintained and he can view his purchase history. The results page can be reached,
whether the user is signed in or not.
From the Flow control diagram below, the user navigates to the confirm page, any
time a selection is made in the results page and the select button is clicked. This could be
in three ways
1. directly from the results page, if the user is already logged in.
2. through the login page, if the user already has an account to login with.
3. from results to login and then through signup, if it’s a new user.
The user can only navigate to the search page (home page) from the confirm page
The User flow control diagram had been designed in Microsoft Visio 2007.
29
Figure 4.15 – User flow control
Login Page
Login.aspx
Onclick_Login
Onclick_Login
Confirm Page
DisplayIninerary.aspx
Onclick_Confirm
Home Page
Search.aspx
Onclick_search
Results Page
Results.aspx
Onclick_Select
Onclick_PurchaseHistory
Onclick_Signup
View
Purchase
History Page
Onclick_AcceptandContinue
Sign Up Page
Register.aspx
4.6 DESIGN
4.6.1 USE CASE DIAGRAMS
The use case diagrams overview the usage requirements for a system. But in
actual development use cases provide significantly more value because they describe "the
meat" of the actual requirements. The use cases describe the sequence of actions that
provide something of measurable value to an actor.
30
Figure 4.16 – User side Use Case Diagram
4.6.2 ACTIVITY DIAGRAMS
Activity diagrams are typically used for business process modeling, for modeling
the logic captured by a single use case or usage scenario, or for modeling the detailed
logic of a business rule. Activity diagram represents the business and operational step-bystep workflows of components in a system. It shows the overall flow of control. In many
ways UML activity diagrams are the object-oriented equivalent of flow charts and data
flow diagrams from structured development. A very common use of activity diagrams is
they enable you to depict both the basic course of action as well as the alternate courses.
The Figure 11 shows the activity diagram for the use case “search for the flight”.
The diagram represents a single execution with the post condition that the results are
displayed. The flow control starts at the initial node that takes the control to the search for
flight action, which leads to the decision node that has 3 possible control flows. The post
condition is met when the control flow ends at the activity final node.
31
Figure 4.17 – Activity Diagram (Search for flight)
The figure 12 shows the activity diagram for the ‘view purchases’ activity. The
only decision node in the diagram checks to see if the user is logged in. The post
condition is met once the results are displayed.
32
Figure 4.18 – Activity Diagram (View Purchases)
4.6.3 CLASS DIAGRAM
Class diagrams show the classes of the system, their interrelationships and the
operations and attributes of the classes. The purpose of a class diagram is to depict the
classes within a model. In an object oriented application, classes have attributes (member
variables), operations (member functions) and relationships with other classes. The UML
class diagram can depict all these things quite easily. The key aspect of design where the
session had to be maintained through out the process, and hence in the figure we have all
the classes importing the SessionVars class that has all the properties and attributes that
could be used by the individual classes through out the session.
Figure 4.19 – Class Diagram
33
4.6.4 SEQUENCE DIAGRAM
Sequence diagrams model the flow of logic within the system in a visual manner,
enabling us both to document and validate your logic, and are commonly used for both
analysis and design purposes. Sequence diagrams are the most popular UML artifact for
dynamic modeling, which focuses on identifying the behavior within the system.
There are 3 sequence diagrams that capture the flow of logic in the current
application. Each modeling the flow based on the possible logical choices that could be
made by the user. The Figure 10, models the flow of logic in the case where the user opts
to search for results right away without logging in. Figures 11 and 12 deal with the cases
where the user logs in before performing the search and where the user is a new user and
decides to signup before searching for the flights respectively.
Figure 4.20 – User Sequence Diagram
34
Figure 21 – User Sequence Diagram 2
35
Figure 4.22 – User Sequence Diagram 3
4.7 SCREEN SHOTS
The figure 18 shows a screenshot where the user is in search page and has entered
the onward and return flight. The pop up ‘date time control’ (calendar) can bee seen
where the current date is shown as the 20th. The user selects the data 04/24/2007 for his
onward journey. The calendar shown in this image is for the return flight. Once the data
inputs are entered, the ‘search’ button can be clicked to view the results.
36
Figure 4.23 – Search Page
Figure 19 shows the onward journey results. The user can make a selection here
by clicking on the radio button associated with the respective itinerary. The results
displayed are in the order or recommended flights from top to bottom. The user can
further sort the data, if he wishes to, by clicking the column title on the respective field.
For example, clicking on the column header ‘Fare’ would sort the results in the order of
price from lowest to highest. Clicking it again would change the sort order the other way.
After the selecting the onward and return flights, the user selects the total itinerary by
clicking the submit button.
37
Figure 4.24 – Results Page
Figure 19 shows the Login page, were the user has entered the user name as
‘temp1’ and the masked password. The login page looks the same, in both the cases,
where the user had already selected the flight or where the user opted to login before
searching for flights.
38
Figure 4.25 – Login Page
Figure 20 shows a screenshot where the user has already selected the flights for
the trip and has been directed to the Confirm page. This means that the user had already
logged in. This page could have been reached directly from the results page or from the
login page after making the selections in the results page. On clicking the confirm page,
the user is directed to the home page (search page) with a welcome message.
39
Figure 4.26 – Confirm Page
40
5. TESTING
5.1 ANTS LOAD
5.1.1 Testing using ANTS Load
ANTS Load is used to predict a web application's behavior and performance
under the stress of a multiple user load. It does this by simulating multiple clients
accessing a web application at the same time, and measuring what happens. ANTS Load
is for load testing websites and web services and works particularly well for applications
written using Microsoft technologies such as ASP.NET and ASP.
Features
It is used to build web applications using Microsoft technologies. It can quantify
performance for a reasonable (>25) number of application users. It can understand the
business impact of performance. It allows simulates multiple concurrent users of a web
application. It measures the performance of the application in terms of page download
times, server performance and errors. Finally it indicates the business impact in terms of
the abandonment prediction and frustration coefficient
ANTS Load has 3 editions:
ANTS Load Entry Level Edition lets you simulate up to 25 concurrent users,
running on a single client computer.
ANTS Load Professional Edition lets you simulate up to 100 concurrent users,
running on a single client computer.
ANTS Load Enterprise Edition lets you simulate thousands, or even tens of
thousands, of concurrent users, running on multiple client computers.
I have used the free evaluation for up to 10 users here for testing my web site.
5.1.2 ANAYLSIS
Website performance testing tools give results that are very subjective to interpret.
Ita been widely quoted that "if a web page takes longer than 10 seconds to download then
a user is likely to lose interest”. Frustration was measured as being very slightly
influenced by time but only if the download time was greater than 30 seconds. Lostness
41
equals the number of page visits required to complete a task (optimal path) divided by the
number of pages visited. 1.0 means the user was not lost at all. There is no upper limit!
You can see in the below test result that the time to connect to each page was zero except
for two pages. This shows that the web site will not be much frustrating to users.
Figure 5.1 – Results
This section shows the overall distribution of metrics for the FRC. The charts
show what proportion of timings fall into which intervals.
Figure 5.2 – Time to Connect
This section shows you the average timings for each web page for this test. This
can be used to find the fastest, and slowest, pages in the current web application.
42
The figure 25 shows that the all the web requests take time that’s less than 50
milliseconds. This emphasis on the user’s frustration level is evident that it would be low
for the current application.
43
Figure 5.3 – Time to get First Byte
The figure 26 shows the time taken for the application to get the first byte. We
can see that time taken to receive the first byte is less for the majority. Moreover, the
maximum time taken was just 250 milliseconds.
44
Figure 5.4 – Time to get Last Byte
The figure 27 shows the time taken for the application to get the last byte. We can
see that the maximum time taken to receive the last byte was 250 milliseconds.
The figure 28 represents the total number of bytes received by each web request. The
complexity of the application is obvious from the vast amount of the web requests
receiving close to 5000-10000 bytes.
45
Figure 5.5 – Bytes Received
5.1.3 RESULTS
From the above analysis, we can conclude that:
The FRC, despite being a very complex application with a lot of request to the
database, performs really well in terms as is evident from the graphs. We can be assured
that the application would minimize the user frustration level.
The time to connect to the web page is low and hence the web page will not be
abandoned by the users.
The time between the first byte and the last byte received is very nominal, We
can see from the figure 28 that despite the high amount of data received is the time to
receive the last byte is low. Thus we can conclude that the level of lost ness while
navigating through the application is very less.
5.2 Unit Testing
Unit testing is a procedure used to validate that individual units of source code are
working properly. The goal of unit testing is to isolate each part of the program and show
that the individual parts are correct. A unit test provides a strict, written contract that the
46
piece of code must satisfy. As a result, it affords several benefits. Experiences show that a
consequent Unit and Integration Test increase the software quality, save time and saves
money. In this approach, each software component, module or class is being test in the
smallest possible context. This leads to robust building blocks, which can be integrated
quite easily following a bottom up testing approach.
5.2.1 Unit Testing Using Unite .NET
Unite .NET is a Unit and Integration Test Environment for Microsoft Visual
Studio .NET, that allows a software developer to efficiently test its software components,
classes etc. as part of a Unit and Integration test. An extensive test harness library and
wizards simplify the test driver development in C# and VB.NET. A tight Microsoft
Visual Studio integration ideally supports the "code a little, test a little" working style.
The Unite .NET Test Control Center allows interactive and automatic test execution. Test
results are reported with a comprehensive HTML/XML-based test execution trace.
Figure 5.6 – Test Results
47
Table 5.1 – Test Case Results
48
5.2.2 ANALYSIS OF RESULTS
An application can be tested using numerous test cases to check for its
correctness. But practically we have to restrict our self to few test cases which can assure
that the application will run perfectly under ideal situations. The test cases used have
been executed successfully with expected results and no errors. Various code snippets
from different methods have been tested for correctness. The test cases basically
concentrate on the correct retrieval of data from the database at various instances.
49
6. FUTURE WORK
6.1 EXTENSIONS
The FRC application is limited to only a few user preferences. The number of
preference characteristic could be increased significantly. The case based reasoning
works effectively for the particular user in context. A recommendation system can be
made more effective by using a collaborative approach. An approach where the
predictions are specific to the user, but use information gleaned from many users. The
FRC generalizes the concept of multiple users by just calculating the total weight of
individual preferences instead of calculating the similarity between different users. The
current system gathers implicit feedback by observing the history of the user purchases.
The scope of implicit feedback gathered can be extended or improved by observing the
user’s action in each given sessions.
In FRC, the feature weight scheme uses static weights in the computation of the
total weight of user preferences. The feature weights can be dynamically updated from
time to time every time a purchase is made. For example, when the user makes a
purchase, the implicit feedback is obtained about the preferences and the weights are
increased for features that have been selected in the current purchase. At the same time,
the weights are decreased for the features that have not been selected. This process yields
in better recommendation as it would tend to push down the recommendation scores of
items that are not being taken up and pull up the scores of ones that are selected.
50
7. CONCLUSION
This report describes the Flight Recommendation Client (FRC), an application
that enables the user search for and finds flights. The search result comprises a large
number of itineraries. Hence the recommendation system cuts down the burden on the
user by recommending the flight that best fit his preferences by placing them at the top.
Explicit feedback leads to an increase in the user’s frustration level. The
recommendation process is highly effective as it uses implicit feedback. The feedback is
obtained by making some observations on the user’s purchase history. The FRC makes
successful recommendations by using the technique of assigning feature weights and user
specific context based recommendations. The recommendation algorithm was designed
with the Flight Recommendation client (FRC) application in mind. Yet, it can be applied
to other domains that use implicit feedback. The key to the success of the FRC is the
ability to sort the results based on user preferences and personalizing it in the
recommendation process.
51
References And/Or Bibliography
[1] “Start VB dot net.com”, “ASP.NET Features”,
http://www.startvbdotnet.com/aspsite/asp/features.aspx
[2] Red-Gate, “Load testing, stress testing”,
http://www.red-gate.com/products/ants_load/index.htm
[3] Shrijeet Nair, “Microsoft Application Test Center”, “Date: 9-17-2002”17/2002
http://www.c-sharpcorner.com/Code/2002/Sept/AppTestCenter.asp
[4]
[5]W3Schools, “ASP.NET Introduction”,
http://www.w3schools.com/aspnet/aspnet_intro.asp
[6] Microsoft Asp.Net, “ASP.NET web: Official Microsoft Asp.Net2 site”,
http://asp.net/whitepaper/whyaspnet.aspx?tabindex=0&tabid=1
[7] Microsoft, “Visual Studio Extensibility”,
http://msdn.microsoft.com/library/default.asp?url=/library/enus/act/htm/actml_c_os.asp
[8] Red-Gate, “Website download time, abandonment”,
http://www.redgate.com/products/ants_load/technical_papers/understanding_testing_results.htm
[9] “Microsoft Visio tutorial”
http://office.microsoft.com/en-us/downloads/CD010899231033.aspx
[10] “Visual Paradigm documentation”
http://www.visual-paradigm.com/product/vpuml/vpumldocuments.jsp
[11] “Introduction to the Diagrams of UML 2.0”
52
http://www.agilemodeling.com/essays/umlDiagrams.htm
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19] A dynamic approach to feature weighting
B. Arslan, F. Ricci, N. Mirzadeh & A. Venturini eCommerce and Tourism
Research Laboratory, ITC-irst via Sommarive 18, 38050 Povo, Italy
[20]
53