Class  Descriptions


 AcceptCallAction

(CompleteActions) AcceptCallAction is an accept event action representing the receipt of a synchronous call request. In addition to the normal operation parameters, the action produces a output token that is needed later to supply the information to the ReplyAction necessary to return control to the caller.

This action is for synchronous calls. If it is used to handle an asynchronous call, execution of the subsequent reply action will complete immediately with no effects.

Attributes

None.

Associations
  • trigger: CallTrigger
The operation call trigger accepted by the action.
  • returnInformation: OutputPin [1..1]
Pin where a token is placed containing sufficient information to perform a subsequent reply and return control to the caller. The value in this token is opaque. It can be passed and copied but it cannot be manipulated by the model.

Constraints

[1] The result pins must match the in and inout parameters of the call trigger operation in number, type, and order.

Semantics

This action accepts events representing the receipt of calls on the operation specified by the call trigger. If an ongoing activity has executed an accept call action that has not completed and the owning object has an event representing a call of the specified activity, the accept call action claims the event and removes it from the owning object. If several accept call actions concurrently request a call on the same operation, it is unspecified which one claims the event, but one and only one action will claim the event. The argument values of the call are placed on the result output pins of the action. Information sufficient to perform a subsequent reply action is placed in a token on the returnInformation output pin. The execution of the accept call action is then complete. This return information token flows like any other data token, but the information in it is opaque andmay not be manipulated by any actions. It only has meaning to ReplyAction.

Note that the target class must not define a method for the operation being received. Otherwise, the operation call will be dispatched to that method instead of being put in the event buffer to be handled by AcceptCallAction. In general, classes determine how operation calls are handled, namely by a method, by a behavior owned directly by the class, by a state machine transition, and so on. The class must ensure that the operation call is handled in a way that AcceptCallAction has access to the call event.

 AcceptEventAction

(CompleteActions) AcceptEventAction is an action that waits for the occurrence of an event meeting specified conditions.

Attributes

none

Associations

  • trigger : Trigger [1]
The type of event accepted by the action, as specified by a trigger. If it is a signal trigger, a signal of any subtype of the specified signal type is accepted.
  • result: OutputPin [1]
Pin holding the event object that has been received. Event objects may be copied in transmission, so identity might not be preserved.

Constraints

[1] Only control edges may target an AcceptEventAction.

[2] If the trigger is a ChangeTrigger, there are no output pins. Same is true for CallTrigger if this class is AcceptCallAction and not one of its children.

[3] If the trigger is a SignalTrigger or a TimeTrigger, there is exactly one output pin.

Semantics

Accept event actions handle events detected by the object owning the activity. Events are detected by objects independently of actions and the events are stored by the object. The arrangement of detected events 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 matching the specification on the action and the event has not been accepted by another action or otherwise consumed by
another behavior, then the accept signal action completes and outputs a token describing the event. If such a matching event is not available, the action waits until such an event 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. Unless otherwise specified by an extension or profile, only one action accepts a given event, even if the event would satisfy multiple concurrently executing
actions.

If the event is a SignalEvent, the result token contains a signal object whose reception by the owning object caused the event.

Signal objects may be copied in transmission and storage by the owning object, so identity might not be preserved. An action whose event is a signal event is informally called an accept signal action. If the event is a TimeEvent, the result token contains the time at which the event occurred. Such an action is informally called a wait time action. If the event is a ChangeEvent ot a CallEvent, the result is a control token, there are no output pins. See CommonBehavior for a description of Event specifications.

If an AcceptEventAction has no incoming edges, then the action starts when the containing activity or structured node does. In addition, an AcceptEventAction with no incoming edges is always enabled to accept events, no matter how many it accepts. It does not terminate after accepting an event and outputing a value, but continues to wait for other events. This semantic is an exception to the normal execution rules in Activities.

This action handles asynchronous messages, including asynchronous calls. If it is used for a synchronous call with no return parameters, an immediate reply is sent with no parameters. If it is used for a synchronous call with return parameters, it is an error and the system behavior is unspecified.

Notation

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


Examples

Figure 157 is an example of the acceptance of a signal indicating the cancellation of an order. The acceptance of the signal causes an invocation of a cancellation behavior. This action is enabled on entry to the activity containing it, therefore no input arrow is shown. In many cases, the arrow from such a signal will be an interrupting edge (CompleteActions).



In Figure 158, a request payment signal is sent after an order is processed. The activity then waits to receive a payment confirmed signal. Acceptance of the payment confirmed signal is enabled only after the request for payment is sent; no confirmation is accepted until then. When the confirmation is received, the order is shipped.



In Figure 159, the end-of-month accept time event action generates an output at the end of the month. Since there are no incoming edges to the time event action, it is enabled as long as its containing activity or structured node is. It will generate an output at the end of every month.


Rationale

Accept event actions are introduced to handle processing of events during the execution of an activity.

Changes from previous UML

AcceptEventAction is new in UML 2.0.

 AddStructuralFeatureValueAction

AddStructuralFeatureValueAction is a write structural feature action for adding values to a structural feature.

Description

Structural Features are potentially multi-valued and ordered, so the action supports specification of insertion points for new values. It also supports the removal of existing values of the structural feature before the new value is added.

The object to access is specified dynamically, by referring to an input pin on which the object will be placed at runtime. The type of the value of this pin is the classifier that owns the specified structural feature, and the value's multiplicity is 1..1.

Attributes
Associations

insertAt : InputPin [0..1] (Specialized from Action:input) Gives the position at which to insert a new value or move an existing value in ordered structural features. The type of the pin is UnlimitedNatural, but the value cannot be zero. This pin is omitted for unordered structural features.

Constraints

[1] Actions adding a value to ordered structural features must have a single input pin for the insertion point with type UnlimitedNatural and multiplicity of 1..1, otherwise the action has no input pin for the insertion point.

    let insertAtPins : Collection = self.insertAt in
        if self.structuralFeature.isOrdered = #false
        then insertAtPins->size() = 0
        else let insertAtPin : InputPin= insertAt->asSequence()->first() in
                insertAtPins->size() = 1
                and insertAtPin.type = UnlimitedNatural
                and insertAtPin.multiplicity.is(1,1))
        endif

Semantics

If isReplaceAll is true, then the existing values of the structural feature are removed before the new one added, except if the new value already exists, then it is not removed under this option. If isReplaceAll is false, then adding an existing value has no effect.

Values of a structural feature may be ordered or unordered, even if the multiplicity maximum is 1.Adding values to ordered structural features requires an insertion point for a new value using the insertAt input pin. The insertion point is a positive integer giving the position to insert the value, or infinity, to insert at the end.. A positive integer less than or equal to the current number of values means to insert the new value at that position in the sequence of existing values, with the integer one
meaning the new value will be first in the sequence. A value of infinity for insertAt means to insert the new value at the end of  the sequence. The semantics is undefined for a value of zero or an integer greater than the number of existing values. The insertion point is required for ordered structural features and omitted for unordered structural features. Reinserting an existing value at a new position moves the value to that position (this works because structural feature values are sets).

The semantics is undefined for adding a value that violates the upper multiplicity of the structural feature. Removing a value succeeds even when that violates the minimum multiplicity--the same as if the minimum were zero. The modeler must determine when minimum multiplicity of structural features should be enforced.
The semantics is undefined for adding a new value for a structural feature with settability readOnly or removeOnly after initialization of the owning object.

Notation

None.

Examples

Rationale

AddStructuralFeatureValueAction is introduced to add structural feature values. isReplaceAll is introduced to replace and add in a single action, with no intermediate states of the object where only some of the existing values are present.

Changes from previous UML

AddStructuralFeatureValueAction is new in UML 2.0. It generalizes AddAttributeAction in UML 1.5.

 AddVariableValueAction

AddVariableValueAction is a write variable action for adding values to a variable.

Description

