This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Kinky use case

 
Philip Pomario
Ranch Hand
Posts: 113
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 375
Monad Scala
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 113
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 45
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 6663
5
Firefox Browser Linux MyEclipse IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 113
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 5782
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    Ranch Hand
    Posts: 375
    Monad Scala
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Greenhorn
    Posts: 24
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
     
    I agree. Here's the link: http://aspose.com/file-tools
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic