Airline business (Business area models:)

Business area models:  Airline business

Here is now my second business area abstract domain model. My second target is Route Airline business. I have been working in Finnair about ten years, so I know the business and the model by myself very well.

The target scope have been narrowed a bit from general airline. This model concentrates on a typical flag carrier base operation: route flights. All these transportation core models contains a pattern; a pair of route design and implementation aspects:  Route, RouteFlight classes for design and Flight for real event.

The largest business cycle – or pulse- is a period or a season like spring, summer, autumn.   These periods are planned and coordinated as one unit. So my example is Finnair and its route can be for example Helsinki – London. When this is decided then the airline has to decide the weekly operating days and the plain type out of the fleet. When this is done then the airline have to negotiate the gate time slots. When this is done the plan for a periods route operation is ready.

The models class RouteFlight is on description object of a single repeating flight. The real flight event can then be generated for a given period from these objects.

The basic collaboration are very straight forward. Here is one of those: buying a ticket and reserving a seat:

These diagrams can be found in StartUML form at: RouteFlightCompany.uml

Just upload and open with StarUML.


5 Responses

  1. I have developed and taught many variants of airline systems over the years, including a simple one in my book (see )

    I like yours, but there are two issues that I would like clarification about:

    1. What exactly is a FlightVersion? Your instances of your Flight class are what actually fly and on what passengers book. So what are these FlightVersions that Flights have many of.

    2. On the other hand you are missing the concept of the leg (the simple example in my book is too). In many airlines, a flight stops at several airports along the way, with passengers getting on and off.

    3. I don’t see the FlightNumber anywhere

    4. I don’t like the fact that you have arrival and departure information redundantly connected with three classes at different levels of abstraction.

    • Here are my answers to your good comments Timothy.

      To start with I have worked in IT-department of Finnair for 10 years (1988-1998).

      1) FlightVersion is the used plane body configuration used in the flight. This can change from leg to leg. I am also very sorry that the cardinalities in the association to flight have turned up side down! So the right cardinality is of course one version / flight.

      2) My flight is actually a leg ( that you can actually read from airport association) The thing that you call flight is actually in my model a route. Route class should of course have flightNumber attribute and it is missing.
      Your “flight” is in my model Route Class associated with leg event objects from class Flight.

      3) The start and end times appears twice because the first scheduled start and end are in is a design object (Coad stereotype Decription) from a class RouteFlight. This object is created in the route design phase and this object will create the “real” flight object and set these time accordingly. So it is not question of the same attributes on different abstract levels but the same abstract level but in consecutive time slots on the time line. That is why they are required twice. They actually have different content and meaning.

      I will correct the diagram class diagram as soon as I’ll return from my trip (to Madrid where I happen to visit now)

    • Well now the corrections are done in the class diagram.

      -jukka t

  2. Hey Jukka,
    I like the model – it’s clear and seems to cover a big chunk of the business domain. I’m interested in how you see the business concepts of “booking” and “boarding pass” fit into this model – are they analogous to “sales instrument” and “participation”?


    • Hi
      About your questions. First booking or reservation can of course be seen as an own event, but it is ALWAYS important to keep the number of classes as low as possible. So booking actually is a state in the life cycle of participation. So just adding a state attribute solves the who life cycle in the model. Well then the ticket. Earlier when we really had some importance in the physical printed ticket one could imagine of a ticket class in the model, but with e-tickets this so called “ticket” is just a conformation of a reservation and thus the same state attribute with value conformed will easily fill that need.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: