Originally posted by Matt Rea:
Yes, I including a Cart class in my class diagram. I also included the Cart in the component diagram where it was relevant. My class diagram was completely technology independant. There were a number of classes that appeared in my component diagrams such as session facades for one example.
[ June 22, 2005: Message edited by: Matt Rea ]
Originally posted by Jay Sam:
Well - I don�t think that step d is necessary at all. The user could be presented with the less costly list of
departure/returns right at step b ! What does the system know at step d, that it doesnt know at step b ?
in step b, the user has chosen departure and return. The system will now "keep" his choice "in mind" (or memory) and re-
turn a list of departure/returns matching the criteria mentioned in step c. Well the thing that disturbs me here, is, it
just specifies departure and return times. If the departure from Vienna is let�s say at 10 AM, and we find a less costly
flight at 10.30AM, but which lasts 5 hours longer (!!!), then the system will display it, according to those requirements.
Do you agree ?
how would you implement the "transfer" of the "change itinerary" use case to the "prepare itinerary" use case, in a
logical way (no technical explanation needed, just the logic).
Originally posted by mahesh manian:
sorry for the typo again.
each segment [leg] of the itinerary has *one* flight[def with defined take off and landing and a flight code]