Segment - BDO question

[Riyadh Ishmail]

Hi,

Im working on part 2 and must say the Domain model has left me very confused!!

I see an itinerary as having a maximum of 2 segments(Outward and inward). Each segment could possible have multiple legs, ie if the outward segment is London to NY then the legs(or hops depending on which terminogy you use) could be LONdon->Amsterdam, Amsterdam->Ny. Each of these legs would be associated with a single flight.

The questions that come to my mind are: why did SUN model the itinerary cardinality as 1:M when it should be 1..1,2?? Am I allowed to introduce this notion of a 'leg' that would exist between segment and flight?

Also I dont agree with the 1:1 bidirectional relationship between flight and segment as a single flight can exist on multiple segments. It could be be in the inward segment of one customer yet at the same time be on the outward segment of another customer. To what extend can we modify the relationships (cardinality and direction)?

Can I have some thoughts on this pls.

[Andrew Monkhouse]

Hi,

Originally posted by Riyadh Ishmail:

I see an itinerary as having a maximum of 2 segments(Outward and inward).

What about around-the-world trips? E.g. My mother did a trip last year that was Australia -> Ireland -> USA -> Australia. Far more complicated itineraries are possible as well.

Sorry for not commenting on the other questions - I would have to look at the instructions again to see how everything works within the requirements.

Please be aware that we do not allow discussions on possible solutions (see the JavaRanch SCEA FAQ for more information). Your question on whether you can modify supplied relationships comes dangerously close to breaking this rule.

Regards, Andrew

[David Brossard]

Hi,

Looking more closely at the Business Domain Model, I too felt confused. At first I couldn't quite see the benefit of having a segment on top of a flight. I think I might have found a reason (although not good).

In general, it all boils down to what one calls an itinerary and how you search for it. Typically websites will let you do either a one-way, a roundtrip, or a multi hop type of trip. That said, it's nothing that cannot be expressed in terms of flights.

My general assumption is that it can probably be modelled both ways. The 'business analyst' probably felt he needed a segment object there so we might as well try to figure out its use. Note that nothing prevents you from modifying the BDM although from what I read you're better off not changing it.

In addition to the segment / flight issue, the use case texts use the flight word very lightly which only adds to the confusion.

[David Brossard]

Getting back to the round-the-world option mentioned, this is in fact just a long trip. Actually, it all depends on our way to search for flights. We can search for JFK - LAX and the system replies with an option that contains a stop over or we can willingly request a multi city trip because it's our intent.
So long as you justify what you do / decide, there's little chance you'll go wrong.

[Ådne Brunborg]

I percievced the domain model as incomplete - remember, it is just the business analyst's version. It describes one view of the system.

You say you disagree with the bidirectional relationship between flight and segment. But where does it state that it is bidirectional? An undirected association is either bidirectional or undecided. And, seeing how ALL relationships are undirected, I would hazard a guess that they are all undecided. (Besides, I wouldn't trust a business analyst to come up with a correct domain model anyway )

When analyzing a business domain model, ask youself these questions:

does it include all the required domain objects?

are all the defined domain objects required?

are the relationships correct? are they necessary? are some missing?

You are the architect here. You can change anything on the model, if you feel justified. I changed, removed and added stuff. And I passed.

You could define a segment as having only two possible values, "in" and "out". You could introduce the concept of a leg, and saying that one segment has 1..n legs, and one leg has one flight. That would change the domain model to be more consistent with your understanding of the business, but it would also introduce one more domain object to the model, thereby increasing the complexity of the system.

Your "segment" domain object is little more than a boolean, stating "true" and "false". Maybe you could move it to the Itinerary and/or Leg domain objects, as a property of these?

Moving it to the Itinerary - this would state wether or not the journey is a one-way or a roundtrip. Does this add value? Not much, no.

Moving it to the Leg - you could very well have a property stating wether or not this segment is part of the "out" or "in" segment (your definition). This could be said to add some value, enabling you to lose the Segment domain object entirely, simplifying the model. But do you really need that information to be stated explicit? Maybe. Up to you.

So, if you do this, you have Itinerary-Leg-Flight. Apart from Segment being changed to Leg, identical with the business analyst's model.

Now, the Leg-Flight relationship as undirected 1:1. One Leg has one and only one Flight, that is fine. But, how many Legs does one Flight have? Navigating the direction Flight-Leg-Itinerary-Customer, how many customers can be on one Flight?
[ January 25, 2008: Message edited by: �dne Brunborg ]

[Kailas Lovlekar]

I would go with Adne on this. Looked for business definition of flight segment and it is used synonymously with flight leg. :roll:

[Chris Hurst]

Having worked for a large airline ;-) ..

Looking more closely at the Business Domain Model, I too felt confused. At first I couldn't quite see the benefit of having a segment on top of a flight. I think I might have found a reason (although not good).

We needed the distinction of segements for a range of subtle reasons including having an effective break in an itinerary (i.e. open jaw'ed) where one segment might be driven say. There were other reasons but I won't bore ... basically in the real world we did need that distinction .. apologies if that doesn't help ;-)