My comments below.
I just wanted to note that consuming the results should be done by another usecase. The possibility that the usecase is not executed is no Eeles, Peter wrote: > Since use-cases are always initiated by an actor, then we need an actor! > One option is to introduce an actor such as a Timer. This is a common > technique for representing time-based actions. > A timer provokes the system through events but we cannot deliver value to the timer, as we would a clerk or an insurance agent. There are many things that could be assigned to the timer as an implementation decision. When talking about value delivered, avoid timers or probes or other inanimate sources of events. Depending on the context, you could just as easily and rightly avoid all discussion of the timers with users. In others, the users are concerned about the system response so it is a first class usecase. For example, when you are doing something periodically to enhance performance or response time, this timer is an implementation detail and should be treated as such (i.e no separate use case outside of development). In any event, these timer usecases should be as light as possible. The value should be represented in the usecases for actors that can appreciate the value delivered. Then it becomes a moot point whether the actions are used. They are assigned to a usecase and the actor didn't execute it. If there is lots of commonality around the timer use case (formating, notification...) then the functionality can be refactored during design. The requirements should remain the same. > > -----Original Message----- > From: Tomer Lev [mailto:[EMAIL PROTECTED]] > Sent: 13 January 2002 07:32 > To: [EMAIL PROTECTED] > Subject: (ROSE) Periodic Internal Action - Use case specification answer > > Hi , A question for the Forum. > > When describing a system with specifying Use cases, as we all do, > what is your favorite way to deal with Internal periodic actions > that no actor initiates (and some actor might-or might not- consume > the action results later). > > There are many examples for such actions: > > + Periodic internal functioning tests. > > + Collection of received, but not yet handled, data/communication. > > and so on. > > > > your educated opinions are welcome. > > Thanks > > Tomer > > > Tomer Lev > SW Team Leader > Taldor-Tici Software Systems. > Voice: 972-8-9484876 > Fax: 972-8-9484897 > Email: [EMAIL PROTECTED] > http://www.tici.co.il <http://www.tici.co.il/> > Mailing Address: > 10 Plaut St. Tamar science Park > P.O.B 2244 Rehovot 76122, ISRAEL > > > > > -- Neil Pitman [EMAIL PROTECTED] +1.514.863.5465 ************************************************************************ * Rose Forum is a public venue for ideas and discussions. * For technical support, visit http://www.rational.com/support * * Post or Reply to: [EMAIL PROTECTED] * Subscription Requests: [EMAIL PROTECTED] * Archive of messages: * http://www.rational.com/support/usergroups/rose/rose_forum.jsp * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send email * To: [EMAIL PROTECTED] * Subject: <BLANK> * Body: unsubscribe rose_forum *************************************************************************
