An Object-oriented Analysis Model for Flight

Reservations: A case study in composition of patterns

Eduardo B. Fernandez and Zhen Jiang
Department of Computer Science and Engineering
Florida Atlantic University
Boca Raton, FL 33431
{ed | zjiang}@cse.fau.edu

Abstract
Airport control software is a very complex real-life system and the flight
reservation system is one of its most commonly used sections. We describe
here an analysis model for such a reservation system, developed by
composing different functional aspects. This model represents a minimum
application to book a series of tickets and it can be applied to a variety of
similar situations. Each part of this model is what we have called a Semantic
Analysis Pattern (SAP), a pattern that realizes a few basic use cases. We use
the airport example to show that SAPs can be combined to build complex
applications in a convenient way that results in models that are flexible and
reusable..
Keywords: Analysis patterns, Flight reservation systems, Object-oriented analysis
and design, Flight routing.

1. Introduction
When dealing with the specification, design, or implementation of a number of
similar applications, common parts can be found. These parts can be specified as
patterns that are independent from a particular specification, implementation details,
or implementation language. Sometimes such modules are not so simple: a general
module for different purposes to achieve separation of concerns is not trivial.
Moreover, the more complicated modules often vary slightly from application to
application. As the number of applications increases, their management becomes
increasingly difficult and unwieldy. The concept of Semantic Analysis Patterns
(SAPs) [3] emphasizes functional aspects of the application model as opposed to

improving flexibility. The main purpose of this type of pattern is to serve as a starting
point when translating requirements into a conceptual model. This type of pattern
represents a minimum application (a set of basic use cases) so that it can be applied to
a variety of situations and it can be combined with other related patterns to describe
more complex applications [4].
Software for airport management is a very complex real-life system and the flight
reservation system is one of its most commonly used parts. Typically a customer
places an order for a seat(s) for a certain combination of connected flights. To support
such an operation, the customer and the system need to check the feasibility of flight
connections and their schedule. Several different atomic patterns can be derived to
provide the different functional aspects of the system. The purpose of this paper is
tying together these existing patterns to design a more complex system, which would
be very hard to build directly. Because of the way it is built the resulting model is also
flexible and reusable.
Section 2 describes the requirement for this system and a set of atomic patterns.
Each atomic pattern focuses on a detailed functional aspect of the system. To describe
each pattern we follow loosely the templates of [2]. Section 3 shows how we
compose these patterns to develop a flight reservation system. The effectiveness and
flexibility of this SAP is shown by domain analysis using some examples. We end
with some conclusions in Section 4.

2. Requirements and atomic patterns

2.1 Requirements
It is possible to visualize the structure of a large system as a set of component
units based on different functional aspects. The list of requirements for the reservation
system is given below. These requirements correspond to some use cases which we
do not describe in detail for conciseness.

Customers make reservations for specific seats in specific flights.

A flight is defined by a number and a date, and determines a route from an

origin airport to a destination airport. Planes are assigned to flights.

A route is the way followed by a flight from its origin airport to its destination
airport. A route may have several flights that share the same origin and
destination airports.
2

A span is the way to get from a start airport to a termination airport using one
flight. The start (or termination) airport is called origin (or destination) airport
of this span.

For each flight there are several connecting flights (different flights that leave
from an intermediate stop closely after its arrival).

A ticket includes a one-ticket route (one-way ticket) or a two-ticket route

(round-trip ticket). By a round-trip ticket, a passenger can go to an airport and
come back using the same route. A passenger may use a different route to
come back from the destination to which she arrived. For each route, she
needs a set of one-way ticket(s). Such a round-trip is a special case of oneway trip where its source and destination are the same. Stops are not indicated
in the ticket unless the flight number changes, which indicates a plane change.

For the convenience of customers we keep information on relevant facilities;

for origins we keep aspects such as parking, for destinations we keep hotels
near the airport, for intermediate stops hotels in the airport, restaurants, etc.
This information also includes details of the cities nearby.

From these requirements, we derive some atomic patterns that describe aspects
such as Order, Collection, Assignment, Connection, Routing, and Role. Most of these
patterns here appeared before, only Connection and Routing appear to be new
patterns. For each functional aspect, we adopt a related pattern to implement it and
make some adjustments to satisfy the requirement of composition.

