How do you model New/Delete/Update?

[rdc02271]

Hi!
I'm a newbie to the UML world and from what i've read it's a bad, bad thing to model the insert/delete/update functionality  using use-cases (because it's functional decomposition). Ok!
But how do you then specify that when in "UPDATE" mode if the user changes the product ID (for instance) and saves the info, our software will have to change the productId in every related document, transaction, whatever.

Do you model this as an alternate scenario?!

Thanks for your help.
Best Regards,
Jorge C.
[email protected]

[thomaskilian]

Try searching this forum and the web for CRUD (Create/Read/Update/Delete). This will give a good start for further discussion.

[slavko]

Try looking at the goals of the actor.  In your use case the goal of the actor is not to update the product ID, this is a task or step in the overall use case but to achieve some higher level intention.   Try asking the question “Why does he want to update the product ID”

Also keep in mind that the use case defines the boundaries of the system and not the internals, so to say the that the software would have to change product ID in every related document, transaction, may be correct but would not be described in the use case.

- Slavko

[sargasso]

the software would have to change product ID in every related document, transaction,

but it sure looks like great candidate for a use case requirement to me!

bruce

[rdc02271]

Hello!
Use cases are about "what happens" right?!
So if the user's goal is to change the product ID the application will have to ask her if she really wants to change the product id. Isn't this an alternate scenario of some sort.
Note: the goal is really to change the product id.
The company I worked for develops retail management software, and one of the requirements is to be able to change the product ID with all the changes it implies: associated documents, etc,etc.

And about the delete? An alternate scenario?

Thanks for your prompt replies.
Jorge Carvalho

[sargasso]

OK try this thinking.

In room 1 is the marketing manager, in room 2 is the "user", in room 3 is a bunch of clerks with a library of product cards.

Manager yellls to user "Change the ID of the fridgits range to gumwobbles!".

User yells to clerks, "Get all the fridgits product cards and change the name to gumwobbles - and show me the results!".

... some time later ...

Clerks presnt a list of all the changed cards to the user.

The use case is "Rebadge product (range)".
The (basic or sweet or whatever) outcome is "All product reference cards updated with new ID and a list of changed cards is presented to the user".  This is your basic scenario.

Alternate scenarios may include such outcomes as (use your imagination, then reduce the set to pragmatics.
a) [Constraint: product cards dont exist] Clerks return message to user that "No such product card(s) exist(s), system not updated".  This is an "error" or alternate scenario.
b) [Constraint: cards not in library] The clerks return an message to the user that "Sharon from the factory has borrowed those cards - we cant do it today!".  Another alternate scenario.
c)... etc

Scenarios describe different outcomes of a use case, not different use cases.

more later...
bruce