Im quite new, but I shall try to answer as best I understand. I dont believe time can be an actor. An actor is someone or something that interacts with the system. Actors interact with use cases. A should result in something of measurable benefit to the participating actors, and this is where time cannot be an actor.
UML does provide notation for events, nicluding time event which looks a bit like an angular hour glass. Have a look at this holub reference card
It is quite common for Time to be an actor, often to kick off an event. Or, many people will choose to not show it on the diagram and simply discuss it in the use case. Both approaches are valid, choose one and stick to it.
We show timer or scheduler as an actor in use cases now & then. As I think about it, our time-driven scenarios are usually not use cases themselves. I'll have to think about why ... the lack of a UI shouldn't mean there is no use case.
I more often show timer or scheduler in sequence diagrams as the source of the trigger event that starts the sequence. Maybe the use case just says "the system sends a message to x" and it's an implementation detail that we happen to make this asynchronous with a timer.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Stan James: our time-driven scenarios are usually not use cases themselves. I'll have to think about why ...
The three amigos initially stated:
A time event is an event that depends on the passage of time and therefore on the existence of a clock . In the real world the clock is implicit. In a computer it is a physical entity� The time event is a message from the clock to the system. � Time events are not declared as named events the way signals are. Instead a time expression is simply used as the trigger of a transition.
I don't know if they have changed their tune for UML 2.0.