Class Descriptions


Action

Description

An action is an executable activity node that is the fundamental unit of executable functionality in an activity, as opposed to control and data flow among actions. The execution of an action represents some transformation or processing in the modeled system, be it a computer system or otherwise.

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.

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

Attributes

  • /context : Classifier [1]
The classifier that owns the behavior of which this action is a part.
  • effect : String [0..1]
An optional text specification of the effect of the action. This may be used to indicate the behavior of an action without specialization into a subclass, or it may represent a text description of an action that is specialized, either for human understanding or to help code generation.

Associations (BasicActivities)

Associations (CompleteActivities)

Constraints

none

Operations

[3] 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

An action execution represents the run-time behavior of executing an action within a specific activity execution. As Action is an abstract class, all action executions will be executions of specific kinds of actions.

The sequencing of actions are controlled by control edges and object flow edges within activities, which carry control and object tokens respectively (see Activity). 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 are as follows:

[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 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.

[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 a 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 cotrol 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 for exception to rule for starting action execution.

If a behavior is not reentrant, then no more than one execution of it wil exist at any given time. An invocation of a nonreentrant behavior does not start the behavior when the behavior is already executing. In this case, 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.

(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.

(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.

(CompleteActivities) Local preconditions and postconditions are constraints that must 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

(CompleteActivities) How local pre- and postconditions are enforced is determined by the implementation. For example, violations may 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'sintention (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.



(CompleteActivities) Local pre- and postconditions are shown as notes attached to the invocation with the keywords



Examples

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



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


(CompleteActivities) The example below illustrates local pre and postcondition for the action of a drink dispensing machine.


Rationale

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 which 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.

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.

 Activity

An activity is the specification of parameterized behavior as the coordinated sequencing of subordinate units whose individual elements are actions. There are actions that invoke activities (directly by "CallBehaviorAction"or indirectly as methods by "CallOperationAction").

Description

An activity specifies the coordination of executions of subordinate behaviors, using a control and data flow model. The subordinate behaviors coordinated by these models may be initiated because other behaviors in the model finish executing, because objects and data become available, or because events occur external to the flow. The flow of execution is modeled as activity nodes connected by activity edges. A node can be the execution of a subordinate behavior, such as an arithmetic
computation, a call to an operation, or manipulation of object contents. Activity nodes also include flow-of-control constructs, such as synchronization, decision, and concurrency control. Activities may form invocation hierarchies invoking other activities, ultimately resolving to individual actions. In an object-oriented model, activities are usually invoked indirectly as methods bound to operations that are directly invoked.

Activities may describe procedural computation. In this context, they are the methods corresponding to operations on classes.

Activities may be applied to organizational modeling for business process engineering and workflow. In this context, events often originate from inside the system, such as the finishing of a task, but also from outside the system, such as a customer call.

Activities can also be used for information system modeling to specify system level processes.

Activities may contain actions of various kinds:

Actions have no further decomposition in the activity containing them. However, the execution of a single action may induce the execution of many other actions. For example, a call action invokes an operation which is implemented by an activity containing actions that execute before the call action completes.

Most of the constructs in the activity chapter deal with various mechanisms for sequencing the flow of control and data among the actions:
Attributes (CompleteActivities)

  • isReadOnly : Boolean = false
If true, this activity must not make any changes to variables outside the activity or to objects. (This is an assertion, not an executable property. It may be used by an execution engine to optimize model execution. If the assertion is violated by the action, then the model is ill-formed.) The default is false (an activity may make nonlocal changes).
  • isSingleExecution : Boolean = false
If true, tokens from separate invocations of the activity may interact.

Associations (BasicActivities)
Associations (IntermediateActivities)
Associations (StructuredActivities)
Stereotypes

None.

Tagged Values

None.

Constraints

[1] The nodes of the activity must include one ActivityParameterNode for each parameter.

[2] An activity cannot be autonomous and have a classifier or behavioral feature context at the same time.

Operations

[1] hostElement operates on Activity. It returns the "innermost" element in the user model that is hosting the activity. This will be either a Method, State, Transition, Message, or Stimulus.

hostElement() : ModelElement;
    hostElement = if self.Method->size() > 0
                          then self.Method
                          else if self.State->size() > 0
                                    then self.State
                                    else if self.Transition->size() > 0
                                            then self.Transition
                                            else if self.Message->size()>0
                                                    then self.Message
                                                    else if self.Stimulus->size>0
                                                            then self.Stimulus
                                                            endif
                                                    endif
                                            endif
                                    endif

[2] hostClassifier operates on Activity. It returns the classifier hosting the activity. This is the classifier on which the activity is defined as a method, action in a state machine, sender of a message in a collaboration, or sender of a stimulus in a CollaborationInstance.

hostClassifier() : Classifier;
hostClassifier = if self.Method->size() > 0
                        then self.Method.owner
                        else if self.State->size() > 0
                                then self.oclAsType(StateVertex).hostClassifier()
                                else if self.Transition->size() > 0
                                        then self.Transition.source.hostClassifier()
                                        else if self.Message->size()>0
                                                then self.Message.sender.base
                                                else if self.Stimulus->size>0
                                                then self.Stimulus.sender.classifier
                                                endif
                                          endif
                                 endif
                          endif

Semantics

The semantics of activities is based on token flow. By flow, we mean that the execution of one node affects and is affected by the execution of other nodes, and such dependencies are represented by edges in the activity diagram. A token contains an object, datum, or locus of control, and is present in the activity diagram at a particular node. Each token is distinct from any other, even if it contains the same value as another. A node may begin execution when specified conditions on its input tokens are satisfied; the conditions depend on the kind of node. When a node begins execution, tokens are accepted from some or all of its input edges and a token is placed on the node. When a node completes execution, a token is removed from the node and tokens are offered to some or all of its output edges. See later in this section for more about how tokens are managed.

All restrictions on the relative execution order of two or more actions are explicitly constrained by flow relationships. If two actions are not directly or indirectly ordered by flow relationships, they may execute concurrently. This does not require parallel execution; a specific execution engine may choose to perform the executions sequentially or in parallel, as long as any explicit ordering constraints are satisfied. In most cases, there are some flow relationships that constrain execution order.

Concurrency is supported IntermediateActivities, but not in BasicActivities.

Activities can be parameterized, which is a capability inherited from Behavior. See "ActivityParameterNode". Functionality inherited from Behavior also supports the use of activities on classifiers and as methods for behavioral features. The classifier, if any, is referred to as the context of the activity. At runtime, the activity has access to the attributes and operations of its context object and any objects linked to the context object, transitively. An activity that is also a method of a behavioral
feature has access to the parameters of the behavioral feature. In workflow terminology, the scope of information an activity uses is called the process-relevant data. Implementations that have access to metadata can define parameters that accept entire activities or other parts of the user model.

An activity with a a classifier context, but that is not a method of a behavioral feature, is invoked when the classifier is instantiated. An activity that is a method of a behavioral feature is invoked when the behavioral feature is invoked. The Behavior metaclass also provides parameters, which must be compatible with the behavioral feature it is a method of, if any.

Behavior also supports overriding of activities used as inherited methods. See the Behavior metaclass for more information.

Activities can also be invoked directly by other activities rather than through the call of a behavioral feature that has an activity as a method. This functional or monomorphic style of invocation is useful at the stage of development where focus is on the activities to be completed and goals to be achieved. Classifiers responsible for each activity can be assigned at a later stage by declaring behavioral features on classifiers and assigning activities as methods for these features. For example, in business reengineering, an activity flow can be optimized independently of which departments or positions are later assigned to handle
each step. This is why activities are autonomous when they are not assigned to a classifier.

Regardless of whether an activity is invoked through a behavioral feature or directly, inputs to the invoked activity are supplied by an invocation action in the calling activity, which gets its inputs from incoming edges. Likewise an activity invoked from another activity produces outputs that are delivered to an invocation action, which passes them onto its outgoing edges.

An activity execution represents an execution of the activity. An activity execution, as a reflective object, can support operations for managing execution, such as starting, stopping, aborting, and so on; attributes, such as how long the process has been executing or how much it costs; and links to objects, such as the performer of the execution, who to report completion to, or resources being used, and states of execution such as started, suspended, and so on. Used this way activity is the modeling basis for the WfProcess interface in the OMG Workflow Management Facility, www.omg.org/cgi-bin/doc?formal/00-05-02. It is expected that profiles will include class libraries with standard classes that are used as root classes for activities in the user model. Vendors may define their own libraries, or support user-defined features on activity classes.

Nodes and edges have token flow rules. Nodes control when tokens enter or leave them. Edges have rules about when a token may be taken from the source node and moved to the target node. A token traverses an edge when it satisfies the rules for target node, edge, and source node all at once. This means a source node can only offer tokens to the outgoing edges, rather than force them along the edge, because the tokens may be rejected by the edge or the target node on the other side. Since multiple edges can leave the same node, token flow semantics is highly distributed and subject to timing issues and race conditions, as is any distributed system. There is no specification of the order in which rules are applied on the various nodes and edges in an activity. It is the responsibility of the modeler to ensure that timing issues do not affect system goals, or that they are eliminated from the model. Execution profiles may tighten the rules to enforce various kinds of execution semantics.

Start at ActivityEdge and ActivityNode to see the token management rules.

Tokens cannot "rest" at control nodes, such as decisions and merges, waiting to moving downstream. Control nodes act as traffic switches managing tokens as they make their way between object nodes and actions, which are the nodes where tokens can rest for a period of time. Initial nodes are excepted from this rule.
A data token with no value in is called the null token. It can be passed along and used like any other token. For example, an action can output a null token and a downstream decision point can test for it and branch accordingly. Null tokens satisfy the type of all object nodes.

The semantics of activities is specified in terms of these token rules, but only for the purpose of describing the expected runtime behavior. Token semantics is not intended to dictate the way activities are implemented, despite the use of the term "execution". They only define the sequence and conditions for behaviors to start and stop. Token rules may be optimized in particular cases as long as the effect is the same.

(IntermediateActivities) Activities can have multiple tokens flowing in them at any one time, if required. Special nodes called object nodes provide and accept objects and data as they flow in and out of invoked behaviors, and may act as buffers, collecting tokens as they wait to move downstream.

(CompleteActivities) Each time an activity is invoked, the isSingleExecution attribute indicates whether the same execution of the activity handles tokens for all invocations, or a separate execution of the activity is created for each invocation. For example, an activity that models a manufacturing plant might have a parameter for an order to fill. Each time the activity is invoked, a new order enters the flow. Since there is only one plant, one execution of the activity handles all orders. If a single execution of the activity is used for all invocations, the modeler must consider the interactions between the multiple streams of tokens moving through the nodes and edges. Tokens may reach bottlenecks waiting for other tokens ahead of them to move downstream, they may overtake each other due to variations in the execution time of invoked behaviors, and most importantly, may abort each other with constructs such as activity final.

If a separate execution of the activity is used for each invocation, tokens from the various invocations do not interact. For example, an activity with a context classifier, but that is not a method, is invoked when the classifier is instantiated, and the modeler will usually want a separate execution of the activity for each instance of the classifier. A new activity execution for each invocation reduces token interaction, but might not eliminate it. For example, an activity may have a loop creating tokens
to be handled by the rest of the activity, or an unsynchronized flow that is aborted by an activity final. In these cases, modelers must consider the same token interaction issues as using a single activity execution for all invocations. Also see the effect of non-reentrant behaviors described at "Action". Except in CompleteActivities, each invocation of an activity is executed separately; tokens from different invocations do not interact.

Nodes and edges inherited from more general activities can be replaced. See RedefinableElement for more information on overriding inherited elements.

(IntermediateActivities) If a single execution of the activity is used for all invocations, the modeler must consider additional interactions between tokens. Tokens may reach bottlenecks waiting for tokens ahead of them to move downstream, they may overtake each other due to the ordering algorithm used in object node buffers, or due to variations in the execution time of invoked behaviors, and most importantly, may abort each other with constructs such as activity final, exception outputs, and
interruptible regions.

(CompleteActivities) Complete activities add functionality that also increases interaction. For example, streaming outputs create tokens to be handled by the rest of the activity. In these cases, modelers must consider the same token interaction issues even when using a separate execution of activity execution for all invocations.

(CompleteActivities) Interruptible activity regions are groups of nodes within which all execution can be terminated if an interruptible activity edge is traversed leaving the region.

See "ActivityNode" and "ActivityEdge" for more information on the way activities function. An activity with no nodes and edges is well-formed, but unspecified. It may be used as an alternative to a generic behavior in activity modeling. See "ActivityPartition" for more information on grouping mechanisms in activities.

Semantic Variation Points

No specific variations in token management are defined, but extensions may add new types of tokens that have their own flow rules. For example, a BPEL extension might define a failure token that flows along edges that reject other tokens. Or an extension for systems engineering might define a new control token that terminates executing actions.

Notation

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

The notation for an activity is a combination of the notations of the nodes and edges it contains, plus a border and name displayed in the upper left corner. Activity parameter nodes are displayed on the border. Actions and flows that are contained in the activity are also depicted.

Pre- and postcondition constraints, inherited from Behavior, are shown as with the keywords «precondition» and «postcondition», respectively. These apply globally to all uses of the activity. See Figure 201 and Behavior in Common Behavior. Compare to local pre- and postconditions on Action.

(CompleteActivities) The keyword «singleExecution» is used for activities that execute as a single shared execution.

Otherwise, each invocation executes in its space. See the notation sections of the various kinds of nodes and edges for more information.


The notation for classes can be used for diagramming the features of a reflective activity as shown below, with the keyword "activity" to indicate it is an activity class. Association and state machine notation can also be used as necessary.



Presentation OptionExamples

The definition of Process Order below uses the border notation to indicate that it is an activity. It has pre and post conditions on the order (see Behavior). All invocations of it use the same execution.

Process Order



The diagram below is based on a standard part selection workflow within an airline design process in section 6.1.1.2 of the Workflow Process Definition RFP, bom/2000-12-11. Notice that the Standards Engineer insures that the substeps in Provide Required Part are performed in the order specified and under the conditions specified, but doesn't necessarily perform the steps. Some of them are performed by the Design Engineer even though the Standards Engineer is managing the process. The Expert Part Search behavior can result in a part found or not. When a part is not found, it is assigned to the Assign Standards
Engineer activity. Lastly, Specify Part Mod Workflow invocation produces entire activities and they are passed to subsequent invocations for scheduling and execution (i.e. Schedule Pat Mod Workflow, Execute Part Mod Workflow, and Research Production Possibility). In other words, behaviors can produce tokens that are activities that can in turn be executed; in short,runtime activity generation and execution.


The diagram below is based on a trouble-ticket activity defined in section 6.1.1.3 of the Workflow Process Definition RFP, bom/2000-12-11.


Rationale

Activities are introduced to flow models that coordinate other behaviors, including other flow models. It supports class features to model control and monitoring of executing processes, and relating them to other objects, for example in an organization model.

Changes from previous UML

Activity replaces ActivityGraph in UML 1.5. Activities are redesigned to use a Petri-like semantics instead of state machines.

Among other benefits, this widens the number of flows that can be modeled, especially those that have parallel flows. Activity also replaces procedures in UML 1.5, as well as the other control and sequencing aspects, including composite and collection actions.

ActivityEdge


An activity edge is an abstract class for directed connections between two activity nodes.

Description

ActivityEdge is an abstract class for the connections along which tokens flow between activity nodes. It covers control and data flow edges.

Description (CompleteActivities)

Edges support controlling token flow and be contained in interruptible regions.

Associations (BasicActivities)

Associations (IntermediateActivities)

Associations (StructuredActivities)
·
inStructuredNode : StructuredActivityNode [0..1]Structured activity node containing the edge.
Associations (CompleteActivities)
Constraints

[1] The source and target of an edge must be in the same activity as the edge.

[2] Activity edges may be owned only by activities or groups.

Semantics

Activity edges are directed connections, that is, they have a source and a target, along which tokens may flow.

Other rules for when tokens may be passed along the edge depend the kind of edge and characteristics of its source and target.

See the children of ActivityEdge and ActivityNode. The rules may be optimized to a different algorithm as long as the effect is the same.

Semantics (IntermediateActivities)

The guard must evaluate to true for every token that is offered to pass along the edge. Tokens in the intermediate level ofactivities can only pass along the edge individually at different times. See application of guards at DecisionNode.

Semantics (CompleteActivities)

Any number of tokens can pass along the edge, in groups at one time, or individually at different times. The weight attribute dictates the minimum number of tokens that must traverse the edge at the same time. It is a value specification evaluated every time a new token becomes available at the source. It must evaluate to a positive integer or null, and may be a constant, that is, a LiteralInteger or a LiteralNull. When the minimum number of tokens are offered, all the tokens at the source are offered to the target all at once. The guard must evaluate to true for each token. If the guard fails for any of the tokens, and this reduces the number of tokens that can be offered to the target to less than the weight, then all the tokens fail to be offered. A null weight means that all the tokens at the source are offerred to the target. This can be combined with a join to take all of the tokens at the source when certain conditions hold. See examples in Figure 210. A weaker but simpler alternative to weight is grouping information into larger objects so that a single token carries all necessary data. See additional functionality for guards at DecisionNode.

Other rules for when tokens may be passed along the edge depend the kind of edge and characteristics of its source and target. See the children of ActivityEdge and ActivityNode. The rules may be optimized to a different algorithm as long as the effect is the same. For example, if the target is an object node that has reached its upper bound, no token can be passed. The implementation can omit unnecessary weight evaluations until the downstream object node can accept tokens.

Edges can be named, by inheritance from RedefinableElement, which is a NamedElement. However, edges are not required to have unique names within an activity. The fact that Activity is a Namespace, inherited through Behavior, does not affect this, because the containment of edges is through ownedElement, the general ownership metaassociation for Element that does not imply unique names, rather than ownedMember.

Edges inherited from more general activities can be replaced. See RedefinableElement for more information on overriding inherited elements.

Semantic Variation Points

See variations at children of ActivityEdge and ActivityNode.

Notation

An activity edge is notated by a stick-arrowhead line connecting two activity nodes. If the edge has a name it is notated near the arrow.


An activity edge can also be notated using a connector, which is a small circle with the name of the edge in it. The circles and lines involved map to a single activity edge in the model. Every connector with a given label must be paired with exactly one other with the same label on the same activity diagram. One connector must have exactly one incoming edge and the other exactly one outgoing edge, each with the same type of flow, object or control. This assumes the UML 2.0 Diagram
Interchange RFP supports the interchange of diagram elements and their mapping to model elements.


Notation (CompleteActivities)

The weight of the edge many be shown in curly braces that contain the weight. The weight is a value specification that is a positive integer, which may be a constant. When regions have interruptions, a lightning-bolt style activity edge expresses this interruption, see InterruptibleActivityRegion. See Pin for filled arrowhead notation.

Examples (BasicActivities)

In the example illustrated below, the arrowed line connecting Fill Order to Ship Order is a control flow edge. This means that when the Fill Order behavior is completed, control is passed to the Ship Order. Below it, the same control flow is shown with an edge name. The one at the bottom left employs connectors, instead of a continuous line. On the upper right, the arrowed lines starting from Send Invoice and ending at Make Payment (via the Invoice object node) are object flow edges. This indicates that the flow of Invoice objects goes from Send Invoice to Make Payment.


In the example below, a connector is used to avoid drawing a long edge around one tine of the fork. If a problem is not priority one, the token going to the connector is sent to the merge instead of the one that would arrive from Revise Plan for priority one problems. This is equivalent to the activity shown in Figure 212, which is how Figure 211 is stored in the model.



Examples (CompleteActivities)

The figure below illustrates three examples of using the weight attribute. The Cricket example uses a constant weight to indicate that a cricket team cannot be formed until eleven players are present. The Task example uses a non-constant weight to indicate that an invoice for a particular job can only be sent when all of its tasks have been completed. The proposal example depicts an activity for placing bids for a proposal, where many such bids can be placed. Then, when the bidding period is over, the Award Proposal Bid activity reads all the bids as a single set and determines which vendor to award the bid.



Rationale

Activity edges are introduced to provide a general class for connections between activity nodes.

Changes from previous UML

ActivityEdge replaces the use of (state) Transition in UML 1.5 activity modeling. It also replaces data flow and control flow links in UML 1.5 action model.

ActivityFinalNode


An activity final node is a final node that stops all flows in an activity.

Description

An activity may have more than one activity final node. The first one reached stops all flows in the activity.

Attributes

None.

Associations

None.

Stereotypes

None.

Tagged Values

None.

Constraints

None.

Semantics

A token reaching an activity final node aborts all flows in the containing activity, that is the activity is terminated, and the token is destroyed. All tokens offered on the incoming edges are accepted. Any object nodes declared as outputs are passed out of the containing activity. If there is more than one final node in an activity, the first one reached terminates the activity, including the flow going towards the other activity final.

If it is not desired to abort all flows in the activity, use flow final instead. For example, if the same execution of an activity is being used for all its invocations, then multiple streams of tokens will be flowing through the same activity. In this case, it is probably not desired to abort all tokens just because one reaches an activity final. Using a flow final will simply consume the tokens reaching it without aborting other flows. Or arrange for separate invocations of the activity to use separate executions of the activity, so tokens from separate invocations will not affect each other.

Semantic Variation Points

None.

Notation

Activity final nodes are notated as a solid circle with a hollow circle, as indicated in the figure below. It can be thought of as a goal notated as "bull's eye," or target.


Presentation Option

Style Guidelines

Examples

The first example below depicts that when the Close Order behavior is completed, all tokens in the activity are terminated.
This is indicated by passing control to an activity final node.



The next figure is based on an example for an employee expense reimbursement process in section 6.1.1.1 of the Workflow Process Definition RFP, bom/2000-12-11. It uses an activity diagram that illustrates two parallel flows racing to complete. The first one to reach the activity final aborts the others. The two flows appear in the same activity so they can share data, for example who to notify in the case of no action.



The last figure is based on the second example in section 6.1.1.4 of the Workflow Process Definition RFP, bom/2000-12-11.

Here, two ways to reach an activity final exist; but it is result of exclusive "or" branching, not a "race" situation like the previous example. This example uses two activity final nodes, which has the same semantics as using one with two edges targeting it. The Notify of Modification behavior must not take long or the activity finals might kill it.



Rationale

Activity final nodes are introduced to model non-local termination of all flows in an activity.

Changes from previous UML

ActivityFinal is new in UML 2.0.

ActivityGroup

(IntermediateActivities) An activity group is an abstract class that for defining sets of nodes and edges in an activity.

Description

Activity groups are a generic grouping construct for nodes and edges. Nodes and edges can belong to more than group. They have no inherent semantics and can be used for various purposes. Subclasses of ActivityGroup may add semantics.

Attributes

None.

Associations


Constraints

[1] All nodes and edges of the group must be in the same activity as the group.

[2] No node or edge in a group may be contained by its subgroups or its containing groups, transitively.

[3] Groups may only be owned by activities or groups.

Semantics

None.

Notation

None.

Examples

None.

Rationale

Activity groups provide a generic grouping mechanism that can be used for various purposes, as defined in the subclasses of ActivityGroup, and in extensions and profiles.

Changes from previous UML

ActivityGroups are new in UML 2.0.

ActivityNode

An activity node is an abstract class for points in the flow of an activity connected by edges.

Description

An activity node is an abstract class for the steps of an activity. It covers invocation nodes, control nodes, and object nodes.
Nodes can be replaced in generalization and (CompleteActivities) be contained in interruptible regions.

Attributes (CompleteStructuredActivities)
Associations (BasicActivities)
Associations (IntermediateActivities)
Associations (StructuredActivities)
Associations
Constraints

[1] Activity nodes can only be owned by activities or groups.

Semantics

Nodes can be named, however, nodes are not required to have unique names within an activity to support multiple invocations of the same behavior or multiple uses of the same action. See Action, which is a kind of node. The fact that Activity is a Namespace, inherited through Behavior, does not affect this, because the containment of nodes is through ownedElement, the general ownership metaassociation for Element that does not imply unique names, rather than ownedMember. Other than naming, and functionality added by the complete version of activities, an activity node is only a point in an activity at this level
of abstraction. See the children of ActivityNode for additional semantics.

Nodes inherited from more general activities can be replaced. See RedefinableElement for more information on overriding inherited elements, and Activity for more information on activity generalization. See children of ActivityNode for additional semantics.

(CompleteStructuredActivities) If the mustIsolate flag is true for an activity node, then any access to an object by an action within the node must not conflict with access to the object by an action outside the node. A conflict is defined as an attempt to write to the object by one or both of the actions. If such a conflict potentially exists, then no such access by an action outside the node may be interleaved with the execution of any action inside the node. This specification does not constrain the ways in which this rule may be enforced. If it is impossible to execute a model in accordance with these rules, then it is ill formed.

Notation

The notations for activity nodes are illustrated below. There are a three kinds of nodes: action node, object node, and control node. See these classes for more information.



Examples

This figure illustrates the following kinds of activity node: action nodes (e.g., Receive Order, Fill Order), object nodes (Invoice), and control nodes (the initial node before Receive Order, the decision node after Receive Order, and the fork node and Join node around Ship Order, merge node before Close Order, and activity final after Close Order).



Rationale

Activity nodes are introduced to provide a general class for nodes connected by activity edges.

Changes from previous UML

ActivityNode replaces the use of StateVertex and its children for activity modeling in UML 1.5.

ActivityParameterNode

An activity parameter node is an object node for inputs and outputs to activities.

Description

Activity parameters are object nodes at the beginning and end of flows, to accept inputs to an activity and provide outputs from it.
(CompleteActivities) Activity parameters inherit support for streaming and exceptions from Parameter.

Attributes

None.

Associations
Constraints

[1] Activity parameter nodes must have parameters from the containing activity.

[2] The type of an activity parameter node is the same as the type of its parameter.

[3] Activity parameter nodes must have either no incoming edges or no outgoing edges.

[4] Activity parameter object nodes with no incoming edges and one or more outgoing edges must have a parameter with in  or inout direction.

[5] Activity parameter object nodes with no outgoing edges and one or more incoming edges must have a parameter with in, inout, or return direction.See Activity.

Semantics

When an activity in invoked, the inputs values are placed as tokens on the input activity parameter nodes, those with no incoming edges. Outputs of the activity must flow to output activity parameter nodes, those with no outgoing edges. See semantics at ObjectNode, Action, and ActivityParameterNode.

Notation

Also see notation at Activity.




(CompleteActivities) The figure below shows annotations for streaming and exception activity parameters, which are same as for pins. See Parameter for semantics of stream and exception parameters.



Presentation Option

(CompleteActivities) See presentation option for Pin when parameter is streaming. This can be used for activity parameters also.

Examples

In the example below, production materials are fed into printed circuit board. At the end of the activity, computers are quality checked.

(CompleteActivities) In the example below, production materials are streaming in to feed the ongoing printed circuit board fabrication. At the end of the activity, computers are quality checked. Computers that do not pass the test are exceptions. See Parameter for semantics of streaming and exception parameters.


Rationale

Activity parameter nodes are introduced to model parameters of activities in way that integrates easily with the rest of the flow model.

Changes from previous UML

ActivityParameterNode is new in UML 2.0.

ActivityPartition

(IntermediateActivities) An activity partition is a kind of activity group for identifying actions that have some characteristic in common.

Description

Partitions divide the nodes and edges to constrain and show a view of the contained nodes. Partitions can share contents. They often correspond to organizational units in a business model. They may be used to allocate characteristics or resources among the nodes of an activity.

Attributes

Associations
Constraints

[1] A partition with isDimension = true may not be contained by another partition.

[2] No node or edge of a partition may be in another partition in the same dimension.

[3] If a partition represents a part, then all the non-external partitions in the same dimension and at the same level of nesting in that dimension must represent parts directly contained in the internal structure of the same classifier.

[4] If a non-external partition represents a classifier and is contained in another partition, then the containing partition must represent a classifier, and the classifier of the subpartition must be nested in the classifier represented by the containing partition, or be at the contained end of a strong composition association with the classifier represented by the containing partition.

[5] If a partition represents a part and is contained by another partition, then the part must be of a classifier represented by the containing partition, or of a classifier that is the type of a part representing the containing partition.

Semantics

Partitions do not affect the token flow of the model. They constrain and provide a view on the behaviors invoked in activities.

Constraints vary according to the type of element that the partition represents. The following constraints are normative:

1) Classifier
Behaviors of invocations contained by the partition are the responsibility of instances of the classifier represented by the partition. This means the context of invoked behaviors is the classifier. Invoked procedures containing a call to an operation or sending a signal must target objects at runtime that are instances of the classifier.

2) Instance
This imposes the same constraints as classifier, but restricted to a particular instance of the classifier.

3) Part
Behaviors of invocations contained by the partition are the responsibility of instances playing the part represented by the partition. This imposes the constraints for classifiers above according to the type of the part. In addition, invoked procedures containing a call to an operation or sending a signal must target objects at runtime that play the part at the time the message is sent. Just as partitions in the same dimension and nesting must be represented by parts of the same classifier's internal
structure, all the runtime target objects of operation and signal passing invoked by the same execution of the activity must play parts of the same instance of the structured classifier. In particular, if an activity is executed in the context of a particular object at runtime, the parts of that object will be used as targets. If a part has more than one object playing it at runtime, the invocations are treated as if they were multiple, that is, the calls are sent in parallel, and the invocation does not complete until all the operations return.

4) Attribute and Value
A partition may be represented by an attribute and its subpartitions by values of that attribute. Behaviors of invocations contained by the subpartition have this attribute and the value represented by the subpartition. For example, a partition may represent the location at which a behavior is carried out, and the subpartitions would represent specific values for that attribute, such as Chicago. The location attribute could be on the process class associated with an activity, or added in a profile to extend behaviors with these attributes.

