Post-Condition for "Change Itinerary"

I don't understand the Post-Condition for "Change Itinerary". Why does the unpaid itinerary only contain the city, flight#,... of the departure flight and city, flight#,... of the return flight? What about the city of destination? What if I have a one-way itinerary only?

D.

Please look at the basic flow of the change itinerary again.

* Customer selects the SEGMENT to change.

Therefore, I believe if it is a one way itinerary, then you will be only changing that ONLY one segment.

Jeremy and David,

It's interesting to note that this deleted segment can be replaced by an entire itinerary, as the Prepare Itinerary Use Case in executed.

-- Dan

hi, Dan.

Thanks for this insight. However, I believe we can safely make the assumption that the search information will be automatically filled out by the change itinerary. As a result, only that segment will be preplaced and not by the entire itinerary.

This exam has a lot of questionable area and we have to make assumptions.

Suppose the flight path is A --> B --> C. A --> B has been replaced by A --> Z -->B, the new flight path is A --> Z --B --C. As long as there is no problemn with time departured from B --> C, I don't see any problem.

I totally agree with Vu.

Change Itinerary use case includes Prepare Itinerary use case. Change itinerary doesn't end until the included use case ends.(the two have same post conditions: a prepared Itinerary with identical words).

Regards
Alain

Originally posted by vu lee:
Suppose the flight path is A --> B --> C. A --> B has been replaced by A --> Z -->B, the new flight path is A --> Z --B --C. As long as there is no problemn with time departured from B --> C, I don't see any problem.

Hi Vu,

makes sense but what if the flight is A-->B-->C and the segment A-->B is replaced by the customer to X-->Y the itinerary would be X-->Y-->C but let's say there is no such thing as Y-->C ?!?
Should I make an assumption that such a case cannot occure since the underlying search algorithm (which is not part of the assigment) is smart enough to figure that out and only return possible combinations?

D.
[ July 11, 2005: Message edited by: David Follow ]

David,
The assignment states that a customer must select a segment to change. In your scenerio, it is not a segment;indeed, it is two segments A --> B and then B --> C.
If the customer selects A --> B segment, the destination city of the new itinerary must be B.

Originally posted by vu lee:
If the customer selects A --> B segment, the destination city of the new itinerary must be B.

Vu,

so is it correct to say that if the customer changes segment A-->B than he can change the departure city (A) but the destination city (B) must remain the same? Therefore he can change the segment A-->B to e.g. X-->B? So the itinerary becomes X-->B-->C?

D.

David,
That's right if an user picks the first segment. If the user pick the middle segment, two end points of that segment cannot be changed.

Vu,

can I assume that the searching algorithm is taking care of that or do I actually have to come up with an algorithm that handles that? I guess it is beyond the scope of the assignment, what do you think? I guess providing an iterface for the search component (algorithm) should be enough, isn't it?

D.

You're right, David. Let's focus on the abstract design and take the 'design by contract' approach

Originally posted by vu lee:
You're right, David. Let's focus on the abstract design and take the 'design by contract' approach

Vu,

do you show this "Search" as a class in your class diagram, or will you depict it as a component in your component diagram?

D.