Create / Edit Use Case Design Problem

[hal9000x]

Hi,
I am trying to find the best way to design a use case deleting, creating and editing an object.



Now in Edit User and Create User I have nearly the same scenario with enter data, validating data, save data and refresh GUI. I think it would be a goof idea to separate this to another use case. I am not sure if that is an include, extend or a generalization.

Thanks for every hint

[Geert Bellekens]

In this case we usually create a "Manage User" that includes all CRUD operation on a user.

Geert

[Graham_Moir]

I agree with Geert, but if you stick with your approach then the use case containing the shared functions would be "included" in the create user/edit user use cases so the relationship would be <<includes>>.

[bioform]

You might have fallen into the use case/decomposition trap (e.g. mis-use case)

Since UC analysis should not be approached as functional decomposition you really should have alarm bells going off about now...

I would recommend that you take a moment and search the forums and/or the web about this specific question (e.g., misuse cases, CRUD use cases, etc.) and you might get a different take on use case analysis.

This is a very understandable trap to fall into (I have myself) but leads you down a road to a ton of UCs to maintain... UC's deal with WHAT needs to be done, not how... and should always be in an active-verb-noun format.... the result being something that is descrete, countable, and essential result.

"An action verb indicates a single activity that happens at a particular point in time and helps a visualize a result. Examples are count, evaluate, print, attach, return... Allocate Service Rep, Calculate Stock Index, Retrieve Sample, Issue Refund, and Translate Document are all use action verbs, and it's easy to visualize a specific result from each.

...A mushy verb, on the other hand, tends to indicate an activity or multiple activities that happen over time. While they might indicate some overall objective, they ndon't help us visualize a single specific result."

Quote from: Page 42, Workflow Modeling, Tools for Process Improvement and Applications Development 2nd Edition...

Really a great source for an engineering approach to use case's and the whole analysis approach. Ton's of actual hands on steps to follow that lead to a reproducible outcome (same set of UCs, business domain classes, etc.)

Hope that helps a bit...

David

[hal9000x]

Thanks for all these helpful answers. My problem is that I was a software developer before I came to the business engineering.

[hal9000x]

In this case we usually create a "Manage User" that includes all CRUD operation on a user.

Geert

Do you have special scenarios for that use case?

[Geert Bellekens]

Nothing special, just describe all the options the user can select (create, read, update, delete) and whatever special validations or actions are required by the system in those cases.
Remember, your use case scenario does not have to describe one single line of actions, you can describe the different paths into one description.
If those paths are relatively small (like one or two steps) you can include those in the main scenario (step 1, step 2, step 2a, step 2b). If they are a bit complexer you might want to create an alternative scenario for it.

Geert

[Oliver F.]

Remember, your use case scenario does not have to describe one single line of actions, you can describe the different paths into one description.
If those paths are relatively small (like one or two steps) you can include those in the main scenario (step 1, step 2, step 2a, step 2b). If they are a bit complexer you might want to create an alternative scenario for it.

Which is something I would refrain from if possible. Especially if test cases are being derived from those scenarios it eases the work of the test designers a lot if scenarios are clearly separated.
Comprehensively describing more complex or compound scenarios from my experience can be done better in activity diagrams. Something like "actor A presses button b and c, then sees result d and switches to view e, otherwise to f"). Activity diagrams greatly help getting an overview of the various paths of a use case and should support scenarios, not replace them.

Oliver

[hal9000x]

Again thanks a lot. Found an interesting presentation on this topic.

http://www.dama-nj.org/presentations/TQ%20Writing%20Good%20Use%20Cases.pdf