A partition may be marked as being a dimension for its subpartitions. For example, an activity may be have one dimension of partitions for location at which the contained behaviors are carried out, and another for the cost of performing them.

Dimension partitions cannot be contained in any other partition.

Partitions may be used in a way that provides enough information for review by high-level modelers, though not enough for execution. For example, if a partition represents a classifier, then behaviors in that partition are the responsibility of instances of the classifier, but the model may or may not say which instance in particular. In particular, a behavior in the partition calling an operation would be limited to an operation on that classifier, but an input object flow to the invocation might not be
specified to tell which instance should be the target at runtime. The object flow could be specified in a later stage of development to support execution. Another option would be to use partitions that represent parts. Then when the activity executes in the context of a particular object, the parts of that object at runtime will be used as targets for the operation calls, as described above.

External partitions are intentional exceptions to the rules for partition structure. For example, a dimension may have partitions showing parts of a structured classifier. It can have an external partition that does not represent one of the parts, but a completely separate classifier. In business modeling, external partitions can be used to model entities outside a business.

Notation

Activity partition may be indicated with two, usually parallel lines, either horizontal or vertical, and a name labeling the partition in a box at one end. Any activity nodes and edges placed between these lines are considered to be contained within the partition. Swimlanes can express hierarchical partitioning by representing the children in the hierarchy as further partitioning of the parent partition, as illustrated in b), below. Diagrams can also be partitioned multidimensionally, as depicted in c), below, where, each swim cell is an intersection of multiple partitions. The specification for each dimension (e.g., part, attribute) is expressed in next to the appropriate partition set.


