Title: AW: (ROSE) Use cases: When its not clear who gets the value
I have to say I disagree with the example for a couple of reasons:
 
1. Cron is a system utility.  It is an implementation detail.  The requirement should be something like "process A occurs regularly every Monday at 10:00am because the business reason is whatever".  Cron is simply a means of implementing that requirement.  Calling the use case "Cron", and writing it with such specific language, presupposes an implementation platform.  What happens if, after the design is complete, someone decides that it will be deployed on a system that doesn't use cron (i.e., non-Unix)?
 
2. There is an excellent article in the Rational Edge archives that discusses the naming of use cases.  In summary, it says use cases should be named with the specific goal of the actor in mind.  Based on this guideline, which I agree with, Cron is not a clear name for a use case.
 
I'm still not convinced one way or the other about "Time" as an Actor, but I definitely think "Cron" as a use case is not the best way to express requirements.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 22, 2001 1:27 AM
To: [EMAIL PROTECTED]
Subject: AW: (ROSE) Use cases: When its not clear who gets the value

The UML 1.3 defines:

Actor
An actor defines a coherent set of roles that users of an entity can play when interacting with the entity. An actor may be considereded to play a seperate role with regard to each use case with which it communicates. [...]

Use Case
The use case construct is used to define the behavior of a system or other semantic entity without revealing the entity�s internal structure. Each use case specifies a sequence of actions [...]

"users of an entity" is - for me - all that, which is not a part of my system. So the system clock is part of the use case.

Actor         UseCase        Actor
User ------>  Cron  --------> external System

Actor: User
can define new Cron-Jobs (which command is on which time?)

Actor: external System
external system or command that is contacted or executed by the cron

UseCase: Cron
- administers the cron-jobs
- checks periodically the jobs
- starts execution of the jobs

Maybe this helps.


Mit freundlichen Gr��en
Jan Mat�rne

RZF NRW
Sachgebiet 314-P Software-Entwicklungs-Methoden
Fiscus AFG NW 42 SoftwareEntwicklungsUmgebung
Internet:       [EMAIL PROTECTED]


    -----Urspr�ngliche Nachricht-----
    Von:    Frank I. Reiter [SMTP:[EMAIL PROTECTED]]
    Gesendet am:    Mittwoch, 21. M�rz 2001 21:41
    An:     [EMAIL PROTECTED]
    Betreff:        (ROSE) Use cases: When its not clear who gets the value


    I'd like to hear some opinions about how to handle something that has me a
    bit stumped.

    I am writing use cases for a system.  For the most part I am finding that
    pretty straight forward.  In one instance however there is behaviour that I
    want to document and I can't see quite how to make it a use case.  (On
    possible answer is that I shouldn't try!)

    The system has a cache of data which originates elsewhere and can change
    over time.  Periodically the system checks with the source of truth for
    updates.  The question that really stumps me is "Who is the actor in this
    use case?"

    The obvious answer is time or the system clock.  I don't really want to do
    that because the rule of thumb that resonates best with me is that the actor
    is a party outside of the system that gets value from the use case.  Time
    gets no value from this.

    So who does?

    Well, I could say that the system does.  That would make this a use case of
    the external system, with my system as the actor, rather than a use case of
    my system.  That wouldn't really belong in my document.

    Various users benefit in that they are working with more up to date data,
    but they get that value through other use cases already written.  They do
    not participate in this use case at all.

    How do people handle this?

    Frank.

    -----
    The very act of seeking sets something in motion to meet us;
    something in the universe, or in the unconscious responds as if
    to an invitation.  - Jean Shinoda Bolen

    ************************************************************************
    * Rose Forum is a public venue for ideas and discussions.
    * For technical support, visit http://www.rational.com/support
    *
    * Admin.Subscription Requests: [EMAIL PROTECTED]
    * Archive of messages: http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
    * Other Requests: [EMAIL PROTECTED]
    *
    * To unsubscribe from the list, please send email
    *
    * To: [EMAIL PROTECTED]
    * Subject:<BLANK>
    * Body: unsubscribe rose_forum
    *
    *************************************************************************

Reply via email to