Activity Diagram Timed Token Emitter

[jeshaw2]

What do you suggest as a UML 2.1 Activity Diagram element for a node that emits replenishable tokens on a timed basis?

I have an activity that executes on a recurring monthly basis.  Upstream of this activity, I have a join with two incoming control flows: One from an <<datastore>> node, and the other being the timing element in question.  The downstream activity must not execute without both tokens.

The only thing I can come up with is another <<datastore>> node named Calendar and a <<selection>> behavior of Monthly.  This seems a bit awkward for such a simple concept.

[Jan ´Bary´ Glas]

If my understanding is good you need this:
From UML Superstucture 2.1 from 06-04-02

In Figure 12.27, the end-of-month accept time event action generates an output at the end of the month. Since there are no incoming edges to the time event action, it is enabled as long as its containing activity or structured node is. It will generate an output at the end of every month.

[jeshaw2]

Yes!
That is exactly the element I'm looking for.
I can't seem to find it in EA.  
Do you know where it is?

OOPS!  I Just found it, thanks.

[Jan ´Bary´ Glas]

If someone is interested:
It is an Event (Recieve) activity element changed with Advanced/Accept Time Event feature.

[jeshaw2]

If someone is interested:
It is an Event (Recieve) activity element changed with Advanced/Accept Time Event feature.

I don't think Event is defined for Activity Diagrams.  I'm using the Action element in the Activity toolbox with a Custom Property Kind of AcceptTimeEvent.  

[Jan ´Bary´ Glas]

I don't think Event is defined for Activity Diagrams.  I'm using the Action element in the Activity toolbox with a Custom Property Kind of AcceptTimeEvent.  

Yes, I agree. That what UML says.
On the other I started doing it the way I describe - I do not know why. It is time to reconsider this modelling. Thanks.  

[sargasso]

J&J

That what UML says

I'm not sure what the problem is here,  I've been using these for yonks.  I didn't think they were an actual "event"  just a notation that MyActivity receives a signal (token) when the ascribed event has occurred.

As Jan's picture indicates, all I know is that "Report Meter Reading"  has received the "End of Month" signal ... and that's all I think it needs to know.  It doesn't know who  or what sent it, nor how the other thing decided it was the end of month.  I dont think it needs to, does it?  The egg timer is nothing more than a convenience icon for the reader to get a clue as to the type of signal.  I didn't think there was any more semantics in it than that.

bruce

p.s.  Actually, Jim the more I think about this the less I am convinced that an activity that is dependent on a timer can be (logically) dependent on some other token.  If activity X fires monthly and when some other signal is present then it cannot cope with any erroneous situation where "EOM" has occurred and the other token is not present - it just wont occur.  Lets say "X" is some sort of monthly reconciliaition process, if EOM is signalled and the necessary input file(s) are not available, the process just wont occur.  The supplier processes dont know diddly about some EOM signal. The timer process dont know about some (or many) GL extract routines.  The only logical point of control is the reconciliation process itself.  It, on receiving an EOM signal looks to see if all its necessary info is available and if not emits an error signal.  If it doesn't, then it will surely just sit there until next month?

If you have a contrary example I would like to hear it.
b

p.p.s.  I will accept that there are processes that depend on more than one timer signal.  However, UML doesn't appear to give us any control over relationships between such timers.  "Ready, Aim, Fire" seems to be semantically equivalent to "Ready, Fire, Aim".  
b

[jeshaw2]

Bruce;
You may be correct for the conditions you describe for I've had the same thoughts.  However, my current conditions are different.  The node upstream of the join, in which the timer activity node participates, is not an activity node, its a <<datastore>> (Object) node.  There is a good example of the situation in Figure 15: DataStore Node

In this case, the data is always present and available at the join, so when the timer token is released to the join, it fires and its downstream activity is initiated.  If there is no data present in the <<datastore>>, the timer token is ignored by the join.

The Activity of the timer node is to listen for a broadcasted timer event which fires on a scheduled basis.

Thoughts?

-Jim

[«Midnight»]

This really is the kind of thing BPMN is good at, while UML is a bit clumsy. Given the recent merger of bpmi.org into the OMG one would hope that this would be resolved soon.

That said, the BPSM (Business Process Semantic Notation) metamodel has completely disappeared from the OMG horizon.

[sargasso]

The Activity of the timer node is to listen for a broadcasted timer event which fires on a scheduled basis.

... I can live with that.

If there is no data present in the <<datastore>>, the timer token is ignored by the join

... But this seems to be a stumbling point.  To me, it is not "ignored" per se, the recipient node will not "fire" until both tokens are present on the merge node, so  if there is no data nothing will happen until there is data.  In the case of Bock's model, if the real order of events is
1) EOM occurs, with no new employees
2) new employee is added
then the activity will fire some time in the middle of the following month when that employee is added.

While this is religiously true the UML semantic, I dont think it is pragmatic.  IOW, I wouldn't "design" a system to work that way (for that example).

Your thoughts.

bruce

[«Midnight»]

it is not "ignored" per se, the recipient node will not "fire" until both tokens are present on the merge node, so  if there is no data nothing will happen until there is data.

Once again a powerful argument for the BPMN approach. And once again a reason to hope that OMG can get going on an update to the core UML activity metamodel.

We live in hope...

[mikewhit]

"Join" - Just on terminology, you will recall that a "thread join" requires all threads to complete before it is successful.

[jeshaw2]

then the activity will fire some time in the middle of the following month when that employee is added.

 An interesting point!

I guess we need some mechanism to control how long a timer token is offered?  If it is not immediately consumed, the offer is withdrawn?

Perhaps a resettable, one-shot timer with some sort of delay on the reset action?

Raises the question of whether or not an activity can recall a token on its output pin...?

OK Bruce...how would you approach this design?

-Jim

[mikewhit]

Just a comment (probably ignorant!) in passing - surely the timer token should always be consumed and the data availability then checked.

[jeshaw2]

Just a comment (probably ignorant!) in passing - surely the timer token should always be consumed and the data availability then checked.

That would be nice, but there is no way to control the ordering of consumption and the UML Spec mandates that both tokens must be present for the join to fire.  It is silent on the life span of an unused token.  However...

Tokens are not held by a join.  Offered tokens are held by the upstream object node until they are consumed by a downstream element (such as a join).  My take would be that offered, but unconsumed, tokens are also destroyed when the object offering them is destroyed.  So some kind of behavior could be established between the timer action and the join that catches the timer-token, holds it for specified time, and then destroys it.  I know, sounds like a bit of a kluge

Better yet, perhaps a guard on the object flow edge between the timer and join.  In other usages, tokens prevented from moving by a guard don't seem to hang around in the system thus modeled.