In some diagramming situations, using parallel lines to delineate partitions is not practical. An alternate is to place the partition name in parenthesis above the activity name, as illustrated for actions in a), below. A comma-delimited list of partition names means that the node is contained in more than one partition. A double colon within a partition name indicates that the partition is nested, with the larger partitions coming earlier in the name. When activities are considered to occur outside the domain of a particular model, the partition can be label with the keyword «external», as illustrated in b) below. Whenever an activity in a swimlane is marked «external», this overrides the swimlane and dimension designation.



Presentation Option

When partitions are combined with the frame notation for Activity, the outside edges of the top level partition can be merged with the activity frame.

Examples

The figures below illustrate an example of partitioning the order processing activity diagram into "swim lanes." The top partition contains the portion of an activity for which the Order Department is responsible; the middle partition, the Accounting Department, and the bottom the Customer. These are attributes of the behavior invoked in the partitions, except for Customer, which is external to the domain. The flow of the invoice is not a behavior, so it does not need to appear in a
partition.


The example below depicts multidimensional swim lanes. The Receive Order and Fill Order behaviors are performed by an instance of the Order Processor class, situated in Seattle, but not necessarily the same instance for both behaviors. Even though the Make Payment is contain with in the Seattle/Accounting Clerk swim cell, it's performer and location are not specified by the containing partition, because it has an overriding partition.



Rationale

Activity partitions are introduced to support the assignment of domain-specific information to nodes and edges.

Changes from previous UML

Edges can be contained in partitions in UML 2.0. Additional notation is provided for cases when swimlanes are too cumbersome. Partitions can be hierarchical and multidimensional. The relation to classifier, parts, and attributes is formalized, including external partitions as exceptions to these rules.

CentralBufferNode

A central buffer node is a object node for managing flows from multiple sources and destinations.

Description

A central buffer node accepts tokens from upstream objects nodes and passes them along to downstream object nodes. They act as a buffer for multiple in flows and out flows from other object nodes. They do not connect directly to actions.

Attributes

None.

Associations

None.

Semantics

See semantics at ObjectNode. All object nodes have buffer functionality, but central buffers differ in that they are not tied to an action as pins are, or to an activity as activity parameter nodes are. See example below.

Notation

See notation at ObjectNode. A central buffer may also have the keyword «centralBuffer» as shown below. This is useful when it needs to be distinguished from the standalone notation for pins shown on the left of Figure 280 and the top left of Figure 286.

Examples

In the example below, the behaviors for making parts at two factories produce finished parts. The central buffer node collects the parts, and behaviors after it in the flow use them as needed. All the parts that are not used will be packed as spares, because each token can only be drawn from the object node by one outgoing edge.



Rationale

Central buffer nodes give additional support for queuing and competition between flowing objects.

Changes from previous UML

CentralBufferNode is new in UML 2.0.

Clause

A clause is an element that represents a single branch of a conditional construct, including a test and a body section. The body section is executed only if (but not necessarily if) the test section evaluates true.

Attributes

none

Associations (StructuredActivities)
  • test : ActivityNode [0..*]
A nested activity fragment with a designated output pin that specifies the result of the test.
  • body : ActivityNode [0..*]
