The essense of usecase diagrams

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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.