Variables are potentially multi-valued and ordered, so the action supports specification of insertion points for new values. It also supports the removal of existing values of the variable before the new value is added.

Attributes

Associations

  • insertAt : InputPin [0..1]
(Specialized from Action:input) Gives the position at which to insert a new value or move an existing value in ordered variables. The types is UnlimitedINatural, but the value cannot be zero. This pin is omitted for unordered variables.

Constraints

[1] Actions adding values to ordered variables must have a single input pin for the insertion point with type UnlimtedNatural and multiplicity of 1..1, otherwise the action has no input pin for the insertion point.

    let insertAtPins : Collection = self.insertAt in
        if self.variable.ordering = #unordered
        then insertAtPins->size() = 0
        else let insertAtPin : InputPin = insertAt->asSequence()->first() in
                    insertAtPins->size() = 1
                    and insertAtPin.type = UnlimitedNatural
                    and insertAtPin.multiplicity.is(1,1))
        endif

Semantics

If isReplaceAll is true, then the existing values of the variable are removed before the new one added, except if the new value already exists, then it is not removed under this option. If isReplaceAll is false, then adding an existing value has no effect.

Values of an variable may be ordered or unordered, even if the multiplicity maximum is 1.Adding values to ordered variables requires an insertion point for a new value using the insertAt input pin. The insertion point is a positive integer giving the position to insert the value, or infinity, to insert at the end.. A positive integer less than or equal to the current number of values means to insert the new value at that position in the sequence of existing values, with the integer one meaning the new value will be first in the sequence. A value of infinity for insertAt means to insert the new value at the end of the sequence. The semantics is undefined for a value of zero or an integer greater than the number of existing values. The insertion point is required for ordered variables and omitted for unordered variables. Reinserting an existing value at a new position moves the value to that position (this works because variable values are sets).

The semantics is undefined for adding a value that violates the upper multiplicity of the variable. Removing a value succeeds even when that violates the minimum multiplicity--the same as if the minimum were zero. The modeler must determine when minimum multiplicity of variables should be enforced.

Notation

None.

Examples

Rationale

AddVariableValueAction is introduced to add variable values. isReplaceAll is introduced to replace and add in a single action, with no intermediate states of the variable where only some of the existing values are present.

Changes from previous UML

AddVariableValueAction is unchanged from UML 1.5.

ApplyFunctionAction

Description

ApplyFunctionAction is an action that invokes a primitive predefined function that computes output values based only on the input values and the function. The execution does not have access to object memory or to any objects. The execution of a primitive function has no side effects on any other object.

Attributes

None.

Associations

Stereotypes

None.

Tagged Values

None.

Constraints

[1] The number and types of the input arguments and output result pins are derived from the parameters of the function.

self.argument->size( ) = self.function.formalParameter->size( )
    and Sequence {1..self.argument->size( )}
        -> forAll (i:Integer |
                let argumenti = self.argument->at(i) in
                        let inparameteri = self.function.formalParameter->at(i) in
                                argumenti.type = inparameteri.type)
    and self.result->size( ) = self.function.returnedResult->size( )
    and Sequence {1..self.result->size( )}
            -> forAll (i:Integer |
                  let resulti = self.result->at(i) in
                          let outparameteri = self.function.returnedResult>at(i) in
                                    resulti.type = outparameteri.type)

Semantics

The result values are computed from the input values according to the given function. During the execution of the computation, no communication or interaction with the rest of the system is possible. The amount of time to compute the results is undefined.

The result values are placed on the output pins of the action execution and the execution of the apply function action is complete. Primitive functions may raise exceptions for certain input values, in which case the computation is abandoned.

Notation

None.

Presentation Option

None.

Examples

None.

Rationale

ApplyFunctionAction is introduced to invoke behaviors that are external to the modeled system.

Changes from previous UML

Same as UML 1.5.

BroadcastSignalAction

Description

BroadcastSignalAction is an action that transmits a signal instance to all the potential target objects in the system, which may cause the firing of a state machine transitions or the execution of associated activities of a target object. The argument values are available to the execution of associated behaviors. The requestor continues execution immediately. Any reply messages are ignored and are not transmitted to the requestor.

Attributes

None

Associations
Constraints

[1] The number and order of argument pins must be the same as the number and order of attributes in the signal.

[2] The type, ordering, and multiplicity of an argument pin must be the same as the corresponding attribute of the signal.

Semantics

When all the control and data flow prerequisites of the action execution are satisfied, a signal object is generated from the argument values according to signal and this signal object is transmitted concurrently to each of the implicit broadcast target objects in the system. The manner of identifying the set of objects that are broadcast targets is a semantic variation point and may be limited to some subset of all the objects that exist. There is no restriction on the location of target objects. The manner of transmitting the signal object, the amount of time required to transmit it, the order in which the transmissions reach the various target objects, and the path for reaching the target objects are undefined.

[1] When a transmission arrives at a target object, it may invoke a behavior in the target object. The effect of receiving such transmission is specified in Chapter 13, "Common Behaviors". Such effects include executing activities and firing state machine transitions.

[2] A broadcast signal action receives no reply from the invoked behavior; any attempted reply is simply ignored, and no transmission is performed to the requestor.

Semantic Variation Point

The determination of the set of broadcast target objects is a semantic variation point.

Notation

None.

Examples

None

Rationale

Sends a signal to a set of system defined target objects.

Changes from previous UML

Same as UML 1.5.

 CallAction

CallAction is an abstract class for actions that invoke behavior and receive return values.

Attributes
  • isSynchronous: Boolean
If true, the call is synchronous and the caller waits for completion of the invoked behavior. If false, the call is asynchronous and the caller proceeds immediately and does not expect a return values.

Associations

Constraints

[1] Only synchronous call actions can have result pins.

Semantics

See children of CallAction.

CallBehaviorAction

Description

CallBehaviorAction is a call action that invokes a behavior directly rather than invoking a behavioral feature that, in turn, results in the invocation of that behavior. The argument values of the action are available to the execution of the invoked behavior. The execution of the call behavior action waits until the execution of the invoked behavior completes and a result is returned on its output pin. In particular, the invoked behavior may be an activity.

Attributes

None.

Associations
Constraints

[1] The number of argument pins and the number of parameters of the behavior of type in and in-out must be equal.

[2] The number of result pins and the number of parameters of the behavior of type return, out, and in-out must be equal.

[3] The type, ordering, and multiplicity of an argument or result pin is derived from the corresponding parameter of the behavior.

Semantics

[1] When all the control and data flow prerequisites of the action execution are satisfied, CallBehaviorAction consumes its input tokens and invokes its specified behavior. The values in the input tokens are made available to the invoked behavior as argument values. When the behavior is finished, tokens are offered on all outgoing control edges, with a copy made for each control edge. Object and data tokens are offered on the outgoing object flow edges as determined by the output pins.
Each parameter of the behavior of the action provides input to a pin or takes output from one. See Pin. The inputs to the action determine the actual arguments of the call.

[2] If the call is asynchronous, a control token is offered to each outgoing control edge of the action and execution of the action is complete. Execution of the invoked behavior proceeds without any further dependency on the execution of the activity containing the invoking action. Once the invocation of the behavior has been initiated, execution of the asynchronous action is complete.

[3] An asynchronous invocation completes when its behavior is started, or is at least ensured to be started at some point.When an asynchronous invocation is done, the flow continues regardless of the status of the invoked behavior. For example, the containing activity may complete even though the invoked behavior is not finished. This is why asynchronous invocation is not the same as using a fork to invoke the behavior followed by a flow final. A forked behavior still needs to
finish for the containing activity to finish. If it is desired to complete the invocation, but have some outputs provided later when they are needed, then use a fork to give the invocation its own flow line, and rejoin the outputs of the invocation to the original flow when they are needed.

[4] If the call is synchronous, execution of the calling action is blocked until it receives a reply token from the invoked behavior. The reply token includes values for any return, out, or inout parameters.