A nested activity fragment that is executed if the test evaluates to true and the clause is chosen over any concurrent clauses that also evaluate to true.
  • predecessorClause : Clause [*]
A set of clauses whose tests must all evaluate false before the current clause can be tested.
  • successorClause : Clause [*]
A set of clauses which may not be tested unless the current clause tests false.
  • decider : OutputPin [1]
An output pin within the test fragment the value of which is examined after execution of the test to determine whether the body shoud be executed.

Associations ((CompleteStructuredActivities))

  • bodyOutput : OutputPin [0..*]
A list of output pins within the body fragment whose values are copied to the result pins of the containing conditional node or conditional node after execution of the clause body.

Semantics

The semantics are explained under "ConditionalNode".

ConditionalNode

A conditional node is a structured activity node that represents an exclusive choice among some number of alternatives.

Description

A conditional node consists of one or more clauses. Each clause consists of a test section and a body section. When the conditional node begins execution, the test sections of the clauses are executed. If one or more test sections yield a true value, one of the corresponding body sections will be executed. If more than one test section yields a true value, only one body section will be executed. The choice is nondeterministic unless the test sequence of clauses is specified. If no test section
yields a true value, then no body section is executed; this may be a semantic error if output values are expected from the conditional node.

In general, test section may be executed in any order, including simultaneously (if the underlying execution architecture supports it). The result may therefore be nondeterministic if more than one test section can be true concurrently. To enforce ordering of evaluation, sequencing constraints may be specified among clauses. One frequent case is a total ordering of clauses, in which case the result is determinate. If it is impossible for more than one test section to evaluate true
simultaneously, the result is deterministic and it is unnecessary to order the clauses, as ordering may impose undesirable and unnecessary restrictions on implementation.Note that, although evaluation of test sections may be specified as concurrent, this does not require that the implementation evaluate them in parallel; it merely means that the model does not impose any order on evaluation.

An "else" clause is a clause that is a successor to all other clauses in the conditional and whose test part always returns true. A notational gloss is provided for this frequent situation.

Output values created in the test or body section of a clause are potentially available for use outside the conditional. However, any value used outside the conditional must be created in every clause, otherwise an undefined value would be accessed if a clause not defining the value were executed.

Attributes (StructuredActivities)
Associations (StructuredActivities)
Associations (CompleteStructuredActivities)
Constraints

None.

Semantics

No part of a conditional node is executed until all control-flow or data-flow predecessors of the conditional node have completed execution. When all such predecessors have completed execution and made tokens available to inputs of the conditional node, the conditional node captures the input tokens and begins execution.

The test section of any clause without a predecessorClause is eligible for execution immediately. If a test section yields a false value, a control token is delivered to all of its successorClauses. Any test section with a predecessorClause is eligible for execution when it receives control tokens from each of its predecessor clauses.

If a test section yields a true value, then the corresponding body section is executed provided another test section does not also yield a true value. If more than one test section yields a true value, exactly one body section will be executed, but it is indeterminate which one will be executed. When a body section is chosen for execution, the evaluation of all other test parts is terminated (just like an interrupting edge). If some of the test parts have external effects, terminating them may be another source of indeterminacy. Although test parts are permitted to produce side effects, avoiding side effects in tests will greatly reduce the chance of logical errors and race conditions in a model and in any code generated from it.

If no test section yields a true value, the execution of the conditional node terminates with no outputs. This may be a semantic error if a subsequent node requires an output from the conditional. It is safe if none of the clauses create outputs. If the isAssured attribute of the conditional node has a true value, the modeler asserts that at least one true section will yield a true value. If the isDeterminate attribute has a true value, the modeler asserts that at most one true section will concurrently yield a true value (the predecessor relationship may be used to enforce this assertion). Note that it is, in general, impossible for a computer system to verify these assertions, so they may provide useful information to a code generator, but if the assertions are incorrect then incorrect code may be generated.

When a body section is chosen for execution, all of its nodes without predecessor flows within the conditional receive control tokens and are enabled for execution. When execution of all nodes within the body section has completed, execution of the conditional node is complete and its successors are enabled.

Within the body section, variables defined in the loop node or in some higher-level enclosing node may be accessed and updated with new values. Values that are used in a data flow manner must be created or updated in all clauses of the conditional, otherwise undefined values would be accessed.

Notation

Presentation Option

Style Guidelines

Mixing sequential and concurrent tests in one conditional may be confusing, although it is permitted.

Examples

Rationale

Conditional nodes are introduced to provide a structured way to represent decisions.

Changes from previous UML

Conditional nodes replace ConditionalAction from the UML 1.5 action model.

ControlFlow

A control flow is an edge starts an activity node after the previous one is finished.

Description

Objects and data cannot pass along a control flow edge.

Attributes

None.

Associations

None.

Constraints

[1] Control flows may not have object nodes at either end.

Semantics

See semantics inherited from ActivityEdge. A control flow is an activity edge that only passes control tokens. Tokens offered by the source node are all offered to the target node.

Notation

A control flow is notated by an arrowed line connecting two actions.



Examples

The figure below depicts an example of the Fill Order action passing control to the Ship Order action. The activity edge between the two is a control flow which indicates that when Fill Order is completed, Ship Order is invoked.


Rationale

Control flow is introduced to model the sequencing of behaviors that does not involve the flow of objects.

Changes from previous UML

Explicitly modeled control flows are new to activity modeling in UML 2.0. They replace the use of (state) Transition in UML 1.5 activity modeling. They replace control flows in UML 1.5 action model.

 ControlNode

A control node is an abstract activity node that coordinates flows in an activity.

Description

A control node is an activity node used to coordinate the flows between other nodes. It covers initial node, final node and its children, fork node, join node, decision node, and merge node.

Attributes

None.

Associations

None.

Stereotypes

None.

Tagged Values

None.

Constraints

[1] The edges coming into and out of a control node must be either all object flows or all control flows.

Semantics

See semantics at Activity. See subclasses for the semantics of each kind of control node.

Semantic Variation Points

None.

Notation

The notations for control nodes are illustrated below: decision node, initial node, activity final, and flow final.

(IntermediateActivities) Fork node and join node are the same symbol, they have different semantics and are distinguished notationally by the way edges are used with them. For more information, see ForkNode and JoinNode below.

Examples

The figure below contains examples of various kinds of control nodes. An initial node is depicted in the upper left as triggering the Receive Order action. A decision node after Received Order illustrates branching based on order rejected or order accepted conditions. Fill Order is followed by a fork node which passes control both to Send Invoice and Ship Order. The join node indicates that control will be passed to the merge when both Ship Order and Accept Payment are completed. Since a merge will just pass the token along, Close Order activity will be invoked. (Control is also passed to Close Order whenever an order is rejected.) When Close Order is completed, control passes to an activity final.


Rationale


Control nodes are introduced to provide a general class for nodes that coordinate flows in an activity.

Changes from previous UML

ControlNode replaces the use of PseudoState in UML 1.5 activity modeling.

 DataStoreNode

A data store node is a central buffer node for non-transient information.

Description

A data store keeps all tokens that enter it, copying them when they are chosen to move downstream. Incoming tokens containing a particular object replace any tokens in the object node containing that object.

Attributes

None.

Associations

None

Constraints

None.

Semantics

Tokens chosen to move downstream are copied so that tokens appear to never leave the data store. If a token containing an object is chosen to move into a data store, and there is a token containing that object already in the data store, then the chosen token replaces existing one. Selection and transformation behavior on outgoing edges can be designed to get information out of the data store, as if a query were being performed. For example, the selection behavior can identify an object to retrieve and the transformation behavior can get the value of an attribute on that object. Selection can also be designed to only succeed when a downstream action has control passed to it, thereby implementing the pull semantics of earlier forms of data flow.

Notation

The data store notation is a special case of the object node notation, using the label «datastore».



Presentation Option

Style Guidelines

Examples

The figure below is an example of using a data store node.

Rationale

Data stores are introduced to support earlier forms of data flow modeling in which data is persistent and used as needed, rather than transient and used when available.

Changes from previous UML

Data stores are new in UML 2.0.

DecisionNode

A decision node is a control node that chooses between outgoing flows.

Description

A decision node has one incoming edge and multiple outgoing activity edges.

Attributes

None.

Associations
Stereotypes

None.

Tagged Values

None.

Constraints

[1] A decision node has one incoming edge.

[2] A decision input behavior has one input parameter and one output parameter. The input parameter must be the same as or a supertype the type of object token coming along the incoming edge. The behavior cannot have side effects.

Semantics

Each token arriving at a decision node can traverse only one outgoing edge. Tokens are not duplicated. Each token offered by the incoming edge is offered to the outgoing edges.

Most commonly, guards of the outgoing edges are evaluated to determine which edge should be traversed. The order in which guards are evaluated is not defined, because edges in general are not required to determine which tokens they accept in any particular order. The modeler should arrange that each token only be chosen to traverse one outgoing edge, otherwise there will be race conditions among the outgoing edges. For decision points, a predefined guard "else" may be defined for at most one outgoing edge. This guard succeeds for a token only if the token is not acepted by all the other edges outgoing from the
decision point.

Notice that the semantics only requires that the token traverse one edge, rather than be offered to only one edge. Multiple edges may be offered the token, but if only one of them has a target that accepts the token, then that edge is traversed. If multiple edges accept the token and have approval from their targets for traversal at the same time, then the semantics is not defined.

If a decision input behavior is specified, then each token is passed to the behavior before guards are evaluated on the outgoing edges. The output of the behavior is available to the guard. Because the behavior is used during the process of offering tokens to outgoing edges, it may be run many times on the same token before the token is accepted by those edges. This means the behavior cannot have side effects. It may not modify objects, but it may for example, navigate from one object to another or get an attribute value from an object.

Semantic Variation Points

None.

Notation

The notation for a decision node is a diamond-shaped symbol, as illustrated on the left side of the figure below. Decision input behavior is specified by the keyword «decisionInput» placed in a note symbol, and attached to the appropriate decision node symbol as illustrated in the figure below.

A decision node must have a single activity edge entering it, and one or more edges leaving it. The functionality of decision node and merge node can be combined by using the same node symbol, as illustrated at the right side of the figure below. This case maps to a model containing a a merge node with all the incoming edges shown in the diagram and one outgoing edge to a decision node that has all the outgoing edges shown in the diagram. It assumes the UML 2.0 Diagram Interchange RFP supports the interchange of diagram elements and their mapping to model elements.

Presentation Option

Style Guidelines

Examples

The figure below contains a decision node that follows the Received Order behavior. The branching is based on whether order was rejected or accepted. An order accepted condition results in passing control to Fill Order and rejected orders to Close Order.


The example in the figure below illustrates an order process example. Here, an order item is pulled from stock and prepared for delivery. Since the item has been remove from inventory, the reorder level should also be checked; and if the actual level falls below a prespecified reorder point, more of the same type of item should be reordered.


Rationale

Decision nodes are introduced to support conditionals in activities. Decision input behaviors are introduced to avoid redudant recalculations in guards.

Changes from previous UML

Decision nodes replace the use of PseudoState with junction kind in UML 1.5 activity modeling.

ExceptionHandler


(ExtraStructuredActivities) An exception handler is an element that specifies a body to execute in case the specified exception occurs during the execution of the protected node.

Associations
  • protectedNode : ExecutableNode [1..1]
The node protected by the handler. The handler is examined if an exception propagates to the outside of the node.
  • handlerBody : ExecutableNode [1..1]
A node that is executed if the handler satisfies an uncaught exception.
  • exceptionType : Classsifier [1..*]
