Is TIME an actor in a use case?
https://stackoverflow.com/questions/855361
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
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
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:
OTHER TIPS
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:
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.
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
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?
I also agree that Time is not a primary actor in this context. I would like to add a few explanations to support the idea that 'Time as an actor' is very often not a good idea at all.
(1) Let's give the thing another name and a workable definition. Time can be measured. But it is a very complex scientific problem to define exactly the concept as such. So for daily use it makes little sense to describe an interaction with it. A description and name for the role that suits me better is something that measures time and is able to notify about it, e.g. TimeService.
(2) We can measure Time everywhere. Time is not only outside in the environment. Only when the user demands that our time provider must not be part of the system to build we should describe an interaction with a secondary actor TimeService and an interface for it. But mostly TimeService will be one of the classes or components that realize/implement the use cases and be absent as actor in a UC diagram.
For more details: this is a short text I wrote about it.
In my answer to a similar question, I said that they way to model activities that should be executed at a given time is to create an actor called 'Scheduler' which is more of a placeholder and does not mention a technology. The idea is there has to be some person or component whose responsibility is to monitor the time and then initiate a particular use case. The use case say 'this use case starts at time X' depending on the needs of the use case. Yes time is a factor that can be modeled but the way the instructor is going about it seems a stretch to me because time itself does not care what happens when, it just is. He is over generalizing in an attempt to fit all types of use cases into his concept of modeling.
In the posited discussion with the instructor, I would ask, "Is time itself - no other mechanism, person, or software - the entity that acts upon the system?" The obvious answer being 'no' but the idea is that there CAN BE an arbitrary actor that a) can measure time, and b) knows that certain use cases are sensitive to time.
I do like the article in @Igor's answer as it really covers much of the issue with making Time a primary actor.
Actors are usually represented by some sort of noun so maybe a compromise is to use a clock as the actor instead of capital-T 'Time'. Like other posters, I agree that you are unlikely to convince the teacher but it is worth having the discussion because it helps to understand how he thinks about modeling in general.
Although I realize it is too-late for the class which generated this question, I posting this answer in hopes of helping others who have come across the problem of modeling time in a use case, or, encountering a professor who has their own opinion on how to model using UML use cases.
Time interacts with the system. E.g. time goes past and the system must do something based on that "action".
I agree with @Novalis time can be actor but not primary actor because every stakeholder is an actor and time can be responsible for the benefit or loss of any stakeholder so it can be considered as secondary actor or whatever name you want to give.
Until I know better I find time being an actor a bit confusing, especially because Actors act, and time is due to the fact that things are in change: the Earth revolves around the Sun, crystals pulsate. We transform the aggregated side effect of these changes with change-to-time converter tools (i.e. clocks!) into the man-made scale we call: time.
