Previous UML Classes Table of Contents UML Packages Next

11.3.2 AcceptEventAction




    Action (from BasicActions ) on page 247


   AcceptEventAction is an action that waits for the occurrence of an event meeting specified condition.


   • isUnmarshall : Boolean = false Indicates whether there is a single output pin for the event, or multiple output pins for attributes of the event.


• trigger : Trigger [1..*] The type of events accepted by the action, as specified by triggers. For triggers with signal events, a signal of the specified type or any subtype of the specified signal type is accepted.

Issue 8146 - add subsets constraint

• result: OutputPin [0..*] Pins holding the received event objects or their attributes. Event objects may be copied in transmission, so identity might not be preserved. {Subsets Action::output}


   [1] AcceptEventActions may have no input pins.

Issue 8146 -add more details to the constraint

   [2] There are no output pins if the trigger events are only ChangeEvent s, or if they are only CallEvent s when this action is an instance of AcceptEventAction and not an instance of a descendant of AcceptEventAction (such as AcceptCallAction ).

   [3] If the trigger events are all TimeEvents, there is exactly one output pin.

   [4] If isUnmarshalled is true, there must be exactly one trigger for events of type SignalEvent . The number of result output pins must be the same as the number of attributes of the signal. The type and ordering of each result output pin must be the same as the corresponding attribute of the signal. The multiplicity of each result output pin must be compatible with the multiplicity of the corresponding attribute.


   Accept event actions handle event occurrences detected by the object owning the behavior (also see InterruptibleActivityRegion (from CompleteActivities ) on page 394). Event occurrences are detected by objects independently of actions and the occurrences are stored by the object. The arrangement of detected event occurrences is not defined, but it is expected that extensions or profiles will specify such arrangements. If the accept event action is executed and the object detected an event occurrence matching one of the triggers on the action and the occurrence has not been accepted by another action or otherwise consumed by another behavior, then the accept event action completes and outputs a value describing the occurrence. If such a matching occurrence is not available, the action waits until such an occurrence becomes available, at which point the action may accept it. In a system with concurrency, several actions or other behaviors might contend for an available event occurrence. Unless otherwise specified by an extension or profile, only one action accepts a given occurrence, even if the occurrence would satisfy multiple concurrently executing actions.

Issue 8146 -replace ‘unmarshall’ with ‘isUnmarshall’

   If the occurrence is a signal event occurrence and isUnmarshall is false, the result value contains a signal object whose reception by the owning object caused the occurrence. If the occurrence is a signal event occurrence and isUnmarshall is true, the attribute values of the signal are placed on the result output pins of the action. Signal objects may be copied in transmission and storage by the owning object, so identity might not be preserved. An action whose trigger is a SignalTrigger is informally called an accept signal action. If the occurrence is a time event occurrence, the result value contains the time at which the occurrence transpired. Such an action is informally called a wait time action. If the occurrences are all occurrences of ChangeEvent , or all CallEvent , or a combination of these, there are no output pins (however, see AcceptCallAction (from CompleteActions ) on page 244). See CommonBehavior for a description of Event specifications. If the triggers are a combination of SignalEvent s and ChangeEvent s, the result is a null value if a change event occurrence or a call event occurrence is accepted.

   This action handles asynchronous messages, including asynchronous calls. It cannot be used with synchronous calls (except see AcceptCallAction (from CompleteActions ) on page 244).


   An accept event action is notated with a concave pentagon. A wait time action is notated with an hour glass.

   Accept event action Accept time event action

   Figure 11.21 - Accept event notations.


    AcceptEventAction (as specialized) on page 321

   Accept event actions are introduced to handle processing of events during the execution of a behavior.

*Changes from previous UML

   AcceptEventAction is new in UML 2.0.