The kind of instances that the handler catches. If an exception occurs whose type is any of the classifiers in the set, the handler catches the exception and executes its body.
  • exceptionInput : ObjectNode
An object node within the handler body. When the handler catches an exception, the exception token is placed in this node, causing the body to execute.

Constraints

The exception body may not have any explicit input or output edges.(str-adv) The result pins of the exception handler body must correspond in number and types to the result pins of the protected node.

Semantics

If an exception occurs during the execution of an action, the set of execution handlers on the action is examined for a handler that matches the exception. A handler matches if the type of the exception is the same as or a descendant of one of the exception classifiers specified in the handler. If there is a match, the handler "catches" the exception. The exception object is placed in the exceptionInput node as a token to start execution of the handler body.

If the exception is not caught by any of the handlers on the node, all the tokens in the node are terminated and the exception propagates to the enclosing executable node or activity. If the exception propagates to the topmost level of the system and is not caught, the behavior of the system is unspecified. Profiles may specify what happens in such cases.

The exception body has no explicit input or output edges. It has the same access to its surrounding context as the protected node. The result tokens of the exception body become the result tokens of the protected node. Any control edges leaving the protected node receive control tokens on completion of execution of the exception body. When the execution body completes execution, it is as if the protected node had completed execution.

Semantic Variation Points

None.

Notation

The notation for exception handlers is illustrated in Figure 240. An exception handler for a protected node is shown by drawing a "lightning bolt" symbol from the boundary of the protected node to a small square on the boundary of the exception handler. The name of the exception type is placed next to the lightning bolt. The small square is the exception input node, and it must be owned by the handler body. Its type is the given exception type. Both the protected node and the exception handler must be at the same nesting level. (Otherwise the notation could be misinterpreted as an interrupting edge, which crosses a boundary.) Multiple exception handlers may may attached to the same protected node, each by its own lightning bolt.


Presentation Option

Style Guidelines

Examples

Figure 241 shows a matrix calculation. First a matrix is inverted, then it is multiplied by a vector to produce a vector. If the matrix is singular, the inversion will fail and a SingularMatrix exception occurs. This exception is handled by the exception handler labeled SingularMatrix, which executes the region containing the SubstituteVector1 action. If an overflow exception occurs during either the matirx inversion or the vector multiplication, the region containing the SubstituteVector2 action is executed.

The successors to an exception handler body are the same as the successors to the protected node. It is unnecessary to show control flow from the hander body. Regardless of whether the matrix operations complete without exception or whether one of the exception handlers is triggered, the action PrintResults is executed next.

Rationale

Changes from previous UML

ExceptionHandler replaces JumpHandler in UML 1.5.

Modeling of traditional break and continue statements can be accomplished using direct control flow from the statement to the control target.UML 1.5 combined the modeling of breaks and continues with exceptions, but that is no longer necessary and it is not recommended in this specification.

ExecutableNode


An executable node is an abstract class for activity nodes that may be executed. It is used as an attachment point for exception handlers.

Associations (StructuredActivities)

ExpansionKind

(ExtraStructuredActivities) ExpansionKind is an enumeration type used to specify how multiple executions of an expansion region interact. See "ExpansionRegion".

Enumeration Literals

ExpansionNode

(ExtraStructuredActivities) An expansion node is an object node used to indicate a flow across the boundary of an expansion region. A flow into a region contains a collection that is broken into its individual elements inside the region, which is executed once per element. A flow out of a region combines individual elements into a collection for use outside the region.

Associations
Semantics

See "ExpansionRegion".

Notation

See "ExpansionRegion".

 ExpansionRegion

(ExtraStructuredActivities) An expansion region is a structured activity region that executes multiple times corresponding to elements of an input collection.

Description

An expansion region is a strictly nested region of an activity with explicit input and outputs (modeled as ExpansionNodes).

Each input is a collection of values. If there are multiple input pins, each of them must hold the same kind of collection, although the types of the elements in the different collections may vary. The expansion region is executed once for each element (or position) in the input collection.

If an expansion region has outputs, they must be collections of the same kind and must contain elements of the same type as the corresponding inputs. The number of output collections at runtime can differ from the number of input collections. On each execution of the region, an output value from the region is inserted into an output collection at the same position as the input elements. If the region execution ends with no output, then nothing is added to the output collection. When this happens
the output collection will not have the same number of elements as the input collections, the region acts as a .

[Reviewer: text is missing]

If all the executions provide an output to the collection, then the output collections will have the same number of elements as the input collections.

The inputs and outputs to an expansion region are modeled as ExpansionNodes. From "outside" of the region, the values on these nodes appear as collections. From "inside" the region the values appear as elements of the collections. Object flow edges connect pins outside the region to input and output expansion nodes as collections. Object flow edges connect pins inside the  region to input and output expansion nodes as individual elements. From the inside of the region, these nodes are visible as individual values. If an expansion node has a name, it is the name of the individual element within the region.

Any object flow edges that cross the boundary of the region, without passing through expansion nodes, provide values that are fixed within the different executions of the region.

Attributes
  • mode : ExpansionKind
The way in which the executions interact:
parallel -- all interactions are independent
iterative -- the interactions occur in order of the elements
stream -- a stream of values flows into a single execution


Associations
  • inputElement : ExpansionNode[1..*]
An object node that holds a separate element of the input collection during each of the multiple executions of the region.
  • outputElement : ExpansionNode[0..*]
An object node that accepts a separate element of the output collection during each of the multiple executions of the region. The values are formed into a collection that is available when the execution of the region is complete.

Constraints

[1] An ExpansionRegion must have one or more argument ExpansionNodes and zero or more result ExpansionNodes.

Semantics

When an execution of an activity makes a token available to the input of an expansion region, the expansion region consumes the token and begins execution. The expansion region is executed once for each element in the collection (or once per element position, if there are multiple collections). The concurrency attribute controls how the multiple executions proceed:

If the value is parallel, the execution may happen in parallel, or overlapping in time, but they are not required to.

If the value is iterative, the executions of the region must happen in sequence, with one finishing before another can begin. The first iteration begins immediately. Subsequent iterations start when the previous iteration is completed. During each of these cases, one element of the collection is made available to the execution of the region as a token during each execution of the region. If the collection is ordered, the elements will be presented to the region in order; if the collection
in unordered, the order of presenting elements is undefined and not necessarily repeatable. On each execution of the region, an output value from the region is inserted into an output collection at the same position as the input elements.

If the value is stream, there is a single execution of the region, but its input place receives a stream of elements from the collection. The values in the input collection are extracted and placed into the execution of the expansion region as a stream, in order if the collection is ordered. Such a region must handle streams properly or it is ill defined. When the execution of the entire stream is complete, any output streams are assembled into collections of the same kinds as the
inputs.

Notation

An expansion region is shown as a dashed rounded box with one of the keywords concurrent, iterative, or streaming in the upper left corner.

Input and output expansion nodes are drawn as small rectangles divided by vertical bars into small compartments. (The symbol in meant to suggest a list of elements.) The expansion node symbols are placed on the boundary of the dashed box. Usually arrows inside and outside the expansion region will distinguish input and output expansion nodes. If not, then a small arrow can be used as with Pins (see Figure 284 ).

As a shorthand notation, the "list box pin" notation may be placed directly on an action symbol, replacing the pins of the action (Figure 243). This indicates an expansion region containing a single action. The equivalent full form is shown in Figure 244.



Presentation Option

The UML 1.5 notation for unlimited dynamicMultiplicity maps to an expansion region in parallel mode, with one behavior invoked in the region, as shown below.

Examples

Figure 246 shows an expansion region with two inputs and one output that is executed concurrently. Execution of the region does not begin until both input collections are available. Both collections must have the same number of elements.

The interior activity fragment is executed once for each position in the input collections. During each execution of the region, a pair of values, one from each collection, is available to the region on the expansion nodes. Each execution of the region produces a result value on the output expansion node. All of the result values are formed into a collection of the same size as the input collections. This output collection is available outside the region on the result node after all the
concurrent executions of the region have completed.

Figure 246 shows a fragment of an FFT (Fast Fourier Transform) computation containing an expansion region. Outside the region, there are operations on arrays of complex numbers. S, Slower, Supper, and V are arrays. Cut and shuffle are operations on arrays. Inside the region, two arithmetic operations are performed on elements of the 3 input arrays, yielding 2 output arrays. Different positions in the arrays do not interact, therefore the region can be executed concurrently on all positions.



The following example shows a use of the shorthand notation for an expansion region with a single action. In this example, the trip route outputs sets of flights and sets of hotels to book. The hotels may be booked independently and concurrently with each other and with booking the flight.



Using the UML 1.5 notation, specify Trip Route below can result in multiple flight segments, each of which must be booked separately. The Book Flight action will invoke the Book Flight behavior multiple times, once for each flight segment in the set passed to BookFlight.


Rationale

Expansion regions are introduced to support applying behaviors to elements of a set without constraining the order of  application.

Changes from previous UML

ExpansionRegion replaces MapAction, FilterAction, and dynamicConcurrency and dynamicMultiplicity attributes on ActionState. Dynamic multiplicities less than unlimited are not supported in UML 2.0.

FinalNode


A final node is an abstract control node at which a flow in an activity stops.

Description

See descriptions at children of final node.

Attributes

None.

Associations

None.

Constraints

[1] A final node has no outgoing edges.

Semantics

All tokens offered on incoming edges are accepted. See children of final node for other semantics.

Notation

The notations for final node are illustrated below. There are a two kinds of final node: activity final and (IntermediateActivities) flow final. For more detail on each of these specializations, see ActivityFinal and FlowFinal.


Examples

The figure below illustrates two kinds of final node: flow final and activity final. In this example, it is assumed that many components can be built and installed before finally delivering the resulting application. Here, the Build Component behavior occurs iteratively for each component. When the last component is built, the end of the building iteration is indicated with a flow final. However, even though all component building has come to an end, other behaviors are still executing. When the last component has been installed, the application is delivered. When Deliver Application has completed, control is passed to an activity final node--indicating that all processing in the activity is terminated.


Rationale

Final nodes are introduced to model where flows end in an activity.

Changes from previous UML

FinalNode replaces the use of FinalState in UML 1.5 activity modeling, but its concrete classes have different semantics than FinalState.

FlowFinalNode

A flow final node is a final node that terminates a flow.

Description

A flow final destroys all tokens that arrive at it. It has no effect on other flows in the activity.

Attributes

None.

Associations

None.

Constraints

None.

Semantics

Flow final destroys tokens flowing into it.

Notation

The notation for flow final is illustrated below.


Examples

In the example below, it is assumed that many components can be built and installed. Here, the Build Component behavior occurs iteratively for each component. When the last component is built, the end of the building iteration is indicated with a flow final. However, even though all component building has come to an end, other behaviors are still executing (such as Install Component).



Rationale

Flow final nodes are introduced to model termination or merging of a flow in an activity.

Changes from previous UML

Flow final is new in UML 2.0.

 ForkNode

A fork node is a control node that splits a flow into multiple concurrent flows.

Description

A fork node has one incoming edge and multiple outgoing edges.

Attributes

None.

Associations

None.

Constraints

[1] A fork node has one incoming edge.

Semantics

Tokens arriving at a fork are duplicated across the outgoing edges. Tokens offered by the incoming edge are all offered to the outgoing edges. When an offered token is accepted on all the outgoing edges, duplicates of the token are made and one copy traverses each edges. No duplication is necessary if there is only one outgoing edge, but it is not a useful case.

