1

Is it allowed in UML to generate arrow as follows between Administrator and Member ?
On one hand, Admin is a secondary actor because he will react according members actions.
On the other hand, he amends the website's content and can do everything a member can.

I have a doubt on the style of the arrow because it is not properly straight showing the heritage, is that an issue ?

UML Diagram / Use Case

Geert Bellekens
  • 12,788
  • 2
  • 23
  • 50
Tarantino
  • 11
  • 2
  • first you do not have a generalization between your actors, a generalization use a different head ( `---|>` rather than `-->` you have), second there is no rule against generalization of actors while you do not create loops etc, so yes your secondary actor can inherits the primary actor, and that because the concept of secondary actor does not exist in UML – bruno Mar 12 '21 at 12:53
  • Hi Bruno, TY for your kind reply. I am not sure having understood properly so I prefer to clarify again yours explanations. You told me that "the concept of secondary actor does not exist in UML" but on many turorial I can see that the notion of seconday actor is used and they have to be placed on the right side. [https://www.youtube.com/watch?v=J8NtoLxhoRc cf 3'54] on that video. My main concerned was should I consider at the end the admin as a normal user even if he can manage website content on his own without expecting user's action ? And the last point was regarding this arrow: – Tarantino Mar 12 '21 at 18:33
  • https://ibb.co/nPNV11v usually the arrows are straight and not bent with several directions to join an entity if you know what I mean. – Tarantino Mar 12 '21 at 18:36
  • In the standard ( [formal/2017-12-05](http://www.omg.org/spec/UML/2.5.1) ) they do not exist, but yes it is common to distinguish primary and secondary and to place secondary at the right, but this is not a rule from UML, just a convention. Because they do not exist in the standard the standard cannot say the generalization is forbidden ;-) For the second part of your remark do not forget an actor is a *role* and not a person => `consider at the end the admin as a normal user` has no sense, you have two roles, whatever a same person can be both in real life. – bruno Mar 12 '21 at 18:39
  • your arrow with the yellow mark is not a generalization, and in fact I don't know what it is because there is nothing about that in the standard – bruno Mar 12 '21 at 18:46
  • How should I consider some association (actions) dedicades to admin only so ? Should I link them to the entity user in general and manage restriction later on. If their is a connexion between for example an association "Manage Content website" (admin rights only). Am I allow to do a connection between actor "member" and this association (even if not some member won't be able to do it) That why I wanted to distinguish theses 2 users case previously. – Tarantino Mar 12 '21 at 18:46
  • I think you do not understand what I said, the use cases connected only with admin are only available for admin and not for other actors (except if they inherit admin)? Out of that "s'inscrire" and "se connecter" are not UC for a member – bruno Mar 12 '21 at 18:49
  • Finally I put an answer – bruno Mar 12 '21 at 19:15
  • 1
    I think I know now what you try to explain me. I am allowed to create differents Use Case: - One for admin connected only (with associations on his own that a member cannot access) - Another UC with all association for visitor / member and admin I am sorry for my misunderstood, many thanks for your patience. – Tarantino Mar 13 '21 at 08:29
  • ok thank you I have just read the answers below – Tarantino Mar 13 '21 at 08:32

2 Answers2

4

What does UML say?

The difference between primary and secondary actors is not UML. The UML specification (see UML 2.5.1 page 638) does not even define the semantics when several actors are associated with the same use-case:

Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors. (...)

The manner in which multiple Actors participate in the UseCase depends on the specific situation on hand and is not defined in this specification. For instance, a particular UseCase might require simultaneous action by two separate Actors or it might require complementary and successive actions by the Actors. (...)

An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases.

In UML, actors are classifiers, and classifiers may be specializations of other classifiers of the same kind. So, yes, from an UML perspective, an actor can be a generalization of another actor regardless of primary or secondary.

By the way, the notation of a generalization is a big non-filled triangle shape. The small arrow head whether open or plain is not correct; it's even misleading.

Is it about roles or is it about users?

According to your narrative:

Admin is a secondary actor because he will react according members actions. On the other hand, (...) he can do everything a Member can.

The main question here, is to know if you speak of the users (i.e. the persons who interact with the system) or if you speak about the user's role. To help you determining that, let's reason with an extreme case: suppose you'd have an intelligent bot or an external system that would replace the Admin (e.g. using some kind of interface); would this automated Admin still have to be a Member?

  • If yes, the role of Admin seems to automatically imply the role of Member. Generalization is ok.
  • If no, the role of Admin in reality independent of the role of Member and it just occurs that human users that have the admin role also have the Member role. In this case you should not use the generalization.

Use-case value and primary vs. secondary actors

UML is neutral about that, but use-cases should in principle be of value to a user, and help the user to achieve his/her goals. Without this principle of value, there is no primary and no secondary users. Here for example Spence & Bittner's definitions:

Primary actors: (...) The primary actors are those for whom the system is built; they are those to whom the system provides sufficient economic value to warrant its construction.

Secondary actors: These are the actors that support the use cases provided by the system and those that support the system itself.

I suspect that if an Admin generates quotes ("devis" in French in your diagram) and invoices ("Facture" in French), there are chances that it's not a secondary actor, but a primary actor.

Last but not the least, verify your usage of include and extend. This seems to correspond to a navigation flow or a functional decomposition (or both) of your system and not really use-cases. But I'll not develop more: for that you'd need to translate your use-cases.

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • `UML specification (see UML 2.5.1 page 638) does not even define the semantics when several actors are associated with the same use-case` This and things are even more murky in OP's case where the same actor is associated (through generalization, but that does not matter here) with use cases on both ends of the same include relationship. AFAIK, there is nothing in the spec that would help one determine, whether one or two separate instances of the same actor are in this case needed to run including use case. – vrsio Mar 12 '21 at 20:07
2

Is a Generalization between primary & secondary Actor allowed?

primary and secondary actors do not exist in UML standard, so there is nothing in the standard saying this is not allowed.

In your case you can have that generalization because you it does not create a circularity.

Is it allowed in UML to generate arrow as follows between Administrator and Member ?

I don't know what is the relation drawn between Membre and Admin in your diagram, so I prefer to say no

I have a doubt on the style of the arrow because it is not properly straight showing the heritage, is that an issue ?

yes it is an issue because one does not know what that relation is / means

If you want a generalization the arrow head is different :

enter image description here

There are other problems in your diagram :

  1. I do not see why Admin is a secondary actor, in your diagram Admin is always a primary actor. But see remark 5 below

  2. by definition a Membre cannot register nor login, so Membre cannot activate the UC s'inscrire nor se connecter. An actor like guest can login or subscribe

  3. when an UC includes an other than means the included UC is always done each time the including UC is activated. You certainly do no want Member login each time he/she want to edit his/her profile, same for Admin each time an account is deleted etc, and as I said by definition of the actors Member and Admin the login cannot be activated by them.

  4. For a lot of people "se connecter" (login) does not have enough plus value to be an UC

  5. how a Membre can "consulter l'historique de ses demandes / devis / facture" while Membre cannot ask the system to create them (with Admin as a secondary actor) ? Visibly some UCs a Member can activate are missing

bruno
  • 32,421
  • 7
  • 25
  • 37