1.

Abstract
The web based “airline reservation system” project is an attempt to stimulate the
basic concepts of airline reservation system. The system enables the customer to do the things
such as search for airline flights for two travel cities on a specified date, choose a flight based on
the details, reservation of flight and cancellation of reservation.

The system allows the airline passenger to search for flights that are available
between the two travel cities, namely the “Departure city” and “Arrival city” for a particular
departure and arrival dates. The system displays all the flight’s details such as flight no, name,
price and duration of journey etc.
After search the system display list of available flights and allows customer to
choose a particular flight. Then the system checks for the availability of seats on the flight. If the
seats are available then the system allows the passenger to book a seat. Otherwise it asks the user
to choose another flight.
To book a flight the system asks the customer to enter his details such as name,
address, city, state, credit card number and contact number. Then it checks the validity of card
and book the flight and update the airline database and user database. The system also allows the
customer to cancel his/her reservation, if any problem occurs.

1
2. System Requirements Specification

HARDWARE:

PROCESSOR : PENTUIUM IV 2.6 GHz

RAM : 512MB DD RAM

MONITOR : 15” COLOR

HARD DISK :250 GB

CDDRIVE : LG52X

KEYBOARD : STANDARD 102 KEYS

MOUSE :OPTICAL MOUSE

SOFTWARE:

FORNT END :JAVA,HTML,SERVLETS

BACKEND : ORACLE 10i

OPERATING SYSTEM : WINDOWS XP

2
 Use-case view

4. IDENTIFICATION OF ACTORS
Actors are not part of system.
Actors represent anyone or anything that interacts with (input to receive output from) the
system.
An actor is someone or something that:
 Interacts with or uses the system.
 Provides input tot and receives information from the system.
 Is external to the system and has no control over the use cases.
Actors are discovered by examining:
 Who directly uses the system?
 Who is responsible for maintaining the system?
 External hardware used by the system.
 Other systems that need to interact with the system.
The need of the actor are used to develop use cases. This insures that the system will be what the
user expected.

Graphical Depiction
An actor is a stereotype of a class and is depicted as “stickman” on a use-case diagram.

Customer

3
Naming:

The name of the actor is displayed below the icon.

Questions that help to identify actors
1. Who is interested in a certain requirement
2. Where is the system used within the organization?
3. Who will benefit from the use of the system?
4. Who will supply the system with information, use this information, and remove this
information?
5. Who will support and maintain the system?
6. Does the system use an external resource?
7. Does one person play several different roles?
8. Do several people play the same role?
9. Does the system interact with a legacy system?
Using the above questions we have identified four actors is online airline reservation system.
They are
1) Traveler
2) Credit and authorization
3) Airline database
4) User database
Customer: Initially Customer searches the fights available in the web page by submitting
departure city and arrival city. After he chooses a flight from a light of available flights. After
choosing he has to submit his details for booking and confirm the booking. He can also have the
ability to cancel the flight if any problem occurs.
UML notion:

Customer

4
 2) Database Administrator: It is responsible for maintaining all the rights details such as
flight number, company, price duration of journey. The request come to any airline database
is queried and executed. The query may be either executable or update query. It is invoked by
the booking system whenever the traveler confirms the booking. It maintains the customer
details such as name, address, city, state and contact number. Whenever the customer cancels
the booking his details will be removed from the database.

UML notation

5
 Airline
database
5. IDENTIFICATION OF USE-CASES AND SUB USE-
CASES
Use case is a sequence of transactions performed by a system that yields a measurable result of
values for a particular actor. The use cases are all the ways the system may be used.
Graphical Depiction:
The base shape of a use case is an ellipse:
Naming
 A use case may have a name, although it is typically not a simple name. It is often written
as an informal text description of the actors and the sequences of events between objects.
Use case names often start with a verb.
 The name of the use case is displayed below the icon.

Reservation

Questions that help to find use cases

1. What are the tasks of each actor?
2. Will any actor create, store, change, remove or read information in the system?
3. What use cases will create, store, change, remove, or read this information?
4. Will any actor need to inform the system about sudden, external changes?
5. Does any actor need to be informed about certain occurrences in the system?
6. What use cases will support or maintain the system?
7. Can all functional requirements be performed by the use cases?
By applying the above questions to the online shopping the following use cases are
identified. They are
1) Search Flight

6
 This use case is started by traveler. It provides the facility for traveler to search for flight
based on departure and arrival city.

UML notation:

Search flight

2) Select Flight
After searching from the list of available flights the choose flight enables the traveler to
choose a flight. Then it checks the availability of seats on that flight. If the scats are available then it
allows the traveler to book a seat, otherwise it asks the traveler to choose another flight. UML
notation:

Select a flight

3) Book Flight
After choosing a flight, the traveler books the flight by using book flight system. To book
a seat the traveler first enters his details. The system then checks the credit card and books the
ticket and sends confirmation to user.
UML notation:

Book flight

4) Cancel Flight
This use case is utilized by traveler. It enables the traveler to cancel his/her reservation if
any problem occurs.
UML notation:

7
cancel flight

8
6. BUILDING REQUIREMNTS MODEL THROUGH USE-CASE
DIAGRAM

USE-CASE DIAGRAM
Definition: A Use-case diagram graphically represents system behavior (use cases). These
diagrams present a high level view of how the system is used as viewed from an outsider’s
(actor’s) perspective. A use-case diagram may contain all or some of the use cases of a system.
Association Relationship:
An association provides a pathway for communication. The communication can be
between use cases, actors, classes or interfaces. Associations are the most general of all
relationships and consequentially the most semantically weak. If two objects are usually
considered independently, the relationship is an association. Associations are of two types
1) Uni-directional association.
2) Bi-directional association.
Graphical Depiction
An association relationship is an orthogonal or straight solid line with an arrow at one
end:
In An Association Relationship, we can provide Stereotype COMMUNICATE also as
shown below

<<communicate>>

traveler Search flight

9
Dependency Relationship:
A dependency is a relationship between two model elements in which a change to one
model element will affect the other model element. Use a dependency relationship to connect
model elements with the same level of meaning. Typically, on class diagrams, a dependency
relationship indicates that the operations of the client invoke operations of the supplier.
We can provide here
1. Include Relationship.
2. Extend Relationship

1. Include Relationship
Multiple use cases may share pieces of the same functionality. This functionality is placed in
a separate use case rather than documenting it in every use case that needs it
Include relationships are created between the new use case and any other use case that “uses”
its functionality.
An include relationship is a stereotyped relationship that connects a base use case to an
inclusion use case. An include relationship specifies how behavior in the inclusion use case is
used by the base use case.

<<include>>

Ease Use-Case Inclusion Use-Case

2. Extend Relationship
An extend relationship is a stereotyped relationship that specifies how the functionality of
one use case can be inserted into the functionality of another use case. Extend relationships
between use cases are modeled as dependencies by using the Extend stereotype. An extend
relationship is used to show
 Optional behavior
10
  Behavior that is run only under certain conditions such as triggering an alarm
 Several different flows that may be run based on actor selection
 An extend relationship is drawn as a dependency relationship that points from the
extension to the base use case
The extend relationship sample demonstrates how you can use an extend relationship to connect
use cases. The sample illustrates two important aspects of extend relationships:
 An extend relationship shows optional functionality or system behavior.
 A base use case does not need to acknowledge any specific extended use cases The
sample below shows a diagram containing an actor interacting with a web site. The
Customer has the option of buying merchandise online as shown through the extend
relationship.
Finally we can conclude
 Extend is used when you wish to show that a use case provides additional functionality
that may be required in another use case.
 Include applies when there is a sequence of behavior that is used frequently in a number
of use cases, and you want to avoid copying the same description of it into each use case
in which it is used.

11
USECASE DIAGRAM FOR AIRLINE RESERVATIONSYSTEM:

<<include>>

login validate user

maintain user details

select dates select cities maintain flight details

<<include>>
<<in clude>>

<<include>>

search for flight

user

<<include>> adminstrator
select the flight type

bookticket
<<extends>>

cancel ticket

<<include>>

return money

payament

12
SUBCLASS USECASE DIAGRAM FOR AIRLINE RESERVATION SYSTEMS:

login

user search flight

database
system

select ticket

user database
book flight airline database

cancel ticket

13
7. FLOW OF EVENTS:

Use case specifications for login system:

1.Use case name: Login system
2. Flow of events:
2.1 Basic flow :
The customer enters the valid login details in login system. If it is not valid 2.2.1 alternate
flow is executed.
2.2 Alternate flow:
2.2.1 Invalid user name
The customer enters the invalid values.
3. Special requirements:
User can enter as a guest.
4.Pre conditions:
There are no preconditions.
5.Post conditions:
There are no post conditions.
6.Extension points:
There are no extension points.

Use case specification for search flight:

1.Use case name: Search Flight.
This use case is started traveler. It provides the facility to search the flights available.
2.Flow of events:
2.1 Basic flow:
This use case is started when the traveler enter the details such as departure city and arrival
city. If the names are invalid alternate flow 2.2.1 is executed. The system then checks for the list
of flights available and print them.if the flight is not available alternate flow 2.2.2 is executed.
2.2 Alternate flow:
2.2.1 If the traveler enters the city with errors such as “arrival date” is preceed departure date or
entering the dates are already completed or the cities are invalid then the system informs the
traveler that returns the details.
2.2.2 If the flight is not available between the two cities that the user enters then the system
display the message that “there is no flight service directly between two cities.
3.Special requirements:
There are no special requirements.
4.Pre conditions;
There are no pre conditions.
5. Post conditions:
There are no post conditions.
6. Extension points:
There are no extension points.

14
Use case specifications for the selecting flight:
1.Use case name: Select Flight
This use case is started by traveler. It provides the facility for traveler to select a flight from a
list of available flights.
2.Flow of events:
2.1 Basic flow:
This use case is started after the search flight is completed by traveler. The system chooses a
flight from the list of available flights if the search system find any flights between the roots. If
there are no seats available alternate flow 2.2.1 is executed.
2.2 Alternate flow:
2.2.1 If there are no seats are available on the selected flight then the system informs the
traveler to choose another flight.
3.Special requirements:
There are no special requirements.
4. Pre conditions:
There are no pre conditions.
5.Post conditions:
There are no post conditions.
6.Extension points:
There are no extension points.

Use case specifications for bookins a flight :

1.Use case name: Book Flight.

This is use case is started by the traveler.it provides the facility for the traveler to book tickets.
2. Flow of events:
2.1 Basic flow;
This use case is started after the traveler chooses a flight.the system then asks the traveler to
enter his/her details and credit card number. The system then checks the credit card number. The
system then checks the credit card validity through credit card authorization mechanism and
books the tickets else alternate flow 2.2.1 is executed. After booking the tickets the system
update databases.
2.2 Alternate flow:
2.2.1 If the credit card is not valid the system ask the traveler to re enter the credit card number
correctly.
3.Special requirements:
There are no special requirements.
4. Pre conditions:
There is availability of seats in the flight which is choosen.
5. Post conditions:
There are no post conditions.
6.Extension points:
There are no extension points.

15
Use case specification for the cancel flight :
1. Use case name: Cancel Flight.
2. This use case id started by traveler to cancel his.her reservation.
3. Flow of events:
3.1 Basic flow:This use case is started by the traveler if he was some problems with travelling.
To cancel the reservation the system asks the traveler his reservation number and
confirmation.else alternate flow 2.2.1 is executed. After the conformation of travler the
system concedes the reservation and update databases.
3.2 Alternate flow:
3.2.1 If the reservation number is in valid the message is displayed in valid number.
4. special conditions:
5. There are no special conditions.
6. Pre conditions:
User must have the reservation with that number.
7. Post conditions:
There are no post conditions.
8. Extension points:
There are no extension points.

16
8. SAMPLE PROTOTYPES FOR APPLICATION

Proto type for login system:

Proto type for registration:

Prototype for searching flight:

17
Prototype for flight details:

18
Prototype for reservation:

Prototype for cancel ticket:

19
9. ACTIVITY DIAGRAM
An Activity diagram is a variation of a special case of a state machine, in which the states
are activities representing the performance of operations and the transitions are triggered by the
completion of the operations. The purpose of Activity diagram is to provide a view of flows and
what is going on inside a use case or among several classes. We can also use activity diagrams to
model code-specific information such as a class operation. Activity diagrams are very similar to
a flowchart because you can model a workflow from activity to activity.
An activity diagram is basically a special case of a state machine in which most of the
states are activities and most of the transitions are implicitly triggered by completion of the
actions in the source activities.
 Activity diagrams represent the dynamics of the system.
 They are flow charts that are used to show the workflow of a system; that is, they show
the flow of control from activity to activity in the system, what activities can be done in
parallel, and any alternate paths through the flow.
 At this point in the life cycle, activity diagrams may be created to represent the flow
across use cases or they may be created to represent the flow within a particular use case.
 Later in the life cycle, activity diagrams may be created to show the workflow for an
operation.
Activity diagrams contain activities, transitions between the activities, decision points,
and synchronization bars. In the UML, activities are represented as rectangles with rounded
edges, transitions are drawn as directed arrows, decision points are shown as diamonds, and
synchronization bars are drawn as thick horizontal or vertical bars as shown in the following.

NewActivity

Activity Decision point Transition

20
 Start state End state Vertical synchronization bar

Horizontal synchronization bar

Activities:
An activity represents the performance of some behavior in the workflow.
Transitions:
Transitions are used to show the passing of the flow of control from activity to activity.
They are typically triggered by the completion of the behavior in the originating activity.
Decision Points:
When modeling the workflow of a system it is often necessary to show where the flow of
control branches based on a decision point. The transitions from a decision point contain a guard
condition, which is used to determine which path from the decision point is taken. Decisions
along with their guard conditions allow you to show alternate paths through a work flow.
Synchronization Bars
In a workflow there are typically some activities that may be done in parallel. A
synchronization bar allows you to specify what activities may be done concurrently.
Synchronization bars are also used to show joins in the workflow; that is, what activities
must complete before processing may continue. Means, a synchronization bar may have many
incoming transitions and one outgoing transition, or one incoming transition and many outgoing
transitions.

21
Swim lanes
Swim lanes may be used to partition an activity diagram. This typically is done to show
what person or organization is responsible for the activities contained in the swim lane.
Initial and Final Activities
There are special symbols that are used to show the starting and final activities in a
workflow. The starting activity is shown using a solid filled circle and the final activities are
shown using a bull’s eye. Typically, there is one starting activity for the workflow and there may
be more than one ending activity (one for each alternate flow in the workflow).

