4

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?

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
Rama Ranneh
  • 47
  • 6

3 Answers3

3

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.

Axel Scheithauer
  • 2,758
  • 5
  • 13
  • Actually there IS a use for extend: optionaliity. Unfortunately this is most times taken wrong and used for functional decomposition. I guess that the OP is using it the right way. But generally: as you said one should stay away of it. – qwerty_so May 04 '22 at 18:17
  • "Two (or more actors) connected to one use case mean that all actors are involved": are you sure? Shouldn’t it at least be "can be involved"? – Christophe May 05 '22 at 15:58
  • The specification says _"When a UseCase has an association to an Actor with a multiplicity that is greater than one at the Actor end, it means that more than one Actor instance is involved in the UseCase."_ It doesn't mention multiple Associations to Actors, but since this also means that more than one Actor instance is linked, I think it also applies. – Axel Scheithauer May 05 '22 at 19:11
  • would this mean that the many ucd that associate different roles to a use case are wrong?(in other words: would the unspecified multiplicity necessarily have a lower bound of 1) – Christophe May 06 '22 at 07:21
  • Well, the UML doesn't say anything about "unspecified" multiplicity. There is a derived property `lower`, that evaluates to `1`, when nothing is specified. Therefore, a tool can distinguish between an unspecified multiplicity and one that is set to 1, but both cases mean, that the multiplicity _is_ 1. Of course you can set it to `0..1` and make the actor optional. I would recommend to show that in the diagram. You then need to define that exactly one on the optional actors is required, which means you need some textual constraint. I try to avoid such constraints. – Axel Scheithauer May 06 '22 at 07:41
  • As far as I know, when no multiplicity is specified, then yon can't infer/assume anything about multiplicity, and not that it is necessarily 1. SySML has clause that specifies such a default multiplicity, but I didn't find any evidence in UML 2.5.1. Could you give me a hint where I can find this assumption? – Christophe May 10 '22 at 06:34
  • "Two (or more actors) connected to one use case mean that all actors are involved in this use case." so I can connect two actors that trigger the UC to the same use case, there is no problem with this if both of them contribute to the UC (need both actors to trigger the use case)? – Rama Ranneh May 11 '22 at 02:12
  • If they start using the system at exactly the same time, both could be primary actors. A seesaw for example will have two primary actors. However, usually one of them is the initiator and the second one is collaborating. – Axel Scheithauer May 11 '22 at 15:46
  • @christophe: As I said, there is a derived property `lower`that evaluates to 1 if `lowerValue=null`. It is defined as _"/lower: The lower bound of the multiplicity interval."_ I don't know, but for me that means, the default value _is_ 1. They could have defined it as default value, but for some unknown reason, they chose a more complicated way. – Axel Scheithauer May 11 '22 at 15:55
2

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.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
0

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).

Jean FEX
  • 19
  • 1
  • 1
    An actor is a BehavioredClassifier and as such can be generalized. Why do you say that the OP's approach is wrong? – qwerty_so May 04 '22 at 18:26
  • Was the primary actor ever in the UML specs? Isn’t the distinction just a practical point of view that was proposed by some authors and well accepted by the community (because it’s indeed practical)? Could you complete your answer by quoting what the UML specs say about multiple actors for a use case? ;-) – Christophe May 06 '22 at 07:16
  • I agree that Actors may be Generalized since they even are Classifiers. I just meant that it was not necessary here. I don't know if primary actors were ever in the Spec. I've seen them used and find it a useful concept that is compliant with the current Spec. I do know that it is taught in the OCUP 2 Certification Guide since I am getting prepared for the Foundation level certificate. – Jean FEX May 06 '22 at 08:22
  • @Christophe Neiter 1.5 nor 2.0 mention a primary actor (htey might use a different term but I scanned for _primary_ looking for _actor_ in the vicinity). I don't have any older specs than 1.5. – qwerty_so May 09 '22 at 22:22
  • I scanned the spec again just for actor. Well, there could be more description than there currently is (or had been). Definitely there is a need to express the difference between primary actors (triggering the UC) and secondary ones (those being triggered). I have introduced my own notation in the past along with a modeling guide on how to use it. Would be nice to see UML being more detailed but to me it looks like OMG is more controlled by techies than by business people. – qwerty_so May 09 '22 at 22:40
  • In section 12.1.2 of the OCUP 2 Certification Guide, it is proposed to use open arrow heads on the Actor-Use Case Associations this way : The arrow head on the Use Case side indicates that "the Actor initiates the Use Case". The arrow head on the side of the Use Case indicates that "this Use Case contacts the Actor to start the behavior". Since these 'are' Associations, their ends are the same as Associations between Classes. Therefore, multiplicities and directions may be used. – Jean FEX May 12 '22 at 12:34