2.2 Travel ticket pattern

Context
A series of tickets for a certain type of trip (one-way / round-trip) is booked for a
passenger.
Problem
How to describe a request for a series of tickets?
Forces
The request must be captured in a precise way.

Passengers want usually a series of tickets, not just a single ticket.

Each ticket includes origin, destination, flight information, and seat

information.

Passenger

TicketSeries

id(/account#):
String
creditInfo: String

1..*
book

ticketseries#: String
bookdate: String

1..*

TicketUnit

1..2
1..*

TicketRoute
type: {one-way, round-trip}
trip_source: String
trip_destination: String

ticket#: String
origin: String
destination: String
flight$#: String
class: {A, B, C}
seat#: String

Figure 1: Class diagram for Order pattern

Solution
A variation of the Order pattern ([4]) satisfies the forces. The class model of Figure 1
shows the required information, including classes to describe the series of tickets
(TicketSeries), the passenger who needs that order (Passenger), and two catalogs of
tickets (TicketRoute and TicketUnit). TicketRoute is used for arranging the schedule
of Flight and TicketUnit is used for price-checking or even later check-in. Each
TicketRoute object consists of several TicketUnit objects. The corresponding
sequence diagram is given in Figure 2 showing how to place an order for a series of
tickets.
:Passenger

:TicketSeries

request

:TicketRoute

check availability

:Ticket-1

:Ticket-2

check availability

confirmed (Ticket-1)
check availability
confirmed (Ticket-2)

show-price
book

confirmed (Ticket-n)

book ticket (Ticket-1)

confirm (Ticket-1)

book ticket (Ticket-n)

confirm (TicketSeries)

confirm (Ticket-n)

Figure 2: Sequence diagram for Order pattern

Consequences
This pattern describes only the ordered tickets, it must be complemented with
other aspects e.g., seat and flight information.

TicketSeries in this pattern may be any other product with multiple units.

The customer who places an order may be a person or a corporation. Here we

only focus on the passenger who will get the ticket(s) and use it (them). We
could use a customer with two roles for this purpose.

The requested tickets refer to a series of products. Their relationship and detail
processing are discussed later in other patterns.

Delivery, payment, and identification details are not included.

2.3 Assignment pattern

Context
A TicketUnit is assigned to a Seat, Flight, and Span.
Problem
How to correlate several objects such as seat, flight, and span under the aspect of one
ticket unit?
Forces
The function of TicketUnit is fulfilled based on related information from the
assigned classes.

TicketUnit is a class different from its assigned classes. It has rights to access
the information of the assigned classes by the assignment.

The availability of a seat and the feasibility of a connecting span and its
connecting flight must be confirmed.

Solution
The Assignment Pattern satisfies these forces. Figure 3 shows classes (TicketUnit,
Seat, Span, and Flight) and their assignment relationship.

Assignment Pattern

{available series tickets}

TicketSeries

1..*

ticketseries#: String
bookdate: String

TicketUnit
ticket#: String

{connected spans}

Span
origin: String
destination: String

{connecting flights have

connecting schedule}

Flight
flight#: String
schedule: List<departure time,
arrival time, stop>

{available seat#}

Seat
seat#: String

association as class
dependence of constraints

Figure 3: Class diagram for the Assignment pattern (TicketUnit)

Consequences

This pattern may be used for assignment of other types of items, i.e., an assignment
to Faculty, Student and Staff in a university department information system.

From the assignment, TicketUnit can access the related information of

assigned classes and provide seat information for a certain span of a flight.

Constraints defined on TicketSeries help to confirm the connecting ticketUnit based

on available seat, connecting flight and connecting span.

Available seat, connecting flight and connecting span are discussed later in other
patterns

2.4 Collection pattern

Context
The availability of a seat as a part of the plane for a flight is checked.
Problem
How to describe the relationship between a whole object and other objects as its parts, where
the collected objects are similar but have their own identities?

Forces
An entity has a certain number of similar units. For example, each seat is a
part of a plane; the plane has global information and knows if a seat with a
specific seat number in a requested class is available.

There is a whole class and a part class. For example, a plane has a whole/part
(WP) relationship with its related seats.

Based on that WP relationship, one can check the availability of units,

An available seat implies an unbooked seat number in the class list of a plane
assigned to the flight.
Collection Pattern

{connecting flights have

connecting schedule}

{available seat#}

Flight

Seat

flight#: String
schedule: List<departure time,
arrival time, stop>

seat#: String
*

1..*

Plane

1
assigned_to

dependence of constraints

type: String
no#: String
seatCapacity: InfoList
classInfo: InfoList

{a plane has a
fixed number
of seats in
a class

Figure 4: Class diagram for Collection pattern (Seat and Plane)

Solution
The Collection Pattern [2] satisfies the forces when interpreted according to the
Reservation pattern of [5]. The class model for such a pattern is shown in Figure 4.
Consequences

This pattern may be used for any whole object and its part objects. This is both an
analysis and a design pattern.

To check if a seat in a requested class is available, the seat (part object) should know
the capacity and class information of a plane (its whole object). Alternatively, a plane
should know if all seats are booked from this WP relationship.

Constraints defined on Seat help to confirm the available seats of a plane which is
assigned to a flight.

Other parts of Plane and other information which are not related to reservation are
not included.

2.5 Connection pattern

Context
In a set of objects, each of them may have a relationship to some others. An airport is
connected with another by an airlink. A span is connected to another if the destination
of the preceding span is also the origin of the succeeding one. A span is also
connected to another if the destination of the preceding span is connected with the
origin of the succeeding one by other means of transportation. If there is another kind
of connection between these two airports we use other-link (see Figure 5). A flight is
connected to another if and only if airport(s) between two connected spans has (have)
a connecting schedule whose arrival time is before departure time.
{connecting flights have
connecting schedule}
f_connecting
1..*

Flight
flight#: String
schedule: List<departure time,
arrival time, stop>

Span

{connection between
different spans}
s_connecting

origin: String
destination: String

Connection Pattern

Connection Pattern

{connecting condition}
a_connected_by
1..*

Airport
name: String
city: String

other_link
1..*

a_connecting

Connection Pattern

Figure 5: Class diagram for Connection pattern

Problem
How to describe a relationship between objects in the same class?
Forces

An object should be connected to another in the same class by a semantic

relationship.

Solution
The Connection Pattern satisfies these forces. Figure 5 shows the applications of such
a pattern for connecting flights, connecting spans, and connecting airports.

Consequences

A connecting association relationship is used to describe the connection

between two related objects in the same class.

This pattern describes a series of objects such that each of them has a
connection to some others.

This pattern may be used for any other type of relationship in a class; e.g.,
managers and employees.

Constraints defined on a class help to confirm the connection between related

objects

Some of the details of the connection are discussed later in other patterns.

2.6 Routing pattern

Context
A flight route represents a collection of connecting air links that can be used together
to form a span for the passenger to travel from start to termination using this flight.
Problem
How to describe a choice among a set of related objects?
Forces

Each Flight object has a route from the origin airport to the destination airport.
Between the origin and the destination, there may be several intermediate
stops. An airlink which links an airport (called preceding airport) to another
(called succeeding airport) without intermediate stops is called a basic airlink.
In a route, two basic airlinks are called connected if and only if the first
airlink ends at the preceding airport of the second airlink. Two basic air links
in different routes are called connected if and only if these two airlinks are
connected at one airport or the succeeding airport of the first airlink is
connected with the preceding airport of the second airlink by other means of
transportation. A route is a set of connected basic airlinks connecting all the
airports through which it passes.

All the basic connection airlinks are available for a passenger to choose as
part of a span in a path from source to destination of his trip.
9

Solution
A Path Pattern [7] can satisfy the forces. The class model for such a pattern is shown
in Figure 6(a) and its application in our reservation system is shown in Figure 6(b).

dependence of constraint
{connecting flights have
connecting schedule}

Flight
flight#: String
schedule: List<departure time,
arrival time, stop>

Path
origin: String
destination: String
1
basic

Route
origin: String
destination: String

1
subset

1..*

1..*

basic

subset

Airlink
airline_link#: String

Span

1..*

{connection between
different spans}

1..*

1..*

origin: String
destination: String

Airlink
{connection
between basic airline_link#: String
airlinks in a
route}

{connection of
airlinks between
different
routes}
{two connecting
airlinks?}

(b)

(a)

Figure 6: Class diagram for Path pattern and its application in the reservation system
Consequences

A span is a part of route of a flight, and the choice of a span is based on

several available connected airlinks in a flight route. For the convenience of
customers, we should list the airlinks of all the airlines. The customer's request
will be satisfied if there is any available connecting span, even when it
belongs to a different airline.

This pattern may be used for any other selection of a set of related objects.

Based on the pattern, connected basic airlinks in a route of a flight provide a

set of available spans. A passenger may select a subset of airlinks in a route to
form a span from its origin to destination. The trip can be extended by other
connecting spans from the destination of the preceding span. With all the
connected spans in different flight routes, a passenger may fulfill a series of
trips from source to destination.

Constraints defined on connecting flights and connecting spans need that the
Airlink provides connection for different airlinks. The constraints on
10

connecting flights are based on the connection between two airlinks in

different routes. The constraints on connecting spans are based on the
connection between different spans. Dependence of constraints is shown in
Figure 6(b).

Since Airlink is an association class for airports, it is better to define

connecting airlinks based on the effect of constraints propagated to Airport.
Two airlinks are connected if and only if their basic units (airports) satisfy the
connecting condition. There is no need to add another connection to the class
Airlink. Otherwise, it is difficult to keep consistency between these two kinds
of definition.

2.7 Role object pattern

Context
To support the descriptions for different airlinks, the airports are described as Origin,
Intermediate, and Destination. An airport usually plays several roles.

Problem
How to model role aspects of an object as separate role objects that are dynamically
attached to and removed from that object (core object).
Forces

An airport may have different roles for routes and spans at the same time. In a
route, an airport and its connected airlinks indicate the available connection
provided by a flight. In a span, an airport and its connected airlinks indicate
the selection of reservation by the passenger.

An airport may change its roles dynamically, that is, at runtime, rather than
fixing them statically at some moment.

A relationship between an airport and its roles is independent from each other
so that changes to a role do not affect airlinks that are not involved in that role.

Solution
The Role Object Pattern can satisfy these forces. A core object usually plays several roles and
the same role is likely to be played by different core objects. When a core object is currently
playing the requested role, it is in a role specific way and meets any request for that role.

11

Using the configuration in [1], Figure 7 shows the class model for such a pattern and its
application for class Airport in our reservation system.
Airport
name: String
city: String

AirportRole

core

roles

roleType: {route_t,
span_t}

0..*

Intermediate

Origin

Destination

arrival_time: Date
departure_time: Date
hotels: String

departure_time: Date
parking_lot: Integer

arrival_time: Date
nearby_hotel: String

Figure 7: Class diagram for Role Object pattern

Consequences

The interface between airports and its roles supports dynamic changes.

Roles can evolve easily and independently of each other. Extending the
component interfaces is very easy.

Role objects can be added and removed dynamically in a software implementation of

this model. A role object can be added and removed at runtime, simply by attaching it
to and detaching it from the core object.

Applications are better decoupled. By explicitly separating the component interface

from its roles, the coupling of applications based on different role extensions is
decreased.

After describing all these aspects, a composition of them for a reservation system is presented
in the next section.
shanghai

803 <M8:00pm, M11:30pm>

<F6:00am, F2:30pm>
858 <W3:00pm, W7:00pm>

New York (NY)

804 <F9:00pm, S6:30am>

3. Reservation pattern and itsLosdomain

analysis
Angeles (LAX)
Tokyo

368 <W4:30pm, W12:30pm>

Dallas (DAL)

Intent This pattern describes the placement of an order for a series of tickets.
Context
898 <M9:00am, M9:00am>

Hongkong
Figure 8 shows some
specific examples of the way of using such Miami
a system.
Customer
(MIA)
A wants to make a reservation in Dallas (DAL) on 8/29/00 (MM/DD/YY) for a
Customer A booked in Dallas, on 8/29/00.
: round-trip, Dallas Los Angeles 9/4/00.
Customer B booked in Shanghai, on 7/8/00.
: one-way, Shanghai Miami 9/6/00,
New York Los Angeles 9/11/00.

12

Customer B changed his reservation.

: one-way, Shanghai Dallas 9/6/00.
Customer B booked for his friend.
: one-way, Hongkong Dallas 9/4/00.

business round-trip to Los Angeles (LAX) next week. Customer B has a conference in
Los Angeles. Before being there, he wants to travel to several cities in the United
States. Starting from Shanghai, he plans to go to first to Miami (MIA). Then, he will
go along the east coast by car. It will take him several days until he arrives at New
York (NY). From NY, he continues the trip by plane and arrives at LAX before
9/12/00. He wants to make a reservation for such a trip. But a friend visiting in
Hongkong (HK) asks customer B to make a reservation for him and his family ( wife
and daughter ) to Dallas (from HK). Now he wants to change his reservation and
make another reservation for the friend and his family so that he can stay with his
friend at Dallas for two days. These examples include some particular cases of a more
general order problem for a series of tickets.

Figure 8: Some examples using the reservation system

Forces

The requested tickets and the relationships between them must be captured in
a precise way. Requests may be individual or group requests. A reservation
may change over time.

Since the pattern is well organized, interfacing with a external system, i.e., an
accounting system, is very easy but the access point is limited.

The pattern must describe a fundamental semantic connection. This means the
pattern must be simple enough to apply to a variety of related situations.
Solution

13

The classes contained in the model (see Figure 9) include Passenger,

TicketSeries, TicketUnit, TicketRoute, Flight, Span, Seat, Plane, Route, Airlink,
Airport, AirportRole, Origin, Intermediate, and Destination.
Passenger

book

id(/account#): String
creditInfo: String

TicketSeries

1..*

TicketUnit
association as class
implied relationship or dependence

ticket#: String

ticketseries#: String
bookdate: String
1..*
{available series tickets}

TicketRoute

s_connecting

type: {one-way, round-trip}

1..2
trip_source: String
trip_destination: String

f_connecting

1..*

Span
origin: String
destination: String

{connecting flights have

connecting schedule}

Flight
1..*

{connection between
different spans}

{available seat#}

Seat
seat#: String

flight#: String
schedule: List<departure time,
arrival time, stop>

1
1..*

1..*

Route
origin: String
destination: String

subset

basic
1..*

1
assigned_to

1..*

Plane
type: String
no#: String
seatCapacity: InfoList
classInfo: InfoList

{a plane has a
fixed number
of seats in
a class

Airport
name: String
city: String

1
a_connecting
roles

other_link
1..*

1
{connecting condition}
core

AirportRole
roleType: {route_t,
span_t}

1
1..*

Airlink

a_connected_by

{connection of
airlinks between
different
routes}

0..*

Figure 9: Class diagram

for theIntermediate
reservation system
Origin
Destination

{connection airline_link#: String

between basic
airlinks in a
{two connecting
route}
airlinks?}

departure_time: Date
parking_lot: Integer

arrival_time: Date
departure_time: Date
hotels: String

arrival_time: Date
nearby_hotel: String

Using such a system, customer A can select an available flight among all those
passing through the span from DAL to LAX, i.e., 803 < M 8: 00pm, M 11: 30pm;
F6 : 00am, F2 : 30pm >, and select another to come back, i.e., 368 < W4 : 30pm,
W12: 30pm >. Although the route of flight 803 covers the span from LAX to DAL
and he may select flight 803 for his ticket, he does not use such a flight because he
does not want to wait until Friday. He disconnects the relationship of ticket for the
back trip and resets it to an earlier flight (flight 368). He will get a series of tickets
with two sets of round-trip ticket units. The first one is for the trip from DAL to LAX
and the second one is for the trip back to DAL. Each ticket unit in a set represents a
span using a part of a route of the flight. For example, customer A uses the part of
route of flight 803 from DAL to LAX and that of flight 368 back to DAL. A trip in
any set can be extended by a ticket with a connecting span. The extension will be
discussed in the next example for customer B. Any airport in the trip may have
different roles for route and span. For example, DAL is an intermediate stop for the
14

route of flight 803 but it is also an origin airport for the span from DAL to LAX. To
check if there is an available seat in the requested class, the detail capacity and class
information of planes < B767, 131 > and < B737, 189 > which are assigned to flights
803 and 368 can be accessed by the collection of requested seats. If the requested seat
is not available and there is no more available seats in the plane, he may use another
flight. Finally, customer A will be satisfied by a seat in the plane. As shown in
Figure10, B17 in < B767, 131 > and C12 in < B737, 189 > are such seats he can book
Passenger

TicketSeries
book

customer_A

association as class
connecting (relationship)
implied relationship or dependence
object entity
disconnected relationship

<Dallas, 3310002,082900>

TicketRoute

TicketUnit

<one-way, DAL, LAX>

<round-trip, DAL, LAX>

#1
#3

#2

<one-way, LAX, DAL>

Span

Flight

<803, M8:00pm, M11:30pm>

<DAL, LAX>

<368, W4:30pm, W12:30pm>

F12

Route

{available seat#}

Seat

E10

contain

<NY, LAX; LAX, NY>

<LAX, MIA>

assigned_to

<B737, 189>
<B767, 131>

subset

Airlink

Plane

<No.234, DAL, NY>

<W 4:30pm>

<W 6:30pm>
<M 10:30pm>

<W 4:30pm>

<DAL, >

<No.3, DAL, LAX>

spanRole Origin

Origin

Airport
<LAX, >

<No.4, LAX, DAL>

<No.2, DAL, MIA>
<No.123, LAX, DAL>
<No.23, NY, DAL>

routeRole

< LAX, DAL>

<M 11:30pm>

Destination
<W6:30pm, W 7:00pm>
<M 10:00pm, M10:30pm>

Intermediate

<M 11:30pm>

Destination

Figure 10: Domain analysis of a reservation system for customer A (round-trip)

Using the same system, customer B can select a series of connecting spans for the one-way
trip from Shanghai to LAX based on all the basic airlinks supported by connecting flights. As
shown in Figure 11, among all the basic airlinks, he selects span < Shanghai,LAX> and its
connecting span < LAX, MIA > which are part of routes of flight 858 and its

connecting flight 368 to go to MIA. Flight 858 is connected by flight 368 at LAX
because the arrival of flight 858 at LAX is two hours earlier than the departure of
flight 368 in the same day. The trip by flight 858 is extended by flight 368 from LAX
to MIA. From MIA, the passenger will go to NY by car; that is, there is an other-link
relationship between MIA and NY. As the arrival time of NY is earlier than the

15

departure time of flight 803, the passenger may select the connecting span of flight
803 from NY to LAX after a trip from Shanghai to New York. The connection
condition and its satisfaction which is requested by the customer and supported by the
routes of flights are used to check the feasibility of spans for the trip. The availability
of the seat(s) in the plane assigned to the route of the used span is checked for the
reservation. If there is no available seat in the plane, the customer should select
another set of connecting spans to reach the destination of his trip. After the check,
customer B makes a reservation for the available series of tickets with three one-way
ticket units (see Figure 11).

Passenger

TicketSeries
book

customer_B

association as class
connecting (relationship)
implied relationship or dependence
object entity
disconnected relationship

<Shanghai, 2086032,070800>

TicketRoute

TicketUnit

<one-way,Shanghai, LAX>

#1
#2

#3

Span

Flight

<858, W3:00pm, W7:00pm>

<NY, LAX>
<Shanghai, DAL>

<803, M8:00pm, M11:30pm;

F6:00am, F2:30pm>

<368, W4:30pm, W12:30pm>

F12

Route

<NY,LAX; LAX, NY>

<Shanghai, DAL>

assigned_to

<DAL, MIA>

Seat

E10
C11
contain

<LAX, MIA>

<B737, 189>
<B767, 921>

<B747, 731>

Plane

subset

Airlink

Airport

<No.4, LAX, DAL>

<Shanghai, >

<No.2, DAL, MIA>

<No.123, LAX, DAL>
<No.174, Shanghai, LAX>
<No.5, LAX, DAL>

spanRole

<NY, >
<MIA, >

<No.23, NY, DAL>

<No.3, DAL, LAX>

<LAX, >

<DAL, >

Origin
<W 3:30pm>
<W 4:30pm>

<M 8:00pm>

<W6:00pm, W 6:30pm>
<M 10:00pm, M10:30pm>

Intermediate

<W 2:00pm>
<M 11:30pm>

<W12:00pm>

Destination

Figure 11: Domain analysis of a reservation from Shanghai to LAX for customer B

16

Passenger

TicketSeries
book

customer_B

association as class
connecting (relationship)
implied relationship or dependence
object entity
disconnected relationship
the change of the reservation

<Shanghai, 2086032,070800>

TicketRoute

TicketUnit

<one-way,Shanghai, LAX>

#1
#2

#3

Span

Flight

<858, W3:00pm, W7:00pm>

<NY, LAX>

<368, W4:30pm, W12:30pm>

<803, M8:00pm, M11:30pm;
F6:00am, F2:30pm>

<804, F9:00pm, S6:30pm>

F12

Route

<NY,LAX; LAX, NY>

<Shanghai, DAL>

assigned_to

<Shanghai, DAL>

E10

Seat

B16
contain

<LAX, MIA>

<B737, 109>
<B767, 921>

<B747, 731>

<No.534, Tokyo, LAX>

Airport

<No.4, LAX, DAL>

<Shanghai, >

<No.2, DAL, MIA>

<No.123, LAX, DAL>
<No.174, Shanghai, LAX>
<No.5, LAX, DAL>

spanRole

<No.29, HK, Tokyo>

Plane

subset

Airlink

<DAL, MIA>

<NY, >
<MIA, >

<No.23, NY, DAL>

<No.3, DAL, LAX>

<LAX, >

<DAL, >

Origin
<W 3:30pm>
<S 3:00am>

<M 8:00pm>

<M 10:00pm, M10:30am>

<W 2:00pm, W2:30pm>

Intermediate

<M 11:30pm>

Destination

<S 6:30am>
<W7:00pm>

Figure 12: Domain analysis of a changed reservation for customer B

After being asked by his friend from Hong Kong, customer B wants to change his
reservation so that he can stay at Dallas two days with his friend. He selects the
simplest span for him to go to DAL. Instead of using the connecting spans of flight
858 and flight 368, he selects the span directly to DAL from the basic airlinks in the
route of flight 858. After two days, he continues his trip to MIA using a connecting
span of connecting flight 804. It is advantageous here to keep most of the feasible
parts of the trip and change to any plan with the most benefit dynamically and easily.
In Figure 12, the customer only changes the connecting spans at DAL and chooses the
simplest span to reach DAL. The related connecting flights and the connecting spans
based on the basic airlinks of the routes which are already available in the system
provide an easy change (see in Figure 12).

17

Passenger

TicketSeries
book

friend of
customer_A

association as class
connecting (relationship)
implied relationship or dependence
object entity

<Shanghai, 2086033,070800>

TicketRoute

TicketUnit

<one-way,HK,DAL>

#1
#2

#3

Span

Flight
<898, M9:00am, M9:00am>

<HK, DAL>

Seat
B18

D18
C18

Route
assigned_to

<HK, DAL>

Plane

contain
<B747, 401>

subset

Airport

Airlink

<No.123, LAX, DAL>

<HK, >

<No.29, HK, Tokyo>

spanRole/routeRole

<LAX, >
<DAL, >

<Tokyo, >

<No.534, Tokyo, LAX>

Origin
<M 9:00am>

<M 7:00am, 7:30am>

<M 11:30am, 11:00am>

Intermediate

<M 9:30am>

Destination

Figure 13: Domain analysis of reservation for the friend and his family
For the friend and his family, customer B selects flight 898 and makes a reservation
for three seats in the same trip. As shown in Figure 13, there is a series of one-way
tickets for the friend. Each ticket unit is assigned to the flight 898 (from HK to DAL),
a seat of the plane, and the span based on the route of such a flight. Except for the
seat, all the ticket units share the same information of this trip. Duplicate copies of the
information for airports and flights are avoided in such a system. This simplifies the
process of finding the feasible spans and available seats for all in the family. It also
facilitates the management of the information for airports and flights.
The domain analysis of the reservation system is presented in Figures 10, 11,
12, and 13, based on the above examples. With the effect of constraints, all the tickets
described in this pattern are guaranteed to satisfy the customer's request. This pattern
also shows its effectiveness and flexibility to serve different orders with dynamic
changes.

18

4. Conclusions and discussion

The model generated satisfies the forces:

The pattern describes the request and satisfaction of ticket(s) for different
types of trip

The pattern can be used as a more abstract pattern. Using other types of product
instead of source and destination, the pattern can apply to any reservation system for
a series of products. The products may be different in different applications.

Documents for account service and other airport services are considered part
of the external systems and are not represented in the pattern.

The effect of other activities can be reflected through appropriate operations.

Considering the composition, analysis of functional aspects based on Use

Cases is used here to avoid overlapping of the composite system. The Role
Object pattern is used to support dynamic binding of composite functionality
and domain analysis is used to describe the system in a precise way and to
avoid a conceptual gap between related classes.

In order to make the pattern applicable to other cases, we have left out:

Details of the items, such as operations for each service.

Exceptions, e.g., unavailable ticket, delays, and flight cancellations.

Alarms.

Historical information.

Billing and payment policies, e.g., order cancellation and refunding.

Personal identification.

These aspects should be completed with additional patterns.

Our approach involves the use of object-oriented methods and Semantic Analysis
Patterns. By solving this type of problems using object-oriented methods we reap the
general benefits of this approach, i.e., reusability, extensibility, and conceptual
abstraction. It is recognized by researchers and practitioners that object-oriented
19

methods are superior to procedural approaches for handling complex systems. This
superiority extends to our approach. The general use of patterns is considered an
advance in object-oriented methods because patterns distill the knowledge and
experience of many developers and are highly reusable. Patterns also improve
software quality because they have been scrutinized by many. Analysis and design
patterns have improved productivity and quality in software development. Our
Semantic Analysis Patterns are larger than standard analysis patterns and have been
shown to ease the task of building conceptual models [3]. In this paper we have added
to those properties the ability to compose patterns to build complex models. While
experiments with actual projects is necessary to prove the practicality of this
approach, we can say that this methodology is a better way to build complex systems
than procedural programming or ad-hoc object-oriented methods. We have also
shown our approach to be convenient to improve practical approaches such as XP [6],
which is another proof of its possible value. There are other object-oriented
approaches based on patterns, e.g., a recent UML book discusses several approaches
[8], and we dont claim that our approach is better than any of these methods, this
would require a detailed and lengthy study. We do claim that our approach allows us
to build complex models in a convenient and error-free way.
It is clear that software for flight reservation defined according to the requirements of
Section 2 is used in many places. This software has been designed either by the
procedural approach (most likely) or by object-oriented methods (in the most recent
cases). However, our Internet search did not yield any complete examples, only trivial
portions in some textbooks. We cannot then compare our solution to other solutions to
this specific problem, but it was not our aim here to show a better solution to this
problem, the example was selected because it was complex enough to show the value
of our approach. Based on the discussion above, we would expect our solution to this
specific problem to be easier to develop, more flexible, and more reusable than most
solutions.

5. References
[1] D. Baumer, D. Riehle, W. Siberski, and M. Wulf, Role Object, Chapter 2 in
Pattern Languages of Program Design 4, Addison- Wesley, 2000.
Also in http://jerry.cs.uiuc.edu/~plop/plop97/Workshops.html#Q2
[2] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal, Patternoriented software architecture, Wiley 1996.
[3] E.B. Fernandez and X. Yuan, Semantic Analysis patterns, Procs. of 19th Int.
Conf. on Conceptual Modeling, ER2000, 183-195.

20

[4] E.B. Fernandez, X. Yuan, and S. Brey, Analysis Patterns for the Order and
Shipment of a Product, Procs. of Pattern Languages of Programs Conference,
PLoP 2000, http://jerry.cs.uiuc.edu/~plop/plop2k.
[5] E.B. Fernandez and X. Yuan, An Analysis Pattern for Reservation and Use of
Reusable Entities, Procs. of Pattern Languages of Programs Conference, PLoP99.
http:/ /st-www.cs.uiuc.edu/~plop/plop99
[6] E.B.Fernandez, "Building complex object-oriented systems with patterns and
XP, Procs. of XP Universe (International Conference on Extreme Programming),
Raleigh, NC, July 23-25, 2001.
[7] S. Shlaer and S. J. MelIor, An Object-Oriented Approach to Domain Analysis,
in Object Lifecycle: Modeling the World in States, Prentice Hall, Englewood Cliffs,
New Jersey, 1991.
[8] K. Siau and T. Halpin, Eds., Unified Modeling Language: Systems Analysis,
Design and Development Issues, IDEA Group Publishing, Hershey, PA, 2001.

21