12.3.2 Action

*Generalizations

   •

    ActivityNode (from BasicActivities , CompleteActivities , FundamentalActivities , IntermediateActivities , CompleteStructuredActivities ) on page 347.

   •

    ExecutableNode (from ExtraStructuredActivities , StructuredActivities) on page 380.

   •

    Action (from BasicActions ) on page 247 (merge increment).

*Description

Issue 8207 - move contents of previous Rationale section to here

   An action represents a single step within an activity, that is, one that is not further decomposed within the activity. An activity represents a behavior that is composed of individual elements that are actions. Note, however, that a call behavior action may reference an activity definition, in which case the execution of the call action involves the execution of the referenced activity and its actions. Similarly for all the invocation actions. An action is therefore simple from the point of view of the activity containing it, but may be complex in its effect and not be atomic. As a piece of structure within an activity model, it is a single discrete element; as a specification of behavior to be performed, it may invoke referenced behavior that is arbitrarily complex. As a consequence, an activity defines a behavior that can be reused in many places, whereas an instance of an action is only used once at a particular point in an activity.

   An action may have sets of incoming and outgoing activity edges that specify control flow and data flow from and to other nodes. An action will not begin execution until all of its input conditions are satisfied. The completion of the execution of an action may enable the execution of a set of successor nodes and actions that take their inputs from the outputs of the action.

   Package CompleteActivities

   In CompleteActivities , action is extended to have pre- and postconditions.

*Attributes

   No additional attributes

*Associations

   Package CompleteActivities

Issue 8207 - add subsets constraints

• localPrecondition : Constraint [0..*] Constraint that must be satisfied when execution is started. {Subsets Element::ownedElement}

• localPostcondition : Constraint [0..*] Constraint that must be satisfied when execution is completed. {Subsets Element::ownedElement}

*Constraints

   No additional constraints

*Operations

   [1] activity operates on Action. It returns the activity containing the action.

   activity() : Activity;

   activity = if self.Activity->size() > 0 then self.Activity else self.group.activity() endif

*Semantics

   The sequencing of actions are controlled by control edges and object flow edges within activities, which carry control and object tokens respectively (see Activity). Alternatively, the sequencing of actions is controlled by structured nodes, or by a combination of structured nodes and edges. Except where noted, an action can only begin execution when all incoming control edges have tokens, and all input pins have object tokens. The action begins execution by taking tokens from its incoming control edges and input pins. When the execution of an action is complete, it offers tokens in its outgoing control edges and output pins, where they are accessible to other actions.

   The steps of executing an action with control and data flow are as follows:

Issue 8674 -insert ‘object’ before ‘flow’

   [1] An action execution is created when all its object flow and control flow prerequisites have been satisfied (implicit join). Exceptions to this are listed below. The object flow prerequisite is satisfied when all of the input pins are offered tokens and accept them all at once, precluding them from being consumed by any other actions. This ensures that multiple action executions competing for tokens do not accept only some of the tokens they need to begin, causing deadlock as each execution waits for tokens that are already taken by others.

   [2] An action execution consumes the input control and object tokens and removes them from the sources of control edges and from input pins. The action execution is now enabled and may begin execution. If multiple control tokens are available on a single edge, they are all consumed.

   [3] An action continues executing until it has completed. Most actions operate only on their inputs. Some give access to a wider context, such as variables in the containing structured activity node, or the self object, which is the object owning the activity containing the executing action. The detailed semantic of execution an action and definition of completion depends on the particular subclass of action.

   [4] When completed, an action execution offers object tokens on all its output pins and control tokens on all its outgoing control edges (implicit fork), and it terminates. Exceptions to this are listed below. The output tokens are now available to satisfy the control or object flow prerequisites for other action executions.

   [5] After an action execution has terminated, its resources may be reclaimed by an implementation, but the details of resource management are not part of this specification and are properly part of an implementation profile.

   See ValuePin and Parameter for exceptions to rule for starting action execution.

Issue 8207 -remove extraneous ‘tokens’

   If a behavior is not reentrant, then no more than one execution of it will exist at any given time. An invocation of a non-reentrant behavior does not start the behavior when the behavior is already executing. In this case, control tokens are discarded, and data tokens collect at the input pins of the invocation action, if their upper bound is greater than one, or upstream otherwise. An invocation of a reentrant behavior will start a new execution of the behavior with newly arrived tokens, even if the behavior is already executing from tokens arriving at the invocation earlier.

   Package ExtraStructuredActivities

   If an exception occurs during the execution of an action, the execution of the action is abandoned and no regular output is generated by this action. If the action has an exception handler, it receives the exception object as a token. If the action has no exception handler, the exception propagates to the enclosing node and so on until it is caught by one of them. If an exception propagates out of a nested node (action, structured activity node, or activity), all tokens in the nested node are terminated. The data describing an exception is represented as an object of any class.

   Package CompleteActivities

   Streaming allows an action execution to take inputs and provide outputs while it is executing. During one execution, the action may consume multiple tokens on each streaming input and produce multiple tokens on each streaming output. See Parameter.

   Local preconditions and postconditions are constraints that should hold when the execution starts and completes, respectively. They hold only at the point in the flow that they are specified, not globally for other invocations of the behavior at other places in the flow or on other diagrams. Compare to pre and postconditions on Behavior (in Activities). See semantic variations below for their effect on flow.

*Semantic Variation Points

   Package CompleteActivities

   How local pre- and postconditions are enforced is determined by the implementation. For example, violations may be detected at compile time or runtime. The effect may be an error that stops the execution or just a warning, and so on. Since local pre and postconditions are modeler-defined constraints, violations do not mean that the semantics of the invocation is undefined as far as UML goes. They only mean the model or execution trace does not conform to the modeler’s intention (although in most cases this indicates a serious modeling error that calls into question the validity of the model).

   See variations in ActivityEdge and ObjectNode.

*Notation

   Use of action and activity notation is optional. A textual notation may be used instead.

   Actions are notated as round-cornered rectangles. The name of the action or other description of it may appear in the symbol. See children of action for refinements.

   Figure 12.28 - Action

   Package CompleteActivities

   Local pre- and postconditions are shown as notes attached to the invocation with the keywords «localPrecondition» and «localPostcondition», respectively.

*Examples

   Examples of actions are illustrated below. These perform behaviors called Send Payment and Accept Payment.

   Figure 12.30 - Examples of actions

   Below is an example of an action expressed in an application-dependent action language:

   Package CompleteActivities

   The example below illustrates local pre- and postconditions for the action of a drink-dispensing machine. This is considered local because a drink-dispensing machine is constrained to operate under these conditions for this particular action. For a machine technician scenario, the situation would be different. Here, a machine technician would have a key to open up the machine, and therefore no money need be inserted to dispense the drink, nor change need be given. In such a situation, the global pre- and postconditions would be all that is required. (Global conditions are described in Activity specification, in the next subsection.) For example, a global precondition for a Dispense Drink activity could be A drink is selected that the vending machine dispenses. The postcondition, then, would be The vending machine dispensed the drink that was selected. In other words, there is no global requirement for money and correct change.

Issue 8207 - move contents of Rationale section to Description

*Changes from previous UML

   Explicitly modeled actions as part of activities are new in UML 2.0, and replace ActionState, CallState, and SubactivityState in UML 1.5. They represent a merger of activity graphs from UML 1.5 and actions from UML 1.5.

   Local pre and postconditions are new to UML 2.0.