Use Case Questions

[Grady Jamyson]

I have following questions about use case diagram.

1. If a manager could receive forms and select forms to review, to audit, to send them back. Do I need to draw "select forms" use case or "receive forms" use case?

2. When a manager receives forms, he could either audit the form or send it back.
I draw two independent use cases for a manager, "audit a form" and "send back a from". But my friend said, "send back a form" should have "extend relationship" with "audit a form".
Which one is right?

3. When I draw activity diagrams, my friend said the number of use cases in use case diagrams must be exactly the same as actions in activity diagram.
i.e., if I have four use cases for the manager described above,
I could only have (and must have) 4 action in activety diagrams. Is that opinion correct?

4. Is there any (sort of standerd) procedure or sequence when I draw UML? For example, I have to draw use cases diagrams firstly, then draw activity diagram secondly...etc.


Thanks a lot.
[ February 28, 2005: Message edited by: Grady Jamyson ]

[Ilja Preuss]

Originally posted by Grady Jamyson:
I have following questions about use case diagram.

First notice that the important part of use cases is not in the diagram, but in the textual description.

Second, much of the answers below depend on what you are using use cases for - use cases for a rough first estimation of a project need to be done differently than use cases you want to base your implementation on.

For a short, general discussion, see http://www.objectmentor.com/resources/articles/Use_Cases_UFJP.pdf

1. If a manager could receive forms and select forms to review, to audit, to send them back. Do I need to draw "select forms" use case or "receive forms" use case?

The use case should describe what the user wants to do with the system. I have to admit that from your description, I'm not sure what that is.

2. When a manager receives forms, he could either audit the form or send it back.
I draw two independent use cases for a manager, "audit a form" and "send back a from". But my friend said, "send back a form" should have "extend relationship" with "audit a form".
Which one is right?

What does it mean to "audit a form"?

3. When I draw activity diagrams, my friend said the number of use cases in use case diagrams must be exactly the same as actions in activity diagram.
i.e., if I have four use cases for the manager described above,
I could only have (and must have) 4 action in activety diagrams. Is that opinion correct?

I don't see why that would be the case. Did he explain the reason for his opinion?

4. Is there any (sort of standerd) procedure or sequence when I draw UML? For example, I have to draw use cases diagrams firstly, then draw activity diagram secondly...etc.

No. Well, yes, there actually are such "cookbook" approaches (Fusion and ICONIX are two examples), but I think they should be taken with a big grain of salt. The fundamental reason for doing a document is to "enable the next step" to go to working, released software. Which steps that should be, taken in which order and to which extend simply too much depends on context that there could be a single "one size fits all" approach.

See http://www.agilemodeling.com/essays/iterateToAnotherArtifact.htm

[Stan James]

My team agonized over use case granularity for a long time. Then we backed up and reminded ourselves the point is to explore and communicate requirements. If you do it in one Word doc or four you get the same requirements and the same software. We have found overly fine grained use cases a bit harder to grasp though, as you have to take each one in the context of several others to get the point. Try to make them tell a useful story about someone using the system. Try not to make them subroutines - a quote from our Rational advisors that reveals my particular weakness.

I had a grad level course where the instructor insisted on a one-to-one mapping of use cases to diagrams of various types. I think every "User does x" statement in the use case had to be an activity diagram. Rigid cookbooks might help hammer in some concepts, but you'll rapidly realize you don't need to take them too literally to get the job done.

Relax, focus on communicating, let us know what kind of use case style you wind up with. It's helpful to us all to hear what works!

[Grady Jamyson]

Let me describe the story again.

I want to buy materals to make products. So, I write a form to apply materials.
A manager might receive a lot of forms a day.
He must approve or reject the forms he received by the content of forms. (agree to buy the materials or disagree to buy with some reasons)
Also, he could review the status of all the forms he has received.

So, I draw three use cases "review forms", "approve forms", "reject forms" for the manager I described.

Then, I add "select forms" action in activity diagram.
I want to use an activity diagram as the flow chart.
I think, after the manager selected forms, (here is a fork) he might "approve forms" or "reject forms", (here is a join) then he could "review forms".

My friend said,
1. use case "reject forms" should have extend relationship with use case "approve forms", because they are the same action with diffenet results by the manager decision.
2. "select forms" action in the activity diagram should be added in the use case diagrma, because there are four actions in activity diagram, but three use cases in use case diagram.
=>just like Stan said, "I think every "User does x" statement in the use case had to be an activity diagram".
So, what you have in an activity diagram should mapped in a use case diagram.

Thanks a lot.

[Ilja Preuss]

Originally posted by Grady Jamyson:
1. use case "reject forms" should have extend relationship with use case "approve forms", because they are the same action with diffenet results by the manager decision.

As Stan said, the goal is communication. Does the diagram become more clear by using the extends relationship? I doubt that it would to me, but you have to decide for yourself.

2. "select forms" action in the activity diagram should be added in the use case diagrma, because there are four actions in activity diagram, but three use cases in use case diagram.

I still don't understand this reasoning. Why should the number of use cases match the number of activities? Isn't a typical use case actually composed of a number of actions?

[Grady Jamyson]

"Why should the number of use cases match the number of activities?"
This is the question I want to know.

I have the same opinion "a use case actually composed of a number of actions" with you.
That is also I wnat to do.

But my friend doesn't think so.
If I draw them as he wants, I think I just draw the use cases with sequence, but not describe the flow of the use cases.

[kri shan]

Another doubt: Each activity represent separte use-case?

[Ilja Preuss]

Originally posted by Grady Jamyson:
If I draw them as he wants, I think I just draw the use cases with sequence, but not describe the flow of the use cases.

If that is what he thinks, I'd say he is wrong. It would be interesting to know his argument for doing it that way, though.

[Scott Ambler]

It's really hard to tell from the information given, but gut feel tells me that what is really happening here is that you're developing a data flow diagram yet are using use case notation to do so and are therefore struggling. If you need a DFD then use a DFD, otherwise you should create actual use cases.

A good rule of thumb is that a use case should describe an activity of value to the actor. I really can't see how "review forms" or "approve forms" provides value.

A business activity such as "Open Brokerage Account" would be a use case with reviewing/approving forms as an activity withing a financial organization for example.

"Review form" might be a use case for a shrink-wrapped application for forms processing, however.

- Scott

[Ilja Preuss]

Scott, good points! Thanks!