Modeling a workflow in an activity diagram can be done several ways; however, the
following steps present just one logical process:
1. Identify a workflow objective. Ask, “What needs to take place or happen by the end of
the workflow? What needs to be accomplished?” For example, if your activity diagram
models the workflow of ordering a book from an online bookstore, the goal of the entire
workflow could be getting the book to the customer.
2. Decide the pre and post-conditions of the workflow through a start state and an end state.
In most cases, activity diagrams have a flowchart structure so start and end states are used
to designate the beginning and ending of the workflow. State and end states clarify the
perimeter of the workflow.
3. Define and recognize all activities and states that must take place to meet your objective.
Place and name them on the activity diagram in a logical order.
4. Define and diagram any objects that are created or modified within your activity diagram.
Connect the objects and activities with object flows.
5. Decide who or what is responsible for performing the activities and states through swim
lanes. Name each swim lane and place the appropriate activities and states within each
swim lane.
6. Connect all elements on the diagram with transitions. Begin with the “main” workflow.
7. Place decisions on the diagram where the workflow may split into an alternate flow. For
example, based on a Boolean expression, the workflow could branch to a different
workflow.
8. Evaluate your diagram and see if you have any concurrent workflows. If so, use

22
 synchronizations to represent forking and joining.
9. Set all actions, triggers and guard conditions in the specifications of each model element.

ACTIVITY DIAGRAM FOR SEARCHING FLIGHTS:

user administrator

display the
enter the interface
details

submit the validate the

details user details

if valid

yes
no
display the
details

display error
message

23
ACTIVITY DIAGRAM FOR SELECTING THE FLIGHT:

user administrator

choose a
flight

request the flight information

select the class of from airline databse
reservation

reservation of particular class available

display user interface

with details

not available

display error
message

24
ACTIVITY DIAGRAM FOR BOOKING TICKET:

user administrator

enter the display the

details gui

validate the
submit the
details
criteria

if details are
valid
yes
no
reserve tickets and
send information

update the
database

reenter the display error

details message

25
ACTIVITY DIAGRAM FOR CANCEL FLIGHT:

user administrator

request the system verify the details and

to cancel ask confirmation

if details valid
no yes cancel the
reservation

update
databases

26
MAIN ACTIVITY BUSINESS DIAGRAM:

USER ADMINISTRATOR

create
catalogs
enter userid and
password

validate user

submit
if valid
yes
display home

validate
enter details
details
yes if validate
no
select flight and
display
book the flight
flights details

submit
details validate

if validi
no
receive book flight yes
acknowledgement

send
acknowledgement

27
 LOGICAL VIEW

10. IDENTIFICATION OF ANALYSIS CLASSES

1) USE-CASE DRIVEN APPROACH
One of the first steps in creating a class diagram is to derive from a use case, via a
collaboration (or collaboration diagram), those classes that participate in realizing the use
case. Through further analysis, a class diagram is developed for each use case and the various
use case class diagrams are then usually assembled into a larger analysis class diagram. This can
be drawn first for a single subsystem or increment, but class diagrams can be drawn at any scale
that is appropriate, from a single use case instance to a large, complex system.
Identifying the objects involved in collaboration can be difficult at first, and takes some
practice before the analyst can feel really comfortable with the process. Here collaboration (i.e.
the set of classes that it comprises) can be identified directly for a use case, and that, once the
classes are known, the next step is to consider the interaction among the classes and so build a
collaboration diagram.
Consider the following use case order products, to identify a set of classes.
Use case description: Search flight.

Traveler Search Flight

Actor Action
1. None
3. The actor (Customer) selects a product.
5. Prepare for order
System Response
2. Displays list of Products.
4. Displays a list of all details for ordering a product.

28
6. Presents a message confirming that the order has been allotted.

Here objective is to find a set of classes that can interact to realize the use case. In this case, we
know from the use case diagram that the traveler is the actor for this use case. The use case
description tells us that traveler search for the flight by giving arrival and departure city. The
objective of the use case search flight is allow the user to search for flights
First begin by picking out from the description all the important things or concepts in the
application domain. Our first list might include traveler, airline database, and user database. But
we are only interested in those about which the system must store some information or
knowledge in order to achieve its objectives. The traveler will be modeled as an actor.
For the purposes of this particular use case, it is unlikely the system will need to
encapsulate any further knowledge about the actor.

The Collaboration Diagram for the Above USE CASE.

Collaboration is between individual object instances, not between classes. This is shown in the
diagram by the convention of writing a colon before the class name, which indicates that this is
an anonymous instance of the class, rather than the class itself. Messages between classes are
shown by arrows, and their sequence is indicated by the number alongside. In this example, these
are not yet labeled, although some those that can be most easily related to the use case
description will probably soon be given names that correspond to responsibilities of the class to
which the message is addressed.
The collaboration diagram drawn above does not yet show any boundary or control
objects, and these must be added. It is also based on certain assumptions about how the
interaction between objects would take place, and we must make these assumptions explicit and
question them.
Although the messages are not yet labeled, the numbers alongside the message arrows
indicates their sequence. The diagram implies a linear flow of messages, along the following
lines.

29
 The system is started by traveler by entering details for search, which is assumed to know
its current status and type. The following figure shows the collaboration diagram after this
refinement adding a boundary object and control object.

: airline : :search flight UI

database 1: enter the details for search

2: send the travelling details

4: send details
5: display details
3: check the database for require flight

: traveller

: :searching system

A boundary object will be responsible for the capture of input from the user and display
of results. All messages are now routed centrally through the control object. This means that no
entity class needs to know anything about any other entity class unless this is directly relevant to
its own responsibilities.
The above figure addresses one major issue, that, it seems reasonable to assume that a
traveler is responsible for search flights. But the collaboration diagram now shows no
communication between traveler and Searching system, so it is not clear how this knowledge
will be maintained.
For this we can have another way that the interaction might work, and we could perhaps
expand this as follows. The entity object airline database obtains a list of available flights and a
control object searching system obtains the need from available and display them using boundary
object display details.

30
COLLABORATION DIAGRAM
A collaboration diagram is an alternate way to show a scenario. This type of
diagram shows object interactions organized around the objects and their links to each
other. A collaboration diagram contains:
 Objects drawn as rectangles
 Links between objects shown as lines connecting the linked objects
 Messages shown as text and an arrow that points from the client to the supplier Message
