Issue 4937:  Sending a signal after a delay (uml2-rtf)
Source: Mentor Graphics Corporation (Mr. Stephen J. Mellor, StephenMellor(at)StephenMellor.com)
Nature: Uncategorized Issue
Severity: 
Summary:  Sending a signal after a delay
Resolution: The feature requested is already supported in UML 2.1: Precede an action by an AcceptEventAction, where the latter references a trigger that refers to a TimeEvent. Thus, for example, if you have a sequence of an AcceptEventAction with a TimeEvent specifyinig the desired delay and a SendSignalAction, then the signal will not be sent until the delay has passed. Note that this feature is extremely generic, probably giving the user even too much support (you can define a statemachine purely with actions, if there are not proper constraint placed on the events allowed in the AcceptEventAction).
Revised Text: closed no change
Actions taken:
March 5, 2002: received issue
October 22, 2002: deferred
October 27, 2008: closed issue
Discussion: 
Can't handle time the way state machines, with expressions, because
  action model needs to be more precise.
Why not on other actions besides SendSignalAction?
What is the relation to the time submission?
Too much for FTF. [Action Semantics FTF]: Can't handle time the way state machines, with expressions,
because action model needs to be more precise. Why not on other actions besides
SendSignalAction? What is the relation to the time submission? Too much for FTF.
Too much of an enhancement for FTF, as indicated in the issue report. In the meantime,
modelers can define actions for time delay.

End of Annotations:=====
Summary: Sending a signal after a delay

Text: 

Issue 4937: Sending a signal after a delay              Actions Ian W.
http://www.omg.org/issues/issue4937.txt
yourdirectory/uml2-superstructure-ftf.open.html#Issue4937


Deferred


Too much of an enhancement for FTF, as indicated in the issue report.
In the meantime, modelers can define actions for time delay.
[Steve Mellor]  Sending a signal after a delay (Steve).