12.3.4 Activity

*Generalizations

   •

    Behavior (from BasicBehaviors ) on page 447

*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-ofcontrol 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:

   •

   Occurrences of primitive functions, such as arithmetic functions.

   •

   Invocations of behavior, such as activities.

   •

   Communication actions, such as sending of signals.

   •

   Manipulations of objects, such as reading or writing attributes or associations.

   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 that 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:

   •

   Object flows for sequencing data produced by one node that is used by other nodes.

   •

   Control flows for sequencing the execution of nodes.

   •

   Control nodes to structure control and object flow. These include decisions and merges to model contingency. These also include initial and final nodes for starting and ending flows. In IntermediateActivities , they include forks and joins for creating and synchronizing concurrent subexecutions.

   •

   Activity generalization to replace nodes and edges.

   •

   Object nodes to represent objects and data as they flow in and out of invoked behaviors, or to represent collections of tokens waiting to move downstream.

   Package StructuredActivities

   •

   Composite nodes to represent structured flow-of-control constructs, such as loops and conditionals.

   Package IntermediateActivities

   •

   Partitions to organize lower-level activities according to various criteria, such as the real-world organization responsible for their performance.

   Package CompleteActivities

   •

   Interruptible regions and exceptions to represent deviations from the normal, mainline flow of control.

*Attributes

   Package BasicActivities

• 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 non-local changes).

• isSingleExecution : Boolean = false If true, all invocations of the activity are handled by the same execution.

   Package CompleteActivities

*Associations

   Package FundamentalActivities

Issue 8208 - add subsets constraints

• group : ActivityGroup [0..*] Top-level groups in the activity. {Subsets Namespace ::ownedElement}

• node : ActivityNode [0..*] Nodes coordinated by the activity. {Subsets Namespace ::ownedElement}

   Package BasicActivities

   • edge : ActivityEdge [0..*] Edges expressing flow between nodes of the activity. {Subsets Namespace ::ownedElement}

   Package IntermediateActivities

   • partition : ActivityPartition [0..*] Top-level partitions in the activity. {Subsets ActivityGroup ::group}

   Package StructuredActivities

• /structuredNode : StructuredActivityNode [0..*] Top-level structured nodes in the activity. Subsets

• variable : Variable [0..*] Top-level variables in the activity. Subsets Namespace ::ownedMember.

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

Issue 8208 -add new constraint

   [3] The groups of an activity have no supergroups.

*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 in IntermediateActivities , but not in BasicActivities .

    Activities can be parameterized, which is a capability inherited from Behavior (see 12.3.9, ActivityParameterNode (from BasicActivities ), on page 350). 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 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.

Issue 8681 - add sentence with a pointer to Parameter at the end of the paragraph.

   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. See Parameter (from CompleteActivities ) on page 412 for more about how activities start and stop execution

   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.

Issue 8679 - add explanation on multiple targets case

   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. Multiple tokens offered to an edge at once is the same as if they were offered one at a time. Since multiple edges can leave the same node, the same token can be offered to multiple targets. However, a token can only be accepted at one target. This means 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 move 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.

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

   Package 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. This applies even if the behavior is a method, for example, on each order. 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 that is the behavior of a classifier, 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. The same is true for modeling methods in common programming languages, which have separate stack frames for each method call. 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 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.

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

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

   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 (from BasicActivities , CompleteActivities , FundamentalActivities , IntermediateActivities , CompleteStructuredActivities ) and ActivityEdge (from BasicActivities , CompleteActivities , CompleteStructuredActivities , IntermediateActivities ) 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 (from IntermediateActivities ) 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 post condition 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 12.33 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 Options

    The round-cornered border of Figure 12.33 may be replaced with the frame notation described in Annex A. Activity parameter nodes are displayed on the frame. The round-cornered border or frame may be omitted completely. See the presentation option for ActivityParameterNode (from BasicActivities ) on page 350.

*Examples

   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.

Issue 8357 -duplicate of 85028502 -replace ‘singleCopy’ with ‘singleExecution’

   The diagram below is based on a standard part selection workflow within an airline design process. 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, Schedule Part Mod Workflow invocation produces entire activities and they are passed to subsequent invocations for scheduling and execution (i.e.,

   Schedule Part 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.

Issue 8732 -add merge node in top diagram before UsePart and reroute flows to it

Issue 8208 - add explanatory paragraph

    Figure 12.37shows another example activity for a process to resolve a trouble ticket.

   Below is an example of using class notation to show the class features of an activity. Associations and state machines can also be shown.

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