2

I am doing a lot of sequence diagrams. We decided to start at a subsystem level of abstraction because we do not have all the details yet. In my diagrams I was using this definition of Actor:

In UML, an Actor is always something (a system or person) that is outside the scope of the system/software that you are building

So the resulting diagram of a hypothetical system that exports data would be:

My system conformed by a web API and a database

Notice that External Web API and External FTP Server are considered actors because they exist even if my system doesn't.

A friend of mine told me that he thinks that Actors are initiators of interactions like User and they don't wait passively to be invoked.

On the other hand, the acording to UML standard an Actor:

specifies a role played by a user or any other system that interacts with the subject

and

Actors may represent roles played by human users, external hardware, or other subjects ...

I think that External Web API meets at least these two requirements. Even though it doesn't initiate the interaction, it interacts with my system by responding the call made by My Web Api.

So, should I represent it as an Actor or just as another Subsystem?

Renato Sanhueza
  • 123
  • 1
  • 6
  • Is your goal to represent the entire system in your sequence diagram, or just the software system you are building? – Robert Harvey Feb 04 '21 at 00:43
  • @RobertHarvey My goal was to represent the system that I am building. But it also depends on external systems that are out of my jurisdiction. – Renato Sanhueza Feb 04 '21 at 00:46
  • 2
    In any case, the only difference is the symbol that you use. It's either going to be a stick-man or a subsystem box, and if your coworker digs his heels in, it's not worth fighting over. At the end of the day, the goal is for the diagram to be readable and understandable, not strictly correct; and the diagram will be clear regardless of the choice of symbol you use for the external systems. – Robert Harvey Feb 04 '21 at 00:46
  • I agree. Nevertheless I would like to know the answer to this question because I wasn't able to find a good source to back either of the two claims. Probably due the fact that there is not much documentation about "subsystem" sequence diagrams out there... – Renato Sanhueza Feb 04 '21 at 00:51
  • 2
    OK, I went and did a Google search for "Actor UML." None of the sources that I found make the assertion that an Actor must initiate actions to be called an Actor. Quite the opposite, in fact; [this article](https://t2informatik.de/en/smartpedia/actor/) states specifically that "an actor can not only be the creator of an action (such as the initiator of an application case) but also the recipient of an expected result." – Robert Harvey Feb 04 '21 at 01:54
  • 2
    There are primary (starting activities) and secondary (waiting to be triggered) actors. –  Feb 04 '21 at 10:54
  • Thanks for your help gentlemen. Even though I am not trying to stick strictly to the standard I wanted to avoid making an obvious mistake. All the evidence points to fact that subsystems outside the scope of my system may be considered as actors. – Renato Sanhueza Feb 04 '21 at 12:29

1 Answers1

2

If we would take it by the book, actors -- human or systems -- should not appear in a sequence diagram, because they are not enclosed in the system under consideration, and hence not in any of its subsystems/components/classes:

17.2.3.1: Interactions are units of behavior of an enclosing Classifier. (...)

Messages exchanged with the outside world would in principle be related to a gate (either explicit or represented by the boundary frame of the diagram), and not to a lifeline of something that is out of scope.

This being said, it is in reality a common practice to show actors in a sequence diagram. The actor being a classifier, it can be associated with a lifeline. We just have to keep in mind that the scope of the sequence diagram is then no longer the system that is designed, but its enclosing environment, a system of systems, or an organisational system including humans and IT, or both together in your case).

It is then advised to show the external systems as an actors. Representing them as a «Subsystem» box would be extremely ambiguous, since it might mislead to think that they are subsystems of the system being designed.

You have already exposed the right formal arguments why an external system can be considered as an actor, and Robert has provided some further references that confirms this position in plain English rather than UML-Speak. As explained by qwerty_so in the comments, an actor who contributes to a use-case launched by another actor, is called a secondary actor. THis applies equally well to human actors and independent systems.

Christophe
  • 74,672
  • 10
  • 115
  • 187