The essense of usecase diagrams

问题:

For a school assignment, we have to make a Usecase diagram. But the documentation that we have, is not very extended. It just describes what components a usecase consists of, and one example.
We have to make a usecase about a library system. We have found 11 usecases, but I won't bother you with all of them.

IIRC, a usecase describes a typical usage of a system, right? But what things belong on a usecase diagram, and how do they connect together?

What we have now are four actors (member, employee, manager and accountant). The ones we have most problems with are member and employee.
The employee is the one who is using the system. Does a member still belongs here as an actor?

Some usecases that we have:

• Member joins the library.
• Member alters his records.
• Member borrows a book.
• Member parts the library (unsubscribes).
• Member books an article.
• Member returns book.
• Member pays (a part) of the fees and fines.

Those become usecases on the diagram. But should there be more usecases, like, employee enters membernumber, employee enters booknumber and so on (uses?).

Can anyone shed(?) a light on this?

Edit: How are sequences of action described? I've been told you can see a uses association like a method call to some kind of routine which recurs? Is this right? And how is extended used?

回答1:

IIRC, a usecase describes a typical usage of a system, right? But what thin[g]s belong on a usecase diagram, and how do they connect together?

Your Use Case diagrams (yes, a typical project will have more than one) should probably be the simplest diagrams in your UML suite. They should map Actors / Roles that you have defined directly to the Use Cases of your system. In fact, they should focus primarily on a single Actor and only include other Actors if they must participate in a particular Use Case.

Here's an example that I got off Google:

Sample Use Case Diagram http://java.sun.com/mailers/newsletters/fundamentals/img/usecase.png

Note the simplicity. One Actor, one System, 5 Use Cases. Nothing else.

Also, as @Eric P suggested and my example image implies, you should title your Use Cases with a "[Verb] [Object]" structure; i.e. "member borrows a book" becomes "Borrow Book". The missing subject of your use case sentence ("member") is encoded in your Use Case diagram as as an Actor with an association to the Use Case.

The employee is the one who is using the system. Does a member still belongs here as an actor?

I'm afraid the answer to that is subjective. Some will say no, that because the system is only being used by the employee, then the employee is the only actor. I personally disagree.

Why? For one, Use Cases are part of the requirements gathering phase. They are there to help you organize the eventual functionality of the system. But to deny the Member Actor simply because your current belief is that the technology will not be used by the Member is to limit yourself in that phase.

What if your eventual system is automated, meaning that the Member goes to a terminal to check out a book herself? If you made an assumption during requirements gathering, you might miss out on important functionality.

Edit: How are sequences of action described? I've been told you can see a uses association like a method call to some kind of routine which recurs? Is this right? And how is extended used?

Use Case Diagrams are high level. They should show your high-level functionality (in the form of each Use Case) and the Actors that utilize them and nothing else. Don't litter your Use Case Diagrams with extends and includes; those should be rare and special-case only. The biggest rookie mistake you can make (and believe me, I've made it!) is to try to modularize your code inside your Use Case diagram. Yes, I know, it's the first thing any programmer worth his salt tries to do, but Use Case diagrams are not the place for it.

Regarding sequences of action: in a typical suite of UML diagrams, each Use Case has associated with it one or more Activity Diagrams. These are roughly analogous to a flow chart and serve as a graphical representation of the typical Use Case narrative structure that most Software Engineering textbooks encourage.

Anyway, I hope this helps. If you have other questions, feel free to ask!

回答2:

I was taught that everyones approach to use case diagrams are a little different, so I don't know if this applies to you, but actors are generally those who have direct contact with the system. So a member would not be an actor unless he scans his own library card or something because he would have to go through the employee.

Use cases should cover everything, but not be greatly detailed. So the employee would check for membership, if it doesnt exist, go to create membership use case, else check for outstanding fees. If membership is in good standing, scan book, etc.

回答3:

It sounds like you have a muddy understanding of what use cases are. Here are some resources to get you going in the right direction:

• Use Cases - An Introduction
• UML Use Case Diagrams

回答4:

The actor is the person using the system, so if the Employee is the only one using the system, then they should be the actor. You could also have multiple possible actors if for example a function is available to both Employees and Managers.

So, you might want to rephrase your use cases to something like "Add new member", "Alter member account", etc.

As for level of detail, I would include as much detail as you can without getting "technical". Brandon's suggestions there are pretty good.