[5] If the call is synchronous, when the execution of the invoked behavior completes, the result values are placed as object tokens on the result pins of the call behavior action, a control token is offered on each outgoing control edge of the call behavior action, and the execution of the action is complete. (CompleteActions, ExtraActivities) If the execution of the invoked behavior yields an exception, the exception is transmitted to the call behavior action where it is presented on a
declared exception pin as an exception token, and the action delivers no normal object or control tokens. If no exception pin is declared, the exception is propagated to an enclosing scope.

Notation

The name of the behavior, or other description of it, that is performed by the action is placed inside the rectangle. If the node name is different than the behavior name, then it appears in the symbol instead.

Presentation Option

The call of an activity is indicated by placing a rake-style symbol within the symbol. The rake resembles a miniature hierarchy, indicating that this invocation starts another activity that represents a further decomposition. An alternative notation in the case of an invoked activity is to show the contents of the invoked activity inside a large round-cornered rectangle. Edges flowing into the invocation connect to the parameter object nodes in the invoked activity. The parameter object nodes are
shown on the border of the invoked activity. The model is the same regardless of the choice of notation. This assumes the UML 2.0 Diagram Interchange RFP supports the interchange of diagram elements and their mapping to model elements.



Below is an example of invoking an activity called FillOrder


Examples

Rationale

Invokes a behavior directly without the need for a behavioral feature.

Changes from previous UML

Same as UML 1.5.

CallOperationAction

Description

CallOperationAction is an action that transmits an operation call request to the target object, where it may cause the invocation of associated behavior. The argument values of the action are available to the execution of the invoked behavior. If the action is marked synchronous, the execution of the call operation action waits until the execution of the invoked behavior completes and a reply transmission is returned to the caller; otherwise execution of the action is complete when the invocation of the operation is established and the execution of the invoked operation proceeds concurrently with the execution of the calling activity. Any values returned as part of the reply transmission are put on the result output pins of the call operation action.

Upon receipt of the reply transmission, execution of the call operation action is complete.

Attributes

None.

Associations

  • operation: Operation [1]
The operation to be invoked by the action execution
  • target: InputPin [1]
The target object to which the request is sent. The classifier of the target object is used to dynamically determine a behavior to invoke. This object constitutes the context of the execution of the operation.

Constraints

[1] The number of argument pins and the number of formal parameters of the operation of type in and in-out must be equal.

[2] The number of result pins and the number of formal parameters of the operation of type return, out, and in-out must be mequal.

[3] The type, ordering, and multiplicity of an argument or result pin is derived from the corresponding formal parameter of the operation.

[4] The type of the target pin must be the same as the type that owns the operation.

Semantics

The inputs to the action determine the target object and additional actual arguments of the call.

[1] When all the control and data flow prerequisites of the action execution are satisfied, information comprising the operation and the argument pin values of the action execution is created and transmitted to the target object. The target objects may be local or remote. The manner of transmitting the call, the amount of time required to transmit it, the order in which the transmissions reach the various target objects, and the path for reaching the target objects are undefined.

[2] When a call arrives at a target object, it may invoke a behavior in the target object. The effect of receiving such call is specified in Chapter 13, "Common Behaviors". Such effects include executing activities and firing state machine transitions.

[3] If the call is synchronous, when the execution of the invoked behavior completes, its return results are transmitted back as a reply to the calling action execution. The manner of transmitting the reply, the time required for transmission, the representation of the reply transmission, and the transmission path are unspecified. If the execution of the invoked behavior yields an exception, the exception is transmitted to the caller where it is reraised as an exception in the execution of the
calling action. Possible exception types may be specified by attaching them to the called Operation using the raisedException association.

[4] If the call is asynchronous, the caller proceeds immediately and the execution of the call operation action is complete. If the call is synchronous, the caller is blocked from further execution until it receives a reply from the invoked behavior.

[5] When the reply transmission arrives at the invoking action execution, the return result values are placed on the result pins of the call operation action, and the execution of the action is complete.

Semantic Variation Points

The mechanism for determining the method to be invoked as a result of a call operation is unspecified.

Notation

The name of the operation, or other description of it, is displayed in the symbol.


Presentation Option

If the node has a different name than the operation, then this is used in the symbol instead. The name of the class may optionally appear below the name of the operation, in parentheses postfixed by a double colon. If the node name is different than the operaiton name, then the behavioral feature name may be shown after the double colon.



Examples

None

Rationale

Calls an operation on a specified target object.

Changes from previous UML

Same as UML 1.5.

ClearAssociationAction

ClearAssociationAction is an action that destroys all links of an association in which a particular object participates.

Description

This action destroys all links of an association that have a particular object at one end.

Attributes

None.

Associations
Constraints

[1] The type of the input pin must be the same as the type of at least one of the association ends of the association.

self.association->exists(end.type = self.object.type)

[2] The multiplicity of the input pin is 1..1.

self.object.multiplicity.is(1,1)

Semantics

This action has a statically-specified association. It has an input pin for a runtime object that must be of the same type as at least one of the association ends of the association. All links of the association in which the object participates are destroyed even when that violates the minimum multiplicity of any of the association ends. If the association is a class, then link object identities are destroyed.

Notation

None.

Examples

Rationale

ClearAssociationAction is introduced to remove all links from an association in which an object participates in a single action, with no intermediate states where only some of the existing links are present.

Changes from previous UML

ClearAssociationAction is unchanged from UML 1.5.

ClearStructuralFeatureAction

ClearStructuralFeatureAction is a structural feature action that removes all values of a structural feature.

Description

This action removes all values of a structural feature.

Attributes

None.

Associations

None.

Constraints

None.

Semantics

All values are removed even when that violates the minimum multiplicity of the structural feature--the same as if the minimum were zero. The semantics is undefined if the settability of the structural feature is addOnly, or the settability is readOnly after initialization of the object owning the structural feature, unless the structural feature has no values. The action has no effect if the structural feature has no values.

Notation

None.

Examples

Rationale

ClearStructuralFeatureAction is introduced to remove all values from a structural feature in a single action, with no intermediate states where only some of the existing values are present.

Changes from previous UML

ClearStructuralFeatureAction is new in UML 2.0. It generalizes ClearAttributeAction from UML 1.5.

ClearVariableAction

ClearVariableAction is a variable action that removes all values of an variable.

Description

This action removes all values of an variable.

Attributes

None.

Associations

None.

Constraints

None.

Semantics

All values are removed even when that violates the minimum multiplicity of the variable--the same as if the minimum were zero.

Notation

None.

Examples

Rationale

ClearVariableAction is introduced to remove all values from an variable in a single action, with no intermediate states where only some of the existing values are present.

Changes from previous UML

ClearVariableAction is unchanged from UML 1.5.

CreateLinkAction

CreateLinkAction is a write link action for creating links.

Description

This action can be used to create links and link objects. There is no return value in either case. This is so that no change of the action is required if the association is changed to an association class or vice versa. CreateLinkAction uses a specialization of LinkEndData called LinkEndCreationData, to support ordered associations. The insertion point is specified at runtime by an additional input pin, which is required for ordered association ends and omitted for unordered ends. The insertion point is a positive integer giving the position to insert the link, or infinity, to insert at the end. Reinserting an existing end at a new position moves the end to that position.

CreateLinkAction also uses LinkEndCreationData to support the destruction of existing links of the association that connect any of the objects of the new link. When the link is created, this option is available on an end-by-end basis, and causes all links of the association emanating from the specified ends to be destroyed before the new link is created.

Attributes

None.

Associations
Constraints

[1] The association cannot be an abstract classifier. 

self.association().isAbstract = #false

Semantics

CreateLinkAction creates a link or link object for an association or association class. It has no output pin, because links are not  necessarily values that can be passed to and from actions. When the action creates a link object, the object could be returned on  output pin, but it is not for consistency with links. This allows actions to remain unchanged when an association is changed to an association class or vice versa. The semantics of CreateLinkObjectAction applies to creating link objects with CreateLinkAction.

This action also supports the destruction of existing links of the association that connect any of the objects of the new link.

This option is available on an end-by-end basis, and causes all links of the association emanating from the specified ends to be destroyed before the new link is created. If the link already exists, then it is not destroyed under this option. Otherwise, recreating an existing link has no effect.

The semantics is undefined for creating a link for an association class that is abstract. The semantics is undefined for creating a link that violates the upper multiplicity of one of its association ends. A new link violates the upper multiplicity of an end if  the cardinality of that end after the link is created would be greater than the upper multiplicity of that end. The cardinality of an end is equal to the number of links with objects participating in the other ends that are the same as those participating in those other ends in the new link, and with qualifier values on all ends the same as the new link, if any.

The semantics is undefined for creating a link that has an association end with settability readOnly or removeOnly after initialization of the other end objects, unless the link being created already exists. Objects participating in the association across from an addable end can have links created as long as the objects across from all readOnly or removeOnly ends are still being initialized. This means that objects participating in links with two or more readOnly or removeOnly ends cannot have
links created unless all the linked objects are being initialized.

Creating ordered association ends requires an insertion point for a new link using the insertAt input pin of LinkEndCreationData. The pin is of type UnlimitedNatural with multiplicity of 1..1. A pin value that is a positive integer less than or equal to the current number of links means to insert the new link at that position in the sequence of existing links, with the integer one meaning the new link will be first in the sequence. A value of infinity for insertAt means to insert the new link
at the end of the sequence. The semantics is undefined for value of zero or an integer greater than the number of existing links.

The insertAt input pin does not exist for unordered association ends. Reinserting an existing end at a new position moves the end so that it is in the position specified after the action is complete.

Notation

None.

Examples

Rationale

CreateLinkAction is introduced to create links.

Changes from previous UML

CreateLinkAction is unchanged from UML 1.5.

CreateLinkObjectAction

(CompleteActions) CreateLinkObjectAction creates a link object.

Description

This action is exclusively for creating links of association classes. It returns the created link object.

Attributes

None.

Associations
Constraints

[1] The association must be an association class.

self.association().oclIsKindOf(Class)

[2] The type of the result pin must be the same as the association of the action.

self.result.type = self.association()

[3] The multiplicity of the output pin is 1..1.

self.result.multiplicity.is(1,1)

Semantics

CreateLinkObjectAction inherits the semantics of CreateLinkAction, except that it operates on association classes to create a  link object. The additional semantics over CreateLinkAction is that the new or found link object is put on the output pin. If the link already exists, then the found link object is put on the output pin. The semantics of CreateObjectAction applies to creating link objects with CreateLinkObjectAction.

Notation

None.

Examples

Rationale

CreateLinkObjectAction is introduced to create link objects in a way that returns the link object. Compare CreateLinkAction.

Changes from previous UML

CreateLinkObjectAction is unchanged from UML 1.5.

CreateObjectAction

CreateObjectAction is an action that creates an object that conforms to a statically specified classifier and puts it on an output pin at runtime.

Description

This action instantiates a classifier. The semantics is undefined for creating objects from abstract classifiers or from association classes.

Attributes

None.

Associations
Constraints

[1] The classifier cannot be abstract.

not (self.classifier.isAbstract = #true)

[2] The classifier cannot be an association class

not self.classifier.oclIsKindOf(AssociationClass)

[3] The type of the result pin must be the same as the classifier of the action.

self.result.type = self.classifier

[4] The multiplicity of the output pin is 1..1.

self.result.multiplicity.is(1,1)

Semantics

The new object is created, and the classifier of the object is set to the given classifier. The new object is returned as the value of the action. The action has no other effect. In particular, no behaviors are executed, no initial expressions are evaluated, and no state machines transitions are triggered. The new object has no structural feature values and participates in no links.

Notation

None.

Examples

Rationale

CreateObjectAction is introduced for creating new objects.

Changes from previous UML

Same as UML 1.5.

DestroyLinkAction

DestroyLinkAction is a write link action that destroys links and link objects.

Description

This action destroys a link or a link object. Link objects can also be destroyed with DestroyObjectAction. The link is specified in the same way as link creation, even for link objects. This allows actions to remain unchanged when their associations are transformed from ordinary ones to association classes and vice versa.

Attributes

None.

Associations

None.

Constraints

None.

Semantics

Destroying a link that does not exist has no effect. The semantics of DestroyObjectAction applies to destroying a link that has a link object with DestroyLinkAction.
The semantics is undefined for destroying a link that has an association end with settability addOnly, or readOnly after initialization of the other end objects, unless the link being destroyed does not exist. Objects participating in the association across from a removable end can have links destroyed as long as the objects across from all readOnly ends are still beinginitialized. This means that objects participating in links with two or more addOnly ends cannot have links destroyed. Same
for objects participating in two or more readOnly ends, unless all the linked objects are being initialized.

Notation

None.

Examples

Rationale

DestroyLinkAction is introduced for destroying links.

Changes from previous UML

DestroyLinkAction is unchanged from UML 1.5.

 DestroyObjectAction


DestroyObjectAction is an action that destroys objects.

Description

This action destroys the object on its input pin at runtime. The object may be a link object, in which case the semantics of  DestroyLinkAction also applies.

Attributes

None.

Associations

Constraints

[1] The multiplicity of the input pin is 1..1.

self.input.multiplicity.is(1,1)

[2] The input pin has no type.

self.input.type->size() = 0

Semantics

The classifiers of the object are removed as its classifiers, and the object is destroyed. The action has no other effect. In particular, no behaviors are executed, no state machines transitions are triggered, and references to the destroyed objects are unchanged.

Destroying an object that is already destroyed has no effect.

Notation

None.

Examples

Rationale

DestroyObjectAction is introduced for destroying objects.

Changes from previous UML

Same as UML 1.5.

 InvocationAction

Invocation is an abstract class for the various actions that invoke behavior.

Attributes

none

Associations

Constraints

Semantics

See children of InvocationAction.

LinkAction

LinkAction is an abstract class for all link actions that identify their links by the objects at the ends of the links and by the qualifiers at ends of the links.

Description

A link action creates, destroys, or reads links, identifying a link by its end objects and qualifier values, if any.

Attributes

None.

Associations
Constraints

[1] The association ends of the link end data must all be from the same association and include all and only the association ends of that association.

self.endData->collect(end) = self.association()->collect(connection))

[2] The association ends of the link end data must not be static.

