Kinky use case

[Philip Pomario]

Hi guys, let me try explaining my doubts without leaking too much information about the project itself.

Let's suppose I have a system for an online bookstore. The hypothetical Prepare Shopping Cart use case states that its post-condition is an unpaid shopping cart that contains all client's books. Though, the Business Analyst did a kinky job stating at the very last line of this UC that it includes Checkout Shopping Cart. As you can imagine: Checkout Shopping Cart's post-condition is a paid shopping cart.

My question is: wouldn't Checkout Shopping Cart's post-condition "overwrite" the post-condition of Prepare Shopping Cart? Which would mean that a customer would not be able the finish adding books to his/her shopping cart and not purchasing all items?

Regards,
Filipe

P.S.: I hope this tweaked description of one use case of the project is understandable.

[Gabriel Claramunt]

Kinky indeed. In the case you mention, the requirements are contradictory (alas, what requirements aren't? ): the postcondition of prepare shopping cart will never be true, because the postcondition of checkout is a paid shopping cart.
But read the fine print of the assignment: "Prepare shopping cart" doesn't include "Checkout shopping cart" it sends the unpaid shopping cart to it... that makes a whole difference with the postconditions
[ June 05, 2007: Message edited by: Gabriel Claramunt ]

[Philip Pomario]

Originally posted by Gabriel Claramunt:

But read the fine print of the assignment: "Prepare shopping cart" doesn't include "Checkout shopping cart" it sends the unpaid shopping cart to it... that makes a whole difference with the postconditions

[ June 05, 2007: Message edited by: Gabriel Claramunt ]

Gabriel, thanks for your reply.

There's something very subtle in the assignment text that I can't get a grip - maybe something is lost during translation. I tend to read one use case "connected" to the other so I can imagine screen flows, and every time I re-read this use case I see an implicit "include" blinking in red bold fonts. I would really appreciate if you could write a bit more about your thoughts.
[ June 05, 2007: Message edited by: Filipe Pomar ]

[Frank Kuepper]

I agree with Gabriel. Taking the requirements by work, it's not an include-relationship but more a sequence of the two. (BTW: have a look at the use-case diagram which underpins this ).

Also think of what you would expect from an application: The result of you preparing your shopping cart, is a bunch of items, that you would like to buy. Then it's up to you to actually hit the "confirm" button to activate the "pay for shopping cart" use case. It's not so "automatic"; you also have the otion to chose the "abort shopping" use-case - Though I admit, that this could be considered an alternative flow

Just my 2 cents...
Frank

[Deepak Bala]

If you find a contradiction you have to make an assumption about it and go ahead. Document and justify your assumption and then incorporate that into your design

[Philip Pomario]

John, true enough. But I don't think there's a contradiction, it's probably something I didn't understand right. I mean that because there's also that "Change Shopping Cart" use case that changes "items" on a unpaid shopping cart - which wouldn't be possible if all carts were to be paid.

So, what you guys are saying is that it's not an include, it's a subtle "asynchronous" call to another use case?

I appreciate your comments.

Filipe Pomar

[Ajith Kallambella]

Why can't you make the following assumptions

Checkout results in only one of the two states - paid or unpaid shopping cart.

A paid shopping cart means all items are paid.

Once the shopping cart is paid for, items cannot be modified.

Modifying items is only allowed for an unpaid shopping cart.

[Gabriel Claramunt]

Originally posted by Filipe Pomar:

So, what you guys are saying is that it's not an include, it's a subtle "asynchronous" call to another use case?

"Include" has specific semantics(?) in a use case model: the flow of the including use case is stopped, the whole included use case flow is executed, and the flow resumes in the including use case at the next step of the inclusion point.
(well, more or less that's the idea... like a synchronous method call)
In this case, maybe is "asynchronous" call , I see it as just a redirection.
Thinking about it, either are 2 different use cases and that implies that the user can prepare the shopping cart today and pay for it later or is really one use case and the user must check out the shopping cart or lose it.
If is 2 use cases the last step of the use case is misleading.

[Shabbir Kothawala]

Well you definetly needs to save the shopping cart. Here since the price of item will not going to change hence the save shopping cart is valid till the expiry date (we need to make this as assumption) as after expiry there is no use of save cart

So if you think of save cart and order cart as 2 different entities then you will have better picture

Thanks,
Shabbir