12

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.

andandandand
  • 21,946
  • 60
  • 170
  • 271

10 Answers10

9

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

Martin Peck
  • 11,440
  • 2
  • 42
  • 69
  • 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 May 12 '09 at 23:25
  • 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. – andandandand May 12 '09 at 23:26
  • Time is an "external system". Check out point 8 just below that definition of Actors. It illustrates Time being added as an actor. – Martin Peck May 12 '09 at 23:27
  • 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. – andandandand May 12 '09 at 23:34
  • 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. – Martin Peck May 12 '09 at 23:38
  • +1: Nice answer, I was looking all night for this. You saved my day :) – Luiggi Mendoza Apr 19 '12 at 00:46
6

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

Igor Zelaya
  • 4,167
  • 4
  • 35
  • 52
  • 1
    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. – alttag Jul 11 '17 at 21:03
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.

Fabio Vinicius Binder
  • 13,024
  • 4
  • 34
  • 33
  • 1
    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. – andandandand May 12 '09 at 23:20
  • 1
    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 – Simonw May 12 '09 at 23:21
  • Yes, it is the convention used by UML. – Fabio Vinicius Binder May 12 '09 at 23:24
  • 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. – onknows Jun 21 '12 at 07:58
1

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.

roblacit
  • 11
  • 2
1

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.

Community
  • 1
  • 1
Kelly S. French
  • 12,198
  • 10
  • 63
  • 93
1

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?

Novalis
  • 2,265
  • 6
  • 39
  • 63
1

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

Jordi Cabot
  • 8,058
  • 2
  • 33
  • 39
0

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.

amitesh
  • 766
  • 5
  • 17
  • 39
0

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.

Balint Pato
  • 1,497
  • 1
  • 13
  • 28
0

Time interacts with the system. E.g. time goes past and the system must do something based on that "action".

Nat
  • 14,175
  • 5
  • 41
  • 64