Previous | UML Classes | Table of Contents | UML Packages | Next |
•
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.
AcceptEventAction is new in UML 2.0.