31

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?

starball
  • 20,030
  • 7
  • 43
  • 238
Thea
  • 7,879
  • 6
  • 28
  • 40
  • 1
    This topic might also help clarify when to represent systems as actors: [UML Use Case Diagrams: Reference](http://msdn.microsoft.com/en-us/library/dd409432.aspx) – Esther Fan - MSFT Jun 28 '10 at 20:50

4 Answers4

28

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.

mallardz
  • 1,070
  • 11
  • 21
Gabriel Ščerbák
  • 18,240
  • 8
  • 37
  • 52
  • 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? – CommonSenseCode Oct 01 '15 at 23:27
  • 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. – www.admiraalit.nl Oct 17 '16 at 11:44
16

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.

Eric J.
  • 147,927
  • 63
  • 340
  • 553
7

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.

LNG
  • 87
  • 1
  • 1
  • You focused on triggering and Gabriel Ščerbák focused on boundary and scope. Both of you pointed nice guides. – Alireza Oct 13 '14 at 13:45
  • 3
    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). – Evandro Pomatti Apr 03 '15 at 18:12
0

Business analysis book of knowledge and skills framework lists several possible types of actors in the use cases for the reason (system, event triggers, services) when writing use cases from the service perspective that team will build. For e.g. my team is not owning applications and we do not have business users, my testers will test API services, so I need to describe my use case from API perspective, so I need to state behavior when APIs will call other other APIs. So in general there are several types of use cases: business case where you state what are users (people) behavior in the application, system/service application - where services are calling other services to behave in particular way. Depending in which team business analyst is working, depending what applications team is owning or not owning, BA needs to describe and adopt to the approaches.

user21782745
  • 1