|Previous||UML Classes||Table of Contents||UML Packages||Next|
Parameter is specialized when used with complete activities.
Parameter (from Kernel , AssociationClasses ) on page 122
Parameters are extended in complete activities to add support for streaming, exceptions, and parameter sets.
Issue 9190 - change multiplicity to 0..1
• effect : ParameterEffectKind [0..1] Specifies the effect that the owner of the parameter has on values passed in or out of the parameter.
• isException : Boolean [1..1] =false Tells whether an output parameter may emit a value to the exclusion of the other outputs.
• isStream : Boolean [1..1] = false Tells whether an input parameter may accept values while its behavior is executing, or whether an output parameter post values while the behavior is executing.
No additional associations
 A parameter cannot be a stream and exception at the same time.
 An input parameter cannot be an exception.
 Reentrant behaviors cannot have stream parameters.
 Only in and inout parameters may have a delete effect. Only out, inout, and return parameters may have a create effect.
isException applies to output parameters. An output posted to an exception excludes outputs from being posted to other data
and control outputs of the behavior. A token arriving at an exception output parameter of an activity aborts all flows in
the activity. Any objects previously posted to non-stream outputs never leave the activity. Streaming outputs posted before
any exception are not affected. Use exception parameters on activities only if it is desired to abort all flows in the activity.
For example, if the same execution of an activity is being used for all its invocations, then multiple streams of tokens will
be flowing through the same activity. In this case, it is probably not desired to abort all tokens just because one reaches
an exception. Arrange for separate executions of the activity to use separate executions of the activity when employing exceptions,
so tokens from separate executions will not affect each other.
Streaming parameters give an action access to tokens passed from its invoker while the action is executing. Values for streaming
parameters may arrive anytime during the execution of the action, not just at the beginning. Multiple value may arrive on
a streaming parameter during a single action execution and be consumed by the action. In effect, streaming parameters give
an action access to token flows outside of the action while it is executing. In addition to the execution rules given at Action,
these rules also apply to invoking a behavior with streaming parameters:
• All required non-stream inputs must arrive for the behavior to be invoked. If there are only required stream inputs, then at least one must arrive for the behavior to be invoked.
• All required inputs must arrive for the behavior to finish.
Issue 8503 - add parenthetical remark
• Either all required non-exception outputs must be posted by the time the activity is finished (output of required streaming
parameters may be posted before execution finishes), or one of the exception outputs must be. An activity finishes when all
its tokens are in its output parameter nodes. If some output parameter nodes are empty at that time, they are assigned the
null token (see
Activity (from BasicActivities , CompleteActivities , FundamentalActivities ,
StructuredActivities) on page 328
), and the activity terminates.
The execution rules above provide for the arrival of inputs after a behavior is started and the posting of outputs before
a behavior is finished. These are stream inputs and outputs. Multiple stream input and output tokens may be consumed and posted
while a behavior is running. Since an activity is a kind of behavior, the above rules apply to invoking an activity, even
if the invocation is not from another activity. A reentrant behavior cannot have streaming parameters because there are potentially
multiple executions of the behavior going at the same time, and it is ambiguous which execution should receive streaming tokens.
The effect of a parameter is a declaration of the modeler’s intent, and does not have execution semantics. The modeler must
ensure that the owner of the parameter has the stated effect.
See semantics of Action and ActivityParameterNode . Also, see MultiplicityElement (from Kernel ) on page 96, which
inherits to Parameter. It defines a lower and upper bound on the values passed to parameter at runtime. A lower bound of zero
means the parameter is optional. Actions using the parameter may execute without having a value for optional parameters. A
lower bound greater than zero means values for the parameter are required to arrive sometime during the execution of the action.
See notation at Pin and ActivityParameterNode . The notation in class diagrams for exceptions and streaming parameters on operations
has the keywords exception or stream in the property string. See notation for Operation.
See examples at Pin and ActivityParameterNode .
Parameter (in Activities) is extended to support invocation of behaviors by activities.
Parameter (in Activities) is new in UML 2.0.