I was confused about the discussions on segment and flight on this site. Than I looked at the real world:
188.8.131.52 User-User Instance Connections
A Flight object represents only a flight segment, that is, the flight from departure at one airport to arrival at the next airport. However, it is of interest sometimes to examine a sequence of flight segments. Instance connections between pairs of Flight objects can be created to define, for example, a flight itinerary or an airframe itinerary. A flight itinerary describes a "continuing flight" with stops en route (e.g., a flight known to passengers by a particular flight number) and can be used to study accumulated flight delay. An airframe itinerary describes the use of a particular aircraft ("airframe") during flight segments and can be used to track and schedule maintenance for that aircraft.
Says it all, or not? ========== I think the itinerary in this case refers to 'airframe itinerary'. (because of 1-1 relation between flight and itinerary) what do you think?
I believe flight, segment, etc. are all jargon and their usage is different around the world....
For instance I'm based in London and when I fly somewhere I expect to get on a plane and arrive at my destination... I might change flights but not many times...
However, I remember a trip to the USA... I flew to Boston and needed to get to Owego... The flight stopped off along the way... i.e. I stayed on whilst we picked up/dropped off passengers... more like a bus...
I don't think it matters as long as you are consistent. Define the terms yourself and stick with your definitions.
Joined: Jan 09, 2005
With respect to the segment flight issue (1-1, 1-n)
My considerations: You want to book a flight from A->B for a specific time.
The system might respond as follows: 1. FlightAAA: A->B (this is one segment, no problem with BDOM)
2. FlightAAA: A->C->B (or even worse: A->C->D->B) These are two segments (right?) But...How many flights is this? A: If this is 1 flight then the flight object will become a mess. (how do you store the city-stop-over, arrival time,..,..,, in one flight-object). And the the BDOM will break... B: if A->B->C is two flights, you will have no problems with the DBOM
3. System responds with FligtXXX: A->C and flightYYY: C->B (two flights, two segments, no problem);
I am still confused on this never-ending debatable issue of Segment, Leg and Flight. But here is what my current understanding is:
If a customer is preparing an itinerary for a roundtrip trip from Boston to Atlanta then:
(a) There are two segments: 1. Boston to Atlanta and 2. Atlanta to Boston.
(b) Each of these segments can have one or more Legs and each leg will have a unique flight associated with it.
(c) If Boston to Atlanta requires a flight stopover for passenger pick up/drop off, with no change in the Flight # etc then it is one leg. This means that there is a direct flight between Boston to Atlanta, which has one stopover.
(d) If Boston to Atlanta requires a change of Flight (and hence flight #) at New York then it has two legs. 1. Boston to New York is one leg and 2. New York to Atlanta is another leg.
(e) If Boston to Atlanta requires no stopover then again there is one leg, This means that there is a direct flight between Boston to Atlanta, which has no stopover. It is a non-stop flight.
Using this understanding helps me in several ways:
Change Itinerary use case allows the customer to - select and change a segment (from an existing itinerary) by deleting it. It says the selected segment is deleted and prepare itinerary use case is executed.
In my case if customer changes the Boston to New York segment then all the legs associated with it also get deleted. This way I do not have to worry about dangling objects or extra validations.
Similarly pricing an itinerary is equal to total of all the segments, which again is equal to the total of all the legs.
Let me know what you feel about this
Joined: Jan 09, 2005
Yes, I think this is probably the desscription that matches the BDOM best. Without changing the BDOm. Thanks. J
Agree that Segment is either a leg or outbound/return flight, but to conform to the BDM, Itinerary-Segment should be a 1-n relationship and Flight-Segment should be 1-1.
I think that Flight and Segment have different uses in EJB. Flight looks as though it could be an entity bean holding the flight details (flight ID, departure/arrival time & airport, plane type).
A Segment seems to be what the customer buys, i.e. it is created by a session bean when reserving the flight, but unlike Flight it is not an entity bean and so can be deleted without affecting the database, if the customer decides to abandon the reservation.
An Itinerary might be seen as several Segments that are bought together, or there could be a rule saying that Segments are linked if they are consecutive (one arrives at airport A, the next leaves from airport A within a given time). I don't think it matters so long as you state your assumptions.
I've come to a similar conclusion to your one. It's good to hear the traffic control people think so too!
The bit I've been thinking about is how the system searches for routes - obviously it can easily search for direct flights ... and you could implement logic to get it to search for linking flights that leave within x many hours ... but you don't want it to offer customers the option of flying from New York to Orlando via Seattle.
So I am thinking of adding a couple of classes which allow the company to define valid routes. So from my example, they might say that the only valid routes for NY-Orlando are NY-Orlando and NY-Washington-Orlando.
The question I have regarding how the system searches for routes is this: Would accessing the module(s) containing the valid legs for trips between two places really be the responsibility of this application? Or, is there already a pre-determined set of flights that are available for a trip between two particular places? That is, is someone ELSE in charge of what flights actually exist in the database for a given trip between 2 places at a given time?
For what it's worth, I have a friend who is a pilot for Delta. From what I understand, Flight Numbers (associated with a Flight) are assigned by an outside entity for all commercial flight. A Flight Number normally correlates with a particular departure and destination city at a particular time of day. So, for instance, flight 337 may depart at 9:05am on Mon, Wed, and Thu of any given week for an Airline. Consequently, a flight number can be executed with multiple types of equipment.
So if an itinerary contains a layover, it would contain multiple flight numbers, and it would be associated with a particular date and time.
From what i can tell, a real-world flight system is beyond the scope of this project; it's probably best to define it one way or the other and stick to it.