self.endData->forall(end.oclisKindOf(NavigableEnd) implies end.isStatic = #false)

[3] The input pins of the action are the same as the pins of the link end data and insertion pins.

    self.input->asSet() =
        let ledpins : Set = self.endData->collect(value) in
            if self.oclIsKindOf(LinkEndCreationData)
            then ledpins->union(self.endData.oclAsType(LinkEndCreationData).insertAt)
            else ledpins

Additional operations:

[1] association operates on LinkAction. It returns the association of the action.

    association();
    association = self.endData->asSequence().first().end.association

Constraints

[1] The input pins of the action are the same as the pins of the link end data, qualifier values, and insertion pins.

self.input->asSet() =
    let ledpins : Set =
        if self.endData.oclIsKindOf(CompleteActions::LinkEndData)
        then self.endData->collect(value)->union(self.endData.qualifier.value)
        else self.endData->collect(value) in
            if self.oclIsKindOf(LinkEndCreationData)
            then ledpins->union(self.endData.oclAsType(LinkEndCreationData).insertAt)
            else ledpins

Semantics

For actions that write links, all association ends must have a corresponding input pin so that all end objects are specified when creating or deleting a link. An input pin identifies the end object by being given a value at runtime. It has the type of the association end and multiplicity of 1..1, since a link always have exactly one object at its ends.

The behavior is undefined for links of associations that are static on any end.

For the semantics of link actions see the children of LinkAction.

Notation

None.

Examples

Rationale

LinkAction is introduced to abstract aspects of link actions that identify links by the objects on their ends.

In CompleteActions, LinkAction is extended for qualifiers.

Changes from previous UML

LinkAction is unchanged from UML 1.5.

LinkEndCreationData

LinkEndCreationData is not an action. It is an element that identifies links. It identifies one end of a link to be created by CreateLinkAction.

Description

This class is required when using CreateLinkAction, to specify insertion points for ordered ends and for replacing all links at end. A link cannot be passed as a runtime value to or from an action. Instead, a link is identified by its end objects and qualifier values, as required. This requires more than one piece of data, namely, the statically-specified end in the user model, the object on the end, and the qualifier values for that end. These pieces are brought together around LinkEndData. Each association end is identified separately with an instance of the LinkEndData class.

Qualifier values are used in CompleteActions.

Attributes
Associations
insertAt : InputPin [0..1] Specifies where the new link should be inserted for ordered association ends, or where an existing link should be moved to. The type of the input is UnlimitedNatural, but the input cannot be zero. This pin is omitted for association ends that are not ordered.

Associations (CompleteActions)
Constraints

[1] LinkEndCreationData can only be end data for CreateLinkAction or one of its specializations.

self.LinkAction.oclIsKindOf(CreateLinkAction)

[2] Link end creation data for ordered association ends must have a single input pin for the insertion point with type UnlimitedNatural and multiplicity of 1..1, otherwise the action has no input pin for the insertion point..

let insertAtPins : Collection = self.insertAt in
    if self.end.ordering = #unordered
    then insertAtPins->size() = 0
    else let insertAtPin : InputPin = insertAts->asSequence()->first() in
            insertAtPins->size() = 1
            and insertAtPin.type = UnlimitedNatural
            and insertAtPin.multiplicity.is(1,1))
    endif

Constraints (CompleteActions)

[1] The qualifiers include all and only the qualifiers of the association end.

self.qualifier->collect(qualifier) = self.end.qualifier

[2] The end object input pin is not also a qualifier value input pin.

self.value->excludesAll(self.qualifier.value)

Semantics

See CreateLinkAction, also see LinkAction and all its children.

Notation

None.

Examples

Rationale

LinkEndCreationData is introduced to indicate which inputs are for which link end objects and qualifiers.

Changes from previous UML

LinkEndCreationData is unchanged from UML 1.5.

LinkEndData

LinkEndData is not an action. It is an element that identifies links. It identifies one end of a link to be read or written by the children of LinkAction. A link cannot be passed as a runtime value to or from an action. Instead, a link is identified by its end objects and qualifier values, if any. This requires more than one piece of data, namely, the statically-specified end in the user model, the object on the end, and the qualifier values for that end, if any. These pieces are brought together around
LinkEndData. Each association end is identified separately with an instance of the LinkEndData class.

Attributes

None.

Associations

Associations (CompleteActions)
Constraints

[1] The property must be an association end.

self.end.association->size = 1

[2] The type of the end object input pin is the same as the type of the association end.

self.value.type = self.end.type

[3] The multiplicity of the end object input pin must be "1..1".

self.value.multiplicity.is(1,1)

Additional operations:

[1] association operates on LinkAction. It returns the association of the action.

association();
association = self.endData->asSequence().first().end.association

Semantics

See LinkAction and its children.

Notation

None.

Examples

Rationale

LinkEndData is introduced to indicate which inputs are for which link end objects and qualifiers.

Changes from previous UML

LinkEndData is unchanged from UML 1.5.

 MultiplicityElement (as specialized)

Operations

[1] The operation compatibleWith takes another multiplicity as input. It checks if one multiplicity is compatible with another.

    compatibleWith(other : Multiplicity) : Boolean;
    compatibleWith(other) = Integer.allInstances()->
        forAll(i : Integer | self.includesCardinality(i) implies other.includesCardinality(i))

[2] The operation is determines if the upper and lower bound of the ranges are the ones given.

    is(lowerbound : integer, upperbound : integer) : Boolean
    is(lowerbound, upperbound) = (lowerbound = self.lowerbound and upperbound = self.upperbound)

 PrimitiveFunction

Description

PrimitiveFunction is not an action. It is the signature of a function that produces output values from input values for use with ApplyFunctionAction. The behavior is described using the body and language attributes. The specification of the detailed behavior is expressed in an external language and is not further specified within UML.

Attributes
body: String A textual representation of the function in the named surface language.
language: String [0..1] Specifies the language in which the body of the primitive function is stated. The interpretation of the body depends on the language. If the language is unspecified, it might be implicit from the body or the context.

Associations

None.

Constraints

None.

Semantics

The interpretation of the function body depends on the specified language. If formal parameters are specified, these provide values to the function during its execution. The result parameters specify the values to be returned by the function.

The execution of a primitive function has no effect on the execution environment other than the production of output values that depend only on the supplied input values.

Notation

None.

Examples

None.

Rationale

PrimitiveFunction models external functions that only take inputs and product outputs and have no effect on the specified system.

Changes from previous UML

Same as UML 1.5.

 QualifierValue


(CompleteActions) QualifierValue is not an action. It is an element that identifies links. It gives a single qualifier within a link end data specification. See LinkEndData.

Description

A link cannot be passed as a runtime value to or from an action. Instead, a link is identified by its end objects and qualifier values, as required. This requires more than one piece of data, namely, the end in the user model, the object on the end, and the qualifier values for that end. These pieces are brought together around LinkEndData. Each association end is identified separately with an instance of the LinkEndData class.

Attributes

None.

Associations

Constraints

[1] The qualifier attribute must be a qualifier of the association end of the link-end data.

self.LinkEndData.end->collect(qualifier)->includes(self.qualifier)

[2] The type of the qualifier value input pin are the same as the type of the qualifier attribute.

self.value.type = self.qualifier.type

[3] The multiplicity of the qualifier value input pin is "1..1".

self.value.multiplicity.is(1,1)

Semantics

See LinkAction and its children.

Notation

None.

Examples

Rationale

QualifierValue is introduced to indicate which inputs are for which link end qualifiers.

Changes from previous UML

QualifierValue is unchanged from UML 1.5

RaiseExceptionAction


Description

(CompleteActions) RaiseExceptionAction is an action that causes an exception to occur. The input value becomes the exception object.

Attributes

None.

Associations

Semantics

When a raise exception action is executed, the value on the input pin is raised as an exception. The value may be copied in this process, so identity may not be preserved. Raising the exception terminates the immediately containing structured node or activity and begins a search of enclosing nested scopes for an exception handler that matches the type of the exception object. See "ExceptionHandler" for details of handling exceptions.

Notation

See Action.

Examples

Rationale

Raise exception action allows models to generate exceptions. Otherwise the only exception types would be predefined built-in exception types, which would be too restrictive.

Changes from previous UML

RaiseExceptionAction replaces JumpAction from UML 1.5. Their behavior is essentially the same, except that it is no longer needed for performing simple control constructs such as break and continue.

ReadExtentAction

Description

(CompleteActions) ReadExtentAction is an action that retrieves the current instances of a classifier.

Attributes

None.

Associations

Constraints

[1] The type of the result output pin is the classifier.

[2] The multiplicity of the result output pin is "0..*".

