Issue 13166: Section: Base Semantics (fuml-rtf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Significant Summary: SendSignalAction completion semantics. SendSignalAction shouldn't require the event pool to be updated before the action completes. Resolution: Add active behavior to EventOccurrence Adding an event occurrence into the event pool of the target should always be done in a separate execution thread than that of the sender of the event occurrence. Not only does this better model the asynchronous nature of signal sends, it also better models the semantics of inter-object communication in general, as discussed in 2.4 Genericity of the Execution Model, even for, say, call event occurrences. That is because the semantics of concurrency in fUML allows for arbitrary sequential or parallel ordering of the execution of concurrent behaviors. Therefore, having concurrent threads for actually sending each event occurrence to the target better models the possibility that concurrent sends may be arbitrarily re-ordered, or even potentially lost (if the execution of a send behavior ends up being postponed, say, until sequentially after its target object has been destroyed). Revised Text: Make the following changes in the specification document and in the normative fUML Semantics XMI. (This resolution presumes the resolutions to issues [1]FUML13-25 and [2]FUML13-23.) In 8.4.3.1 Overview, under Event Occurrences, after the first paragraph, insert the following: The EventOccurrence class is also an active class in the execution model, in a similar way to ObjectActivation, as described above. When an event occurrence is sent using the sendTo operation of EventOccurrence, the event occurrence classifier behavior is started asynchronously and the event occurrence sends a SendSignal to itself. When the classifier behavior asynchronously receives the SendSignal, it carries out the actual sending of the event occurrence to the target object, resulting in the event occurrence being placed in the target object event pool. Thus, not only is the dispatching of the event occurrence asynchronously decoupled from the receipt of the event occurrence, but actual transmission of the event occurrence to the target object is asynchronously decoupled from the execution that initiated the sending of the event occurrence. Note: The above model of the sending of event occurrences supports the general approach to the semantics of inter-object communications in fUML (see 2.4). Since each event occurrence is sent using a concurrently executing behavior in the execution model, the semantics of concurrency (as also discussed in 2.4) allows event occurrences that have been sent concurrently to be arbitrarily re-ordered in time before delivery or arbitrarily delayed in time relative to the concurrent execution of the target object event dispatch loop behaviors. This is consistent with the allowed possibility that inter-object communication may not be reliable or deterministic. At the end of the third paragraph (beginning "To start a classifier behavior"), add the following sentence: (Note that an invocation event occurrence is not sent using the asynchronous EventOccurrence behavior, as described above for signal and call event occurrences, but is placed directly into the event pool of the context object of the classifier behavior execution.) In Figure 8.16 Event Occurrences, add the signal SendSignal. Show that the class EventOccurrence is active with the classifier behavior SendBehavior, and add the following operation to it: + sendTo(in target: Reference) Add a directed association from EventOccurrence to Reference with an association end + target having multiplicity 0..1 and opposite end multiplicity *. Editorial Note. The resolution to [3]FUML13-16 would change the subclause number for EventOccurrence referenced below to 8.4.3.2.6. In 8.4.3.2.3 EventOccurrence, add Figure 8-18 Classifier Behavior for EventOccurrence with the attached diagram: and renumber subsequent figures appropriately. Under Associations, replace "None" with: *target : Reference [0..1] A reference to the target object to which this event occurrence is being sent. Under Operations, add the following operation: [4] sendTo ( in target : Reference ) this.target = target; _startObjectBehavior(); _send(new SendSignal()); Editorial Note. The number of this operation is consistent with the revisions made in the resolution to issue [4]FUML13-25. In 8.6.2.2.9 SendSignalActionActivation, under Operations, in the operation doAction, change the statement ((Reference)target).send(signalEventOccurrence); to signalEventOccurrence.sendTo((Reference)target); Editorial Note. This statement was previously updated in the resolution to issue [5]FUML13-23. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/FUML13-25 [2] http://issues.omg.org/browse/FUML13-23 [3] http://issues.omg.org/browse/FUML13-16 [4] http://issues.omg.org/browse/FUML13-25 [5] http://issues.omg.org/browse/FUML13-23 Actions taken: December 18, 2008: received issue January 7, 2013: Deferred December 22, 2015: closed issue April 6, 2017: Resolved Discussion: End of Annotations:===== m: webmaster@omg.org Date: 18 Dec 2008 11:49:54 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Notification: No Specification: Semantics of a Foundational Subset of Executable UML Models Section: Base Semantics FormalNumber: ptc/08-11-03 Version: RevisionDate: Page: Nature: Revision Severity: Significant HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080219 Firefox/2.0.0.12 Navigator/9.0.0.6 Description SendSignalAction completion semantics. SendSignalAction shouldn't require the event pool to be updated before the action completes.