When a system should be included as an actor in use case diagram?

Question

I'm making a use case diagram for a new system. I'm wondering when a system should be included as an actor in use case diagram?

Thanks.

Solution 1

As stated in another answer, an actor is a system or role interacting with the system under development. You should include a system as an actor in a use case if it is outside the system you are developing, and if it directly interacts with the system you are developing.

This is important because you need to define the boundary of your system, which means its scope and interfaces. Including a system as an actor will clearly state the requirement for your system under development to provide a suitable interface for that actor system.

Solution 2

Different people have different philosophies about how to correctly model in UML (which is not surprising since UML was standardized by committee).

I use actors to capture every "thing" (type of person, type of system) that can interact with the system I am designing and find them useful to create a common understanding among all stakeholders of how the new system will be interacted with.

I suggest creating an actor for everything you know will interact with the system, and trace that actor to every use case the actor can execute. That way, you gain a full understanding of who can do what.

Solution 3

System is never an actor in a use case model. You have to think about the thing that is triggering the system under investigation to carry out a process. The system itself is dumb and cannot trigger itself into action. It can only be triggered by a user or by Time. If you think the system is triggering the action then it will probably be Time that is the actor. For example, a process is triggered to run when an electronic message is received. The process is fully automated and is not triggered by a user telling the system that the message has arrived so who is the actor? It is not the system but Time. What you have to imagine is that there is a process to look for the arrival of the electronic message and this is looking at specific time intervals e.g. every second or every minute or once a month etc. Therefore it is Time that triggers the process that runs when the electronic message is received.

Comments

[Alireza]

You focused on triggering and Gabriel Ščerbák focused on boundary and scope. Both of you pointed nice guides.

[Evandro Pomatti]

Yes it does. Specification clearly states that, you can download it from OMG and check it. External systems can be depicted as actors of the use case diagram. And UML 2.5 officially defines that a use case with no actors is triggered by the subject it is contained in (a scheduled job for instance).

[CommonSenseCode]

Is the database of the system a use case like stores data or an external actor due that it receives inputs or gives outputs to the system?

[www.admiraalit.nl]

Usually, the database is considered to be inside the system boundary, i.e. it is a part of the black box that interacts with the actor(s) and not an actor itself. But there are exceptions. Suppose you design a new system that is connected to an existing database which remains as is, then you might consider that db as an actor. But do this only if it is relevant for the stakeholders who read your use cases.