If guards are used on edges outgoing from forks, the modelers should ensure that no downstream joins depend on the arrival of  tokens passing through the guarded edge. If that cannot be avoided, then a decision node should be introduced to have the guard, and shunt the token to the downstream join if the guard fails. See example in Figure 212.

Notation

The notation for a fork node is simply a line segment, as illustrated on the left side of the figure below. In usage, however, the fork node must have a single activity edge entering it, and two or more edges leaving it. The functionality of join node and fork node can be combined by using the same node symbol, as illustrated at the right side of the figure below. This case maps to a model containing a a join node with all the incoming edges shown the diagram and one outgoing edge to a fork node that has all the outgoing edges shown in the diagram. It assumes the UML 2.0 Diagram Interchange RFP supports the interchange of diagram elements and their mapping to model elements.


Examples

In the example below, the fork node passes control to both the Ship Order and Send Invoice behaviors when Fill Order is completed.


Rationale

Fork nodes are introduced to support parallelism in activities.

Changes from previous UML

Fork nodes replace the use of PseudoState with fork kind in UML 1.5 activity modeling. State machine forks in UML 1.5 required synchronization between parallel flows through the state machine RTC step. UML 2.0 activity forks model unrestricted parallelism.

InitialNode

An initial node is a control node at which flow starts when the activity is invoked.

Description

An activity may have more than one initial node.

Attributes

None.

Associations

None.

Constraints

[1] An initial node has no incoming edges.

Semantics

An initial node is a starting point for invoking an activity. A control token is placed at the initial node when the activity starts.

Tokens in an initial node are offered to all outgoing edges. If an activity has more than one initial node, then invoking the activity starts multiple flows, one at each initial node. For convenience, initial nodes are an exception to the rule that control nodes cannot hold tokens if they are blocked from moving downstream (see Activity). This is equivalent interposing a CentralBufferNode between the initial node and its outgoing edges.

Note that flows can also start at other nodes, see ActivityParameterNode and AcceptEventAction, so initial nodes are not required for an activity to start execution.

Notation

Initial nodes are notated as a solid circle, as indicated in the figure below.



Examples

In the example below, the initial node passes control to the Receive Order behavior at the start of an activity.


Rationale

Initial nodes are introduced to model where flows start in an activity.

Changes from previous UML

InitialNode replaces the use of PseudoState with kind initial in UML 1.5 activity modeling.

InputPin

An input pin is a pin that holds input values to be consumed by an action. They are object nodes and receive values from other actions through object edges. See Pin, Action, and ObjectNode for more details.

Attributes

None.

Associations

None.

Constraints

[1] Input pins have incoming edges only.

InterruptibleActivityRegion

An interruptible activity region is an activity group that supports termination of tokens flowing in the portions of an activity.

Description

An interruptible region contains activity nodes. When a token leaves an interruptible region via edges designated by the region as interrupting edges, all tokens and behaviors in the region are terminated.

Attributes

None.

Associations (CompleteActivities)
Constraints

[1] Interrupting edges of a region must have their source node in the region and their target node outside the region in the same activity containing the region.

Semantics

The region is interrupted when a token traverses an interrupting edge. At this point the interrupting token has left the region and is not terminated.

Token transfer is still atomic, even when using interrupting regions. If a non-interrupting edge is passing a token from a source node in the region to target node outside the region, then the transfer is completed and the token arrives at the target even if in interruption occurs during the traversal. In other words, a token transition is never partial; it is either complete or it does not happen at all.

Do not use an interrupting region if it is not desired to abort all flows in the region in some cases. For example, if the same execution of an activity is being used for all its invocations, then multiple streams of tokens will be flowing through the same activity. In this case, it is probably not desired to abort all tokens just because one leaves the region. Arrange for separate invocations of the activity to use separate executions of the activity when employing interruptible regions, so tokens from each
invocation will not affect each other.

Notation

An interruptible activity region is notated by a dashed, round-cornered rectangle drawn around the nodes contained by the region. An interrupting edge is notation with a lightning-bolt activity edge.

Presentation Option

An option for notating an interrupting edge is an zig zag adornment on a straight line.


Examples

The first figure below illustrates that when an order cancellation request is made--only while receiving, filling, or shipping)



Rationale

Interruptible regions are introduced to support more flexible non-local termination of flow.

Changes from previous UML

Interruptible regions in activity modeling are new to UML 2.0.

 JoinNode

Description

A join node has multiple incoming edges and one outgoing edge.

(CompleteActivities) Join nodes have a boolean value specification using the names of the incoming edges to specify the conditions under which the join will emit a token.

Attributes

None.

Associations

None.

Associations (CompleteActivities)
Constraints

[1] A join node has one outgoing edge.

Semantics

If there is a token offered on all incoming edges, then tokens are offered on the outgoing edge according to the following join rules:
  1. If all the tokens offered on the incoming edges are control tokens, then one control token is offered on the outgoing edge.
  2. If some of the tokens offered on the incoming edges are control tokens and other are data tokens, then only the data tokens are offered on the outgoing edge.No joining of tokens is necessary if there is only one incoming edge, but it is not a useful case.

(CompleteActivities) The reserved string "and" used as a join specification is equivalent to a specification that requires at least one token offered on each incoming edge. It is the default. The join specification is evaluated whenever a new token is offered on any incoming edge. The evaluation is not interrupted by any new tokens offered during the evaluation, nor are concurrent evaluations started when new tokens are offered during an evaluation.

If any tokens are offered to the outgoing edge, they must be accepted or rejected for traversal before any more tokens are offered to the outgoing edge. If tokens are rejected for traversal, they are no longer offered to the outgoing edge. The join specification may contain the names of the incoming edges to refer to whether a token was offered on that edge at the time the evaluation started.

Other rules for when tokens may be passed along the outgoing edge depend the characteristics of the edge and its target. For example, if the outgoing edge targets an object node that has reached its upper bound, no token can be passed. The rules may be optimized to a different algorithm as long as the effect is the same. In the full object node example, the implementation can omit the unnecessary join evaluations until the down stream object node can accept tokens.

Notation

The notation for a join node is a line segment, as illustrated on the left side of the figure below. The join node must have one or more activity edges entering it, and only one edge leaving it. The functionality of join node and fork node can be combined by using the same node symbol, as illustrated at the right side of the figure below. This case maps to a model containing a a join node with all the incoming edges shown in the diagram and one outgoing edge to a fork node that has all the outgoing edges shown in the diagram. It assumes the UML 2.0 Diagram Interchange RFP supports the interchange of diagram elements and their mapping to model elements.




(CompleteActivities) Join specifications are shown near the join node, as shown below.


Examples

The example at the left of the figure indicates that a Join is used to synchronize the processing of the Ship Order and Accept Order behaviors. Here, when both have been completed, control is passed to Close Order.



(CompleteActivities) The example below illustrates how a join specification can be used to ensure that both a drink is selected and the correct amount of money has been inserted before the drink is dispensed. Names of the incoming edges are used in the join specification to refer to whether tokens are available on the edges.


Rationale

Join nodes are introduced to support parallelism in activities.

Changes from previous UML

Join nodes replace the use of PseudoState with join kind in UML 1.5 activity modeling.

LoopNode

(StructuredActivities) A loop node is a costructured activity node that represents a loop with setup, test, and body sections.

Description

Each section is a well-nested subregion of the activity whose nodes follow any predecessors of the loop and precede any successors of the loop. The test section may precede or follow the body section. The setup section is executed once on entry to the loop, and the test and body sections are executed repeatedly until the test produces a false value. The results of the final execution of the test or body are available after completion of execution of the loop.

Attributes
Associations (StructuredActivities)
  • setupPart : ActivityNode[0..*]
The set of nodes and edges that initialize values or perform other setup computations for the loop.
  • bodyPart : ActivityNode[0..*]
The set of nodes and edges that perform the repetitive computations of the loop. The body section is executed as long as the test section produces a true value.
  • test : ActivityNode[0..*]
The set of nodes, edges, and designated value that compute a Boolean value to determine if another execution of the body will be performed.
  • decider : OutputPin [1]
An output pin within the test fragment the value of which is examined after execution of the test to determine whether to execute the loop body.

