1. Airline Reservation System
Mobius Incorporated

2. Who we are ?
• Mobius Incorporated
• Mobius strip or band
• Infinity
• Limitless service

3. Roles And Responsibilities
COEN 6312
Name Role Organization/
Position
Contact information
Onkar Kadam Managing and Monitoring/Controlling the
project
Project Manager onkar_ka@mobius.com
Mehran Khan Communicate with sponsors for
requirement gathering & analysis and
managing deliverables
Team leader mehran_re@mobius.com
Purvesh Managing the technical implementation
processes such as designing, coding and
maintenance
Engineer Purvesh_p@mobius.com
Saketh Responsible for managing quality analysis,
Capital resources.
Engineer Saketh_rd@mobius.com
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.
Engineer Yun_wa@mobius.com

4. Motivation
• Model Driven Software Development.
• Universal Approach.
• Platform Independent Approach.
• Deliver a satisfactory product.
COEN 6312

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

6. Project Requirements
• Reliable Solution.
• Real-time tracking.
• Notifying respective parties
• Airline agent : Booking/Update/Cancellation
• Operational Manager: Crew/Flight
Management
• User Friendly
• Extensible

7. Initial Decisions
• Online.
• Airline Agent : Not an employee.
• Dedicated Interfaces for Airline Agent and
Operational Manager.
• Authentication

8. Phase 1(Use Case Diagrams)

9. Use-case Diagram ?
• External view.
• What happens?
• Internal View – Domain.
• Organizing Requirements.
• Vocabulary of the domain from a user
perspective.
• System Behavior.

10. Use-case Diagram 1

11. Use-case Diagram 2

12. Impact of use-case
• Helped in understanding the problem from
users point of view.
• Foundation / Base
• Test Cases
• Graphical User Interface

13. Graphical user Interface

14. Domain Chart

15. Phase 2(Class Diagram)

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

18. 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
1. schedule a particular flight
2. update the schedule of a flight
3. assign a Plane and crew to a particular flight

19. 1. Airline agent

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

21. 2. Operation manager

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

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

24. Phase 3 (State Machine
Diagrams)

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

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

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

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

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

30. Phase 4

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

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

33. Development environments
• Sparx Systems Enterprise Architect
• Eclipse EMF
• Visual Paradigm
• ScriptCase Tool

34. Development environments

35. Development environments

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

37. Work sharing

38. Work sharing

39. Demonstration of project

40. Conclusion
• We Implemented few classes and
functionalities .
• Difficulties is finding apt tool for code
generation.

41. Q&A

42. Thank You