Airline reservation System UML question - where do these methods belong?

Question

I am preparing for Software Engineering interviews and figured out its good to get a sense of Object Oriented Design for my interviews. In all the examples of UML diagrams I looked at, I am having trouble figuring out where the methods belong. For example, the following is one of the UML diagrams from a Object Oriented Design course for a Airline Reservation System.

The main issue I have with this diagram are things like:

1. Flight class containing addFlightSchedule() method
2. Airport class containing getFlights() method etc.

Having done some work in this area, I always have a service class (like FlightScheduler class) that has addFlightSchedule() method and the Flight object is merely the one that contain attributes / methods applicable for a flight. So, is it right to design classes in that way during the interview ? Is there a reason why all online UML diagrams have service (operation) methods as part of the class itself ?

Answer 1

This is a domain model that tells something about the domain logic. It's not an implementation model of how the system should work:

1. The flight

In this model, the fight represents an airline route between two airports. And flight companies like train companies like regularity. Therefore the same route (flight) can be operated on a periodic schedule (here on one or several days of a week. Alternatively, it can be a charter flight operated only on specific dates, and therefore the flight can have none, one or more custom dates.

In such a model it is therefore logic to find addSchedule() in the fight, because this allows the flight to be described more in details. So it's definitively part of the expected flight behaviors. If any other class would do it, you'd create a dependency and a coupling to a specific implementation.

The only suprising thing here, is that CustomeSchedule and WeekSchedule are not specializations of a FlightSchedule.

2. THe airport

It is a clear role of an airport to know what planes are supposed to arrive and to depart from the airport and when. In every airport I can consult the list of expected arrivals and departures, with some infos about the flight.

And this is what getFilghts() is about: it's up to the aiport to deliver this information to other classes that only know the airport. If this model would not provide this airport method, every passenger would have to know about all the planes in all the world and findout the planes departing from the airport. This would break encapsulation, because the apassenger would have to know way too much details about the world.

THis being said, in real world, you'd expect this method to take a specific data as a paramter: again, it's not up to to filter the flights and find the one suitable for a given date.

Principle of least knowledge

This model aims to encapsulate the objects sufficiently, so that each object does not have to know how to relate all the others.

It tires to comply with the principle of the least knowledge, so that every class has to know as few classes as necessary. In perticular, passengers know about airport and about planes. THey do not in principle have to know about how schedules work.

This model is clearly a simplification and it is also imperfect. It's for example not clear how instances of a flight are created. But perhaps your book addresses this question and the different alternatives in a dedicated chapter ;-)