labels in collaboration diagrams:
Messages on a collaboration diagram are represented by a set of symbols that are the
same as those used in a sequence diagram, but with some additional elements to show
sequencing and recurrence as these cannot be inferred from the structure of the diagram. Each
message label includes the message signature and also a sequence number that reflects call
nesting, iteration, branching, concurrency and synchronization within the interaction.
The formal message label syntax is as follows: [Predecessor] [guard-condition] sequence-
expression [return-value ':='] message-name’ (‘ [argument-list] ') '
A predecessor is a list of sequence numbers of the messages that must occur before the
current message can be enabled. This permits the detailed specification of branching pathways.
The message with the immediately preceding sequence number is assumed to be the predecessor
by default, so if an interaction has no alternative pathways the predecessor list may be omitted
without any ambiguity. The syntax for a predecessor is as follows:
Sequence-number { ',' sequence-number} '1'
The 'l' at the end of this expression indicates the end of the list and is only included when
an explicit predecessor is shown.
Guard conditions are written in Object Constraint Language (OCL), and are only shown
where the enabling of a message is subject to the defined condition. A guard condition may be
used to represent the synchronization of different threads of control.

31
 A sequence-expression is a list of integers separated by dots ('.') optionally followed by a
name (a single letter), optionally followed by a recurrence term and terminated by a colon. A
sequence-expression has the following syntax:
Integer {'.' integer} [name] [recurrence] ': '
In this expression integer represents the sequential order of the message. This may be
nested within a loop or a branch construct, so that, for example, message 5.1 occurs after
message 5.2 and both are contained within the activation of message 5.
The name of a sequence-expression is used to differentiate two concurrent messages
since these are given the same sequence number. For example, messages 3.2.1a and 3.2.1b are
concurrent within the activation of message 3.2.
Recurrence reflects either iterative or conditional execution and its syntax is as follows:
Branching: ‘[‘condition-clause’ ],
Iteration: ‘* “[‘iteration-clause ‘ ]’
Difference between sequence and collaboration diagrams
 Sequence diagrams are closely related to collaboration diagrams and both are alternate
representations of an interaction.
 Sequence diagrams show time-based object interaction while collaboration diagrams
show how objects associate with each other.
 A sequence diagram is a graphical view of a scenario that shows object interaction in a
time based sequence
 A collaboration diagram shows object interactions organized around the objects and their
links to each other.

IDENTIFICATION OF METHODS AND ATTRIBUTES OF CLASSES

Attributes
Attributes are part of the essential description of a class. They belong to the class, unlike objects,
which instantiate the class. Attributes are the common structure of what a member of the class
can 'know'. Each object will have its own, possibly unique, value for each attribute.
Guidelines for identifying attributes of classes are as follows:

32
  Attributes usually correspond to nouns followed by prepositional phrases. Attributes also
may correspond to adjectives or adverbs.
 Keep the class simple; state only enough attributes to define the object state.
 Attributes are less likely to be fully described in the problem statement.
 Omit derived attributes.
 Do not carry discovery attributes to excess.

Some questions are there which help in identifying the responsibilities of classes and deciding
what data elements to keep track of:
 What information about an object should we keep track of?
 What services must a class provide?

Answering the first question helps us to identify the attributes of a class. Answering the second
question helps us to identify class methods.
The attributes identified in our system are:
 Attributes for Airline Reservation : details,country,date
 Attributes for User : name,number.
The responsibilities identified in our system are:
 Methods for Administrator:update,details.
 Methods for User: enter detais.

REFLEXIVE RELATIONSHIPS:
Multiple objects belonging to the same class may have to communicate with one another. This is
shown on the class diagram as a reflexive association or aggregation. Role names rather than

33
asociation names typically are used for reflexive relationships.

0..*

0..*

course

manages

course offering
proffessor course
manager

34
17. UML CLASS DIAGRAM
CLASS DIAGRAMS
 Class diagrams are created to provide a picture or view of some or all of the classes in the
model.
 The main class diagram in the logical view of the model is typically a picture of the
packages in the’ system. Each package also has its own main class diagram, which
typically displays the “public” classes of the package.
A class diagram is a picture for describing generic descriptions of possible systems. Class
diagrams and collaboration diagrams are alternate representations of object models.
Class diagrams contain icons representing classes, packages, interfaces, and their
relationships. You can create one or more class diagrams to depict the classes at the top level of
the current model; such class diagrams are themselves contained by the top level of the current
model.

CLASS :

A class is a description of a group of objects with common properties (attributes),

common behavior (operations), common relationships to other objects, and common semantics.
Thus, a class is a template to create objects. Each object is an instance of some class and objects
cannot be instances of more than one class.
Classes should be named using the vocabulary of the domain. For example, the Bus class
may be defined with the following characteristics: Attributes - location, time offered Operations
- retrieve location, retrieve time of day, add a student to the offering.
Each object would have a value for the attributes and access to the operations specified
by the Airline database class.

35
UML REPRESENTATION:
 In the UML, classes are represented as compartmentalized rectangles.
 The top compartment contains the name of the class.
 The middle compartment contains the structure of the class (attributes).
 The bottom compartment contains the behavior of the class as shown below.

<<boundary class>>
airline reservation
flightno : long
flightname : string
duration : string
price : currency

ANALYSIS CLASS STEROTYPES

Analysis class stereotypes represent three particular kinds of class that will be
encountered again and again when carrying out requirements modeling. UML DEFINITION:

Stereotype:
 A new type of modeling element that extends the semantics of the metamodel.
 Stereotypes must be based on certain existing types or classes in the metamodel.
 Stereotypes may extend the semantics but not the structure of preexisting classes.
 Certain stereotypes are defined in the UML, others may be user defined.
UML is designed to be capable of extension; developers can add new stereotypes depend
on need. But this is only done when it is absolutely necessary. Three analysis class
stereotypes to the UML are:
 Boundary classes,
 Control classes
 Entity classes.
1. Boundary classes:
Boundary classes, it is a ‘model interaction between the system and its actors’. Since
they are part of the requirements model, boundary classes are relatively abstract. They do not
directly represent all the different sorts of interface that will be used in the implementation

36
language. The design model may well do this later, but from an analysis perspective we are
interested only in identifying the main logical interfaces with users and other systems.
This may include interfaces with other software and also with physical devices such as printers,
motors and sensors. Stereotyping these as boundary classes emphasizes that their main task is to
manage the transfer of information across system boundaries. It also helps to partition the
system, so that any changes to the interface or communication aspects of the system can be
isolated from those parts of the system that provide the information storage.
The class Search flight Ul is a typical boundary class. This style of writing the name
shows that the class is Search flight UI and it belongs to the User Interface package when we
write the package name in this way before the class name, it means that this class is imported
from a different package from the one with which we are currently working. In this case, the
current package is the Agate application package, which contains the application requirements
model, and thus consists only of domain objects and classes. Alternative notations for Boundary
class stereotype can be represented as shown below
a) With stereotype

<<boundary class>>
airline reservation
flightno : long
flightname : string
duration : string
price : currency

b) Symbol

airline database

37
2. Entity classes
The second analysis class stereotype is the entity class, which are given in the class
diagram of Allotting Buses to Routes by the two classes Bus and Route.
Entity classes are used to model ‘information and associated behavior of some
phenomenon or concept such as an individual, a real-life object, or a real-life event’. As a
general rule, entity classes represent something within the application domain, but external to the
software system, about which the system must store some information. Instances of an entity
class will often require persistent storage of information about the things that they represent. This
can sometimes help to decide whether an entity class is the appropriate modeling construct.
For example, an actor is often not represented as an entity class. This is in spite of the fact
that all actors are within the application domain, external to the software system and important to
its operation. But most systems have no need to store information about their users or to model
their behavior. While there are some obvious exceptions to this (consider a system that monitors
user access for security purposes), these are typically separate, specialist applications in their
own right. In such a context, an actor would be modeled appropriately as an entity class, since
the essential requirements for such a system would include storing information about users,
monitoring their access to computer systems and tracking their actions while logged on to a
network. But it is more commonly the case that the software we develop does not need to know
anything about the people that use it, and so actors are not normally modeled as classes. The
following are representations for Entity classes.
a) With stereotype

<<entity class>>
traveller
first name : string
middle name : string
last name : string
age : int address:string
j e-mailid : string
origin city : string
destination city : string
departure date : date
arrival date

38
b) symbol

travaler

3. Control classes
The third of the analysis class stereotypes is the control class, given by y the class
Searching system in Search flight.
Control classes ‘represent coordination, sequencing, transactions and control of other
objects’ .In the USDP, as in the earlier methodology Objectory. it is generally recommended that
there should be a control class for each use case.
In a sense, then, the control class represents the calculation and scheduling aspects of the
logic of the use case at any rate, those parts that are not specific to the behavior of a particular
entity class, and that are specific to the use case. Meanwhile the boundary class represents
interaction with the user and the entity classes represent the behavior of things in the application
domain and storage of information that is directly associated with those things. The following are
the notations can be used to represent Control class
a) With stereotype

<<control class>>
searching system

check database()
send details()
b)

b) symbol

symbol

39
CLASS DIAGRAM FOR LOGIN SYSTEM:

<<BOUNDARYCLASS>>
loginui
id : String
<<CONTROLCLASS>>
startui()
loginsystem
enterloginid()
display()
senddetails()
checkvalidity()

<<ENTITYCLASS>>
informationdetails

receivedetails()
senddetails()

CLASS DIAGRAM FOR SEARCHING FLIGHTS:

<<CONTROLCLASS>>
<<BOUNDARYCLASS>>
searchui SEARCHSYSTEM
sname : String
send details()
no : integer
checkdetails()
dname : String
class : String

STARTUI()
ENTERDETAILS()
SENDDETAILS()
DISPLAY()

<<ENTITYCLASS>>
INFORMATIONDETAILS

requestflights()
senddetails()

40
CLASS DIAGRAM FOR SELECTING FLIGHT:

<<BOUNDARYCLASS>>
selectui <<controlclass>>
ch : String selectsystem
number : integer
name : String senddetails()
checkflightavailability()
startui()
display()
senddetails()

<<ENTITYCLASS>>
informationdetails

requestdetails()
senddetails()

CLASS DIAGRAM FOR BOOKING FLIGHT:

<<BOUNDARYCLASS>> <<controlclass>>
bookingui bookingsystem
name : String
number : integer senddetails()
time : integer checkvalidity()
no : integer

startui()
enterdetails()
display()
sendconfirmation() <<ENTITYCLASS>>
informationdetails

updatedetails()

<<boundaryclass>>
bookingdetails

sendetails()

41
CLASS DIAGRAM FOR CANCELLING FLIGHT:

<<BOUNDARYCLASS>>
cancelui
no : integer <<controlclass>>
name : String cancelsystem

startui() sendnum()
entername() checkconfirm()
enternum()
askconfirm()
display()

<<ENTITYCLASS>>
informationdetails

update()

42
For example, in the above figure, the inheritance hierarchy exhibits low inheritance coupling and
is poorly designed. The subclass Land Vehicle needs neither the attributes maximum Altitude
and takeoff Speed nor the operations check Altitude () and takeOff (). They have been inherited
unnecessarily.
In this example it shows the base class, Vehicle, would be better named Flying Vehicle and the
inheritance relationship is somewhat suspect. A land vehicle is not a kind of flying vehicle
.However, many systems developers view designs with a small degree of unnecessary
inheritance as being acceptable if the hierarchy is providing valuable reuse and is meaningful.
However, a subclass with unnecessary attributes or operations is more complex than it needs to
be and objects of the subclass may take more memory than they actually need. The real problems
may come when the system needs maintenance. The system’s maintainer may not realize that
some of the inherited attributes and operations are unused and may modify the system incorrectly
as a result. Alternatively the system’s maintainer may use these unneeded features to provide a
fix for a new user requirement,

43
making the system even more difficult to maintain in the future. For these reasons, unnecessary
inheritance should be kept as low as possible.
Operation Cohesion measures the degree to which an operation focuses on a single functional
requirement. Good design produces highly cohesive operations, each of which deals with a
single functional requirement. For example in the following figure , the operation
calculateRoomSpace () is highly cohesive.

Lecturer
lecturer name
lecturer Address {
roomNumber return
room Length roomLength
room width roomWidth;
}
calculatedRoomSpace()

Class Cohesion reflects the degree to which a class is focused on a single requirement. The class
Lecturer in the previous figure exhibits low levels of cohesion as it has three attributes
(roomNumber, roomLength and room Width and one operation calculate RoomSpace ()) that
would be more appropriate in a class Room. The class Lecturer should only have attributes that
describe a Lecturer object (e.g. lecturerName and lecturerAddress) and operations that use them.
Specialization Cohesion addresses the semantic cohesion of inheritance hierarchies. For example
in the following figure all the attributes and operations of the Address base class are used by the
derived classes - this hierarchy has high inheritance coupling. However, it is neither true that a
person is a kind of address nor that a company is a kind of address. The example is only using
inheritance as a syntactic structure for sharing attributes and operations. This structure has low
specialization cohesion and is poor design. It does not reflect meaningful inheritance in the
problem domain.

44
 ADDRESS
number
street
town
country
pincode

PERSON COMPANY
person name companyName
age annual income
gender annual profit

45
A better design is shown in the following figure, in which a common clas Address is being
used by both the Person and Company classes.

Address
number
street
town
country
pincode

located at
lives at
Company
Person company name
person name annual income
age annual profit
gender

2 Liskov Substitution Principle

The Liskov Substitution Principle (LSP) is another design criteria which is applicable to
inheritance hierarchies. LSP states that, in object interactions, it should be possible to treat a
derived object as if it were a base object. If the principle is not applied then it may be possible to
violate the integrity of the derived object.
In the following figure objects of the class MortgageAccount cannot be treated as if they
are objects of the class ChequeAccount because MortgageAccount objects do not have a debit
operation whereas ChequeAccount objects do. The debit operation is declared private in
MortgageAccount and hence cannot be used by any other object. It also shows an alternative
structure that satisfies LSP. Interestingly, this inheritance hierarchy has maximal inheritance
coupling, and enforcing the LSP normally produces structures with high inheritance coupling.

46
 Account
Account name
cheque Account balance
Account Name
balance credit()

credit()
debit()

MortageAccount Mortage Account cheque account

intrest Rate intrest Rate
debit()
calculate interfaces() calculate intrest()
debit()

3 Further design guidelines

The following are the further guidelines which are to be considered for good design.
Design Clarity. A design should be made as easy to understand as possible. This reinforces the
need to use design standards or protocols that have been specified.
Don’t Over-Design. Developers are on occasions tempted to produce designs that may
not only satisfy current requirements but may also be capable of supporting a wide range of
future requirements. Designing flexibility into a system has a cost, the system may take longer to
design and construct but this may be offset in the future by easier and less expensive
modification. However, it is not feasible to design for every eventuality. Systems that are over
designed in first instance are more difficult to extend if the modifications are not sympathetic to
the existing structure.
Control Inheritance Hierarchies. Inheritance hierarchies should be neither too deep nor
too shallow. If a hierarchy is too deep it is difficult for the developer to understand easily what
features are inherited. There is a tendency for developers new to 00 to produce over-specialized
hierarchies, thus adding complexity rather than reducing it.
Keep Messages and Operations Simple. In general it is better to limit the number of
parameters passed in a message to no more than three .Ideally an operation should be capable of
specification in no more than one page.
Design Volatility. A good design will be stable in response to changes in requirements. It
reasonable to expect some change in the design if the requirements are changed, However, any

47
change in the design should be commensurate with the change in requirements. Enforcing
encapsulation is a key factor in producing stable systems.
Evaluate by Scenario. An effective way of testing the suitability of a design is to role
paly it against the use cases using CRC cards.
Design by Delegation. A complex object should be decomposed (if possible) into component
objects forming a composition or aggregation. Behavior can then be delegated to the
component objects producing a group of objects that are easier to construct and maintain. This
approach also improves reusability.
Keep Classes Separate. In general, it is better not to place one class inside another. The
internal class is encapsulated by the other class and cannot be accessed independently. This
reduces the flexibility of the system.

REFINING ATTRIBUTES, METHODS AND RELATIONSHIPS

Attributes
During analysis Stage we need to consider in detail the data types of the attributes also.
Common primitive data types include Boolean (true or false), Character (any alphanumeric or
special character), Integer (whole numbers) and Floating-Point (decimal numbers). In most
object-oriented languages more complex data types, such as Money, String, Date, or Name can
be constructed from the primitive data types or may be available in standard libraries. An
attribute's data type is declared in UML using the following syntax:

name ':' type-expression '=' initial-value '{'property-string'}'

48
 The name is the attribute name, the type-expression is its data type, the initial value is the
value the attribute is set to when the object is first created and the property-string describes a
property of the attribute, such as constant or fixed. The characters in single quotes are literals.

