Contradiction in Prepare Itinerary post-condition

[David Follow]

Hi all,

in the last paragraph of the basic flow of Prepare Itinerary it says
"Systems sends the priced itinerary to Pay for Itierary Use Case"

In the Pay for Itinerary Use Case the user pays the for itinerary via TransMaster for instance. So in my understanding the itinerary has been paid for since the post-condition of pay for itinerary is a paid customer itinerary.

However, the post-condition of Prepare Itinerary is an unpaid itinerary

Further, in the Use Case Diagram Customer has a connection with "Pay for Itinerary" although "Pay of Itinerary" is called from "Prepare Itinerary". Why isn't this an <<include>>? I think the Customer doesn't call "Pay for Itinerary" directly.

Can anybody clearify this contradiction?

Thanks, D.
[ June 28, 2006: Message edited by: David Follow ]

[Raj Nerurkar]

David,

Actually I see the confusion you have. Its a valid confusion when you analyze the use cases and the use case model. However I think we need to make certain logical assumptions based on our experience.

This is what I have assumed.
1. Prepare Itinerary does not include Pay for Itinerary and therefore the Post Condition of Prepare Itinerary now becomes valid with this assumption.

2. Since Prepare Itinerary does not include Pay for Itinerary, the use case model become valid when a direct connection is shown from the customer to the Pay for Itinerary use case since the customer pays for itinerary once it is confirmed which is what I have assumed as the outcome of Prepare Itinerary.


With few such assumptions, everything starts falling in place .
Regards
Raj

[Samuel Pessorrusso]

Ok, but what about the Price itinerary precondition (user logged in) ? That is not according to the Prepare Itinerary Use Case (user needs to be logged in just before confirming the itinerary).

[David Follow]

Raj,

I understand you strategy of making assumptions, but isnt that changing the requirement which you are not supposed to do!?

D.

[Santiago Urrizola]

Ok, but what about the Price itinerary precondition (user logged in) ? That is not according to the Prepare Itinerary Use Case (user needs to be logged in just before confirming the itinerary).

Its the same, there is a precodition of: "user must logged in" to pay for itinerary ... this is contradictory with the other ... it thinks you must pick just one of them,
My assumption is: user must loged in to do anything in the system.

[Raj Nerurkar]

You asked..
-------------------------------------------------------------------------
Ok, but what about the Price itinerary precondition (user logged in) ? That is not according to the Prepare Itinerary Use Case (user needs to be logged in just before confirming the itinerary).
-------------------------------------------------------------------------

Answer..
If you asssume that Prepare Itinerary ends before Pay for Itinerary begins then then in the Prepare Itinerary use case you just need to check if the user is logged in before you send the user to the ConfirmItinerary Page.

Once the user logs in (if not already) and the system displays the Confirm Itinerary page then the Pay for Itinerary use case begins. On the Confirm Itinerary Page when the user clicks on Confirm, the Pay for Itinerary use case is realized.

Hope this helps.

[Samuel Pessorrusso]

Actually, the question was about the PRICE Itinerary pre-condition and not about the Pay for Itinerary.

The confusion about precondition is because the Prepare Itinerary ends after the price itinerary, and the user must be logged in just before confirming the Itinerary, which have already been priced.