Associations ((CompleteStructuredActivities)

  • result : OutputPin [0..*]
A list of output pins that constitute the data flow output of the entire loop.
  • loopVariable : OutputPin [0..*]
A list of output pins owned by the loop that hold the values of the loop variables during an execution of the loop. When the test fails, the values are copied to the result pins of the loop.
  • bodyOutput : OutputPin [0..*]
A list of output pins within the body fragment the values of which are copied to the loop variable pins after completion of execution of the body, before the next iteration of the loop begins or before the loop exits.
  • loopVariableInput : InputPin[0..*]
A list of values that are copied into the loop variable pins before the first iteration of the loop.

Constraints

None.

Semantics

No part of a loop node is executed until all control-flow or data-flow predecessors of the loop node have completed execution.

When all such predecessors have completed execution and made tokens available to inputs of the loop node, the loop node captures the input tokens and begins execution.

First the setup section of the loop node is executed. A front end node is a node within a nested section (such as the setup section, test section, or body section) that has no predecessor dependencies within the same section. A control token is offered to each front end node within the setup section. Nodes in the setup section may also have individual dependencies (typically data flow dependencies) on nodes external to the loop node. To begin execution, such nodes must receive their individual tokens in addition to the control token from the overall loop.

A back end node is a node within a nested section that has no successor dependencies within the same section. When all the back end nodes have completed execution, the overall section is considered to have completed execution. (It may be thought of as delivering a control token to the next section within the loop.)
When the setup section has completed execution, the iterative execution of the loop begins. The test section may precede or follow the body section (test-first loop or test-last loop). The following description assumes that the test section comes first. If the body section comes first, it is always executed at least once, after which this description applies to subsequent iterations.

When the setup section has completed execution (if the test comes first) or when the body sections has completed execution of an iteration, the test section is executed. A control token is offered to each front end node within the test section. When all back end nodes in the test section have completed execution, execution of the test section is complete. Typically there will only be one back end node and it will have a Boolean value, but for generality it is permitted to perform arbitrary computation in the test section.

When the test section has completed execution, the Boolean value on the designated decider pin within the test section is examined. If the value is true, the body section is executed again. If the value is false, execution of the loop node is complete.

When the setup section has completed execution (if the body comes first) or when the iteration section has completed execution and produced a true value, execution of the body section begins. Each front end node in the body section is offered a control token. When all back end nodes in the body section have completed execution, execution of the body section is complete.

Within the body section, variables defined in the loop node or in some higher-level enclosing node are updated with any new values produced during the iteration and any temporary values are discarded.

Notation

Examples

Rationale

Loop nodes are introduced to provide a structured way to represent iteration.

Changes from previous UML

Loop nodes are new in UML 2.0.

MergeNode

A merge node is a control node that brings together multiple alternate flows. It is not used to synchronize concurrent flows but to accept one among several alternate flows.

Description

A merge node has multiple incoming edges and a single outgoing edge.

Attributes

None.

Associations

Constraints

[1] A merge node has one outgoing edge.

Semantics

All tokens offered on incoming edges are offered to the outgoing edge. There is no synchronization of flows or joining of  tokens.

Notation

The notation for a merge node is a diamond-shaped symbol, as illustrated on the left side of the figure below. In usage, however, the merge node must have two or more edges entering it and a single activity edge leaving it. The functionality of merge node and decision node can be combined by using the same node symbol, as illustrated at the right side of the figure below. This case maps to a model containing a a merge node with all the incoming edges shown the diagram and one outgoing
edge to a decision node that has all the outgoing edges shown in the diagram. It assumes the UML 2.0 Diagram InterchangeRFP supports the interchange of diagram elements and their mapping to model elements.


Examples

In the example below, either one or both of the behaviors, Buy Item or Make Item could have been invoked. As each completes, control is passed to Ship Item. That is, if only one of Buy Item or Make Item complete, then Ship Item is invoked only once; if both complete, Ship Item is invoked twice.



Rationale

Merge nodes are introduced to support bringing multiple flows together in activities. For example, if a decision is used after a fork, the two flows coming out of the decision need to be merged into one before going to a join. Otherwise the join will wait for both flows, only one of which will arrive.

Changes from previous UML

Merge nodes replace the use of PseudoState with junction kind in UML 1.5 activity modeling.

ObjectFlow


An object flow is an activity edge that can have objects or data passing along it.

Description

An object flow models the flow of values to or from object nodes.

(CompleteActivities) Object flows add support for modeling the effects of behaviors, multicast/receive, and token selection from object nodes and transformation of tokens.

Attributes (CompleteActivities)
Associations (CompleteActivities)
Constraints (BasicActivities)

[1] Object flows may have an action on at most one end.

[2] Object nodes connected by an object flow, with optionally intervening control nodes, must have compatible types. In particular, the downstream object node type must be the same or a supertype of the upstream object node type.

[3] Object nodes connected by an object flow, with optionally intervening control nodes, must have the same upper bounds.

Constraints (CompleteActivities)

[1] An edge with constant weight may not target an object node, or lead to an object node downstream with no intervening actions, that has an upper bound less than the weight.

[2] A transformation behavior has one input parameter and one output parameter. The input parameter must be the same as or a supertype the type of object token coming from the source end. The output parameter must be the same or a subtype of the type of object token expected downstream. The behavior cannot have side effects.

[3] An object flow may have a selection behavior only if has an object node as a source.

[4] A selection behavior has one input parameter and one output parameter. The input parameter must be a bag of elements of  the same as or a supertype the type of source object node. The output parameter must be the same or a subtype of the type of source object node. The behavior cannot have side effects.

[5] isMulticast and isMultireceive cannot both be true.

[6] Only object flows with actions at one end or the other may have effects. Only object flows with actions on the target end  may have a delete effect. Only object flows with actions on the source end may have create effect.

Semantics (BasicActivities)

See semantics inherited from ActivityEdge. An object flow is an activity edge that only passes object and data tokens.

Tokens offered by the source node are all offered to the target node, subject to the restrictions inherited from ActivityEdge.

Two object flows may have the same object node as source. In this case the edges will compete for objects. Once an edge takes an object from an object node, the other edges do not have access to it. Use a fork to duplicate tokens for multiple uses.

Semantics (CompleteActivities)

If a transformation behavior is specified, then each token offered to the edge is passed to the behavior, and the output of the behavior is given to the target node for consideration. Because the behavior is used while offering tokens to the target node, it may be run many times on the same token before the token is accepted by the target node. This means the behavior cannot have side effects. It may not modify objects, but it may for example, navigate from one object to another, get an attribute value from an object, or replace a data value with another.

If a selection behavior is specified, then it is used to offer a token from the source object node to the edge, rather than using object node's ordering. It has the same semantics as selection behavior on object nodes. See ObjectNode. See application at DataStoreNode.

Multicasting and receiving is used in conjunction with partitions to model flows between behaviors that are the responsibility of objects determined by a publish and subscribe facility. To support execution the model must be refined to specify the particular publish/subscribe facility employed. This is illustrated in the Figure 274.

Notation

An object flow is notated by an arrowed line.



(CompleteActivities) Selection behavior is specified with the keyword «selection» placed in a note symbol, and attached to the appropriate objectFlow symbol as illustrated in the figure below.



(CompleteActivities) Specifying the effect that the behavior of the actions have on the objects flowing on the edge can be represented by placing the effect in braces near the edge leading to the affected object node. Since flows from actions to pins are elided, the effect is shown next to the pin.


Presentation Option


To reduce clutter in complex diagrams, object nodes may be elided. The names of the invoked behaviors can suggest their parameters. Tools may support hyperlinking from the edge lines to show the data flowing along them, and show a small square above the line to indicate that pins are elided, as illustrated in the figure below. Any adornments that would normally be near the pin, like effect, can be displayed at the ends of the flow lines.

Examples

In the example on the left below, the two arrowed lines are both object flow edges. This indicates that order objects flow from Fill Order to Ship Order. In the example on the right, the one arrowed line starts from the Fill Order object node pin and ends at Ship Order object node pin. This also indicates that order objects flow from Fill Order to Ship Order.



On the left, the example below shows the Pick Materials activity provide an order along with its associated materials for assembly. On the right, the object flow has been simplified through eliding the object flow details.



(CompleteActivities) In the figure below, two examples of selection behavior are illustrated. The example on the left indicates that the orders are to be shipped based or order priority--and those with the same priority should be filled on a first-in/first-out (FIFO) basis. The example on the right indicates that the result of a Close Order activity produces closed order objects, but the Send Customer Notice activity requires a customer object. The selection, then, specifies that a query operation that takes an Order evaluates the customer object via the Order.customer:Party association. At the bottom of the figure, an example depicts a Place Order activity which creates orders and Fill Order activity which reads these placed orders for the purpose of filling them.



(CompleteActivities) In the example below, the Requests for Quote (RFQs) are sent to multiple specific sellers (i.e. is multicast) for a quote response by each of the sellers. Some number of sellers then respond by returning their quote response.

Since multiple responses can be received, the edge is labeled for the multiple-receipt option. Publish/subscribe and other brokered mechanisms can be handled using the multicast and multireceive mechanisms. Note that the swimlanes are an important feature for indicating the subject and source of this.



Rationale

Object flow is introduced to model the flow of data and objects in an activity.

Changes from previous UML

Explicitly modeled object flows are new in UML 2.0. They replace the use of (state) Transition in UML 1.5 activity modeling.

They also replace data flow dependencies from UML 1.5 action model.

ObjectFlowEffectKind

The datatype ObjectFlowEffectKind is an enumeration that indicates the data base effect of an action.

Enumeration Values

ObjectNode

An object node is an abstract activity node that is part of defining object flow in an activity.

Description

An object node is an activity node that indicates an instance of a particular classifier, possibly in a particular state, may be available at a particular point in the activity. Object nodes can be used in a variety of ways, depending on where objects are flowing from and to, as described in the semantics section.

(CompleteActivities) Complete object nodes add support for token selection, limitation on the number of tokens, and specifying the state required for tokens.

Attributes (CompleteActivities)
Associations (BasicActivities)

None.

Associations (CompleteActivities)

Constraints (BasicActivities)

[1] All edges coming into or going out of object nodes must be object flow edges.

Constraints (CompleteActivities)

[1] The upper bound must be equal to the upper bound of nearest upstream and downstream object nodes that do not have intervening action nodes.

[2] If an object node has a selection behavior, then the ordering of the object node is ordered, and vice versa.

[3] A selection behavior has one input parameter and one output parameter. The input parameter must be a bag of elements of  the same type as the object node or a supertype of the type of object node. The output parameter must be the same or a subtype of the type of object node. The behavior cannot have side effects.

Semantics

Object nodes may only contain values at runtime that conform to the type of the object node, in the state or states specified, if any. If no type is specified, then the values may be of any type. Multiple tokens containing the same value may reside in the object node at the same time. This includes data values.

Semantics (CompleteActivities)

An object node may not contain more tokens than its upper bound. The upper bound must be a positive LiteralInteger or a LiteralNull. An upper bound that is a LiteralNull means the upper bound is unlimited. See ObjectFlow for additional rules regarding when objects may traverse the edges incoming and outgoing from an object node.

The ordering of an object node specifies the order in which tokens in the node are offered to the outgoing edges. This can be set to require that tokens do not overtake each other as they pass through the node (FIFO), or that they do (LIFO or modeler-defined ordering). Modeler-defined ordering is indicated by an ordering value of ordered, and a selection behavior that determines what token to offer to the edges. The selection behavior takes all the tokens in the object node as input and chooses a single token from those. It is executed whenever a token is to be offered to an edge. Because the behavior is used while
offering tokens to outgoing edges, it may be run many times on the same token before the token is accepted by those edges.

This means the behavior cannot have side effects. The selection behavior of an object node is overridden by any selection behaviors on its outgoing edges. See ObjectFlow. Overtaking due to ordering is distinguished from the case where the each invocation of the activity is handled by a separate execution of the activity. In this case, the tokens have no interaction with each other, because they flow through separate executions of the activity. See Activity.

Notation

Object nodes are notated as rectangles. A name labeling the node is placed inside the symbol, where the name indicates the type of the object node. Object nodes whose instances are sets of the "name" type are labeled as such. Object nodes with a signal as type are shown with the symbol on the right.


(CompleteActivities) A name labeling the node indicates the type of the object node. The name can also be qualified by a state or states, which is to be written within brackets below the name of the type. Upper bounds and ordering other than the  are notated in braces underneath the object node.

(CompleteActivities) Selection behavior is specified with the keyword «selection» placed in a note symbol, and attached to an ObjectNode symbol as illustrated in the figure below.


Presentation Option

It is expected that the UML 2.0 Diagram Interchange RFP will define a metaassociation between model elements and view elements, like diagrams. It can be used to link an object node to an object diagram showing the classifier that is the type of the object and its relations to other elements. Tools can use this information in various ways to integrate the activity and class diagrams, such as a hyperlink from the object node to the diagram, or insertion of the class diagram in the activity diagram as desired. See example in Figure 287.

Style Guidelines

Examples

See examples at ObjectFlow and children of ObjectNode.

Rationale

Object nodes are introduced to model the flow of objects in an activity.

Changes from previous UML

ObjectNode replaces and extends ObjectFlowState in UML 1.5. In particular, it and its children support collection of tokens at runtime, single sending and receipt, and the new "pin" style of activity model.

ObjectNodeOrderingKind

ObjectNodeOrderingKind is an enumeration indicating queuing order within a node.

Enumeration Values

OutputPin

An output pin is a pin that holds output values produced by an action. Output pins are object nodes and deliver values to other actions through object edges. See Pin, Action, and ObjectNode for more details.

Attributes

None.

Associations

None.

Constraints

[1] Output pins have outgoing edges only.

 Parameter (as specialized)

(CompleteActivities) Parameter is specialized when used with complete activities.

Description

Parameters are extended in complete activities to add support for streaming, exceptions, and parameter sets.

Attributes

Associations

None.

Constraints

[1] A parameter cannot be a stream and exception at the same time.

[2] An input parameter cannot be an exception.

[3] Reentrant behaviors cannot have stream parameters.

Semantics

isException applies to output parameters. An output posted to an exception excludes outputs from being posted to other data and control outputs of the behavior. A token arriving at an exception output parameter of an activity aborts all flows in the activity. Any objects previously posted to non-stream outputs never leave the activity. Streaming outputs posted before any exception are not affected. Use exception parameters on activities only if it is desired to abort all flows in the activity. For example, if the same execution of an activity is being used for all its invocations, then multiple streams of tokens will be flowing through the same activity. In this case, it is probably not desired to abort all tokens just because one reaches an exception. Arrange for separate executions of the activity to use separate executions of the activity when employing exceptions, so tokens from separate executions will not affect each other.

Streaming parameters give an action access to tokens passed from its invoker while the action is executing. Values for streaming parameters may arrive anytime during the execution of the action, not just at the beginning. Multiple value may arrive on a streaming parameter during a single action execution and be consumed by the action. In effect, streaming parameters give an action access to token flows outside of the action while it is executing. In addition to the execution rules
given at Action, these rules also apply to invoking a behavior with streaming parameters:

The execution rules above provide for the arrival of inputs after a behavior is started and the posting of outputs before a behavior is finished. These are stream inputs and outputs. Multiple stream input and output tokens may be consumed and posted while a behavior is running. Since an activity is a kind of behavior, the above rules apply to invoking an activity, even if the invocation is not from another activity. A reentrant behavior cannot have streaming parameters because there are
potentially multiple executions of the behavior going at the same time, and it is ambiguous which execution should receive streaming tokens.

See semantics of Action and ActivityParameterNode.

Notation

See notation at Pin and ActivityParameterNode. The notation in class diagrams for exceptions and streaming parameters on operations has the keywords "exception" or "stream" in the property string. See notation for Operation.

Examples

See examples at Pin and ActivityParameterNode.

Rationale

Parameter (in Activities) is extended to support invocation of behaviors by activities.

Changes from previous UML

Parameter (in Activities) is new in UML 2.0.

ParameterSet

A parameter set is an element that provides alternative sets of inputs and outputs that a behavior may use.

Description

An parameter set acts as a complete set of inputs and outputs to a behavior, exclusive of other parameter sets on the behavior.

Attributes

None.

Associations (CompleteActivities)

Constraints

[1] The parameters in a parameter set must all be inputs or all be outputs of the same parameterized entity, and the parameter set is owned by that entity.

[2] If a behavior has input parameters that are in a parameter set, then any inputs that are not in a parameter set must be streaming. Same for output parameters.

Semantics

A behavior with input parameter sets can only accept inputs from parameters in one of the sets per execution. A behavior with output parameter sets can only post outputs to the parameters in one of the sets per execution. The semantics described at Action and ActivityParameter apply to each set separately.

Notation

Multiple object flows entering or leaving a behavior invocation are typically treated as "and" conditions. However, sometimes one group of flows are permitted to the exclusion of another. This is modeled as parameter set and notated with rectangles surrounding one or more pins. The notation in the figure below expresses a disjunctive normal form where one group of "and" flows are separated by "or" groupings. For input, when one group or another has a complete set of input flows, the activity may begin. For output, based on the internal processing of the behavior, one group or other of output flows may occur.

Examples

In the figure below, the Ship Item activity begins whenever it receives a bought item or a made item. The diagram on the left uses a decision diamond; the one on the left uses parameter sets to express the same notion. The example at the bottom of the figure is a similar simplification of the Trouble Ticket example earlier.


Rationale

Parameter sets provide a way for behaviors to direct token flow in the activity which invokes those behaviors.

Changes from previous UML

ParameterSet is new in UML 2.0.

 Pin

A pin is an object node for inputs and outputs to actions.

Description

Pins are connected as inputs and outputs to actions. They provide values to actions and accept result values from them.

Attributes

None.

Associations

None.

Constraints
[1] If the action is an invocation action, the number and types of pins must be the same as the number of parameters and types of the invoked behavior or behavioral feature. Pins are matched to parameters by order.

See constraints on ObjectFlow.

Semantics

A pin represents an input to an action or an output from an action. The definition on an action assumes that pins are ordered (although names are usually sufficient in the notation to disambiguate pins, so the ordering is rarely shown in the notation).

Notation
Pin rectangles may be notated as small rectangles that are attached to action rectangles. See figure below and examples. The name of the pin can be displayed near the pin. The name is not restricted, but it is often just shows the type of object or data that flows through the pin. It can also be a full specification of the corresponding behavior parameter for invocation actions, using the same notation as parameters for behavioral features on classes. The pins may be elided in the notation even though they are present in the model.


The situation in which the output pin of one action is connected to the input pin of the same name in another action may be shown by the optional notations of Figure 281. The standalone pin in the notation maps to an output pin and an input pin in the underlying model. This form should be avoided if the pins are not of the same type. These variations in notation assume the UML 2.0 Diagram Interchange RFP supports the interchange of diagram elements and their mapping to model elements, so that the chosen variation is preserved on interchange.


See ObjectNode for other notations applying to pins, with examples for pins below.

(CompleteActivities) To show streaming, a text annotation is placed near the pin symbol: {stream} or {nonstream}. See figure below. The notation is the same for a standalone object node. Nonstream is the default where the notation is omitted.



(CompleteActivities) Pins for exception parameters are indicated with a small triangle annotating the source end of the edge that comes out of the exception pin. The notation is the same even if the notation uses a standalone notation. See figure below.


See ObjectNode for other notations applying to pins, with examples for pins below.

Presentation Option

When edges are not present to distinguish input and output pins, an optional arrow may be placed inside the pin rectangle, as shown below. Input pins have the arrow pointing toward the action and output pins have the arrow pointing away from the action.



(CompleteActivities) Additional emphasis may be added to streaming parameters by using a graphical notation instead of the textual adornment. Object nodes can be connected with solid arrows contained filled arrowheads to indicate streaming. Pins can be shown as filled rectangles. When combined with the option above, the arrows are shown as normal arrowheads.



Examples

In the example below, the pin named "Order" represents Order objects. In this example at the upper left, the Fill Order behavior produces filled orders and Ship Order consumes them and an invocation of Fill Order must complete for Ship Order to begin. The pin symbols have been elided from the actions symbols; both pins are represented by the single box on the arrow.

The example on the upper right shows the same thing with explicit pin symbols on actions. The example at the bottom of the figure illustrates the use of multiple pins.


In the figure below, the object node rectangle Order is linked to a class diagram that further defines the node. The class diagram shows that filling an order requires order, line item, and the customer's trim-and-finish requirements. An Order token is the object flowing between the Accept and Fill activities, but linked to other objects. The activity without the class diagram provides a simplified view of the process. The link to an associated class diagram is used to show more detail.

(CompleteActivities) In the example below Order Filling is a continuous behavior that periodically emits (streams out) filled-order objects, without necessarily concluding as an activity. The Order Shipping behavior is also a continuous behavior that periodically receives filled-order objects as they are produced. Order Shipping is invoked when the first order arrives and does not terminate, processing orders as they arrive.


(CompleteActivities) Examples of exception notation is shown at the top of the figure below. Accept Payment normally completes with a payment as being accepted and the account is then credited. However, when something goes wrong in the acceptance process, an exception can be raised that the payment is not valid, and the payment is rejected.



(CompleteActivities) The figure below shows two examples of selection behavior. Both examples indicate that orders are to be shipped based or order priority--and those with the same priority should be filled on a first-in/first-out (FIFO) basis.



Rationale

Pins are introduced to model inputs and outputs of actions.

Changes from previous UML

Pin is new to activity modeling in UML 2.0. It replaces pins from UML 1.5 action model.

StructuredActivityNode

(StructuredActivities) A structured activity node is an executable activity node that may have an expansion into subordinate nodes as an ActivityGroup. The subordinate nodes must belong to only one structured activity node, although they may be nested.

Description

A structured activity node represents a structured portion of the activity that is not shared with any other structured node, except for nesting. It may have control edges connected to it, and pins in CompleteStructuredActivities. The execution of any embedded actions may not begin until the structured activity node has received its object and control tokens. The availability of output tokens from the structured activity node does not occur until all embedded actions have completed execution.
(CompleteStructuredActivities) Because of the concurrent nature of the execution of actions within and across activities, it can be difficult to guarantee the consistent access and modification of object memory. In order to avoid race conditions or other concurrency-related problems, it is sometimes necessary to isolate the effects of a group of actions from the effects of actions outside the group. This may be indicated by setting the mustIsolate attribute to true on a structured activity node. If a
structured activity node is "isolated," then any object used by an action within the node cannot be accessed by any action outside the node until the structured activity node as a whole completes. Any concurrent actions that would result in accessing such objects are required to have their execution deferred until the completion of the node.

Note ­ Any required isolation may be achieved using a locking mechanisms, or it may simply sequentialize execution to avoid concurrency conflicts. Isolation is different from the property of "atomicity", which is the guarantee that a group of actions either all complete successfully or have no effect at all. Atomicity generally requires a rollback mechanism to prevent committing partial results.

Attributes

None.

Associations
Constraints

[1] The edges owned by a structured node must have source and target nodes in the structured node.

Semantics

Nodes and edges contained by a structured node cannot be contained by any other structured node. This constraint is modeled as a specialized multiplicity from ActivityNode and ActivityEdge to StructuredActivityNode. See children of structuredActivityNode.

No subnode in the structured node may begin execution until the node itself has consumed a control token. A control flow from a structured activity node implies that a token is produced on the flow only after no tokens are left in the node or its contained nodes recursively.

(CompleteStructuredActivities) An object node attached to a structured activity node is accessible within the node. The same rules apply as for control flow. An input pin on a structured activity node implies that no action in the node may begin execution until all input pins have received tokens. An output pin on a structured activity node will make tokens available outside the node only after no tokens left in the node or its contained nodes recursively.

Notation

A structured activity node is notated with a dashed round cornered rectangle enclosed its nodes and edges, with the keyword «structured» at the top. Also see children of StructuredActivityNode.

Examples

See children of StructuredActivityNode.

Rationale

StructuredActivityNode is for applications that require well-nested nodes. It provides well-nested nodes that were enforced by strict nesting rules in UML 1.5.


Changes from previous UML

StructuredActivityNode is new in UML 2.0.

ValuePin

A value pin is an input pin that provides a value to an action that does not come from an incoming object flow edge.

Attributes

None.

Associations
Constraints

[1] Value pins have no incoming edges.

[2] The type of value specification must be compatible with the type of the value pin.

Semantics

ValuePins provide values to their actions, but only when the actions are otherwise enabled. If an action has no incoming edges or other way to start execution, a value pin will not start the execution by itself or collect tokens waiting for execution to start.

When the action is enabled by these other means, the value specification of the value pin is evaluated and the result provided as input to the action, which begins execution. This is an exception to the normal token flow semantics of activities.

Notation

A value pin is notated as an input pin with the value specification written beside it.

Examples

Rationale

ValuePin is introduced to reduce the size of activity models that use constant values.

Changes from UML 1.5

ValuePin replaces LiteralValueAction from UML 1.5.

 Variable

(StructuredActivities) Variables are elements for passing data between actions indirectly. A local variable stores values shared by the actions within a structured activity group but not accessible outside it. The output of an action may be written to a variable and read for the input to a subsequent action, which is effectively an indirect data flow path. Because there is no predefined relationship between actions that read and write variables, these actions must be sequenced by control flows to prevent race conditions that may occur between actions that read or write the same variable.

Description

A variable specifies data storage shared by the actions within a group. There are actions to write and read variables. These actions are treated as side effecting actions, similar to the actions to write and read object attributes and associations. There are no sequencing constraints among actions that access the same variable. Such actions must be explicitly coordinated by control flows or other constraints.

Any values contained by a variable must conform to the type of the variable and have cardinalities allowed by the multiplicity of the variable.

Associations

None.

Attributes
Constraints

None.

Semantics

A variable specifies a slot able to hold a value or a sequence of values, consistent with the multiplicity of the variable. The values held in this slot may be accessed from any action contained directly or indirectly within the group action that is the scope of the variable.

Notation

None.

Examples

None.

Rationale

Variables are introduced to simplify translation of common programming languages into activity models for those applications that do not require object flow information to be readily accessible. However, source programs that set variables only once can be easily translated to use object flows from the action that determines the values to the actions that use them. Source programs that set variables more than once can be translated to object flows by introducing a local object containing attributes for the variables, or one object per variable combined with data store nodes.

Changes from UML 1.5

Variable is unchanged from UML 1.5, except that it is used on StructuredActivityNode instead of GroupNode.