Making a use cases diagram for an automated system

How exactly does one draw out a use cases diagram when everything is automated? Here is an example with a request I got:

"Make a modification that resets a game server to a certain map or switches gametypes when there have been no players for 2 hours"

Now, there are basically no users in the classical sense. The modification in question kicks in automatically once it's been added to the server. Thinking ahead there would be a timer that would poll the n开发者_JAVA百科umber of players at a regular interval and then start a countdown once that number is zero. Then the timer would call a method that would trigger a change.

What Actors can you see in this description?

---

May I suggest that the actor in this case should be implementation agnostic, rather than being 'timer', something along the lines of 'Server Monitor'. There is a critical difference here in separating the instance of the actor and the actor itself (or the role and who/what is performing the role.

I.e. the role of 'Server Admin' could be instantiated in many different ways:

• Timer
• Counter
• Server admin employee

You should think about the actor as fulfilling a particular 'role', and a role encapsulating a logical group of functionality. That way your end product doesn't get in the way of your requirements and you can more easily answer questions (particularly when looking for improvements down the track):

• Can i automate this?
• Is there a cheaper/faster way to perform this role?
• Is this use case specific to this role?
• Does this role have other use cases?

Just trying to highlight the benefits and importance of separating the role your actor plays (i.e. server admin) and the app/person/machine instantiating it.

---

Timers are often modelled as actors in use case diagrams. I suggest you do so.