Operations

Each operation also has to be specified in terms of the parameters that it passes and
returns. The syntax used for an operation is:
Operation name' ('parameter-list ') “: “return-type-expression

An operation's signature is determined by the operation's name, the number and type of
its parameters and the type of the return value if any.

Object visibility

The concept of encapsulation is one of the fundamental principles of object-orientation.

During analysis various assumptions have been made regarding the encapsulation boundary for
an object and the way that objects interact with each other.

For example, it is assumed that the attributes of an object cannot be accessed directly by
other objects but only via 'get' and 'set' operations (primary operations) that are assumed to be
available for each attribute. Moving to design involves making decisions regarding which
operations (and possibly attributes) are publicly accessible. In other words we must define the
encapsulation boundary.

The following are the different kinds of visibilities, their symbols and their meaning.
Visibility Visibility Meaning
symbol

49
 + Public The feature (an operation or an attribute) is directly
accessible by an instance of any class.
- Private The feature may only be used by an instance of the class
that includes it.
# Protected The feature may be used either by instances of the class
that includes it or of a subclass or descendant of that
class.
~ Package The feature is directly accessible only by instances of a
class in the same package.

Interfaces

Generally a class may present more than one external interface to other classes or the
same interface may be required from more than one class. An interface in UML is a group of
externally visible (i.e. public) operations. The interface contains no internal structure, it has no
attributes, no associations and the implementation of the operations is not defined. Formally, an
interface is equivalent to an abstract class that has no attributes, no associations and only abstract
operations.

The following figure shows two alternative notations for an interface. The simpler of the
two UML interface notations is a circle. This is attached by a solid line to the classes that support
the interface. For example, in Figure the Advert class supports two interfaces, Manageable and
accessible, that is, it provides all of the operations specified by the interface. The circle notation
does not include a list of the operations provided by the interface type, though they should be
listed in the repository. The dashed arrow from the Staff class to the Manageable interface circle
icon indicates that it uses or needs, at most, the operations provided by the interface.

The alternative notation uses a stereotyped class icon. As an interface only specifies the
operations and has no internal structure, the attributes compartment is omitted. This notation lists
the operations on the diagram. The realize relationship, represented by the dashed line with a
triangular arrowhead, indicates that the passenger class (e.g reservation) supports at least the

50
operations listed in the interface .Again the dashed arrow from staff means that the class needs or
uses no more than the operations listed in the interface.

CLASS SPECIFICATION - Attributes and operation signatures

Object visibility
Interfaces
In general it is better to limit the number of parameters passed in a message to no more
than three .Ideally an operation should be capable of specification in no more than one page.
Design Volatility. A good design will be stable in response to changes in requirements. It is
reasonable to expect some change in the design if the requirements are changed. However, any
change in the design should be commensurate with the change in requirements. Enforcing
encapsulation is a key factor in producing stable systems.

51
 Test case for Cancelling flights :
Test case Test test case test steps test status (P/F)
id case desc step Expected actual
name
Flight Validate To verify that Enter flight an error F
number Flight flight number number in message
number on character “flight
Cancellation and click number
page cancel should
button. not be in
character
s” must
be
displayed

Booking
enter the successf
Flight ully
number “valid P
with four flight
digits and number”
click must be
cancel displayed
button. .

User Validate To verify that enter User an error F

User User name name message
name on starting “Special
Cancellation with chars not
page does special allowed
not take chars (! in User
special hello) and name”
characters click must be
cancel displayed
button

enter User Message P

name with is
characters displayed
>3 and <10 ”Success
and click fullly
cancel Cancellat
button ion is
complete
d”.

52
 Test case for Booking flights :
Test case Test case test case desc test steps test status (P/F)
id name step Expected actual
Flight Validate To verify that enter flight an error F
number Flight flight number number in message
number on Booking character “flight
page and click number
book should
button not be in
otherwise character
click cancel s” must
button be
displayed
enter the
Flight
number Booking
with four successfu
digits and lly “valid P
click book flight
button number”
otherwise must be
click cancel displayed.
button

Credit Validate To verify that enter card an error F

card Credit credit card number message
card number on less than “The card
Booking page 10 digits number
must be 10 ,enter User must not
digit number details click be less
Book than 10
button digits”
otherwise must be
click cancel displayed
button

enter flight Message P

number is
with 10 displayed
digits saying
,enter User “valid
details click credit card
Book number”.
button
otherwise
click cancel
button

53
User Validate To verify that enter User an error F
User User name name message
name on Booking starting “Special
page does with chars not
not take special allowed
special chars (! in User
characters hello) and name”
click Book must be
button displayed
otherwise
click
cancel
button

enter User Message P

name with is
characters displayed
>3 and <10 ”Success
and click fullly
Book booking
button complete
otherwise d”.
click
cancel
button

Code and Screenshots

54
Index.jsp
<jsp:include page="header.jsp" />
<nav class="navbar navbar-expand-lg navbar-dark indigo">
<div class="container">
<a class="navbar-brand" href="#">
<img src="assets/images/icon.png" alt="">
</a>
<button class="navbar-toggler" type="button" data-toggle="collapse" data-
target="#navbarText"
aria-controls="navbarText" aria-expanded="false" aria-label="Toggle
navigation">
<span class="navbar-toggler-icon"></span>
</button>
<div class="collapse navbar-collapse" id="navbarText">
<ul class="navbar-nav mr-auto">
<li class="nav-item ">
<a class="nav-link" href="#">Home

</a>
</li>
<li class="nav-item">
<a class="nav-link" href="login.jsp">Register</a>
</li>
<li class="nav-item">
<a class="nav-link" href="flight-search.jsp">Search
Flight</a>
</li>

</ul>

</div>
</div>

</nav>
<section id="home" class="intro-section">

55
 <div class="container">
<div class="row">
<div class="col-md-12">
<div class="video-box mt-5">
<img src="assets/images/in.png" alt="video illutration"
class="img-fluid">
</div>
</div>

</div>
<div class="row">
<div class="col-md-12">
<div class="heading">
<h1>Buddha traveler agency</h1>
<h4> Lorem ipsum dolor sit amet consectetur adipisicing elit.
Amet placeat, magni praesentium ab
</h4>
</div>

</div>
</div>
</div>
</section>

<!-----------------------------main content------------->

<jsp:include page="footer.jsp" />

Register Page

56
Login Page

package com.air;

import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;

/**

57
 * Servlet implementation class Login
*/
@WebServlet("/Login")
public class Login extends HttpServlet {
private static final long serialVersionUID = 1L;

public void service(HttpServletRequest request,HttpServletResponse response)

{
String email= request.getParameter("email");
String password= request.getParameter("password");

Modal m=new Modal();

m.setEmail(email);
m.setPassword(password);
boolean x=m.user();
String psd = m.getPassword();
if(psd.equals(password))
{
HttpSession session =request.getSession(true);
int id=m.getId();
String name=m.getName();
String mobile=m.getMobile();
String dob=m.getDob();
String gender=m.getGender();
String address=m.getAddress();
session.setAttribute("id", id);
session.setAttribute("name", name);
session.setAttribute("email", email);
session.setAttribute("mobile", mobile);
session.setAttribute("dob", dob);
session.setAttribute("gender", gender);
session.setAttribute("address", address);

if(x==true)
{
try
{
response.sendRedirect("/Air/home.jsp");
}
catch(Exception e)
{
e.printStackTrace();
}
}
else
{

58
 try
{
response.sendRedirect("/Air/userfaillogin.jsp");
}
catch(Exception e)
{
e.printStackTrace();
}
}
}
}

}
Search Flight