self.result.multiplicity.is(0,#null)

Semantics

The extent of a classifier is the set of all instances of a classifier that exist at any one time.

Semantic Variation Point

It is not generally practical to require that reading the extent produce all the instances of the classifier that exist in the entire universe. Rather, an execution engine typically manages only a limited subset of the total set of instances of any classifier and may manage multiple distributed extents for any one classifier. It is not formally specified which managed extent is actually read by a ReadExtentAction.

Notation

None.

Examples

None.

Rationale

ReadExtentAction is introduced to provide access to the runtime instances of a classifier.

Changes from previous UML

ReadExtentAction is unchanged from UML 1.5.

ReadIsClassifiedObjectAction

(CompleteActions) ReadIsClassifiedObjectAction is an action that determines whether a runtime object is classified by a given classifier.

Description

This action tests the classification of an object against a given class. It can be restricted to testing direct instances.

Attributes
Associations
Constraints

[1] The multiplicity of the input pin is 1..1.

self.argument.multiplicity.is(1,1)

[2] The input pin has no type.

self.argument.type->size() = 0

[3] The multiplicity of the output pin is 1..1.

self.result.multiplicity.is(1,1)

[4] The type of the output pin is Boolean

self.result.type = Boolean

Semantics

The action returns true if the input object is classified by the specified classifier. It returns true if the isDirect attribute is false and the input object is classified by the specified classifier, or by one of its (direct or indirect) descendents. Otherwise, the action returns false.

Notation

None.

Examples

None.

Rationale

ReadisClassifiedObjectAction is introduced for run-time type identification.

Changes from previous UML

ReadisClassifiedObjectAction is unchanged from UML 1.5.

 ReadLinkAction

ReadLinkAction is a link action that navigates across associations to retrieve objects on one end.

Description

This action navigates an association towards one end, which is the end that does not have an input pin to take its object (the "open" end). The objects put on the result output pin are the ones participating in the association at the open end, conforming to the specified qualifiers, in order if the end is ordered. The semantics is undefined for reading a link that violates the navigability or visibility of the open end.

Attributes

None.

Associations
Constraints

[1] Exactly one link-end data specification (the "open" end) must not have an end object input pin.

self.endData->select(ed | ed.value->size() = 0)->size() = 1

[2] The type and ordering of the result output pin are same as the type and ordering of the open association end.

let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)->asSequence()->first().end in
    self.result.type = openend.type
    and self.result.ordering = openend.ordering

[3] The multiplicity of the open association end must be compatible with the multiplicity of the result output pin.

let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)->asSequence()->first().end in
    openend.multiplicity.compatibleWith(self.result.multiplicity)

[4] The open end must be navigable.

let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)->asSequence()->first().end in
    openend.isNavigable = #true

[5] Visibility of the open end must allow access to the object performing the action.

let host : Classifier = self.activity().hostClassifier() in
let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)->asSequence()->first().end in
        openend.visibility = #public
        or self.endData->exists(oed | not oed.end = openend
        and (host = oed.end.participant
        or (openend.visibility = #protected
        and host.allSupertypes->includes(oed.end.participant))))

Semantics

Navigation of a binary association requires the specification of the source end of the link.The target end of the link is not specified. When qualifiers are present, one navigates to a specific end by giving objects for the source end of the association and qualifier values for all the ends. These inputs identify a subset of all the existing links of the association that match the end objects and qualifier values. The result is the collection of objects for the end being navigated towards, one object from each identified link.

In a ReadLinkAction, generalized for n-ary associations, one of the link-end data must have an unspecified object (the "open" end). The result of the action is a collection of objects on the open end of links of the association, such that the links have the given objects and qualifier values for the other ends and the given qualifier values for the open end. This result is placed on the output pin of the action, which has a type and ordering given by the open end. The multiplicity of the open end must be compatible with the multiplicity of the output pin. For example, the modeler can set the multiplicity of this pin to support multiple values even when the open end only allows a single value. This way the action model will be unaffected by changes in the multiplicity of the open end. The semantics are defined only when the open end is navigable, and visible to the host object of the action.

Notation

None.

Examples

Rationale

ReadLinkAction is introduced to navigate across links.

Changes from previous UML

ReadLinkAction is unchanged from UML 1.5.

 ReadLinkObjectEndAction

(CompleteActions) ReadLinkObjectEndAction is an action that retrieves an end object from a link object.

Description

This action reads the object on an end of a link object. The association end to retrieve the object from is specified statically, and the link object to read is provided on the input pin at run time.

Attributes

None.

Associations
Constraints

[1] The property must be an association end.

self.end.association->size = 1

[2] The association of the association end must be an association class.

self.end.Association.oclIsKindOf(AssociationClass)

[3] The ends of the association must not be static.

