Is TIME an actor in a use case?

Question

Alright, on a true false question:

a)The actors of a system are only represented by humans or another software components.

I said TRUE, and the teacher marked it as wrong, not because he considered that I missed hardware components (which I guess I would partially concede), but because, on his words:

"TIME is also an actor."

How would an use case diagram consider TIME as an actor??

Please refer to any bibliography which considers time an actor. I haven't found any, and truthfully I don't think it makes any sense. Time doesn't act by itself, it's either a system or a person that works on a schedule.

Solution 1

The UML 2 Use Case Diagramming Guidelines here...

http://www.agilemodeling.com/style/useCaseDiagram.htm

... show how Time can be represented.

I suspect though that you should ask your Teacher to explain how Time is an actor and how it's represented on a Use Case diagram because, after all, they'll be marking your next assignment and so their interpretation trumps all others :-)

Oh, and Wikipedia says Time is an Actor, so it must be true:

http://en.wikipedia.org/wiki/Use_case

Solution 2

I don't agree that time is an actor. What you have to really think is who is going to benefit from the action and put in the functional description setting the timetable creation and execution. Take a look at this article:

Dr. Use Case

Solution 3

An actor can be considered as someone or something that starts a use case. Scheduled tasks are started by "time". In this sense, "time" is an actor, because it starts a use case.

Example:

A report must be generated each 6 hours. So, the time "6 hours" must be an actor because the generate task will be started each 6 hours.

Solution 4

I agree with having Time as an actor. If a use case in the system is triggered at a certain moment of time I'd model Time as actor and relate it with that use case. Time can be considered an external entity (and thus an actor) in these scenarios

Solution 5

Yes TIME can be actor in a use case. But should not be primary actor.Since it is really violate definition of actor in a use case.

Primary actor is someone/thing which has a goal for interacting with the system.

What kind of goal does Time has?

Time ------> RunPayroll

Who has benefit from running payroll? Maybe Time actor hides a real actor.

Payroll Administrator (primary actor) ---> RunPayroll  --> Time (Supporting actor)

But that does give impresion that Run Payroll Use case invoked manually by Payroll Administrator? Afterall we are developing an automation sytstem?

But keep in mind that, if we use the Payroll Administrator as the Primary Actor, then we can capture all the system features that surround the running of payroll. This includes features that allow the Payroll Administrator to set the timetables for running payroll and to handle discrepancies, manual intervention, and holidays. [Dear Dr. Use Case: Is the Clock an Actor]

You can get that nice Ibm article from Dear Dr. Use Case: Is the Clock an Actor?

View more solutions

Comments

[andandandand]

Please show an example in which the actor "Time" interacts with a system. I believe Time doesn't act by itself, it's either a system who works with a timer or a person who acts on a schedule.

[Simonw]

Would you have considered time as an actor before reading this question? I would always have considered that case you provided to be an example of a software component starting the use case, i.e. the scheduler

[Fabio Vinicius Binder]

Yes, it is the convention used by UML.

[andandandand]

Your link says: An actor is a person, organization, or external system that plays a role in one or more interactions with your system (actors are typically drawn as stick figures on UML Use Case diagrams).

[andandandand]

Then marks a person or "system* with the name Time, as someone working on a schedule, not a magical mystical entity that works by itself.

[Martin Peck]

Time is an "external system". Check out point 8 just below that definition of Actors. It illustrates Time being added as an actor.

[andandandand]

Yeah, I already referenced it and I find it moronic, cause its not something that acts by itself, but rather a condition scheduled by the system itself, who would be the one who is truly "acting". Either way thanks for the obscure reference to nonsensical canon. Your answer is marked as accepted.

[Martin Peck]

I guess my main answer was "get your Teacher to convince you" and then "understand what your Teacher thinks, even if you disagree, because knowing what they beleive allows you to score high marks". I totally sympathise with your point of view - this is just one of the many problems I have with UML.

[Luiggi Mendoza]

+1: Nice answer, I was looking all night for this. You saved my day :)

[onknows]

A use case cannot be started. Interaction described by use case can be initiated by someone. Imagine situation where for performance reasons some of what system does in response to user interacting with system to reach user goal is postponed and scheduled for latter processing. That is a design/implementation decision. It doesn't change the functional requirements (in use case). Now TIME becomes the actor? I rather keep use case as is but I would consider adding TIME as 'secondary' actor. So TIME helps primary actor reach user goal. TIME does not have user goals (use cases) agains system.

[alttag]

It's a great article, thanks for the link. One of the things I tell my students is that it's partly about what you're trying to communicate. Use case modeling is intended to communicate information about a system's design in a clear, consistent way to multiple audiences. If they it's modeled achieves that goal (whether we choose to use Time as and actor or not), we've succeeded. For this reason, although I nodded my head all the way through the article, because using Time as an actor communicates an important trigger in the system I would recommend its use.

[Kelly S. French]

Would it be any different to name the actor, "Scheduler"?