Home page

59
Book Page

60
Booking List

61
String url="jdbc:mysql://localhost/air?useSSL=false&serverTimezone=UTC";
String unn="root";
String pwd="";

Modal()
{
try
{
DriverManager.registerDriver(new com.mysql.jdbc.Driver());
con=DriverManager.getConnection(url,unn,pwd);
}
catch(Exception e )
{
e.printStackTrace();
}
}
int register()
{
try
{
String ss= "SELECT * FROM user where email=?";
pstmt = con.prepareStatement(ss);
pstmt.setString(1, email);
res = pstmt.executeQuery();
if(res.next()==false)
{
String s="INSERT INTO user VALUES(?,?,?,?,?,?,?,?)";
pstmt=con.prepareStatement(s);
pstmt.setInt(1, id);

pstmt.setString(2, name);
pstmt.setString(3, email);
pstmt.setString(4, mobile);
pstmt.setString(5, dob);
pstmt.setString(6, gender);
pstmt.setString(7, address);
pstmt.setString(8, password);

int x=pstmt.executeUpdate();
return x;
}
else
{
return -1;
}

62
 }
catch (Exception e)
{
e.printStackTrace();
}
return 0;
}

//*********************************user Login Module*************

boolean user()
{
try
{
String s="SELECT * FROM user WHERE email =? AND
password =?";
pstmt=con.prepareStatement(s);
pstmt.setString(1, email);
pstmt.setString(2, password);
res=pstmt.executeQuery();
while(res.next()==true)
{
id=res.getInt(1);
name=res.getString(2);
email=res.getString(3);
mobile=res.getString(4);
dob=res.getString(5);
gender=res.getString(6);
address=res.getString(7);
password=res.getString(8);

return true;
}

}
catch(Exception e)
{
System.out.println("Some problem in Model");
}
return false;
}

int book()
{

63
 try {
String s="INSERT INTO book
VALUES(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)";
pstmt=con.prepareStatement(s);
pstmt.setString(1, book_id);
pstmt.setString(2, book_user);
pstmt.setString(3, book_flight);
pstmt.setString(4, destination);
pstmt.setString(5, d_date);
pstmt.setString(6, d_time);
pstmt.setString(7, dto);
pstmt.setString(8, to_date);
pstmt.setString(9, to_time);
pstmt.setString(10, name);
pstmt.setString(11, email);
pstmt.setString(12, mobile);
pstmt.setString(13, gender);
pstmt.setString(14, dob);
pstmt.setString(15, address);
pstmt.setString(16, book_date);

int x=pstmt.executeUpdate();
return x;
}
catch (Exception e)
{
e.printStackTrace();
}
return 0;
}
//*********************************Admin Login Module*************
boolean admin()
{
try
{
String s="SELECT * FROM admin WHERE email =? AND password
=?";
pstmt=con.prepareStatement(s);
pstmt.setString(1, email);
pstmt.setString(2, password);
res=pstmt.executeQuery();
while(res.next()==true)
{

email=res.getString(3);

64
 password=res.getString(4);
name=res.getString(2);

return true;
}

}
catch(Exception e)
{
System.out.println("Some problem in Model");
}
return false;
}

//_________________________Add Flight__________________
int flight()
{
try {
String s="INSERT INTO flight VALUES(?,?,?,?,?,?,?,?,?,?,?,?)";
pstmt=con.prepareStatement(s);
pstmt.setInt(1, flight_id);

pstmt.setString(2, flight_name);
pstmt.setString(3, destination);
pstmt.setString(4, dto);
pstmt.setString(5, d_date);
pstmt.setString(6, d_time);
pstmt.setString(7, to_date);
pstmt.setString(8, to_time);
pstmt.setString(9, price);
pstmt.setString(10, sheet);
pstmt.setString(11, date);
pstmt.setInt(12, staus);
int x=pstmt.executeUpdate();
return x;
}
catch (Exception e)
{
e.printStackTrace();
}
return 0;
}
//********************************* Flight Search Module*************
public List<Modal> get() {

List<Modal> list = null;

65
 Modal item = null;
try {

list = new ArrayList<Modal>();

String sql = "SELECT * FROM flight where destination=? and dto=? and
price=?";
pstmt = con.prepareStatement(sql);
pstmt.setString(1, "GKP");
pstmt.setString(2, "BLR");
pstmt.setString(3, "3000");
res = pstmt.executeQuery();

while(res.next()) {
String flight_name = res.getString("flight_name");
String destination = res.getString("destination");
String dto = res.getString("dto");
String d_date = res.getString("d_date");

String d_time = res.getString("d_time");

String to_date = res.getString("to_date");
String to_time = res.getString("to_time");
String price = res.getString("price");
System.out.println(d_date+d_time);
item = new Modal();

item.setFlight_name(res.getString("flight_name"));
item.setDestination(res.getString("destination"));

item.setDto(res.getString("dto"));
item.setD_date(res.getString("d_date"));
item.setD_time(res.getString("d_time"));
item.setTo_date(res.getString("to_date"));

item.setTo_time(res.getString("to_time"));
item.setPrice(res.getString("price"));
list.add(item);
System.out.println(destination);
}
}catch(SQLException e) {
e.printStackTrace();
}
return list;
}

66
}
Database user side
User Register

Flight Data base

Booking Data base

Admin Side
Page

Database
67
Add Flight

68
package com.air;

import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

/**
* Servlet implementation class Flight
*/
@WebServlet("/Flight")
public class Flight extends HttpServlet
{
private static final long serialVersionUID = 1L;

public void service(HttpServletRequest request , HttpServletResponse response)

{
//String user_id =request.getParameter("user_id");
String flight_name =request.getParameter("flight_name");
String destination =request.getParameter("destination");
String dto =request.getParameter("dto");

69
String d_date =request.getParameter("d_date");
String d_time =request.getParameter("d_time");
String to_date =request.getParameter("to_date");
String to_time =request.getParameter("to_time");
String price =request.getParameter("price");
String sheet =request.getParameter("sheet");

Modal m=new Modal();

//m.setUser_id((user_id)+(m.getId()));
m.setFlight_name(flight_name);
m.setDestination(destination);
m.setDto(dto);
m.setD_date(d_date);
m.setD_time(d_time);
m.setTo_date(to_date);
m.setTo_time(to_time);
m.setPrice(price);
m.setSheet(sheet);

int x=m.flight();
if(x==1)
{
try
{

response.sendRedirect("/Air/flight-succeses.jsp");
}
catch (Exception e)
{

}
}

else
{
try
{
response.sendRedirect("/Air/flight-error.jsp");
}
catch (Exception e)
{

}
}

70
}

}
Booking List Page

Modal.java
package com.air;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;
import java.util.ArrayList;
import java.util.List;
import com.mysql.jdbc.Statement;

public class Modal

{
private int id;
private String name;

71
private String email;
private String mobile;
private String dob;
private String gender;
private String address;
private String password;
private int flight_id;
private String flight_name;
private String destination;
private String dto;
private String d_date;
private String d_time;
private String to_date;
private String to_time;
private String price;
private String sheet;
private String book_id;
DateTimeFormatter dtf = DateTimeFormatter.ofPattern("MM/dd/yyyy");
LocalDateTime now = LocalDateTime.now();
private String date = dtf.format(now);
private String book_date =dtf.format(now);
private int staus;

private String book_user;

private String book_flight;
Statement statement = null;
Connection con=null;
PreparedStatement pstmt=null;
ResultSet res=null;
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getEmail() {
return email;
}
public void setEmail(String email) {
this.email = email;

72
}
public String getMobile() {
return mobile;
}
public void setMobile(String mobile) {
this.mobile = mobile;
}
public String getDob() {
return dob;
}
public void setDob(String dob) {
this.dob = dob;
}
public String getAddress() {
return address;
}
public void setAddress(String address) {
this.address = address;
}
public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}

