Rama Ranneh
Rama Ranneh

Reputation: 57

Extend in use case diagram

I read that it is not correct to connect more than one primary actor to a use case so a situation like the image below is not correct enter image description here

So I used inheritance like this enter image description here

But the use case has an extended use case that is for only one actor (the second actor does not have that extended use case). So in my example both manager and HR can browse users but only the manager can block a user. enter image description here

How can I represent that in the diagram?

Upvotes: 4

Views: 828

Answers (3)

qwerty_so
qwerty_so

Reputation: 36295

I'm with Axel: stay away from «extend» unless you know what it's meant for. I would guess that in your case it's legit. So what you can do is to just add a constraint to either the extend relation or to the actors explaining the restriction. Simply show it as a note with the constraint { in curly brackts}.

Otherwise there is a convention to put primary actors (the one that triggers the UC) to the left and involved actors to the right. Your approach with generalization is just fine. An actor represents role (like in a screenplay). And identifying those roles is an essential part during UC synthesis.

As always I recommend to read Bittner/Spence about use case modeling.

Upvotes: 2

Axel Scheithauer
Axel Scheithauer

Reputation: 3625

Two (or more actors) connected to one use case mean that all actors are involved in this use case. If you want to show, that either one of multiple actors can be involved, a generalization is a good possibility.

The notion of "primary" actor is not specified in UML. Therefore, I talked about actors involved in a use case. Of course, in the description of the use case you will be clear about which actor initiates the use. This will be the primary actor.

All the problems you have with «extend» can be solved by simply omitting it. In my opinion «extend» doesn't contribute to a better model. If you want to say that there is an overlap in the description of several use cases, you could use «include». But actually, you should not worry too much about these relationships. After all, you want to describe what actors are using the system for. Each actor goal is an own use case.

Upvotes: 3

Jean FEX
Jean FEX

Reputation: 19

This notion of "primary" actor is not in the latest (2.5.1) version of the UML Specification. You just associate the right actor/s (Manager, HR or both) to each of your use cases without using generalization (inheritance).

Upvotes: 0

Related Questions