Originally posted by Tomi Tuomainen:
Parag,
According to my assignment we could make that assumption. In real life this probably is not very likely pricing model, the total price is something else than the price of segments (if reserved as invidual flights). But if the pricing model is simple and requirements describe price per destination and nothing else, we should stick to that.
Tomi
Tomi,
Yeah..seemed that way too..now am throwing another assumption your way on similar lines...tell me what u feel abt it..I am assuming that the definition of a segment entails a single flight from Point A to Point B as long as its the same flight #. this is something which was discussed and seems correct enough. So, I guess if a "flight" has 2 segments, they would possibly be 2 different flight #s (hence, they are 2 segments and not 1). for example,
a "flight" from Point A to Point C, which stops at B.
So,
A --> B [one flight #] //Segment 1
B --> C [a different flight #] //Segment 2
Lets assume the customer adds these 2 segments to his one way itinerary. If we go by the 'Change Itinerary' use case, the custmer is allowed to select the segment to change and the system lets him do that.
here are 2 possible assumptions:
1. The entire itinerary is discarded and the customer starts all over again.
2. The selected segment is discarded and the customer selects another segment.
In case 1, its simple..we dont have to worry abt dependency of the 2nd segment to the 1st etc..in the 2nd there is a dependency as if the customer selects the 1st segment and changes it to go from A-->D instead of A-->B, we definitely make the 2nd segment invalid as the customer might no longer end up at B !
Now, should we go by 1 and make the assumption accordingly (makes life simple) or should we go by 2 and make provisions to make the dependencies stick together so that the integrity is maintained?
ur thoughts?
Parag