public String getGender() {

return gender;
}
public void setGender(String gender) {
this.gender = gender;
}

public int getFlight_id() {

return flight_id;
}
public void setFlight_id(int flight_id) {
this.flight_id = flight_id;
}
public String getFlight_name() {
return flight_name;
}
public void setFlight_name(String flight_name) {
this.flight_name = flight_name;
}

73
public String getDestination() {
return destination;
}
public void setDestination(String destination) {
this.destination = destination;
}
public String getDto() {
return dto;
}
public void setDto(String dto) {
this.dto = dto;
}
public String getD_date() {
return d_date;
}
public void setD_date(String d_date) {
this.d_date = d_date;
}
public String getD_time() {
return d_time;
}
public void setD_time(String d_time) {
this.d_time = d_time;
}
public String getTo_date() {
return to_date;
}
public void setTo_date(String to_date) {
this.to_date = to_date;
}
public String getTo_time() {
return to_time;
}
public void setTo_time(String to_time) {
this.to_time = to_time;
}
public String getPrice() {
return price;
}
public void setPrice(String price) {
this.price = price;
}
public String getSheet() {
return sheet;
}
public void setSheet(String sheet) {

74
 this.sheet = sheet;
}
public String getDate() {
return date;
}
public void setDate(String date) {
this.date = date;
}
public int getStaus() {
return staus;
}
public void setStaus(int staus) {
this.staus = staus;
}

public String getBook_date() {

return book_date;
}
public void setBook_date(String book_date) {
this.book_date = book_date;
}

public String getBook_user() {

return book_user;
}
public void setBook_user(String book_user) {
this.book_user = book_user;
}
public String getBook_flight() {
return book_flight;
}
public void setBook_flight(String book_flight) {
this.book_flight = book_flight;
}

public String getBook_id() {

return book_id;
}
public void setBook_id(String book_id) {
this.book_id = book_id;
}

75
String url="jdbc:mysql://localhost/air?useSSL=false&serverTimezone=UTC";
String unn="root";
String pwd="";

Modal()
{
try
{
DriverManager.registerDriver(new com.mysql.jdbc.Driver());
con=DriverManager.getConnection(url,unn,pwd);
}
catch(Exception e )
{
e.printStackTrace();
}
}
int register()
{
try
{
String ss= "SELECT * FROM user where email=?";
pstmt = con.prepareStatement(ss);
pstmt.setString(1, email);
res = pstmt.executeQuery();
if(res.next()==false)
{
String s="INSERT INTO user VALUES(?,?,?,?,?,?,?,?)";
pstmt=con.prepareStatement(s);
pstmt.setInt(1, id);

pstmt.setString(2, name);
pstmt.setString(3, email);
pstmt.setString(4, mobile);
pstmt.setString(5, dob);
pstmt.setString(6, gender);
pstmt.setString(7, address);
pstmt.setString(8, password);

int x=pstmt.executeUpdate();
return x;
}
else
{
return -1;
}
}

76
 catch (Exception e)
{
e.printStackTrace();
}
return 0;
}

//*********************************user Login Module*************

boolean user()
{
try
{
String s="SELECT * FROM user WHERE email =? AND
password =?";
pstmt=con.prepareStatement(s);
pstmt.setString(1, email);
pstmt.setString(2, password);
res=pstmt.executeQuery();
while(res.next()==true)
{
id=res.getInt(1);
name=res.getString(2);
email=res.getString(3);
mobile=res.getString(4);
dob=res.getString(5);
gender=res.getString(6);
address=res.getString(7);
password=res.getString(8);

return true;
}

}
catch(Exception e)
{
System.out.println("Some problem in Model");
}
return false;
}

int book()
{

try {

77
 String s="INSERT INTO book
VALUES(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)";
pstmt=con.prepareStatement(s);
pstmt.setString(1, book_id);
pstmt.setString(2, book_user);
pstmt.setString(3, book_flight);
pstmt.setString(4, destination);
pstmt.setString(5, d_date);
pstmt.setString(6, d_time);
pstmt.setString(7, dto);
pstmt.setString(8, to_date);
pstmt.setString(9, to_time);
pstmt.setString(10, name);
pstmt.setString(11, email);
pstmt.setString(12, mobile);
pstmt.setString(13, gender);
pstmt.setString(14, dob);
pstmt.setString(15, address);
pstmt.setString(16, book_date);

int x=pstmt.executeUpdate();
return x;
}
catch (Exception e)
{
e.printStackTrace();
}
return 0;
}
//*********************************Admin Login Module*************
boolean admin()
{
try
{
String s="SELECT * FROM admin WHERE email =? AND password
=?";
pstmt=con.prepareStatement(s);
pstmt.setString(1, email);
pstmt.setString(2, password);
res=pstmt.executeQuery();
while(res.next()==true)
{

email=res.getString(3);
password=res.getString(4);

78
 name=res.getString(2);

return true;
}

}
catch(Exception e)
{
System.out.println("Some problem in Model");
}
return false;
}

//_________________________Add Flight__________________
int flight()
{
try {
String s="INSERT INTO flight VALUES(?,?,?,?,?,?,?,?,?,?,?,?)";
pstmt=con.prepareStatement(s);
pstmt.setInt(1, flight_id);

pstmt.setString(2, flight_name);
pstmt.setString(3, destination);
pstmt.setString(4, dto);
pstmt.setString(5, d_date);
pstmt.setString(6, d_time);
pstmt.setString(7, to_date);
pstmt.setString(8, to_time);
pstmt.setString(9, price);
pstmt.setString(10, sheet);
pstmt.setString(11, date);
pstmt.setInt(12, staus);
int x=pstmt.executeUpdate();
return x;
}
catch (Exception e)
{
e.printStackTrace();
}
return 0;
}
//********************************* Flight Search Module*************
public List<Modal> get() {

List<Modal> list = null;

Modal item = null;

79
try {

list = new ArrayList<Modal>();

String sql = "SELECT * FROM flight where destination=? and dto=? and
price=?";
pstmt = con.prepareStatement(sql);
pstmt.setString(1, "GKP");
pstmt.setString(2, "BLR");
pstmt.setString(3, "3000");
res = pstmt.executeQuery();

while(res.next()) {
String flight_name = res.getString("flight_name");
String destination = res.getString("destination");
String dto = res.getString("dto");
String d_date = res.getString("d_date");

String d_time = res.getString("d_time");

String to_date = res.getString("to_date");
String to_time = res.getString("to_time");
String price = res.getString("price");
System.out.println(d_date+d_time);
item = new Modal();

item.setFlight_name(res.getString("flight_name"));
item.setDestination(res.getString("destination"));

item.setDto(res.getString("dto"));
item.setD_date(res.getString("d_date"));
item.setD_time(res.getString("d_time"));
item.setTo_date(res.getString("to_date"));

item.setTo_time(res.getString("to_time"));
item.setPrice(res.getString("price"));
list.add(item);
System.out.println(destination);
}
}catch(SQLException e) {
e.printStackTrace();
}
return list;
}
}

80
REFERENCES

1. Ali Bahrami – “Object oriented systems Development”

2. Grady Booch, James Rumbaugh, and Ivar Jacobson -”Unified Modeling Language User
Guide”
3. Simon Bennett ,Steve Mcrobband Ray Farmer– “Object Oriented Analysis and Design”
4. Terry quatrani –“Visual modeling with Rational Rose 2002”

81