Project on Airline Reservation System

Agenda

Introduction
Project Overview
System Analysis
Software Requirement
OO Approach
Design Approach
Requirements Listing
Next Steps
Q&A
Introduction
 ARS is part of Passenger Service System
(application support direct contact with
passenger)
 Inventory Management – maintain flight
details
 Manual Vs Technical System
 Model – View – Controller Design

08/06/19 2
Manual Vs Technical System
 Manual: Time consuming & lazy, more error
prone
 Technical System:
 Faster System
 Accuracy
 Reliability
 Informative
 Reservations and cancellations from any
where to any place

08/06/19 3
Model - View - Controller
 Model: Application Object
 View: screen presentation
 Controller: Control the user interface update as per
the user input

08/06/19 4
Project Overview
 Objective is to Design and develop an
Airline Reservation System
 Implement ARS as standalone system
 Database design as data storage
 Extensible system for future enhancement
& maintenance
 Object oriented approach

08/06/19 5
System Analysis
 Block Diagram

Response
User Interface Request
ARS Reports
(Customer)

Process Customer
Data Storage & Request
Access
Booking
Database Processing

08/06/19 6
Software Requirement
 Language: C++ (Visual Studio)
 Store Information: File or Database (Oracle/
IIS…)
 User Interface: MFC
 Platform: Windows
 Design diagram: Rational Rose

08/06/19 7
OO Approach: Fundamentals
 Procedural Vs Object Oriented Approach
 Why use OO Approach
 OO Overview
 Object Oriented Principle

08/06/19 8
Procedural Approach
APPLICATION

Module 1 Module 2 …….. Module N

Program 1 Program 2 ……… Program N

Function 1 Function 2 ……… Function N

 Developing an application using the procedural approach would involve

 Identification of modules

 Programs inside each module

 Every program would contain several functions and data

 The data would be the information necessary for the program and its

functions

08/06/19 9
OO Approach
 An Object oriented approach  An object is a thing in a computer
views systems and programs as system that is capable of
a collection of interacting responding to messages.
OBJECTS.  An object has to be created from a
class so that it can be used
OBJECT

Do this
OBJECT OBJECT OBJECT
Do this OBJECT
Do this
OBJECT

 In the procedural approach, a

program responds to messages
 The procedural approach views
when its functions are invoked.
systems and programs as a
collection of interacting  By simply including the file, the
FUNCTIONS functions can be invoked and
invocation requires nothing else

08/06/19 10
Procedural vs. Object-Oriented Programming
 The unit in procedural programming is function, and unit
in object-oriented programming is class
 Procedural programming concentrates on creating
functions, while object-oriented programming starts from
isolating the classes, and then look for the methods inside
them.
 Procedural programming separates the data of the
program from the operations that manipulate the data,
while object-oriented programming focus on both of them

figure1: procedural figure2: object-oriented

08/06/19 11
Why choose the Object Oriented approach?
 The OO approach
 Deals with classes as the building blocks
Project ProjLead
 Allows Real World Modeling * *
 The idea of OOP is to try to approach * *

programming in a more natural way by grouping

ProjMgr
all the code that belongs to a particular object—
such as an account or a customer — together 1 1

 Raise the level of abstraction

 Applications can be implemented in the
Employee
same terms in which they are described by
users
 Easier to find nouns and construct a system Manager Salesperson
centered around the nouns than actions in 1 *
isolation
 Easier to visualize an encapsulated representation of data and responsibilities of entities
present in the domain
 The modern methodologies recommend the object-oriented approach even for
applications developed in C or Cobol

08/06/19 12
Overview of Object Orientation
• Object orientation is a technique for system modeling,
Object oriented analysis and design, or OOAD, attempts to
describe a system as it exists in real life.
• The system is modeled as a number of related objects that
interact. Any system needs objects to do work. It “asks” its
objects to do its work, just as you might ask objects in an
online store to deliver goods to you and charge the cost to
your credit card.
• All objects have attributes (characteristics), this is
sometimes referred to as state.
• They also have operations (or methods), this is sometimes
referred to as behavior.

08/06/19 13
About Object

08/06/19 14
About Class

08/06/19 15
08/06/19 16
Object-oriented Principle –
Encapsulation
 Encapsulation is the mechanism that binds
together the code and the data it manipulates, and
keeps both safe from outside interference and
misuse.

Public variables and methods A Class

Private variables
and methods
Public variables is not recommended
08/06/19 17
Object-oriented Principle -
Inheritance
 Inheritance is the process by which one object
acquires the properties of another object. By use
of inheritance, an object need only define all of its
characteristics that make it unique within its class,
it can inherit its general attributes from its parent.

Account

Checking Mortgage Loan

08/06/19 18
Design Overview
 Use Case overview
 System Functionality

08/06/19 19
Use Case Overview
 a view of a system that emphasizes the
behavior as it appears to outside users.
 A use case model partitions system
functionality into transactions (‘use cases’)
that are meaningful to users (‘actors’).

08/06/19 20
Use Case Modeling: Core Elements
Construct Description Syntax
use case A sequence of actions, including
variants, that a system (or other
entity) can perform, interacting with U seC aseN am e

actors of the system.

actor A coherent set of roles that users
of use cases play when interacting
with these use cases.
A c to rN a m e

system Represents the boundary between

boundary the physical system and the actors
who interact with the physical
system.

08/06/19 21
Use Case example
Telephone Catalog

Check
status

Place Salesperson
order

F ill o r d e r s

Customer Shipping Clerk

Establish
credit

Supervisor

08/06/19 22
Use case diagram for ARS
(Customer view)
 Customer Use
Case Diagram

08/06/19 23
System Functionality
 User Functionality
 Administrator Functionality

08/06/19 24
User Functionality
 Enquiry
 Reservation
 Report
 Edit
 Cancellation
 Concession

08/06/19 25
Administrator Functionality
 Add/Delete/Modify customer information
 Add/Delete/Modify flight information
 List all passenger/flight details
 Cancellations of Reservation

08/06/19 26
Requirements Listing
 Enquiry
 Reservation
 Cancellation
 Report
 Concession
 Fare detail & payment
 List of all passenger
 List of all flights
 List of passenger(date wise)
 List of passenger(flight wise)

08/06/19 27
Next Steps
 Modules Identification
 Data type identification
 Interface definition
 Class identification
 Identify design pattern
 Interaction between object and database
 Table structure
 User Interface

08/06/19 28
 Q&A

Thank You!

08/06/19 29