airline reservation system - model driven software engineering approach

Airline Reservation System

Mobius Incorporated

Who we are ?

• Mobius Incorporated• Mobius strip or band • Infinity• Limitless service

Roles And Responsibilities

COEN 6312

Name Role Organization/Position

Contact information

Onkar Kadam Managing and Monitoring/Controlling the project

Project Manager [email protected]

Mehran Khan Communicate with sponsors for requirement gathering & analysis and managing deliverables

Team leader [email protected]

Purvesh Managing the technical implementation processes such as designing, coding and maintenance

Engineer [email protected]

Saketh Responsible for managing quality analysis, Capital resources.


Yun Responsible for validation/Testing and maintenance. Once new features are added, does regression testing and ensures that the quality goals of the product are met.


mailto:[email protected]




Motivation

• Model Driven Software Development.• Universal Approach.• Platform Independent Approach.• Deliver a satisfactory product.

COEN 6312

Proceedings• Project Requirements - Onkar• Phase 1(Use Case Diagrams) - Onkar• Phase 2(Class Diagrams) - Saketh• Phase 3 (State Machine Diagrams) - Yun• Phase 4 (Miscellaneous)- Purvesh• Phase 5 (Demo)- Mehran• Conclusion.

Project Requirements

• Reliable Solution.• Real-time tracking.• Notifying respective parties• Airline agent : Booking/Update/Cancellation• Operational Manager: Crew/Flight

Management• User Friendly• Extensible

Initial Decisions

• Online.• Airline Agent : Not an employee.• Dedicated Interfaces for Airline Agent and

Operational Manager.• Authentication

Phase 1(Use Case Diagrams)

Use-case Diagram ?

• External view.• What happens?• Internal View – Domain.• Organizing Requirements.• Vocabulary of the domain from a user

perspective.• System Behavior.

Use-case Diagram 1

Use-case Diagram 2

Impact of use-case

• Helped in understanding the problem from users point of view.

• Foundation / Base• Test Cases• Graphical User Interface

Graphical user Interface

Domain Chart

Phase 2(Class Diagram)

Class diagram? • Class diagram for modeling the static structure of classes in the system• UML class diagram is a so-called "bridge" between software specification

at the user side and software realization at the developer side. • We requires strong guidelines for identification of class objects from the

problem domain and notational conventions for modeling of the class diagram for its further usage in system coding.

• The central analysis diagram of the object-oriented design• As the objects are found, they can be grouped by type and classified• classes are examined, filtered, and refined based on their responsibilities

to the system

Class Diagram(Continued)• Decisions on class diagram

Reservation system(passenger, seat, flight) Categorizing Flight Keep track of Delays Two Users

1. Airline agent

1. Booking flights

2. Updating Passenger Information

3. Cancelling bookings

2. Operation Manager

4. schedule a particular flight

5. update the schedule of a flight

6. assign a Plane and crew to a particular flight

1. Airline agent

• No two passengers should have the same passport number.• No two seats in a flight should be occupied by the same passenger• The same flight crew members cannot be assigned to two flights with the

same departure time• A flight must have at least 5 crews assigned to it.• Add a passenger to a flight only if he/she is not already booked

Airline agent (Continued)

Context : Passenger

Invariant : AllInstances forAll (p1, p2:person|p1< >p2 implies

p1.passportnumber< >p2.passportnumber)

2. Operation manager

Operation Manager (Continued)• Airline crews are only going to receive an alert if the operational manager

assigns them as crews in a flight. • The operational manager can only assign available crews to a flight. • No two Employee should have the same employee id. • The same flight crew members cannot be assigned to two flights with the

same departure time • A flight crew cannot be assigned more than 50 hours of work per week or

less than 30 hours per week. • A flight must have at least 5 crews assigned to it.

Context : Employee

Invariant : AlInstances forAll (e1, e2:Employee|e1< >e2 implies

e1.passportnumber< >e2.passportnumber)

Impact of Class Diagram Helped in understanding the user requirements and coming up with a

possible solution. Foundation for Phase 4 Relation to Model Driven Software Engineering Generating code from models

– Example: Generating code from domain model in EMF Reverse engineering of abstract models from detailed models or code

– Example: Generating class diagrams from Java code

Phase 3 (State Machine Diagrams)

State Diagram?

• State diagram for modeling the behavior of objects in the system

• Real-time behavior of each class that has significant dynamic behavior is modeled using a State diagram

• An object’s behavior is modeled in terms of what state it is in initially, and what state it transitions to when a particular event is received

• and model what actions an object performs with certain state

1. State diagram : Flight • After initialization, flight is at the

unscheduled state.

• When the flight takes off, it is going into the departed state.

• After landing on the destination airport, the flight object transmits to the landed state. Then the flight will be set into the expired flight lists.

• If the flight schedule is cancelled, the flight information will be destroyed soon.

2. State diagram : Plane• Four states: NotAssigned, Assigned,

InTransmit and Inmaintenance.

• After initialization, plane object is at the unassigned state.

• If the plane is assigned to some flight, it’s object should be set to the Assigned state.

• When plane takes off, it enters into the InTransit state.

• If the plane needs to be repaired, it goes to Inmaintenance state; After repairing, it goes into NotAssigned state again.

3. State diagram : Passenger

• After initialization, passenger object is at the Booked state.

• If the passenger cancels the flight, the object transmits to the cancelled state. Then the passenger’s information will be deleted soon.

• Check-in state means the flight will be take off soon, the passenger cannot cancel his/her flight.

• If the passenger is on the flight, its object is at the InFlight state. After landing on the destination airport, the passenger’s information will be kept on the expired passenger lists.

4. State diagram : Seat

• Two states: seat available or seat occupied. • This state diagram has no termination point.• When a ticket is booked, a seat of the corresponding flight

is assigned to the passenger, seat object transits to Occupied state.

• If a ticket is available or the passenger cancels the flight, the seat will be released. Its state becomes available.

Phase 4

Challenges

• The choice of models to create has a profound influence on how a problem is attacked and how a solution is shaped.

• Every model may be expressed at different levels of precision with their issues.

• The best models are connected to reality.• through a small set of nearly independent

models.

Support to course work

• Support for such as traditional process modeling.• Ability to customize the definition properties underlying UML

model elements.• Ability to capture requirements, associate them with model

elements which satisfy them, • and trace how requirements have been satisfied at all stages of

development.• Ability to create customized reports and documentation on your

designs, • Ability to generate and reverse code (i.e., C++, Java, etc) to

facilitate iterative analysis and design, for reuse of existing code or class libraries, and for documentation of code.

Development environments

• Sparx Systems Enterprise Architect• Eclipse EMF• Visual Paradigm• ScriptCase Tool

Development environments

Work Contribution

• Team members in our group were meeting on regular bases, everyone has contributed and put his best effort in the project.

• Drop box tool was used to organize files and to put everyone work and when updating files, we were tagging a new version number manually.

• Emails to communicate and share ideas were used sometimes.• Tasks were assigned to each team members and everyone start

to help others once he finish is part to finish faster.• The project was manageable however we needed to have more

time to finish Implementation(deliverable 5) tasks.

Work sharing

Demonstration of project

Conclusion

• We Implemented few classes and functionalities .

• Difficulties is finding apt tool for code generation.

Thank You