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?

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
  • 81,699