正确指定主要/次要角色（UML用例图）

Question

Consider the following case:

I have a webservice that provides information about orders in an online shop. On another machine there is a windows service that retrieves orders from the webservice once an hour and writes the data to a database. Instead of a scheduled task a windows service is used, because it provides a tcp endpoint, so a client can manually (using a simple desktop application) command the service to retrieve data of a specific order.

I am unsure where I have to place the windows service. It is a primary actor calling the webservice in a given interval, but it is a secondary actor as it reacts to the command of a client.

How should I proceed creating a Use-Case-Diagram for this scenario?

Answer 1

The answer depends on what you consider as your system.

One system

If your system contains both the webservice and windows service as parts of your (multi-tiered) system, then neither is an actor. The functionality offered by the windows service will be one (or more, depending on the complexity of the service) use case. If you assume that webservice it might become a second use case, that is included by the windows service (a rare case but works here).

The mere fact that those parts are on separate machined doesn't change a thing. It's common approach that database has it's separate machines but no-one reasonable consider it to be separate from the system itself.

Two systems

If you treat windows service as a separate system then you will actually have two use case diagrams, one for each of the systems.

In this case the use case diagram of windows service will have the client as a primary actor and system containing the webservice as a secondary actor.

In the use case diagram of the system with webservice your primary actor would be the windows service system (again as a whole , not a service itself). In this diagram the client is not depicted at all as it does not interact with the system.

Component as a system

Even if you consider both windows service and webservice as a single system, you may still depict use cases of components rather than the system as a whole. In such case the aproach will be similar to the situation with two systems.

Answer 2

In addition to what @Ister said: Draw a boundary that represents your system under consideration. Now think about what is inside (the use case bubbles) and what is outside (the actors). For the latter there's the convention to place the primary actors to the left and the secondary ones to the right. Primary actors are usually considered the ones that start a workflow while the secondary ones are being triggered/informed in the course of any such workflow.