Would you show things an Actor cannot do on a Use Case diagram?

Question

On a Use Case diagram can you show things that an actor cannot do, for example because they won't have permissions to do it?

Or is it just implied due to the fact that they won't have a line joining them to the particular use case?

Answer 1

If the Use Case you are diagramming is the case where an actor attempts to do something that is not permitted and is then denied, then yes, I would show it.

Otherwise, I would stick to only including things that are actually part of the use case.

Answer 2

No. An Actor would be connected to everything that he can do. If the Actor can't do it, then it's not shown.

Answer 3

This is what alternate paths are for. The basic path (a.k.a. happy path) will show what happens when the correct Actor initiates the Use Case. In the alternate paths you can show what happens if the wrong Actor attempts to initiate it.

Answer 4

You might model Role actors that can do the task. You could then have another use case that has the original actor attempting to acquire the given Role.

Answer 5

IMHO this question and most of the answers give a wrong impression about the way use cases should be used.

Use case was intended as a requirements technique that uses natural language. It is most and quite effective that way.

It can be a thoroughly destructive technique when it is combined with too much UML/modeling. Structured modeling of use case texts for example by modeling main and alternative flows using UML Activity Diagrams is a tried and tested way for example to create Use Cases of Mass Destruction.

A use case diagram can be useful but we should remember the purpose of use case as a technique which is first and foremost to identify the user goals a system should support. Subsequently we can capture more details using natural language in use case texts using main flow, alternative flows etc.

Using diagramming tools we can visualize some simple information: - For each user goal we can create model element type Use Case. - Show system boundary using a box for the system with use case elements in it. - Create a relationship between actor and use case to show the actor has a particular goal against the system.

Keeping an up-to-date list of actors mapped to goals is however of secondary importance. Doing a stakeholder analysis, drawing up lists of actors is a means to identify the users goals. After user goals have been identified it is strictly speaking not longer necessary to keep the lists of actors around.

If we are asking questions about how to put user permissions in a use case model we are most likely trying to capture too much information. We should abstract model elements away so that the model does not try to answer/capture these type of detailed design questions.