An Object-oriented Analysis Model for Flight Reservations: A case study in composition of patterns

plumponionchipsSoftware and s/w Development

Nov 18, 2013 (3 years and 11 months ago)

91 views


1


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
reusab
le..

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 foun
d. 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 Pa
tterns
(SAPs) [3] emphasizes functional aspects of the application model as opposed to

2

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 patte
rn
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 co
mplex 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 n
eed 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 foc
uses 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 show
n 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 flig
ht 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 sev
eral flights that share the same origin and
destination airports.


3




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 ea
ch 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 on
e
-
way 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 pa
tterns 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.


4
























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 pa
ssenger 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.



















Figure 2: Sequence diagram for Order pattern


Passenger
TicketSeries
book
TicketRoute
TicketUnit
id(/account#):
String
creditInfo
: String
ticketseries
#: String
bookdate
: String
1
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
1..2
1..*
1..*
1..*
:Passenger
:
TicketSeries
:
TicketRoute
:Ticket
-
1
:Ticket
-
2

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

confirmed (Ticket
-
n)
show
-
price
book
book ticket (Ticket
-
1)
confirm (Ticket
-
1)
book ticket (Ticket
-
n)
confirm (Ticket
-
n)


confirm (
TicketSeries
)

5

Consequences



This p
attern 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 co
rporation. 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 discus
sed 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 assig
ned 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.


6
















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 i
n 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 co
nnecting 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?


TicketSeries
TicketUnit
Flight
Seat
Span
{available seat#}
ticketseries
#: String
bookdate
: String
origin: String
destination: String
ticket#: String
flight#: String
schedule: List<departure time,
arrival time, stop>
seat#: String
{connecting flights have
connecting schedule}
1..*
{available series tickets}
{connected spans}
Assignment Pattern
association as class
dependence of constraints

7

Forces



An entity has a certain number of similar uni
ts. 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) relat
ionship 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.













Figure 4: Class diagram for Col
lection 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.

Plane
Flight
Seat
assigned_to
{available seat#}
flight#: String
schedule: List<departure time,
arrival time, stop>
seat#: String
type: String
no#: String
seatCapacity
:
InfoList
classInfo
:
InfoList
{a plane has a
fixed number
of seats in
a class
1..*
1
*
{connecting flights have
connecting schedule}
dependence of constraints
Collection Pattern

8




Other parts of Plane and other information which are not related to reservat
ion 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 t
wo 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.














Figure 5: Class diagram for Co
nnection 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.


Airport
Flight
Span
origin: String
destination: String
flight#: String
schedule: List<departure time,
arrival time, stop>
name: String
city: String
{connecting condition}
1..*
1
1..*
1
other_link
a_connected_by
a_connecting
1..*
1
f_connecting
{connecting flights have
connecting schedule}
{connection between
different spans}
s_connecting
Connection Pattern
Connection Pattern
Connection Pattern

9

Consequences



A connecting association relationship is used to describe the connection
between two related objects in the same class.




This patter
n 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, th
ere 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 o
nly 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
conn
ected 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.


10


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).














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 select
ion 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 c
onnecting spans need that the
Airlink provides
connection
for different airlinks. The constraints on
Airlink
Route
Flight
Span
dependence of constraint
origin: String
destination: String
flight#: String
schedule: List<departure time,
arrival time, stop>
airline_link#: String
origin: String
destination: String
{two connecting
airlinks
?}
{connection
between basic
airlinks
in a
route}
{connection of
airlinks
between
different
routes}
1..*
1..*
1
1
subset
basic
1..*
1
{connecting flights have
connecting schedule}
{connection between
different spans}
Airlink
Path
airline_link#: String
origin: String
destination: String
1..*
1..*
1
1
subset
basic
(a)
(b)

11

connecting flights are based on the
connection
between two airlinks in
different routes. The constraints on connecting spans are based on the
connection
be
tween 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 dyna
mically
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 airpor
t 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

12

playing the requested role, it is in a role specific way and meets any request for that role.
Using the configuration in [1], Figure 7 shows the class model for such a pattern a
nd its
application for class Airport in our reservation system.















Figure 7: Class diagram for Role Object pattern


Consequences



The interface between airports and its roles supports dynamic changes.




Roles can evolve easily and independentl
y 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.



3.

Reservation pattern and its domain analysis


Intent

This pattern describes the placement of an order for a series of tickets.

Context

AirportRole
Airport
Origin
Intermediate
Destination
name: String
city: String
departure_time: Date
parking_lot: Integer
arrival_time: Date
departure_time: Date
hotels: String
arrival_time: Date
nearby_hotel: String
roleType
: {route_t,
span_t}
0..*
core
roles

13

Figure 8 shows some specific examples of the way of us
ing such a system. Customer
A
wants to make a reservation in Dallas (DAL) on 8/29/00 (MM/DD/YY) for a
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 i
n 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 b
efore
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 an
other 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.

shanghai
Tokyo
Hongkong
Los Angeles (LAX)
Dallas (DAL)
Miami (MIA)
New York (NY)
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.
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.
858 <W3:00pm, W7:00pm>
368 <W4:30pm, W12:30pm>
898 <M9:00am, M9:00am>
804 <F9:00pm, S6:30am>
803 <M8:00pm, M11:30pm>
<F6:00am, F2:30pm>

14

Sol
ution

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.




















Figure 9: Class d
iagram for the reservation system





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
: 00
pm, 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. T
he extension will be
AirportRole
Airlink
Airport
Route
Plane
Passenger
TicketSeries
book
TicketRoute
TicketUnit
Flight
Seat
Span
assigned_to
association as class
implied relationship or dependence
{available seat#}
Origin
Intermediate
Destination
id(/account#): String
creditInfo
: String
ticketseries
#: String
bookdate
: String
1
*
type: {one
-
way, round
-
trip}
trip_source: String
trip_destination: String
origin: String
destination: String
ticket#: String
flight#: String
schedule: List<departure time,
arrival time, stop>
seat#: String
type: String
no#: String
seatCapacity
:
InfoList
classInfo
:
InfoList
{a plane has a
fixed number
of seats in
a class
name: String
city: String
departure_time: Date
parking_lot: Integer
arrival_time: Date
departure_time: Date
hotels: String
arrival_time: Date
nearby_hotel: String
roleType
: {route_t,
span_t}
airline_link#: String
origin: String
destination: String
0..*
core
roles
{connecting condition}
1..*
1
1..*
1
other_link
a_connected_by
a_connecting
{two connecting
airlinks
?}
{connection
between basic
airlinks
in a
route}
{connection of
airlinks
between
different
routes}
1..*
1..*
1
1
subset
basic
1..*
1
1..*
1
*
1..*
1
f_connecting
1..*
{connecting flights have
connecting schedule}
1..2
1..*
1..*
{available series tickets}
{connection between
different spans}
s_connecting

15

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
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. I
f 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 s
eats he can book























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 ba
sic 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. Flig
ht 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
Origin
Destination
<W 6:30pm>
spanRole
<M 11:30pm>
<LAX, …>
<DAL, …>
<No.234, DAL, NY>
<No.123, LAX, DAL>
Airlink
Airport
Route
Plane
Passenger
TicketSeries
book
TicketRoute
<one
-
way, DAL, LAX>
customer_A
<Dallas, 3310002,082900>
TicketUnit
Flight
Seat
Span
#1
#2
#3
<NY, LAX; LAX, NY>
<B767, 131>
assigned_to
subset
E10
F12
contain
association as class
connecting (relationship)
implied relationship or dependence
object entity
disconnected relationship
<803, M8:00pm, M11:30pm>
<368, W4:30pm, W12:30pm>
<LAX, MIA>
<No.4, LAX, DAL>
<No.2, DAL, MIA>
<M 10:30pm>
<DAL, LAX>
< LAX, DAL>
<B737, 189>
<No.3, DAL, LAX>
<No.23, NY, DAL>
<W 4:30pm>
<one
-
way, LAX, DAL>
<round
-
trip, DAL, LAX>
{available seat#}
Origin
Intermediate
Destination
routeRole
<W6:30pm, W 7:00pm>
<M 10:00pm, M10:30pm>
<M 11:30pm>
<W 4:30pm>

16

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
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 Ne
w 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 t
he 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 seri
es of tickets with three one
-
way
ticket units (see Figure 11).



























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

Origin
Intermediate
Destination
<W 3:30pm>
spanRole
<W6:00pm, W 6:30pm>
<M 10:00pm, M10:30pm>
<W 2:00pm>
<M 11:30pm>
<Shanghai, …>
<LAX, …>
<DAL, …>
<No.174, Shanghai, LAX>
<No.5, LAX, DAL>
<No.123, LAX, DAL>
Airlink
Airport
Route
Plane
Passenger
TicketSeries
book
TicketRoute
<one
-
way,Shanghai, LAX>
customer_B
<Shanghai, 2086032,070800>
TicketUnit
Flight
Seat
Span
<368, W4:30pm, W12:30pm>
<Shanghai, DAL>
#1
#2
#3
<Shanghai, DAL>
<B747, 731>
assigned_to
C11
subset
E10
F12
contain
association as class
connecting (relationship)
implied relationship or dependence
object entity
disconnected relationship
<858, W3:00pm, W7:00pm>
<803, M8:00pm, M11:30pm;
F6:00am, F2:30pm>
<LAX, MIA>
<NY,LAX; LAX, NY>
<No.4, LAX, DAL>
<No.2, DAL, MIA>
<MIA, …>
<NY, …>
<W 4:30pm>
<M 8:00pm>
<DAL, MIA>
<NY, LAX>
<B737, 189>
<B767, 921>
<No.3, DAL, LAX>
<No.23, NY, DAL>
<W12:00pm>

17



























Figure 12: Domain analysis of a changed reservation for c
ustomer 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 fligh
t
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 feasib
le
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
span
s based on the basic airlinks of the routes which are already available in the
system provide an easy change (see in Figure 12).

Origin
Intermediate
Destination
<W 3:30pm>
spanRole
<M 10:00pm, M10:30am>
<W 2:00pm, W2:30pm>
<M 11:30pm>
<Shanghai, …>
<LAX, …>
<DAL, …>
<No.174, Shanghai, LAX>
<No.5, LAX, DAL>
<No.123, LAX, DAL>
Airlink
Airport
Route
Plane
Passenger
TicketSeries
book
TicketRoute
<one
-
way,Shanghai, LAX>
customer_B
<Shanghai, 2086032,070800>
TicketUnit
Flight
Seat
Span
<368, W4:30pm, W12:30pm>
<Shanghai, DAL>
#1
#2
#3
<Shanghai, DAL>
<B747, 731>
assigned_to
B16
subset
E10
F12
contain
association as class
connecting (relationship)
implied relationship or dependence
object entity
disconnected relationship
the change of the reservation
<858, W3:00pm, W7:00pm>
<803, M8:00pm, M11:30pm;
F6:00am, F2:30pm>
<804, F9:00pm, S6:30pm>
<LAX, MIA>
<NY,LAX; LAX, NY>
<No.4, LAX, DAL>
<No.2, DAL, MIA>
<No.29, HK, Tokyo>
<No.534, Tokyo, LAX>
<MIA, …>
<NY, …>
<S 3:00am>
<M 8:00pm>
<DAL, MIA>
<NY, LAX>
<B737, 109>
<B767, 921>
<No.3, DAL, LAX>
<No.23, NY, DAL>
<W7:00pm>
<S 6:30am>

18


























Figure 13: Domain analysis of reservation for the friend and his family


For the friend and his fam
ily, 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, a
nd 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 fi
nding 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 abo
ve 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.

Origin
Intermediate
Destination
<M 9:00am>
spanRole
/
routeRole
<M 7:00am, 7:30am>
<M 11:30am, 11:00am>
<M 9:30am>
<HK, …>
<LAX, …>
<Tokyo, …>
<DAL, …>
<No.29, HK, Tokyo>
<No.534, Tokyo, LAX>
<No.123, LAX, DAL>
Airlink
Airport
Route
Plane
Passenger
TicketSeries
book
TicketRoute
<one
-
way,HK,DAL>
friend of
customer_A
<Shanghai, 2086033,070800>
TicketUnit
Flight
Seat
Span
<898, M9:00am, M9:00am>
<HK, DAL>
#1
#2
#3
<HK, DAL>
<B747, 401>
assigned_to
C18
subset
D18
B18
contain
association as class
connecting (relationship)
implied relationship or dependence
object entity

19



4.

Conclusion
s 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 an
d 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. T
he 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 oth
er 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 a
nd 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 w
e reap the
general benefits of this approach, i.e., reusability, extensibility, and conceptual
abstraction. It is recognized by researchers and practitioners that object
-
oriented

20

methods are superior to procedural approaches for handling complex systems. T
his
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 qualit
y 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 bui
lding 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 metho
dology 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. Th
ere are other object
-
oriented
approaches based on patterns, e.g., a recent UML book discusses several approaches
[8], and we don’t claim that our approach is better than any of these methods, this
would require a detailed and lengthy study. We do claim tha
t 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
t
o 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
sp
ecific 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.

Als
o in http://jerry.cs.uiuc.edu/~plop/plop97/Workshops.html#Q2


[2] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal,
Pattern
-
oriented software architecture,
Wiley 1996.


[3] E.B. Fernandez and X. Yuan, “Semantic Analysis patterns”,
Procs.

of 19
th

Int.
Conf. on Conceptual Modeling, ER2000
, 183
-
195.




21

[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,
PLoP’99.

http:/ /st
-
www.cs.uiuc.edu/~plop/plop99


[6] E.B.Fernandez, "Building c
omplex 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 Li
fecycle: 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.