self.end.association.end->forall(oclIsKindOf(NavigableEnd) implies isStatic = #false)

[4] The type of the object input pin is the association class that owns the association end.

self.object.type = self.end.association

[5] The multiplicity of the object input pin is "1..1".

self.object.multiplicity.is(1,1)

[6] The type of the result output pin is the same as the type of the association end.

self.result.type = self.end.type

[7] The multiplicity of the result output pin is 1..1.

self.result.multiplicity.is(1,1)

Semantics

Notation

None.

Examples

Rationale

ReadLinkObjectEndAction is introduced to navigate from a link object to its end objects.

Changes from previous UML

ReadLinkObjectEndAction is unchanged from UML 1.5.

 ReadLinkObjectEndQualifierAction

(CompleteActions) ReadLinkObjectEndAction is an action that retrieves a qualifier end value from a link object.

Description

This action reads a qualifier value or values on an end of a link object. The association end to retrieve the qualifier from is specified statically, and the link object to read is provided on the input pin at run time.

Attributes

None.

Associations

Constraints

[1] The qualifier attribute must be a qualifier attribute of an association end.

self.qualifier.associationEnd->size() = 1

[2] The association of the association end of the qualifier attribute must be an association class.

self.qualifier.associationEnd.association.oclIsKindOf(AssociationClass)

[3] The ends of the association must not be static.

self.qualifier.associationEnd.association.end->forall(oclIsKindOf(NavigableEnd) implies isStatic = #false)

[4] The type of the object input pin is the association class that owns the association end that has the given qualifier attribute.

self.object.type = self.qualifier.associationEnd.association

[5] The multiplicity of the qualifier attribute is 1..1.

self.qualifier.multiplicity.is(1,1)

[6] The multiplicity of the object input pin is "1..1".

self.object.multiplicity.is(1,1)

[7] The type of the result output pin is the same as the type of the qualifier attribute.

self.result.type = self.qualifier.type

[8] The multiplicity of the result output pin is "1..1".

self.result.multiplicity.is(1,1)

Semantics

Notation

None.

Examples

Rationale

ReadLinkObjectEndQualifierAction is introduced to navigate from a link object to its end objects.

Changes from previous UML

ReadLinkObjectEndQualifierAction is unchanged from UML 1.5, except the name was corrected from

ReadLinkObjectQualifierAction.

ReadSelfAction

ReadSelfAction is an action that retrieves the host object of an action.

Description

Every action is ultimately a part of some activity, which is in turn is optionally attached in some way to the specification of a classifier--for example as the body of a method or as part of a state machine. When the activity executes, it does so in the context of some specific host instance of that classifier. This action produces this host instance, if any, on its output pin. The type of the output pin is the classifier to which the activity is associated in the user model.

Attributes

None.

Associations

Constraints

[1] The action must be contained in an activity that has a host classifier.

self.activity().hostClassifier()->size() = 1

[2] If the action is contained in an activity that is acting as the body of a method, then the operation of the method must not be static.

let hostelement : Element = self.activity().hostElement() in
    not hostelement.oclIsKindOf(Method)
    or hostelement.oclAsType(Method).specification.isStatic = #false

[3] The type of the result output pin is the host classifier.

self.result.type = self.activity().hostClassifier()

[4] The multiplicity of the result output pin is "1..1".

self.result.multiplicity.is(1,1)

Semantics

The semantics is undefined for activities that have no context object.

Notation

None.

Examples

Rationale

ReadSelfAction is introduced to provide access to the context object when it is not available as a parameter.

Changes from previous UML

ReadSelfAction is unchanged from UML 1.5.

ReadStructuralFeatureAction

ReadStructuralFeatureAction is a structural feature action that retrieves the values of a structural feature.

Description

This action reads the values of a structural feature, in order if the structural feature is ordered.

Attributes

None.

Associations

Constraints

[1] The type and ordering of the result output pin are the same as the type and ordering of the structural feature.

self.result.type = self.structuralFeature.type
and self.result.ordering = self.structuralFeature.ordering

[2] The multiplicity of the structural feature must be compatible with the multiplicity of the output pin.

self.structuralFeature.multiplicity.compatibleWith(self.result.multiplicity)

Semantics

The values of the structural feature of the input object are placed on the output pin of the action. The type and ordering of the output pin are the same as the specified structural feature. The multiplicity of the structural feature must be compatible with the multiplicity of the output pin. For example, the modeler can set the multiplicity of this pin to support multiple values even when the structural feature only allows a single value. This way the action model will be unaffected by changes in the
multiplicity of the structural feature.

Notation

None.

Examples

Rationale

ReadStructuralFeatureAction is introduced to retrieve the values of a structural feature.

Changes from previous UML

ReadStructuralFeatureAction is new in UML 2.0. It generalizes ReadAttributeAction from UML 1.5.

 ReadVariableAction

ReadVariableAction is a variable action that retrieves the values of an variable.

Description

This action reads the values of a variables, in order if the variable is ordered.

Attributes

None.

Associations

Constraints

[1] The type and ordering of the result output pin of a read-variable action are the same as the type and ordering of the variable.

self.result.type =self.variable.type
and self.result.ordering = self.variable.ordering

[2] The multiplicity of the variable must be compatible with the multiplicity of the output pin.

self.variable.multiplicity.compatibleWith(self.result.multiplicity)

Semantics

The values of the variable are placed on the output pin of the action. The type and ordering of the output pin are the same as the specified variable. The multiplicity of the variable must be compatible with the multiplicity of the output pin. For example, the modeler can set the multiplicity of this pin to support multiple values even when the variable only allows a single value. This way the action model will be unaffected by changes in the multiplicity of the variable.

Notation

None.

Examples

Rationale

ReadVariableAction is introduced to retrieve the values of a variables.

Changes from previous UML

ReadVariableAction is unchanged from UML 1.5.

 ReclassifyObjectAction

(CompleteActions) ReclassifyObjectAction is an action that changes which classifiers classify an object.

Description

ReclassifyObjectAction adds given classifier to an object and removes given classifiers from that object. Multiple classifiers may be added and removed at a time.

Attributes

Associations
Constraints

[1] None of the new classifiers may be abstract.

not self.newClassifier->exists(isAbstract = true)

[2] The multiplicity of the input pin is 1..1.

self.argument.multiplicity.is(1,1)

[3] The input pin has no type.

self.argument.type->size() = 0

Semantics

After the action completes, the input object is classified by its existing classifiers and the "new" classifiers given to the action; however, the "old" classifiers given to the actions do not any longer classify the input object. The identity of the object is preserved, no behaviors are executed, and no initial expressions are evaluated. "New" classifiers replace existing classifiers in an atomic step, so that structural feature values and links are not lost during the reclassification, when the "old" and "new"
classifiers have structural features and associations in common.

Neither adding a classifier that duplicates an already existing classifier, nor removing a classifier that is not classifying the input object, has any effect. Adding and removing the same classifiers has no effect.

If isReplaceAll is true, then the existing classifiers are removed before the "new" classifiers are added, except if the "new" classifier already classifies the input object, in which case this classifier it is not removed. If isReplaceAll is false, then adding an existing value has no effect.

It is an error, if any of the "new" classifiers is abstract or if all classifiers are removed from the input object.

Notation

None.

Examples

None.

Rationale

ReclassifyObjectAction is introduced to change the classifiers of an object.

Changes from previous UML

ReclassifyObjectAction is unchanged from UML 1.5.

RemoveStructuralFeatureValueAction

RemoveStructuralFeatureValueAction is a write structural feature action that removes values from structural features.

Description

The object to access is specified dynamically, by referring to an input pin on which the object will be placed at runtime. The type of the value of this pin is the classifier that owns the specified structural feature, and the value's multiplicity is 1..1.

Attributes

None.

Associations

None.

Constraints

None.

Semantics

Structural features are potentially multi-valued. Removing a value succeeds even when it violates the minimum multiplicity.

Removing a value that does not exist has no effect.

The semantics is undefined for removing an existing value for a structural feature with settability addOnly. The semantics is undefined for removing an existing value of a structural feature with settability readOnly after initialization of the owning object.

Notation

None.

Examples

Rationale

RemoveStructuralFeatureValueAction is introduced to remove structural feature values.

Changes from previous UML

RemoveStructuralFeatureValueAction is new in UML 2.0. It generalizes RemoveAttributeValueAction in UML 2.0.

  RemoveVariableValueAction

RemoveVaraibleValueAction is a write variable action that removes values from variables.

Description

One value is removed from the set of possible variable values.

Attributes

None.

Associations

None.

Constraints

None.

Semantics

Variables are potentially multi-valued. Removing a value succeeds even when it violates the minimum multiplicity. Removing a value that does not exist has no effect.

Notation

None.

Examples

Rationale

RemoveVariableValueAction is introduced to remove variable values.

Changes from previous UML

RemoveVariableValueAction is unchanged from UML 1.5.

ReplyAction

(CompleteActions) ReplyAction is an action that accepts a set of return values and a token containing return information produced by a previous accept call action. The reply action returns the values to the caller of the previous call, completing execution of the call.

Attributes

none

Associations
Constraints

[1] The reply value pins must match the return, out, and inout parameters of the call trigger operation in number, type, and order.

Semantics

The execution of a reply action completes the execution of a call that was initiated by a previous AcceptCallAction. The two are connected by the returnInformation token, which is produced by the AcceptCallAction and consumed by the ReplyAction.

The information in this token is used by the execution engine to return the reply values to the caller and to complete execution of the original call. The details of transmitting call requests, encoding return information, and transmitting replies are opaque and unavailable to models, therefore they need not be and are not specified in this document.

Return information may be copied, stored in objects, and passed around, but it may only be used in a reply action once. If the same return information token is supplied to a second ReplyAction, the execution is in error and the behavior of the system is unspecified. It is not intended that any profile give any other meaning the the return information. The operation specified by the call trigger must be consistent with the information returned at runtime.

If the return information is lost to the execution or if a reply is never made, the caller will never receive a reply and therefore will never complete execution. This is not inherently illegal but it represents an unusual situation at the very least.

SendObjectAction


SendObjectAction is an action that transmits an object to the target object, where it may invoke behavior such as the firing of state machine transitions or the execution of an activity. The value of the object is available to the execution of invoked behaviors. The requestor continues execution immediately. Any reply message is ignored and is not transmitted to the requestor.

Attributes

None

Associations
request: InputPin [1] The signal request object, which is transmitted to the target object as a signal. The signal object may be copied in transmission, so identity might not be preserved. (Specialized from InvocationActon.argument)
target: InputPin [1] The target object to which the signal is sent.

Constraints

None.

Semantics

[1] When all the control and data flow prerequisites of the action execution are satisfied, the object on the input pin is transmitted to the target object. The target object may be local or remote. The object on the input pin may be copied during transmission, so identity might not be preserved. The manner of transmitting the object, the amount of time required to transmit it, the order in which the transmissions reach the various target objects, and the path for reaching the target
objects are undefined.

[2] When a transmission arrives at a target object, it may invoke behavior in the target object. The effect of receiving a objectis specified in Chapter 13, "Common Behaviors". Such effects include executing activities and firing state machine transitions.

[3] A send object action receives no reply from the invoked behavior; any attempted reply is simply ignored, and no transmission is performed to the requestor.

Notation

See Action.

Presentation Option

If the activity in which a send object action is used will always send a signal, then the SendSignalAction notation can be used.

Examples

None

Rationale

Sends a signal to a specified target object.

Changes from previous UML

SendObjectAction is new in UML 2.0.

 SendSignalAction

SendSignalAction is an action that creates a signal instance from its inputs, and transmits it to the target object, where it may cause the firing of a state machine transition or the execution of an activity. The argument values are available to the execution of associated behaviors. The requestor continues execution immediately. Any reply message is ignored and is not transmitted to the requestor. If the input is already a signal instance, use SendObjectAction.

Attributes

None

Associations
Constraints

[1] The number and order of argument pins must be the same as the number and order of attributes in the signal.

The type, ordering, and multiplicity of an argument pin must be the same as the corresponding attribute of the signal.

Semantics

[1] When all the control and data flow prerequisites of the action execution are satisfied, a signal instance of the type specified by signal is generated from the argument values and his signal instance is transmitted to the identified target object. The target object may be local or remote. The signal instance may be copied during transmission, so identity might not be preserved.The manner of transmitting the signal object, the amount of time required to transmit it, the order in which the
transmissions reach the various target objects, and the path for reaching the target objects are undefined.

[2] When a transmission arrives at a target object, it may invoke behavior in the target object. The effect of receiving a signal object is specified in Chapter 13, "Common Behaviors". Such effects include executing activities and firing state machine transitions.

[3] A send signal action receives no reply from the invoked behavior; any attempted reply is simply ignored, and no transmission is performed to the requestor.

Notation

A send signal action is notated with a convex pentagon. The symbol may optionally have a input pin for the target object but this is often omitted. The symbol has a control output only.



Examples

Figure 166 shows part of an order-processing workflow in which two signals are sent. An order is created (in response to some previous request that is not shown in the example). A signal is sent to the warehouse to fill and ship the order. Then an invoice is created and sent to the customer.


Rationale

Sends a signal to a specified target object.

Changes from previous UML

Same as UML 1.5.

 StartOwnedBehaviorAction

Description

(CompleteActions) StartOwnedBehaviorAction is an action that starts the owned behavior of the input.

Attributes

None.

Associations
Constraints

[1] The input pin has no type.

self.argument.type->size() = 0

Semantics

When a StartOwnedBehaviorAction is invoked, it initiates the owned behavior of the classifier of the input object. If the behavior has already been initiated, this action has no effect.

Notation

None.

Examples

None.

Rationale

This action is provided to permit the explicit initiation of owned behaviors, such as state machines and code, in a detailed, low-level "raw" specification of behavior.

Changes from previous UML

StartOwnedBehaviorAction is unchanged from UML 1.5.

StructuralFeatureAction

StructuralFeatureAction is an abstract class for all structural feature actions.

Description

This abstract action class statically specifies the structural feature being accessed.

The object to access is specified dynamically, by referring to an input pin on which the object will be placed at runtime. The type of the value of this pin is the classifier that owns the specified structural feature, and the value's multiplicity is 1..1.

Attributes

None.

Associations

Constraints

[1] The structural feature must have not be static.

self.structuralFeature.isStatic = #false

[2] The type of the object input pin is the same as the classifier of the object passed on this pin.

[3] The multiplicity of the input pin must be 1..1.

self.object.multiplicity.is(1,1)

[4] Visibility of structural feature must allow access to the object performing the action.

let host : Classifier = self.activity().hostClassifier() in
    self.structuralFeature.visibility = #public
    or host = self.structuralFeature.featuringClassifier.type
    or (self.structuralFeature.visibility = #protected and host.allSupertypes
            ->includes(self.structuralFeature.featuringClassifier.type)))

Semantics

A structural feature action operates on a statically specified structural feature of some classifier. The action requires an object on which to act, provided at runtime through an input pin. The semantics is undefined for accessing a structural feature that violates its visibility. The semantics for static features is undefined.

The structural features of an object may change over time due to dynamic classification. However, the structural feature specified in a structural feature action is inherited from a single classifier, and it is assumed that the object passed to a structural feature action is classified by that classifier directly or indirectly. The structural feature is referred to as a user model element, so it is uniquely identified, even if there are other structural features of the same name on other classifiers.

Notation

None.

Examples

Rationale

StructuralFeatureAction is introduced for the abstract aspects of structural feature actions.

Changes from previous UML

StructuralFeatureAction is new in UML 2.0. It generalizes AttributeAction in UML 1.5.

TestIdentityAction

TestIdentifyAction is an action that tests if two values are identical objects.t

Description

This action returns true if the two input values are the same identity, false if they are not.

Attributes

None.

Associations

Constraints

[1] The input pins have no type.

self.first.type->size() = 0
and self.second.type->size() = 0

[2] The multiplicity of the input pins is 1..1.

self.first.multiplicity.is(1,1)
and self.second.multiplicity.is(1,1)

Semantics

When all control and data flow prerequisites of the action have been satisfied, the input values are obtained from the input pins and made available to the computation. If the two input values represent the same object (regardless of any implementation-level encoding), the value true is placed on the output pin of the action execution, otherwise the value false is placed on the output pin. The execution of the action is complete and satisfies appropriate control and data flow prerequisites.

Notation

None.

Examples

Rationale

TestIdentityAction is introduced to tell when two values refer to the same object.

Changes from previous UML

TestIdentityAction is unchanged from UML 1.5.

 VariableAction

Description

VariableAction is an abstract class for actions that operate on a statically specified variable.

Attributes

None.

Associations
Constraints

[1] The action must be in the scope of the variable.

self.variable.isAccessibleBy(self)

Semantics

Variable action is an abstract metaclass. For semantics see its concrete subtypes.

Notation

None.

Examples

Rationale

VariableAction is introduced for the abstract aspects of variable actions.

Changes from previous UML

VariableAction is unchanged from UML 1.5.

WriteStructuralFeatureAction

WriteStructuralFeatureAction is an abstract class for structural feature actions that change structural feature values.

Description

A write structural feature action operates on a structural feature of an object to modify its values. It has an input pin on which the value that will be added or removed is put. Other aspects of write structural feature actions are inherited from StructuralFeatureAction.

Attributes

None.

Associations
Constraints

[1] The type input pin is the same as the classifier of the structural feature.

self.value.type = self.structuralFeature.featuringClassifier

[2] The multiplicity of the input pin is 1..1.

self.value.multiplicity.is(1,1)

Semantics

None.

Notation

None.

Examples

Rationale

WriteStructuralFeatureAction is introduced to abstract aspects of structural feature actions that change structural feature values.

Changes from previous UML

WriteStructuralFeatureAction is new in UML 2.0. It generalizes WriteAttributeAction in UML 1.5.

 WriteLinkAction

WriteLinkAction is an abstract class for link actions that create and destroy links.

Description

A write link action takes a complete identification of a link and creates or destroys it.

Attributes

None.

Associations

None.

Constraints

[1] All end data must have exactly one input object pin.

self.endData.forall(value->size() = 1)

Semantics

See children of WriteLinkAction.

Notation

None.

Examples

Rationale

WriteLinkAction is introduced to navigate across links.

Changes from previous UML

WriteLinkAction is unchanged from UML 1.5.

 WriteVariableAction

WriteVariableAction is an abstract class for variable actions that change variable values.

Description

A write variable action operates on a variable to modify its values. It has an input pin on which the value that will be added or removed is put. Other aspects of write variable actions are inherited from VariableAction.

Attributes

None.

Associations
Constraints

[1] The type input pin is the same as the type of the variable.

self.value.type = self.variable.type

[2] The multiplicity of the input pin is 1..1.

self.value.multiplicity.is(1,1)

Semantics

See children of WriteVariableAction.

Notation

None.

Examples

Rationale

WriteVariableAction is introduced to abstract aspects of structural feature actions that change variable values.

Changes from previous UML

WriteVariableAction is unchanged from UML 1.5.