Previous UML Classes Table of Contents UML Packages Next


12.3.14 CallBehaviorAction


    CallBehaviorAction (from BasicActions ) on page 255

*Attributes

   No additional attributes

*Associations

   No additional associations

*Constraints

   No additional constraints

*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 output to a pin or takes input 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. Any return or out values from the invoked behavior are not passed back to the containing activity. 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. (StructuredActions , ExtraStructuredActivities ) If the execution of the invoked behavior yields an exception, the exception is transmitted to the call behavior action to begin the search for the handler . See RaiseExceptionAction (from StructuredActions ) on page 277.

*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. Pre- and postconditions on the behavior can be shown similarly to Figure 12.29 on page 326, using keywords «precondition» and «postcondition».


   Figure 12.63 CallBehaviorAction

   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 specification supports the interchange of diagram elements and their mapping to model elements.

   


.


   .

   .

   (Note: the border and name are other symbols are present to provide clarity, only.)

   Below is an example of invoking an activity called FillOrder.

Figure 12.64 - Invoking Activities that have nodes and edges



   Figure 12.65 - Example of invoking an activity

    CallBehaviorAction (from BasicActions ) on page 255

*Changes from previous UML

    CallBehaviorAction (from BasicActions ) on page 255